Recentemente sono stata al DevOpsForum 2019, organizzato da Logrocon. In questa conferenza i partecipanti hanno cercato soluzioni e nuovi strumenti per un'interazione efficace tra il business e gli specialisti in sviluppo e assistenza informatica.
La conferenza è stata un successo: ci sono stati davvero molti interventi utili, formati di presentazione interessanti e tantissime opportunità di dialogo con i relatori. E soprattutto è importante che nessuno ha cercato di vendermi nulla, cosa che ultimamente succede spesso con i relatori alle grandi conferenze.
Raccolta degli interventi di Raiffeisen Bank, AlfaStrakhovanie, l'esperienza di Mango Telecom nell'implementazione della automazione e altri dettagli a seguire.
Mi chiamo Yana, lavoro come tester, mi occupo di automazione, oltre a DevOps e adoro partecipare a conferenze e meetup. Negli ultimi due anni sono stata a conferenze di Oleg Bunin (HighLoad++, TeamLead Conf), a eventi Jug (Heisenbug, JPoint), a TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
La prima cosa che noto è il programma della conferenza. In misura minore guardo di cosa tratterà l'intervento, in maggiore misura — chi è il relatore. Anche se l'intervento risulta molto tecnico e interessante, non è detto che tu possa applicare delle best practices dal discorso nella tua azienda. E allora hai bisogno di un relatore.
La luce in fondo al pipeline in Raiffeisen Bank
Di solito, organizzo una caccia ai relatori interessanti nei corridoi. Al DevOpsForum 2019 è emerso nel mio campo d'interesse un relatore di Raiffeisen Bank — Mikhail Bizhan. Durante il suo intervento ha raccontato come le loro squadre si avvicinano progressivamente al DevOps, perché ne hanno bisogno e come vendere l'idea della trasformazione DevOps al business. In generale, ha parlato di come vedere la luce in fondo al pipeline.
Mikhail Bizhan, direttore dell'automazione in Raiffeisen Bank
Attualmente, nella loro azienda non c'è un «vero DevOps». Vale a dire che è vero, ma non in tutte le squadre. Nell'implementazione del DevOps, si basano sulla prontezza delle squadre sia dal punto di vista dei singoli ingegneri, sia in termini di necessità del prodotto e maturità della piattaforma su cui è costruito il prodotto. Misha ha spiegato come far capire al business perché il DevOps sia necessario.
Il segmento bancario ha diversi fattori di crescita: il costo dei servizi e l'espansione della clientela. Aumentare il costo dei servizi non è un buon fattore, mentre la crescita della clientela lo è. Se i concorrenti lanciano un prodotto oggettivamente eccezionale, tutti i clienti si spostano lì, poi nel tempo il mercato si stabilizza. Pertanto, l'immissione sul mercato di nuovi prodotti e la velocità di tale immissione sono le principali cose su cui le banche si concentrano. Ecco perché è necessario il DevOps, e il business lo comprende.
Un'altra osservazione importante: il DevOps non riduce sempre il time to market. Il DevOps non può funzionare da solo, è solo una parte del processo di creazione e immissione di un prodotto sul mercato, dalla sviluppo alla produzione (dal codice al cliente). Ma tutto ciò che precede il codice non ha relazione diretta con il DevOps. In altre parole, i marketer possono studiare il mercato per anni e passare la vita a recuperare i concorrenti. È necessario comprendere rapidamente di cosa ha bisogno il cliente e pianificare l'implementazione di una funzione o di un'altra: spesso è proprio questo che manca affinché il DevOps funzioni e l'azienda raggiunga i suoi obiettivi. Pertanto, in primo luogo, alla Raiffeisenbank hanno concordato con il business che era necessario imparare a utilizzare il DevOps. L'automazione per il semplice gusto di automatizzare non aiuterà molto nella conquista di nuovi clienti.
In generale, Misha ritiene che il DevOps debba essere implementato, ma con saggezza. Bisogna essere pronti al fatto che all'inizio della trasformazione la produttività del team potrebbe diminuire, guadagneranno meno soldi, ma poi tutto ciò sarà giustificato.
L'automazione dei test in "Mango Telecom"
Un'altra presentazione interessante per me come tester è stata fatta da Eghor Maslov di «Mango Telecom». La presentazione si intitolava «Automazione del ciclo completo di testing nel team SCRUM». Eghor ritiene che DevOps sia stato creato proprio per SCRUM, ma allo stesso tempo è abbastanza problematico implementare DevOps nel team SCRUM. Questo accade perché il team SCRUM è sempre molto occupato e non ha tempo da dedicare a novità e ristrutturazioni del processo. Il problema risiede anche nel fatto che SCRUM non prevede l'assegnazione di sub-team (team di tester, team di sviluppatori, ecc.). Inoltre, per automatizzare i processi esistenti è necessaria la documentazione, e in SCRUM la documentazione è frequentemente assente: «il prodotto è più importante di qualche scartoffia».
Dopo la transizione a SCRUM, i tester hanno iniziato a consultarsi con gli sviluppatori su come testare le funzionalità. Gradualmente, il volume delle funzionalità è aumentato, la documentazione era assente e hanno iniziato a scoprire molti bug in quelle funzionalità prive di copertura testuale, e non era chiaro chi e quando le avesse testate. In poche parole, c'era caos. Hanno deciso di passare all'automazione del testing. Ma anche allora è avvenuto un completo fallimento. Hanno coinvolto specialisti esterni per l'automazione, che programmavano in un stack sconosciuto ai tester interni. Il framework per i test automatici funzionava, ma dopo che gli esterni se ne sono andati, ha funzionato solo per due settimane. Successivamente, c'è stata un'altra tentativo di implementare l'autotesting. È iniziato con l'idea che tutto dovesse essere costruito internamente, con le proprie forze (direzione corretta: incrementare l'expertise interna), nell'ambito di SCRUM, e nel processo creare documentazione. Lo stack per l'automazione deve essere identico a quello del prodotto (qui sono decisamente d'accordo, non testate un progetto in JavaScript con altro). Alla fine dello sprint, organizzavano una demo di come funziona il test automatico, con l'intera squadra partecipe (utile). In questo modo, aumentava il coinvolgimento di tutti i membri del team nel processo di automazione, il loro livello di fiducia nei test automatici e la possibilità che i test venissero effettivamente utilizzati (e non venissero commentati dopo un mese a causa di continui fallimenti).
A proposito, al DevOpsForum 2019 c'era un microfono aperto — un formato di presentazione noto da tempo e, a mio avviso, utile. Cammini, ascolti le relazioni e poi decidi che durante la conferenza vale la pena discutere un certo argomento o problema, condividere esperienze pertinenti nella risoluzione di un compito.
Ho anche notato che gli organizzatori hanno creato un flusso di brevi presentazioni. Ogni relazione dura non più di 10 minuti, seguita da domande. In questo modo, si possono coprire molti argomenti e porre domande agli oratori che ci hanno interessato.
Tra una presentazione e l'altra, ho fatto un giro tra gli stand dei partner della conferenza e ho raccolto/vinto molte cose diverse. Ah, quanto amo il materiale promozionale!
Tavola rotonda e domande sul DevOps con il direttore dello sviluppo di AlfaStrakhovanie
La ciliegina sulla torta del DevOpsForum 2019 per me è stata la sessione plenaria di un'ora con esperti DevOps. Sono stati invitati quattro partecipanti alla sessione, che dovevano osservare il DevOps da diversi punti di vista: Anton Isanin (AlfaStrakhovanie, direttore dello sviluppo), Nailya Zamashkina (Fintech Lab, direttore operativo), Oleg Egorkin (Rostelecom, Agile coach) e Anton Martyanov (esperto indipendente, che ha esaminato il DevOps dal punto di vista del business).
Gli esperti si sono sistemati vicino al pubblico e così è iniziato: per un'ora i partecipanti dal pubblico hanno posto le loro domande, e gli esperti hanno risposto. A volte si sono svolti veri e propri dibattiti. Le domande erano le più varie, ad esempio: servono veramente gli ingegneri DevOps, perché non si possono formare a partire dagli amministratori di sistema, bisogna proporre il DevOps a tutti, qual è il suo valore e così via.
Dopo, ho parlato personalmente con Anton Isanin. Abbiamo discusso della necessità di portare la cultura DevOps in ogni casa e abbiamo rivelato il lato oscuro della trasformazione DevOps.
Immagina che tutti si siano riuniti e abbiano deciso che il DevOps è necessario sia per il prodotto che per il business e il team. Si sono messi subito all'opera. Tutto è andato bene. Respiriamo. Il DevOps ci ha avvicinato al cliente, ora possiamo soddisfare rapidamente tutte le sue richieste. Alla fine abbiamo una grande divisione Ops con regolamenti rigorosi e requisiti, e continua a segnalare difetti nel prodotto, creando un sacco di richieste. Inoltre, tutti i difetti arrivano con lo stato "urgente", anche se il cliente ha improvvisamente deciso di colorare un pulsante di giallo invece che di verde. Il progetto cresce, cresce il numero di rilascio e, di conseguenza, il numero di difetti e le incomprensioni da parte dei clienti sulle nuove funzionalità. Ops assume altre 10 persone per poter segnalare i difetti, mentre lo sviluppo assume 15 in più per poterli risolvere. E invece di implementare nuove funzionalità, il team deve affrontare infinite SD, spiegando le funzionalità all'utente e anche al supporto. Alla fine, sia Ops che lo sviluppo sono occupati, ma il cliente e il business non sono soddisfatti: nuove funzionalità rimangono bloccate. Risultato, sembra che il DevOps ci sia, ma in realtà non c'è.
Riguardo alla necessità di implementare il DevOps, Anton ha dichiarato chiaramente che ciò dipende direttamente dalle dimensioni del business. Se la gestione di un solo cliente all'anno porta all'azienda un miliardo, il DevOps non è necessario (supponendo che non sia necessario rilasciare regolarmente nuove modifiche per quel cliente). Tutto va bene. Ma se il business cresce e ci sono più clienti, allora è necessario adeguarsi. Di solito, all'inizio non c'è un Ops efficace in azienda. Prima sviluppiamo il prodotto, e solo dopo ci rendiamo conto che per far funzionare il prodotto è necessario monitorare le server, controllare le consegne. È allora che nasce Ops. Resta da capire che Ops, come divisione separata, inizierà a porre una serie di ostacoli per lo sviluppo e tutte le consegne inizieranno a bloccarsi. In questo caso, la cultura DevOps è già rilevante, ma è necessario non dimenticare il suo lato oscuro.
Fonte: habr.com
