Uptime Institute dispone de un archivo donde conservamemoria de todos los incidentes relacionados con paradas de servicio no planificadas de los ├║ltimos 18 a├▒os. Rick Schuknecht, vicepresidente y ejecutivo de redes globales de esta organizaci├│n, haanalizado los datos recogidos para realizar estudios anuales.
Yevgeniy Sverdlik, editor de DCD para la regi├│n NAM, entrevist├│ al directivo durante el pasado Symposium de Uptime Institute:
DCD Focus: ¿Han investigado cuál es el coste de una parada del servicio?
RS: No miramos particularmente cu├íl es el coste. Se trata de un tema dif├¡cil. Cuando hablamos con una compa├▒├¡a, generalmente no quieren saber cu├íl es el precio de una ca├¡da. El costo de una interrupci├│n del servicio puede encontrarse en un buen n├║mero de ├íreas diferentes. Puede tratarse de p├®rdidas en la facturaci├│n o de la reputaci├│n en la industria. O incluso de una violaci├│n de la normativa.Las compa├▒├¡as, dependiendo del sector denegocio en el que operan, utilizan diferentes maneras de percibir el coste de un corte del servicio. Cuando trabajaba en el lado corporativo (y no en Uptime), en un gran banco, hab├¡amos calculado que el coste de una ca├¡da era para nosotros de unos cinco millones de d├│lares por minuto.
┬┐Ha visto cambios en las principales causas de incidentes de downtime en los pasados cinco a├▒os?
No. Durante los pasados cinco a├▒os los datos han sido consistentes: tres cuartos, o casi trescuartos, se pueden atribuir al error humano.
┬┐Es ├®sta, por lo tanto, la principal causa deca├¡das en el data center?
Los datos nos indican que cerca del 10% de los eventos se deben a verdaderas fallas. El resto son cuasi accidentes, donde algo previene que ese evento desencadene un proceso en cascada que desemboque en falla. De todas las que se han producido, aproximadamente un 73% se atribuyen directamente a un error humano, mientras que el 27% restante se distribuye entre otras categorías.
¿Podría proporcionarnos algunos ejemplos de los problemas que han detectado?
Un ejemplo se produce cuando un sistema se dise├▒├│ correctamente, pero no se construy├│ de forma adecuada, y por lo tanto no funciona como ser├¡a deseado. Otro caso es un sistema instalado como fue dise├▒ado, pero no operado correctamente, lo que conduce al fallo.T├¡picamente, vemos fallos relacionados con la restauraci├│n del sistema una vez que la actividad de mantenimiento se ha llevado a cabo. Generalmente, hay un script que se utiliza para poner fuera de servicio una piezade equipamiento o sistema, y hay otro script para ponerlo de nuevo en servicio, y uno de estos pasos fue, o bien incorrecto, o bien no se sigui├│ adecuadamente. El sistema se puso de nuevo en servicioÔǪ pero no funcion├│ porque no hab├¡a sido restaurado adecuadamente.
┬┐Estamos hablando de todo tipo de sistemas?
S├¡. El├®ctricos, de refrigeraci├│n, sistemas de control, etc. Varios de los errores de los que hemos tenido constancia estuvieron directamente relacionados con la gesti├│n inadecuada de los sistemas de prevenci├│n de incendios.
¿Hay tipos de sistemas más propensos a sufrir cortes no planificados?
En 2010 se inform├│ de 23 fallos en un total de 305 incidentes. Unos 20 de los 23 fallos fueron el├®ctricos y tres mec├ínicos. Cerca del 80% de esos 20 (incidentes relacionados conequipo el├®ctrico) tuvieron lugar en los sistemas de distribuci├│n de critical power (posterior al UPS), fallos causados en su mayor├¡a por error humano, y los otros fueron en los sistemas UPS. Los tres producidos en la parte mec├ínica fueron todos provocados por problemas en los sistemas anti-incendios.
¿Cuáles son las conclusiones más interesantes extraídas de estos datos?
El factor de fallo humano sigue estando en un ratio de tres por cada cuatro durante todos estos a├▒os. Dado el ├®nfasis que instituciones como Uptime Insitute y otras ponemos en presentaciones, conferencias y simposios en la interacci├│n humana con las m├íquinas, es interesante que el n├║mero siga siendo el mismo. Pero el registro est├í ah├¡ y es muy estable. A├▒o tras a├▒o, el 75% de los fallos se atribuye al error humano. Lo cual me parece muy curioso.
Yevgeniy Sverdlik, editor de DCD para la regi├│n NAM, entrevist├│ al directivo durante el pasado Symposium de Uptime Institute:
DCD Focus: ¿Han investigado cuál es el coste de una parada del servicio?
RS: No miramos particularmente cu├íl es el coste. Se trata de un tema dif├¡cil. Cuando hablamos con una compa├▒├¡a, generalmente no quieren saber cu├íl es el precio de una ca├¡da. El costo de una interrupci├│n del servicio puede encontrarse en un buen n├║mero de ├íreas diferentes. Puede tratarse de p├®rdidas en la facturaci├│n o de la reputaci├│n en la industria. O incluso de una violaci├│n de la normativa.Las compa├▒├¡as, dependiendo del sector denegocio en el que operan, utilizan diferentes maneras de percibir el coste de un corte del servicio. Cuando trabajaba en el lado corporativo (y no en Uptime), en un gran banco, hab├¡amos calculado que el coste de una ca├¡da era para nosotros de unos cinco millones de d├│lares por minuto.
┬┐Ha visto cambios en las principales causas de incidentes de downtime en los pasados cinco a├▒os?
No. Durante los pasados cinco a├▒os los datos han sido consistentes: tres cuartos, o casi trescuartos, se pueden atribuir al error humano.
┬┐Es ├®sta, por lo tanto, la principal causa deca├¡das en el data center?
Los datos nos indican que cerca del 10% de los eventos se deben a verdaderas fallas. El resto son cuasi accidentes, donde algo previene que ese evento desencadene un proceso en cascada que desemboque en falla. De todas las que se han producido, aproximadamente un 73% se atribuyen directamente a un error humano, mientras que el 27% restante se distribuye entre otras categorías.
¿Podría proporcionarnos algunos ejemplos de los problemas que han detectado?
Un ejemplo se produce cuando un sistema se dise├▒├│ correctamente, pero no se construy├│ de forma adecuada, y por lo tanto no funciona como ser├¡a deseado. Otro caso es un sistema instalado como fue dise├▒ado, pero no operado correctamente, lo que conduce al fallo.T├¡picamente, vemos fallos relacionados con la restauraci├│n del sistema una vez que la actividad de mantenimiento se ha llevado a cabo. Generalmente, hay un script que se utiliza para poner fuera de servicio una piezade equipamiento o sistema, y hay otro script para ponerlo de nuevo en servicio, y uno de estos pasos fue, o bien incorrecto, o bien no se sigui├│ adecuadamente. El sistema se puso de nuevo en servicioÔǪ pero no funcion├│ porque no hab├¡a sido restaurado adecuadamente.
┬┐Estamos hablando de todo tipo de sistemas?
S├¡. El├®ctricos, de refrigeraci├│n, sistemas de control, etc. Varios de los errores de los que hemos tenido constancia estuvieron directamente relacionados con la gesti├│n inadecuada de los sistemas de prevenci├│n de incendios.
¿Hay tipos de sistemas más propensos a sufrir cortes no planificados?
En 2010 se inform├│ de 23 fallos en un total de 305 incidentes. Unos 20 de los 23 fallos fueron el├®ctricos y tres mec├ínicos. Cerca del 80% de esos 20 (incidentes relacionados conequipo el├®ctrico) tuvieron lugar en los sistemas de distribuci├│n de critical power (posterior al UPS), fallos causados en su mayor├¡a por error humano, y los otros fueron en los sistemas UPS. Los tres producidos en la parte mec├ínica fueron todos provocados por problemas en los sistemas anti-incendios.
¿Cuáles son las conclusiones más interesantes extraídas de estos datos?
El factor de fallo humano sigue estando en un ratio de tres por cada cuatro durante todos estos a├▒os. Dado el ├®nfasis que instituciones como Uptime Insitute y otras ponemos en presentaciones, conferencias y simposios en la interacci├│n humana con las m├íquinas, es interesante que el n├║mero siga siendo el mismo. Pero el registro est├í ah├¡ y es muy estable. A├▒o tras a├▒o, el 75% de los fallos se atribuye al error humano. Lo cual me parece muy curioso.