HabrΓ©-ri buruzko argitalpenetan, nire taldearekin lankidetzak eraikitzeko esperientziari buruz idatzi nuen jada ( negozio berri bat abiaraztean lankidetza-hitzarmena nola egin hitz egiten du, negozioa apurtu ez dadin). Eta orain bezeroekin lankidetza nola eraikitzeari buruz hitz egin nahiko nuke, haiek gabe ez baita ezer eroriko. Espero dut artikulu hau baliagarria izatea euren produktua enpresa handiei saltzen hasten diren startupentzat.
Une honetan MONQ Digital lab izeneko startup baten buru nago, non nire taldea eta biok produktu bat garatzen ari garen IT korporatiboari eusteko eta ustiatzeko prozesuak automatizatzeko. Merkatuan sartzea ez da lan erraza eta etxerako lantxo batekin hasi ginen, merkatuko adituen, gure bazkideen bitartez eta merkatuaren segmentazioa egin genuen. Galdera nagusia "noren minak senda ditzakegu hobekien?" ulertzea zen.
Bankuak TOP 3 segmentuetan sartu ziren. Eta noski, zerrendako lehenak Tinkoff eta Sberbank izan ziren. Banku-merkatuko adituak bisitatu genituenean, esan ziguten: aurkeztu zure produktua bertan, eta banku-merkaturako bidea irekiko da. Han eta han sartzen saiatu ginen, baina porrota itxaroten gintuen Sberbanken, eta Tinkoff-eko mutilak askoz irekiagoak ziren errusiar startupekin komunikazio produktiborako (agian garai hartan Sber-ek zuelako). gure Mendebaldeko lehiakideetatik ia mila milioi). Hilabete barru proiektu pilotu bat hasi genuen. Nola gertatu den, irakurri.
Urte asko daramatzagu funtzionamendu eta monitorizazio gaiak jorratzen, orain gure produktua sektore publikoan inplementatzen ari gara, aseguruetan, bankuetan, telekomunikazio enpresetan, inplementazio bat aire konpainia batekin zen (proiektua baino lehen, ez genuen uste abiazioa IT-aren mendeko industria zela, eta orain benetan espero dugu, COVID-en arren, konpainia sortu eta aireratzea).
Egiten dugun produktua enpresa-softwareari dagokio, AIOps (Artificial Intelligence for IT Operations, edo ITOps) segmentuari. Enpresan prozesuen heldutasun maila handitzen ari diren sistemak ezartzearen helburu nagusiak:
- Suteak itzali: hutsegiteak identifikatu, hondakinetatik abisu-jarioa garbitu, arduradunei zereginak eta gorabeherak esleitu;
- Informatika-zerbitzuaren eraginkortasuna areagotzea: gorabeherak konpontzeko denbora murriztea, hutsegiteen arrazoiak adierazi, informatikako egoeraren gardentasuna areagotu;
- Negozioaren eraginkortasuna areagotu: eskuzko lan kopurua murriztu, arriskuak murriztu, bezeroen leialtasuna areagotu.
Gure esperientziaren arabera, bankuek honako "minak" dituzte monitorizazioaren azpiegitura informatiko handi guztiekin batera:
- βnork daki zerβ: sail tekniko asko daude, ia denek dute gutxienez jarraipen sistema bat, eta gehienek bat baino gehiago dituzte;
- "eltxo-sorta" alertak: sistema bakoitzak ehunka sortzen ditu eta haiekin bonbardatzen ditu arduradun guztiak (batzuetan sailen artean ere bai). Zaila da jakinarazpen bakoitzaren kontrol-fokua etengabe mantentzea; haien premia eta garrantzia berdindu egiten da kopuru handia dela eta;
- banku handiek -sektoreko buruzagiek beren sistemak etengabe kontrolatzeaz gain, akatsak non dauden jakitea nahi dute, baita AIren benetako magia ere - sistemak autokontrolatu, autoiragartzea eta zuzentzea.
Tinkoff-eko lehen bilerara etorri ginenean, berehala esan ziguten ez zutela inolako arazorik monitorizazioan eta ezerk ez ziela minik egiten, eta galdera nagusia hauxe zen: βZer eskain diezaiekegu dagoeneko ondo daudenei?β.
Elkarrizketa luzea izan zen, haien mikrozerbitzuak nola eraikitzen diren, sailek nola funtzionatzen duten, zein azpiegitura-arazo diren sentikorragoak, zeintzuk diren erabiltzaileentzat hain sentikorrak, non dauden "puntu itsuak" eta zeintzuk diren haien helburuak eta SLA-ak.
Bide batez, bankuaren SLA-ak benetan ikusgarriak dira. Adibidez, XNUMX. lehentasuneko sarearen erabilgarritasun-intzidentzia bat minutu batzuk baino ez dira behar konpontzeko. Hemen akatsen eta geldialdiaren kostua, noski, ikusgarria da.
Ondorioz, hainbat lankidetza-esparru identifikatu ditugu:
- lehen fasea aterkiaren jarraipena da, gertakarien ebazpenaren abiadura handitzeko
- bigarren fasea prozesuen automatizazioa da, arriskuak murrizteko eta IT saila eskalatzeko kostuak murrizteko.
Hainbat "puntu zuri" alerten kolore distiratsuekin margo zitezkeen monitorizazio-sistemetako informazioa prozesatuz soilik, ezinezkoa baita neurriak zuzenean hartzea; monitorizazio-sistema ezberdinetako datuak "pantaila bakarrean" zentralizatzea ere beharrezkoa zen. gertatzen ari zenaren irudi orokorra ulertzeko. "Aterkiak" egokiak dira zeregin honetarako eta baldintza hauek bete genituen orduan.
Oso gauza garrantzitsua, gure ustez, bezeroekiko harremanetan zintzotasuna da. Lizentziaren kostuaren lehen elkarrizketa eta kalkuluaren ondoren, esan zen kostua hain baxua denez, baliteke lizentzia bat berehala erostea merezi zuela (banku berdeari buruzko goiko artikuluan Dynatrace Klyuch-Astrom-ekin alderatuta, gure lizentzia ez da mila milioiren herena kostatzen, baina 12 mila errublo hilean gigabyte 1, Sberrentzat hainbat aldiz merkeagoa izango litzateke). Baina berehala esan genien zer dugun eta zer ez. Agian integratzaile handi bateko salmenta-ordezkariak esan lezake "bai, dena egin dezakegu, noski gure lizentzia erosi", baina gure karta guztiak mahai gainean jartzea erabaki genuen. Abian jarri zenean, gure kutxak ez zuen Prometheus-ekin integraziorik, eta automatizazio azpisistema duen bertsio berri bat kaleratzear zegoen, baina oraindik ez diegu bezeroei bidali.
Proiektu pilotua hasi zen, bere mugak zehaztu ziren eta 2 hilabete eman ziguten. Eginkizun nagusiak hauek izan ziren:
- plataformaren bertsio berri bat prestatu eta bankuaren azpiegituretan zabaldu
- konektatu 2 monitorizazio sistema (Zabbix eta Prometheus);
- bidali jakinarazpenak arduradunei Slack-en eta SMS bidez;
- exekutatu autosendatze scriptak.
Proiektu pilotuaren lehen hilabetea plataformaren bertsio berri bat prestatzen eman zen, modu oso azkarrean, proiektu pilotuaren beharretarako. Bertsio berriak berehala barne hartzen ditu Prometheus-ekin integrazioa eta sendatze automatikoa. Gure garapen-taldeari esker, ez zuten lo egin hainbat gau, baina agindutakoa kaleratu zuten, aurretik hartutako beste konpromiso batzuen epeak galdu gabe.
Pilotua konfiguratzen ari ginela, arazo berri bat topatu dugu, proiektua aurreikusi baino lehen itxi zezakeena: berehalako mezulariei eta SMS bidez alertak bidaltzeko, Microsoft Azure zerbitzarietarako sarrerako eta irteerako konexioak behar genituen (orduan plataforma hau erabiltzen genuen. alertak Slack-era bidaltzeko) eta kanpoko bidalketa zerbitzuko SMS bat. Baina proiektu honetan segurtasuna zen arreta berezia. Bankuaren politikaren arabera, "zulo" horiek ezin ziren inola ere ireki. Dena begizta itxi batetik funtzionatu behar zuen. Slack-era eta SMS bidez alertak bidaltzen dituzten gure barne-zerbitzuen APIa erabiltzea proposatu ziguten, baina ez genuen aukerarik izan horrelako zerbitzuak kutxatik kanpo konektatzeko.
Garapen taldearekin eztabaidatutako arratsalde bat irtenbide baten bilaketa arrakastatsu batekin amaitu zen. Atzerako lana arakatu ondoren, inoiz ez genuen denbora eta lehentasun nahikoa izan dugun zeregin bat aurkitu dugu: plug-in-sistema bat sortzea, inplementazio-taldeek edo bezeroak beraiek gehigarriak idatzi ahal izateko, plataformaren gaitasunak zabalduz.
Baina zehatz-mehatz hilabete geratzen zitzaigun, eta horretan dena instalatu, konfiguratu eta automatizazioa zabaldu behar izan genuen.
Sergei gure arkitekto buruaren arabera, gutxienez hilabete behar da plug-in sistema ezartzeko.
Ez genuen denborarik izan...
Irtenbide bakarra zegoen: joan bezeroarengana eta kontatu dena dagoen bezala. Elkarrekin eztabaidatu epe-aldaketa. Eta funtzionatu zuen. 2 aste gehiago eman zizkiguten. Emaitzak erakusteko euren epeak eta barne betebeharrak ere bazituzten, baina 2 erreserba aste zituzten. Azkenean, dena jarri dugu martxan. Ezinezkoa zen nahastea. Zintzotasunak eta lankidetza-ikuspegiak bere fruituak eman zituzten berriro.
Pilotuaren ondorioz, hainbat emaitza eta ondorio tekniko garrantzitsu lortu ziren:
Alertak prozesatzeko funtzionalitate berria probatu dugu
Inplementatutako sistema Prometheus-en alertak behar bezala jasotzen eta taldekatzen hasi zen. Prometheus bezeroaren arazoari buruzko alertak 30 segundoro hegan egiten ziren (denboraren arabera taldekatzea ez dago gaituta), eta "aterkian" bertan biltzea posible ote zen galdetzen genuen. Posible dela ikusi da - plataforman alertak prozesatzea script baten bidez ezartzen da. Horrek prozesatzeko ia edozein logika ezartzea posible egiten du. Dagoeneko logika estandarra ezarri dugu plataforman txantiloi moduan - ez baduzu zeure zerbait asmatu nahi, prest egindako bat erabil dezakezu.
"Abiarazle sintetikoa" interfazea. Konektatutako monitorizazio-sistemetatik abisuen tratamendua konfiguratzea
Sistemaren βosasunβ egoera eraiki
Alertetan oinarrituta, konfigurazio-unitateen (CU) osasunean eragina duten monitorizazio-gertaerak sortu ziren. Baliabide-zerbitzuaren eredua (RSM) inplementatzen ari gara, barneko CMDB bat erabil dezakeena edo kanpoko bat konektatu dezakeena - proiektu pilotuan bezeroak ez zuen bere CMDB konektatu.
Baliabide-zerbitzu ereduarekin lan egiteko interfazea. RSM pilotua.
Beno, egia esan, bezeroak azkenik monitorizazio pantaila bakarra du, non sistema ezberdinetako gertaerak ikusgai dauden. Gaur egun, bi sistema "aterkiari" konektatuta daude: Zabbix eta Prometheus, eta plataformaren barne-kontrol sistema bat.
Analytics interfazea. Jarraipen pantaila bakarra.
Prozesuen automatizazioa martxan jarri da
Gertaeren jarraipenak aurrez konfiguratutako ekintzak abiarazi zituen - alertak bidaltzea, script-ak exekutatzen, gertakariak erregistratzea/aberastea - azken hori ez zen bezero zehatz honekin probatu, zeren proiektu pilotuan ez zegoen zerbitzuen mahaiarekin integraziorik.
Ekintza ezarpenen interfazea. Bidali alertak Slack-era eta berrabiarazi zerbitzaria.
Produktuaren funtzionaltasuna hedatua
Automatizazio-scriptei buruz hitz egitean, bezeroak bash-en laguntza eta script horiek eroso konfiguratu ahal izateko interfaze bat eskatu zuen. Bertsio berriak apur bat gehiago egin du (lua-n eraikuntza logiko osoak idazteko gaitasuna cURL, SSH eta SNMPrako laguntzarekin) eta script baten bizi-zikloa kudeatzeko aukera ematen duen funtzionaltasuna ezarri du (sortu, editatu, bertsioen kontrola). , ezabatu eta artxibatu).
Autosendatzeko scriptekin lan egiteko interfazea. Zerbitzaria berrabiarazi script-a SSH bidez.
Funtsezko aurkikuntzak
Pilotuan zehar, erabiltzaileen istorioak ere sortu ziren, egungo funtzionaltasuna hobetzen eta bezeroarentzako balioa areagotzen dutenak, hona hemen horietako batzuk:
- inplementatu aldagaiak zuzenean alertatik autosendatze scriptera birbidaltzeko gaitasuna;
- gehitu baimena plataformari Active Directory bidez.
Eta erronka globalagoak jaso genituen: produktua beste gaitasun batzuekin "eraikitzea":
- MLn oinarritutako baliabide-zerbitzu eredu baten eraikuntza automatikoa, arauak eta eragileak baino (ziurrenik orain erronka nagusia);
- scripting eta hizkuntza logiko gehigarrietarako laguntza (eta hau JavaScript izango da).
Nire ustez garrantzitsuenaPilotu honek erakusten duena bi gauza dira:
- Bezeroarekiko lankidetzak eraginkortasunaren gakoa dira, komunikazio eraginkorra zintzotasunean eta irekitasunean oinarrituta eraikitzen denean, eta bezeroa denbora laburrean emaitza esanguratsuak lortzen dituen talde baten parte bihurtzen denean.
- Inola ere ez da beharrezkoa "pertsonalizatzea" eta "makuluak" eraikitzea - ββsistema soluzioak soilik. Hobe da denbora pixka bat gehiago ematea, baina beste bezeroek erabiliko duten sistema-irtenbide bat egitea. Bide batez, hori gertatu zen, plugin sistemak eta Azurerekiko menpekotasuna ezabatzeak balio gehigarria eman zien beste bezeroei (kaixo, 152 Lege Federala).
Iturria: www.habr.com