El problema
La revisión post-incidente se suele escribir una semana después, de memoria, por la persona que más trabajo tuvo en el puente. Para entonces la línea de tiempo es una suposición, y las preguntas que cambiarían algo la próxima vez no se hacen. El service desk había recibido decenas de llamadas por el login antes de que nadie en IT lo supiera, y ninguna alerta saltó hasta mucho después de la detección. Una alerta de la cola de pagos saltó a las dos y diez y nadie actuó hasta las tres. La mesa de trading pasó hora y media sin una actualización y nunca recibió el aviso de resolución. El cambio de la noche anterior fue la causa, y el ticket no lo dice. La acción que habría detectado la caída del login lleva un mes vencida. Los datos están en la herramienta ITSM, las consolas de monitorización, el chat del puente y la bandeja de enviados; la revisión que importa los junta por incidente y los mide contra la política que el equipo se comprometió a cumplir.
Qué he hecho
- Detección: la primera alerta sobre el servicio o el CI frente al primer aviso de los usuarios y el ticket, con los puntos ciegos (avisan los usuarios, sin alerta) y las alertas que nadie atendió.
- Respuesta: el tiempo hasta la asignación, la mitigación y la resolución frente a los objetivos de cada prioridad, y si constan un incident commander, un responsable de comunicaciones y un responsable técnico.
- Comunicaciones: una actualización a los interesados cada N minutos según la política, la primera tarde, los huecos y el aviso de resolución que falta.
- Antes y después: cambios en el servicio en las 72 horas previas al impacto, la revisión post-incidente en N días laborables, la causa raíz en el registro de problema, las acciones vencidas y los incidentes que vuelven en el mismo CI en 30 días.
report.htmlcon una línea de tiempo por incidente en SVG, un borrador de revisión post-incidente por cada incidente mayor con las partes que solo pueden escribir las personas bien marcadas, y CSV de incidentes, MTTD/MTTA/MTTM/MTTR por mes y prioridad, huecos de comunicación, acciones vencidas y repeticiones.- Un comando
startque imprime la tarjeta de roles, el checklist de los primeros quince minutos y la primera comunicación para un incidente nuevo, y un exportador de solo lectura en PowerShell para ServiceNow y Jira Service Management.
Cómo está hecho
Python solo con la librería estándar. La demo es el equipo de operaciones IT de un banco inventado durante un trimestre: 54 incidentes, seis de ellos mayores, en pagos con tarjeta, banca online, voz de trading, la API móvil, el hub de pagos y datos de mercado, con alertas de cinco herramientas de monitorización, cambios, líneas de tiempo del puente, comunicaciones, problemas y acciones, y los problemas puestos a propósito. 15 tests, un runbook para los primeros quince minutos y la revisión semanal, y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.
Qué aprendí
De liderar la respuesta técnica en incidentes mayores y los post-mortems que vinieron después, y de ser responsable de los procesos de incidencias, cambios y problemas. Uno de ellos fue la caída de una línea de voz que usaba una mesa de trading en una empresa de servicios financieros: la solución fue técnica, pero lo que la mesa recordaba era cada cuánto tenía noticias nuestras. Las lecciones que dan forma a la herramienta son que la detección empieza con la primera señal, no con el ticket; que una actualización sin novedades sigue siendo una actualización; que un cambio en los días previos es sospechoso hasta que la revisión lo descarta; y que una revisión sin responsable y fecha para cada acción es una reunión, no una revisión.
Siguientes pasos
- Ejecutarlo con las exportaciones reales del último trimestre y ajustar los objetivos, el intervalo de comunicaciones y los días para la revisión con los responsables de incidentes mayores.
- Leer las alertas de las APIs de monitorización y las comunicaciones del plan de comunicación en lugar de dos CSV.
- Escribir el borrador de revisión en el registro de problema, y llevar los puntos ciegos y las acciones vencidas a la revisión mensual de servicio.
¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.
The problem
The post-incident review is usually written a week later, from memory, by the person who was busiest on the bridge. By then the timeline is a guess, and the questions that would change something next time are not asked. The service desk had dozens of calls about logins before anyone in IT knew, and no alert fired until well after detection. An alert on the payments queue fired at ten past two and nobody acted until three. The trading desk went an hour and a half without an update and never got the resolution notice. The change the night before was the cause, and the ticket does not say so. The action that would have caught the login outage is a month overdue. The facts are in the ITSM tool, the monitoring consoles, the bridge chat and the sent folder; the review that matters joins them per incident and measures them against the policy the team signed up to.
What I built
- Detection: the first alert on the service or CI against the first user report and the ticket, with blind spots (users first, no alert) and alerts nobody acted on.
- Response: time to acknowledge, mitigate and resolve against the targets of each priority, and whether an incident commander, a comms lead and a tech lead were recorded.
- Communications: a stakeholder update every N minutes as the policy says, the first one late, the gaps, and the missing resolution notice.
- Before and after: changes on the service in the 72 hours before the impact, the post-incident review within N business days, the root cause in the problem record, overdue actions, and incidents that came back on the same CI within 30 days.
report.htmlwith a timeline per incident as inline SVG, one draft post-incident review per major incident with the parts only people can write clearly marked, and CSVs for the incidents, MTTD/MTTA/MTTM/MTTR by month and priority, comms gaps, overdue actions and repeats.- A
startcommand that prints the role card, the first-fifteen-minutes checklist and the first stakeholder update for a new incident, and a read-only PowerShell exporter for ServiceNow and Jira Service Management.
How it is built
Python with the standard library only. The demo is the IT operations team of a made-up bank over one quarter: 54 incidents, six of them major, on card payments, online banking, trader voice, the mobile API, the payments hub and market data, with alerts from five monitoring tools, changes, bridge timelines, stakeholder updates, problems and actions, and the problems placed on purpose. 15 tests, a runbook for the first fifteen minutes and the weekly review, and a GitHub Actions workflow that runs the tests and rebuilds the demo data and the screenshot.
What I learned
From leading the technical response in major incidents and the post-mortems that followed, and from owning the incident, change and problem processes. One of them was the outage of a voice line used by a trading desk at a financial services firm: the fix was technical, but what the desk remembered was how often they heard from us. The lessons that shaped the tool are that detection starts at the first signal, not at the ticket; that an update with nothing new is still an update; that a change in the days before is a suspect until the review rules it out; and that a review without an owner and a date for each action is a meeting, not a review.
Next steps
- Run it on last quarter's real exports and tune the targets, the update interval and the review days with the major incident managers.
- Read the alerts from the monitoring APIs and the updates from the communication plan instead of two CSVs.
- Write the draft review into the problem record, and bring the blind spots and overdue actions to the monthly service review.
Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →