{"id":55735,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/eshhe-raz-o-devops-i-sre"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"eshhe-raz-o-devops-i-sre","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","title":{"rendered":"Ancora su DevOps e SRE","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A seguito della discussione in chat AWS Minsk Community<\/a><\/noindex><\/p>\n

Negli ultimi tempi si sono accese vere e proprie battaglie sul significato di DevOps e SRE.
\nNonostante ormai molte discussioni su questo tema siano diventate ridondanti, ho deciso di presentare la mia visione alla comunit\u00e0 di Habr. A chi \u00e8 interessato, siete tutti invitati a proseguire. E ricominciamo da capo!
\n<\/a><\/noindex><\/p>\n

Contesto<\/h4>\n

\nCos\u00ec, 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\u00e0 sapete da dove nasce DevOps. <\/p>\n

La nascita delle pratiche DevOps<\/h4>\n

\nPoi sono arrivati dei signori seri e hanno detto: non \u00e8 cos\u00ec che funziona l'industria. E hanno portato i modelli del ciclo di vita. Ecco, per esempio, il modello V.<\/p>\n

\"Ancora
\nQuindi, 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\u00ec hanno deciso di creare pratiche che realizzassero queste finalit\u00e0.<\/p>\n

Una digressione lirica su ci\u00f2 che \u00e8 una pratica<\/b>
\nPer me, una pratica \u00e8 un connubio tra tecnologia e disciplina. Un esempio: la pratica della descrizione dell'infrastruttura come codice con terraform. La disciplina \u00e8 come descrivere l'infrastruttura come codice, e questo risiede nella mente dello sviluppatore, mentre la tecnologia \u00e8 appunto terraform.<\/p>\n

Cos\u00ec hanno deciso di chiamarle pratiche DevOps \u2014 credo volessero dire 'da Sviluppo a Operazioni'. Hanno inventato concetti elaborati \u2014 pratiche CI\/CD, pratiche basate sul principio dell'IaC, migliaia di esse. E cos\u00ec gli sviluppatori iniziano a scrivere codice, gli ingegneri DevOps trasformano la descrizione del sistema in codice in sistemi funzionanti (s\u00ec, il codice \u00e8 purtroppo solo una descrizione, ma non \u00e8 l'implementazione del sistema), la consegna si attiva, e cos\u00ec 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\u00ec.<\/p>\n

Tutto di nuovo non va bene<\/h4>\n

\nNon 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 \u2014 una cultura produttiva \u2014 ha ricominciato a infuocarsi, generando nuovamente discorsi di insoddisfazione. Si \u00e8 scoperto improvvisamente che la consegna del software \u00e8 un compito assolutamente non banale. Ogni infrastruttura di sviluppo ha il suo stack, dove a volte \u00e8 necessario assemblare, a volte distribuire un ambiente, qui c'\u00e8 bisogno di Tomcat, l\u00ec di un metodo complicato di avvio \u2014 in generale, ci si sente sopraffatti. Inoltre, il problema, come strano ma vero, risiedeva principalmente nell'organizzazione dei processi \u2014 questa funzione di consegna, come un collo di bottiglia, \u00e8 diventata un blocco per i processi. Inoltre, l'operazione (Operations) non era affatto scomparsa. Nel modello V non \u00e8 visibile, ma c'\u00e8 ancora tutto il ciclo di vita sulla destra. Alla fine, \u00e8 necessario mantenere l'infrastruttura, monitorare i processi, risolvere incidenti e occuparsi anche della consegna. Cio\u00e8, partecipare sia allo sviluppo che all'operazione \u2014 ed \u00e8 cos\u00ec che \u00e8 sorto Development & Operations. E poi \u00e8 arrivato il grande hype sui microservizi. E con loro, lo sviluppo ha cominciato a migrare dal locale al cloud \u2014 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\u00f2 anche andare bene, ma nonostante questo? E Google?<\/p>\n

SRE di Google<\/h4>\n

\nGoogle \u00e8 arrivato, ha mangiato i cactus pi\u00f9 grandi e ha deciso: non ci serve questo, abbiamo bisogno di affidabilit\u00e0. E l'affidabilit\u00e0 va gestita. Cos\u00ec ha deciso che servivano specialisti per gestire l'affidabilit\u00e0. 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'\u00e8 un trucco sporco che Google si \u00e8 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\u00e9 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\u00e0 (naturalmente, non direttamente, ma influenzando l'infrastruttura, cambiando l'architettura, monitorando le modifiche e le metriche, affrontando gli incidenti). \u00c8 un bel quadro, pu\u00f2 scrivere libri<\/a><\/noindex>. Ma cosa fare se non sei Google e l'affidabilit\u00e0 ti preoccupa comunque?<\/p>\n

Sviluppo delle idee DevOps<\/h4>\n

\nEcco 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 \u00e8 possibile addirittura affidare la consegna agli sviluppatori \u2014 \u00e8 solo un deployment.yaml. La containerizzazione risolve il problema. Inoltre, la maturit\u00e0 dei sistemi CI\/CD \u00e8 gi\u00e0 a un livello tale che basta scrivere un file ed \u00e8 fatta: gli sviluppatori ce la faranno da soli. E qui iniziamo a parlare di come realizzare il nostro SRE, con\u2026 chiunque. <\/p>\n

SRE non \u00e8 in Google<\/h4>\n

\nOk, 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\u00e0... 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 \u00e8 il carico dei processori ci\u00f2 che conta, n\u00e9 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 \u00e8 stata tolta da l\u00ec, 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\u00e0.<\/p>\n

In sintesi. All'improvviso, ma siete gi\u00e0 stanchi di leggere e non vedete l'ora di scrivere un commento all'autore dell'articolo. DevOps come pratiche di consegna \u00e8 stato, \u00e8, e sar\u00e0. E non andr\u00e0 da nessuna parte. SRE come insieme di pratiche operative rende questa consegna stessa un successo.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u0447\u0430\u0442\u0435 AWS Minsk Community \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0440\u0430\u0437\u0433\u043e\u0440\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0431\u0438\u0442\u0432\u044b \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043d\u044f\u0442\u0438\u044f DevOps \u0438 SRE. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0443\u0436\u0435 \u0432\u043e \u043c\u043d\u043e\u0433\u043e\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443 \u0443\u0436\u0435 \u043d\u0430\u0431\u0438\u043b\u0438 \u043e\u0441\u043a\u043e\u043c\u0438\u043d\u0443, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u0438 \u043c\u043d\u0435, \u0440\u0435\u0448\u0438\u043b \u0432\u044b\u043d\u0435\u0441\u0442\u0438 \u043d\u0430 \u0441\u0443\u0434 \u0445\u0430\u0431\u0440\u0430-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 \u0438 \u0441\u0432\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443. \u0422\u0435\u043c, \u043a\u043e\u043c\u0443 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e, \u0434\u043e\u0431\u0440\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55736,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ancora su DevOps e SRE | ProHoster","description":"A seguito della discussione nella chat della Community di AWS Minsk, di recente si sono accese vere e proprie battaglie riguardo alla definizione del concetto.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0415\u0449\u0435 \u0440\u0430\u0437 \u043e DevOps \u0438 SRE | ProHoster","og:description":"\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u0447\u0430\u0442\u0435 AWS Minsk Community \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0440\u0430\u0437\u0433\u043e\u0440\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0431\u0438\u0442\u0432\u044b \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043d\u044f\u0442\u0438\u044f.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-10-05 06:23:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=55735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/55736"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=55735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=55735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=55735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}