La Era de la Observabilidad

Introducción

Cuando el fundador de New Relic, Lew Cirne, creó el monitoreo del rendimiento de aplicaciones (APM), la innovación clave era la visibilidad profunda del código en las aplicaciones monolíticas ejecutadas en un centro de datos. Luego la puso a disposición de todos los ingenieros de desarrollo y operaciones como una solución SaaS. En la actualidad, a medida que las nuevas tecnologías y prácticas —nube, microservicios, contenedores, funciones sin servidor, DevOps, ingeniería de confiabilidad de sitios (SRE) y más— aumentan la velocidad y reducen la dificultad de obtener un software desde el código hasta la producción, también introducen más complejidad. 

Como la compañía pionera que perfeccionó el monitoreo del rendimiento de aplicaciones, creemos que los obstáculos a los que se enfrentan los equipos de software modernos exigen un nuevo enfoque. El antídoto para la complejidad y la manera en que los ingenieros pueden mantener los sistemas modernos disponibles para ofrecer excelentes experiencias a los clientes es la observabilidad.

La observabilidad está captando la atención del mundo del software porque su eficacia permite a los ingenieros ofrecer experiencias del cliente excelentes con software, a pesar de la complejidad de las operaciones digitales modernas.

No obstante, es necesario aclarar que la observabilidad no es un sinónimo sofisticado de monitoreo.

El monitoreo proporciona a los equipos de software la instrumentación que recopila datos sobre los sistemas y les permite responder de inmediato en caso de errores y problemas. En otras palabras, el monitoreo prepara los sistemas para obtener datos, con el objetivo de saber cuando algo no funciona e iniciar una respuesta inmediata. 

La observabilidad, por otro lado, es la práctica de instrumentar esos sistemas con herramientas para recopilar datos prácticos que indican no solo el cuándo de un error o un problema, sino —aún más importante— el por qué. Este último es lo que los equipos necesitan para poder responder con rapidez y solucionar emergencias en el software moderno.

La observabilidad ayuda a los equipos de software modernos a:

• Proporcionar software de alta calidad a escala
• Crear una cultura de innovación sostenible
• Optimizar las inversiones en la nube y en herramientas modernas
• Ver el rendimiento de sus negocios digitales en tiempo real

En New Relic, creemos que las métricas, los eventos, los registros y los rastreos (o M.E.L.T como los llamamos) son los tipos de datos esenciales de la observabilidad. Sin embargo, la observabilidad es mucho más que solo datos.

¿Cómo puede establecer la observabilidad de sus sistemas? ¿Y qué resultados puede esperar si tiene observabilidad? En nuestra opinión, hay cuatro dificultades clave que impulsan la necesidad de la observabilidad. Y para resolver esas dificultades, las organizaciones tienen que adoptar una práctica de observabilidad basada en tres componentes: instrumentación abierta, datos conectados y programabilidad. En este ebook, presentaremos esas tendencias, dificultades y componentes.

Capítulo 1: Las arquitecturas modernas exigen un nuevo enfoque de monitoreo

El ritmo de las innovaciones tecnológicas en los últimos cinco a diez años ha sido impresionante y ha tenido un impacto enorme en los equipos de software. Las tendencias clave son, entre otras:

• Presión para innovar con prontitud. Los equipos de software afrontan gran presión de sacar al mercado nuevas funciones y experiencias con más frecuencia y rapidez que la competencia. La nube ha ampliado el panorama competitivo al bajar la barrera de entrada, exigiendo que los equipos de software trabajen y se adapten más rápido que nunca, con frecuencia con menos recursos. Los equipos de más alto rendimiento despliegan software entre una vez por hora y una vez por día, mientras que los equipos elite hacen despliegues a pedido varias veces al día.

