У публікацыях на Хабре я ўжо пісаў аб сваім досведзе пабудовы партнёрскіх адносін са сваёй камандай ( распавядаецца аб тым, як скласці партнёрскую дамову пры старце новага бізнэсу, каб бізнэс не разваліўся). А зараз я б хацеў расказаць пра тое, як будаваць партнёрскія адносіны з кліентамі, бо без іх развальвацца будзе няма чаму. Я спадзяюся гэты артыкул будзе карысная стартапам, пачаткоўцам продажу свайго прадукта буйному бізнэсу.
Я зараз як раз узначальваю такі стартап MONQ Digital lab, дзе мы з камандай распрацоўваем прадукт па аўтаматызацыі працэсаў падтрымкі і эксплуатацыі карпаратыўнага ІТ. Вынахад на рынак вельмі не простая задача і мы пачалі з невялікай хатняй працы, мінулі па экспертах рынка, нашым партнёрам і правялі сегментацыю рынка. Асноўным пытаннем было зразумець "чые болі мы лепш за ўсё можам вылечыць?"
У ТОП3 сегментаў патрапілі банкі. І вядома ж першым у спісе былі Тинькофф і Ашчадбанк. Калі мы хадзілі па экспертах банкаўскага рынку яны казалі: укараніце свой прадукт туды, і шлях на рынак банкаў будзе адкрыты. Мы паспрабавалі ўвайсці і туды, і туды, але ў Ашчадбанку нас чакаў правал, а хлопцы з Тинькофф апынуліся на парадак больш адчыненымі да прадуктыўных зносін з расійскімі стартапамі (можа быць з-за таго, што Ашчад у гэты час амаль за мільярд нашых заходніх канкурэнтаў). Ужо праз месяц мы распачалі пілотны праект. Як гэта было, чытайце далей.
Мы шмат гадоў займаемся пытаннямі эксплуатацыі і маніторынгу, цяпер укараняем наш прадукт у дзяржсектары, у страхаванні, у банках, у тэлекам-кампаніях, адно ўкараненне было ў авіякампаніі (перад праектам, мы і не думалі, што авіяцыя настолькі ІТ-залежная галіна, і зараз вельмі спадзяемся, нягледзячы на COVID, што кампанія выплыве і пойдзе на ўзлёт).
Той прадукт, які мы робім адносіцца да карпаратыўнага ПЗ, сегменту AIOps (Artificial Intelligence for IT Operations, або ITOps). Асноўныя мэты ўкаранення такіх сістэм па меры павышэння ўзроўню сталасці працэсаў у кампаніі:
- Патушыць пажары: выявіць збоі, ачысціць паток алертаў ад смецця, паставіць цягі і інцыдэнты на адказных;
- Падвысіць эфектыўнасць працы ІТ-службы: зменшыць час рашэння інцыдэнтаў, паказаць на чыннікі збояў, падвысіць празрыстасць стану ІТ;
- Павысіць эфектыўнасць бізнесу: скараціць аб'ём ручной працы, знізіць рызыкі, павысіць лаяльнасць кліентаў.
Па нашым досведзе, у банкаў агульныя са ўсімі буйнымі IT-інфраструктурамі "болі" з маніторынгам наступныя:
- "хто ў што здольны": тэхаддзелаў шмат, практычна ў кожнага як мінімум адна свая сістэма маніторынгу, а ў большасці – больш за адну;
- "камарыны рой" алертаў: кожная сістэма генеруе сотні і бамбіць імі ўсіх адказных (часам яшчэ і паміж аддзеламі). Пастаянна трымаць фокус кантролю на кожным апавяшчэнні складана, іх тэрміновасць і важнасць нівеліруецца з-за вялікай колькасці;
- буйныя банкі - лідэры сектара хочуць не проста бесперапынна маніторыць свае сістэмы, ведаць, дзе ёсць збоі, але і сапраўднай магіі AI - зрабіць так, каб сістэмы самаманіторыліся, самапрагназавалі і самавыпраўляліся.
Калі мы дашлі на першую сустрэчу ў Тинькофф, нам адразу сказалі, што ў іх няма праблем з маніторынгам і ў іх нічога не баліць, і асноўным пытаннем было: "Што мы можам прапанаваць для тых, у якіх і так усё добра?"
Размова была доўгая, мы абмеркавалі як пабудаваны іх мікрасэрвісы, як працуюць падраздзяленні, якія праблемы інфраструктуры больш адчувальныя, якія менш адчувальныя для карыстальнікаў, дзе “белыя плямы”, і якія ў іх мэты і SLA.
Дарэчы, SLA у банка сапраўды ўражваюць. Напрыклад, на ўстараненне інцыдэнту першага прыярытэту, звязанага з сеткавай даступнасцю, даецца ўсяго некалькі хвілін. Кошт памылкі і прастою тут, вядома, вялікая.
У выніку мы выявілі некалькі напрамкаў супрацоўніцтва:
- першы этап - парасонавы маніторынг, для павышэння хуткасці рашэння інцыдэнтаў
- другі этап - аўтаматызацыя працэсаў для зніжэння рызык і зніжэнне выдаткаў на маштабаванне ІТ-падраздзяленні.
Некалькі "белых плям" можна было размаляваць у яркія колеры алертаў, толькі апрацаваўшы інфармацыю з некалькіх сістэм маніторынгу, бо наўпрост зняць метрыкі было нельга, таксама патрэбна была цэнтралізацыя дадзеных з розных сістэм маніторынгу на "адзін экран", каб разумець агульную карціну таго, што адбываецца. Для гэтай задачы падыходзяць "парасоны" і мы задавальнялі тады гэтым патрабаванням.
Вельмі важная штука, на наш погляд, ва ўзаемаадносінах з кліентамі - гэта сумленнасць. Пасля першай размовы і разліку кошту ліцэнзіі было сказана, раз кошт такі невысокі, можа адразу варта купіць ліцэнзію (у параўнанні з Dynatrace Ключ-Астром з артыкула вышэй пра зялёны банк, наша ліцэнзія каштуе не траціну ад мільярда, а 12 тысяч рублёў у месяц за 1 гігабайт, для Сбера яна абышлася б у разы танней). Але мы адразу сказалі ім, што ў нас ёсць і што не. Быць можа сейл з буйнога інтэгратара мог бы сказаць "ды мы ўсе можам, вядома купіце нашу ліцэнзію", але мы вырашылі выкласці ўсе карты на стол. У нашай каробцы на момант старту не было інтэграцыі з Prometheus, а таксама новая версія з падсістэмай аўтаматызацыі павінна была вось-вось выйсці, але кліентам мы яе яшчэ не адгружалі.
Пачаўся пілотны праект, былі вызначаны яго межы і нам далі 2 месяцы. Асноўныя задачы былі:
- падрыхтаваць новую версію платформы і разгарнуць яе ў інфраструктуры банка
- падключыць 2 сістэмы маніторынгу (Zabbix і Prometheus);
- адпраўляць абвесткі адказным у Slack і па СМС;
- запускаць скрыпты аўтахілінга.
Першы месяц пілотнага праекту ў нас сышоў на падрыхтоўку новай версіі платформы ў суперхуткім рэжыме для патрэб пілотнага праекту. У новую версію адразу ўвайшла інтэграцыя з Prometheus і аўтахілінгам. Дзякуй нашай камандзе распрацоўкі, яны не спалі некалькі начэй, але выпусцілі абяцанае без зрыву тэрмінаў па іншых узятых раней абавязацельствах.
Пакуль наладжвалі пілот сутыкнуліся з новай праблемай, якая магла закрыць праект датэрмінова: для адпраўкі абвестак у месэнджары і па СМС нам патрэбныя ўваходныя і выходныя злучэнні з серверамі Microsoft Azure (на той момант мы выкарыстоўвалі дадзеную платформу для дасылкі абвестак у Slack) і вонкавым сэрвісам адпраўкі СМС. Але ў гэтым праекце бяспека была ў асаблівым фокусе ўвагі. У адпаведнасці з палітыкай банка такія "дзіркі" не маглі быць адкрыты ні пры якіх умовах. Усё павінна было працаваць з зачыненага контуру. Нам прапанавалі выкарыстоўваць API уласных унутраных сэрвісаў, якія адпраўляюць абвесткі ў Slack і па СМС, але ў нас не было магчымасці падлучыць такія сэрвісы са скрынкі.
Вечар дэбатаў з камандай распрацоўкі скончыўся паспяховым пошукам рашэння. Пакалупаўшы бэклог мы знайшлі адну задачу, на якую ніколі не хапала часу і прыярытэту - зрабіць плягінную сістэму, каб каманды ўкаранення або кліент самі маглі пісаць дапаўненні, пашыраючы магчымасці платформы.
Але ў нас заставаўся роўна месяц, за які трэба было ўсё ўстанавіць, настроіць і разгарнуць аўтаматызацыю.
Па адзнацы Сяргея, нашага галоўнага архітэктара, на ўкараненне плягіннай сістэмы патрэбен мінімум месяц.
Мы не паспявалі…
Рашэнне было адно - ісці да кліента і ўсё расказваць, як ёсць. Разам абмяркоўваць зрух тэрмінаў. І гэта спрацавала. Нам далі дадаткова 2 тыдні. У іх таксама былі свае тэрміны і ўнутраныя абавязацельствы паказаць вынікі, але былі 2 тыдні рэзервовыя. У выніку мы ўсё паставілі на карту. Нельга было опростоволоситься. Сумленнасць і партнёрскі падыход зноў даў свой плён.
У выніку пілота атрымалі некалькі важных тэхнічных вынікаў і высноў:
Апрабавалі новы функцыянал апрацоўкі алертаў
Разгорнутая сістэма пачала правільна прымаць алерты з Prometheus і рабіць іх групоўку. Алерты па праблеме з Prometheus кліента ляцелі кожныя 30 секунд (не ўключана групоўка па часе), і нам было цікава, ці можна іх будзе групаваць у самім "парасоніку". Аказалася, што можна – настройка апрацоўкі алертаў у платформе рэалізаваная скрыптам. Гэта дае магчымасць рэалізацыі практычна любой логікі іх апрацоўкі. Стандартную логіку мы ўжо рэалізавалі ў платформе ў выглядзе шаблонаў - калі няма жадання прыдумляць нешта сваё, можна скарыстацца гатовым.
Інтэрфейс "сінтэтычнага трыгера". Настройка апрацоўкі алертаў з падключаных сістэм маніторынгу
Пабудавалі стан «здароўя» сістэмы
Па алертах ствараліся падзеі маніторынгу, якія ўплываюць на здароўе канфігурацыйных адзінак (КЕ). Мы рэалізуем рэсурсна-сэрвісную мадэль (РСМ), якая можа выкарыстоўваць або ўнутраную CMDB, або падключыць знешнюю - на пілотным праекце кліент сваю CMDB не падключаў.
Інтэрфейс працы з рэсурсна-сэрвіснай мадэллю. Пілотная РСМ.
Ну і, уласна, у кліента з'явіўся, нарэшце, адзіны экран маніторынгу, дзе бачна падзеі з розных сістэм. На бягучы момант да "парасона" падключана дзве сістэмы – Zabbix і Prometheus, і ўнутраная сістэма маніторынгу самой платформы.
Інтэрфейс аналітыкі. Адзіны экран маніторынгу.
Запусцілі аўтаматызацыю працэсаў
Падзеі маніторынгу ініцыявалі запуск наладжаных дзеянняў - адпраўку абвестак, запуск скрыптоў, рэгістрацыю / узбагачэнне інцыдэнтаў - апошняе не паспрабавалі менавіта з гэтым кліентам, т.я. у пілотным праекце не было інтэграцыі з сервісдэскам.
Інтэрфейс наладкі дзеянняў. Адпраўка абвестак у Slack і перазагрузка сервера.
Пашырылі функцыянал прадукта
Пры абмеркаванні скрыптоў аўтаматызацыі кліент прасіў падтрымку bаsh і інтэрфейс, у якім гэтыя скрыпты можна было б зручна наладжваць. У новай версіі было зроблена крыху больш (магчымасць напісання паўнавартасных лагічных канструкцый на Lua з падтрымкай cURL, SSH і SNMP) і рэалізаваны функцыянал, які дазваляе кіраваць жыццёвым цыклам скрыпту (ствараць, рэдагаваць, кіраваць версіямі, выдаляць і архіваваць).
Інтэрфейс працы са скрыптамі аўтахілінга. Скрыпт перазагрузкі сервера па SSH.
асноўныя высновы
Падчас пілота таксама былі сфарміраваны юзерстарыс, якія паляпшаюць бягучы функцыянал і павышаюць каштоўнасць для кліента, вось некаторыя з іх:
- рэалізаваць магчымасць пракіду зменных непасрэдна з алерту ў скрыпт аўтахілінгу;
- дадаць на платформе аўтарызацыю праз Active Directory.
І атрымалі больш глабальныя выклікі для нас – "нарасціць" прадукт іншымі магчымасцямі:
- аўтапабудовай рэсурсна-сэрвіснай мадэлі на аснове ML, а не правіл і агентаў (напэўна, галоўны выклік зараз);
- падтрымкай дадатковых моў скрыптавання і логікі (і гэта будзе JavaScript).
На мой погляд, самае галоўнае, Што паказвае дадзены пілот, гэта дзве рэчы:
- Партнёрскія адносіны з кліентам - залог эфектыўнасці, калі на базе сумленнасці і адкрытасці будуецца эфектыўная камунікацыя, і кліент становіцца часткай каманды, якая за кароткія тэрміны дамагаецца значных вынікаў.
- Ні пры якіх умовах не трэба "кастаміць" і будаваць "мыліцы" - толькі сістэмныя рашэнні. Лепш выдаткаваць крыху больш часу, але зрабіць сістэмнае рашэнне, якое будзе выкарыстоўвацца і ў іншых кліентаў. Дарэчы, так і выйшла, убудованая сістэма і адмова ад залежнасці з Azure, далечы дадатковую каштоўнасць і іншым кліентам (прывітанне, 152ой ФЗ).
Крыніца: habr.com