¿Por qué un banco necesita AIOps y un seguimiento general, o en qué se basan las relaciones con los clientes?

En publicaciones sobre Habré, ya escribí sobre mi experiencia al crear asociaciones con mi equipo (aquí habla sobre cómo redactar un contrato de asociación al iniciar un nuevo negocio para que el negocio no se desmorone). Y ahora me gustaría hablar sobre cómo construir asociaciones con los clientes, ya que sin ellos nada se desmoronará. Espero que este artículo sea de utilidad para las startups que están empezando a vender su producto a grandes empresas.

Actualmente dirijo una startup llamada MONQ Digital lab, donde mi equipo y yo estamos desarrollando un producto para automatizar los procesos de soporte y operación de TI corporativa. Entrar en el mercado no es una tarea fácil y empezamos con un poco de tarea, consultamos a expertos del mercado, a nuestros socios y llevamos a cabo la segmentación del mercado. La pregunta principal era comprender "¿qué dolores podemos curar mejor?"

Los bancos entraron en el TOP 3 de segmentos. Y, por supuesto, los primeros en la lista fueron Tinkoff y Sberbank. Cuando visitamos a los expertos del mercado bancario, nos dijeron: introduzca su producto allí y se abrirá el camino hacia el mercado bancario. Intentamos ingresar tanto allí como allí, pero en Sberbank nos esperaba el fracaso, y los muchachos de Tinkoff resultaron estar mucho más abiertos a una comunicación productiva con las startups rusas (tal vez debido al hecho de que Sber en ese momento compró casi mil millones de nuestros competidores occidentales). Al cabo de un mes comenzamos un proyecto piloto. Cómo sucedió, sigue leyendo.

Llevamos muchos años lidiando con temas de operación y monitoreo, ahora estamos implementando nuestro producto en el sector público, en seguros, en bancos, en empresas de telecomunicaciones, una implementación fue con una aerolínea (antes del proyecto, ni siquiera Creo que la aviación era una industria tan dependiente de las TI, y ahora realmente esperamos, a pesar de COVID, que la empresa surja y despegue).

El producto que fabricamos pertenece al software empresarial, el segmento AIOps (Inteligencia artificial para operaciones de TI o ITOps). Los principales objetivos de la implementación de este tipo de sistemas a medida que aumenta el nivel de madurez de los procesos en la empresa:

1. Apagar incendios: identificar fallas, limpiar de escombros el flujo de alertas, asignar tareas e incidentes a los responsables;
2. Incrementar la eficiencia del servicio de TI: reducir el tiempo para resolver incidentes, indicar las causas de las fallas, aumentar la transparencia del estado de TI;
3. Aumente la eficiencia empresarial: reduzca la cantidad de mano de obra, reduzca los riesgos, aumente la fidelidad de los clientes.

Según nuestra experiencia, los bancos tienen los siguientes “problemas” con el monitoreo en común con todas las grandes infraestructuras de TI:

• “quién sabe qué”: hay muchos departamentos técnicos, casi todos tienen al menos un sistema de seguimiento y la mayoría tiene más de uno;
• “Enjambre de mosquitos” de alertas: cada sistema genera cientos y bombardea con ellas a todos los responsables (a veces también entre departamentos). Es difícil mantener constantemente el foco de control sobre cada notificación, su urgencia e importancia se nivela debido al gran número;
• Los grandes bancos (los líderes del sector quieren no solo monitorear continuamente sus sistemas, saber dónde hay fallas, sino también la verdadera magia de la IA): hacer que los sistemas se automonitoreen, se autopredigan y se autocorrijan.

Cuando asistimos a la primera reunión en Tinkoff, inmediatamente nos dijeron que no tenían problemas con el seguimiento y que nada les perjudicaba, y la pregunta principal fue: "¿Qué podemos ofrecer a aquellos a los que ya les va bien?"

La conversación fue larga, discutimos cómo se construyen sus microservicios, cómo funcionan los departamentos, qué problemas de infraestructura son más sensibles, cuáles son menos sensibles para los usuarios, dónde están los "puntos ciegos" y cuáles son sus objetivos y SLA.

Por cierto, los SLA del banco son realmente impresionantes. Por ejemplo, un incidente de disponibilidad de red de prioridad XNUMX puede tardar solo unos minutos en resolverse. El coste del error y el tiempo de inactividad aquí, por supuesto, es impresionante.

Como resultado, identificamos varias áreas de cooperación:

1. La primera etapa es el monitoreo general para aumentar la velocidad de resolución de incidentes.
2. la segunda etapa es la automatización de procesos para reducir riesgos y reducir costos de escalamiento del departamento de TI.

Varios “puntos blancos” podían pintarse con los colores brillantes de las alertas sólo procesando información de varios sistemas de monitoreo, ya que era imposible tomar métricas directamente; también era necesario centralizar los datos de diferentes sistemas de monitoreo en “una sola pantalla” para para comprender el panorama general de lo que estaba sucediendo. Los “paraguas” son adecuados para esta tarea y entonces cumplimos con estos requisitos.

Algo muy importante, en nuestra opinión, en las relaciones con los clientes es la honestidad. Después de la primera conversación y el cálculo del costo de la licencia, se dijo que dado que el costo es tan bajo, podría valer la pena comprar una licencia de inmediato (en comparación con Dynatrace Klyuch-Astrom del artículo anterior sobre el banco verde, nuestro la licencia no cuesta un tercio de mil millones, sino 12 mil rublos por mes por 1 gigabyte, para Sber costaría varias veces más barato). Pero inmediatamente les dijimos lo que tenemos y lo que no. Quizás un representante de ventas de un gran integrador podría decir “sí, podemos hacer de todo, por supuesto comprar nuestra licencia”, pero decidimos poner todas nuestras cartas sobre la mesa. En el momento del lanzamiento, nuestra caja no tenía integración con Prometheus y estaba a punto de lanzarse una nueva versión con un subsistema de automatización, pero aún no la hemos enviado a los clientes.

Se inició el proyecto piloto, se determinaron sus límites y nos dieron 2 meses. Las principales tareas fueron:

• preparar una nueva versión de la plataforma e implementarla en la infraestructura del banco
• conectar 2 sistemas de monitoreo (Zabbix y Prometheus);
• enviar notificaciones a los responsables en Slack y vía SMS;
• ejecutar scripts de reparación automática.

El primer mes del proyecto piloto se dedicó a preparar una nueva versión de la plataforma en modo súper rápido para las necesidades del proyecto piloto. La nueva versión incluye inmediatamente integración con Prometheus y recuperación automática. Gracias a nuestro equipo de desarrollo, no durmieron durante varias noches, pero cumplieron lo prometido sin incumplir los plazos de otros compromisos asumidos previamente.

Mientras estábamos montando el piloto, nos encontramos con un nuevo problema que podía cerrar el proyecto antes de lo previsto: para enviar alertas a mensajería instantánea y vía SMS, necesitábamos conexiones entrantes y salientes a servidores de Microsoft Azure (en aquel momento usábamos esta plataforma para enviar alertas a Slack) y un servicio de envío de SMS externo. Pero en este proyecto, la seguridad fue un enfoque particular. De acuerdo con la política del banco, tales "agujeros" no podían abrirse bajo ninguna circunstancia. Todo tenía que funcionar en un circuito cerrado. Nos ofrecieron utilizar la API de nuestros propios servicios internos que envían alertas a Slack y por SMS, pero no tuvimos la oportunidad de conectar dichos servicios de inmediato.

Una velada de debate con el equipo de desarrollo concluyó con una búsqueda exitosa de una solución. Después de revisar el trabajo pendiente, encontramos una tarea para la que nunca tuvimos suficiente tiempo y prioridad: crear un sistema de complementos para que los equipos de implementación o el cliente pudieran escribir complementos ellos mismos, ampliando las capacidades de la plataforma.

Pero nos quedaba exactamente un mes, durante el cual tuvimos que instalar todo, configurar e implementar la automatización.

Según Sergei, nuestro arquitecto jefe, se necesita al menos un mes para implementar el sistema enchufable.

No tuvimos tiempo...

Solo había una solución: acudir al cliente y contarle todo tal como está. Discutan juntos el cambio de fecha límite. Y funcionó. Nos dieron 2 semanas más. También tenían sus propios plazos y obligaciones internas para mostrar resultados, pero tenían 2 semanas de reserva. Al final, lo arriesgamos todo. Era imposible equivocarse. La honestidad y el enfoque colaborativo nuevamente dieron sus frutos.

Como resultado del piloto se obtuvieron varios resultados y conclusiones técnicas importantes:

Probamos la nueva funcionalidad para procesar alertas

El sistema desplegado comenzó a recibir correctamente las alertas de Prometheus y a agruparlas. Las alertas sobre el problema del cliente Prometheus aparecían cada 30 segundos (la agrupación por tiempo no está habilitada) y nos preguntábamos si sería posible agruparlas en el propio "paraguas". Resultó que es posible: configurar el procesamiento de alertas en la plataforma se implementa mediante un script. Esto hace posible implementar casi cualquier lógica para procesarlos. Ya hemos implementado la lógica estándar en la plataforma en forma de plantillas; si no desea crear algo propio, puede utilizar uno ya preparado.

Interfaz de “disparador sintético”. Configuración del procesamiento de alertas de los sistemas de monitoreo conectados

Construyó el estado de “salud” del sistema.

A partir de las alertas, se crearon eventos de monitoreo que afectaron el estado de las unidades de configuración (CU). Estamos implementando un modelo de servicio de recursos (RSM), que puede usar una CMDB interna o conectar una externa; durante el proyecto piloto, el cliente no conectó su propia CMDB.

Interfaz para trabajar con el modelo recurso-servicio. Piloto RSM.

Bueno, de hecho, el cliente finalmente tiene una única pantalla de monitoreo, donde son visibles los eventos de diferentes sistemas. Actualmente, dos sistemas están conectados al "paraguas": Zabbix y Prometheus, y un sistema de monitoreo interno de la propia plataforma.

Interfaz de análisis. Pantalla única de seguimiento.

Automatización de procesos lanzada

El monitoreo de eventos desencadenó el lanzamiento de acciones preconfiguradas (enviar alertas, ejecutar scripts, registrar/enriquecer incidentes); esto último no se intentó con este cliente en particular, porque en el proyecto piloto no hubo integración con el service desk.

Interfaz de configuración de acciones. Envía alertas a Slack y reinicia el servidor.

Funcionalidad ampliada del producto

Al hablar de scripts de automatización, el cliente solicitó compatibilidad con bash y una interfaz en la que estos scripts pudieran configurarse cómodamente. La nueva versión hizo un poco más (la capacidad de escribir construcciones lógicas completas en Lua con soporte para cURL, SSH y SNMP) e implementó una funcionalidad que le permite administrar el ciclo de vida de un script (crear, editar, control de versiones). , eliminar y archivar).

Interfaz para trabajar con scripts de reparación automática. Script de reinicio del servidor a través de SSH.

Resultados clave

Durante el piloto también se crearon historias de usuario que mejoran la funcionalidad actual y aumentan el valor para el cliente, estas son algunas de ellas:

• implementar la capacidad de reenviar variables directamente desde la alerta al script de reparación automática;
• agregar autorización a la plataforma a través de Active Directory.

Y recibimos desafíos más globales: "desarrollar" el producto con otras capacidades:

• construcción automática de un modelo de recursos-servicio basado en ML, en lugar de reglas y agentes (probablemente el principal desafío ahora);
• soporte para lenguajes lógicos y de secuencias de comandos adicionales (y este será JavaScript).

En mi opinión, lo mas importanteLo que este piloto muestra son dos cosas:

1. Las asociaciones con el cliente son la clave de la eficacia, cuando la comunicación eficaz se construye sobre la base de la honestidad y la apertura, y el cliente pasa a formar parte de un equipo que logra resultados significativos en poco tiempo.
2. Bajo ninguna circunstancia es necesario "personalizar" y construir "muletas", solo soluciones de sistema. Es mejor dedicar un poco más de tiempo, pero crear una solución de sistema que será utilizada por otros clientes. Por cierto, esto es lo que sucedió, el sistema de complementos y la eliminación de la dependencia de Azure proporcionaron valor adicional a otros clientes (hola, Ley Federal 152).

Fuente: habr.com