IT knowledge base
CTRL+F per cercare la tua parola chiave

Dalla funzione alla cultura: come si è evoluto DevOps in una grande azienda

Abbiamo già parlato su Habré dei prodotti digitali delle e-mail registrate per Posta, spedizione commerciale , e-stampe . Chi usa Mail potrebbe aver notato che abbiamo iniziato a rilasciare sempre più applicazioni e servizi e abbiamo imparato a farlo prontamente. Ora il time to market per i nuovi prodotti in Mail è di soli 3 mesi e le versioni vengono rilasciate ogni settimana.

Abbiamo deciso di guardare indietro e ricordare come una grande azienda ha implementato le pratiche DevOps per rispondere rapidamente alle nuove richieste.

Fai l'applicazione un anno e torna indietro

Partiamo dal fatto che, storicamente, il business della posta è offline. I prodotti digitali hanno iniziato ad apparire nel nostro paese relativamente di recente. Pertanto, lo sviluppo dei primi progetti per la Posta è stato completamente affidato a terzisti esterni. Ciò ha causato difficoltà: il lavoro è stato svolto secondo la metodologia a cascata e ha richiesto molto tempo, il tempo di sviluppo del prodotto potrebbe richiedere un anno o più. E quando è successo che l'appaltatore è cambiato prima dell'avvio del progetto, allora ci siamo trovati, se non all'inizio, nel mezzo del percorso, e l'azienda non aveva più esperienza e competenza.

Per accelerare, nel Post è stato creato il Dipartimento per lo sviluppo tecnologico, che avrebbe dovuto aiutare a sistematizzare e migliorare il lavoro sui prodotti digitali e sviluppare le proprie competenze. Quindi è iniziato il processo di nascita di DevOps in Mail: sono stati acquistati i primi strumenti centralizzati che hanno permesso di costruire e controllare processi, implementare pratiche DevOps. Ad esempio, l'utilizzo di GitLab ci ha aiutato a gestire il codice e le sue modifiche, e ora vediamo cosa succede ogni giorno. TeamCity ha reso possibile creare e testare i prodotti automaticamente. Non appena le modifiche apparivano in GitLab, TeamCity le aggiungeva e le eseguiva attraverso il sistema. E Maven ha reso possibile vedere lo stesso standard di costruzione in tutti i prodotti in modo da non avere a che fare con un mucchio di sistemi diversi. Nel diagramma sottostante, puoi vedere un elenco più completo di strumenti che abbiamo selezionato e implementato per automatizzare gli standard che sono apparsi allora in azienda.

Ecco come si presentava il processo che abbiamo creato per il lancio di nuovi prodotti in Mail

Grazie alle innovazioni, siamo stati in grado di mettere ordine nel processo di sviluppo e ridurre i tempi di rilascio di 4 volte. Se prima gli sviluppatori esterni mostravano solo il risultato finale al momento stabilito, ora hanno regolarmente dimostrato e concordato i risultati intermedi. I partner hanno iniziato a lavorare sui nostri strumenti e sul nostro processo.

E su questo schema piuttosto classico, è stato possibile lavorare a lungo, alcune aziende generalmente vivono con esso fino ad oggi e si sentono benissimo. Ma il mercato della logistica sta crescendo rapidamente e, per stare al passo con la domanda, la Posta ha deciso di creare un proprio team, che avrebbe dovuto accelerare la digitalizzazione. Così nel 2018 è apparso un ramo speciale in Post - Postal Technologies, che ora è diventato un'entità legale separata. Pochtatech ha dovuto affrontare il compito di accelerare lo sviluppo, ridurre il time to market, acquisire e mantenere competenze all'interno dell'azienda.

L'origine della cultura dall'interno

Se prima potevamo impiegare un anno o più da un'idea al lancio di un prodotto, ora il nostro obiettivo era quello di impiegare non più di 3 mesi per creare un MVP con cui poter entrare nel mercato. Per passare al nostro sviluppo e iniziare ad accumulare competenze a tutti gli effetti, abbiamo iniziato a mettere insieme il nostro team di sviluppo. Con l'arrivo di nuove persone, cominciarono ad apparire nuove idee e approcci. I team stessi hanno iniziato a implementare nuovi strumenti per ridurre i tempi di sviluppo e gradualmente hanno iniziato a condividere i loro risultati con gli altri, raccontando come hanno accelerato, come si sono liberati dell'attesa per le code di costruzione e così via.

Grazie all'implementazione dei processi DevOps, abbiamo ben accelerato il processo di rilascio del prodotto dall'idea al primo utente (MVP):

2017

2018

2019

365 giorni

180 giorni

> 90 giorni

Come abbiamo accelerato? Hanno appena dato agli sviluppatori l'opportunità di non essere distratti dal loro lavoro principale. Quando il codice è pronto, viene automaticamente assemblato, testato e viene presa una decisione sulla consegna alla produzione. Sebbene l'ultima fase in alcuni prodotti funzioni anche automaticamente.

Abbiamo iniziato a utilizzare un approccio al prodotto: ora in Pochtatech, ogni team è responsabile del proprio prodotto dentro e fuori. Il progetto ha il proprio team di sviluppo, ingegneri DevOps dedicati e alcuni progetti hanno il proprio supporto. Il processo è costruito in modo tale che il team di sviluppo sia lo stesso del team di supporto, che sa non solo come è scritto il codice, ma anche come viene assemblato, testato, consegnato agli ambienti, funziona in produzione, lo stesso team fornisce SLA del prodotto.

I prodotti creati utilizzando DevOps continuano a prosperare dopo il lancio, anche se devi trasferire specialisti tra progetti o cambiare completamente il team. Il controllo competente della versione e la gestione dello stand consentono di mantenere e mantenere le competenze all'interno dell'azienda e garantire una crescita affidabile e stabile, limitando al contempo la quantità di lavoro manuale.

