SRE (Ingeniería de confiabilidad del sitio): un enfoque para garantizar la disponibilidad de proyectos web. Se considera un marco para DevOps y explica cómo tener éxito en la aplicación de las prácticas de DevOps. Este artículo es una traducción del Capítulo 6 Monitoreo de sistemas distribuidos del libro de Ingeniería de confiabilidad del sitio de Google. Preparé esta traducción yo mismo y confié en mi propia experiencia para comprender los procesos de monitoreo. En el canal de telegramas @monitorim_it y el blog en el Medio, también publiqué un enlace a la traducción del cuarto capítulo del mismo libro sobre los objetivos del nivel de servicio.

Traducción por cat. Que tengas una buena lectura!

Los equipos de Google SRE tienen los principios básicos y las mejores prácticas para crear sistemas exitosos de monitoreo y notificación. Este capítulo proporciona recomendaciones sobre los problemas que puede encontrar un visitante de la página web y cómo resolver los problemas que dificultan la visualización de las páginas web.

Definiciones

No se utiliza un vocabulario único para discutir temas relacionados con el monitoreo. Incluso en Google, los términos a continuación no se usan comúnmente, pero enumeraremos las interpretaciones más comunes.

Monitoreo

Recopilación, procesamiento, agregación y visualización de datos cuantitativos en tiempo real sobre el sistema: la cantidad de solicitudes y tipos de solicitudes, la cantidad de errores y tipos de errores, el tiempo de procesamiento de solicitudes y el tiempo de actividad del servidor.

Monitoreo de caja blanca

Monitoreo basado en métricas mostradas por componentes internos del sistema, incluidos registros, métricas de perfiles de la máquina virtual Java o manejador HTTP que generan estadísticas internas.

Monitoreo de caja negra

Probar el comportamiento de la aplicación desde el punto de vista del usuario.

Tablero (tableros)

Una interfaz (generalmente la web) que proporciona una visión general de los indicadores clave de salud para los servicios. El panel de control puede tener filtros, la capacidad de seleccionar indicadores para mostrar, etc. La interfaz se crea para identificar los indicadores más importantes para los usuarios. La información para el personal de soporte técnico también se puede mostrar en el tablero: cola de solicitudes, lista de errores de alta prioridad, ingeniero asignado para un área de responsabilidad determinada.

Alerta (aviso)

Notificaciones diseñadas para ser recibidas por una persona por correo electrónico o de otra manera, que pueden iniciarse como resultado de errores o un aumento en la cola de solicitudes. Las notificaciones se clasifican en: tickets, alertas por correo electrónico y mensajes de mensajería.

Causa raíz

Un defecto de software o factor humano que no debería volver a ocurrir cuando se elimina. El problema puede tener varias razones principales: automatización insuficiente de los procesos, defecto de software, estudio insuficiente de la lógica de la aplicación. Cada uno de estos factores puede ser la causa raíz, y cada uno de ellos debe ser eliminado.

Nodo y máquina

Términos intercambiables para denotar una sola instancia de una aplicación en ejecución en un servidor físico, máquina virtual o contenedor. Puede haber varios servicios en una máquina. Los servicios pueden ser:

• relacionados entre sí: por ejemplo, un servidor de caché y un servidor web;
• servicios no relacionados en un solo hardware: por ejemplo, un repositorio de código y un asistente para un sistema de configuración, como Puppet o Chef .

Empujar

Cualquier cambio en la configuración del software.

Por qué se necesita monitoreo

Hay varias razones por las cuales las aplicaciones deben ser monitoreadas:

Análisis de tendencia larga

¿Qué tan grande es la base de datos y qué tan rápido está creciendo? ¿Cómo está cambiando el número diario de usuarios?

Comparación de rendimiento

¿Las consultas de Acme Bucket of Bytes 2.72 son más rápidas que Ajax DB 3.14? ¿Cuánto mejor se almacenan en caché las solicitudes después de la aparición de un nodo adicional? ¿El sitio se ha vuelto más lento en comparación con la semana pasada?

Alertas (notificaciones)

Algo está roto y alguien necesita arreglarlo. O algo se romperá pronto y alguien debería comprobarlo pronto.

Crear paneles

Los paneles deben responder preguntas básicas e incluir algunas de las "4 señales de oro" : latencia, tráfico, errores y carga (saturación).

Realización de un análisis retrospectivo (depuración)

El retraso en el procesamiento de la solicitud ha aumentado, ¿y qué más sucedió al mismo tiempo?
Los sistemas de monitoreo son útiles como fuente de datos para los sistemas de inteligencia de negocios y para simplificar el análisis de incidentes de seguridad. Dado que este libro se enfoca en áreas de ingeniería en las cuales los SRE tienen experiencia, no discutiremos las técnicas de monitoreo aquí.

El monitoreo y las alertas le permiten al sistema saber cuándo se ha roto o está a punto de romperse. Cuando el sistema no puede recuperarse automáticamente, queremos que la persona analice la alerta, determine si el problema es relevante, solucione y determine su causa raíz. Si no audita los componentes del sistema, nunca recibirá una alerta simplemente porque "algo parece un poco extraño".

La carga de alertas humanas es un uso bastante costoso del tiempo de los empleados. Si un empleado está trabajando, una alerta interrumpe el flujo de trabajo. Si el empleado está en casa, la notificación interrumpe el tiempo personal y, posiblemente, el sueño. Cuando las alertas ocurren con demasiada frecuencia, los empleados escanean, retrasan o ignoran rápidamente las alertas entrantes. De vez en cuando, ignoran la alerta real, que está enmascarada por los eventos de ruido. Las interrupciones del servicio pueden durar mucho tiempo, porque los eventos de ruido interfieren con el diagnóstico rápido y la resolución de problemas. Los sistemas de advertencia eficientes tienen una buena relación señal / ruido.

Definir expectativas razonables de un sistema de monitoreo

Configurar el monitoreo de una aplicación compleja es en sí mismo una tarea de ingeniería difícil. Incluso con una importante infraestructura de herramientas para recopilar, mostrar y alertar, el equipo de Google SRE con 10-12 miembros generalmente incluye una o dos personas cuyo objetivo principal es crear y mantener sistemas de monitoreo. Este número ha disminuido con el tiempo a medida que generalizamos y centralizamos la infraestructura de monitoreo, pero cada equipo de SRE generalmente tiene al menos un personal de monitoreo. Debo decir que, aunque es bastante interesante observar los paneles del sistema de monitoreo, los equipos de SRE evitan cuidadosamente situaciones que requieren que alguien mire la pantalla para monitorear los problemas.

En general, Google cambió a sistemas de monitoreo simples y rápidos con herramientas óptimas para el análisis post-factum. Evitamos sistemas "mágicos" que intentan predecir umbrales o detectar automáticamente la causa raíz. Los sensores que detectan contenido inapropiado en las solicitudes del usuario final son los únicos contraejemplos; Mientras estos sensores sigan siendo simples, pueden identificar rápidamente las causas de anomalías graves. Otros formatos para usar datos de monitoreo, como la planificación de capacidad o el pronóstico del tráfico, son más desafiantes. La observación realizada durante mucho tiempo (meses o años) con una baja tasa de muestreo (horas o días) revelará una tendencia a largo plazo.

El equipo de Google SRE ha trabajado con éxito variable con jerarquías de dependencia complejas. Raramente usamos reglas como "si descubro que la base de datos ha comenzado a funcionar lentamente, recibo una notificación sobre la desaceleración de la base de datos, de lo contrario, recibo una alerta sobre un sitio que funciona lentamente". Las reglas basadas en la dependencia generalmente se aplican a partes invariables de nuestro sistema, como un sistema para filtrar el tráfico de usuarios a un centro de datos. Por ejemplo, "si el filtrado de tráfico al centro de datos está configurado, no me avise sobre los retrasos en el procesamiento de las solicitudes de los usuarios"; esta es una regla general para las notificaciones del centro de datos. Pocos equipos en Google admiten jerarquías de dependencia complejas porque nuestra infraestructura tiene una tasa constante de refactorización continua.

