Quando o seu fornecedor cai
Última atualização:
Uma página de estado de um fornecedor é o painel público que um fornecedor de nuvem, alojamento, código ou pagamentos mantém para declarar a sua própria saúde: um indicador geral, uma lista de componentes e uma cronologia de incidentes escrita pelo próprio fornecedor enquanto esses incidentes ainda decorrem. Lâ-la bem é uma competência de operador, porque o título é um resumo e a verdade vive debaixo dele —em que componente está afetado, em que região, com que impacto declarado, e até onde o incidente avançou no próprio fluxo do fornecedor—. Este artigo ensina essa leitura e termina com o que fazer nos primeiros dez minutos quando o fornecedor em questão é um de que depende. Comece no painel de estado dos fornecedores, que reúne as páginas dos principais fornecedores num instantâneo, e tenha presente ao longo de todo o texto a pergunta de está em baixo, ou é só você?: as duas ferramentas respondem às metades opostas da mesma dúvida.
Duas coisas diferentes: o indicador e o estado do incidente
Toda a página de estado madura traz dois sinais separados que os leitores confundem constantemente. O primeiro é o indicador geral: um único estado resumido para todo o serviço, normalmente um de none, minor, major, critical ou maintenance no feed legível por máquinas por trás da página —o modelo documentado na documentação para programadores da Statuspage, que a maioria dos grandes fornecedores usa diretamente ou imita de perto—. O indicador é deliberadamente grosseiro. Existe para que um leitor ocupado —ou uma máquina, como o nosso painel de estado— possa responder a «passa-se alguma coisa ali?» num segundo, e é calculado a partir do componente mais afetado, do próprio juízo do fornecedor, ou de ambos.
O segundo sinal é o incidente em si, e tem o seu próprio ciclo de vida que o indicador achata. Um incidente abre com um nome, um impacto declarado e um estado retirado de um fluxo: a investigar (vemos sintomas e ainda não sabemos a causa), identificado (sabemos a causa e estamos a trabalhar nela), a monitorizar (uma correção saiu e estamos a ver se aguenta) e resolvido (acreditamos que terminou, sujeito ao postmortem). Esses estados carregam informação que o indicador não pode carregar. Um incidente crítico que está há duas horas em monitorização está provavelmente a terminar; um incidente minor que entrou em investigação há quatro minutos pode ainda tornar-se qualquer coisa.
Leia ambos, nessa ordem, e leia as atualizações entre eles. A cronologia de atualizações curtas sob um incidente é onde o fornecedor lhe diz o que o título nunca dirá: que subsistema falhou, que solução alternativa existe, se o afetado são os dados ou só a disponibilidade, e se a próxima atualização está prometida para daí a vinte minutos ou duas horas. Um incidente cujas atualizações deixam de chegar é ele próprio um sinal —ou a equipa está sobrecarregada, o que se correlaciona com uma falha mais longa, ou o incidente foi silenciosamente dobrado dentro de um maior—. Os operadores que tiram uma captura do título e param de ler agem rotineiramente sobre a frase menos informativa da página.
Porque «todos os sistemas operacionais» pode ainda significar que você está em baixo
O indicador resume o serviço inteiro, e os serviços modernos não são uma só coisa. Um fornecedor pode estar honestamente verde a nível global enquanto a região onde implementa, a única superfície de produto que chama, a versão herdada da API a que está preso ou o plano de controlo de que precisa para uma implementação estão a falhar para cada cliente que lhes toca. As listas de componentes existem precisamente por isto: uma página como a página de estado do GitHub decompõe o serviço em operações Git, pedidos de API, Actions, Pages e mais, e qualquer um deles pode estar degradado enquanto a faixa geral continua tranquilizadora —ou o contrário, com a faixa vermelha por um componente que nunca usou—.
Há também três lacunas mais silenciosas. Primeira, o atraso de declaração: um fornecedor declara um incidente quando o confirmou, não quando ocorreu o primeiro erro, por isso os primeiros minutos de muitas falhas mostram uma página verde e um feed social a arder; a página não está a mentir, está apenas atrasada. Segunda, os limiares: um fornecedor pode tratar uma taxa de erro de dois por cento num nível como ruído normal e nunca declarar nada, enquanto esses dois por cento se concentram exatamente no seu padrão de tráfego. Terceira, o âmbito: as páginas de estado descrevem o lado do fio do fornecedor. Uma falha de DNS, um problema de encaminhamento ou um caminho bloqueado entre os seus utilizadores e um fornecedor saudável produz uma falha total para si sob um indicador verde —e é por isso que a pergunta companheira, está em baixo ou é só você, tem de ser respondida a partir de pontos de vista independentes, não a partir da própria página do fornecedor—.
A regra de trabalho é tratar o verde como «nenhum incidente declarado», nunca como «saudável provado». Quando a sua própria monitorização diz que os utilizadores estão a falhar e o fornecedor diz operacional, acredite na sua monitorização no que toca aos seus utilizadores e use a página de estado para outro trabalho: verificar se mais tarde aparece uma declaração, que confirma retroativamente a causa, e se o componente de que depende tem um histórico de incidentes com a mesma forma daquele que está a viver.
Subscreva componentes, não páginas
A maioria dos operadores subscreve uma página de estado como subscreve um boletim: uma subscrição, cada incidente, para sempre —e depois, previsivelmente, começa a ignorar o correio, porque um feed global de um grande fornecedor produz um gotejar constante de incidentes de componentes que não usa, em regiões que não serve—. A fadiga de alertas não é um defeito de caráter; é a resposta correta a um sinal mal delimitado. A correção é mecânica e está disponível em quase todas as páginas de estado maduras: subscreva ao nível do componente. O mesmo modelo da Statuspage que define os indicadores também permite aos subscritores filtrar por componente, e os fornecedores que correm os seus próprios sistemas, como a página de estado da Cloudflare, oferecem a mesma escolha através dos seus próprios fluxos de subscrição.
Delimite cada subscrição ao que realmente mudaria o seu comportamento às 3 da manhã. Os componentes que o seu tráfego de produção chama pertencem ao canal ruidoso —o que chama, manda mensagens ou pelo menos marca algo que verá em minutos—. Os componentes que usa só para construções, analítica ou ferramentas internas pertencem a um canal silencioso que revê em horas de trabalho. Os componentes que não usa não pertencem a lado nenhum: cada notificação que ignora corretamente torna a seguinte mais fácil de ignorar, incluindo a que importa. Reveja a lista sempre que a pilha mudar, porque as subscrições apodrecem nas duas direções —dependências novas a que ninguém subscreveu, e mortas que continuam a chamar um canal que ninguém vê—.
Prefira feeds legíveis por máquinas quando puder. O correio é o canal mais lento e mais ignorável que uma página de estado oferece; os webhooks e os feeds podem alimentar o seu próprio painel, abrir um bilhete interno, ou virar a página de espera preparada da sua equipa de suporte antes de chegar a primeira queixa de um utilizador. Mesmo uma versão leve compensa: o instantâneo do nosso painel de estado dos fornecedores constrói-se exatamente a partir destes feeds públicos, o que prova que os dados estão ali para serem consumidos programaticamente em vez de admirados num separador do navegador que tem de se lembrar de abrir.
Construa o seu próprio inventário de dependências
Nenhum dos conselhos acima funciona sem uma lista, e a maioria das equipas descobre durante uma falha que não tem uma. Um inventário de dependências é simplesmente a resposta escrita a uma pergunta que soa trivial e não o é: que serviços externos, se parassem esta noite, nos parariam a nós —e quais apenas nos envergonhariam—. Construa-o com bom tempo. Percorra a sua arquitetura superfície a superfície —alojamento, DNS, alojamento de código e CI, os fornecedores de base de dados e armazenamento, o processador de pagamentos, os remetentes de correio e SMS, o fornecedor de identidade, o rastreador de erros, a etiqueta de analítica, os tipos de letra e scripts que as suas páginas carregam do CDN de outro— e escreva, para cada um, o fornecedor, o componente que realmente consome, onde vive a sua página de estado, e o que os seus utilizadores experienciam quando ele falha.
Classifique cada entrada pela forma da sua falha, não pelo quanto gosta do vendedor. Algumas dependências são duras: se param, você para, e o único trabalho disponível é comunicar e esperar. Algumas são moles: o site corre sem elas, degradado —sem analítica, sem widget de chat, sem personalização— e para essas, o inventário deve dizer quem pode desligá-las e como. E algumas estão escondidas: as dependências transitivas que não escolheu, como o estado da região de nuvem onde a sua própria base de dados SaaS corre, ou a infraestrutura de certificados e DNS por baixo de tudo. As dependências escondidas são as que produzem a falha de «está tudo em baixo e nada do que pagamos está na lista», e encontra-as perguntando a cada vendedor, uma vez, de que é que ele depende.
Guarde o inventário onde um incidente o possa alcançar: no runbook, junto à lista de escalação, não numa página wiki que ninguém pode abrir quando o fornecedor de identidade é precisamente o que está em baixo. Uma página chega. O seu trabalho durante uma falha é transformar «algo está errado» numa lista de verificação —por cada dependência dura, acima ou abaixo, em trinta segundos— e o seu trabalho depois é ser corrigido, porque cada incidente real lhe ensina algo sobre uma dependência que tinha classificado mal. Um inventário que nunca é corrigido é um documento histórico, não operacional.
Os primeiros dez minutos de uma falha de fornecedor
Do minuto zero ao dois: confirme e localize. Verifique a sua própria monitorização para se certificar de que a falha é real e sua para anunciar, e depois abra o painel de estado e a página do fornecedor suspeito. Está a responder a uma pergunta: há um incidente declarado que se cruze com o que usa —componente, região, produto—? Se houver, tem a sua causa e a sua primeira mensagem. Se não houver, alargue a verificação: outro fornecedor do seu inventário, a sua última implementação, o seu DNS. A maioria dos dramas falsos morre nestes dois minutos, e a maioria dos reais ganha aqui a sua forma.
Do minuto dois ao cinco: comunique, com clareza e cedo. Conte aos seus utilizadores, nos canais que realmente leem, que um fornecedor externo nomeado está a ter um incidente, o que isso significa para eles em termos práticos —o que não funciona, o que continua a funcionar, se os seus dados estão seguros— e quando voltará a atualizar. Uma mensagem de espera honesta enviada no minuto quatro vence uma explicação precisa enviada no minuto quarenta, porque o silêncio é o que os utilizadores preenchem com os seus piores palpites e os nomes dos seus concorrentes. Internamente, abra um único fio de incidente, nomeie uma só pessoa para falar, e carimbe tudo com a hora; agradecerá a si mesmo no postmortem, e a equipa de suporte do fornecedor também, se precisar deles.
Do minuto cinco ao dez: pare de piorar e prepare as aterragens suaves. Congele as implementações —uma mudança feita dentro de um incidente ativo de um fornecedor externo não pode ser avaliada e pode nem sequer poder ser revertida—. Desligue as novas tentativas agressivas e os trabalhos não essenciais que martelam o fornecedor que falha; a recuperação é mensuravelmente mais lenta quando dez mil clientes tentam de novo em uníssono, e alguns fornecedores limitá-lo-ão até uma segunda falha, desta vez autoinfligida. Desligue ou degrade as dependências moles que o seu inventário marcou como descartáveis, publique a página de espera se tiver uma, e depois entre no ritmo que o incidente ditar: monitorize as atualizações do fornecedor, atualize os seus utilizadores às horas prometidas haja ou não notícias, e não mude mais nada a menos que os factos mudem. A falha terminará no horário do fornecedor, não no seu; os seus dez minutos decidem se os seus utilizadores a recordam como o mau dia do fornecedor deles ou como o seu.