• Mayores expectativas de los clientes. Los clientes esperan más y toleran menos. Las experiencias de usuario lentas, propensas a errores y mal diseñadas no tienen ninguna posibilidad de éxito entre los clientes. Si los clientes no pueden hacer lo que desean hacer, no van a volver. Según el desarrollador de aplicaciones Dot Com Infoway, el 62% de las personas desinstala una aplicación si la experiencia móvil se bloquea, se congela o contiene errores. Los equipos elite que ofrecen el mejor rendimiento de software restablecen el servicio en menos de una hora cuando surge un incidente o un defecto que afecta a los usuarios, en comparación con los equipos de bajo rendimiento que tardan entre una semana y un mes en restablecer el servicio.1

• Más opciones de tecnología. En la actualidad, las organizaciones diseñan arquitecturas de microservicios y sistemas distribuidos en muchos proveedores de la nube y de plataformas de computación. Estos servicios son más fáciles de adoptar y usar que nunca, y cada vez funcionan mucho mejor juntos. Es posible elegir varios sistemas y servicios para el soporte de todo lo que se necesita en un stack de tecnología moderno, sin necesidad del trabajo administrativo que requiere configurar y mantener el stack.

• El ascenso de DevOps y la automatización. Las compañías se están organizando alrededor de equipos autónomos responsables del diseño, entrega y operación de extremo a extremo de los servicios que poseen en producción. En ocasiones, aprovechan las plataformas y herramientas comunes que los equipos internos de la plataforma ofrecen como servicios. La automatización reduce el trabajo repetitivo y de poco valor, y mejora la confiabilidad. En una arquitectura nativa de la nube, todo lo del stack se controla con software y toda el área de superficie es programable. Y como toda esa automatización es software, puede fallar. Los equipos necesitan monitorear su CI/CD y las demás herramientas de automatización exactamente como lo harían con las aplicaciones que dan servicio directo a los clientes. La recopilación de datos acerca de cada componente dentro de un sistema es la esencia de la observabilidad.

Estas tendencias están creando cuatro dificultades importantes que impulsan la necesidad de la observabilidad en los sistemas modernos:

1. Mayor complejidad. Si bien las tecnologías nativas de la nube han transformado la manera de diseñar, entregar y operar las aplicaciones, también han generado más complejidad para los equipos encargados de su mantenimiento. A medida que las aplicaciones monolíticas se refactorizan en microservicios, en los que la vida útil de un contenedor se puede medir en minutos o menos, los equipos de software tienen de pronto servicios que cambian constantemente. Como cada aplicación individual se deconstruye potencialmente en decenas de microservicios, los equipos de operaciones se enfrentan a una complejidad de escala: tienen ahora la responsabilidad de servicios que conocen poco y que, sin embargo, deben mantener.
2. Más riesgo. Los despliegues frecuentes y la infraestructura dinámica implican la introducción de más riesgo, con más frecuencia. Este aumento del riesgo hace que la detección y la reversión inmediatas sean mucho más importantes que cuando los despliegues eran poco frecuentes. Y, a medida que las empresas adoptan prácticas ágiles y entregas continuas para ofrecer software con más rapidez, están agregando otra área de superficie de software (a través de las herramientas de entrega y los pipelines) que se debe monitorear y mantener.
3. Carencia de habilidades. La explosión de arquitecturas de microservicios ha introducido nuevos problemas, ya que los equipos de software deben reconsiderar cómo diseñan, desarrollan y despliegan las aplicaciones. Todos los integrantes del equipo también tienen que entender y poder solucionar problemas en partes de una aplicación que antes desconocían. Por ejemplo, hoy en día, un experto en bases de datos también debe saber de redes y de API. La desventaja es que la cantidad de tecnologías nuevas y diversas que los equipos tienen que aprender a usar es exorbitante para que una sola persona las domine. Los equipos necesitan maneras de entender mejor esas tecnologías en el contexto del trabajo que realizan.
4. Demasiadas herramientas. Los entornos híbridos, los millares de contenedores en producción y la gran cantidad de despliegues por día generan volúmenes enormes de datos de telemetría operativa. El trabajo con varias herramientas de monitoreo y el cambio de contexto necesario para buscar y correlacionar los datos más importantes, o para buscar y resolver problemas, toma mucho tiempo que los equipos no tienen cuando sus clientes se ven afectados por un problema de producción.

