Por que um banco precisa de AIOps e monitoramento abrangente, ou em que se baseia o relacionamento com o cliente?

Nas publicações do Habré, já escrevi sobre minha experiência de construção de parcerias com minha equipe (aqui fala sobre como fazer um acordo de parceria na hora de iniciar um novo negócio para que o negócio não desmorone). E agora gostaria de falar sobre como construir parcerias com os clientes, pois sem eles não haverá nada para desmoronar. Espero que este artigo seja útil para startups que estão começando a vender seus produtos para grandes empresas.

Atualmente estou liderando uma startup chamada MONQ Digital lab, onde eu e minha equipe estamos desenvolvendo um produto para automatizar os processos de suporte e operação de TI corporativa. Entrar no mercado não é uma tarefa fácil e começamos com um pequeno trabalho de casa, passamos por especialistas de mercado, nossos parceiros e realizamos a segmentação de mercado. A questão principal era entender “cujas dores podemos curar melhor?”

Os bancos chegaram aos 3 principais segmentos. E, claro, os primeiros da lista foram Tinkoff e Sberbank. Quando visitamos especialistas do mercado bancário, eles disseram: apresente aí o seu produto e o caminho para o mercado bancário estará aberto. Tentamos entrar ali e ali, mas o fracasso nos esperava no Sberbank, e o pessoal da Tinkoff acabou se mostrando muito mais aberto à comunicação produtiva com startups russas (talvez pelo fato de o Sber naquela época comprou quase um bilhão de nossos concorrentes ocidentais). Em um mês, iniciamos um projeto piloto. Como isso aconteceu, continue lendo.

Há muitos anos que lidamos com questões de operação e monitoramento, agora estamos implementando nosso produto no setor público, em seguros, em bancos, em empresas de telecomunicações, uma implementação foi com uma companhia aérea (antes do projeto, nem sequer Acho que a aviação era uma indústria tão dependente da TI e agora realmente esperamos, apesar da COVID, que a empresa surja e decole).

O produto que fabricamos pertence ao segmento de software empresarial, AIOps (Inteligência Artificial para Operações de TI, ou ITOps). Os principais objetivos da implementação de tais sistemas à medida que aumenta o nível de maturidade dos processos na empresa:

1. Apagar incêndios: identificar falhas, limpar o fluxo de alertas de detritos, atribuir tarefas e incidentes aos responsáveis;
2. Aumentar a eficiência do serviço de TI: reduzir o tempo de resolução de incidentes, indicar as causas das falhas, aumentar a transparência do estado de TI;
3. Aumente a eficiência dos negócios: reduza a quantidade de trabalho manual, reduza os riscos, aumente a fidelização dos clientes.

Na nossa experiência, os bancos têm as seguintes “dores” de monitorização em comum com todas as grandes infraestruturas de TI:

• “sabe-se lá o quê”: existem muitos departamentos técnicos, quase todos possuem pelo menos um sistema de monitoramento e a maioria possui mais de um;
• “enxame de mosquitos” de alertas: cada sistema gera centenas e bombardeia com eles todos os responsáveis ​​(às vezes também entre departamentos). É difícil manter constantemente o foco do controle sobre cada notificação, sua urgência e importância são niveladas devido ao grande número;
• grandes bancos - os líderes do sector querem não só monitorizar continuamente os seus sistemas, saber onde há falhas, mas também a verdadeira magia da IA ​​- fazer com que os sistemas se automonitorizem, autoprevejam e autocorrijam.

Quando chegamos à primeira reunião na Tinkoff, fomos imediatamente informados de que eles não tinham problemas com o monitoramento e nada os prejudicava, e a pergunta principal era: “O que podemos oferecer para quem já está bem?”

A conversa foi longa, discutimos como são construídos seus microsserviços, como funcionam os departamentos, quais problemas de infraestrutura são mais sensíveis, quais são menos sensíveis para os usuários, onde estão os “pontos cegos”, e quais são seus objetivos e SLAs.

Aliás, os SLAs do banco são realmente impressionantes. Por exemplo, um incidente de disponibilidade de rede de prioridade XNUMX pode levar apenas alguns minutos para ser resolvido. O custo do erro e do tempo de inatividade aqui, é claro, é impressionante.

Como resultado, identificamos várias áreas de cooperação:

1. a primeira etapa é o monitoramento abrangente para aumentar a velocidade da resolução de incidentes
2. a segunda etapa é a automação de processos para reduzir riscos e reduzir custos de dimensionamento do departamento de TI.

Vários “pontos brancos” poderiam ser pintados com as cores brilhantes dos alertas apenas através do processamento de informações de vários sistemas de monitoramento, uma vez que era impossível obter métricas diretamente; também era necessário centralizar os dados de diferentes sistemas de monitoramento em “uma tela” para para entender o quadro geral do que estava acontecendo. Os “guarda-chuvas” são adequados para esta tarefa e então cumprimos esses requisitos.

Uma coisa muito importante, em nossa opinião, no relacionamento com os clientes é a honestidade. Após a primeira conversa e cálculo do custo da licença, foi dito que como o custo é tão baixo, talvez valesse a pena comprar uma licença imediatamente (em comparação com Dynatrace Klyuch-Astrom do artigo acima sobre o banco verde, nosso a licença não custa um terço de bilhão, mas 12 mil rublos por mês por 1 gigabyte; para Sber custaria várias vezes mais barato). Mas imediatamente dissemos a eles o que temos e o que não temos. Talvez um representante de vendas de um grande integrador pudesse dizer “sim, podemos fazer tudo, claro, comprar nossa licença”, mas decidimos colocar todas as cartas na mesa. Na época do lançamento, nosso box não tinha integração com Prometheus, e uma nova versão com subsistema de automação estava para ser lançada, mas ainda não enviamos aos clientes.

O projeto piloto começou, seus limites foram determinados e nos deram 2 meses. As principais tarefas foram:

• preparar uma nova versão da plataforma e implantá-la na infraestrutura do banco
• conectar 2 sistemas de monitoramento (Zabbix e Prometheus);
• enviar notificações aos responsáveis ​​no Slack e via SMS;
• execute scripts de recuperação automática.

O primeiro mês do projeto piloto foi gasto na preparação de uma nova versão da plataforma em modo super-rápido para as necessidades do projeto piloto. A nova versão inclui imediatamente integração com Prometheus e recuperação automática. Graças à nossa equipe de desenvolvimento, eles ficaram várias noites sem dormir, mas liberaram o que prometeram sem perder os prazos de outros compromissos previamente assumidos.

Durante a montagem do piloto, encontramos um novo problema que poderia encerrar o projeto antes do previsto: para enviar alertas para mensageiros instantâneos e via SMS, precisávamos de conexões de entrada e saída com servidores Microsoft Azure (naquela época usávamos esta plataforma para enviar alertas para o Slack) e um serviço de envio externo de SMS. Mas neste projeto, a segurança foi um foco particular. De acordo com a política do banco, tais “buracos” não poderiam ser abertos em hipótese alguma. Tudo tinha que funcionar em circuito fechado. Foi-nos oferecido o uso da API de nossos próprios serviços internos que enviam alertas para o Slack e via SMS, mas não tivemos a oportunidade de conectar esses serviços imediatamente.

Uma noite de debate com a equipe de desenvolvimento terminou com uma busca bem-sucedida por uma solução. Depois de vasculhar o backlog, encontramos uma tarefa para a qual nunca tivemos tempo e prioridade suficientes - criar um sistema de plug-ins para que as próprias equipes de implementação ou o cliente pudessem escrever add-ons, ampliando as capacidades da plataforma.

Mas faltava exatamente um mês para instalar tudo, configurar e implantar a automação.

Segundo Sergei, nosso arquiteto-chefe, leva pelo menos um mês para implementar o sistema plug-in.

Não tivemos tempo...

