Amenudo la realidad del sector de IT confluye en un panorama arduo y complejo, desbordado por la urgencia y la desestructuración, donde impera la doble necesidad de flexibilidad y organización, improvisación y seguimiento.
Muchas veces uno observa que ha perdido la perspectiva y no sabe qué parámetros tomar para otorgarle dirección al caos. Empresas más o menos grandes, help desks más o menos estructurados, quién no sintió alguna vez que el día a día se le iba de las manos y ansió tener el poder de detenerlo todo por un instante para volver a empezar con procedimientos definidos y una perspectiva más clara de la situación.
Quiero en esta oportunidad tomar un marco de referencia para empezar a disipar la problemática de IT Operations. Voy a referirme a Microsoft Operation Framework (MOF).
¿Qué es MOF?
MOF, Microsoft Operation Frame-work, es un conjunto de conceptos, principios y prácticas recomendadas, que han sido diseñados a los fines de contribuir en la organización de IT Operations. Tiene como objetivo principal elevar al máximo el beneficio de las inversiones en tecnología, incrementando el nivel de servicios brindados al negocio, optimizando costos y minimizando los riesgos que todo entorno conlleva.
Para quienes ya tienen referenciado a MSF (Microsoft Solution Frame-work), el mismo consiste en una guía de modelos, disciplinas y principios, que proveen de prácticas eficaces para planificar, diseñar, desarrollar e implementar nuevas soluciones de IT (Build IT right). Mientras que MOF ofrece un marco de referencia que les permite a las organizaciones lograr confiabilidad en los sistemas que ya están en producción y que son de misión crítica, asegurando su disponibilidad y soporte, así como su mantenimiento y administración (Run IT right).
MOF está basado en ITIL «IT Infrastructure Library», que es un conjunto de normas y procedimientos de la OGC (Gobierno Británico); un estándar de facto en el área de infraestructura. Dentro de quienes han contribuido a construir este marco están los Microsoft Partners con el aporte de su experiencia, el propio grupo de IT de Microsoft, consultores de campo e ingenieros en infraestructura que han trabajado aunando esfuerzos con los clientes para construir un abordaje de excelencia operacional.
¿En qué me puede ayudar MOF?
En mi experiencia en el ámbito de infraestructura, he llegado a la conclusión de que los principales problemas que afrontamos a diario son:
•
Falta de un SLA (Service Level Agreement).• Falta de procesos de administración de seguridad.• Deficiente o inexistente administración de riesgos.
Intentaré explicarlos a lo largo de este artículo haciendo hincapié en cómo MOF aborda dichas dificultades desde sus tres modelos: el modelo de procesos, el modelo de equipo y el modelo de riesgos.
¿Por qué necesito un Service Level Agreement (SLA)?
Un SLA es generalmente conocido como un contrato entre dos empresas, proveedora y cliente de un servicio, en el cual se especifican los detalles de la solución a brindar, disponibilidad, indemnizaciones, etc. Es cierto, este es un aspecto del SLA, tal vez el más formal y no por ello menos importante.
Pero una vez dentro de la organización, donde IT y su cliente están en el mismo ámbito, no suponemos ni someramente que pueda sernos útil en algo. SLA es TODA DEFINICION DE UN SERVICIO prestado por IT Operations incluyendo alcances y limitaciones, el esclarecimiento explícito de las prestaciones que se otorgarán al negocio y a qué costos. Pregúntele a un socio de su compañía si tiene conocimiento sobre los niveles actuales de servicio entregados por IT y al departamento de IT cuántos problemas le trajo cuando le exigieron soluciones a un costo imposible.
El otro aspecto importante es el ACUERDO. El SLA no existe puertas para adentro de IT sino que parte de la negociación con el cliente, puesto que el destinatario de nuestros servicios debe saber en qué puede contar con nosotros y en qué no, deberá haber alguien que le brinde el soporte y la infraestructura adecuada a sus objetivos.
Una vez que usted definió el qué y el cómo junto con su cliente, ahora resta poner en marcha los PROCEDIMIENTOS que sustentarán ese acuerdo. Si algo falta muchas veces en los departamentos de IT es la dirección clara de cuál es el objetivo puesto en la tarea. Frente a un mismo problema: ¿Por qué decido modificar la configuración actual o planear la implementación de un nuevo software?. ¿Cuál es la diferencia?. Simplemente, la estrategia que da sentido a una u otra respuesta a un requerimiento. Cuando todo esto está listo, entonces comenzarán a planificarse -ahora sí con un rumbo claro- los cursos de acción para cada tipo de situaciones, en función de cómo se ha delineado el servicio de cara al cliente.
Y finalmente, en forma periódica, es importante REVISAR la eficacia de IT Operations en la entrega de los servicios convenidos y sus posibles conflictos con el SLA aprobado y los requerimientos expuestos por el cliente. Esta es la oportunidad de replantear qué servicios han quedado obsoletos y ya no son necesarios por los cambios que ha sufrido el negocio o son demasiado costosos de mantener y sería preferible actualizar.
Las revisiones del SLA son críticas para el manejo de las expectativas del cliente. MOF recomienda realizar un apropiado manejo de dichos intereses, de otro modo, IT siempre decepcionará a su cliente. Es el momento de recalcar todos los aspectos que IT ha cubierto en forma eficiente y respaldar con documentación que reporte con claridad el nivel de los servicios prestados y su relación con las actividades y objetivos de la organización.
Seguridad sí, ¿pero cómo?
Otros de los males de los que adolece el departamento de sistemas es la falta de organización adecuada. A menudo encontramos innumerables tareas inconexas y falta de claridad en el objetivo que sustenta cada procedimiento.
De hecho, cuando pensamos en seguridad, generalmente decimos: Ah!, firmas digitales, certificates servers, instalación de hot fixes y patches, políticas de firewall, intrusion detection.
Pues, si bien gran parte de la seguridad pasa por estas tareas y funcionalidades que usted tiene implementadas, la clave para que esto funcione son los PROCESOS. Y en este aspecto MOF tiene mucho para decirnos.
En el modelo de procesos de MOF existen 20 SMFs (Service Management Functions) o procesos, agrupados en cuatro cuadrantes en función de su similitud y de la misión que desempeñan en la estructura de IT Operations. Microsoft Operation Framework contempla el problema de la seguridad a través de dos elementos: un proceso (SMF) y un rol. En esta oportunidad voy a referirme al primero de ellos:
Security Administration SMF que se encuentra en el cuadrante de operaciones.
Podemos decir entonces que el primer aspecto importante de todo SLA es la DEFINICION. Es imprescindible evaluar las necesidades del cliente interno y las limitaciones que ofrecen los recursos disponibles y definir:
Dadas las exigencias del negocio, sus restricciones presupuestarias, los recursos tecnológicos, los recursos humanos, y un buen diseño de procedimientos, se podrá lograr ESTE determinado nivel de servicios en su punto óptimo para la empresa y para IT.
Y ese será el umbral que indique hasta dónde llegar. Ni más, ni menos. No menos porque se estaría afectando la disponibilidad de la tecnología que necesita disponible la organización para seguir el curso normal de sus actividades, y no más porque habría un mal aprovechamiento de los costos otorgándole al negocio lo que su cliente no le pidió y probablemente no necesite.
Entre los daños más comunes causados por problemas de seguridad encontramos pérdida de información, violación de accesos restringidos, corrupción de datos, etc. El objetivo de Security Administration SMF es justamente:
• Preservar la confidencialidad
• Resguardar la integridad
• Asegurar la disponibilidad
Se me ocurren en este momento algunas tareas que nos pueden servir de ejemplo:
• La revisión de las ACLs de archivos y objetos del directorio en nuestra red. Planificación de los
permisos y monitoreo de los accesos locales y remotos.
• El control de las vulnerabilidades a las que están expuestos los sistemas operativos y aplicaciones su
actualización en forma centralizada.
• Una correcta administración de los cambios (change management) para no dejar blancos en nuestras
soluciones que puedan representar amenazas de seguridad.
Ahora lo invito a reflexionar: ¿En qué rango de nuestras prioridades están dichas tareas?
En el cuadro que adjunté líneas atrás, se podrá observar que security administration es un proceso decisivo dentro de Operating Quadrant. Como tal, y por su nivel jerárquico, se relaciona y organiza en función de sí todo el resto de los SMFs. Más aún, este proceso tiene estrechas relaciones con otros procesos por fuera de dicho cuadrante. (Para más información sobre los cuadrantes y SMFs de MOF lo invito a ingresar a los links que adjunto al final de este artículo).
A continuación ejemplificaré cuán íntimamente ligados están algunos procesos de MOF con la seguridad:
System Administration. Este proceso certifica que la seguridad no se verá comprometida por causa de la organización del resto de los procesos y roles en la estructura de IT Operations.
Network Administration. Lidia con el mantenimiento de los componentes de la red, servidores, routers, switches, firewalls, etc. Una configuración y monitoreo inapropiado implicará un enorme riesgo de seguridad.
Problem Management. Este proceso debe asegurar que se mantiene el correcto grado de alerta respecto de posibles incidentes relacionados con la seguridad y que no se pasarán por alto a la hora de evaluar el punto de fallo. Si un servicio cualquiera de nuestra red está inusualmente lento o presenta comportamientos fallidos y erráticos, debería ser considerada la posibilidad de un ataque que esté ocasionando un “denial of service”. A menudo una vulnerabilidad, antes de ser explotada, nos da avisos que no estamos preparados para ver.
Financial Management. Con frecuencia, la seguridad es un aspecto omitido en el panorama presupuestario o bien se realiza una evaluación inadecuada de los costos. Es muy importante determinar cuántos fondos serán necesarios para conformar un entorno seguro y las posibles consecuencias para la compañía, también medidas en dinero, en caso de no tomar los recaudos necesarios.
Risk Management: El secreto es la continuidad
Trataré de utilizar un ejemplo sencillo para explicar los aspectos más importantes de la administración de riesgos, señalando cuáles a menudo descuidamos.
Supongamos un caso de una empresa que aún no ha desarrollado dentro de IT Operations un manejo de riesgos. Un día se interrumpe la alimentación de energía y la empresa, al no contar con un sistema de UPS, debe afrontar serias pérdidas dentro de las cuales está el daño en dispositivos de almacenamiento y la consecuente pérdida de información.
Luego de hacer frente a las consecuencias operacionales y económicas que el hecho ha causado, la empresa decide comprar una UPS.
Al año la empresa sufre otro corte de luz y la UPS falla. El departamento de IT, que en cierto modo ya había identificado el riesgo, comienza ahora a analizarlo y evaluarlo con mayor profundidad.
En primer lugar se da cuenta de que el riesgo cambió, y que la primera acción tomada no hizo desaparecer el riesgo, sino que lo transformó, y que ahora deberá contemplar las consecuencias de ese cambio. La causa continúa siendo un factor externo, la consecuencia permanece inalterable (la corrupción de datos), pero la condición se trasladó a un nuevo punto de fallo: LA UPS.
Ahora que el riesgo está identificado, se analiza su probabilidad e impacto, y se determina que por su criticidad quedará listado por encima de otros de menor prioridad. Se implementa un plan de acción que incluye como mitigación del riesgo verificar periódicamente el estado y comportamiento de la UPS ante cortes de alimentación, y hacer un script de apagado de los servidores para cuando se termine la batería. Un riesgo que tenía un alto porcentaje de probabilidad, ahora ha disminuido considerablemente.
Lo más importante de todo, es que a pesar de tener planes de mitigación, la empresa aprendió que el riesgo no desapareció, y por ello ideó planes de contingencia para cuando ocurra la consecuencia: mejorar el sistema de backup para poder restaurar los servidores en línea en el menor tiempo posible y así disminuir el impacto económico por la falta de disponibilidad de la información.
Tal vez pueda parecer muy obvio en este ejemplo, pero si trata de extrapolar estas nociones a los aspectos de su tecnología que resultan más inestables, verá que alguno de ellos no se está tomando en cuenta.
Algunas prácticas recomendadas:
• Monitoree el riesgo y haga un seguimiento exhaustivo, determinando si se modifica su causa, condición o consecuencia. Evalúe si es pertinente seguir considerándolo un riesgo.
• Analice el riesgo y haga una lista de prioridades. No desperdicie energía en riesgos a los cuales se hallará raramente expuesto.• Realice un control que asegure que los procedimientos sean llevados en forma adecuada, por el personal adecuado y en el momento adecuado.• Valúe económicamente sus riesgos, esto le dará otro panorama a la hora de efectuar un correcto análisis del impacto de los mismos.
La vieja frase “De IT se acuerdan solamente cuando hay problemas”, nos llama a un replanteo de cómo estamos haciendo las cosas. Por un lado habrá que dar conocimiento de los logros obtenidos conformes al SLA y, por otro, tendremos que cambiar de la vereda del incendio a la de mejores planes de mitigación y contingencia de riesgos.
Para más información sobre MOF:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/opex/mofrl/mofeo.asp
Conozca los fundamentos de ITIL:http://www.itil.org/
Estándares sobre seguridad:http://www.isfsecuritystandard.com/index_ie.htm
Otros:http://www.helpdeskinst.com/; http://www.itsmf.com/
