No número anterior falei de desastres, hecatombes e catástrofes, e usei case seiscentas palabras en tratar de vos convencer de o máis importante non é poñerse a buscar a unha persoa á que lle endosar toda a culpa e toda a responsabilidade, senón facer unha investigación das causas do problema e de como evitalo no futuro: a análise postmórtem.
Xa que estou, quero facer notar que a maioría das análises postmórtem fanse porque algo ocorreu mal, pero iso non é sempre así: ás veces fanse porque algo saíu mellor do que esperabamos, e outras veces fanse por sistema. Nesta Folla vou imaxinar que queremos facer unha análise postmórtem dun fallo, que é o caso máis habitual.
O primeiro paso do proceso é recadar información. Tan pronto como sexa posible (incluso durante o suceso), alguén debería encargarse de gardar todos os chats, documentos, emails e outras cousas que conteñan información relacionada co fallo. Tamén alguén debería entrevistar á xente involucrada no asunto o antes posible: a memoria humana é falible e a xente esquece cousas ou comeza a lembralas incorrectamente case de inmediato.
De seguido, despois de solucionar o problema, é cando comezamos a propia análise e a escritura do informe postmórtem. Case sempre imos facer as dúas cousas ao mesmo tempo, guiando a análise pola estrutura do informe, pero en investigacións de sucesos moi graves ou complicados pode ser necesario facer a investigación primeiro e o informe despois.
Comezamos o informe falando do fallo que nos levou a facer a análise postmórtem. Para escribir esta sección, a min gústame contestar tres preguntas: “que pasou?”, “como pasou?” e “por que pasou?”
Para contestar “que pasou”, escribide un parágrafo explicativo do problema do que trata esta análise (“o sistema web parou de servir peticións durante 50 minutos”) e despois escribide unha liña temporal detallada (“ás 08:47 chegou a primeira alerta, ás 08:51 a persoa que estaba de garda tentou reiniciar o servizo”, etc).
Para contestar “como pasou”, poñede o chapeu de técnicos e falade de como se encheu o disco duro, o servidor parou de responder, os outros tentaron recoller a carga pero fallaron tamén, etc.
Para contestar “por que pasou”, facede como que tedes tres anos e preguntade “por que” a todo: “Por que se encheu o disco duro?” “Porque había unha morea de ficheiros temporais vellos.” “Por que?” “Porque o proceso que os limpaba non funcionou.” “Por que?” “Porque non tiña os permisos necesarios.” “Por que?” “Porque llos quitou o instalador do xogo de xadrez.” “E por que instalou alguén un xogo de xadrez no servidor?”, etc.
Na segunda parte do informe falamos do que se fixo ben e do que se fixo mal. Por unha banda, as cousas nas que houbo boa sorte, intervencións que funcionaron e medidas preventivas que impediron que o problema fora a máis; pola outra banda, os atrancos, confusións, ferramentas que non funcionaron, mala sorte e, en xeral, todo o que empeorou o problema.
Na terceira parte do informe falamos das leccións aprendidas e as medidas que imos tomar para impedir que este problema volva ocorrer ou para diminuír o seu impacto se sucede outra vez.
E con isto xa está feita a análise postmórtem e o seu informe. En serio, non ten máis! O obxectivo do proceso é aprender e deixar constancia do aprendido, non castigar a ninguén, así que non ten sentido facelo máis complicado do necesario.
Se queredes un exemplo, podedes ver este informe dun fallo de App Engine alá no ano 2010. É practicamente igual ao informe interno, excepto polos detalles confidenciais, así que podedes usalo de guía nos vosos postmórtems.
A ilustración desta Folla é un gravado de José Guadalupe Posada.
1 comentario