Система сповіщень в продукті: чому це корисно не тільки розробникам, а й product owner

Вітаю! Мене звати Євгеній, я займаюсь продуктовим менеджментом і розробкою в Daiquiri Team. У цій статті я ділюся своїм досвідом імплементації системи сповіщень на продукті для стартапу. Коли ти створюєш продукт для стартапу, особливо складно обґрунтовувати потрібність розробки підсистем для підвищення стабільності. Це пов’язано з бажаною швидкістю розробки — темп реалізації нових фіч просто шалений. Менше з тим, і для стартапів такі модулі бувають критично необхідними. У цьому тексті я спробував розкрити, чому це вигідно не тільки команді розробки, а й тим, хто виконує функцію product owner.

Коли на розробку продукту витрачено вже декілька тисяч годин досвідчених розробників, а сам продукт вже у production, питання його стабільності є досить важливим. Всі сервіси та служби на серверах мають працювати стабільно, а якщо десь відбулась критична проблема — відповідні члени команди розробки мають про це оперативно дізнатись і почати це виправляти.

У цій статті розповім про свій досвід налаштування системи сповіщень продукту Calibra. Нам вдалося не тільки забезпечити технічну стабільність продукту, а й оптимізувати витрати та покращити процеси нашого клієнта.

Щоби було легше зрозуміти проблеми, які ми вирішували, треба розповісти основне про продукт. Calibra — це line of business або BPMS, тобто система, яка покривала більшу частину робочих процесів компанії нашого клієнта. Компанія нашого клієнта керувала численними рекламними кампаніями своїх клієнтів у їх інтересах, заробляючи з кожного залученого ліда. Продукт керував акаунтами, з яких запускалася реклама, всіма рекламними налаштуваннями, міг автоматично змінювати рекламу, збирав статистику ефективності реклами та багато іншого.

Як це працювало загалом

Наш продукт хостився на декількох серверах на Hetzner, це приблизно 10 застосунків, деякі з яких були розгорнуті у декількох копіях. Тож на кожному сервері був розгорнутий сервіс, який збирав усі необхідні дані та надсилав їх у централізоване сховище.

На боці цього сховища ми конфігурували події. Подія означала факт, що щось почало бути не так. Наприклад, на сервері вільного місця стало менше ніж 10% — подія одразу створювалась. І, відповідно, вона відмічалася як завершена, коли ми звільняли дисковий простір та інформація про цей факт знову надходила до сховища моніторингу.

По кожній події ми налаштовували сповіщення. На початку та в момент завершення кожної події наша система моніторингу надсилала повідомлення у канали Slack. Один канал був суто про технічні сповіщення, там була присутня тільки команда розробки. У другому каналі були сповіщення, про які слід знати всім, включно з product owner та тимлідами з боку клієнта.

Це було дуже зручно завдяки тредам Slack. При кожному такому повідомленні ми мали змогу швидко обговорити проблему, обрати рішення чи просто дізнатись статус по проблемі. Це ж стосувалось і команди клієнта — майже завжди про проблеми вони дізнавались саме від нашого моніторингу, задовго до того, як будуть помітні наслідки проблеми.

Як результат, клієнт був завжди поінформований щодо проблем на проєкті. І тут ми маємо на увазі не просто технічні проблеми, а й безпосередньо проблеми бізнесу клієнта як такого.

Приклади вигоди клієнта від такої системи

У статті я зібрав декілька найяскравіших прикладів, які підтверджують, що навіть для продуктів ранньої стадії такий моніторинг вигідний. Особливо, якщо робити моніторинг з метою вирішення об’єктивно існуючих задач.

Типовий приклад гіпотетичної проблемної ситуації, яка має покриватися моніторингом

Контроль критичних продуктових метрик

Одна з підсистем продукту була особливо фінансово важливою для нашого клієнта. Ця підсистема забезпечувала надсилання даних про ліди на рекламні майданчики. Завдяки цим даним рекламні майданчики оптимізували аудиторію, якій показується реклама, і ефективність реклами суттєво зростала.

Водночас ми вже мали декілька прецедентів падіння цього процесу, і у більшості випадків не з причин всередині системи сповіщень. Менше з тим, Calibra могла зчитувати з рекламних майданчиків результати надходжень даних про ліди. Таким чином, якщо лідів відправлялось мало, ми могли сигналізувати про це, щоби мати можливість якомога швидше це виправити, максимально оптимізувавши рекламні витрати клієнту. В результаті це виглядало так:

  • якщо за 1 годину не прийшло жодного ліда за групою рекламних кампаній — це проблема, в такому випадку прилітає сповіщення;
  • ми створили чекліст типових проблем на нашому боці, який покривав 95%+ випадків. Якщо це не наша проблема, вирішувати її потрібно було клієнту. Ми перевіряли ситуацію за чеклістом після сповіщення у Slack;
  • після перевірки ми звертались до клієнта у Slack-треді, повідомляючи йому про проблему на його стороні продукту.

Як результат, ми вирішуємо частину проблем клієнта, вчасно повідомляючи йому про наявні проблеми. І разом з цим швидше помічаємо продуктові проблеми, які можемо вирішити власноруч.

Нагадування щодо оплати 3rd-party

Майже на всіх продуктах нині використовуються 3rd-party — це вигідно з огляду на економію витрат на розробку. У нашій системі сповіщень було з десяток подібних інтеграцій. Деякі з них можна було сплатити на рік вперед, деякі списувались за непередбачуваним графіком. Нашому клієнту було необхідно використовувати декілька кредитних карток, бо не всі 3rd-party могли списувати з кожної картки.

