Cuando los servicios electrónicos del Estado se caen: Principios de arquitectura para sistemas públicos fiables

La fiabilidad de un servicio electrónico se comprueba cuando falla una dependencia o hay que restaurar datos. Un aviso de caída no demuestra una causa técnica. Estas recomendaciones se basan en los principios de fiabilidad de AWS, no en la investigación de un incidente concreto del ESKN.

Dónde buscar riesgos

Revise dependencias, versiones con soporte y opciones de recuperación. Un monolito no es intrínsecamente poco fiable. Hay un riesgo concreto cuando una dependencia detiene todo el proceso y no existe una alternativa probada.

Principios de arquitectura para servicios electrónicos fiables

Design for Failure

Cualquier componente acaba fallando, y el sistema tiene que darlo por hecho de antemano. Un circuit breaker corta una dependencia colgada para que un servicio lento no arrastre al resto. La graceful degradation mantiene utilizable lo que sigue funcionando en lugar de servir una página en blanco. Y el failover automático mueve el tráfico a una instancia de respaldo sin que nadie tenga que contestar el teléfono de madrugada.

Observability desde el primer día

No puede arreglar lo que no ve. Un sistema moderno necesita cuatro cosas a la vez:

• todos los logs en un solo lugar y con posibilidad de búsqueda
• métricas en tiempo real, es decir, CPU, memoria, response time y error rate
• distributed tracing, para poder seguir una misma petición a través de los componentes
• alerting que salte antes de que el primer usuario reporte el problema

Sin ellas, buscar la causa de una caída se convierte en adivinar.

Escalabilidad y redundancia

Elija redundancia y replicación según la interrupción y pérdida de datos aceptables. Varios entornos pueden limitar el impacto si sus dependencias son independientes, hay capacidad de reserva y la conmutación está probada.

Deployment y rollback automatizados

Los despliegues repetibles y las comprobaciones automáticas reducen errores. Blue-green y canary permiten verificar cambios gradualmente. Pruebe la vuelta atrás también con cambios de base de datos, porque restaurar solo la aplicación puede ser insuficiente.

Comunicación transparente durante una caída

Durante una caída, indique las funciones afectadas, las alternativas y la hora de la siguiente actualización. Confirme la causa solo después de investigarla. Tras la recuperación, documente el impacto y las correcciones.

Las pruebas de carga, por cierto, no son solo cosa del lanzamiento. El tráfico cambia con el tiempo, así que las pruebas tienen que cambiar con él.

Demostrar la recuperación

Tanto las entidades públicas como las empresas necesitan un responsable del incidente y un orden de restauración. El ejercicio debe medir el tiempo de recuperación y comprobar que los datos estén completos.

Y un failover no demuestra resiliencia solo porque aparezca en un diagrama de arquitectura. Hay que ejercitarlo de forma periódica con una conmutación controlada, cronometrarlo frente a un objetivo de recuperación y comprobarlo con una carga parecida a la real.

Si está construyendo un sistema que debe ser fiable, hablemos sobre cómo lograrlo.