Abecedario de observabilidad II: la vida de un proyecto de la J a la R.

Este post es la segunda parte de una serie dedicada al desarrollo de proyectos de observabilidad. En el post anterior hablamos de la vida de un proyecto de la A a la I y en el próximo, cerraremos el abecedario explicando de la S a la Z.

En la primera parte definimos lo que es la observabilidad, cómo podemos plantear nuestro camino particular y, en general, por dónde empezar una vez que tenemos claro lo que queremos. En este segundo post entramos verdaderamente en harina. ¿Por qué letra íbamos?

J de “Jugando con walkie-talkies”

Posiblemente, para muchas de las personas que estáis leyendo este post, esta sección sea trivial y conocida. No obstante, me gustaría dedicarle un poco de espacio a las definiciones ya que es lo que nos va a ayudar a que estemos en la misma página conforme vayamos avanzando en el escenario.

Comencemos por la parte más fundamental sobre la que construimos todo este asunto: los datos. Y es que sí, al final todo se resume a extraer, procesar y explotar datos contextualizados que nos permitan generar información. Esta última viene representada de diferentes formas y nos da varios puntos de vista sobre un mismo hecho acontecido en nuestra aplicación. Cada pieza de información que emite la aplicación es considerada una señal.

Actualmente existen diferentes tipos de señales, las más aceptadas son:

• Logs. El primer tipo de señal creado. Su objetivo es exportar lo que ocurre dentro de una aplicación de una manera sencilla. Los logs son líneas de texto, idealmente estructurados o semiestructurados que nos permiten entender el comportamiento y estado de una aplicación en lenguaje natural.
• Métricas. Son habitualmente valores numéricos que representan estados discretos o información cuantitativa sobre un aspecto de la aplicación. Las métricas se generan de forma discreta en intervalos regulares, por lo que al ser leídas con la misma frecuencia nos permite generar series temporales que modelan el comportamiento de esa variable.
• Trazas. Representan un proceso dentro de la aplicación. Encapsulan todas las llamadas y transacciones que se realizan entre las diferentes entidades, componentes o incluso servicios externos que componen el proceso. Nos permiten entender el comportamiento entre los diferentes componentes involucrados en el flujo de ejecución.

En general, la mayoría de las aplicaciones y frameworks dedicados a la observabilidad atacan estos tres tipos de señales, por lo que su estandarización, recogida y explotación debe ser el mínimo exigible de nuestra nueva estrategia. Toda aplicación debería generar este tipo de señales.

Sin embargo, los nuevos tiempos traen consigo “nuevas” señales que pueden resultar muy útiles. Estas son:

• Perfiles. Los perfiles son una representación fiel del comportamiento y el rendimiento de un proceso a nivel de runtime y sistema operativo. Su registro de forma continuada –lo que se conoce como “Continuous Profiling”– permite obtener una foto precisa del rendimiento de una aplicación.
• Eventos. Son logs especiales que incluyen metadatos relativos al negocio. Permiten mapear procesos y eventos de la aplicación con procesos y flujos del negocio. Es una forma de generar conocimiento abstraído de la capa puramente tecnológica.
• Baggage (a falta de una traducción fidedigna). Se trata de datos en forma clave-valor que se pueden propagar anexados a diferentes tipos de señal. Normalmente se utilizan para asociar datos que solo se conocen al inicio del flujo y que es útil mantener hasta el final como metadatos. Un ejemplo sería el identificador de un usuario.

Debemos tener muy claro qué información queremos generar en nuestras aplicaciones, no solo por los usos que podamos darle, sino porque cada señal tiene un formato y procesamiento diferente. No es lo mismo procesar texto semi estructurado como un log, que una serie temporal. Tanto la forma de recoger las señales como la forma de procesarlas y almacenarlas es completamente distinta.

La clave para entender esta fase del proyecto reside en analizar cuál es el porcentaje de cobertura del ámbito definido que realmente observamos e identificar qué capas no estamos incluyendo hasta el momento.

When an organization has observability, it has visibility into everything — an arduous but admirable pursuit, considering the maze that is the modern technology stack. This includes network (owned and unowned), infrastructure (on-premises, cloud, and hybrid), homegrown and third-party applications, and digital customer experience.
Splunk – State of Observability 2024

K de “Kamikazes sin saberlo”

Un título bastante deprimente, lo sé. Pero es cierto que muchas veces nos encontramos con proyectos o iniciativas que comienzan con mucho ánimo y buenas intenciones para terminar de bruces con la fría realidad de una factura en el correo electrónico a final de mes y la persona de financiero abriéndote un chat de buena mañana.

No suelen ser conversaciones agradables, lo prometo.

Por ello, la gestión del coste debe ser algo a tener en cuenta desde el mismo diseño de la estrategia (¿recordáis cómo aún no hemos avanzando en el modelo?). En ese sentido, debemos decidir inicialmente dónde vamos a almacenar la información. Normalmente, esa decisión está estrechamente relacionada con otra: cuál va a ser mi herramienta (o conjunto de herramientas) de observabilidad. Lo que habitualmente es referido como backend de observabilidad.

Al igual que cuando hablamos de desplegar una nueva solución, tanto en cloud como on-premise, los datos de observabilidad deben ser explotados por una o varias herramientas que permitan crear visualizaciones avanzadas, alertar, generar reglas, aplicar IA, filtrar logs, realizar análisis de trazas, crear mapas de componentes, etc. Realmente muchas de las capacidades que tendremos en las siguientes fases de nuestro modelo dependerán de la herramienta que elijamos.

En este punto, debemos tener ambición pero manteniendo los pies en la tierra. De nada nos sirve elegir una suite de herramientas barata u open source gestionada por nosotros mismos si no tenemos el conocimiento para usarlas o, en el peor de los casos, no nos permitiera implementar más allá de casos básicos. En el otro extremo, sería aún peor contratar un servicio SaaS de grado empresarial y empezar a mandar información sin filtro. Nos encontraríamos con facturas gigantescas sin aprovechar apenas las ventajas que nos ofrecen.

Habiendo asustado suficiente, y por dejar claro el paisaje que tenemos, actualmente existen dos tipos de aproximaciones:

• Herramientas especializadas. Tanto open source como propietarias. Con soporte enterprise o no. Existen multitud de herramientas especializadas en el procesamiento de algunos tipos de señales. Grafana, Prometheus, Jaeger o Sentry son algunos ejemplos ampliamente reconocidos.
  
  La ventaja de estas herramientas es que están dedicadas a resolver un problema concreto, suelen ser sencillas de utilizar y están ampliamente aceptadas por la comunidad. Esto asegura productos muy probados, con un gran ritmo de versionado, muchísima documentación y amplias integraciones.
  
  Las desventajas radican en que suelen ser gestionadas internamente y tienen un grado de mantenimiento. Algunas de ellas, como Prometheus, tampoco disponen de un servicio de soporte empresarial, habría que acudir a otros productos comerciales basados en él.
• Herramientas generalistas / servicios integrales. Suelen presentarse tanto en versiones “Enterprise” de gestión interna como en servicios SaaS/PaaS en Cloud. Aúnan la capacidad de ingestar todo tipo de señales y suelen ofrecer potentes módulos con visualizaciones avanzadas y capacidades de caja. Permiten acelerar el Time To Market pero suelen ir asociados a costes bastante elevados. El modelo de pricing varía: por host, por volumetría o una mezcla de ambos. Habitualmente, también suelen tener paquetes de funcionalidades extra más avanzadas que tienen un sobrecoste sobre la licencia base.
  
  Adicionalmente, estos servicios tienen asociados SLA’s y soporte 24x7 (en función del tier contratado). Ejemplos de este tipo de servicios o herramientas son Datadog, Grafana Cloud/Enterprise, NewRelic, Dynatrace, etc.

No entraré en un debate conmigo mismo sobre una herramienta u otra (este abecedario es bastante largo ya sin mis divagaciones), pero me gustaría indicar que para elegir un modelo u otro se deben tener en cuenta multitud de componentes:

• Precio de la solución.
• Necesidades de retención.
• Necesidades de alta disponibilidad.
• Necesidades de capacidades enterprise (SLA’s, soporte, etc).
• Conocimiento interno.
• Capacidad de gestión de la infraestructura en caso de ser desplegada internamente.
• Requisitos de seguridad.
• Modelo de acceso y operación.
• Funcionalidades que ofrecen.
• Facilidad de adaptación de la solución (¿cómo integrar aplicaciones ya desarrolladas?)

