Site Reliability Engineering path Build. Fail. Learn. Repeat.

Parte de lograr armar culturas sustentables de ingeniería es entender las distintas ramas involucradas en el proceso de desarrollo de software. Hoy vamos a charlar respecto a Site Reliability Engineering: una disciplina tan importante como mal comprendida.

Entonces primero definamos un poco qué es esto de SRE,  ¿ es una cultura ? ¿ Es un rol/posición dentro de una empresa ? ¿ Es un concepto ?  A lo largo de todo el artículo voy a intentar definir lo que abarca SRE, ya que es a la vez un rol, una cultura y un concepto. Empecemos por el principio de donde nace este nuevo concepto, Site Reliability Engineer es definido como un rol por Google en 2005, pero para entender porqué Google llegó a este rol tenemos que situarnos en lo que “era” tradicionalmente. Históricamente las empresas han empleado SysAdmins o Administradores de Sistemas para operar los sistemas informáticos complejos. Digo “era” porque es una práctica que todavía al día de hoy sigue dando.

Como mencioné, muchas empresas continúan con esta práctica de contratar SysAdmins, por tres razones principalmente. Primero es relativamente fácil contratar SysAdmins ya que es una práctica muy conocida y mucho talento para contratar. Segundo existen muchas herramientas para ayudar a esta práctica  y por último por estas dos razones que tenemos talento y sistemas preparados el onboarding de estos recursos es extremadamente rápido ya que no tienen que reinventar la rueda.

Para solucionar este modelo de Developers y Operaciones totalmente separado es que nace la cultura de DevOps. Este “nuevo” paradigma cambió la forma que los distintos equipos interactúan entre ellos,  ganando velocidad  y distribuyendo el conocimiento. Con esta nueva metodología vemos que un desarrollador con las herramientas y procesos correctos puede ganar full ownership de todo el ciclo de vida de su aplicación. Es decir, el desarrollador a través de pipelines tiene la facultad de desarrollar, desplegar su código en los distintos ambientes y operar sobre su aplicación. Es bajo este paradigma que gran parte de las tareas de los tradicionales SysAdmins carecen de sentido, ¿Entonces los sysadmin murieron? La respuesta es claro que  NO! Pero si es verdad que vamos a ver distintas evoluciones de este rol. El rol de SysAdmin va seguir siendo un rol fundamental para aquellas organizaciones que tienen Infraestructura On Premise y/o un modelo de Cloud Computing donde  tienen que administrar los sistemas operativos.

Algunas de las evoluciones que vemos en el mercado del rol de sysadmin puede ser :

• Sysadmin > DevOps Engineer
• Sysadmin > Site Reliability Engineer 
• Sysadmin > Operations Engineer

Muchas veces se me discutió con gran criterio que Devops no es un Rol/Posición sino es una cultura/metodología, en lugar de llamarlos Devops deberíamos de llamarlos SRE.  Ante esta postura mi opinión es que ambos roles tienen que existir en una organización, ya que ambos roles tienen distinto FOCO. En el siguiente diagrama muestro el alcance de los dos Roles:

El gran foco del equipo de Devops es facilitar el ciclo de vida de los desarrolladores y generar todas las herramientas necesarias para que estos no necesiten de nadie para poder mantener su aplicación. Para ello van a estar construyendo diversos tipos de pipelines que les permita a los devs poder operar con la mayor seguridad posible, sin romper necesidades de cumplimiento que tenga la empresa entre otras razones. Este rol a veces lo vemos descrito como Core Services Engineer.

Por otro lado tenemos a SRE, el gran foco de este equipo es velar por la tener la máxima Resiliencia posible como lo dice el propio nombre. Para ello estas personas tienen un rol que abarca tareas de Developer, Operaciones, Devops y Arquitectura.  ¿ Cómo podemos “challenger” una arquitectura sin conocer patrones de arquitectura ? ¿ Cómo podemos identificar que genera carga operativa y automatizar la misma sino vivimos la operación ?

”Hope is not a strategy.”

Benjamin Treynor Sloss

Entonces la existencia de estos dos equipos ayudan a generar una contraposición de intereses que busca la excelencia ya que un equipo ‘DevOps’ va a buscar potenciar a los equipos de desarrollo para salir más rápido a producción  y el otro equipo ‘SRE’ va perseguir la resiliencia de la plataforma. Si bien es verdad que trabajan casi con el mismo stack tecnológico la Infra ( AWS, GCP, Azure, Docker, Kubernetes, Onpremise cualquiera que sea ) al ser sus focos distintos cada uno va centrar todos sus esfuerzos en la excelencia en una vertical.

