La mayoría de las transiciones a una solución de cloud computing implican un cambio de una solución gestionada técnicamente (“yo lo construyo, yo lo mantengo”) a una solución administrada por contrato (“alguien más está haciendo esto por mí, ¿cómo puedo asegurarme de que están haciendo lo que se supone deben hacer? “).

Este cambio requiere una mayor capacidad de negociación del contrato de TI para establecer los términos de la relación (“¿Qué obtengo?”) Y habilidades de gestión de proveedores para mantener la relación (“¿Cómo puedo asegurarme de que lo obtenga?”)[1]. Esto implica identificar primero los requerimientos del negocio y establecer los indicadores clave de rendimiento esperados[2]. No olvidemos que hablamos de un servicio –y lo necesitamos para proveer servicios.

Por un lado, Kristin Knapp, editor del sitio de SearchCloudComputing, nos recuerda que los acuerdos de nivel de servicio (SLA) establecen confianza; los usuarios quieren seguridad de que su proveedor le garantiza un cierto nivel de servicio.

Tenemos que ser capaces de articular nuestras expectativas cuando se está negociando el acuerdo con el proveedor –y no es sólo mirarlo a los ojos cuando buscamos una respuesta, ni conviene acelerar su proceso. Un SLA no es una solución de una sola parte[3] [sabemos que en todo SLA existen dos partes]. Una de las partes -el proveedor de servicio en la nube, por ejemplo- no debe imponer decisiones acerca de cómo deben hacerse las cosas, sobre todo cuando la otra parte -el cliente de servicios de nube, por ejemplo- tiene diferentes expectativas sobre cómo debería formularse el SLA. Existe un impacto tecnológico y legal, especialmente cuando buscamos utilizar una nube pública[4].

Ninguno de nosotros desea que un proveedor simplemente reconozca el problema –luego que nosotros como usuarios asentamos la reclamación correspondiente primero. Debe haber un vínculo con la cura – como un tiempo de respuesta de una media hora para los problemas de servicio de mayor gravedad.

También es importante entender lo que el SLA cubre en términos de lo que recibirás y cómo va a recibirlo si el proveedor incumple el acuerdo. Así, igual de importante, deseamos la seguridad de que nuestro proveedor deberá pagar (o reembolsar) si no se cumplen las garantías acordadas[5] -pero no sólo con crédito, que los usuarios en general podríamos aplicar a nuestra factura de nube o para la compra de otro servicio en la nube, ya que rara vez se compensa la pérdida financiera o de negocio que puede ocurrir después de una interrupción (o degradación) en el servicio.

De hecho, no [siempre] se trata de dinero, se trata de la capacidad de ofrecer un servicio. No es de extrañar que los precios de los servicios en nube bajen con el tiempo y así, la elección de un proveedor se va a centrar todo sobre la prestación del servicio y el mayor tiempo de actividad que ofrezca.

Por otro lado, los clientes deben estar a la altura, por sanidad. Y una de las mejores maneras de hacerlo es construir aplicaciones en la nube que son resistentes, tolerante a fallos y diseñadas específicamente para la nube. Y realmente se necesita diseñar contra fallos por cuanto los proveedores cuentan con [se apoyan en] esto para proporcionar sus servicios “diferenciados”. No olvidemos que ya existe la ISO/IEC 27017 aplicada a la seguridad en nube, y que la CSA está tras este punto.

Un SLA de nube debe incluir términos más granulares alrededor de la respuesta del proveedor y el tiempo de recuperación. En concreto, los SLA de nube deben incluir términos que abarcan el “ciclo de gestión de fallos” completo de un servicio en la nube, sugirió Jason Andersen de Stratus Technologies. Esto incluye cinco fases clave de fallo de un servicio en la nube:

Darse cuenta de que hay un hecho/problema ocurrido
Localizar el hecho/problema
Aislar el hecho/problema
Recuperación del hecho/problema
Recuperación completa del hecho/problema

Muchos términos del SLA sólo hablan de la disponibilidad en nube en términos de un servicio que está “operativo” o “caído” –lo que hace atemorizante y confusa la tarea de establecer un SLA, y no tienen en cuenta los distintos niveles de desempeño que siempre existen entre ambos. ¿Cuánta degradación es requerida para que un servicio se considere ‘caído’? ¿Cuál es el tiempo de resolución ofrecido (el tiempo que tarda un proveedor de nube para resolver completamente un problema con su servicio)? En la granularidad de los términos utilizados está el asunto –el diablo está en los detalles (definiciones y terminología entre otros).

Por lo anterior, Tom Nolle de CIMI Corporation[6] nos sugiere establecer un SLA en nube como un pequeño proyecto.

