V publikacijah na Habréju sem že pisal o svojih izkušnjah pri gradnji partnerstev s svojo ekipo ( govori o tem, kako sestaviti partnersko pogodbo ob ustanovitvi novega podjetja, da podjetje ne razpade). In zdaj bi rad govoril o tem, kako zgraditi partnerstvo s strankami, saj brez njih ne bo nič razpadlo. Upam, da bo ta članek koristen startupom, ki začenjajo prodajati svoje izdelke velikim podjetjem.
Trenutno vodim startup z imenom MONQ Digital lab, kjer z ekipo razvijamo produkt za avtomatizacijo procesov podpore in delovanja korporativnega IT-ja. Vstop na trg ni lahka naloga in začeli smo z majhno domačo nalogo, šli skozi tržne strokovnjake, naše partnerje in izvedli segmentacijo trga. Glavno vprašanje je bilo razumeti, "čigave bolečine lahko najbolje pozdravimo?"
Banke so se uvrstile med TOP 3 segmente. In seveda, prva na seznamu sta bila Tinkoff in Sberbank. Ko smo obiskali poznavalce bančnega trga, so rekli: uvedite tam svoj produkt, pa bo pot na bančni trg odprta. Poskušali smo vstopiti tako tam kot tam, vendar nas je v Sberbank pričakal neuspeh, fantje iz Tinkoffa pa so se izkazali za veliko bolj odprte za produktivno komunikacijo z ruskimi startupi (morda zaradi dejstva, da je Sber takrat skoraj milijarda naših zahodnih konkurentov). V enem mesecu smo začeli pilotni projekt. Kako se je zgodilo, preberite.
Z vprašanji delovanja in spremljanja se ukvarjamo že vrsto let, zdaj naš produkt implementiramo v javni sektor, v zavarovalništvo, banke, telekome, ena implementacija je bila pri letalski družbi (pred projektom nismo niti mislim, da je bilo letalstvo tako odvisna industrija od IT, in zdaj res upamo, da se bo podjetje kljub COVID-u pojavilo in zaživelo).
Izdelek, ki ga izdelujemo, sodi v poslovno programsko opremo, segment AIOps (Artificial Intelligence for IT Operations oz. ITOps). Glavni cilji uvedbe takih sistemov, saj se stopnja zrelosti procesov v podjetju poveča:
- Gasite požare: prepoznajte okvare, očistite tok opozoril pred razbitinami, dodelite naloge in incidente odgovornim;
- Povečajte učinkovitost IT storitve: skrajšajte čas za reševanje incidentov, navedite vzroke okvar, povečajte preglednost IT statusa;
- Povečajte učinkovitost poslovanja: zmanjšajte količino fizičnega dela, zmanjšajte tveganja, povečajte zvestobo strank.
Po naših izkušnjah imajo banke naslednje »bolečine« pri spremljanju, ki so skupne vsem velikim IT infrastrukturam:
- »kdo ve kaj«: tehničnih oddelkov je veliko, skoraj vsak ima vsaj en nadzorni sistem, večina pa več kot enega;
- »mosquito swarm« opozoril: vsak sistem ustvari na stotine in z njimi bombardira vse odgovorne (včasih tudi med oddelki). Težko je stalno vzdrževati fokus nadzora na posameznem obvestilu, njihova nujnost in pomembnost sta zaradi velikega števila izenačena;
- velike banke – vodilni v sektorju ne želijo samo nenehno spremljati svojih sistemov, vedeti, kje so napake, ampak tudi pravo čarovnijo umetne inteligence – narediti sisteme za samonadzor, samopredvidevanje in samopopravljanje.
Ko smo prišli na prvi sestanek v Tinkoff, so nam takoj povedali, da nimajo težav s spremljanjem in jih nič ne boli, glavno vprašanje pa je bilo: "Kaj lahko ponudimo za tiste, ki jim gre že dobro?"
Pogovor je bil dolg, razpravljali smo o tem, kako so zgrajene njihove mikrostoritve, kako delujejo oddelki, kateri infrastrukturni problemi so bolj občutljivi, kateri manj občutljivi za uporabnike, kje so »mrtve pege« in kakšni so njihovi cilji in SLA.
Mimogrede, pogodbe o ravni storitev banke so res impresivne. Na primer, razrešitev incidenta z razpoložljivostjo omrežja prioritete XNUMX lahko traja le nekaj minut. Cena napak in izpadov je tukaj seveda impresivna.
Posledično smo opredelili več področij sodelovanja:
- prva stopnja je krovni nadzor za povečanje hitrosti reševanja incidentov
- druga stopnja je avtomatizacija procesov za zmanjšanje tveganj in zmanjšanje stroškov za povečanje IT oddelka.
Več »belih lis« je bilo mogoče pobarvati v svetle barve opozoril le z obdelavo informacij iz več nadzornih sistemov, saj je bilo nemogoče neposredno prevzeti meritve, prav tako je bilo treba podatke iz različnih nadzornih sistemov centralizirati na »en zaslon«, da razumeti celotno sliko dogajanja. »Dežniki« so primerni za to nalogo in te zahteve smo takrat izpolnili.
Zelo pomembna stvar v odnosih s strankami je po našem mnenju poštenost. Po prvem pogovoru in izračunu stroškov licence je bilo rečeno, da glede na to, da so stroški tako nizki, bi se morda splačalo takoj kupiti licenco (v primerjavi z Dynatrace Klyuch-Astrom iz zgornjega članka o zeleni banki, naš licenca ne stane tretjine milijarde, ampak 12 tisoč rubljev na mesec za 1 gigabajt, za Sber bi stala nekajkrat ceneje). Smo pa takoj povedali, kaj imamo in česa ne. Morda bi komercialist velikega integratorja lahko rekel »ja, mi zmoremo vse, seveda kupi licenco«, vendar smo se odločili položiti vse karte na mizo. V času lansiranja naš box ni imel integracije s Prometheusom in je bila tik pred izidom nova različica s podsistemom za avtomatizacijo, vendar je še nismo poslali strankam.
Pilotni projekt se je začel, njegove meje so bile določene in imeli smo 2 meseca časa. Glavne naloge so bile:
- pripraviti novo različico platforme in jo namestiti v infrastrukturo banke
- povežite 2 nadzorna sistema (Zabbix in Prometheus);
- pošiljanje obvestil odgovornim v Slacku in prek SMS-a;
- zaženite skripte za samodejno zdravljenje.
Prvi mesec pilotnega projekta je bil namenjen pripravi nove različice platforme v super hitrem načinu za potrebe pilotnega projekta. Nova različica takoj vključuje integracijo s Prometheusom in samodejno zdravljenje. Zahvaljujoč naši razvojni ekipi več noči niso spali, ampak so izdali, kar so obljubili, ne da bi zamudili roke za druge prej sprejete obveznosti.
Med nastavljanjem pilotnega projekta smo naleteli na novo težavo, ki bi lahko projekt predčasno zaprla: za pošiljanje opozoril v takojšnje sporočanje in prek SMS-ov smo potrebovali dohodne in odhodne povezave s strežniki Microsoft Azure (takrat smo uporabljali to platformo za pošiljanje opozoril v Slack) in zunanjo storitev pošiljanja SMS. Toda v tem projektu je bila posebna pozornost namenjena varnosti. Skladno s politiko banke takšnih “lukenj” v nobenem primeru ni bilo mogoče odpreti. Vse je moralo delovati iz zaprtega kroga. Ponudili so nam uporabo API-ja lastnih internih storitev, ki pošiljajo opozorila v Slack in prek SMS-ov, vendar nismo imeli možnosti, da bi takšne storitve povezali takoj.
Večer debate z razvojno ekipo se je zaključil z uspešnim iskanjem rešitve. Ko smo brskali po zaostankih, smo našli eno nalogo, za katero nikoli nismo imeli dovolj časa in prioritete - ustvariti plug-in sistem, da bi lahko implementacijske ekipe ali naročnik sami pisali dodatke, ki širijo zmogljivosti platforme.
Imeli pa smo natanko mesec dni, v katerem smo morali vse namestiti, konfigurirati in uvesti avtomatizacijo.
Po besedah Sergeja, našega glavnega arhitekta, je za implementacijo vtičnega sistema potrebnih vsaj mesec dni.
Nismo imeli časa...
Rešitev je bila samo ena - pojdi do stranke in povej vse tako, kot je. Skupaj se pogovorite o premiku roka. In uspelo je. Dobili smo dodatna 2 tedna. Imeli so tudi svoje termine in interne obveznosti za prikaz rezultatov, vendar so imeli 2 rezervna tedna. Na koncu smo vse postavili na kocko. Nemogoče je bilo zamočiti. Poštenost in partnerski pristop sta se ponovno obrestovala.
Kot rezultat pilota je bilo pridobljenih več pomembnih tehničnih rezultatov in zaključkov:
Preizkusili smo novo funkcionalnost obdelave opozoril
Razporejeni sistem je začel pravilno prejemati opozorila od Prometheusa in jih združevati. Opozorila o problemu iz odjemalca Prometheus so letela vsakih 30 sekund (časovno združevanje ni omogočeno) in nas je zanimalo, ali bi jih bilo mogoče združiti v samem “dežniku”. Izkazalo se je, da je to mogoče - nastavitev obdelave opozoril v platformi izvaja skript. To omogoča implementacijo skoraj katere koli logike za njihovo obdelavo. V platformo smo že implementirali standardno logiko v obliki predlog - če ne želite ustvariti nečesa svojega, lahko uporabite že pripravljeno.
Vmesnik "sintetični sprožilec". Nastavitev obdelave opozoril iz povezanih nadzornih sistemov
Konstruirano stanje "zdravja" sistema
Na podlagi opozoril so bili ustvarjeni dogodki spremljanja, ki so vplivali na zdravje konfiguracijskih enot (CU). Implementiramo virsko-storitveni model (RSM), ki lahko uporablja ali notranji CMDB ali povezuje zunanjega - med pilotnim projektom naročnik ni povezal lastnega CMDB.
Vmesnik za delo z modelom vir-storitev. Pilot RSM.
No, pravzaprav ima odjemalec končno enoten nadzorni zaslon, kjer so vidni dogodki iz različnih sistemov. Trenutno sta na “dežnik” povezana dva sistema - Zabbix in Prometheus ter notranji nadzorni sistem same platforme.
Analitični vmesnik. Enotni nadzorni zaslon.
Uvedena avtomatizacija procesov
Spremljanje dogodkov je sprožilo zagon prednastavljenih dejanj - pošiljanje opozoril, izvajanje skriptov, registracija/obogatitev incidentov - slednje ni bilo preizkušeno s tem odjemalcem, ker v pilotnem projektu ni bilo integracije s servisno pisarno.
Vmesnik za nastavitve dejanj. Pošljite opozorila Slacku in znova zaženite strežnik.
Razširjena funkcionalnost izdelka
Ko smo razpravljali o skriptih za avtomatizacijo, je odjemalec zahteval podporo za bash in vmesnik, v katerem bi lahko te skripte priročno konfigurirali. Nova različica je naredila nekaj več (zmožnost pisanja polnih logičnih konstruktov v Lui s podporo za cURL, SSH in SNMP) in implementirala funkcionalnost, ki omogoča upravljanje življenjskega cikla skripta (ustvarjanje, urejanje, nadzor različic , brisanje in arhiviranje).
Vmesnik za delo s skripti za samodejno zdravljenje. Skript za ponovni zagon strežnika prek SSH.
Ključne ugotovitve
Med pilotom so bile ustvarjene tudi uporabniške zgodbe, ki izboljšujejo trenutno funkcionalnost in povečujejo vrednost za stranko, tukaj je nekaj izmed njih:
- implementirajte možnost posredovanja spremenljivk neposredno iz opozorila v skript za samodejno zdravljenje;
- dodajte avtorizacijo na platformo prek Active Directory.
In prejeli smo več globalnih izzivov - "zgraditi" izdelek z drugimi zmogljivostmi:
- samodejna konstrukcija modela virov in storitev, ki temelji na strojnem jeziku namesto pravil in agentov (verjetno glavni izziv zdaj);
- podpora za dodatne skriptne in logične jezike (in to bo JavaScript).
Po mojem mnenju, najbolj pomembna stvarTa pilot prikazuje dve stvari:
- Partnerstvo s stranko je ključ do učinkovitosti, ko se učinkovita komunikacija gradi na osnovi poštenosti in odprtosti, stranka pa postane del ekipe, ki v kratkem času dosega pomembne rezultate.
- V nobenem primeru ni treba "prilagajati" in graditi "bergel" - samo sistemske rešitve. Bolje je porabiti malo več časa, vendar narediti sistemsko rešitev, ki jo bodo uporabljali drugi naročniki. Mimogrede, to se je zgodilo, sistem vtičnikov in odprava odvisnosti od Azure sta zagotovila dodatno vrednost drugim strankam (pozdravljeni, zvezni zakon 152).
Vir: www.habr.com