Por diseño, es crucial que los equipos de SRE se centren en la arquitectura y desarrollo. Sin reingeniería constante, la carga de operaciones aumenta y los equipos necesitarán más personas solo para mantener el ritmo de la carga de trabajo. Eventualmente, un grupo centrado en operaciones tradicionales escala linealmente con el tamaño del servicio: si los productos compatibles con el servicio tienen éxito, la carga operativa crecerá con el tráfico. Eso significa contratar a más personas para hacer las mismas tareas una y otra vez.

Gran parte de la disponibilidad de los sistemas viene de una buena arquitectura claro está pero también de erradicar el error humano, justamente al tratar de reducir el “toil” operativo estamos buscando garantizar la disponibilidad. Como dijo Benjamin Treynor “Hope is not a strategy”, el rol de SRE justamente es suponer que todo lo que se puede romper se va a romper y crear mecanismos que sean resilientes ante estas fallas.

Para ello tradicionalmente se trata la resiliencia como si lo viéramos como una buena práctica, esto está “ok” pero no alcanza si buscamos tener una aspiración como un 99,99% de disponibilidad de servicio y mucho más si queremos buscar el 99,999%. La única forma de alcanzar tal hazaña es provocando Caos en nuestras aplicaciones/sistemas para prever el Caos Real.

Chaos Engineering  es la disciplina que bajo un método científico inyecta fallas en los sistemas para simular cómo reaccionan los mismos. Pocas empresas tienen la capacidad de realmente simular Caos antes de salir incluso a producción para ello existen varias soluciones que son efectivas a la hora de generar esto.  Las herramientas más conocidas son todas vinculadas a Monos o Simios ! https://github.com/Netflix/SimianArmy o https://github.com/Netflix/chaosmonkey ambas herramientas realizadas y liberadas por Netflix. En mi experiencia estas tools necesitan de un equipo de personas expertas que sepan operarlas, gestionarlas y sacarles el mejor provecho, en Pomelo vimos de utilizar Gremlin.

Gremlin es una herramienta de Chaos Engineering as service, ¡hace extremadamente sencillo algo que no es para sencillo! Como si fuera poco generaron una certificación 📚‘Certified Chaos Engineering Professional’ totalmente gratis 👏👏👏 y con muy buen material disponible para aprender de esta disciplina. Dejo Link  https://lnkd.in/eAdsqdS5

Ahora no podemos aplicar Caos Engineering si no contamos con observabilidad absoluta de lo que estamos corriendo desde nuestros servidores hasta las aplicaciones.Es de igual importancia desarrollar y poner a correr aplicaciones, como saber cual es el estado y que está pasando en las mismas. Para los que venimos del mundo de infra el monitoreo  que empieza desde el día cero, desde cosas básicas como hacer un Ping para validar que esté respondiendo hasta scripts que permitan ver una línea específica en un log.  Hoy en día no se concibe un monitoreo que no sea FullStack y que él mismo nos permite cruzar datos de aplicación, logs, métricas bajando al mayor nivel posible tanto así que a veces se genera una marea de datos!

Hay distintas tools  de Observabilidad muy buenas como Datadog, Dynatrace, Splunk, Sumologic , Soluciones Opensource como Prometheus, Grafana, Zabbix, Nagios, entre otras ! Muchas veces la propia elección de la herramienta ya es un desafío en sí, nos va a servir para todos los casos de usos? Vamos a tener una tool para APM y otra para Infra? ¿Qué pasa con los eventos de seguridad?

De las herramientas que tuve la oportunidad de probar, configurar y usar en ambientes productivos puedo decir que New Relic, Inc. es una de las más sólidas sobre todo en términos de Full Stack Observability hace simple algo que es realmente complejo. Por ello desde Pomelo elegimos New Relic como nuestra observability tool. Una de las cosas copadas fue la creación e incorporación de Pixie https://pixielabs.ai/ que le permitio a New Relic tener Open-Telemetry sobre los clusters de Kubernetes en tiempo real. Dejo links a la New Relic University 📖 que cuenta con varios cursos gratuitos e incluso una certificación para realizar 🔥, https://lnkd.in/eMycVBf2.

