Seguimiento de incidentes

Completado

Los incidentes tienen un ciclo de vida. Para responder de forma más eficaz, debe ser capaz de llevar un seguimiento de la evolución del incidente, así como de su respuesta a él, desde el principio del ciclo de vida.

Evalúe lo que sabe

Una buena manera de evaluar el procedimiento de seguimiento de incidentes usando un incidente específico es hacerse una serie de preguntas:

  • ¿Cuándo descubrió el problema? Si su objetivo consiste en reducir el tiempo que se tarda en recuperarse de los incidentes, debe empezar a capturar información desde el momento en que detecte los problemas.
  • ¿Cómo detectó el problema? ¿Le alertó del incidente el sistema de supervisión? ¿Lo descubrió a través de las quejas de los clientes, directamente o en las redes sociales?
  • Si acaba de detectar el problema, ¿es usted el primero en saberlo? Si es así, ¿a quién se lo debe notificar? En caso contrario, ¿quién más tiene constancia del problema?
  • Si hay otras personas al tanto, ¿qué se puede hacer al respecto? (En caso de que se pueda hacer algo). ¿Dan todos por supuesto que alguien lo estará investigando, o bien alguien ha tomado medidas para solucionarlo?
  • ¿Es muy grave? Puede que no tengamos noción de la gravedad o el impacto, y no hay ningún sitio donde podamos averiguar la gravedad real del problema y a quién afecta.

Si no se realiza ningún tipo de seguimiento, puede ser difícil contestar a estas preguntas.

Estandarice dónde se realizará el seguimiento de la información del incidente

Existen diversos lugares en los que podría conservar y compartir la lista de incidentes (activos o de otro tipo), así como toda la información disponible sobre ellos. Puede ser algo tan sencillo como un área de archivos compartidos con documentos de Word o algo tan complejo como servicios y software muy especializados de seguimiento de incidentes. Entre estos dos extremos se encuentran los sistemas de vales y de seguimiento del trabajo, que se pueden poner en marcha para esta tarea. En realidad, el sistema que elija es menos importante que la manera de usarlo. Sea cual sea el sistema que use, todas las personas que tengan relación con los incidentes (ingenieros, asistencia al cliente, dirección, relaciones públicas, departamento jurídico, etc.) deben saber adónde dirigirse para encontrar el sistema, cómo notificar un incidente y cómo acceder a los datos cuando sea necesario. Una manera de garantizar el fracaso del seguimiento de incidentes es hacer que las personas a las que presta ayuda no sepan cómo acceder al sistema ("Pero ¿cuál era la dirección URL del sistema?") cuando lo necesiten.

En este módulo, usaremos la funcionalidad de elementos de trabajo de Azure DevOps para nuestro sistema de seguimiento de ejemplo.

Cree un puente de conversación

Para responder a algunas de las preguntas de la sección anterior, Evalúe lo que sabe, y empezar el proceso de respuesta ante incidentes, debe disponer de una manera de comunicarse con otras personas sobre el incidente. Lo ideal es contar con algún tipo de medio electrónico de "colaboración en equipo" para conversar, aunque los puentes telefónicos también funcionan. Las teleconferencias y los puentes telefónicos son menos preferibles porque es más difícil revisar de forma retroactiva la comunicación sobre los incidentes (de ahí la función de "escriba" mencionada anteriormente).

Sea cual sea el medio que elija, debe asegurarse de definir un canal único que se limite estrictamente a hablar sobre el incidente y nada más. Es importante mantener fuera de este canal los debates irrelevantes, ya que es necesario poder tomar los datos y analizarlos más adelante en la revisión posterior al incidente.

En este módulo, usaremos Microsoft Teams como método para la comunicación de incidentes.

Automatice el inicio del seguimiento de incidentes

Repasemos los elementos que hemos reunido hasta ahora. Disponemos de:

  • Una lista de turnos de las personas de guardia (y una rotación definida para ellas).
  • Un rol que se puede asignar a las personas que trabajan en un incidente.
  • Un lugar específico en el que declararemos el incidente y llevaremos a cabo el seguimiento.
  • Un canal único para que las personas que trabajan en ese incidente se comuniquen.

En la medida más completa posible, puede y debe automatizar la creación y administración de todas estas cosas. Cuando surge un problema urgente, lo último que quiere es tener que recuperar todos los pasos necesarios para notificar un incidente, reunir a las personas adecuadas y realizar el seguimiento. Lo que realmente le interesa es dar el visto bueno para que se ponga en marcha de inmediato el trabajo que solucione el problema.

