Po co bankowi AIOps i parasolowy monitoring, czyli na czym opierają się relacje z klientami?

W publikacjach na temat Habré pisałem już o swoich doświadczeniach w budowaniu partnerskich relacji z moim zespołem (tutaj mówi o tym, jak spisać umowę spółki przy zakładaniu nowego biznesu, aby biznes się nie rozpadł). A teraz chciałbym porozmawiać o tym, jak budować partnerskie relacje z klientami, bo bez nich nie będzie się co rozpadać. Mam nadzieję, że ten artykuł będzie przydatny dla startupów, które zaczynają sprzedawać swój produkt dużym firmom.

Obecnie kieruję start-upem o nazwie MONQ Digital lab, gdzie wraz z zespołem rozwijam produkt umożliwiający automatyzację procesów wsparcia i obsługi korporacyjnego IT. Wejście na rynek nie jest łatwym zadaniem, zaczęliśmy od małej pracy domowej, przeszliśmy przez ekspertów rynkowych, naszych partnerów i przeprowadziliśmy segmentację rynku. Głównym pytaniem było zrozumienie, „czyje bóle możemy najlepiej uleczyć?”

Banki znalazły się w TOP 3 segmentów. I oczywiście pierwszymi na liście były Tinkoff i Sbierbank. Kiedy odwiedziliśmy ekspertów rynku bankowego, powiedzieli: wprowadź tam swój produkt, a droga do rynku bankowego stanie otworem. Próbowaliśmy wejść i tam, i tam, ale w Sbierbanku czekała nas porażka, a chłopaki z Tinkoff okazali się znacznie bardziej otwarci na produktywną komunikację z rosyjskimi startupami (może ze względu na to, że Sber w tym czasie kupił prawie miliard naszych zachodnich konkurentów). W ciągu miesiąca rozpoczęliśmy projekt pilotażowy. Jak to się stało, czytaj dalej.

Zagadnieniami obsługi i monitoringu zajmujemy się od wielu lat, obecnie wdrażamy nasz produkt w sektorze publicznym, w ubezpieczeniach, w bankach, w firmach telekomunikacyjnych, jedno wdrożenie było u linii lotniczej (przed projektem nawet nie uważamy, że lotnictwo było branżą tak zależną od IT, a teraz naprawdę mamy nadzieję, że pomimo Covid, firma wyjdzie i wystartuje).

Produkowany przez nas produkt należy do oprogramowania korporacyjnego segmentu AIOps (Artificial Intelligence for IT Operations, w skrócie ITOps). Główne cele wdrażania takich systemów jak wzrost poziomu dojrzałości procesowej w przedsiębiorstwie:

1. Gaś pożary: identyfikuj awarie, oczyszczaj strumień alarmów ze śmieci, przydzielaj zadania i zdarzenia osobom odpowiedzialnym;
2. Zwiększ efektywność obsługi IT: skróć czas rozwiązywania incydentów, wskaż przyczyny awarii, zwiększ przejrzystość stanu IT;
3. Zwiększ efektywność biznesową: zmniejsz ilość pracy fizycznej, zmniejsz ryzyko, zwiększ lojalność klientów.

Z naszego doświadczenia wynika, że ​​banki borykają się z następującymi problemami związanymi z monitorowaniem, typowymi dla wszystkich dużych infrastruktur IT:

• „kto wie co”: działów technicznych jest wiele, prawie każdy ma przynajmniej jeden system monitorowania, a większość ma więcej niż jeden;
• „rój komarów” alertów: każdy system generuje setki i bombarduje nimi wszystkich odpowiedzialnych (czasami także między działami). Trudno jest stale utrzymać skupienie kontroli nad każdym zgłoszeniem, ich pilność i waga są zrównane ze względu na dużą liczbę;
• duże banki – liderzy branży chcą nie tylko na bieżąco monitorować swoje systemy, wiedzieć, gdzie występują awarie, ale także prawdziwej magii AI – aby systemy mogły się samomonitorować, przewidywać i samokorygować.

Kiedy przyjechaliśmy na pierwsze spotkanie w Tinkoff, od razu powiedziano nam, że nie mają problemów z monitoringiem i nic ich nie boli, a główne pytanie brzmiało: „Co możemy zaoferować tym, którzy już dobrze sobie radzą?”

Rozmowa była długa, rozmawialiśmy o tym, jak zbudowane są ich mikroserwisy, jak pracują działy, które problemy z infrastrukturą są bardziej wrażliwe, które mniej wrażliwe dla użytkowników, gdzie są „martwe punkty”, jakie są ich cele i SLA.

Swoją drogą, umowy SLA banku są naprawdę imponujące. Na przykład rozwiązanie zdarzenia dotyczącego dostępności sieci o priorytecie XNUMX może zająć tylko kilka minut. Koszt błędów i przestojów jest tutaj oczywiście imponujący.

W rezultacie zidentyfikowaliśmy kilka obszarów współpracy:

1. pierwszym etapem jest monitoring parasolowy w celu zwiększenia szybkości rozwiązywania incydentów
2. drugim etapem jest automatyzacja procesów, mająca na celu redukcję ryzyka i redukcję kosztów skalowania działu IT.

Kilka „białych plam” można było pomalować jaskrawymi kolorami alarmów jedynie poprzez przetworzenie informacji z kilku systemów monitorowania, ponieważ bezpośrednie pobieranie wskaźników było niemożliwe; konieczne było także scentralizowanie danych z różnych systemów monitorowania na „jednym ekranie”, aby zrozumieć ogólny obraz tego, co się działo. Do tego zadania nadają się „parasolki” i wtedy spełniliśmy te wymagania.

Naszym zdaniem bardzo ważną rzeczą w relacjach z klientami jest uczciwość. Po pierwszej rozmowie i wyliczeniu kosztu licencji padło stwierdzenie, że skoro koszt jest tak niski, to może warto od razu kupić licencję (w porównaniu do Dynatrace Klyuch-Astrom z powyższego artykułu o zielonym banku, naszym licencja kosztuje nie jedną trzecią miliarda, ale 12 tysięcy rubli miesięcznie za 1 gigabajt, w przypadku Sbera byłoby to kilka razy tańsze). Ale od razu powiedzieliśmy im, co mamy, a czego nie. Być może przedstawiciel handlowy dużego integratora mógłby powiedzieć „tak, możemy wszystko, oczywiście kupmy naszą licencję”, ale my postanowiliśmy wyłożyć wszystkie karty na stół. W momencie premiery nasz box nie miał integracji z Prometheusem, a miała się ukazać nowa wersja z podsystemem automatyzacji, lecz nie wysłaliśmy jej jeszcze do klientów.

Ruszył projekt pilotażowy, ustalono jego granice i dano nam 2 miesiące. Głównymi zadaniami było:

• przygotować nową wersję platformy i wdrożyć ją w infrastrukturze banku
• podłączyć 2 systemy monitorowania (Zabbix i Prometheus);
• wysyłaj powiadomienia do osób odpowiedzialnych w Slacku i poprzez SMS;
• uruchom skrypty automatycznej naprawy.

Pierwszy miesiąc pilotażu upłynął na przygotowaniu nowej wersji platformy w trybie superszybkim na potrzeby projektu pilotażowego. Nowa wersja od razu uwzględnia integrację z Prometheusem i funkcję automatycznego leczenia. Dzięki naszemu zespołowi programistów nie spali przez kilka nocy, ale wypuścili to, co obiecali, nie uchybiając terminom innych wcześniej podjętych zobowiązań.

Przygotowując pilotaż napotkaliśmy nowy problem, który mógł zakończyć projekt przed terminem: do wysyłania alertów na komunikatory internetowe i poprzez SMS potrzebne były połączenia przychodzące i wychodzące z serwerami Microsoft Azure (wówczas korzystaliśmy z tej platformy do wysyłania alertów do Slacka) oraz zewnętrzną usługę wysyłania SMS-ów. Jednak w tym projekcie szczególny nacisk położono na bezpieczeństwo. Zgodnie z polityką banku takich „dziur” w żadnym wypadku nie można było otworzyć. Wszystko musiało działać w zamkniętej pętli. Zaproponowano nam skorzystanie z API naszych własnych, wewnętrznych serwisów wysyłających alerty na Slacka oraz poprzez SMS, jednak nie mieliśmy możliwości podłączenia takich usług od razu po wyjęciu z pudełka.

Wieczór debaty z zespołem programistów zakończył się sukcesem w poszukiwaniu rozwiązania. Szperając w backlogu znaleźliśmy jedno zadanie, na które nigdy nie starczyło nam czasu i priorytetu - stworzyć system wtyczek, tak aby zespoły wdrożeniowe lub klient mogli sami pisać dodatki, rozszerzając możliwości platformy.

Został nam jednak dokładnie miesiąc, podczas którego musieliśmy wszystko zainstalować, skonfigurować i wdrożyć automatyzację.

Według Siergieja, naszego głównego architekta, wdrożenie systemu wtyczek zajmuje co najmniej miesiąc.

Nie mieliśmy czasu...

Rozwiązanie było tylko jedno – udać się do klienta i powiedzieć wszystko tak, jak jest. Omówcie wspólnie zmianę terminu. I zadziałało. Dostaliśmy dodatkowe 2 tygodnie. Mieli też własne terminy i wewnętrzne zobowiązania do przedstawienia wyników, ale mieli 2 tygodnie rezerwowe. W końcu postawiliśmy wszystko na jedną kartę. Nie dało się zepsuć. Uczciwość i partnerskie podejście po raz kolejny się opłaciły.

