Buscando SRE

Capítulo 1. Contexto frente a control en la ESR

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Un debate con Coburn Watson, Microsoft (antes Netflix) y David N. Blank-Edelman

David: Hemos tenido el placer de hablar de muchas cosas en el tiempo que llevamos conociéndonos. Una de las cosas más interesantes de las que te he oído hablar es una forma de hacer SRE que se centra en proporcionar contexto en lugar de utilizar procesos centrados en el control (la forma más habitual de practicar SRE). ¿Podemos profundizar un poco más en esto? ¿Puedes explicar qué entiendes por contexto frente a control y cuál sería un buen ejemplo de cada uno?

Coburn: Considero que el contexto proporciona información adicional y pertinente, que permite a alguien comprender mejor la razón de ser de una solicitud o afirmación determinada. En el nivel más alto, el contexto relacionado con la disponibilidad, tal como se comparte en Netflix con un equipo de ingeniería, sería la tendencia de disponibilidad de sus microservicios y cómo se relaciona con el objetivo deseado, incluida la disponibilidad de las dependencias posteriores. Con este contexto específico del dominio, un equipo de ingeniería tiene la responsabilidad (y el contexto) de tomar las medidas necesarias para mejorar su disponibilidad.

En un modelo basado en el control, un equipo será consciente del objetivo de disponibilidad de su microservicio o microservicios, pero si no lo consigue, puede haber una acción punitiva. Esta acción podría consistir en retirarles la capacidad de enviar código a producción. En Netflix, nos inclinamos por el primer modelo, compartiendo el contexto sobre la disponibilidad a nivel de microservicio, y trabajando con los equipos cuando es necesario para ayudar a mejorar la disponibilidad.

El reto es asegurarse de que se proporciona suficiente contexto a los equipos. Cuando alguien toma una decisión operativa no ideal en Netflix, la primera pregunta que hay que hacerse es si esa persona tenía contexto suficiente para tomar una decisión mejor. Muy a menudo, el equipo de SRE descubrirá que un golpe a la disponibilidad es el resultado de un contexto insuficiente transmitido al equipo, en particular el contexto relacionado con la fiabilidad. Ésas son las lagunas que intentamos cerrar como equipo de SRE para mejorar la disponibilidad general.

En una organización muy grande, puede ser un reto proporcionar suficiente contexto para que, basándose sólo en él, las personas puedan alcanzar los objetivos de disponibilidad deseados para sus servicios. En organizaciones de esta escala, a menudo hay que recurrir a más procesos para alcanzar los objetivos de disponibilidad. Un ejemplo es el modelo de presupuesto de errores de Google.¹ Otro caso para un modelo más basado en el control es cuando hay vidas en juego. Si alguien escribe con frecuencia software inseguro para el sistema de piloto automático de un avión, esa persona (y esa empresa) probablemente tenga una tolerancia muy baja a un enfoque basado principalmente en el contexto. No quieren reunirse y averiguar cómo mejorar su disponibilidad mediante un contexto adicional si los aviones están cayendo del cielo. Depende de cada organización de SRE determinar cuánto riesgo puede asumir como uno de los factores para encontrar la división entre un modelo basado en el contexto y otro basado en el control.

Creo que hay una diferencia entre información y contexto. En el monitoreo de sistemas, la información podría ser simplemente un montón de métricas de disponibilidad que introduzco en un panel y envío por correo electrónico al equipo. Un ingeniero típico que recibiera un correo así lo ignoraría porque 1) se encarga de escribir la lógica empresarial de un servicio, y 2) carece de los conocimientos necesarios para digerir y comprender las métricas de recursos y disponibilidad presentadas como series temporales.

En Netflix disponemos de cientos de miles de métricas operativas. Con el fin de apoyar un modelo basado en el contexto para mejorar la disponibilidad, tenemos que aportar conocimientos específicos del dominio a los datos. Esto requiere tomar la información y masajearla en un formato que cuente una historia sobre la disponibilidad. Aplicando esta transformación, podemos enviar este contexto a los equipos cuando lo necesiten, para que puedan medir si mejora la disponibilidad de un microservicio determinado. Por ejemplo, una métrica clave de la disponibilidad es la tendencia de la tasa de éxito de los servicios dependientes de un microservicio determinado (medida desde el lado del cliente y desglosando las tasas de fallo en función de la causa).