Uno de los desafíos de establecer un SLA en la nube es que la experiencia entregada por una aplicación en nube depende de varios aspectos o zonas de servicio por lo que la primera tarea es desarrollar un mapa de entidades que muestre quién provee qué porción del servicio en nube y cómo esta porción transita entre estas entidades.

Por ejemplo, las comunicaciones empleadas, si son accesos locales o remotos, los dispositivos empleados, las cargas de trabajo exigidas, los flujos de trabajo generados –que son en última instancia la base de los SLA.

Para una buena gestión del SLA y decisiones de su política, es necesario medir el comportamiento de cada uno de los proveedores de las diferentes zonas que componen el servicio en nube. Podemos comenzar con mecanismos para medir el tiempo de respuesta y pasar de eso a las condiciones de medición en los puntos de frontera de estas diferentes zonas. Un buen inicio es medir en el punto de conexión del usuario. Para la observación de la zona frontera alguna forma de supervisión de tráfico o protocolo es difícil de superar.

Sin la consideración y herramientas adecuadas, incluso un buen SLA probablemente fallará porque no se sabrá que está siendo violado ni por qué. Recopile datos en un repositorio de forma natural. Esta recopilación de datos le permite ejecutar consultas para analizar el rendimiento y las condiciones en el tiempo y establecer líneas de base para un comportamiento normal, así como los umbrales de lo que se considera que son violaciones al SLA. La analítica de red puede ser una base sólida para basar las decisiones alrededor de los acuerdos de nivel de servicio de computación en nube.

Para que el SLA de computación en nube y los servicios que ofrece tengan éxito es fundamental tomar un enfoque organizado para el SLA y las decisiones que surgen de su cumplimiento.

Así que la pregunta es, entonces, ¿Qué estás haciendo para monitorear el servicio [de tu proveedor en nube] y qué estás haciendo para asegurarte de que estás [el servicio que ofreces está] disponible?

Dan Sullivan[7] nos recuerda que si bien no existe precisamente una plantilla [proporciono un ejemplito[8]], hay puntos que no debemos olvidar –aunque nos parezcan obvios ahora pueden escapársenos en el momento:

Suacuerdo de nivel deservicio en la nube(SLA) debe especificar los nivelesmínimos derendimiento paracada servicio, codificadocon parámetros específicos –insisto, debemos ser específicos, y no aceptar generalidades[9].
Tenga en cuenta losrequisitospara documentaruna interrupcióny el tiempo quetiene para presentaruna reclamación.
Esvital entenderlos procedimientos de documentaciónde interrupciónantes de usar cualquierservicio en la nube.
Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros –y que nuestros datos permanezcan siendo nuestros [o definir a priori la manera de recuperarlos].
Seguridad de los datos en la nube –lo que es una responsabilidad compartida: proveedor-usuario[10]; todos esperan que alguien [usted] sea responsable.
Gobierno de la nube -de probar procesos internos a comprobar el cumplimiento de su proveedor con las regulaciones.
Contratos firmados –locales e internacionales (buen viaje).
Tarifas y costos ocultos.
Dependencias con terceros.
Retención de datos.
Servicios de datos –controles de seguridad por ejemplo.
Versiones, versiones, versiones –de todo y para todo.
Licencias, licencias, licencias –de todo y para todo.
Estándares empleados –porque heredamos las certificaciones.
No olviden lo básico[11]:
- Codifica losparámetros específicosy los nivelesmínimos requeridospara cada elementodel servicio [y busquemos utilizar las mejores prácticas que encontremos para que no olvidemos ninguno, ITIL® por ejemplo], así como los recursospor incumplimiento deesos requisitos.
- Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros, afirmar la propiedad de nuestra institución de sus datos almacenados en el sistema del proveedor de servicios [y que nuestros datos permanezcan siendo nuestros], y especifica sus derechos para recuperarla [definiendo a priori la manera de recuperarlos].
- Detalles dela infraestructura del sistemay las normasde seguridadque deben mantenersepor elproveedor de servicios, junto con sus derechospara auditarsu cumplimiento o al menos teneracceso a susinformes de auditoríaescritos porun tercero de confianza –de verdad, no es broma.
- Especificasus derechos ycosto paraseguirydejar de utilizar el
Ni tampoco olvidar que debe existir un balance entre seguridad y riesgos[12] [redundancia, disponibilidad, continuidad, resiliencia, y otros términos relacionados], comprender la noción de niveles “aceptables” de riesgo[13], y los riesgos de firmar un contrato estándar[14] porque importa:
- Tiempo de actividad / inactividad.
- Periodo de tiempo de inactividad (inactividad recurrente en un periodo pre-establecido).
- Rendimiento y tiempo de respuesta –niveles máximos de latencia aceptados, QoS, entre otros aspectos.
- Tiempo de inactividad programado.
- Tiempo de corrección de errores.
- Infraestructura /

