Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Etapa 2: Implementar la observabilidad
En esta etapa, comienza el proceso para que sus equipos avancen gradualmente hasta llegar a la Estrella Polar.
Elige tu plataforma de observabilidad
El primer paso es identificar las herramientas adecuadas para ingerir, visualizar y analizar las señales y enviar alertas. Al seleccionar una herramienta, tenga en cuenta su conjunto de funciones, el modelo de licencia, el precio, los requisitos de habilidad y el mantenimiento.
Conjunto de funciones
Estas son algunas de las preguntas a tener en cuenta:
-
Configurabilidad y personalización. ¿Qué funciones ofrece la herramienta para simplificar la experiencia de investigación y ayudar a reducir el MTTR? ¿La herramienta proporciona correlación de alarmas, cálculos métricos, flexibilidad para gestionar la telemetría faltante o detectar anomalías?
-
Granularidad. ¿Cuál es la granularidad admitida en la ingesta y visualización de señales de telemetría?
-
Personas. ¿La herramienta es compatible con las experiencias que quieres ofrecer a tus desarrolladores, ingenieros de plataformas y otras personas? ¿Funciona tanto para profesionales técnicos como empresariales?
-
Widgets. ¿Qué tipos de widgets admiten los paneles? ¿La herramienta permite la creación de widgets personalizados?
-
Soluciones prediseñadas. ¿Qué tipos de soluciones de observabilidad prediseñadas ofrece la herramienta para reducir el tiempo de amortización?
-
Automatización e IA generativa. ¿Qué funciones ofrece la herramienta que pueden ayudar a automatizar o reducir el trabajo para usted y su equipo? Por ejemplo, la detección automática de anomalías, el análisis predictivo y otras capacidades generativas de IA pueden ayudar a reducir el stress de las suposiciones y las incógnitas (es decir, cosas que no conoces ni entiendes completamente). ¿La herramienta admite el uso de AI/ML modelos generativos para mejorar el análisis de los datos a escala? ¿Le ofrece la opción de automatizar e implementar? AIOps
-
Seguridad.¿Qué tipos de integraciones de autenticación y autorización admite la herramienta? ¿Las experiencias de usuario e inicio de sesión satisfacen las necesidades de su organización?
-
OpenTelemetry soporte. ¿La herramienta y el agente lo apoyan OpenTelemetry? La mayoría de las plataformas de observabilidad admiten la ingesta de señales OpenTelemetry compatibles, pero no todos los agentes ofrecen opciones de configuración para reenviar estas señales a una plataforma de observabilidad.
-
Integraciones. ¿Qué integraciones ofrece la herramienta? Considera si necesitas enviar alertas a Slack, contactar a los miembros del equipo o automatizar la resolución.
-
Escalabilidad. ¿Qué nivel de escalabilidad y rendimiento tiene la herramienta? La solución de observabilidad debe ampliarse a medida que aumentan las demandas y el uso, de modo que pueda proporcionar diagnósticos incluso si la aplicación no está disponible.
-
Support. ¿Qué modelo de soporte se ofrece? Su herramienta de observabilidad debe estar disponible incluso si la aplicación falla para que pueda cumplir sus objetivos de MTTR y disponibilidad de las aplicaciones o sus acuerdos de nivel de servicio (). SLAs Las soluciones de código abierto pueden ofrecer un soporte formal limitado.
Modelo de licenciamiento e implementación
Tenga en cuenta el modelo de licencia (de código abierto o comercial) y el modelo de implementación (autohospedado o basado en la nube) de la solución. Las opciones de código abierto suelen tener costes iniciales más bajos, pero es posible que requieran más tiempo de implementación, instalación y configuración, mantenimiento y formación del equipo antes de que aporten valor. Si está considerando opciones de código abierto, es posible que necesite un equipo dedicado de expertos en observabilidad. El software comercial suele ofrecer una rentabilidad más rápida con un coste inicial más elevado, y la necesidad de contar con un equipo dedicado a la observación va evolucionando con el paso del tiempo a medida que aumentan la adopción, la complejidad y la madurez. Las soluciones autohospedadas requieren más tiempo de implementación, configuración, mantenimiento y sobrecarga operativa en comparación con las soluciones basadas en la nube.
Dimensiones de precios
¿Cómo afectará el modelo de precios de la herramienta al coste total de propiedad (TCO) a medida que la aplicación gane nuevos usuarios, una arquitectura más amplia o nuevas funciones y aplicaciones? Por ejemplo, algunos modelos de licencias típicos son perpetuos o se basan en las suscripciones, el número de usuarios nominales, el consumo o el volumen. Tenga en cuenta cómo se ampliará el uso de su aplicación y de la herramienta de observabilidad y cómo el modelo de licencia puede afectar al coste de la herramienta.
Habilidades de equipo
En función del conjunto de habilidades actuales y de la madurez de tu equipo, tendrás que determinar qué nivel de perfeccionamiento será necesario. Considera qué tipo de apoyo proporciona el proveedor para capacitar a tu equipo. Considera también si tu estructura organizativa admite la configuración y la administración de la herramienta que elijas. Por ejemplo, si así lo desea OpenTelemetry, debería considerar la posibilidad de crear un equipo independiente que se especialice en la observabilidad.
Operaciones y mantenimiento
Evalúe las siguientes preguntas:
-
¿Qué opciones de implementación ofrece el agente de observabilidad o el recopilador? ¿Cumplen esas opciones con los requisitos de su arquitectura? Por ejemplo, si utiliza un despliegue en contenedores para la herramienta de observabilidad, ¿admite un daemonset o un sidecar? ¿Qué medidas o herramientas adicionales tendría que adoptar o utilizar el equipo de operaciones para garantizar la alineación con la seguridad y todos los demás procesos?
-
¿Cuál es el esfuerzo necesario para mantener la solución? ¿Qué tan simple o automatizado es el proceso de actualización del agente o del recopilador? Las interfaces de observabilidad totalmente administradas y basadas en la nube suelen tener una sobrecarga operativa menor en comparación con las aplicaciones alojadas y de implementación automática, aunque la administración del agente o del recopilador sigue siendo la misma. Tenga en cuenta la estructura de su equipo y tenga en cuenta el coste humano que supone mantener la opción que elija.
Instrumente su solicitud
Las respuestas a las preguntas de la sección anterior le proporcionan la información que necesita para instrumentar su aplicación, es decir, para añadir código que capture las señales de telemetría a la aplicación y para medir, observar y validar los comportamientos. Puede utilizar SDKs, por ejemplo, el OpenTelemetry SDK como lenguaje de la aplicación para instrumentarla automáticamente. Es posible que aún tengas que añadir un código de instrumentación manual para cubrir cualquier laguna y garantizar la end-to-end visibilidad. Sea intencionado con la telemetría que añada y asegúrese de poder volver a conectarla a una o más de SLIs las SLOs que estableció en la etapa anterior.
Recopile la telemetría
Implemente componentes de observabilidad
Cuando la telemetría fluya y se incorpore a una plataforma de observabilidad, cree cuadros de mando, alertas, manuales y manuales.
-
Paneles: cree paneles que contengan información relevante, incluida una representación visual de las tendencias actuales e históricas asociadas a los resultados priorizados. Haga que estos paneles estén disponibles para las partes interesadas que definió en la etapa 1. Para obtener más información, consulte Creación de paneles para una visibilidad operativa en el sitio web
de Amazon Builders' Library. -
Alertas: defina alertas para notificar a su equipo cuando los resultados estén en riesgo o se estén infringiendo. Considera la posibilidad de añadir alertas para problemas de seguridad y rendimiento. Optimice las alertas para reducir la fatiga y los costos de las alertas adoptando lo siguiente:
-
Utilice la detección de anomalías para evitar establecer umbrales estrictos, que requieren ajustes frecuentes, y para reducir la aparición de incógnitas desconocidas.
-
Utilice combinaciones de alertas inteligentes que analicen varias métricas relacionadas de forma conjunta en lugar de configurar alertas individuales para cada métrica. Por ejemplo, en lugar de configurar alertas independientes para la CPU, la memoria y el tiempo de respuesta, cree una alerta significativa que se active solo cuando estas métricas indiquen, en conjunto, un problema real. Este enfoque reduce considerablemente el ruido de las alertas y ayuda a sus equipos a centrarse en los problemas reales que afectan al servicio, en lugar de tener que responder a picos aislados de las métricas.
-
Genere alertas solo cuando la experiencia del usuario o los resultados estén en peligro. Por ejemplo, evita recibir alertas sobre un pico de CPU provocado por una actualización automática cuando tu aplicación no tenga usuarios activos.
-
-
Guías: un manual de estrategias proporciona un modelo mental y un contexto a la persona que responde a un incidente o alerta, y le ayuda a identificar la causa raíz más rápidamente. Considere la posibilidad de crear manuales de estrategias para aplicaciones complejas y muy acopladas y para aplicaciones que carezcan de instrumentación pero que tengan un impacto directo en los resultados que identificó y priorizó en la etapa 1.
-
Guías de ejecución: utilice las guías de ejecución para definir los pasos necesarios para resolver un incidente o una alerta.
Valide el sistema de observabilidad
A lo largo del ciclo de vida del desarrollo de software (SDLC), compruebe que los cuadros de mando proporcionen los comportamientos y las actualizaciones esperados durante las pruebas del sistema. Implemente la ingeniería del caos y valide los pasos que están documentados en los manuales y manuales para asegurarse de que son precisos y cumplen su propósito. También debes validar la propiedad de las alertas y las rutas de escalamiento.
