Señales de que paga por una fiabilidad que no necesita

Se habla poco sobre la fiabilidad excesiva: la fiabilidad insuficiente se manifiesta con fallos, y la excesiva parece una virtud. La empresa paga por complejidad que no utiliza y lo considera prudencia.

Sin embargo, la complejidad introducida prematuramente no solo consume presupuesto. Añade nuevas maneras de fallar. Un sistema de diez componentes interconectados no falla en diez escenarios, sino en un número mucho mayor, y no todos son previsibles de antemano.

Por qué ocurre esto

Las causas rara vez son malintencionadas, y entenderlas es más útil que juzgarlas.

Los ingenieros eligen tecnologías no solo por la tarea, sino también por el mercado laboral: la experiencia con un stack moderno aumenta su valor, la experiencia en mantener un monolito en un solo servidor no. Es un comportamiento racional, y no cambiará solo por exhortaciones.

La segunda causa es la ausencia de retroalimentación. La solución excesiva no crea problemas inmediatos: todo funciona, solo que más caro y más complejo. La factura llega después, cuando cambian las personas del equipo.

La tercera es la imitación. Los informes técnicos de grandes compañías describen arquitecturas pensadas para cargas que usted no tiene, y se trasladan las soluciones junto con un contexto que no se traslada.

Síntomas

Orquestación para una carga que no existe. Kubernetes para una tienda online con doscientas visitas al día. Es una herramienta excelente para decenas de servicios y varios equipos, pero para una sola aplicación añade su propia capa de red, su propio almacenamiento, sus propias fallas y requiere a una persona que entienda todo eso.

Fragmentación que adelanta al tamaño del equipo. Cuarenta servicios para tres desarrolladores. La división del sistema en partes independientes sirve principalmente para que los equipos no se estorben entre sí: cuando tres personas trabajan en el producto, no se estorban entre ellas, y ya incurre en los costes de coordinación de versiones, llamadas en red y depuración de interacciones. Aquí conviene recordar la observación de Conway: la estructura del sistema refleja la estructura de la organización. Si la organización consta de un equipo, un sistema de cuarenta servicios no le corresponde.

Automatización de operaciones raras. Tres semanas de trabajo de un ingeniero para un script que realiza una acción que la empresa hace una vez al año. Un manual escrito en una hora resolvería la misma tarea —con la diferencia de que el manual no quedará obsoleto en silencio, mientras que el script puede romperse en un año y nadie lo sabrá hasta que haga falta.

Entornos que nadie usa. Cuatro copias del entorno de producción por las que el proveedor factura mensualmente, cuando dos de ellas no se han abierto en semanas.

Respaldo sin verificación. Formalmente hay un sitio de backup, pero nunca se ha hecho la conmutación. Este es el peor caso: los gastos ya se han incurrido completamente, pero la confianza es falsa —una conmutación no verificada funciona en el momento de la avería aproximadamente en la mitad de los casos.

Monitoreo al que no responden. Cientos de comprobaciones configuradas y un canal de notificaciones que nadie lee desde hace tiempo, porque siempre hay algo ardiendo allí. Ese monitoreo cuesta dinero y no aporta nada.

El verdadero costo

La tentación de medir la redundancia por la factura del proveedor es grande, pero el hardware es la parte más barata.

El conocimiento se concentra en una persona. Una sistema complejo lo entiende por completo su autor. Mientras esté en la empresa, todo funciona. Cuando se va, queda una construcción a la que nadie se atreve a tocar —y cualquier cambio en ella empieza a llevar semanas en lugar de horas.

La incorporación se prolonga. Un nuevo ingeniero llega a trabajar de forma autónoma en varios meses, porque las conexiones entre componentes no están documentadas en ningún lugar y, por el código, es imposible entender por qué la caída de un servicio rompe una función no relacionada.

La velocidad de cambios cae. Esta es la pérdida más cara y la más imperceptible. Una hipótesis de producto que podría comprobarse en una semana se verifica en un mes. Un competidor comprobará cuatro en ese tiempo.

Aumenta la probabilidad de fallos en cascada. La automatización que reacciona a una avería, si está mal configurada, la empeora: reinicia un servicio que no tiene tiempo de arrancar, redirige la carga a un respaldo que no la soporta y convierte una avería local en una falla general.

Cómo distinguir la complejidad justificada de la excesiva

Los indicios por sí solos no prueban nada: hay empresas que necesitan Kubernetes y empresas en las que cuarenta servicios están justificados. Lo que las distingue no es el tamaño, sino la capacidad de responder a tres preguntas.

Primera: qué fallo concreto evita esto y cuánto cuesta? La respuesta «es la arquitectura correcta» no vale. Vale: «la caída de un servidor en este escenario nos cuesta 300.000, la solución cuesta 100.000 al año».

Segunda: cuántas personas del equipo pueden mantenerlo? Si la respuesta es «una», la complejidad no está implantada, sino tomada a préstamo bajo la garantía personal de un empleado concreto.

Tercera: cuándo fue la última vez que lo usamos? El sitio de respaldo, la conmutación automática, el plan de recuperación —todo eso o bien se ha probado en la práctica o solo existe en papel.

Tres respuestas firmes significan que la complejidad está justificada. La ausencia de respuestas significa que está pagando por una fiabilidad que, probablemente, no tiene.

Si la complejidad ya está construida

El primer impulso —simplificar todo de nuevo— suele ser un error: la migración hacia atrás cuesta dinero y riesgos, y no conviene tocar un sistema en funcionamiento sin necesidad.

Es más sensato actuar de otra manera.

Detengan el crecimiento. No añadan nuevos componentes hasta que no haya respuesta a la primera de las tres preguntas.

Reduzcan el factor de irremplazabilidad. Describan el sistema de forma que lo entienda una segunda persona. Esto es más barato que cualquier migración y elimina el riesgo principal.

Eliminen lo que no se usa. Entornos inactivos, monitoreo al que nadie presta atención, servicios sin tráfico: se pueden apagar sin decisiones arquitectónicas.

Simplifiquen en la siguiente gran modificación. Cuando un componente deba reescribirse de todas formas, entonces decidan si debe seguir siendo como antes.

Pregunta que conviene hacer regularmente

Una vez por trimestre tiene sentido preguntar al equipo directamente: ¿qué problema del negocio resuelve lo que estamos construyendo ahora, y qué ocurrirá si no lo hacemos?

La pregunta no debe sonar a acusación —con ese tono recibirá respuestas defensivas en lugar de honestas. La formulación «ayúdenme a entender por qué estamos pagando» funciona mejor que «por qué lo implementaron».

Un buen equipo la responderá en un minuto. Si nadie tiene respuesta, ha encontrado no un problema técnico, sino de gestión.

Lecturas relacionadas: cuatro niveles de tolerancia a fallos — qué complejidad es adecuada en cada etapa, y cuánto cuesta una hora de inactividad — cómo obtener la cifra para la primera pregunta.