En vista de estas tendencias y dificultades, y del ritmo general del cambio tecnológico, los equipos necesitan una sola solución que reduzca la complejidad y el riesgo, y lo haga con gastos indirectos bajos. La solución debe subsanar la carencia de habilidades y ser fácil de usar, entender y navegar a la hora de obtener el contexto esencial. Asimismo, debe permitir que cualquier equipo dentro de una organización vea todos sus datos de observabilidad en un solo lugar y obtenga el contexto que necesita para extraer rápidamente el significado y tomar las medidas apropiadas.

_{1. “Accelerate: State of DevOps 2019,” DORA, septiembre de 2019}

Capítulo 2: La era de la observabilidad

Aunque el monitoreo en general existe por lo menos desde el inicio de la era de Unix (la primera versión salió en 1971), el término monitoreo del rendimiento de aplicaciones (APM) no se generalizó sino hasta principios de la década del 2000. Desde entonces, el monitoreo ha evolucionado para proporcionar métricas detalladas, rastreos y alertas sobre el rendimiento y la experiencia del usuario en todo el stack de tecnología, incluida la nube.

Ahora que los entornos modernos se han vuelto cada vez más complejos, la observabilidad es sumamente importante para el éxito futuro de los equipos de software y sus organizaciones. Les da a los equipos la capacidad de tener una vista conectada de todos sus datos de rendimiento en un solo lugar y en tiempo real, para detectar los problemas con más rapidez, entender la causa del problema y, en última instancia, ofrecer experiencias excelentes a sus clientes.

La observabilidad no es un concepto nuevo. Tiene su origen en la ingeniería y la teoría del control, y fue introducido por el ingeniero húngaro-americano Rudolf E. Kálmán para los sistemas dinámicos lineales. Una definición comúnmente aceptada de la observabilidad, como se aplica en la ingeniería y la teoría del control, es una medida de lo bien que se pueden deducir los estados internos de un sistema a partir del conocimiento de sus salidas externas.

En el ciclo de vida del software, la observabilidad abarca la recopilación, la visualización y el análisis de las métricas, los eventos, los registros y los rastreos para obtener un conocimiento holístico de la operación de un sistema. La observabilidad permite saber por qué algo está mal, en comparación con el monitoreo, que solo dice que algo está mal.

Yuri Shkuro, autor e ingeniero de software de Uber Technologies, explica la diferencia de esta manera: el monitoreo mide lo que uno decide con anterioridad que es importante, mientras que la observabilidad es la capacidad de hacer preguntas que uno desconoce de antemano acerca del sistema.

Como dijimos anteriormente, en New Relic, creemos que las métricas, los eventos, los registros y los rastreos son los tipos de datos esenciales de la observabilidad, y que los eventos son un tipo de telemetría crítico (y con frecuencia pasado por alto) que debe formar parte de cualquier solución de observabilidad. Más adelante, hablaremos sobre esto. En definitiva, cuando instrumentamos todo y usamos esos datos de telemetría para crear un conocimiento práctico fundamental de las relaciones y las dependencias dentro de nuestro sistema, además de su rendimiento y estado, estamos practicando la observabilidad. No obstante, en New Relic, nuestro enfoque es aún más matizado, ya que creemos firmemente en tres componentes básicos de la observabilidad.

Capítulo 3: Los tres componentes básicos de la observabilidad

Hasta ahora, hemos definido la observabilidad como la práctica de instrumentar los sistemas para recopilar datos prácticos que proporcionen no solo el cuándo de un error o problema, sino también el por qué. La capacidad de responder al por qué es la manera en que los equipos resuelven realmente la causa fundamental de los problemas y garantizan la confiabilidad del sistema. Para lograr la observabilidad de los sistemas, consideramos que se necesitan tres elementos básicos:

1. Instrumentación abierta. Nuestra definición de instrumentación abierta es la recopilación de datos de telemetría de códigos abiertos o específicos del proveedor de una aplicación, servicio, host de infraestructura, contenedor, servicio en la nube, función sin servidor, aplicación móvil o cualquier otra entidad que emita datos. Proporciona visibilidad a toda el área de superficie de las aplicaciones y la infraestructura críticas del negocio.
2. Entidades conectadas. Es necesario analizar todos esos datos de telemetría para que las entidades que los producen puedan ser identificadas y conectadas, y los metadatos tienen que ser incorporados para crear una correlación entre las entidades y sus datos. Esas dos acciones crean contexto y significado a partir de grandes volúmenes de datos. Con ese contexto, la selección se puede proporcionar como modelos visuales del sistema o la tecnología sin necesidad de configuración adicional. La última ventaja de las entidades conectadas es que la inteligencia se puede aplicar para obtener aún más significado. La inteligencia aplicada es la aplicación del aprendizaje automático y la ciencia de datos para buscar patrones o anomalías en los datos a fin de que las personas puedan tomar decisiones y actuar.
3. Programabilidad. Cada negocio es único y no hay selección automática suficiente que pueda satisfacer las distintas necesidades de un negocio o ser adecuada para todos los usos. Los negocios necesitan una manera de crear su propio contexto y su propia selección además de todos los datos de telemetría, combinando datos comerciales críticos y dimensiones. New Relic es único en el espacio de la observabilidad porque reconoce la importancia de esa necesidad, y da a los clientes la capacidad de diseñar aplicaciones además de todos los datos de telemetría. Por ejemplo: tener la capacidad de mostrar claramente el costo de los errores y las fallas en un proceso comercial, asociar el importe total real a esas fallas y proporcionar una ruta para analizar los datos a fondo y encontrar el motivo.

Si desea más información acerca de cómo la observabilidad está evolucionando para brindar soporte al software moderno, consulte The 10 Principles of Observability: Guideposts on the Path to Success with Modern Software.

Capítulo 4: Instrumentación abierta

Cuando New Relic comenzó a operar en 2008, la mejor manera de recopilar datos de telemetría para la observabilidad era a través de agentes. Los desarrolladores de software y los equipos de operaciones desplegaban agentes dentro de sus aplicaciones y hosts, y esos agentes recopilaban datos de métricas, eventos, rastreos y registros, los empaquetaban de maneras patentadas y los enviaban para su agregación y presentación.

Aunque esa sigue siendo hoy una manera eficaz de recopilar datos de telemetría, el sector ha cambiado. En la actualidad, hay muchas otras fuentes de telemetría. Muchos frameworks y sistemas abiertos para el desarrollo de software tienen métricas, eventos, registros y rastreos integrados que se emiten en formatos comunes. Para la observabilidad, es preciso recopilar datos de códigos abiertos y patentados, y combinarlos en un solo lugar. Asimismo, es necesario aplicar la instrumentación automáticamente donde tenga sentido hacerlo y agregar instrumentación donde la visibilidad sea más necesaria.

M.E.L.T.: un análisis rápido

En la mayoría de los casos, las métricas son el punto de partida de la observabilidad. Los gastos generales para recopilarlas son bajos, su almacenamiento es económico, se pueden dimensionar para hacer análisis rápidos y son una manera excelente de medir el estado en general. Por eso, han surgido muchas herramientas para la recopilación de métricas, como Prometheus, Telegraf, StatsD, DropWizard y Micrometer. Muchas compañías han diseñado incluso sus propios formatos patentados para la recopilación de métricas, además de los almacenamientos de datos abiertos y compatibles con series de tiempo, como Elasticsearch. Una solución de observabilidad necesita poder consumir las métricas provenientes de cualquiera de estas fuentes que equipos muy diferentes hayan adoptado en las operaciones digitales modernas.

Los rastreos son valiosos para mostrar la latencia de extremo a extremo de cada llamada en una arquitectura distribuida. Estas llamadas proporcionan información específica de un sinnúmero de recorridos de los clientes a través de un sistema. Los rastreos permiten a los ingenieros entender esos recorridos, encontrar embotellamientos e identificar errores, para poderlos corregir y optimizar. Al igual que con las métricas, han surgido muchas herramientas (Jaeger, Zipkin y AWS X-ray, por mencionar unas cuantas) basadas en soluciones personalizadas creadas por organizaciones sofisticadas.

