Responder a un incidente

Detección

Las personas de tu empresa pueden enterarse de los incidentes de varias maneras: mediante la supervisión, a través de los informes de clientes u observándolos ellas mismas. No obstante, cuando se produce un incidente, el primer paso que da el equipo es el de registrar un ticket de incidente (en nuestro caso, una incidencia de Jira).

Emisión de un nuevo incidente

Si se ha creado la incidencia del incidente pero no se ha asignado aún a un gestor de incidentes (IM), el incidente presentará el estado "new "(nuevo). Este es el estado inicial del workflow de incidentes de Jira.

Tenemos un servicio que usa webhooks de Jira para activar una alerta de contacto cuando se crea un incidente principal. Esta avisa a un IM de guardia en el servicio que se ha seleccionado. Por ejemplo, un incidente con Bitbucket se pondrá en contacto con un gestor de incidentes de Bitbucket. Asimismo, tenemos una lista global e integral de gestores de incidentes principales que se denomina "Incident manager on call" (Gestor de incidentes de guardia) o IMOC.

La alerta de contacto incluye la clave de incidencia del incidente, un resumen que indica al gestor de incidentes a dónde dirigirse para comenzar a gestionar el incidente (incidencia de Jira), qué falla en general y su nivel de gravedad.

Inicio de comunicaciones

Lo primero que hace el GI cuando se conecta es asignarse la incidencia del incidente y cambiar el estado de la incidencia al de corrección. El campo de la persona asignada de la incidencia de Jira también muestra quién es el GI actual. En una respuesta de emergencia, es esencial dejar claro quién está al mando, por lo que somos muy estrictos en cuanto a asegurarnos de que este campo sea preciso.

A continuación, el GI establece los canales de comunicación del equipo de incidentes. El objetivo en este momento es el de establecer y centrar todas las comunicaciones del equipo de incidentes en ubicaciones conocidas. Normalmente utilizamos tres métodos de comunicación para los equipos, cada uno de los cuales queda representado en un campo en la incidencia de Jira para cada incidente:

• Una sala de chat en Slack o cualquier otro servicio de mensajería. Esto permite al equipo comunicarse y compartir observaciones, enlaces y capturas de pantalla con marcas temporales y de forma que puedan conservarse. Si se da al canal de chat el nombre de la clave de la incidencia (por ejemplo, HOT-1234), se facilita que se unan las personas que deban participar en la conversación.
• Un videochat en una aplicación de conferencias como Skype, Blue Jeans o similar. Si os encontráis todos en el mismo lugar, reúne al equipo en una sala física. Pensamos que la comunicación cara a cara ayuda al equipo a trabajar de manera más rápida y con menos tira y afloja.
• Una página de Confluence denominada "incident state document" (documento de estado del incidente). Cuando varias personas editan a la vez una misma página, pueden ver la información que se está reuniendo en tiempo real. Esta es una excelente manera de supervisar los cambios (por ejemplo, una tabla que indica quién ha cambiado qué, cuándo, cómo, por qué, cómo deshacerlo, etc.), de varias secuencias de trabajo o de un cronograma ampliado. El documento de estado del incidente resulta realmente útil como única fuente de información durante incidentes complejos o de larga duración.

Hemos comprobado que usar el videochat y la sala de chat al mismo tiempo da mejores resultados durante un incidente, puesto que ambos están optimizados para cosas diferentes. El videochat destaca en la creación de una imagen mental compartida del incidente de manera rápida en una conversación de grupo, mientras que los chat de texto son perfectos para mantener un registro del incidente con marcas temporales, vínculos compartidos en paneles, capturas de pantallas y otras URL.

Estos métodos también se pueden utilizar para registrar observaciones, cambios y decisiones importantes que tienen lugar en las conversaciones no registradas. El GI o cualquier miembro del equipo de gestión de incidentes puede hacerlo con solo anotar las observaciones, los cambios y las decisiones en la sala de chat especializada a medida que vayan apareciendo en tiempo real. No pasa nada si parece que cada uno habla consigo mismo. Estas notas resultan sumamente útiles durante los análisis retrospectivos, cuando los equipos necesitan reconstruir el cronograma del incidente y averiguar qué lo provocó.