Case study: come DevOps ha accelerato la consegna dei server

Il compito principale dello specialista DevOps di Mail è trovare soluzioni tecniche alle sfide e ai problemi esistenti dal lato operativo e di sviluppo. Ad esempio, l'anno scorso ci siamo resi conto che, grazie all'utilizzo della piattaforma di virtualizzazione, dedichiamo molto tempo all'ordinazione di nuove capacità di server. Per ottenere un server, è necessario attendere da un giorno a una settimana e, dopo averlo ricevuto, concedere il tempo per un controllo funzionale. Di conseguenza, sono trascorse 2-3 settimane dal momento della richiesta fino alla messa in funzione del server.

Quindi abbiamo deciso di sviluppare in due direzioni: distribuire la nostra piattaforma cloud e utilizzare Kubernetes. Ora tutto funziona così: abbiamo ordinato dieci macchine abbastanza potenti e su di esse creiamo gli ambienti di cui abbiamo bisogno. Il servizio cessa di essere legato a un server specifico: Kubernetes gestisce tutto.

Dopo l'introduzione di Kubernetes su alcuni prodotti, il processo ha iniziato a funzionare molto più velocemente. Ora, quando un'azienda ha una nuova attività, dopo la discussione viene aggiunta al bug tracker, viene creato un ramo in GitLab (dove verrà eseguito lo sviluppo per l'attività) e immediatamente appare un ambiente in Kubernetes in cui le modifiche solo per questo compito sono memorizzati. Qui verranno testati separatamente dal resto e non interferiranno con nessuno, i report verranno generati immediatamente. Quando un'attività viene chiusa, viene unita al ramo di integrazione principale, dove vengono eseguiti i test.

All'inizio della storia, abbiamo mostrato come appariva la struttura dell'interazione con lo sviluppo di terze parti. Passiamo ora ai processi e agli strumenti rappresentati in questo diagramma:

Con l'evoluzione di DevOps, molti dei nostri strumenti sono passati agli standard di posta. È così che Confluence e GitLab sono diventati un luogo comune in tutta l'azienda. Insieme a GitLab, è stato aggiunto il supporto CI di GitLab e ora tutti i nostri nuovi prodotti lo utilizzano.

Inoltre, grazie all'introduzione di nuovi prodotti e pratiche, noi:

  • Abbiamo costruito un sistema di gestione della configurazione.
  • Abbiamo costruito un sistema di integrazione continua: assemblaggio e distribuzione.
  • Abbiamo definito i nostri approcci su come i prodotti dovrebbero entrare in tutti gli ambienti: sviluppo, test, fase, produzione.
  • Abbiamo implementato sistemi di registrazione e un sistema di controllo della qualità del codice
  • Aggiunti sistemi per lavorare con documentazione, bug, casi di test.
  • Inizia la promozione di Infrastructure as Code (IaC).

DevOps si è infiltrato nell'azienda dalla pratica quotidiana, senza una richiesta dal "top". Questa generazione caotica dall'interno non è andata bene. Tutti coloro che hanno implementato i propri strumenti e approcci lo hanno fatto a modo loro. Una persona potrebbe stabilire un qualche tipo di processo e, dopo che se ne è andato, nessuno sapeva cosa e come avrebbe dovuto funzionare. Occorre ora affrontare le conseguenze di un'attuazione non sistemica. Al fine di ridurre tutti i processi a un unico approccio, nel 2020 è stata costituita una community DevOps presso Mail. L'obiettivo della comunità è far sì che la cultura si sviluppi in modo sistemico. Per fare ciò, abbiamo iniziato a costruire una struttura e ad assumere persone specifiche per le attività DevOps. Cioè, la cosa più interessante sta accadendo proprio ora: gli approcci e gli standard principali sono in fase di costruzione.

Alla cultura attraverso i ruoli

Finora, DevOps in Mail è più un ruolo in cui vengono posti determinati compiti: manutenzione e automazione dei rilasci, automazione dell'impostazione del monitoraggio e dell'analisi dei log, partecipazione al miglioramento del prodotto per un'architettura di microservizi, proposte per portare il prodotto a uno stato pronto per il cloud/nativo. La parola "ruolo" in relazione a DevOps può sembrare strana e strana, ma il modo in cui un'azienda si sviluppa impone un atteggiamento non standard all'approccio.

Comprendiamo che DevOps non è responsabilità di una persona, ma dell'intero team, quindi ora il nostro obiettivo principale è fare in modo che DevOps diventi una cultura all'interno dell'azienda. In modo che chiunque partecipi alla creazione di un prodotto si renda conto che deve inserirsi pienamente nei processi DevOps e quindi essere adattato per l'automazione.

Ora i nostri DevOps hanno la capacità di essere direttamente responsabili del prodotto, e per questo abbiamo un intero set di strumenti: sistemi per la raccolta dei log, la raccolta delle metriche, il monitoraggio, la costruzione, la gestione automatica della configurazione e il controllo della versione. DevOps può risolvere qualsiasi problema sia lato server che lato codice. Il codice non è molto lontano dall'accesso per tre richieste. Se hai bisogno di log o metriche, sono aperti a tutti i progetti. Quando non ci sono abbastanza dati, puoi implementare un sistema aggiuntivo per ottenerli. L'obiettivo principale è che il prodotto funzioni, la qualità cresce e lo sviluppo va più veloce. Liberati dalla routine, gli specialisti DevOps sono impegnati in uno dei compiti più interessanti: garantire il funzionamento stabile del prodotto sotto carico elevato e rilasci frequenti.