De ce are nevoie o bancă de monitorizare AIOps și umbrelă sau pe ce se bazează relațiile cu clienții?

În publicațiile despre Habré, am scris deja despre experiența mea de a construi parteneriate cu echipa mea (aici vorbește despre cum să întocmești un acord de parteneriat atunci când începe o nouă afacere, astfel încât afacerea să nu se destrame). Și acum aș dori să vorbesc despre cum să construim parteneriate cu clienții, deoarece fără ei nu va exista nimic care să se destrame. Sper că acest articol va fi util startup-urilor care încep să-și vândă produsul companiilor mari.

În prezent, conduc un startup numit MONQ Digital lab, unde echipa mea și cu mine dezvoltăm un produs pentru automatizarea proceselor de susținere și operare IT corporativă. Intrarea pe piață nu este o sarcină ușoară și am început cu puțină teme, am trecut prin experții de piață, partenerii noștri și am realizat segmentarea pieței. Întrebarea principală a fost să înțelegem „ale cui dureri le putem vindeca cel mai bine?”

Băncile au ajuns în TOP 3 segmente. Și, desigur, primii pe listă au fost Tinkoff și Sberbank. Când am vizitat experții din piața bancară, aceștia ne-au spus: introduceți-vă produsul acolo, iar calea către piața bancară va fi deschisă. Am încercat să intrăm și acolo și acolo, dar eșecul ne aștepta la Sberbank, iar băieții de la Tinkoff s-au dovedit a fi mult mai deschiși la comunicarea productivă cu startup-urile rusești (poate datorită faptului că Sber la acea vreme). cumparat aproape un miliard dintre concurenții noștri occidentali). În decurs de o lună am început un proiect pilot. Cum sa întâmplat, citiți mai departe.

Ne confruntăm cu probleme de operare și monitorizare de mulți ani, acum implementăm produsul nostru în sectorul public, în asigurări, în bănci, în companii de telecomunicații, o implementare era cu o companie aeriană (înainte de proiect, nici măcar nu am făcut cred că aviația era o industrie atât de dependentă de IT, iar acum sperăm cu adevărat, în ciuda COVID, că compania va apărea și va decola).

Produsul pe care îl facem aparține software-ului de întreprindere, segmentul AIOps (Inteligenta Artificială pentru Operațiuni IT, sau ITOps). Principalele obiective ale implementării unor sisteme precum nivelul de maturitate a procesului în companie crește:

1. Stingeți incendiile: identificați defecțiunile, curățați fluxul de alerte de la moloz, atribuiți sarcini și incidente celor responsabili;
2. Creșterea eficienței serviciului IT: reducerea timpului de rezolvare a incidentelor, indicarea cauzelor defecțiunilor, creșterea transparenței stării IT;
3. Creșteți eficiența afacerii: reduceți cantitatea de muncă manuală, reduceți riscurile, creșteți loialitatea clienților.

Din experiența noastră, băncile au următoarele „dureri” cu monitorizarea în comun cu toate infrastructurile IT mari:

• „cine știe ce”: sunt multe departamente tehnice, aproape toată lumea are cel puțin un sistem de monitorizare, iar majoritatea au mai mult de unul;
• „roi de țânțari” de alerte: fiecare sistem generează sute și îi bombardează pe toți responsabilii (uneori și între departamente). Este dificil să menții în mod constant focalizarea controlului asupra fiecărei notificări, urgența și importanța acestora este nivelată din cauza numărului mare;
• băncile mari - liderii de sector vor nu doar să-și monitorizeze în mod continuu sistemele, să știe unde există eșecuri, ci și adevărata magie a AI - să facă sistemele să se automonitorizeze, să se auto-predice și să se autocorecteze.

Când am venit la prima întâlnire de la Tinkoff, ni s-a spus imediat că nu au probleme cu monitorizarea și nimic nu i-a rănit, iar întrebarea principală a fost: „Ce putem oferi celor care se descurcă deja bine?”

Conversația a fost lungă, am discutat despre cum sunt construite microserviciile lor, cum funcționează departamentele, care probleme de infrastructură sunt mai sensibile, care sunt mai puțin sensibile pentru utilizatori, unde sunt „punctele oarbe” și care sunt obiectivele și SLA-urile lor.

Apropo, SLA-urile băncii sunt cu adevărat impresionante. De exemplu, un incident de disponibilitate a rețelei cu prioritate XNUMX poate dura doar câteva minute. Costul erorilor și al timpului de nefuncționare aici, desigur, este impresionant.

