MTTR no es “Tiempo medio para reiniciar” (por sus siglas en inglés)

Fallar rápido es el mantra de la velocidad hoy en día. Ya sea DevOps o negocios, la premisa de operar en una economía digital exige un tiempo de actividad lo más perfecto posible.

Si bien la teoría de esta filosofía es buena, en la práctica el resultado suele ser simplemente más fracaso. Al no centrarnos en encontrar la causa raíz (MTTR) y, en cambio, solo en garantizar la disponibilidad (tiempo de actividad), estamos perdiendo datos valiosos a un ritmo sin precedentes. Afrontémoslo: cuando lo único que le importa es el tiempo de actividad, el MTTR se convierte en tiempo medio de reinicio en lugar de tiempo medio de resolución . Y sin una resolución (un motivo para el tiempo de inactividad), no se puede evitar que vuelva a suceder.

Este enfoque es perjudicial para el negocio.

Ya ves, no estás dejando caer paquetes, estás dejando caer partes de centavos. Y como nos enseña el clásico tropo criminal de desviar fracciones de centavos de las transacciones para acumular millones, cada fracción de centavo cuenta. Cada segundo en el que un componente, un servicio o un servidor no responde, estás perdiendo valor, tanto experiencial como existencial. Los consumidores no tolerarán un rendimiento deficiente ni tiempos de inactividad, y los libros contables de las empresas tampoco pueden tolerar ninguna de las dos cosas.

Y si sabe algo sobre rendimiento y ancho de banda, sabrá que la base de ambos cálculos radica en los paquetes por segundo que puede procesar el sistema subyacente. Esto no sólo es cierto en la red, sino para cada componente que interactúa con una transacción. La aplicación. Los servicios de la aplicação . Enrutadores. Interruptores. Bases de datos. Si tiene una conexión de red, está vinculado a este mismo cálculo y restringido por su capacidad para pasar paquetes.

ADVERTENCIA: MATEMÁTICAS AVANZAN

La velocidad de las redes actuales garantiza que hagamos exactamente eso a una velocidad de millones de paquetes por segundo. Las transacciones comerciales, por supuesto, se realizan principalmente a través de una red (literal) de transacciones HTTP, cada una de las cuales transmite información crucial para realizar negocios. La cantidad de paquetes necesarios para realizar una transacción depende de la cantidad de datos requeridos. El paquete promedio transporta 1500 bytes de datos (esa es la MTU). Entonces, si un mensaje basado en HTTP que lleva una carga JSON que representa una transacción requiere 4500 bytes (después del cifrado, por supuesto), eso equivale aproximadamente a tres paquetes. Seamos generosos y digamos que una transacción comercial digital típica requiere cinco paquetes. Una red de 10 Gbps puede procesar poco menos de 15 millones de paquetes por segundo. Suponiendo que hay suficiente capacidad computacional disponible, se podría decir que eso equivale a 3 millones de transacciones. Supongamos que cada transacción vale una fracción (un tercio) de un centavo. Eso es un millón de dólares por segundo.

Hoy en día, nadie procesa transacciones a esa velocidad o volumen. Incluso Visa, que indiscutiblemente procesa datos a velocidades que la mayoría de las empresas no requieren, afirma que su capacidad es de alrededor de 24.000 transacciones por segundo. Suponiendo el mismo valor de esas transacciones (un tercio de centavo), eso sigue siendo 8.000 dólares por segundo.

El punto es que una falla en la cadena de transacciones compuesta por enrutadores, conmutadores, infraestructura de servicios de aplicação y redes, infraestructura de aplicaciones y componentes es algo muy malo™. Es costoso porque una falla significa que los paquetes no se procesan, y tampoco los centavos que representan. Y no hay ninguna parte de la economía digital que no dependa del intercambio de paquetes.

La respuesta hasta ahora está en el mantra "fallar rápido": simplemente genere una nueva instancia de X o Y o Z o cualquier componente que haya fallado. Pero ese componente falló *por una razón* y es de suma importancia descubrir dicha razón y abordarla. Rápidamente. Porque todavía hay segundos costosos entre el fallo y la restauración que cuestan valor al negocio. Si falló una vez, es probable que falle otra vez. Y otra vez.

VISIBILIDAD: LA PIEDRA CLAVE SOBRE LA QUE SE APOYA MTTR

Es por esto que la visibilidad es tan fundamental para el éxito en la economía digital. Porque es la visibilidad la que permite a todas las operaciones encontrar y remediar la causa del fallo. Desafortunadamente, a menudo se sacrifica la visibilidad en aras de la velocidad. No se trata de la velocidad literal de las transacciones, sino del tiempo necesario para obtener valor. En nuestra prisa por lanzar aplicaciones al mercado con mayor rapidez y frecuencia, no hemos invertido lo suficiente en habilitar la visibilidad necesaria para mitigar las fallas.

De hecho, se podría argumentar que la filosofía de "fallar rápido" de DevOps es una respuesta a ese fracaso. Sin la capacidad de encontrar y abordar la causa de la falla, DevOps ha determinado que es mejor restaurar la disponibilidad que perder el tiempo. Esa capacidad se vuelve cada vez más difícil de alcanzar a medida que las organizaciones adoptan enfoques de múltiples nubes para implementar aplicações.

En 2018, el desafío de la visibilidad en múltiples nubes fue citado por menos de un tercio (31%). En 2019 , ese porcentaje aumentó a más de un tercio (39%), para empatarse con el rendimiento y la seguridad como los principales desafíos para las múltiples nubes. La visibilidad es un componente fundamental de la "observabilidad" general que reúne el monitoreo, el análisis y las alertas para brindar información valiosa sobre el estado de un sistema en cualquier momento. Esto es particularmente importante durante una falla, porque el estado del sistema se distribuye entre múltiples feudos de TI que pueden o no permitir compartir información que puede conducir rápidamente a una resolución en lugar de solo un reinicio .

La capacidad de una malla de servicios para agregar valor a través del rastreo distribuido es un excelente ejemplo de cómo habilitar la visibilidad. Pero necesitamos ampliar eso para incluir toda la cadena de servicios de aplicação que escalan y protegen las aplicações que se ejecutan en un mundo en contenedores. Y eso incluye componentes distribuidos y aplicações que se ejecutan en la nube pública y que pueden ser parte de la cadena de ejecución. Se requiere visibilidad en todos los entornos, la infraestructura y las aplicações para encontrar y abordar problemas que provocan tiempos de inactividad o un rendimiento deficiente.

La visibilidad es fundamental para permitir que las organizaciones vuelvan a medir el éxito en la resolución de MTT en lugar del reinicio de MTT.