Sua status page deveria ter se escrito uma hora atrás
A comunicação de incidente é escrita por último, pela pessoa mais estressada da sala, quando deveria ser a primeira coisa que um sistema rascunha no instante em que os sinais divergem.
Apollo Space Research
Apollo Space
O gráfico ficou vermelho às 9h14. A status page atualizou às 10h02. Nos quarenta e oito minutos entre os dois, trezentos clientes deram refresh numa página verde que mentia para eles, dois deles tuitaram, um deles abriu um ticket de suporte que dizia “é só comigo?”, e o único engenheiro capaz de resolver a queda passou onze desses minutos não resolvendo, porque alguém tinha que escrever o update, e ele era esse alguém.
Esse gap não é um gap de tooling. O monitoramento funcionou. O alerta disparou. A página tem um botão de editar. O gap é que a mensagem que o cliente mais precisava ouvir foi a última coisa de que alguém se lembrou, escrita pela pessoa menos capaz de dedicar atenção, no exato momento em que atenção era o recurso mais escasso do prédio.
Este post é sobre fechar esse gap pelo lado errado.
A mensagem é escrita por último, pela pessoa mal posicionada
Aqui está a ordem em que os incidentes realmente acontecem, em quase toda empresa. O sinal diverge. Um humano percebe. O humano começa a debugar. Em algum ponto, um segundo humano, ou o mesmo primeiro humano exausto, lembra que clientes existem, e que a coisa certa a fazer é contar algo a eles. Então ele para, abre um doc ou um editor de status page, e encara uma caixa em branco enquanto o incidente segue queimando atrás dele.
A comunicação de incidente é escrita por último, pela pessoa mais estressada, quando deveria ser a primeira coisa que um sistema rascunha no instante em que os sinais divergem.
Leia essa ordem de novo, porque ela está exatamente de cabeça para baixo. A comunicação tem a dependência mais frouxa do fix, você pode dizer a um cliente “vimos, estamos cuidando” antes de ter a menor ideia do que é “isso”. E mesmo assim ela é agendada atrás do fix, atrás da triagem, atrás da correria da war-room, no único slot em que a pessoa que a escreve tem a menor bandwidth e o maior risco. O artefato que precisa do autor mais calmo recebe o mais abalado.
O resto deste post é sobre inverter essa ordem: tornar o rascunho a primeira coisa que existe, não a última.
Ingênuo: uma status page é uma caixa que um humano lembra de preencher
A história ingênua da comunicação de incidente é a que quase todo mundo vive. Você tem uma status page. É um sistema de gerenciamento de conteúdo com uma URL pública. Quando algo quebra, um humano deve fazer login, escolher uma severidade, escrever uma frase e publicar. Depois, deve voltar e postar updates, e no final, postar o tudo-resolvido.
Funciona na demo. Falha no incidente, por três razões que todas rimam.
Falha porque lembrar é um trabalho humano no pior momento humano. Durante uma queda, a página é mais uma coisa competindo por um cérebro já sobrecomprometido com o fix. “Atualizar a status page” é uma tarefa sem dono no instante em que as mãos do plantonista estão cheias, e durante um incidente real, sempre estão.
Falha porque a caixa em branco é lenta. Mesmo quando alguém lembra, agora tem que compor. Qual a severidade? O que dizemos sem prometer demais? Quais sistemas estão afetados, exatamente? São três decisões e uma tarefa de escrita, serializadas, enquanto o relógio corre e clientes dão refresh.
E falha porque a página só sabe o que um humano digita nela. O sistema de monitoramento já sabia, às 9h14, que a latência tinha triplicado no caminho de checkout. A status page não sabia, porque nada conectava a coisa que detectou o problema à coisa que o anuncia. Dois sistemas, uma parede entre eles, e a parede é operada por uma pessoa sob estresse máximo.
A página não está quebrada. Ela está apenas downstream de um humano que, naquele momento, é a ferramenta errada para o trabalho.
O reframe: a divergência é o gatilho, não o humano
O fix não é um humano mais rápido ou uma caixa em branco melhor. O fix é perceber que o gatilho já existe, e não é uma pessoa lembrando.
O gatilho é a divergência. O momento em que o sinal se afasta do normal, latência triplicando, taxa de erro subindo, uma fila acumulando, um provedor de pagamento dando timeout, esse é o evento. Um humano percebendo a divergência é um segundo evento, mais lento, não confiável, sobreposto ao real. Estamos ligando nossa comunicação ao evento lento quando o rápido estava bem ali.
Então inverta. No momento em que os sinais divergem, um sistema rascunha a mensagem. Não publica, rascunha. Ele lê o que o monitoramento já sabe, escreve a frase voltada ao cliente que um humano teria escrito, escolhe a severidade provável, lista as superfícies afetadas pelo nome, e coloca tudo diante de um humano como uma coisa quase finalizada com um botão: publicar, ou resolver isso primeiro.
A caixa em branco vira uma caixa cheia. O lembrar vira automático. E os onze minutos que o engenheiro passou compondo viram onze minutos resolvendo, porque o compor já aconteceu, no instante em que o gráfico virou, por um sistema que não se abala.
Esse é o mesmo movimento que a Apollo faz em todo lugar: o sistema fala primeiro, e o trabalho do humano muda de produzir a coisa para aprovar a coisa. Um rascunho que você rejeita em quatro segundos te custou quatro segundos. Uma caixa em branco que você tem que preencher durante uma queda te custa a queda.
Por que um rascunho, e não um auto-publish
Há uma supercorreção tentadora aqui, e vale matá-la antes que se espalhe. Se o sistema consegue escrever o update, por que não deixá-lo publicar o update? Pular o humano por completo. Divergência entra, status page sai, totalmente automático.
Porque comunicação de incidente é exatamente onde você não quer automação total, e a razão é o falso positivo. Monitoramento dispara em coisas que não são incidentes, um blip de deploy, um health check barulhento, um soluço regional que se cura sozinho em noventa segundos. Um sistema que publica sozinho transforma cada um desses num “estamos com problemas” público que assusta clientes sobre uma queda que nunca houve. Você treinaria seus usuários a ignorar a página, o que é pior do que não ter uma.
O rascunho é a unidade certa porque divide o trabalho na linha onde máquinas e humanos são cada um forte. A máquina é boa na parte que é lenta e mecânica sob estresse: perceber instantaneamente, ler os sinais, compor a frase, montar a lista de sistemas afetados. O humano é bom na parte que é rápida e de alto julgamento: isso é real, e queremos dizer isso em voz alta agora? Uma olhada, uma decisão, um botão.
A máquina escreve o rascunho. O humano é dono do publish.
Essa divisão é o design inteiro. Não é “deveríamos deixar a IA conduzir o incidente”, ninguém sério quer isso. É “o humano deveria começar de uma caixa em branco ou de um rascunho quase final, durante o único momento em que ele tem menos tempo para escrever”. Posto assim, não é uma decisão difícil.
E o rascunho continua ficando melhor em ser rascunho. O mesmo sistema que observa os sinais também observa quais rascunhos o humano publicou como estavam e quais ele reescreveu, então o rascunho do próximo incidente soa mais como seu time e menos como um robô, sem ninguém ajustar um template.
O mesmo gap, em todo lugar onde um humano é o mensageiro
Quando você enxerga o formato, vê que não é realmente sobre status pages. A status page é a instância mais visível de um padrão que percorre toda empresa: uma mensagem que deveria viajar na velocidade do evento viaja na velocidade de um humano cansado lembrando de enviá-la.
A versão interna é o ping da war-room que sai vinte minutos atrasado, então metade da empresa debuga um problema que a outra metade já conhece. A versão do stakeholder é o executivo que ouve sobre a queda de um cliente em vez do próprio time, porque o update que deveria ter chegado a ele ficou na fila atrás do combate ao incêndio. A versão do follow-up é o postmortem que está “ainda sendo escrito” três semanas depois, quando as únicas pessoas que lembram da timeline já passaram para o próximo incêndio.
Cada um desses é o mesmo defeito. A comunicação é tratada como algo que uma pessoa produz depois do trabalho real, quando poderia ser algo que um sistema rascunha a partir do trabalho real, no momento em que o trabalho começa. Suponha que um incidente típico consuma, digamos, trinta minutos da atenção de um engenheiro em comunicação, o update da war-room, a status page, a nota ao stakeholder, a timeline para o eventual relatório. São trinta minutos da sua pessoa mais afiada não resolvendo a coisa que ela é unicamente capaz de resolver. Não porque a escrita fosse difícil. Porque nada a iniciou por ela.
O custo não é a digitação. O custo é quando a digitação acontece, no pico do incidente, pela pessoa no caminho crítico, em vez de no vale do evento, por um sistema que nunca esteve no caminho crítico.
A virada: a voz mais calma da sala não deveria ser uma pessoa
Aqui está a parte que não é sobre incidentes.
A razão de esse gap doer é que decidimos silenciosamente que a pessoa mais estressada da sala deveria também ser a voz da empresa em seu pior momento. Entregamos a escrita da mensagem voltada ao cliente, a que decide se a confiança sobrevive à queda, ao humano cujas mãos estão mais fundas no fracasso e cuja adrenalina está mais alta. Chamamos isso de ownership. Na verdade é uma armadilha para a pior mensagem no pior momento.
A promessa aqui não é “a IA conduz seus incidentes.” Ninguém capaz quer isso, e a linha rascunho-não-publish está lá precisamente para recusá-la. A promessa é mais estreita e mais humana: a pessoa que pode resolver a coisa consegue passar o incidente resolvendo a coisa, porque a mensagem que precisava ser escrita já foi escrita, com calma, por algo que começou no instante em que o gráfico ficou vermelho, e esperou um humano dizer sim, envie.
Uma empresa que se comunica na velocidade de seus eventos em vez da velocidade de seu humano mais sobrecarregado não é software mais rápido. É uma empresa onde estar sob pressão não significa mais estar em silêncio, e onde o cliente ouve “vimos” enquanto o engenheiro ainda está lendo o trace, não quarenta e oito minutos depois.
É isso que estamos construindo na Apollo Space, um operating system para empresas onde o rascunho proativo é o default, para que a mensagem que mais importa seja a primeira coisa que existe, não a última de que alguém se lembra. Se você já publicou um update de status com as mãos tremendo enquanto o fix real esperava, você já sabe que o update deveria ter se escrito uma hora atrás. Ele estava esperando um gatilho que você já havia ligado. Só não tinha permissão de ser o que importava.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaA morte lenta da voz de um marketeiro
Você publica uma peça real por semana e silenciosamente a traduz em dez, e cada tradução é uma pequena chance de soar um pouco menos como você mesmo. Construímos o OS porque nada no mercado estava guardando isso.
Pensamento de ProdutoNo dia em que alguém pede demissão, sua empresa esquece como ela funciona
Onboarding não está quebrado porque o treinamento é ruim. Está quebrado porque sua empresa não consegue lembrar, e cansamos de ver a resposta sair pela porta.
Pensamento de ProdutoA primeira coisa que um novo contratado deveria fazer é ler a empresa
Um ótimo onboarding não te entrega docs, ele já sabe quem você é quando você faz login.