Abecedario de observabilidad III: la vida de un proyecto de la S a la Z.

Este post es la tercera parte de una serie dedicada al desarrollo de proyectos de observabilidad. En los anteriores posts hablamos sobre la observabilidad, qué es, por qué es tan interesante y qué pasos deberíamos dar para establecer una correcta estrategia de observabilidad siempre ajustada a los requisitos de la compañía, tanto a nivel de gobernanza, seguridad, disponibilidad, auditoría, etc. Aun así, como todo buen cliffhanger, terminamos antes de finalizar nuestro particular viaje por el modelo. Lo siento por eso ;)

Pero lo prometido es deuda, ¡vamos allá!

S de “Site Reliability Engineering”

Debo aquí una mención especial a una filosofía que implementa muchos mecanismos que nos ayudan a implementar este estado del modelo: la ingeniería de fiabilidad del sitio o, por sus siglas en inglés, SRE.

Dentro de los múltiples conceptos de SRE, es de destacar la aplicación de métricas para analizar no solo la disponibilidad de la plataforma, sino el impacto que esto tiene en los usuarios finales: ¿qué tan fiable es mi aplicación? En concreto, hablamos de las métricas doradas (Golden Metrics) y de los indicadores de servicio.

Las métricas doradas son introducidas por Google (Beyer et al., 2016, #) y representan valores que nos dan un primer vistazo a cómo se comporta una aplicación de cara a la experiencia de usuario (sí, lo sé, han existido siempre, pero es una forma de apoyarme en bibliografía reputada). Existen frameworks parecidos como las métricas RED o USE, pero al final suelen representar el mismo concepto. Definamos las de Google:

• Latencia: el tiempo que tarda un servicio en responder a una petición.
• Errores: representa la tasa de error de una aplicación. Es decir, cuántas peticiones del total devuelven un estado erróneo.
• Saturación: representa cuál es el nivel de sobrecarga de un sistema, la relación entre las tareas o procesos que un sistema puede acometer simultáneamente sin afectar al rendimiento con respecto a los procesos actuales.
• Tráfico: el volumen de peticiones y transacciones de entrada y salida.

Por otro lado, tenemos los indicadores:

• KPIs (indicadores claves del rendimiento): son medidas concretas que permiten a una organización analizar la distancia entre su estado actual y el estado deseado ideal. Dos grandes KPIs en el contexto SRE son el MTTR (tiempo medio de reparación) que mide el tiempo que tardamos en recuperar un sistema caído, y el MTBR (tiempo medio entre fallos).
• SLOs (objetivos a nivel de servicio): son indicadores objetivos y medibles cuyo cumplimiento es esperable y deseable de una manera realista y, por lo tanto, ofrecidos a los clientes. Podemos definir objetivos como una latencia específica, una tasa de error por debajo de cierto umbral, o la disponibilidad del servicio.
• SLIs (indicadores a nivel de servicio): son las métricas concretas que permiten medir el grado de cumplimiento de un SLO.
• SLAs (acuerdo de nivel de servicio): se trata de una serie de criterios por los que un cliente entiende que un proveedor cumple con el servicio que se presta. Es un acuerdo formal entre dos o más partes más que un dato técnico. También definen qué ocurre en caso de no cumplirse los SLOs.
• Presupuesto de error (error budget): define el umbral aceptable de no cumplimiento de un SLO.

Disponer de estas métricas bien definidas nos permitirá ser muy conscientes de la estabilidad de nuestros sistemas, sobre todo desde una perspectiva de cliente. Esto es, al mismo tiempo, una oportunidad para priorizar mejoras y, por otro, una herramienta para plantear estrategias comerciales.

T de “¿Tenemos que informar a la AEPD?”

Entendedme aquí la pregunta como algo cómico, pero no lejos de la realidad. No es trivial, pues es un ejemplo mucho más patrio de la clásica pregunta de “¿cuántos usuarios han sido impactados?”. Si no sabemos si nuestros usuarios se ven perjudicados y somos capaces de medirlo, ¿cómo sabemos dónde no llegamos al corte? ¿Cómo sabemos cuál es el problema? ¿Cómo puede el negocio mejorar el proceso? Una pregunta lleva a otra y terminamos tomando decisiones que a lo mejor son demasiado cortoplacistas o creemos que es algo que se puede solucionar de forma técnica, cuando probablemente haya un problema más grave en la ineficiencia del proceso entendido como algo global.

Este es un melón demasiado grande para este texto, ni es el objetivo del mismo. Donde quiero hacer hincapié es en cómo la observabilidad puede ayudar a resolver estas preguntas.

El primer problema cuando hablamos de observabilidad en el negocio es cómo relacionar la capa tecnológica con los procesos de negocio a los que afecta. No es lo mismo el sistema que gestiona el chatbot de ayuda del área personal de un cliente que la web a través de la cual se realizan los procesos de contratación. Normalmente, ambas aplicaciones son gestionadas de forma independiente hasta cierto punto y tienen diferentes responsables porque son parte de procesos distintos del negocio (captación vs retención) con presupuestos distintos y objetivos también distintos.

Los eventos nos ayudan mucho en este sentido. Ya los hemos definido anteriormente, pero revisitar la definición no nos hará daño. Los eventos son logs especialmente estructurados para identificar momentos, cambios de estado, transacciones o errores dentro del proceso de negocio del que forma parte. Un ejemplo sobre un error en el proceso de alta de un nuevo cliente:

• Log normal: { “body”: “[ERROR] The SQL statement has failed. Error code: SLQxxxxx”}
• Evento: { “body”: “[ERROR] Error en el alta del usuario.”, “event_id”: “new_customer_registration”, “event_process”: “service_contracting”}

Realmente, no es nada complicado ni es algo que no podamos implementar incluso si el estándar que utilicemos no los recogen explícitamente. Ni siquiera son incompatibles entre ellos, tanto así que probablemente nos interesa devolver ambas líneas. Y aun así, nos abren la capacidad de instrumentar nuestras aplicaciones con conocimiento propio del negocio. Es decir, aplicamos la estrategia inicial: que sean las propias aplicaciones las que nos digan lo que ocurre.

Si continuamos con el ejemplo, una cosa es que sepamos que hay 30 de cada 1000 queries a esa base de datos que fallan en ese momento del flujo (un operador puede ir e investigar más en profundidad) y otra que seamos capaces de saber en el mismo momento que 30 de 1000 usuarios que intentan contratar nuestro servicio no se les puede dar de alta en el sistema. La clave está en introducir una trazabilidad clara “top-down” (desde el proceso de negocio hasta la base de datos como capa tecnológica).

Aplicando correctamente esta estrategia obtendremos un conocimiento sólido del rendimiento de nuestro proceso en su completitud. Si a eso le sumamos las métricas doradas de las que hablábamos antes así como los indicadores, tenemos un mapa muy preciso de cada fase del proceso y su comportamiento. Podemos por lo tanto poner la tirita donde más nos duele evitando por el camino frustraciones, apuestas, luchas de egos, esfuerzos en vano e inversiones a fondo perdido. Útil, ¿verdad?

U de “Un esfuerzo común”

A estas alturas, quienes hayáis llegado hasta aquí habréis caído en la cuenta de lo costoso que es lo que proponemos. Herramientas y licencias aparte, hasta ahora lo que se ha propuesto es “barato” de implementar en términos de esfuerzo. No es necesario realizar proyectos mastodónticos ni “big bangs” para llevar todo lo que hemos comentado hasta ahora a la realidad.

Sin embargo, esto no es así con la observabilidad del negocio. Como bien hemos comentado, si de verdad queremos implementar esta última fase, debemos introducir conocimiento del negocio en la propia aplicación. Básicamente, debemos decirle a la aplicación a qué proceso pertenece y qué eventos son los que lleva a cabo. No tiene complejidad como tal, pero instrumentar este conocimiento en el catálogo completo de aplicaciones de una compañía no es algo que se haga en un espacio corto de tiempo. De hecho, es prácticamente la primera vez que hemos tenido que meternos a modificar el código.

Podría hacer lo contrario y optar por lo que muchos post sensacionalistas en internet suelen hacer: basarme en un estado ideal. Sin embargo, quiero ser honesto, las compañías tienen aplicaciones ya hechas y no van a cambiar todas ellas de la noche a la mañana. Es por ello que, al igual que con todo lo que involucra modernizar, debemos hacer un análisis serio sobre qué aplicaciones son las que nos van a devolver un mayor rendimiento a nuestro esfuerzo y empezar por ellas.

Igualmente, existe otro eje sobre el que no hemos hablado, pero que da título a esta sección y es crucial en esta etapa: la involucración de negocio. Desde la definición de los SLOs y SLAs hasta el inventariado de aplicaciones y procesos de la compañía, la capa de negocio debe trabajar codo con codo en el diseño de la estrategia de observabilidad.

Con todo ello, la observabilidad del negocio termina de implementar la observabilidad como un elemento integral de la compañía. Un resumen rápido de algunas cosas que nos proporciona:

• La correlación de la información, unida a un conocimiento profundo del comportamiento del sistema, permite establecer SLIs, SLOs y SLAs para cada aplicación en consonancia con las necesidades del negocio.
• Las aplicaciones definen KPIs implementables en su fase de diseño que permitan evaluar la salud del flujo de negocio que llevan a cabo. Estas aplicaciones son directamente definidas por equipos multidisciplinares de negocio y tecnología y analizados en el contexto de un ecosistema de aplicaciones interrelacionadas.
• Negocio es capaz de calcular métricas como el MTTR, MTBR, etc, de las aplicaciones; modelando la respuesta de la compañía en torno a esos valores.
• Cuando hay una incidencia, es posible calcular el impacto que esta tiene a nivel de negocio. Clientes afectados, cuantización monetaria, transacciones en estados inconsistentes, etc. Esto permite adecuarse mucho mejor a las obligaciones legales o contractuales en las que la compañía incurra con su actividad.

Al igual que todo lo anterior, la observabilidad del negocio no pretende iniciar algo que no existiera antes, sino que pone el foco en la implementación sistematizada de este tipo de aproximaciones.

V de “Vista de pájaro”

Llegados a este punto, ya hemos recorrido íntegramente todo el modelo de madurez que hemos propuesto. Partimos de una compañía que apenas tenía experiencia en este mundo y lo hemos puesto a la cabeza de las prácticas de observabilidad del mercado. Nuestra compañía ahora es capaz de entender profundamente el estado de sus sistemas, incluyendo el rendimiento de las mismas. Esto permite incorporar todo el conocimiento a la capa de negocio, pudiendo ponderar de forma precisa el impacto que los sistemas puedan tener en los diferentes procesos de negocio. Acercamos ambos mundos siendo mucho más certeros a la hora de localizar ineficiencias, cuellos de botella y riesgos, tomando decisiones precisas y efectivas que permitan mejorar la experiencia del cliente.

Adicionalmente, disponemos de todo un catálogo de aplicaciones y procesos completamente observados. Conocemos cuáles son sus fases, eventos e involucración dentro del proceso de negocio. Sabemos, además, cómo es la experiencia de usuario de nuestros clientes al usar las aplicaciones y podemos ofrecer a nuestros equipos de operación multitud de herramientas para acelerar la investigación y el tratamiento de las incidencias que puedan surgir.

El nuevo framework permite que los nuevos elementos nazcan también observados, minimizando el impacto que tiene en el desarrollo de la aplicación. La observabilidad ahora es un factor que aparece a la izquierda del proceso de desarrollo, en el mismo diseño de la aplicación. Esto implica una cobertura total de nuestro catálogo, lo que facilita en gran medida la auditabilidad y análisis de la seguridad de nuestros sistemas.

Por último, los equipos de desarrollo serán capaces de analizar profundamente el rendimiento y el comportamiento de sus aplicaciones tanto en ecosistemas complejos de microservicios como en aproximaciones monolíticas que, en muchas ocasiones, eran grandes cajas negras. El acceso libre a esta información permite mejorar la calidad de los desarrollos, mejorando el rendimiento y maximizando el aprovechamiento de los recursos.

Sin embargo, queda una duda: ¿cómo podemos acelerar este proceso? ¿Cómo podemos simplificar la adopción de la observabilidad tal y como la hemos planteado?

W de “Workflows fantásticos y dónde implementarlos”

Hasta ahora hemos analizado qué es la observabilidad, qué niveles de adopción podemos encontrarnos (sea como sea el modelo de madurez que uséis) y cuál sería la aproximación para implementarlos. Pero seamos sinceros: es laborioso.

Hablamos al final de estandarizar la práctica totalidad de los componentes que forman nuestro panorama informático (servicios, servidores, aplicaciones, procesos, etc) con el único objetivo de poder definir el qué, cuándo, dónde, cómo y por qué de todos ellos. A estos efectos, se promociona actualmente una disciplina que nos puede ayudar en este viaje (no es por el SEO, lo prometo): Platform Engineering.

Platform Engineering es, en esencia, una filosofía basada en diseñar los procesos de desarrollo y operaciones como parte de un producto unificado (gestionada por un equipo habilitador dedicado) que, a través de un portal del desarrollador, provea de capacidades (bases de datos, mensajería, CICD, etc) bajo un modelo de autoprovisión.

El equipo de Plataforma es transversal a la compañía y se encarga de diseñar e implementar las diferentes capacidades (capabilities) de la plataforma. La plataforma se versiona y se gestiona como un producto interno para el que los diferentes equipos de desarrollo son meros clientes. El equipo de desarrollo por su parte, simplemente consume, sin necesidad de preocuparse por lo que se gestiona por debajo o, directamente, sin obligar a reinventar la rueda. El uso de la Plataforma asegura la estandarización, la seguridad, la operación centralizada y, de la misma forma, la observabilidad.

La razón por la que introduzco esta cuña de plataforma como una palanca útil para la adopción de la observabilidad es porque, si se introduce esta última como una capacidad nativa de la plataforma, toda aplicación que nazca en el contexto de esta ya dispondrá de todo lo necesario. La madurez de la plataforma se podrá mapear directamente contra el modelo de madurez elegido y permitirá actuar de manera unificada sin entrar en rediseños o rearquitecturizar las aplicaciones.

Figure out where there’s the most friction in your current development process — whether it is in the deployment pipeline, a Tower of Babel’s worth of different programming languages, or a lack of standardization around observability — and focus your platform team’s efforts there.
Greg Leffler, Director of Developer Evangelism, Splunk

X de “Xenofobia tecnológica”

Vivimos en una época de novedades casi continuas, cambios de nomenclaturas, nuevas tecnologías, aproximaciones, arquitecturas e incluso de nuevas oportunidades de negocio. Actualmente, una empresa que no es capaz de abrazar nuevas formas de hacer las cosas es una empresa que tiene un futuro poco prometedor.

La observabilidad plantea, en este caso, dos puntos a considerar a la hora de adoptar nuevas tecnologías:

• ¿Dónde introducimos el cambio? Recordemos que una de las principales ventajas de la observabilidad del negocio es poder ponderar el efecto que tiene la tecnología sobre las operaciones y procesos de la empresa. Una observabilidad sólida en este sentido es un gran apoyo para el análisis de nuevas tecnologías. Poder cuantificar el beneficio del cambio, no solo a nivel de capacidad técnica (ej. mejora de latencia o mayor consistencia en las transacciones), sino en una visión clara de cómo podría este cambio afectar al cliente en su experiencia es una oportunidad fantástica para elegir nuevas herramientas que se adapten a la realidad y necesidades de la empresa. Sin saltos de fe.
• ¿Cómo introducimos el cambio? Evidentemente, debemos tener en cuenta que los cambios en la tecnología o en las arquitecturas pueden introducir cambios en los procesos de negocio o modificar los catálogos empresariales. Por tanto, la adopción de la tecnología debe tener en cuenta todos estos cambios y trasladarlos a la realidad de nuestra implementación de observabilidad. Si esto se hace correctamente, mantendremos siempre actualizados las visualizaciones, eventos y mapas de componentes, permitiendo una toma de decisiones actualizada con información real.

Por lo tanto, no rechacemos a las nuevas tecnologías una vez tengamos todo nuestro stack montado, sino todo lo contrario. La observabilidad nos permite plantear mejor los cambios tecnológicos, haciendo estimaciones más exactas, aterrizando expectativas y evitando frustraciones.

Y de “Ya queda poco”

Antes de cerrar esta serie con mis propias reflexiones, me gustaría ayudaros con un pequeño resumen de todo lo que hemos estado cubriendo hasta ahora. Realmente, con que os quedéis con los puntos que os ofrezco abajo, a mí me basta. Pero quedaría raro que los pusiera al principio, ¿verdad?

• La observabilidad consiste en nuestra capacidad de recabar datos contextualizados expuestos por un componente (servidor, aplicación, servicio, etc). Actualmente, esto implica que sea la propia aplicación la que nos provea con información que antes eran parte de las responsabilidades del conocimiento del operador: entorno, versión, lenguaje, upstreams, downstreams, si forma parte de un cluster o no, nodo en el que se ejecuta, etc.
• Para implementar la observabilidad, es útil (como en cualquier otro caso) realizar una autoevaluación en el marco de un modelo de madurez. El que hemos visitado en esta serie está compuesto por las siguientes fases:
  • Monitorización tradicional: se monitorizan algunos sistemas, sin una estrategia clara ni estándares bien definidos. La monitorización es reactiva, aislada y fundamentalmente dominio de operaciones e infraestructura
  • Observabilidad fundacional: se plantean estándares tanto para la telemetría como para la forma de extraerla, almacenarla y explotarla. Se centraliza la explotación y se democratiza el acceso a la información. Los equipos de desarrollo empiezan a poder usarla como parte del propio proceso de desarrollo.
  • Observabilidad completa: la información se correlaciona y se crean visualizaciones avanzadas para cubrir cada capa tecnológica. Se pasa a la proactividad, con alertas contextualizadas y los equipos de seguridad pueden comenzar a explotar la herramienta.
  • Observabilidad sistematizada: se introducen métricas DORA y del ciclo de CI/CD. La plataforma utiliza de forma activa sistemas de remediación automática. Se usan herramientas de IA/ML para detectar patrones y acelerar el RCA.
  • Observabilidad de negocio: se introducen objetivos de negocio a nivel de servicio (KPIs, SLIs, SLAs y SLOs). El negocio es consciente del impacto de una incidencia de manera cuantificada y puede tomar medidas informadas para mejorar o mitigar.
• Hasta ahora, el panorama de las herramientas y frameworks de observabilidad estaba disperso, centrado en herramientas concretas. Sin embargo, en los últimos años, han nacido aproximaciones agnósticas que intentan simplificar este entorno como OTel (OpenTelemetry, 2024) u OpenMetrics (Prometheus, n.d.).
• Este proceso es laborioso y requiere de un esfuerzo conjunto tanto de las capas tecnológicas como de las capas de negocio de la compañía. Esto puede ser acelerado gracias a arquitecturas empresariales, de software y de sistemas.
• Las culturas, filosofías y metodologías DevOps, SRE, GitOps y Platform Engineering son palancas extraordinarias para la adopción de la observabilidad. Adicionalmente, son adoptadas ampliamente y tienen mucha literatura desarrollada al respecto.

Z de “Zapatero a tus zapatos”

Como dije en un principio (o casi en el principio, qué sé yo a estas alturas), este texto está pensado para orientar a todo tipo de perfil. Es posible que el lenguaje o el contenido no sea así, en cuyo caso, me disculpo de antemano. Sin embargo, el ánimo es real y como tal, estoy seguro que sea cual sea tu perfil, querido/a lector/a, hay algo en todo esto que es de utilidad para ti.

No he querido casarme con una implementación tecnológica por muy fan de OpenTelemetry que sea (creo que apenas se ha notado, solo le he dedicado una sección). Esto ha sido con el objetivo de entender que la implementación de la observabilidad tiene más que ver con un esfuerzo de estandarización y definición que con el despliegue de una herramienta concreta o el uso de una librería. Evidentemente, esto se tiene que hacer y no es trivial, pero la implementación se convierte en un infierno mucho mayor si la primera parte no está correctamente cumplimentada.

El modelo de madurez nos ayuda a planificar los pasos siguientes, esos en los que muchas veces no sabemos muy bien por dónde tirar. Existen multitud de frentes y, evidentemente, implementarlos todos no es realista, pero debemos hacer un esfuerzo en tener claros qué subconjunto de técnicas, automatismos y visualizaciones queremos utilizar. Al final, somos como deportistas de élite: sin un trabajo de visualización, probablemente nos la peguemos cuando llegue el momento de la verdad.

Por último, quisiera despedirme de ti con varias reflexiones.

Antes he comentado que muchos proyectos de observabilidad nacen de la necesidad de conseguir información más contextualizada que incluso nos permita tomar decisiones a nivel de procesos de negocio. Sin embargo, también es un producto lógico de una tendencia evidente. Hace unos años, el boom del Cloud hizo que muchas empresas apostaran por una estrategia de pago por uso y se subieron a un carro con un altísimo ritmo de innovación. Esto obligó a las empresas a requerir servicios de gente especializada en estos entornos (que no eran tantos) y se suscribieron servicios de operación y mantenimiento externalizados.

Con el paso del tiempo, las compañías han alcanzado un estado donde ya se ha creado conocimiento interno suficiente como para asumir esas funciones, e incluso muchas de ellas han decidido girar el timón y volver al on-premise o tomar iniciativas de plataforma como una forma de unificar la gestión incluso en entornos híbridos. La necesidad de la gestión interna (ya sea en cloud, on-premise, híbrida, con plataforma o sin ella) ha derivado en una reflexión profunda: los sistemas son ahora mucho más complejos, pero nuestra monitorización no lo es. Si metemos en la coctelera el aumento del uso de servicios SaaS y PaaS con modelos de facturación “creativos”, tenemos un descontrol considerable que deriva en un inevitable caos, frustración e impacto económico.

Por ello, considero que la clave de una correcta adopción radica en el cambio de mentalidad. De nada sirve hacer un inventario de 10.000 métricas de 50 componentes distintos. No nos sirve instalar a mano un agente en cada máquina que instalemos y dar el día por terminado. Tampoco nos sirve depender de que el operador lleve lo suficiente en la empresa como para saber que el servicio A tiene una condición de carrera que afecta al servicio C en el 20% de los casos. Sencillamente, no es práctico ni escalable.

Por desgracia, la observabilidad es, al final, una necesidad evidente que nunca ha tenido la importancia que debería en los proyectos. Pensemos por tanto en la observabilidad como algo necesario para todos los miembros de una compañía, independientemente de su título. Todos se ven beneficiados y a todos nos interesa empujar su correcta implementación, cada uno desde un lado distinto de la mesa, pero todos sentados en la misma.

Esto es especialmente relevante cuando pensamos en el lado humano de cualquier empresa, donde existen personas con diferentes filosofías, formas de trabajar y apertura al cambio. Incidir en que la observabilidad no es únicamente un campo exclusivo de los equipos de operación, sino una forma de controlar, evaluar y mejorar a todos los niveles. La información es poder, y si ponemos esa información al servicio de las personas, es éxito asegurado.

Por lo que ahora te toca a ti, desde tu lado de la mesa, aplicar todo lo que hemos comentado en esta serie. Como se suele decir: zapatero, a tus zapatos.

Referencias

• Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly.
• Prometheus. (n.d.). The OpenMetrics project. The OpenMetrics project — Creating a standard for exposing metrics data. Retrieved January 8, 2025
• OpenTelemetry. (2024, August 6). What is OpenTelemetry? OpenTelemetry. Retrieved January 8, 2025