Cloud, rilasci e operatività: esperienza sul campo in Azure e AWS.

Piattaforme con accesso alla produzione limitato

In contesti con forti vincoli di sicurezza, la produzione è gestita da un team dedicato.

Quando non posso accedere direttamente all'ambiente o ai database di produzione, log e strumenti di monitoraggio diventano essenziali per riconoscere le anomalie e ricostruirne le cause. Questo richiede attenzione alla qualità del logging e alla tracciabilità dei problemi già durante lo sviluppo.

Quando c'è un'anomalia in produzione

In un sistema con accesso limitato molte strade sono chiuse: non si può entrare nel database, né correggere al volo, né aggiungere una riga di log per capire meglio. Per questo parto dall'intero percorso della richiesta e uso il monitoraggio dei singoli componenti per capire se il problema è nel codice oppure in un componente sovraccarico, che va ridimensionato. Nei sistemi complessi questi casi anomali spesso non sono previsti dai requisiti, e gli altri componenti possono interpretare in modo fuorviante le risposte che ricevono.

Una volta circoscritta l'area, analizzo il componente. Solo i componenti software permettono di adattare il logging, e spesso non è necessario. Se il problema è nel programma, i log devono bastare: verifico che contengano le informazioni necessarie e che la loro struttura permetta di seguire il flusso che ha portato all'errore, perché un singolo evento in mezzo a centinaia di altri non lo mostra. Dove non bastano, il miglioramento va pianificato in anticipo: in questi ambienti non si rilascia una correzione sul momento.

In alcuni progetti ho contribuito a preparare configurazioni con Terraform, così che le modifiche all'infrastruttura fossero versionate, verificabili e coordinate con il processo di rilascio.

Gestione diretta di ambienti e rilasci

In altri progetti seguo più da vicino l'operatività, dallo sviluppo fino alla produzione.

Ho lavorato alla configurazione di pipeline di rilascio, anche quando l'aggiornamento coinvolge servizi diversi come applicazioni, CRM e Service Bus. Ho seguito ambienti di sviluppo, test, staging e produzione, occupandomi del monitoraggio dei servizi e dell'analisi delle anomalie.

Le integrazioni e i flussi di dati hanno coinvolto, secondo il progetto, Azure Functions, Service Bus e Stream Analytics, insieme a componenti di rete come Azure Firewall e Application Gateway. Ho utilizzato anche Entra ID per l'identità e Azure Synapse nell'ambito dei dati.

Un rilascio su più sistemi

Un rilascio distribuito su più sistemi richiede una pianificazione attenta. Spesso comporta un fermo programmato del servizio, e l'aggiornamento di applicazioni e database va coordinato con il passaggio in produzione dei sistemi di altri team. Serve una procedura scritta e mantenuta nel tempo, che copra il flusso normale e gli scenari di risoluzione dei problemi. Non è una procedura fissa: non sempre si aggiornano tutti i sistemi, a volte cambiano solo alcuni microservizi.

Il tipo di aggiornamento determina altri due aspetti.

Il ripristino. I problemi inattesi possono capitare comunque. Nei rilasci più semplici si può tornare alla versione precedente, usando i pacchetti già rilasciati dei moduli (artifact), e analizzare con calma. Quando la scadenza non è rinviabile o il rilascio è troppo complesso per tornare indietro, il problema va risolto sul momento, anche a costo di un fermo più lungo.

Le persone. In quel caso tutte le persone utili alla soluzione, del proprio team e degli altri, per i servizi e per l'infrastruttura, devono essere disponibili al momento del passaggio in produzione, per affrontare insieme il problema (la cosiddetta war room). Anche questa disponibilità va pianificata.