9.8 Sobreaviso e prontidão operacional

Visão geral e motivação

Alguém está acordado agora porque o seu sistema pode acioná-lo. O sobreaviso (on-call) é o arranjo humano que põe uma pessoa qualificada ao alcance de um problema de produção a qualquer hora, e a prontidão operacional é o trabalho que vocês fazem antes para que essa pessoa tenha uma chance. Este capítulo trata dessa prontidão e desse sistema humano: como projetar um rodízio que as pessoas consigam sustentar por anos, como decidir o que vale a pena para acordar alguém e como garantir que um serviço esteja genuinamente pronto para ser operado antes de deixá-lo carregar tráfego real.

Mantenham isto distinto de dois vizinhos. O capítulo 9.3 cobre a gestão de incidentes, o processo de resposta quando algo está ativamente quebrado: papéis de comando, níveis de severidade, coordenação e revisões pós-incidente. O capítulo 9.1 cobre a engenharia de confiabilidade de sites (SRE), a disciplina mais ampla de engenhar a confiabilidade com objetivos de nível de serviço e orçamentos de erro. Este capítulo fica a montante do incidente e ao lado da disciplina. Faz uma pergunta mais estreita e mais pessoal: o serviço está pronto para rodar, e a pessoa que carrega o bipe está preparada para ter sucesso e não para sofrer? Uma organização pode ter um excelente processo de incidentes e ainda assim esgotar seus engenheiros, porque a dor do sobreaviso é decidida muito antes de qualquer incidente, pela qualidade dos alertas, pelo estado dos runbooks e pela humanidade da escala.

Para grandes equipes, o sobreaviso deixa de ser um favor informal e vira infraestrutura. Uma plataforma com centenas de serviços e dezenas de equipes não pode depender da única pessoa que por acaso sabe como tudo funciona. Precisa de rodízios, caminhos de escalonamento e padrões de prontidão que se sustentem quando os autores originais já foram embora. Em contextos corporativos e governamentais, as apostas sobem ainda mais. Os serviços regulados carregam compromissos de disponibilidade e obrigações de dever de cuidado com a equipe que os opera. Um sistema de benefícios ou de saúde voltado ao cidadão não pode sair do ar durante a noite porque a única pessoa que o entendia estava de férias. A prontidão operacional é como uma instituição mantém suas promessas depois que a festa de lançamento acaba, e o sobreaviso humano é como ela mantém as pessoas que mantêm essas promessas.

Princípios fundamentais

Acionem um humano apenas para problemas urgentes, acionáveis e reais.
Projetem o rodízio para uma pessoa que tem vida, não para uma máquina sempre disponível.
Provem que um serviço está pronto para operar antes de ele carregar tráfego de produção.
Alertem sobre sintomas visíveis ao usuário e SLOs, não sobre toda causa interna.
Tratem runbooks e revisões de prontidão como documentos vivos que são usados, não arquivados.
Quem constrói um serviço deve ajudar a operá-lo, dentro de limites humanos e apoiados.
Meçam a saúde do sobreaviso e cortem o trabalho repetitivo (toil) para que a carga tenda a cair e não a subir.

Recomendações

Projete um rodízio humano e sustentável

Comecem pela forma da escala, porque ela decide mais sobre a sustentabilidade do que qualquer ferramenta. Um padrão comum é um rodízio semanal com um respondente primário, que atende primeiro os acionamentos, e um secundário, que age como reserva quando o primário não reconhece ou precisa de ajuda. Mantenham o grupo grande o bastante para que qualquer engenheiro fique de sobreaviso no máximo uma semana em quatro e, idealmente, uma em seis ou mais. Um rodízio de quatro pessoas ou menos é um sinal de alerta: doença, feriados e evasão o colapsarão nos mesmos dois heróis exaustos.

Onde vocês operam entre fusos horários, prefiram um modelo follow-the-sun, em que equipes de regiões diferentes cobrem, cada uma, suas horas de luz do dia, de modo que ninguém seja acionado rotineiramente às 3 da manhã. Isso respeita o ritmo circadiano, o ciclo interno de sono e vigília do corpo, cuja perturbação é um custo direto à saúde e não um pequeno incômodo. Quando o follow-the-sun não é possível, comprimam a dor: blocos de turno noturno mais curtos, tempo de recuperação garantido depois de uma noite ruim e uma regra explícita de que um engenheiro muito acionado durante a noite não deve um dia inteiro de trabalho de funcionalidades na manhã seguinte.

