(Para hoy martes, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre la necesidad de dotar de un cuerpo documental a la operación de nuestros sistemas y hacerlo con el menor sufrimiento posible)

La creación de procedimientos es una de esas tareas que muchas veces, por no decir siempre, se pasa por alto dentro de las tareas propias de la gestión de sistemas. Naturalmente no es algo que a los técnicos les agrade mucho, precisamente porque lo que a un técnico le gusta es ‘jugar’ con los cacharros que tiene a su disposición; eso de escribir no es que sea sólo para novelistas, sino que cuando llega la fatídica hora de pasar al papel lo aprendido, o se ha olvidado, o ha pasado a ser la tarea menos prioritaria de las pendientes (a veces porque hay justificadamente otras tareas más urgentes, y a veces porque “se buscan” esas otras tareas). En definitiva, es una de esas cosas que presentan más batalla para el personal que esta operando y explotando los sistemas; según mi experiencia personal, si tuviera que decir cuál es la tarea más problemática que me ha tocado lidiar en el trato con las super-estrellas-técnicos-de-la-muerte, sin lugar a dudas diria que es la procedimentación de una plataforma, no tanto por el contenido sino por la calidad y la dedicación a la redacción, porque un procedimiento mal hecho es casi lo mismo que nada, por la rapidez en que cae en desuso y lo poco que se utiliza.

Algunos de ustedes (no todos) estarán pensando: ¿que tiene que ver esto con la seguridad? ¿esto no es una cosa que se hace una vez al año con los auditores? ¿tú tienes tiempo para esas cosas?

Bien, déjenme decirles que no sólo la seguridad no esta reñida con la documentación, sino que desde mi prisma ésta es como una extensión de cualquier tarea en la gestión de los sistemas y por lo tanto dentro de la seguridad es un aspecto crucial en la continuidad de las operaciones, el escalado de problemas, la anticipación de incidentes de manera reactiva y proactiva, en mantener un manual de operaciones limpio que permita que un sistema sea fléxible y transparente, etc. La lista es interminable. Al fin y al cabo, la documentación en la gestión de la operación y explotación de los sistemas acaba siendo procedimentación.

Pero, ¿cómo podemos saber que tenemos y que necesitamos? Ante todo, lo primero que hay que asumir es que la tarea de procedimentación de una plataforma es una tarea dura, así que como ejemplo vamos a plantearnos que tenemos un ‘parque’ de sistemas que gestionamos, diversos y que debemos poner ‘orden’ en este punto. Fijemos tres objetivos: mejorar la operación, facilitar el aprendizaje, y poner la base para incrementar la disponibilidad de los sistemas, con lo que vamos de salida bien servidos (nada de auditorias y excentricidades de momento, por favor). Para ello sugiero —como aproximación no pretenciosa y por supuesto mejorable— que podemos seguir los siguientes pasos:

1. Identificar los sistemas y categorizarlos por áreas.

La perspectiva que utilizo a la hora de poner orden en los sistemas es basar mi categorización de los sistemas existentes en categorias no técnicas, evitando clasificar los sistemas por su sistema operativo, fabricante, etc… Es como hacer un inventario de los sistemas existentes pero por una “metacategoría” superior. Por ejemplo: sistema de aplicación de nóminas, cortafuegos de redes de proveedores, etc. Se trata de buscar una palabra que nos pueda identificar la finalidad del cacharro en cuestión, y si de paso lo ubicamos en la red y físicamente, pues mejor que mejor.

2. Identificar procedimientos básicos.

No nos podemos pasar horas y horas mirando los sistemas, categorizándolos, conociéndolos, estudiándolos… si queremos arrancar y coger algo de inercia debemos comenzar por lo más básico: el procedimiento de parada y arranque. Naturalmente en este punto hay una vasta variedad de procedimientos, desde el típico cortafuegos hasta el sistema que para apagarlo y encenderlo requiere que se apaguen y enciendan decenas de aplicaciones y subsistemas internos. Esto es perfecto, es el momento justo de poder identificar nuevos procedimientos y empezar a conocer los sistemas desde un punto de vista técnico.

Ahora que ya tenemos el apagado y encendido de botón (manías de antaño) vamos un poco más allá.

3. Identificar las aplicaciones afectadas.

