No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Introducción a Incident Response

16/21
Recursos

¿Quién debería manejar los incidentes en una compañía?

A menudo se asume que los operadores deben gestionar todos los incidentes en una compañía, pero, ¿es realmente eficaz? Muchos expertos y empresas están empezando a desafiar esta convención. Se plantea que los mismos desarrolladores que envían el software a producción deberían también encargarse de manejar sus propios incidentes. Esta estrategia ofrece diversas ventajas:

  • Responsabilidad directa: Los desarrolladores tienen una comprensión más profunda del código subyacente y pueden reaccionar de manera más eficiente.
  • Comunicación clara: Al involucrar al equipo original, se evitan distorsiones en la transferencia de información.
  • Mejora continua: Los incidentes se convierten en oportunidades de aprendizaje directo, lo que impulsa mejoras continuas y la calidad del software.

Por ello, herramientas como PagerDuty resultan indispensables, ya que permiten gestionar alertas y notificaciones de manera efectiva, incluso activando escalaciones cuando el personal designado no responde.

¿Cómo responder adecuadamente a un incidente?

Responder a un incidente requiere de un proceso bien definido para asegurar que se maneje de manera eficiente y reducir al mínimo el impacto. Aquí te presentamos un enfoque paso a paso de cómo actuar cuando surge un incidente:

  1. Evaluación inicial (Triage):

    • Determina el impacto del incidente. ¿Es crítico? Si el impacto es mínimo, podrías decidir resolverlo posteriormente.
    • Abre un canal de comunicación con tu equipo para documentar cada paso y evitar repeticiones innecesarias.
  2. Notificación a clientes:

    • Comunica el estado del incidente a tus clientes, incluso si es solo para informar que estás trabajando en ello.
    • Las páginas de estado son vitales para ofrecer actualizaciones confiables y reducen la ansiedad de los usuarios.
  3. Documentación y proceso de mejoras:

    • Lleva un timeline detallado de las acciones realizadas. Esto no solo será útil durante el incidente, sino para la fase de análisis post-incidente.
    • No olvides documentar tanto las soluciones implementadas como las acciones futuras para evitar repetir los mismos errores.

¿Por qué es importante escribir un postmortem?

Un postmortem no es simplemente una revisión de un incidente; es una oportunidad valiosa para aprender y mejorar. Consiste en realizar un análisis exhaustivo de qué salió mal, por qué ocurrió y cómo prevenirlo en el futuro. Aquí te presentamos los elementos esenciales de un postmortem eficaz:

  • Explicación detallada: ¿Qué salió mal y por qué?
  • Identificación de fallos previos: ¿Cómo podrías haber identificado el problema antes?
  • Plan de acción: ¿Qué medidas se implementarán para prevenir futuros eventos similares?
  • Educación organizacional: Compartir el postmortem internamente asegura que todos los equipos aprendan de la experiencia y fortalece la cultura de prevención.

Pagder Duty ofrece excelentes recursos y ejemplos sobre cómo estructurar un postmortem. Además, compañías como Outzettle publican incidentes significativos, ofreciendo contexto técnico y disculpándose con los clientes, lo que refuerza la confianza en su compromiso con la mejora continua.

Dado que las empresas están en constante crecimiento y evolución, la documentación interna se vuelve crucial para que cualquier lección aprendida esté fácilmente disponible para nuevos miembros del equipo, asegurando que los errores no se repitan. Así que, aunque redactar un postmortem puede parecer tedioso, es una inversión en inteligencia organizacional y una herramienta poderosa para evitar que tu teléfono suene otra vez por la misma razón.

Aportes 11

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Que hacer cuando suena el teléfono:

  1. Mide el alcance del error (Mide el impacto del error).
  2. Comunícate con el cliente y compañeros.
  3. Escribe un postmortem.

Facebook se cayó hace poco. No importa cuando leas esto…

Usualmente, son los operadores quienes manejan los incidentes de la compañía (a ellos son a los que llaman [en horario extra-laboral]), aunque no debería ser siempre así; los trabajadores que desarrollan el software son quienes deberían manejar sus incidentes.

Cuando ocurre un incidente, tenemos una llamada y aceptamos el manejo del mismo, quiere decir que no se va a escalar a otra persona y que seremos el responsable de ello.

  1. Debemos verificar la dimensión del incidente. Si es algo pequeño, puede que no sea necesario resolverlo de manera inmediata y puede ser resuelto en horario laboral o en un momento específico. Si por otro lado, es un incidente grande, lo atendemos de forma inmediata.
  2. Abrir un canal de comunicación con nuestros compañeros.
  3. Llevar un Timeline. Anotar cada paso llevado a cabo, una secuencia de eventos con fecha. Con esto, nos evitamos tener que repetir pasos que ya hemos realizado, o que ingrese un nuevo trabajador y explicarle lo que ya le hemos explicado a varias personas, también nos ahorraríamos el tener que responder dudas e inquietudes de nuestros compañeros; estaría todo documentado. (Los video-chats no se guardan). No siempre es necesario publicar el Timeline en un incidente; sin embargo, es muy importante tenerlo, puesto que si llegan más personas a atender el asunto, habrán muchas preguntas, lo cual se transforma en estrés y entre más estrés tengamos, más errores cometeremos.
    El Timeline es mucho más efectivo después del incidente. Puede ser compartido entre los compañeros internos para que sepan cómo manejamos el incidente.
  4. Notificar a nuestro cliente. No importa si el cliente es público o interno, pero debemos notificar la situación. Debemos informarle al cliente que ya estamos trabajando en dicho incidente (aunque no sepamos aún qué está sucediendo con exactitud), y a medida que vayamos avanzando, le vamos notificando de los pasos que estamos dando para que esté al tanto hasta que resolvamos el incidente. La comunicación es crucial, y así, le damos confianza al cliente de que cada vez que algo salga mal, se lo diremos. Sin comunicación, el cliente comenzará a insistir y a hacer preguntas (las cuales ya debieron haber sido respondidas en un documento) lo cual se resume en estrés, que no es saludable para un momento de resolución de incidentes.
  5. El proceso no termina cuando se soluciona el incidente, sino que luego debemos escribir un Post-Mortem. A pesar de que es tedioso, es la mejor manera de aprender.
    El Post-Mortem es una explicación detalla sobre qué estuvo mal, por qué estuvo mal, por qué no nos dimos cuenta antes y qué haremos al respecto, qué vamos a mejorar. Puede ser estructurado con un resumen de manera que nuestro cliente de nivel ejecutivo pueda comprender, donde también se pueden pedir disculpas de manera formal, y luego añadir una sección bastante técnica sobre el incidente (con gráficas de ser posible) porque literalmente es de ahí de donde aprendemos qué hicimos mal. Es importante que el cliente vea la sección técnica, para que esté enterado de que como compañía estamos aprendiendo y que muy probablemente este incidente no volverá a ocurrir.
  6. Lo más importante: comunicar sobre el incidente internamente. Ya sabemos manejar el incidente, la compañía crece, los equipos crecen, y las probabilidades de que le vuelva a ocurrir ese mismo incidente a otro equipo, aumentan.

Excelente la honestidad!

Bancolombia y Nequi se cayeron hace poco. No importa cuando leas esto...

Excelente clase

Muy buenos concejos, te agradezco todo.

El documentar el proceso y los incidentes que pasan me parece que es muy importante en las compañías porque como lo menciona el profesor si llega uno nuevo al caso y se esta tardando mas de lo esperado ya esta documentado todo el proceso que hiciste y en ocasiones las imágenes también son importantes en este proceso de documentar

Les recomiendo ver este video de Freddy narrando la caída de Gitlab es oro puro

Muy buena explicación y relevancia al proceso de incidentes!!!

Buen clase!