🧨 SAPocalypsis Now Episodio 31

Esta historia combina hechos reales, ampliamente documentados en litigios públicos del sector ERP, con elementos completamente inventados para darle cuerpo narrativo: nombres de empresas, personajes, diálogos, escenas y detalles concretos de esta historia son ficticios. Cualquier similitud con personas, empresas o situaciones reales más allá de los hechos públicamente conocidos es pura coincidencia. Ni el nombre de la empresa cervecera ni el de la consultora aquí utilizados corresponden a los reales, y ningún diálogo reproducido aquí ocurrió tal cual se describe.

"Coge el casco, el mono, los pañales y el portátil, súbete a un taxi y vete a Colonias SA"  

Era verano de 2006, recuerdo que estaba en la oficina de Logisap Consulting SL y que era un día tranquilo por la mañana, diría que un martes. Yo regresaba de desayunar y echarme unas risas con los compañeros cuando me senté a leer correos antes de abordar mis tareas.

Disponíamos de una lista de distribución llamada forosap en la que cualquier compañero podía preguntar y responder dudas de los demás. Me encantaba cotillear esos correos ya que se aprendía muchísimo ya que su uso era realmente extendido en la compañía, incluso los directores, todos ellos ex-consultores, contestaban siempre que podían dando rienda suelta a su experiencia y extenso conocimiento lo cual animaba a más gente a participar.

En contadas ocasiones había preguntas que como consultor Basis podía o me sentía con autoridad para contestar, y justamente esa tarde, entró una que decía más o menos así: "¿Cómo puedo deshacer el borrado de un job?". Nadie había respondido aún. Pensé, ésta me la sé. Recuerdo que tardé menos de un segundo en responder "No se puede". Quién preguntaba era uno de los dos consultores junior asignados al cliente Colonias SA para tareas básicas de operación Basis bajo el paraguas de MF Enterprise, otra consultora grande la cual era realmente la prestadora del servicio. 

En menos de un minuto, llegó la repregunta "¿Seguro que no hay ninguna forma?". A lo que ya me temí que la habían liado y respondí, "Sí la hay, si está documentado recrearlo y si no, deberás restaurar la última copia de seguridad del sistema en otro sistema auxiliar, levantar con 0 procesos de batch y usuarios bloqueados por precaución y copiar el job borrado a mano". 

Después de mandarlo me quedé unos instantes pendiente y al ver que no había repregunta me dispuse a empezar con mis tareas cuando de repente una mano me tocó el hombro...

Me giré, era mi jefe, y ya era un pelín tarde para bajar a desayunar y demasiado pronto para ir a comer... "tienes un minuto? Vamos a la sala...". La vehemencia fruto de mi juventud del momento, me hizo plantear por un segundo que quizá iba a recibir una colleja por responder con demasiada prepotencia, algo de lo que adolecía persistentemente en esa época. 

Así que entré en la sala con la cabeza baja dispuesto a recibir un justificado rapapolvo pero mi jefe me tenía preparado otro regalito. "Coge el casco, el mono, los pañales y el portátil, súbete a un taxi y vete a Colonias SA, que están parados porque se han cargado todos los jobs de producción"

Y eso hice, mientras en paralelo mi jefe gestionaba los accesos para que nada más llegar allí pudiera pasar los controles de seguridad. Una vez en el departamento de informática, y antes de que el cliente se percatara de mi presencia, me senté con mis compañeros para que me contaran exactamente como había ocurrido todo. Al parecer, ellos ejecutaron unos procedimientos que les había proporcionado MF Enterprise en la que las tareas de reorganización estándar de SAP se ejecutaban manualmente con el consiguiente riesgo a error humano en la pantalla de selección. Y el error ocurrió, se borraron todos los jobs de producción. Cuando lo comprendí, un rayo de esperanza me atravesó el cráneo y dije "pués los copiamos de preproducción!", a lo que mi compañero contestó con la voz entrecortada que ese procedimiento se había hecho primero en desarrollo y luego en preproducción antes de en producción. Vamos, que no podíamos sacarlos de ningún lado.

Alineamos nuestra posición de que la única forma de recuperar los jobs no documentados era restaurando en un entorno auxiliar o de preproducción que tuviese suficiente potencia para levantar una base de datos de 2TBs. Levanté la cabeza para buscar con quién hablar y el escenario era dantesco. El responsable de informática reunido, el resto del equipo del cliente al teléfono intentando desbloquear el almacén, un café en la moqueta...

Finalmente nos atendió un técnico de Oracle de MF Enterprise. La primera pregunta se respondía sola: "No van a parar, no?" Todos los departamentos tienen mayor o menor afectación, almacén lo que más, pero si no han parado a estas alturas ya tiran para adelante. También nos cuenta que acaban de migrar producción a 64 bits ese mismo fin de semana. Es decir, nos estaban ofreciendo un hardware de 32-bits que había estado dando el servicio de producción hasta hace dos días. Sobre el papel genial, puesto que el cambio de 32-bits a 64-bits además de ser reversible no altera los ficheros de datos, simplemente afecta al sistema operativo y a los binarios que usas además del hardware. Sin embargo, los datos ya no estaban ahí y había que abordar una restauración de más de 2 TBs que en aquella época y con aquella tecnología era muchísimo. Sea como sea, reaccioné inmediatamente "entonces, que empiecen a restaurar ya...". Pero no era tan fácil, una auditoría de seguridad había advertido de que las cintas debían alejarse inmediatamente del servidor al menos 10 kms por riesgo ante desastres naturales, y Colonias SA había aplicado esas recomendaciones y por tanto las cintas tenían que recorrer toda la ciudad.

Recuerdo que se solicitaron las cintas físicas ese mismo día a media tarde y que no llegaron a las instalaciones donde teníamos el servidor de 32-bits hasta entrada la noche. Mientras tanto, el técnico de Oracle y los de UNIX habían revisado los discos, habíamos generado y revisado el control.sql para regenerar los control files y los uids y permisos de usuario coincidían. Se lanzó la restauración a eso de las 23h y acordamos reencontrarnos a las 5:00 para descansar un poco y dejando un retén para verificar que el proceso no se interrumpía.

Al día siguiente, con el técnico de Oracle estuvimos solucionando algún problema de librerías con Oracle que finalmente se solucionó con un relink y montamos una reunión para tomar la decisión de cómo proseguir. El responsable de informática era reacio a levantar tan siquiera SAP. "Hemos hecho un refresco de sistema sin procedimiento, ¿hay alguien que me garantice al 100% que si levanto SAP no va a haber jobs o crons que puedan hacerse pasar por producción respecto los demás entornos de la compañía?" Nadie le rebatió, básicamente porque todavía no teníamos nada. Así que tocó entrar a nivel de consola SQL*Plus a hacer SELECTs a las tablas de jobs TBTCO, TBTCP. Comparando resultados de la restauración y producción, descubrimos que había exactamente 300 jobs en el entorno de restauración que no existían en producción.

No solo eso, sinó que los conseguimos identificar, y conseguimos obtener información de sus pasos: programa ABAP, variante, usuario de verificación de autorizaciones, así como su programación. Sin embargo, tener la información no iba a hacer que se solucionara todo, y seguimos investigando hasta encontrar en internet un programa ABAP que exportaba e importaba la definición de jobs entre distintos sistemas mediante simples ficheros planos CSV. Lo metimos en desarrollo, le hicimos varios arreglos para que no funcionara para un job sinó para un rango de jobs, lo probamos y funcionó.

Con todo ello nos presentamos a la mesa del director de informática pero su cara no mejoró. Estaba muy bien haber conseguido todo aquello, pero se habían recreado muchos jobs manualmente sobre la marcha en las últimas 24 horas, y aunque seguramente no se hubieran creado los 300 jobs, sí que se habían creado los más importantes y críticos, es decir, aquellos que hacían que la compañía funcionase. 

Finalmente, un equipo del propio cliente formado por funcionales se pusieron a puntear los jobs de producción versus nuestras exportaciones del entorno restaurado. En el entorno restaurado nunca se llegó a levantar SAP y yo no puedo contar mucho más porque tras esa decisión me llamó mi jefe para irme inmediatamente a otro marrón. ¿Documentarían esos jobs?

De esta experiencia saqué varias lecciones aprendidas:

- La primera es que los procedimientos de operación deben ser ejecutados con unos mínimos de comprensión y conciencia de lo que se está haciendo, y siempre deben tener protecciones eficientes y fiables ante error humano.

- La segunda es que no puede ser que todo tu sistema funcione a golpe de jobs. Puede haber jobs críticos, por supuesto, pero siempre documentados, y nunca un número elevado.

- La tercera es que un buen consultor Basis debe saber algo de ABAP, lo mínimo, pero lo justo para entender código en internet (o hoy día algo generado por IA) que puede salvarle la vida y algo de SQL*Plus y Excel para hacer tratamiento de datos, joins básicas y saber exportar e importar datos.

- Y la cuarta es que ni siquiera las mejoras consultoras en auditorías de seguridad plantean la posibilidad real de una necesidad de restaurar los backups que prodigan. Llevarse las cintas a la otra punta de la ciudad para que así se cumpla la distancia de 10 kms te cubre ante un tsunami en el Mediterraneo pero no para lo que realmente hace falta. Esa distancia en una ciudad con mucho tráfico a la hora de la salida de los colegios, sumado a una infraestructura tecnológicamente inadecuada para esos volúmenes, resulta en un tiempo de restauración de más de 12 horas cuando no debería ser de más de 2.