O escalonamento é a rede de segurança sob o rodízio. Definam, por escrito, o que acontece quando o primário não reconhece um acionamento dentro de uma janela fixada: passa ao secundário, depois a um líder de equipe ou gerente e depois a um grupo mais amplo. Uma política de escalonamento automática e bem compreendida significa que nenhum acionamento cai em silêncio no chão e que nenhuma pessoa cansada é a única linha de defesa.

Faça da política de acionamento algo sobre problemas acionáveis, urgentes e reais

O modo mais rápido de destruir um rodízio de sobreaviso é acionar pessoas por coisas sobre as quais elas não podem ou não precisam agir. Adotem uma regra e defendam-na com ferocidade: um acionamento é uma alegação de que um humano precisa fazer algo agora. Se um alerta não passa nos três testes, urgente, acionável e descrevendo um problema real e visível ao usuário, ele não merece um acionamento. Encaminhem-no a um chamado, um painel ou um resumo diário.

O inimigo aqui é a fadiga de alarmes, o fenômeno bem documentado em que pessoas expostas a alarmes frequentes se dessensibilizam e passam a ignorá-los, inclusive os que importam. É um conceito de segurança do paciente vindo dos hospitais e que se transfere exatamente para o software. Quando todo turno traz vinte acionamentos e dezenove são ruído, quem responde aprende a dispensá-los meio dormindo, e o vigésimo, o que era real, recebe a mesma dispensa reflexa. Cada alerta ruidoso que vocês toleram é um pequeno imposto sobre a credibilidade de todos os outros alertas.

Tratem a qualidade dos alertas como uma entrega de engenharia de primeira classe. Acompanhem a razão entre reconhecimento e ação: dos acionamentos que dispararam, quantos levaram um humano a fazer algo que importava? Um alerta que nem uma vez exigiu ação num trimestre é candidato à exclusão ou ao rebaixamento. Revisem os alertas numa cadência regular e deem a qualquer engenheiro a legitimidade de questionar um ruidoso. O objetivo é um rodízio em que um acionamento seja raro o bastante para ainda significar algo.

Alerte sobre sintomas e SLOs, não sobre causas

O modo mais eficaz de cortar o ruído é mudar sobre o que vocês alertam. Alertar sobre causas, como CPU alta, um disco cheio ou um único processo reiniciado, gera uma enxurrada de acionamentos por condições que talvez nunca afetem um usuário e que o sistema muitas vezes se autocura. Alertem, em vez disso, sobre sintomas: o serviço está fazendo o que os usuários precisam que ele faça? Liguem os alertas de acionamento aos seus objetivos de nível de serviço (SLOs), as metas numéricas de confiabilidade definidas no capítulo 9.1, e acionem quando vocês estiverem queimando o orçamento de erros depressa o bastante para errar a meta, ou quando um indicador voltado ao usuário, como a latência ou a taxa de sucesso, cruza uma linha que as pessoas de fato sentem.

Essa abordagem baseada em sintomas e guiada por SLO depende da observabilidade e da telemetria do capítulo 9.2, já que o alerta de taxa de consumo só funciona quando as métricas, os logs e os rastros são estruturados e confiáveis. O ganho é dramático: um punhado de alertas de sintomas significativos substitui centenas de alertas de causas, e um acionamento volta a correlacionar com um problema que vale acordar alguém. As causas ainda importam, mas pertencem aos painéis de diagnóstico que quem responde consulta depois de um alerta de sintoma disparar, não ao caminho de acionamento.

Exija prontidão operacional antes do lançamento

Um serviço deve merecer o seu caminho até a produção. Antes de carregar tráfego real, passem-no por uma revisão de prontidão de produção: uma verificação estruturada, idealmente feita por alguém de fora da equipe construtora, de que o serviço de fato pode ser operado. Codifiquem a revisão como uma lista de verificação que vire um padrão compartilhado entre as equipes. Uma boa lista cobre monitoramento e SLOs, alertas que atendam à política de acionamento, painéis, runbooks para as falhas prováveis, propriedade definida e um rodízio de sobreaviso, expectativas de capacidade e de carga, análise de dependências e de modos de falha, backup e recuperação, controles de segurança e de acesso e um plano de reversão.

A revisão é uma conversa, não um portão a ser burlado. O valor dela é forçar a equipe construtora a enfrentar a operabilidade enquanto ainda tem o contexto, em vez de descobrir às 2 da manhã, seis meses depois, que ninguém escreveu um runbook ou definiu um alerta. Liguem a prontidão aos testes de resiliência do capítulo 9.6: um serviço que nunca teve uma falha de dependência injetada antes do lançamento está fazendo uma promessa não testada sobre como falha. Para lançamentos corporativos e governamentais de alto risco, façam da revisão de prontidão um passo obrigatório e documentado, porque o custo de um serviço voltado ao cidadão que falha em público sem estar pronto se mede tanto em confiança quanto em dinheiro.

