Formazione scritta DevOps

Come proteggere la pipeline di deployment DevOps?

Una volta realizzata con il team DevOps una pipeline di deployment funzionante per il rilascio continuo dell'organizzazione IT, applicando i principi già visti, puoi eseguire deployment in produzione a basso rischio senza approvazioni esterne. La maggior parte dei deployment in produzione non richiede più un processo di approvazione delle modifiche. Ti affidi alla buona progettazione della metodologia di rilascio del software, ai test e al monitoraggio automatizzati e agli avvisi intelligenti degli ambienti, senza dipendere soltanto da autorità esterne. Ricorda comunque che sicurezza e conformità restano compiti importanti del team DevOps, sia per rispettare i requisiti di legge sia per tutelare i clienti. Il team continuerà a collaborare con gli specialisti interni di sicurezza e conformità e ad avvalersi delle loro competenze. Progettare sistemi sicuri e conformi al quadro normativo in cui opera l'organizzazione deve diventare un'abitudine quotidiana.

Tipi di modifiche nei sistemi di produzione

• Modifiche standard: Modifiche a basso rischio che non richiedono approvazione e si distribuiscono rapidamente perché sono completamente automatizzate e registrate. Sono modifiche standard, ad esempio, gli aggiornamenti di tabelle di riferimento del database, gli aggiornamenti dei contenuti, le modifiche di stile e le patch standard di sistemi operativi, database o altri componenti esterni.
• Modifiche normali: Modifiche ad alto rischio che richiedono l'approvazione del Change Advisory Board (CAB). Il CAB richiede un modulo di richiesta di modifica (RFC) per valutarle. I lead time sono lunghi, perché spesso i membri del CAB non conoscono abbastanza il lavoro per valutarlo. Sospendono le modifiche e decidono infine in base a esperienza, intuito e pregiudizi su chi le ha richieste.
• Modifiche urgenti: Modifiche ad alto rischio che richiedono l'approvazione dell'alta direzione. Tra gli esempi ci sono gli errori critici nei sistemi di produzione che incidono sui clienti, le correzioni di deployment problematici, le patch di sicurezza e i ripristini di servizio.

A prescindere dal tipo, tu e il team DevOps dovete documentare tutte le modifiche nei sistemi di gestione delle modifiche e pianificazione del lavoro, come Remedy e Jira, così il lavoro sarà visibile a tutti, dentro e fuori dal team.

Usa lo storico dei deployment automatizzati riusciti per trasformare le modifiche normali in standard

Solo aumentando la proporzione di modifiche standard rispetto a quelle normali puoi evitare le approvazioni del Change Advisory Board (CAB) e ottenere un flusso più rapido e una pipeline di deployment di qualità superiore.

Tu e il team DevOps usate lo storico dei deployment automatizzati riusciti per convertire il maggior numero possibile di modifiche normali in standard. Mostrate al CAB lo storico dei deployment e l'elenco degli incidenti in produzione, dimostrando che i deployment automatizzati in produzione non causano incidenti o ne causano soltanto di trascurabili.

Accelera il deployment delle modifiche normali

Per le modifiche che devono rimanere normali, automatizza la compilazione del modulo di richiesta di modifica (RFC). Collega al modulo i risultati dei test automatizzati e manuali, gli incidenti risolti e non risolti, i dati di monitoraggio e i log dei sistemi non di produzione. Facilita il lavoro del CAB fornendo già nella prima versione tutte le informazioni che cerca, in modo da accelerare il più possibile le approvazioni.

Dopo l'approvazione, rendi possibile il deployment delle modifiche normali con un solo clic. Esamina regolarmente con il CAB i tipi di modifiche normali e concorda le condizioni per convertirle in standard, così potrai distribuire automaticamente la maggior parte delle modifiche dell'organizzazione DevOps.

Riduci la burocrazia e la dipendenza da altri nell'organizzazione DevOps

Più un'organizzazione cresce, più la burocrazia trova modo di alimentarsi. Ha la capacità invisibile di crescere esponenzialmente e durare all'infinito. Se affidi l'approvazione del tuo lavoro ad autorità e controlli di livello superiore, smetterai di sentirti autonomo e responsabile dei risultati. Questo farà fallire regolarmente l'autorità sopra di te.

Alla fine anche questa autorità avrà bisogno di un'altra a cui affidarsi e da cui farsi controllare. La spirale negativa si prolunga fino alla prossima riorganizzazione. Dopo la riorganizzazione è quasi certo, con una probabilità vicina al 100%, che una nuova spirale leggermente diversa sostituisca quella in corso.

L'azienda deve ricordare che separare le mansioni e affidare controlli e responsabilità a persone esterne al team rallenta il rilascio, ne riduce la qualità e rende l'organizzazione meno sicura. Una grande società finanziaria statunitense ha subito una frode ai bancomat a causa di una backdoor inserita da uno sviluppatore nel software. Revisori, specialisti di sicurezza, responsabili della conformità e autorità del CAB esterni non sono riusciti a individuare il codice fraudolento distribuito in produzione. Solo all'interno del team che lo aveva sviluppato si sarebbe potuto rilevarlo con tecniche DevOps fondamentali, come l'ispezione dei check-in e le revisioni del codice.

Per rilasciare rapidamente e in sicurezza, devi ridurre la dipendenza da altri e la separazione delle mansioni, che impedirebbero al team DevOps di assumersi responsabilità. Adotta nel team altri controlli, come ispezione dei check-in, programmazione in coppia, revisione tra pari, test automatizzati e monitoraggio. Se la legge impone la separazione delle mansioni, i controlli interni permetteranno comunque a revisori e responsabili della conformità di prendere decisioni migliori, informate e più rapide.

CONCLUSIONE

DevOps introduce una dimensione nuova e dinamica per la conformità e la sicurezza delle informazioni. Quando l'infrastruttura è codice, il codice crea e rimuove i sistemi e viene distribuito automaticamente, per i revisori è difficile capire cosa stia succedendo. È una nuova sfida e anche un'occasione per adottare meccanismi e ruoli di audit e conformità più snelli e intelligenti.

Nel team DevOps tutti si occupano di sicurezza delle informazioni, conformità e velocità della pipeline. Uno degli obiettivi principali del team è dare ai responsabili della conformità accesso self-service a informazioni, log, report e metriche che dimostrino l'alta qualità dei rilasci. Questo semplifica i processi burocratici di approvazione o, meglio ancora, li elimina del tutto.