Міграція з PagerDuty: покроковий план

Цей текст — короткий путівник, який я тримаю в собі для команд, що готуються до переходу з PagerDuty. Не маркетинговий матеріал, не рекламний порівняльний огляд. Покрокова інструкція з тими частинами, які зазвичай пропускають, і з тими, які зазвичай переоцінюють.

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

Тиждень до переходу: інвентаризація

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

Список перший: усі джерела сповіщень. Кожен інструмент, який зараз надсилає webhook до PagerDuty. Grafana, Prometheus, Sentry, Datadog, синтетичний моніторинг (Pingdom, Better Stack), власні внутрішні сервіси, що використовують PagerDuty API напряму. Один рядок на джерело. Якщо ви не можете згадати, поверніться до журналів останнього місяця в PagerDuty — там видно, від чого приходили реальні події.

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

Список третій: усі активні політики ескалації. З поведінкою: хто перший, хто другий, які затримки, які канали. Скільки реально таких політик у вас — три? шість? сімнадцять? У 80% команд, які я бачив, цей список виявляється коротшим, ніж очікувалося, бо багато політик копіювалися одна з одної без реальних відмінностей.

Цей документ — ваш контракт із собою. Усе, чого в ньому немає, не мігрує. Точка.

Тижні перший і другий: паралельна робота

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

Виглядає це приблизно так у конфігурації Alertmanager:

receivers:
  - name: dual_routing
    webhook_configs:
      - url: https://events.pagerduty.com/...
      - url: https://api.wardenpoint.com/webhook/...

Перший URL — як завжди. Другий — нове джерело. Обидва отримують ту саму подію в той самий момент.

Два тижні. Не один. Один тиждень не дає вам вихідних, а вихідні мають інший профіль сповіщень — інші люди в команді, інший час реакції, інші типи інцидентів. Якщо новий інструмент пройшов суботній ранок без пропусків і неділю без помилкових пробуджень — він пройде і будні.

За цей період відбувається ще одна корисна річ, на яку зазвичай ніхто не розраховує. Стає видно неактуальних одержувачів у PagerDuty. Тих, що пішли з компанії пів року тому. Номерів телефону, які давно змінилися. Slack-ідентифікаторів, що більше не збігаються з email. Команда роками тихо обходила ці проблеми («Маріуш уже не відповідає, дзвони одразу до Анни»). Тепер ці пастки видно у звітах нового інструмента. Виправляйте їх зараз, а не після переходу — потім нагода зникне.

Тиждень третій: переключення джерел

Не перемикати все одразу. Йдіть від найтихіших до найголосніших джерел.

Порядок, який працює:

1. Синтетичний моніторинг (Pingdom, Better Stack)
2. Sentry або Rollbar
3. Grafana
4. Prometheus / Alertmanager
5. Власні webhook з ваших сервісів
6. Інтеграція з основним сервісом, що приносить виторг

Між кроками — два-три дні. Не доба. Не тиждень. Достатньо, щоб подія встигла прилетіти та ланцюжок встигнув відпрацювати.

На кожному кроці обовʼязковий тест: спричиніть штучне сповіщення через /api/v1/notifications/test або еквівалент. Не просто перевірте, що сповіщення відобразилося в інтерфейсі — пройдіть повний шлях до SMS або до дзвінка на телефон чергового. Без цього кроку нічого не зараховується.

День переключення для основного джерела

Один четвер, не пʼятниця. Не вівторок ранок після свята. Звичайний робочий четвер о 14:00 за вашим часом.

Дії:

1. У джерелі №6 з вашого списку (тому, що приносить виторг) вимикаєте webhook до PagerDuty.
2. Залишаєте webhook до нового інструмента увімкненим.
3. Залишаєте графік чергувань у PagerDuty увімкненим ще на тиждень. Це коштує приблизно нічого і дає страховку, якщо щось пропустили.
4. Інформуєте команду через канал команди. Один абзац: «з цієї хвилини джерело X надсилає виклики через [новий інструмент]. PagerDuty залишається активним до наступного четверга як запасна страховка».

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

Тиждень після: спостереження

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

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

Якщо щось сталося — повертаєте webhook на старе джерело і розбираєтесь, не панікуючи.

Що не варто мігрувати

Я зустрічав команди, які перейшли тільки частково — і це нормально. PagerDuty залишається в них для звернень підтримки клієнтів у стилі керування ІТ-послугами (ITSM), які не вимагають будити когось о 3:00, а для справжніх інцидентів інфраструктури вони використовують новий інструмент. Це не недомігрована система. Це усвідомлений вибір — структура витрат двох інструментів різна, і кожний оптимізований під своє.

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