Escreva runbooks e playbooks que de fato sejam usados

Um runbook é um documento operacional passo a passo: como reiniciar este serviço, rotacionar esta credencial, esvaziar esta fila, interpretar este alerta. Um playbook é o guia de resposta mais amplo para uma classe de situação. Ambos são inúteis se ninguém os lê, e a maioria dos runbooks não é lida porque está obsoleta, vaga ou impossível de achar às 3 da manhã. Consertem os modos de falha diretamente. Liguem o runbook a partir do próprio alerta, para que quem responde chegue a ele com um clique a partir do acionamento. Mantenham os runbooks em controle de versões junto ao código, como as práticas de documentação do capítulo 2.7 recomendam, para que sejam revisados e atualizados como qualquer outro artefato. Escrevam-nos para um estranho estressado e com sono, com comandos concretos e saídas esperadas, não prosa que presume o contexto do autor.

O teste de um runbook é se alguém que não é o autor consegue segui-lo com sucesso sob pressão. Validem isso na integração e nos game days e atualizem o runbook no instante em que um incidente revela que ele estava errado. Um runbook que mente é pior que nenhum, porque manda quem responde, cansado, com confiança na direção errada.

Seja dono do que constrói, dentro de limites humanos

O movimento DevOps popularizou o “você constrói, você opera”: a equipe que escreve um serviço também carrega o seu bipe. O benefício é real e vale defender. Quando os construtores sentem seus próprios acionamentos, investem em confiabilidade, consertam alertas ruidosos e projetam para a operabilidade, porque o ciclo de retorno chega a eles pessoalmente e não cai sobre uma equipe de operações separada que não consegue consertar a causa raiz.

O modelo tem limites que vocês precisam respeitar. Exige que as equipes sejam genuinamente equipadas para operar seus serviços: com as ferramentas, a plataforma, o treinamento e o tempo para fazer bem as operações, como a efetividade de engenharia do capítulo 1.10 e as formas de trabalhar do capítulo 1.4 exigem. A propriedade plena é cruel quando imposta a uma equipe pequena demais para compor um rodízio, ou sem o apoio de plataforma que torna o sobreaviso suportável. Algumas organizações rodam um híbrido, em que uma equipe central de SRE ou de plataforma é dona em conjunto dos níveis mais difíceis ou dá cobertura fora do horário para serviços que atendem a um patamar alto de confiabilidade, liberando as equipes de produto dos acionamentos noturnos de rotina. O princípio a manter é o ciclo de retorno; a forma pode flexionar para se ajustar ao tamanho da equipe, à maturidade e à humanidade da carga.

Integre deliberadamente os engenheiros de sobreaviso e rode game days

Ninguém deveria pegar o bipe pela primeira vez sozinho e despreparado. Construam um caminho de integração: acompanhar um respondente experiente por um rodízio (shadowing), acompanhar de forma inversa, em que o novato conduz com um mentor observando, uma passagem pelos painéis e runbooks e um mapa claro de a quem escalar. Façam da prontidão para entrar de sobreaviso um marco explícito, não uma suposição.

Os game days são o ensaio que torna o sobreaviso real. Num game day, vocês exercitam deliberadamente uma falha, idealmente num ambiente realista, e deixam o engenheiro de sobreaviso responder usando apenas as ferramentas e os runbooks que teria num incidente real. É aqui que vocês descobrem que o runbook está desatualizado, que falta um sinal no painel ou que o alerta nunca dispara. Os game days constroem a memória muscular e a confiança que transformam um primeiro acionamento real de pânico em procedimento, e se ligam naturalmente à engenharia do caos do capítulo 9.6.

Faça passagens de turno limpas e meça a saúde do sobreaviso

A passagem de bastão entre turnos é onde o contexto vaza. Instituam uma passagem curta e estruturada: o que está degradado no momento, que alertas dispararam e foram suprimidos, que mudanças estão em andamento, o que vigiar. Combinem-na com uma higiene básica de sobreaviso, incluindo uma política de que o respondente que sai não deixe bagunça para o que entra e de que tudo que ficou meio consertado seja escrito.

