1. ¿Qué es el MTTR?

Cuando ocurre una falla en el sistema, necesitamos usar algunos indicadores para medir la gravedad y el alcance de la falla. Entre ellos, MTTR (Mean Time To Repair ) es un indicador muy importante, que puede ayudarnos a comprender el tiempo promedio necesario para reparar el sistema. No es aconsejable tardar demasiado en reparar el sistema, especialmente para una empresa como JD.com. Si el MTTR es demasiado largo, puede tener consecuencias graves, como la liquidación de las facturas de las tarjetas por parte del usuario y la pérdida de ingresos para la empresa. Por lo tanto, para garantizar la estabilidad y confiabilidad del sistema, debemos acortar el MTTR tanto como sea posible.

Para calcular el MTTR, divida el tiempo total de mantenimiento por el número total de operaciones de mantenimiento en un período de tiempo determinado. La fórmula de cálculo del MTTR es:

2. Cómo acortar el MTTR

Comprender MTTR es una herramienta muy importante para cualquier organización, ya que nos ayuda a responder y solucionar mejor los problemas en producción. En la mayoría de los casos, las organizaciones esperan reducir el MTTR a través de equipos de mantenimiento internos, lo que requiere los recursos, herramientas y soporte de software necesarios.

Entonces, ¿qué medidas puede tomar para acortar el MTTR de su organización? El mejor lugar para comenzar es comprender cada fase del MTTR y tomar medidas para reducir el tiempo dedicado a cada fase. En concreto, podemos considerar los siguientes aspectos:

1. Tiempo de descubrimiento de problemas: monitoreo y alarmas para identificar fallas

Para el período de tiempo que necesitan los técnicos para identificar el problema después de que ocurre una falla, podemos acortar el tiempo de identificación MTTR estableciendo un sistema de alarma. Al monitorear el funcionamiento del sistema en tiempo real y descubrir y activar rápidamente el mecanismo de alarma, podemos ayudarnos a localizar el problema en el menor tiempo posible y tomar las medidas adecuadas para repararlo.

Podemos filtrar información de alarmas innecesaria estableciendo umbrales y reglas razonables, evitando así que el ruido de las alarmas interfiera con el equipo de desarrollo y operación y permitiéndoles centrarse más en problemas reales.

1.1 Monitoreo de la UMP

Obtenga 3 indicadores de monitoreo dorados (tasa de disponibilidad, volumen de llamadas, TP99) a través de UMP.

Al configurar el mecanismo de alarma, podemos considerar de manera integral factores como la disponibilidad, TP99 y el volumen de llamadas para su evaluación. La evaluación integral de estos indicadores puede ayudarnos a obtener una comprensión más completa del funcionamiento del sistema, de modo que se puedan descubrir problemas potenciales de manera oportuna y se puedan tomar las medidas correspondientes.

Se recomienda que al configurar alarmas, primero se pueda adoptar una estrategia más estricta, es decir, apretar primero y luego aflojar, y ajustar gradualmente al mejor estado . Esto garantiza que los problemas se detecten en las primeras etapas y se eviten fallas importantes. Pero a medida que el sistema se estabiliza gradualmente, también podemos relajar el umbral de alarma adecuadamente según la situación real para mejorar la disponibilidad y eficiencia del sistema.

Cabe señalar que al configurar alarmas, debemos realizar ajustes y optimizaciones en función de escenarios comerciales específicos y características del sistema. Diferentes sistemas pueden tener diferentes puntos de riesgo y cuellos de botella, por lo que debemos formular estrategias de alarma correspondientes basadas en la situación real para garantizar la estabilidad y confiabilidad del sistema.

critical告警方式：咚咚、邮件、即时消息(京ME)、语音
可用率：（分钟级）可用率 < 99.9% 连续 3 次超过阈值则报警，且在 3 分钟内报一次警。
性能：（分钟级）TP99 >= 200.0ms 连续 3 次超过阈值则报警，且在 3 分钟内只报一次警。
调用次数：当方法调用次数在 1 分钟的总和，连续 3 次大于 5000000 则报警，且在 3分钟内只报一次警

warning告警方式：咚咚、邮件、即时消息
可用率：（分钟级）可用率 < 99.95% 连续 3 次超过阈值则报警，且在 30 分钟内报一次警。
性能：（分钟级）TP99 >= 100.ms 连续 3 次超过阈值则报警，且在 30 分钟内只报一次警。
调用次数：当方法调用次数在 1 分钟的总和，连续 3 次大于 2000000 则报警，且在 3 分钟内只报一次警

Si UMP es una tarea programada, el punto más importante es determinar el período de seguimiento . Solo configurando correctamente el período de monitoreo podemos asegurar que el UMP se ejecute normalmente dentro del período de tiempo esperado, de esta manera, una vez que el UMP no se ejecute dentro del período de tiempo esperado, el mecanismo de alarma se activará automáticamente para detectar y resolver. el problema a tiempo.

