Site Reliability Engineering (SRE): principios

He querido resumir en un post, los principios que se explican en el libro «Site Reliability Engineer» de Google (gratis y online).

CAPITULO 1 & 2 – INTRO

Además de programar, a un SRE se le pide conocimientos avanzados de cómo funciona el sistema UNIX a nivel interno, y de networking (capas de la 1 a la 3)

La clave está en dedicar al menos un 50% del tiempo en automatizar las tareas de operaciones o a hacer tareas de ingeniería (mejorar la fiabilidad, el performance, etc.). De esta manera, evitas tener un equipo que crezca a la vez que crece la infraestructura (y por tanto, las tareas de operaciones si no estuvieran automatizadas).

También es clave dedicarle tiempo a los postmortem para aquellos incidentes relevantes. En caso contrario, no se estará aprovechando la oportunidad de mejorar nuestros sistemas.

El concepto de «error budget» es (1 – disponibilidad_acordada). Si se establece 99.99% de disponibilidad acordada, el error budget será de 0.01%. Este error budget se podrá usar para lo que se quiera, pero típicamente se usará para tomar riesgos deployando nuevas funcionalidades lo antes posible.

Aprox un 70% de las caídas son debidas a cambios en producción. Los SREs deben aplicar best practices para automatizar completamente los cambios (progresivos) en producción así como el rollback.

Las alertas del sistema de monitorización deberían interpretarse y solucionarse de forma automática, y a partir de ahí, únicamente deberían notificar a un humano cuando éstos necesiten tomar parte.

CAPITULO 3 – EMBRACING RISK

Cuando tienes un sistema distribuido, una métrica temporal (uptime) para medir la disponibilidad puede no ser la adecuada pues es probable que el sistema esté siempre, al menos parcialmente funcionando. Google en su lugar usa «requests success rate» (requests exitosas/total de requests). Los SREs deberían trabajar con los Product Owners (o los developers a falta de éstos) para trasladar las metas del negocio en objetivos explícitos.

Cuando los SLO se incumplen sistemáticamente hasta agotar el error budget, las releases se paran temporalmente para invertir recursos adicionales en testing y desarrollo, con el objeto de hacer al sistema más robusto. Cuando el error budged está casi lleno, los desarrolladores pueden querer tomar más riesgos. Al contrario, cuando está casi vacío, las releases se pueden espaciar o se puede querer poner más enfasis en el testing.

CAPITULO 4  – SLOs

SLI (Indicadores): muestran valores concretos del sistema que estamos midiendo. Ej. latencia de la request, error rate, etc.

SLO (Objetivo): el valor o rango de valores que queremos ver en nuestros SLI. Escoger y publicar los SLO a los usuarios evitará que éstos se hagan una idea equivocada de cómo funciona o rinde el sistema.

SLA (Agreement): el contrato que define las consecuencias de cumplir (o no) con los SLO. Los SRE normalmente no se involucran en la definición de los SLAs.

Es mejor escoger menos indicadores, pero que realmente importen. En general escogeremos indicadores internos, pero no hay que olvidar los del lado del cliente.

• User-facing: disponibilidad, latencia y throughtput
• Storage: latencia, disponibilidad y durabilidad (pérdida de los datos almacenados)
• En general: que el sistema devuelva la respuesta correcta

Por simplicidad, se tiende a agregar los resultados de estas mediciones, y se prefiere usar percentiles que la media en las diversas muestras.

Respecto a los objetivos, hay que empezar definiendo aquellos que le importen al cliente, y al final, tener tan pocos SLO como sea posible.

Al final, se monitorizarán y medirán los SLIs y se intentará que cumplan los SLO. En caso contrario, se deberá tomar parte.

Se pueden publicar SLOs ligeramente más pesimistas que los que hemos definido, para que los clientes sepan qué esperar del sistema, pero dándonos un pequeño margen para actuar. El sistema no debe performar mucho mejor que los SLOs definidos, pues creará costumbre y restará importancia a los SLO.