W wyniku pilotażu uzyskano kilka ważnych wyników technicznych i wniosków:

Przetestowaliśmy nową funkcjonalność przetwarzania alertów

Wdrożony system zaczął poprawnie odbierać alerty od Prometheusa i grupować je. Alerty o problemie z klienta Prometheus pojawiały się co 30 sekund (grupowanie według czasu nie jest włączone) i zastanawialiśmy się, czy nie byłoby możliwości pogrupowania ich w samym „parasolku”. Okazało się, że jest to możliwe – konfiguracja przetwarzania alertów w platformie realizowana jest za pomocą skryptu. Dzięki temu możliwe jest zaimplementowanie niemal dowolnej logiki ich przetwarzania. W platformie zaimplementowaliśmy już standardową logikę w postaci szablonów – jeśli nie chcesz wymyślać czegoś własnego, możesz skorzystać z gotowej.

Interfejs „syntetyczny wyzwalacz”. Konfigurowanie przetwarzania alertów z podłączonych systemów monitorowania

Skonstruowano stan „zdrowia” systemu

Na podstawie alertów utworzono zdarzenia monitorujące, które miały wpływ na kondycję jednostek konfiguracyjnych (CU). Wdrażamy model zasobowo-usługowy (RSM), który może wykorzystywać albo wewnętrzną bazę CMDB, albo podłączyć zewnętrzną - w trakcie projektu pilotażowego klient nie podłączył własnej bazy CMDB.

Interfejs do pracy z modelem zasoby-usługi. Pilotażowy RSM.

No i tak naprawdę klient ma wreszcie jeden ekran monitoringu, na którym widoczne są zdarzenia z różnych systemów. Obecnie do „parasolki” podłączone są dwa systemy – Zabbix i Prometheus oraz wewnętrzny system monitorowania samej platformy.

Interfejs analityczny. Pojedynczy ekran monitorowania.

Uruchomiono automatyzację procesów

Monitorowanie zdarzeń spowodowało uruchomienie wstępnie skonfigurowanych działań - wysyłanie alertów, uruchamianie skryptów, rejestrowanie/wzbogacanie incydentów - tego ostatniego nie próbowano z tym konkretnym klientem, ponieważ w projekcie pilotażowym nie było integracji z service deskiem.

Interfejs ustawień akcji. Wysyłaj alerty do Slacka i zrestartuj serwer.

Rozszerzona funkcjonalność produktu

Omawiając skrypty automatyzujące, klient poprosił o obsługę basha i interfejs, w którym można by wygodnie konfigurować te skrypty. Nowa wersja zrobiła nieco więcej (możliwość pisania pełnoprawnych konstrukcji logicznych w Lua z obsługą cURL, SSH i SNMP) i zaimplementowaną funkcjonalność pozwalającą zarządzać cyklem życia skryptu (tworzenie, edycja, kontrola wersji , usuń i zarchiwizuj).

Interfejs do pracy ze skryptami automatycznej naprawy. Skrypt ponownego uruchomienia serwera przez SSH.

Kluczowe ustalenia

W trakcie pilotażu powstały także historie użytkowników, które poprawiają obecną funkcjonalność i zwiększają wartość dla klienta, oto niektóre z nich:

• zaimplementować możliwość przekazywania zmiennych bezpośrednio z alertu do skryptu autonaprawy;
• dodaj autoryzację do platformy poprzez Active Directory.

Otrzymaliśmy także więcej globalnych wyzwań – „rozbudowanie” produktu o inne możliwości:

• automatyczna konstrukcja modelu zasobów i usług w oparciu o ML, a nie reguły i agentów (obecnie prawdopodobnie główne wyzwanie);
• obsługa dodatkowych języków skryptowych i logicznych (i będzie to JavaScript).

W mojej opinii, najważniejszeTen pilot pokazuje dwie rzeczy:

1. Partnerska współpraca z klientem jest kluczem do efektywności, gdy skuteczna komunikacja zbudowana jest w oparciu o szczerość i otwartość, a klient staje się częścią zespołu, który w krótkim czasie osiąga znaczące rezultaty.
2. W żadnym wypadku nie trzeba „dopasowywać” i budować „kuli” – jedynie rozwiązania systemowe. Lepiej poświęcić trochę więcej czasu, ale stworzyć rozwiązanie systemowe, z którego będą korzystać inni klienci. Nawiasem mówiąc, tak się stało, system wtyczek i eliminacja zależności od Azure zapewniły dodatkową wartość innym klientom (witaj, ustawa federalna 152).

Źródło: www.habr.com