Acima de tudo, meçam. Vocês não gerenciam uma carga que não veem. Acompanhem os acionamentos por turno, a fração de acionamentos que caem fora do horário (noites, madrugadas, fins de semana), o tempo até o reconhecimento e com que frequência os níveis secundário e de escalonamento são acionados. Vigiem a tendência, não só o número: um rodízio cujos acionamentos fora do horário sobem trimestre após trimestre caminha para o esgotamento seja qual for a contagem absoluta atual. Alimentem essas métricas numa revisão operacional regular em que a equipe decide qual trabalho repetitivo (toil) automatizar, quais alertas matar e onde a prontidão falhou. Reduzir o toil, o trabalho operacional manual e repetitivo que escala com o tráfego em vez de ser consertado uma vez, é como vocês mantêm estável a carga de sobreaviso enquanto o sistema cresce.

Compromissos: prós e contras

Escolha	Prós	Contras
Você constrói, você opera	Ciclo de retorno de confiabilidade apertado. Os donos consertam as causas raiz	Cruel para equipes subdotadas ou minúsculas. Carga noturna desigual
Sobreaviso central de SRE ou plataforma	Protege as equipes de produto dos acionamentos noturnos de rotina. Habilidade operacional profunda	Enfraquece o ciclo de retorno do construtor. Pode virar depósito
Rodízio follow-the-sun	Ninguém é acionado de madrugada. Humano e saudável	Exige gente em várias regiões. Maior sobrecarga de passagem de turno
Rodízio local pequeno	Simples. Todos conhecem o sistema	Colapsa com doença ou evasão. Esgotamento rápido
Alertas de sintoma e SLO	Poucos acionamentos, significativos. Pouca fadiga	Exige telemetria madura. Pode perder causas de lenta formação
Alertas por causa	Pegam problemas cedo e de modo específico	Inundam quem responde. Conduzem à fadiga de alarmes
Revisões rigorosas de prontidão	Menos surpresas desagradáveis em produção	Atrasam lançamentos. Podem parecer burocráticas se burladas

A tensão central é entre cobertura e humanidade. Pressionem pela cobertura máxima e vocês obtêm rodízios grandes, alertas agressivos e propriedade plena em toda parte, o que protege o sistema enquanto tritura as pessoas. Otimizem puramente para o conforto de quem responde e vocês arriscam lacunas onde um problema real espera sem atenção. Resolvam isso não repartindo a diferença, mas elevando a qualidade: alertas excelentes, runbooks que funcionam e serviços prontos permitem que um rodízio menor e mais calmo cubra mais terreno com segurança. As organizações que operam melhor costumam ser as cujos respondentes são menos acionados, porque investiram em prontidão e não em resistência. Cada hora gasta removendo um alerta ruidoso ou consertando um runbook recompra várias horas de atenção humana e protege a credibilidade do sistema inteiro.

Perguntas para discutir com sua equipe