SRE al final del camino se vuelven en los “maestros” de la observabilidad, ven patrones donde otros nos los ven. Ya que gran parte de su tarea es como puedo comprar esta disponibilidad y para ello todo comienza en cómo puedo medir por ejemplo la cantidad de request a determinado endpoint y sus status code, ahora bajemos mas quiero medir la latencia de los request que fueron 4XX o 5XX al endpoint en cuestión desde distintos puntos. Estas métricas  nos van a interesar para entender si nuestro servicio es confiable o no.

Cuando una aplicación, sistema o servicio no es confiable, deja de ser utilizado. Por ello una de las tareas es encontrar un equilibrio entre sacar nuevas versiones/feature/dar valor al usuario y que nuestro sistema siga siendo confiable.

Para esto Google definió una clara metodología  que involucra varias siglas que seguramente alguna es conocida como el SLA ( Service Level Agreement  ), otras no tan conocidas como SLO ( Service Level Objetive ), SLI ( Service Level Indicator )  y Error budget. ¡En que consisten estas siglas!

SLA es el compromiso adquirido con los clientes de niveles de cumplimiento que tenemos que asegurar como mínimo, siempre para los casos de incumplimiento de SLA se determinan penalidades e incluso cláusulas de rescisión.

SLO es el objetivo adquirido por el equipo que tenemos que asegurar como minimo de Uptime/Error Rate/Latency para que nuestra operación sea excelente.

SLI es el indicador, es decir la medición de los objetivos pautados en los SLO.

Error Budget es cuánto tiempo puede estar caído el servicio, es sano consumir el error budget mensual.

Ahora cómo se relacionan todos estos:

¿Qué  tiene que ver todo esto con el título del artículo “Site Reliability Engineering” path Build. Fail. Learn. Repeat. ” ?, hasta ahora definimos que es la práctica de SRE y cuales son sus grandes tareas pero porque “Build. Fail. Learn. Repeat.” . En SRE, como en cualquier proceso, es imposible lograr desde el inicio imaginarnos todos los escenarios posibles, para ello el método científico nos dice genera Hipótesis prueba la misma en ambiente controlado, aprende del resultado e itera el modelo. ¿Hasta cuándo  vamos a iterar el modelo ? El modelo se va iterar las veces que sea necesario hasta que logremos en base a métricas  determinar qué estamos cumpliendo con el SLO del flujo. Para esto es que la práctica de Caos Engineering es clave, ya que nos permite adelantarnos a los verdaderos incidentes simulando los mismos.

Entonces si logramos simular todos los escenarios no vamos a tener más incidentes ? No , SIEMPRE VAMOS A TENER INCIDENTES no importa qué tan preparados estemos lo que vamos a estar generando es la capacidad de anticiparnos a estos incidentes, aprender de los mismos y tratar que no se repita el mismo incidente dos veces, a veces el incidente es ocasionado por un tercero y no tenemos el control para mitigarlo. Ejemplo una conexión con algún  proveedor que sea único  ( como  los proveedores gubernamentales ) y que este se caiga.  Por lo que tenemos que prepararnos para responder estos incidentes, esto va desde buenas prácticas como documentar los incidentes y sus mecanismos de resolución, hasta cuales son planes de comunicación y de escalamiento de cualquier incidente.

El flujo va estar conformado  por uno o más EVENTOS que disparan una o más ALERTAS las cuales pueden tener uno o más procesos de ESCALAMIENTO y ser atendidas mediante uno o más PLANES DE ACCIÓN. Después que se completan estas fases comienza el análisis “postmortem”.

Ahora quiero arrancar un departamento de SRE que hago ? tengo que invocar magos para cubrir estas posiciones ? ¿Existen estos perfiles tan todo terreno que saben de Arquitectura, Operaciones, Resiliencia, Automatización y Desarrollo?

La realidad es que estos perfiles son extremadamente difíciles de conseguir, pero no es tan difícil de conseguir un equipo politécnico que nos permita cubrir todas las necesidades descritas y trabajar muy fuertemente en la sinergia de este equipo. 

La gran reflexión que deberíamos llevarnos frente a la filosofía SRE es “BUILD. FAIL. LEARN . REPEAT. ” iterar las métricas, iterar los escenarios, iterar los flujos operativos, iterar las hipótesis que armamos para garantizar la resiliencia. Esta es la única gran receta para tener una gran resiliencia.