Qual a Diferença Entre SRE e DevOps?
Neste artigo, procuramos demonstrar as respostas apropriadas para as seguintes perguntas: Qual você deve escolher entre SRE e DevOps? SRE é aplicável apenas a ambientes de nuvem? Qual é exatamente a função da equipe DevOps? SRE e DevOps são compatíveis entre si? SRE exige codificação? É uma boa ideia seguir carreira em DevOps? As respostas para todas essas perguntas podem ser encontradas nesta página.
Quando se trata de desenvolvimento, lançamento e produção de software, as empresas podem escolher entre SRE e DevOps. No entanto, uma análise abrangente das diferenças e similaridades entre esses dois métodos pode ajudar as empresas a selecionar a estratégia mais apropriada.
O Que É “DevOps”?
“DevOps” é uma prática que une desenvolvimento e operações. O objetivo do DevOps é garantir que a mesma equipe responsável pelo desenvolvimento também seja responsável pela manutenção do código em produção.
A entrega contínua permite que os desenvolvedores avaliem as atualizações do aplicativo antes de entregar o software. Além da entrega contínua, DevOps abrange o desenvolvimento de software, o lançamento de novas versões, o teste e a integração dessas novas versões, o gerenciamento de configuração e o monitoramento em tempo real.
O Que É SRE?
SRE significa “Site Reliability Engineering” (Engenharia de Confiabilidade de Sites). A Engenharia de Confiabilidade de Software (SRE) é uma parceria entre a engenharia de software e as operações de sistema. Um dos objetivos da SRE é detectar e tomar medidas preventivas contra problemas que possam resultar em tempo de inatividade.
Comparado ao DevOps, o que é exatamente SRE?
A Engenharia de Confiabilidade de Sistema é uma amálgama de operações de sistema e engenharia de software.
A Engenharia de Confiabilidade de Software (SRE) preocupa-se com aspectos do desenvolvimento de software como velocidade, qualidade, design, agilidade e inovação. Além disso, a SRE é responsável pelas necessidades operacionais, como capacidade de manutenção, disponibilidade e desempenho.
Qual a Diferença Entre SRE e DevOps, Comparando-os?
SRE vs. DevOps – Uma Comparação Organizacional
Na maioria das empresas, muitos departamentos trabalham no mesmo produto. No entanto, o produto só pode ter sucesso se esses departamentos cooperarem.
As diferenças 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 é facilitar o gerenciamento eficiente de recursos em todos os departamentos de uma organização.
Os SREs, por outro lado, não atacam diretamente os silos, mas sim incentivam a discussão entre todos. Por causa disso, a propriedade de um produto é distribuída igualmente entre todos os funcionários da organização que trabalham nele.
SRE vs. DevOps: Falhas de Teste
As empresas sabem que, se o software não for constantemente testado, ele eventualmente falhará em algum momento. DevOps emprega testes automatizados para descobrir problemas e minimizar riscos. DevOps garante que as equipes não cometam os mesmos erros ao realizar essa prática.
A falha é investigada usando duas abordagens diferentes pelos SREs, a saber, indicadores de nível de serviço (SLIs) e objetivos de nível de serviço (SLOs). Os SLOs representam a porcentagem de sucesso dos SLIs, que quantifica o número de falhas que ocorrem por solicitação ao longo do tempo.
Medição do Progresso entre SRE e DevOps
A eficácia do DevOps é avaliada usando estas quatro métricas. Esses fatores incluem o número de implantações, o tempo necessário para restaurar o serviço, o tempo necessário para se preparar para as mudanças e a porcentagem de modificações bem-sucedidas.
Os SREs monitoram o progresso observando quatro sinais: tráfego, latência, saturação e erros. Ao medir, os desenvolvedores devem levar em consideração os padrões existentes que correspondem a cada estatística.
Organização da Equipe em Termos de SRE vs. DevOps
Engenheiros de confiabilidade de sites com experiência anterior em desenvolvimento de software e operações são a espinha dorsal das equipes de SRE.
Muitas funções diferentes podem ser preenchidas dentro de uma equipe DevOps. Alguns exemplos dessas funções incluem analistas de qualidade, desenvolvedores de software, gerentes de lançamento, administradores de sistema, proprietários de produtos e engenheiros de confiabilidade de sistema.
SRE versus DevOps: Ferramentas
Contêineres, microsserviços, integração e entrega contínuas, infraestrutura como código, testes de resiliência e sistemas de monitoramento são algumas das tecnologias que DevOps e SREs compartilham. Outras ferramentas incluem testes de resiliência.
SRE versus DevOps: Foco
O objetivo principal da SRE é desenvolver aplicações que sejam altamente confiáveis e muito escaláveis. Portanto, as tarefas de um SRE concentram-se principalmente em garantir e manter a confiabilidade da aplicação, em vez de fazer modificações frequentes.
DevOps, por outro lado, preocupa-se principalmente em criar ambientes de produção nos quais os desenvolvedores tenham maior controle. O objetivo do DevOps é implementar pipelines de CI/CD em todas as fases do produto para facilitar o desenvolvimento ágil.
SRE vs. DevOps: Diferenças na Forma Como a Mudança É Implementada
Em vez de lançar atualizações em grande escala de uma vez para o aplicativo de software, o DevOps faz ajustes incrementais no produto ao longo do tempo. Quando isso é feito, há menos instâncias de problemas em aplicativos DevOps, e eles têm um gerenciamento de revisão superior.
Os SREs revertem as alterações de forma rápida e frequente para garantir que o produto esteja livre de erros. Os SREs avaliam as atualizações usando lançamentos canary antes de colocar as alterações em produção. Além disso, o SRE deve encontrar um equilíbrio entre a confiabilidade e a frequência das atualizações.
A Automação é um Diferenciador Chave entre SRE e DevOps.
A SRE visa eliminar tarefas maçantes, determinando quais atividades ocupam mais de cinquenta por cento do tempo de um engenheiro e, em seguida, eliminando essas atividades. Além disso, os SREs são responsáveis por preparar códigos específicos para uma variedade de processos e, em seguida, adicionar esses códigos a um playbook.
As estratégias automatizadas do DevOps permitem a criação de loops de feedback entre as equipes de desenvolvimento e operações. O objetivo da automação que o DevOps emprega é acelerar o processo de envio de alterações incrementais para aplicativos que já estão em execução.
Quais São as Vantagens de Usar SRE?
O Google desenvolveu o modelo SRE com o objetivo de simplificar para os desenvolvedores a concentração na velocidade com que novos recursos estão sendo adicionados e na inventividade desses recursos, ao mesmo tempo em que permite que os operadores de sistema se concentrem em manter a consistência e a estabilidade.
O conceito é adaptável a qualquer organização e, nos últimos anos, houve um aumento perceptível no interesse em usá-lo. As empresas que implementaram o modelo SRE têm anedotas fascinantes que têm muitos pontos em comum, girando em torno das vantagens do SRE e como elas transformaram essas práticas em um impacto tangível e benéfico em seus negócios.
Quando visto através das lentes de uma equipe de engenharia, as vantagens do SRE são prontamente aparentes desde o início. Historicamente, o foco principal das equipes de engenharia tem sido o desenvolvimento de aplicativos e a capacidade de fornecer novos recursos o mais rápido possível.
Evidentemente, um grupo contemporâneo e experiente sabe que este é apenas um componente da equação. Entre outras atividades, a alocação de tempo e esforço para o desenvolvimento de técnicas de teste, processos para integração e implantação contínuas e automação de nuvem contribuem para a saúde de um sistema de software.
A abordagem de engenharia de confiabilidade de software (SRE) fornece às equipes princípios de engenharia de software que podem ser aplicados às suas operações de TI. Isso ajuda as equipes a elevar o nível de excelência operacional. Por causa desses princípios, elas poderiam fazer melhorias em várias áreas, incluindo capacidade, desempenho, disponibilidade e latência. As práticas de SRE são uma disciplina que se concentra em diminuir e, eventualmente, simplificar o processo de operação e manutenção de soluções de software.
Essas práticas podem abranger uma variedade de facetas que estão presentes em todo o ciclo de vida do software. Em vez de evitar alterações em sua solução de software, uma equipe que adota com sucesso as práticas de SRE mudará sua carga de trabalho operacional para as tarefas diárias de desenvolvimento, abraçando as complexidades de engenharia que vêm com a escala e os novos recursos. Essa mudança ocorrerá devido à decisão da equipe de não evitar alterações em sua solução de software.
Visão de Engenharia Unificada e Coordenação entre as Várias Equipes
A abordagem de engenharia de confiabilidade de software (SRE), quando aplicada a várias equipes de engenharia de software, fornece uma visão de engenharia coesa para a empresa. Essa visão de engenharia unificada incentiva a cooperação, o compartilhamento de informações e uma linguagem consistente entre as diversas equipes. Ao contrário da introdução de uma nova biblioteca de software ou de uma ferramenta de implantação, a adoção eficaz do SRE não é apenas responsabilidade da equipe de engenharia de software. A empresa e outras partes interessadas não 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, é essencial estabelecer uma cultura na qual as equipes de engenharia se sintam psicologicamente seguras para falhar e possam aprender com seus erros.
Uma conversa entre as partes interessadas de negócios e técnicas é a única maneira de construir o alinhamento essencial para definir os vários níveis de serviço, uma noção central no SRE, e compreender o esforço e o impacto nos negócios conectados a cada nível.
Conceitos Cruciais para o Nível de Serviço SRE
Os seguintes são os principais conceitos de nível de serviço SRE:
- Indicadores de Nível de Serviço (SLIs), abreviados como SLIs, são uma ou mais métricas de confiabilidade quantitativas da solução de software vistas do ponto de vista de seus clientes. Em um sistema baseado na web, alguns exemplos úteis são os códigos de status HTTP e a latência total de ponta a ponta.
- Objetivos de Nível de Serviço (SLOs), frequentemente conhecidos como SLOs, são um ou mais objetivos que um determinado SLI deve atender dentro de um período predeterminado. No contexto de uma solução web, isso pode significar buscar um máximo de 1% de HTTP 5xx (erro de servidor) por mês ou atingir uma latência de menos de 200 milissegundos para cada solicitação HTTP por dia.
- Para calcular a confiabilidade, divida o número de ações bem-sucedidas (ou seja, o número de vezes que funcionou corretamente) pelo número total de ações. Isso lhe dará o valor da confiabilidade.
- A quantidade de falta de confiabilidade que as várias partes interessadas estão prontas para suportar é chamada de orçamento de erros. Em poucas palavras, pode ser determinado subtraindo o valor de confiabilidade de 100% do total.
Os conceitos de níveis de serviço SRE e os valores de confiabilidade e orçamento de erros associados são extremamente úteis para estabelecer essa linguagem comum em toda a organização. Isso cria um entendimento compartilhado entre empresas, desenvolvedores e engenheiros SRE sobre a definição de expectativas e responsabilidades. Mesmo sendo fáceis de entender, os conceitos de nível de serviço SRE e os valores de confiabilidade e orçamento de erros associados são benéficos. Igualmente crucial, estabelecer uma meta de 100% de confiabilidade é tanto romântico quanto incorreto, pois impede a equipe de inovar, impede a equipe de aprender com seus erros e retarda a taxa de lançamento de novos recursos.
A Própria Empresa como Fonte de Criação de Valor
O paradigma SRE provocou uma mudança fundamental na forma como os executivos de alto nível nas empresas pensam sobre as responsabilidades operacionais e as práticas de engenharia de software. No passado, as partes interessadas do negócio consideravam apenas a criação de novos recursos de engenharia de software algo que valia a pena. Por outro lado, as operações de TI subjacentes e outras atividades eram vistas como despesas irritantes. Líderes organizacionais esclarecidos no desenvolvimento de software moderno de hoje entendem que mais é necessário para valorizar o desenvolvimento e o ajuste fino de um ótimo motor se ele for colocado em um chassi velho e enferrujado.
Eles estão cientes desse fato porque mais é necessário para valorizar o desenvolvimento de um ótimo motor. Portanto, é necessário considerar e atribuir um valor apropriado a toda a solução de software nas várias etapas de seu ciclo de vida. Esse valor foi melhor compreendido após a adoção de uma perspectiva SRE e a consequente mudança de cultura e vantagens. Por exemplo, a capacidade do aplicativo de escalar para atender a demandas inesperadas de tráfego em ocasiões especiais (como a Black Friday) tem menos a ver com a lógica de negócios do aplicativo e mais com a forma como as operações do sistema são tratadas e gerenciadas. A escalabilidade é a capacidade de uma solução de software de atender a demandas inesperadas de tráfego.
Outros exemplos, como otimização de custos na nuvem ou ter estratégias adequadas de backup e recuperação de desastres, que simultaneamente reduzem custos e riscos ao mesmo tempo em que aumentam a excelência operacional, provaram que as operações são (e devem ser tratadas como) um centro vital de criação de valor.
Os engenheiros de confiabilidade de sites são responsáveis por impulsionar continuamente as melhorias estruturais e possuem uma rara combinação de talentos que são difíceis 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úmero de trabalhadores ou terceirizando-a é frequentemente uma má decisão. É essencial ter uma compreensão firme do fato de que nem todas as soluções de software exigem uma equipe SRE especializada ou responsabilidades.
Mesmo no Google, a participação em equipes SRE é voluntária. Se o escopo da solução ou o estágio de maturidade do projeto não exigirem esse grau de assistência, o trabalho que precisa ser feito para SRE pode ser de propriedade e impulsionado pela equipe de desenvolvimento. Apesar disso, é essencial ter em mente que a atitude e as práticas SRE ainda precisam ser realizadas, e essa cultura deve ser cultivada.
Resumo
SRE e DevOps são a mesma coisa vistas de diferentes perspectivas.
SRE (Site Reliability Engineering) e DevOps (Development Operations) são ferramentas que as empresas podem usar para melhorar a comunicação entre suas equipes de desenvolvimento de software e operações. No entanto, as empresas devem considerar o uso de DevOps se quiserem acelerar o processo de lançamento de seu produto no mercado e incorporar atualizações enquanto a produção está em andamento. Por outro lado, as empresas que desejam automação de trabalho em larga escala devem usar SREs como sua solução.
Experimente a Prometteur Solutions se precisar contratar alguém com experiência em DevOps ou engenharia de confiabilidade de sites.
A Prometteur Solutions permite que as empresas contratem engenheiros pré-selecionados com qualidade do Silicon Valley em apenas três a cinco dias úteis. De um grupo de desenvolvedores totalizando 2 milhões.
Perguntas Frequentes (FAQs)
O que é “DevOps”? DevOps é uma prática que une desenvolvimento e operações.
O que é SRE? SRE significa “Site Reliability Engineering” (Engenharia de Confiabilidade de Sites). A Engenharia de Confiabilidade de Software (SRE) é uma parceria entre a engenharia de software e as operações de sistema.
1. SRE precisa de codificação? Sim, a codificação é necessária para os SREs. Engenheiros especializados em confiabilidade de sites trabalham para encontrar maneiras de tornar os sistemas mais confiáveis. Para atingir esse objetivo, ocasionalmente é essencial entrar no código-fonte de um sistema, identificar o problema e, frequentemente, fornecer um patch de volta à base de código.
2. Uma carreira em DevOps é uma escolha inteligente? Nos últimos cinco anos, houve um aumento de 40 a 50% na demanda por DevOps.
3. Qual linguagem de programação é ideal para uso em ambientes DevOps? Python é a linguagem mais popular para DevOps devido ao grande número de módulos de biblioteca que podem realizar responsabilidades comuns. As linguagens usadas para programação estão no centro do processo de desenvolvimento para sistemas DevOps. Como resultado, as pessoas que trabalham em DevOps precisam conhecer as linguagens de programação apropriadas que podem ser usadas nesses tipos de sistemas.
