"Infraestructura resiliente." "Una organización más resiliente." "Soluciones resilientes." La palabra resiliente está en todos los folletos, todas las juntas y todos los titulares de tecnología, y sospecho que la mitad de quienes la usan no podría definirla si les preguntaras de golpe. Vale la pena aclararla, porque cuando se entiende bien, deja de ser un adorno de marketing y se vuelve una idea genuinamente útil, y bastante más honesta que las promesas que suele acompañar.
Lo que NO significa
El malentendido más común es creer que resiliente quiere decir "que nunca falla", "invulnerable", "a prueba de todo". No. De hecho, la resiliencia parte de aceptar que las cosas van a fallar. Un sistema que promete no fallar nunca no es resiliente: es, en el mejor de los casos, robusto, y en el peor, una ilusión. La palabra viene originalmente de la física —la capacidad de un material de recuperar su forma tras una deformación— y de la psicología —la capacidad de una persona de sobreponerse a la adversidad—. En ambos casos, la clave no es evitar el golpe, sino sobrevivirlo y volver.
Lo que sí significa
En tecnología, un sistema resiliente es el que, ante un evento adverso —una falla, un ataque, un pico de carga, un desastre—, tiene la capacidad de absorber el golpe, seguir funcionando (aunque sea de forma degradada) y recuperarse. Cuatro capacidades lo componen:
- Resistir: aguantar lo que se pueda sin caer.
- Absorber: cuando el golpe pasa la resistencia, encajarlo sin colapsar del todo —degradar el servicio de forma controlada en lugar de morir de golpe—.
- Recuperarse: volver a la normalidad, rápido, después del evento.
- Adaptarse: aprender del golpe para quedar mejor preparado la próxima vez.
Robusto vs resiliente: la distinción que aclara todo
Aquí está la diferencia que hace útil la palabra. Un sistema robusto es fuerte: resiste mucho. Pero un sistema puramente robusto tiende a fallar de forma catastrófica: aguanta, aguanta, aguanta... y cuando finalmente cede, se rompe entero, de golpe. Un sistema resiliente asume que va a recibir golpes que no puede resistir, y se diseña para fallar bien: para doblarse en lugar de quebrarse, para caer poco a poco en lugar de desplomarse, y sobre todo para levantarse. El puente robusto resiste el terremoto más grande previsto; el puente resiliente, además, se agrieta de forma controlada y se puede reparar rápido si lo supera. En TI: un servidor robusto es potente; una arquitectura resiliente sobrevive a que ese servidor muera.
Por qué la resiliencia es la meta honesta
La razón por la que "resiliente" es mejor objetivo que "infalible" es simple: lo infalible no existe. Todo falla —discos, redes, energía, software, personas—. Prometer que nada fallará es venderle humo al cliente; diseñar para que, cuando algo falle, el impacto sea mínimo y la recuperación rápida, es ingeniería honesta. Por eso la resiliencia es el hilo que conecta tantos temas de este blog: la recuperación de datos, la continuidad del negocio y la recuperación ante desastres, la inmutabilidad de los respaldos, la redundancia, el no depender de un solo sistema. Todos son formas de la misma pregunta madura: no "¿cómo evito que algo salga mal?", sino "¿cómo hago para que, cuando salga mal, no me hunda?". La próxima vez que oigas "resiliente", ya sabes qué deberías exigir detrás de la palabra.