La confiabilidad sigue siendo el objetivo para quienes están relacionados con los servicios de nube. Desde los equipos de ingenieros que quieren garantizar que diseñan y crean un servicio sólido y reducen los incidentes en el sitio, hasta quienes prestan servicios que quieren reducir el efecto de los incidentes. En esta nota, David Bills, Gerente de estrategias de confiabilidad en Microsoft, cuenta cómo reducir fallas a la hora de diagramar servicios en la nube.
Por David Bills, Gerente de estrategias de confiabilidad en Microsoft
Uno de los conceptos clave en el diseño de servicios de nube es la importancia de constituir resiliencia en el servicio con el afán de mejorar la confiabilidad. Todos los proveedores de servicios se esfuerzan para ofrecer un servicio confiable a sus clientes. Sin embargo, en la realidad, a veces las cosas salen mal. A pesar de las persistentes amenazas relacionadas con la confiabilidad, un servicio con capacidad de recuperación debe permanecer completamente funcional y permitir que los clientes realicen las tareas necesarias para completar su trabajo.
En este sentido, se deben diseñar los servicios para minimizar el efecto de un fallo en un cliente determinado, reducir al mínimo el número de clientes afectados por una falla y minimizar el número de minutos que un cliente (o clientes) se queda sin poder utilizar el servicio en su totalidad.
Resulta de suma importancia que las organizaciones consideren el modo en que operará y debería operar su servicio cuando ocurra un error conocido. Por ejemplo, ¿qué debe hacer el servicio cuando no está disponible otro servicio de computación en la nube de los que depende? ¿Qué debe hacer cuando el servicio no se puede conectar a la base de datos principal? ¿Cómo debe reaccionar el servicio cuando hay un aumento repentino en el tráfico y lleva su capacidad a su límite máximo?
En la experiencia de Microsoft, existen tres causas principales del fallo:
- Fallas en el dispositivo y la infraestructura: desde las fallas esperadas/término de la vida útil de los dispositivos, a fallas catastróficas, a menudo causadas por desastres naturales o accidentes que no están en las manos de la organización.
- Error humano: errores del administrador o errores de configuración que a menudo no están bajo el control de la organización.
- Imperfecciones del software: defectos en el código y problemas relacionados con el software en el servicio en línea implementado. Las pruebas previas a la presentación pueden controlar esto hasta cierto punto.
- Protección para el centro de datos híbrido
