Mi occupo di automazione dal 2004 circa, quando gestivo quasi 200 nodi AlphaServer. In particolare mi occupavo della parte hardware: sembra banale, ma occorre considerare che esisteva un mini sistema operativo in esecuzione sotto lo Unix che verificava i componenti connessi, rilevando errori critici e non. Identificare il prima possibile gli errori non critici, significava poter pianificare un fermo per sostituire il componente che si stava guastando risparmiandosi una notte di lavoro.

L’automazione che avevo creato allora era uno script che, tramite SSH, accedeva alle varie istanze di Tru64 UNIX, eseguiva gli strumenti di diagnostica, recuperava gli errori rilevati, li categorizzava secondo la criticità, e li rendeva disponibili per una review.

Successivamente, era circa il 2007, mi sono trovato a gestire installazioni di sistemi Linux in modo abbastanza ricorrente. Sostituire l’installazione a DVD con un sistema automatico, significava risparmiare diverse ore di lavoro su base settimanale. Allora decisi di usare PXE, mediante il quale all’accensione di un sistema, fisico o virtuale, veniva caricato l’installer Linux che installava la base del sistema operativo secondo alcuni parametri di base definiti come “standard” (poi capiremo il senso delle virgolette).

Tali sistemi Linux richiedevano poi di essere personalizzati in base al ruolo, installando pacchetti e configurazioni specifiche. Dopo aver provato CFEngine e puppet, decisi di usare quest’ultimo che, anche se da poco rilasciato, mi era sembrato meno complicato.

Successivamente mi spostai nell’ambito network gestendo decine di router Cisco. Questi router contenevano alcune access list usate per filtrare traffico e per classificarlo in base alla QoS richiesta. Settimanalmente c’erano alcune piccole modifiche da effettuare a queste access list. L’automazione che avevo creato si basava su Expect, che, via SSH, si collegava ai vari router e sostituiva (aggiornava) le access list. Netmiko e Ansible erano ancora nei sogni di quelli che li avrebbero sviluppati.

Nel 2011, per esigenze personali di studio, avevo necessità di automatizzare la creazione di laboratori di rete, e fu così che nacque UNetLab, ora gestito sotto il nome di EVE-NG che è appunto la base del nostro laboratorio.

Esperienze successive nell’ambito automazione includono:

• l’automazione di policy firewall Palo Alto Networks per attivare, in specifiche finestre di manutenzione, l’accesso remoto a dispositivi industriali (il progetto è poi stato interamente riscritto come FWAdmin, plugin per Netbox);
• l’automazione della discovery di reti e la generazione di parte della documentazione (il progetto è evoluto nel tempo e ora è rilasciato come NetDoc, plugin per NetBox);
• la migrazione di un datacenter su tecnologia Cisco ACI (ho sviluppato script Python che invocavano direttamente le API);
• la generazione di una bozza di remediation plan a partire dagli output di Nessus;
• il provisioning di linee per un service provider su tecnologica Cisco XR (ho scelto Ansible per permettere al team di rete di modificarsi autonomamente i playbook);
• la migrazione di un backbone per un service provider su tecnologica Cisco XR (ho scelto Ansible il provisioning dei dispositivi e PyATS + Genie per la validazione di circa 140 dispositivi).

Tutti questi progetti sono raggruppabili in due categorie che io chiamo:

• single task automation;
• process automation.

La differenza tra le due è sostanziale.

Single task automation

Chiamo single task automation l’attività che nasce da una necessità del tutto personale, volta ad automatizzare una serie di attività (task) della persona stessa. Nella maggior parte dei casi l’automazione in azienda nasce così: ci sono dei task ripetitivi, se la persona che li esegue è particolarmente creativa, essa scriverà un piccolo software per automatizzare quei task. Vediamone le caratteristiche:

• one shot;
• basato su script procedurali, scritti per risolvere un task, e generalmente non riusabili;
• finalizzato ad un uso personale;
• non coinvolge il team ma rimane confinato alla singola persona;
• non incluso in nessuna procedura;
• strettamente legato alla persona che l’ha sviluppato.

In breve:

• facile da implementare (pro);
• non scala, causa una proliferazione di script, ed è limitato a specifici task (contro).

Quello che caratterizza maggiormente questo tipo di automazioni è il breve ciclo di vita: nascendo sull’esigenza del singolo e non raggiungendo quasi mai il grado di processo, non appena l’autore cambia ruolo o azienda, l’automazione cessa.

Posso affermare che, nonostante il numero altissimo di ore risparmiate, l'80% dei miei progetti di automazione sia morto non appena ho cambiato ruolo o azienda.

Process automation

Chiamo process automation l’automazione, nata eventualmente anche da single task automation, che viene accettata a livello aziendale e diventa quindi il modo per eseguire uno o più task specifici. Gli script sono quindi documentati, mantenuti e usati da un team di persone. Ma non solo: gli script sono l’unico modo autorizzato per eseguire i task associati. Vediamone le caratteristiche:

• l’automazione è basata su framework approvati a livello aziendali e monitorati in termini di vulnerabilità;
• le persone non possono agire se non tramite gli script approvati e, in situazioni di emergenza questo potrebbe essere un problema;
• rispetto alla libertà totale, gli script offrono poca o nulla libertà di movimento e, in situazioni di emergenza questo potrebbe essere un problema;
• modifiche agli script sono consentite solo previa autorizzazione e relativi test;
• l’automazione è approvata dall’azienda e definita come standard.

In breve:

• il processo è definito, standardizzato, meno soggetto ad errori umani e, soprattutto grazie ad alcuni framework, auto documentato (pro);
• lo sviluppo dell’automazione è generalmente più lenta a causa del numero di persone da coinvolgere per la definizione del processo, per la standardizzazione, e per lo sviluppo. Alla lunga l’automazione toglie competenza, poiché le persone si abituano ad usare script e perdono la visione del mondo sottostante.