Una caída de los servicios de cualquier página web o herramienta digital siempre acarrea problemas para la empresa y sus usuarios. Si esto es así para cualquier compañía, en el caso de entidades críticas como los bancos, las consecuencias pueden ser fatales, con enormes pérdidas económicas debido a lo esencial de sus operaciones y la confianza que deben generar estas instituciones en sus clientes y accionistas. De hecho, según datos del Ponemon Institute, solo una hora de inactividad en sus sistemas puede generar a bancos y entidades bancarias pérdidas de 500 millones de euros.
El sector bancario es dinámico, exigente y está ampliamente marcado por el cumplimiento normativo. En este entorno, la disponibilidad debe ser completa 24 horas siete días a la semana, pues los clientes esperan acceso ininterrumpido a sus cuentas, pagos y servicios. Un fallo en una transferencia, un cajero o la app móvil tiene un impacto inmediato en su confianza.
No obstante, pese a lo esencial de mantener sus sistemas siempre activos, en la actualidad los bancos tienen arquitecturas tremendamente complejas, marcadas por un entorno híbrido en el que los sistemas heredados (legacy) coexisten con microservicios en la nube, APIs y partners externos que tienen como objetivo impulsar la innovación digital. En este entramado, el núcleo legacy es el sistema tradicional que gestiona todas las transacciones históricas de los bancos, es decir, gestión de cuentas corrientes, ahorros, préstamos hipotecarios, información básica de clientes, etc. Este se basa en plataformas mainframe tradicionales, como puede ser IBM zSeries, y pese a ser un sistema que presenta un alto grado de fiabilidad, es difícil de adaptar y actualizar a las cambiantes necesidades de la banca moderna totalmente digital, ya que sus ciclos de desarrollo son complejos y lentos.
La migración completa del servicio tradicional basado en mainframe a estructuras más actuales representa para los bancos un riesgo operativo y financiero extremadamente alto, por lo que la solución para poder prestar todos los servicios demandados en la actualidad sin tener que modificar el núcleo legacy es la integración de los mismos en sus sistemas actuales, lo que ha dado pie a esta arquitectura híbrida. Este sistema ha supuesto ciertas ventajas, como el rápido despliegue de nuevas funcionalidades mediante acoples al mainframe, la escalabilidad selectiva por la cual solo se desarrollan servicios específicos que generan demanda real, o la flexibilidad de no tener que depender de los sistemas tradicionales.
De esta forma, los sistemas bancarios actuales tienen varias capas de operación, comenzando por el núcleo legacy para seguir con la capa de integración y APIs, que es el puente entre el núcleo y las funcionalidades de la banca moderna. Tras estas se encuentra la capa de los microservicios y cloud, pilar base para todas las gestiones y canales digitales (aplicación móvil, banca online): apertura online de cuentas, gestión de inversiones, chatbots de asistencia, procesamiento de pagos (como el Bizum, por ejemplo).
La convivencia de diferentes arquitecturas y sistemas en una industria tan crítica como la bancaria convierte la supervisión del estado óptimo de estas plataformas en algo muy complejo, para lo que la vía tradicional de supervisión de sistemas, la monitorización, se queda corta. Esto se debe a que esta metodología se fundamenta en la identificación de errores conocidos por bloques, pero no puede medir el sistema en su conjunto, ni explica las causas, ni es proactiva identificando un fallo antes de que su impacto sea crítico. Por otro lado, la observabilidad es la herramienta tecnológica clave para el mantenimiento de los sistemas tecnológicos bancarios.
Esta metodología permite comprender internamente el comportamiento de un sistema con los datos que proporcionan sus componentes, pudiendo responder preguntas complejas sobre el funcionamiento del mismo incluso sobre eventos muy específicos. De esta manera, proporciona una visión holística del sistema, incluso con la mezcla entre núcleo tradicional y microservicios modernos.
¿De dónde salen los datos que utiliza esta herramienta para su análisis y posterior control de los sistemas internos? En la observabilidad existen tres métricas claves, cada una de las cuales responde a una pregunta en concreto: ¿cuánto o cuándo? (métricas), ¿dónde? (trazas) y ¿por qué? (logs).
Las Métricas son agregaciones numéricas que cuantifican el comportamiento del sistema (CPU, memoria, latencia, tasa de errores, etc). Su principal función es proporcionar una visión cuantitativa del rendimiento y la salud del sistema. Por otro lado, las Trazas son registros de eventos relacionados con una solicitud específica, que permiten seguir el flujo de la solicitud a través de múltiples componentes del sistema. Por último, los Logs son registros detallados de los eventos discretos generados por aplicaciones, servidores y servicios, con marcas de tiempo y contexto.
Estos completos registros son esenciales en un sistema híbrido en el que los fallos son totalmente impredecibles, pues un problema puede surgir en en una interacción cualquiera entre un microservicio en la nube y una transacción en el mainframe. Además, el impacto de estos fallos, por la propia confección del sistema híbrido, puede ser transversal, con una caída del sistema de evaluación de créditos afectando a la aplicación móvil, el proceso de apertura de cuentas y las decisiones de préstamo en sucursal de forma simultánea.
Por ello es de vital importancia conocer el contexto de cualquiera de estos errores. No sirve de nada que el sistema identifique un fallo genérico, es necesario conocer en qué transacción se produjo, qué servicio, qué API o base de datos y qué usuarios lo están experimentando. Para ello, la observabilidad hace uso conjunto de sus tres pilares de datos principales (métricas, traces y logs) para obtener una base holística de todo el sistema mediante la cual controlar todo el contexto.
De esta manera, gracias a esta metodología, se puede reconstruir el camino completo de cualquier transacción financiera, sin importar cuántos sistemas legacy, microservicios, APIs o nubes atraviese. A su vez, se puede generar una relación causa-efecto que ayude a comprender por qué un problema en un sistema consejero impacta a otros servicios dependientes del mismo, y cómo esto termina por afectar a la experiencia del usuario, ya sea un cliente intentado realizar una transacción o un empleado una operación bancaria. Por otro lado, gracias a la compilación masiva de datos, se pueden “hacer preguntas” al sistema sobre acciones específicas que sean de interés (obtener más información sobre una transacción concreta Y del usuario X a las 00.00). Esto a su vez permite identificar de forma muy precisa el componente o interacción que presenta irregularidades.
Con este conocimiento se pueden detectar anomalías en segundos, como picos de latencia o cuellos de botella antes de que produzcan un fallo y afecten al sistema. Si este error se llegase a producir, se puede diagnosticar la causa con el punto exacto de fallo, lo que proporciona a los equipos IT del banco un contexto completo de la situación para que centren sus esfuerzos únicamente en la solución. Esta resolución de problemas más eficiente minimiza en gran medida el tiempo de recuperación y de inactividad del sistema.
Esto es fundamental, ya que si se produjese un fallo grave de interrupción de servicio, los bancos experimentarían la imposibilidad de realizar sus operaciones transaccionales habituales (pagos, transferencias, compras, concesión de préstamos o gestión de inversiones, por ejemplo) con el consiguiente impacto económico. No obstante, sufrirán pérdidas adicionales asociadas a los gastos de reparación de los sistemas, así como costes legales y posibles compensaciones a clientes por daños y perjuicios al verse estos afectados por el fallo. Adicionalmente, las entidades regulatorias pueden imponer sanciones si se esclarece que ha habido deficiencias en la gestión operacional o tecnológica que ha llevado al fallo e interrupción del servicio.
No obstante, las herramientas de observabilidad no cumplen únicamente el cometido de mantener los sistemas en su rendimiento correcto y anticipar fallos. Las entidades financieras pueden hacer uso de esta tecnología para estar al día con el estricto sistema regulatorio al que están sometidos –GDPR, PSD2 (Payment Services Directive 2), leyes antiblanqueo, entre otros– ya que proporciona la visibilidad y los registros detallados necesarios para demostrar el cumplimiento de estas normativas, investigar incidentes y responder a auditorías. Por otro lado, en cuestión de experiencia del cliente, la observabilidad evita lentitud en los servicios o errores en las transacciones, que son fuente de frustración para los usuarios, pero también puede servir para poner en evidencia la necesidad de implementar nuevas herramientas que completen el servicio y generen valor añadido.
En definitiva, en el complejo sistema bancario actual, con arquitectura híbrida basada en un núcleo clásico y microservicios , la observabilidad aporta visibilidad, comprensión y control del sistema, lo que la convierte en un activo estratégico clave para garantizar la estabilidad operativa, pero también para ofrecer la mejor experiencia digital. En nettaro trabajamos con bancos e instituciones bancarias públicas diseñando en la implementación de esta tecnología diseñando planes específicos para cada entidad y sus necesidades.
