Tarde o temprano, en cualquier proyecto, es hora de trabajar en la estabilidad / disponibilidad de su servicio. Para algunos servicios, en la etapa inicial, la velocidad de desarrollo de características es más importante, en este momento el equipo no está completamente formado y las tecnologías no se seleccionan con mucho cuidado. Para otros servicios (a menudo tecnológicos b2b), con el fin de ganar la confianza del cliente, surge la necesidad de un alto tiempo de actividad con el primer lanzamiento público. Pero supongamos que el momento X, sin embargo, ha llegado y usted comenzó a preocuparse por cuánto tiempo "permanece" su servicio en el período del informe. Debajo del corte, sugiero ver de qué se trata el tiempo de inactividad y la mejor manera de trabajar para reducirlo.
Indicadores
Obviamente, antes de mejorar algo, debe comprender el estado actual. Por lo tanto, si comenzamos a reducir el tiempo de inactividad, es antes que nada y es necesario comenzar a medirlo.
No hablaremos aquí en detalle sobre cómo hacer esto específicamente, los pros y los contras de los diferentes enfoques, pero el proceso de tesis se parece a esto:
- confiamos en métricas cercanas al negocio (errores en el servicio, tiempo de respuesta del servicio, $ / segundo, registros / segundo, etc.)
- determinar qué es bueno y qué es malo
- transición buena-> mala es el comienzo de un incidente
- transición mala-> buena - fin del incidente
- tiempo de principio a fin - la duración del incidente (límite con nosotros)
- la suma de la duración de los incidentes para el período (mes / trimestre / año) - tiempo de inactividad
- (100 - <tiempo de inactividad> / <duración del período> * 100) = porcentaje de disponibilidad para el período
Cuando se habla de tiempo de actividad / tiempo de inactividad, a menudo mencionan otro indicador:
MTTR (tiempo medio de reparación): el tiempo promedio desde el inicio del incidente hasta su finalización.
Los problemas con él comienzan desde la primera palabra en la abreviatura. Dado que todos los incidentes son diferentes, promediar la duración no puede decirnos nada sobre el sistema.
Esta vez no promediaremos nada, solo veremos qué sucede durante el incidente.
Anatomía de un incidente.
Veamos qué pasos importantes se pueden distinguir durante el incidente:
- detección : el intervalo entre el primer error que le dimos al usuario antes de que el asistente recibiera el SMS
- reacción : desde recibir una notificación sobre un problema hasta el momento en que una persona comenzó a resolver este problema (generalmente en ese momento el evento de monitoreo se transfiere al estado Reconocido)
- investigación : desde el comienzo del trabajo sobre un problema hasta el momento en que se comprende la causa del incidente y sabemos qué se debe hacer para restaurar el trabajo.
- Eliminación : el tiempo de recuperación, por ejemplo, la versión de reversión, promovió un nuevo
maestro servidor de base de datos primario
Quizás nuestro modelo esté incompleto y haya otras etapas, pero propongo presentarlas solo después de darnos cuenta de cómo esto nos ayudará en la práctica. Mientras tanto, considere con más detalle cada etapa.
Detección
¿Por qué pasamos tiempo buscando una emergencia? ¿Por qué no enviar una notificación sobre el primer error que recibe un usuario? De hecho, conozco muchas compañías que intentaron hacer esto, pero abandonaron esta idea solo unas horas más tarde, por lo que recibieron varias decenas de SMS. Creo que no hay un solo servicio más o menos grande que no tenga un flujo constante de errores "en segundo plano". No todos son una señal de que algo se ha roto, también hay errores en el software, datos no válidos obtenidos del formulario y validación insuficiente, etc.
Como resultado, el nivel de errores (u otras métricas) que excede las fluctuaciones diarias se utiliza como criterio para abrir un incidente. Esto es precisamente lo que lleva al hecho de que la notificación de los empleados responsables se produce más tarde que el inicio real del problema.
Pero volvamos a nuestra tarea original: reducir la duración de los incidentes. ¿Cómo podemos acortar el tiempo de detección? ¿Más rápido para notificar? ¿Se te ocurre una súper lógica para detectar anomalías?
Sugiero no hacer nada todavía, sino mirar las siguientes etapas, ya que en realidad están interconectadas.
Reacción
Aquí tenemos un factor puramente humano. Suponemos que el monitoreo logró detectar el problema y despertamos con éxito al ingeniero de servicio (toda la escalada también funcionó en la etapa anterior).
Considere el "peor" caso, no tenemos un servicio de servicio dedicado, y la alerta atrapó al administrador que dormía pacíficamente. Sus acciones:
- responder a SMS: aquí una esposa con un oído sensible ayuda mucho, varias aplicaciones para el teléfono, mejorando el efecto de recibir SMS (1-5 minutos)
- tome la decisión de que, sin embargo, se arrastrará fuera de la cama: si las alertas no se configuran correctamente, una persona puede esperar 2 minutos "¿y si llega la resolución?" y quedarse dormido (1-15 minutos)
- llegar a la computadora portátil, abrir los ojos, despertarse, monitorear, presionar Ack: (1-15 minutos)
Como resultado, en el peor de los casos, tenemos 35 minutos de reacción. Según mis observaciones, ese tiempo de reacción parece ser cierto.
Como en esta etapa estamos tratando con personas, debemos actuar con mucho cuidado y consideración. ¡En ningún caso necesita escribir un reglamento según el cual una persona que acaba de despertarse debe moverse! Solo creemos las condiciones.
Eliminemos las dudas del ingeniero de que el problema terminará por sí solo. Esto se hace de manera muy simple: haga que el criterio de alerta sea insensible a problemas menores y notifique si el incidente dura un tiempo significativo . Sí, solo aumentamos la duración de la etapa de "detección", pero veamos un ejemplo:
- aumentar el tiempo de detección en 5 minutos
- el número de incidentes se reduce: todas las ráfagas cortas de errores generalmente caen en 1 minuto. Estos incidentes cortos deben registrarse, pero sin notificar a las personas. A menudo, dan un tiempo de inactividad muy grande en total, pero puede lidiar con ellos durante el horario comercial. Para esta tarea, necesitará una granularidad alta en el monitoreo, ya que el problema ya ha terminado, y las herramientas de diagnóstico en su mayor parte no mantienen el historial.
- Si una persona se ve obligada a responder a las alertas una vez al mes o con menos frecuencia, y no cada dos días, responderá de manera más adecuada y no tratará esto como una rutina.
- la notificación retrasada le permite a una persona no pensar: si llega un SMS, entonces todo es serio y no se corregirá
Potencialmente, este enfoque reducirá el tiempo de reacción total en más de 15 minutos. Si tal tiempo de reacción no le conviene, debe pensar en el servicio de guardia.
Investigación
Quizás esta sea la etapa más difícil de un accidente cuando necesite comprender qué está sucediendo y qué hacer. En realidad, esta etapa a menudo se combina con la etapa de tomar medidas, ya que generalmente el proceso es así:
- miramos el monitoreo, los registros (si el monitoreo no es suficiente), lanzamos algunas otras herramientas de diagnóstico
- presentar hipótesis
- Probamos las hipótesis, ya sea por métricas o realizando alguna acción (reiniciar todo :)
- evaluar los resultados de los cambios
- comunicarse con colegas si su conocimiento de un subsistema en particular no es suficiente
y así sucesivamente hasta la iluminación o el final del incidente.
Esta etapa suele ser la más significativa en la duración total del incidente. ¿Cómo reducirlo?
Aquí no todo está muy claro, hay varios vectores:
- Simplifique su infraestructura : imagine lo rápido que las personas que tienen una base de datos y un bloqueo de servicio
- difusión del conocimiento en un equipo : ideal si la comunicación de las personas no se realiza durante el incidente, sino durante el trabajo diario (la comunicación de las personas es generalmente un proceso muy largo)
- monitoreo : muchas personas piensan que el monitoreo funciona solo en la etapa de "detección", pero de hecho puede actuar como una optimización del proceso de prueba de hipótesis ("¿funciona la base de datos correctamente?", "¿mi servicio se convierte en recursos?") y también como un transporte difusión del conocimiento en equipo. "Serge, ¿verifica si hay errores en el registro X sobre puntos muertos?" puede convertirse en un disparador, cuya descripción será un enlace a la wiki con instrucciones .
Eliminación
Como dije anteriormente, esta etapa a menudo se fusiona con la anterior. Pero sucede que la razón está clara de inmediato, pero la recuperación será muy larga. Por ejemplo, tiene un servidor muerto con maestro primario (no podré acostumbrarme a él durante mucho tiempo :) con una base de datos, y nunca promoviste una réplica, es decir, leerás la documentación, implementarás una nueva configuración de la aplicación, etc.
Naturalmente, después de cada incidente significativo, debe descubrir cómo evitar que esto vuelva a suceder o acelerar en gran medida la recuperación. Pero veamos qué direcciones podemos tratar de resolver de manera proactiva:
- herramientas de administración de infraestructura : si para arreglar todo lo que necesita para implementar una nueva configuración, pero esto se hace en al menos 20 minutos, esta es su limitación. Intente idear escenarios de lo que podría suceder y una forma de acelerar urgentemente algunos procesos. Por ejemplo, en ansible ha configurado serial (ejecución paralela de tareas) = 3, pero si todavía miente, puede rodar con serial = 30, debe enseñar a todos a redefinir esto (de manera similar a la estrategia de actualización continua en kubernetes).
- simulacros : si sabe que los escenarios probables de falla y recuperación no están automatizados, debe tener instrucciones que deben probarse . Planifique el tiempo de inactividad (si es necesario), realice ejercicios. A menudo, en esta etapa, estos casos están automatizados, ya que la mayoría de las trampas de incluso los procedimientos más complicados a primera vista se aclaran durante los ejercicios.
- interacción con contratistas : debe saber de antemano qué hará si su proveedor de hosting se enferma. A menudo, la conciencia de la probabilidad de un problema y el costo del cierre del riesgo lleva a la conclusión: "solo esperaremos la recuperación". Pero, por otro lado, los ingenieros y las empresas estarán listos para tal escenario. Por ejemplo, puede resolver el problema de cambiar su tráfico a un código auxiliar preparado previamente, notificar a los usuarios con una carta preparada, etc. O viceversa, realiza una instrucción según la cual le damos al host 30 minutos para recuperarse, y luego comenzamos a movernos a otro DC, donde ya hay una réplica de la base de datos, pero necesita expandir todo lo demás. Y aquí nuevamente, las enseñanzas, tomamos nota del tiempo para moverse, etc.
MTBF (tiempo medio entre fallas)
Otra métrica común mencionada en la discusión del tiempo de actividad. Nuevamente, propongo no promediar nada, sino simplemente hablar sobre la cantidad de incidentes que ocurren durante un intervalo de tiempo.
Aquí viene la cuestión de cuánto se ha ocupado de la tolerancia a fallas de su servicio:
- ¿Hay un solo punto de falla (SPOF) en la infraestructura, cuál es la probabilidad de falla?
- ¿Qué tan seguro está de que no hay SPOF que desconozca? (este es exactamente el problema que resuelve el mono del caos )
- ¿Están funcionando bien los equilibradores de carga? ( mi informe sobre equilibrio )
- ¿Qué tan resistente es la red?
- ¿Qué tan confiable es el centro de datos?
A veces, para calcular / predecir todo esto, hacen un "mapa de riesgo", donde cada escenario (que podría suponerse, por supuesto, siempre hay aquellos que aún no conocemos) tiene una probabilidad + impacto (tiempo de inactividad corto / largo, pérdida de datos, pérdida de reputación , etc.) Luego, trabajan sistemáticamente en dicha tarjeta, cerrando en primer lugar escenarios muy probables y serios en términos de impacto.
Otra técnica que se puede utilizar es la clasificación de incidentes pasados. Se habla mucho ahora de que es muy útil escribir incidentes "post mortem", que analizan las causas del problema, las acciones de las personas, resuelven posibles acciones futuras. Pero para ver rápidamente las causas de todos los accidentes durante el período anterior, es conveniente resumir su duración con una agrupación de acuerdo con "clases de problemas" y dónde el mayor tiempo de inactividad es tomar medidas:
- errores humanos : reduzca el número de acciones manuales en producción, varias protecciones contra errores del operador
- lanzamientos fallidos : vale la pena mejorar las pruebas (incluidas las pruebas de carga)
- errores de aplicación : repara fugas, bloqueos y otras congelaciones
- red : comprar equipo, configurar, contratar redes, cambiar el contratista
- Bases de datos : contratar un DBA, cuidar la tolerancia a fallas, comprar mejor hardware
- DC : piense en respaldo o reubicación
- influencias externas (ddos, bloqueo, revisiones de certificados, dominios): compre antiddos, compre proxies, monitoree el período de validez de los dominios / certificados, tenga varios certificados de diferentes AC.
Es decir, si ni siquiera trata de predecir posibles escenarios de problemas, definitivamente vale la pena trabajar con incidentes que ya han sucedido.
Total
Todos los incidentes son diferentes:
El algoritmo para trabajar para aumentar el tiempo de actividad es muy similar a cualquier otra optimización:
-> -> ->
Desde mi propia experiencia, puedo decir que para una mejora significativa en el tiempo de actividad es suficiente comenzar a seguirlo y analizar las causas de los incidentes. Suele suceder que los cambios más simples traen el efecto más significativo.
Nuestro servicio de monitoreo ayuda no solo con la etapa de "detección", sino que también reduce en gran medida la "investigación" (los clientes lo confirmarán)