Ya en el punto anterior seguro que nos hemos topado de frente con sistemas donde un simple reboot no es tan sencillo, ya que los sistemas tienen la mala costumbre de alojar aplicaciones que además permiten conexiones externas o hacen uso de bases de datos. Desde casos mas o menos simples, como un AS400 clásico de pantalla verde hasta complejos sistemas distribuidos, nos enfrentamos a la tarea de poder conocer mejor qué albergamos en la casa. Para ello ¿qué mejor que los propios técnicos para que se vayan familiarizando con el negocio y con palabras de la casa? Aqui nos encontraremos con procedimientos ya mal escritos o acciones manuales del personal de turno (el súper de contabilidad, el jefe de recursos humanos,…) que hacen de su aplicación su vida y para los que meter mano a su aplicación es casi peor que meterle mano a su… bueno, se lo imaginan. Pero por el bien de todos es necesario obtener esa preciada información que es ¿y cómo arranco yo esto si tú no estas? Tras la respuesta se encuentra el procedimiento de parada y arranque, que asociaremos a nuestro sistema engrosando nuestra colección.

Vayamos un poco más al fondo de la cuestión.

4. Agrupar los procedimientos en un manual de operaciones.

El manual de operaciones no es una cosa que yo considere estandarizada y de hecho este ‘nombre’ no lo considero acuñado por la industria. Para mi el manual de operaciones es el lugar donde, de una manera rápida y eficaz, vamos a tener el día a dia del operador y técnico de sistemas. En éste debemos ser capaces de encontrar, categorizado, una descripción de las tareas que se ejecutan habitualmente con los procedimientos asociados, así como enlaces a documentación externa que podamos requerir para entender mejor la operativa. Incluiremos aquí la documentación de incidencias, procedimientos, enlace a manuales, teléfonos importantes de contacto, gestión de autorizaciones, etc.

Como verán, no sin poco esfuerzo, poco a poco estamos comenzando a disponer de mas información de la cual tirar del hilo para poder gestionar una plataforma de forma completa.

5. Elevar la situación a la disponibilidad de operaciones.

Ahora es cuando podemos darle ese valor añadido a nuestra documentación. De los procedimientos existentes vamos a declarar como críticos aquellos que afecten a la disponibilidad de las operaciones. ¿Qué significa esto? Pues ni mas ni menos que vamos a disponer de un conjunto de procedimientos que son los que nos van a dar la posibilidad de abordar problemas de contingencias locales y globales. Es en este punto donde empezaremos a echar en falta aspectos gestión de medios de cintas de backup/recuperación, procedimientos de restauraciones parciales/totales, funcionamiento básico del cuadro eléctrico, SAI y grupo electrógeno,… lo que significará que estamos en el camino correcto para poder abordar la totalidad de los procedimientos para la gestión integral de una plataforma.

Naturalmente me dejo mucho por el camino, como por ejemplo definir el procedimiento, definir las figuras intervinientes, los medios que se emplean, la validez y caducidad del procedimiento, autor, requisitos de medios gráficos y escritos utilizados, revisiones periódicas y pre-puesta en producción, etc. Pero la base que he intentado plasmar aquí posibilita contemplar una plataforma en toda su amplitud desde el prisma de la operación, buscando asegurar la disponibilidad de sistemas teniendo como soporte básico la documentación. He visto en muchos lugares cómo la simple palabra “procedimiento” hacía que las miradas se fijasen en el techo, y surgiesen las mismas excusas de siempre (eso es lo que son: excusas) por parte de los técnicos: “es que no tenemos tiempo”, “es que somos poca gente”, “¿para qué procedimentar si soy el único que hace las copias?”, etc. Pero si nos lo proponemos, una vez hayamos alcanzado la “velocidad de crucero” veremos como el “efecto procedimientos” permite mejorar la calidad de la plataforma al decrementar los tiempos de respuesta de las incidencias, independizar al técnico que las atiende, mejorar el conocimiento general y permitir la rotación de los técnicos, abarcar proyectos de automatización de plataforma, orientar el reporting al negocio… infinitas posibilidades que con las herramientas adecuadas permiten trabajar de forma flexible con el entorno.

De cualquier modo, no pierdan el tiempo: lo que hagan, háganlo bien.

(+7 rating, 7 votes)

 Loading ...