El servicio tiene dos servidores de aplicaciones y una base de datos en clúster, y en el diagrama de arquitectura parece seguro. Pero un día, un solo dispositivo de red falla y todo el servicio se apaga. La revisión posterior al incidente revela que ambos servidores de aplicaciones se estaban ejecutando en el mismo hipervisor, o que ambas instancias de la base de datos estaban conectadas al mismo arreglo de almacenamiento. La redundancia solo existía en una capa.
Descubrimientos como este son incómodos para todos. El propietario del servicio creía que estaba protegido. Es posible que el equipo de operaciones hubiera sospechado del punto débil, pero no tenía forma de probarlo. Y las personas que lucharon contra el incidente por la noche se preguntan por qué nadie lo vio venir.
Por qué los puntos únicos de falla permanecen ocultos
Un punto único de falla (SPOF) rara vez es un error de diseño. Suele ser el resultado de una deriva gradual. Los cambios en la infraestructura, las máquinas virtuales se mueven, la capacidad se reasigna. Lo que estaba separado en el momento de la implementación puede terminar en el mismo hardware meses después.
- La redundancia se evalúa capa a capa. El equipo de aplicaciones ve dos servidores, el equipo de virtualización ve capacidad de reserva, y nadie ve toda la cadena.
- Los diagramas capturan la intención, no la realidad. Muestran cómo se supone que deben ser las cosas, no dónde se han movido los sistemas desde entonces.
- Las revisiones de resiliencia son ejercicios puntuales. Ocurren en el momento del diseño o durante una auditoría, no de forma continua.
- La mantenimiento expone debilidades demasiado tarde. Si ambos nodos de un par redundante se parchean al mismo tiempo, el servicio se cae incluso aunque sea formalmente redundante.
Una mejor forma de pensar sobre la resiliencia
La resiliencia del servicio es una propiedad de toda la cadena de dependencias, no de componentes individuales. Por lo tanto, debe evaluarse a nivel de servicio, en todas las capas a la vez. Recomendamos:
- Registrar la redundancia explícitamente. Qué elementos se sustituyen entre sí y forman un grupo redundante.
- Buscar SPOF de forma continua, no una vez al año. Cada cambio en la infraestructura puede alterar la respuesta.
- Probar la resiliencia con simulación. Preguntar qué sucede cuando un componente específico falla.
- Llevar la redundancia al mantenimiento. Parchear nodos redundantes uno tras otro para que el servicio siga funcionando.
Cómo maneja Eywo Stratum
Eywo Stratum funciona con un mapa de dependencias en capas, desde servicios de negocio hasta aplicaciones, bases de datos y servidores, hasta hipervisores, almacenamiento y red. Sobre esa base, puede:
- registrar grupos redundantes, es decir, elementos que se sustituyen entre sí,
- identificar puntos únicos de falla, los componentes cuya falla afecta a un servicio independientemente de la redundancia en otra parte de la cadena,
- evaluar la resiliencia del servicio y mostrar dónde está protegido un servicio y dónde no,
- simular la falla de un componente seleccionado y mostrar los servicios y aplicaciones afectados.
El conocimiento de la redundancia también da forma al mantenimiento. Los cambios se pueden realizar elemento por elemento de forma continua, de modo que los nodos de un grupo redundante nunca se desactivan juntos. En la edición Business, el acuerdo de parcheo con el propietario del servicio admite parcheo continuo de nodos redundantes: un nodo se actualiza y verifica antes de que el siguiente lo siga. El servicio permanece disponible incluso durante el mantenimiento rutinario.
El propietario del servicio ya no tiene que confiar en un diagrama. Ve el estado actual, derivado de la CMDB, y sabe en qué depende realmente su servicio.
Conclusión
Los puntos únicos de falla no aparecen de la noche a la mañana, y una revisión puntual no los hará desaparecer. Solo se pueden encontrar mirando un servicio en su conjunto, en todas las capas, con una vista que se mantiene actualizada. Los descubrimientos incómodos de la noche se convierten en elementos ordinarios en el plan de trabajo, solucionados de forma calmada y durante las horas de trabajo.
Los grupos redundantes, el análisis de puntos únicos de falla y la simulación de interrupciones son parte de la edición Standard; el parcheo continuo de nodos redundantes como parte de la gestión de parches viene con la edición Business.
Eywo Stratum Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.