La mayoría de los sistemas de chat tienen una función de tema de la sala . El IM actualiza el tema de la sala con vínculos útiles e información sobre el incidente, que incluyen:

• El resumen del incidente y su nivel de gravedad.
• A quién pertenece cada función, comenzando por el IM.
• Vínculos a la incidencia del incidente, a la sala de videochat y al documento de estado del incidente.

Esto permite que todo el que tenga la clave de incidencia del incidente pueda unirse al chat y ponerse al día con respecto al incidente rápidamente (recuerda que nombramos el canal de chat con el nombre de la clave de incidencia del incidente, p. ej., HOT-1234).

Por último, el GI pone en su propio estado de chat personal la clave de incidencia del incidente que está gestionando. Gracias a ello, los compañeros saben que está ocupado con un incidente.

Evaluación

Después de establecer los canales de comunicación del equipo de gestión de incidentes, es momento de evaluar el incidente para que el equipo pueda decidir qué contar sobre él y quién debe corregirlo.

A continuación, te mostramos una serie de preguntas que los GI deben formular a sus equipos:

• ¿Cuál es el impacto en los clientes (a nivel interno o externo)?
• ¿Qué ven los clientes?
• ¿A cuántos clientes les afecta (a algunos, a todos)?
• ¿Cuándo ha comenzado?
• ¿Cuántos casos de soporte han abierto los clientes?
• ¿Existen otros factores? (P. ej., Twitter, seguridad o pérdida de datos)

Este es un buen momento para comenzar a añadir datos al cronograma del incidente. Registra las observaciones del equipo para que los que se unan puedan ponerse al día rápidamente. Esto también es importante más tarde, durante el proceso de análisis a toro pasado. Asegúrate de anotar si la hora de comienzo del incidente coincide con un cambio (por ejemplo, el despliegue de Bamboo), de modo que se pueda revertir el cambio como solución potencial ante el incidente.

Según el impacto del incidente y la cantidad de trabajo que los equipos creen que necesitarán para resolverlo, asignamos las incidencias a uno de los siguientes niveles de gravedad:

Envío de comunicaciones iniciales

Cuando estés razonablemente seguro de que el incidente es real, debes comunicarlo a nivel externo e interno lo antes posible. El objetivo de la comunicación inicial interna es centrar la respuesta al incidente en un único lugar y reducir la confusión. El objetivo de la comunicación externa es decir a los clientes que tienes conocimiento de un fallo y que estás investigándolo con urgencia. Una comunicación rápida y precisa sobre los incidentes ayuda a ganarse la confianza del personal y los clientes.

Usamos Statuspage para las comunicaciones de incidentes a nivel externo e interno. Tenemos páginas de estado independientes para el personal interno de la compañía y para los clientes externos. Más adelante seguiremos hablando sobre cómo usar cada una de ellas, pero por el momento el objetivo es conseguir establecer las comunicaciones lo más rápido posible. Para ello, seguimos estas plantillas:

Derivación

Te has hecho cargo del incidente, has establecido las comunicaciones de equipo, has evaluado la situación y has informado al personal y a los clientes de que hay un incidente en curso. ¿Y ahora qué?

Los primeros en responder deberían ser todas las personas que requieres para resolver el incidente, pero con frecuencia necesitarás ponerte en contacto con otros equipos. Llamaremos a esto derivación.

El sistema clave en este paso es una lista de contacto y una herramienta de alerta como Opsgenie. Opsgenie y los sistemas similares te permiten definir listas de guardia para que cualquier equipo determinado tenga una rotación de personal con el que se espera poder contactar para responder en caso de emergencia. Esto es más importante que necesitar a un individuo específico todo el tiempo ("volver a contactar con Bob"), puesto que los individuos no siempre estarán disponibles (a veces se irán de vacaciones, cambiarán de trabajo o se cansarán si los llamas demasiado). También es de vital importancia para el concepto de "hacer todo lo posible" en la guardia, puesto que está claro qué individuos tiene la responsabilidad de responder.

