V publikacích o Habrém jsem již psal o svých zkušenostech s budováním partnerství s mým týmem ( hovoří o tom, jak sepsat společenskou smlouvu při zahájení nového podnikání, aby se podnikání nerozpadlo). A teď bych chtěl mluvit o tom, jak budovat partnerství s klienty, protože bez nich nebude nic, co by se rozpadlo. Doufám, že tento článek bude užitečný pro startupy, které začínají prodávat svůj produkt velkým podnikům.
V současné době vedu startup s názvem MONQ Digital lab, kde s týmem vyvíjíme produkt pro automatizaci procesů podpory a provozu firemního IT. Vstup na trh není snadný úkol a začali jsme malým domácím úkolem, prošli odborníky na trh, našimi partnery a provedli segmentaci trhu. Hlavní otázkou bylo pochopit, „čí bolesti můžeme nejlépe vyléčit?
Banky se dostaly do TOP 3 segmentů. A samozřejmě první na seznamu byly Tinkoff a Sberbank. Když jsme navštívili odborníky na bankovní trh, řekli: představte tam svůj produkt a cesta na bankovní trh bude otevřená. Zkoušeli jsme vstoupit tam i tam, ale ve Sberbank nás čekal neúspěch a kluci z Tinkoff se ukázali být mnohem otevřenější produktivní komunikaci s ruskými startupy (možná i díky tomu, že Sber v té době téměř miliarda našich západních konkurentů). Během měsíce jsme zahájili pilotní projekt. Jak se to stalo, čtěte dál.
Problematikou provozu a monitoringu se zabýváme řadu let, nyní implementujeme náš produkt ve veřejném sektoru, v pojišťovnictví, v bankách, v telekomunikačních společnostech, jedna implementace byla u letecké společnosti (před projektem jsme Myslíme si, že letectví bylo odvětví závislé na IT, a teď opravdu doufáme, že navzdory COVIDu společnost vznikne a vzlétne).
Produkt, který vyrábíme, patří do podnikového softwaru, segmentu AIOps (Artificial Intelligence for IT Operations neboli ITOps). Hlavní cíle implementace takových systémů, protože úroveň vyspělosti procesů ve společnosti se zvyšuje:
- Haste požáry: identifikujte poruchy, odstraňte proud výstrah od trosek, přidělujte úkoly a incidenty odpovědným osobám;
- Zvýšit efektivitu IT služby: snížit čas na řešení incidentů, označit příčiny poruch, zvýšit transparentnost stavu IT;
- Zvyšte efektivitu podnikání: snižte množství manuální práce, snižte rizika, zvyšte loajalitu zákazníků.
Podle našich zkušeností mají banky s monitorováním společné se všemi velkými IT infrastrukturami následující „bolestky“:
- „kdo ví co“: existuje mnoho technických oddělení, téměř každý má alespoň jeden monitorovací systém a většina jich má více;
- „komáří roj“ výstrah: každý systém generuje stovky a bombarduje jimi všechny odpovědné (někdy také mezi odděleními). Je obtížné neustále udržovat zaměření kontroly na každé oznámení, jejich naléhavost a důležitost je vzhledem k velkému počtu vyrovnaná;
- velké banky – sektoroví lídři chtějí nejen neustále monitorovat své systémy, vědět, kde dochází k poruchám, ale také skutečné kouzlo umělé inteligence – zajistit, aby se systémy samy monitorovaly, samy predikovaly a samy opravovaly.
Když jsme přišli na první schůzku v Tinkoffu, hned nám bylo řečeno, že s monitorováním nemají problémy a nic je nebolí, a hlavní otázka zněla: „Co můžeme nabídnout těm, kterým se již daří?“
Konverzace byla dlouhá, diskutovali jsme o tom, jak se budují jejich mikroslužby, jak fungují oddělení, které problémy s infrastrukturou jsou citlivější, které méně citlivé pro uživatele, kde jsou „slepá místa“ a jaké jsou jejich cíle a SLA.
Mimochodem, SLA banky jsou opravdu působivé. Například řešení incidentu s dostupností sítě s prioritou XNUMX může trvat jen několik minut. Náklady na chyby a prostoje jsou zde samozřejmě působivé.
V důsledku toho jsme identifikovali několik oblastí spolupráce:
- první fází je zastřešující monitorování pro zvýšení rychlosti řešení incidentů
- druhou fází je automatizace procesů pro snížení rizik a snížení nákladů na škálování IT oddělení.
Několik „bílých míst“ bylo možné vybarvit jasnými barvami výstrah pouze zpracováním informací z několika monitorovacích systémů, protože nebylo možné přímo brát metriky; bylo také nutné centralizovat data z různých monitorovacích systémů na „jednu obrazovku“, aby pochopit celkový obraz toho, co se dělo. Pro tento úkol jsou vhodné „deštníky“ a tyto požadavky jsme tehdy splnili.
Velmi důležitou věcí ve vztazích s klienty je podle nás upřímnost. Po prvním rozhovoru a propočtu nákladů na licenci zaznělo, že vzhledem k tomu, že náklady jsou tak nízké, možná by stálo za to zakoupit si licenci hned (v porovnání s Dynatrace Klyuch-Astrom z výše uvedeného článku o zelené bance, naše licence nestojí třetinu miliardy, ale 12 tisíc rublů měsíčně za 1 gigabajt, pro Sber by to stálo několikrát levnější). Ale hned jsme jim řekli, co máme a co ne. Možná by obchodní zástupce velkého integrátora mohl říci „ano, můžeme všechno, samozřejmě koupit naši licenci“, ale rozhodli jsme se vyložit všechny karty na stůl. V době uvedení na trh náš box neměl integraci s Prometheusem a chystala se vydání nové verze s automatizačním subsystémem, ale zatím jsme ji zákazníkům neexpedovali.
Začal pilotní projekt, byly stanoveny jeho hranice a dostali jsme 2 měsíce. Hlavní úkoly byly:
- připravit novou verzi platformy a nasadit ji do infrastruktury banky
- propojit 2 monitorovací systémy (Zabbix a Prometheus);
- zasílat upozornění odpovědným osobám ve Slacku a prostřednictvím SMS;
- spustit autohealing skripty.
První měsíc pilotního projektu byl věnován přípravě nové verze platformy v superrychlém režimu pro potřeby pilotního projektu. Nová verze okamžitě zahrnuje integraci s Prometheus a auto-healing. Díky našemu vývojovému týmu několik nocí nespali, ale vydali to, co slíbili, aniž by promeškali termíny pro další dříve přijaté závazky.
Při nastavování pilotního projektu jsme narazili na nový problém, který mohl projekt předčasně ukončit: pro zasílání upozornění do instant messengerů a prostřednictvím SMS jsme potřebovali příchozí a odchozí připojení k serverům Microsoft Azure (v té době jsme používali tuto platformu pro zasílání upozornění na Slack) a externí odesílací servisní SMS. V tomto projektu však byla kladena zvláštní pozornost na bezpečnost. V souladu s politikou banky nebylo možné takové „díry“ za žádných okolností otevřít. Vše muselo fungovat z uzavřené smyčky. Bylo nám nabídnuto použití API našich vlastních interních služeb, které posílají upozornění na Slack a prostřednictvím SMS, ale neměli jsme možnost takové služby po vybalení připojit.
Večerní debata s vývojovým týmem skončila úspěšným hledáním řešení. Když jsme se prohrabali backlogem, našli jsme jeden úkol, na který jsme nikdy neměli dost času a priority – vytvořit plug-in systém, aby si implementační týmy nebo klient mohli sami psát doplňky, rozšiřující možnosti platformy.
Zbýval nám ale přesně měsíc, během kterého jsme museli vše nainstalovat, nakonfigurovat a nasadit automatizaci.
Podle Sergeje, našeho hlavního architekta, trvá implementace systému plug-in minimálně měsíc.
Neměli jsme čas...
Existovalo jediné řešení – jít za klientem a říct vše tak, jak to je. Prodiskutujte společně posun termínu. A fungovalo to. Dostali jsme 2 týdny navíc. Měli také své vlastní termíny a interní povinnosti ukázat výsledky, ale měli 2 rezervní týdny. Nakonec vše dáme na řadu. Nebylo možné to pokazit. Poctivost a partnerský přístup se opět vyplatily.
Výsledkem pilotního projektu bylo dosaženo několika důležitých technických výsledků a závěrů:
Vyzkoušeli jsme novou funkcionalitu pro zpracování upozornění
Nasazený systém začal správně přijímat výstrahy od Promethea a seskupovat je. Upozornění na problém z klienta Prometheus létala každých 30 sekund (seskupování podle času není povoleno) a zajímalo nás, zda by bylo možné je seskupit do samotného „deštníku“. Ukázalo se, že to možné je – nastavení zpracování upozornění v platformě je realizováno skriptem. To umožňuje implementovat téměř jakoukoli logiku pro jejich zpracování. Do platformy jsme již implementovali standardní logiku ve formě šablon – pokud nechcete vymýšlet něco vlastního, můžete použít již hotovou.
Rozhraní „Syntetická spoušť“. Nastavení zpracování výstrah z připojených monitorovacích systémů
Vytvořil stav „zdraví“ systému
Na základě výstrah byly vytvořeny monitorovací události, které ovlivnily stav konfiguračních jednotek (CU). Implementujeme zdrojovo-servisní model (RSM), který může využívat buď interní CMDB, nebo připojit externí – během pilotního projektu klient nepřipojoval vlastní CMDB.
Rozhraní pro práci s modelem zdroj-služba. Pilot RSM.
Ve skutečnosti má klient konečně jednu monitorovací obrazovku, kde jsou viditelné události z různých systémů. V současné době jsou k „deštníku“ připojeny dva systémy – Zabbix a Prometheus a interní monitorovací systém samotné platformy.
Analytické rozhraní. Jedna monitorovací obrazovka.
Spuštěna automatizace procesů
Sledování událostí spustilo spouštění předem nakonfigurovaných akcí - odesílání upozornění, spouštění skriptů, registrace/obohacování incidentů - to poslední nebylo s tímto konkrétním klientem vyzkoušeno, protože v pilotním projektu nedošlo k integraci se servisním oddělením.
Rozhraní nastavení akcí. Odešlete výstrahy Slacku a restartujte server.
Rozšířená funkčnost produktu
Při diskuzi o automatizačních skriptech klient požádal o podporu bash a rozhraní, ve kterém by mohly být tyto skripty pohodlně konfigurovány. Nová verze toho udělala trochu víc (možnost psát plnohodnotné logické konstrukce v Lua s podporou cURL, SSH a SNMP) a implementovala funkcionalitu, která umožňuje řídit životní cyklus skriptu (vytvářet, upravovat, spravovat verze , smazat a archivovat).
Rozhraní pro práci s autohealing skripty. Skript pro restart serveru přes SSH.
Klíčová zjištění
Během pilotního projektu byly také vytvořeny uživatelské příběhy, které zlepšují současnou funkčnost a zvyšují hodnotu pro klienta, zde jsou některé z nich:
- implementovat schopnost předávat proměnné přímo z výstrahy do skriptu autohealingu;
- přidat oprávnění k platformě prostřednictvím Active Directory.
A dostali jsme další globální výzvy – „vybudovat“ produkt s dalšími schopnostmi:
- automatická konstrukce modelu služby zdrojů založeného na ML, spíše než na pravidlech a agentech (pravděpodobně hlavní problém současnosti);
- podpora dalších skriptovacích a logických jazyků (a to bude JavaScript).
Podle mého názoru, nejdůležitější věcTento pilot ukazuje dvě věci:
- Klíčem k efektivitě jsou partnerství s klientem, kdy je efektivní komunikace postavena na upřímnosti a otevřenosti a klient se stává součástí týmu, který v krátké době dosahuje významných výsledků.
- Za žádných okolností není nutné „přizpůsobovat“ a stavět „berličky“ – pouze systémová řešení. Je lepší věnovat trochu více času, ale vytvořit systémové řešení, které využijí další klienti. Mimochodem, stalo se to, systém pluginů a odstranění závislosti na Azure poskytly další hodnotu dalším klientům (ahoj, federální zákon 152).
Zdroj: www.habr.com