U publikacijama na Habréu već sam pisao o svom iskustvu izgradnje partnerstva sa svojim timom ( govori o tome kako sastaviti ugovor o partnerstvu prilikom pokretanja novog posla da se posao ne bi raspao). A sada bih želeo da pričam o tome kako izgraditi partnerstvo sa klijentima, jer bez njih se ništa neće raspasti. Nadam se da će ovaj članak biti koristan startupima koji počinju da prodaju svoje proizvode velikim preduzećima.
Trenutno vodim startup pod nazivom MONQ Digital lab, gdje moj tim i ja razvijamo proizvod za automatizaciju procesa podrške i upravljanja korporativnim IT-om. Ulazak na tržište nije lak zadatak i krenuli smo uz malo domaće zadaće, prošli kroz tržišne stručnjake, naše partnere i izvršili segmentaciju tržišta. Glavno pitanje je bilo razumjeti “čije bolove možemo najbolje izliječiti?”
Banke su ušle u TOP 3 segmenta. I naravno, prvi na listi bili su Tinkoff i Sberbank. Kada smo posjetili stručnjake za bankarsko tržište, rekli su: uvedite svoj proizvod tamo i put do bankarskog tržišta će biti otvoren. Pokušali smo da uđemo i tamo i tamo, ali u Sberbanki nas je čekao neuspjeh, a momci iz Tinkoffa su se pokazali mnogo otvoreniji za produktivnu komunikaciju s ruskim startupima (možda zbog činjenice da je Sber u to vrijeme skoro milijardu naših zapadnih konkurenata). U roku od mjesec dana započeli smo pilot projekat. Kako se to dogodilo, čitajte dalje.
Dugi niz godina se bavimo pitanjima rada i praćenja, sada implementiramo naš proizvod u javnom sektoru, u osiguranju, u bankama, u telekom kompanijama, jedna implementacija je bila kod avio kompanije (prije projekta nismo ni mislim da je avijacija bila industrija zavisna od IT-a, a sada se zaista nadamo, uprkos COVID-u, da će se kompanija pojaviti i poletjeti).
Proizvod koji proizvodimo pripada poslovnom softveru, segmentu AIOps (vještačka inteligencija za IT operacije ili ITOps). Glavni ciljevi implementacije ovakvih sistema kao što je povećanje stepena zrelosti procesa u kompaniji:
- Gasite požare: identificirajte kvarove, očistite tok upozorenja od krhotina, dodijelite zadatke i incidente odgovornima;
- Povećati efikasnost IT usluge: smanjiti vrijeme za rješavanje incidenata, ukazati na uzroke kvarova, povećati transparentnost IT statusa;
- Povećajte poslovnu efikasnost: smanjite količinu ručnog rada, smanjite rizike, povećajte lojalnost kupaca.
Prema našem iskustvu, banke imaju sljedeće "muke" s praćenjem koje su zajedničke svim velikim IT infrastrukturama:
- “ko zna šta”: postoji mnogo tehničkih odjela, skoro svi imaju barem jedan sistem za praćenje, a većina ih ima više;
- „roj komaraca“ upozorenja: svaki sistem generiše stotine i njime bombarduje sve odgovorne (ponekad i između odeljenja). Teško je konstantno održavati fokus kontrole na svakom obavještenju zbog velikog broja;
- velike banke – lideri sektora žele ne samo da kontinuirano nadgledaju svoje sisteme, da znaju gdje ima kvarova, već i pravu magiju AI – da učine sisteme samonadzornim, samopredviđenim i samoispravljajućim.
Kada smo došli na prvi sastanak u Tinkoff, odmah nam je rečeno da nemaju problema sa praćenjem i da ih ništa ne boli, a glavno pitanje je bilo: „Šta možemo ponuditi onima koji već rade dobro?“
Razgovor je bio dug, razgovarali smo o tome kako se grade njihovi mikroservis, kako funkcionišu odjeli, koji su infrastrukturni problemi osjetljiviji, koji manje osjetljivi za korisnike, gdje su „slijepe tačke“, koji su im ciljevi i SLA.
Inače, SLA-ovi banke su zaista impresivni. Na primjer, problem dostupnosti mreže prioriteta 1 može potrajati samo nekoliko minuta da se riješi. Cijena greške i zastoja ovdje je, naravno, impresivna.
Kao rezultat toga, identifikovali smo nekoliko oblasti saradnje:
- prva faza je krovno praćenje kako bi se povećala brzina rješavanja incidenata
- druga faza je automatizacija procesa za smanjenje rizika i smanjenje troškova za skaliranje IT odjela.
Nekoliko „bijelih tačaka” moglo se obojiti u svijetle boje upozorenja samo obradom informacija iz nekoliko sistema za praćenje, jer je bilo nemoguće direktno uzeti metriku, također je bilo potrebno centralizirati podatke iz različitih sistema za praćenje na „jedan ekran” po redu da bi razumeli celokupnu sliku onoga što se dešavalo. “Kišobrani” su prikladni za ovaj zadatak i tada smo ispunili te zahtjeve.
Veoma važna stvar, po našem mišljenju, u odnosima sa klijentima je iskrenost. Nakon prvog razgovora i obračuna cijene licence, rečeno je da bi se, budući da je cijena toliko niska, možda isplatilo kupiti licencu odmah (u poređenju sa Dynatrace Klyuch-Astromom iz gornjeg članka o zelenoj banci, naš licenca košta ne trećinu milijarde, već 12 hiljada rubalja mjesečno za 1 gigabajt, za Sber bi to koštalo nekoliko puta jeftinije). Ali odmah smo im rekli šta imamo, a šta nemamo. Možda bi prodajni predstavnik velikog integratora mogao reći „da, možemo sve, naravno da kupimo našu licencu“, ali smo odlučili da sve svoje karte položimo na sto. U trenutku lansiranja, naša kutija nije imala integraciju sa Prometheusom, a nova verzija sa podsistemom za automatizaciju je trebala biti objavljena, ali je još nismo isporučili klijentima.
Pilot projekat je počeo, njegove granice su određene i dobili smo 2 mjeseca. Glavni zadaci su bili:
- pripremiti novu verziju platforme i implementirati je u infrastrukturu banke
- povezati 2 nadzorna sistema (Zabbix i Prometheus);
- slati obavještenja odgovornima u Slacku i putem SMS-a;
- pokrenite skripte za automatsko iscjeljivanje.
Prvi mjesec pilot projekta protekao je u pripremi nove verzije platforme u superbrzom načinu rada za potrebe pilot projekta. Nova verzija odmah uključuje integraciju sa Prometheusom i auto-iscjeljenje. Zahvaljujući našem razvojnom timu, nisu spavali nekoliko noći, ali su pustili ono što su obećali bez propuštanja rokova za druge ranije preuzete obaveze.
Dok smo postavljali pilot, naišli smo na novi problem koji bi mogao zatvoriti projekat prije roka: za slanje upozorenja instant messengerima i putem SMS-a, bile su nam potrebne dolazne i odlazne veze sa Microsoft Azure serverima (u to vrijeme koristili smo ovu platformu za slanje upozorenja u Slack) i eksternu uslugu slanja SMS-a. Ali u ovom projektu sigurnost je bila poseban fokus. U skladu sa politikom banke, takve „rupe“ se ni pod kojim okolnostima nisu mogle otvarati. Sve je moralo raditi iz zatvorene petlje. Ponuđeno nam je da koristimo API sopstvenih internih servisa koji šalju upozorenja u Slack i putem SMS-a, ali nismo imali priliku da povežemo takve servise van kutije.
Veče debate sa razvojnim timom završeno je uspešnom potragom za rešenjem. Preturajući po zaostatku, pronašli smo jedan zadatak za koji nikada nismo imali dovoljno vremena i prioriteta – kreiranje plug-in sistema kako bi implementacijski timovi ili klijent mogli sami pisati dodatke, proširujući mogućnosti platforme.
Ali ostalo nam je tačno mjesec dana, tokom kojeg smo morali sve instalirati, konfigurirati i implementirati automatizaciju.
Prema rečima Sergeja, našeg glavnog arhitekte, potrebno je najmanje mesec dana za implementaciju plug-in sistema.
nismo imali vremena...
Postojalo je samo jedno rješenje - otići do klijenta i reći sve kako je. Razgovarajte o promjeni roka zajedno. I uspjelo je. Dobili smo dodatne 2 sedmice. Imali su i svoje rokove i interne obaveze da pokažu rezultate, ali su imali 2 rezervne sedmice. Na kraju smo sve stavili na kocku. Bilo je nemoguće zabrljati. Iskrenost i partnerski pristup opet su se isplatili.
Kao rezultat pilota dobijeno je nekoliko važnih tehničkih rezultata i zaključaka:
Testirali smo novu funkcionalnost za obradu upozorenja
Raspoređeni sistem je počeo ispravno primati upozorenja od Prometeja i grupirati ih. Upozorenja o problemu od Prometheus klijenta su letjela svakih 30 sekundi (grupiranje po vremenu nije omogućeno), a mi smo se pitali da li bi ih bilo moguće grupisati u sam „kišobran“. Ispostavilo se da je to moguće - podešavanje obrade upozorenja na platformi implementirano je skriptom. Ovo omogućava implementaciju gotovo svake logike za njihovu obradu. Već smo implementirali standardnu logiku u platformu u obliku šablona - ako ne želite da smislite nešto svoje, možete koristiti gotov.
“Sintetički okidač” interfejs. Podešavanje obrade dojava sa povezanih sistema za praćenje
Konstruisano stanje „zdravlja“ sistema
Na osnovu upozorenja kreirani su događaji praćenja koji su uticali na zdravlje konfiguracionih jedinica (CU). Implementiramo resursno-servisni model (RSM), koji može koristiti ili interni CMDB ili povezati eksterni - tokom pilot projekta klijent nije povezao vlastiti CMDB.
Interfejs za rad sa modelom usluge resursa. Pilot RSM.
Pa, u stvari, klijent konačno ima jedan ekran za praćenje, na kojem su vidljivi događaji iz različitih sistema. Trenutno su na “kišobran” povezana dva sistema - Zabbix i Prometheus, te interni sistem za praćenje same platforme.
Sučelje analitike. Jedan ekran za praćenje.
Pokrenuta automatizacija procesa
Praćenje događaja je pokrenulo pokretanje unapred konfigurisanih radnji - slanje upozorenja, pokretanje skripti, registrovanje/obogaćivanje incidenata - ovo poslednje nije isprobano sa ovim konkretnim klijentom, jer u pilot projektu nije bilo integracije sa servisnom službom.
Interfejs postavki akcije. Pošaljite upozorenja u Slack i ponovo pokrenite server.
Proširena funkcionalnost proizvoda
Kada se raspravljalo o skriptama za automatizaciju, klijent je tražio podršku za bash i interfejs u kojem bi se ove skripte mogle pogodno konfigurisati. Nova verzija je učinila nešto više (mogućnost pisanja punopravnih logičkih konstrukcija u Lua uz podršku za cURL, SSH i SNMP) i implementirala funkcionalnost koja vam omogućava da upravljate životnim ciklusom skripte (kreiranje, uređivanje, kontrola verzija , brisanje i arhiviranje).
Interfejs za rad sa skriptama za autohealing. Skripta za ponovno pokretanje servera putem SSH-a.
Glavni nalazi
Tokom pilotiranja kreirane su i korisničke priče koje poboljšavaju trenutnu funkcionalnost i povećavaju vrijednost za klijenta, evo nekih od njih:
- implementirati mogućnost prosljeđivanja varijabli direktno iz upozorenja u skriptu za automatsko iscjeljivanje;
- dodajte autorizaciju platformi putem Active Directory-a.
I dobili smo više globalnih izazova - da "nadogradimo" proizvod drugim mogućnostima:
- automatska konstrukcija modela usluge resursa zasnovanog na ML, a ne na pravilima i agentima (verovatno glavni izazov sada);
- podrška za dodatne jezike za skriptiranje i logiku (a to će biti JavaScript).
Po mom mišljenju najvažnijiOno što ovaj pilot pokazuje su dvije stvari:
- Partnerstvo sa klijentom je ključ efikasnosti, kada se efektivna komunikacija gradi na osnovu iskrenosti i otvorenosti, a klijent postaje deo tima koji postiže značajne rezultate za kratko vreme.
- Ni u kom slučaju nije potrebno „prilagođavati“ i graditi „štake“ – samo sistemska rješenja. Bolje je potrošiti malo više vremena, ali napraviti sistemsko rješenje koje će koristiti i drugi klijenti. Inače, evo šta se dogodilo, sistem dodataka i eliminacija zavisnosti od Azurea dali su dodatnu vrednost drugim klijentima (zdravo, Federalni zakon 152).
izvor: www.habr.com