🧨 SAPocalypsis Now Episodio 28

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.

Hacía ya varios meses que el proyecto de implantación de SAP había arrancado. Era una empresa con más de 50 millones de clientes, que había funcionado toda la vida con mainframe y que ahora había montado en SAP los procesos de atención a cliente de sus 10 centros. 

Estábamos todavía todo el equipo de implementación operativo puesto que estábamos con los rollouts de los centros y además estábamos inmersos en la mejora de muchos procesos.

Es preciso destacar que debido a cuestiones de volumen y por algunas limitaciones para segregar correctamente a nivel de centro por parte de la solución vertical de SAP que se implementó, se decidió adoptar un modelo basado en diversas instancias de producción. Algunos centros que guardaban interdependencia de procesos irían juntos, mientras que los demás irían aislados en un sistema de producción dedicado.

No era para menos, para el centro más tocho, tuvimos que montar prácticamente una infraestructura de límites, con más de 10 servidores de aplicación para atender a 9.000 usuarios.

Los datos que debían compartir entre todos los centros, eran el maestro de clientes y de materiales, aparte del workbench y customizing global. Por ello, y para disponer de un único punto de acceso y menú para los usuarios, se dispuso un sistema de producción adicional que cubriría todos esos procesos centrales y al que llamamos "hub".

Sin embargo, los clientes se seguirían gestionando desde mainframe por una buena temporada. Así que se implementó una integración entre hub y mainframe para hacer la consulta de clientes on-demand en lugar de cargar 50 millones de datos de calidad discutible en cada uno de los sistemas locales de cada centro. Y funcionaba muy bien, en cuanto un cliente era atendido en uno de los centros, si no existía en el sistema de ese centro, se lanzaba la consulta al hub, y si ahí tampoco existía, entonces el hub lo iba a buscar al mainframe. 

Una vez los datos de ese cliente ya se encuentran en el sistema del centro, se permitía su actualización, pero los cambios realizados no se propagaban a otros centros que pudieran tener también registrado ese cliente, por lo que en ese caso los datos dejaban de estar sincronizados.

Así que nos pusimos a revisar todo el proceso con Jonás, el responsable ABAP, y determinamos que cualquier modificación hecha en el sistema local, debía propagarse al hub, y éste a su vez debía redistribuirlo a los demás con el objetivo de que si alguno lo tenía, lo actualizara y sinó lo ignorara.

A pesar de que pudiera parecer un cambio de cierta complejidad, en ningún momento pensamos en activar ningún protocolo especial por el paso a producción de este cambio. Al fin y al cabo estábamos reutilizando mecanismos que ya estaban funcionando, además de que ya estábamos habituados a este tipo de integraciones no solo para los clientes sinó también para los materiales. Por todo ello, se pasó el cambio un lunes a última hora después del cierre de centros como mandaba el protocolo de cambio estándar.

Cuando llego a la oficina el martes a las 9:30, ya antes de montar el portátil veo a un par de project managers junto con el director de proyecto y varios consultores agolpados en el puesto de trabajo de Jonás y con cara de mucha preocupación. Conforme me acerco, se van percatando de mi presencia y van abriendo paso hacia él. 

Jonás: Pedro, no se puede entrar a ningún entorno de producción... 

yo: ¿Qué ha dicho Basis?

Jonás: Lo están mirando...

yo: Vámonos con ellos, aquí no tenemos nada que hacer

Entramos en la sala con los compañeros de SAP Basis, ahí estaban Eva, Marta y Toni. Les damos los buenos días y nos instalamos.

yo: ¿Cuando ha empezado todo?

Eva: Con la apertura, a las 9:00..

yo: ¿Que sale en el dpmon?

Toni: Todo ON HOLD de RFC..

yo: Alguno ha conseguido entrar ni que sea al menú?

Marta: sí pero de casualidad y luego ...frito

yo: ¿Habéis tratado de cambiar algunos BATCH por DIA?

Marta: Sí, se quedan enganchados al instante

yo: Jonás, tiene que ser lo que subimos ayer. Subió algo más de integraciones?

Jonás: No..., yo que sé..

yo: Lo desactivamos. Si bloqueamos los usuario de RFC en el hub y los locales?

Marta: No, eso no servirá, mejor cargarse o renombrar todos los destinos RFC ...

Toni: No, tardaremos mucho... no llegamos a la SM59... habría que hacer una UPDATE a pelo en la RFCDES por consola SQL... y antes mejor un export de la RFCDES por si la liamos

Eva: ¡Parémoslo todo! Total, ¡no pueden hacer nada! Y arranquemos de forma controlada

yo: Ok, todos de acuerdo? Lo comunico a negocio pero acordemos antes qué vamos a arrancar y qué vamos a dejar parado

Eva: Arrancamos Barcelona, vigilamos activamente el dpmon, y si todo va bien, arrancamos el hub y vemos qué ocurre.

yo: Vamos parando hub ya.

Todos estábamos de acuerdo, así que inicio llamada al CIO y al responsable funcional, les cuento el plan y les pido que comuniquen a los centros. Seguidamente les doy el OK a Basis para parar todo y arrancar solo Barcelona.

yo: ¿Qué vemos?

Toni: Van entrando... mira, aquí veo una en espera.. 

yo: ¿Aparecen más? 

Toni: No.. sí.. aparecen más pero van saliendo por timeout las otras, hay procesos de diálogo libres en todo momento, están pudiendo trabajar pero sin hub...

yo: Ok, arrancamos hub y seguimos monitorizando dpmon

Eva: Arrancando... arrancado... ¡Ahí entra otra consulta al hub!

Toni y Eva: ¡Están poniéndose todos los procesos ON HOLD!.. ¡Ya no queda casi nada libre!

Marta: ¡En menos de 2 segundos se han quedado todos los DIA pillados!

yo: ¡Paramos otra vez y arrancamos solo Barcelona! Jonás, esto lo ha hecho 1 sola consulta. Ponte a revisar que está pasando con la redistribución de clientes.

Jonás: Pero si no arrancamos hub..

Marta: A ver, podemos renombrar solo el destino RFC de hub a Barcelona y que Jonás lo ajuste en debugging

Toni: Ok, con ese update me atrevo (arremangándose)

Al rato teníamos Barcelona y hub arriba y a Jonás debugueando un caso de redistribución. Como el destino RFC de hub a Barcelona no existía la llamada petaba con un dump inmediatamente sin consumir tiempo. O sea, la búsqueda de clientes no existentes en Barcelona petaba al usuario pero no hundían el sistema y Jonás podía analizarlo en debug y ponerle el nombre que tenía para ver qué ocurría. 

Jonás descubrió que la redistribución se estaba llamando recursivamente. Un simple cambio en un cliente de Barcelona, era mandado al hub y se actualizaba. Hasta aquí bien. Esta modificación disparaba la redistribución, pero la redistribución incluía Barcelona. Cuando Barcelona lo recibía, y comprobaba que existía, lo volvía a actualizar, lo cual volvía a generar puntero de modificación, lo cual volvía a disparar la comunicación del cliente al hub. Y vuelta a empezar. 

En apenas unas pocas líneas de código y solo cambiando una coma en un cliente, éramos capaces de inutilizar en 2 segundos 11 sistemas de producción algunos de ellos con numerosos servidores de aplicación. Recuerdo como dije en cachondeo: Hemos creado el primer virus en ABAP...

Jonás modificó el código para excluir el origen del cambio en la redistribución y lo pasamos como cambio urgente y todo se solucionó, renombramos la RFC, arrancamos resto de sistemas, comunicamos, observación y finalmente nos fuimos a hacer unas cañas.

En los días siguientes, definimos grupos de RFC por cada proceso, con parámetros de ejecución muy restringidos, dejando siempre almenos un 50% o más de los servidores de aplicación fuera de las RFCs, usuarios específicos por proceso en lugar de un genérico de RFC, y construimos unos shell scripts que podían modificar de una el nombre de todos los destinos RFC para desactivarlos o activarlos con efecto inmediato y con el sistema colgado o detenido. De hecho, esta lección también la extrapolamos a los jobs.

Estas incidencias complejas pueden ocurrir, hay que saber reaccionar, pero lo más importante es que hay que pensar de qué modo evitamos que nos pueda volver a ocurrir.