Mi equipo no es dueño de la disponibilidad, pero nuestro trabajo es mejorarla con el tiempo. ¿Por qué? Porque siempre puede reventar una rueda del coche. A menudo los equipos se acercan y dicen: "No estoy muy seguro de por qué ha bajado mi disponibilidad; ¿podemos hablar de ello?". Al investigar la situación, podría descubrirse que alguien modificó una biblioteca cliente o cambió un ajuste de tiempo de espera. Como ya se ha dicho, es importante partir del principio de que las personas no actúan de forma negligente; sólo les falta el contexto para tomar las mejores decisiones. Tampoco hay que olvidar que los sistemas pueden ser excesivamente complejos y que el listón operativo necesario para evitar incidentes es demasiado alto o innecesario. Un ejemplo de esta última categoría es el ajuste de los tiempos de espera estáticos en un sistema dinámico.

Aunque un modelo basado en el contexto es ideal, puedes desviarte hacia el control necesario cuando veas que un equipo tiene incidentes repetidos. Se les ha proporcionado el mismo contexto de disponibilidad efectiva que a otros equipos y, sin embargo, su disponibilidad sigue sufriendo. En algunas empresas, el control adopta la forma de prohibir que se pase código a producción, y entonces, claro, los ingenieros acuden a la dirección porque necesitan pasar código a producción. En Netflix, empiezo con la conversación "estás en mi lista" con un director de ingeniería, que implica establecer en persona un nivel adicional en torno a las expectativas de disponibilidad del servicio. Si hay un punto de vista común, entonces mencionaré que están desarrollando muchas funciones, pero no abordan los cambios necesarios para mejorar la disponibilidad. Concluyo preguntando: "¿Cómo podemos incluirlos en tu lista?". En mi mente, ése es el grado de control que realmente quiero. Tengo suerte de trabajar en una empresa con un conjunto maduro de personas que reconocen la importancia de la disponibilidad para el negocio y priorizan los esfuerzos adecuadamente. Creo que este tipo de debate suele hacer que la aguja apunte en la dirección correcta.

Ya se ha mencionado anteriormente, pero merece la pena recordarlo de nuevo: antes de que haga parecer el contexto contra el control como una utopía que todo el mundo puede alcanzar, recuerda que dirigimos un negocio en el que si tenemos un fallo, puede que no se entreguen los flujos. No tenemos aviones que caen del cielo ni máquinas cardíacas que se paran. Eso nos da más flexibilidad sobre dónde nos situamos en el espectro contexto-contra-control.

David: ¿Significa esto que un enfoque basado en el contexto funciona a escalas menores, pero no tan bien a escalas mayores?

Coburn: Creo que la "escala" a la que funciona el contexto sobre el control tiene poco que ver con el tamaño del entorno de producción o la base de clientes. Tiene más que ver con el tamaño de la organización y la forma de operar entre equipos. A medida que crece una organización, el uso eficaz del contexto para la disponibilidad puede suponer un reto. Un factor clave puede ser que haya menos comunicación individual o tiempo cara a cara a medida que crece la empresa.

En Netflix, tengo el lujo de que todos los equipos de ingeniería con los que me relaciono residen en un mismo campus. Puedo tomarme un café con cualquier directivo de Netflix. He trabajado en grandes empresas como HP con equipos situados al otro lado del globo. En esa situación global, sigo consiguiéndoles el contexto adecuado, pero requiere más trabajo darles un contexto eficaz. Mi suposición es que si una empresa se inclina y empieza por el control es principalmente porque (independientemente de la escala) se sienten mucho más cómodos dirigiendo con procesos y control.

David: ¿Hay alguna forma de que la infraestructura juegue un papel en la fiabilidad en relación con el contexto?

