16 de janeiro, o incidente; só em 10 de março foi publicado o post-mortem. No meio, por 53 dias, a equipe oficial esteve fazendo o quê? Essa foi a minha maior dúvida antes de eu ler o Post-Mortem.
Transcrevi os marcos temporais do post-mortem para um bloco de notas: o ataque ocorreu em 16 de janeiro; ainda naquela noite, a principal cadeia suspendeu o serviço de ponte; no fim de janeiro, foram concluídos a consolidação dos fundos e a verificação dos endereços afetados; em 10 de março, foi publicado o post-mortem completo. Antes de transcrever $DUSK , eu conferi o carimbo de atualização na página de publicação para confirmar que nenhuma versão intermediária tinha sido retirada. No terceiro registro eu parei: dentro desses 53 dias, a equipe oficial só atualizou o status duas vezes — uma no dia do incidente e outra no dia da publicação do post-mortem.
Abri o calendário e contei: de 16 de janeiro a 10 de março são 53 dias, com 2 atualizações; em média, só se mexeu a cada 26,5 dias. No fim de janeiro, aquela rodada de consolidação dos fundos e verificação de endereços — tudo foi apenas completado no post-mortem; na época, não houve uma palavra sequer para o público. Eu dividi esses 53 dias em quatro blocos: congelamento em nível de horas; verificação em nível de dias; causa raiz em nível de semanas; e o post-mortem, somado à auditoria interna, ocupou mais de um mês. Os três primeiros blocos ficaram vazios, e só no último é que começaram a falar. Essa é a conta que eu fiz — e também o lugar em que eu senti que havia algo errado desde o começo.
Mas, quando abro esses quatro blocos, o silêncio não significa incompetência. Congelar em nível de horas (@Dusk ) quer dizer que, no mesmo dia do incidente, o risco foi cortado para não se espalhar; verificação em nível de dias quer dizer que a reconciliação por transação não atrasou; causa raiz em nível de semanas quer dizer que a conclusão pode ser verificada, não é um “achismo”. Cada etapa tem uma ação clara — apenas não houve atualização pública.
Também comparei o modo como as recentes ocorrências de ponte foram tratadas: em alguns projetos, no dia seguinte ao incidente já apagaram o Twitter; em outros, atrasaram por meio ano e publicaram um comunicado sem detalhes; e há também os que simplesmente não respondem. Depois de comparar, fiquei ainda mais certo: o processo é a matéria-prima da confiança — e este post-mortem é um dos poucos que expõe, de forma completa, a linha do tempo, as causas e as medidas.
Por isso, agora vou ficar de olho em uma coisa: na próxima vez que acontecer, de do evento até o post-mortem, haverá algum tipo de atualização processual no meio? A frequência das atualizações é o padrão de medida da transparência. Não adianta falar o quanto quiser; nada supera a honestidade dos carimbos de tempo. #dusk
Transcrevi os marcos temporais do post-mortem para um bloco de notas: o ataque ocorreu em 16 de janeiro; ainda naquela noite, a principal cadeia suspendeu o serviço de ponte; no fim de janeiro, foram concluídos a consolidação dos fundos e a verificação dos endereços afetados; em 10 de março, foi publicado o post-mortem completo. Antes de transcrever $DUSK , eu conferi o carimbo de atualização na página de publicação para confirmar que nenhuma versão intermediária tinha sido retirada. No terceiro registro eu parei: dentro desses 53 dias, a equipe oficial só atualizou o status duas vezes — uma no dia do incidente e outra no dia da publicação do post-mortem.
Abri o calendário e contei: de 16 de janeiro a 10 de março são 53 dias, com 2 atualizações; em média, só se mexeu a cada 26,5 dias. No fim de janeiro, aquela rodada de consolidação dos fundos e verificação de endereços — tudo foi apenas completado no post-mortem; na época, não houve uma palavra sequer para o público. Eu dividi esses 53 dias em quatro blocos: congelamento em nível de horas; verificação em nível de dias; causa raiz em nível de semanas; e o post-mortem, somado à auditoria interna, ocupou mais de um mês. Os três primeiros blocos ficaram vazios, e só no último é que começaram a falar. Essa é a conta que eu fiz — e também o lugar em que eu senti que havia algo errado desde o começo.
Mas, quando abro esses quatro blocos, o silêncio não significa incompetência. Congelar em nível de horas (@Dusk ) quer dizer que, no mesmo dia do incidente, o risco foi cortado para não se espalhar; verificação em nível de dias quer dizer que a reconciliação por transação não atrasou; causa raiz em nível de semanas quer dizer que a conclusão pode ser verificada, não é um “achismo”. Cada etapa tem uma ação clara — apenas não houve atualização pública.
Também comparei o modo como as recentes ocorrências de ponte foram tratadas: em alguns projetos, no dia seguinte ao incidente já apagaram o Twitter; em outros, atrasaram por meio ano e publicaram um comunicado sem detalhes; e há também os que simplesmente não respondem. Depois de comparar, fiquei ainda mais certo: o processo é a matéria-prima da confiança — e este post-mortem é um dos poucos que expõe, de forma completa, a linha do tempo, as causas e as medidas.
Por isso, agora vou ficar de olho em uma coisa: na próxima vez que acontecer, de do evento até o post-mortem, haverá algum tipo de atualização processual no meio? A frequência das atualizações é o padrão de medida da transparência. Não adianta falar o quanto quiser; nada supera a honestidade dos carimbos de tempo. #dusk