La Ingeniería de Fiabilidad del Sitio o Site Reliability Engineering (SRE) es un conjunto de prácticas interdisciplinarias ampliamente utilizadas que ayudan a aumentar la eficiencia del desarrollo de software. Pero, además de eso, su propósito es crear sistemas escalables, conectados, fiables y comunicados que proporcionen resultados mejorados y más fiables.
La SRE genera organizaciones más conectadas y eficientes que pueden construir software resistente, iterable y escalable. Para hacer esto, los ingenieros de SRE acuden a su experiencia en codificación.
Con el objetivo de ayudar en esta cuestión, Google desarrolló una lista de métricas. Se trata de las señales de oro de SRE, que revisaremos a continuación para conocer cómo pueden colaborar para tener éxito en el tema.
La importancia de las métricas de SRE
Las señales de oro de SRE se volvieron populares porque Google publicó un libro exhaustivo sobre Site Reliability Engineering. Además, otros gigantes de la tecnología siguen debatiendo sobre el tema. Por lo tanto, te invitamos a conocer más sobre esta iniciativa si deseas que tu sistema sea cada vez mejor a medida que se amplía, es decir, que resulte rápido y fiable.
Con sólo tomarte el tiempo necesario para identificar los problemas de fiabilidad y trabajar en equipo teniendo en cuenta esto, es muy probable que hayas conseguido integrar tanto la fiabilidad como las pruebas en una fase más temprana del proceso de desarrollo de software.
Considerando que estas señales son mucho más difíciles de rastrear que la velocidad del CPU o el rendimiento de la memoria RAM, es fundamental acudir a algo extra para medir cada servicio con eficacia. Incluso cada uno tiene diferentes definiciones, métricas y herramientas asociadas.
Además, los elementos como los contenedores, los microservicios y la tecnología sin servidor pueden dificultar aún más la obtención de señales. Pero dado que estas son tan importantes, tendrás que desviarte un poco de tu camino. Principalmente porque te ayudarán a solucionar problemas de tus sistemas distribuidos de manera efectiva y evitarás el ruido de alerta tradicional.
Veamos los tres métodos que colaborarán con el rastreo de estas importantes métricas de SRE.
El método USE
USE es un método de monitoreo relacionado con el hardware, que significa lo siguiente:
- Utilización: porcentaje de tiempo que un recurso está activo.
- Saturación: cantidad de "esfuerzo" que debe realizar un recurso determinado (a menudo, la longitud de la fila).
- Errores: cuántos eventos de error se producen en un momento dado.
RED
RED es un método de monitoreo relacionado con los servicios, y proviene de:
- Rate o Tasa: número de soloicitudes por segundo.
- Errores: número de solicitudes fallidas.
- Duración: cuánto tardan esas solicitudes.
Las señales de oro de SRE
Ahora, por fin llegamos a las tan elogiadas señales de oro de SRE. Se trata de métricas relacionadas con Kubernetes. Son las siguientes:
- Latencia: tiempo necesario para satisfacer una petición.
- Tráfico: nivel de demanda del sistema.
- Errores: tasa de solicitudes que resultan fallidas.
- Saturación: cuán sobrecargado está tu sistema.
Profundicemos en estas señales.
Las cuatro señales de oro de SRE
Ya definimos las señales de oro de SRE. Ahora profundizaremos qué hacen y cómo medirlas con precisión.
Latencia
La latencia es el tiempo que transcurre entre que se solicita un servicio y el instante en el que finalmente se obtiene. También se conoce como tiempo de respuesta. Medir tanto la latencia como la latencia entre servicios es crucial. Para ello, deberás establecer una línea de base: si no puedes cumplir con ella significa que hay una degradación de la aplicación.
Otra cuestión para recordar es que las medias pueden ser engañosas, así que utiliza histogramas. De esta forma, implementarás valores basados en umbrales percentiles, lo cual resulta una forma más precisa de medir esta señal.
Los valores del percentil 95 o 99 pueden ayudar a detectar un rendimiento deficiente en una solicitud o componente. Además, debes vigilar la latencia de errores, ya que una transacción con un mal rendimiento a largo plazo repercutirá negativamente en la demanda.
Tráfico
El tráfico se refiere al volumen de actividad presente en la aplicación. No es universal porque depende del tipo de aplicación que estés ejecutando.
Tampoco uses promedios para esta métrica. Algunos ejemplos de tráfico incluyen: cuántas solicitudes ha gestionado una API, el ancho de banda consumido para transmitir un determinado programa o el número de conexiones a un servidor.
Errores
En lenguaje llano, los errores significan la tasa de fallos de las solicitudes. Los más manifiestos son HTTP 500s. Pero eso no significa que te duermas en los laureles, ya que algunos no aparecen como errores -mide el tallo o los errores en las tasas-.
La idea de los errores es informar sobre los fallos en la aplicación, así como los de dependencia o desconfiguraciones del servicio. Además, las tasas de error pueden impactar en otras mediciones, como la saturación.
Saturación
La saturación mide cuán recargado está tu servicio. No nos referimos a que esté completo como un restaurante, sino qué tan agobiada se encuentra la prestación.
Tampoco existe una forma universal de medir la saturación. De hecho, resulta un desafío porque depende del tipo de aplicación que estás ejecutando que afectará diferente a las métricas de saturación. Por lo tanto, necesitas métricas flexibles para obtener una idea.
He aquí algunos ejemplos que puedes utilizar para determinar la saturación:
- Percentil 99 de latencia.
- Uso de memoria y CPU para todas las aplicaciones.
- Tasas de entrada/salida de disco para todas las bases de datos y aplicaciones de streaming.
- Recolección de elementos no utilizados de memoria, heap y thread pool para todas las aplicaciones basadas en Java.
Otra cuestión a tener en cuenta es que los servicios de las aplicaciones suelen empezar a degradarse mucho antes que una métrica alcance el 100% de utilización.
Configuración de las métricas para las señales de oro de SRE
Para empezar, configurar en tus aplicaciones las métricas para las cuatro señales de oro de SRE puede llevar un tiempo. La forma más fácil y rápida de hacerlo es para monitorear y probar las aplicaciones al principio de las fases de desarrollo y prueba de carga. Es necesario que obtengas una visión clara de las características de rendimiento antes de su ejecución.
Una vez establecidas las señales, te resultará mucho más fácil saber si necesitas una supervisión adicional. O, de otro modo, ya dispondrás de los medios para lograr una mayor observabilidad del sistema.
Una buena manera de hacerlo es aplicar las señales de oro de SRE a las siguientes actividades:
- Monitoreo de caja negra o sintética.
- Supervisión de la experiencia del usuario.
- Obtención de una visión clara de los tiempos de ejecución de las aplicaciones.
- Creación de tableros útiles y procesables que proporcionen información de un solo vistazo sobre el componente de supervisión.
Otra cuestión que hay que tener en cuenta es que las cuatro señales de oro de SRE constituyen el primer paso hacia un monitoreo significativo. El seguimiento en tiempo real de las cuatro señales ayudará a tus equipos a controlar los problemas mucho más rápido. Además, ofrecen una visión general del estado de todos los servicios, aunque no estén necesariamente bajo su responsabilidad.
En resumen, se trata de:
- Alertar: mantenerte informado cuando las cosas no funcionan como deberían.
- Resolver los problemas: ayudarte a solucionarlos.
- Planificar la capacidad: mejorar proactivamente las cosas con el tiempo para reducir la vulnerabilidad.
Y estas cuestiones no sólo ayudan con la gestión de incidentes, sino también con todo el ciclo de vida del incidente (a lo largo del tiempo).
Resumen
Las cuatro señales de oro de SRE implica tener una comprensión mucho mayor de la salud de tu sistema. A su vez, eso llevará a tu equipo a detectar problemas y reducir la probabilidad de que éstos vuelvan a aparecer en el futuro. Medir el tráfico, la saturación, los errores y la latencia es clave para establecer una línea de base de la aplicación que sirva como patrón oro, un listón por debajo del cual tus aplicaciones no pueden caer nunca.
Y aunque existen diferentes formas de realizar su seguimiento, no dejes de aplicar estas señales. Medirlas correctamente es uno de los factores más importantes para que el ciclo de vida de tu aplicación sea lo más fiable y libre de errores posible desde el principio.
El resultado es un proceso de desarrollo más "limpio", con menos errores, una tasa de respuesta más rápida a esos errores y más control sobre cada paso del proceso.
Preguntas frecuentes
¿Qué es el monitoreo de SRE?
Significa realizar un seguimiento de las señales de oro de SRE para garantizar que el ciclo de vida de una aplicación esté libre de errores y sea lo más eficiente posible. De lo contrario, estarás abriéndote a más vulnerabilidades o repitiendo los mismos errores.
¿Por qué necesitamos de SRE?
La Ingeniería de Fiabilidad del Sitio existe para mantener la comunicación entre los equipos de desarrollo, lo que ayuda a trabajar hacia el mismo objetivo. Esto reduce el aislamiento de la organización y crea un vínculo mucho más estrecho entre las diferentes áreas, gracias a los ingenieros de fiabilidad del sitio, que tienen experiencia tanto en codificación como en operaciones.
¿Qué es SRE en Google?
Ben Treynor, un ingeniero de Google, acuñó la Ingeniería de Fiabilidad del Sitio en 2003. Sus esfuerzos dieron lugar al floreciente sector de SRE, un gran complemento para DevOps y, a su vez, para el sector del desarrollo de software.