Coburn: En nuestra perspectiva de modelo push, consideramos que tenemos una gran fiabilidad porque somos inmutables por naturaleza. Creo que todos hemos trabajado en empresas en las que actualizamos algo, y resulta que era malo y nos pasamos la noche luchando contra el fuego porque intentamos que el sitio vuelva a funcionar porque el parche no funcionó. Cuando vamos a poner nuevo código en producción, nunca actualizamos nada, sólo introducimos una nueva versión junto con el código base actual. Es eso de rojo/negro o azul/verde, como lo llame la gente en su empresa. Introducimos la nueva versión del código y, si algo se rompe en la versión canaria, simplemente la retiramos e inmediatamente volvemos atrás, o ni siquiera llevamos a cabo la implementación completa. Esto reduce la recuperación de posiblemente horas a minutos.

Aunque tenemos Implementaciones de código inmutables, también tenemos algo llamado Propiedades rápidas. Esto significa que podemos entrar en producción con la capacidad posterior de actualizar dinámicamente una propiedad de la aplicación. Dado que esto rompe nuestro modelo inmutable pero a menudo es necesario, vemos que esta capacidad se utiliza en exceso y provoca incidentes en producción. Al igual que ocurre con otros problemas comunes en producción, si vemos que un equipo o conjunto de equipos tropieza con el problema de la gestión dinámica de propiedades, buscamos formas de eliminar el riesgo mediante herramientas mejoradas. En nuestro entorno de producción, ahora utilizamos Spinnaker, nuestra plataforma de entrega continua, para gestionar despliegues escalonados de propiedades dinámicas con el fin de minimizar el radio de explosión e identificar los problemas con antelación. Nos referimos a esta estrategia general como "barandilla".

Incluso una vez que hemos hecho eso, a veces los equipos siguen yendo a cambiar algo manualmente en lugar de pasar por un conducto rápido de propiedades y rompen la producción. Si vuelve a ocurrir, decimos: "Vale, está claro que no han entendido el mensaje. Tenemos que reunirnos con ellos y decirles: 'por favor, no pulséis este botón'". Intentamos a toda costa no quitar el botón, pero en algún momento, probablemente lo haremos.

David: Esto plantea una pregunta sobre los circuitos de retroalimentación. Parece que algunas de tus señales de retroalimentación son "¿se cayó el sitio?", "¿tendió algo a positivo?", o en términos de dinero "¿tendió a negativo de la forma que querías?". ¿Hay alguna forma más directa de que los humanos comprendan si obtuvieron el contexto que necesitaban, aparte de observar el sistema a modo de caja negra y ver si los indicadores que estabas observando cambiaban?

Coburn: Esa es una de las evoluciones que hemos hecho a medida que nuestra empresa ha crecido. En Netflix tenemos probablemente 2.000 ingenieros, y eso abarca todos los dominios de productos diferentes. Yo podría estar construyendo una interfaz de usuario de herramientas internas, un motor de codificación, preparando una pila de infraestructura o algo para ofrecerte mejores recomendaciones. Algunos de esos esfuerzos tienen un impacto más significativo que otros en la disponibilidad de cara al cliente. Desde una perspectiva numérica, probablemente el 50% de nuestros equipos de ingeniería en un día determinado pueden hacer lo que quieran en producción y no tiene ningún riesgo posible para la disponibilidad de nuestro servicio en modo alguno.

Al principio solíamos pasearnos por la sala golpeando la sartén virtual y gritando: "¡Eh, nuestra disponibilidad está en tres nueves; esto es un problema!". El problema es que es un mensaje muy difuso y el 50% de la gente dice: "Vale, genial, dices que la disponibilidad no es buena, pero ¿qué puedo hacer al respecto, ya que mis servicios no pueden afectar a la disponibilidad?".

Entonces, cambiamos nuestro mensaje para centrar el golpe de la sartén en los equipos que realmente afectan a la disponibilidad, que podrían ser el otro 50% de la población. Así que, ahora, al menos nuestro mensaje sobre la disponibilidad del servicio está llegando al público adecuado. El siguiente paso es canalizar el contexto, que es específico para cada equipo de ingeniería y les permite evaluar si tienen una disponibilidad por debajo de lo normal.

