Publikacijose apie Habré jau rašiau apie savo patirtį kuriant partnerystę su savo komanda ( kalbama apie tai, kaip surašyti partnerystės sutartį pradedant naują verslą, kad verslas nesugriūtų). O dabar norėčiau pakalbėti apie tai, kaip užmegzti partnerystę su klientais, nes be jų nebus ko subyrėti. Tikiuosi, kad šis straipsnis bus naudingas pradedantiesiems, kurie pradeda parduoti savo produktą didelėms įmonėms.
Šiuo metu vadovauju startuoliui MONQ Digital lab, kuriame su komanda kuriame produktą, skirtą įmonės IT palaikymo ir valdymo procesams automatizuoti. Įeiti į rinką nėra lengva užduotis ir pradėjome nuo nedidelių namų darbų, perėjome rinkos ekspertus, savo partnerius ir atlikome rinkos segmentavimą. Pagrindinis klausimas buvo suprasti „kieno skausmus galime geriausiai išgydyti?
Bankai pateko į TOP 3 segmentus. Ir, žinoma, pirmieji sąraše buvo „Tinkoff“ ir „Sberbank“. Kai lankėmės pas bankų rinkos ekspertus, jie sakė: pristatykite ten savo produktą, ir kelias į bankų rinką bus atviras. Bandėme įeiti ir ten, ir ten, tačiau Sberbanke mūsų laukė nesėkmė, o vaikinai iš Tinkoff pasirodė daug atviresni produktyviam bendravimui su Rusijos startuoliais (gal dėl to, kad Sberis tuo metu beveik milijardas mūsų Vakarų konkurentų). Per mėnesį pradėjome bandomąjį projektą. Kaip tai atsitiko, skaitykite toliau.
Jau daug metų sprendžiame veiklos ir stebėsenos klausimus, dabar savo produktą diegiame viešajame sektoriuje, draudime, bankuose, telekomunikacijų įmonėse, vienas diegimas buvo su aviakompanija (iki projekto net nedarėme manau, kad aviacija buvo tokia nuo IT priklausoma pramonė, ir dabar mes tikrai tikimės, nepaisant COVID, kad įmonė atsiras ir pakils).
Mūsų gaminamas produktas priklauso įmonės programinei įrangai, AIOps (dirbtinis intelektas IT operacijoms arba ITOps) segmentui. Pagrindiniai tokių sistemų diegimo tikslai, nes procesų brandos lygis įmonėje didėja:
- Gesinkite gaisrus: nustatykite gedimus, išvalykite įspėjimų srautą nuo šiukšlių, paskirkite užduotis ir incidentus atsakingiems asmenims;
- Padidinti IT paslaugos efektyvumą: sumažinti incidentų sprendimo laiką, nurodyti gedimų priežastis, padidinti IT būsenos skaidrumą;
- Padidinti verslo efektyvumą: sumažinti rankų darbo kiekį, sumažinti riziką, didinti klientų lojalumą.
Mūsų patirtis rodo, kad bankai turi tokius „skausmus“ su stebėjimu, kaip ir visos didelės IT infrastruktūros:
- „kas ką žino“: yra daug techninių skyrių, beveik visi turi bent vieną stebėjimo sistemą, o dauguma – daugiau nei vieną;
- įspėjimų „spiečius apie uodus“: kiekviena sistema generuoja šimtus ir su jais bombarduoja visus atsakingus asmenis (kartais ir tarp skyrių). Sunku nuolat sutelkti dėmesį į kiekvieno pranešimo kontrolę, jų skubumas ir svarba yra išlyginti dėl didelio skaičiaus;
- didieji bankai – sektoriaus lyderiai nori ne tik nuolat stebėti savo sistemas, žinoti, kur yra gedimų, bet ir tikroji AI magija – priversti sistemas savarankiškai stebėti, nuspėti ir save koreguoti.
Atvykus į pirmąjį susitikimą „Tinkoff“, iš karto buvo pasakyta, kad su stebėjimu jiems problemų nėra ir nieko neskauda, o pagrindinis klausimas buvo: „Ką galime pasiūlyti tiems, kuriems jau sekasi?
Pokalbis buvo ilgas, diskutavome, kaip kuriamos jų mikropaslaugos, kaip veikia padaliniai, kurios infrastruktūros problemos jautresnės, kurios mažiau jautrios vartotojams, kur yra „aklosios dėmės“, kokie jų tikslai ir SLA.
Beje, banko SLA yra tikrai įspūdingi. Pavyzdžiui, XNUMX prioriteto tinklo pasiekiamumo incidentas gali užtrukti tik kelias minutes. Žinoma, klaidų ir prastovų kaina čia yra įspūdinga.
Dėl to nustatėme kelias bendradarbiavimo sritis:
- pirmasis etapas yra skėtis stebėjimas, siekiant padidinti incidentų sprendimo greitį
- antrasis etapas yra procesų automatizavimas, siekiant sumažinti riziką ir sumažinti IT skyriaus mastelio keitimo išlaidas.
Keletą „baltų dėmių“ buvo galima nudažyti ryškiomis perspėjimų spalvomis tik apdorojant informaciją iš kelių stebėjimo sistemų, nes nebuvo galima tiesiogiai paimti metrikų, taip pat reikėjo centralizuoti skirtingų stebėjimo sistemų duomenis „viename ekrane“, kad suprasti bendrą vaizdą apie tai, kas vyksta. „Skėčiai“ yra tinkami šiai užduočiai ir mes tada atitikome šiuos reikalavimus.
Labai svarbus dalykas, mūsų nuomone, santykiuose su klientais yra sąžiningumas. Po pirmo pokalbio ir paskaičiavus licencijos kainą, buvo pasakyta, kad kadangi kaina tokia maža, galbūt verta įsigyti licenciją iš karto (palyginti su Dynatrace Klyuch-Astrom iš aukščiau esančio straipsnio apie žaliąjį banką, mūsų licencija kainuoja ne trečdalį milijardo, o 12 tūkstančių rublių per mėnesį už 1 gigabaitą, Sber kainuotų kelis kartus pigiau). Bet mes iškart jiems pasakėme, ką turime, o ko ne. Galbūt pardavimų atstovas iš didelio integratoriaus galėtų pasakyti „taip, mes galime padaryti viską, žinoma, nusipirk mūsų licenciją“, bet nusprendėme visas savo korteles padėti ant stalo. Paleidimo metu mūsų dėžutė nebuvo integruota su „Prometheus“ ir netrukus buvo išleista nauja versija su automatizavimo posisteme, tačiau mes jos dar neišsiuntėme klientams.
Prasidėjo bandomasis projektas, buvo nustatytos jo ribos ir mums buvo duoti 2 mėn. Pagrindinės užduotys buvo:
- parengti naują platformos versiją ir įdiegti ją banko infrastruktūroje
- prijungti 2 stebėjimo sistemas (Zabbix ir Prometheus);
- siųsti pranešimus atsakingiems asmenims Slack ir SMS žinutėmis;
- paleiskite automatinio gydymo scenarijus.
Pirmasis bandomojo projekto mėnuo buvo praleistas ruošiant naują platformos versiją itin greitu režimu bandomojo projekto reikmėms. Naujoji versija iš karto apima integraciją su Prometheus ir automatinį gydymą. Mūsų kūrėjų komandos dėka jie nemiegojo kelias naktis, o išleido tai, ką pažadėjo, nepraleisdami kitų anksčiau prisiimtų įsipareigojimų terminų.
Nustatydami bandomąjį projektą susidūrėme su nauja problema, dėl kurios projektas galėjo būti uždarytas anksčiau laiko: norint siųsti įspėjimus momentiniams pasiuntiniams ir SMS žinutėmis, mums reikėjo įeinančių ir išeinančių jungčių su „Microsoft Azure“ serveriais (tuo metu naudojome šią platformą siųsti įspėjimus Slack) ir išorinę siuntimo paslaugą SMS. Tačiau šiame projekte saugumui buvo skiriamas ypatingas dėmesys. Pagal banko politiką tokios „skylės“ negalėjo atsidaryti jokiomis aplinkybėmis. Viskas turėjo veikti iš uždaro ciklo. Mums buvo pasiūlyta naudotis savo vidinių paslaugų API, kurios siunčia perspėjimus į Slack ir SMS žinutėmis, tačiau neturėjome galimybės tokių paslaugų prijungti iš dėžutės.
Debatų vakaras su kūrėjų komanda baigėsi sėkminga sprendimo paieška. Pasiknaisioję po atsilikimą radome vieną užduotį, kuriai niekada neužteko laiko ir prioriteto – sukurti įskiepių sistemą, kad diegimo komandos ar klientas galėtų patys rašyti priedus, plečiančius platformos galimybes.
Bet mums liko lygiai mėnuo, per kurį turėjome viską įdiegti, sukonfigūruoti ir įdiegti automatiką.
Pasak mūsų vyriausiojo architekto Sergejaus, įdiegti įskiepių sistemą užtrunka mažiausiai mėnesį.
Mes neturėjome laiko...
Išeitis buvo tik viena – nueik pas klientą ir pasakyk viską taip, kaip yra. Kartu aptarkite termino pakeitimą. Ir pavyko. Mums buvo duotos papildomos 2 savaitės. Jie taip pat turėjo savo terminus ir vidinius įsipareigojimus rodyti rezultatus, tačiau turėjo 2 rezervines savaites. Galų gale mes viską sudėjome ant linijos. Sumaišyti buvo neįmanoma. Sąžiningumas ir partnerystės požiūris vėl pasiteisino.
Bandymo metu buvo gauti keli svarbūs techniniai rezultatai ir išvados:
Išbandėme naują įspėjimų apdorojimo funkciją
Įdiegta sistema pradėjo teisingai gauti įspėjimus iš Prometheus ir juos grupuoti. Perspėjimai apie problemą iš „Prometheus“ kliento skraidė kas 30 sekundžių (grupavimas pagal laiką neįjungtas), ir mes galvojome, ar būtų galima juos sugrupuoti pačiame „skėtyje“. Paaiškėjo, kad tai įmanoma – perspėjimų apdorojimo nustatymas platformoje įgyvendinamas pagal scenarijų. Tai leidžia įgyvendinti beveik bet kokią jų apdorojimo logiką. Mes jau įdiegėme standartinę logiką platformoje šablonų pavidalu - jei nenorite sugalvoti kažko savo, galite naudoti paruoštą.
„Sintetinis trigeris“ sąsaja. Įspėjimų iš prijungtų stebėjimo sistemų apdorojimo nustatymas
Sukūrė sistemos „sveikatos“ būseną
Remiantis įspėjimais, buvo sukurti stebėjimo įvykiai, kurie turėjo įtakos konfigūracijos vienetų (CU) būklei. Diegiame resursų-paslaugų modelį (RSM), kuris gali naudoti arba vidinį CMDB, arba jungti išorinį – pilotinio projekto metu klientas neprijungė savo CMDB.
Sąsaja darbui su išteklių ir paslaugų modeliu. Pilotas RSM.
Na, o iš tikrųjų klientas pagaliau turi vieną stebėjimo ekraną, kuriame matomi įvykiai iš skirtingų sistemų. Šiuo metu prie „skėčio“ prijungtos dvi sistemos – „Zabbix“ ir „Prometheus“ bei pačios platformos vidinė stebėjimo sistema.
Analitikos sąsaja. Vienas stebėjimo ekranas.
Pradėtas procesų automatizavimas
Įvykių stebėjimas paskatino iš anksto sukonfigūruotų veiksmų paleidimą - įspėjimų siuntimą, scenarijų vykdymą, incidentų registravimą / praturtinimą - pastarasis nebuvo išbandytas su šiuo konkrečiu klientu, nes bandomajame projekte nebuvo integracijos su aptarnavimo centru.
Veiksmų nustatymų sąsaja. Nusiųskite įspėjimus „Slack“ ir paleiskite serverį iš naujo.
Išplėstas gaminio funkcionalumas
Aptariant automatizavimo scenarijus, klientas paprašė bash palaikymo ir sąsajos, kurioje būtų galima patogiai konfigūruoti šiuos scenarijus. Naujoje versijoje padaryta šiek tiek daugiau (galimybė rašyti visavertes logines konstrukcijas Lua programoje su cURL, SSH ir SNMP palaikymu) ir įdiegta funkcija, leidžianti valdyti scenarijaus gyvavimo ciklą (kurti, redaguoti, valdyti versiją , ištrinti ir archyvuoti).
Sąsaja darbui su automatinio gydymo scenarijais. Serverio perkrovimo scenarijus per SSH.
Pagrindinės išvados
Bandymo metu taip pat buvo sukurtos vartotojų istorijos, kurios pagerina esamą funkcionalumą ir padidina vertę klientui, štai keletas iš jų:
- įdiegti galimybę persiųsti kintamuosius tiesiai iš įspėjimo į automatinio gydymo scenarijų;
- pridėti prieigos teisę prie platformos per „Active Directory“.
Ir sulaukėme daugiau globalių iššūkių – „sukurti“ produktą su kitomis galimybėmis:
- automatinis išteklių ir paslaugų modelio kūrimas remiantis ML, o ne taisyklėmis ir agentais (turbūt dabar pagrindinis iššūkis);
- papildomų scenarijų ir logikos kalbų palaikymas (ir tai bus „JavaScript“).
Mano nuomone, svarbiausias dalykasŠis pilotas rodo du dalykus:
- Partnerystė su klientu yra raktas į efektyvumą, kai efektyvi komunikacija kuriama sąžiningumo ir atvirumo pagrindu, o klientas tampa komandos dalimi, kuri per trumpą laiką pasiekia reikšmingų rezultatų.
- Jokiomis aplinkybėmis nereikia „pritaikyti“ ir kurti „ramentus“ – tik sisteminius sprendimus. Geriau skirti šiek tiek daugiau laiko, bet sukurti sisteminį sprendimą, kurį naudos kiti klientai. Beje, taip ir atsitiko, papildinių sistema ir priklausomybės nuo Azure panaikinimas suteikė papildomos vertės kitiems klientams (sveiki, Federalinis įstatymas 152).
Šaltinis: www.habr.com