Sulla base della discussione nella chat
Negli ultimi tempi si stanno svolgendo vere e proprie battaglie riguardo alla definizione di DevOps e SRE.
Nonostante il fatto che le discussioni su questo tema siano ormai diventate un po' monotone, anche per me, ho deciso di portare alla comunità di Habr la mia visione su questo argomento. A chi è interessato, benvenuto sotto il cat. E che tutto ricominci da capo!
Antefatti
Così, nei tempi antichi, c'era una squadra di sviluppatori software e amministratori di server. I primi scrivevano codice, i secondi, usando varie parole affettuose nei confronti dei primi, configuravano i server, venendo periodicamente dagli sviluppatori e ricevendo in cambio un esaustivo "sulla mia macchina funziona tutto". Le aziende aspettavano software e tutto si bloccava, di tanto in tanto si rompeva, tutti erano nervosi. Soprattutto chi pagava per tutto questo caos. L'era gloriosa e analogica. Ma sì, lo sapete già da dove nasce DevOps.
Nascita delle pratiche DevOps
Poi sono arrivati uomini seri e hanno detto: "questa non è un'industria, non si può lavorare così". E hanno portato modelli di ciclo di vita. Ecco, per esempio, il modello a V.
Quindi, cosa vediamo? Le aziende vengono con un concetto, gli architetti progettano soluzioni, gli sviluppatori scrivono codice, e poi c'è un fallimento. 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 si trova un solo cliente d'affari che aspetta promesse. Si è giunti alla conclusione che servono metodi per sistemare questo processo. E hanno deciso di creare pratiche per realizzarli.
Una digressione lirica su cosa sia la pratica
Con pratica intendo un collegamento tra tecnologia e disciplina. Esempio: pratica di descrivere l'infrastruttura con codice su Terraform. La disciplina è come descrivere l'infrastruttura con il codice, è nella testa dello sviluppatore, mentre la tecnologia è appunto Terraform.
E hanno deciso di chiamarli pratiche DevOps — penso intendessero da Development a Operations. Hanno inventato varie cose complesse — pratiche CI/CD, pratiche basate sul principio IaC, sono migliaia. E così è cominciato, gli sviluppatori scrivono codice, gli ingegneri DevOps trasformano la descrizione del sistema in codice in sistemi funzionanti (sì, il codice è purtroppo solo una descrizione, ma non l'incarnazione del sistema), la consegna prende piede, e così via. Gli amministratori di ieri, dopo aver acquisito nuove pratiche, si sono orgogliosamente riciclati in ingegneri DevOps, ed è iniziato un vero e proprio fermento. E fu sera, e fu mattina… scusate, non proviene da lì.
Tutto di nuovo non va bene
Non appena tutto si è stabilizzato, e vari astuti "metodologi" hanno cominciato a scrivere tomi su pratiche DevOps, è cominciata a infiammarsi una disputa su chi fosse realmente il famigerato ingegnere DevOps e che DevOps fosse una cultura di produzione, si è nuovamente manifestato il malcontento. All'improvviso si è scoperto che la consegna del software è un compito assolutamente non triviale. Ogni infrastruttura di sviluppo ha il proprio stack, a volte è necessario assemblare, a volte distribuire un ambiente, qui serve tomcat, lì serve un'anomala modalità di avvio — insomma, è una vera confusione. E c'è anche un problema che, stranamente, risulta anzitutto nell'organizzazione dei processi: questa funzione di consegna, come un collo di bottiglia, ha cominciato a bloccare i processi. Inoltre, non è stata annullata l'operazione (Operations). Non è visibile nel modello a V, e lì c'è ancora l'intero ciclo di vita a destra. Alla fine è necessario anche mantenere in qualche modo l'infrastruttura, monitorare, gestire gli incidenti e occuparsi della consegna. Ovvero, sedere con un piede nello sviluppo e con l'altro nell'operazione — e così è nato un Development & Operations. E poi è arrivato anche il grande hype sui microservizi. E con loro anche lo sviluppo ha cominciato a spostarsi dal locale al cloud — prova a debugare qualcosa localmente se i microservizi sono decine o centinaia, qui la consegna continuativa diventa un mezzo di sopravvivenza. Per una "piccola e modesta azienda" potrebbe andare bene, ma tutto sommato? E Google?
SRE di Google
È arrivato Google, ha mangiato i cactus più grandi e ha deciso: non ci serve questo, abbiamo bisogno di affidabilità. E l'affidabilità deve essere gestita. Così ha deciso: abbiamo bisogno di specialisti che gestiranno l'affidabilità. Li ha chiamati ingegneri SRE e ha detto: ecco a voi tutto, fate come al solito, bene. Ecco a voi SLI, ecco a voi SLO, ecco a voi il monitoraggio. E ha puntato il dito sulle operazioni. E ha chiamato il suo "DevOps affidabile" SRE. Sembra tutto a posto, ma c'è un brutto trucco che Google poteva permettersi: assumere ingegneri SRE con qualifiche da sviluppatori, a cui magari mancava solo un po' di esperienza nel funzionamento dei sistemi. Ma anche Google ha problemi nell'assumere queste persone, principalmente perché compete con se stesso: qualcuno deve pur descrivere la logica aziendale. Ha delegato la consegna agli ingegneri di rilascio, e gli ingegneri SRE gestiscono l'affidabilità (ovviamente non direttamente, ma influenzando l'infrastruttura, modificando l'architettura, monitorando le modifiche e le metriche, gestendo gli incidenti). È tutto molto bello, si può . E cosa fare se non siete Google, ma l'affidabilità comunque vi preoccupa?
Sviluppo delle idee DevOps
Qui è appena arrivato Docker, nato da lxc, e poi 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. Ha semplificato a tal punto che è diventato possibile persino delegare la consegna agli sviluppatori: che ci vuole con deployment.yaml? La containerizzazione risolve il problema. E la maturità dei sistemi CI/CD è già a un livello in cui basta scrivere un file ed è tutto in movimento: gli sviluppatori ce la faranno da soli. E qui iniziamo a parlare di come creare il nostro SRE, con... beh, anche chiunque.
SRE non in Google
Va bene, abbiamo consegnato la spedizione, sembrerebbe che possiamo respirare, tornare ai vecchi e buoni tempi in cui gli amministratori monitoravano il carico delle CPU, ottimizzavano i sistemi e sorseggiavano qualcosa di indefinito in silenzio e tranquillità… Aspetta. Non è per questo che abbiamo avviato tutto (peccato!). Improvvisamente si scopre che nel metodo di Google possiamo trarre ottime pratiche — non è il caricamento delle CPU l'aspetto importante, né quanto spesso cambiamo i dischi o ottimizziamo i costi nel cloud, ma le metriche aziendali — quelle famose SLx. E la gestione dell'infrastruttura non è stata affatto annullata, gli incidenti devono essere risolti, bisogna essere di guardia di tanto in tanto, e più in generale, essere aggiornati sui processi aziendali. E ragazzi, iniziate un po' a programmare a un buon livello, Google vi sta già aspettando.
In sintesi. Improvvisamente, ma siete già stanchi di leggere e fremete dalla voglia di commentare l'articolo. Il DevOps come pratica di consegna è stato, è e sarà sempre presente. E non scomparirà. L'SRE come insieme di pratiche operative rende questa consegna stessa di successo.
Fonte: habr.com
