Configuración de Incidentes
Configuration
Cada incidente creado en Rootly puede ser marcado con un conjunto de propiedades. Estas propiedades pueden ser integradas o una propiedad personalizada. Las propiedades del incidente juegan un papel clave durante la gestión de incidentes ya que
- ayudan a caracterizar cada incidente (por ejemplo, tipo = normal)
- pueden ser utilizadas como eventos desencadenantes (por ejemplo, Estado Actualizado)
- pueden ayudar a definir condiciones de ejecución (por ejemplo, Severidad es SEV0)
- pueden ser utilizadas como filtros de métricas
- pueden ser referenciadas usando la sintaxis de Liquid
Propiedades Fijas
Las propiedades fijas no se pueden personalizar. Son creadas tal cual por Rootly y están restringidas a propósito para imponer un cierto nivel de estándar en toda la plataforma.Tipo de Incidente
La propiedad de tipo es utilizada por Rootly para identificar la clasificación de los incidentes que se están creando. Este campo no se puede personalizar y se determina en el momento de la creación del incidente. Los tipos de incidentes disponibles son:| Tipo | Descripción | Valor de Datos |
|---|---|---|
| Incidente | Estos son los incidentes más comunes que crean los equipos. Se declaran a través del /rootly new comando de Slack. | normal |
| Sub Incidente | Estos son incidentes secundarios que se pueden crear bajo cualquier incidente normal. Se declaran dentro de un canal de incidente existente a través del /rootly sub comando de Slack. | normal_sub |
| Incidente de Prueba | Estos son equivalentes a un incidente normal, pero se utilizan con fines de prueba. Los incidentes de prueba no se pueden publicar en las páginas de estado. Se declaran a través del /rootly test comando de Slack. | test |
| Sub Incidente de Prueba | Estos son equivalentes a un sub incidente normal, pero se utilizan con fines de prueba. Los sub incidentes de prueba tampoco se pueden publicar en las páginas de estado. Se declaran dentro de un canal de incidente de prueba existente a través del /rootly sub comando de Slack. | test_sub |
| Incidente de Relleno | Estos son incidentes que se agregan DESPUÉS de que ya han sido resueltos. Cuando se declara un incidente de relleno, no se ejecutarán todos los flujos de trabajo que se activan en Incidente Creado. Se declaran a través del /rootly new comando de Slack y con la opción de Incidente de Relleno seleccionada. | backfilled |
| Mantenimiento Programado | Estos son “incidentes” que se pueden declarar para ciclos de mantenimiento planificados. Tienen sus propios estados únicos y otras propiedades. Se declaran a través del /rootly maintenance comando de Slack. | scheduled |
Estado del Incidente
El estado del incidente es un componente clave que impulsa los procesos de respuesta a incidentes. Al igual que con las otras propiedades en esta sección, el estado también es fijo y no se puede personalizar. Los estados de incidentes disponibles son:| Tipo | Descripción | Valor de Datos |
|---|---|---|
| Triaje | El estado de triaje se utiliza para problemas que no han sido confirmados como un incidente. Para declarar un incidente en el estado de triaje, simplemente marque la casilla Marcar como En Triaje al crear un incidente. Este estado NO se aplica a los mantenimientos programados. | in_triage |
| Iniciado | Esto marca el inicio oficial de un incidente. Puede hacer progresar un incidente desde el estado de triaje a iniciado o declarar un incidente directamente en el estado iniciado. Este estado NO se aplica a los mantenimientos programados. | started |
| Mitigado | El estado mitigado se utiliza para indicar que el impacto del incidente se ha detenido. Este no es el final de un incidente. Este estado NO se aplica a los mantenimientos programados. | mitigated |
| Resuelto | El estado resuelto se utiliza para indicar el final de un incidente. Esto es típicamente cuando se crean retrospectivas y se cierran los tickets de problemas activos. Este estado NO se aplica a los mantenimientos programados. | resolved |
| Cancelado | El estado cancelado se puede usar en cualquier momento de la vida de un incidente. Típicamente se utiliza para marcar un incidente falso positivo o cerrar un incidente duplicado. Este estado NO se aplica a los mantenimientos programados. | cancelled |
| Programado | El estado programado solo se aplica a los mantenimientos programados. Se utiliza para indicar que la ventana de mantenimiento ha sido planificada y creada. | scheduled |
| En Progreso | El estado en progreso solo se aplica a los mantenimientos programados. Se utiliza para indicar que la ventana de mantenimiento está actualmente activa. | in_progress |
| Completado | El estado completado solo se aplica a los mantenimientos programados. Se utiliza para indicar que el mantenimiento planificado ha terminado. | completed |
Propiedades Configurables
Las propiedades configurables están integradas, pero se pueden personalizar. A continuación se muestra una lista de propiedades configurables que se pueden personalizar para adaptarse a su proceso de gestión de incidentes. Por favor, haga clic en cada propiedad para descubrir cómo configurar cada propiedad y cómo referenciarlas a través de variables Liquid.| Propiedad | Descripción |
|---|---|
| Entornos | Esta propiedad le permite caracterizar los incidentes por el entorno que están impactando. Los incidentes que afectan a PROD deben tener prioridad sobre los incidentes que solo afectan a DEV. |
| Severidades | Esta propiedad le ayuda a categorizar el nivel de impacto de los incidentes. Los incidentes SEV0 deben manejarse con prioridad sobre los incidentes SEV3. |
| Tipos de Incidentes | Esta propiedad a menudo se confunde con la propiedad Tipo. Tipo es una categorización interna utilizada por la plataforma Rootly, mientras que Tipo se puede personalizar según los requisitos de categorización de incidentes de su empresa. El uso de esta propiedad es muy flexible. Algunas empresas la utilizan para distinguir errores de UI de problemas de API. Otras utilizan esta propiedad para distinguir interrupciones internas de incidentes que afectan a los clientes. |
| Roles de Incidentes | Esta propiedad ayuda a definir las responsabilidades de sus respondedores durante un incidente. Un Comandante de Incidentes debe tener tareas diferentes a las del Líder de Comunicaciones. |
| Equipos | Esta propiedad le permite asignar incidentes a sus equipos responsables. Los incidentes relacionados con el producto deben ir al equipo de Producto, mientras que los incidentes de seguridad son mejor manejados por el equipo de InfoSec. |
| Servicios | Esta propiedad le permite marcar los componentes de servicio que están impactados. Los servicios impactados pueden reflejarse en las páginas de estado. |
| Funcionalidades | Esta propiedad le permite marcar comportamientos funcionales específicos que se interrumpen durante los incidentes. Por ejemplo, la capacidad de agregar un artículo al carrito o la capacidad de iniciar sesión. Al igual que Servicios, Funcionalidades también se pueden mostrar en las páginas de estado. |
| Causas de Incidentes | Esta propiedad le permite categorizar rápidamente la causa raíz de los incidentes. Esto es particularmente útil para identificar tendencias al analizar incidentes históricos. |
Orden de propiedades
El orden de los elementos dentro de cada propiedad es el orden en que se muestran los elementos cuando la propiedad se utiliza como campo de formulario. El orden de los elementos es global, lo que significa que afectará a todas las personas que interactúen con el campo. Puede personalizar el orden de los elementos manualmente, arrastrando y soltando los elementos en el orden que prefiera, o ordenándolos alfabéticamente.