¿Tenemos nuestra solución elegida? ¿Sí? Bien, prosigamos.

L de “Ligando las partes”

En este punto tenemos claro qué tipo de información queremos generar en las aplicaciones, dónde la vamos a almacenar, cómo las vamos a explotar y cuál es el modelo de operación que vamos a implantar. El siguiente paso es, ¿cómo unimos los puntos? ¿Cómo nos aseguramos que la información se almacena de la manera adecuada? ¿Cómo trasladamos todo este modelo teórico que hemos ideado a una realidad en la que participan muchos equipos y aplicaciones?

La respuesta está en las dos primeras líneas de trabajo que mencionamos inicialmente: la arquitectura de sistemas y la arquitectura de software.

Nuestro objetivo es poder llegar a un estado de observabilidad fundacional, es decir, la base de todo. Es lógico, por tanto, pensar que debemos también incluir la observabilidad como un componente básico del diseño de nuestros sistemas y el diseño de nuestro software.

Desde un punto de vista organizacional, no es mantenible y escalable disponer de equipos de aplicación que resuelvan el mismo problema una y otra vez de forma completamente distinta. Es un hecho que existen necesidades comunes a todos los proyectos de software y, por lo tanto, una organización debe tender hacia una solución común. Ojo, común no significa centralizada; eso ya depende de cada casa.

Una oficina de arquitectura software potente se encargará de tomar estas decisiones y proveer a los equipos de los mecanismos y artefactos software necesarios para ello. La observabilidad no será un caso distinto para cada proyecto, todas las aplicaciones deben implementarla. Y si esa implementación es común, resolvemos muchos problemas presentes y futuros, aceleramos el desarrollo y podemos asegurar la auditabilidad, calidad y seguridad en el proceso.

La instrumentación de los arquetipos, imágenes base de contenedor y procesos de CI/CD que utilizan los proyectos software es la mejor manera de asegurar que cualquier aplicación creada dentro de la organización cumplirá “de caja” con todas las directrices y estándares necesarios para implementar observabilidad. Con ello, proveemos a los equipos con “observability by design”. No se tienen que preocupar de investigar y probar nuevas configuraciones y librerías; únicamente deben usar los artefactos ya preparados a tal efecto. Adicionalmente, asegurar que todo funciona correctamente, que se siguen los estándares y que la aplicación es observable debería ser parte de los requisitos no funcionales de cualquier tarea de desarrollo.

Un ejemplo muy claro que se beneficia enormemente de esto es la generación de logs y trazas, cuya estandarización permite mejorar el rendimiento de las consultas, unificar políticas en diferentes entornos o controlar el volumen, entre otros. Al configurar las librerías de logging y tracing en el arquetipo, es sencillo vincularlas, añadiendo el ID de la traza como atributo del log. Adicionalmente, si todos los componentes de una aplicación (en el caso de aplicaciones basadas en microservicios) utilizan la misma configuración, es perfectamente posible compartir ese ID de traza. Gracias a esto último, obtenemos el Santo Grial de los beneficios de la observabilidad: trazabilidad end-to-end.

Pero, ¿y la arquitectura de sistemas que mencionaba? ¿Dónde la aplicamos?

En primer lugar, debemos tener en cuenta que independientemente de la herramienta que hayamos decidido utilizar como backend, al final va a necesitar una serie de configuraciones a nivel de red, seguridad, accesos, almacenamiento, etc. Es importante recordarlo, aunque esta historia no va de eso.

Si en la parte software nos preguntamos “¿cómo podemos hacer para que la observabilidad sea parte integral del ciclo de vida de la aplicación?”, en el caso de la administración de sistemas es análoga: “¿cómo podemos asegurar que nuestros sistemas estén observados durante todo su ciclo de vida?”.

Evidentemente, cada sistema se observa de una manera distinta y, para colmo, es altamente dependiente de la/s herramienta/s que elijamos como backend de observabilidad. Unas herramientas usan un tipo de agentes, otras otro, las formas de autenticación son distintas y, en ocasiones, hasta los protocolos y formatos difieren. Así pues, la gran pregunta: ¿cómo?

