Ho Automatizzato Tutto e Mi Sono Reso Inutile: La Mia Storia

Nove mesi fa ho iniziato una collaborazione con una nuova azienda. Infrastruttura AWS abbastanza grossa, team IT ridotto, processi manuali ovunque. Il classico scenario che conosco bene, sysadmin che spengono incendi tutto il giorno, nessun tempo per costruire qualcosa di solido. Mi sono rimboccato le maniche e ho fatto quello che so fare, ho automatizzato quasi tutto. Patch management, cost optimization, backup con restore testing automatico, monitoring custom su stack applicativi, pulizia periodica dei server. In meno di tre trimestri, il mio calendario si era svuotato. E lì è iniziato il problema vero.

Questo articolo non è una success story, è una riflessione onesta su cosa succede quando un sysadmin fa troppo bene il suo lavoro e su come trasformare quella situazione in un vantaggio strategico invece di un boomerang professionale.

La Fase Operativa: Come Ho Costruito l’Automazione

Quando sono arrivato, il primo mese l’ho passato a mappare tutto, solo osservare, documentare, capire i flussi reali. È un’abitudine che ho sviluppato negli anni, intervenire senza contesto in un ambiente enterprise è il modo più veloce per creare danni.

Il primo problema evidente era AWS. Istanze EC2 lasciate running over weekend, bucket S3 con lifecycle policy inesistenti, reserved instances sottoutilizzate. Ho costruito una pipeline con AWS Cost Explorer API e Lambda che ogni mattina alle 7:00 mi mandava un report con le anomalie di spesa:

import boto3
from datetime import datetime, timedelta

def get_cost_anomalies():
    ce = boto3.client('ce', region_name='eu-west-1')
    response = ce.get_cost_and_usage(
        TimePeriod={
            'Start': (datetime.now() - timedelta(days=7)).strftime('%Y-%m-%d'),
            'End': datetime.now().strftime('%Y-%m-%d')
        },
        Granularity='DAILY',
        Metrics=['UnblendedCost'],
        GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
    )
    return response['ResultsByTime']

In tre mesi ho ridotto la spesa AWS del 23% circa 4.200€ al mese recuperati. Non con magia, ma con Savings Plans, rightsizing delle istanze e spegnimento automatico degli ambienti di staging fuori orario lavorativo tramite EventBridge Scheduler.

Per il patch management su Linux (RHEL e Ubuntu, principalmente) ho usato Ansible con un playbook strutturato che girava ogni domenica notte, applicava gli aggiornamenti di sicurezza, verificava i servizi post-patch e rollava indietro automaticamente in caso di failure del health check. Niente di rivoluzionario, ma prima di me veniva fatto a mano, quando veniva fatto.

Il pezzo che mi ha dato più soddisfazione tecnica è stato il backup restore testing. Non basta fare i backup, devi sapere che funzionano. Ho costruito un job notturno che ogni 48 ore ripristinava un backup casuale su un’istanza effimera, eseguiva una suite di test di integrità sul database, e mandava un report. Se il restore falliva, alert immediato su PagerDuty. In sei mesi, ho scoperto tre casi di backup corrotti che altrimenti avremmo scoperto solo durante un disastro reale.

Il Momento in Cui Ho Capito di Avere un Problema

Dopo circa cinque mesi, il mio ticket queue era praticamente vuoto. Le automazioni giravano. I costi erano sotto controllo. I backup funzionavano. Il monitoring rilevava i problemi prima che li segnalassero gli utenti. In teoria, il sogno.

In pratica, ho iniziato a ricevere domande sempre più frequenti dal management “Cosa stai facendo questa settimana?”. Non era cattiveria, era una domanda legittima. Se tutto funziona da solo, qual è il valore di un sysadmin senior che costa X al mese?

Ho visto questa dinamica in altri contesti prima d’ora, ma è diverso quando la vivi sulla tua pelle. Il paradosso è reale, più sei bravo a costruire sistemi resilienti e autonomi, meno sei visibile nel day-to-day. E in molte organizzazioni, la visibilità viene confusa con il valore.

Come Ho Trasformato il Problema in Leva Strategica

