SREs trazem ORDEM(R) ao CAOS

Uma análise dos desafios e das responsabilidades do seu grande aliado: o engenheiro de confiabilidade de sites (SRE).

Por Keith McDuffee, embaixador da Snyk, especialista em DevSecOps e fundador da StackRef.com.

“Qual é a diferença entre um engenheiro de DevOps e um engenheiro de confiabilidade de sites?”

É uma pergunta que ouço o tempo todo — inclusive em entrevistas de emprego, nas quais já me fizeram essa pergunta e às vezes eu mesmo a fiz. Mas existe uma resposta certa? Tudo depende de quem você pergunta. Acredito que existe uma linha divisória, mas ela é tão tênue que você precisa apertar os olhos para enxergá-la.

Por enquanto, vamos falar sobre SREs. Quais são suas responsabilidades? O que eles fazem? Que desafios enfrentam no dia a dia?

Vou tentar ser esperto aqui e agrupar as responsabilidades no que chamo de ORDERR e os desafios em CHAOS.

CHAOS

O que deixa os SREs sempre alertas e sem dormir à noite? Podemos categorizar esses fatores da seguinte forma:

Falha de componentes críticos

Os componentes que formam um sistema de computador são muitos, mas não estamos falando apenas de hardware. O hardware — mesmo com redundâncias — pode falhar, mas também é preciso considerar serviços e aplicações. Aplicações travam, serviços ficam sobrecarregados e o hardware simplesmente para de funcionar.

Intervenção humana

A falta de automação eficaz é como acordar um SRE às 2h da manhã todas as noites para digitar 4, 8, 15, 16, 23 e 42 no teclado. Depender de uma pessoa de carne e osso para executar tarefas que poderiam ser facilmente deixadas para um programa é pedir para que ela fique frustrada, exausta e digite o código errado. Além disso, quando esses sistemas automatizados falham — e eles podem mesmo falhar —, não ter como reproduzir o processo de forma rápida e fácil acaba se tornando mais um problema.

Bugs no código da aplicação

Há um limite para o que um SRE pode fazer. Alguns sabem programar e conhecem uma aplicação de ponta a ponta, mas geralmente não é por isso que foram contratados. Ainda assim, um SRE pode ajudar a identificar os responsáveis e envolver os engenheiros certos. Com suas ferramentas de observabilidade, os SREs também devem ter um pouco de presciência, pois, sem elas, há uma bomba-relógio prestes a acordá-los. De novo.

Problemas em software de código aberto

Às vezes, seus desenvolvedores não são totalmente culpados por um código que trava ou não é seguro (embora, idealmente, devessem saber disso). Muitas aplicações são construídas com dependências de código aberto — algumas tão complexas e misteriosas que nenhuma equipe interna de desenvolvimento de software conseguiria entendê-las por completo. Um módulo importado para um projeto a fim de habilitar um único recurso pode introduzir milhares de outros componentes desnecessários, trazendo vulnerabilidades ainda não descobertas e problemas de desempenho.

As dependências de código aberto não são as únicas possíveis culpadas. Componentes pagos de terceiros também podem ser responsáveis — e, às vezes, a situação pode ser pior: você fica à mercê das prioridades da empresa, não da comunidade em geral (log4j, alguém?).

Incidentes de segurança

O verdadeiro pesadelo de um SRE. Quando isso acontece, ou o problema não pode ser resolvido de imediato e com facilidade, ou ele passa despercebido por mais tempo do que você gostaria de admitir. Ataques de negação de serviço (DoS) estão incluídos aqui e são um tipo de ameaça a mitigar. Mas uma presença hostil e ativa nos seus sistemas é outra história. Só dá para dizer que a situação foi “resolvida” quando a ameaça ativa está sob controle e foi contida, e tudo o que pode ter sido comprometido está sendo tratado como resíduo nuclear.

ORDERR

Eu tentei — tentei mesmo — reduzir tudo a apenas ORDER, mas simplesmente não dá para ignorar ou separar os dois últimos Rs da lista.

Observabilidade

De que adianta tentar lidar com o CAOS se você não consegue enxergá-lo? Observabilidade é justamente como você acompanha tudo: disponibilidade, desempenho e atividade.

Mas não basta ter visibilidade dessas informações. É preciso contar com alertas confiáveis e que indiquem ações concretas para os eventos que exigem atenção. Aqui, “acionáveis” e “confiáveis” caminham juntos. Se um SRE é acordado à noite por um alarme falso — e esses alarmes continuam —, ele pode ficar exausto e acabar diante de uma situação de “Pedro e o lobo”: um alerta que parecia falso é, na verdade, motivo de preocupação.

Embora alertas relevantes e oportunos sejam importantes, um SRE não pode depender apenas deles. Ter visibilidade por meio do monitoramento, para que os SREs acompanhem continuamente o que está em execução, é o primeiro passo para configurar esses alertas! Algumas equipes de SRE usam ferramentas de terceiros; outras criam as próprias. Tudo depende do orçamento e da existência de uma solução que atenda às suas necessidades específicas.

Há ferramentas demais para listar nesta categoria, mas aqui vão algumas: Datadog, New Relic, ELK Stack (com opções gratuitas de suporte e hospedagem), SolarWinds e Splunk.

Confiabilidade

