Medición de DevOps: supervisión y observabilidad

Una buena supervisión es un aspecto esencial de los equipos de alto rendimiento. En la investigación de DevOps Research and Assessment (DORA), se muestra que una solución integral de supervisión y observabilidad, junto con otras prácticas técnicas, contribuye de manera positiva a la entrega continua.

La investigación de DORA definió estos términos de la siguiente manera:

La supervisión es una herramienta o una solución técnica que permite a los equipos observar y comprender el estado de sus sistemas. La supervisión se basa en la recopilación de conjuntos predefinidos de métricas o registros.

La observabilidad es una herramienta o una solución técnica que permite a los equipos depurar de forma activa su sistema. La observabilidad se basa en la exploración de las propiedades y los patrones que no se definen con anticipación.

Para realizar un buen trabajo con la supervisión y la observabilidad, los equipos deben tener lo siguiente:

  • Informes sobre el estado general de los sistemas (¿Mis sistemas funcionan? ¿Tienen recursos suficientes disponibles?)
  • Informes sobre el estado del sistema según la experiencia de los clientes (¿Mis clientes saben si el sistema no está activo y tienen una mala experiencia?)
  • Supervisión de métricas clave de sistemas y empresas
  • Herramientas para ayudarte a comprender y depurar los sistemas en producción
  • Herramientas para encontrar información sobre elementos que no conocías antes (es decir, puedes identificar lo desconocido)
  • Acceso a herramientas y datos que ayudan a comprender y diagnosticar problemas de infraestructura en el entorno de producción, incluidas las interacciones entre servicios, y a hacer un seguimiento de ellos.

Cómo implementar la supervisión y la observabilidad

Las soluciones de supervisión y observabilidad están diseñadas para realizar las siguientes acciones:

  • Proporcionar los indicadores principales de una interrupción o una degradación del servicio
  • Detectar interrupciones, degradaciones de servicios, errores y actividad no autorizada
  • Ayudar a depurar interrupciones, degradaciones de servicios, errores y actividad no autorizada
  • Identificar tendencias a largo plazo para la planificación de capacidad y los propósitos comerciales
  • Exponer efectos secundarios inesperados de cambios o funcionalidad agregada

Al igual que con todas las funciones de DevOps, la instalación de una herramienta no es suficiente para lograr los objetivos, pero las herramientas pueden ayudar o dificultar el esfuerzo. Los sistemas de supervisión no deben estar limitados a una sola persona o a un equipo dentro de una organización. Capacitar a todos los desarrolladores para que dominen la supervisión ayuda a desarrollar una cultura de toma de decisiones basada en datos y mejora la capacidad de depuración general del sistema, lo que reduce las interrupciones.

Hay algunos puntos clave para lograr una implementación eficaz de la supervisión y la observabilidad. En primer lugar, la supervisión debería indicarte qué no funciona y ayudarte a comprender la razón, antes de que se produzca demasiado daño. La métrica clave en caso de una interrupción o degradación del servicio es el tiempo de restablecimiento (TTR). La capacidad de comprender con rapidez qué es lo que no funciona es lo que más contribuye al TTR y la ruta más rápida para restablecer el servicio (lo que no significa que los problemas subyacentes se solucionarán de inmediato).

Hay dos formas de alto nivel de observar un sistema: la supervisión en caja negra, en la que no se conoce el estado interno ni los mecanismos del sistema, y la supervisión en caja blanca, en la que sí se los conoce.

Para obtener más información, consulta “Monitoring Distributed Systems” (Supervisión de sistemas distribuidos) en el libro Site Reliability Engineering (Ingeniería de confiabilidad de sitios).

Supervisión en caja negra

En un sistema de supervisión en caja negra (o sintético), la entrada se envía al sistema que se encuentra en análisis de la misma manera que lo haría un cliente. Esto puede tomar la forma de llamadas HTTP a una API pública o llamadas RPC a un extremo expuesto, o puede llamar a una página web completa para que se procese como parte del proceso de supervisión.

La supervisión en caja negra es un método basado en muestras. El sistema de caja negra supervisa el mismo sistema que se encarga de las solicitudes de los usuarios. Un sistema de caja negra también puede proporcionar cobertura del área de superficie del sistema de destino. Esto podría implicar el sondeo de cada método externo de la API. También puedes considerar una combinación representativa de solicitudes para imitar mejor el comportamiento real del cliente. Por ejemplo, podrías realizar 100 operaciones de lecturas y solo 1 de escritura en una API determinada.

Puedes controlar este proceso con un sistema de programación a fin de asegurarte de que estas entradas se realicen a una velocidad suficiente para ganar confianza en el muestreo. El sistema también debe contener un motor de validación, que puede ser tan simple como verificar los códigos de respuesta o hacer coincidir los resultados con expresiones regulares, procesar un sitio dinámico en un navegador sin interfaz gráfica y recorrer el árbol del DOM en busca de elementos específicos. Después de tomar una decisión (aprobada o con errores) en un sondeo determinado, debes almacenar el resultado y los metadatos para generar informes y alertas. Examinar una instantánea de una falla y su contexto puede ser muy valioso para diagnosticar un problema.

Supervisión en caja blanca

La supervisión y la observabilidad dependen de las señales enviadas desde la carga de trabajo que se analiza al sistema de supervisión. En general, esto puede adoptar la forma de los tres componentes más comunes: métricas, registros y seguimientos. Algunos sistemas de supervisión también realizan un seguimiento de los eventos y los informan, lo que puede representar interacciones del usuario con un sistema completo o cambios de estado dentro del sistema.

Las métricas solo son mediciones tomadas dentro de un sistema, que representan el estado de ese sistema de manera medible. Casi siempre son numéricas y tienden a tomar la forma de contadores, distribuciones y medidores. Existen algunos casos en los que las métricas de string tienen sentido, pero, en general, se usan métricas numéricas debido a la necesidad de realizar cálculos matemáticos en estas para generar estadísticas y visualizaciones.

Los registros se pueden considerar como archivos que solo permiten agregar y que representan el estado de un solo subproceso de trabajo en un momento determinado. Estos registros pueden ser una sola string, como “El usuario presionó el botón X”, o una entrada de registro estructurada que incluye metadatos como la hora en que ocurrió el evento, qué servidor la procesó y otros elementos del entorno. En ocasiones, un sistema que no puede escribir registros estructurados producirá una string semiestructurada como [timestamp] [server] message [code], que se puede analizar después del hecho, según sea necesario. Las entradas de registro suelen escribirse mediante una biblioteca cliente como log4j, structlog, bunyan, log4net o Nlog. El procesamiento de registros puede ser un método para producir estadísticas que se pueden considerar confiables, ya que se pueden volver a procesar según los registros inmutables almacenados, incluso si el propio sistema de procesamiento de registros tiene errores. Además, los registros se pueden procesar en tiempo real para producir métricas basadas en registros.

Los seguimientos están compuestos por intervalos, que se usan para seguir un evento o una acción del usuario a través de un sistema distribuido. Un intervalo puede mostrar la ruta de una solicitud a través de un servidor, mientras que otro intervalo puede ejecutarse en paralelo, ambos con el mismo intervalo superior. Estas forman un seguimiento, que a menudo se visualiza en un gráfico de cascada similar a los que se usan en las herramientas de creación de perfiles. Esto permite a los desarrolladores comprender el tiempo que se toma en un sistema, muchos servidores, colas y saltos de red. Un framework común es OpenTelemetry, que se formó a partir de OpenCensus y OpenTracing.

El servidor que se mide puede informar métricas, registros y seguimientos al sistema de supervisión, o lo hace un agente adyacente que puede presenciar o inferir situaciones en el sistema.

Instrumentación

Para usar un sistema de supervisión, el sistema debe estar instrumentado. Es decir, el código debe agregarse a un sistema para exponer su estado interno. Por ejemplo, si un programa simple contiene un grupo de conexiones a otro servicio, recomendamos hacer un seguimiento del tamaño de ese grupo y la cantidad de conexiones sin usar en un momento determinado. Para ello, un desarrollador debe escribir código en la lógica del grupo de conexiones a fin de realizar un seguimiento de cuándo se forman o destruyen las conexiones, cuándo se transfieren y cuándo se muestran. Esto puede tomar la forma de entradas de registro o eventos. También, puedes aumentar o disminuir un medidor para el tamaño de la cola, o bien aumentar un contador cada vez que se crea una conexión o que un grupo se expande.

