¿Sabes qué es SRE y qué puede hacer por tu negocio?

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:

1. Contratar sólo gente que sepa programar ya que la primera obligación de un SRE es escribir código. La consecuencia de poner a alguien que desarrolla a realizar operaciones es que intentará automatizar su trabajo.
2. Definir para cada uno de los servicios su SLO o Service Level Objective que típicamente será el nivel de disponibilidad.
3. Utilizar este SLO para medir el rendimiento de cada servicio y realizar informes.
4. Utilizar un presupuesto de error como criterio de lanzamiento. (Más adelante explicaremos esto en detalle)
5. Tanto los ingenieros SRE como los desarrolladores pertenecen al mismo pool de personal y todos son tratados como desarrolladores. No hay una línea de separación entre ambos. Se invita a los desarrolladores a probar un tiempo el trabajo de ingeniero SRE y a quedarse si quieren.
6. El trabajo de operaciones excedente recaerá sobre el equipo de desarrollo.
7. Limitar la carga operacional de cada SRE al 50 % para que, al menos, dediquen el otro 50% del tiempo a automatizar y mejorar la fiabilidad.
8. El equipo SRE comparte el 5% del trabajo de operaciones con el equipo de desarrollo. Los programadores también se mancharán sus manos, dedicando parte de su tiempo a la gestión de tickets, al soporte de guardias, etc. Y además, si se añaden funcionalidades que producen inestabilidad en el sistema el equipo SRE puede devolver el producto al equipo de desarrollo que deberá asumir el soporte del producto a tiempo completo mientras no esté listo para ser soportado en producción.
9. Un equipo de guardia tiene un mínimo de 8 ingenieros o 6x2 (en 2 localizaciones). Tener ingenieros suficientes garantiza una cantidad de trabajo aceptable sin caer en el agotamiento.
10. Cada ingeniero puede manejar un máximo de 2 incidencias por turno. La resolución del problema pueda llevar unos minutos pero el proceso de resolución completo se alarga ya que incluye el postmorten, su revisión, establecer un conjunto de acciones, registrarlo en el sistema de ticketing, etc. De forma que, de media,no suelen caber más en un turno.
11. Se realizan postmortems de cada evento.
12. Estos postmortems no buscan echar las culpas a nadie porque no se centran en las personas, hacen foco sobre el proceso y la tecnología. Ya que generalmente cuando algo falla el problema suele estar en el sistema, el proceso, el entorno o el stack tecnológico.

El presupuesto de error

¿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.

Monitorización

Los equipos SRE suelen manejar únicamente tres tipos de resultados de la monitorización.

• En primer lugar, están las alertas, para avisar a una persona que debe intervenir inmediatamente. Se activan porque algo está pasando o está a punto de pasar y es necesario que alguien actúe rápidamente para revertir la situación.
• La segunda categoría son los tickets. En este caso también hace falta que una persona tome medidas pero no inmediatamente, puede que en horas o puede que en días.
• Y la tercera categoría es el logging. Esta es una información que generalmente nadie necesita mirar, pero queda disponible para diagnóstico o para fines forenses.

La resolución de problemas

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.

• La degradación gradual es la capacidad para tolerar fallos sin tener un colapso completo. Por ejemplo, si la red del usuario está yendo lenta, una web puede dejar de servir contenido que no sea relevante para preservar los procesos más críticos.
• La defensa en profundidad trata de conseguir que los fallos se arreglen automáticamente para no impactar al usuario. Automatizando la resolución se consiguen mejorar notablemente los tiempos medios para la reparación. Las diferentes capas del sistema se diseñan para tolerar puntos de fallo sin que nadie intervenga, ni siquiera que esté al tanto.

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.

Planificación de la capacidad

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.

SRE frente a DevOps

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.