Algunas de las ideas descritas en este capítulo siguen siendo relevantes: siempre existe la oportunidad de pasar más rápido de un síntoma a una causa raíz, especialmente en sistemas que cambian constantemente. Por lo tanto, aunque este capítulo describe algunos objetivos para los sistemas de monitoreo y las formas de lograr estos objetivos, es importante que los sistemas de monitoreo sean simples y comprensibles para todos en el equipo.

Del mismo modo, para mantener un bajo nivel de ruido y un alto nivel de señal, los enfoques para monitorear objetos para los que se realizan alertas deben ser muy simples y confiables. Las reglas que generan advertencias para las personas deben ser fáciles de entender y presentar un problema claro.

Síntomas vs. Causas

Su sistema de monitoreo debe responder dos preguntas: "qué se rompió" y "por qué se rompió".
"Lo que está roto" habla del síntoma y "por qué está roto" de la causa. La siguiente tabla muestra ejemplos de tales paquetes.

"Qué" y "por qué" son algunos de los bloques de construcción más importantes para crear un buen sistema de monitoreo con señal máxima y ruido mínimo.

Caja negra vs caja blanca

Combinamos un amplio monitoreo de caja blanca con un modesto monitoreo de caja negra para métricas críticas. La forma más fácil de comparar la caja negra con la caja blanca es que la caja negra está orientada a los síntomas y es un monitoreo reactivo más que proactivo: "el sistema no está funcionando en este momento". El cuadro blanco depende de las capacidades de verificación interna del sistema: registros de eventos o servidores web. Por lo tanto, el cuadro blanco le permite detectar problemas futuros, mal funcionamiento que parecen una retransmisión de una solicitud, etc.

Tenga en cuenta que en un sistema multicapa, un síntoma en el área de responsabilidad de un ingeniero es un síntoma en el área de responsabilidad de otro ingeniero. Por ejemplo, el rendimiento de la base de datos ha disminuido. Las lecturas lentas de la base de datos son un síntoma de las SRE en las bases de datos que las detectan. Sin embargo, para el SRE front-end, que observa un sitio web lento, la razón de la misma lectura lenta de la base de datos es el funcionamiento lento de la base de datos. Por lo tanto, el monitoreo de recuadro blanco a veces se enfoca en los síntomas y, a veces, en razones, dependiendo de cuán extenso sea.

Al recopilar telemetría, se requiere monitoreo de caja blanca para la depuración. Si los servidores web responden lentamente a las consultas de la base de datos, debe saber qué tan rápido interactúa el servidor web con la base de datos y qué tan rápido responde. De lo contrario, no puede distinguir un servidor de base de datos lento de un problema de red entre el servidor web y la base de datos.

El monitoreo de recuadro negro tiene una ventaja clave al enviar alertas: inicia una notificación al destinatario cuando el problema ya ha provocado síntomas reales. Por otro lado, para un problema de caja negra que aún no ha surgido, pero es inminente, el monitoreo es inútil.

Cuatro señales de oro

Las cuatro señales doradas de monitoreo son latencia, tráfico, errores y saturación. Si solo puede medir cuatro métricas en un sistema de usuario, concéntrese en estas cuatro.

Retraso

El tiempo requerido para procesar la solicitud. Es importante distinguir entre la demora de solicitudes exitosas y no exitosas. Por ejemplo, un error HTTP 500 causado por una pérdida de conexión a una base de datos u otro backend puede diagnosticarse muy rápidamente, sin embargo, un error HTTP 500 puede indicar una solicitud fallida. Identificar el efecto del error 500 en el retraso general puede llevar a conclusiones erróneas. Por otro lado, ¡un error lento es incluso un error rápido! Por lo tanto, es importante rastrear el retraso con un error, y no solo filtrar los errores.

Tráfico

El número de solicitudes a su sistema se mide en métricas de sistema de alto nivel. Para un servicio web, esta dimensión generalmente representa el número de solicitudes HTTP por segundo, separadas por la naturaleza de la solicitud (por ejemplo, contenido estático o dinámico). Para un sistema de transmisión de audio, esta medición puede concentrarse en la velocidad de E / S de la red o en la cantidad de sesiones simultáneas. Para un sistema de almacenamiento de valor clave, dicha medición puede ser transacciones o resultados de búsqueda por segundo.