Correlación

Las métricas se pueden recopilar de la aplicación y de sus sistemas subyacentes, como la JVM, el SO invitado, el hipervisor, el SO de nodos y el hardware. Ten en cuenta que, a medida que avanzas en una pila, puedes comenzar a combinar las métricas que se comparten en las cargas de trabajo. Por ejemplo, si una sola máquina entrega varias aplicaciones, observar el uso del disco podría no corresponder de forma directa con el sistema en observación. Sin embargo, los problemas relacionados con las aplicaciones en un sistema compartido pueden ayudarte a identificar un factor contribuyente (como un disco lento). Desglosar una aplicación única hasta las métricas de sistema subyacentes y, luego, mostrar todas las aplicaciones afectadas de forma similar puede ser muy potente.

Medir un sistema distribuido significa tener observabilidad en muchos lugares y poder visualizarlos en conjunto. Esto puede referirse a un frontend y a su base de datos o a una aplicación para dispositivos móviles que se ejecuta en el dispositivo de un cliente, un balanceador de cargas en la nube y un conjunto de microservicios. Poder conectar los datos de todas estas fuentes en un solo lugar es un requisito fundamental en las herramientas de observabilidad modernas.

Procesamiento

Después de recopilar datos de varias fuentes para el sistema, generarás estadísticas y agregarás datos en varios dominios. Pueden ser cohortes de usuarios, regiones de la huella de procesamiento o ubicaciones geográficas de los clientes. Desarrollar estas estadísticas sobre la marcha en función de eventos sin procesar es muy beneficioso, pero puede ser costoso en términos de almacenamiento y la capacidad de procesamiento en tiempo real que se requiere.

Cuando elijas las herramientas y planifiques la instrumentación, debes tener en cuenta la cardinalidad y dimensionalidad. Estos dos aspectos de la recopilación de métricas pueden afectar en gran medida tu capacidad para escalar y observar un sistema.

La cardinalidad es la medida de valores distintos en un sistema. Por ejemplo, un campo como cpu-utilization suele necesitar un rango entre 0 y 100. Sin embargo, si haces un seguimiento del identificador único de un usuario, todos son distintos, por lo que si tienes 1 millón de usuarios, tienes una cardinalidad de 1 millón. Esto marca una gran diferencia.

La dimensionalidad es la capacidad de registrar más de un solo valor junto con una marca de tiempo, como podría suceder en una base de datos de serie temporal simple que respalda un sistema de supervisión. Tan solo registrar el valor de un contador, por ejemplo, las solicitudes enviadas, podría registrar solo el valor de la cantidad de solicitudes enviadas hasta este momento, como {time=x, value=y}. Sin embargo, al igual que con los registros estructurados, recomendamos registrar algunos datos del entorno, lo que da como resultado algo como lo siguiente: {time=x, value=y, server=foo, cluster=123, environment=prod, service=bar}. La combinación de cardinalidad y dimensionalidad altas puede aumentar considerablemente los requisitos de procesamiento y almacenamiento, hasta el punto en que la supervisión puede no funcionar como se esperaba. Los desarrolladores que escriben datos y metadatos generados de forma dinámica en sistemas de supervisión deben comprender esto.

Aprendizaje y mejoras

