Basato su una discussione in chat
Recentemente sono scoppiate vere e proprie battaglie sulla definizione di DevOps e SRE.
Nonostante il fatto che in molti modi le discussioni su questo argomento mi abbiano già messo i denti al limite, me compreso, ho deciso di portare il mio punto di vista su questo argomento alla corte della comunità Habra. Per coloro che sono interessati, benvenuti a cat. E che tutto ricominci da capo!
Sfondo
Quindi, nei tempi antichi, un team di sviluppatori di software e amministratori di server viveva separatamente. Il primo ha scritto con successo il codice, il secondo, con l'aiuto di varie parole affettuose e affettuose rivolte al primo, ha configurato i server, venendo periodicamente dagli sviluppatori e ricevendo in risposta un messaggio completo "tutto funziona sulla mia macchina". L'azienda aspettava il software, tutto era inattivo, si rompeva periodicamente, tutti erano nervosi. Soprattutto quello che ha pagato per tutto questo pasticcio. Era gloriosa della lampada. Bene, sai già da dove viene DevOps.
La nascita delle pratiche DevOps
Poi sono venuti ragazzi seri e hanno detto: questo non è un settore, non puoi lavorare così. E hanno introdotto modelli del ciclo di vita. Ecco, ad esempio, il modello V.
Quindi cosa vediamo? Un'azienda nasce con un concetto, gli architetti progettano soluzioni, gli sviluppatori scrivono codice e poi fallisce. Qualcuno in qualche modo testa il prodotto, qualcuno in qualche modo lo consegna all'utente finale e da qualche parte all'uscita di questo modello miracoloso siede un cliente aziendale solitario in attesa del tempo promesso in riva al mare. Siamo giunti alla conclusione che abbiamo bisogno di metodi che ci consentano di avviare questo processo. E abbiamo deciso di creare pratiche che le implementassero.
Una digressione lirica sul tema di cosa sia la pratica
Per pratica intendo una combinazione di tecnologia e disciplina. Un esempio è la pratica di descrivere l'infrastruttura utilizzando il codice terraform. La disciplina è come descrivere l'infrastruttura con il codice, è nella testa dello sviluppatore e la tecnologia è la terraformazione stessa.
E hanno deciso di chiamarle pratiche DevOps: penso che intendessero dallo sviluppo alle operazioni. Abbiamo escogitato varie cose intelligenti: pratiche CI/CD, pratiche basate sul principio IaC, migliaia di esse. E si parte, gli sviluppatori scrivono codice, gli ingegneri DevOps trasformano la descrizione del sistema sotto forma di codice in sistemi funzionanti (sì, il codice, sfortunatamente, è solo una descrizione, ma non l'incarnazione del sistema), la consegna continua, e così via. Gli amministratori di ieri, dopo aver padroneggiato nuove pratiche, si sono orgogliosamente riqualificati come ingegneri DevOps e tutto è andato da lì. E fu sera e fu mattina... scusa, non di lì.
Non va ancora tutto bene, grazie a Dio
Non appena tutto si è calmato e vari astuti "metodologi" hanno iniziato a scrivere grossi libri sulle pratiche DevOps, sono scoppiate silenziosamente controversie su chi fosse il famigerato ingegnere DevOps e che DevOps sia una cultura di produzione, è sorto di nuovo il malcontento. All'improvviso si è scoperto che la distribuzione del software è un compito assolutamente non banale. Ogni infrastruttura di sviluppo ha il proprio stack, da qualche parte devi assemblarlo, da qualche parte devi distribuire l'ambiente, qui hai bisogno di Tomcat, qui hai bisogno di un modo astuto e complicato per avviarlo - in generale, ti batte la testa. E il problema, stranamente, si è rivelato principalmente nell'organizzazione dei processi: questa funzione di consegna, come un collo di bottiglia, ha iniziato a bloccare i processi. Inoltre, nessuno ha annullato le operazioni. Non è visibile nel modello V, ma sulla destra è comunque presente l'intero ciclo di vita. Di conseguenza, è necessario in qualche modo mantenere l’infrastruttura, monitorare il monitoraggio, risolvere gli incidenti e occuparsi anche della consegna. Quelli. sedermi con un piede sia nello sviluppo che nelle operazioni - e all'improvviso si è scoperto che si trattava di sviluppo e operazioni. E poi c’è stata la campagna pubblicitaria generale per i microservizi. E con loro, lo sviluppo dalle macchine locali ha iniziato a spostarsi nel cloud: prova a eseguire il debug di qualcosa localmente, se ci sono dozzine e centinaia di microservizi, la consegna costante diventa un mezzo di sopravvivenza. Per una “piccola e modesta azienda” andava bene, ma comunque? E che dire di Google?
SRE di Google
Google è arrivato, ha mangiato i cactus più grandi e ha deciso: non ne abbiamo bisogno, abbiamo bisogno di affidabilità. E l’affidabilità deve essere gestita. E ho deciso che abbiamo bisogno di specialisti che gestiscano l'affidabilità. Li ho chiamati ingegneri SR e ho detto, per voi è tutto, fatelo bene come al solito. Ecco SLI, ecco SLO, ecco il monitoraggio. E ha ficcato il naso nelle operazioni. E ha chiamato il suo “DevOps affidabile” SRE. Sembra che tutto vada bene, ma c'è uno sporco hack che Google può permettersi: assumere persone che siano sviluppatori qualificati per la posizione di ingegneri SR e che facciano anche un po' di compiti e comprendano il funzionamento dei sistemi di lavoro. Inoltre, la stessa Google ha problemi con l'assunzione di tali persone - principalmente perché qui compete con se stessa - è necessario descrivere a qualcuno la logica aziendale. La consegna è stata assegnata agli ingegneri del rilascio, gli ingegneri SR gestiscono l'affidabilità (ovviamente, non direttamente, ma influenzando l'infrastruttura, modificando l'architettura, monitorando cambiamenti e indicatori, affrontando gli incidenti). Bello, puoi . Ma cosa succede se non sei Google, ma l'affidabilità è ancora in qualche modo una preoccupazione?
Sviluppo di idee DevOps
Proprio allora è arrivato Docker, che è nato da lxc, e poi vari sistemi di orchestrazione come Docker Swarm e Kubernetes, e gli ingegneri DevOps hanno esalato: l'unificazione delle pratiche ha semplificato la consegna. Lo ha semplificato a tal punto che è diventato possibile persino esternalizzare la consegna agli sviluppatori: cos'è deploy.yaml. La containerizzazione risolve il problema. E la maturità dei sistemi CI/CD è già al livello della scrittura di un file e il gioco è fatto: gli sviluppatori possono gestirlo da soli. E poi iniziamo a parlare di come possiamo creare il nostro SRE, con... o almeno con qualcuno.
SRE non è su Google
Bene, ok, abbiamo consegnato la consegna, sembra che possiamo espirare, tornare ai bei vecchi tempi, quando gli amministratori osservavano il caricamento del processore, mettevano a punto i sistemi e sorseggiavano tranquillamente qualcosa di incomprensibile dalle tazze in pace e tranquillità... Basta. Non è per questo che abbiamo iniziato tutto (il che è un peccato!). All'improvviso si scopre che nell'approccio di Google possiamo facilmente adottare pratiche eccellenti: non è il carico del processore che è importante, e non quanto spesso cambiamo i dischi lì o ottimizziamo i costi nel cloud, ma le metriche aziendali sono le stesse famigerate SLx. E nessuno ha rimosso loro la gestione dell'infrastruttura e devono risolvere gli incidenti, essere in servizio periodicamente e in generale tenere sotto controllo i processi aziendali. E ragazzi, iniziate a programmare poco a poco ad un buon livello, Google vi sta già aspettando.
Riassumere. All'improvviso, ma sei già stanco di leggere e non vedi l'ora di sputare e scrivere all'autore in un commento all'articolo. DevOps come pratica di distribuzione è sempre stato e lo sarà. E non andrà da nessuna parte. La SRE come insieme di pratiche operative garantisce il successo di questa consegna.
Fonte: habr.com