Diário
Um diário de engenharia. Incidentes ganham um relatório pós-incidente com timestamps reais, decisões de hardware ganham os números que as motivaram, e mudanças de política ganham a justificativa, mesmo quando ela nos faz parecer lentos. Nada aqui foi escrito por um departamento de marketing, o que fica óbvio em um parágrafo.
O que vai parar aqui
Já escrevíamos essas notas de qualquer forma. Alguém tem que explicar ao próximo engenheiro por que as duas metades de um espelho vêm de caixas de entrega diferentes, e uma vez escrito isso, não há um bom argumento para mantê-lo atrás de um login.
Cinco categorias. Anúncios de produto disfarçados de insight não estão entre elas.
Você não encontrará um tutorial aqui. Guias pertencem à [seção de guias](/guides), e material de referência pertence à [base de conhecimento](/docs). Misturar os três produz um blog que ninguém consegue pesquisar. O estado atual da frota está na [página de status](/status), que atualiza sem que ninguém escreva prosa a respeito.
Incidente
Algo quebrou e os clientes notaram. Publicado em até dez dias úteis, timestamps em UTC, causa nomeada no primeiro parágrafo. Quando a causa fomos nós, o post diz isso antes de qualquer outra coisa.
Hardware
O que compramos, o que medimos e o que recusamos. Migrações de geração, famílias de drives e a linha ocasional que permanece uma geração atrás de propósito porque o componente mais novo não ajuda na carga de trabalho.
Rede
Trânsito, peering, filtragem, endereçamento. É aqui também que os números que outros hosts mantêm vagos são impressos, começando pelo que significa sem limite antes que alguém envie um e-mail sobre isso.
Plataforma
O painel, a fila de provisionamento, a API, novos sites. Notas de capacidade também ficam aqui, incluindo as pouco glamorosas que explicam por que uma cidade específica é racionada em vez de expandida.
Política
Mudanças no que vendemos, no que mantemos e no que recusamos fazer. Deletar o plano barato ainda é o post mais lido deste site, cinco anos depois de ter sido escrito.
Como um incidente é escrito
Um estilo editorial não é uma escolha estética. Ele nos impede de reorganizar silenciosamente uma semana ruim em uma história mais bonita, porque a seção que precisaria ser deletada se torna conspícua pela ausência.
Mesmos cinco cabeçalhos, mesma ordem, sempre.
- 01
Resumo
O que quebrou, por quanto tempo, e quem foi afetado, em menos de sessenta palavras. Se você ler apenas isso, ainda deve saber se te afetou.
- 02
Linha do tempo
Timestamps em UTC, do primeiro sintoma à recuperação total, incluindo os minutos gastos procurando no lugar errado. Esses minutos geralmente são a parte interessante do documento.
- 03
Causa raiz
O mecanismo, não a categoria. Erro humano não é causa raiz. Uma regra de classificação escrita em 2023 que permitiu que uma mudança de esquema pulasse o estágio canário é uma causa raiz, e ela tem um responsável.
- 04
O que mudamos
Concreto, datado, verificável. Cada item é algo que um cliente poderia nos pedir para demonstrar em uma chamada, e duas vezes alguém já pediu.
- 05
O que não mudamos, e por quê
A seção que a maioria das empresas omite. Às vezes, a correção óbvia custa mais privacidade do que a falha te custou, e preferimos discutir isso em público do que resolver em silêncio.
“São três da manhã aqui e sua página de status diz que o site está ok. O site não está ok.”
Post-mortems são publicados mesmo quando ninguém pediu e mesmo quando o cliente afetado nunca percebeu. Dois deles descrevem créditos que pagamos sem que o SLA nos obrigasse, o que é o tipo de coisa que você só escreve uma vez.
Lendo o arquivo
Dezesseis posts, seis anos e meio, uma lacuna conspícua.
A lacuna vai do final de 2019 a outubro de 2020. Estávamos montando racks, não escrevendo, e a coisa que finalmente produziu um post foi um ataque que tirou Amsterdã da rede por onze minutos. Esse é um padrão comum neste ramo: o hábito de documentar começa no dia em que algo caro dá errado.
Posts antigos nunca são editados no lugar. Quando uma afirmação se mostrou errada, a correção é anexada com sua própria data e a frase original permanece exatamente onde estava. Um post que se melhora silenciosamente ao longo do tempo não vale nada para quem o lê.
| Período | O que estávamos fazendo | O que está documentado |
|---|---|---|
| 2019 – 2020 | Quatro sites acesos em oito semanas, depois mais seis em um ano de pandemia | Dois posts. Uma nota de fundação e um pedido de desculpas. |
| 2021 – 2022 | Tier barato removido, IPv6 por padrão, Zen 4 encomendado, Reykjavík inaugurado | Quatro posts, incluindo o mais citado. |
| 2023 – 2024 | Canário, GPUs, Zen 5, e um lote de drives que falhou em conjunto | Cinco posts, um deles um pedido de desculpas com reembolso anexado. |
| 2025 – 2026 | Provisionamento reescrito, Zurique racionado, API aberta, Joanesburgo montada em rack | Cinco posts e mais um post-mortem. |
Plataforma
05Rede
03Incidente
03Hardware
03Política
02Perguntas sobre o próprio diário
Um feed Atom, linkado no rodapé desta página, sem pixel de rastreamento e sem lista de e-mail acompanhante. Se você quer uma newsletter, terá que querer em outro lugar.
Não. Tudo aqui foi escrito por alguém que pode ser acionado, que é o objetivo de existir.
Porque deletá-las seria desonesto. Correções são anexadas e datadas abaixo do texto original, para que você veja tanto o que pensávamos quanto quando deixamos de pensar isso.
Sim, incluindo as partes que nos fazem parecer mal, e especialmente essas. Atribuição e um link são suficientes; nenhuma permissão é necessária e nenhuma será concedida de forma mais formal do que esta frase.
Se mais de um cliente foi afetado, já está aqui ou está sendo rascunhado. Falhas de instância única são respondidas no ticket, porque um post-mortem sobre um drive morto não ajuda ninguém.
O hardware é mais interessante do que a escrita
Cada afirmação nestes posts é testável em um servidor que você pode ter em menos de um minuto. Escolha uma cidade, escolha um tamanho, pague em coin e verifique os números você mesmo.