Incidentes
Un incidente es cualquier evento no planificado que afecta materialmente a la disponibilidad, la fiabilidad, la latencia, la corrección o la postura de seguridad de los servicios de EvoMap.
Ciclo de vida
| Fase | Qué significa |
|---|---|
| Investigando | El equipo está confirmando el impacto, el alcance y la causa probable. |
| Identificado | Se conoce el componente o la dependencia afectados. |
| Mitigando | Se está aplicando una corrección, una reversión, un desvío de tráfico o una solución alternativa. |
| Supervisando | El servicio parece recuperado y el equipo vigila que no haya regresiones. |
| Resuelto | El incidente está cerrado y ya no causa impacto en los clientes. |
| Análisis post-incidente | Se está preparando o publicando un resumen de seguimiento o un análisis más profundo. |
Niveles de gravedad
| Gravedad | Impacto en el cliente | Ejemplos |
|---|---|---|
| P0 | Caída amplia en producción o riesgo para la seguridad de los datos. | El intercambio de tokens OAuth no está disponible para ningún cliente; la API pública devuelve 5xx de forma sostenida. |
| P1 | Degradación importante de una ruta crítica. | Las entregas de webhooks se retrasan en muchas aplicaciones; la cola de revisión de aplicaciones está bloqueada. |
| P2 | Impacto limitado o existe una solución alternativa fiable. | Una familia de endpoints está lenta; el historial de estado está desactualizado mientras la API en vivo funciona. |
| P3 | Defecto menor, problema de documentación o caso de soporte aislado. | Enlace incorrecto en la documentación; entrada poco clara en el registro de cambios. |
Registros públicos de incidentes
Un registro público de incidente debe incluir:
- Los servicios afectados y los síntomas visibles para el cliente.
- La hora de primera detección y la hora de resolución.
- Una cronología de las actualizaciones.
- La mitigación o la solución alternativa, si existe.
- El resumen final de la resolución.
- Un enlace al análisis post-incidente cuando se justifique un informe más profundo.
Los registros de incidentes no deben incluir datos personales de clientes, secretos, tickets privados, registros internos ni cargas útiles de solicitudes sin censurar.
Mantenimiento programado
El mantenimiento programado debe indicar:
- La hora de inicio y de fin previstas con su zona horaria.
- Los servicios que pueden verse afectados.
- Si pueden interrumpirse las llamadas a la API, los flujos OAuth, la entrega de webhooks o la revisión de aplicaciones.
- La acción esperada del cliente, si la hay.
Las actualizaciones de mantenimiento deben publicarse antes de la ventana, cuando comienza la ventana y cuando finaliza.
Cómo se relacionan los tickets de soporte con los incidentes
Los tickets de soporte son conversaciones privadas sobre un desarrollador, una organización, un cliente OAuth, una entrega de webhook o un caso de facturación concretos. Los incidentes son registros operativos públicos cuando el impacto es lo bastante amplio como para comunicarlo en la página de estado.
Un ticket puede vincularse a un incidente cuando informa del mismo problema subyacente de la plataforma. El ticket sigue siendo privado; el registro del incidente permanece público y censurado.
Cómo informar de un posible incidente
Antes de abrir un ticket:
- Consulta
/status. - Consulta el Registro de cambios por si hay un cambio reciente de la API o del comportamiento.
- Abre un ticket de soporte o escribe a
[email protected]con marcas de tiempo, ID de solicitud, endpoints afectados y los códigos de error observados.