{"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\/pt\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","title":{"rendered":"Mais uma vez sobre DevOps e SRE","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Inspirado em uma discuss\u00e3o no chat Comunidade AWS Minsk<\/a><\/noindex><\/p>\n

Recentemente, verdadeiras batalhas t\u00eam se intensificado em torno da defini\u00e7\u00e3o dos conceitos de DevOps e SRE.
\nEmbora essas discuss\u00f5es j\u00e1 estejam cansativas, decidi apresentar minha perspectiva \u00e0 comunidade do Habr. A todos os interessados, sintam-se \u00e0 vontade para continuar. Que tudo comece de novo!
\n<\/a><\/noindex><\/p>\n

Antecedentes<\/h4>\n

\nAssim, em tempos antigos, havia uma equipe separada de desenvolvedores de software e administradores de servidores. Os primeiros escreviam c\u00f3digo com sucesso, enquanto os segundos, usando v\u00e1rias palavras carinhosas em rela\u00e7\u00e3o aos primeiros, configuravam os servidores, visitando os desenvolvedores algumas vezes e recebendo como resposta um enf\u00e1tico \"na minha m\u00e1quina funciona tudo\". O neg\u00f3cio esperava pelo software, tudo parava, quebrava de vez em quando, e todos ficavam nervosos. Especialmente quem pagava todo esse caos. A gloriosa era anal\u00f3gica. Mas voc\u00eas j\u00e1 sabem de onde vem o DevOps. <\/p>\n

O nascimento das pr\u00e1ticas de DevOps<\/h4>\n

\nEnt\u00e3o, vieram os senhores s\u00e9rios e disseram - isso n\u00e3o \u00e9 uma ind\u00fastria, n\u00e3o se pode trabalhar assim. E trouxeram modelos de ciclo de vida. Por exemplo, o modelo em V.<\/p>\n

\"Mais
\nEnt\u00e3o, o que vemos? O neg\u00f3cio chega com um conceito, os arquitetos projetam solu\u00e7\u00f5es, os desenvolvedores escrevem c\u00f3digo, e ent\u00e3o - tudo desmorona. Algu\u00e9m testa o produto de algum jeito, algu\u00e9m o entrega ao usu\u00e1rio final e em algum ponto dessa maravilha de modelo, um solit\u00e1rio cliente do neg\u00f3cio espera a promessa que est\u00e1 no vento. Chegaram \u00e0 conclus\u00e3o de que eram necess\u00e1rios m\u00e9todos que pudessem organizar esse processo. Decidiram ent\u00e3o criar pr\u00e1ticas que os implementassem.<\/p>\n

Um par\u00eantese l\u00edrico sobre o que \u00e9 pr\u00e1tica<\/b>
\nPor pr\u00e1tica, entendo uma combina\u00e7\u00e3o de tecnologia e disciplina. Exemplo - a pr\u00e1tica de descrever infraestrutura como c\u00f3digo usando terraform. A disciplina \u00e9 como descrever a infraestrutura como c\u00f3digo, est\u00e1 na cabe\u00e7a do desenvolvedor, e a tecnologia \u00e9, de fato, o terraform.<\/p>\n

E decidiram cham\u00e1-los de pr\u00e1ticas DevOps \u2013 acho que se referiam a 'do Desenvolvimento \u00e0 Opera\u00e7\u00e3o'. Inventaram diversas coisas complicadas \u2013 pr\u00e1ticas de CI\/CD, pr\u00e1ticas baseadas no princ\u00edpio de IaC, milhares delas. E assim come\u00e7ou, os desenvolvedores escrevem c\u00f3digo, os engenheiros DevOps transformam a descri\u00e7\u00e3o do sistema em c\u00f3digo em sistemas funcionais (sim, c\u00f3digo \u00e9 infelizmente apenas uma descri\u00e7\u00e3o, mas de forma alguma a manifesta\u00e7\u00e3o do sistema), a entrega gira, e assim por diante. Administradores de ontem, ao dominar novas pr\u00e1ticas, orgulhosamente se requalificaram como engenheiros DevOps, e tudo come\u00e7ou. E foi \u00e0 noite, e foi de manh\u00e3... desculpe, n\u00e3o \u00e9 disso que se trata.<\/p>\n

Tudo de novo n\u00e3o est\u00e1 certo.<\/h4>\n

\nAssim que as coisas se acalmaram, diferentes 'metodologistas' astutos come\u00e7aram a escrever livros volumosos sobre pr\u00e1ticas DevOps, debates silenciosos come\u00e7aram sobre quem realmente \u00e9 o t\u00e3o falado engenheiro DevOps e o que \u00e9 DevOps \u2013 uma cultura de produ\u00e7\u00e3o, a insatisfa\u00e7\u00e3o voltou a surgir. De repente, ficou claro que a entrega de software \u00e9 uma tarefa absolutamente n\u00e3o trivial. Cada infraestrutura de desenvolvimento tem sua pr\u00f3pria pilha; em alguns lugares, \u00e9 preciso compilar, em outros, configurar o ambiente, aqui precisamos de tomcat, ali um jeito complicado de inicializar \u2013 no geral, a cabe\u00e7a d\u00f3i. E a quest\u00e3o, estranhamente, estava primariamente na organiza\u00e7\u00e3o dos processos \u2013 essa fun\u00e7\u00e3o de entrega, como um gargalo, come\u00e7ou a bloquear os processos. Al\u00e9m disso, a opera\u00e7\u00e3o (Operations) n\u00e3o foi cancelada. N\u00e3o \u00e9 vis\u00edvel no modelo V, e ainda h\u00e1 todo o ciclo de vida \u00e0 direita. No final, \u00e9 preciso manter a infraestrutura, monitorar, resolver incidentes e ainda se preocupar com a entrega. Ou seja, equilibrar tanto o desenvolvimento quanto a opera\u00e7\u00e3o \u2013 e de repente surgiu esse Development & Operations. E ainda houve um frenesi em torno de microsservi\u00e7os. Com eles, o desenvolvimento come\u00e7ou a migrar das m\u00e1quinas locais para a nuvem \u2013 tente depurar algo localmente se h\u00e1 dezenas e centenas de microsservi\u00e7os; a entrega cont\u00ednua torna-se uma quest\u00e3o de sobreviv\u00eancia. Para uma 'pequena empresa discreta' isso \u00e9 aceit\u00e1vel, mas e quanto ao Google?<\/p>\n

SRE do Google<\/h4>\n

\nO Google chegou, comeu os maiores cactos e decidiu \u2014 n\u00e3o precisamos disso, precisamos de confiabilidade. E a confiabilidade precisa ser gerenciada. E decidiu \u2014 precisamos de especialistas que gerenciem a confiabilidade. Chamou-os de engenheiros de SR e disse, aqui est\u00e1 tudo que voc\u00eas precisam, fa\u00e7am o que costumam fazer, bem. Aqui est\u00e1 seu SLI, aqui est\u00e1 seu SLO, aqui est\u00e1 a monitora\u00e7\u00e3o. E apontou para as opera\u00e7\u00f5es. E chamou seu 'DevOps confi\u00e1vel' de SRE. Parece tudo bem, mas h\u00e1 um truque sujo que o Google p\u00f4de se permitir \u2014 contratar pessoas para a posi\u00e7\u00e3o de engenheiros de SR que tinham qualifica\u00e7\u00f5es de desenvolvedores e ainda entendiam um pouco sobre o funcionamento de sistemas em opera\u00e7\u00e3o. Al\u00e9m disso, o Google tamb\u00e9m tem problemas para contratar essas pessoas \u2014 principalmente porque ele mesmo concorre consigo mesmo \u2014 deve haver algu\u00e9m que descreva a l\u00f3gica de neg\u00f3cios. A entrega foi delegada aos engenheiros de lan\u00e7amento, os engenheiros de SR gerenciam a confiabilidade (claro, n\u00e3o diretamente, mas influenciando a infraestrutura, mudando a arquitetura, monitorando mudan\u00e7as e indicadores, lidando com incidentes). Bonito, pode escrever livros<\/a><\/noindex>. E o que fazer se voc\u00ea n\u00e3o \u00e9 o Google, mas a confiabilidade ainda o preocupa?<\/p>\n

Desenvolvimento de ideias de DevOps<\/h4>\n

\nAqui chegou o Docker, que cresceu a partir do lxc, e depois v\u00e1rias sistemas de orquestra\u00e7\u00e3o como Docker Swarm e Kubernetes, e os engenheiros de DevOps respiraram aliviados \u2014 a unifica\u00e7\u00e3o das pr\u00e1ticas simplificou a entrega. Simplificou a tal ponto que se tornou poss\u00edvel at\u00e9 passar a entrega para os desenvolvedores \u2014 o que h\u00e1 naquele deployment.yaml? A containeriza\u00e7\u00e3o resolve o problema. E a maturidade dos sistemas de CI\/CD j\u00e1 est\u00e1 num n\u00edvel onde voc\u00ea escreve um arquivo e tudo come\u00e7a a funcionar \u2014 os desenvolvedores conseguem sozinhos. E aqui come\u00e7amos a falar sobre como criar nosso SRE, com... bem, com qualquer um. <\/p>\n

SRE n\u00e3o \u00e9 s\u00f3 no Google<\/h4>\n

\nBem, entregamos a tarefa, parece que podemos respirar aliviados, voltar aos velhos tempos em que os administradores monitoravam a carga dos processadores, ajustavam sistemas e sorviam algo indefinido de canecas em sil\u00eancio e tranquilidade... Espera. N\u00e3o foi por isso que tudo come\u00e7ou (e que pena!). De repente, percebemos que na abordagem do Google podemos adotar boas pr\u00e1ticas \u2014 n\u00e3o \u00e9 a carga dos processadores que importa, nem a frequ\u00eancia com que trocamos os discos, ou a otimiza\u00e7\u00e3o de custos na nuvem, mas sim as m\u00e9tricas de neg\u00f3cios \u2014 todos aqueles already notorious SLx. E a gest\u00e3o da infraestrutura n\u00e3o foi retirada deles, h\u00e1 incidentes a serem resolvidos, \u00e9 necess\u00e1rio estar de plant\u00e3o periodicamente e, de modo geral, estar por dentro dos processos de neg\u00f3cios. E pessoal, comecem a programar um pouco melhor, o Google j\u00e1 est\u00e1 esperando por voc\u00eas.<\/p>\n

Resumindo. De repente, mas voc\u00ea j\u00e1 est\u00e1 cansado de ler e mal pode esperar para comentar sobre o autor do artigo. DevOps, como pr\u00e1tica de entrega, existiu, existe e sempre haver\u00e1. E n\u00e3o vai a lugar nenhum. O SRE, como um conjunto de pr\u00e1ticas de opera\u00e7\u00e3o, torna essa entrega bem-sucedida.
\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\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\udd47Mais uma vez sobre DevOps e SRE | ProHoster","description":"Com base na discuss\u00e3o no chat da AWS Minsk Community, recentemente t\u00eam ocorrido verdadeiras batalhas sobre a defini\u00e7\u00e3o do conceito.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/55735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=55735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/55735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/55736"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=55735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=55735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=55735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}