Ca urmare, am identificat mai multe domenii de cooperare:

1. prima etapă este monitorizarea umbrelă pentru a crește viteza de rezolvare a incidentelor
2. a doua etapă este automatizarea proceselor pentru a reduce riscurile și a reduce costurile pentru scalarea departamentului IT.

Mai multe „pete albe” puteau fi vopsite în culorile strălucitoare ale alertelor doar prin procesarea informațiilor din mai multe sisteme de monitorizare, deoarece era imposibil să se preia direct metrici; a fost, de asemenea, necesar să se centralizeze datele din diferite sisteme de monitorizare pe „un singur ecran” pentru pentru a înțelege imaginea de ansamblu a ceea ce se întâmpla. „Umbrelele” sunt potrivite pentru această sarcină și am îndeplinit aceste cerințe atunci.

Un lucru foarte important, în opinia noastră, în relațiile cu clienții este onestitatea. După prima conversație și calculul costului licenței, s-a spus că, deoarece costul este atât de mic, ar putea merita să cumpărați o licență imediat (comparativ cu Dynatrace Klyuch-Astrom din articolul de mai sus despre banca verde, licența nu costă o treime de miliard, ci 12 mii de ruble pe lună pentru 1 gigabyte, pentru Sber ar costa de câteva ori mai ieftin). Dar le-am spus imediat ce avem și ce nu. Poate că un reprezentant de vânzări al unui mare integrator ar putea spune „da, putem face totul, bineînțeles să ne cumpărăm licența”, dar am decis să ne punem toate cărțile pe masă. La momentul lansării, caseta noastră nu avea integrare cu Prometheus, iar o nouă versiune cu subsistem de automatizare era pe cale să fie lansată, dar încă nu am livrat-o clienților.

A început proiectul pilot, i s-au stabilit limitele și ni s-au dat 2 luni. Sarcinile principale au fost:

• pregătiți o nouă versiune a platformei și implementați-o în infrastructura băncii
• conectați 2 sisteme de monitorizare (Zabbix și Prometheus);
• trimite notificări celor responsabili în Slack și prin SMS;
• rulați scripturi de vindecare automată.

Prima lună a proiectului pilot a fost petrecută pregătind o nouă versiune a platformei în modul super-rapid pentru nevoile proiectului pilot. Noua versiune include imediat integrarea cu Prometheus și auto-vindecarea. Datorită echipei noastre de dezvoltare, ei nu au dormit câteva nopți, dar au eliberat ceea ce au promis fără a rata termenele limită pentru alte angajamente asumate anterior.

În timp ce înființam pilotul, am întâlnit o nouă problemă care ar putea închide proiectul înainte de termen: pentru a trimite alerte către mesagerie instantanee și prin SMS, aveam nevoie de conexiuni de intrare și de ieșire la serverele Microsoft Azure (la vremea aceea folosim această platformă). pentru a trimite alerte către Slack) și un serviciu extern de trimitere SMS. Dar în acest proiect, siguranța a fost un accent deosebit. În conformitate cu politica băncii, astfel de „găuri” nu au putut fi deschise în nicio circumstanță. Totul trebuia să funcționeze dintr-o buclă închisă. Ni s-a oferit să folosim API-ul propriilor noastre servicii interne care trimit alerte către Slack și prin SMS, dar nu am avut ocazia să conectăm astfel de servicii imediat.

O seară de dezbatere cu echipa de dezvoltare s-a încheiat cu o căutare de succes a unei soluții. După ce am scotocit prin backlog, am găsit o sarcină pentru care nu am avut niciodată suficient timp și prioritate - să creăm un sistem de plug-in, astfel încât echipele de implementare sau clientul să poată scrie ele însele suplimente, extinzând capacitățile platformei.

Dar mai aveam exact o lună, timp în care a trebuit să instalăm totul, să configuram și să implementăm automatizarea.

Potrivit lui Serghei, arhitectul nostru șef, este nevoie de cel puțin o lună pentru a implementa sistemul de plug-in.

nu am avut timp...

A existat o singură soluție - mergeți la client și spuneți totul așa cum este. Discutați împreună despre schimbarea termenului limită. Și a funcționat. Ni s-au dat încă 2 săptămâni. De asemenea, aveau propriile termene limită și obligații interne de a arăta rezultate, dar aveau 2 săptămâni de rezervă. Până la urmă, punem totul în joc. Era imposibil să încurci. Onestitatea și o abordare de parteneriat au dat din nou roade.