El contexto de seguimiento W3C pronto se convertirá en la norma para propagar el "contexto de rastreo" en todos los límites de los procesos. El contexto de rastreo proporciona una manera estándar de dar seguimiento al flujo de datos a través de un sistema, por medio del seguimiento de las llamadas originales —intervalos principales y secundarios— en todos los sistemas distribuidos complejos. Cuando los desarrolladores utilizan una norma para su contexto de rastreo, los intervalos de varios sistemas distintos se pueden volver a unir de manera confiable para la presentación y la búsqueda en una plataforma de observabilidad. El contexto de rastreo también contiene etiquetas importantes y otros metadatos que aumentan la utilidad de la búsqueda y la correlación.

Parte de la Cloud Native Computing Foundation (CNCF), el proyecto de OpenTelemetry, fusiona la recopilación de métricas y rastreos en un formato abierto. A medida que más organizaciones adopten OpenTelemetry, esperamos ver más instrumentación integrada estándar y común que reduzca la necesidad de ejecutar agentes para la instrumentación de bytecode en tiempo de ejecución. Dada la amplitud de herramientas, como Kubernetes e Istio en la CNCF, y su rápida adopción, es probable que OpenTelemetry se vuelva omnipresente en el software moderno como una fuente de telemetría.

Los registros son importantes cuando un ingeniero se encuentra en modo de depuración "profunda", tratando de entender un problema. Los registros proporcionan datos de alta fidelidad y contexto detallado relacionados con un evento, para que los ingenieros puedan recrear lo que sucedió milisegundo por milisegundo. Al igual que con las métricas y los rastreos, han surgido herramientas para reducir el trabajo y los intentos de recopilar, filtrar y exportar registros. Algunas de las soluciones comunes son Fluentd, Fluent Bit, Logstash y AWS CloudWatch, además de muchos otros estándares emergentes.

Todos estos proyectos para métricas, registros y rastreos están construyendo un futuro en el que la instrumentación se volverá más fácil gracias a este enfoque tipo "todo incluido".

Los eventos son un tipo de telemetría crítico (y con frecuencia pasado por alto) que debe formar parte de cualquier solución de observabilidad. Lamentablemente, aunque los eventos y los registros tienen similitudes, a menudo se comete el error de tratarlos como si fueran iguales. Los eventos son entradas discretas y detalladas de puntos de análisis significativos, pero contienen un nivel más alto de abstracción que el nivel de detalle proporcionado por los registros. Los registros son entradas completas y discretas de todo lo que ocurrió dentro de un sistema; los eventos son entradas de situaciones significativas seleccionadas ocurridas, con metadatos adjuntos a la entrada para aclarar el contexto. Por ejemplo, cuando New Relic recopila los eventos de una transacción — instancias individuales de la ejecución de un método o un bloque de código en un proceso— se agregan datos automáticamente para mostrar el número de llamadas hechas de la base de datos y la duración de esas llamadas.

Aunque la mayoría de las herramientas de código abierto que proporcionan instrumentación esencial también vienen con un almacenamiento de datos discreto para recopilar, almacenar y poner los datos a disposición de los análisis, esto disminuye la utilidad de la observabilidad, porque obliga a los ingenieros y a los equipos a conocer y entender varias herramientas. Sin un almacenamiento de datos unificado, cuando surgen problemas —o peor, emergencias—, los ingenieros tienen que cambiar de contexto a través de varias herramientas para encontrar el origen del problema. Una solución de observabilidad abierta tiene la interoperabilidad de todos estos datos, sin importar el origen, y crea automáticamente las entidades y conexiones entre ellos para proporcionar un contexto crítico.

Capítulo 5: Datos conectados y seleccionados

