1. Contexto frente a Control en la SRE

Una discusión 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 común de practicar SRE). ¿Podemos profundizar un poco más en esto? ¿Puede explicar a qué se refiere con 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 compartido 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 descendentes. 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, pero si no lo consigue, puede que se tome una medida punitiva. Esta acción podría implicar la eliminación de su capacidad para 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 suficiente contexto 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 que se transmite al equipo, en particular el contexto relacionado con la fiabilidad. Esas son las lagunas que tratamos de 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 contexto adicional si los aviones están cayendo del cielo. Depende de cada organización de SRE determinar cuánto riesgo pueden asumir como uno de los factores para encontrar la división entre un modelo basado en el contexto y uno basado en el control.

Creo que hay una diferencia entre información y contexto. En la monitorización 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 normal que reciba un correo así lo ignorará porque: 1) se encarga de escribir la lógica de negocio 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 transformarla en un formato que cuente una historia sobre la disponibilidad. Al aplicar esta transformación, podemos transmitir este contexto a los equipos en función de las necesidades para que puedan medir si mejora la disponibilidad de un microservicio determinado. Por ejemplo, una métrica de disponibilidad clave 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 de cliente o cambió una configuración de tiempo de espera. Como ya se ha dicho, es importante partir del principio de que las personas no están actuando 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, puede desviarse hacia el control necesario cuando vea 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 el código se pase a producción, y entonces, por supuesto, los ingenieros acuden a la dirección porque necesitan pasar código a producción. En Netflix voy a empezar con la discusión “estás en mi lista” con un gerente de ingeniería, lo que implica en persona el establecimiento de niveles adicionales en torno a las expectativas de disponibilidad del servicio. Si hay un punto de vista común, menciono que están desarrollando muchas funciones, pero no abordan los cambios necesarios para mejorar la disponibilidad. Concluyo preguntando: “¿Cómo podemos incluirlas en su lista?”. En mi mente, ese es el grado de control que realmente quiero. Tengo la 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.

Aunque ya se ha mencionado anteriormente, merece la pena volver a recordarlo: antes de que el contexto frente a control parezca una utopía que todo el mundo puede alcanzar, recuerda que dirigimos un negocio en el que, si hay 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-frente a-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 cómo funcionan entre los 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 una menor comunicación uno a uno o tiempo cara a cara a medida que la empresa crece.

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 director de Netflix. He trabajado en grandes empresas como HP, con equipos situados al otro lado del mundo. En esa situación global, todavía les consigo el contexto apropiado, pero requiere más trabajo dar un contexto efectivo. Mi hipótesis es que si una empresa se inclina y empieza con el control es principalmente porque (independientemente de la escala) se sienten mucho más cómodos liderando con procesos y control.

David: ¿Hay alguna forma en que la infraestructura influya 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 defectuoso y nos pasamos la noche luchando contra los incendios porque intentamos volver a poner en marcha el sitio porque el parche no funcionaba. 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 ese 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 “canario”, la retiramos y la volvemos a instalar inmediatamente, o ni siquiera llevamos a cabo el despliegue completo. Esto reduce la recuperación de horas a minutos.

Aunque tenemos despliegues de código inmutable, también tenemos algo llamado Propiedades Rápidas. Esto significa que podemos entrar en producción con una capacidad posterior para 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 conduce a incidentes de producción. Al igual que otros problemas comunes en producción, si vemos que un equipo o un conjunto de equipos tropiezan 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 los 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 “quitamiedos”.

Incluso una vez que hemos hecho esto, a veces los equipos siguen yendo a cambiar algo manualmente en lugar de pasar por una canalización rápida de propiedades y rompen la producción. Si vuelve a ocurrir, decimos: “Está claro que no han entendido el mensaje. Tenemos que reunirnos con ellos y decirles: 'Por favor, no pulses 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 ha caído el sitio?”, “¿ha habido una tendencia positiva?”, o en términos de dinero “¿ha habido una tendencia negativa en el sentido que querías?”. ¿Hay alguna forma más directa de saber si los humanos obtuvieron el contexto que necesitaban, aparte de observar el sistema como una caja negra y ver si los indicadores que estabas mirando 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 creando una interfaz de usuario de herramientas internas, un motor de codificación, creando una pila de infraestructura o algo para ofrecer mejores recomendaciones. Algunos de estos esfuerzos tienen un impacto más significativo en la disponibilidad de cara al cliente que otros. Desde una perspectiva numérica, probablemente el 50% de nuestros equipos de ingenieros 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 de ninguna manera.

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: “Está bien, genial, estás diciendo 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ía ser el otro 50% de la población. Así que, ahora, al menos nuestro mensaje sobre la disponibilidad de los servicios 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 los estándares.

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 en ejecución 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 borde 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. Y aún más difícil es que, en muchos casos, la causa sea externa. Por ejemplo, pensemos 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 cuando te refieres 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 para servir y persistir los datos. Usando este modelo, se calcularía la disponibilidad como el porcentaje de tiempo que la matriz de discos (el servicio de streaming de Netflix, en mi mundo) es capaz de proporcionar servicio a un cliente. La tasa a la que fallan las unidades en la matriz representa la fiabilidad de la unidad (en mi caso, un microservicio).