Use Logic Apps para la automatización sin código

Una manera de automatizar la respuesta inicial consiste en usar Logic Apps, ya que ayuda a simplificar el trabajo de programar, automatizar y orquestar tareas, procesos empresariales y flujos de trabajo.

Logic Apps es un servicio en la nube de Azure para compilar soluciones de integración. Usa conectores para crear flujos de trabajo automatizados. Los desencadenadores inician la instancia de Logic Apps cuando se produce un evento específico o cuando los datos cumplen los criterios especificados. Las acciones son las operaciones que se realizan después en el flujo de trabajo de Logic Apps.

En nuestro ejemplo, usará los siguientes conectores de Logic Apps para el seguimiento de incidentes:

  • Azure Boards (parte de Azure DevOps), que se puede usar para crear y llevar el seguimiento de problemas e incidentes.
  • Azure Storage, donde se puede almacenar y recuperar información sobre quién está de guardia, de modo que se pueda asignar a las personas adecuadas la respuesta al incidente. En nuestro ejemplo, usaremos Azure Table Storage, ya que ofrece un almacén de "clave-valor" muy sencillo que facilita el almacenamiento de una lista de ingenieros y su estado de guardia.
  • Microsoft Teams, que se puede usar para crear un canal de incidentes nuevo y único para llevar un seguimiento de las conversaciones de los equipos de ingeniería en tiempo real cuando se comunican sobre incidentes específicos. Esto le permite conservar las interacciones con respecto a la escala de tiempo de los eventos más adelante al realizar una revisión con posterioridad al incidente.

Vamos a recapitular todo esto con una instancia de Logic Apps. En primer lugar, observe la aplicación completa que se muestra en el diseñador de Logic Apps. Más adelante, la examinaremos con detalle.

Screenshot of a zoomed out view of a logic app as displayed in the Logic Apps Designer.

El primer paso es controlar un desencadenador, que es la solicitud HTTP que hemos mencionado. Se realiza una solicitud HTTP POST a nuestra aplicación lógica que contiene una carga JSON con información sobre el incidente que se quiere declarar. Analizamos esa carga y devolvemos una confirmación de que la hemos recibido:

Screenshot of the HTTP and Response block in Logic App Designer view of the Logic App.

Con esta información, creamos un elemento de trabajo en la organización de Azure DevOps que representa este incidente.

Screenshot of the Create a work item block in Logic App Designer view of the Logic App.

Después, se creará un nuevo canal de Teams para el incidente:

Screenshot of the Create a channel block in Logic App Designer view of the Logic App.

Una vez creado, el elemento de trabajo que generamos hace un momento se actualiza con un vínculo al nuevo canal. De este modo, toda la información se mantiene en el mismo lugar (el elemento de trabajo) y los usuarios pueden consultarla posteriormente para saber adónde dirigirse si quieren unirse a ese canal.

Screenshot of the Update work item block in Logic App Designer view of the Logic App.

Ahora es el momento de incluir en el escenario a la persona que está de guardia. Realizamos una búsqueda en Azure Table Storage para encontrar la dirección de correo electrónico del ingeniero de guardia. Esta acción devuelve una respuesta JSON, que luego analizaremos.

Screenshot of the Get entities block in Logic App Designer view of the Logic App.

Dado que la consulta devolverá una lista, el paso siguiente consiste en iterar cada elemento de la lista. Asignamos el elemento de trabajo a cada persona (ahora son "propietarios" del incidente).

Screenshot of the Foreach block in Logic App Designer view of the Logic App.

Después, como paso final, enviamos un mensaje al canal de Teams con un puntero al elemento de trabajo para las personas que se unen al canal y que quieren saber dónde se almacena la información autorizada para dicho incidente.

Screenshot of the Post a message as the Flow bot channel block in Logic App Designer view of the Logic App.

Este es solo un ejemplo de cómo se puede automatizar la configuración de los mecanismos de comunicación y seguimiento de incidentes. En la siguiente unidad, profundizaremos un poco más en los aspectos de la comunicación en torno a un incidente.

Comprobar los conocimientos

1.

¿Cuál de estas preguntas no resulta de utilidad inmediata a la hora de evaluar el proceso de seguimiento de incidentes?

2.

Al crear un puente de conversación para comunicarse sobre un incidente, ¿por qué es importante definir un canal único para ello?

3.

¿Cuál de las siguientes afirmaciones es verdadera?

4.

¿Qué herramienta se puede usar para la automatización sin código destinada a automatizar la respuesta inicial?