Pourquoi une banque a-t-elle besoin de l’AIOps et d’une surveillance globale, ou sur quoi reposent les relations clients ?

Dans des publications sur Habré, j'ai déjà écrit sur mon expérience de création de partenariats avec mon équipe (ici explique comment rédiger un accord de partenariat lors du démarrage d'une nouvelle entreprise afin que l'entreprise ne s'effondre pas). Et maintenant, je voudrais parler de la façon de nouer des partenariats avec les clients, car sans eux, rien ne s'effondrera. J'espère que cet article sera utile aux startups qui commencent à vendre leur produit aux grandes entreprises.

Je dirige actuellement une startup appelée MONQ Digital lab, où mon équipe et moi développons un produit pour automatiser les processus de support et d'exploitation de l'informatique d'entreprise. Entrer sur le marché n'est pas une tâche facile et nous avons commencé par faire quelques devoirs, nous sommes passés par des experts du marché, nos partenaires et avons procédé à une segmentation du marché. La question principale était de comprendre « quelles douleurs pouvons-nous le mieux guérir ? »

Les banques sont entrées dans le TOP 3 des segments. Et bien sûr, les premiers sur la liste étaient Tinkoff et Sberbank. Lorsque nous avons rendu visite à des experts du marché bancaire, ils nous ont dit : introduisez votre produit là-bas et la voie vers le marché bancaire sera ouverte. Nous avons essayé d'entrer là et là, mais l'échec nous attendait à la Sberbank, et les gars de Tinkoff se sont révélés beaucoup plus ouverts à une communication productive avec les startups russes (peut-être en raison du fait que Sber à cette époque acheté près d'un milliard de nos concurrents occidentaux). En un mois, nous avons lancé un projet pilote. Comment c'est arrivé, lisez la suite.

Nous traitons des problèmes d'exploitation et de surveillance depuis de nombreuses années, maintenant nous implémentons notre produit dans le secteur public, dans les assurances, dans les banques, dans les entreprises de télécommunications, une implémentation a été avec une compagnie aérienne (avant le projet, nous n'avions même pas je pense que l’aviation était une industrie tellement dépendante de l’informatique, et maintenant nous espérons vraiment, malgré le COVID, que l’entreprise émergera et décollera).

Le produit que nous fabriquons appartient au segment des logiciels d'entreprise, le segment AIOps (Artificial Intelligence for IT Operations, ou ITOps). Les principaux objectifs de la mise en œuvre de systèmes tels que l'augmentation du niveau de maturité des processus dans l'entreprise :

1. Éteignez les incendies : identifiez les pannes, éliminez le flux d'alertes des débris, attribuez les tâches et les incidents aux responsables ;
2. Augmenter l'efficacité du service informatique : réduire le temps de résolution des incidents, indiquer les causes des pannes, augmenter la transparence de l'état informatique ;
3. Augmentez l'efficacité de l'entreprise : réduisez la quantité de travail manuel, réduisez les risques, augmentez la fidélité des clients.

D’après notre expérience, les banques ont les « problèmes » suivants en matière de surveillance, communs à toutes les grandes infrastructures informatiques :

• « qui sait quoi » : il existe de nombreux services techniques, presque tout le monde dispose d'au moins un système de surveillance, et la plupart en ont plusieurs ;
• « essaim de moustiques » d'alertes : chaque système en génère des centaines et en bombarde tous les responsables (parfois aussi entre services). Il est difficile de maintenir constamment le contrôle sur chaque notification ; leur urgence et leur importance sont nivelées en raison de leur grand nombre ;
• les grandes banques - les leaders du secteur veulent non seulement surveiller en permanence leurs systèmes, savoir où se trouvent les pannes, mais aussi découvrir la véritable magie de l'IA - faire en sorte que les systèmes s'auto-surveillent, s'auto-prédisent et s'auto-corrigent.

Lorsque nous sommes arrivés à la première réunion à Tinkoff, on nous a immédiatement dit qu'ils n'avaient aucun problème de surveillance et que rien ne leur faisait de mal, et la question principale était : « Que pouvons-nous offrir à ceux qui vont déjà bien ?

La conversation a été longue, nous avons discuté de la façon dont leurs microservices sont construits, du fonctionnement des départements, des problèmes d'infrastructure les plus sensibles, de ceux qui le sont moins pour les utilisateurs, où sont les « angles morts » et quels sont leurs objectifs et leurs SLA.