Al igual que con las configuraciones de matrices de discos (configuración RAID, almacenamiento en caché, etc.), se pueden aplicar patrones operativos en una arquitectura de microservicios para mejorar la disponibilidad general del servicio ante posibles fallos del microservicio. 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. Cuando es posible, el marco ofrece una experiencia alternativa para seguir prestando servicio al usuario final.

En conclusión, establecer y medir los objetivos de fiabilidad a nivel de microservicio permite avanzar hacia una disponibilidad agregada deseada a nivel de servicio. Las distintas 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 puede 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 a la que los servicios proporcionaban llamadas satisfactorias a su vecino. Si soy un servicio que gestiona la información de suscriptores o miembros y tengo 30 servicios que se comunican conmigo, mi principal medida de disponibilidad debería ser la tasa de éxito de mis dependencias. Muchas veces, los equipos se centran en su visión del lado del servicio de estar en funcionamiento. Esto no garantiza que se estén atendiendo correctamente las solicitudes 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 [interprocess communication (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 satisfactorias. 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?

Digamos 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 se está alcanzando el objetivo para una semana determinada. Rojo o amarillo significa que no se ha alcanzado el objetivo. El amarillo significa mejora con respecto a la semana anterior; el rojo indica degradación. Si hace clic en una barra del gráfico, obtendrá un informe detallado que muestra, para toda la ventana, las tasas de llamadas de los servicios ascendentes (cliente) que se comunican con el microservicio y la disponibilidad de esas llamadas. En el panel de la derecha hay una vista de las tasas de éxito y de llamadas de la dependencia descendente, lo que resulta útil ya que la disponibilidad del microservicio puede verse reducida por la dependencia descendente. Llamamos a esta implementación interna “marco de puntuación de disponibilidad de microservicios”. En este punto, el equipo de SRE (que trabaja con Data Analytics) ha proporcionado información a un equipo sobre los microservicios que poseen y, en particular, su disponibilidad de microservicios para los servicios de clientes dependientes, independientemente de la disponibilidad del servicio de Netflix. Debería ser información muy útil. Cuando los cuadros de mando se envían 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 solo cuando cambia algo a lo que un equipo deba prestar atención.

David: Entonces, 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 su coche que indica “su neumático delantero derecho está perdiendo presión”. No te dice qué hacer al respecto, sólo te informa de que la tendencia va en la dirección equivocada. A la hora de pensar en la mejor manera 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 se dispara un 20% en un empujón, las alarmas empiezan a saltar. 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 es análoga en el caso de la fiabilidad: si se ignoran las pequeñas desviaciones y no se abordan de forma proactiva, se está a la espera de la gran interrupción.

David: Bien, ¿qué se hace desde una perspectiva contextual para que la gente pueda tomar 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 que la gente mira un cuadro de mando sincrónicamente y luego toma la decisión correcta?

Coburn: Si alguien tiene un problema que afecta significativamente a la disponibilidad real de la producción, como incidentes de producción constantes que impiden a los clientes transmitir contenido, el contexto del cuadro de mando de disponibilidad de microservicios probablemente no sea la forma de resolver el problema. En ese caso, lo más probable es que hayan estado recibiendo el informe pero no hayan actuado en consecuencia. La forma de resolver ese problema es reunirse en una sala y encontrar una forma de avanzar. Esto 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 despliegue en el momento, nos esforzamos por poner la información dentro de las herramientas con las que trabajan. Spinnaker ahora expone las tendencias de disponibilidad en el clúster (el término de AWS es Autoscaling Group) y está justo delante del ingeniero si están 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 tiene que está causando un incidente o interrupción repetida.

Desde una perspectiva contextual, si están teniendo 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 humanos frente a un informe entregado por el sistema. En Netflix, el equipo Core SRE no tiene la responsabilidad de intervenir y solucionar problemas específicos de 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, este es el único equipo en Netflix que ve todos los fallos, ya sean externos, internos, de CDN [Content Delivery Network], de red, etc., con la responsabilidad resultante de determinar a qué equipos hay que llegar e involucrar.

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

Coburn: En función de la deficiencia específica en el riesgo operativo que queramos abordar, tenemos un par de canales para conseguir que se aplique la mejor práctica: 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 mejor práctica sugerida es una de las extensiones de herramientas incorporadas previamente a las herramientas.

Ambos son métodos para ayudar a mover la aguja de la disponibilidad de forma agregada.

Algunos cambios que incorporamos al utillaje podrían denominarse “quitamiedos”. Un ejemplo concreto es un paso adicional en el despliegue añadido a Spinnaker que detecta cuando alguien intenta eliminar toda la capacidad del clúster mientras sigue recibiendo cantidades significativas de tráfico. Esta barandilla ayuda a llamar la atención sobre una acción posiblemente peligrosa, de la que el ingeniero no era consciente. Se trata de un método de contexto “justo a tiempo”.

David: ¿Qué ocurre en los casos en que alguien utiliza una de sus 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 querer cambiar la herramienta porque la herramienta está muy bien. ¿Cómo se propaga esta experiencia en la organización una vez que se ha aprendido 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. Esta era una barrera bastante importante para la adopción, por lo que creamos un vídeo de cuatro minutos para que funcionara como un tutorial de incorporación para el uso del informe. Cuando los usuarios reciben el informe, se les pide que vean este vídeo de cuatro minutos para saber cómo utilizarlo. No fue un éxito rotundo, pero sin duda mejoró la capacidad de acción del informe para quienes se tomaron el tiempo de utilizarlo.

David: Hablemos de las limitaciones del contexto frente al control. ¿Cree 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 en Netflix? ¿Es la simplicidad del producto Netflix lo que hace que funcione tan bien para usted?

Coburn: En primer lugar, me gustaría señalar que, en conjunto, el servicio de Netflix (en términos de sus partes interactivas) 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 en la organización de ingeniería y la estructura de nuestro servicio. Estos son algunos de los factores clave:

• Tenemos a todos los ingenieros reunidos en un mismo lugar. Los principios comunes de ingeniería se socializan fácilmente y el conocimiento tribal adicional de las mejores 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 dispositivos).
• Tenemos un servicio en el que la gente no muere si falla.
• Tenemos un poco de pista de aterrizaje y tenemos un equipo SRE que está dispuesto a recibir un montón de balas si la disponibilidad empeora y decir “mi trabajo es arreglarlo”.

En cuanto a este último punto, puede ser un poco difícil para la organización de fiabilidad decir que son responsables de mejorar la disponibilidad, pero al mismo tiempo no tienen un control total sobre los factores que afectan a 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 se distribuye 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 y comienzan 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. Se podría generalizar esta perspectiva en el sentido de que, con el tiempo, se irá más hacia el otro extremo del espectro desde el que se empezó, 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. ¿Puede hablarnos un poco más de ello?

Coburn: Pienso en cuatro dimensiones principales: ritmo de innovación, seguridad, fiabilidad y eficiencia (infraestructura/operaciones). Dependiendo de cómo esté estructurada su organización, podría ser propietaria de una o varias de las dimensiones. Incluso si no posee una dimensión determinada, las decisiones que tome en su 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). Tener presente este modelo nos permite, como organización de SRE, ser más reflexivos a la hora de preguntar a otros equipos de ingeniería.

Algo relacionado con esto, también hacemos concesiones explícitas para mejorar una dimensión a costa de otra. Tenemos casos en los que ejecutamos de forma significativamente ineficiente (sobreaprovisionamiento) 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: Bien, ¿y cómo relaciona eso con el contexto frente al control?

Coburn: Con el control como ejemplo, digamos que le quito a alguien la capacidad de introducir código porque necesito aumentar esta dimensión de fiabilidad. Por un lado, esto detiene las roturas 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: ¿El contexto tiene un efecto positivo o negativo en alguna de esas dimensiones? Está claro que el control sí, como acaba de decir, pero ¿y el contexto?

Coburn: Al menos en nuestro caso, el contexto tiene un fuerte efecto positivo. 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. Y 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 todavía no he visto que el contexto que proporcionamos a los equipos provoque un comportamiento no deseado que realmente perjudique la disponibilidad. Un área en la que esto puede suponer un riesgo es la eficiencia de las infraestructuras. Aunque proporcionamos un contexto detallado de los costos de infraestructura a los equipos, no tenemos ni imponemos presupuestos de costos de nube a los equipos. Por ejemplo, los ingenieros simplemente despliegan cualquier infraestructura que necesiten y reciben un informe de costos cada mes que les proporciona contexto sobre su costo. Con este contexto, un equipo decidió intentar optimizar la eficiencia manteniendo un tipo de instancia más antiguo y menos fiable, que por supuesto era mucho más barato. 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 contexto de costos, la decisión fue sobreindexar en eficiencia, y como resultado la fiabilidad se llevó un golpe. Decidimos socializar con los equipos que preferíamos ser menos eficientes que comprometer la fiabilidad, en línea con nuestra priorización explícita de las preocupaciones de dominio.

Coburn Watson es actualmente socio de la organización de Ingeniería de Infraestructura de Producción en 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 de rendimiento y la infraestructura en 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.

Volver al índice