Відповідно, може бути таке, що ти забудеш поповнити якусь з карток або поповниш її на неправильну суму, внаслідок чого 3rd-party перестає працювати, доки не проведеш платіж. У таких ситуаціях нам допомагав моніторинг:

  • у клієнта не пройшов банківський платіж, після чого 3rd-party перестав працювати;
  • API 3rd-party перестає працювати, за кодом помилки моніторинг визначає, що це несплата;
  • клієнт і ми дізнаємось про це. Клієнт може невідкладно вирішити цю проблему;
  • в результаті, інтеграція відновлює роботу за мінімальний час.

Такі ситуації трапляються постійно, але вони не мають суттєво шкодити процесам. Тож завдяки системі моніторингу ми страхуємо клієнта від людського фактору у цьому питанні.

Падіння того, що не має падати

Для однієї з команд на боці клієнта ми реалізували сповіщення через Telegram. Це була команда менеджерів із запуску реклами. Вони придумували креативи для реклами, налаштовували таргетинг та власноруч контролювали відповідність ефективності реклами їхнім очікуванням. Їм треба було знати, наприклад, коли ROI рекламної кампанії падав нижче очікувань, які вони налаштували у Calibra. Такі речі були реалізовані як повідомлення від бота в Telegram.

Коли ми розробляли ці сповіщення, ми вирішили зробити для них і моніторинг. Більше для того, щоб перестрахуватися — якщо помилимось у наступних релізах, матимемо технічну можливість одразу це побачити.

Одного дня ми отримуємо повідомлення у каналі, що сповіщення в Telegram не надсилаються. Перевіряємо у БД — дійсно, не надіслані. Перевіряємо код — жодних змін за останні декілька днів, навіть не тільки у коді про сповіщення, а й у коді про цей конкретний тип сповіщень.

Після цього ми вирішили зайти в Telegram — так, він не працював. І на ServerFault також була інформація, що багато користувачів мають проблеми з доступом.

Здавалося б, у цьому кейсі не так і багато зиску, адже Telegram і без нас вирішує цю проблему, вдіяти нічого не можемо і часу на аналіз проблеми не зекономили. Але ми усе перевірили і знаємо реальну причину проблеми та не маємо нарікань на наше рішення та наші налаштування відправки Telegram-сповіщень. А свідома довіра між компанією з розробки продукту і клієнтом вартує дуже дорого.

Пришвидшення релізів

У цьому продукті ми з клієнтом часто разом проходили періоди, коли треба було розробляти щось дуже швидко. Це не було нашим бажанням, саме клієнт просив нас зробити щось максимально оперативно. Ми проговорювали, що можемо випустити нові оновлення на 30-40% часу швидше, але будуть ризики під час релізу — щось може не працювати правильно, бо його не протестували достатньо якісно. В цілому обставини були такі, що всім було вигідно піти на ризики.

Саме у таких випадках нас страхував і моніторинг в тому числі. Коли найважливіші складові продукту покриті моніторингом, випускати сирий реліз набагато спокійніше і безпечніше. Всі усвідомлюють ризики — наприклад, застосунок може декілька годин не працювати, поки ми щось виправляємо одразу після релізу. Чи якась підсистема запрацює некоректно — ми її одразу відключимо, виправимо, а потім знову включимо.

Для стартапів швидкість — це все. Для цього можна пожертвувати суворістю тестування і частину проблем вирішувати постфактум. В такому випадку моніторинг вчасно сповістить про проблему з релізом, і команда зможе швидко відреагувати і виправити.

Допомога у координації роботи команд

На великих продуктах буває так, що частини однієї системи розробляються двома різними командами. Наприклад, у нашій співпраці ми розробляли левову частку продукту, а найбільш sensitive складові (наприклад, фінансові модулі продукту) розроблялися командою на боці клієнта.

Частини продукту від різних розробників зазвичай пов’язані якимось API. І одна з команд може зламати таку інтеграцію невдалим релізом. У довготривалих співпрацях таке трапляється нерідко. За допомогою системи сповіщень такі ситуації можуть бути вирішені в наступному порядку:

  • у наших колег був невдалий реліз, підсистема впала;
  • ми отримуємо сповіщення у канал, одразу перевіряємо стан на нашому боці, ніби, проблем бути не повинно;
  • тегаємо у Slack представника іншої команди, і питаємо його, чи не було релізів за останні години;
  • член команди клієнта пише в тред, що, вірогідно, помилка на їхньому боці, і вони відкочуються до попереднього релізу;
  • проблема вирішена, інтеграція після відкату працює.

У підсумку, завдяки системі моніторингу всі розуміють, чому ця частина продукту зараз не працює. Основна команда не витрачає на це зайвий час.

Висновок

У цьому проєкті моніторинг та система сповіщень заощадили багато грошей та часу. Ми можемо послатися на оцінку клієнта — витрати на розробку і підтримку моніторингу були фактично менші за витрати, які, вірогідно, треба було б понести, якби ми не зробили підсистему моніторингу.

Наш головний висновок з цього досвіду — стабільні рішення точно можуть бути ефективними і на досить ранній стадії продукту, тобто навіть у стартапі. Головне — це керуватися здоровим глуздом і вирішувати реальні задачі, як тільки вони виникають.

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі