La importancia de diseñar de servicios de nube confiables



Por David Bills, Gerente de estrategias de confiabilidad

La confiabilidad sigue siendo el objetivo primordial para quienes están relacionados con los servicios en línea. Desde los equipos de ingenieros que quieren garantizar que diseñan y crean un servicio sólido y reducen al mínimo los incidentes en el sitio, hasta quienes prestan servicios que quieren reducir el efecto de los incidentes para sus clientes mediante la entrega de un resultado consistente y predecible.

Para quienes desean diseñar o construir un servicio en línea, se recomienda que dar un vistazo al White paper “Una introducción para diseñar servicios de nube confiables”, que trabajó Microsoft, a fin de obtener un panorama sobre el modo de construir un servicio más confiable y con capacidad de recuperación. Del mismo modo, se recomienda que los clientes de nubes observen el modo en que su proveedor promueve la capacidad de recuperación en sus servicios.

Uno de los conceptos clave 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.

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.

  • Reducir 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.

Para contribuir con las organizaciones en la solución de las consecuencias de estas tres causas y las estrategias de mitigación para hacer frente a ellos, recomendamos el modelado con capacidad de recuperación. En este post analizamos el modo de fallo y el análisis de efectos (FMEA), un método reconocido en el sector para identificar las dependencias y limitar los posibles puntos de fallo.

La figura siguiente muestra dónde encaja FMEA en el proceso de desarrollo básico.

Descripción general del proceso básico de desarrollo

El diseño de un servicio con capacidad de recuperación y la implementación de mecanismos sólidos de recuperación es un proceso iterativo. Las iteraciones de diseño son fluidas y tienen en cuenta tanto la información obtenida de pruebas anteriores a la publicación y datos acerca del funcionamiento del servicio una vez que se ha implementado.

Tags:

Publicaciones Relacionadas