Pero incluso averiguar a quién proporcionar esta información no siempre es fácil. En una arquitectura de microservicios, puede haber más de 40 equipos que tengan microservicios funcionando en un momento dado, lo que puede afectar a la disponibilidad en la ruta crítica del servicio. Si estamos midiendo la disponibilidad en el perímetro de nuestro servicio y determinamos que una décima parte del 1% de los usuarios no pudieron reproducir películas en una hora determinada, es bastante difícil identificar qué equipo podría haber provocado realmente esa interrupción. Aún más difícil es que, en muchos casos, la causa sea externa. Como ejemplo, piensa en una plataforma de juegos en línea que necesita estar disponible para jugar a un título en el servicio. En ese caso, tal vez tenga que acudir al equipo de interfaz de usuario de Netflix que depende de ese servicio y ver si pueden crear resiliencia ante el fallo del servicio del proveedor externo (cosa que hemos hecho).

Me parece útil ser claro dentro de tu organización al referirte a los términos "disponibilidad" y "fiabilidad". Como analogía a cómo utilizamos estos términos en Netflix en el contexto de nuestro servicio de streaming, me refiero a una matriz de discos que podría formar parte de una Red de Área de Almacenamiento. Si la matriz de discos representa el servicio, las unidades de disco subyacentes en la matriz representarían microservicios. El diseño de la matriz de discos tiene en cuenta que las unidades individuales pueden fallar, pero la matriz debe seguir funcionando tanto para servir como para persistir los datos. Utilizando este modelo, calcularías la disponibilidad como el porcentaje de tiempo que la matriz de discos (el servicio de streaming Netflix, en mi mundo) es capaz de prestar servicio a un cliente. El ritmo al que fallan los discos en el array representa la fiabilidad del disco (en mi caso, un microservicio).

Al igual que con las configuraciones de matrices de discos (configuración RAID, almacenamiento en caché, etc.), puedes aplicar patrones operativos en una arquitectura de microservicios para mejorar la disponibilidad general del servicio ante posibles fallos de los microservicios. Un ejemplo en uso en Netflix es el marco Hystrix, basado en el patrón bulkhead, que abre "circuitos" entre microservicios cuando falla un microservicio descendente. El marco sirve de experiencia alternativa cuando es posible seguir prestando servicio a un usuario final.

En conclusión, establecer y medir los objetivos de fiabilidad a nivel de microservicio te permite avanzar hacia una disponibilidad agregada deseada a nivel de servicio. Diferentes organizaciones pueden utilizar los términos disponibilidad y fiabilidad de forma diferente, pero así es como nosotros los definimos a la luz de nuestro modelo operativo.

David: Entonces, ¿qué tipo de información puedes dar a ese equipo que sea procesable?

Coburn: Otra empresa con la que hablé tenía un informe de disponibilidad de microservicios. Se fijaban en la tasa de éxito de las llamadas de los servicios a su vecino. Si soy un servicio que gestiona la información de suscriptores o miembros y tengo 30 servicios que me hablan, mi principal medida de disponibilidad debería ser la tasa de éxito que tienen mis dependencias. Muchas veces, los equipos se centran en su visión del lado del servicio de estar en funcionamiento. Esto no garantiza que estés atendiendo correctamente las peticiones al ritmo deseado, pero todo se reduce a las medidas.

Nos gustó el modelo de la otra empresa y buscamos la forma de aplicarlo a nuestra propia infraestructura. Por suerte, tenemos un marco común de IPC [comunicación entre procesos] y disponemos de métricas en torno a Hystrix y otros comandos que registran la tasa a la que un cliente (servicio dependiente) está teniendo llamadas con éxito. Agregamos esta información para todos nuestros microservicios críticos y comparamos la tendencia con los 30 días anteriores. No pretende ser casi en tiempo real, sino más operativo: ¿estás mejorando o empeorando?

