Come Microsoft gestisce sistemi affidabili con DevOps

Microsoft ha operato piattaforme online complesse fin dai primi giorni della internet commerciale. Lungo la strada, abbiamo evoluto un set sostanziale di procedure per mantenere i sistemi disponibili, sani e sicuri. Queste procedure fanno parte di un'iniziativa più ampia per mantenere e migliorare una cultura del sito live.

Impostazioni cultura del sito live

Le impostazioni cultura dei siti live sono l'obiettivo di un'organizzazione di assegnare priorità all'esperienza e all'affidabilità del sito live su tutto il resto. Dopo tutto, i clienti possono spostarsi tra provider di servizi abbastanza facilmente al giorno d'oggi con i servizi cloud e basati su Internet, amplificando notevolmente l'importanza della fiducia dei clienti. Il sito live deve essere sempre disponibile ed eseguire come promesso ai clienti.

Esistono vari fattori che contribuiscono a una cultura del sito live di successo.

Sito live per primo

Mettere prima di tutto l'esperienza del sito live è parte integrante di una piattaforma di successo. I team non possono concentrare l'attenzione sulle nuove funzionalità lucide e ignorare il modo in cui tali funzionalità vengono presentate agli utenti. Ci si basa su procedure di distribuzione sicure che consentono ai clienti di usufruire dell'accesso ininterrotto alla piattaforma. Questo può diventare particolarmente complicato quando si tratta di rilasciare gli aggiornamenti del servizio con controllo delle versioni senza tempi di inattività.

Controllare l'esposizione tramite flag di funzionalità

Durante la distribuzione attraverso gli anelli e le fasi, controllando l'esposizione con i flag di funzionalità, si scopre occasionalmente un problema nell'ambiente di produzione. Nonostante tutte le nostre revisioni e automazione, a volte le cose si verificano ancora. Come dicono, non c'è posto come produzione!

In genere, il monitoraggio dell'integrità e i dati di telemetria avvisano quando qualcosa non è corretto. Uno sviluppatore può creare un ramo off main, apportare una correzione ed eseguirne il pull in main. Mantenere lo stesso flusso di lavoro generale significa che gli sviluppatori non devono cambiare contesto o apprendere un processo diverso per una modifica del codice diversa.

Per risolvere una distribuzione di hotfix, è necessario un altro passaggio, che consiste nel selezionare la modifica nel ramo di rilascio. Viene eseguita una distribuzione di hotfix dal ramo di rilascio corrente ogni mattina del giorno feriale, anche se è possibile eseguire questa operazione su richiesta per correzioni urgenti. La correzione raggiunge effettivamente la produzione dal ramo di rilascio per prima. Tuttavia, poiché si sviluppa in main primo luogo, si sa che non regredisce lo sprint successivo quando viene creato un nuovo ramo di versione da main.

Le versioni dei prodotti locali sono in gran parte le stesse, anche se senza gli anelli di distribuzione e le fasi. Inoltre, poiché si eseguono più test manuali su configurazioni e forme di dati diverse, c'è una coda più lunga tra il taglio del ramo di rilascio e l'inserimento del prodotto nelle mani dei clienti.

La sicurezza deve essere presa personalmente

L'obiettivo è quello di rendere reali e personali le vulnerabilità. Ciò garantisce che le persone si preoccupino davvero. Facciamo anche un ampio uso di giochi di guerra per trovare e affrontare i rischi di sicurezza in tutto il sistema, sia nel codice che nel codice. Quando il team rosso può mostrare che sono stati inseriti nel codice trasformando una finestra di dialogo rovesciato, motiva il proprietario del codice a risolvere il problema e assicurarsi che non si verifichi di nuovo altrove. Questo tipo di concorrenza è molto più reale e personale di un avviso di analisi statica su un potenziale rischio XSS. Creiamo questo tipo di cultura e dinamica attraverso giochi di guerra e altri esercizi di sicurezza. Persone essere orgogliosi dell'hacking nel codice dell'altro o di essere in grado di bloccare i tentativi. Questo infonde una cultura del codice sicura.

Non possiamo pianificare ogni vettore di attacco, ma ciò che possiamo fare è presupporre che ci sarà una violazione e pianificare quanto velocemente possiamo reagire a tale violazione. Un sacco di lavoro sulla sicurezza è stato intorno a questo per i nostri team.

Infine, gli esseri umani commettono errori. A volte ottengono pigri e fanno cose come archiviare le password nelle condivisioni file. Possiamo dirgli di non e possiamo inviarli alla formazione sulla sicurezza e possiamo fare tutti i tipi di altre cose. La maggior parte delle persone impara, ma ci vuole solo una persona per rompere il sistema. È possibile avere tutti i tipi di elenchi di procedure consigliate, ma a meno che non si stia rendendo reale, è necessario presupporre che le persone commettono errori. Ciò richiede un certo livello di supervisione per garantire che vengano seguiti processi critici.

La progettazione è più di un partner di operazioni

Abbiamo imparato presto a rendere il sito live una parte importante delle responsabilità del team di progettazione. Questo è stato enorme per noi perché, in passato, una persona poteva distribuire qualcosa, lasciare per il fine settimana e tornare lunedì per trovare 900 problemi dei clienti che i team di assistenza clienti e operazioni stavano gestendo tutto il fine settimana. È importante che la progettazione paghi il prezzo per i problemi del sito live. In caso contrario, non c'è alcun incentivo a creare sistemi che evitino tali problemi. Quando ti chiami alle 2 del 2 per risolvere qualcosa che hai rotto, ti ricordi.

Man mano che abbiamo evoluto questa responsabilità, live site è la cosa più importante che facciamo è diventato il motto di tutto il team. È l'esperienza del cliente che hanno in questo momento e non è solo una tassa. È in realtà qualcosa che le persone contano su di noi e ci facciamo orgoglio. Deve essere una caratteristica distintiva del nostro prodotto.

La telemetria di produzione è l'heartbeat del servizio

Per sopravvivere nel mondo veloce dove praticamente qualsiasi cosa può andare storta, abbiamo bisogno di grandi sistemi di avviso. Gli avvisi non consentiti, gli avvisi ridondanti o i volumi di avviso sovraccarico consentono di ignorare tutti gli avvisi. È facile creare troppi avvisi, quindi il processo si distillizza davvero fino a una semplice domanda: questo avviso è utilizzabile? In questo modo, microsoft si impegna sui problemi corretti dei clienti e li gestisce il più rapidamente possibile.

Man mano che il team di progettazione si è azzerato sugli avvisi interattivi, hanno notato che molti problemi che si presentano, soprattutto durante la notte, tendono ad avere correzioni simili, almeno temporaneamente. Questo ha portato a un focus sui sistemi che erano meglio al failover e alla riparazione automatica. Ora i problemi si verificano, generano avvisi e quindi si risollevano abbastanza bene per il team di progettazione di attendere fino al mattino per risolvere il problema. Questo non sarebbe successo se il team di ingegneria ha appena spinto fuori bit che ha mantenuto altre persone di notte. Ora lavorano per bilanciare questi miglioramenti come parte non solo della velocità delle caratteristiche, ma anche della velocità di miglioramento dell'ingegneria.

Riepilogo

L'adozione di una cultura del sito live ha influenzato il modo in cui Microsoft compila e distribuisce software. Rendendo i team di progettazione una parte fondamentale della sicurezza e delle operazioni, la qualità del codice e dell'esperienza degli utenti finali è migliorata drasticamente. Essere un partecipante completo delle operazioni ha reso l'ingegneria uno stakeholder chiave, ottenendo sistemi progettati per operazioni migliori.