D’ailleurs, les SLA de la banque sont vraiment impressionnants. Par exemple, la résolution d’un incident de disponibilité du réseau de priorité XNUMX peut prendre seulement quelques minutes. Bien entendu, le coût des erreurs et des temps d’arrêt est impressionnant.

En conséquence, nous avons identifié plusieurs domaines de coopération :

1. la première étape est une surveillance globale pour augmenter la vitesse de résolution des incidents
2. la deuxième étape est l'automatisation des processus pour réduire les risques et les coûts de mise à l'échelle du service informatique.

Plusieurs « points blancs » pourraient être peints dans les couleurs vives des alertes uniquement en traitant les informations provenant de plusieurs systèmes de surveillance, car il était impossible de prendre directement des mesures ; il était également nécessaire de centraliser les données des différents systèmes de surveillance sur « un seul écran » afin de pour comprendre l'image globale de ce qui se passait. Les « parapluies » conviennent à cette tâche et nous avons alors répondu à ces exigences.

Une chose très importante, à notre avis, dans les relations avec les clients est l’honnêteté. Après la première conversation et le calcul du coût de la licence, il a été dit que puisque le coût est si bas, cela vaut peut-être la peine d'acheter une licence tout de suite (par rapport à Dynatrace Klyuch-Astrom de l'article ci-dessus sur la banque verte, notre la licence ne coûte pas un tiers de milliard, mais 12 1 roubles par mois pour XNUMX gigaoctet, pour Sber, cela coûterait plusieurs fois moins cher). Mais nous leur avons immédiatement dit ce que nous avions et ce que nous n’avions pas. Peut-être qu’un représentant commercial d’un grand intégrateur pourrait dire « oui, nous pouvons tout faire, bien sûr acheter notre licence », mais nous avons décidé de jouer cartes sur table. Au moment du lancement, notre box n'avait pas d'intégration avec Prometheus et une nouvelle version avec un sous-système d'automatisation était sur le point d'être publiée, mais nous ne l'avons pas encore livrée aux clients.

Le projet pilote a commencé, ses limites ont été déterminées et on nous a donné 2 mois. Les tâches principales étaient :

• préparer une nouvelle version de la plateforme et la déployer dans l’infrastructure de la banque
• connectez 2 systèmes de surveillance (Zabbix et Prometheus) ;
• envoyer des notifications aux responsables dans Slack et par SMS ;
• exécuter des scripts d'autoréparation.

Le premier mois du projet pilote a été consacré à la préparation d'une nouvelle version de la plateforme en mode ultra-rapide pour les besoins du projet pilote. La nouvelle version inclut immédiatement l'intégration avec Prometheus et la guérison automatique. Grâce à notre équipe de développement, ils n’ont pas dormi pendant plusieurs nuits, mais ont publié ce qu’ils avaient promis sans manquer les délais pour d’autres engagements précédemment pris.

