Yn publikaasjes oer Habré skreau ik al oer myn ûnderfining fan it bouwen fan gearwurkingsferbannen mei myn team ( praat oer hoe't jo in gearwurkingsoerienkomst opstelle kinne by it starten fan in nij bedriuw, sadat it bedriuw net útinoar falt). En no wol ik prate oer hoe't jo partnerskippen mei kliïnten bouwe, om't sûnder har neat útinoar falle sil. Ik hoopje dat dit artikel nuttich sil wêze foar startups dy't har produkt begjinne te ferkeapjen oan grutte bedriuwen.
Ik bin op it stuit haad fan in opstart neamd MONQ Digital lab, wêr't myn team en ik in produkt ûntwikkelje foar it automatisearjen fan de prosessen fan it stypjen en operearjen fan bedriuws-IT. De merk ynfiere is gjin maklike taak en wy binne begon mei in bytsje húswurk, gongen troch merkeksperts, ús partners en fierden merksegmentaasje út. De wichtichste fraach wie om te begripen "waans pine kinne wy it bêste genêze?"
Banken makken it yn 'e TOP 3 segminten. En fansels, de earste op 'e list wiene Tinkoff en Sberbank. Doe't wy saakkundigen fan bankmerken besochten, seine se: yntrodusearje jo produkt dêr, en it paad nei de bankmerk sil iepen wêze. Wy besochten sawol dêr as dêr yn te gean, mar mislearring wachte ús by Sberbank, en de jonges fan Tinkoff bliken folle mear iepen te wêzen foar produktive kommunikaasje mei Russyske startups (miskien troch it feit dat Sber op dat stuit hast in miljard fan ús westerske konkurrinten). Binnen in moanne binne wy in proefprojekt begûn. Hoe't it barde, lês fierder.
Wy hawwe in protte jierren dwaande west mei problemen fan operaasje en monitoaring, no implementearje wy ús produkt yn 'e publike sektor, yn fersekering, yn banken, yn telekombedriuwen, ien ymplemintaasje wie mei in loftfeartmaatskippij (foar it projekt hawwe wy net iens tink dat de loftfeart sa'n IT-ôfhinklike yndustry wie, en no hoopje wy wirklik, nettsjinsteande COVID, dat it bedriuw sil ûntstean en opstappe).
It produkt dat wy meitsje heart ta ûndernimmingssoftware, it segment AIOps (Artificial Intelligence for IT Operations, of ITOps). De haaddoelen fan it ymplementearjen fan sokke systemen lykas it nivo fan prosesferfal yn it bedriuw nimt ta:
- Brannen útsette: mislearrings identifisearje, de stream fan warskôgings wiskje fan ôffal, taken en ynsidinten tawize oan ferantwurdliken;
- Ferheegje de effisjinsje fan 'e IT-tsjinst: ferminderje de tiid om ynsidinten op te lossen, de oarsaken fan mislearrings oanjaan, de transparânsje fan' e IT-status ferheegje;
- Ferheegje saaklike effisjinsje: ferminderje it bedrach fan hânwurk, ferminderje risiko's, fergrutsje klantloyaliteit.
Yn ús ûnderfining hawwe banken de folgjende "pine" mei tafersjoch mienskiplik mei alle grutte IT-ynfrastruktuer:
- "wa wit wat": der binne in protte technyske ôfdielings, hast elkenien hat op syn minst ien tafersjochsysteem, en de measten hawwe mear as ien;
- "muggenswerm" fan warskôgings: elk systeem genereart hûnderten en bombardeart allegear ferantwurdliken mei har (soms ek tusken ôfdielingen). It is lestich om konstant de fokus fan kontrôle op elke notifikaasje te behâlden; har urginsje en belang wurdt nivellere troch it grutte oantal;
- grutte banken - sektorlieders wolle net allinich har systemen kontinu kontrolearje, witte wêr't mislearrings binne, mar ek de echte magy fan AI - om de systemen sels te kontrolearjen, sels te foarsizzen en selskorrekt te meitsjen.
Doe't wy by de earste gearkomste by Tinkoff kamen, waarden wy fuortdaliks ferteld dat se gjin problemen hiene mei tafersjoch en neat sear se, en de wichtichste fraach wie: "Wat kinne wy biede foar dyjingen dy't it al goed dogge?"
It petear wie lang, wy besprutsen hoe't har mikrotsjinsten binne boud, hoe't ôfdielingen wurkje, hokker ynfrastruktuerproblemen gefoeliger binne, wat minder gefoelich binne foar brûkers, wêr binne de "blinde flekken", en wat binne har doelen en SLA's.
Trouwens, de SLA's fan 'e bank binne echt yndrukwekkend. Bygelyks, in ynsidint foar beskikberens fan prioriteit XNUMX kin mar in pear minuten duorje om op te lossen. De kosten fan flater en downtime hjir, fansels, is yndrukwekkend.
As gefolch hawwe wy ferskate gebieten fan gearwurking identifisearre:
- de earste etappe is paraplu monitoring te fergrutsjen de snelheid fan ynsidint resolúsje
- de twadde etappe is proses automatisearring te ferminderjen risiko's en ferminderjen kosten foar skaalfergrutting fan de IT ôfdieling.
Ferskate "wite flekken" koenen wurde skildere yn 'e heldere kleuren fan warskôgings allinich troch it ferwurkjen fan ynformaasje fan ferskate tafersjochsystemen, om't it ûnmooglik wie om direkt metriken te nimmen; it wie ek nedich om gegevens fan ferskate tafersjochsystemen te sintralisearjen op "ien skerm" yn oarder om it algemiene byld te begripen fan wat der bart. "Umbrellas" binne geskikt foar dizze taak en wy foldogge oan dizze easken doe.
In heul wichtich ding, nei ús miening, yn relaasjes mei kliïnten is earlikens. Nei it earste petear en de berekkening fan 'e kosten fan' e lisinsje waard sein dat, om't de kosten sa leech binne, it miskien de muoite wurdich wêze kin om in lisinsje direkt te keapjen (ferlike mei Dynatrace Klyuch-Astrom út it artikel hjirboppe oer de griene bank, ús lisinsje kostet net in tredde fan in miljard, mar 12 tûzen roebel per moanne foar 1 gigabyte, foar Sber it soe kostje ferskate kearen goedkeaper). Mar wy fertelden har daliks wat wy hawwe en wat wy net. Miskien kin in ferkeapfertsjintwurdiger fan in grutte yntegrator sizze "ja, wy kinne alles dwaan, fansels keapje ús lisinsje", mar wy besletten om al ús kaarten op 'e tafel te lizzen. Op it stuit fan lansearring hie ús doaze gjin yntegraasje mei Prometheus, en in nije ferzje mei in automatisearringssubsysteem stie op it punt om frij te wurden, mar wy hawwe it noch net nei klanten ferstjoerd.
It pilotprojekt begûn, de grinzen waarden bepaald en wy krigen 2 moannen. De wichtichste taken wiene:
- tariede in nije ferzje fan it platfoarm en ynsette it yn de bank syn ynfrastruktuer
- ferbine 2 monitoaring systemen (Zabbix en Prometheus);
- ferstjoere notifikaasjes nei ferantwurdliken yn Slack en fia SMS;
- rinne autohealing skripts.
De earste moanne fan it pilotprojekt waard bestege oan it tarieden fan in nije ferzje fan it platfoarm yn supersnelle modus foar de behoeften fan it pilotprojekt. De nije ferzje befettet fuortendaliks yntegraasje mei Prometheus en auto-healing. Mei tank oan ús ûntwikkelingsteam sliepten se ferskate nachten net, mar lieten se út wat se tasein hawwe sûnder de deadlines te missen foar oare earder makke ferplichtingen.
Wylst wy de pilot ynstelden, tsjinkamen wy in nij probleem dat it projekt foarôfgeand oan skema slute koe: om warskôgings te stjoeren nei instant messengers en fia SMS, hiene wy ynkommende en útgeande ferbiningen nedich mei Microsoft Azure-tsjinners (op dat stuit brûkten wy dit platfoarm om warskôgings nei Slack te stjoeren) en in eksterne ferstjoertsjinst SMS. Mar yn dit projekt wie feiligens in spesjaal fokus. Yn oerienstimming mei it belied fan de bank koene sokke "gaten" yn gjin gefal net iepene wurde. Alles moast wurkje út in sletten lus. Wy waarden oanbean om de API fan ús eigen ynterne tsjinsten te brûken dy't warskôgings stjoere nei Slack en fia SMS, mar wy hawwe net de kâns om sokke tsjinsten út 'e doaze te ferbinen.
In jûn fan debat mei it ûntwikkelteam einige mei in suksesfolle syktocht nei in oplossing. Nei't wy de efterstân trochsocht hawwe, fûnen wy ien taak dêr't wy noait genôch tiid en prioriteit foar hiene - in plug-in-systeem te meitsjen sadat de ymplemintaasjeteams as de kliïnt sels tafoegings skriuwe kinne, en de mooglikheden fan it platfoarm útwreidzje.
Mar wy hiene krekt in moanne oer, wêryn wy alles ynstalleare, automatisearring konfigurearje en ynsette.
Neffens Sergei, ús haadarsjitekt, duorret it op syn minst in moanne om in plug-in-systeem te realisearjen.
Wy hiene gjin tiid...
D'r wie mar ien oplossing - gean nei de klant en fertel alles sa't it is. Beprate de deadline ferskowing tegearre. En it wurke. Wy krigen in ekstra 2 wiken. Se hiene ek har eigen deadlines en ynterne ferplichtingen om resultaten te sjen, mar se hiene 2 reservewiken. Oan 'e ein sette wy alles op' e line. It wie ûnmooglik om te rommeljen. Earlikens en in partnerskiplike oanpak betellen wer frucht.
As gefolch fan 'e pilot waarden ferskate wichtige technyske resultaten en konklúzjes krigen:
Wy testen de nije funksjonaliteit foar it ferwurkjen fan warskôgings
It ynset systeem begon goed warskôgings fan Prometheus te ûntfangen en se te groepearjen. Alerts oer it probleem fan 'e Prometheus-kliïnt fleagen elke 30 sekonden (groepearje troch tiid is net ynskeakele), en wy fregen ús ôf oft it mooglik wêze soe om se yn 'e "paraplu" sels te groepearjen. It die bliken dat it mooglik is - it ynstellen fan de ferwurking fan warskôgings yn it platfoarm wurdt útfierd troch in skript. Dit makket it mooglik om te fieren hast alle logika foar it ferwurkjen fan harren. Wy hawwe al standertlogika yn it platfoarm ymplementearre yn 'e foarm fan sjabloanen - as jo net wat fan jo eigen wolle komme, kinne jo in klearmakke brûke.
"Syntetyske trigger" ynterface. It ynstellen fan ferwurking fan warskôgings fan ferbûne tafersjochsystemen
Konstruearre de steat fan "sûnens" fan it systeem
Op grûn fan warskôgings waarden tafersjocheveneminten makke dy't de sûnens fan konfiguraasje-ienheden (CU's) beynfloede. Wy implementearje in resource-service model (RSM), dat kin brûke of in ynterne CMDB of ferbine in eksterne ien - tidens it pilotprojekt de klant hat net ferbûn syn eigen CMDB.
Ynterface foar wurkjen mei it boarne-tsjinstmodel. Pilot RSM.
No, yn feite, de klant hat úteinlik in inkele monitoring skerm, dêr't eveneminten út ferskate systemen binne sichtber. Op it stuit binne twa systemen ferbûn mei de "paraplu" - Zabbix en Prometheus, en in ynterne tafersjochsysteem fan it platfoarm sels.
Analytics ynterface. Single monitoring skerm.
Prosesautomatisaasje lansearre
Tafersjoch-eveneminten triggere de lansearring fan foarôf ynstelde aksjes - it ferstjoeren fan warskôgings, it útfieren fan skripts, registrearjen / ferrykjen fan ynsidinten - dat lêste waard net besocht mei dizze bepaalde kliïnt, om't yn it pilotprojekt wie gjin yntegraasje mei de tsjinstbalie.
Aksje ynstellings ynterface. Stjoer warskôgings nei Slack en herstart de tsjinner.
Utwreide produktfunksjonaliteit
By it besprekken fan automatisearringsskripts frege de kliïnt om bash-stipe en in ynterface wêryn dizze skripts maklik konfigureare koenen. De nije ferzje hat in bytsje mear dien (de mooglikheid om folweardige logyske konstruksjes yn Lua te skriuwen mei stipe foar cURL, SSH en SNMP) en funksjonaliteit ymplementearre wêrmei jo de libbenssyklus fan in skript kinne beheare (oanmeitsje, bewurkje, ferzjekontrôle , wiskje en argivearje).
Ynterface foar wurkjen mei autohealing skripts. Server opnij skript fia SSH.
Key Findings
Tidens de pilot waarden ek brûkersferhalen makke dy't de hjoeddeistige funksjonaliteit ferbetterje en wearde foar de klant ferheegje, hjir binne guon fan har:
- ymplemintearje de mooglikheid om fariabelen direkt fan 'e warskôging nei it autohealing-skript troch te stjoeren;
- foegje autorisaasje ta oan it platfoarm fia Active Directory.
En wy krigen mear wrâldwide útdagings - om it produkt "op te bouwen" mei oare mooglikheden:
- automatyske konstruksje fan in boarne-tsjinstmodel basearre op ML, ynstee fan regels en aginten (wierskynlik de wichtichste útdaging no);
- stipe foar ekstra skript- en logyske talen (en dit sil JavaScript wêze).
Yn myn miening, it wichtichsteWat dizze pilot toant is twa dingen:
- Partnerships mei de klant binne de kaai foar effektiviteit, as effektive kommunikaasje wurdt boud op basis fan earlikens en iepenheid, en de klant wurdt diel fan in team dat berikt wichtige resultaten yn in koarte tiid.
- Under gjin omstannichheden is it nedich om "oan te passen" en te bouwen "krukken" - allinich systeemoplossingen. It is better om in bytsje mear tiid te besteegjen, mar meitsje in systeemoplossing dy't brûkt wurde troch oare kliïnten. Trouwens, dit is wat barde, it plugin-systeem en it opheffen fan ôfhinklikens fan Azure levere ekstra wearde foar oare kliïnten (hallo, Federal Law 152).
Boarne: www.habr.com