Site Reliability Engineering

Hace poco más de 12 años, en Google se gestó una iniciativa denominada “Site Reliability Engineering (SRE)” —que en español sería Ingeniería de Confiabilidad de Sitios.

Hoy en día, SRE es fundamental para la operación de los servicios en línea de esta empresa, y el concepto se está extendiendo al resto de la industria, tanto así que ya puedes decir que te dedicas a hacer SRE, y las personas —al menos, las adecuadas— te entenderán.

Yo tuve oportunidad de colaborar unos años en Google como parte del equipo de SRE, y actualmente me desempeño como consultor independiente en el rol de SRE. En el siguiente artículo comparto mi perspectiva de en qué consiste este concepto, cuáles son sus beneficios, y algunos tips para incorporarlo en tu forma de trabajo.

¿Por qué debe interesarme SRE?

Recientemente fui invitado a dar una plática sobre SRE en la Asociación Rumana para Mejor Software [1]. Dado que esta es audiencia principalmente dedicada al desarrollo de software y no a la operación o administración de sistemas, posiblemente parezca raro que ellos se interesen en SRE. Es decir, ¿por qué le interesaría a un desarrollador aprender de SRE? o más aún, ¿por qué debería un desarrollador interesarse en facilitar la vida de la gente de operaciones?

El hecho de que el equipo de operaciones soporte adecuadamente tu trabajo como desarrollador, te beneficia. No se trata de abrir la puerta para que los de operaciones te echen la culpa cuando las cosas salgan mal, sino de hacer una alianza; una alianza que hará que tu software opere sin problemas en producción y por lo tanto puedas enfocarte en construir funcionalidad innovadora.

Tal vez tengas la noción de que los desarrolladores solo deben enfocarse en agregar funcionalidad al software para atraer más usuarios, y dejar en manos de operaciones la confiabilidad de este. Pero un servicio poco confiable es difícil que pueda retener usuarios, independientemente de qué tan atractiva sea su funcionalidad. ¿Y qué mejor que tener como aliado a un equipo que tenga “confiabilidad” en su nombre?

¿Qué es la ingeniería de la confiabilidad?

La ingeniería de la confiabilidad es la rama de la ingeniería que se preocupa porque los productos diseñados funcionen como se espera, aun cuando sus componentes no sean confiables por naturaleza. Se enfoca en mejorar la confiabilidad de los componentes, establecer requerimientos mínimos, y hace un uso intensivo de estadística para predecir fallas y entender los problemas.

Ben Treynor es quien inició esta práctica en Google hace poco más de 12 años, y él define SRE de la siguiente forma:

“Fundamentalmente, es lo que sucede cuando le pides a un ingeniero de software que diseñe funcionalidad de operación”.

La primera recomendación al crear un equipo de SRE es contratar solamente a personas que puedan programar. Escribir software es una de las principales actividades de SRE. Esto es porque la visión de SRE consiste en tratar a la operación como un problema de ingeniería de software, es decir que se usa software para resolver problemas tradicionalmente resueltos a mano, implementando pruebas rigurosas, revisiones de código, y tomando decisiones basadas en datos, no en corazonadas.

También implica que SRE puede entender el producto al que está dando soporte y que hay respeto entre los ingenieros de desarrollo y operación.

Posiblemente, algunas de las recomendaciones que hago aquí solo tienen sentido en el contexto de una empresa con las características de Google: varios equipos de desarrollo y operaciones, un crecimiento mayor a la velocidad con la que se puede contratar gente, y un compromiso de la alta dirección para implementar reglas drásticas. Así que mi interés no es pregonar sobre por qué todos deben adoptar SRE, sino extraer algunas de las ideas más útiles que pueden aplicarse en un amplio rango de situaciones.

¿A qué se dedica SRE?

El equipo de SRE se dedica principalmente a mantener tu servicio en línea, realizando las tareas tradicionales de sysadmin como aprovisionamiento de infraestructura, configuración, monitoreo y asignación de recursos de cómputo, etcétera. Utilizan herramientas especializadas para monitorear servicios y obtener alertas en cuanto se detecta un problema. A ellos les toca despertarse a media noche para levantar un sistema caído o corregir una falla.

Pero eso no es todo: la confiabilidad no solo es impactada por nuevos lanzamientos. Puede que de pronto aumente la utilización de un sistema, falle el hardware, haya problemas de conectividad. Al trabajar a gran escala, todo tipo de fallas pueden darse. El objetivo de SRE es que dichas fallas afecten la disponibilidad del sistema lo menos posible. Para ello, SRE trabaja continuamente en 3 grandes estrategias: minimizar el impacto de las fallas, disminuir el tiempo requerido para recuperarse, evitar reincidencias. A continuación entro en más detalle de cada una de estas estrategias.

Minimizar el impacto de fallas

Hay que buscar que una falla no pueda provocar la caída de un servicio entero. Una de las tácticas que SRE utiliza es fragmentar y distribuir un servicio a través de varios “dominios de falla”. Un ejemplo sería distribuir los datos de un sistema a través de varios centros de datos, de manera que si un centro de datos en particular se incendia, solo una fracción de los usuarios se vean afectados. El equipo de SRE dedica gran parte de su tiempo a planear y habilitar sistemas que abarquen distintas regiones geográficas para maximizar redundancia y mantener la latencia de comunicación en niveles razonables.