Colocar todos los datos de telemetría de casi cualquier lugar en un solo sitio es un buen punto de partida, pero no es suficiente. Los datos deben estar conectados de manera tal que permitan conocer las relaciones entre las entidades, y tienen que estar correlacionados con los metadatos para poder entender su relación con el negocio. Este tipo de conexiones le da contexto y significado a los datos. El contexto, por ejemplo, logra vistas seleccionadas que muestran la información más importante acerca de los datos e imitan su entorno específico. Además, si todos los datos y las conexiones de telemetría se almacenan en un lugar, es posible aplicar inteligencia a esos conjuntos de datos muy grandes, y hacer surgir patrones, anomalías y correlaciones que no son fáciles de detectar para las personas que observan los paneles.

Básicamente, se necesita una manera de ver cómo todas las entidades del sistema están relacionadas entre sí en un momento determinado. No es posible sencillamente mantener un mapa mental del sistema cuando este cambia cada día, hora o minuto. Tampoco es factible depender de la configuración para administrar esas relaciones. A medida que todos los equipos agregan servicios nuevos, refactorizan los antiguos y activan y desactivan instancias de aplicaciones efímeras, se vuelve imposible mantener un mapa mental. No obstante, las entidades, sus conexiones y sus relaciones son una parte del contexto esencial para la observabilidad.

El contexto es imposible sin metadatos y dimensiones. Según el sistema, el negocio o la aplicación, la gama de datos valiosos es potencialmente enorme. Por ejemplo, en el caso de una aplicación de comercio electrónico, el contexto útil incluye, entre otros, lo siguiente:

• Detalles del equipo que posee la aplicación, el runbook y el repositorio de código
• Etiquetas del Docker o el proveedor de la nube donde está desplegado
• Su función y tipo de servicio
• Las regiones donde ha sido desplegado
• Sus dependencias ascendentes y descendentes
• Sus eventos de despliegue o cambio
• Su estado de alerta
• Todo dato de rastreo o registro asociado con las transacciones que realiza
• Otros datos del negocio (por ejemplo, valor del carrito)

La selección de visualizaciones de datos es una herramienta potente para mostrar entidades conectadas, bien conocidas y bien definidas. Ya sabemos cómo representar mejor un proceso de aplicación de Java que se ejecuta en un contenedor, o una función AWS Lambda que llama a DynamoDB después de una llamada de SQS, o un clúster de Kubernetes que ejecuta un despliegue dinámico; ya resolvimos esos problemas. Y para un ingeniero de SRE o DevOps ocupado, imitar esos entornos en un conjunto de paneles es una pérdida de tiempo valioso. Una plataforma de observabilidad debe incorporar las mejores prácticas de los líderes del sector y mostrar las señales más importantes del estado, además de proporcionar experiencias interactivas que permitan a los ingenieros solucionar los problemas rápidamente. En pocas palabras, crear manualmente visualizaciones y paneles para tecnologías específicas y omnipresentes es un trabajo arduo.

La selección a través del contexto también ayuda con el problema de la carencia de habilidades en una operación digital compleja. Proporciona una manera en que todos los integrantes de la organización puedan visualizar los flujos y las dependencias en sus sistemas complejos y ver todo lo que es aplicable a la totalidad del entorno. Puesto que esta selección imita bien diversos sistemas, hace más accesible que las personas los entiendan, aunque no conozcan esa tecnología o ese código en particular.

La observabilidad no sirve de nada si no se pueden tomar medidas inmediatas cuando el sistema no está funcionando correctamente. A través del aprendizaje automático y los análisis predictivos, la inteligencia aplicada toma los datos de la observabilidad y los hace significativos y prácticos. A veces, las operaciones de TI la llaman inteligencia artificial, o Gartner, una firma de análisis del sector, la conoce como AIOps; de cualquier manera, la inteligencia aplicada encuentra la señal dentro del ruido para poder tomar las medidas necesarias. 

