Google introdujo tantas innovaciones que sería imposible enumerarlas a todas. Y no hablamos solo de las obvias, como los algoritmos del motor de búsqueda o los programas y apps casi omnipresentes (Google Maps, Docs, Gmail), ni siquiera de los vehículos autoconducidos. Hoy vamos a referirnos a esta innovación: el Site Reliability Engineering (SRE) o Ingeniería de Fiabilidad del Sitio.
En pocas palabras, el SRE es un framework práctico para el desarrollo de software que mejora incluso a grandes como DevOps. Espera, ¿qué? Sí, si luchaste para implementar DevOps en tu organización, sabrás que hay un jugador aún más importante.
Pero no te preocupes. El Site Reliability Engineering aporta muchas cosas que DevOps no tiene, aunque ambos no son mutuamente excluyentes. El SRE fomenta el crecimiento y la cooperación entre Desarrollo y Operaciones, dos partes del proceso de despliegue de software que a menudo están en conflicto.
Con características como la fiabilidad del producto, la innovación y la adopción de mayores niveles de responsabilidad, el Site Reliability Engineering propone una versión más madura del espacio de trabajo de IT, donde no existen conflictos entre los departamentos.
Echemos un vistazo a cómo se logra esto.
¿Qué es Site Reliability Engineering (SRE)?
El Site Reliability Engineering (SRE) fue introducido por primera vez en 2003 por el ingeniero de SRE de Google, Ben Treynor Sloss. Si se nos permite la licencia poética, podríamos imaginarlo como el padre fundador de la Ingeniería de Fiabilidad del Sitio. Cuando Google le encomendó la tarea de crear equipos más integrados, Treynor Sloss acuñó el término, así como un nuevo conjunto de principios operativos.
Para él, el Site Reliability Engineering es "lo que ocurre cuando a un ingeniero de software se le encarga lo que antes se llamaba operaciones".
Ahora, el SRE trata de arreglar un problema que suele ser muy común en las organizaciones: el siloing. Es decir, cuando los equipos trabajan sin tener en cuenta a los demás en sus propias áreas compartimentadas, sin saber qué hace el resto.
Por lo general, los equipos de Desarrollo quieren lanzar al público algunas nuevas características necesarias. Pero el equipo de Operaciones puede y debe asegurarse de que esas nuevas funcionalidades no destruyan la estructura del software.
Te puedes imaginar que esto suele dar lugar a algunas luchas de poder bastante shakesperianas. Y la consecuencia no deseada es un tira y afloja, con Ops haciendo de papá malo, y Devs buscando una ventana para lanzarse y evitar el toque de queda "totalmente injusto".
El Site Reliability Engineering elimina de un plumazo este molesto debate. Se acabaron las discusiones sobre qué se puede lanzar y cuándo. Para ello, el SRE da luz verde (o roja, suponemos) algorítmicamente a los proyectos según criterios preestablecidos.
Pero, ¿quiénes son los profesionales que supervisan esta magia? Echemos un vistazo al papel del ingeniero del SRE.
¿Qué hace un ingeniero de SRE?
El trabajo principal de un ingeniero del Site Reliability Engineering es asegurar de que un producto sea estable, fiable y fácil de iterar. Así que, como puedes imaginar, tienen que ser competentes en algo más que en la codificación. Además, deben contar con experiencia en operaciones. Los administradores de sistemas, o quienes estén a cargo de Operaciones de IT que tienen experiencia en desarrollo, también pueden desempeñar esta tarea.
Los equipos de SRE son responsables de gran parte de los servicios en producción:
- Implementación, configuración y monitoreo del código
- Respuesta de disponibilidad
- Latencia
- Gestión de cambios
- Respuesta a emergencias
- Gestión de la capacidad
En resumen, el Site Reliability Engineering ayuda a los equipos a determinar qué está listo para el lanzamiento y qué no, utilizando los SLA (Acuerdos de Nivel de Servicio) para predefinir la fiabilidad necesaria del sistema. A su vez, los ingenieros logran esto a través de los SLI (Service-Level Indicators o Indicadores de Nivel de Servicio) y los SLO (Service-Level Objectives u Objetivos de Nivel de Servicio).
Pero esto también ocurre a través de la "jerarquía de necesidades". Es hora de echar un vistazo a la pirámide del SRE.
Principios del SRE: la pirámide del Site Reliability Engineering
El Site Reliability Engineering gestiona procesos o sistemas en forma cuidada, es decir, debe estar atento a la salud de estos servicios, lo cual no es una tarea fácil. El monitoreo de los sistemas, la respuesta a los incidentes, la planificación de la capacidad y el análisis en profundidad de las interrupciones del servicio, entre otras cuestiones, pueden llevar mucho tiempo y requieren de manos y ojos expertos.
El SRE, como práctica diaria, implica la construcción de complejos sistemas distribuidos desde la base, y luego también un funcionamiento eficiente.
Entonces, ¿qué aspecto tiene un servicio "sano" o bien gestionado? Es un poco como la jerarquía de necesidades de Maslow:
"La jerarquía de necesidades de Maslow es una teoría motivacional en psicología que comprende un modelo de cinco niveles de necesidades humanas, a menudo representado como niveles jerárquicos dentro de una pirámide.
Desde la base de la jerarquía hacia arriba, las necesidades son: fisiológicas (comida y ropa), de seguridad (laboral), de amor y pertenencia (amistad), de estima y de autorrealización.
Las necesidades de la parte inferior de la jerarquía deben satisfacerse antes de que los individuos puedan atender las necesidades de la parte superior".
Y así es como funciona precisamente la pirámide del SRE: determinando qué servicios son necesarios (que están más abajo en la pirámide), y cuáles dependen de que se satisfagan esas necesidades.
Entonces, ¿qué viene primero y qué viene después en la pirámide de necesidades del Site Reliability Engineering? Echemos un vistazo.
1. Monitoreo
El monitoreo es la forma de evaluar si un servicio está funcionando como corresponde. Sin este paso, sólo confías en tu mirada y esperas voluntariamente hasta que algo se incendie. Más aún, quieres ser proactivo en lugar de reactivo; captar tus problemas antes de que lo hagan tus usuarios es parte de tu estrategia de supervivencia a largo plazo.
2. Respuesta a los incidentes
Hablamos mucho del soporte 24/7, pero es una afirmación un poco hiperbólica. Más bien, el soporte de guardia es una herramienta que debe desplegarse con cuidado y criterio. La idea es estar al tanto de cómo funcionan (o no funcionan) los sistemas informáticos distribuidos. La verdad es que nadie quiere estar conectado todo el año, pero así ocurre y forma parte de la vida de los ingenieros, porque las cosas se rompen todo el tiempo.
Pero ser consciente de un problema es sólo la primera parte, la más fácil. Luego llega el momento de intentar encontrar soluciones que se mantengan (y que no rompan nada más allá). Algunas soluciones son temporales y otras son arreglos más consistentes, pero seguro que los ingenieros del SRE utilizarán ambas para detener la sangría cuando suceda algo malo. La respuesta a incidentes es algo que todos los equipos deben hacer; y además hacerlo bien.
Así que, después de identificar cuál es el problema, podemos avanzar al siguiente paso.
3. Solución de problemas
Lo ideal es contar con soluciones que se puedan utilizar a largo plazo y que no causen más daños que beneficios. Esta reflexión es doblemente importante cuando se trata de una respuesta de emergencia, porque la solución de hoy puede ser la catástrofe de mañana.
Cuanto más pueda tu equipo desplegar una gestión eficaz de los incidentes para hacer frente a los problemas emergentes, mayores serán las posibilidades de éxito general. Además, eso tiende a poner un límite a la ansiedad de todos.
4. Incidentes post-mortem y análisis
Ahora es el momento de llegar al fondo de las cosas y averiguar qué es lo que realmente ha provocado todo este lío. Si no, te quedas atascado en tu propio bucle en el que el mismo problema se repite una y otra vez. Incluso si eso hace que tu equipo mejore exponencialmente en la resolución, no implica que igualmente estén dando vueltas en círculo.
Y esta es una parte integral de la cultura SRE: crear una cultura post-mortem sin culpa en la que se pueda examinar qué salió mal y trabajar para arreglar las causas de raíz antes de que vuelvan a aparecer como malas cicatrices en una película de terror.
En resumen, tú y tu equipo tendrán que aprender del fracaso. Y esto es un terreno privilegiado para las herramientas de automatización y los rastreadores.
5. Pruebas
Las pruebas llegan una vez que hemos entendido dónde están los problemas. Ahora, la idea es evitar que estos problemas aparezcan desde el principio. La prevención va a ser una alternativa mucho más segura (por no hablar de rentable) que atender las cuestiones después del hecho.
Aquí es donde las suites de prueba serán de gran ayuda. Deben probar tu software a fondo para comprobar si surgen ciertas clases de errores antes de pasarlo a producción. Así, estos testeos garantizan que el software es fiable antes de que vea la luz.
6. Planificación de la capacidad
El objetivo de la planificación de la capacidad (también conocida como gestión de la capacidad en ITIL) es asegurarse de que los recursos de IT son suficientes para satisfacer los próximos requerimientos de la empresa de forma rentable.
Aquí es donde se revisa cada detalle del proyecto para garantizar de que se cumplen los objetivos de manera ajustada, eficaz y eficiente, aprovechando los recursos monetarios y las asignaciones presupuestarias existentes.
7. Desarrollo
En Google, es muy frecuente ver que el enfoque del Site Reliability Engineering (SRE) adopta la forma de diseño de sistemas e ingeniería de software internos.
Esto se hace mediante una forma de consenso distribuido, que aumenta la fiabilidad.
En otras palabras, se logra un consenso de manera no centralizada al estar distribuido junto a los nodos de datos, lo que ayuda a perfilar un sistema capaz de escalar más allá de los centros de datos completos, aunque es más fácil decirlo que hacerlo.
Además, los desarrolladores pueden manejar alrededor del 5% de la carga de trabajo de las operaciones. Esto ocurre cuando hay un desborde en las operaciones, lo que lleva a los desarrolladores a manejar el resto. Esto también conduce a una mayor conexión con el producto en un estado de rendimiento del mundo real.
8. Producto
Es la etapa en la que -con suerte- hay un producto que está listo para la acción. La idea con el Site Reliability Engineering es que sea capaz de proporcionar a sus clientes un producto que funcione como se pretende desde el principio -y evitar los desperfectos que pueden ocurrir desde el día de lanzamiento, debiendo ser parcheado hasta que sea funcional-.
Puedes decir que "eso nunca nos pasaría a nosotros", pero parte de la razón por la que existe el SRE lugar es que muy pocas empresas pueden garantizar productos fiables en el lanzamiento, o más allá.
¿Por qué se necesita el Site Reliability Engineering (SRE)?
Si tuviéramos que resumir su importancia, los ingenieros del Site Reliability Engineering (SRE) deberán asegurar un software sin deficiencias durante su lanzamiento. También son responsables de mantener los sistemas y la observabilidad, al tiempo que aprovechan la automatización para que estos sistemas sean cada vez más eficientes.
A menudo, esto también significa ser los primeros en responder cuando algo va mal. Sin embargo, no lo hacen aislados de los demás, sino más bien en tándem con (y dentro de) los equipos individuales.
Otro punto importante de los SREs es su papel en generar un software más resistente. Y esta tarea no se puede delegar en un subcontratado, sino una característica que hay que diseñar e incorporar a los sistemas. El resultado de estas prácticas es que cuando algo va mal, no se produce una cascada de desperfectos en todo el sistema. Además es mucho más fácil limitar los daños.
Las 5 mejores prácticas del Site Reliability Engineering (SRE)
Si estás planeando implementar la ingeniería de fiabilidad de software en tu empresa, estas son algunas de las mejores prácticas de SRE que debes seguir:
- Crea presupuestos de errores: la cantidad máxima de errores que puedes acumular en tu sistema antes de que tus usuarios noten que algo está mal -Y que las cosas estén mal los hace infelices, algo que tu no quieres.
- Piensa como un usuario para definir los SLOs (Service Level Objectives): al hacerlo medirás la disponibilidad y el rendimiento pensando como un usuario, y no necesariamente desde la perspectiva de un desarrollador.
- Monitoreo de errores y disponibilidad: es necesario para garantizar que tu software funciona como debe ser. Además, tú te enterarás de cualquier cambio o problema antes que tus clientes, y eso es crucial.
- Asegúrate de no pasar por alto la gestión de cambios: estos pueden afectar a todo el sistema. De hecho, la mayoría de las interrupciones se producen cuando se introducen cambios en el acto. Por lo tanto, evalúa adecuadamente el impacto probable de un cambio antes de introducirlo. Si la relación costo/beneficio es correcta, no hay problema. Pero siempre debes observar el panorama general.
- Crea una cultura post-mortem libre de culpa: las situaciones caóticas ocurrirán, pero asegúrate de pensar positivamente en las personas involucradas. Todo el mundo trabaja al máximo de su capacidad e intenta evitar los accidentes a propósito. Si tienes un sistema sólido de resolución de incidentes y retrospectiva, puedes sacar el máximo provecho de los fallos. Y no es necesario acusar a alguien para conseguirlo.
Los 5 retos del SRE
Hemos cubierto los beneficios y las mejores prácticas. Ahora es el momento de echar un vistazo rápido a los cinco desafíos del SRE que pueden aparecer en tu camino.
- No hay suficiente participación de todos los equipos: tal vez haya reunido un gran equipo de SRE, pero no tienes suficientes ingenieros de fiabilidad del sitio. Esto puede ser un problema si tienes una organización grande, por lo que depende de ti mantener los flujos de comunicación.
- Tu proceso es demasiado grande para el tiempo de respuesta a incidentes: la respuesta a los problemas debe ser lo más sencilla posible, por lo que debes trabajar para reducir al mínimo los wikis y las listas de comprobación.
- Se aprende de los post-mortem: ya hemos mencionado que se puede aprender mucho de este tipo de reuniones. Si no lo haces, estás pidiendo que el mismo problema se repita una y otra vez.
- Es importante ser proactivo y no esperar a que se produzcan errores o interrupciones antes de disponer de un sistema para hacerles frente: las simulaciones permiten a los ingenieros estar más preparados cuando ocurren cosas reales, y lo agradecerán (y tú lo agradecerás a su vez).
- La gestión de incidentes sin SLOs no es suficiente: aunque puedes tener mucho éxito implementando el SRE, los SLOs son un bloque de construcción esencial, no un extra. Esto significa establecer un presupuesto de errores y, básicamente, un nivel aceptable en el que deben funcionar tus servicios. Establece SLOs realistas, rastreables y claros y obtendrás lo mejor del SRE.
Resumen
El Site Reliability Engineering puede parecer otra nueva palabra de moda en una larga lista de términos tecnológicos que pronto se olvidarán. Pero en realidad es una solución perfecta para muchos de tus problemas de desarrollo y operaciones.
Te recomendamos que lo estudies y empieces a llenar tus equipos con SRE competentes que te ayuden a alcanzar tus objetivos de la mejor manera y, lo que es más importante, con estabilidad, soporte y fiabilidad tras un lanzamiento.
Preguntas frecuentes
¿Qué significa SRE?
SRE es la sigla de Site Reliability Engineering (Ingeniería de Fiabilidad del Sitio), un conjunto de prácticas entre equipos que buscan que que el desarrollo de software esté menos aislado y sea más eficiente.
¿Qué hace un ingeniero SRE?
Un ingeniero de fiabilidad del sitio tiene la tarea de asegurar continuamente de que un producto es fiable. También debe mitigar y prevenir los problemas, además de ayudar a los equipos de desarrollo y de operaciones a estar en sintonía.
¿Cuál es el objetivo de un equipo de Site Reliability Engineering?
Priorizar los objetivos de fiabilidad mediante el uso de SLOs para medir el rendimiento del sistema o del sitio.
¿Cuál es la diferencia entre DevOps y SRE?
Ambos son enfoques fundamentalmente sinérgicos. Su principal diferencia podría ser que SRE es un conjunto de prácticas prescriptivas, mientras que DevOps es un marco general.
