Miért AIOps és ernyőfigyelés egy bank számára, vagy milyen kapcsolatokra épülnek az ügyfelekkel

A Habréval kapcsolatos publikációkban már írtam a csapatommal való partneri kapcsolatok kiépítésének tapasztalatairól (itt beszél arról, hogyan kell új vállalkozás indításakor partnerségi megállapodást kötni, hogy a vállalkozás ne dőljön szét). És most arról szeretnék beszélni, hogyan építsünk partnerséget az ügyfelekkel, hiszen nélkülük nem lesz semmi, ami széteshet. Remélem, hogy ez a cikk hasznos lesz azoknak az induló vállalkozásoknak, akik termékeiket nagyvállalatoknak kezdik eladni.

Jelenleg a MONQ Digital lab nevű startup élén állok, ahol csapatommal a vállalati IT támogatási és működtetési folyamatainak automatizálására fejlesztünk egy terméket. A piacra lépés nem egyszerű feladat, egy kis házi feladattal kezdtük, végigjártuk a piaci szakértőket, partnereinket és elvégeztük a piac szegmentálását. A fő kérdés az volt, hogy megértsük, kinek a fájdalmait tudjuk a legjobban meggyógyítani?

A bankok bejutottak a TOP 3 szegmensbe. És természetesen az első a listán a Tinkoff és a Sberbank volt. Amikor meglátogattuk a bankpiaci szakértőket, azt mondták: mutassa be a termékét ott, és megnyílik az út a bankpiac felé. Megpróbáltunk bejutni oda is, de a Sberbankban kudarc várt ránk, és a Tinkoff srácai sokkal nyitottabbak voltak az orosz startupokkal való produktív kommunikációra (talán annak a ténynek köszönhető, hogy a Sber akkoriban vásárolt közel egymilliárd nyugati versenytársunk). Egy hónapon belül elindítottunk egy kísérleti projektet. Hogyan történt, olvass tovább.

Évek óta foglalkozunk üzemeltetési és monitorozási kérdésekkel, most a közszférában, biztosításban, bankokban, távközlési cégeknél vezetjük be termékünket, egy megvalósítás volt légitársaságnál (a projekt előtt még nem is úgy gondolja, hogy a repülés annyira informatikai függő iparág volt, és most nagyon reméljük, a COVID ellenére, hogy a vállalat felbukkan és felszáll).

Az általunk készített termék a vállalati szoftverek, az AIOps (Artificial Intelligence for IT Operations, vagy ITOps) szegmensbe tartozik. Az ilyen rendszerek bevezetésének fő céljai, mivel a vállalati folyamatok érettsége növekszik:

1. Oltsa el a tüzet: azonosítsa a hibákat, tisztítsa meg a riasztások folyamát a törmeléktől, osszon ki feladatokat és eseményeket a felelősökhöz;
2. Növelje az informatikai szolgáltatás hatékonyságát: csökkentse az incidensek megoldásának idejét, jelezze a meghibásodások okát, növelje az informatikai állapot átláthatóságát;
3. Növelje az üzleti hatékonyságot: csökkentse a fizikai munka mennyiségét, csökkentse a kockázatokat, növelje az ügyfelek lojalitását.

Tapasztalataink szerint a bankoknak az alábbi „fájdalmak” vannak a monitorozással kapcsolatban, minden nagy IT infrastruktúrával közös:

• „ki mit tud”: sok a műszaki osztály, szinte mindenkinek van legalább egy felügyeleti rendszere, és a legtöbbnek több is van;
• „szúnyograj” a riasztások: minden rendszer több százat generál, és ezzel bombázza az összes felelőst (néha osztályok között is). Nehéz folyamatosan fenntartani az egyes bejelentések ellenőrzésének fókuszát, ezek sürgőssége és fontossága a nagy szám miatt kiegyenlítődik;
• a nagy bankok – a szektor vezetői nemcsak folyamatosan figyelni szeretnék rendszereiket, tudni, hol vannak meghibásodások, hanem az AI igazi varázslatát is – önellenőrzővé, önjóslóvá és önkorrekcióssá tenni a rendszereket.

Amikor megérkeztünk az első találkozóra a Tinkoffba, azonnal közölték velünk, hogy nincs gondjuk a monitorozással, és semmi sem bántja őket, és a fő kérdés az volt: „Mit tudunk ajánlani azoknak, akik már jól vannak?”

A beszélgetés hosszú volt, megbeszéltük, hogyan épülnek fel a mikroszolgáltatásaik, hogyan működnek a részlegek, mely infrastrukturális problémák érzékenyebbek, melyek kevésbé érzékenyek a felhasználókra, hol vannak a „vakfoltok”, mik a céljaik, SLA-ik.

Egyébként a bank SLA-i igazán lenyűgözőek. Például egy XNUMX. prioritású hálózati rendelkezésre állási incidens megoldása csak néhány percig tarthat. A hiba és az állásidő költsége itt természetesen lenyűgöző.

Ennek eredményeként több együttműködési területet azonosítottunk:

1. az első szakasz az esernyőfigyelés az incidensfeloldás sebességének növelése érdekében
2. a második szakasz a folyamatok automatizálása a kockázatok és az informatikai részleg bővítésének költségeinek csökkentése érdekében.

Több „fehér folt” csak több felügyeleti rendszer információinak feldolgozásával festhető a riasztások élénk színére, mivel nem lehetett közvetlenül mérőszámot venni, illetve a különböző felügyeleti rendszerek adatait „egy képernyőre” kellett központosítani annak érdekében hogy megértsük a történtek összképét. Az „esernyők” alkalmasak erre a feladatra, és ezeknek a követelményeknek akkor megfeleltünk.

Véleményünk szerint nagyon fontos dolog az ügyfelekkel való kapcsolatokban az őszinteség. Az első beszélgetés és a licenc költségének kiszámítása után elhangzott, hogy mivel ilyen alacsony a költség, érdemes lehet azonnal licencet venni (a zöld bankról szóló fenti cikk Dynatrace Klyuch-Astrom-jával összehasonlítva, a licenc nem harmadmilliárd, hanem havi 12 ezer rubel 1 gigabájtért, a Sber esetében többszöröse olcsóbb lenne). De azonnal elmondtuk nekik, hogy mi van és mi nincs. Talán egy nagy integrátor értékesítési képviselője azt mondhatná, hogy „igen, mindent megtehetünk, természetesen vegyük meg a licencünket”, de úgy döntöttünk, hogy az összes kártyánkat az asztalra tesszük. Az induláskor dobozunk nem volt integrálva a Prometheusszal, és hamarosan megjelent egy új verzió automatizálási alrendszerrel, de még nem szállítottuk ki a vásárlóknak.

Elkezdődött a pilot projekt, meghatározták a határait és 2 hónapot kaptunk. A fő feladatok a következők voltak:

• készítse elő a platform új verzióját, és helyezze üzembe a bank infrastruktúrájában
• 2 felügyeleti rendszer csatlakoztatása (Zabbix és Prometheus);
• értesítést küld a Slack felelőseinek és SMS-ben;
• futtasson autohealing szkripteket.

A kísérleti projekt első hónapja a platform új verziójának szupergyors módban történő elkészítésével telt a pilot projekt igényeinek megfelelően. Az új verzió azonnal tartalmazza a Prometheusszal való integrációt és az automatikus gyógyulást. Fejlesztői csapatunknak köszönhetően több éjszakán át nem aludtak, hanem kiadták, amit ígértek, anélkül, hogy elmulasztották volna a többi korábban vállalt kötelezettséget.

A pilot üzembe helyezése során egy új problémába ütköztünk, amely a projektet a tervezett határidő előtt lezárhatta: az azonnali üzenetküldőknek és SMS-ben történő riasztásokhoz bejövő és kimenő kapcsolatokra volt szükségünk a Microsoft Azure szerverekhez (akkor ezt a platformot használtuk riasztások küldéséhez a Slacknek) és egy külső küldő szolgáltatási SMS-t. De ebben a projektben a biztonság kiemelt figyelmet kapott. A bank politikájának megfelelően ilyen „lyukakat” semmilyen körülmények között nem lehetett nyitni. Mindennek zárt körből kellett működnie. Felajánlották a saját belső szolgáltatásaink API-jának használatát, amelyek riasztást küldenek a Slack-nek és SMS-ben, de nem volt lehetőségünk ilyen szolgáltatások csatlakoztatására.

A fejlesztőcsapattal folytatott vitaest sikeres megoldáskereséssel zárult. A lemaradásban turkálva találtunk egy olyan feladatot, amelyre soha nem volt elég időnk és prioritásunk - egy beépülő rendszer létrehozása, hogy az implementációs csapatok vagy a kliens maguk írhassanak kiegészítőket, bővítve ezzel a platform képességeit.

De pontosan egy hónapunk volt hátra, ezalatt mindent fel kellett szerelni, beállítani és bevezetni az automatizálást.

Szergej, főépítészünk szerint a beépülő rendszer bevezetése legalább egy hónapot vesz igénybe.

Nem volt időnk...

Csak egy megoldás volt: menj el az ügyfélhez, és mondj el mindent úgy, ahogy van. Beszéljétek meg együtt a határidő eltolódását. És működött. Kaptunk plusz 2 hetet. Nekik is megvoltak a saját határidőik és belső kötelezettségeik az eredmény felmutatására, de volt 2 tartalék hét. A végén mindent feltettünk a sorba. Lehetetlen volt elrontani. Az őszinteség és a partneri megközelítés ismét kifizetődött.