Errores

Esta es la frecuencia de solicitudes fallidas que son explícitamente (por ejemplo, HTTP 500), implícitamente (por ejemplo, HTTP 200, pero en combinación con el contenido incorrecto), o una política (por ejemplo, "Si registró la respuesta en un segundo, cualquier segundo es un error"). Si los códigos de respuesta del protocolo HTTP son insuficientes para expresar todas las condiciones de falla, se pueden requerir protocolos secundarios (internos) para detectar fallas parciales. El monitoreo de todas estas solicitudes erróneas puede no ser informativo, mientras que las pruebas de sistema de extremo a extremo lo ayudarán a descubrir que está procesando el contenido incorrecto.

Saturación

La métrica muestra cuánto se utiliza su servicio. Esta es una medida de monitoreo del sistema que identifica los recursos más limitados (por ejemplo, en un sistema con memoria limitada, muestra memoria, en un sistema con limitaciones de E / S, se muestra el número de E / S). Tenga en cuenta que muchos sistemas degradan el rendimiento antes de alcanzar el 100% de utilización, por lo que es importante tener un propósito de uso.

En sistemas complejos, la saturación se puede complementar midiendo la carga de un nivel superior: ¿puede su servicio manejar adecuadamente el tráfico dual, procesar solo un 10% más de tráfico o procesar incluso menos tráfico del que lo hace actualmente? Para servicios simples que no tienen parámetros que cambien la complejidad de la solicitud (por ejemplo, "No me dé nada" o "Necesito un número entero único y monótono") que rara vez cambian su configuración, el valor estático de la prueba de carga puede ser adecuado. discutido en el párrafo anterior, la mayoría de los servicios deberían usar señales indirectas, como la utilización de la CPU o el ancho de banda de la red, que tienen un límite superior conocido. El aumento de la latencia es a menudo un indicador primario de saturación. Medir el tiempo de respuesta del percentil 99 en una ventana pequeña (por ejemplo, un minuto) puede dar una señal de saturación muy temprana.

Finalmente, la saturación también se asocia con predicciones de saturación inminente, por ejemplo: "Parece que su base de datos llenará su disco duro en 4 horas".

Si mide las cuatro señales doradas y cuando surge un problema con una de las métricas (o, en el caso de saturación, casi un problema), notifique a la persona, su servicio será más o menos monitoreado.

Ansiedad por la cola (o instrumentación y rendimiento)

Al crear un sistema de monitoreo desde cero, es tentador desarrollar un sistema basado en valores promedio: latencia promedio, utilización promedio de CPU de nodos u ocupación promedio de la base de datos. El peligro de los dos últimos ejemplos es obvio: los procesadores y las bases de datos se eliminan de una manera muy impredecible. Lo mismo ocurre con el retraso. Si ejecuta un servicio web con un retraso promedio de 100 ms a 1000 solicitudes por segundo, el 1% de las solicitudes puede demorar 5 segundos. Si los usuarios dependen de varios de estos servicios web, el percentil 99 de un servidor puede convertirse fácilmente en el tiempo medio de respuesta de la interfaz.

La forma más sencilla de distinguir entre un promedio lento y una "cola" de consultas muy lenta es recopilar las dimensiones de consulta expresadas en estadísticas (una herramienta adecuada para mostrar histogramas) en lugar de retrasos reales: cuántas solicitudes fueron atendidas por el servicio, que tomó entre 0 ms y 10 ms, entre 10 ms y 30 ms, entre 30 ms y 100 ms, entre 100 ms y 300 ms, etc. Expandir los bordes del histograma de manera aproximadamente exponencial (con un coeficiente aproximado de 3) es a menudo una forma simple de visualizar la distribución de consultas.

Elección del nivel de detalle adecuado para mediciones

Se deben medir diferentes elementos del sistema con diversos grados de detalle. Por ejemplo:

• El monitoreo de la utilización de la carga de la CPU en un intervalo de tiempo específico no mostrará valores atípicos a largo plazo que den como resultado altas latencias.
• Por otro lado, para un servicio web que se enfoca en no más de 9 horas de tiempo de inactividad por año (99.9% del tiempo de actividad anual), la verificación de una respuesta HTTP de 200 más de una o dos veces por minuto probablemente será innecesariamente frecuente.
• Del mismo modo, probablemente no sea necesario verificar el espacio libre en el disco duro para obtener una disponibilidad del 99.9% más de una vez cada 1-2 minutos.

Tenga cuidado de cómo estructura la granularidad de las dimensiones. La frecuencia de recopilar la carga de la CPU una vez por segundo puede proporcionar datos interesantes, pero tales mediciones frecuentes pueden ser muy caras de recopilar, almacenar y analizar.Si el objetivo de monitoreo requiere una granularidad alta y no requiere una velocidad de reacción alta, puede reducir estos costos configurando la recopilación de métricas en el servidor y luego configurando un sistema externo para recopilar y agregar estas métricas. Usted podría:

1. Mida la utilización de la CPU cada segundo.
2. Recorte los detalles al 5%.
3. Agregue métricas cada minuto.

Esta estrategia permitirá recopilar datos con gran granularidad sin experimentar altos costos de análisis y almacenamiento.

Tan simple como sea posible, pero no más fácil

La imposición de requisitos diferentes entre sí puede conducir a un sistema de monitoreo muy complejo. Por ejemplo, su sistema puede tener los siguientes elementos complicados:

• Alertas según diferentes valores de umbral para el retraso en el procesamiento de solicitudes, en diferentes percentiles, para todo tipo de indicadores diferentes.
• Escribir código adicional para detectar e identificar posibles causas.
• Cree paneles relacionados para cada una de las posibles causas de problemas.

Las fuentes de complicaciones potenciales nunca terminan. Como todos los sistemas de software, el monitoreo puede volverse tan complicado que se vuelve frágil y difícil de cambiar y mantener.

Por lo tanto, diseñe su sistema de monitoreo para simplificarlo tanto como sea posible. Al elegir qué rastrear, recuerde lo siguiente:

• Las reglas que con mayor frecuencia capturan incidentes reales deben ser tan simples, predecibles y confiables como sea posible.
• Las configuraciones para la recopilación de datos, la agregación y las alertas que rara vez se realizan (por ejemplo, menos de una vez por trimestre para algunos comandos SRE) deben eliminarse.
• , , - - , .

En Google, la recopilación básica y la agregación de indicadores, combinados con alertas y paneles, funcionan bien como un sistema relativamente autónomo (de hecho, el sistema de monitoreo de Google está dividido en varios subsistemas, pero generalmente las personas conocen todos los aspectos de estos subsistemas). Puede ser tentador combinar el monitoreo con otros métodos de verificación de sistemas complejos: perfiles detallados del sistema, depuración de procesos, seguimiento de detalles sobre excepciones o fallas, pruebas de carga, recopilación y análisis de registros o verificación de tráfico. Si bien la mayoría de estas cosas tienen características comunes con el monitoreo básico, mezclarlas juntas generará demasiados resultados en la creación de un sistema complejo y frágil. Al igual que con muchos otros aspectos del desarrollo de software, el soporte para varios sistemas es claro, simple,los puntos de integración acoplados libremente son una mejor estrategia (por ejemplo, usar una API web para recuperar datos de resumen en un formato que puede permanecer constante durante un largo período de tiempo).

Vinculación de principios juntos

Los principios discutidos en este capítulo pueden integrarse en una filosofía de monitoreo y alerta respaldada y respetada por los equipos de Google SRE. Es deseable adherirse a esta filosofía de monitoreo; es un buen punto de partida para crear o revisar una metodología de alerta y puede ayudar a formular las preguntas correctas al servicio operativo, independientemente del tamaño de su organización o la complejidad del servicio o sistema.

Al crear reglas de monitoreo y alerta haciendo las siguientes preguntas, puede evitar falsos positivos y alertas innecesarias:

• ¿Esta regla detecta un estado indetectable del sistema que es urgente, que requiere acción e inevitablemente afecta al usuario?
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

Estas preguntas reflejan la filosofía fundamental de las alertas y los sistemas de alerta:

• Cada vez que llega una alerta, debo responder con urgencia. Puedo reaccionar con urgencia varias veces al día antes de cansarme.
• Cada alerta debe ser relevante.
• Cada respuesta a una alerta debe requerir intervención humana. Si la alerta se puede procesar automáticamente, no debería aparecer.
• Las alertas deben ser sobre un nuevo problema o evento que no existía antes.

Este enfoque borra ciertas diferencias: si la notificación cumple las cuatro condiciones anteriores, no importa si la notificación se envía desde el sistema de monitoreo de White-box o Black-Box. Este enfoque también refuerza ciertas diferencias: es mejor gastar mucho más esfuerzo en identificar los síntomas que en las causas; Cuando se trata de razones, solo debe preocuparse por las razones inevitables.

Monitoreo a largo plazo

En los entornos productivos actuales, los sistemas de monitoreo siguen un sistema productivo en constante evolución con una arquitectura de software cambiante, características de carga y rendimiento objetivo. Las alertas que actualmente son difíciles de automatizar pueden convertirse en una ocurrencia frecuente, tal vez incluso digna de resolverse. En este punto, alguien debería encontrar y eliminar las causas profundas del problema; Si dicho permiso no es posible, la respuesta a la notificación requiere una automatización completa.

Es importante que las decisiones de monitoreo se tomen con objetivos a largo plazo en mente. Cada advertencia que se realiza hoy distrae a una persona de mejorar el sistema mañana, por lo que a menudo hay una disminución en la disponibilidad o productividad de un sistema productivo en el momento necesario para mejorar el sistema de monitoreo a largo plazo. Veamos dos ejemplos que ilustran este fenómeno.

Bigtable SRE: Historial de alertas

La infraestructura interna de Google generalmente se proporciona y mide en términos de nivel de servicio (SLO). Hace muchos años, el servicio de SLO de Bigtable se basaba en el rendimiento promedio de una transacción sintética que simulaba un cliente en funcionamiento. Debido a problemas en Bigtable y en niveles más bajos de la pila de almacenamiento de datos, el rendimiento promedio se debió a la cola "grande": el peor 5% de las solicitudes fueron a menudo mucho más lentas que el resto.

Se enviaron notificaciones por correo electrónico a medida que se acercaban al umbral de SLO, y se enviaron alertas al mensajero cuando se excedió el SLO. Ambos tipos de alertas se enviaron con la frecuencia suficiente, consumiendo cantidades inaceptables de tiempo de ingeniería: el equipo pasó una cantidad considerable de tiempo analizando alertas para encontrar algunas que fueran realmente relevantes. A menudo pasamos por alto un problema que realmente afectaba a los usuarios, porque solo algunas de las alertas eran específicamente para este problema. Muchas de las alertas no fueron urgentes debido a problemas comprensibles en la infraestructura y funcionaron de manera estándar, o no se procesaron en absoluto.

Para remediar la situación, el equipo adoptó un enfoque triple: mientras hacía grandes esfuerzos para mejorar el rendimiento de Bigtable, establecimos temporalmente el percentil 75 como nuestro objetivo de SLO para retrasar la respuesta a la solicitud. También desactivamos las alertas por correo electrónico, ya que había tantas que era imposible dedicar tiempo a diagnosticarlas.

Esta estrategia nos permitió tomar un descanso para comenzar a solucionar problemas a largo plazo en Bigtable y niveles inferiores de la pila de almacenamiento de datos, en lugar de solucionar constantemente problemas tácticos. Los ingenieros realmente podrían hacer el trabajo cuando no los atacaban constantemente las alertas. Finalmente, la demora temporal en el procesamiento de notificaciones nos permitió mejorar la calidad del servicio.

Gmail: respuestas predecibles y algorítmicas de personas