Supongamos que un equipo posee tres microservicios, y el objetivo es que los microservicios tengan una disponibilidad de cuatro nueves para las llamadas de los clientes. Si estos microservicios se mantienen por encima de cuatro nueves, el equipo nunca recibirá un correo electrónico (informe de disponibilidad). Si los últimos 7 días comparados con los 21 anteriores tienen una desviación de forma negativa, o si los microservicios no consiguen alcanzar los cuatro nueves, se enviará un informe al equipo. El informe muestra semana a semana como un gráfico de barras. El color verde indica que estás alcanzando el objetivo para una semana determinada. Rojo o amarillo significa que no estás logrando el objetivo. El amarillo significa mejora respecto a la semana anterior; el rojo indica degradación. Si haces clic en una barra del gráfico, obtendrás un informe detallado que muestra, para toda la ventana, las tasas de llamadas de los servicios ascendentes (cliente) que hablan con el microservicio y la disponibilidad para esas llamadas. En el panel derecho hay una vista de las tasas de llamadas y de éxito de la dependencia descendente, lo que resulta útil porque la disponibilidad del microservicio puede verse reducida por la dependencia descendente. A esta implementación interna la llamamos "cuadro de mando de disponibilidad de microservicios". Llegados a este punto, el equipo de SRE (que trabaja con Análisis de Datos) ha proporcionado información a un equipo sobre los microservicios que poseen, y en particular sobre su disponibilidad de microservicios para los servicios de clientes dependientes, independientemente de la disponibilidad del servicio Netflix. Debería ser una información muy procesable. Cuando se envían cuadros de mando continuamente a los ingenieros, pueden dejar de mirarlos con relativa rapidez. La solución de SRE en Netflix consiste en enviar un cuadro de mando sólo cuando cambie algo a lo que un equipo deba prestar atención.

David: Esto suena bastante reactivo, ¿verdad? Les envías un cuadro de mando porque te gustaría que algo que ya ha ocurrido fuera diferente en el futuro. ¿Cuál es el lado proactivo de esto? ¿Cómo ayudas a alguien que está intentando tomar una buena decisión mucho antes de que reciba un cuadro de mando?

Coburn: Una buena analogía para el cuadro de mando es un mensaje en el salpicadero de tu coche indicando "tu neumático delantero derecho está perdiendo presión". No te dice qué hacer al respecto, sólo te informa de que una tendencia va en la dirección equivocada. Al pensar en la mejor forma de informar a la gente, aproveché la experiencia de trabajos anteriores en el ámbito del rendimiento, donde no nos preocupa tanto detectar las grandes desviaciones de rendimiento. Tenemos canarios que evalúan un sistema en busca de desviaciones significativas, de modo que si la demanda de CPU da un salto del 20% en una pulsación, empiezan a saltar las alarmas. Lo que acaba afectándote a largo plazo es el aumento de cinco milisegundos semana tras semana durante un periodo de seis meses. Al final del cual dices: "Vaya, de repente estoy funcionando con el triple de capacidad para ese servicio; ¿qué ha pasado?". La función del cuadro de mando es detectar también las desviaciones más pequeñas para evitar esa deriva lenta y peligrosa. Creo que la situación análoga para la fiabilidad es que si ignoras las pequeñas desviaciones y no las abordas proactivamente, sólo estás esperando la gran interrupción.

David: Vale, entonces, ¿qué haces desde una perspectiva contextual para permitir que la gente tome las decisiones correctas en el momento? En teoría, el concepto de presupuesto de errores significa que en cualquier momento T, tengo una forma de determinar en ese momento si debo hacer o no hacer algo como lanzar una nueva versión. ¿Cuál es la versión contextual de esto? ¿Es la teoría de que la gente mira un cuadro de mando sincrónicamente y luego toma la decisión correcta?

