A engenharia de confiabilidade de sites (SRE) é comum em grandes empresas, no entanto, empresas menores também precisam dela. Embora a função de engenheiro de confiabilidade de site (SRE) tenha se tornado predominante nos últimos anos, muitas pessoas, mesmo na indústria de software, não sabem o que ela é ou o que faz.
Então, este artigo tem como objetivo esclarecer essas questões explicando o que é a engenharia de confiabilidade de sites (SRE), como ele se relaciona ao DevOps e como um SRE funciona quando toda a sua organização de engenharia pode caber em uma cafeteria.
O que é engenharia de confiabilidade de site?
O livro Site Reliability Engineering: How Google Runs Production Systems, escrito por um grupo de engenheiros do Google, é considerado o livro definitivo sobre engenharia de confiabilidade de sites (SRE). O vice-presidente de engenharia do Google, Ben Treynor Sloss, cunhou o termo no início dos anos 2000 e o definiu como: “É o que acontece quando você pede a um engenheiro de software para projetar uma função de operações.”
Os administradores de sistemas têm escrito códigos há muito tempo. No entanto, por muitos desses anos, uma equipe de administradores de sistemas gerenciava muitas máquinas manualmente. Naquela época, “muitos” podem ter sido dezenas ou centenas, mas quando você escala para milhares ou centenas de milhares de hosts. Ou seja, você simplesmente não pode continuar a jogar as pessoas no problema. Então, quando o número de máquinas fica tão grande, a solução óbvia é usar código para gerenciar hosts (e o software que é executado neles).
Além disso, até bem recentemente, a equipe de operações era completamente separada dos desenvolvedores. Os conjuntos de habilidades para cada trabalho foram considerados completamente diferentes. Contudo, a função SRE tenta reunir os dois trabalhos.
No entanto, antes de nos aprofundarmos sobre o que é um SRE e como os SREs funcionam com a equipe de desenvolvimento, precisamos entender como a engenharia de confiabilidade do site funciona dentro do paradigma DevOps.
Engenharia de Confiabilidade de Sites (SRE) e DevOps
Em sua essência, a engenharia de confiabilidade de sites (SRE) é uma implementação do paradigma DevOps. Contudo, parece haver uma grande variedade de maneiras de definir DevOps. O modelo tradicional, onde as equipes de desenvolvimento (“devs”) e operações (“ops”) eram separadas, fazia com que a equipe que escreve o código não se responsabilizasse pelo seu funcionamento quando os clientes começassem a usá-lo. Ou seja, a equipe de desenvolvimento “jogaria o código por cima do muro” para a equipe de operações instalar e dar suporte.
Entretanto, essa situação pode levar a uma disfunção significativa. Afinal, os objetivos das equipes de desenvolvimento e operações ficavam constantemente em conflito. Por exemplo, um desenvolvedor deseja que os clientes usem o código “mais recente e melhor”, no entanto, a equipe de operações deseja um sistema estável com o mínimo de alterações possível. Sua premissa é que qualquer mudança pode introduzir instabilidade, enquanto um sistema sem mudanças deve continuar a se comportar da mesma maneira. Contudo, observe que minimizar a mudança no lado do software não é o único fator importante na prevenção da instabilidade. Por exemplo, se seu aplicativo da web permanecer exatamente o mesmo, mas o número de clientes crescer 10 vezes, seu aplicativo pode falhar de muitas maneiras diferentes.
Onde entra o DevOps?
Portanto, a premissa do DevOps é que, ao mesclar essas duas tarefas distintas em uma, você elimina a contenção. Afinal, se o “dev” quiser implantar novo código o tempo todo, ele terá que lidar com qualquer falha que o novo código crie. Como disse Werner Vogels da Amazon, “você constrói, você executa”. Entretanto, os desenvolvedores já têm muito com que se preocupar. Afinal, eles são continuamente pressionados a desenvolver novos recursos para os produtos de seus empregadores. Então, pedir que eles entendam a infraestrutura, incluindo como implantar, configurar e monitorar seu serviço, pode ser um pouco demais. É aqui que entra um SRE.
O papel do SRE na prática
Quando um aplicativo da web é desenvolvido, geralmente há muitas pessoas que contribuem. Afinal, existem:
- Designers de interface de usuário;
- Designer gráfico;
- Engenheiros de front-end;
- Engenharia de back-end e uma série de outras especialidades (dependendo das tecnologias usadas).
Além disso, os requisitos incluem como o código é gerenciado (por exemplo, implantado, configurado, monitorado). E essas são justamente as áreas pertinentes à engenharia de confiabilidade de sites (SRE). No entanto, é importante lembrar que um engenheiro que desenvolve uma boa aparência para um aplicativo se beneficia do conhecimento do trabalho do engenheiro de back-end. Por exemplo, como os dados são obtidos de um banco de dados. Da mesma forma, o SRE entende como o sistema de implantação funciona e como adaptá-lo para as necessidades específicas dessa base de código ou projeto em particular.
Portanto, um SRE não é apenas “uma pessoa de operações que codifica”. Ao invés disso, o SRE é outro membro da equipe de desenvolvimento com um conjunto diferente de habilidades. Estas giram particularmente em torno de implantação, gerenciamento de configuração, monitoramento, métricas, etc. Entretanto, assim como um engenheiro que desenvolve uma boa aparência para um aplicativo deve saber como são os dados obtidos de um armazenamento de dados, um SRE não é o único responsável por essas áreas. Afinal, toda a equipe trabalha em conjunto para entregar um produto que pode ser facilmente atualizado, gerenciado e monitorado.
Portanto, a necessidade de um SRE surge naturalmente quando uma equipe está implementando DevOps, mas percebe que está exigindo muito dos desenvolvedores e precisa de um especialista para saber o que a equipe de operações costumava fazer.
Conclusão
Uma equipe de engenharia de confiabilidade de sites (SRE) é uma das maneiras mais eficientes de implementar o paradigma DevOps em uma startup, por exemplo. Afinal, a contratação de um SRE dedicado bem no início em sua inicialização irá liberar tempo para os desenvolvedores se concentrarem em seus desafios específicos. Não obstante, o SRE pode se concentrar na melhoria das ferramentas e processos que tornam os desenvolvedores mais produtivos. Além disso, um SRE se concentrará em garantir que seus clientes tenham um produto confiável e seguro.
Conheça 7 termos-chave na engenharia de confiabilidade de sites (SRE)
Quer entender a engenharia de confiabilidade de sites (SRE) mais a fundo? Então, confira esta cartilha de terminologias SRE que explica alguns de seus fundamentos, desde a função de trabalho até SLAs e resolução de problemas.
Vale frisar que a engenharia de confiabilidade de sites (SRE) pode ser:
- Uma maneira de fechar a lacuna entre os desenvolvedores de software e as equipes de operações de TI;
- Uma forma de melhorar os fluxos de trabalho e resiliência para equipes que já praticam DevOps.
Ou, como diz o Google, que estabeleceu o termo e conceito de SRE, é quando uma organização trata as operações de TI como um problema de software.
Afinal, ao fazer isso, uma empresa verá muitos benefícios em seu pipeline de desenvolvimento. Por exemplo, o SRE reduz o esforço manual por meio da automação e leva à melhoria da qualidade do software. Isso, por sua vez, aumenta a confiabilidade, repetibilidade e flexibilidade do sistema. Portanto, uma equipe de engenharia de confiabilidade de sites (SRE) também aborda e melhora outros aspectos do ecossistema de TI, como desempenho geral, disponibilidade, solução de problemas e monitoramento.
No entanto, antes de adotar uma abordagem SRE, é importante entender alguns termos-chave.
Engenheiro de confiabilidade do site
Um engenheiro de confiabilidade do site preenche a lacuna entre os desenvolvedores e a equipe de operações de TI. Seu intuito é criar e garantir a escalabilidade, estabilidade e previsibilidade dos sistemas de uma organização. Então, para isso, os SREs automatizam tarefas rotineiras, gerenciam mudanças de produção e determinam respostas a emergências, entre outras tarefas.
Toil
As tarefas que mantêm a plataforma de TI funcionando são, obviamente, essenciais, contudo, concluí-las manualmente não é. Portanto, a redução dessas tarefas, também conhecidas como toil, é um dos principais objetivos da SRE. Patches e atualizações automatizáveis são tarefas consideradas árduas.
Error budget
Disponibilidade de cem por cento é um padrão irreal. Então, como nenhum serviço é perfeito, os usuários devem definir um padrão de desempenho internamente, externamente ou ambos. Essa lacuna de desempenho, ou quantidade de tempo de inatividade aceitável, é chamada de error budget (orçamento de erro). É responsabilidade do engenheiro de confiabilidade do site manter o desempenho dentro desse quadro, concluindo as tarefas de administração e rastreando as principais métricas.
Acordo de nível de serviço (SLA)
Este é o contrato entre um fornecedor e o cliente que define as expectativas de ambas as partes. Por exemplo, os SLAs definem padrões para serviços, como nível de disponibilidade, para que os clientes entendam a responsabilidade do provedor por interrupções ou problemas de desempenho. Ou seja, o provedor é isento caso um problema esteja fora dos níveis de gravidade ou das circunstâncias definidas no SLA. Contudo, se está dentro do contrato, geralmente há uma penalidade financeira. Isso garante a responsabilidade por parte do provedor e do usuário.
Objetivo de nível de serviço (SLO)
Ao invés de ser uma métrica distinta, o SLO faz parte do SLA. Na verdade, os SLOs rastreiam os principais indicadores de desempenho que o cliente deve esperar do fornecedor, tal como as penalidades impostas se as expectativas não forem atendidas. Então, os SLOs definem uma faixa de desempenho aceitável, começando com as principais métricas, como tempo de recuperação de desastres e disponibilidade de aplicativos. Contudo, cabe a um SRE alinhar essas metas de desempenho definidas pelo SLO com o orçamento de erros da organização para garantir os padrões de desempenho. Isso envolve a configuração de alertas e o monitoramento do valor dos SLOs.
Indicador de nível de serviço (SLI)
Outro componente típico de um SLA, os SLIs são uma medida direta do comportamento de um serviço que indica o nível de desempenho que o cliente recebe. O provedor e o cliente os definem juntos. Na verdade, os SLIs são a base dos SLOs. Exemplos de SLIs incluem latência, taxa de erro e disponibilidade. No entanto, deve haver um equilíbrio preciso entre as métricas escolhidas para garantir que aquelas críticas para o ambiente específico ou a base de usuários não sejam negligenciadas.
Incidente de TI post-mortem
A vantagem dos incidentes de TI é a oportunidade de aprender e melhorar. Então, um incidente post-mortem avalia a causa raiz de um problema e seus efeitos, revela lições importantes e ajuda a equipe de TI a estabelecer um plano para prevenir a recorrência. Os SREs são responsáveis por conduzir essas autópsias e compartilhar os resultados com a equipe sênior, como líderes executivos, engenheiros e arquitetos. Além disso, as autópsias bem-sucedidas removem a culpa para criar um ambiente onde a equipe se sinta confortável para falar honestamente sobre os incidentes, já que enfoca a discussão sobre o motivo da ocorrência do problema.