Recuperarse rapidamente

Comúnmente, la forma más efectiva de reestablecer un sistema que falla es reiniciándolo. Así que otra estrategia es instrumentar los sistemas para que reinicien automáticamente milisegundos después de que se detecta una falla. Si se requiere intervención humana, es crucial que se notifique lo antes posible a las personas adecuadas y que tengan acceso rápido a la información que necesitan para resolver el problema tal como: documentación del ambiente de producción, guías de soporte, reportes de monitoreo, etcétera. Después de todo, es muy probable que a las 2 de la mañana te cueste trabajo recordar en qué país está ubicado cierto segmento de la base de datos, o cuál es la serie de comandos que necesitas para redireccionar el tráfico.

El equipo de SRE dedica bastante tiempo a implementar alertas automatizadas, escribir documentación y guías de soporte, e implementar otros preparativos para recuperación de desastres.

Evitar reincidencias

Cuando un incidente provoca una falla en el sistema, la primera prioridad es restablecer el sistema; pero también es muy importante estudiar la falla, con el objetivo de encontrar la causa raíz y resolverla. Así que otra actividad importante de SRE consiste en redactar reportes de postmortem. Cada incidente debe tener un postmortem, y estos deben usarse con fines de aprendizaje, no de echar culpa.

Prevenir fallas

Por supuesto, otra estrategia más, consiste en evitar que se den fallas en primer lugar. Claro que nadie puede evitar que un disco duro falle, pero hay otros tipos de fallas que se pueden prever. Por ejemplo, un aumento súbito en la carga de uso de un sistema puede tirarlo, por lo que el equipo de SRE debe asegurar que los sistemas sean probados con cargas de trabajo mayores a lo normal. También deben estar preparados para poder escalar rápidamente un servicio (por ejemplo: habilitar más nodos de procesamiento) en caso de que el sistema de monitoreo detecte que se ha alcanzado cierto umbral.

El equipo de SRE puede evitar fallas provocadas por situaciones como que se agote el espacio de almacenamiento o se degraden los componentes físicos. El monitoreo es el elemento clave: captar métricas relevantes y seguir su tendencia a lo largo del tiempo.

Mejorando la relación entre SWE y SRE

La lucha entre el equipo de desarrollo (Software Engineering, SWE) y el de operaciones comienza porque ambos tienen metas distintas. Llega el fin de semana y los desarrolladores quieren liberar una nueva versión a producción, pero los de operaciones quieren tener un fin de semana tranquilo. Cuando las liberaciones son problemáticas, lo que típicamente se hace es agregar burocracia para minimizar los riesgos: revisiones, checklists, ventanas de cambio, etcétera. El resultado es que los desarrolladores continuamente buscan formas de saltarse estos controles, y se generan problemas mayores.

Uno de los principales aspectos de SRE es evitar esto por completo, a través de un cambio en los incentivos para eliminar las presiones entre los equipos de desarrollo y operaciones. A continuación menciono algunas de las estrategias que se aplican en Google para lograrlo:

Tener acuerdos de servicio

Antes de que un servicio pueda ser soportado, se debe determinar el nivel de disponibilidad que debe mantener para que los usuarios y la empresa estén contentos: esto es lo que se conoce como Service Level Agreement (SLA). El SLA define cómo se mide la disponibilidad (por ejemplo: porcentaje de queries completados exitosamente en menos de 50 ms) y cual es el mínimo valor aceptable o SLO (el valor objetivo de nivel de servicio). Esta es una decisión de producto, no técnica. Es un número muy importante para un equipo de SRE y su relación con desarrolladores. No se toma a la ligera, y debe cumplirse de forma rigurosa.

Un objetivo de disponibilidad 100% rara vez es una buena idea, y en la mayoría de los casos es imposible conseguirlo. En empresas como Google, una meta común de disponibilidad en los servicios online es de cinco nueves (99.999%); esto significa que un servicio no puede estar caído más de 5 minutos durante todo un año.

Son muy pocas las cosas que realmente requieren una disponibilidad de 100% (por ejemplo: un marcapasos), y lograrla es muy costoso.

Medir y reportar el desempeño

Una vez que hayas definido el SLA y SLO, es muy importante que estos sean monitoreados y reportados continuamente. Si esperas para el fin del trimestre para producir un reporte manual, el SLA no sirve de nada, ya que no nos sirve enterarnos tan tarde de los problemas.

Este es un aspecto clave de SRE, ya que permite ver el avance de un servicio a lo largo del tiempo, detectando problemas de capacidad antes de que provoquen la caída del sistema, y al mismo tiempo mostrando qué tanto se puede tener el sistema abajo sin romper el SLA. Esto último nos lleva a la siguiente recomendación…

Administrar el presupuesto de falla

