¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.techbiz
Juan María Fiz 08/10/2018 - Actualizado: 16/09/2022 Cargando comentarios…
Google tiene ya 8 productos que superan el billón (10^9) de usuarios. ¿Os habéis preguntado alguna vez cómo consiguen gestionar esos servicios? ¿Cómo trabajan sus equipos para mantener todo en un estado óptimo? ¿Cómo realizan los despliegues de nuevas funcionalidades?
A principios de los años 2000, cuando comenzaron con el buscador, ya percibieron que uno de los mayores problemas que tenían para gestionar sus servicios radicaba en la vieja guerra entre la gente de desarrollo y la gente de operaciones.
Los equipos de desarrollo escribían código y lo lanzaban a los equipos de operaciones para su despliegue. Estos trataban de hacerlo funcionar y, si no podían, lo lanzaban de vuelta al equipo de desarrollo. Generalmente los operadores tenían poco conocimiento de código y los desarrolladores tenían poco conocimiento de prácticas operacionales.
A los desarrolladores les preocupaba despachar el código y desplegar nuevas funcionalidades mientras que a los operadores les preocupaba la fiabilidad y mantener las cosas funcionando. En definitiva, perseguían objetivos diferentes: funcionalidad vs. estabilidad.
El concepto de SRE (Site Reliability Engineering) fue creado por Ben Treynor en Google para solventar esta problemática y para fomentar la fiabilidad, la responsabilidad y la innovación de los productos.
Los principios básicos, que detalla su fundador en esta charla, se podrían resumir de la siguiente manera:
¿Cómo se resuelve el conflicto que se genera entre el equipo de desarrollo que quiere desplegar nuevas funcionalidades y que los usuarios adopten su producto y el equipo de operaciones que no quiere que todo vuele por los aires durante su guardia? La solución que se ha alcanzado con los SREs es tener un presupuesto de error.
Para ello negocio o los responsables del producto deben establecer cuál es el objetivo de disponibilidad que quieren para el sistema. Una vez has hecho eso, uno menos el objetivo de disponibilidad es lo que se denomina el presupuesto de error.
Si tiene que estar 99.99% disponible, eso significa que puede estar un 0.01% no disponible. Este tiempo de indisponibilidad es el presupuesto. Y se puede utilizar para gastar en realizar los lanzamientos o aquellas otras tareas que el equipo estime oportunas, siempre que no se rebase el presupuesto.
El presupuesto de error es algo permisible porque el 100% es un objetivo de fiabilidad erróneo para casi todo. En la mayoría de los casos el usuario no percibirá la diferencia entre un sistema 100% disponible y, por ejemplo, 99.999% disponible.
También hay que tener en cuenta que cuanto más cerca se quiera estar del 100%, más esfuerzo y más tiempo habrá que dedicar. Resulta más caro, técnicamente más complejo y generalmente el usuario no lo notará.
Y, además, hay que tener en cuenta que cuanto más se trate de hacerlo fiable por encima de lo que necesita, más se estará penalizando el producto porque se estará frenando el despliegue de nuevas funcionalidades.
SRE acaba con el debate sobre cuándo se puede hacer un despliegue. El go o no go se basará en una fórmula matemática. Cuando se supera el presupuesto de errores hay que congelar los despliegues y dedicar tiempo a estabilizar el sistema y a realizar mejoras para asegurar cumplir con el SLO.
Los equipos SRE suelen manejar únicamente tres tipos de resultados de la monitorización.
Las cosas fallan. Y hay que estar preparado para que esto ocurra antes o después. Por eso un equipo SRE dedica la mayor parte de su tiempo a construir sistemas que sean tolerantes a fallos. Y lo hace por dos vías: la degradación gradual y la defensa en profundidad.
Estas respuestas automáticas proporcionan alta disponibilidad y, al final, la experiencia de usuario no se ve degradada de forma significativa al ocurrir un fallo y da tiempo a arreglarlo sin tener un problema visible de cara al usuario.
La previsión de demanda y la planificación de capacidades son imprescindibles para garantizar la defensa en profundidad de un servicio. Por desgracia es algo que la mayoría de las veces no se hace. Pero resulta fundamental hacer benchmarking de tus servicios, medir cómo se comportan con una carga elevada y qué capacidad sobrante tienen en los picos de demanda.
Haciendo esto se puede prever la demanda y planificar la capacidad para evitar que surjan múltiples emergencias, que ocurran cortes del servicio y abunden las noches sin dormir.
El término DevOps no goza de una definición uniforme. La teoría parte de una gran idea, tener a la gente de desarrollo trabajando conjuntamente con el equipo de operaciones. Pero en su aplicación práctica parece haber un montón de variabilidad en cómo se interpreta por la industria.
DevOps es un conjunto de prácticas y un modelo diseñado para derribar esas barreras entre desarrolladores y operadores. Reduce los silos organizacionales, acepta el fallo como algo normal, implementa el cambio gradual, se aprovecha del uso de herramientas y de la automatización y trata de medir todo lo posible.
Google caracteriza la salud de un servicio en forma de pirámide, desde los requisitos más básicos necesarios para que un sistema funcione como un servicio hasta los niveles más altos de función, los que permiten la autogestión y el gobierno activo del servicio en lugar de apagar fuegos de forma reactiva.
La definición actual de SRE ha sido refinada durante los últimos 15 años incluyendo todas las piezas que hemos visto: equilibrio entre el equipo SRE y el equipo de desarrollo, libre movilidad entre equipos, límites en la carga operacional, presupuestos de errores y todo lo demás.
Y el resultado es que SRE es una implementación muy detallada de la propuesta DevOps. Reduce los silos compartiendo la propiedad del producto entre el equipo SRE y el equipo de desarrollo. Trata el fallo como algo normal mediante el presupuesto de errores y los postmortems sin culpas.
Los cambios se introducen de manera gradual mediante despliegues de tipo canary en una pequeña parte del sistema. Se automatiza todo el trabajo posible y se miden el esfuerzo dedicado y la fiabilidad
Google nos enseña su metodología para que aprendamos de su experiencia y la adoptemos en nuestro trabajo diario. Actualmente SRE es utilizado por compañías tan dispares como Facebook, Dell, Atlassian, Twitter, Apple, Oracle, Dropbox, Amazon o Microsoft.
Está claro que para implementarlo cada empresa requerirá hacer adaptaciones específicas para que encaje dentro su ecosistema y cubra sus necesidades. Todo cambio exige cierto esfuerzo y actitud, pero merece la pena porque es una herramienta excelente para ayudarnos en la transformación digital.
Hace que todos los integrantes sientan que forman un solo equipo y que alineen sus objetivos hacia un fin común. Este marco metodológico soluciona muchos de los problemas a los que nos enfrentamos a la hora de desarrollar, gestionar y mantener nuestros productos digitales.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.