Tomemos el ejemplo de un servidor de bases de datos con elevada tolerancia ante fallas, con su propio almacenamiento externo RAID y en el que se utiliza software de clustering para que funcione orquestadamente con otro servidor ubicado en un centro de datos diferentes, para mayor seguridad. Con esta configuración, ya tenemos a un sistema muy complejo formado por miles de componentes que están altamente acoplados. El staff de IT de este ejemplo es muy capacitado y diligente, ocupándose de todos los backups necesarios.
Luego, supongamos que existe un error de programación en un controlador RAID a causa de una combinación inesperada de caudal de datos y actividad en el procesador multi-threaded on-board. La condición causa un overflow periódico y la consiguiente corrupción de datos que son grabados en los drives de disco. Como los sistemas son exactos duplicados, el evento es igual en los dos nodos del cluster.
A nivel de lo controlable, todo parece estar bien, dado que el error es latente. No se hará visible hasta que una o más estructuras de bases de datos estén lo suficientemente corruptas como para alertar sobre el problema. Al detectarse el problema, se comienza a controlar logs y a buscar brechas de seguridad porque todo “funcionaba bien.” El punto es que múltiples componentes pueden interactuar en formas no previstas y neutralizar la capacidad de tolerancia a fallas de un sistema.
El nivel de complejidad puede incrementar la posibilidad de errores y también la de problemas de seguridad. En un sistema tan complejo, una brecha de seguridad anónima es casi inevitable.
Fuente: Artículo de George Spafford para Datamation