# Los puntos únicos de falla que no conoce · Stilla > Un servicio es redundante en papel. En la realidad, puede depender de un solo conmutador, matriz de almacenamiento o hipervisor. URL: https://stilla.eywo.digital/es/blog/single-points-of-failure/ Language: es Last updated: 2026-10-25 [← Volver al blog](https://stilla.eywo.digital/es/blog/) Resiliencia18 de junio de 2026Actualizado 25 de octubre de 20264 min readEquipo de Eywo # Los puntos únicos de falla que no conoce Un servicio es redundante en papel. En la realidad, puede depender de un solo conmutador, matriz de almacenamiento o hipervisor. A continuación, se explica cómo encontrar esos puntos débiles antes de que se conviertan en un problema. 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: 1. **Registrar la redundancia explícitamente.** Qué elementos se sustituyen entre sí y forman un grupo redundante. 2. **Buscar SPOF de forma continua, no una vez al año.** Cada cambio en la infraestructura puede alterar la respuesta. 3. **Probar la resiliencia con simulación.** Preguntar qué sucede cuando un componente específico falla. 4. **Llevar la redundancia al mantenimiento.** Parchear nodos redundantes uno tras otro para que el servicio siga funcionando. ## Cómo maneja Stilla Stilla 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. **Stilla Standard** Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados. [Comparar ediciones →](https://stilla.eywo.digital/es/editions/) ## Más artículos [CMDB·25 de octubre de 2026 ### La red virtual en la CMDB: del grupo de puertos al switch leaf Entre una máquina virtual y la red física se encuentra una capa que la mayoría de las CMDB no ven: conmutadores virtuales, grupos de puertos y enlaces ascendentes de host. Sin embargo, aquí es precisamente donde se decide qué servicios afectará un cambio en la red. Standard4 min read](https://stilla.eywo.digital/es/blog/virtual-network-in-the-cmdb/)[Gobernanza·25 de octubre de 2026 ### NIS2 y DORA: lo que las operaciones de TI deben poder demostrar Ambas regulaciones formulan la misma pregunta: ¿sabe qué servicios se ven afectados por una interrupción, quién es responsable de ellos y qué cambió cuándo? Sin un mapa de dependencias fiable, las respuestas se elaboran manualmente, a menudo bajo presión de tiempo. Standard3 min read](https://stilla.eywo.digital/es/blog/nis2-dora-evidence/)[Implantación·15 de octubre de 2026 ### Implantación de ITSM sin un proyecto de seis meses La introducción de una nueva herramienta de ITSM no tiene que significar meses de talleres y consultores. Comience con un área, importe los datos que ya mantiene en Excel y verifique la preparación antes de salir en vivo. Standard4 min read](https://stilla.eywo.digital/es/blog/itsm-without-half-year-project/)