Automatizzare? Sempre!

30 Sep 2022 - Giulio Vian - ~7 minuti

Alcuni anni fa ho tenuto una conferenza, dal titolo “Automate? Always!” (Automatizzare? Sempre!), per stimolare una discussione sull’automazione nell’ingegneria del software. Oggi metto per iscritto l’argomento di quella presentazione sperando di raggiungere un pubblico più vasto.

Nota: in questo post mi riferisco a qualsiasi automazione nel ciclo di vita dello sviluppo software: spaziando dalle macro dell’editor agli script di distribuzione (con un’enfasi su questi ultimi).

Per favore pazienta, perché questo post sarà un po’ più lungo degli altri, e considera che ci sarebbe da dire di più che un singolo articolo.

Il buon senso: l’automazione fa risparmiare sui costi

Iniziamo con questa citazione «our goal should be to automate all the activities that are repeated while creating and maintaining the system» ( Priti Biyani, ThoughtWorks , enfasi mia) ossia «il nostro obiettivo dovrebbe essere automatizzare tutte le attività ripetitive durante la creazione e la manutenzione del sistema». ThoughtWorks suggerisce che la ripetizione innesca l’automazione e, osservo, l’autore sottindende un progetto greenfield, nuovo, e la sua evoluzione.

In modo meno solenne, più grafico, xkcd #1205 trasmette l’idea di risparmiare tempo.

Se non si risparmia tempo, suggerisce Randall, automatizzare è insensato. Si possono trovare altri esempi in letteratura, nei blog e sui giornali. Il presupposto comune è sempre: l’automazione è giustificata dal risparmio di tempo, cioè dal risparmio sui costi.

Sebbene questo sia semplice buon senso, la realtà è più sfumata e ho trovato un buon elenco di ragioni presso Mattias Geniar . Questi elenca sei giustificazioni:

risparmiare tempo,
per acquisire coerenza,
per guadagnare velocità, quantità di moto e velocità,
per programmare le attività,
per ridurre compiti noiosi o meno divertenti,
per rendere felici gli amministratori di sistema e gli sviluppatori.

Qui iniziamo a vedere due nuove prospettive: psicologica e operativa. Alla sua lista possiamo facilmente aggiungere che l’automazione nel software aiuta a:

ridurre gli errori umani e gli errori manuali,
migliorare la qualità dei processi, attraverso lo sforzo di progettazione e analisi,
ottenere di più, ad esempio consentendo alle persone di fare cose senza una conoscenza dettagliata degli interni di un sistema.

Nel proseguo di questo articolo cercherò di indagare su queste ulteriori motivazioni per l’automazione in modo che possiate valutare meglio elementi meno diretti e più intangibili, e con questi giustificare quando l’investimento nell’automazione è la cosa giusta per quel contesto specifico.

L’automazione crea opportunità, il risparmio sui costi è un effetto collaterale

A mio avviso ci sono sette dimensioni che aggiungono valore allo sforzo di automazione: l’esplorazione, il miglioramento dei processi, l’effetto a cascata, la soddisfazione, l’apprendimento, l’ispezione e la convalida e, infine, il monitoraggio. Esaminiamoli uno alla volta.

Esplorare

Si affronta una nuova applicazione, un nuovo sistema: le persone che ci hanno lavorato se ne sono andate, la documentazione è scarsa. Cosa puoi fare?

Aggiungere l’automazione è un modo per comprendere un sistema esistente. Considera il sistema come una scatola nera e prova ad automatizzare delle modifiche alla configurazione o a scrivere alcuni script per il deploy. Magari aggiungi una pipeline di CI che sostituisce gli script di build ad hoc che funzionano solo sulla macchina dello sviluppatore.

Tutte queste attività richiedono un certo livello di reverse engineering e di sperimentare il sistema in modo quasi scientifico: ipotizzi, sperimenti e convalidi la tua ipotesi su come il sistema interagisce con l’ambiente. Configurazione, dipendenze, relazioni emergeranno come risultato dei tuoi tentativi di automatizzarlo.

Miglioramento

Qualsiasi automazione rimuove un processo manuale, non è evidente? Non sempre. Rimuovere l’intervento umano non è semplice e scontato: potresti dover affrontare resistenze, giochi di potere, paure. Per questo la tua automazione deve avere due caratteristiche: essere trasparente e apportare valore. La trasparenza ha due aspetti: uno è la visibilità del funzionamento interno dell’automazione, l’altro è il monitoraggio dei passaggi di automazione per l’auditing e il debug. L’apporto di valore può avere più sfaccettature:

un amministratore riduce il tempo per un’attività,
un utente deve aspettare meno per un risultato,
più compiti completati senza errori,
errori costosi prevenuti da controlli anticipati.

In generale dovremmo considerare sia gli effetti positivi diretti sia gli effetti negativi e preventivi; i guadagni in aggiunta alla riduzione dei costi.

Documentare