Este é um tema abrangente. Muitas coisas podem afetar a confiabilidade de sistemas e aplicações. Tudo está em jogo, desde a base até as camadas superiores (e além!): geolocalização, instalações de hospedagem, servidores e hardware, redes, sistema operacional, serviços, código da aplicação e a forma como os serviços oferecidos são entregues. Cansou? Os SREs também.

Eu incluiria um “A” aqui, de disponibilidade, mas acredito que os conceitos são tão próximos que podem significar a mesma coisa. Garantir que você tenha tudo o que precisa para manter seus sistemas disponíveis — redundância, métodos automatizados e/ou manuais de failover, segurança e resposta a incidentes de negação de serviço — faz parte da confiabilidade.

Com exceção do código da aplicação, os SREs são os únicos responsáveis por cuidar de tudo o que mantém confiáveis os sistemas de uma organização. No caso do código da aplicação, muitas vezes os SREs são apenas o meio pelo qual os desenvolvedores responsáveis pelo software ganham visibilidade, e não quem corrige o que está quebrado. Isso é feito, em parte, com ferramentas de análise estática de código, que apontam problemas à medida que são encontrados, ou por meio do monitoramento e dos registros já implementados. Depois que os problemas são identificados, cabe aos SREs encaminhá-los à equipe ou às equipes certas e garantir que sejam resolvidos rapidamente.

A Snyk oferece ferramentas para ajudar nessa categoria.

Resposta a desastres

“Desastre” é um termo amplo para SREs. Pode significar desde uma falha em infraestrutura crítica até — Deus nos livre — um avião cair com seu principal engenheiro de software a bordo. Claro que também inclui qualquer situação relacionada à segurança.

Ter meios eficazes para responder a esses desastres é fundamental para as responsabilidades de um SRE. Por isso, é essencial manter runbooks atualizados e disponíveis (falaremos deles no E abaixo), já que nem sempre dá para confiar só na memória. Pode ser difícil encontrar tempo para exercícios de simulação e testes regulares de recuperação de desastres, mas eles são fundamentais para garantir respostas mais rápidas e organizadas a situações críticas.

Algumas ferramentas pagas (e com opções gratuitas limitadas) para essa categoria são Mattermost e PagerDuty.

Uma resposta eficaz também exige...

Comunicação eficaz

Há muitos meios de comunicação, especialmente quando as equipes trabalham remotamente e estão distribuídas por diferentes fusos horários. É essencial estabelecer uma forma clara de comunicação para qualquer situação problemática — não apenas definir onde, mas também como e quando.

Meios de comunicação adequados não só ajudam os SREs a manter a observabilidade das situações, como também garantem que elas sejam tratadas corretamente e em tempo hábil, sem duplicar esforços.

Também é preciso se comunicar com as partes interessadas, tanto internas quanto externas. Se algo parecer fora do normal, a comunicação começa com as equipes internas, antes de informar os clientes externos sobre problemas que afetam o uso dos serviços. Os SREs são o ponto de partida para decidir se, quando e como será feita a comunicação externa.

Aqui estão algumas ferramentas de comunicação bastante conhecidas: Slack, Microsoft Teams e Atlassian StatusPage.

Recuperação

Tudo isso leva ao objetivo final (além de evitar que algo dê errado): recuperar tudo para um estado estável e seguro. Todos os fatores mencionados acima determinam a rapidez com que isso pode ser alcançado.

• Observe o que está acontecendo.

• Tenha meios confiáveis de failover e redundância.

• Garanta que o plano de ação de resposta a desastres seja seguido.

• Coloque em prática a comunicação eficaz.

Os SREs são responsáveis por cumprir uma meta de MTR (tempo médio de recuperação), e não dá para alcançá-la contando com a sorte. Depois da recuperação, é hora de retomar a comunicação eficaz para tranquilizar as partes interessadas. Mas, para o SRE, o trabalho ainda não acabou. É hora de...

Retrospectiva

Quando a poeira baixar, os SREs podem respirar aliviados, mas não por muito tempo. Algo ruim aconteceu. E, se nada for feito, é provável que aconteça de novo.

Isso nos leva de volta à comunicação eficaz. Precisamos entender quando, o quê, onde, por quê e como, além de definir o que vamos fazer para evitar que isso aconteça novamente.

As lições aprendidas devem ser documentadas junto com o incidente, acompanhadas de um plano de ação que não simplesmente desapareça no ar. Talvez seja necessário ajustar algum dos pontos anteriores: melhorar a observabilidade, reforçar os sistemas e a segurança, acrescentar camadas de confiabilidade ou até aprimorar a comunicação. Depois, é preciso estabelecer prazos razoáveis para garantir que tudo seja feito, e os SREs devem acompanhar os responsáveis para assegurar que as ações sejam concluídas.

DevOps vs. SRE

Então, o que fazem os profissionais de DevOps quando não são também SREs? Não vou entrar em todos os detalhes, mas, em relação aos SREs, o DevOps ajuda a fazer com que tudo isso aconteça entre os SREs e os desenvolvedores — capacitando os dois lados a fazer o que precisam sem precisar ficar passando problemas de um lado para o outro. O DevOps dá suporte e fornece toda a ORDERR de que os SREs dependem para lidar com o CHAOS, ao mesmo tempo que permite que quem não é SRE participe tanto quanto necessário.

Boa sorte por aí…

- K