Vocês pessoalmente aceitariam carregar este rodízio por um ano, e o que mudariam se a resposta for não? Esta pergunta corta a abstração porque torna a carga pessoal. Levem os números reais à conversa: quantos acionamentos dispararam no mês passado, quantos caíram depois da meia-noite ou num fim de semana e quanto tempo o reconhecimento médio levou. Perguntem a cada pessoa do rodízio se a forma atual é uma que ela consegue sustentar sem temer a sua semana de sobreaviso e ouçam as respostas silenciosas tanto quanto as altas. Se a resposta honesta é que o rodízio só é sobrevivível porque um par de heróis absorve o pior dele, vocês acharam uma fragilidade que quebrará na primeira vez que um deles for embora. A saída que vocês querem é uma lista concreta de mudanças, seja um grupo maior, uma divisão follow-the-sun, uma redução de acionamentos noturnos ou uma limpeza de alertas, com um dono e uma data atrelados a cada uma.
Para cada alerta que pode acionar um humano, vocês conseguem nomear a ação que se espera de quem responde? A maioria dos rodízios nunca auditou isso, e o exercício é revelador. Puxem a lista completa de alertas de acionamento e, para cada um, perguntem o que quem responde deve fazer quando ele dispara e com que frequência ele disparou sem levar a nenhuma ação real no último trimestre. Os alertas que falham no teste, aqueles a que ninguém consegue atrelar uma ação ou que consistentemente se resolvem sozinhos antes de alguém tocar neles, são o ruído que erode a confiança em todos os outros alertas. Levem os dados de reconhecimento versus ação, se tiverem, e estejam prontos para apagar ou rebaixar com agressividade. O objetivo é um caminho de acionamento em que todo alerta seja um pedido genuíno de ajuda humana, e a reunião deve terminar com uma lista de alertas mais curta e mais afiada do que começou.
Quando um novo engenheiro entra neste rodízio, o que exatamente o prepara, e vocês testaram que funciona? A integração ao sobreaviso costuma ser presumida e não projetada, e a lacuna aparece na primeira vez que um novato é acionado sozinho diante de uma falha que nunca viu. Percorram o caminho real que um novo respondente faz: o que ele acompanha, que runbooks lê, se alguém seguiu esses runbooks recentemente para confirmar que ainda funcionam e a quem escala quando empaca. Tentem escolher um incidente recente real e perguntar se um recém-contratado, armado apenas com os runbooks e painéis atuais, teria conseguido resolvê-lo. A resposta honesta costuma expor documentação obsoleta e sinais ausentes, que é exatamente o que os game days devem revelar antes que um incidente real o faça. Saiam com um marco definido de prontidão para o sobreaviso e uma agenda dos game days que o manterão honesto.
Onde os nossos acionamentos fora do horário de fato caem, e estamos dispostos a mudar a escala ou a cobertura para proteger o sono das pessoas? Os acionamentos noturnos e de fim de semana carregam um custo de saúde que uma contagem bruta esconde, então um rodízio que parece tolerável na média pode ainda estar arruinando em silêncio algumas pessoas que por acaso pegam as falhas das 3 da manhã. Levem uma discriminação dos acionamentos por hora e dia da semana, dividida por serviço e por respondente, e procurem a concentração e não a média. A consideração contrária é real: a cobertura follow-the-sun exige gente em mais de uma região e acrescenta sobrecarga de passagem, enquanto um rodízio local pequeno é mais simples mas deixa alguém dono das noites. Decidam deliberadamente se a correção é um rodízio em uma segunda região, uma equipe central de plataforma assumindo os níveis fora do horário, blocos noturnos mais curtos com tempo de recuperação garantido ou uma limpeza de alertas que remove o ruído noturno na origem. Para operadores corporativos e governamentais, tratem o dever de cuidado com a equipe de sobreaviso como uma obrigação formal, com dono e métrica reportada, não como um slogan de bem-estar, porque um regulador ou um conselho de trabalhadores pode um dia pedir que vocês o demonstrem.
A nossa revisão de prontidão de produção é uma conversa genuína sobre como o serviço falha, ou uma lista de verificação burlada para passar no portão? Uma revisão de prontidão só compensa se mudar o que é entregue, e o modo de falha é um formulário preenchido na tarde antes do lançamento para satisfazer um processo em que ninguém acredita. Levem as últimas revisões concluídas e perguntem o que cada uma de fato pegou: um runbook ausente, uma reversão não testada, um alerta que nunca disparou ou nada. A tensão é entre a velocidade de lançamento e o rigor operacional, e uma revisão que parece burocracia será burlada, enquanto uma que revela modos reais de falha será ressentida até a primeira vez que salvar a noite de alguém. Decidam quem conduz a revisão, se é alguém de fora da equipe construtora e que evidência, como uma falha de dependência injetada ou um runbook que um estranho seguiu, conta como aprovação. Em lançamentos corporativos e governamentais, guardem a revisão concluída como artefato de auditoria e liguem-na aos testes de resiliência do capítulo 9.6, porque um serviço voltado ao cidadão que falha em público sem estar pronto custa uma confiança que nenhuma reversão recupera.
Onde o “você constrói, você opera” genuinamente nos serve, e onde é silenciosamente cruel com uma equipe que não dotamos de recursos para operar o seu serviço? A propriedade plena cria o ciclo de retorno que faz os construtores consertarem alertas ruidosos e projetarem para a operabilidade, mas, imposta a uma equipe pequena demais para compor um rodízio humano, vira uma máquina lenta de esgotamento vestida de responsabilização. Levem o mapa de quais equipes são donas de quais bipes, quão grande cada rodízio realmente é depois de tirar as pessoas que nunca pegam um acionamento difícil e que plataforma, ferramentas e treinamento cada equipe tem para fazer bem as operações. A atração contrária é entre o princípio limpo da propriedade universal e a realidade bagunçada de que alguns níveis precisam de uma equipe central de SRE ou de plataforma como dona em conjunto do trabalho de confiabilidade mais difícil ou para dar cobertura fora do horário. A saída que vocês querem é uma classificação honesta de cada serviço em totalmente próprio, compartilhado ou coberto centralmente, com a lacuna de recursos nomeada para qualquer equipe a quem estão pedindo que opere algo que não consegue sustentar. Para uma organização grande ou pública, acrescentem os prazos de contratação e de recrutamento do apoio de plataforma e do quadro que a propriedade humana pressupõe, porque uma equipe que vocês não conseguem dotar de pessoal na janela relevante é uma que vocês estão preparando para o fracasso.