1.2 Las llamadas de alarma deberían realizarse de forma rápida, precisa y poco frecuente.

Al procesar información de alarmas, nuestra clave no es la cantidad, sino la exactitud e integridad de la información . Nuestro equipo recibe cientos de mensajes de alarma cada día. ¿Tienes suficiente energía y tiempo para revisar cada uno? ¿Puedes asegurarte de que cada uno reciba atención?

Por lo tanto, debemos evaluar el impacto comercial y establecer una frecuencia de alarma adecuada según la situación. Especialmente para aquellos mensajes de alarma que se consideran "voces clave", debemos descubrirlos y solucionarlos lo antes posible . Sólo así podremos asegurarnos de poder responder con rapidez y precisión ante emergencias y minimizar los posibles impactos.

1.3 Los detalles determinan el éxito o el fracaso.

1. Si el tiempo de respuesta a la información de alarma es largo, debemos verificar si el mecanismo de respuesta de servicio del equipo es normal. Necesitamos asegurarnos de que la información de la alarma pueda comunicarse de manera efectiva a las personas adecuadas para que el problema pueda resolverse de manera oportuna.

2. En cuanto a la liquidación diaria de la información de alarma, debemos establecer un mecanismo de procesamiento correspondiente para garantizar que cada información de alarma pueda manejarse adecuadamente. Si no podemos lograr la compensación y el cierre diarios, debemos analizar en profundidad los motivos y tomar las medidas correspondientes para mejorarlos.

3. Al procesar información de alarmas, debemos analizar en profundidad sus causas fundamentales. Sólo encontrando la raíz del problema se podrá resolver fundamentalmente.

4. Si la alarma es frecuente pero no se ha solucionado, debemos considerar seriamente si la alarma es necesaria. A veces, algunas alarmas pueden ser causadas por falsas alarmas o problemas irrelevantes, en este momento debemos filtrar y excluir estas alarmas.

5. Si ocurre un problema y no se agrega la información de alarma correspondiente de UMP u otros enlaces, debemos verificar cuidadosamente si hay otros enlaces principales que también se han perdido. Si falta alguna adición, podemos utilizar la herramienta de escaneo para encontrarla.

6. Para la información de alarma que apareció antes, no podemos concluir, según la experiencia, que sea causada por un motivo determinado. La experiencia histórica no es necesariamente precisa y confiable, y sólo se pueden sacar conclusiones reales mediante la investigación y el análisis de registros relevantes.

7. Al configurar la información de alarma, debemos considerar cuidadosamente su racionalidad. Se recomienda ajustar gradualmente a las mejores condiciones apretando primero y luego aflojando. Esto puede evitar demasiados o muy pocos mensajes de alarma desde el principio, mejorando así la eficiencia y precisión del trabajo.

2. Es hora de aliviar los problemas del sistema: mecanismo de respuesta a fallas, hemostasia rápida

¿Por qué necesitamos mitigar los problemas del sistema en lugar de simplemente localizarlos? Esto se debe a que cuando se trata de problemas del sistema, simplemente localizar el problema es sólo una parte de la solución. Más importante aún, debemos mitigar los problemas del sistema lo más rápido posible para evitar un mayor impacto en el negocio.

Para mejorar la eficiencia del manejo de problemas, debemos partir de los siguientes tres aspectos:

1. Mejorar el sistema de comando y la división de roles : un sistema de comando completo y una división de roles clara pueden mejorar efectivamente la eficiencia del manejo de fallas. Al abordar problemas, cada rol debe aclarar sus responsabilidades y tareas y trabajar juntos para resolver el problema.

2. Medios completos de aislamiento de fallas técnicas : a nivel técnico, debemos adoptar algunos medios de aislamiento de fallas, como a través de interruptores DUCC, para evitar una reversión excesiva del código. Esto puede detener el sangrado más rápidamente (DUCC cambia en segundos, si la máquina retrocede varias veces, tardará entre 5 y 10 minutos)

3. Garantía de un mecanismo de manejo de fallas suficientemente detallado : Finalmente, necesitamos establecer una garantía de un mecanismo de manejo de fallas suficientemente detallado, que incluya pruebas ambientales UAT, simulacros de resolución de problemas, SOP del plan de emergencia, etc. Esto permite una respuesta rápida y una resolución eficaz de problemas cuando surgen problemas.

En resumen, para mejorar la eficiencia del manejo de problemas, debemos tomar una serie de medidas para aliviar el tiempo de problemas del sistema, no solo localizar el problema. Sólo así se podrá garantizar realmente la estabilidad y fiabilidad del sistema.

2.1 Implementar un mecanismo de respuesta de emergencia ante fallas