Si el SLO es el tiempo mínimo de disponibilidad, entonces al restar 1 - SLO obtenemos la fracción de tiempo que nuestro servicio puede fallar y todavía cumplir el SLA. Esto es lo que llamamos nuestro presupuesto de falla, y debemos aprovecharlo.

En el caso de servicios inestables que acostumbran tener errores, la mayoría de nuestro presupuesto de falla se desperdicia en fallas del sistema, lo cual no nos deja margen para intentar lanzar cambios. Por otro lado, cuando tenemos servicios estables que no usan el presupuesto de falla, tenemos la libertad de apostar parte de ese presupuesto para liberar nueva funcionalidad al usuario con mayor frecuencia.

Una vez que el presupuesto de falla se ha agotado, no se permite hacer nuevos lanzamientos hasta que transcurra suficiente tiempo sin fallas para darnos nuevo saldo.

Al darle visibilidad a todos sobre el comportamiento del presupuesto de falla, se ayuda a reducir conflictos entre los equipos de desarrollo y operaciones. Si el servicio está funcionando adecuadamente, entonces el equipo de operaciones no necesita interferir para oponerse a lanzamientos; se cuenta con evidencia cuantitativa para justificar las decisiones. Esto contribuye a evitar resentimiento y desconfianza entre desarrollo y operaciones. No es que los de operaciones quieran hacerle la vida difícil a los desarrolladores, es que simplemente no tienen presupuesto de falla disponible. Al mismo tiempo, esto provee un incentivo al equipo de desarrollo para evitar malgastar el presupuesto de falla con versiones que contengan errores o estén mal preparadas para liberación.

Dar visibilidad al trabajo de otros

Si el equipo de operaciones es visto por los desarrolladores como un grupo de bomberos cuyo trabajo consiste en apagar incendios 24X7, tienen menos incentivos a hacer buen software. De forma similar, si el equipo de desarrollo no tiene visibilidad a lo que sucede en el ambiente de producción, difícilmente podrán establecer confianza. Por ello es buena práctica que el equipo de desarrollo ocasionalmente haga algo de trabajo de operaciones por ejemplo: atender tickets, gestionar servidores, hacer liberaciones a producción. Lo que resultará en mejor comunicación entre equipos, y un entendimiento común de las prioridades.

Balancear el personal

Un mecanismo que se utiliza en Google es tener un límite de personal unificado entre desarrollo y operaciones. De esta forma, mientras necesites más personas para mantener el servicio en línea, contarás con menos desarrolladores para construir nueva funcionalidad. Combinado con esto, en Google los SRE se pueden mover libremente entre equipos, o incluso moverse a desarrollo. De esta forma, un servicio que es latoso de soportar solo tendrá acceso a los ingenieros menos experimentados.

Limitar la carga operativa

En Google, los SREs no deben dedicar más de la mitad de su tiempo a “trabajo operativo”. El resto de su tiempo deben ocuparlo en tareas de automatización, monitoreo, planeación de crecimiento … y no en continuamente arreglar de forma manual problemas derivados de sistemas mal hechos.

Si se encuentra que un equipo de SRE está dedicando demasiado tiempo a trabajo operativo, esa carga extra se reasigna al equipo de desarrollo. En casos extremos, un servicio puede ser considerado demasiado inestable para mantener, y entonces el equipo de SRE elimina su soporte por completo. Esto implica que el equipo de desarrollo ahora debe realizar todo el trabajo operativo y de soporte.

Otras lecciones aprendidas

Además de los lineamientos que he descrito aquí, hay otras prácticas que creo que serían útiles para cualquier equipo de operaciones e incluso de desarrollo.

Automatiza todo. No es sustentable hacer todo manualmente. No solo es un tema de tiempo ni de dinero, sino de disponibilidad de talento en el mercado laboral.

Involucra a operaciones en el diseño de sistemas. Nadie conoce mejor los retos de un ambiente de producción que el equipo de operaciones. Su retroalimentación te puede ayudar a ver riesgos de escalabilidad, planeación de capacidad, redundancia, y tomar acciones para evitarlos desde el diseño del sistema.

Documenta el diseño. Documentar los detalles de un sistema previo a su construcción es una gran forma de detectar problemas temprano, además es muy útil para comunicar a tu equipo qué es lo que se está construyendo, y convencerlos de que es una gran idea.

Revisa tu código y versiona los cambios. Todo debe estar sujeto a código de versiones: código, scripts de instalación, archivos de configuración. Puede parecer que no valga la pena, pero tener una historia completa de tu ambiente de producción es invaluable. Y al tener control de versiones, entra otra regla: ningún cambio se acepta sino es revisado por un colega. Puede ser frustrante tener que encontrar a un revisor y esperar aprobación por cada cambio, pero una vez que te acostumbres te darás cuenta que los beneficios superan por mucho las inconveniencias.

Antes de modificar, mide. El monitoreo no solo sirve para enviar alertas, sino que es una parte esencial de SRE. Te permite sensar tu disponibilidad, evaluar tendencias, predecir crecimiento, y realizar análisis forense. El monitoreo debe proporcionarte los datos que necesitas para tomar decisiones basadas en hechos. Antes de optimizar o hacer un cambio, encuentra donde está realmente el cuello de botella.