7,99 €
Mehr erfahren.
- Herausgeber: BRASPORT
- Kategorie: Fachliteratur
- Sprache: Spanisch
¿Qué es "observar" sino el acto de examinar atentamente, prestar atención detallada y analizar minuciosamente un objeto, evento o situación? ¿Y cómo puede esta palabra tan simple transformar la forma en que se aplica la tecnología a los negocios? A través de un enfoque colaborativo, este libro reúne las experiencias y los conocimientos de diversos expertos, ofreciendo una visión práctica y detallada sobre cómo implementar y aprovechar la observabilidad. Al explorar desde los fundamentos hasta casos prácticos, "Jornada de la observabilidad" se presenta como una herramienta indispensable para nosotros, los profesionales de TI, los ejecutivos y todos aquellos que buscan la excelencia en la gestión. Prepárese para una inmersión que transformará la forma en que ve y gestiona la tecnología. Embárquese en este viaje y descubra cómo la observabilidad puede revolucionar los negocios, proporcionando mayor seguridad, eficiencia y satisfacción. Al fin y al cabo, en un mundo de tecnologías y datos exponenciales, observar abre el camino hacia la toma de decisiones correctas, hacia la creación de lo nuevo y hacia infinitas posibilidades.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 362
Veröffentlichungsjahr: 2025
Ähnliche
Organización y Curaduría
Antonio Muniz
Andreia Aranha
Felipe Santos
Tatiane Payá
William Lavieri
JornadaDE LA OBSERVABILIDAD
Uniendo tecnología y negocios para mejorar la experiencia del cliente
Rio de Janeiro 2025
Copyright© 2025 por Brasport Livros e Multimídia Ltda.
Todos los derechos reservados. Ninguna parte de este libro puede ser reproducida, por ningún medio, especialmente en fotocopia (xerox), sin el permiso por escrito de la editorial.
Editor: Antonio Muniz
Tradutor: William Lavieri
Producción Editorial: Monaliza Rosário
Edición electrónica: Rinaldo Mickus e Gleyce Roberta
Portada: Rinaldo Mickus
Se ha empleado mucha técnica y atención en la producción de este libro. Sin embargo, pueden producirse errores de mecanografía y/o impresión. Si tiene alguna duda, incluso sobre conceptos, le rogamos que envíe un mensaje a [email protected] para que nuestro equipo, junto con el autor, pueda aclararla. Brasport y el autor o autores no asumen ninguna responsabilidad por los daños o pérdidas que puedan sufrir personas o bienes como consecuencia del uso de este libro.
BRASPORT Livros e Multimídia Ltda.Rua Sete de Setembro, 48, 3º andar, loja 301Centro, Rio de Janeiro, RJ, CEP 20050-009Tel./Fax: (21)2568.1415Correos electrónicos: [email protected]@brasport.com.brwww.brasport.com.br
Conozca al patrocinador de este libro: Delfia, curadora pionera en soluciones de observabilidad en Brasil
Delfia
Somos Defia, una empresa de curaduría tecnológica que lleva más de 20 años seleccionando, filtrando e implementando tecnologías de vanguardia en el mercado brasileño. En un mundo en constante actualización, nuestro equipo de curadores se ha convertido en un filtro de inteligencia humana, buscando soluciones tecnológicas disponibles en el mercado y seleccionando las que ofrecen los mejores resultados.
En observabilidad, comenzamos incluso antes de que surgiera el término. En 2009 ya estábamos explorando el mercado internacional para implementar en Brasil soluciones de monitorización de datos como Application Performance Management y Network Performance Monitoring. Así, hemos madurado nuestras líneas de negocio para ofrecer cada vez más predicción a los clientes.
Avanzamos en la monitorización de la experiencia del cliente con Business Journey y operaciones del Command Center centradas en la monitorización de extremo a extremo y la resolución de problemas de las aplicaciones.
En este contexto, hemos facilitado la entrada en el país de importantes herramientas de este nicho, como AppDynamics y Datadog, consideradas líderes en su sector. De este modo, coronamos nuestro papel pionero en la asociación con estas tecnologías de vanguardia.
A partir de toda nuestra experiencia en la monitorización de datos, consolidada y avalada por grandes actores del mercado, también fuimos pioneros en traer la nueva era de la monitorización a Brasil: la observabilidad.
Apostamos firmemente en el concepto de observabilidad para la transformación de la TI estratégica y vinculada a los resultados empresariales. Esto se debe a que proporcionar visibilidad e insight valioso sobre el comportamiento de las aplicaciones y los usuarios lleva a las empresas a adelantarse a sus competidores, con decisiones empresariales más acertadas y basadas en datos.
Hoy somos una referencia en observabilidad en el país: nuestra curaduría apoya a grandes empresas del sector financiero, servicios, telecomunicaciones y minorista a ampliar su visión sobre la tecnología y sus resultados de negocio.
Acerca de la Jornada Colaborativa
¡Juntos somos más inteligentes y transformamos más vidas!
Érase una vez un profesor universitario que soñaba con publicar un libro cuando terminó su máster en 2007.
Tras algunas ideas para publicar sobre temas como la certificación Microsoft, la gestión de proyectos y la gestión de servicios, el sueño comenzó a hacerse realidad en 2017 con el libro “Jornada DevOps”, pero algunos obstáculos frenaron su evolución tras definir la estructura final para la certificación oficial EXIN y escribir tres capítulos.
En septiembre de 2018, durante una conferencia en la PUC Minas, surgió una idea: “¿ayudarían otras personas apasionadas por DevOps con la escritura colaborativa?”. Decenas de personas aceptaron la invitación y el libro se presentó ante 350 personas el 6 de junio de 2019 en el Centro de Convenciones SulAmérica de Rio de Janeiro, tras un intenso trabajo coordinado con personas de varias ciudades que nunca habían trabajado juntas antes.
Tras esta exitosa experiencia, en la que se aprendieron muchas cosas, la ampliación de los equipos generó grandes amistades, nuevas iniciativas y una donación de 553 000 reales a instituciones con el lanzamiento de 41 libros con empresas amigas como Globo, Lojas Renner, Banco PAN, Banco Carrefour, etc.
Soñamos con transformar más vidas uniendo la inteligencia colectiva de expertos, comunidades y empresas amigas...
www.jornadacolaborativa.com.br/
www.linkedin.com/company/jornadacolaborativa/
Prefacio
¿Qué es “observar” sino el acto de examinar atentamente, prestar atención detallada y analizar minuciosamente un objeto, evento o situación? ¿Y cómo puede esta palabra tan simple transformar la forma en que se aplica la tecnología a los negocios?
Puedo afirmar con certeza que estudiar y aplicar el concepto de observabilidad en mi día a día como líder de TI ha transformado mi trayectoria profesional, aportándome un aprendizaje que ha ampliado mi perspectiva de gestión y haciéndola más estratégica. Así pude ver más allá de las cuestiones técnicas, observando cómo las personas, los procesos y la tecnología se integran de forma coordinada y orientada al negocio.
Por eso, cuando me invitaron a escribir este prefacio, quise contribuir rápidamente reforzando cómo este conocimiento también puede marcar la diferencia para todos aquellos que ahora comienzan este viaje de lectura. El libro que tienen en sus manos es mucho más que una guía técnica; es un manifiesto sobre la importancia de integrar los negocios y la tecnología de manera cohesionada y proactiva.
La observabilidad no es solo una herramienta, sino una filosofía que impregna todas las capas de la organización, desde la infraestructura técnica hasta la experiencia del cliente. Nos permite ver lo que está sucediendo, entender por qué, predecir lo que puede ocurrir y actuar de forma proactiva para garantizar el mejor resultado posible.
En este mundo cada vez más complejo, donde los sistemas distribuidos y los microservicios se entrelazan en una “danza” constante, la observabilidad es la clave para desvelar los secretos del rendimiento, la fiabilidad y la eficiencia. Nos permite tomar decisiones basadas en datos y optimizar los recursos, ofreciendo la mejor experiencia posible a nuestros clientes.
A través de un enfoque colaborativo, este libro reúne las experiencias y los conocimientos de diversos expertos, ofreciendo una visión práctica y detallada sobre cómo implementar y aprovechar la observabilidad. Al explorar desde los fundamentos hasta casos prácticos, “Jornada de la observabilidad” se presenta como una herramienta indispensable para nosotros, los profesionales de TI, los ejecutivos y todos aquellos que buscan la excelencia en la gestión.
Prepárese para una inmersión que transformará la forma en que ve y gestiona la tecnología. Embárquese en este viaje y descubra cómo la observabilidad puede revolucionar los negocios, proporcionando mayor seguridad, eficiencia y satisfacción. Al fin y al cabo, en un mundo de tecnologías y datos exponenciales, observar abre el camino hacia la toma de decisiones correctas, hacia la creación de lo nuevo y hacia infinitas posibilidades.
Claudia Marquesani
Directora de Tecnología, eterna “observadora” de la tecnología y del mundo.
Presentación de la Jornada de la Observabilidad
En mi labor como empresario, advisor y editor, tengo un gran contacto con ejecutivos, empresarios y consejeros cada vez más interesados en iniciativas que mejoren la experiencia del cliente. La observabilidad se está convirtiendo en una práctica importante para la gran mayoría de las empresas en este mundo digital en el que vivimos.
Aunque implica muchas acciones técnicas, el objetivo de la observabilidad está directamente relacionado con los negocios. Piensa en cómo esta visión es imprescindible en el mundo digital:
✓ Lucas accedió a una aplicación para pedir un coche e ir al centro comercial.
✓ Hubo una demora mayor de lo aceptable o no hay previsión de cuándo llegará.
✓ Lo más probable es que no llame a la empresa para quejarse de la situación, sino que haga un nuevo pedido utilizando otra aplicación.
✓ ¿Cuánto ha dejado de ganar la aplicación por la falta de observabilidad que podría evitar el fallo?
La historia del libro “Jornada de la Observabilidad” comenzó el 12 de septiembre de 2023, en una animada conversación con Tati durante el evento de lanzamiento del libro “Jornada SRE” en el precioso auditorio de Accenture en São Paulo. Después de unos días, reflexioné y pensé que la sugerencia de Tati de profundizar en este importante tema en un nuevo libro colaborativo tenía mucho sentido. Pensamos en algunos nombres para formar el equipo organizador y de curaduría, y me entusiasmó mucho el fuerte compromiso de William desde la estructuración inicial de los capítulos. También contamos con el refuerzo de un gran equipo de curaduría: Felipe y Andreia.
La elección de personas con experiencias diversas para el equipo de coautores fue una sorpresa positiva y contamos con la rápida adhesión de grandes profesionales que viven a diario la observabilidad en diversas empresas.
El resultado del libro ha sido increíble porque nuestro gran equipo ha sabido combinar la visión técnica con la empresarial para contribuir a la mejora de los resultados de las empresas que dependen cada vez más de la tecnología.
¡Espero que evolucione en su carrera profesional y mejore la experiencia de sus clientes con este contenido tan rico!
Antonio Muniz
Fundador de Jornada Colaborativa, CEO Advisor - IT Services
Resumen
PARTE I. OBSERVANDO LOS CONCEPTOS
1. Las diferencias entre observabilidad y monitorización
Andreia AranhaWilliam Lavieri
La observabilidad y la monitorización pueden parecer similares, pero son conceptos muy diferentes en cuanto a enfoque y finalidad.
La principal diferencia es que “monitorización” es un verbo, que denota acción, es decir, la acción de monitorizar un sistema. Y “observabilidad” es un sustantivo, es decir, una característica o función que un sistema puede tener o no.
Una rápida analogía para servir de ejemplo.
Un conductor que maneja un coche está realizando la acción de conducir el vehículo, incluso si ese coche no tiene ningún panel de navegación en su consola, el conductor aún puede guiarlo, saber si el motor está encendido y si el coche está en movimiento, basándose en su observación cognitiva (sus propios ojos). Este escenario se acerca mucho al concepto de monitorización tradicional.
Sin embargo, si el vehículo cuenta con funciones de observabilidad en su fabricación, que externalizan información al conductor sobre los recursos, las operaciones y las condiciones del vehículo, como la presión de los neumáticos, la temperatura del motor, la velocidad y el combustible, esto permitirá una mayor y mejor monitorización por parte del conductor.
Tenga en cuenta que la observabilidad es un conjunto de técnicas de medición y externalización de información sobre los recursos, las operaciones y las condiciones de uso/estado del vehículo, que deben definirse y construirse en la fase de fabricación. Posteriormente, si esta información se presenta y consume a través de un panel analógico o digital, si las luces indicadoras son verdes o azules, o incluso si hay una aplicación móvil integrada en la consola del coche para seguir esta información, todo lo que ocurre después de la medición y la externalización de la información se considera monitorización, ya que es en ese momento cuando la información ya tratada y correlacionada se consume y su consumidor puede reaccionar ante cualquier situación.
Para los sistemas de TI se aplican los mismos conceptos, independientemente si el objetivo es un proyecto de hardware, software o ciberseguridad. Sea cual sea la naturaleza del proyecto, las definiciones de observabilidad deben tenerse en cuenta durante la fase de diseño y construcción, con el fin de evitar retrabajo y adaptaciones técnicas, que en el futuro puedan generar débitos técnicos o incluso anti-estándares.
Otro error conceptual muy común, es confundir o unificar el concepto de observabilidad con herramientas de mercado. Si decidís utilizar Grafana o Kibana para crear determinados paneles de monitoreo, se trata de una decisión sobre monitorización, ya que ambas utilizan información ya externalizada por un sistema para presentar gráficos en un panel intuitivo, lo que permite una mejor reacción del consumidor.
Las decisiones sobre observabilidad están mucho más cercas con la configuración de la infraestructura, las prácticas y los frameworks de desarrollo, además de las técnicas de externalización de datos. Esto se refleja en los pilares de la observabilidad en los mecanismos de logs, métricas y traces:
Otro error conceptual muy común es confundir o unificar el concepto de observabilidad con herramientas de mercado. Si tú o tu empresa decidís utilizar Grafana o Kibana para crear determinados paneles, se trata de una decisión sobre herramientas de monitorización, ya que ambas utilizan información ya externalizada por un sistema para presentar gráficos en un panel intuitivo, lo que permite una mejor reacción del consumidor.
Las decisiones sobre observabilidad están mucho más relacionadas con las configuraciones de infraestructura, las prácticas y los marcos de desarrollo, además de las técnicas de externalización de datos. Esto se refleja en los pilares de la observabilidad en registros, métricas y trazas:
Métricas: Son medidas cuantitativas sobre el consumo, las ejecuciones y el estado interno del sistema. Los ejemplos más comunes son el consumo de CPU, memoria, disco y volumen de conexiones.
Logs: Son registros que describen en detalle eventos específicos dentro de un sistema. Un ejemplo común es cuando la memoria de un servidor o servicio alcanza el 100% y no responde a nuevas solicitudes, se registra un evento denominado “Out of Memory”, que indica su saturación.
Traces: Facilitan la comprensión de un recorrido realizado a través de una solicitud (y su respectiva respuesta), que recorre varios servicios distribuidos. Para muchos, el trace se considera la evolución del log tradicional, cuando se implementa de forma encadenada en entornos distribuidos, permitiendo la trazabilidad transaccional del consumo del usuario a través de todo el ecosistema de TI.
Tenga en cuenta que si su sistema no externaliza ningún tipo de información, aun no tiene sentido elegir una herramienta de monitoreo. Por otro lado, algunas herramientas pueden ayudar con las tareas de extracción de información interna de su sistema, ya sea mediante la inspección de la ejecución a nivel del kernel o del espacio de usuario, lo que puede ser más o menos intrusivo, además de las pruebas sintéticas, que envían solicitudes al sistema y, en función de su respuesta, intentan determinar su estado interno.
Un sistema de TI se considera observable, es decir, cumple mínimamente con el concepto de observabilidad, cuando externaliza información de cuatro tipos, considerados Golden Signals de la observabilidad:
Latencia: Es el tiempo necesario para procesar y responder una solicitud. Las altas latencias afectan directamente a la experiencia de los usuarios. Un sistema puede estar “en funcionamiento”, pero ser lo suficientemente lento para comprometer la experiencia de los clientes. La medición de la latencia se puede consolidar desde la perspectiva del usuario final o desglosar por cada llamada e integración interna del sistema, hasta concebir la respuesta al usuario final.
Tráfico: Representa el volumen de solicitudes o la carga de trabajo en un sistema. Permite comprender si el sistema se está utilizando dentro de las especificaciones límite para las que fue diseñado o si está sobrecargado. Conocer el punto de ruptura del sistema y de sus integraciones permite orientar los trabajos preventivos de capacidad o incluso el rediseño del sistema.
Errores: Porcentaje de solicitudes que resultan en fallos. Un aumento en la tasa de error puede indicar fallos lógicos, problemas de dependencias, fallos de infraestructura o incluso violaciones de contratos de API. Normalmente, las ejecuciones se contabilizan analizando su encabezado HTTP, que indica 20x para éxito, 30x para redirección de contenido, 40x para fallos en el lado del cliente y 50x para fallos en el lado del servidor. Conocer el volumen habitual de esta contabilización para cada tipo de solicitud al sistema puede ayudar a identificar loops, timeout, solicitudes mal realizadas, etc.
Saturación: Cuán cerca está el sistema de su capacidad máxima. Los sistemas que operan constantemente cerca de la saturación son propensos a fallas o degradación del rendimiento. Por lo general, esta métrica se mide para recursos vitales como CPU, memoria, E/S, conexiones simultáneas, colas de mensajes o número de subprocesos. Además de conocer y observar estos recursos, será necesario correlacionarlos con su diseño de arquitectura para determinar “quién está consumiendo”, “cómo” y “por qué”, lo que permitirá determinar si el consumo es legítimo o excesivo para cada situación.
Por último, podemos concluir que la observabilidad es una característica y capacidad de un sistema de TI para externalizar información sobre sus recursos, operaciones y condiciones de uso/estado, permitiendo que las herramientas y procesos de monitoreo consuman y reaccionen a la información externalizada. En este libro se presentarán técnicas para aplicar la observabilidad en diversas dimensiones y aspectos de TI. Espero que nuestro recorrido contribuya a satisfacer sus expectativas.
2. La observabilidad en el mundo de la nube
Vanessa Genaro
En contraste con los métodos de desarrollo monolíticos y en cascada habituales en la década de 1990 hasta principios de la década de 2000, los equipos de desarrollo de software y operaciones actuales están adoptando cada vez más enfoques modernos como el cloud native y el agile. Estos permiten a los equipos lanzar nuevas funcionalidades de forma autónoma, sin estar rígidamente vinculados al impacto en otros equipos. Esto aporta una serie de beneficios comerciales significativos, como el aumento de la productividad y la rentabilidad. Por ejemplo, la capacidad de ajustar individualmente los componentes del servicio según la demanda y de asignar recursos en una amplia gama de servidores, tanto virtuales como físicos, se traduce en un mejor control de los costes y una mayor escalabilidad para el negocio (MAJORS; FONG-JONES; MIRANDA, 2022, p. 61).
Sin embargo, es importante reconocer que estos beneficios conllevan costes de gestión. La introducción de sistemas abstractos con controles dinámicos plantea retos de complejidad emergente y patrones de comunicación no jerárquicos. Mientras que los sistemas monolíticos más antiguos eran más sencillos de supervisar y comprender, la ejecución viable de sistemas nativos en la nube a gran escala requiere hoy en día prácticas sociotécnicas más avanzadas, como la observabilidad (MAJORS; FONG-JONES; MIRANDA, 2022, p. 62).
La computación en la nube ha transformado fundamentalmente la forma en que las empresas desarrolla, implementa y operan sus sistemas de software. Con la transición a entornos distribuidos y altamente escalables, ha surgido la necesidad de un enfoque diferente para comprender y controlar el rendimiento y la fiabilidad de estos sistemas. Aquí es donde entra en juego el concepto de observabilidad. Charity Majors, Liz Fong-Jones y George Miranda (2022, p. 60) afirman:
La observabilidad no existe en el vacío, sino que es una consecuencia y parte integrante de los movimientos DevOps, SRE y cloud native.
En abril de 2012, nace Downdetector, un sitio web dedicado a rastrear interrupciones y problemas relacionados con los servicios de Internet, incluyendo sitios web, aplicaciones y proveedores de servicios. Con ello, aumenta la necesidad de transparencia y responsabilidad por parte de las empresas de tecnología, lo que fomenta la rápida resolución de problemas y la comunicación abierta con los usuarios. Por lo tanto, estar atento solo a los problemas que “sabemos” que pueden salir mal ya no era suficiente; las empresas necesitaban comprender primero qué era una jornada de servicio satisfactoria y cómo garantizar el estado normal de nuestras aplicaciones.
Tras la COVID-19, hemos visto cómo se ampliaba este panorama y el mundo ha conocido el acrónimo BANI, que significa “frágil”, “ansioso”, “no lineal” e “incomprensible”. Estos términos describen las características de los sistemas complejos e inciertos. La idea detrás de BANI es reconocer que muchos aspectos del mundo moderno, especialmente en la era digital, se caracterizan por la fragilidad, la ansiedad, la no linealidad y la incomprensibilidad. Estas características pueden influir en la forma en que las organizaciones planifican y responden a los cambios y las incertidumbres. Refuerza la necesidad de evolucionar la forma en que supervisamos nuestros sistemas: en lugar de supervisar lo que se conoce, es necesario observar y construir un modelo que nos permita actuar de forma proactiva.
En este capítulo, exploraremos el papel crucial de la observabilidad en el mundo de la nube. Discutiremos qué es la observabilidad, por qué es importante, los componentes principales de la observabilidad en la nube y cómo las organizaciones pueden implementar prácticas de observabilidad eficaces para garantizar el éxito de sus sistemas distribuidos. También presentamos un caso práctico de Netflix.
¿Qué es la observabilidad?
Si el monitoreo se centra en cosas que anticipamos que van a salir mal, creando límites de aceptabilidad y alertas cuando se superan, la observabilidad se centra en externalizar la mayor cantidad de datos posible sobre todo el servicio, lo que nos permite inferir cuál es el estado actual de ese servicio. La capacidad de observación proporciona una visibilidad más granular del comportamiento INESPERADO de los sistemas complejos, junto con un contexto rico. Una buena capacidad de observación ayuda a los equipos a comprender lo que está sucediendo, actuar y obtener información valiosa y útil para todas las partes interesadas.
La observabilidad se compone de tres pilares:
✓ Métricas: ayudan a responder a la pregunta ¿tengo un problema? y son muy útiles para la detección y alerta en tiempo real, especialmente con sistemas a gran escala.
✓ Traces: ayudan a comprender dónde está el problema en una compleja red de microservicios. Son muy útiles para explorar y resolver problemas de dependencias de servicios ascendentes/descendentes y transacciones de usuarios.
✓ Logs: te ayudan a profundizar y comprender “por qué está ocurriendo el problema” en primer lugar.
Juntos, y cuando se correlacionan de manera eficaz, estos tres tipos de datos pueden proporcionar la velocidad, el contexto y los detalles que necesita para comprender completamente el comportamiento de los sistemas complejos.
¿Por qué es importante la observabilidad en un entorno de nube?
El propósito de la observabilidad es ayudar a las personas a comprender el estado interno de sus sistemas y aplicaciones. Este estado se puede lograr de varias maneras, como, por ejemplo, mediante el uso combinado de logs, métricas y traces. Sin embargo, el objetivo de la observabilidad en sí mismo no está vinculado a la forma en que se lleva a cabo. En sistemas monolíticos, donde se pueden prever las posibles áreas de fallo, una sola persona podría depurar los sistemas y lograr una observabilidad adecuada utilizando logs detallados de las aplicaciones o métricas básicas a nivel del sistema, como el uso de la CPU o el disco. Sin embargo, estas herramientas y técnicas heredadas ya no son eficaces para hacer frente a los nuevos retos de gestión que plantean las oportunidades de los sistemas nativos de la nube.
Por lo tanto, vemos que hay varias razones por las que la observabilidad es tan importante en este contexto:
1. Entornos distribuidos y escalables: en la nube, los sistemas están compuestos por una infinidad de servicios interconectados y distribuidos globalmente. La observabilidad permite realizar un seguimiento del rendimiento y el comportamiento de estos sistemas complejos en tiempo real.
2. Identificación y resolución rápida de problemas: con la observabilidad, los equipos de operaciones pueden detectar y diagnosticar problemas rápidamente, minimizando el tiempo de inactividad y el impacto en los usuarios.
3. Optimización de recursos: al supervisar las métricas de uso de recursos, las organizaciones pueden identificar oportunidades de optimización y reducir los costes operativos en la nube.
4. Mejora de la experiencia del usuario: con una visión global del sistema, las empresas pueden garantizar una experiencia coherente y de alta calidad a los usuarios finales, independientemente de la complejidad de la infraestructura subyacente.
Componentes de la observabilidad en la nube de
Podemos decir que la observabilidad está conectada con la Tercera Forma de DevOps. La Tercera Forma de DevOps, propuesta por Gene Kim, Jez Humble y Patrick Debois, es un enfoque que busca ir más allá de la simplificación de los procesos de desarrollo y operaciones (DevOps) para integrar la seguridad, la calidad y la confiabilidad a lo largo de todo el ciclo de vida del desarrollo de software. Nos permite a los equipos tener una comprensión más profunda y holística de cómo están funcionando nuestros sistemas en producción. En lugar de centrarse únicamente en la entrega rápida de nuevas funciones (la Primera Forma) o en la estabilidad operativa (la Segunda Forma), la Tercera Forma de DevOps destaca la importancia de aprender y responder rápidamente a los comentarios del sistema en producción.
Para lograr la observabilidad en su aplicación en la nube, se necesita lo siguiente:
1. Recopilación de datos: implementar mecanismos para recopilar datos de métricas, logs y rastreos de todos los componentes del sistema distribuido.
2. Almacenamiento e indexación: centralizar e indexar los datos recopilados en un lugar accesible y fácil de buscar.
3. Visualización y análisis: utilizar herramientas de visualización y análisis para transformar los datos en insight útil, identificando patrones, tendencias y anomalías.
4. Alertas y notificaciones: configurar alertas y notificaciones que se activen cuando se cumplan determinadas condiciones, lo que permite una respuesta proactiva a eventos y problemas.
5. Automatización y corrección: automatizar las acciones correctivas para resolver rápidamente los problemas y reducir la intervención manual.
Implementación de la observabilidad en la nube con
Para implementar prácticas eficaces de observabilidad en la nube, las organizaciones deben seguir algunas directrices:
1. Cultura de observabilidad: promover una cultura organizativa que valore la observabilidad y fomente la colaboración entre los equipos de desarrollo, operaciones y seguridad.
2. Herramientas y tecnologías: invertir en herramientas y tecnologías adecuadas para recopilar, almacenar, visualizar y analizar datos de observabilidad de forma eficaz.
3. Estándares y mejores prácticas: seguir los estándares y mejores prácticas establecidos por la comunidad para la implementación de la observabilidad, como los principios de OpenTelemetry y las directrices de la CNCF (Cloud Native Computing Foundation).
4. Monitorización proactiva: anticipar y prevenir problemas mediante la monitorización proactiva y el análisis predictivo.
5. Interacción continua: revisar y mejorar continuamente las prácticas de observabilidad basándose en los comentarios y la evolución de los sistemas y los requisitos empresariales.
Estudio de caso de
Tal y como se identifica en el libro “Manual de DevOps” (KIM et al., 2018, p. 318), a continuación, se presenta un caso práctico que se relaciona muy bien con nuestro tema:
Un buen ejemplo de análisis de telemetría para encontrar y corregir problemas de forma proactiva antes de que afecten a los clientes lo encontramos en Netflix, proveedor internacional de películas y series de televisión en streaming. Netflix obtuvo unos ingresos de 6200 millones de dólares procedentes de 75 millones de suscriptores en 2015. Uno de sus objetivos es proporcionar la mejor experiencia a quienes ven vídeos en línea en todo el mundo, lo que requiere una infraestructura de distribución robusta, escalable y resistente. Roy Rapoport describe uno de los retos de gestionar el servicio de distribución de vídeos basado en la nube de Netflix: “Dado un rebaño de ganado que debe tener el mismo aspecto y comportarse de la misma manera, ¿qué ganado parece diferente del resto? O, más concretamente, si tenemos un clúster de ordenadores sin estado de mil nodos, todos ejecutando el mismo software y sujetos a la misma carga de tráfico aproximada, nuestro reto es descubrir qué nodos no son parecidos”. Una de las técnicas estadísticas que el equipo utilizó en Netflix en 2012 fue la detección de valores discrepantes, definida por Victoria J. Hodge y Jim Austin, de la Universidad de York, como la detección de “condiciones de ejecución anormales, que pueden dar lugar a una degradación significativa del rendimiento, como un defecto en la rotación del motor de un avión o un problema de flujo en una tubería”. Rapoport explica que Netflix utilizó la detección de valores discrepantes de una manera muy sencilla, que consistió en calcular primero cuál era el “normal actual” de forma inmediata, dada la población de nodos en un clúster de ordenadores. A continuación, identificamos los nodos que no se ajustaban a ese patrón y los retiramos de la producción”. Rapoport continúa: “Podemos identificar los nodos defectuosos automáticamente, sin definir cuál es el comportamiento “correcto”. Y, como lo diseñamos para que funcione de manera resiliente en la nube, no le decimos a nadie de Operaciones que haga nada, sino que simplemente eliminamos el nodo informático defectuoso y luego lo registramos o notificamos a los ingenieros de la forma que ellos prefieran”. Al implementar el proceso Server Outlier Detection (Detección de valores atípicos del servidor), dice Rapoport, Netflix “redujo significativamente el trabajo de encontrar servidores defectuosos y, lo que es más importante, redujo considerablemente el tiempo necesario para corregirlos, lo que se tradujo en una mayor calidad del servicio. La ventaja de utilizar estas técnicas para preservar la salud mental de los empleados, el equilibrio entre el trabajo y la vida personal y la calidad del servicio no puede ser lo suficientemente enfatizada”. El trabajo realizado en Netflix destaca una forma muy específica de utilizar la telemetría para mitigar los problemas antes de que afecten a nuestros clientes.
3. Uso de objetivos de nivel de servicio (SLO) para mejorar la fiabilidad
Alessandro Silva Rodrigo Macia
Introducción a los objetivos de nivel de servicio (SLO)
Los objetivos de nivel de servicio (SLO) son metas internas establecidas para medir el estado del servicio. Popularizados por el libro “Site Reliability Engineering” (BEYER et al., 2016), los SLO constituyen una parte fundamental de los acuerdos de nivel de servicio (SLA), externos entre los proveedores de servicios y sus clientes. Estas medidas internas suelen ser más estrictas que los acuerdos externos o los compromisos de disponibilidad. Con este rigor adicional, los SLO pueden proporcionar un mecanismo de seguridad que permite a los equipos identificar y corregir los problemas antes de que la experiencia del usuario externo alcance niveles inaceptables.
Se ha escrito mucho sobre el uso de los SLO para la fiabilidad del servicio (se recomienda el libro “Implementing Service Level Objectives”, de Alex Hidalgo (2020), para comprender mejor el tema), y no son exclusivos del mundo de la observabilidad. Sin embargo, adoptar un enfoque basado en SLO para supervisar el estado del servicio requiere una capacidad de observación integrada en sus sistemas. Los SLO pueden implementarse, y a veces se implementan, en sistemas sin observabilidad. Sin embargo, las ramificaciones de esta práctica pueden tener consecuencias graves e involuntarias. Para entender por qué ocurre esto, comencemos por examinar las características de las alertas de monitorización tradicionales.
Enfoques tradicionales del monitoreo
En los enfoques basados en la monitorización, las alertas suelen centrarse en lo que es más fácil de medir. Las métricas se utilizan para realizar un seguimiento de los estados simplificados del sistema, que pueden indicar un mal funcionamiento de los procesos subyacentes de un servicio o ser una señal temprana de problemas futuros: activar una alerta si la CPU supera el 80%, si la memoria disponible cae por debajo del 10%, si el espacio en disco está casi lleno, si hay un número excesivo de subprocesos en ejecución, entre otras medidas simplistas de las condiciones del sistema.
Aunque estas medidas son fáciles de recopilar, a menudo no son indicadores útiles para activar alertas. Estas métricas simplistas también pueden indicar la ejecución de un proceso de backup, el funcionamiento del garbage collector en su función de limpieza o una variedad de otros eventos normales en el sistema. En resumen, estas condiciones pueden ser reflejo de numerosos factores, no solo de los problemas específicos de interés. Las alertas basadas en estas métricas simplistas generan un alto índice de falsos positivos.
Los equipos de ingeniería, responsables del funcionamiento del software en producción, suelen aprender a ignorar o incluso a suprimir estas alertas debido a su falta de fiabilidad. Es habitual utilizar frases como “no te preocupes por esta alerta: sabemos que el proceso consume mucha memoria ocasionalmente”.
Acostumbrarse a las alertas propensas a falsos positivos es problemático y peligroso. En otras industrias, este fenómeno se conoce como “normalización de la desviación”, un término que tiene su origen en la investigación del desastre del Challenger. Cuando los miembros de una organización ignoran habitualmente las alarmas o no actúan ante ellas, se vuelven insensibles hasta el punto de no reconocer la gravedad de una alerta, desviándose de la respuesta esperada. Los fallos considerados “normales” e ignorados constituyen, como mínimo, ruido de fondo y, en el peor de los casos, negligencias que pueden provocar fallos sistémicos en cadena con consecuencias desastrosas.
Esta disfunción es tan frecuente en la industria del software que muchos proveedores de herramientas de monitoreo y respuesta a incidentes ofrecen soluciones etiquetadas como AIOps para gestionar, suprimir o procesar esta sobrecarga de alertas. Los equipos de ingeniería están tan acostumbrados al ruido de las alertas que esta situación se considera ahora normal. Si el futuro de la ejecución de software en producción es generar tanto ruido que sea necesario procesarlo artificialmente, es razonable afirmar que la situación ha evolucionado más allá de la normalización de la desviación: los proveedores del sector ya han capitalizado esta tendencia ofreciendo soluciones para su gestión.
Recuerde, cuanto más preciso y completo sea el análisis de requisitos, más fácil será identificar la solución de software que mejor se adapte a las necesidades de su organización.
Los sistemas distribuidos aumentan el problema de la fiabilidad alerta
En sistemas aislados, anticipar modos de fallo es significativamente más fácil. Por lo tanto, parece lógico implementar un monitoreo que prevea cada uno de estos modos de fallo conocidos. Los equipos de operaciones que dan soporte a sistemas autónomos pueden desarrollar verificaciones de monitoreo muy específicas para cada estado definido. Sin embargo, a medida que los sistemas se vuelven más complejos, se produce una explosión combinatoria de posibles modos de fallo. Los equipos de operaciones, acostumbrados a sistemas menos complejos, pueden depender de su intuición, sus suposiciones y sus recuerdos de fallos pasados para predecir posibles fallos. Aunque esta estrategia con monitoreo tradicional puede funcionar a menor escala, la creciente complejidad de los sistemas modernos exige que los equipos desarrollen y mantengan cientos o incluso miles de verificaciones de estado precisas para cubrir todos los escenarios posibles.
Esta metodología es insostenible. Las verificaciones a menudo no se mantienen, el conocimiento es difícil de transferir y el comportamiento histórico no puede predecir con seguridad los fallos futuros. La mentalidad tradicional del monitoreo suele centrarse en prevenir los fallos. Sin embargo, en sistemas distribuidos con cientos o miles de componentes que procesan tráfico de producción, los fallos son inevitables.
En los sistemas contemporáneos, los equipos de ingeniería suelen distribuir la carga entre múltiples sistemas distintos. Se separan, fragmentan, particionan horizontalmente y replican datos a través de sistemas distribuidos geográficamente. Aunque estas decisiones arquitectónicas optimizan el rendimiento, la resiliencia y la escalabilidad, también pueden hacer que los fallos sistémicos sean difíciles de detectar o predecir. Los modos de fallo emergentes pueden afectar a los usuarios mucho antes de que las sondas sintéticas, utilizadas tradicionalmente como indicadores, señalen cualquier problema. De repente, las mediciones tradicionales de la salud del servicio pierden su valor al volverse irrelevantes para el comportamiento general del sistema.
Las métricas tradicionales del sistema suelen fallar a la hora de identificar modos de fallo inesperados en sistemas distribuidos. Un número anormal de subprocesos
