{"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 una volta su DevOps e SRE","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sulla base della discussione nella chat AWS Minsk Community<\/a><\/noindex><\/p>\n

Negli ultimi tempi si stanno svolgendo vere e proprie battaglie riguardo alla definizione di DevOps e SRE.
\nNonostante il fatto che le discussioni su questo tema siano ormai diventate un po' monotone, anche per me, ho deciso di portare alla comunit\u00e0 di Habr la mia visione su questo argomento. A chi \u00e8 interessato, benvenuto sotto il cat. E che tutto ricominci da capo!
\n<\/a><\/noindex><\/p>\n

Antefatti<\/h4>\n

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

Nascita delle pratiche DevOps<\/h4>\n

\nPoi sono arrivati uomini seri e hanno detto: \"questa non \u00e8 un'industria, non si pu\u00f2 lavorare cos\u00ec\". E hanno portato modelli di ciclo di vita. Ecco, per esempio, il modello a V.<\/p>\n

\"Ancora
\nQuindi, cosa vediamo? Le aziende vengono con un concetto, gli architetti progettano soluzioni, gli sviluppatori scrivono codice, e poi c'\u00e8 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 \u00e8 giunti alla conclusione che servono metodi per sistemare questo processo. E hanno deciso di creare pratiche per realizzarli.<\/p>\n

Una digressione lirica su cosa sia la pratica<\/b>
\nCon pratica intendo un collegamento tra tecnologia e disciplina. Esempio: pratica di descrivere l'infrastruttura con codice su Terraform. La disciplina \u00e8 come descrivere l'infrastruttura con il codice, \u00e8 nella testa dello sviluppatore, mentre la tecnologia \u00e8 appunto Terraform.<\/p>\n

E hanno deciso di chiamarli pratiche DevOps \u2014 penso intendessero da Development a Operations. Hanno inventato varie cose complesse \u2014 pratiche CI\/CD, pratiche basate sul principio IaC, sono migliaia. E cos\u00ec \u00e8 cominciato, gli sviluppatori scrivono 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 l'incarnazione del sistema), la consegna prende piede, e cos\u00ec via. Gli amministratori di ieri, dopo aver acquisito nuove pratiche, si sono orgogliosamente riciclati in ingegneri DevOps, ed \u00e8 iniziato un vero e proprio fermento. E fu sera, e fu mattina\u2026 scusate, non proviene da l\u00ec.<\/p>\n

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

\nNon appena tutto si \u00e8 stabilizzato, e vari astuti \"metodologi\" hanno cominciato a scrivere tomi su pratiche DevOps, \u00e8 cominciata a infiammarsi una disputa su chi fosse realmente il famigerato ingegnere DevOps e che DevOps fosse una cultura di produzione, si \u00e8 nuovamente manifestato il malcontento. All'improvviso si \u00e8 scoperto che la consegna del software \u00e8 un compito assolutamente non triviale. Ogni infrastruttura di sviluppo ha il proprio stack, a volte \u00e8 necessario assemblare, a volte distribuire un ambiente, qui serve tomcat, l\u00ec serve un'anomala modalit\u00e0 di avvio \u2014 insomma, \u00e8 una vera confusione. E c'\u00e8 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 \u00e8 stata annullata l'operazione (Operations). Non \u00e8 visibile nel modello a V, e l\u00ec c'\u00e8 ancora l'intero ciclo di vita a destra. Alla fine \u00e8 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 \u2014 e cos\u00ec \u00e8 nato un Development & Operations. E poi \u00e8 arrivato anche il grande hype sui microservizi. E con loro anche lo sviluppo ha cominciato a spostarsi dal locale al cloud \u2014 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?<\/p>\n

SRE di Google<\/h4>\n

\n\u00c8 arrivato Google, ha mangiato i cactus pi\u00f9 grandi e ha deciso: non ci serve questo, abbiamo bisogno di affidabilit\u00e0. E l'affidabilit\u00e0 deve essere gestita. Cos\u00ec ha deciso: abbiamo bisogno di specialisti che gestiranno l'affidabilit\u00e0. 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'\u00e8 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\u00e9 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\u00e0 (ovviamente non direttamente, ma influenzando l'infrastruttura, modificando l'architettura, monitorando le modifiche e le metriche, gestendo gli incidenti). \u00c8 tutto molto bello, si pu\u00f2 scrivere libri<\/a><\/noindex>. E cosa fare se non siete Google, ma l'affidabilit\u00e0 comunque vi preoccupa?<\/p>\n

Sviluppo delle idee DevOps<\/h4>\n

\nQui \u00e8 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 \u00e8 diventato possibile persino delegare la consegna agli sviluppatori: che ci vuole con deployment.yaml? La containerizzazione risolve il problema. E la maturit\u00e0 dei sistemi CI\/CD \u00e8 gi\u00e0 a un livello in cui basta scrivere un file ed \u00e8 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. <\/p>\n

SRE non in Google<\/h4>\n

\nVa 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\u00e0\u2026 Aspetta. Non \u00e8 per questo che abbiamo avviato tutto (peccato!). Improvvisamente si scopre che nel metodo di Google possiamo trarre ottime pratiche \u2014 non \u00e8 il caricamento delle CPU l'aspetto importante, n\u00e9 quanto spesso cambiamo i dischi o ottimizziamo i costi nel cloud, ma le metriche aziendali \u2014 quelle famose SLx. E la gestione dell'infrastruttura non \u00e8 stata affatto annullata, gli incidenti devono essere risolti, bisogna essere di guardia di tanto in tanto, e pi\u00f9 in generale, essere aggiornati sui processi aziendali. E ragazzi, iniziate un po' a programmare a un buon livello, Google vi sta gi\u00e0 aspettando.<\/p>\n

In sintesi. Improvvisamente, ma siete gi\u00e0 stanchi di leggere e fremete dalla voglia di commentare l'articolo. Il DevOps come pratica di consegna \u00e8 stato, \u00e8 e sar\u00e0 sempre presente. E non scomparir\u00e0. L'SRE come insieme di pratiche operative rende questa consegna stessa di 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 una volta su DevOps e SRE | ProHoster","description":"A proposito della discussione nel chat AWS Minsk Community Ultimamente si stanno scatenando 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}]}}