Perspectiva por setor

Startup. Com um punhado de engenheiros, todos estão de sobreaviso e não há espaço para um rodízio de heróis se esconder. Gastem o tempo escasso nas duas mudanças que compensam mais depressa: apaguem os alertas baseados em causas e acionem apenas sobre um par de SLOs que acompanhem o seu fluxo central e liguem um runbook de uma página a cada alerta restante. Pulem ferramentas elaboradas e o follow-the-sun; uma planilha compartilhada, um escalonamento automático do primário para o secundário e uma regra firme de que uma noite ruim compra a manhã seguinte de folga levarão vocês mais longe do que qualquer compra de plataforma.

Pequena empresa. Vocês provavelmente não têm SRE dedicado e não conseguem dotar de pessoal um rodízio noturno, então apoiem-se no que compram e não no que constroem. Prefiram serviços gerenciados e hospedagem cujo provedor carregue os acionamentos profundos de infraestrutura e usem uma ferramenta hospedada de acionamento em vez de montar o próprio escalonamento. Enquadrem a prontidão como uma lista de verificação curta e um punhado de alertas significativos ligados ao que um cliente notaria e sejam honestos de que alguns serviços simplesmente não devem acionar um humano durante a noite quando um chamado pela manhã bastaria.

Grande empresa. O problema é a consistência entre muitas equipes: uma revisão compartilhada de prontidão de produção, uma política comum de acionamento e um repositório de runbooks em controle de versões para que um engenheiro que passa de uma equipe a outra entenda de imediato o sistema de sobreaviso. Façam da saúde do sobreaviso uma métrica governada, com limiares de acionamentos fora do horário que disparem revisão, padronizem o escalonamento e a passagem de turno para que nenhum acionamento caia em silêncio e deixem uma equipe central de plataforma ser dona em conjunto dos níveis mais difíceis. Gerenciem o portfólio de rodízios como gerenciam o portfólio de serviços, com dados sobre toil, carga de acionamentos e risco de esgotamento alimentando uma revisão operacional regular.

Governo. As regras de contratação, a transparência e o dever de cuidado moldam o arranjo. Tratem a saúde da equipe de sobreaviso como uma exigência formal e auditável e, onde a escala noturna é limitada, contratem um parceiro de operações follow-the-sun para que nenhum servidor seja acionado rotineiramente às 3 da manhã. Guardem cada revisão de prontidão concluída como artefato de auditoria, escrevam runbooks para serem executados por um respondente que não construiu o sistema, já que as pessoas que o operarem daqui a cinco anos não serão seus autores, e ensaiem o pico sazonal com game days antes que os cidadãos o encontrem de verdade.

Exemplos

Startup. Uma startup de doze pessoas lança seu primeiro produto pago e põe os seis engenheiros num rodízio semanal com primário e secundário. No primeiro mês o bipe dispara toda noite, principalmente por alertas de CPU e disco que se resolvem sozinhos, e dois engenheiros começam em silêncio a procurar emprego. A equipe para e reconstrói: apaga todo alerta baseado em causas, define dois SLOs para o checkout e a busca e aciona apenas sobre o consumo do orçamento de erros. Os acionamentos caem de cerca de quarenta por semana para três. Acrescentam uma lista de verificação de prontidão de uma página que todo serviço novo precisa passar e ligam cada runbook diretamente ao seu alerta. O sobreaviso deixa de ser o motivo de as pessoas saírem e vira uma parte administrável do trabalho, e eles o fizeram com uma planilha e disciplina e não com uma ferramenta cara.

Grande empresa. Uma empresa global de pagamentos roda centenas de serviços sob um modelo de “você constrói, você opera”, apoiada por uma equipe central de plataforma que fornece o sistema de acionamento, o processo de revisão de prontidão e um repositório compartilhado de runbooks em controle de versões. Todo serviço passa por uma revisão documentada de prontidão de produção antes do lançamento, cobrindo SLOs, alertas, runbooks, capacidade e reversão. A saúde do sobreaviso é uma métrica acompanhada: as equipes cujos acionamentos fora do horário passam de um limiar disparam uma revisão automática, e a equipe de plataforma se oferece para ser dona em conjunto do trabalho de confiabilidade até a carga baixar. Os game days rodam trimestralmente contra injeção realista de falhas. Como o padrão é uniforme e as ferramentas são compartilhadas, um engenheiro pode passar de uma equipe a outra e entender de imediato o sistema de sobreaviso, e a liderança consegue ver, por equipe, se a carga humana é sustentável.

