Publicado el

Diseñar para fallar

Todo falla tarde o temprano. Una arquitectura madura decide de antemano cuánto tiempo puede estar caída y cuántos datos puede perder, lo diseña para cumplirlo y lo prueba antes de necesitarlo.

Línea de servicio Arquitectura Cloud

La pregunta no es si falla

Discos, regiones, proveedores, despliegues, personas: todo falla en algún momento. Una arquitectura no se mide por si falla, sino por cuánto daño hace cuando falla y cuánto tarda en volver.

Eso no se improvisa durante el incidente. Se decide antes, se diseña y se prueba.

Dos números que lo deciden todo

Línea de tiempo de un incidenteIncidente ilustrativo: el objetivo de pérdida de datos se cumple y el de tiempo de recuperación no.ARQUITECTURA · RECUPERACIÓNLo que se acordó y lo que pasóÚltima copia válida9:45Fallo10:00Detección10:12Decisión10:20Restaurado10:52Servicio normal11:05RPO real 15 minRTO real 65 minPérdida de datosAcordado: 15 min · Real: 15 minCumple el objetivo.Tiempo caídoAcordado: 60 min · Real: 65 minNo cumple: el diseño se revisa.Se detectó a los 12 minutos: la mitad del exceso estuvo en la detección, no en la restauración.Datos ilustrativos, no corresponden a ningún caso realN100F · n100f.com

  • Objetivo de punto de recuperación (RPO): cuántos datos se pueden perder, medido en tiempo. Si es de quince minutos, hace falta copiar o replicar al menos cada quince minutos.
  • Objetivo de tiempo de recuperación (RTO): cuánto tiempo puede estar caído el servicio. Si es de una hora, la recuperación completa (detectar, decidir, restaurar, comprobar) tiene que caber en una hora.

Cada valor tiene un costo: cuanto más pequeños, más redundancia y más gasto mensual. Por eso se acuerdan con el negocio y se escriben, como el resto de los requisitos de calidad.

Del número al diseño

Objetivo Diseño habitual
Horas de caída y un día de datos aceptables Copias diarias y restauración manual documentada
Una hora de caída, minutos de datos Copias frecuentes, réplicas y recuperación automatizada en la misma región
Minutos de caída, sin pérdida práctica Réplicas síncronas y despliegue en varias zonas o regiones, con conmutación automática

Lo que no está probado no existe

Una copia de seguridad que nunca se ha restaurado es una suposición. Un plan de recuperación que nunca se ha ejecutado es un documento. La recuperación se prueba:

  1. Restaurando de verdad, de forma periódica, en un entorno separado, y midiendo cuánto tarda.
  2. Simulando fallos controlados (una instancia, una zona, una dependencia) para comprobar que el sistema reacciona como se diseñó.
  3. Ensayando el procedimiento con las personas que lo ejecutarán, no solo con quien lo escribió.

Cada prueba deja un resultado escrito: tiempo real de recuperación, datos perdidos y qué hubo que corregir. Si el tiempo real supera el objetivo, el diseño no cumple su requisito, aunque nunca haya fallado.


Cómo lo aplicamos: Arquitectura Cloud.

Si tu costo cloud crece sin que nadie sepa por qué, o tu arquitectura depende de quien la montó, conversemos.

Conversemos