În urma pilotului, s-au obținut câteva rezultate tehnice și concluzii importante:

Am testat noua funcționalitate pentru procesarea alertelor

Sistemul instalat a început să primească corect alerte de la Prometheus și să le grupeze. Alertele cu privire la problemă de la clientul Prometheus zburau la fiecare 30 de secunde (gruparea după timp nu este activată) și ne întrebam dacă ar fi posibil să le grupăm în „umbrelă” în sine. S-a dovedit că este posibil - configurarea procesării alertelor în platformă este implementată printr-un script. Acest lucru face posibilă implementarea aproape orice logică pentru procesarea lor. Am implementat deja logica standard în platformă sub formă de șabloane - dacă nu doriți să veniți cu ceva propriu, puteți utiliza una gata făcută.

Interfață „declanșator sintetic”. Configurarea procesării alertelor de la sistemele de monitorizare conectate

A construit starea de „sănătate” a sistemului

Pe baza alertelor, au fost create evenimente de monitorizare care au afectat starea de sănătate a unităților de configurare (CU). Implementăm un model de servicii de resurse (RSM), care poate folosi fie un CMDB intern, fie conecta unul extern - în timpul proiectului pilot clientul nu și-a conectat propriul CMDB.

Interfață pentru lucrul cu modelul resursă-serviciu. Pilot RSM.

Ei bine, de fapt, clientul are în sfârșit un singur ecran de monitorizare, unde sunt vizibile evenimentele din diferite sisteme. În prezent, două sisteme sunt conectate la „umbrelă” - Zabbix și Prometheus și un sistem intern de monitorizare a platformei în sine.

Interfață de analiză. Un singur ecran de monitorizare.

S-a lansat automatizarea proceselor

Monitorizarea evenimentelor a declanșat lansarea acțiunilor preconfigurate - trimiterea de alerte, rularea scripturilor, înregistrarea/îmbogățirea incidentelor - aceasta din urmă nu a fost încercată cu acest client anume, deoarece în proiectul pilot nu a existat nicio integrare cu biroul de service.

Interfață de setări de acțiune. Trimiteți alerte către Slack și reporniți serverul.

Funcționalitate extinsă a produsului

Când discuta despre scripturi de automatizare, clientul a cerut suport pentru bash și o interfață în care aceste scripturi ar putea fi configurate convenabil. În noua versiune, s-a făcut ceva mai mult (capacitatea de a scrie constructe logice cu drepturi depline în Lua cu suport pentru cURL, SSH și SNMP) și s-a implementat funcționalitate care vă permite să gestionați ciclul de viață al unui script (creați, editați , gestionați versiunile, ștergeți și arhivați).

Interfață pentru lucrul cu scripturi de vindecare automată. Scriptul de repornire a serverului prin SSH.

Principalele constatări

În timpul pilotului au fost create și poveștile utilizatorilor care îmbunătățesc funcționalitatea actuală și cresc valoarea pentru client, iată câteva dintre ele:

• implementați capacitatea de a transmite variabile direct de la alertă la scriptul de auto-vindecare;
• adăugați autorizație la platformă prin Active Directory.

Și am primit mai multe provocări globale - să „construiem” produsul cu alte capacități:

• construirea automată a unui model de resurse-serviciu bazat pe ML, mai degrabă decât pe reguli și agenți (probabil principala provocare acum);
• suport pentru scripturi suplimentare și limbaje logice (și acesta va fi JavaScript).

În opinia mea cel mai important lucruCeea ce arată acest pilot sunt două lucruri:

1. Parteneriatele cu clientul sunt cheia eficacității, atunci când comunicarea eficientă este construită pe baza onestității și deschiderii, iar clientul devine parte dintr-o echipă care obține rezultate semnificative într-un timp scurt.
2. În niciun caz nu este necesar să „personalizați” și să construiți „cârje” - doar soluții de sistem. Este mai bine să petreceți puțin mai mult timp, dar să creați o soluție de sistem care să fie folosită de alți clienți. Apropo, așa s-a întâmplat, sistemul de pluginuri și eliminarea dependenței de Azure au oferit valoare suplimentară altor clienți (bună ziua, Legea federală 152).

Sursa: www.habr.com