Introducción a Incident Response

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!

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!