Cerrar

Manual de incidentes de Atlassian

Definir los incidentes y los valores de incidente. Conoce cuáles son las herramientas correctas y las funciones de equipo.

Incident Management home

Responder a un incidente

Las siguientes secciones describen el proceso de Atlassian para responder a los incidentes. El gestor de incidentes (IM) sigue esta serie de pasos para llevar el incidente desde la detección hasta la resolución.

Incident response workflow

Detección

People at your company can become aware of incidents in many ways. They can be alerted by monitoring, through customer reports, or by observing it themselves. However an incident occurs, the first step the team takes is logging an incident ticket (in our case, a Jira issue). 

Usamos una URL corta y fácil de recordar que redirige al personal de Atlassian a un portal interno de Jira Service Desk. El personal de Atlassian puede comprobar si ya hay un incidente en progreso consultando el panel de Jira o un macro de Jira en Confluence. Los equipos como nuestros equipos de atención al cliente tienen paneles establecidos en ubicaciones conocidas para supervisar los incidentes en curso.

Para cada incidente, completaremos los siguientes campos:

Campo de Jira Tipo Texto de ayuda
Summary Texto

What's the emergency?

Description Texto

What's the impact on customers? Include your contact details so responders can reach you

"Severity" (Gravedad) Selección única

(Hipervínculo a una página de Confluence con nuestra escala de gravedad en ella). Eligir entre "Sev" (Gravedad) 2 o 1 significa que crees que se puede resolver de inmediato, por lo que se contactará con las personas adecuadas.

"Faulty service" (Servicio defectuoso) Selección única

El servicio que contiene el fallo que está causando el incidente. Si no estás seguro, haz la suposición más exacta que puedas. Si no tienes ni idea, selecciona "Unknown" (Desconocido).

"Affected products" (Productos afectados) Casillas Which products are affected by the incident? Select any that apply

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 abrirán casos de soporte sobre un incidente que les afecta. Una vez que nuestros equipos de atención al cliente determinan que todos estos casos se relacionan con un incidente, etiquetan estos casos con la clave de incidencia del incidente para supervisar cómo afecta al cliente y para realizar de forma más sencilla un seguimiento de los clientes afectados una vez que se haya resuelto el problema.


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 IM cuando se conecta es asignarse la incidencia del incidente y cambiar el estado de la incidencia a "fixing" (en reparación). El campo de asignado de la incidencia de Jira también muestra qué es el IM 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 exacto. 

A continuación, el IM 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 de 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. Esta permite al equipo comunicarse, compartir observaciones, vínculos y capturas de pantalla con marcas temporales y de forma preservada. Si se da al canal de chat el nombre de la clave de incidencia (p. ej., 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 cambios, decisiones y observaciones importantes que ocurren en conversaciones no registradas. El IM o cualquier integrante del equipo de incidentes puede hacerlo con solo anotar cambios, decisiones y observaciones en la sala de chat dedicada puesto que se dan en tiempo real. No pasa nada si parece que cada uno se está hablando a sí mismo. Estas notas son increíblemente valiosas durante los análisis a toro pasado cuando los equipos necesitan reconstruir el cronograma del incidente y descubrir qué lo causó. 

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

Finally, the IM sets their own personal chat status to the issue key of the incident they are managing. This lets their colleagues know that they're busy managing an incident. 


Evaluación

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

A continuación te mostramos una serie de preguntas que los IM 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 incidencias con uno de los siguientes niveles de gravedad

"Severity" (Gravedad) Description Examples
1 Un incidente crítico con un impacto muy alto
  • Falla un servicio público, como Jira Cloud, para todos los clientes.
  • Se ha vulnerado la confidencialidad o privacidad.
  • Pérdida de datos del cliente.
2 Un incidente principal con impacto significativo
  • No está disponible un servicio público para un subconjunto de clientes.
  • Afecta a una funcionalidad esencial (p. ej., git push, issue create).
3 Un incidente secundario con bajo impacto
  • Una inconveniencia secundaria para los clientes que cuenta con una solución alternativa.
  • Degradación del rendimiento usable.

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:

  Statuspage a nivel interno External Status page
Nombre del incidente

<Clave de incidencia del incidente> - <Gravedad> - <Resumen del incidente>

Investigar las incidencias con <producto>

Mensaje Estamos investigando un incidente que afecta a <producto X>, <producto Y> y <producto Z>. En unos minutos enviaremos actualizaciones por correo electrónico.

Estamos investigando incidencias con <producto> y pronto publicaremos actualizaciones aquí.

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:

  • Incident Manager, described in the Overview page.
  • 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.

Mantener informado la personal interno es importante porque genera una verdad coherente y común sobre el incidente. Cuando algo falla la información al respecto es escasa, especialmente durante las fases iniciales, y si no estableces una fuente de información fiable sobre lo que está ocurriendo y cómo estás respondiendo, las personas tienen 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 (<Clave de incidencia del incidente> - <Gravedad> - <Resumen 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 lista de verificación 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 proceso de perspectiva única que resuelva todos los incidentes. Si lo hubiera, simplemente lo automatizaríamos y ya habríamos acabado. En su lugar, reafirmamos el siguiente proceso para adaptarse rápidamente a una variedad de escenarios de respuesta a incidentes: 

  • Observa lo que está sucediendo. Comparte observaciones y confírmalas.
  • Desarrolla teorías sobre lo 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 cuidadosa? ¿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

An incident is resolved when the current or imminent business impact has ended. At that point, the emergency response ends and the team transitions onto any cleanup tasks and the postmortem.

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.