CAPITULO 5 – ELIMINATING TOIL

Los SREs deberían trabajar por lo menos un 50% del tiempo en proyectos de ingeniería de largo plazo (de ahí la palabra Engineering del título), en lugar de en «toil».

Un SRE debería ocupar su tiempo trabajando en:

• Software Eng: automation scripts, creación de tools/frameworks, añadir funcionalidades en los servicios para mejorar el escalado/fiabilidad o hacer más robusto el código de la IAC.
• Systems Eng: updates en las monitorizaciones, configuraciones de servidores, OS tuning, etc. Los SREs deberían trabajar conjuntamente con arquitectura.
• Toil: tareas de operationes manuales, repetitivas, automatizables, tácticas, que no ofrecen valor y/o que escalan con el crecimiento del sistema.
• Extra: ayuda en el proceso de hiring, meetings, limpieza de la cola de bugs, peer review, training, etc.

CAPITULO 6 – MONITORING

• El monitoring es una pieza clave. En los equipos de 10-12 SRE de Google, suele haber 1 o 2 completamente dedicados.
• El sistema de monitorización se ha de diseñar pensando en hacerlo lo más simple posible
• En lugar de enviar alertas vía mail, se debe poner el foco en crear dashboards que muestren los problemas críticos actuales.
• Todos los «pagers» (alarmas de guardia) deberían implicar urgencia y requerir inteligencia, pues deberían ser siempre sobre problemas nuevos. Si el «pager» se soluciona haciendo una tarea repetitiva, no debería ser un «pager».

Los cuatro métricas de oro:

• Latencia: cuánto tiempo tarda en servirse una request. También interesa la latencia de las request fallidas
• Tráfico: HTTP requests por segundo, transacciones por segundo, etc.
• Errores: explícitos (ej. HTTP 500), implícitos (ej. HTTP 200 con contenido erróneo) o por política (i.e. si nos hemos comprometido a servir peticiones en menos de 1 segundo, serán errores por política aquellas que tarden más)
• Saturación: con foco en los recursos más limitados (RAM, i/o, etc.). Es importante definir límites, pues normalmente el 100% de saturación es demasiado tarde.

CAPÍTULO 7 – AUTOMATIZACIÓN

Añadiendo automatización externa al sistema, corremos el riesgo de que ésta quede obsoleta o inservible si se introducen cambios al sistema sin actualizar convenientemente la automatización externa. En un mundo ideal un sistema no necesitaría automatizción externa, pues la propia aplicación se encargaría de gestionar todos los casos (ej. una base de datos que automáticamente se recupera sola al sufrir un problema).

Vale la pena tener en cuenta las buenas prácticas habituales de la ingeniería de software (sub-sistemas desacoplados, APIs,  minimizar efectos secundarios, etc.) de cara a conseguir grandes sistemas que operen de forma autónoma.

CAPÍTULO 8 – RELEASE ENGINEERING

Google tiene su propio equipo de Release Engineers, los cuales trabajan en:

• Aplicar best-practices y ofrecer herramientas para que los propios equipos de sean auto-suficientes, y tengan total libertad sobre cuando subir nuevos cambios.
• Mejorar la velocidad de despliegue. Desplegar frecuentemente tiene menos riesgos.
• Asegurar la consistencia y repetibilidad de los builds.
• Imponer ciertas políticas de control, como requerir reviewers para los cambios en el código. El proceso de release automatizado de Google genera un informe con los cambios que incluye la release, muy últi para los SREs de cara al troubleshooting.

Uno de los objetivos es que ni developers ni SREs tengan que preocuparse del proceso de release.

CAPÍTULO 9 – SIMPLICIDAD

Los equipos de SREs deberían:

• Tirar para atrás cambios en el código que añadan complejidad accidental (no propia del problema que se quiere resolver)
• Luchar para eliminar complejidad opcional u obsoleta. No tiene sentido mantener código que ya no se usa, ni si quiera «por si» se quisiera usar más adelante, si se usa un sistema de control de versiones.