Principios y prácticas clave de la SRE: ciclos virtuosos
Si realmente es verdad que en cierto sentido "somos lo que hacemos", hemos llegado al corazón de este módulo. En esta unidad veremos dos de las prácticas que suelen considerarse esenciales en la práctica de la SRE. Ambas nacen del principio de que es importante crear "ciclos virtuosos". Los ciclos virtuosos en este contexto son prácticas que crean bucles de comentarios en una organización que ayudan a esa organización a mejorar continuamente. Tenemos módulos de seguimiento enteros sobre estas dos prácticas en cuestión, por lo que solo vamos a echar un vistazo a información general de cada una de ellas.
Ciclo virtuoso 1: SLI y SLO
En este módulo resaltamos nuestra idea del trabajo con vistas al "nivel de confiabilidad adecuado". Esta sección es precisamente donde se aplica este concepto.
Imagine que tiene un nuevo servicio que tiene pensado llevar a producción (uno que se ha creado o que aún está en el proceso de planeación). Como parte de ese proceso, es importante tomar algunas decisiones sobre la confiabilidad deseada. Si no escribe todo el código por sus propios medios, estas decisiones se toman (y esto es fundamental) en colaboración con los desarrolladores que lo crean.
La primera decisión que se toma es qué se debe usar como indicadores del estado del servicio (un indicador del nivel de servicio o SLI). Otra manera de formular esta pregunta sería "¿Cómo se sabe cuándo está activo y funciona bien?". Hay muchas maneras de realizar el seguimiento de SLI y exploraremos algunas en detalle más adelante. Sin embargo, estos indicadores suelen ser:
- Medidas de éxito y error. ¿Completa el servicio correctamente una operación durante un porcentaje del tiempo?
- Medidas de tiempo. ¿Se devolvió una respuesta dentro de un umbral de tiempo determinado?
- Medidas de rendimiento. Se procesó cierta cantidad de datos?
O bien, una combinación de todas estas medidas.
Como ejemplo sencillo, podríamos decir que un SLI de nuestro servicio sería la frecuencia con la que devuelve un mensaje de éxito, indicado con un código HTTP 200 (frente al código 500 o algún otro código).
Ahora que se tiene un indicador claro de cómo funciona el servicio, se quiere decidir qué nivel de confiabilidad se espera o se desea de él. Por ejemplo, durante una parte del día, ¿se prevé observar una tasa de error del 20 % del servicio? Vamos a usar números elevados y redondos porque son fáciles de imaginar al principio. En los módulos posteriores aumentaremos la complejidad y la precisión de instrucciones como esta ("¿Qué usuarios verán esa tasa de error?, ¿algunos de ellos?, ¿la mayoría?", etc.). Esa expectativa, creada en colaboración con el desarrollador del servicio, es un objetivo de nivel de servicio (SLO).
El SLO debe ser algo que se pueda medir y representar con precisión en el sistema de supervisión. Está pensado para ser un propósito objetivo y bien analizado de la confiabilidad del servicio: ¿Qué cifra es suficientemente buena? Aquí no hay ningún "Bueno, creo que el servicio ha funcionado bien la última semana más o menos, pero es difícil de saber". Tanto si el servicio cumple su SLO como si no lo cumple, los datos deben quedar claros. Si no lo cumple (sobre todo varias veces durante un intervalo de tiempo), es que algo pasa y se debe solucionar.
Presupuestos de error
Se entiende que una organización pueda entrar en acción si un servicio no cumple su SLO. Pero la SRE lleva todo este concepto un paso más allá para los casos en los que se cumple o se supera el SLO. Algunas organizaciones usan los SLO para crear lo que denominan "presupuestos de error".
Para demostrar esta idea, vamos a usar el servicio de ejemplo que hemos tratado y su SLO del 80 % de éxito (piense en él como "debe ser de hasta un 80 % del tiempo"). Con el SLO del 80 % del tiempo hemos declarado que nuestro servicio debe ser de hasta un 80 % del tiempo. ¿Y qué ocurre con el 20 % restante? Si el servicio baja hasta ese 20 %, no nos "preocupa" porque hemos decidido que estar a ese 20 % adicional no nos parece importante como objetivo del servicio.
Entonces, si no nos preocupa lo que pasa durante ese tiempo, ¿qué podemos hacer con el servicio? Algo que podemos hacer seguro es alterar el servicio en ejecución con una actualización, quizás con una nueva versión que agregue algunas características. Si esa nueva versión permanece y no agrega ningún tiempo de inactividad, estupendo. Si esa nueva versión hace que el servicio sea menos estable y que devuelva errores otro 10 % del tiempo a medida que se depura, todo sigue bien. Estamos dentro de nuestro presupuesto de falta de confiabilidad permitida.
Un presupuesto de error es la diferencia entre la confiabilidad perfecta potencial del servicio y su confiabilidad deseada (100 % - 80 % = 20 %). En este caso, el presupuesto de error nos da un fondo de falta de confiabilidad del 20 %: un 20 % del tiempo en el que "no nos preocupa si está activo o no, porque sigue estando dentro de las especificaciones". Podemos recurrir a ese 20 % del tiempo y gastarlo de la manera que nos apetezca (quizás con más lanzamientos) hasta que se agote como cualquier otro presupuesto.
Los presupuestos de error también se usan en algunas organizaciones en el caso menos agradable: cuando no se cumple el SLO. En ese caso, podría optar por hacer algo un poco más estricto que "tomar una medida". Digamos que el servicio ha tenido algunos problemas y ha estado activo solo el 60 % del tiempo, como indica el SLI que se ha elegido antes. No se ha cumplido el objetivo (el SLO). Nuestro servicio ha agotado su presupuesto de error. La organización podría optar por retener un lanzamiento planeado porque sabe que alterar aún más el sistema en este momento podría solo empeorar aún más la situación de confiabilidad. Los presupuestos de error suelen calcularse para un periodo de tiempo determinado: un mes, un trimestre, etc. De forma continua, de modo que si la fiabilidad del servicio mejora, ese presupuesto vuelve.
Durante este tiempo de lanzamientos regulados, la organización podría optar por quitar algunos recursos de ingeniería del desarrollo de características con vistas al trabajo de confiabilidad para ayudar a descubrir y mejorar el origen de los problemas que han provocado que el servicio agotara su SLO.
El motivo por el que decimos "algunas organizaciones" en lo referente a los presupuestos de error es su implementación, sobre todo en el caso en el que se usa para regular lanzamientos, en el que se necesita un cierto compromiso institucional. A la hora de enfrentarse a una decisión relativa a un lanzamiento, la organización tiene que estar dispuesta a decir que, si la confiabilidad del servicio hasta la fecha no ha sido aceptable, se retendrá dicho lanzamiento. Esa decisión no es una que todas las organizaciones estén dispuestas a tomar. Tampoco es la única respuesta posible a un presupuesto de error agotado, pero es de la que más se habla.
En un módulo independiente, hablamos con mucho más detalle sobre los SLA, los SLO y los presupuestos de error. Pero vale la pena destacar aquí el aspecto del ciclo virtuoso de estas prácticas. En teoría, es una manera para la organización de describir la confiabilidad de un servicio, comunicarla y actuar de manera coherente con ella y de hacerlo de una manera en la que todos trabajen por una mayor confiabilidad. Este bucle de comentarios puede ser muy importante.
Ciclo virtuoso 2: análisis Blameless Postmortem
La idea de un análisis retrospectivo (el análisis retrospectivo de un evento significativo, por lo general no deseado) no es para nada específica de la ingeniería de confiabilidad de sitios. Tampoco es rara en el mundo de las operaciones. Algo que está más cerca de ser característico es el empeño de la SRE en que los análisis post-mortem han de ser "intachables". Deben centrarse en el error del proceso o la tecnología durante el incidente, y no en las acciones de personas concretas. "¿Cuál ha sido el proceso aplicado que ha permitido que X hiciera lo que ha provocado el error? ¿Qué información no tenía disponible esa persona, o incluso estaba destacada en el momento que los ha llevado a la conclusión incorrecta? ¿Qué vallas de contención debería haber habido para que no hubiera tenido lugar un error de tal magnitud?". Estas son el tipo de preguntas que se formulan en un análisis retrospectivo sin acusaciones.
El tono y el sentido de estas preguntas es fundamental. Se buscan maneras de mejorar los sistemas o procesos, y no maneras de castigar a los usuarios cuyo uso de esos sistemas o procesos, de buena fe, haya contribuido a la interrupción. Es importante recordar que "no puede lanzarse a lo confiable". La experiencia enseña que una organización que despide a una persona cada vez que hay un incidente de producción (con pocas excepciones), no aprende de esos incidentes. El resultado es que solo queda una persona temblando en una esquina asustada de realizar el menor cambio.
Pero un proceso de análisis post-mortem que funcione correctamente en una organización creará un ciclo virtuoso. Con él, la organización aprende de las interrupciones y mejora continuamente sus sistemas (lo que proporciona un análisis adecuado y el seguimiento correspondiente).
Esta relación con los errores (aprovechados por la organización como oportunidades de aprendizaje y mejora) es un principio básico de la ingeniería de confiabilidad de sitios. La creación de ciclos virtuosos para aprovechar estas oportunidades y dirigir la organización hacia una mayor confiabilidad es otro.
En la unidad siguiente veremos otros principios y prácticas, que se centran en el lado humano de la SRE.