Coburn: Si alguien tiene un problema que está afectando significativamente a la disponibilidad real de la producción, como tener constantemente incidentes de producción que hacen que los clientes no puedan transmitir contenido, entonces el contexto del cuadro de mando de disponibilidad de microservicios probablemente no sea la forma de resolver ese problema. En ese caso, lo más probable es que hayan estado recibiendo el informe pero no actuando en consecuencia. La forma de resolver ese problema es reunirse en una sala y trazar un camino a seguir. Eso no significa que deban dejar de enviar código, porque tienen muchos otros servicios que dependen de ellos.

En cuanto a tu pregunta sobre más información en tiempo real para ayudar a los ingenieros a tomar mejores decisiones de implementación en el momento, nos esforzamos por poner la información dentro de las herramientas con las que trabajan. Spinnaker expone ahora las tendencias de disponibilidad en el clúster (el término de AWS es Grupo de Autoescalado) y está justo delante del ingeniero si está haciendo un cambio a través de la interfaz de usuario.

Cuando nos fijamos en la mejora continua de la disponibilidad, el objetivo se divide en dos categorías principales: evitar todos los incidentes, independientemente del tipo, y un patrón de fallo específico que alguien tenga y que esté causando un incidente o una interrupción repetida.

Desde una perspectiva contextual, si tienen un problema en el que están tomando una serie de decisiones una y otra vez que dan lugar a incidentes que afectan a la producción, eso requiere un informe entregado por un humano frente a un informe entregado por un sistema. En Netflix, el equipo Core SRE no tiene la responsabilidad de intervenir y solucionar problemas específicos de los microservicios, sino que el equipo se considera el "sistema nervioso central de Netflix". Llevando la analogía del sistema nervioso central un poco más lejos, éste es el único equipo de Netflix que ve todos los fallos, ya sean externos, internos, de CDN [Red de Entrega de Contenidos], de red, etc., con la consiguiente responsabilidad de determinar a qué equipos hay que dirigirse e implicar.

David: Considerando a tu grupo como el sistema nervioso de Netflix, ¿qué proceso tienes para propagar la información por toda la org para que la gente de una parte pueda aprender de las otras partes (ya sea una buena forma de hacer algo o no repetir una mala experiencia)?

Coburn: En función de la deficiencia específica en riesgo operativo que queramos abordar, tenemos un par de canales para conseguir que se apliquen las buenas prácticas: impulsar las mejoras necesarias en nuestras herramientas operativas (por ejemplo, Spinnaker, análisis canario) para exponerlas sin problemas a todos los equipos o socializar el cambio sugerido a través de un boletín de disponibilidad que se publica mensualmente. En algunos casos, la buena práctica sugerida es una de las extensiones de las herramientas previamente incorporadas a las mismas.

Ambos son métodos que ayudan a mover la aguja de la disponibilidad de forma agregada.

Algunos cambios que incorporamos a las herramientas podrían denominarse barandillas. Un ejemplo concreto es un paso adicional en la implementación añadido a Spinnaker que detecta cuando alguien intenta eliminar toda la capacidad del clúster mientras sigue tomando cantidades significativas de tráfico. Este quitamiedos ayuda a llamar la atención sobre una acción posiblemente peligrosa, que el ingeniero no sabía que era arriesgada. Se trata de un método de contexto "justo a tiempo".

David: ¿Qué ocurre en los casos en que alguien utiliza una de tus herramientas, como Hystrix, de una forma que es perfectamente válida, pero la experiencia ha demostrado que esa forma da resultados negativos? No es el caso de que quieras cambiar la herramienta porque la herramienta está muy bien. ¿Cómo se propaga una experiencia así por la organización una vez aprendida la lección? ¿Parece que los informes de disponibilidad serían un ejemplo de ello?

Coburn: Así es. El informe de disponibilidad es realmente difícil de interpretar. Una vez que lo recibes, tienes que hacer clic en tres o cuatro lugares estratégicos (y a menudo ocultos) del informe sólo para llegar a los datos procesables. Esto supuso una barrera bastante importante para la adopción, por lo que creamos un vídeo de cuatro minutos para que funcionara como tutorial de incorporación al uso del informe. Cuando la gente recibe el informe, dice que por favor vea este vídeo de cuatro minutos para entender cómo utilizar este informe. No movió la aguja del todo, pero sin duda mejoró la capacidad de acción del informe para quienes se tomaron la molestia de utilizarlo.

David: Hablemos de las limitaciones del contexto frente al control. ¿Crees que un sistema basado en el contexto funciona igual de bien en un entorno en el que el producto y sus métricas son más complejos que Netflix? ¿Es la simplicidad del producto Netflix lo que hace que funcione tan bien para ti?

Coburn: En primer lugar, señalaría que, en conjunto, el servicio de Netflix (en términos de sus partes interactuantes) es tan complejo como cualquier otro. Hay una serie de factores que permiten que el contexto sea más ampliamente eficaz en Netflix que en otras empresas. Está directamente relacionado con la falta de complejidad de la organización de ingeniería y la estructura de nuestro servicio. Los siguientes son algunos de los factores clave:

• Tenemos a todos los ingenieros sentados en un mismo lugar. Los principios comunes de ingeniería se socializan fácilmente y el conocimiento tribal adicional de las buenas prácticas se socializa y discute implícitamente.

• Tenemos una versión dominante del software que se ejecuta en una región determinada en un momento dado. Además, tenemos el control sobre esa pila de software y podemos cambiarla cuando queramos (no se envía a los clientes, a excepción de las aplicaciones de los dispositivos).

• Tenemos un servicio en el que la gente no muere si se rompe.

• Tenemos un poco de recorrido y contamos con un equipo de SRE que está dispuesto a recibir un montón de balas si la disponibilidad empeora y a decir "mi trabajo es arreglarlo".

En cuanto a este último punto, puede resultar algo difícil para la organización de fiabilidad decir que es responsable de mejorar la disponibilidad, pero al mismo tiempo no tener un control total sobre los factores que influyen en la disponibilidad. Mucha gente no se siente cómoda diciendo que es responsable de mejorar algo sobre lo que no tiene necesariamente un control absoluto.

En una empresa en la que envías un producto sobre el terreno (por ejemplo, el software de un coche autoconducido), este modelo podría no funcionar. No querrías esperar y decir: "Vaya, mira, ese coche se ha salido de la carretera. Ha sido un error. ¿Quién lo ha escrito? Bueno, hagámoslo bien el año que viene". En cambio, el espacio en el que operamos permite bastante margen para aprovechar el contexto sobre el control, ya que no ponemos vidas en peligro y podemos hacer cambios rápidamente en el entorno del producto agregado. Dicho esto, creo que se pueden ver situaciones en las que las empresas empiezan a escalar en las que empezaron con el contexto, pero con el tiempo pasan a tener un poco más de control, según lo justifiquen las necesidades del cliente y la fiabilidad. Podrías generalizar esta perspectiva en el sentido de que con el tiempo te moverás más hacia el otro extremo del espectro desde el que empezaste, aunque sólo sea un poco.

David: En el pasado hemos hablado un poco del contexto frente al control desde la perspectiva de la inversión en ingeniería. ¿Puedes hablar un poco más de ello?

Coburn: Pienso en cuatro dimensiones principales: ritmo de innovación, seguridad, fiabilidad y eficacia (infraestructura/operaciones). Dependiendo de cómo esté estructurada tu organización, podrías ser dueño de una o varias de las dimensiones. Aunque no seas dueño de una dimensión determinada, las decisiones que tomes en tu propio espacio pueden tener repercusiones significativas en las demás. Yo estoy en una situación en la que poseo al menos dos, fiabilidad y eficiencia, porque también poseo la planificación de la capacidad. Cuando pienso en lo mucho que quiero presionar a los equipos para que mejoren esas dimensiones, quiero intentar lo menos posible reducir el arrastre sobre las otras (ritmo de innovación, seguridad). Mantener este modelo en mente nos permite, como organización de SRE, ser más reflexivos a la hora de preguntar a otros equipos de ingeniería.