Governo. Uma autoridade tributária nacional opera um sistema de declaração com picos sazonais rígidos e a obrigação legal de permanecer disponível aos cidadãos. Como a força de trabalho está concentrada num único fuso horário e a escala noturna é limitada, a autoridade contrata um arranjo follow-the-sun com um parceiro de operações para que nenhum servidor seja acionado rotineiramente no meio da noite e trata a saúde e o dever de cuidado da equipe de sobreaviso como uma exigência formal. Toda mudança de serviço passa por uma revisão de prontidão operacional antes da implantação, com a lista de verificação guardada para auditoria. Os runbooks são escritos para serem executados por um respondente que não construiu o sistema, porque as pessoas que o operarão em cinco anos não serão as que o escreveram. Durante a temporada de declarações, a autoridade roda game days contra o cenário de carga de pico, de modo que os respondentes encontram a onda em ensaio antes de encontrá-la de verdade.

Justificativa de negócio: motivações, ROI e TCO

O retorno da prontidão operacional e do sobreaviso humano aparece em dois livros-razão: a confiabilidade do sistema e a retenção da equipe. Do lado da confiabilidade, os serviços que passam por uma revisão de prontidão e carregam alertas baseados em sintomas falham menos e se recuperam mais depressa, porque o runbook existe, o alerta é significativo e quem responde foi ensaiado. O tempo médio de reconhecimento e o tempo médio de recuperação caem quando um acionamento chega a uma pessoa preparada com um runbook ligado e não a uma confusa caçando contexto. Do lado humano, o sobreaviso é uma das principais causas de evasão de engenheiros, e substituir um engenheiro sênior custa um múltiplo grande do investimento que teria sido preciso para consertar o rodízio. O esgotamento ocupacional (burnout), o estado de exaustão crônica no trabalho que a Organização Mundial da Saúde reconhece como um fenômeno ocupacional, é caro precisamente porque leva as suas pessoas mais experientes, as que entendem o sistema, e as expulsa.

O custo de adoção é sobretudo pontual e modesto. Vocês escrevem uma lista de verificação de prontidão, migram os alertas de causas para sintomas, põem os runbooks em controle de versões e montam métricas de saúde do sobreaviso. O custo recorrente é a disciplina de revisar alertas, rodar game days e honrar uma escala humana. O custo da negligência se compõe em silêncio: os alertas ruidosos geram fadiga, a fadiga gera incidentes reais perdidos e saídas, e cada saída leva embora conhecimento operacional, o que eleva a carga de quem fica. Para defender o caso junto à liderança, liguem a saúde do sobreaviso a métricas que ela já acompanha: frequência e duração de incidentes, tempo até o reconhecimento, evasão não planejada e a tendência de acionamentos fora do horário. Um rodízio cujos acionamentos fora do horário caem enquanto o sistema cresce é evidência direta de que o seu investimento em confiabilidade está funcionando e de que os seus engenheiros ainda estarão aqui no ano que vem.

Antipadrões e armadilhas

O rodízio de heróis: duas ou três pessoas absorvem em silêncio todo acionamento difícil, de modo que a escala parece boa no papel e colapsa no instante em que uma delas sai.
Acionar por causas: alertar sobre CPU, memória e disco em vez de sintomas visíveis ao usuário, inundando quem responde com acionamentos que nunca precisaram de um humano.
Fadiga de alertas tolerada: alertas sabidamente ruidosos deixados no caminho de acionamento por meses porque apagá-los parece arriscado, até quem responde ignorar tudo.
Apodrecimento de runbooks: documentos escritos uma vez no lançamento, nunca atualizados e confiantemente errados quando um respondente cansado os segue às 3 da manhã.
Propriedade sem apoio: impor o “você constrói, você opera” a uma equipe pequena demais para compor um rodízio ou sem a plataforma e as ferramentas para rodá-lo de modo humano.
Teatro de prontidão: uma lista de verificação de revisão preenchida para passar no portão em vez de enfrentar de verdade como o serviço falha.
Lançar e abandonar: entregar um serviço sem rodízio, sem alertas e sem runbooks e depois descobrir a lacuna durante a primeira interrupção.
Carga não medida: nenhum dado sobre acionamentos por turno ou fora do horário, de modo que o esgotamento é invisível até as pessoas saírem.
Primeiro acionamento, sem ensaio: pôr um novo engenheiro de sobreaviso sem acompanhamento nem game day e depois fingir surpresa quando ele trava.