Al principio, Gmail se creó sobre un sistema de control de procesos Workqueue modificado, que se creó para procesar fragmentos de índice de búsqueda por lotes. Workqueue se adaptó a procesos de larga duración y posteriormente se aplicó a Gmail, pero algunos errores en el código opaco del planificador resultaron ser muy difíciles de curar.

En ese momento, el monitoreo de Gmail estaba estructurado de tal manera que se activaban alertas cuando se cancelaban tareas individuales usando Workqueue. Este enfoque no era ideal, porque incluso en ese momento Gmail realizó miles de tareas, cada una de las cuales se proporcionó a fracciones de un porcentaje de nuestros usuarios. Nos aseguramos de que los usuarios de Gmail tuvieran una buena interfaz de usuario, pero resolver tantas alertas era inalcanzable.

Para resolver este problema, Gmail SRE creó una herramienta que ayudó a depurar el programador lo mejor posible para minimizar el impacto en los usuarios. El equipo tuvo varias discusiones sobre si era necesario automatizar todo el ciclo desde la detección de un problema hasta su resolución hasta que se encontrara una solución a largo plazo, pero algunos de ellos estaban preocupados de que tal solución retrasaría la corrección real del problema.

Esta tensión era común en el equipo y a menudo reflejaba una falta de confianza en la autodisciplina: mientras que algunos miembros del equipo quieren dar tiempo para una solución correcta, otros temen que la solución final se olvide y la solución temporal dure para siempre. Este problema merece atención, ya que es demasiado fácil solucionar problemas temporalmente, en lugar de tener que solucionar la situación de manera continua. Los gerentes y el personal técnico desempeñan un papel clave en la implementación de soluciones a largo plazo, apoyando y priorizando soluciones potencialmente a largo plazo, incluso cuando el "dolor" inicial disminuye.

Las alertas periódicas periódicas y las respuestas algoritmizadas deberían ser una señal de alerta. La falta de voluntad de su equipo para automatizar tales alertas significa que el equipo carece de la confianza de que pueden confiar en los algoritmos. Este es un problema grave que debe abordarse.

A la larga

Un tema común vincula los ejemplos de Bigtable y Gmail: la competencia entre la disponibilidad a corto y largo plazo. A menudo, un gran esfuerzo puede ayudar a un sistema frágil a lograr una alta disponibilidad, pero este camino suele ser de corta duración, cargado de agotamiento del equipo y dependencia de un pequeño número de miembros de este equipo tan heroico.

Una disminución controlada de la disponibilidad a corto plazo suele ser una tarea dolorosa pero estratégicamente importante para la estabilidad a largo plazo del sistema. Es importante no considerar cada alerta de forma aislada, sino considerar si el nivel general de alertas conduce a un sistema saludable y accesible con un equipo viable y un pronóstico favorable. Analizamos las estadísticas de la frecuencia de las alertas (generalmente expresadas como incidentes de turno, cuando un incidente puede consistir en varios incidentes relacionados) en informes trimestrales con la administración, lo que permite a los tomadores de decisiones representar constantemente la carga en el sistema de alerta y el estado general del equipo.

Conclusión

El camino hacia un monitoreo y alertas saludables es simple y directo. Se enfoca en los síntomas del problema para el cual se emiten alertas, y monitorear la causa sirve como una ayuda para solucionar problemas. La supervisión de los síntomas es más fácil cuanto más alto esté en la pila que controla, aunque la supervisión de la carga y el rendimiento de la base de datos debe realizarse directamente en ella. Las notificaciones por correo electrónico tienen beneficios muy limitados y tienden a convertirse fácilmente en ruido; en su lugar, debe usar un panel que supervise todos los problemas actuales que se envían por correo electrónico. El tablero también se puede combinar con un registro de eventos para analizar correlaciones históricas.

A la larga, es necesario lograr una alternancia exitosa de alertas sobre síntomas y problemas reales inevitables, adaptar los objetivos para garantizar que el monitoreo respalde el diagnóstico rápido.

Gracias por leer la traducción hasta el final. Suscríbase a mi canal de telegramas sobre el monitoreo de @monitorim_it y el blog en el medio .