Este es un gran momento para hacer eso que como administrador/a de sistemas nunca has querido/podido hacer: inventario. Es necesario establecer con certeza qué tipo de sistemas se utilizan: sistemas basados en Kubernetes, Linux, Windows, servidores especializados como appliances, bases de datos, etc. Cada componente de nuestra infraestructura a nivel físico, virtual, orquestación y tooling (¿es que nadie piensa en Kafka?) debe tener definido su método de observación. No daré pistas al respecto, no quiero inmiscuirme en vuestra libertad creativa, pero debemos tener preparada una respuesta estándar para cada casuística desde el momento en el que se plantea como una necesidad a introducir en el ecosistema. Por desgracia, y como he mencionado anteriormente, la observabilidad de los sistemas dista mucho de poder ser unificada en una misma aproximación; especialmente cuando tratamos de dispositivos mucho más especializados y de bajo nivel.

PD: no es por dar ideas malintencionadas, pero si no se ha hecho ya, la aplicación de observabilidad es una magnífica palanca para impulsar la persistencia como código y las automatizaciones. Mejoramos la operación, el mantenimiento y aumentamos la auditabilidad, eficiencia y seguridad. Imagine the possibilities.

Por lo tanto, siguiendo el modelo de observabilidad desde el diseño, tenemos:

• La seguridad de que toda la infraestructura existente y todos los componentes se encuentran observados. Nacen, se desarrollan y mueren observados.
• Las aplicaciones son observadas en un entorno observado. Desde la configuración de las librerías, hasta la instrumentación de las configuraciones en el proceso de CI/CD proveen los mecanismos para asegurar que no se puede dar de alta una aplicación sin observabilidad.

Y todo esto, sin que el equipo de desarrollo tenga que pelearse con ello. “By default” lo llaman.

M de “Miles de orígenes de datos”

Y todos distintos: aplicaciones, bases de datos, almacenes de secretos, clusters de Kubernetes, servicios cloud, servidores Linux, Windows, etc. Ya disponemos de casi todos los elementos necesarios para poder definir e implementar nuestra estrategia. Solo nos falta agrupar y estandarizar la forma en la que recogemos los datos y los almacenamos.

Y aquí hay un proyecto del que tenemos que hablar: OpenTelemetry (OTel).

No es mi objetivo convencer de absolutamente nada y no debemos caer en la falacia que esta es la única forma de hacer las cosas. Existen muchas alternativas a OTel. Sin embargo, este análisis carecería de relevancia si no comentara la importancia de este proyecto.

OpenTelemetry es un proyecto incubado de la CNCF cuyo objetivo consiste en la estandarización tanto de las propias definiciones como de las implementaciones de la gestión de telemetría. Es decir, provee de estándares, formatos, protocolos, SDKs y librerías con el ánimo de que todas las aplicaciones hablen el mismo idioma. Esto permite, entre otras cosas, una gestión transparente de todo el proceso de recogida, transformación y almacenamiento de las distintas señales.

En los últimos años, se ha convertido en un estándar de facto para la gestión de la telemetría y prácticamente cualquier tipo de backend empresarial implementa OTel como una opción para el usuario. Es un proyecto open source con una amplia comunidad y muchísimas aportaciones de empresas como Google, Grafana, Datadog, Microsoft, etc. Por último, es un esfuerzo completamente agnóstico, cuyo objetivo principal consiste en su implementación en cualquier entorno.

Para entender por qué es tan relevante, analicemos sus componentes:

• OTLP – OpenTelemetry Protocol. Se trata de un protocolo de capa 7 compatible con HTTP y gRPC. Permite enviar en un único formato serializado cualquier tipo de señal (de momento logs, trazas y métricas) con la seguridad de que este proceso es ligero, eficiente y sencillo de des-serializar en el destino. Pretende establecer un lenguaje unificado para la comunicación entre todos los agentes involucrados en la recopilación de datos y la ingesta.
• OpenTelemetry Collector. Una pieza clave en la propuesta de OTel. Se trata de una pieza de software que podemos desplegar en nuestro entorno y será el encargado de recibir la información (tanto en modo push como en modo pull) y enviarla al destino correspondiente. Dicho así no parece nada del otro mundo pero profundicemos un poco más en su estructura interna:
  • Receivers: son módulos que definen cómo vamos a recibir los datos. Podemos definir orígenes de métricas de Prometheus, abrir listeners para recibir trazas en formato Zipkin o Jaeger o recibir logs enviados por una aplicación. Cómo no podría ser de otra manera, también permite abrir conexiones OTLP de forma que una aplicación podría enviar toda la información a un solo endpoint.
  • Processors: módulos que permiten modificar la estructura de la información. Podemos hacer relabelling, modificar datos, añadir nuevas etiquetas, filtrar en función del contenido, optimizar el consumo de memoria aplicando procesos batch, etc.
  • Exporters: permiten enviar a multitud de destinos en sus formatos nativos o en OTLP.
  • Pipelines: los anteriores componentes definen de forma declarativa cuáles son los los posibles orígenes de datos, transformaciones y destinos. Los pipelines se encargan de definir cuál es el flujo concreto que va a seguir la información tanto para logs, trazas y métricas. Podremos definir que las métricas de Prometheus de un origen en concreto debe pasar por un relabelling específico antes de ir al destino o que los logs deben pasar en modo batch para optimizar el uso de memoria.
• OpenTelemetry SDKs. De nada serviría todo lo anterior si no pudiéramos implementarlo en nuestras aplicaciones. OTel dispone de un conjunto de SDKs para los principales lenguajes de programación que permiten tanto la auto instrumentación como la instrumentación manual. ¿Qué significa eso? Que podríamos adoptar OTel en las aplicaciones sin necesidad de tocar el código fuente en muchos casos.

Con todo ello, la gestión centralizada de todo el proceso “ETL” (llamémoslo así por comodidad, no me juzguéis tan rápido) de la telemetría da una vuelta de tuerca y se vuelve algo mucho más genérico, escalable y adaptable a las necesidades.

¿Cómo hace OTel para recibir trazas, logs y métricas en 3 formatos distintos, modificarlos y exportarlos tanto juntos como separados? Bueno, ahí está su magia, no seré yo quien la desvele, ni es el objetivo de este análisis.

N de “No sé por dónde vamos, me he perdido”

Natural. Hemos tenido que hacer una desviación interesante para poder establecer toda la base de una estrategia de observabilidad sólida. Podéis considerarlo un “detour”, que es lo mismo, pero suena más moderno y menos improvisado.

Hagamos un breve resumen de lo que hemos ido comentando:

• Una forma única de implementar la observabilidad en todas nuestras aplicaciones. Nos aseguramos de que todas ellas exportan tanto métricas, logs, trazas y alguna más en función de nuestras necesidades.
• Una forma única de implementar la observabilidad en los sistemas. Nuestras automatizaciones son las encargadas de asegurarnos que no nos dejamos “puntos negros”.
• Una forma unificada y estándar de recoger, procesar y almacenar la información. Sean cuales sean las consideraciones que debamos aplicar. Todos hablamos el mismo idioma.
• Uno o varios backend que nos permitirán explotar toda esa información y operar sobre ella.
• Un modelo de acceso y operación que defina quién debe acceder a qué datos.

Hagamos un fast-forward en todo esto e imaginemos que todo estos puntos ya están implementados y funcionando. Tenemos un backend lleno de información sin explotar o con visualizaciones muy básicas pero, ¿y qué? La fundación ya está hecha.

O de “Observabilidad completa” (para una vez que lo tengo fácil…)

Ya tenemos la ciudadanía de observabilidad fundacional. El resumen es que, al final, debemos tener algo como lo siguiente:

• La compañía dispone de un estándar a la hora de tratar con información de telemetría.
• La compañía dispone de una plataforma habilitadora de observabilidad o, en su defecto, de los automatismos necesarios para desplegar todos los componentes.
• Todas las capas tecnológicas son observadas.
• La observabilidad es parte de la arquitectura de software y está incorporada en los arquetipos e imágenes base utilizadas en los despliegues.
• Existe un subconjunto muy reducido de herramientas para la explotación, idealmente una consola unificada gobernada siguiendo un modelo de RBAC.
• El ciclo de vida de la información está definido e implementado. Los períodos de retención para cada tipo de señal son independientes y ajustados a las necesidades de la compañía y las restricciones regulatorias que debe cumplir.
• En este nivel los equipos directamente beneficiados son:
  • Operaciones e infraestructura
  • Desarrollo - QA
  • Seguridad
  • Auditoría

Llega el siguiente nivel en el modelo de madurez: la observabilidad completa. En este punto, el objetivo es mejorar toda la explotación implementando visualizaciones avanzadas, alertado reactivo y proactivo y procesos industrializados. ¿Qué ocurre cuándo aparece una nueva aplicación? ¿Cuál es su proceso de onboarding? ¿Tendrá alertas y dashboard genéricos de caja?

El objetivo consiste en hacer uso de las referencias cruzadas de las que disponemos. Podemos establecer cauces para el análisis de Causa Raíz (RCA). Los equipos de QA y desarrollo utilizan activamente la información para detectar cuellos de botella, problemas de rendimiento y bugs. Los equipos de seguridad pueden generar informes de seguridad avanzados e incluso hacer un análisis de cumplimiento contra diferentes regulaciones o estándares. A nivel de auditoría, al tener visibilidad sobre todas las aplicaciones e infraestructura, es mucho más sencillo poder crear reportes de evidencias.

Este es un proceso menos complejo que el anterior, pero aún así no debemos pensar que es trivial. El éxito de esta fase reside en nuestra capacidad de poder “productivizar” la información y que estos comiencen a ser de verdadera utilidad para la compañía y los distintos equipos. El desarrollo de las visualizaciones, la formación de los equipos, el refinado de las alertas y la creación de procedimientos a nivel organizacional son tareas lentas que en muchos casos requieren de personal con un alto nivel de conocimiento técnico o muy especializado.

P de “Parece que ya está todo hecho”

La gran mayoría de las veces, las empresas no “maduran” en cuestión de meses o un año, como podría ser el tiempo que tardemos en completar los estadios anteriores. La madurez conlleva un tiempo de aprendizaje y, sobre todo, de introducir la observabilidad como un elemento cultural inherente a cualquier desarrollo e iniciativa IT. Lamentablemente, no es un proceso que podamos acelerar metiendo más profesionales o perfiles más senior.

Los dos siguientes estadios del modelo de madurez son mucho más “vagos”, en el sentido en que no deberíamos caer en el error de considerarlos como estados lineales, sino estados complementarios. Una empresa puede disponer de observabilidad en el negocio (Business Observability) sin necesidad de implementar inteligencia artificial y viceversa. No obstante, sí que podemos considerar que alcanzar un estado de observabilidad sistematizada es una grandísima palanca para la adopción de observabilidad en el negocio.

Una de las características más fundamentales de estos dos últimos estados del modelo es la “amplitud” de los actores que aparecen como beneficiarios directos de estas plataformas. Dejamos los niveles técnicamente más profundos bien asentados para ir subiendo niveles de abstracción que deriven en una toma de decisiones ágil, eficaz e informada.

Por lo tanto, sí, en cierto modo está todo hecho y muchos proyectos suelen terminar en esta fase. Pero, en realidad, todavía quedan muchas posibilidades por explorar y ahí es dónde marcamos la diferencia.

Q de “Queremos seguir mejorando”

Bueno, creo que ha llegado el momento de alimentar un poco al tiránico SEO: ¡Inteligencia Artificial! ¡Machine Learning! Y no meto IA Generativa (¡uy!) porque aún está muy verde en estos temas. Perdonadme el espacio publicitario.

Chistes aparte, la Inteligencia Artificial es un antes y un después en la forma que hemos entendido las posibilidades de la observabilidad y la monitorización. De hecho, en numerosas ocasiones, encuentro definiciones de observabilidad que son poco menos que una fórmula del estilo: Observabilidad = Monitorización + IA. Huelga decir que, sin menospreciar las posibilidades que ofrece la IA en estos temas, no estoy de acuerdo con tales afirmaciones. La IA (entendida como un amplio campo de técnicas y no solo como IA Generativa) es una magnífica herramienta para potenciar todo lo que estamos comentando y llevarlo al siguiente nivel pero, en mi humilde opinión, no debería ser un requisito.

Entremos por lo tanto a analizar la observabilidad sistematizada en profundidad. En nuestro viaje, hemos hablado de estandarizar la emisión, recogida y almacenamiento de la información para poder ofrecer una gestión unificada de la misma. A continuación, hemos incidido en el desarrollo de visualizaciones, alertas proactivas y reactivas, accesos, creación de mapas de componentes y la inclusión de todo esto como parte del flujo de desarrollo. Dado que el ser humano ya se beneficia, dejemos que la máquina lo haga también.