Lors de la mise en place du pilote, nous avons rencontré un nouveau problème qui pourrait clôturer le projet plus tôt que prévu : pour envoyer des alertes par messagerie instantanée et par SMS, nous avions besoin de connexions entrantes et sortantes aux serveurs Microsoft Azure (à l'époque nous utilisions cette plateforme pour envoyer des alertes à Slack) et un service d'envoi externe de SMS. Mais dans ce projet, la sécurité était une priorité particulière. Conformément à la politique de la banque, de tels « trous » ne pouvaient en aucun cas être ouverts. Tout devait fonctionner en boucle fermée. On nous a proposé d'utiliser l'API de nos propres services internes qui envoient des alertes à Slack et via SMS, mais nous n'avons pas eu la possibilité de connecter de tels services directement.

Une soirée de débat avec l'équipe de développement s'est terminée par une recherche réussie d'une solution. Après avoir fouillé le retard, nous avons trouvé une tâche pour laquelle nous n'avions jamais assez de temps et de priorité : créer un système de plug-ins afin que les équipes de mise en œuvre ou le client puissent écrire eux-mêmes des modules complémentaires, élargissant ainsi les capacités de la plate-forme.

Mais il nous restait exactement un mois, pendant lequel nous devions tout installer, configurer et déployer l'automatisation.

Selon Sergei, notre architecte en chef, la mise en œuvre du système de plug-ins prend au moins un mois.

Nous n'avons pas eu le temps...

Il n'y avait qu'une seule solution : aller voir le client et lui dire tout tel quel. Discutez ensemble du décalage des délais. Et ça a marché. On nous a donné 2 semaines supplémentaires. Ils avaient également leurs propres délais et obligations internes pour montrer les résultats, mais ils disposaient de 2 semaines de réserve. En fin de compte, nous avons tout mis en jeu. Il était impossible de se tromper. L’honnêteté et l’approche partenariale ont encore une fois porté leurs fruits.

À la suite du projet pilote, plusieurs résultats et conclusions techniques importants ont été obtenus :

Nous avons testé la nouvelle fonctionnalité de traitement des alertes

Le système déployé a commencé à recevoir correctement les alertes de Prometheus et à les regrouper. Les alertes sur le problème du client Prometheus volaient toutes les 30 secondes (le regroupement par temps n'est pas activé), et nous nous demandions s'il serait possible de les regrouper dans le « parapluie » lui-même. Il s'est avéré que c'est possible : la configuration du traitement des alertes dans la plateforme est implémentée par un script. Cela permet de mettre en œuvre presque n'importe quelle logique pour les traiter. Nous avons déjà implémenté une logique standard dans la plate-forme sous forme de modèles - si vous ne souhaitez pas créer votre propre modèle, vous pouvez en utiliser un tout fait.

Interface « Gâchette synthétique ». Mise en place du traitement des alertes des systèmes de surveillance connectés

Construit l’état de « santé » du système

Sur la base des alertes, des événements de surveillance ont été créés et ont affecté l'état des unités de configuration (CU). Nous implémentons un modèle de service de ressources (RSM), qui peut utiliser soit une CMDB interne, soit en connecter une externe. Lors du projet pilote, le client n'a pas connecté sa propre CMDB.

Interface pour travailler avec le modèle ressource-service. Pilote RSM.

Eh bien, en fait, le client dispose enfin d'un seul écran de surveillance, où les événements de différents systèmes sont visibles. Actuellement, deux systèmes sont connectés au « parapluie » : Zabbix et Prometheus, ainsi qu'un système de surveillance interne de la plateforme elle-même.

Interface d'analyse. Écran de surveillance unique.

Automatisation des processus lancée

Les événements de surveillance ont déclenché le lancement d'actions préconfigurées - envoi d'alertes, exécution de scripts, enregistrement/enrichissement des incidents - cette dernière n'a pas été tentée avec ce client particulier, car dans le projet pilote, il n’y avait pas d’intégration avec le service desk.

Interface des paramètres d'action. Envoyez des alertes à Slack et redémarrez le serveur.

Fonctionnalité du produit étendue

Lors de la discussion sur les scripts d'automatisation, le client a demandé la prise en charge de bash et une interface dans laquelle ces scripts pourraient être facilement configurés. La nouvelle version a fait un peu plus (la possibilité d'écrire des constructions logiques à part entière dans Lua avec prise en charge de cURL, SSH et SNMP) et implémenté des fonctionnalités qui vous permettent de gérer le cycle de vie d'un script (créer, modifier, contrôler la version , supprimer et archiver).

Interface pour travailler avec des scripts d'autoréparation. Script de redémarrage du serveur via SSH.

principaux résultats

Au cours du pilote, des user stories ont également été créées pour améliorer les fonctionnalités actuelles et augmenter la valeur pour le client. En voici quelques-unes :

• implémentez la possibilité de transférer des variables directement de l'alerte vers le script d'autoréparation ;
• ajouter une autorisation à la plateforme via Active Directory.

Et nous avons reçu des défis plus globaux - pour « construire » le produit avec d'autres capacités :

• construction automatique d'un modèle de ressources-services basé sur le ML, plutôt que sur des règles et des agents (probablement le principal défi actuellement) ;
• prise en charge de langages de script et de logique supplémentaires (et ce sera JavaScript).

À mon avis, la chose la plus importanteCe pilote montre deux choses :

1. Les partenariats avec le client sont la clé de l'efficacité, lorsqu'une communication efficace est construite sur la base de l'honnêteté et de l'ouverture, et que le client fait partie d'une équipe qui obtient des résultats significatifs en peu de temps.
2. En aucun cas, il n'est nécessaire de « personnaliser » et de construire des « béquilles » - uniquement des solutions système. Il vaut mieux y consacrer un peu plus de temps, mais créer une solution système qui sera utilisée par d'autres clients. D'ailleurs, c'est ce qui s'est passé, le système de plugins et l'élimination de la dépendance à Azure ont apporté une valeur supplémentaire aux autres clients (bonjour, loi fédérale 152).

Source: habr.com