Rootly ayuda a agilizar su procedimiento de respuesta a incidentes a través de automatizaciones fáciles de usar y potentes durante cada etapa del ciclo de vida del incidente.

1. Detección de Incidentes: Rootly se integra con varias aplicaciones de observabilidad como Datadog, Grafana, Sentry, etc. para alertar a los equipos cuando surgen anomalías o problemas potenciales.

2. Paginación y Notificación: Tras la detección de un problema potencial, Rootly notifica a las partes interesadas relevantes a través de varios canales de comunicación como Slack, correo electrónico o SMS.

3. Triaje de Incidentes: Al ser alertado, el incidente se clasifica para evaluar su gravedad e impacto en las operaciones de la organización. Rootly proporciona una interfaz centralizada para empoderar a los miembros del equipo para colaborar eficientemente y recopilar información sobre el posible incidente.

4. Respuesta a Incidentes: Rootly facilita los esfuerzos de respuesta a incidentes automatizando tareas manuales, lo que ayuda a eliminar la carga cognitiva durante las interrupciones del sistema.

5. Colaboración y Comunicación: A lo largo del proceso de resolución de incidentes, Rootly sirve como centro para la colaboración y comunicación entre los miembros del equipo. Permite la comunicación en tiempo real, el intercambio de archivos y las actualizaciones de estado, asegurando que todos se mantengan informados y alineados en los esfuerzos de respuesta a incidentes.

6. Resolución y Análisis Post-Incidente: Una vez que se resuelve el incidente, Rootly facilita el análisis post-incidente para documentar las causas raíz, las lecciones aprendidas y las áreas de mejora.

7. Análisis de Incidentes: Rootly captura toda la información relevante del incidente y proporciona métricas perspicaces para ayudar a los equipos a interpretar sus datos de incidentes.

​

Ciclo de Vida del Incidente

Rootly gestiona los incidentes a través de las siguientes etapas. Cada etapa está representada como el status del incidente.

​

Triaje

El estado de triage se utiliza para problemas potenciales que no han sido confirmados como un incidente. Colocar un incidente en el estado de triage permite a los equipos limitar el radio de impacto de cualquier notificación y mantener la investigación inicial a un pequeño grupo de respondedores.

Los incidentes pueden ser declarados en el estado de triage seleccionando la casilla Mark as In Triage.

El valor de datos para el estado de triage es in_triage.

Cuando un incidente está en el estado de triage, la {{ incident.in_triage_at }} marca de tiempo se registrará automáticamente.

​

Iniciado

Una vez que un incidente está en el estado started, significa que el incidente ha sido confirmado como un incidente real.

Para declarar un incidente directamente en el estado started, simplemente deje la casilla Mark as In Triage sin marcar.

El valor de datos para el estado started es started.

Cuando un incidente está en el estado started, la {{ incident.started_at }} marca de tiempo se registrará automáticamente.

​

Mitigado

Un incidente pasa al estado mitigated una vez que su impacto ha sido contenido. Sin embargo, esto NO significa que el incidente haya sido oficialmente solucionado.

Un incidente puede avanzar al estado mitigated utilizando el comando /rootly mitigate o a través del botón Mitigate.

El valor de datos para el estado mitigated es mitigated.

Cuando un incidente está en el estado mitigated, la {{ incident.mitigated_at }} marca de tiempo se registrará automáticamente.

Esta marca de tiempo se establecerá automáticamente al mismo valor que la {{ incident.resolved_at }} marca de tiempo si se omite el estado mitigated.

​

Resuelto

Un incidente se considera resolved una vez que se ha solucionado el problema que causó el incidente.

Un incidente puede avanzar al estado resolved utilizando el comando /rootly resolve o a través del botón Resolve.

El valor de datos para el estado resolved es resolved.

Cuando un incidente está en el estado resolved, la {{ incident.resolved_at }} marca de tiempo se registrará automáticamente.

​

Cancelado

CANCELED - El incidente puede ser cancelado si se determina que no es un incidente real (falso positivo) o si es un duplicado de otro incidente. El valor de datos para este estado es canceled.

Un incidente se considera cancelled una vez que se ha determinado como un falso positivo o se ha identificado como un duplicado de un incidente existente.

Un incidente puede avanzar al estado cancelled utilizando el comando /rootly cancel o a través del botón Cancel Incident.

El botón Cancel Incident solo está disponible cuando el incidente está en el estado triage.

El valor de datos para el estado cancelled es cancelled.

Cuando un incidente está en el estado cancelled, la {{ incident.cancelled_at }} marca de tiempo se registrará automáticamente.

​

Propiedades del Incidente

Cada incidente creado en Rootly puede caracterizarse con un conjunto de propiedades de datos. Estas propiedades pueden ser integradas o personalizadas.

Las propiedades del incidente juegan un papel clave durante la gestión de incidentes ya que pueden

• ayudar a categorizar cada incidente (por ejemplo, tipo = seguridad, orientado al cliente, backend, etc.)

• ser utilizadas como condiciones de ejecución para automatizaciones (por ejemplo, crear retrospectiva de incidente cuando el estado = resuelto, notificar a la dirección si la gravedad = SEV0)

• ser utilizadas para obtener análisis de incidentes perspicaces (por ejemplo, trazar un gráfico desglosando los incidentes por su servicio afectado)

Puede leer más sobre estas propiedades en la página dedicada aquí.

​

Soporte

Si necesita ayuda o más información sobre esta página, por favor contacte asupport@rootly.como inicie un chat navegando aHelp > Chat with Us.