Una compañía en un estado de observabilidad sistematizada es aquella que utiliza toda la información y herramientas de las que dispone para poder diseñar respuestas automáticas a eventos, no solo correctivas sino también mitigadoras. Un sistema así es capaz de aplicar además estrategias basadas en el uso de Machine Learning para predecir comportamientos anómalos, riesgos o acelerar dramáticamente el análisis de causa raíz.

Esta estrategia no es nueva, en el mundo de seguridad hace tiempo que los SOAR están ampliamente implementados en las organizaciones y muchos servicios en la nube ya incluyen comportamientos inteligentes en sus firewall.

Pongamos algunos ejemplos:

• Sistemas que son capaces de extrapolar comportamientos estacionales y escalar y desescalar sus servicios para ajustar la demanda.
• Sistemas capaces de identificar patrones de comportamiento avanzados en los usuarios de las aplicaciones que dan error para poder crear un análisis pormenorizado de las causas de los mismos.
• Realizar un análisis del contexto de un problema, para poder avisar al equipo más adecuado en cada caso.

Con la adición de la inteligencia artificial, las posibilidades crecen enormemente. Como se suele decir en estos casos, el techo es nuestra propia creatividad.

Por último, la propia adopción de la observabilidad por parte de nuevos equipos, aplicaciones o stakeholders (lo que muchas veces definimos como un proceso de onboarding), es completamente automática. Dashboards, alertas, grupos y accesos nacen en el mismo proceso de manera que todo equipo cuando comienza un proyecto ya dispone de la capacidad de explotar la información.

Si además disponemos de información sobre los procesos de desarrollo (tickets, artefactos, PR/MR, commits, despliegues, etc) por primera vez salimos de un contexto observabilidad técnica a una aplicación directa en la gestión de los equipos y los proyectos (véase las métricas DORA, Atlassian, n.d.). Somos por tanto, capaces de salir del cuadro tecnológico por primera vez y hacer nuestros primeros pinitos en la optimización de procesos.

R de “Repercusión en el negocio”

¿Cuál es el impacto de la caída de un servicio en mi negocio? ¿Cuántos usuarios son impactados? ¿Puedo utilizar la observabilidad como una herramienta también para alimentar la toma de decisiones de alto nivel?

Todas estas preguntas son clave. La razón de ello es simple: son las que, en muchas ocasiones, originan las iniciativas de observabilidad actuales. En la introducción comentaba que una de las cosas en las que quería adentrarme era la motivación de este tipo de proyectos. Algo así como: ¿por qué ahora suena tanto? Realmente las aplicaciones siempre se han “monitorizado” hasta cierto punto. ¿Por qué entonces ahora hay tantos proyectos promocionados en las organizaciones?

La razón es sencilla: estamos en una época en la que la información es poder (más que nunca). Lo que en términos un poco más marketinianos consideramos empresas “Data-Driven”. Incluso aquellas compañías que se han desmarcado de esta filosofía (muchas veces deshumanizadora), ponen en valor la importancia de los datos como un pilar fundamental. Es el caso de Netflix y sus "informed captains" (Netflix, n.d.). La observabilidad no es más que otra derivada de este esfuerzo de generar datos para transformarlos en información que pueda ser usada en la toma de decisiones.

Surge, por tanto, un nuevo esfuerzo dentro de las estrategias de observabilidad: la observabilidad del negocio (Business Observability).

Sin embargo, por más que me gustaría continuar con ello, pararemos de momento aquí. El camino ha sido largo y deberíamos descansar junto a la hoguera. En el siguiente post terminaremos la serie y hablaremos más en profundidad de la observabilidad del negocio y cómo nos puede ayudar a generar un verdadero impacto en la estrategia de la propia compañía, así como herramientas y filosofías concretas que podemos implementar para facilitar la adopción.

Referencias

• Atlassian. (n.d.). DORA Metrics: How to measure Open DevOps Success. Atlassian. Retrieved January 8, 2025.
• Netflix. (n.d.). Netflix Jobs. Netflix Jobs. Retrieved January 8, 2025.
• OpenTelemetry. (2024, August 6). What is OpenTelemetry? OpenTelemetry. Retrieved January 8, 2025.
• Splunk. (2024). State of Observability 2024.