Responder a un incidente

Puntos clave: el proceso de respuesta ante incidentes de Atlassian consta de diez pasos —detectar, generar, abrir comunicaciones, evaluar, enviar comunicaciones iniciales, escalar, delegar, enviar comunicaciones de seguimiento, revisar, resolver— y está dirigido por un gestor de incidentes desde el momento en que se registra un ticket hasta que finaliza el impacto en el negocio.

• Qué es: un manual de estrategias repetible basado en un ticket de incidente de Jira como fuente fiable de información, un canal de chat y un puente de vídeo con su nombre, un documento de estado del incidente compartido, niveles de gravedad que deciden a quién se avisa y Statuspage para las comunicaciones internas y externas.

• Por qué es importante: un comando claro, canales con nombre y un cronograma por escrito son lo que mantiene una respuesta coordinada bajo presión y dan al análisis retrospectivo algo sobre lo que basar la actividad.

• Cómo ayuda Jira Service Management: proporciona registros de incidentes, alertas de guardia y derivación, integración de chat y vídeo, y enlaces a Statuspage y análisis retrospectivos, para que el proceso se ejecute desde una sola plataforma.

Las siguientes secciones describen el proceso de Atlassian para responder a incidentes. El gestor de incidentes (GI) sigue esta serie de pasos para guiar el incidente desde la detección hasta la resolución. Cada paso a continuación es una sección independiente; juntos forman el manual de estrategias que siguen nuestros gestores de incidentes.

Detección

Las personas de tu empresa pueden enterarse de los incidentes de varias maneras: Pueden recibir alertas mediante la monitorización, los informes de clientes o su propia observación. 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). 

Usamos una URL corta y fácil de recordar que redirige a los Atlassians a un portal interno de Jira Service Management. Atlassians pueden comprobar si un incidente ya está en curso consultando un panel de Jira o una macro de Jira en Confluence. Los equipos como nuestros equipos de atención al cliente tienen paneles en ubicaciones conocidas para supervisar los incidentes en curso.

Para cada incidente, completaremos los siguientes campos:

Una vez que se ha creado el incidente, su clave de incidencia se utiliza en todas las comunicaciones internas relativas al incidente.

A menudo, los clientes abren casos de soporte sobre incidentes que les afectan. Una vez que nuestros equipos de asistencia al cliente determinan que todos estos casos están relacionados con un incidente, etiquetan esos casos con la clave de incidencia del incidente para hacer un seguimiento del impacto en el cliente y hacer un seguimiento más fácilmente con los clientes afectados cuando el incidente esté resuelto.

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 configura los canales de comunicación del equipo del incidente. El objetivo en este punto es establecer y centrar todas las comunicaciones del equipo del incidente en lugares conocidos. Normalmente usamos tres métodos de comunicación del equipo, cada uno de los cuales está representado por 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. Darle al canal de chat el mismo nombre que la clave de la incidencia (por ejemplo, HOT-1234) facilita a las personas que necesitan participar unirse a 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 descubierto que usar tanto el chat de vídeo como las salas de chat funciona mejor durante un incidente, ya que ambos están optimizados para cosas diferentes. El chat de vídeo es excelente para crear rápidamente una imagen mental compartida del incidente mediante la discusión en grupo, mientras que el chat de texto es ideal para mantener un registro con marca de tiempo del incidente, enlaces compartidos a paneles, capturas de pantalla 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)

Ahora es un buen momento para empezar a añadir al cronograma del incidente. Registra las observaciones del equipo para que las personas que se incorporen puedan ponerse al día. Esto también es importante más adelante en el proceso de análisis retrospectivo. Asegúrate de anotar si la hora y fecha de inicio del incidente coincide con un cambio (por ejemplo, una implementación de Bamboo) para que el cambio se pueda revertir y potencialmente resolver 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: 

Una vez que hayas establecido el impacto del incidente, ajusta o confirma la gravedad de la incidencia del incidente y comunícasela al equipo. Hemos comprobado que la numeración del nivel resulta altamente beneficiosa a la hora de comunicar con claridad la gravedad.

En Atlassian, los incidentes de gravedad 3 se transmiten a los equipos de entregas para su resolución durante el horario laboral, mientras que los de gravedad 1 y 2 requieren ponerse en contacto con los miembros del equipo para corregirlos de manera inmediata. La diferencia de respuesta entre la gravedad 1 y 2 es más sutil y depende del servicio afectado.

Se debe documentar y acordar una matriz de gravedad para todos tus equipos con el fin de tener una respuesta coherente a los incidentes de acuerdo con el impacto en los clientes.

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:

Además de crear un incidente de Statuspage, enviamos un correo electrónico a una lista de distribución de comunicaciones de incidentes que incluye a nuestro equipo líder de ingeniería, a los gestores de incidentes principales y demás personal pertinente. Este correo electrónico tiene el mismo contenido que el incidente de Statuspage interno. El correo electrónico permite al personal responder y formular preguntas, mientras que la Statuspage es más bien una comunicación de difusión unidireccional.

Ten en cuenta que siempre incluimos la clave de incidencia de Jira del incidente en todas las comunicaciones internas relacionadas con el incidente, de modo que el personal sepa a qué sala de chat acceder si necesita realizar más preguntas.

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 grandes, es aconsejable incorporar a otro gestor de incidentes cualificado como una "comprobación de validez" secundaria para el GI. Pueden centrarse en tareas específicas que liberen al GI, como mantener 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.

Actualizar al personal interno es importante porque crea una verdad compartida de forma coherente sobre el incidente. Cuando algo sale mal, la información al respecto es escasa, especialmente en las primeras etapas, y si no estableces una fuente de información fiable sobre lo que ha pasado 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.

• Usa la misma convención para el formato del nombre del incidente y el asunto del correo electrónico.

• 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.

Actualizar a los clientes externos es importante porque ayuda a la compilación de confianza. Aunque les pueda afectar, podrán seguir con otras cosas siempre y cuando sepan que les mantendrás al día.

Para las comunicaciones externas, simplemente actualizamos el incidente que abrimos en la Statuspage externa anteriormente, cambiando su estado según corresponda. Intentamos que las actualizaciones sean "breves y concisas" porque a los clientes externos no les interesan los detalles técnicos del incidente; solo quieren saber si ya se ha solucionado y, de no ser así, cuándo se solucionará. Por lo general, 1-2 oraciones serán suficientes.

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, no entres en pánico; eso no ayuda. Mantén la calma y el resto del equipo seguirá tu ejemplo.

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.

Obtén el manual en versión impresa o PDF

Tenemos un suministro limitado de versiones impresas de nuestro Manual de gestión de incidentes, que enviamos de forma gratuita. También puedes descargar una versión en PDF.

Consigue el manual