Comencemos definiendo que SRE es el acrónimo de Software (o Site, dependiendo del contexto) Reliability Engineer. Considerando esto, pueden existir muchas acepciones diferentes de lo que ser un SRE significa; de hecho, en muchos lados verás definiciones diferentes que pasan más que nada por la visión del autor, pero la fuente de verdad siempre es la definición de sus creadores: Google.
“SRE es lo que tienes cuando tratas las operaciones como si fueran un problema de software. Nuestra misión es proteger, proveer y evolucionar el software y los sistemas detrás de los servicios públicos de Google con un ojo siempre vigilante en su disponibilidad, latencia, performance y capacidad.”
El objetivo principal es tener el up-time de las aplicaciones lo más alto posible, lo cual consiste en buscar la resiliencia de nuestras aplicaciones para que su disponibilidad sea la más alta posible. Técnicamente no podemos tenerla al 100% porque siempre hay factores externos que pueden influir, por ejemplo un corte de luz, pero sí podemos tener el 99,9 %.
Es simple: transformamos el porcentaje en tiempo. Consideremos que el mes tiene 30 días, es decir, 720 horas o 43200 minutos; podemos decir que el 0,01% es igual a 4,32 minutos. Por lo tanto, el tope de Down-time que podemos admitir son 4,32 minutos mensualmente, tiempo permitido que podemos perder, o en conceptos de SRE: error budget.
Toda esta información es variable según los objetivos de la organización, puedes revisar availability table aquí.
Ser SRE implica obtener métricas (Service Level Indicators), extrapolar los datos a largo plazo para proyectar y definir objetivos con el cliente (Service Level Objective), y finalmente realizar los planes de acción y acuerdos de negocio en base a las metas (Service Level Agreements).
Un ejemplo interesante para entender qué medir para considerar el up-time es el siguiente: si tuviésemos una aplicación de venta por Internet, podríamos considerar que el uptime está dado por que la página esté arriba, y obtener un indicador de eso. Pero si por algún motivo el carro de compras no funciona, entonces nuestra aplicación está muerta. Los indicadores deben ser relevantes para definir el servicio.
Aquí la relevancia del trabajo diario del SRE es estar constantemente viendo los procesos generales de los equipos de trabajo para mejorarlos, automatizar lo que sea automatizable, llevar un control del error budget... En caso de que los tiempos se consuman, el SRE tiene la jerarquía de hacer freeze a los deployments, que de por sí tienen mucho riesgo de Down-time, y evangelizar al universo.
Es sumamente importante entender que, en un mundo ideal, SRE deja de existir como rol y se aplica como filosofía en nuestro trabajo diario, y es transversal al área o al rol. Quizás puede sonar complejo todo esto al mismo tiempo, pero tiene un mundo bastante interesante respecto lo técnico.
Por lo tanto, se entiende que SRE es más que monitoreo, tiene todo lo que es DevOps con una visión proactiva, no se limita a simplemente hacer lo necesario, sino que hace lo necesario para después no tener que hacer más. Es mejor invertir 5 horas de trabajo automatizando un proceso, que estar repitiendo un trabajo manual de una hora al mes todos los meses. Como dice Google: “Class SRE implements DevOps”.
