Neste artigo, procuramos demonstrar as respostas apropriadas para as seguintes perguntas: Qual voc\u00ea deve escolher entre SRE e DevOps? SRE \u00e9 aplic\u00e1vel apenas a ambientes de nuvem? Qual \u00e9 exatamente a fun\u00e7\u00e3o da equipe DevOps? SRE e DevOps s\u00e3o compat\u00edveis entre si? SRE exige codifica\u00e7\u00e3o? \u00c9 uma boa ideia seguir carreira em DevOps? As respostas para todas essas perguntas podem ser encontradas nesta p\u00e1gina.<\/p>\n
Quando se trata de desenvolvimento, lan\u00e7amento e produ\u00e7\u00e3o de software, as empresas podem escolher entre SRE e DevOps. No entanto, uma an\u00e1lise abrangente das diferen\u00e7as e similaridades entre esses dois m\u00e9todos pode ajudar as empresas a selecionar a estrat\u00e9gia mais apropriada.<\/p>\n
“DevOps” \u00e9 uma pr\u00e1tica que une desenvolvimento e opera\u00e7\u00f5es. O objetivo do DevOps \u00e9 garantir que a mesma equipe respons\u00e1vel pelo desenvolvimento tamb\u00e9m seja respons\u00e1vel pela manuten\u00e7\u00e3o do c\u00f3digo em produ\u00e7\u00e3o.<\/p>\n
A entrega cont\u00ednua permite que os desenvolvedores avaliem as atualiza\u00e7\u00f5es do aplicativo antes de entregar o software. Al\u00e9m da entrega cont\u00ednua, DevOps abrange o desenvolvimento de software, o lan\u00e7amento de novas vers\u00f5es, o teste e a integra\u00e7\u00e3o dessas novas vers\u00f5es, o gerenciamento de configura\u00e7\u00e3o e o monitoramento em tempo real.<\/p>\n
SRE significa “Site Reliability Engineering” (Engenharia de Confiabilidade de Sites). A Engenharia de Confiabilidade de Software (SRE) \u00e9 uma parceria entre a engenharia de software e as opera\u00e7\u00f5es de sistema. Um dos objetivos da SRE \u00e9 detectar e tomar medidas preventivas contra problemas que possam resultar em tempo de inatividade.<\/p>\n
A Engenharia de Confiabilidade de Sistema \u00e9 uma am\u00e1lgama de opera\u00e7\u00f5es de sistema e engenharia de software.<\/p>\n
A Engenharia de Confiabilidade de Software (SRE) preocupa-se com aspectos do desenvolvimento de software como velocidade, qualidade, design, agilidade e inova\u00e7\u00e3o. Al\u00e9m disso, a SRE \u00e9 respons\u00e1vel pelas necessidades operacionais, como capacidade de manuten\u00e7\u00e3o, disponibilidade e desempenho.<\/p>\n
SRE vs. DevOps \u2013 Uma Compara\u00e7\u00e3o Organizacional<\/strong><\/p>\n Na maioria das empresas, muitos departamentos trabalham no mesmo produto. No entanto, o produto s\u00f3 pode ter sucesso se esses departamentos cooperarem.<\/p>\n As diferen\u00e7as que podem surgir entre os membros da equipe podem ser resolvidas com a ajuda do DevOps, que aproxima todos sob um objetivo unificado. O objetivo da metodologia DevOps \u00e9 facilitar o gerenciamento eficiente de recursos em todos os departamentos de uma organiza\u00e7\u00e3o.<\/p>\n Os SREs, por outro lado, n\u00e3o atacam diretamente os silos, mas sim incentivam a discuss\u00e3o entre todos. Por causa disso, a propriedade de um produto \u00e9 distribu\u00edda igualmente entre todos os funcion\u00e1rios da organiza\u00e7\u00e3o que trabalham nele.<\/p>\n SRE vs. DevOps: Falhas de Teste<\/strong><\/p>\n As empresas sabem que, se o software n\u00e3o for constantemente testado, ele eventualmente falhar\u00e1 em algum momento. DevOps emprega testes automatizados para descobrir problemas e minimizar riscos. DevOps garante que as equipes n\u00e3o cometam os mesmos erros ao realizar essa pr\u00e1tica.<\/p>\n A falha \u00e9 investigada usando duas abordagens diferentes pelos SREs, a saber, indicadores de n\u00edvel de servi\u00e7o (SLIs) e objetivos de n\u00edvel de servi\u00e7o (SLOs). Os SLOs representam a porcentagem de sucesso dos SLIs, que quantifica o n\u00famero de falhas que ocorrem por solicita\u00e7\u00e3o ao longo do tempo.<\/p>\n Medi\u00e7\u00e3o do Progresso entre SRE e DevOps<\/strong><\/p>\n A efic\u00e1cia do DevOps \u00e9 avaliada usando estas quatro m\u00e9tricas. Esses fatores incluem o n\u00famero de implanta\u00e7\u00f5es, o tempo necess\u00e1rio para restaurar o servi\u00e7o, o tempo necess\u00e1rio para se preparar para as mudan\u00e7as e a porcentagem de modifica\u00e7\u00f5es bem-sucedidas.<\/p>\n Os SREs monitoram o progresso observando quatro sinais: tr\u00e1fego, lat\u00eancia, satura\u00e7\u00e3o e erros. Ao medir, os desenvolvedores devem levar em considera\u00e7\u00e3o os padr\u00f5es existentes que correspondem a cada estat\u00edstica.<\/p>\n Organiza\u00e7\u00e3o da Equipe em Termos de SRE vs. DevOps<\/strong><\/p>\n Engenheiros de confiabilidade de sites com experi\u00eancia anterior em desenvolvimento de software e opera\u00e7\u00f5es s\u00e3o a espinha dorsal das equipes de SRE.<\/p>\n Muitas fun\u00e7\u00f5es diferentes podem ser preenchidas dentro de uma equipe DevOps. Alguns exemplos dessas fun\u00e7\u00f5es incluem analistas de qualidade, desenvolvedores de software, gerentes de lan\u00e7amento, administradores de sistema, propriet\u00e1rios de produtos e engenheiros de confiabilidade de sistema.<\/p>\n SRE versus DevOps: Ferramentas<\/strong><\/p>\n Cont\u00eaineres, microsservi\u00e7os, integra\u00e7\u00e3o e entrega cont\u00ednuas, infraestrutura como c\u00f3digo, testes de resili\u00eancia e sistemas de monitoramento s\u00e3o algumas das tecnologias que DevOps e SREs compartilham. Outras ferramentas incluem testes de resili\u00eancia.<\/p>\n SRE versus DevOps: Foco<\/strong><\/p>\n O objetivo principal da SRE \u00e9 desenvolver aplica\u00e7\u00f5es que sejam altamente confi\u00e1veis e muito escal\u00e1veis. Portanto, as tarefas de um SRE concentram-se principalmente em garantir e manter a confiabilidade da aplica\u00e7\u00e3o, em vez de fazer modifica\u00e7\u00f5es frequentes.<\/p>\n DevOps, por outro lado, preocupa-se principalmente em criar ambientes de produ\u00e7\u00e3o nos quais os desenvolvedores tenham maior controle. O objetivo do DevOps \u00e9 implementar pipelines de CI\/CD em todas as fases do produto para facilitar o desenvolvimento \u00e1gil.<\/p>\n SRE vs. DevOps: Diferen\u00e7as na Forma Como a Mudan\u00e7a \u00c9 Implementada<\/strong><\/p>\n Em vez de lan\u00e7ar atualiza\u00e7\u00f5es em grande escala de uma vez para o aplicativo de software, o DevOps faz ajustes incrementais no produto ao longo do tempo. Quando isso \u00e9 feito, h\u00e1 menos inst\u00e2ncias de problemas em aplicativos DevOps, e eles t\u00eam um gerenciamento de revis\u00e3o superior.<\/p>\n Os SREs revertem as altera\u00e7\u00f5es de forma r\u00e1pida e frequente para garantir que o produto esteja livre de erros. Os SREs avaliam as atualiza\u00e7\u00f5es usando lan\u00e7amentos canary antes de colocar as altera\u00e7\u00f5es em produ\u00e7\u00e3o. Al\u00e9m disso, o SRE deve encontrar um equil\u00edbrio entre a confiabilidade e a frequ\u00eancia das atualiza\u00e7\u00f5es.<\/p>\n A Automa\u00e7\u00e3o \u00e9 um Diferenciador Chave entre SRE e DevOps.<\/strong><\/p>\n A SRE visa eliminar tarefas ma\u00e7antes, determinando quais atividades ocupam mais de cinquenta por cento do tempo de um engenheiro e, em seguida, eliminando essas atividades. Al\u00e9m disso, os SREs s\u00e3o respons\u00e1veis por preparar c\u00f3digos espec\u00edficos para uma variedade de processos e, em seguida, adicionar esses c\u00f3digos a um playbook.<\/p>\n As estrat\u00e9gias automatizadas do DevOps permitem a cria\u00e7\u00e3o de loops de feedback entre as equipes de desenvolvimento e opera\u00e7\u00f5es. O objetivo da automa\u00e7\u00e3o que o DevOps emprega \u00e9 acelerar o processo de envio de altera\u00e7\u00f5es incrementais para aplicativos que j\u00e1 est\u00e3o em execu\u00e7\u00e3o.<\/p>\n O Google desenvolveu o modelo SRE com o objetivo de simplificar para os desenvolvedores a concentra\u00e7\u00e3o na velocidade com que novos recursos est\u00e3o sendo adicionados e na inventividade desses recursos, ao mesmo tempo em que permite que os operadores de sistema se concentrem em manter a consist\u00eancia e a estabilidade.<\/p>\n O conceito \u00e9 adapt\u00e1vel a qualquer organiza\u00e7\u00e3o e, nos \u00faltimos anos, houve um aumento percept\u00edvel no interesse em us\u00e1-lo. As empresas que implementaram o modelo SRE t\u00eam anedotas fascinantes que t\u00eam muitos pontos em comum, girando em torno das vantagens do SRE e como elas transformaram essas pr\u00e1ticas em um impacto tang\u00edvel e ben\u00e9fico em seus neg\u00f3cios.<\/p>\n Quando visto atrav\u00e9s das lentes de uma equipe de engenharia, as vantagens do SRE s\u00e3o prontamente aparentes desde o in\u00edcio. Historicamente, o foco principal das equipes de engenharia tem sido o desenvolvimento de aplicativos e a capacidade de fornecer novos recursos o mais r\u00e1pido poss\u00edvel.<\/p>\n Evidentemente, um grupo contempor\u00e2neo e experiente sabe que este \u00e9 apenas um componente da equa\u00e7\u00e3o. Entre outras atividades, a aloca\u00e7\u00e3o de tempo e esfor\u00e7o para o desenvolvimento de t\u00e9cnicas de teste, processos para integra\u00e7\u00e3o e implanta\u00e7\u00e3o cont\u00ednuas e automa\u00e7\u00e3o de nuvem contribuem para a sa\u00fade de um sistema de software.<\/p>\n A abordagem de engenharia de confiabilidade de software (SRE) fornece \u00e0s equipes princ\u00edpios de engenharia de software que podem ser aplicados \u00e0s suas opera\u00e7\u00f5es de TI. Isso ajuda as equipes a elevar o n\u00edvel de excel\u00eancia operacional. Por causa desses princ\u00edpios, elas poderiam fazer melhorias em v\u00e1rias \u00e1reas, incluindo capacidade, desempenho, disponibilidade e lat\u00eancia. As pr\u00e1ticas de SRE s\u00e3o uma disciplina que se concentra em diminuir e, eventualmente, simplificar o processo de opera\u00e7\u00e3o e manuten\u00e7\u00e3o de solu\u00e7\u00f5es de software.<\/p>\n Essas pr\u00e1ticas podem abranger uma variedade de facetas que est\u00e3o presentes em todo o ciclo de vida do software. Em vez de evitar altera\u00e7\u00f5es em sua solu\u00e7\u00e3o de software, uma equipe que adota com sucesso as pr\u00e1ticas de SRE mudar\u00e1 sua carga de trabalho operacional para as tarefas di\u00e1rias de desenvolvimento, abra\u00e7ando as complexidades de engenharia que v\u00eam com a escala e os novos recursos. Essa mudan\u00e7a ocorrer\u00e1 devido \u00e0 decis\u00e3o da equipe de n\u00e3o evitar altera\u00e7\u00f5es em sua solu\u00e7\u00e3o de software.<\/p>\n Vis\u00e3o de Engenharia Unificada e Coordena\u00e7\u00e3o entre as V\u00e1rias Equipes<\/strong><\/p>\n A abordagem de engenharia de confiabilidade de software (SRE), quando aplicada a v\u00e1rias equipes de engenharia de software, fornece uma vis\u00e3o de engenharia coesa para a empresa. Essa vis\u00e3o de engenharia unificada incentiva a coopera\u00e7\u00e3o, o compartilhamento de informa\u00e7\u00f5es e uma linguagem consistente entre as diversas equipes. Ao contr\u00e1rio da introdu\u00e7\u00e3o de uma nova biblioteca de software ou de uma ferramenta de implanta\u00e7\u00e3o, a ado\u00e7\u00e3o eficaz do SRE n\u00e3o \u00e9 apenas responsabilidade da equipe de engenharia de software. A empresa e outras partes interessadas n\u00e3o tecnicamente orientadas impactam significativamente a capacidade de habilitar e cultivar uma cultura na qual a atitude SRE pode florescer. Com uma conversa entre todas as partes interessadas sobre o que a confiabilidade significa para a empresa, \u00e9 essencial estabelecer uma cultura na qual as equipes de engenharia se sintam psicologicamente seguras para falhar e possam aprender com seus erros.<\/p>\n Uma conversa entre as partes interessadas de neg\u00f3cios e t\u00e9cnicas \u00e9 a \u00fanica maneira de construir o alinhamento essencial para definir os v\u00e1rios n\u00edveis de servi\u00e7o, uma no\u00e7\u00e3o central no SRE, e compreender o esfor\u00e7o e o impacto nos neg\u00f3cios conectados a cada n\u00edvel.<\/p>\n Conceitos Cruciais para o N\u00edvel de Servi\u00e7o SRE<\/strong><\/p>\n Os seguintes s\u00e3o os principais conceitos de n\u00edvel de servi\u00e7o SRE:<\/p>\n Os conceitos de n\u00edveis de servi\u00e7o SRE e os valores de confiabilidade e or\u00e7amento de erros associados s\u00e3o extremamente \u00fateis para estabelecer essa linguagem comum em toda a organiza\u00e7\u00e3o. Isso cria um entendimento compartilhado entre empresas, desenvolvedores e engenheiros SRE sobre a defini\u00e7\u00e3o de expectativas e responsabilidades. Mesmo sendo f\u00e1ceis de entender, os conceitos de n\u00edvel de servi\u00e7o SRE e os valores de confiabilidade e or\u00e7amento de erros associados s\u00e3o ben\u00e9ficos. Igualmente crucial, estabelecer uma meta de 100% de confiabilidade \u00e9 tanto rom\u00e2ntico quanto incorreto, pois impede a equipe de inovar, impede a equipe de aprender com seus erros e retarda a taxa de lan\u00e7amento de novos recursos.<\/p>\n A Pr\u00f3pria Empresa como Fonte de Cria\u00e7\u00e3o de Valor<\/strong><\/p>\n O paradigma SRE provocou uma mudan\u00e7a fundamental na forma como os executivos de alto n\u00edvel nas empresas pensam sobre as responsabilidades operacionais e as pr\u00e1ticas de engenharia de software. No passado, as partes interessadas do neg\u00f3cio consideravam apenas a cria\u00e7\u00e3o de novos recursos de engenharia de software algo que valia a pena. Por outro lado, as opera\u00e7\u00f5es de TI subjacentes e outras atividades eram vistas como despesas irritantes. L\u00edderes organizacionais esclarecidos no desenvolvimento de software moderno de hoje entendem que mais \u00e9 necess\u00e1rio para valorizar o desenvolvimento e o ajuste fino de um \u00f3timo motor se ele for colocado em um chassi velho e enferrujado.<\/p>\n Eles est\u00e3o cientes desse fato porque mais \u00e9 necess\u00e1rio para valorizar o desenvolvimento de um \u00f3timo motor. Portanto, \u00e9 necess\u00e1rio considerar e atribuir um valor apropriado a toda a solu\u00e7\u00e3o de software nas v\u00e1rias etapas de seu ciclo de vida. Esse valor foi melhor compreendido ap\u00f3s a ado\u00e7\u00e3o de uma perspectiva SRE e a consequente mudan\u00e7a de cultura e vantagens. Por exemplo, a capacidade do aplicativo de escalar para atender a demandas inesperadas de tr\u00e1fego em ocasi\u00f5es especiais (como a Black Friday) tem menos a ver com a l\u00f3gica de neg\u00f3cios do aplicativo e mais com a forma como as opera\u00e7\u00f5es do sistema s\u00e3o tratadas e gerenciadas. A escalabilidade \u00e9 a capacidade de uma solu\u00e7\u00e3o de software de atender a demandas inesperadas de tr\u00e1fego.<\/p>\n Outros exemplos, como otimiza\u00e7\u00e3o de custos na nuvem ou ter estrat\u00e9gias adequadas de backup e recupera\u00e7\u00e3o de desastres, que simultaneamente reduzem custos e riscos ao mesmo tempo em que aumentam a excel\u00eancia operacional, provaram que as opera\u00e7\u00f5es s\u00e3o (e devem ser tratadas como) um centro vital de cria\u00e7\u00e3o de valor.<\/p>\n Os engenheiros de confiabilidade de sites s\u00e3o respons\u00e1veis por impulsionar continuamente as melhorias estruturais e possuem uma rara combina\u00e7\u00e3o de talentos que s\u00e3o dif\u00edceis de encontrar: um conhecimento profundo da tecnologia e um foco nas necessidades dos clientes. Portanto, tentar economizar despesas para uma equipe SRE reduzindo o n\u00famero de trabalhadores ou terceirizando-a \u00e9 frequentemente uma m\u00e1 decis\u00e3o. \u00c9 essencial ter uma compreens\u00e3o firme do fato de que nem todas as solu\u00e7\u00f5es de software exigem uma equipe SRE especializada ou responsabilidades.<\/p>\n Mesmo no Google, a participa\u00e7\u00e3o em equipes SRE \u00e9 volunt\u00e1ria. Se o escopo da solu\u00e7\u00e3o ou o est\u00e1gio de maturidade do projeto n\u00e3o exigirem esse grau de assist\u00eancia, o trabalho que precisa ser feito para SRE pode ser de propriedade e impulsionado pela equipe de desenvolvimento. Apesar disso, \u00e9 essencial ter em mente que a atitude e as pr\u00e1ticas SRE ainda precisam ser realizadas, e essa cultura deve ser cultivada.<\/p>\n SRE e DevOps s\u00e3o a mesma coisa vistas de diferentes perspectivas.<\/p>\n SRE (Site Reliability Engineering) e DevOps (Development Operations) s\u00e3o ferramentas que as empresas podem usar para melhorar a comunica\u00e7\u00e3o entre suas equipes de desenvolvimento de software e opera\u00e7\u00f5es. No entanto, as empresas devem considerar o uso de DevOps se quiserem acelerar o processo de lan\u00e7amento de seu produto no mercado e incorporar atualiza\u00e7\u00f5es enquanto a produ\u00e7\u00e3o est\u00e1 em andamento. Por outro lado, as empresas que desejam automa\u00e7\u00e3o de trabalho em larga escala devem usar SREs como sua solu\u00e7\u00e3o.<\/p>\n Experimente a Prometteur Solutions se precisar contratar algu\u00e9m com experi\u00eancia em DevOps ou engenharia de confiabilidade de sites.<\/p>\n A Prometteur Solutions permite que as empresas contratem engenheiros pr\u00e9-selecionados com qualidade do Silicon Valley em apenas tr\u00eas a cinco dias \u00fateis. De um grupo de desenvolvedores totalizando 2 milh\u00f5es.<\/p>\n O que \u00e9 \u201cDevOps\u201d?<\/strong> DevOps \u00e9 uma pr\u00e1tica que une desenvolvimento e opera\u00e7\u00f5es.<\/p>\n O que \u00e9 SRE?<\/strong> SRE significa “Site Reliability Engineering” (Engenharia de Confiabilidade de Sites). A Engenharia de Confiabilidade de Software (SRE) \u00e9 uma parceria entre a engenharia de software e as opera\u00e7\u00f5es de sistema.<\/p>\n 1. SRE precisa de codifica\u00e7\u00e3o?<\/strong> Sim, a codifica\u00e7\u00e3o \u00e9 necess\u00e1ria para os SREs. Engenheiros especializados em confiabilidade de sites trabalham para encontrar maneiras de tornar os sistemas mais confi\u00e1veis. Para atingir esse objetivo, ocasionalmente \u00e9 essencial entrar no c\u00f3digo-fonte de um sistema, identificar o problema e, frequentemente, fornecer um patch de volta \u00e0 base de c\u00f3digo.<\/p>\n 2. Uma carreira em DevOps \u00e9 uma escolha inteligente?<\/strong> Nos \u00faltimos cinco anos, houve um aumento de 40 a 50% na demanda por DevOps.<\/p>\n 3. Qual linguagem de programa\u00e7\u00e3o \u00e9 ideal para uso em ambientes DevOps?<\/strong> Python \u00e9 a linguagem mais popular para DevOps devido ao grande n\u00famero de m\u00f3dulos de biblioteca que podem realizar responsabilidades comuns. As linguagens usadas para programa\u00e7\u00e3o est\u00e3o no centro do processo de desenvolvimento para sistemas DevOps. Como resultado, as pessoas que trabalham em DevOps precisam conhecer as linguagens de programa\u00e7\u00e3o apropriadas que podem ser usadas nesses tipos de sistemas.<\/p>\n","protected":false},"excerpt":{"rendered":" Qual a Diferen\u00e7a Entre SRE e DevOps? Neste artigo, procuramos demonstrar as respostas apropriadas para as seguintes perguntas: Qual voc\u00ea deve escolher entre SRE e DevOps? SRE \u00e9 aplic\u00e1vel apenas a ambientes de nuvem? Qual \u00e9 exatamente a fun\u00e7\u00e3o da equipe DevOps? SRE e DevOps s\u00e3o compat\u00edveis entre si? SRE exige codifica\u00e7\u00e3o? \u00c9 uma boa […]<\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","om_disable_all_campaigns":false,"footnotes":""},"categories":[1167],"tags":[],"class_list":{"0":"post-12959","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-uncategorized-pt"},"yoast_head":"\nQuais S\u00e3o as Vantagens de Usar SRE?<\/h3>\n
\n
Resumo<\/h3>\n
\nPerguntas Frequentes (FAQs)<\/h3>\n