Llegamos a ustedes gracias a:



Reportajes y análisis

SLA en la nube de Microsoft y otras

10 consejos a seguir

[25/02/2015] El 19 de noviembre del 2014 el departamento de TI de una compañía contratistas de Texas comenzó a recibir reportes de que el sistema de e-mail basado en la nube Office 365 de Microsoft no estaba disponible para sus empleados. Los usuarios no podían acceder al correo en sus teléfonos o a través de Outlook. A medida que el día avanzaba, el e-mail de algunos usuarios regresó y el de otros no. Cuando los trabajadores de los Estados Unidos se retiraron, empleados internacionales comenzaron a reportar problemas similares.

Después de la interrupción, los directores de TI se organizaron y presentaron un reclamo a Microsoft por incumplimiento en el acuerdo de nivel de servicio (SLA), el cual garantiza que Office y otros servicios en línea de Microsoft estarían disponibles en un 99,9% durante el mes. Si el servicio estuviera disponible más bajo de eso, el cliente recibiría un 25% de crédito. Pero la respuesta que obtuvieron de Microsoft los sorprendió: el acceso Web siguió disponible, así que, técnicamente, el servicio no fue interrumpido; por lo tanto no hubo incumplimiento del SLA.

"El número de personas dispuestas, capaces y con conocimientos suficientes para usar esa opción es muy bajo, señala un directivo del staff de TI, quien solicitó permanecer en el anonimato para no amargar la relación con Microsoft. En respuesta, la compañía contratante educó desde entonces a sus empleados en cómo usar el acceso web al e-mail cuando el Outlook está caído.

En respuesta a una solicitud de comentarios sobre la situación, Microsoft emitió una declaración diciendo que se esfuerza por lograr "un servicio siempre disponible, y que los SLA están ahí para ofrecer un reaseguramiento financiero a ese compromiso. Si un servicio en línea de Microsoft no está disponible menos del 95% durante el mes, los clientes obtienen un crédito completo por ese período.

Sin embargo, el episodio ilustra la necesidad de entender todos los términos y condiciones en los SLA de nube. Los acuerdos empresariales pueden ser complicados, así que aquí hay 10 cosas que se deben vigilar cuando se revisan los SLA para Microsoft Office 365 (la oferta SaaS) y para Microsoft Azure (el cual incluye componentes IaaS y PaaS). Muchos de los consejos aplican para otras plataformas de nube también, tales como AWS, pero son específicas para los servicios en la nube de Microsoft. Vea aquí la lista de garantía de tiempo en actividad del SLA para IaaS Azure de Microsoft; el SLA del servicio en línea puede verse aquí.

1. Lea el contrato y toda la documentación de soporte

Esto puede parecer obvio, pero muchas personas en realidad no leen el contrato, al igual que los contratos de Acuerdo de Licencia de Usuario Final. "Me encuentro con una increíble cantidad de personas que ven un PowerPoint y firman el contrato, señala Paul DeGroot, quien trabaja como consultor en Pica Communications aconsejando clientes acerca de las licencias de Microsoft.Si no entiende algo en el contrato después de analizarlo, pida ayuda. La clave para entender su SLA es leerlo.

Sin embargo, los contratos pueden ser confusos. DeGroot agrega que a veces la información relevante está en un documento de soporte. Los parámetros del SLA pueden ser delineados en una sección de un documento, pero el contrato puede estar sujeto a términos que están definidos en otra literatura. Asegúrese de leer el contrato completo, incluyendo cualquier documento de soporte.

2. Los incumplimientos del SLA deben reportarse

Algunos proveedores ofrecerán automáticamente crédito a los clientes cuando hay una interrupción, otros no lo harán. Es imperativo que los clientes reporten cualquier interrupción que creen que incumple el SLA. DeGroot se ha topado con casos en los que los clientes han experimentado una interrupción por varios días, y en la que seguramente su facturación no refleja el evento con un crédito. Pero si no documenta y reporta esto, no tendrá ninguna prueba de que experimentó una caída. Si tiene un problema grábelo, informe a su proveedor inmediatamente y elabore un reclamo por el incumplimiento del SLA.

Microsoft requiere que los clientes presenten un reclamo de incumplimiento a Soporte al cliente al final del mes calendario después de que el evento ha ocurrido. Así que, por ejemplo, si ocurre un incidente a mediados de febrero, el cliente tiene hasta fines de marzo para reportarlo. El reclamo debe incluir una descripción detallada del incidente; la duración del mismo; el número de usuarios o sitios impactados; la descripción de sus intentos para remediar la situación.

3. Un SLA con 99,9% de disponibilidad aún permite ocho horas de inactividad por año

Muchos de los servicios de Microsoft vienen con una disponibilidad de 99,9% garantizada (tres nueves). Eso suena bien. Pero estar disponible el 99,9% del año aún permite ocho horas y 45 minutos de caídas cada año, sin incumplimiento del SLA. ¿Cómo se sentiría si su carga de trabajo no está disponible por ocho horas un día?

Esta calculadora de tiempo de disponibilidad puede ayudar a los usuarios a predecir cuánto tiempo de caída podrían esperar de su proveedor, en base al tiempo de disponibilidad garantizado en su SLA.

4. Cada servicio tiene su propio SLA

Cada servicio individual puede tener su propio SLA con garantía de tiempo de actividad. Por ejemplo, las VMs de Microsoft Azure tienen una garantía de operatividad de 99,95% (si se despliega en dos Conjuntos de Disponibilidad; más adelante veremos más de esto) y la base de datos SQL tiene un 99,9% de tiempo de disponibilidad garantizado. La mayoría de productos SaaS en línea de Microsoft que vienen con 99,9% de tiempo de disponibilidad permiten que haya hasta 43 minutos de caídas en un mes sin incumplir el SLA.

Como Troy Hunt, un blogger experto de Microsoft, señala en este texto, esos eventos de caídas no tienen que ocurrir a la misma vez para que el SLA del proveedor esté intacto. Así que, por ejemplo, si tiene un sistema que funciona sobre VMs de Azure, una base de datos SQL y almacenamiento Azure, entonces el primer día del mes una VM Azure podría caerse por 21 minutos e interrumpir su carga de trabajo. Al siguiente día Azure SQL podría caerse por otros 42 minutos y traerse abajo la aplicación. Ambas situaciones estarían dentro del SLA. Para más acerca de esto, el blogger Bren Stineman explora cómo calcular los SLA agregados a través de múltiples servicios aquí.

5. Las VM pueden requerir ser desplegadas en múltiples instancias para que el SLA entre en juego

Uno de los mantras de la computación en la nube es prepararse para las fallas. Y, de hecho, algunos servicios de nube -incluyendo el Microsoft AWS- ordenan que clientes diseñen sus sistemas para estar preparados para fallas y para satisfacer los términos del SLA. El AWS, por ejemplo, requiere que esas máquinas virtuales se desplieguen en múltiples zonas de disponibilidad (que son diferentes centros de datos en la nube AWS) y ambas copias de la VM deben no estar disponibles para incumplir con el SLA. Microsoft utiliza el término Conjuntos de Disponibilidad en lugar de Zonas de Disponibilidad, pero es la misma idea. Los clientes deben prestar atención a las mejores prácticas de arquitectura para asegurar que sus sistemas cumplen con los términos del SLA.

6. La migración a una VM saludable podría causar caídas, lo cual no incumple el SLA

Una cosa a tener en cuenta es que si diseña su sistema para ser tolerante a fallas y para hacer conmutación a otra VM o Conjunto de Disponibilidad, esa acción en sí misma podría ocasionar problemas, como un reinicio. Si su sistema se cae debido a que no fue configurado para manejar una migración a un nuevo conjunto de VMs, entonces esa falla no es culpa del proveedor y no cuenta como incumplimiento de SLA. Las herramientas como Simian Army Chaos Monkey de Netflix y Chaos Gorilla pueden ayudar a los clientes de AWS a probar la tolerancia de sus sistemas a interrupciones.

7. ¿Realmente el servicio no está disponible y es culpa de su proveedor?

En el ejemplo de arriba de la compañía de Texas, el personal de TI creía que la interrupción era culpa de Microsoft, que en realidad lo era. Pero el servicio realmente no estaba fuera de disponibilidad porque el acceso web era una opción, así que esto no contaba contra el SLA. Así que si su app se cae, ¿es realmente culpa del proveedor? ¿El servicio no está disponible desde todos los puntos de acceso? De manera similar, a veces los servicios de nube se caen, pero no es culpa de los proveedores. Para que los SLA de Microsoft sean incumplidos, el servicio debe estar caído debido a "circunstancias dentro del control de Microsoft, estipula la compañía. Cuando ocurre una caída, revise si hay algo en su externo que haya causado la interrupción. Por ejemplo, ¿su conexión de red a la nube está bien? Los clientes tienen que probar que su proveedor falló, y el que servicio estaba realmente caído para poder ser compensados por el incumplimiento del SLA. Una herramienta de ayuda para determinar si su proveedor ha tenido una interrupción son los paneles de control de salud, en los que Microsoft y AWS informan qué servicios han estado no disponibles.

8. Los términos de servicio pueden cambiar

La nube es una industria que se mueve rápidamente y las ofertas de los proveedores pueden cambiar. Cuando las ofertas cambian, también pueden cambiar los SLA. Típicamente los SLA delinearán si un proveedor tiene que notificar a los clientes de un cambio al servicio o al SLA, o si los clientes deben estar preparados para una interrupción en el servicio. Pero esto puede variar de proveedor a proveedor, y de servicio a servicio, independientemente de que los clientes sean informados de los cambios. Si un cambio súbito a un servicio pudiera impactar en su carga de trabajo, revise para asegurarse de que su proveedor le notificará de tales cambios.

Microsoft notificará a sus clientes de lo que llama "cambios disruptivos a sus productos, anota Donal Retallack, vicepresidente de investigación en la consultora Directions on Microsoft.

Microsoft define "cambios disruptivos como: "cambio(s) en los que un cliente o administrador requiere tomar acción para evitar una degradación significativa de la operación normal del servicio. Microsoft promete informar al cliente con seis meses de anticipación de un cambio disruptivo a su plataforma de Dynamics CRM. Pero otros cambios no disruptivos podrían ocurrir sin que Microsoft notifique a los clientes.

9. El tiempo de interrupción planeado no siempre juega contra el SLA

Una cosa es que un servicio se detenga por una razón inesperada, pero a veces la nube puede caerse debido a que el proveedor del servicio la apaga. Verizon, por ejemplo, tuvo casi 48 horas de interrupción planeada a inicios de este año. Las interrupciones como esa pueden significar que el servicio esté caído, pero no cuenta contra el SLA. Los clientes pueden solicitar a su proveedor que se asegure de informarles de cualquier interrupción planeada.

10. Una versión "previa o una beta de un servicio puede que no venga con un SLA

Muchos proveedores ofrecen tres capas de servicio u otros productos que están en versión previa. Típicamente, esos servicios gratuitos y previos no están cubiertos por los SLA. Así que siéntase libre de usarlos pero asegúrese de que entiende los términos y los riesgos de usarlos antes de confiar a ellos funciones críticas.