(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.
“Chapeau” por el artículo, que me parece, además de interesante, una referencia a mi trabajo actual tan acertada,que me siento plenamente identificado en el contexto o labor de técnico/documentador.
Obviamente estás hablando de las dificultades que se pueden encontrar a la hora de documentar, y si bien es cierto que es así, debo aportar un punto de vista adicional a lo dicho:
Me voy a referir a las incidencias: aquello que surge por primera vez y provoca tanta inseguridad a tantos usuarios y responsables.
El ansia de documentación que impera en un entorno distribuido -dónde habitualmente se mueven muchas personas realizando labores que DEBEN ser documentadas- es tal que, en momentos concretos, y ante una incidencia de cualquier tipo, los responsables quieren (y deben) saber detalles de los eventos, poco menos que en el preciso instante en que se producen.
Me parece justo, necesario e imprescindible que así sea, pero para el técnico que está resolviendo una incidencia, se genera a su alrededor un entorno estresante, que puede llegar a complicar y retrasar incluso la disponibilidad del entorno afectado. No se puede documentar DURANTE la resolución de un problema, ya que puede salir algo así:
– Sospecho que el problema surge por un fix de sistema operativo aplicado por seguridad…… (pasan horas… mucho estrés…)
– Descargo un nuevo parche XYZ987123 recomendado por el fabricante.
– Muevo el parche por ftp al servidor
– arranco la herramienta de configuracion/instalación de parches
– ejecuto instalacion del arreglo en el sistema que tiene la version 18.33 SP1
– verifico que se activa correctamente
– confirmo el arreglo
– devuelvo el sistema al entorno.
Y prácticamente… (el ejemplo no es el más adecuado, pero lo resume) has ocupado el 75% del tiempo en escribir eso. No es que no se deba hacer, sino que me parece que NO se debería hacer al mismo tiempo que estás usando de tu profundo conocimiento (o desconocimiento) del entorno para solventar un problema que perturba la producción. Creo sinceramente que bastaría con decir tres cosas en tres momentos diferentes:
1.- Se detecta un problema (determinado o no) en tal sistema, procediendo a su investigación.
2.- Se ha encontrado la solucion al problema X y la duración prevista de la no disponibilidad será en torno a n horas/n minutos.
3.- Se ha solucionado la incidencia: Se emitirá en breve un informe/procedimiento sobre el problema encontrado.
Y ya, con el sistema en producción, proceder a documentar. No pienso que sea una tarea dura, excepto si estás informando en tiempo real, por escrito, por teléfono, por telepatía (a algunos les gustaría ver/escuchar en tiempo real lo que estás escribiendo o diciendo), respecto al problema.
No puedo escribir más, porque mi jefe de proyecto me pide que documente lo que estoy investigando (esperando respuesta del fabricante) en relación a una incidencia surgida… y es para ayer.
Saludos.
Antes que nada, gracias por tu comentario.
En el caso de las incidencias para mi tiene una mención especial y aparte por diversos motivos:
1 – Una incidencia empieza a ser documentada desde que se notifica al equipo de soporte. En este caso siempre se debe disponer de una herramienta, como las que vosotros teneís, para que la labor de documentación sea ya parte de la propia resolución de esta.
2 – Una incidencia debe dar lugar siempre – despues de su resolución – a una reflexion sobre las acciones preventivas y reactivas a la incidencia. Ejemplo: revisar un procedimiento, adecuar un control especifico, implantar un nuevo control para prevenir futuras incidencias…Y es en este punto donde tiene un papel importante la documentación.
Estoy de acuerdo que, mientras ejecuto la resolución de la incidencia o desconozco su solución final, no puedo estar ‘dando a la tecla’ para escribir algo que puedo dejar atrás, pero como en todo siempre existen dos aproximaciones, y en base a esto puedo decir que Vodafone, desde atención al cliente (esta claro que no es lo mismo que una gestión técnica) deja rastro de cada acción en una incidencia de negocio. No conozco el caso de IBM a la perfección, pero alguna vez he visto que su sistema de gestión de ¿incidencias? deja bastante rastro.
Naturalmente de la incidencia al procedimiento hay un paso largo (una puede ser causa y otra consecuencia), pero una relación muy estrecha.
Siempre es necesario encontrar cual es el equilibrio en la gestión en tiempo ‘real’ de los sistemas y las labores de gestión ‘offline’.
Muchas gracias por tu visión y aproximación!!!
Estoy plenamente de acuerdo con el artículo y con vuestros comentarios posteriores y solo deseo añadir que llevo mas de veinte años documentando sistemas y creando procedimientos, y recibiendo por ello las críticas jocosas de compañeros que no consideran necesaria tal documentación, y cuyo pensamiento se transmite fácilmente a los directivos que deciden cuales son los presupuestos y medios necesarios para el área en la que trabajo, incidiendo en forma negativa el considerar que la documentación de sistemas y la creación de procedimientos no aporta valor añadido al resultado fina.
Afortunadamente para eso están las uaditorías y sus resultados suelen ser bastante claros en los requerimientos de documentar sistemas y procedimientos en uso ya que de palabra las auditorias no son válidas, las evidencias hay que presentarlas.
Por último decir que es frecuente encontrarse con procedimientos que fueron escritos tiempo atrás y nunca se revisaron, siendo recomendado por los auditores que se revisen con una periodicidad de no maas de dos años.
La cosa va mejorando pero no mucho, salvo auditorías que empujen.
Un saludo