In publikasies oor Habré het ek reeds geskryf oor my ervaring van die bou van vennootskappe met my span ( praat oor hoe om 'n vennootskapsooreenkoms op te stel wanneer 'n nuwe besigheid begin word sodat die besigheid nie uitmekaar val nie). En nou wil ek praat oor hoe om vennootskappe met kliënte te bou, want sonder hulle sal daar niks wees om uitmekaar te val nie. Ek hoop dat hierdie artikel nuttig sal wees vir beginners wat hul produk aan groot besighede begin verkoop.
Ek is tans aan die hoof van 'n opstart genaamd MONQ Digital lab, waar ek en my span 'n produk ontwikkel vir die outomatisering van die prosesse van ondersteuning en bedryf van korporatiewe IT. Om die mark te betree is nie 'n maklike taak nie en ons het met 'n bietjie huiswerk begin, deur markkundiges, ons vennote gegaan en marksegmentering uitgevoer. Die hoofvraag was om te verstaan "wie se pyne kan ons die beste genees?"
Banke het dit in die TOP 3 segmente gemaak. En natuurlik, die eerste op die lys was Tinkoff en Sberbank. Toe ons bankmarkkundiges besoek het, het hulle gesê: stel jou produk daar bekend, en die pad na die bankmark sal oop wees. Ons het probeer om beide daar en daar in te gaan, maar mislukking het op ons gewag by Sberbank, en die ouens van Tinkoff was baie meer oop vir produktiewe kommunikasie met Russiese beginners (miskien as gevolg van die feit dat Sber op daardie tydstip byna 'n miljard van ons Westerse mededingers). Binne 'n maand het ons 'n loodsprojek begin. Hoe dit gebeur het, lees verder.
Ons het al baie jare te doen met kwessies van bedryf en monitering, nou implementeer ons ons produk in die openbare sektor, in versekering, in banke, in telekommunikasiemaatskappye, een implementering was met 'n lugredery (voor die projek het ons nie eers dink dat lugvaart so 'n IT-afhanklike bedryf was, en nou hoop ons regtig, ten spyte van COVID, dat die maatskappy sal opduik en opstyg).
Die produk wat ons maak behoort aan ondernemingsagteware, die AIOps (Artificial Intelligence for IT Operations, of ITOps) segment. Die hoofdoelwitte van die implementering van sulke stelsels soos die vlak van prosesvolwassenheid in die maatskappy verhoog:
- Blus vure: identifiseer mislukkings, verwyder die stroom waarskuwings van puin, ken take en insidente toe aan diegene wat verantwoordelik is;
- Verhoog die doeltreffendheid van die IT-diens: verminder die tyd om voorvalle op te los, dui die oorsake van mislukkings aan, verhoog die deursigtigheid van die IT-status;
- Verhoog besigheidsdoeltreffendheid: verminder die hoeveelheid handearbeid, verminder risiko's, verhoog kliëntelojaliteit.
In ons ervaring het banke die volgende "pyne" met monitering in gemeen met alle groot IT-infrastruktuur:
- "wie weet wat": daar is baie tegniese afdelings, byna almal het ten minste een moniteringstelsel, en die meeste het meer as een;
- "muskiet swerm" van waarskuwings: elke stelsel genereer honderde en bombardeer almal wat verantwoordelik is met hulle (soms ook tussen departemente). Dit is moeilik om voortdurend die fokus van beheer op elke kennisgewing te handhaaf; hul dringendheid en belangrikheid word gelyk aan die groot aantal;
- groot banke - sektorleiers wil nie net hul stelsels voortdurend monitor, weet waar daar mislukkings is nie, maar ook die ware magie van KI - om die stelsels selfmonitor, selfvoorspel en selfkorrek te maak.
Toe ons by die eerste vergadering by Tinkoff kom, is ons dadelik meegedeel dat hulle geen probleme met monitering het nie en niks het hulle seergemaak nie, en die hoofvraag was: "Wat kan ons bied vir diegene wat reeds goed doen?"
Die gesprek was lank, ons het bespreek hoe hul mikrodienste gebou word, hoe departemente werk, watter infrastruktuurprobleme meer sensitief is, watter minder sensitief is vir gebruikers, waar is die “blinde kolle”, en wat is hul doelwitte en SLA’s.
Terloops, die bank se SLA's is regtig indrukwekkend. Byvoorbeeld, 'n prioriteit XNUMX-netwerkbeskikbaarheidvoorval kan dalk net 'n paar minute neem om op te los. Die koste van foute en stilstand hier is natuurlik indrukwekkend.
As gevolg hiervan het ons verskeie areas van samewerking geïdentifiseer:
- die eerste fase is sambreelmonitering om die spoed van voorvalresolusie te verhoog
- die tweede fase is proses-outomatisering om risiko's te verminder en koste vir die skaal van die IT-afdeling te verminder.
Verskeie "wit kolle" kon slegs in die helder kleure van waarskuwings geverf word deur inligting van verskeie moniteringstelsels te verwerk, aangesien dit onmoontlik was om direk metrieke te neem; dit was ook nodig om data van verskillende moniteringstelsels na "een skerm" te sentraliseer in volgorde om die geheelbeeld van wat gebeur het te verstaan. “Sambrele” is geskik vir hierdie taak en ons het toe aan hierdie vereistes voldoen.
'n Baie belangrike ding, na ons mening, in verhoudings met kliënte is eerlikheid. Na die eerste gesprek en berekening van die koste van die lisensie, is gesê dat aangesien die koste so laag is, dit dalk die moeite werd kan wees om dadelik 'n lisensie te koop (in vergelyking met Dynatrace Klyuch-Astrom uit die artikel hierbo oor die groen bank, ons lisensie kos nie 'n derde van 'n miljard nie, maar 12 duisend roebels per maand vir 1 gigagreep, vir Sber sou dit 'n paar keer goedkoper kos). Maar ons het dadelik vir hulle gesê wat ons het en wat ons nie het nie. Miskien kan 'n verkoopsverteenwoordiger van 'n groot integreerder sê "ja, ons kan alles doen, koop natuurlik ons lisensie," maar ons het besluit om al ons kaarte op die tafel te lê. Ten tyde van die bekendstelling het ons boks nie integrasie met Prometheus gehad nie, en 'n nuwe weergawe met 'n outomatiseringsubstelsel was op die punt om vrygestel te word, maar ons het dit nog nie aan kliënte gestuur nie.
Die loodsprojek het begin, die grense daarvan is bepaal en ons het 2 maande gekry. Die hooftake was:
- berei 'n nuwe weergawe van die platform voor en ontplooi dit in die bank se infrastruktuur
- verbind 2 moniteringstelsels (Zabbix en Prometheus);
- stuur kennisgewings aan diegene wat verantwoordelik is in Slack en per SMS;
- voer outo-genesingsskrifte uit.
Die eerste maand van die loodsprojek is bestee aan die voorbereiding van 'n nuwe weergawe van die platform in supervinnige modus vir die behoeftes van die loodsprojek. Die nuwe weergawe sluit onmiddellik integrasie met Prometheus en outo-genesing in. Danksy ons ontwikkelingspan het hulle vir 'n hele paar nagte nie geslaap nie, maar vrygestel wat hulle belowe het sonder om die sperdatums vir ander voorheen gemaak verpligtinge te mis.
Terwyl ons die loods opgestel het, het ons 'n nuwe probleem teëgekom wat die projek voor skedule kon sluit: om waarskuwings na kitsboodskappers en per SMS te stuur, het ons inkomende en uitgaande verbindings na Microsoft Azure-bedieners nodig gehad (ons het destyds hierdie platform gebruik om waarskuwings na Slack te stuur) en 'n eksterne stuurdiens-SMS. Maar in hierdie projek was veiligheid 'n besondere fokus. Ingevolge die bank se beleid kon sulke “gate” onder geen omstandighede oopgemaak word nie. Alles moes uit 'n geslote lus werk. Ons is aangebied om die API van ons eie interne dienste te gebruik wat waarskuwings na Slack en per SMS stuur, maar ons het nie die geleentheid gehad om sulke dienste uit die boks te koppel nie.
'n Aand van debat met die ontwikkelingspan het geëindig met 'n suksesvolle soeke na 'n oplossing. Nadat ons deur die agterstand gesoek het, het ons een taak gekry waarvoor ons nooit genoeg tyd en prioriteit gehad het nie - om 'n inpropstelsel te skep sodat die implementeringspanne of die kliënt self byvoegings kan skryf, wat die vermoëns van die platform uitbrei.
Maar ons het presies 'n maand oor gehad, waartydens ons alles moes installeer, opstel en outomatisering moes ontplooi.
Volgens Sergei, ons hoofargitek, neem dit minstens 'n maand om die inpropstelsel te implementeer.
Ons het nie tyd gehad nie...
Daar was net een oplossing – gaan na die kliënt en vertel alles soos dit is. Bespreek die spertydverskuiwing saam. En dit het gewerk. Ons het 'n ekstra 2 weke gekry. Hulle het ook hul eie sperdatums en interne verpligtinge gehad om resultate te wys, maar hulle het 2 reserweweke gehad. Op die ou end sit ons alles op die spel. Dit was onmoontlik om te mors. Eerlikheid en 'n vennootskapbenadering het weer vrugte afgewerp.
As gevolg van die loods is verskeie belangrike tegniese resultate en gevolgtrekkings verkry:
Ons het die nuwe funksionaliteit vir die verwerking van waarskuwings getoets
Die ontplooide stelsel het begin om waarskuwings van Prometheus korrek te ontvang en hulle te groepeer. Waarskuwings oor die probleem van die Prometheus-kliënt het elke 30 sekondes gevlieg (groepering volgens tyd is nie geaktiveer nie), en ons het gewonder of dit moontlik sou wees om hulle in die "sambreel" self te groepeer. Dit het geblyk dat dit moontlik is - die opstel van die verwerking van waarskuwings in die platform word deur 'n skrif geïmplementeer. Dit maak dit moontlik om byna enige logika vir die verwerking daarvan te implementeer. Ons het reeds standaardlogika in die platform geïmplementeer in die vorm van sjablone - as jy nie met iets van jou eie vorendag wil kom nie, kan jy 'n klaargemaakte een gebruik.
"Sintetiese sneller"-koppelvlak. Opstel van verwerking van waarskuwings vanaf gekoppelde moniteringstelsels
Konstrueer die toestand van "gesondheid" van die stelsel
Gebaseer op waarskuwings, is moniteringsgebeurtenisse geskep wat die gesondheid van konfigurasie-eenhede (CU's) beïnvloed het. Ons implementeer 'n hulpbrondiensmodel (RSM), wat óf 'n interne CMDB of 'n eksterne een kan gebruik - tydens die loodsprojek het die kliënt nie sy eie CMDB gekoppel nie.
Koppelvlak om met die hulpbrondiensmodel te werk. Vlieënier RSM.
Om die waarheid te sê, die kliënt het uiteindelik 'n enkele moniteringsskerm, waar gebeurtenisse van verskillende stelsels sigbaar is. Tans is twee stelsels aan die "sambreel" gekoppel - Zabbix en Prometheus, en 'n interne moniteringstelsel van die platform self.
Analytics-koppelvlak. Enkele moniteringsskerm.
Prosesoutomatisering van stapel gestuur
Moniteringsgebeurtenisse het die bekendstelling van vooraf-gekonfigureerde aksies veroorsaak - die stuur van waarskuwings, die uitvoer van skrifte, registrasie/verryking van voorvalle - laasgenoemde is nie met hierdie spesifieke kliënt probeer nie, omdat in die loodsprojek was daar geen integrasie met die dienstoonbank nie.
Aksie instellings koppelvlak. Stuur waarskuwings na Slack en herlaai die bediener.
Uitgebreide produkfunksionaliteit
Wanneer outomatiseringsskrifte bespreek word, het die kliënt gevra vir bash-ondersteuning en 'n koppelvlak waarin hierdie skrifte gerieflik gekonfigureer kan word. Die nuwe weergawe het 'n bietjie meer gedoen (die vermoë om volwaardige logiese konstrukte in Lua te skryf met ondersteuning vir cURL, SSH en SNMP) en funksionaliteit geïmplementeer wat jou toelaat om die lewensiklus van 'n skrip te bestuur (skep, redigeer, weergawebeheer , skrap en argiveer).
Koppelvlak om met outo-genesingsskrifte te werk. Bediener herlaai skrip via SSH.
Sleutelbevindinge
Tydens die loods is gebruikersstories ook geskep wat die huidige funksionaliteit verbeter en waarde vir die kliënt verhoog, hier is 'n paar daarvan:
- die vermoë te implementeer om veranderlikes direk vanaf die waarskuwing na die outo-genesingsskrif aan te stuur;
- voeg magtiging by die platform via Active Directory.
En ons het meer wêreldwye uitdagings ontvang - om die produk met ander vermoëns te "opbou":
- outomatiese konstruksie van 'n hulpbrondiensmodel gebaseer op ML, eerder as reëls en agente (waarskynlik die grootste uitdaging nou);
- ondersteuning vir bykomende skrif- en logiese tale (en dit sal JavaScript wees).
In my mening, die belangriksteWat hierdie loods wys is twee dinge:
- Vennootskappe met die kliënt is die sleutel tot effektiwiteit, wanneer effektiewe kommunikasie gebou word op grond van eerlikheid en openheid, en die kliënt deel word van 'n span wat beduidende resultate in 'n kort tyd behaal.
- Dit is onder geen omstandighede nodig om “krukke” te “pasmaak” en te bou nie – slegs stelseloplossings. Dit is beter om 'n bietjie meer tyd te spandeer, maar maak 'n stelseloplossing wat deur ander kliënte gebruik sal word. Terloops, dit is wat gebeur het, die inpropstelsel en die uitskakeling van afhanklikheid van Azure het bykomende waarde aan ander kliënte verskaf (hallo, Federale Wet 152).
Bron: will.com