Sistemas de Misión Crítica (I): Acuerdos de Nivel de Servicio (SLAs)

(Este es el primero de una serie de tres artículos sobre Sistemas de Misión Crítica. En esta ocasión nos vamos a referir a los Acuerdos de Nivel de Servicio entre usuarios de tecnología y proveedores tecnológicos, y de cómo medir el cumplimiento de los mismos)

 Normalmente  las necesidades que llevaron al surgimiento de la "Arquitectura de Software" como disciplina dentro de la Ingeniería de Software tienen que ver más con la continuidad operacional de los negocios soportados por software, que por las Ciencias de la Computación en sí mismas

Ejemplos: la necesidad de abaratar costos de mantenimiento posterior; la necesidad de poder intercambiar mañana piezas sin quedar atado a decisiones previas, tomadas -claro está- en momentos en que el porvernir era difícil de precisar; la necesidad de eficientizar en forma conjunta el consumo de memoria, cómputo de CPU y ancho de banda utilizado en la red; y tantas otras

El hecho es que los negocios existieron desde mucho antes que la Informática fuera creada y comoditizada (es decir, en otras palabras, accesible para una mayoría a costos no privativos). Sin embargo, la irrupción de la tecnología informática en general, y de la industria del software en particular, potenciaron la forma de hacer negocios, llevando a estos a una escala inimaginable en períodos previos al surgimiento. Esto a veces cuesta un poco de entender: si los negocios, las industrias habían sido creados previamente, cómo es posible que la no disponibilidad total o parcial de una determinada tecnología pueda impactar en los resultados de algo que no dependió originalmente de la misma?

Sencillo de explicar: qué hacés hoy si se corta la luz en tu zona y en un radio de 50 kilómetros a la redonda? Te querés matar, no? No podés estar en tu casa ni podés ir a ningún lugar cerca porque estás en la misma. Y sin embargo la luz eléctrica fue aplicada en forma masiva hace menos de 200 años. Cómo hacían antes para no estar de mal humor? Simplemente se vivía distinto. Era otro contexto, otra expectativa y por lo tanto también se ponía otra energía en las cosas, acorde a este "sistema de coordenadas" limitado por aquel contexto

En el mundo de los negocios de hoy, entonces, se habla de misión crítica -o de sistemas de misión crítica- cuando la no disponibilidad, total o parcial, de los mismos afecta seriamente a los resultados de estos negocios. Te pasó ir al banco a querer abrir un depósito a plazo (un "plazo fijo", como se lo llama en Argentina) y que te digan "ahora no, estamos sin sistema"?
Qué hiciste ahí? Te fuiste a otro banco a terminar de hacer la transacción para no andar con la guita encima? Supongamos que sí. Qué le pasó al banco que estaba sin sistema desde el momento en que te fuiste? Se perdió de recibir plata, esa plata que a su vez el banco presta y por la que cobra una renta; renta de la que subsiste con una parte, y usa otra parte para pagarte a vos el interés de haber hecho el depósito a plazo

Al haberte ido sin hacer el depósito, el banco se pierde de prestar tu guita a un tercero, por ende renuncia a cobrar la renta por el servicio de la deuda y, en definitiva, a ganar plata. Eso es, entonces, un "Sistema de Misión Crítica": es un sistema cuya no disponibilidad total o parcial termina afectando negativamente las utilidades de un dado negocio. Y te voy anticipando antes de seguir qué es lo que pasa si en un negocio deja de entrar plata por un problema de los sistemas. Si eso se prolonga en el tiempo lo más probable es que empiece a salir cierta gente del área de Sistemas para desbloquear el paso y posibilitar que la plata vuelva a entrar al negocio. Capisce? Sabía que me ibas a entender: no es que los negocios hoy puedan subsistir sin los sistemas, pero si es claro que el área de Sistemas va a subsistir en la medida en que el negocio lo haga (y si no explicame por qué, si te toca trabajar de 9 a 6 de la tarde, hay días que ya son más de las 9 de la noche y todavía estas dando vueltas ahí adentro) sin una hora estimada de fin de actividades

Pero claro, entendida la definición, aceptada la magnitud del problema viene la pregunta: y a mí arquitecto qué? Qué debo saber / hacer / evitar para que la continuidad del negocio no se vea seriamente afectada -al menos, al punto de poner en riesgo mi pellejo-? En lo que sigue, te paso las claves de supervivencia. El enfoque que voy a tomar va a ir del nivel más alto, desde la perspectiva empresarial, hacia los inferiores (más vinculados con aplicaciones específicas y la infraestructura que soporta a las mismas)

 

Business are business (Negocios son negocios)
Como la que manda es la misión empresarial primaria de la organización, hay que empezar a abordar el problema desde los principales stakeholders (interesados) de esta función: los gerentes del negocio, analistas y usuarios en general. Es con estos interesados con quienes se debe establecer (y seguramente negociar) un Acuerdo de Nivel de Servicios (Service-Level Agreement o SLA). Y se parte del nivel más alto, menos técnico, ya que estos interesados no conocen demasiado (o no es mandatorio que conozcan) de las intricancias de nuestras tecnologías. Para ponerlo en palabras nuestras, podríamos usar el ámbito de los casos de uso o sus interacciones como marco de referencia. En este contexto, ejemplos típicos de SLAs pueden postular cosas tales como "pedir un estado de cuenta, una vez ingresado el número de cliente, no puede demorar más de 20 segundos" o -en el caso de una telco, por ejemplo- "el alta del servicio de telefonía básica, una vez ingresado al sistema la conformidad del cliente y todos sus datos para la facturación, no puede demorar más de 30 minutos"
Los Acuerdos de Nivel de Servicios, en muchos casos, establecen compromisos mutuos. Por ejemplo, el caso anterior de la telco, quizás hace falta verificar cierta información del cliente para constatar veracidad o historia de morosidad, y esos procesos pueden ser semi automáticos. Si son semi automáticos, quiere decir que el otro lado del semi es manual, y si es semi manual, tené claro que no es la gente de tecnología la que va a ejecutar esa parte manual. El negocio sigue mandando, por lo que acá los mismos stakeholders van a tener que cumplir buena parte del acuerdo, y no reclamar al área de tecnología por esas demoras
Ahora, la parte que les cabe a los operadores del negocio es un problema de ellos. El tema es, nosotros, cómo ir a la mesa de negociaciones con datos claros acerca de lo que somos capaces de proveer (por así decir, hasta dónde nos la bancamos). Y particularmente, para no dejar pintados a los hombres de negocios (lo cual es suicida de nuestra parte), ser claros en lo que necesitamos para, desde la tecnología, brindar el nivel de servicios que ellos esperan para con los clientes
La "precisa" nos la va a dar la Administración de Capacidades (Capacity Management) que es un proceso iterativo y abarcador. Iterativo porque no termina (sino que, en todo caso, se abandona) y abarcador porque para saber hasta dónde la tecnología es capaz de soportar niveles de servicio del negocio, es preciso conocer que niveles de servicio la tecnología misma es capaz de brinda (por ejemplo, accesos a la base de datos cuánto demoran, qué ancho de banda tenemos disponible, cuántos usuarios concurrentes somos capaces de soportar y qué configuración necesitaríamos para soportar más o mejorar los tiempos de respuesta, etc)


Figura 1- Administración de Capacidades
como un proceso contínuo

Ahora bien, ninguna bola de cristal hace falta conseguir acá. Microsoft Operations Framework (MOF) es una guía que aglutina prácticas para llevar desde la Gerencia de Tecnología hacia los níveles inferiores de la misma, impactando en las actividades de todos sus integrantes. MOF se compone de cuadrantes: Optimización, Cambios, Operación y Soporte

 
Figura 2- Cómo se integra Microsoft
Operations Framework (MOF) 

Particularmente el cuadrante de Optimización incluye guías para Administración de Nivel de Servicio (MOF Service Management Functions), entre las que aparece, entre otras, la Administración de Capacidades (Capacity Management) que te comenté. Asimismo, cada producto de la familia Microsoft te ofrece sus propias herramientas para planificación de capacidades; herramientas éstas que deberías usar dentro de un proceso MOF

 

Monitoreo de Actividades
Ahora, esto es obviamente un proceso. Una vez que las capacidades han sido establecidas, los SLAs han sido negociados… cómo verificar el efectivo cumplimiento en forma automatizada? Cómo saber, en tiempo real, que el alta de un servicio a un cliente lleva atascado más de dos horas? O cómo saber, incluso al lunes siguiente de un fin de semana, que el proceso de altas dejó de funcionar por x tiempo? Cómo conocer esas cosas al momento en que ocurren o incluso llevar la estadística de cuántas veces ocurrieron?
Para esto, lo que se hace es establecer umbrales basados, justamente, en los SLA definidos. Pero estos umbrales se descomponen en dos niveles: nivel de negocio y nivel de infraestructura. Porque no es lo mismo hablar del proceso de negocio que transfiere dinero de una cuenta a otra (y que para eso lleva determinado workflow) que el proceso de más bajo nivel que accede a una base de datos u otro servicio remoto para invocar determinada transacción
En la arquitectura Microsoft, los umbrales de negocio se monitorean mediante una facilidad incluída en Biztalk Server 2006, llamada Business Activity Monitoring (BAM, por Monitoreo de Actividad de Negocio)


Figura 3 – Arquitectura del motor de Monitoreo de Actividad
de Negocio de Biztalk Server 2006

BAM habilita a especificar eventos que se disparan a medida que las actividades van sucediendo. Estos eventos sirven para actualizar indicadores que luego pueden ser analizados desde el portal de BAM o exportados a Excel (o también, mediante SQL Server Notification Services, enviados a aplicaciones externas)
Biztalk 2006 también incluye un monitoreador similar pero para servicios provistos por terceros: me estoy refiriendo a Business Activity Services (BAS). Ambas facilidades, BAM y BAS, están pensadas más desde el punto de vista del usuario que de la gente de tecnología
En gran medida, hablando en términos agnósticos de la plataforma, estas facilidades de monitoreo le son conferidas el Bus de Servicios Empresariales (Enterprise Service Bus o ESB) en una Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA). Al respecto, Lukas Cudridge ofreció una presentación acerca de cómo montar un ESB en la plataforma Microsoft (particularmente en torno de Biztalk Server 2006). Esa sesión está disponible para descarga acá. También, en la pasada conferencia sobre SOA y Procesos de Negocios que Microsoft brindó en Redmond en Octubre pasado, se anunció el lanzamiento del ESB Toolkit, mayormente basado en los conceptos de la sesión que te comento (según averigüé, este ESB Toolkit se encuentra ya en fase de testing)

 

Monitoreo de Procesos Sistémicos
Las actividades de negocio se apoyan en procesos tecnológicos. Los mismos ya no deben ser monitoreados por usuarios sino por operadores y expertos del área de tecnología. Para ello, hacen falta herramientas que permitan diagnosticar con precisión problemas de seguridad, bajo ancho de banda, de acceso a volúmenes de datos, de denegación de servicio o bajo rendimiento en general. Existe una herramienta capaz de hacer eso? Claro, que existe. Se vino llamando durante años Microsoft Operations Manager (MOM), que actualmente va por su versión MOM 2005, pero en el roadmap está previsto embeberlo definitivamente a la estrategia Microsoft System Center, por lo que su nombre pasará a ser System Center Operations Manager 2007, y ya va por su Release Candidate 2!!


Figura 4 – Consola de Operador de MOM 2005

Querés echar un vistazo rápido a MOM 2005 en acción? No te pierdas esta demo (click acá). Ahí vas a ver que MOM es capaz de suscribirse a eventos tanto del sistema operativo como eventos lanzados por aplicaciones (MS Exchange, SQL Server, etc). Una vez que los recibe, es capaz de lanzar notificaciones vía mail, paging o mecanismos extensivos (claro, al operador que tenga que recibir esos mensajes y actuar en consecuencia no le debe causar ninguna gracia que MOM sea capaz de ubicarlo, pero en términos de la misión crítica y el negocio, enhorabuena)
Lo más interesante de MOM, si sos desarrollador de aplicaciones .NET, es que tenés la posibilidad de dotar a tu aplicación de elementos que la habiliten a ser monitoreadas por MOM (a esto me voy a referir en un post por llegar). Esto quiere decir que desde una única consola de operador es posible monitorear la salud de todo el portfolio de sistemas de la organización

 

Estimados, voy a parar acá. Esta serie de "Misión Crítica" va a contener una segunda parte explicando estrategias del punto de vista del desarrollo de aplicaciones, para que sean aptas para la misión crítica. En una tercera parte voy a explicar las herramientas que tienen a mano los arquitectos de infraestructura, sea para distribuir carga y hacer a los sistemas escalables, como para prevención y recupero de información ante desastres. Hasta entonces

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

3 respuestas a Sistemas de Misión Crítica (I): Acuerdos de Nivel de Servicio (SLAs)

  1. Ariel dijo:

    Hola Diego,
     
    he visto que has estado viviendo en varios sitios y me gustaría poder intercambiar contigo info acerca de tu experiencia en Madrid.
    He estado repasando tu blog y en varios sitios has hecho mención a cosas que me han ( y me siguen) pasado.
    Actualmente trabajo para una multinacional en el área de sistemas de información.
    Un saludo,
     
    Ariel
     

  2. Diego dijo:

    Con gusto, Charlie, mi cuenta es diegum@hotmail.com

  3. Mario dijo:

    Excelente aporte agregare tu blog para intercambiar información, tienes muchos temas de interés. Gracias

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s