Tutti noi abbiamo incontrato un sistema scarsamente documentato. Cercare di automatizzare è un modo per descriverne il comportamento. Questo approccio è simile all’effetto descritto da molti blogger: per imparare bene qualcosa mi costringo a scriverne. È anche simile ad implementare dei test automatici per un’applicazione: ogni test definisce esattamente una piccola parte del comportamento del sistema. Il valore dell’automazione starà in ciò che potremmo chiamare “documentazione eseguibile”: non un documento passivo, che richiede interpretazione, ma qualcosa che puoi usare per agire sul sistema. Automatizzare per documentare implica, però, che il codice sorgente dell’automazione sia pubblicato in una posizione di facile accesso, dove chiunque sia interessato al sistema di destinazione cercherà informazioni.

Effetto a cascata

Considera ora questi effetti positivi non intenzionali:

il successo nell’automazione di un elemento può indurre o consentire l’automazione di altre componenti,
può avviare una emulazione virtuosa e più persone automatizzeranno le proprie faccende con generale guadagno per tutta l’organizzazione,
esemplifica la fattibilità tecnica preparando la via ad altre automazioni,
dimostra valore al management.

La maggior parte degli elementi elencati sono psicologici e si riflettono sulle prestazioni dell’organizzazione.

Soddisfazione

Tra gli effetti psicologici più sottili, meno quantificabili sebbene reali, includerei:

persone più contente, perché delegano le faccende noiose alle macchine e possono concentrarsi su problemi più interessanti,
semplicità e facilità d’uso, rispetto a seguire delle istruzioni scritte o a spuntare liste di controlli,
quel senso di realizzazione che ogni sviluppatore conosce quando un programma è completo e funziona come previsto,
quando l’attività automatizzata è complessa, riduciamo lo sforzo mentale per eseguirla in futuro.

Apprendimento

Ho menzionato prima l’idea di automatizzare per imparare, ma cosa si può imparare? Ovviamente potremmo imparare nuove tecnologie e linguaggi di scripting. Meno evidente è l’opportunità di esplorare concetti di infrastruttura, fare esperienza con problemi e vincoli reali. Che magnificenza è apprezzare la latenza di rete copiando file da una parte all’altra dell’oceano! Impara come funziona davvero il parallelismo cercando di ridurre al minimo i tempi di deploy su un gruppo di macchine.

Ispeziona e valida

Nomina legacy (un sistema antiquato) e un brivido percorre la spina dorsale di qualsiasi ingegnere. Sistema legacy, codice legacy, come possiamo fidarcene, come possiamo manipolarlo o cambiarlo? Ecco, l’automazione è proprio un modo per ispezionare e rivedere una componente esistente. Scrivere uno script di compilazione, uno script di distribuzione, uno script per modificare la configurazione, son vie per costringerci a rivedere le configurazioni manuali in essere, a mettere in discussione i valori impostati, per aggiungere controlli di convalida automatizzati lungo il processo. Mi sono spesso imbattuto in file di configurazione che sono solo un caos di proprietà non correlate, senza organizzazione né standardizzazione dei nomi. Come il corallo o le stalattiti, passava inosservato nell’oscurità e cresce, cresce, cresce. È ora di mettere in discussione, rivedere, ripulire!

Traccia

Un ultimo elemento da affrontare è il guadagno in visibilità. L’automazione aiuta a identificare utilizzi, dipendenze e configurazioni. Invece di cercare in un documento Word la frase che il sistema richiede installare la versione X di un componente, questa dipendenza viene indicata in bella vista in uno script di automazione. Anzi mettiamo un test se sia installata una versione corretta e sennò la installiamo!

L’automazione consente anche di raccogliere informazioni e archiviarle in un luogo centrale. Un esempio è la creazione di un database delle dipendenze a livello di organizzazione, fondamentale per gestire i problemi di sicurezza (Distinta base del software, SBOM). Questo diventa ogni giorno più rilevante: non solo i sistemi, ma un preciso e aggiornato inventario per gestirli.

Conclusione

“Automate ALL the things” ( Niall Murphy et al., Site Reliability Engineering, O’Reilly 2016 ), ossia automatizza TUTTO è un’idea fondamentale della moderna ingegneria del software. Vogliamo delegare di più alle macchine e passare a uno stile dichiarativo.

Nella pratica, considera cosa automatizzare per primo, pianifica aggiungere incrementalmente un po’ di automazione al tuo lavoro quotidiano, assegna le priorità considerando tutti gli effetti, sia diretti che indiretti. Non cadere nella trappola di automatizzare la cosa sbagliata, al momento sbagliato: xkcd #1319

Fotografa lo stato prima e dopo, meglio se includi una o più metriche oggettive. Comunica ciò che hai ottenuto, mostrandone i benefici. Racconta ad un’ampia platea mostrando le misure che hai preso: ispirerà gli altri. Infine, non dimenticare che DevOps non è automazione; è l’automazione che supporta la prospettiva DevOps.

Riferimenti

Voi che ne pensate?

Architecture
DevOps Automation