Independientemente del tamaño de una organización, una de sus características más importantes es su capacidad para responder a emergencias. Al enfrentar emergencias, es necesario contar con un plan de emergencia completo y un mecanismo de capacitación práctica para garantizar que se pueda responder a diversas emergencias de manera rápida y efectiva. Para lograr este objetivo debemos partir de los siguientes aspectos:

1. Establecer un proceso completo de entrenamiento y ejercicio: Es muy importante establecer y mantener un proceso completo de entrenamiento y ejercicio. Esto requiere un grupo de personas que estén familiarizadas con el negocio y dedicadas a ser responsables de formular y ejecutar planes relevantes. Al mismo tiempo, es necesario realizar simulacros y pruebas de simulación periódicamente basados en condiciones reales para garantizar la eficacia y operatividad de los planes de emergencia.

2. Informe el problema al grupo primero y utilice las fortalezas del equipo: cuando se enfrente a una emergencia, primero debe informar el problema al grupo y aprovechar al máximo las fortalezas del equipo. Mediante una lluvia de ideas se puede encontrar más rápidamente la causa raíz del problema y se pueden tomar las medidas correspondientes para solucionarlo.

3. Determine razonablemente la gravedad del problema: al determinar la gravedad del problema, es necesario tener un buen criterio de ingeniería y mantener un cierto nivel de calma.

En resumen, para mejorar la capacidad de la organización para responder a emergencias, necesitamos establecer un proceso completo de entrenamiento y ejercicio, aprovechar al máximo la fuerza del equipo y determinar razonablemente la gravedad del problema . Sólo así se podrá garantizar realmente la estabilidad y fiabilidad de la organización.

División de roles clave

1. Comandante de falla . Este rol es el núcleo de todo el sistema de comando, su responsabilidad más importante es la organización y coordinación, no la ejecución, como responsable, líder de equipo y arquitecto.

2. Comunicación y orientación . Responsable de la recopilación y presentación de informes de información interna y externa, pero requiere buenas habilidades de comunicación y expresión, como un gerente de producto.

3. Ejecutor . Todo tipo de personal involucrado en el manejo de fallas es responsable de la ubicación real de fallas y la recuperación del negocio, como los colegas principales de I + D y operación y mantenimiento del equipo.

Mecanismo de proceso

1. Después de que se descubre una falla, los colegas de guardia o los líderes de equipo tienen derecho a convocar al desarrollo comercial correspondiente u otros recursos necesarios para organizar rápidamente una reunión.

2. Si el problema es difícil y tiene un gran impacto, puede solicitar la intervención de un nivel superior, como el jefe de departamento, etc.

mecanismo de retroalimentación

Comentarios sobre el progreso del procesamiento actual y la siguiente acción. Si hay alguna operación que deba realizarse de inmediato, infórmela con anticipación. El contenido que debe informarse incluye el impacto en el negocio y el sistema. Finalmente, el comandante de fallas hará una decisión antes de ejecutarla para evitar estar ocupado. Algo salió mal. Ningún progreso sigue siendo progreso y se requiere retroalimentación oportuna. Comentarios de personal no técnico, como atención al cliente, etc. No se debe describir en términos técnicos, sino en un lenguaje lo más comercial posible, y se debe dar a la otra parte una expectativa aproximada, como por ejemplo qué estamos haciendo, cuánto tiempo llevará recuperarnos y si no puede hacerlo. se restaurará, ¿cuánto tiempo tomará recibir una devolución de llamada? Comentarios y más.

2.2 Plan de emergencia de hemostasia rápida

Principios básicos: en todos los medios y acciones tomadas durante el proceso de manejo de fallas, la recuperación del negocio es la máxima prioridad y restaurar las soluciones de hemostasia en el sitio es mayor que encontrar la causa de la falla.

1. Cuando se enfrenta a un problema, su primera reacción puede ser iniciar inmediatamente el proceso de resolución de problemas e intentar encontrar la causa raíz del problema lo antes posible. ¡Esto está mal! No hagas esto. El enfoque correcto es: mitigar los problemas del sistema es la primera prioridad y hacer todo lo posible para restaurar el sistema al servicio.

2. Detener el sangrado rápidamente en lugar de investigar la causa raíz. Primero, solo es necesario localizar aproximadamente el problema y luego restaurar la escena mediante algunas medidas del plan de emergencia (desactualización del interruptor DUCC, limitación de corriente, reversión, etc.).

3. Para problemas en línea, primero piense si se debe a cambios como conectarse a Internet, modificar la configuración comercial, etc., y alinear la información.

4. Comenzaron a aparecer errores durante el lanzamiento, pero ¿todo era normal antes del lanzamiento? No se preocupe por nada, retírelo primero y luego investigue lentamente después de que vuelva a la normalidad.

