Elogio della semplicità

Un nuovo incarico presso un cliente che mi porta spesso in giro è il motivo principale dell’assenza e della rarefazione degli articoli di questo blog.

Uno dei problemi che sto affrontando è tentare quanto possibile di semplificare un’infrastruttura che parte complessa per ragioni strutturali con uffici letteralmente nei cinque continenti (sono stato graziato e per ora niente uffici stabili ai poli) e data centre che si spostano costantemente via mare da una time zone all’altra.

Chi c’era prima di me ha fatto un ottimo lavoro per cercare di mantenere semplice l’infrastruttura, ora tocca a me e alle persone del mio gruppo.

I motivi per cui un’infrastruttura tende a diventare complessa (anche se semplice nell’apparenza) sono molteplici e non tutti si applicano al caso su cui sto lavorando.

Sedimentazione – Questo è il problema principale: in un’infrastruttura si sovrappongono periodi di gestione diversi, è naturale. Spesso la nuova gestione o il nuovo software non può rimpiazzare immediatamente al 100% quello vecchio e il phase out dei sistemi vecchi arriva rapidamente all’80% per poi procedere lentamente al 90% e procedere sempre più lentamente dando l’impressione che la meta del 100% sia raggiungibile asintoticamente all’infinito. Zenone ci aveva visto molto lungo con il paradosso di Achille e la tartaruga.

Una delle ragioni è che spesso il rimanente 10% è al di fuori dell’IT e nessuno vuol prendersi la responsabilità di staccare la spina di un sistema obsoleto.

La soluzione è il coinvolgimento delle persone per sensibilizzarle sui costi di mantenimento di un sistema obsoleto e spesso inutilizzato. La responsabilità di dire “spegni” o la responsabilità di mantenere dei costi inutili.

Ego – Il peggiore. Il SysAdmin fa apposta a creare sistemi complessi per compiacersi delle proprie presunte capacità di creazione o per rendersi indispensabile. La replica di un dato dall’archivio A all’archivio B che può essere fatta connettendo i due archivi con API condivise passa attraverso un server terzo, tre schedulazioni indipendenti e non sincronizzabili, esportazioni, rielaborazioni, importazioni, script complessi, programmi di terze parti non manutenuti, dipendenze di librerie e di sistemi operativi e salcielo che altro. Sto esagerando? Non credo.

A questo problema non ci sono soluzioni che non siano drastiche o che non passino per la crescita intellettuale del SysAdmin, ma sto vagheggiando.

Questo tipo di persone ha tutto il mio viscerale, sincero e smisurato odio. Andate a zappare i campi.

Fortunatamente sia nell’incarico attuale sia in altri contesti ho molto poco a che fare con questo genere di individui.

Design iniziale – Un prodotto cambia nel tempo, ma spesso l’implementazione è figlia delle linee guida valide al momento della prima installazione. Pensiamo ad Active Directory, nel tempo con l’evolversi del prodotto le linee guida e le best practices sono cambiate, alcune volte con negazioni di quelle precedenti. Ci può stare, ma spesso l’adeguamento è complesso, se non impossibile. Un esempio per tutti: il nome a dominio base di Active Directory; nel tempo c’è stato un oscillare tra il nome a dominio Internet dell’organizzazione, un nome a dominio con un TLD inesistente e un nome a dominio registrato ma dedicato. Anche per le varie sedi si è passato da un modello a trust tra domini ad uno a foresta.

Qui la soluzione passa purtroppo per analisi e implementazioni delle modifiche, attività spesso molto onerose che fanno preferire lo status quo, finché il problema non diventa davvero grosso e ingestibile.

Interdipendenza– Alcuni processi dipendono necessariamente da altri, non si può fare a meno. Quello che si può, invece, ridurre è l’interdipendenza non strettamente necessaria. Esempio teorico: un rilevatore di presenze (o altro dispositivo analogo) che necessita di un IP fisso è meglio configurarlo con l’IP fisso impostato sul device anziché mettere il suo MAC nel server DHCP ed associarlo ad un IP fisso; questo perché se il DHCP non è disponibile quando si accendere il rilevatore di presenze (penso al ritorno di corrente dopo un blackout) potrebbero esserci degli errori che vanno poi gestiti.

In questo caso la soluzione non è dissimile dal metodo suggerito dal Rasoio di Occam (Pluralitas non est ponenda sine necessitate): i benefici dell’interdipendenza vanno sempre soppesati e confrontati con i problemi che potrebbero nascere se il servizio da cui si dipende non è disponibile.

Tecnologie forzatamente obsolete – Può capitare che venga adottata una tecnologia che sembra promettente o che viene molto propagandata, per scoprire che chi la vende l’ha abbandonata  in favore di un’altra tecnologia (HPE, sto parlando di te!). In questo caso ci si deve tenere in casa qualcosa che è stato pagato caro ma non ha più una vita di mercato e si sa che il supporto, benché garantito, sarà comunque inferiore a quello di altri prodotti.

Qui ci sono ben poche soluzioni, spesso i prodotti diventano obsoleti senza che sia onestamente possibile prevederlo. I capricci aziendali sono difficili da indovinare o prevedere.

In questo caso può aiutare l’utilizzo di prodotti che scambiano dati in modo standard o che si basino su soluzioni il più possibile standard in modo che siano rimpiazzabili in maniera quasi trasparente.

In linea generale, il suggerimento è sempre quello di valutare cosa succede se si rompe o si ferma qualcosa (un server, uno storage, un backup, un ufficio) e valutare come lo si fa ripartire o lo si ripristina da zero.

Inoltre prima di aggiungere qualcosa (server, VM, procedura, software) al sistema i vantaggi dell’aggiunta devono essere onestamente superiori ai disagi che si creano. Forte enfasi su onestamente: non fate i tifosi ottusi delle tecnologie che non vi viene in tasca nulla.