Parte de operar un sistema es aprender de las interrupciones y los errores. El proceso de escritura de retrospectivas o análisis retrospectivos con acciones correctivas está bien documentado. Un resultado de este proceso es el desarrollo de una supervisión mejorada. Es fundamental que una organización en constante evolución permita que cualquier persona dentro de ella actualice los sistemas de supervisión con rapidez y eficacia. La configuración de la supervisión es crucial, por lo que debe hacerse un seguimiento de los cambios mediante la revisión y la aprobación, al igual que con el desarrollo y la entrega de código. Conservar la configuración de supervisión en un sistema de control de versión es un buen primer paso para permitir un acceso amplio al sistema, a la vez que mantienes el control sobre esta parte fundamental del sistema. Desarrollar la automatización en la implementación de la configuración de supervisión a través de una canalización de automatización también puede mejorar tu capacidad para garantizar que estas opciones de configuración sean válidas y se apliquen de manera coherente. Después de tratar la configuración de supervisión como código, todas estas mejoras se pueden realizar mediante un proceso de automatización de implementaciones, el mismo sistema que usa el resto de tu equipo sería ideal.

Errores comunes de la implementación de la supervisión y la observabilidad

Cuando desarrollas un sistema para la supervisión y la observabilidad de la organización, debes tener en cuenta que, por lo general, no existe una solución simple lista para usar. Cualquier sistema de supervisión aceptable requerirá un conocimiento profundo de cada componente que quieras medir y una manipulación directa del código para instrumentar esos sistemas. Evita tener una sola persona para la supervisión o un equipo dedicado que sea el único responsable del sistema. Esto no solo te ayudará a prevenir un punto único de fallo, sino que también aumentará tu capacidad de comprender y mejorar el sistema como una organización completa. La supervisión y la observabilidad deben estar incorporadas en el conocimiento básico de todos los desarrolladores. Un inconveniente común es que el equipo de operaciones, NOC o algún otro equipo similar es el único que tiene permitido realizar cambios en un sistema de supervisión. Esto debe evitarse y reemplazarse por un sistema que siga los patrones de la CD.

Un antipatrón común de la escritura de alertas en los sistemas de supervisión es tratar de enumerar todas las condiciones de error posibles y escribir una alerta para cada una. A esto se lo denomina alertas basadas en causas, y debes evitarlo tanto como sea posible. En su lugar, debes enfocarte en las alertas basadas en síntomas, que solo te alertan cuando un síntoma orientado al usuario es visible o se espera que suceda pronto. Aún podrás observar los sistemas que no estén orientados a los usuarios, pero no se debería alertar directamente a los ingenieros de guardia si no hay síntomas orientados al usuario. Ten en cuenta que el término orientado al usuario también puede incluir usuarios internos de la organización.

Cuando generes alertas, debes considerar cómo se entregan. Las alertas deben tener varias vías a los ingenieros activos, incluidos, entre otros: la entrega de SMS, las apps para dispositivos móviles dedicadas, las llamadas telefónicas automatizadas o el correo electrónico. Un error común es enviar alertas por correo electrónico a todo un equipo a través de una lista de distribución de correo electrónico. Esto puede dar como resultado alertas ignoradas debido a la difusión de la responsabilidad. Otro error común es una relación señal/ruido deficiente. Si enviar muchas alertas no es práctico, o no se obtiene una mejora, el equipo perderá con facilidad las alertas que son significativas y, tal vez, muy importantes. Este problema se conoce como fatiga por alarmas. Se debe hacer un seguimiento muy cuidadoso a cualquier método para silenciar o suprimir un conjunto de alertas a fin de garantizar que no sea demasiado amplio ni se aplique con demasiada frecuencia.

Cuando se crean paneles de supervisión para visualizar métricas, un error común es dedicar mucho tiempo a la creación del “Panel perfecto”. Esto es similar al error de alertas basadas en causa anterior. En un equipo de alto funcionamiento, el sistema que se encuentra en observación cambia tan rápido que el tiempo dedicado a crear un panel estará obsoleto antes de que se complete. En su lugar, es importante centrarse en la capacidad de los miembros del equipo de crear con rapidez un panel o algún otro conjunto de visualizaciones que se adapten a sus necesidades.

No separar las métricas del producto o las orientadas a los ejecutivos, como la tasa de adquisición de usuarios y el seguimiento de ingresos, de los paneles de estado operativos o de servicio, también es un problema común, ya que ambos son muy importantes, pero distintos. Te recomendamos que los mantengas separados.

Cómo medir la supervisión y la observabilidad