La inteligencia aplicada proporciona una orientación clara, incluso cuando los conjuntos de datos son grandes y complejos. Las máquinas son muy buenas para identificar patrones, tendencias y errores en los datos a una escala que las personas simplemente no pueden reproducir. Las capacidades adecuadas de inteligencia aplicada detectan problemas lo antes posible a partir de los datos de telemetría, y correlacionan y asignan prioridades a los eventos para reducir el ruido y la fatiga de las alertas. La inteligencia aplicada puede enriquecer automáticamente las alertas de incidentes con contexto, orientación y sugerencias aplicables, lo que incluye recomendaciones que ayudan a determinar rápidamente la causa fundamental de un problema y la manera resolverlo.

Este es un ejemplo de la inteligencia aplicada en acción: un equipo recibe una alerta acerca de la infracción del límite de tiempo de respuesta de una aplicación. La inteligencia ya examinó automáticamente el rendimiento, los errores de latencia y las señales de la transacción relacionados con la aplicación en las seis horas anteriores a la alerta. En este caso, la inteligencia detecta latencia en el almacenamiento de datos del que depende la aplicación, y muestra una conexión directa entre el problema de la base de datos y el tiempo de respuesta lento de la aplicación. Esto tiene dos ventajas:

1. Dado que la inteligencia aplicada ya hizo análisis importantes para la resolución de problemas y redujo el tiempo medio de detección (MTTD), el equipo puede resolver más rápidamente el problema subyacente y, con ello, reducir el tiempo medio de resolución (MTTR).
2. Como la inteligencia aplicada se vuelve más útil cuando se entrena con más datos, y puede eliminar el ruido de las alarmas secundarias o falsas, el equipo reducirá en gran medida la fatiga general causada por las alarmas y se podrá dedicar a entregar mejor software, con más rapidez.

Cuando se pueden ver las dependencias y los detalles de todos los tipos de telemetría en tiempo real, es posible conocer con más rapidez y facilidad los problemas del sistema y resolverlos para encontrar el "por qué" detrás de los datos. Cuando estos imitan eficaz y automáticamente el entorno técnico, las visualizaciones seleccionadas facilitan a todos la búsqueda de las causas fundamentales. Y al aplicar inteligencia a los grandes conjuntos de datos, se muestran las conexiones en los datos, para que las personas se dediquen a lo que hacen mejor: tomar decisiones matizadas sobre lo que hay que hacer en una situación difícil.

Capítulo 6: Programabilidad

La conexión de los datos de observabilidad con los resultados comerciales es un paso crítico que las organizaciones deben dar para convertirse en negocios digitales maduros. Es necesario comenzar con las medidas de negocio indispensables para el éxito, e identificar luego los indicadores clave de rendimiento (KPI) que contribuyen directamente al éxito de esas métricas. Las métricas como la latencia, los errores o la carga de páginas son elecciones obvias para entender el rendimiento de la aplicación, pero son menos útiles para entender el impacto que tiene una aplicación en la experiencia del cliente y los KPI comerciales.

Por eso, es importante conectar la observabilidad de nuevo con el negocio y proporcionar a los equipos la información que necesitan para tomar decisiones basadas en los datos. La pregunta es ¿cómo? 

Para la mayoría de las soluciones, la respuesta ha sido ver los KPI en los paneles. Los paneles son una herramienta excelente para mostrar de inmediato vistas adecuadas de los datos. Son herramientas flexibles y avanzadas, fundamentales para cualquier solución de observabilidad. Pero dado el entorno tecnológico específico y los KPI únicos del negocio, es más importante que nunca ir más allá de los paneles y adoptar el diseño de aplicaciones para obtener datos acerca del negocio digital y combinarlos con los datos de telemetría. Al conectar los datos de negocio además de la plataforma de observabilidad, una aplicación ofrece una experiencia seleccionada interactiva que, con frecuencia, tiene flujos de trabajo integrados y permite la combinación de conjuntos de datos externos en tiempo real. Los paneles no pueden hacer eso, pero las aplicaciones sí.

Para conectar los datos comerciales y de telemetría en las aplicaciones, es necesario que la solución de observabilidad sea una plataforma que se pueda ampliar. Además, debe ser programable.

