Qué proteger primero, y en qué se puede ahorrar

Intentar que todo sea igualmente fiable es la forma más rápida de agotar el presupuesto sin aumentar la fiabilidad donde hace falta. Cuando un equipo propone migrar todo a un clúster con conmutación automática, piensa en términos de tecnología. El negocio piensa en términos de consecuencias, y las consecuencias de distintas fallas difieren en dos órdenes de magnitud.

Un mapa de dependencias muestra de qué depende cada cosa. El siguiente paso es convertirlo en un documento financiero: determinar cuánto cuesta cada tipo de fallo y repartir el presupuesto proporcionalmente.

Clasifique funciones, no servidores

El primer error típico es clasificar por prioridad servidores y servicios. La unidad correcta es la función de negocio: «el cliente realiza un pedido», «el cliente accede a su cuenta», «contabilidad exporta los documentos de cierre».

La diferencia es fundamental. Un mismo servidor puede atender funciones críticas y secundarias a la vez — y entonces se descubre que la generación de informes pesados, que nadie consideraba importante, vive en la misma base que la gestión de pedidos y puede tumbarla. Estas cosas se ven solo al clasificar por funciones.

Tres clases

La proporción en un sistema sano suele ser: la clase A comprende una minoría de funciones — en promedio del cinco al quince por ciento. Si después de la clasificación tienes más de un tercio en la clase A, el análisis se hizo de forma formal. Normalmente eso significa que cada responsable defendió su área como crítica y el ejercicio degeneró en la negociación de estados.

Cinco preguntas para cada función

Para que la clasificación no se convierta en una disputa sobre la importancia de los departamentos, pase cada función por la misma lista. Anote las respuestas — le servirán en la siguiente revisión.

1. ¿Hace que deje de entrar dinero ahora mismo? Si la respuesta es sí — es clase A y no hacen falta más discusiones.

2. ¿Existen obligaciones contractuales sobre la disponibilidad de esta función? Las penalizaciones contractuales convierten la cuestión técnica en jurídica y a menudo elevan la clase un nivel.

3. ¿Puede el usuario alcanzar su objetivo por otra vía? Si al fallar el autocompletado de la dirección esta se puede introducir manualmente — la función se degrada pero no bloquea. Si sin ella no se puede completar el pedido — bloquea.

4. ¿Cuánto tiempo puede estar la función inactiva sin consecuencias irreversibles? La diferencia entre «una hora» y «un día» determina si se necesita automatización o basta con un responsable de guardia con instrucciones.

5. ¿Existe un procedimiento manual alternativo y quién lo maneja? Emitir la factura manualmente mientras la integración con contabilidad está caída es una solución operativa que reduce la clase. Pero solo si ese procedimiento está documentado y probado al menos una vez, y no inventado en el momento de la conversación.

La clasificación no es permanente

Estacionalidad. Para el comercio minorista, las semanas previas a la Navidad cambian totalmente el panorama: una función que todo el año fue clase B puede pasar a clase A en ese periodo. Un enfoque sensato es describir con antelación el «modo de pico»: qué se refuerza, qué se desconecta temporalmente para descargar lo crítico, quién está de guardia.

Crecimiento del producto. Una función añadida como experimento puede convertirse en un año en la principal fuente de ingresos, manteniendo infraestructura de nivel experimental. Estas situaciones se detectan exclusivamente mediante revisiones periódicas.

Cambios regulatorios. La aparición de una obligación de reporte convierte en un día una exportación que antes era de fondo en una función con plazos estrictos.

Dónde exactamente se ahorra el dinero

La clasificación no sirve para fortalecer solo la clase A, sino para justificar no fortalecer el resto.

Los entornos de prueba no se replican. Un entorno de pruebas que cae un sábado puede esperar hasta el lunes. Duplicarlo es gasto puro.

Los archivos se almacenan en almacenamiento frío. Los documentos de cierre de hace tres años no necesitan estar en un almacenamiento replicado de acceso instantáneo: la diferencia de coste es de un orden de magnitud, y el requisito es «recuperarlos en 24 horas a petición».

Las funciones secundarias se desactivan en lugar de replicarse. A veces la solución correcta no es restaurar el servicio más rápido, sino aprender a operar sin él. Una aplicación que continúa funcionando correctamente con el módulo de recomendaciones inaccesible es más barata y fiable que un servicio de recomendaciones tolerante a fallos.

Las tareas pesadas de fondo se aíslan. Sacar los informes a una réplica de base de datos separada es más barato que escalar la principal para la carga que genera contabilidad una vez al mes.

Cómo se ve al final

El resultado debe ser una tabla de una página: función, clase, tiempo de inactividad tolerable, pérdida de datos aceptable, responsable. No un documento de cuarenta páginas — nadie lo abrirá en el momento de la incidencia.

Esa tabla es la que responde a la pregunta que, de otro modo, se resuelve discutiendo: por qué gastamos tanto en pagos y nada en recomendaciones. Y también protege el presupuesto cuando llega otra propuesta de «hacer todo fiable» sin cálculo.

Lecturas relacionadas: cuánto cuesta una hora de inactividad — cómo obtener las cifras para la parte derecha, y cuatro niveles de tolerancia a fallos — qué medidas son adecuadas en cada clase.