Cuando implementas un sistema de supervisión y observabilidad en la organización, puedes hacer un seguimiento de algunas métricas internas para ver tu rendimiento. Estas son algunas de las métricas para las que recomendamos hacer un seguimiento mediante una encuesta mensual o un análisis automático de tus registros retrospectivos o de alertas.

  • Cambios realizados en la configuración de la supervisión. ¿Cuántas solicitudes de extracción o cambios por semana se realizan en el repositorio que contiene la configuración de supervisión? ¿Con qué frecuencia se envían estos cambios al sistema de supervisión? (¿Por día? ¿Por lotes? ¿De inmediato?)
  • Alertas fuera de horario. ¿Qué porcentaje de alertas se maneja por la noche? Si bien algunas empresas globales tienen un modelo de asistencia continua, lo hace que esto no sea un problema, puede ser una indicación de que no se prestó la atención suficiente a los indicadores principales de fallas. Las alertas nocturnas frecuentes pueden provocar fatiga de alertas y equipos agotados.
  • Balance de alertas de equipos. Si cuentas con equipos responsables de un servicio en ubicaciones diferentes, ¿las alertas se distribuyen de forma equitativa y las reciben todos los equipos? De no ser así, ¿por qué no?
  • Falsos positivos. ¿Cuántas alertas no generaron ninguna acción o se marcaron como “Funciona según lo previsto”? Las alertas que no son prácticas y que no te ayudaron a predecir fallas deben borrarse.
  • Falsos negativos. ¿Para cuántas fallas del sistema no se generaron alertas o se generaron más tarde de lo esperado? ¿Con qué frecuencia los informes retrospectivos incluyen agregar alertas nuevas (basadas en síntomas)?
  • Creación de alertas. ¿Cuántas alertas se crean por semana (total o agrupadas por gravedad, equipo, etcétera)?
  • Confirmación de alertas. ¿Qué porcentaje de alertas se confirman dentro del plazo acordado (como 5 minutos, 30 minutos)? En ocasiones, esto se combina con una métrica, como la falla de alerta, cuando se notifica a una persona secundaria del envío de una alerta.
  • Alarmas silenciadas y duración del silencio. ¿Cuántas alertas se encuentran silenciadas o suprimidas por semana? ¿Cuántas se agregan a este grupo? ¿Cuántas se quitan? Si el silenciamiento de alertas tiene un sistema de vencimiento, ¿cuántos silencios duran más tiempo del esperado? ¿Cuál es el período máximo y medio de silencio? (Uno divertido es “¿cuántos silencios son infinitos”?)
  • Alertas no prácticas. ¿Qué porcentaje de alertas se consideraron “no prácticas”? Es decir, el ingeniero al que se alertó no pudo tomar medidas de inmediato, ya sea por no comprender la implicación de la alerta o debido a un problema conocido. Las alertas no prácticas son una fuente conocida de trabajo duro.
  • Usabilidad: alertas, runbooks y paneles. ¿Cuántos gráficos hay en los paneles? ¿Cuántas líneas por gráfico? ¿Los equipos pueden comprender los gráficos? ¿Hay textos explicativos para ayudar a los ingenieros nuevos? ¿Las personas deben desplazarse y navegar mucho para encontrar la información que necesitan? ¿Los ingenieros pueden pasar de una alerta a una guía y a un panel de manera eficaz? ¿Las alertas tienen un nombre que permite guiar a los ingenieros en la dirección correcta? Podrían medirse a través de encuestas al equipo a lo largo del tiempo.
  • MTTD, MTTR, impacto. El tiempo de detección, el tiempo de resolución y el impacto son fundamentales. Considera medir el “área bajo la curva” del tiempo que la interrupción afectó a los clientes por la cantidad de clientes afectados. Esto se puede estimar o realizar con mayor precisión con herramientas.

Mediante el seguimiento de algunas o de todas estas métricas, comenzarás a comprender mejor qué tan bien funcionan los sistemas de supervisión y observabilidad en tu organización. Si desglosas estas mediciones por producto, por equipo operativo o por otros métodos, obtendrás estadísticas no solo sobre el estado de los productos, sino también de los procesos y las personas.

Próximos pasos