A estas alturas todos hemos podido jugar un rato con Chat-GPT, explorando sus posibilidades, fortalezas y debilidades. Matheus Thait, MD de Thoughtworks España, comentaba hace unos días en LinkedIn su experiencia con ChatGPT y algunas conclusiones sobre su habilidad para reconocer y emular el lenguaje, cambiando dinámicamente entre varios idiomas, de forma tan natural que hace que Google Assistant y Alexa parezcan juguetes toscos y anticuados. ChatGPT resulta convincente en sus argumentos incluso cuando está equivocado, utilizando las mismas herramientas que el más devoto conspiranoico para defender sus argumentos. Y esto deriva en el tercer punto que Matheus comentaba: la popularización de ChatGPT frente a motores de búśqueda como Google puede ser peligrosa, porque ofrece respuestas inmediatas y convincentes, sin importar si con correctas o incorrectas, en lugar de dirigirte a las fuentes de la información y dejar que tú mismo formes una opinión razonada basada en diversas fuentes. Muy de este siglo, si se me permite.

Si hay una metodología mistificada hasta el absurdo esa es probablemente Objectives and Key Results (OKR). El concepto es sumamamente sencillo y, sin embargo, la tendencia innata a creer que algo que no conocemos debe ser complejo a la fuerza hace que su adopción resulte un tanto tortuosa. Hasta que, finalmente y a través de la experiencia, comprobamos que no era tan fiera la bestia. Objetivos y resultados clave: qué queremos y cómo vamos a medir si estamos consiguiéndolo. A esto le sumamos las iniciativas: qué vamos a hacer para intentar conseguir ese objetivo. ¿Cuánto podemos complicar algo tan simple?

Una vez vista la introducción a Site Reliability Engineering (SRE) y los conceptos de niveles de servicio SLI, SLO y SLA, la última pieza del puzle es el Error Budget o presupuesto de error.

Si se trata de medir la fiabilidad del servicio, de comprender si está funcionando correctamente, podríamos argumentar que ya tenemos toda esa información en dashboards con métricas de uso de CPU o de memoria, de usuarios conectados al servicio, latencias, etc… y sí, es cierto. Sin embargo, estos dashboards tienen un problema: sin un conocimiento profundo del sistema, ¿te atreverías a asegurar si está funcionando correctamente basándote sólo en esta imágen?

Cuando pensamos en el flujo de desarrollo de muchas empresas, partimos de una idea transformada en requisitos de negocio. Estos requisitos se pasan al equipo de desarrollo, que los implementa y deja los cambios en manos de operaciones para su puesta en producción y mantenimiento, de modo que finalmente lleguen al mercado. Este modelo de trabajo, sumamente compartimentado, tiene dos puntos de fricción claros: