Dar los primeros pasos en Site Reliability Engineering

14 mayo
Marcin Deryło
Dar los primeros pasos en Site Reliability Engineering
Si pensamos en cómo se ha creado e implementado tradicionalmente el software, hay dos lados: el equipo de desarrollo (redacción de código y pruebas) y el equipo de operaciones (responsable de mantener todo funcionando de manera estable). Al equipo de operaciones no le gustan los cambios, a diferencia del equipo de desarrollo, por lo que existe una brecha entre los dos. Este conflicto crea formas subóptimas de crear e implementar software en producción.

Solución: Site Reliability Engineering

En 2003, la gente de Google decidió probar algo diferente como solución a este problema. Crearon el llamado "equipo de producción" incluyendo a 7 personas responsables del diseño de las operaciones. Su enfoque ha evolucionado a lo largo de los años, pero en el fondo, siguen haciendo lo mismo, capacitando a muchos nuevos ingenieros de confiabilidad del sitio cada mes. Al contrario de lo que uno pueda pensar, el objetivo de un equipo de SRE no es solo el soporte sino también la ingeniería, es decir, buscan mejoras de manera proactiva en lugar de solo reaccionar a los problemas que están sucediendo. Por lo tanto, brinda la oportunidad de introducir una escala sublineal del equipo de operaciones junto con la escala del servicio porque las SRE buscan el cambio en lugar de preservar el status quo. Además, los SRE son desarrolladores de software, por lo que no solo pueden cambiar la infraestructura alrededor de la aplicación, sino también el código de la aplicación en sí, ya que tienen las mismas habilidades de codificación que el equipo de desarrollo.

¿Qué es la confiabilidad?

La confiabilidad es un concepto difuso: puede significar varias cosas, según el sistema que esté construyendo. Si estás creando una solución de base de datos, la durabilidad de los datos puede ser un concepto crucial. Si estás trabajando en un servicio de transacciones en línea, la latencia y la disponibilidad de tu servicio serán sus aspectos clave. Por lo tanto, la confiabilidad puede tener diferentes significados dependiendo del contexto.

Como se supone que los SRE mantienen la confiabilidad de un sistema y lo mejoran, necesitan algún tipo de medición que les muestre si están haciendo un buen trabajo o no. Y llega algo llamado Indicadores de nivel de servicio (Service Level Indicators): mediciones de cosas identificadas como vitales para el negocio. La tarea de un equipo de SRE es proporcionar formas de medirlos, lo que nos permitirá mostrar el estado actual del sistema. Cuando se definen, se deben configurar los valores objetivo para estas mediciones.

Los Service Level Objectives destacan las cosas que son importantes para las empresas y los usuarios; ayudan a establecer expectativas a nivel de software. Los SLO le permiten hacer suposiciones sobre qué tan confiable es tu servicio. No tenes que lograrlo desde el 1er día, simplemente podes ajustarlos a medida que avanza, cuando veas cómo se comporta el servicio.

Por ejemplo, digamos que queremos que las solicitudes de nuestro servicio se procesen en 50 milisegundos, el 99% del tiempo. Deben permitirse algunas infracciones de los números objetivo: el 100% de SLO no es realista. No tenes que esperar tal confiabilidad del servicio, porque significaría que nada cambia. Además, no se puede controlar todo, hay cosas como las redes que no se pueden controlar, por lo que pensar que se puede lograr ese objetivo simplemente no es posible.

Además, cuanto más te acerques al 100% en tus SLO, más caro será mejorar tus métricas. La alta fiabilidad no es gratuita. Nuevamente, los SLO del 100% significan que nada puede cambia, lo que significa que no hay innovación. La clave es seguir siendo lo suficientemente confiable pero permitir el cambio. Necesitamos un espacio para "romper cosas". Eso se denomina presupuesto de error (100%, lo que sea que tenga en sus SLO). A medida que se lanzan nuevas versiones del software, podrás ver el presupuesto de error restante, controlar la rapidez con que lo consume y tomar algunas decisiones basadas en eso. Si utilizas demasiado presupuesto de error, ¿quizás debería reducir la velocidad? ¿O considerar hacer más pruebas en el lanzamiento? Este presupuesto de error debe ser visible para todos: desarrolladores, SRE y operaciones comerciales. Debería servirles como un mecanismo de equilibrio natural entre las innovaciones y la estabilidad de las cosas y reducir la fricción entre los equipos de desarrollo (que introducen cambios) y los SRE (que mantienen la estabilidad de los sistemas).

 

Los principios de la SRE

Ahora, echemos un vistazo a las ideas fundamentales de SRE y las cosas que el equipo está haciendo a diario.

Primero, SRE no se trata de soporte, tiene un fuerte enfoque en la ingeniería. Los SRE son desarrolladores de software: tienen habilidades de codificación, pueden cambiar scripts, código de aplicación, pueden automatizar cosas, etc. Por supuesto, todavía hay algunas partes que aún no están automatizadas o son demasiado caras para automatizarlas y es difícil justificar tales inversiones. Así que hay cosas que se hacen manualmente una y otra vez y son repetitivas. A esas cosas las llamamos "toil", Ej. lanzamientos, búsqueda de scripts: todo lo que necesita el juicio humano, pero no resulta en una mejora permanente. Otras cosas que se consideran toil son las reacciones a incidentes, las liberaciones, el tratamiento de algunos problemas no urgentes con la producción, etc. Si tene demasiado toil se vuelve peligroso. Podría tener un efecto negativo en las personas, p. Ej. pueden aburrirse por la repetitividad de las tareas. ¿Cómo abordar este problema? Necesitamos limitar el toil de manera agresiva: el límite de trabajo de Google está establecido en el 50%. Por supuesto, habrá días en los que tendrá mucho toil y días en los que podrá concentrarse estrictamente en la ingeniería. Pero, ¿qué deberías hacer si tenes demasiado toil? Necesitas decirle a alguien en voz alta, p. Ej. tu gerente, al respecto. Tal vez insista en hacer crecer su equipo de SRE para repartir la carga entre varias personas o, trasladar la responsabilidad al equipo de desarrollo. Básicamente, la responsabilidad de SRE es limitar el toil a largo plazo también. Lo que hace un SRE es ingeniería. Esto llevará a mejoras permanentes, introducir innovaciones y mejorar el rendimiento y la estabilidad de los sistemas.

El trabajo de ingeniería que realizan los SRE es de dos tipos. En primer lugar, la ingeniería de software (escribir código, cambiar código, diseñar cosas, probar cosas), pero no es la misma ingeniería de software que hace el equipo de desarrollo, el enfoque es diferente aquí: automatización, creación de herramientas y marcos, tener algunas características para mejorar escalabilidad, rendimiento y confiabilidad, creando una infraestructura sólida para que la utilicen los desarrolladores. La otra cosa es la ingeniería de sistemas: configuración de los servicios de producción (parámetros de JVM, creación de documentación valiosa, configuración y mantenimiento de sistemas) y trabajo con el equipo de desarrollo (para saber qué funciona y qué no funciona en el sistema).

Permítanme decirlo nuevamente: SRE no se trata de soporte, se trata de cambiar las cosas lo más rápido posible, lo que significa sin violar los SLO acordados, permanecer dentro de los límites del presupuesto de error. De hecho, existen riesgos en no gastar el presupuesto de error. Hay una historia interesante en uno de los libros escritos por las SRE de Google. Se trata de un servicio de cierre distribuido que tenían. Era realmente estable, sólido como una roca, tan sólido que muchos otros servicios comenzaron a confiar en él porque siempre funcionaba. Sin embargo, cuando sucedió un evento inesperado, este sistema falló con todo lo demás. No tenía por qué suceder porque muchas de esas dependencias eran excesivas, no eran realmente estrictamente necesarias, pero seguían ahí. El equipo detrás de este sistema ha publicado sus SLO para que todos los vean y establecer sus expectativas. Para evitar que las personas creyeran que su servicio era más confiable de lo que anunciaban sus SLO, comenzaron a desencadenar interrupciones artificiales en la producción a propósito, para agotar su presupuesto de errores. La moraleja de la historia es que no debemos rehuir al uso de nuestros presupuestos de error: ¡está para gastarlo! No tiene sentido salvarlo.

 

El siguiente pilar de la SRE es el seguimiento. Hay formas de supervisar la salud del sistema. Hay múltiples elementos en el sistema de monitoreo: alertas, tickets (como Jira u otros sistemas), registros.

En algún momento, las cosas saldrán mal, por lo que una respuesta de emergencia también es algo que hacen los SRE. No hay forma de que un SRE evite el servicio de guardia. También deberíamos tratar de tener la menor necesidad de respuestas de emergencia como sea posible, porque dependemos de las personas y las personas tienen una latencia terrible. No pueden resolver problemas tan rápido como lo hace el software. Otra parte de la respuesta de emergencia es tener que ejecutar libros para un ingeniero de guardia, por lo que, si lo despiertan en medio de la noche, tendrá una lista de pasos a seguir. Y, por supuesto, realizar autopsias después de haber solucionado o mitigado un problema. También necesitamos fomentar la confianza en sí mismos en las personas responsables de la respuesta de emergencia. Lo bueno es capacitarlos: una forma de hacerlo es el juego de roles (por ejemplo, a través de los ejercicios de Wheel of Misfortune), que se usa en Google. De esta forma, la gente no tiene miedo cuando suena el teléfono y la alerta está activada.

SRE también se trata de la gestión del cambio. Pero aquí no significa asegurarnos de que nunca romperemos nada cuando hacemos un cambio, se trata más de poder mitigar los efectos negativos de los cambios rápidamente. Hay algunas técnicas que se pueden emplear, por ejemplo, despliegues progresivos que nos permiten detectar un problema rápidamente y retroceder rápidamente al último estado bueno conocido. Estos procesos deben automatizarse, ya que los ingenieros pueden aburrirse y perder la atención al ejecutarlos manualmente, lo que puede provocar problemas con más frecuencia.

Lo fundamental cuando queremos escalar nuestro sistema a medida que aumenta la demanda, es pronosticar esta demanda y planificar la capacidad en consecuencia. Hay que recordar que el sistema no solo tendrá un crecimiento orgánico (más registros de usuarios), también habrá ocasiones en las que alguien publique un comentario en Reddit de que realmente le gusta su servicio y ... ¿adivinen qué? Cada vez más personas se registrarán repentinamente y tendrás que ser capaz de manejar esos picos también. Para saber cuánta capacidad tiene, debe ejecutar pruebas de carga de forma regular. Si haces esto, podrás aprovisionar nuevos recursos. Una cosa que aprendí en la conferencia de la SRE en Dublín este año: Google realiza ejercicios de planificación de capacidad durante las entrevistas de la SRE; te dan la tarea de diseñar un sistema (por ejemplo, servicio para compartir fotos); te dicen cuántos usuarios se registrarán, cuántas fotos se cargarán diariamente, etc. y te piden que proporciones números concretos (cuántas máquinas necesitas, cuánto espacio en disco necesitas, etc.). Organizaron un taller como este durante la conferencia y fue una experiencia excelente y valiosa.

La capacidad es una cosa. Otra cosa que está fuera de nuestro control es la demanda. Estos dos indican cuál será el uso de recursos. La tercera parte es la eficiencia con la que está utilizando los recursos. Los SRE pueden cambiar el código de la aplicación; si ven que la aplicación hace algo de manera ineficiente, pueden cambiarlo. No esperarán hasta que el equipo de desarrollo resuelva el problema. La forma en que uno usa los recursos también tiene que ver con el costo: si los usan de manera ineficiente, generan más costos para la empresa de los que realmente se necesitan. Cuando las SRE brindan servicios, deben tener en cuenta la eficiencia para alcanzar los niveles de desempeño esperados por la empresa.

Algunos consejos y trucos

Resulta que no hay muchas cosas que pueda hacer para mejorar la confiabilidad. Básicamente, puede intercambiar cosas para ser más confiable:

  • dinero: introducí más dinero en el sistema para tener más recursos redundantes o servidores más grandes,
  • calidad: renunciá a algo de calidad por una mejor confiabilidad: resultados degradados, interruptores automáticos que tendrán respuestas de respaldo cuando se disparen, por lo que no obtendrá la funcionalidad completa, pero seguirá funcionando en lugar de apagarse de inmediato,
  • latencia (reintentos, retroceso exponencial y fluctuación), entonces estarás cambiando tiempo por confiabilidad.

Todas estas son técnicas valiosas. Solo recuerda que cada vez que haces esas cosas, aumenta la complejidad general de una aplicación o de un sistema completo.