Incluye siempre la clave de incidencia de Jira del incidente en la alerta de contacto relativa al incidente. Esta es la clave que la persona que recibe la alerta utiliza para unirse a la sala de chat del incidente.

Delegación

Después de realizar las derivaciones y de que se conecten, el IM delega una función para ellos. Siempre que comprendan qué se requiere de su función, podrán trabajar de manera rápida y efectiva como parte del equipo de incidentes.

Las funciones que usamos en Atlassian son:

• Gestor de incidentes: función descrita en la página de descripción general.
• Líder técnico: trabajador técnico experimentado. Es responsable de desarrollar teorías sobre qué ha fallado y por qué, de decidir los cambios y de dirigir el equipo técnico. Trabaja codo con codo con el IM.
• Gestor de comunicaciones: persona familiarizada con las comunicaciones públicas, que posiblemente pertenezca al equipo de atención al cliente o a relaciones públicas. Es responsable de escribir y enviar comunicaciones a nivel interno y externo sobre el incidente.

Usamos el tema de la sala de chat para mostrar la función actual de cada participante, datos que se mantienen actualizados si cambian las funciones durante un incidente.

El IM también puede idear y delegar funciones según requiera el incidente, por ejemplo, varios líderes técnicos si hay más de una secuencia de trabajo en marcha o gestores de comunicaciones independientes a nivel externo e interno.

En incidentes complicados o de larga duración, se aconseja contar con otro gestor de incidentes como "comprobación de integridad" de respaldo para el IM. Pueden centrarse en tareas específicas que liberen al IM, como llevar el cronograma.

Envío de comunicaciones de seguimiento

Ya has enviado las comunicaciones iniciales, pero una vez que el equipo de incidentes está en marca tienes que volver a informar al personal y a los clientes sobre el incidente.

Es fundamental mantener informado al personal interno porque permite disponer de una base de información coherente y común sobre el incidente. Cuando algo falla, la información al respecto es escasa, en especial durante las fases iniciales y, si no creas una fuente de información fiable sobre lo que ha ocurrido y cómo estás respondiendo, la gente tiende a sacar sus propias conclusiones.

Para las comunicaciones internas, seguimos este patrón:

• Comunícate mediante nuestra Statuspage a nivel interno y por correo electrónico, como se describe en la sección anterior sobre comunicaciones internas.
• Utiliza la misma convención para el formato del asunto del correo electrónico y el nombre del incidente ( - - ).
• Comienza con un resumen de una o dos frases sobre el estado actual y el impacto.
• Continúa con una sección denominada "Estado actual" de dos a cuatro viñetas.
• Incluye una sección denominada "Siguientes pasos" de dos a cuatro viñetas.
• Informa sobre cómo y cuándo se enviará la siguiente ronda de comunicaciones.

Usamos la siguiente checklist para revisar si las comunicaciones contienen toda la información necesaria:

• ¿Cómo afecta actualmente a los clientes?
• ¿A cuántos clientes internos y externos afecta?
• Si se conoce el origen del problema, ¿cuál es?
• Si existe una hora estimada de llegada para la restauración, ¿cuál es?
• ¿Cuándo y dónde se llevará a cabo la siguiente actualización?

Animamos a nuestros gestores de incidentes a ser explícitos sobre los asuntos desconocidos en sus comunicaciones internas. Así se reduce la incertidumbre. Por ejemplo, si aún no sabes cuál es el origen del problema, resulta mucho mejor decir "el origen del problema se desconoce por el momento" que simplemente omitir cualquier mención al respecto.

Mantener informados a los clientes externos es importante porque ayuda a ganarse su confianza. Aunque pueda afectarles, podrán seguir con otros asuntos siempre que sepan que les mantendrás al tanto.

Para las comunicaciones externas, simplemente transmitimos información nueva sobre el incidente que hemos abierto anteriormente en la Statuspage a nivel externo y cambiamos su estado conforme sea necesario. Intentamos que las actualizaciones de información sean "cortas y amables" puesto que los clientes externos no están interesados en los detalles técnicos del incidente, lo único que quieren saber es si se ha corregido ya o cuándo se solucionará. Por lo general, con una o dos frases bastará.

Realizar comunicaciones de incidentes es un arte; cuanto más práctica tengas, mejor se te dará. En nuestra formación de gestores de incidentes, recreamos un incidente hipotético, redactamos comunicaciones de borrador para este y las leemos al resto de la clase. Es una buena manera de desarrollar esta capacidad antes de hacerlo de verdad. Asimismo, siempre es una buena idea que alguien revise tus comunicaciones a modo de "segunda opinión" antes de enviarlas.

Revisa

No existe un único proceso preceptivo que resuelva todos los incidentes. Si lo hubiera, simplemente lo automatizaríamos y se acabó. En su lugar, realizamos iteraciones en el siguiente proceso para adaptarnos rápidamente a las distintas situaciones de respuesta ante incidentes:

• Observa lo que está sucediendo. Comparte observaciones y confírmalas.
• Desarrolla teorías sobre los motivos por los que está pasando.
• Desarrolla experimentos que prueben o desmientan esas teorías. Llévalos a cabo.
• Repite.

Por ejemplo, puedes observar una tasa de error elevada en un servicio que se corresponde con un fallo de tu proveedor de infraestructura regional como se ha publicado en su Statuspage. Puedes teorizar que el fallo está aislado solo en esta región, decidir que falle en otra región y observar los resultados.

El mayor reto para el IM en este punto está relacionado con mantener la disciplina del equipo:

• ¿El equipo se está comunicando de manera efectiva?
• ¿Cuáles son las observaciones, teorías y secuencias de trabajo actuales?
• ¿Estamos tomando las decisiones de manera efectiva?
• ¿Estamos aplicando cambios de manera intencionada y con atención? ¿Sabemos qué cambios estamos realizando?
• ¿Las funciones son claras? ¿Todos están cumpliendo con su trabajo? ¿Necesitamos derivar a más equipos?

En cualquier caso, que no cunda el pánico. No sirve de nada. Mantén la calma y el resto del equipo hará lo mismo.

El IM tiene que estar atento a la fatiga del equipo y planificar relevos de equipos. Un equipo dedicado corre el riesgo de agotarse al resolver incidentes complejos. Por este motivo, los IM deberían vigilar cuánto tiempo llevan despiertos los miembros y cuánto tiempo llevan trabajando en el incidente, además de decidir quién va a ocupar su función a continuación.

Resolución

Se considera que un incidente se ha resuelto cuando el impacto empresarial actual o inminente ha cesado. En este momento, la respuesta de emergencia termina y el equipo pasa a las tareas de limpieza y al análisis retrospectivo.

Las tareas de limpieza se pueden enlazar y supervisar como vínculos de incidencia desde la incidencia de Jira del incidente.

En Atlassian, utilizamos los campos personalizados de Jira para supervisar las horas de comienzo del impacto, las horas de detección y las horas de finalización del impacto del incidente. Utilizamos estos campos para calcular el tiempo de recuperación (TTR), que es un intervalo entre el momento de inicio y la finalización, y el tiempo de detección (TTD), que es un intervalo entre el momento de inicio y la detección. La distribución de tu TTD y TTR de incidente suele ser una métrica empresarial importante.

Una vez que el incidente está resuelto, enviamos las comunicaciones internas y externas finales. Las comunicaciones internas contienen un resumen del impacto y la duración del incidente, que incluye cuántos casos de soporte se han emitido y demás dimensiones importantes del incidente, y enuncian claramente que el incidente se ha resuelto y que no se enviarán más comunicaciones al respecto. Las comunicaciones externas suelen ser breves e informan a los clientes de que se ha restaurado el servicio y que se realizará un seguimiento con un análisis a toro pasado.

Para obtener más información sobre cómo Jira Service Management ayuda a los equipos a ejecutar cada paso del proceso de respuesta, desde la centralización de las alertas y la organización de la comunicación sobre incidentes hasta la unificación de los equipos para una mejor colaboración mediante la realización de análisis retrospectivos de los incidentes para examinar las causas fundamentales, haz clic en el botón que se muestra a continuación.