Para garantizar un modelo de responsabilidad compartida en nube -o un enfoque por el que tanto el proveedor de la nube y sus clientes son responsables de ciertos aspectos de la seguridad- las empresas deben definir claramente sus propias responsabilidades, junto con las del proveedor de la nube. Por tanto, debe establecerse una línea clara [que podría llegar a ser muy delgada] que indique cuál de las partes es responsable no sólo de ciertos aspectos de la seguridad de los datos, sino además de la seguridad de las aplicaciones, máquinas virtuales, interfaces, configuraciones de servicio y más en la nube. “La infraestructura de nube ofrece la capacidad de escalar una aplicación horizontalmente, pero sólo si la aplicación posee una arquitectura para aprovechar esa capacidad”, dijo Ed Featherston, Senior Enterprise Architect and Director en Collaborative Consulting. Si la aplicación no escala debido a un defecto de diseño, el proveedor puede seguir cumpliendo con los requisitos del SLA[15]. De ahí que convenga separar la nube de la aplicación; TI debe ser capaz de distinguir los problemas potenciales de infraestructura de problemas de la aplicación.

“Va a ser dependiente del contrato, pero está en nosotros como empresa, asegurar de que está muy claramente indicado en el contrato dónde está dicha línea”, dijo Peter Keenan, Director de Seguridad de la Información en Lazard, una firma de asesoría y gestión de activos financieros en Nueva York. “Creo que se va a realizar caso por caso y servicio por servicio”.

No olvide asegurarse de tener un seguimiento continuo del ecosistema de su proveedor porque las cosas cambian diariamente. Claro, es aconsejable utilizar herramientas especializadas e integradas lo mejor posible para nuestro ecosistema de nube.

De igual forma, cuanta más supervisión regulatoria enfrente tu empresa, más tienes que preocuparte por cuestiones de jurisdicción de datos. Consulta con tus propios auditores de gobierno, asegúrate de saber si existen regulaciones estatales o locales que podrían aplicarse a los datos almacenados en la nube, y asegúrate de que sabes dónde almacenará los datos tu proveedor de nube[16].

Probablemente si aplicamos la herramienta 6W-2H nos ayude a determinar cosas importantes como: estado, acceso, tiempo de respuesta, tiempo de caducación, versionamiento, fallo, entre otros. ¿Cuántos nueves deseamos de disponibilidad? ¿Quién es culpable de qué, cuándo y por qué?…

Sugiero al lector [si aún está interesado] revisar la exhaustiva información de la Comisión Europea sobre Acuerdos de Nivel de Servicio en Cloud Computing[17].

[1] Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[2] Fuente: http://searchcloudcomputing.techtarget.com/tip/Defining-the-right-cloud-SLA-requirements-up-front, junio/2012

[3] Fuente: http://www.ibm.com/developerworks/cloud/library/cl-slastandards/, enero/2013

[4] Fuente: http://searchcloudcomputing.techtarget.com/tip/Embrace-these-cloud-service-level-agreement-best-practices, setiembre/2015

[5] Fuente: http://searchcloudcomputing.techtarget.com/news/4500252585/IT-pros-crave-a-new-kind-of-cloud-SLA, agosto/2015

[6] Fuente: http://searchcloudapplications.techtarget.com/tip/Avoid-the-cloud-computing-SLA-trap?utm_medium=EM&asrc=EM_NLN_48206904&utm_campaign=20151002_How%20will%20microservices%20impact%20the%20cloud?_fchurchville&utm_source=NLN&track=NL-1806&ad=903291&src=903291, setiembre/2015

[7] Fuente: http://searchcloudcomputing.techtarget.com/answer/Sidestep-problems-be-your-own-cloud-SLA-watchdog, julio/2014

[8] Fuente: http://clkrep.lacity.org/onlinecontracts/2009/C-116359_c_11-20-09.pdf, noviembre/2009

[9] Fuente: http://searchcloudapplications.techtarget.com/answer/When-cloud-providers-fail-Recovering-from-an-SLA-violation, octubre/2013

[10] Fuente: http://searchcloudcomputing.techtarget.com/news/4500256467/Cloud-security-requires-shared-responsibility-model, octubre/2015

[11] Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[12] Fuente: http://lts.lehigh.edu/services/explanation/guide-evaluating-service-security-cloud-service-providers, 2015