El llamado circuito cerrado se refiere a todo el proceso de emisión de alarmas, reclamos, procesamiento colaborativo, recuperación de problemas y revisión y mejora.
Programación, personal dedicado para realizar tareas especiales.
Este método no suena exagerado, pero es realmente muy efectivo. Aunque estaba preocupado durante el turno, tenía miedo de que me culparan, pero como era un sistema de turnos, siempre tuve esperanza en mi corazón y estaría bien sobrevivir a este ciclo.
La persona de turno es la primera persona responsable durante el turno, y dedicará el 120% de su energía a afrontar el problema, obviamente es más fácil promover la solución del problema cuando la persona es la responsable, siempre interrumpido por la policía. .
Los sistemas de programación generalmente no son de código abierto. Generalmente son una función del centro de eventos. PagerDuty proporciona capacidades de programación. Ayuda mucho.
Aunque el personal de servicio le ha prestado gran atención durante su período de servicio, inevitablemente lo descuidará, lo que requiere un mecanismo de escalada de alarma.
Mecanismo de escalada de alarma
La escalada de alarma se refiere a un mecanismo en el que el sistema notifica automáticamente al personal de segunda y tercera línea si la primera persona responsable no responde a tiempo después de recibir la alarma. Puede haber muchas razones por las que el personal de primera línea no respondió de manera oportuna, como que el teléfono móvil estaba silenciado y no lo escuchó, se quedó dormido por la noche o se olvidó de traer el teléfono móvil cuando salió temporalmente. En este momento, el sistema encuentra que una determinada alarma no se ha recuperado y no ha sido reclamada. Después de un período de tiempo, debe notificar al líder del personal de servicio o al personal de respaldo de segunda línea. El personal de línea no responde durante mucho tiempo, deben continuar actualizándose.
El mecanismo de escalada de alarma requiere la cooperación de la función de reclamo, es decir, después de que el personal de primera línea recibe la alarma, debe decirle al sistema a través de un determinado mecanismo: "Ya conocía la alarma y ahora he comenzado a lidiar". con ello, así que no intensifiques la situación".
Por lo tanto, el mecanismo de escalada generalmente está habilitado solo para alarmas graves y no es necesario habilitar el mecanismo de escalada para alarmas de advertencia o notificación. Por supuesto, cada equipo puede decidir cómo establecer este estándar.
Lógica de convergencia de alarmas
La lógica de convergencia general es la convergencia de tres niveles, evento -> alerta -> incidente.
La lógica de convergencia del evento a la alerta se denomina convergencia de primer nivel. Solo que esta lógica de convergencia no es suficiente y la información de alarma todavía está relativamente dispersa. No es fácil coordinar en función de estas alarmas dispersas y converger múltiples alertas en un incidente (falla). Es más conveniente coordinar en función del incidente. . Sin embargo, existe una lógica de convergencia fija de evento a alerta, que el programa puede hacer converger automáticamente, pero es difícil converger automáticamente de alerta a incidente.
1. Convergencia basada en tiempo, 2. Convergencia basada en tiempo + etiquetas, 3. Convergencia basada en tiempo + similitud de texto.
Dado que no hay forma de hacer converger automáticamente la alarma en una falla, se puede hacer manualmente. Es relativamente fácil distinguir las alarmas clave asociadas con una falla, siempre que las alarmas clave estén asociadas con la falla y la coordinación posterior basada en esta falla sea suficiente. La llamada colaboración, una es la sincronización de información y el procesamiento colaborativo, y la otra es la revisión y gestión conjunta de elementos de seguimiento.
Coordinación de fallas
En primer lugar, no es necesario escalar todas las alarmas a la coordinación de fallas. En términos generales, si la alarma puede ser tratada directamente por el personal de servicio, no afectará los servicios de otros equipos, no es necesario notificar a otros equipos y, por lo general, no es necesario actualizar a una falla. Es suficiente con coordinar en el nivel de alarma. El equipo lo digiere internamente; si la persona de turno y su equipo no pueden manejar la alarma por sí solos, es necesario actualizarla a falla y traer a personas de otros equipos para que se ocupen. con ello juntos.
Varios equipos trabajan juntos para solucionar una falla, y las personas de diferentes equipos encontrarán algunas pistas diferentes, que deben sincronizarse con todas las personas relevantes de manera oportuna. En este momento, puede agregar comentarios debajo de la falla y otros pueden verlo a tiempo. Una vez detenida la pérdida, todos deben revisar de acuerdo con el cronograma de fallas y producir una serie de elementos de seguimiento. En este momento, el módulo de gestión de fallas debe tener la función de gestión de elementos de seguimiento, o al menos poder comunicarse bien con el sistema de gestión de tareas.
Con un mecanismo de coordinación de fallas de este tipo, la probabilidad de que se resuelvan las fallas aumentará considerablemente. En el futuro, con algunos métodos de estadísticas operativas, se contará el tiempo promedio de pérdida de parada de fallas de cada equipo y se contarán las listas roja y negra. Todo el mundo tendrá un mayor entusiasmo para afrontar los fracasos. Por supuesto, no importa cuán entusiastas sean las personas, no son tan rápidas como las máquinas. Si algunas alarmas pueden relacionarse directamente con la lógica de procesamiento automático, sin duda aumentará en gran medida la tasa de eventos de circuito cerrado.
Manejo automático de alarmas
Muchos sistemas de monitoreo se pueden configurar con Webhooks para volver a llamar automáticamente a una interfaz HTTP cuando se activa una alarma para conectar alguna lógica automatizada de modo que el evento de alarma pueda procesarse automáticamente sin supervisión. Por ejemplo, si un determinado servicio en una sala de computadoras cuelga, la lógica del webhook es llamar automáticamente a la interfaz de corte de flujo para cortar el flujo del servicio, a fin de lograr el propósito de detener la pérdida.
Es posible que la lógica del procesamiento automático de alarmas no necesariamente pueda lograr la autorreparación de las alarmas. A veces es muy valioso utilizar este mecanismo simplemente para captar la escena. Por ejemplo, cuando un proceso se cuelga, quiero conocer algunas condiciones de ejecución de la máquina en ese momento, como la ocupación de varios recursos, información de registro del sistema, etc., podemos usar el método de procesamiento automático de alarmas para Ejecutar automáticamente un script para capturar información en el sitio en la máquina en ese momento es mucho más eficiente que iniciar sesión manualmente en la máquina para verificar después de recibir una alarma.
Este artículo es una nota de estudio del día 15 de agosto. El contenido proviene de las "Notas prácticas del sistema de monitoreo de operación y mantenimiento" de Geek Time . Se recomienda este curso.