La importancia del "testing"

Esta tarde de casualidad, he encontrado un ranking con los 10 mayores desastres causados por servicios TIC. Algunos ya los conocía y otros la verdad es que me han sorprendido.

El número 1 de la lista es impactante: en 1983 un fallo en el sistema de detección de misiles soviético detectó por error un ataque estadounidense y estuvo a punto de desencadenar la tercera guerra mundial.

Todas ellas, sin duda se produjeron porque los sistemas no habían sido debidamente probados. Se considera que en proyectos críticos (como sin duda lo era el soviético), el 80% de su presupuesto debe ser destinado la realización de pruebas (testing).

Esta máxima, en el caso de los planes de recuperación de desastres (PRD) no debería ser menospreciada. En este sentido, nos podemos plantear la siguiente pregunta: ante un desastre, ¿de qué depende el éxito del plan de recuperación? Mi opinión es que depende de lo bien que haya sido "testeado".

Desde mi punto de vista, realizar un diseño óptimo del plan, es importante, pero sin duda lo es más la simulación periódica del mismo, para poder corregir los posibles fallos de diseño e instruir adecuadamente a las personas implicadas. La única forma de obtener suficientes garantías de éxito ante un desastre, es incluir este plan dentro de un ciclo de mejora continua.

Yo creo que sin haber realizado estas pruebas, la correcta recuperación de los sistemas, quedará en gran medida, en manos del azar.

¿Cómo realizar un BIA?

BIA son las siglas de Análisis de Impacto en el Negocio, en inglés, Business Impact Analysis.

El BIA ayuda a integrar los servicios de TI en los procesos de negocio, cuantificando el impacto que una indisponibilidad de estos servicios tendría en los mismos y determinando, para cada servicio de TI, el tiempo de recuperación necesario para que dicho impacto no pase a ser inasumible por el negocio ya sea desde un punto de vista económico, de imagen, legal, etc.

El BIA se engloba, como una de sus primeras fases, en el Plan de Continuidad de los Servicios de TI que, a su vez, forma parte del Plan de Continuidad del Negocio.

Por tanto, la organización de TI debe conocer en cuanto tiempo puede recuperar sus servicios y en cuanto tiempo necesita el negocio que sean recuperados. Estas dos variables se conocen como RTA (Recovery Time Actual) o Tiempo de Recuperación Garantizado y RTO (Recovery Time Objective) o Tiempo de Recuperación Objetivo o Deseado.

Es necesario tener en cuenta una variable más: el RPO (Recovery Point Objective) o Punto de Recuperación Objetivo o Deseado. Este valor describe la cantidad aceptable de datos que se pueden perder, medido en tiempo. Este valor, que ha de proporcionar el negocio, está estrechamente ligado a la política de backup, archiving, replicación de datos, etc. que se esté realizando.

Una vez se obtengan dichos valores para cada servicio, será el momento de diseñar las estrategias de recuperación que permitan cubrir ese gap.

¿Cómo calculamos el RTA?

1. El primer paso, por tanto, es calcular, para cada servicio, su RTA. Para ello, es condición necesaria disponer de la lista de servicios de TI que soportan los procesos de negocio de la organización.

2. El segundo paso consiste en estudiar cómo la infraestructura de TI soporta el servicio. Es decir, qué cadena de activos de TI soportan el servicio de TI. Estos activos se pueden agrupar, básicamente, en los siguientes grupos: CPD, Infraestructura WAN, infraestructura LAN, servidores, software (sistemas operativos, aplicaciones estándares, aplicaciones de negocio) y datos.

3. Para cada uno de estos grupos de activos en general y activos incluidos en particular, estudiaremos las contingencias existentes. Básicamente el tipo de contingencia (redundancias, tolerancias, contratos de mantenimiento, equipos en spare, etc) y la dependencia de la contingencia (si depende de la organización o de un tercero).

4. Por último, con estos datos, calcularemos el Tiempo de Recuperación Garantizado (RTA). El RTA del servicio lo marcará el mayor RTA de la cadena de activos que lo soporta.

¿Cómo calculamos el RTO?

Para calcular el RTO, nos reunimos con los diferentes departamentos de la organización y les preguntamos dos cosas:

1. ¿Cómo utilizan la informática?. Con esta pregunta tratamos de averiguar qué servicios de TI utilizan y cómo los utilizan.

2. ¿Qué dependencia tienen de la informática? o más concretamente ¿Cuánto tiempo consideran que, para su operativa diaria, es admisible que un servicio de TI pueda no estar disponible?. Aquí es importante matizar al entrevistado que se trata de un escenario de desastre.

Con la información obtenida de las entrevistas y el visto bueno del Comité de Dirección de la organización, podremos establecer el RTO para cada servicio de TI.

Si, para un servicio de TI determinado, el RTO obtenido es inferior al RTA calculado, no se estará cumpliendo con los requisitos del negocio y, como ya se ha comentado, deberemos diseñar un escenario futuro que nos permita eliminar esa diferencia. Ese escenario futuro tendrá que tener en cuenta la tecnología, los procesos, las personas y los proveedores (ITIL v3).

Lo más importante es que el RTA lo proporcione la organización de TI y el RTO lo proporcione el negocio. Esta clarificación de espectativas mútuas es la mejor manera de integrar los servicios de TI en los procesos de negocio. Es un error que desde TI se piense que se sabe lo que necesita el negocio sin haber intentado averiguarlo mediante una aproximación minimamente estructurada como la que se ha expuesto.

