Bueno, ha llegado el día en el que publico un resumen (muy básico y que seguramente iré actualizando) de lo que entiendo es un SRE y sus funciones básicas. Allá vamos.
¿Qué es un SRE?
Hay muchas definiciones de lo que es un SRE, pero me quedo con ésta de Microsoft:
Site Reliability Engineering is an engineering discipline devoted to helping an organization achieve the appropriate level of reliability in their systems, services, and products.
Y que complemento con esta frase sacada del libro de SRE de Google:
In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).
¿En qué se diferencia un SRE de un DevOps?
La gran pregunta (más alla del focus en la fiablidad de producción del SRE). La verdad es que DevOps y SREs tienen mucho en común.
DevOps es la cultura que pretende romper los silos que ha habido tradicionalmente en los departamentos de desarrollo, operaciones, redes y seguridad. Su mantra es «Cultura, Automatización, Lean (Continuous Delivery), Medición y Colaboración».
SRE es un puesto de trabajo que vendría a implementar algunos de los conceptos de la filosofía DevOps. Sus principios son:
- Usar estrategias de ingeniería del software para solucionar problemas de operaciones
- Trabajar en base a SLOs (Objetivos de nivel de servicio)
- Minimizar las arduas tareas manuales de operaciones (automatizar)
- Mejorar el descubrimiento temprano de problemas y reducir el tiempo de resolución de problemas (MTTR)
- Compartir el ownership de la aplicación junto a los developers
- Usar las mismas herramientas en todos los equipos
Fuente: The Site Reliability Workbook
¿Qué hace un SRE?
Los SRE son responsables de la salud de los sistemas y para contar con sistemas saludables, según Google, se necesitan los siguiente elementos:
- Monitorización: un sistema de monitorización de la infraestructura diseñado con tiempo y cabeza.
- Respuesta a incidencias: guardias, troubleshooting efectivo, y mitigación de la incidencia (que no tiene por qué ser la recuperación total del servicio durante la guardia).
- Post-mortem y análisis de la causa de la incidencia: blameless postmortem, y tracking de las incidencias en producción recientes (causas y acciones que se tomaron como respuesta).
- Testing
- Capacity planning: construir y asegurar que contamos con un entorno adecuado a nuestras necesidades.
- Desarrollo: participación de las decisiones de diseño de los sistemas y escritura de código. Sistemas distribuidos, pipelines de procesamiento de datos e integridad de los datos.
- Producto: cómo lanzar releases de los productos ofreciéndo a los clientes la mejor experiencia posible.
Un SRE no puede estar toda su jornada apagando fuegos, respondiendo a pager duties o procesando la cola de tickets. Idealmente, un 50% del tiempo un SRE debería estar escribiendo código, automatizando tareas o trabajando en proyectos que hagan más eficientes los servicios.
Fuentes:
https://docs.microsoft.com/en-us/learn/modules/intro-to-site-reliability-engineering/
https://landing.google.com/sre/sre-book/
WinOps 2018: How LinkedIn built a world-class SRE capability