A pilot eredményeként számos fontos technikai eredmény és következtetés született:

Teszteltük az új funkciót a riasztások feldolgozásához

A telepített rendszer elkezdte megfelelően fogadni a Prometheus riasztásait és csoportosítani azokat. A Prometheus klienstől 30 másodpercenként érkeztek riasztások a problémáról (az idő szerinti csoportosítás nincs engedélyezve), és arra voltunk kíváncsiak, hogy lehet-e csoportosítani őket magában az „esernyőben”. Kiderült, hogy lehetséges - a riasztások feldolgozásának beállítása a platformon egy szkript segítségével történik. Ez lehetővé teszi szinte bármilyen logika megvalósítását a feldolgozásukhoz. A szabványos logikát már sablonok formájában implementáltuk a platformon - ha nem szeretne saját ötletekkel előállni, használhat egy készet is.

„Szintetikus trigger” interfész. A csatlakoztatott megfigyelőrendszerekből származó riasztások feldolgozásának beállítása

Megkonstruálta a rendszer „egészségügyi” állapotát

A riasztások alapján megfigyelési események jöttek létre, amelyek befolyásolták a konfigurációs egységek (CU) állapotát. Erőforrás-szolgáltatási modellt (RSM) valósítunk meg, amely használhat belső CMDB-t vagy külső CMDB-t is - a pilot projekt során a kliens nem kapcsolta be saját CMDB-jét.

Interfész az erőforrás-szolgáltatás modellel való munkához. Pilóta RSM.

Nos, a kliensnek végre egyetlen felügyeleti képernyője van, ahol a különböző rendszerek eseményei láthatók. Jelenleg két rendszer csatlakozik az „ernyőhöz” - a Zabbix és a Prometheus, valamint magának a platformnak egy belső felügyeleti rendszere.

Analytics felület. Egyetlen monitorozó képernyő.

Elindult a folyamatautomatizálás

Az események figyelése előre konfigurált műveletek elindítását váltotta ki - riasztások küldése, szkriptek futtatása, incidensek regisztrálása/dúsítása - ez utóbbit nem próbáltuk ki ennél a kliensnél, mert a pilot projektben nem történt integráció a szervizzel.

Műveletbeállítások felület. Riasztások küldése a Slacknek, és indítsa újra a szervert.

Bővített termékfunkciók

Amikor az automatizálási szkriptekről beszéltünk, az ügyfél bash támogatást és egy olyan felületet kért, amelyen ezek a szkriptek kényelmesen konfigurálhatók. Az új verzió egy kicsit többet tett (teljes értékű logikai konstrukciók írásának képessége Lua-ban a cURL, SSH és SNMP támogatásával), és olyan funkciókat is bevezetett, amelyek lehetővé teszik a szkript életciklusának kezelését (létrehozás, szerkesztés, verzióvezérlés). , törlés és archiválás).

Interfész az autohealing szkriptekkel való munkavégzéshez. Szerver újraindítási szkript SSH-n keresztül.

Fő megállapítások

A pilot során olyan felhasználói történetek is készültek, amelyek javítják a jelenlegi funkcionalitást és növelik az ügyfél számára az értéket, íme néhány ezek közül:

• megvalósítani a változók közvetlen továbbításának képességét a riasztásból az autohealing szkriptbe;
• jogosultság hozzáadása a platformhoz az Active Directory segítségével.

És újabb globális kihívások elé nézünk – a termék más képességekkel való „felépítése”:

• egy erőforrás-szolgáltatás modell automatikus felépítése ML alapú szabályok és ügynökök helyett (valószínűleg ez a fő kihívás most);
• további szkript- és logikai nyelvek támogatása (ez a JavaScript lesz).

Véleményem szerint a legfontosabbEz a pilot két dolgot mutat:

1. Az eredményesség záloga az ügyféllel való partneri kapcsolat, amikor a hatékony kommunikáció az őszinteségre és a nyitottságra épül, és az ügyfél egy olyan csapat részévé válik, amely rövid időn belül jelentős eredményeket ér el.
2. Semmilyen körülmények között nem szükséges "testreszabni" és "mankókat" építeni - csak rendszermegoldásokat. Jobb, ha egy kicsit több időt tölt, de olyan rendszermegoldást készít, amelyet más ügyfelek is használni fognak. Egyébként ez történt, a beépülő modulrendszer és az Azure-tól való függés megszüntetése további értéket nyújtott a többi kliensnek (helló, 152-es szövetségi törvény).

Forrás: will.com