Modelo de maturidade

Nível 1, Iniciar: O sobreaviso é informal e reativo. Algumas pessoas são telefonadas quando as coisas quebram, os alertas disparam sobre causas e são em sua maioria ruído, os runbooks estão ausentes ou obsoletos, os serviços são lançados sem verificação de prontidão e ninguém mede a carga humana até alguém se esgotar ou sair.
Nível 2, Desenvolver: Aparecem práticas básicas, mas variam por equipe. Alguns rodízios têm primário, secundário e escalonamento definidos, alguns alertas são ajustados e alguns runbooks são escritos, e existe uma lista de verificação de prontidão aplicada de modo inconsistente. Os acionamentos podem ser contados nas equipes que se dão ao trabalho, os acionamentos noturnos são comuns e a integração ao sobreaviso é improvisada e não projetada.
Nível 3, Padronizar: As revisões de prontidão são um passo documentado antes do lançamento, imposto entre as equipes. O acionamento é baseado em sintomas e SLOs conforme uma política comum, os runbooks vivem em controle de versões e se ligam a partir dos alertas, a integração inclui acompanhamento e game days, as passagens de turno seguem um formato estruturado e o escalonamento é uniforme o bastante para que um engenheiro que passa de uma equipe a outra reconheça o sistema de imediato.
Nível 4, Gerenciar: O sobreaviso é medido e controlado em relação a linhas de base. Os acionamentos por turno, a fração fora do horário, o tempo até o reconhecimento, a frequência de escalonamento e a razão entre reconhecimento e ação são acompanhados por equipe e comparados a metas, de modo que um rodízio derivando para o esgotamento fica visível antes de as pessoas saírem e não depois. Os limiares disparam revisão, a qualidade dos alertas é auditada com base em evidências de quais acionamentos levaram a ação real e as decisões de escala e de propriedade são conduzidas pelos dados e não por anedota.
Nível 5, Orquestrar: A saúde do sobreaviso é um resultado continuamente melhorado e integrado em toda a organização. As tendências de acionamentos e de acionamentos fora do horário caem conforme o sistema cresce, o toil é sistematicamente automatizado, o follow-the-sun ou equivalente protege o sono, os game days e a injeção de falhas são rotina e a organização adapta propriedade, cobertura e padrões de prontidão conforme aprende com cada turno, reequilibrando a carga entre equipes e regiões à medida que o quadro de risco muda.

Ideias para discussão

Qual é a sua razão atual entre acionamentos que levaram a ação real e acionamentos que se resolveram sozinhos, e o que seria preciso para medi-la?
Se o seu respondente mais conhecedor saísse amanhã, quais serviços se tornariam inseguros de operar, e por quê?
Onde o “você constrói, você opera” serve bem a vocês, e onde é silenciosamente cruel com uma equipe subdotada?
Quando foi a última vez que vocês viram um novo engenheiro seguir um dos seus runbooks em condições realistas, e o que quebrou?
Os seus acionamentos fora do horário estão subindo ou caindo nos últimos quatro trimestres, e alguém é dono desse número?
Qual item da revisão de prontidão, se imposto com rigor, teria prevenido o seu lançamento ruim mais recente?

Principais conclusões

A prontidão de sobreaviso é decidida antes de qualquer incidente, pela qualidade dos alertas, runbooks e rodízio, não por heroísmo durante a interrupção.
Acionem um humano apenas para problemas urgentes, acionáveis e visíveis ao usuário. Alertem sobre sintomas e SLOs e encaminhem todo o resto a chamados e painéis.
Projetem rodízios para pessoas com vida: grupos grandes o bastante, follow-the-sun onde possível, escalonamento automático e tempo de recuperação honrado.
Provem que os serviços estão prontos antes do lançamento com uma revisão de prontidão de produção, mantenham os runbooks em controle de versões e ligados a partir dos alertas e ensaiem com game days.
Meçam a saúde do sobreaviso, especialmente os acionamentos fora do horário e o tempo até o reconhecimento, e reduzam a carga cortando toil e ruído e não pedindo que as pessoas suportem mais.

Referências e leitura complementar

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
Rob Ewaschuk, “My Philosophy on Alerting,” in Site Reliability Engineering appendix
John Allspaw and Jesse Robbins (eds.), Web Operations: Keeping the Data on Time
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
World Health Organisation, ICD-11, entry on burn-out as an occupational phenomenon