La svolta è arrivata quando ho cambiato prospettiva, invece di difendere il tempo libero che avevo creato, ho iniziato a venderlo come capacità strategica reinvestibile.

Ho preparato un documento, in cui mappavo tutto quello che le automazioni mi avevano permesso di NON fare più manualmente, quantificando il tempo recuperato in ore/settimana. Poi ho proposto dove reinvestire quelle ore:

1. Osservabilità avanzata: Il monitoring che avevo costruito era funzionale ma non maturo. Ho proposto di migrare da alert reattivi a un sistema predittivo usando Prometheus con regole di anomaly detection basate su medie mobili. Su Grafana ho costruito dashboard che mostravano trend di 30-90 giorni, non solo lo stato corrente.

2. Security posture: Con Lynis e custom script Bash ho avviato un programma di hardening sistematico su tutti i server, producendo report periodici sul CIS Benchmark score di ogni host:

#!/bin/bash
# CIS hardening score report
lynis audit system --quiet --no-colors | \
  grep -E 'Hardening index|Warning|Suggestion' | \
  tee /var/log/lynis/report-$(date +%Y%m%d).txt

# Invia risultati a Elasticsearch
curl -X POST "http://elk-stack:9200/lynis-reports/_doc" \
  -H 'Content-Type: application/json' \
  -d @/var/log/lynis/report-$(date +%Y%m%d).txt

3. Disaster Recovery documentato e testato: Avevamo backup che funzionavano, ma nessun runbook per uno scenario di ripristino completo. Ho scritto procedure dettagliate e ho organizzato un DR drill trimestrale, esercizio che nessuno aveva mai fatto prima.

Queste proposte hanno cambiato la conversazione con il management. Da “cosa fai tutto il giorno” a “quando possiamo iniziare con il progetto di DR?”.

La Lezione Tecnica e Organizzativa che Porto con Me

C’è una cosa che ho imparato in modo definitivo in questi nove mesi, l’automazione non è il prodotto finale del lavoro di un sysadmin. È il mezzo per liberare banda cognitiva e tempo da reinvestire su problemi di livello superiore.

Il sysadmin che automatizza tutto e poi si siede ad aspettare ha commesso un errore strategico, non tecnico. Le sue automazioni sono eccellenti, il problema è che non ha comunicato il loro valore e non ha proposto la prossima frontiera.

Alcune cose pratiche che ho imparato a fare sistematicamente:

• Documentare il ROI di ogni automazione in termini di ore risparmiate, errori evitati, costi ridotti. Non per vantarmi, ma per avere numeri concreti quando servono.
• Produrre report mensili sullo stato dell’infrastruttura automatizzata, visibili al management. Se le cose vanno bene in silenzio, nessuno lo sa.
• Proporre sempre il prossimo passo prima che qualcuno si chieda cosa sto facendo. Il vuoto di comunicazione viene riempito con supposizioni, quasi mai favorevoli.
• Considerare il knowledge transfer come parte del lavoro, documentare le automazioni in modo che un collega possa gestirle. Questo aumenta il valore percepito, non lo diminuisce.

Cosa Farei Diversamente Fin Dal Primo Giorno

Se tornassi indietro, cambierei una cosa fondamentale, inizierei a costruire visibilità in parallelo all’automazione, non dopo.

Ogni automazione completata dovrebbe essere accompagnata da una comunicazione interna, che spieghi cosa fa, perché lo fa, e quale problema risolve. Non per fare il fenomeno, ma per costruire un audit trail del valore prodotto.

Avrei anche strutturato prima un sistema di metriche di infrastruttura presentabile al business, uptime, MTTR, costo per workload, numero di incidenti evitati. Numeri che trasformano il lavoro tecnico in linguaggio comprensibile a chi decide i budget.

L’automazione è una delle competenze più preziose che un sysadmin può avere oggi. Ma è uno strumento, non un obiettivo. Chi la padroneggia davvero sa che liberare tempo è solo il primo step, la domanda vera è cosa costruisci con quel tempo?

Se stai attraversando una situazione simile, o se hai trovato modi efficaci per comunicare il valore dell’automazione al management, mi interessa confrontarmi. Lascia un commento o scrivimi direttamente.