5. ¿ La aplicación ha estado ejecutándose de manera estable durante mucho tiempo, pero de repente el proceso comienza a cerrarse? Lo más probable es que se trate de una pérdida de memoria, así que reinicie el método silenciosamente.

6. ¿Cómo confirmar si se trata de un problema introducido en línea? ¿Existe el mismo problema año tras año antes de conectarse (como ayer o la semana pasada) ? Si también existe, significa que no tiene nada que ver con estar en línea. Eche un vistazo al registro de ayer: el registro es el más confiable. La tasa de disponibilidad engañará a todos (porque es posible que haya administrado la tasa de disponibilidad hoy y la tasa de disponibilidad antes era del 100%, pero no necesariamente es del 100%).

7. Los negocios, los productos y la I+D se ejecutan en paralelo

8. Al localizar el problema rápidamente, la escena del problema debe guardarse a tiempo. Por ejemplo, primero elimine el servicio JSF, pero conserve una máquina (no la reinicie) y conserve la información de la pila JVM para el análisis posterior de la causa raíz.

2.3 Aprovechar al máximo las herramientas existentes para analizar de forma inteligente los problemas de posicionamiento

2.2.1 Para TP99, que es alto y difícil de posicionar:

La relación de llamadas es compleja, lo que dificulta localizar rápidamente los cuellos de botella en el rendimiento. Se pueden utilizar herramientas para clasificar de antemano las complejas dependencias entre servicios y centrarse en las cuestiones centrales de los servicios con cuellos de botella, en lugar de clasificar los vínculos sólo cuando surgen problemas.

• Como Taishan failover, etc.: informa de forma inteligente con qué factor está más relacionada esta alarma, la función está en prueba.

• La señalización global, que integra los puntos de recogida de UMP, puede localizar rápidamente qué enlace tiene un alto TP99

• Aplicación de enlace largo, configura el gráfico de radar de Taishan.

• Enlace de llamadas distribuidas de Pfinder como base para el análisis

2.2.2 En respuesta al repentino aumento del volumen de llamadas

Puede usar JSF> Protección del tráfico> Aplicaciones e interfaces> Alias y nombre del método para ubicar el volumen de llamadas de las aplicaciones ascendentes y luego tomar las medidas correspondientes, como la comunicación ascendente, las estrategias de limitación actuales, etc.

2.2.3 Análisis de subprocesos, JVM, muestreo de CPU de gráfico de llama, etc.

Plataforma Taishan》Diagnóstico de fallas》Diagnóstico en línea

2.2.4 Cuestiones comerciales

Según la búsqueda en el cuaderno de bitácora, no hay nada que decir al respecto.

Al guiar y capacitar a los técnicos a través de procedimientos estandarizados, puede reducir el tiempo que lleva resolver los problemas. En caso de que se produzca la misma falla, contar con la documentación y los planes de respuesta a emergencias (POE) adecuados le permite examinar rápidamente todos los factores causales que pueden haber provocado la falla.

3. Resumen

Una vez reparado el problema en línea, redactar un informe de revisión del COE (Centro de Excelencia) es un paso muy importante. En este informe podemos revisar todo el proceso de manejo del problema y pensar en lo que podríamos haber hecho para acortar el MTTR (tiempo medio de reparación) más rápido si lo hubiéramos hecho en ese momento.

En concreto, podemos partir de los siguientes aspectos:

1. Analice la causa del problema: primero, debe realizar un análisis en profundidad del problema para descubrir la causa raíz del problema . Sólo encontrando la causa raíz del problema podremos tomar medidas específicas para resolverlo y acortar el MTTR.

2. Resumir experiencias y lecciones: en el proceso de análisis del problema, debemos resumir experiencias y lecciones y hacer sugerencias para mejorar. Estas sugerencias pueden incluir optimizar procesos, mejorar la eficiencia, reforzar la formación, etc., pero no es necesario enumerar un montón de acciones, sólo centrarse en los puntos clave según la regla 2/8 .

3. Haga inferencias de un ejemplo para evitar que ocurran problemas similares la próxima vez : Necesitamos aplicar la experiencia y las lecciones aprendidas de este problema a otros problemas similares para evitar que problemas similares vuelvan a ocurrir.

En resumen, mediante un análisis en profundidad de los problemas, identificando las causas fundamentales, resumiendo experiencias y lecciones y sacando inferencias de un ejemplo, podemos acortar efectivamente el MTTR y garantizar la estabilidad y confiabilidad del sistema .

referencia:

SRE Descifrado de operación y mantenimiento de Google

Entrega continua 2.0

Autor: JD Logística Feng Zhiwen

Fuente: Comunidad de desarrolladores de JD Cloud Ziyuanqishuo Tech Indique la fuente al reimprimir

[Estabilidad] Exploración sobre el acortamiento del MTTR | Equipo técnico de JD Logistics