Só havia uma solução: ir até o cliente e contar tudo como está. Discuta a mudança de prazo juntos. E funcionou. Recebemos mais 2 semanas. Eles também tinham prazos e obrigações internas próprias para apresentar resultados, mas tinham 2 semanas de reserva. No final, colocamos tudo em risco. Era impossível bagunçar. A honestidade e uma abordagem de parceria novamente valeram a pena.

Como resultado do piloto, foram obtidos vários resultados e conclusões técnicas importantes:

Testamos a nova funcionalidade para processamento de alertas

O sistema implantado passou a receber corretamente alertas do Prometheus e agrupá-los. Alertas sobre o problema do cliente Prometheus voavam a cada 30 segundos (o agrupamento por tempo não está habilitado), e estávamos nos perguntando se seria possível agrupá-los no próprio “guarda-chuva”. Descobriu-se que é possível - a configuração do processamento de alertas na plataforma é implementada por meio de um script. Isso torna possível implementar quase qualquer lógica para processá-los. Já implementamos a lógica padrão na plataforma na forma de modelos - se você não quiser criar algo próprio, pode usar um já pronto.

Interface “gatilho sintético”. Configurando o processamento de alertas de sistemas de monitoramento conectados

Construiu o estado de “saúde” do sistema

Com base nos alertas, foram criados eventos de monitoramento que afetaram o funcionamento das unidades de configuração (CUs). Estamos implementando um modelo de serviço de recursos (RSM), que pode usar um CMDB interno ou conectar um externo - durante o projeto piloto o cliente não conectou seu próprio CMDB.

Interface para trabalhar com o modelo de serviço de recursos. Piloto RSM.

Pois bem, na verdade o cliente finalmente conta com uma única tela de monitoramento, onde ficam visíveis eventos de diferentes sistemas. Atualmente, dois sistemas estão conectados ao “guarda-chuva” – Zabbix e Prometheus, e um sistema de monitoramento interno da própria plataforma.

Interface analítica. Tela única de monitoramento.

Lançada automação de processos

Os eventos de monitorização desencadearam o lançamento de ações pré-configuradas - envio de alertas, execução de scripts, registo/enriquecimento de incidentes - esta última não foi tentada com este cliente em particular, porque no projeto piloto não houve integração com o service desk.

Interface de configurações de ação. Envie alertas para o Slack e reinicie o servidor.

Funcionalidade expandida do produto

Ao discutir scripts de automação, o cliente solicitou suporte bash e uma interface na qual esses scripts pudessem ser configurados de maneira conveniente. A nova versão fez um pouco mais (a capacidade de escrever construções lógicas completas em Lua com suporte para cURL, SSH e SNMP) e implementou funcionalidades que permitem gerenciar o ciclo de vida de um script (criar, editar, controle de versão , excluir e arquivar).

Interface para trabalhar com scripts de recuperação automática. Script de reinicialização do servidor via SSH.

Principais conclusões

Durante o piloto também foram criadas histórias de usuários que melhoram a funcionalidade atual e aumentam o valor para o cliente, aqui estão algumas delas:

• implementar a capacidade de encaminhar variáveis ​​diretamente do alerta para o script de recuperação automática;
• adicione autorização à plataforma via Active Directory.

E recebemos mais desafios globais - para “construir” o produto com outras capacidades:

• construção automática de um modelo de serviços de recursos baseado em ML, em vez de regras e agentes (provavelmente o principal desafio agora);
• suporte para linguagens adicionais de script e lógica (e isso será JavaScript).

Na minha opinião, a coisa mais importanteO que este piloto mostra são duas coisas:

1. As parcerias com o cliente são a chave para a eficácia, quando a comunicação eficaz é construída com base na honestidade e abertura, e o cliente passa a fazer parte de uma equipe que alcança resultados significativos em pouco tempo.
2. Em hipótese alguma é necessário “customizar” e construir “muletas” – apenas soluções sistêmicas. É melhor gastar um pouco mais de tempo, mas faça uma solução de sistema que será utilizada por outros clientes. Aliás, foi o que aconteceu, o sistema de plugins e a eliminação da dependência do Azure agregaram valor a outros clientes (alô, Lei Federal 152).

Fonte: habr.com