¿Qué es?
SRE son las siglas de Site Reliability Engineering, o lo que es lo mismo, Ingeniería de Confiabilidad del Sitio.
El concepto de SRE fue creado en 2003 por Ben Treynor, trabajador de Google y según sus propias palabras, SRE es “lo que sucede cuando un ingeniero de software se encarga de las tareas de operaciones”.
Los equipos de SRE basan sus esfuerzos en utilizar software (código) para resolver problemas, mejorar los sistemas/servicios/aplicaciones en producción y automatizar el mayor número de tareas manuales.
El fin de los equipos SRE es mejorar el ciclo de entrega continua de un producto, colaborando con los equipos de desarrollo para que entiendan y apliquen los procesos de operaciones, a lo largo de todo el ciclo de vida de desarrollo de una aplicación. Todo ello, con el objetivo de que cualquier aplicación o servicio desarrollado, sea altamente confiable y escalable.
Seguramente, esto te sonará familiar y te estarás preguntando ¿SRE es lo mismo que DevOps? La respuesta es no. Para empezar, el concepto de SRE nació antes que la filosofía DevOps. Esto no quiere decir que no compartan muchas ideas y que pretendan cubrir objetivos similares, pero plantean cuestiones diferentes:
- DevOps se plantea el qué hay que hacer para cerrar la brecha entre desarrollo y Operaciones.
- SRE se plantea el cómo hay que hacer las cosas para cerrar la brecha entre desarrollo y Operaciones.
Desde Kiteris, nos gusta explicar SRE como un framework de DevOps, por ello, utilizamos como símil lo que supone el framework de SCRUM respecto a la aplicación de los principios de Agile.
Los pilares de SRE.
Como hemos comentado anteriormente, SRE busca dar respuesta al cómo hay que hacer las cosas. Por ello, SRE define unos pilares fundamentales que intentan ofrecer respuesta a esta cuestión.
Reducir los silos de la organización.
Para conseguir este objetivo, SRE impulsa la distribución de la propiedad y responsabilidad del trabajo entre todos los equipos de la compañía. Con ello, pretende que los equipos se sientan con ownership del proyecto y de esta manera, vean todas las tareas como un conjunto indivisible para alcanzar el éxito. Esto evita las típicas situaciones de “esto no es mío”, “lo mío ya está hecho” o “esto no está en mi tejado”.
Se aceptan los fallos como algo normal.
Se parte de la premisa de que las cosas fallan y más cuando hay intervención humana de por medio. Por ello, los equipos SRE dedican gran parte de su tiempo a resolver problemas críticos y a mejorar los sistemas para que sean altamente tolerables a fallos.
Para conseguir este objetivo, los equipos de SRE trabajan sobre tres enfoques diferenciados.
- Anticipar problemas antes de que sucedan. Por regla general, se suele producir una degradación gradual en los sistemas antes de que suceda un problema que conlleve una pérdida de servicio.
- Runbook y postmortem. Todos los equipos SRE generan documentación de las operativas más frecuentes y analizan detalladamente incidencias que sean repetitivas o hayan ocasionado problemas de inestabilidad a los sistemas. La documentación es clave para disponer de un conocimiento distribuido y mejorar los tiempos de resolución de incidentes.
- Automatizar. Los equipos SRE trabajan en automatizar la resolución de problemas lo máximo posible, sin que eso suponga un impacto al usuario. Esto consigue reducir considerablemente los tiempos medios de resolución y también, suponen minimizar las situaciones que conllevan un alto estrés a los equipos técnicos.
Cambios graduales.
Como ya sabes, SRE nació en las entrañas de Google. Como cualquier empresa vanguardista, una de sus principales necesidades de negocio es realizar lanzamientos y mejoras muy frecuentes de sus productos. SRE abraza el cambio y la mejora continua, pero siempre aportando el grado de calidad y escalabilidad necesario, para que un producto sea lo más confiable posible.
Los equipos de SRE ayudarán a los equipos de desarrollo a implementar estas buenas prácticas y entender la necesidad de aplicar los procesos de operaciones necesarios para cumplir este objetivo.
De igual forma, en Kiteris vemos a los equipos SRE como una posible evolución de los equipos AMS, añadiéndoles conocimiento DevOps y enfocados principalmente a las aplicaciones críticas y en entornos 24×7.
Automatización.
Hemos comentado que las cosas fallan y más cuando hay una intervención humana. Por ello, SRE pretende automatizar el máximo número de tareas manuales posibles, con el objetivo de ofrecer valor a los equipos de desarrollo y operaciones. Ante una menor intervención humana, una mayor confiabilidad del sistema.
Medir, medir y medir…
Para que un equipo de SRE pueda saber si las cosas marchan bien, necesitan disponer de las herramientas necesarias para saber qué está sucediendo y qué va a suceder en sus sistemas. Esto se puede conseguir mediante la configuración de alertas de monitorización, implementación de un ciclo de pruebas completo antes de cada entrega o code reviews que garanticen las buenas prácticas en el desarrollo. También, para ayudar a poder anticipar problemas, SRE incluye el concepto de Observabilidad que veremos con un mayor detalle más adelante.
De igual manera, como ya hemos comentado repetidamente, SRE se centra en otorgar la máxima confiabilidad posible. Para ello, es imprescindible definir una serie de niveles de servicio que permitan medir esta característica. SRE define tres tipos de Service Level diferenciados:
- SLA (acuerdo de nivel de servicio). Es el más conocido y suelen conllevar una serie de consecuencias contractuales en caso de su cumplimiento o no cumplimiento.
- SLO (objetivo de nivel de servicio). Este nivel es el más importante para cualquier organización que quiera implementar SRE, ya que define el objetivo de disponibilidad óptimo para garantizar la satisfacción del cliente/usuario. Son indicadores que se basan en aspecto más específicos que los SLA’s, como por ejemplo el tiempo de respuesta total de un proceso de alta de usuario en una página web.
- SLI (indicador de nivel de servicio). Los SLI’s son indicadores que forman parte de un SLO y servirán a los equipos de SRE para centrar sus esfuerzos en corregir métricas determinadas que ayuden a conseguir alcanzar los SLO’s prometidos. Por lo tanto, un SLI puede ser la latencia que presenta una determinada consulta dentro de un formulario que rellena un usuario en un proceso de alta de usuario de una página web.
Recomendamos la lectura de los libros creados por Google, en los cuales se detallan y se ponen ejemplos de las prácticas comentadas.