Certificaciones TIC: la tendencia de un futuro inmediato

Quizá por el hecho de trabajar en un sector relativamente joven, lo cierto es que las certificaciones de calidad en las TIC (ISO27000, ISO2000, etc.) no están tan "extendidas" como en otros sectores, sobre todo como en aquellos relacionados con la producción.

En la actualidad, desde las organizaciones competentes se está trabajando por impulsar la calidad en el ámbito TIC, así que en los próximos años se espera que aparezcan nuevas normas y que evolucionen las existentes.

Sin embargo, la realidad es que hoy en día son muy pocas las empresas que han conseguido este tipo de certificaciones. Las causas pueden ser muy diversas: puede que los clientes no las exijan, que las organizaciones crean que aportan muy poco al negocio, que el mundo de la certificación TIC no sea lo suficientemente maduro...

Más allá de la confianza que aporta que "alguien" independiente garantice que estás trabajando de forma adecuada y con los medios necesarios, muchas empresas se plantean implantar estas normas para conseguir "el sello", es decir, la certificación se ve como un hecho que les diferencia de sus competidores: en definitiva, una buena estrategia de marketing.

Llegados a este punto, es posible que poco a poco vayan cambiando las reglas de juego: lo que se inició como un intento de desmarcarse de la competencia, puede que con el tiempo, acabe convirtiéndose en un requisito imprescindible para operar en el sector, ya que nadie querrá quedarse atrás, y los clientes no confiarán en aquellos que no muestren orgullosos sus correspondientes certificados.

Gestión de incidencias, gestión de peticiones o, simplemente, gestión de tareas

En esta entrada voy a hablar de mi particular visión acerca de la gestión de incidencias y peticiones en los Help Desk, Service Desk, etc.

En la versión 2 de ITIL, el proceso de gestión de peticiones de servicio estaba incluido en el proceso de gestión de incidencias. Se entendía (y yo sigo entendiendo) que la manera de tratar las peticiones de servicio era bastante similar a la manera de tratar las incidencias. Si tenemos presente que las peticiones de servicio son aquellas solicitudes realizadas por los usuarios tales como, solicitar un PC nuevo, una conexión VPN, un restore, etc, podemos entender que se gestionen de forma parecida a las incidencias.

En la versión 3 de ITIL, ambos procesos se separaron. No me parece mal a nivel teórico. A nivel práctico sigo pensando que en ITIL versión 2 ya quedaba claro: al categorizar distinguimos entre incidencias y peticiones de servicio y luego clasificamos en función de la categoría elegida.

Tenemos, por tanto, por un lado gestión de incidencias y por otro gestión de peticiones. Sin embargo a mi me gusta hablar simplemente de gestión de tareas.

Para razonar lo anterior, empezaremos hablando de cómo se gestiona una incidencia o una petición de servicio. Se puede hacer, básicamente, de dos maneras:

1.- En lo que podríamos llamar "modo estrella": el operador del help desk recibe la llamada, el correo, lo que sea. El operador lo intenta resolver él en primera instancia y si no lo consigue lo pasa a un técnico. El técnico realiza la acción necesaria y devuelve la incidencia al operador. El operador la cierra si ya está resuelta o se la trasmite a otro técnico para que lo haga. Este segundo técnico devuelve la incidencia al operador y este la cierra si está resuelta o la envía a otro técnico....Aquí he exagerado el escalado, no suele haber tantos niveles.

Si se trata de una petición de servicio, lo mismo. El operador traspasa la petición al primer técnico para que realice la tarea. Una vez realizada, el técnico se la devuelve al operador para que este se la pase al siguiente técnico necesario para resolver la petición....

2.- También es posible que los diferentes técnicos implicados conozcan (o esté documentado), para cada tipo de incidencia y petición de servicio, quien es el siguiente que debe hacer algo. De esta manera. sólo el último, devolverá la incidencia o petición al operador de help desk para su cierre. Sinceramente, bastante difícil.

Todavía existe una tercera opción, la que a mi me gusta:

a) Para todas los tipos de incidencias y peticiones de servicio, definimos las tareas necesarias, quien las ha de realizar (grupo o persona) y las dependencias entre ellas.

b) Insertamos esta información en la herramienta y la asociamos a la clasificación de las incidencias y peticiones de servicio.

c) La herramienta nos permite la posibilidad de añadir o quitar tareas a las ya definidas por defecto.

d) Los diferentes técnicos y no técnicos que han de resolver la incidencia o petición de servicio trabajan únicamente con tareas de manera que ellos sólo ven en la herramienta aquellas tareas que pueden realizar. El flujo de las mismas ya está definido en la herramienta.

La gran mayoría de herramientas de nivel medio-alto permiten trabajar con flujos de tareas. Sin embargo, no se suelen utilizar porque no se ha realizado el trabajo previo de definir lo expresado en el punto a); o porque no se mantienen actualizadas; pero, sobretodo, por cuestión de precio.

Trabajando con flujos de tareas nos interesa que toda la organización de TI y, seguramente, parte de la organización fuera de TI, trabaje con la herramienta. Si, por ejemplo, el departamento de compras está fuera de TI y trabaja con nuestra herramienta, podremos asignarle la tarea de compra de un PC nuevo cuando entre un empleado en nuestra empresa.

El problema reside en que la gran mayoría de estas herramientas se licencian por puesto de trabajo y, entonces, se intenta minimizar el número de personas que necesitan trabajar con ella.