Cuando se cuenta con una plataforma de observabilidad en la cual se pueden diseñar aplicaciones adaptadas a necesidades particulares, aumenta la capacidad de hacer lo que antes no era posible con una herramienta de observabilidad, por ejemplo:

• Priorizar las inversiones en software y medir la eficacia de esas inversiones en tiempo real.
• Conocer, con contexto detallado, las relaciones entre la tecnología, el negocio y los clientes.
• Tomar decisiones basadas en los datos que tengan el mayor impacto directo en los KPI específicos.
• Compartir conocimientos a través de visualizaciones interactivas diseñadas como modelo de un negocio particular, no solo del entorno tecnológico.

Por último, una plataforma de observabilidad programable proporciona a los equipos la capacidad de diseñar aplicaciones que tomen en cuenta su sistema único de registro sin necesidad de desplegar otra herramienta. Esto tiene varias ventajas: reduce el cambio de contexto entre herramientas durante una emergencia; disminuye el tiempo y el trabajo necesarios para aprovisionar, operar, mantener y monitorear otro sistema; y baja el costo de comprar, diseñar y aprender a usar una herramienta más.

Capítulo 7: Resumen

A medida que evoluciona la innovación de software, el mundo seguirá avanzando más rápido y se volverá más complejo. Así como hace solo unos años no habría sido posible prever las últimas tecnologías y tendencias, no sabemos cuáles serán los próximos avances importantes. Lo que sí sabemos es que esta innovación y esta complejidad continuas seguirán aumentando las expectativas de que sus equipos avancen con más rapidez y adopten otras tecnologías sin cometer ningún error a velocidades vertiginosas. También necesitará automatizar más y estar al tanto de las expectativas del cliente que hayan establecido otras compañías —incluidos sus competidores— de ofrecer las experiencias del cliente de vanguardia.

Dados estos desafíos, usted necesita una sola plataforma de observabilidad que reduzca la complejidad y el riesgo, y que lo haga con gastos generales reducidos. Necesita una plataforma que ayude a subsanar la carencia de habilidades, que sea fácil de usar, entender y navegar para obtener el contexto esencial, de modo que su uso no sea un obstáculo para ningún equipo dentro de una organización. Necesita una plataforma que permita a sus equipos ver todos los datos de telemetría y de negocio en un solo lugar, obtener el contexto que requieren para extraer el significado rápidamente y tomar las medidas apropiadas, y trabajar con los datos de maneras provechosas para el negocio.

Una plataforma de observabilidad debe:

• Recopilar y combinar en un solo lugar los datos de telemetría de códigos abiertos y patentados. Esta instrumentación abierta reduce la proliferación de herramientas y el cambio de contexto cuando surgen problemas y emergencias, porque proporciona interoperabilidad de todos los datos, sin importar la fuente.
• Formar conexiones y relaciones entre las entidades y aplicar esas conexiones para crear contexto y significado y poder entender los datos. El contexto se debe presentar en vistas seleccionadas que muestren la información más importante.
• Dar la capacidad de diseñar además aplicaciones personalizadas. A diferencia de los paneles, las aplicaciones proporcionan experiencias seleccionadas e interactivas, tienen con frecuencia flujos de trabajo integrados y permiten la combinación de conjuntos de datos externos en tiempo real. La programabilidad redefine las posibilidades de la observabilidad.

Con una plataforma de observabilidad abierta, conectada y programable, las ventajas para su negocio son enormes: innovación más rápida, despliegues más ágiles, menos trabajo, costos reducidos y mejor entendimiento de cómo priorizar el tiempo finito y la atención. Todo esto se traduce en un conocimiento común más profundo de los datos, los sistemas y los clientes. Asimismo, mejorará la cultura y hará crecer su negocio a medida que obtenga vistas en tiempo real del rendimiento de sus sistemas digitales y de cómo sus clientes interactúan con el software, lo cual le permitirá dedicarse a lo más importante: los resultados comerciales que debe generar todos los días.