У публікаціях на Хабрі я вже писав про свій досвід побудови партнерських відносин зі своєю командою ( розповідається про те, як скласти партнерську угоду при старті нового бізнесу, щоб бізнес не розвалився). А зараз я хотів би розповісти про те, як будувати партнерські відносини з клієнтами, бо без них розвалюватися не буде чому. Я сподіваюся, ця стаття буде корисна стартапам, які починають продажу свого продукту великому бізнесу.
Я зараз очолюю такий стартап 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