A seguito della discussione in chat
Negli ultimi tempi si sono accese vere e proprie battaglie sul significato di DevOps e SRE.
Nonostante ormai molte discussioni su questo tema siano diventate ridondanti, ho deciso di presentare la mia visione alla comunità di Habr. A chi è interessato, siete tutti invitati a proseguire. E ricominciamo da capo!
Contesto
Così, nei tempi antichi, esistevano team di sviluppatori software e amministratori di server separati. I primi scrivevano codice con successo, mentre i secondi, utilizzando parole gentili nei confronti dei primi, configuravano i server, facendo delle visite agli sviluppatori e ricevendo in risposta il generico "sul mio computer funziona tutto". L'azienda aspettava il software, tutto era fermo, si rompeva di tanto in tanto, e tutti erano nervosi. Soprattutto chi pagava per questo disordine. L'epoca del lampo nostalgico. Ma so che già sapete da dove nasce DevOps.
La nascita delle pratiche DevOps
Poi sono arrivati dei signori seri e hanno detto: non è così che funziona l'industria. E hanno portato i modelli del ciclo di vita. Ecco, per esempio, il modello V.
Quindi, cosa vediamo? L'azienda arriva con un concetto, gli architetti progettano delle soluzioni, gli sviluppatori scrivono codice e poi si verifica un fallimento. Qualcuno testava il prodotto in modo approssimativo, qualcun altro lo consegnava all'utente finale e, da qualche parte nell'uscita di questo straordinario modello, c'era un azionista aziendale in attesa delle promesse. Sono giunti alla conclusione che erano necessari metodi per migliorare questo processo. Così hanno deciso di creare pratiche che realizzassero queste finalità.
Una digressione lirica su ciò che è una pratica
Per me, una pratica è un connubio tra tecnologia e disciplina. Un esempio: la pratica della descrizione dell'infrastruttura come codice con terraform. La disciplina è come descrivere l'infrastruttura come codice, e questo risiede nella mente dello sviluppatore, mentre la tecnologia è appunto terraform.
Così hanno deciso di chiamarle pratiche DevOps — credo volessero dire 'da Sviluppo a Operazioni'. Hanno inventato concetti elaborati — pratiche CI/CD, pratiche basate sul principio dell'IaC, migliaia di esse. E così gli sviluppatori iniziano a scrivere codice, gli ingegneri DevOps trasformano la descrizione del sistema in codice in sistemi funzionanti (sì, il codice è purtroppo solo una descrizione, ma non è l'implementazione del sistema), la consegna si attiva, e così via. I vecchi amministratori, dopo aver appreso le nuove pratiche, si sono orgogliosamente riconvertiti in ingegneri DevOps e tutto ha preso il via. E c'era la sera, e c'era la mattina... scusate, non volevamo andare da lì.
Tutto di nuovo non va bene
Non appena tutto si era sistemato, vari 'metodologi' ingegnosi hanno cominciato a scrivere tomi sulle pratiche DevOps, e il dibattito su chi fosse davvero il famigerato ingegnere DevOps e cosa fosse DevOps — una cultura produttiva — ha ricominciato a infuocarsi, generando nuovamente discorsi di insoddisfazione. Si è scoperto improvvisamente che la consegna del software è un compito assolutamente non banale. Ogni infrastruttura di sviluppo ha il suo stack, dove a volte è necessario assemblare, a volte distribuire un ambiente, qui c'è bisogno di Tomcat, lì di un metodo complicato di avvio — in generale, ci si sente sopraffatti. Inoltre, il problema, come strano ma vero, risiedeva principalmente nell'organizzazione dei processi — questa funzione di consegna, come un collo di bottiglia, è diventata un blocco per i processi. Inoltre, l'operazione (Operations) non era affatto scomparsa. Nel modello V non è visibile, ma c'è ancora tutto il ciclo di vita sulla destra. Alla fine, è necessario mantenere l'infrastruttura, monitorare i processi, risolvere incidenti e occuparsi anche della consegna. Cioè, partecipare sia allo sviluppo che all'operazione — ed è così che è sorto Development & Operations. E poi è arrivato il grande hype sui microservizi. E con loro, lo sviluppo ha cominciato a migrare dal locale al cloud — prova a fare il debug localmente con decine e centinaia di microservizi, ora la consegna continua diventa un mezzo di sopravvivenza. Per una "piccola e modesta azienda" può anche andare bene, ma nonostante questo? E Google?
SRE di Google
Google è arrivato, ha mangiato i cactus più grandi e ha deciso: non ci serve questo, abbiamo bisogno di affidabilità. E l'affidabilità va gestita. Così ha deciso che servivano specialisti per gestire l'affidabilità. Li ha chiamati ingegneri SRE e ha detto: ecco tutto, fate come al solito, bene. Ecco il SLI, ecco l'SLO, ecco il monitoraggio. E ha puntato il dito sulle operazioni. E ha chiamato il suo "DevOps affidabile" SRE. Sembrerebbe tutto a posto, ma c'è un trucco sporco che Google si è potuto permettere: assumere per il ruolo di ingegneri SRE persone che avevano competenze da sviluppatori e conoscevano anche un po' il funzionamento dei sistemi in funzionamento. E ci sono problemi anche per Google con l'assunzione di queste persone, principalmente perché compete con se stesso: qualcuno deve pur descrivere la logica di business. Ha scaricato la consegna sugli ingegneri di rilascio, gli ingegneri SRE gestiscono l'affidabilità (naturalmente, non direttamente, ma influenzando l'infrastruttura, cambiando l'architettura, monitorando le modifiche e le metriche, affrontando gli incidenti). È un bel quadro, può . Ma cosa fare se non sei Google e l'affidabilità ti preoccupa comunque?
Sviluppo delle idee DevOps
Ecco che arriva Docker, nato da lxc, seguito da vari sistemi di orchestrazione come Docker Swarm e Kubernetes, e gli ingegneri DevOps hanno tirato un sospiro di sollievo: l'unificazione delle pratiche ha semplificato la consegna. Semplificata a tal punto che ora è possibile addirittura affidare la consegna agli sviluppatori — è solo un deployment.yaml. La containerizzazione risolve il problema. Inoltre, la maturità dei sistemi CI/CD è già a un livello tale che basta scrivere un file ed è fatta: gli sviluppatori ce la faranno da soli. E qui iniziamo a parlare di come realizzare il nostro SRE, con… chiunque.
SRE non è in Google
Ok, abbiamo affidato la consegna, sembrerebbe che possiamo tirare un sospiro di sollievo e tornare ai bei vecchi tempi in cui gli amministratori guardavano il carico dei processori, ottimizzavano i sistemi e sorseggiavano tranquillamente qualcosa di poco chiaro in silenzio e serenità... Aspetta. Non era per questo che abbiamo iniziato tutto (peccato!). All'improvviso ci rendiamo conto che nel processo di Google possiamo adottare pratiche eccellenti: non è il carico dei processori ciò che conta, né quanto spesso cambiamo i dischi, o quanto ottimizziamo i costi nel cloud, ma le metriche aziendali: tutti quei famosi SLx. E la gestione dell'infrastruttura non è stata tolta da lì, e gli incidenti devono essere risolti, e bisogna vigilare periodicamente, e in generale occorre essere preparati sui processi aziendali. E ragazzi, iniziate a programmare a un buon livello, Google vi aspetta già.
In sintesi. All'improvviso, ma siete già stanchi di leggere e non vedete l'ora di scrivere un commento all'autore dell'articolo. DevOps come pratiche di consegna è stato, è, e sarà. E non andrà da nessuna parte. SRE come insieme di pratiche operative rende questa consegna stessa un successo.
Fonte: habr.com