Algo relacionado, también hacemos concesiones explícitas para mejorar una dimensión a costa de otra. Tenemos casos en los que funcionamos de forma significativamente ineficiente (sobreaprovisionados) para un microservicio determinado con el fin de aumentar la tasa de innovación o la fiabilidad. Si tenemos un servicio que necesita funcionar con el doble de margen debido a la explosión del tráfico, no me importa si eso me cuesta decenas de miles de dólares más al año, porque todo lo que necesito es una gran interrupción para quemar rápidamente esa cantidad de esfuerzo/tiempo de ingeniería.

David: Vale, ¿y cómo relacionas eso con el contexto frente al control?

Coburn: Con el control como ejemplo, digamos que en realidad quito a alguien la capacidad de empujar código porque necesito aumentar esta dimensión de fiabilidad. Por un lado detiene la rotura a corto plazo, pero ralentiza la innovación. El objetivo es intentar proporcionar más contexto para evitar ralentizar a la fuerza otras dimensiones y dejar que el propietario de un servicio determinado determine qué dimensión optimizar, teniendo en cuenta sus demandas actuales. En cambio, el control tiene un efecto mucho más binario sobre otras dimensiones.

David: ¿Tiene el contexto un efecto positivo o negativo en alguna de esas dimensiones? El control lo tiene claramente, como acabas de mencionar, pero ¿y el contexto?

Coburn: Context tiene un fuerte recorrido y un historial, al menos en nuestro caso. En los últimos cinco años, nuestra población de clientes se ha multiplicado por seis, nuestro streaming se ha multiplicado por seis, nuestra disponibilidad ha mejorado cada año, nuestro número de equipos ha aumentado cada año y nuestro ritmo de innovación ha subido cada año. Eso sin aplicar el control para mejorar la disponibilidad, sino predominantemente mejorando a través del contexto combinado con la mejora de la plataforma para que los ingenieros pasen menos tiempo trabajando en aspectos operativos que no deberían ser necesarios en su función (como determinar cómo configurar las canalizaciones para tener empujes escalonados a través de las regiones).

David: Si el control puede tener un efecto negativo en esas dimensiones, ¿puede el contexto tener un efecto adverso similar?

Coburn: Puede, pero aún no he visto que el contexto que proporcionamos a los equipos dé lugar a un comportamiento no deseado que perjudique realmente la disponibilidad. Un área en la que esto puede ser un riesgo es la eficiencia de la infraestructura. Aunque proporcionamos a los equipos un contexto detallado de los costes de infraestructura, no tenemos ni imponemos a los equipos presupuestos de costes de nube. Por ejemplo, los ingenieros simplemente implementan cualquier infraestructura que necesiten y reciben un informe de costes cada mes que les proporciona contexto sobre su coste. Con este contexto, un equipo optó por intentar optimizar la eficiencia permaneciendo en un tipo de instancia más antiguo y menos fiable, que por supuesto era mucho menos caro. Entonces se produjo una interrupción debida a instancias de bajo rendimiento y menos fiables, que a menudo funcionaban con un aprovisionamiento insuficiente. En este caso, proporcionamos un contexto de costes, la decisión fue sobreindexar la eficiencia y, como resultado, la fiabilidad se vio afectada. Decidimos socializar con los equipos que preferíamos funcionar con menos eficiencia que comprometer la fiabilidad, en consonancia con nuestra priorización explícita de las preocupaciones de dominio.

Biografía del colaborador

Coburn Watson es actualmente socio de la organización de Ingeniería de Infraestructura de Producción de Microsoft. Recientemente concluyó una aventura de seis años en Netflix, donde dirigió la organización responsable de la fiabilidad del sitio, la ingeniería del rendimiento y la infraestructura de la nube. Sus más de 20 años de experiencia en el ámbito tecnológico abarcan desde la gestión de sistemas hasta el desarrollo de aplicaciones y la fiabilidad y el rendimiento de sitios a gran escala.

¹ Véase el Capítulo 4, "Objetivos de Nivel de Servicio", del primer libro de Google sobre Ingeniería de la Fiabilidad del Sitio Web.