Migracja z PagerDuty: praktyczny plan działania

Większość rozmów o migracji z PagerDuty kończy się jednym argumentem, którego nie da się obalić tabelą cen ani porównaniem funkcji: «zostawiamy, bo nie warto się przepychać». To prawdziwy argument. Nie warto przepychać się, jeśli przepychanie kosztuje więcej, niż oszczędność. Cały spór sprowadza się do tego jednego pytania, a nie do tego, czy nowe narzędzie jest lepsze.

Spróbuję więc tej rozmowy od drugiej strony. Nie «co dostaniecie po migracji», tylko «ile faktycznie kosztuje sama migracja, jeśli zrobi się ją uczciwie». Bo właśnie tutaj większość argumentów się rozsypuje — koszt migracji jest niemal zawsze zawyżony w wyobraźni decydenta, a oszczędność niedoceniona w tej samej wyobraźni.

Mit «trzeba przepisać wszystko»

Pierwszy odruch zespołu, który myśli o zmianie narzędzia powiadomień, to wyobrażenie wielkiej migracji. Eksport historii incydentów. Przeniesienie wszystkich integracji. Przepisanie polityk eskalacji. Reedukacja zespołu. Wielomiesięczna praca w tle.

Wszystkie te kroki są zbędne. Większość z nich szkodzi. Eksport historii incydentów ma sens, jeśli planujecie analizować dane historyczne — co prawie nikt nie robi po dwóch latach. Przepisywanie polityk eskalacji jednoznacznie ma sens, ale to dwa wieczory pracy, nie kwartał. Reedukacja zespołu? Inżynierowie, którzy umieli odbierać wezwania z PagerDuty, umieją odbierać je z dowolnego innego narzędzia w pierwszej minucie pierwszego dyżuru.

Migracja, którą prowadziliśmy w czterech zespołach, średnio zajmowała 22 godziny pracy starszego inżyniera. To trzy dni robocze. Najwięcej czasu pochłania nie konfiguracja, tylko obserwacja okresu pracy dwutorowej.

Tydzień przed migracją: trzy listy, nie prezentacja

Na tydzień przed planowanym przełączeniem zróbcie jeden dokument. Nie prezentację, nie obszerny raport. Jeden dokument z trzema listami.

Lista pierwsza: wszystkie źródła wezwań. Każde narzędzie, które obecnie wysyła webhook do PagerDuty. Grafana, Prometheus, Sentry, Datadog, monitoring syntetyczny (Pingdom, Better Stack), własne wewnętrzne serwisy używające PagerDuty API bezpośrednio. Jeden wiersz na źródło. Jeśli nie pamiętacie wszystkich, wróćcie do dzienników ostatniego miesiąca w PagerDuty — widać tam, z czego przyszły realne zdarzenia.

Lista druga: wszystkie aktywne grafiki dyżurów. Kto, kiedy, na jakim interwale rotacji. Tu nie próbujcie przepisywać historii — tylko aktualny stan i najbliższe dwa tygodnie.

Lista trzecia: wszystkie aktywne polityki eskalacji. Z zachowaniem: kto pierwszy, kto drugi, jakie opóźnienia, jakie kanały. Ile naprawdę takich polityk macie — trzy? sześć? siedemnaście? W 80% zespołów, które widziałem, ta lista okazuje się krótsza, niż się spodziewano, bo wiele polityk kopiowało jedną z drugiej bez realnych różnic.

Ten dokument to wasz kontrakt sam ze sobą. Wszystko, czego w nim nie ma, nie migruje. Kropka.

Praca dwutorowa, czyli najbardziej niedoceniana technika

Większość migracji przegrywa nie na konfiguracji, tylko na zaufaniu. Zespół boi się przełączyć źródło wezwań, bo nie wie, czy nowe narzędzie złapie nocny alarm tak samo, jak stare. To racjonalny strach — żaden test syntetyczny nie udowodni tego, co udowadnia tylko dwa tygodnie ruchu produkcyjnego.

Rozwiązaniem nie jest większy test ani dłuższa dokumentacja. Rozwiązaniem jest konfiguracja, w której to samo źródło wezwań — Grafana, Prometheus, Sentry — wysyła zdarzenie do obu narzędzi jednocześnie. PagerDuty wzywa zespół jak dotychczas. Nowe narzędzie cicho odbiera ten sam strumień, próbuje uruchomić swój łańcuch eskalacji, ale nikogo nie budzi.

W konfiguracji Alertmanager wygląda to mniej więcej tak:

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

Pierwszy URL — jak zwykle. Drugi — nowe źródło. Oba dostają to samo zdarzenie w tym samym momencie. Dwa tygodnie, nie jeden. Jeden tydzień nie daje wam weekendu, a weekend ma inny profil wezwań — inni ludzie w zespole, inny czas reakcji, inne typy incydentów.

Po dwóch tygodniach widzisz wszystko, co potrzebne do decyzji. Czy nowe narzędzie zauważyło wezwania, których PagerDuty nie złapał? Czy są przypadki, gdy łańcuch wybrał złą osobę? Czy SMS dotarł szybciej z jednego źródła niż z drugiego? Wszystkie pytania, na które nie da odpowiedzieć żaden cennik ani demo, dostają konkretną odpowiedź ze swojego własnego ruchu.

Najczęstszy efekt uboczny tego ćwiczenia — odkrycie martwych odbiorców w PagerDuty. Osoby, które dawno odeszły z firmy, telefony, które nigdy nie były aktualizowane, identyfikatory na Slacku, które nie zgadzają się z e-mailem. Zespół przez lata cicho omijał te problemy («aha, Mariusz już nie odbiera, dzwoń od razu do Anny»). Praca dwutorowa to bezlitośnie ujawnia. Sama ta korzyść zwykle uzasadnia ćwiczenie.

Kolejność przełączania, która działa

Większość zespołów myli się o kolejność. Naturalny odruch: zacznijmy od najważniejszego źródła, bo «tam najwięcej ryzyka, więc trzeba to zrobić jako pierwsze». To dokładnie przeciwnie do tego, co działa.

Najtańsze źródła pierwsze. Te, które generują wezwania raz w tygodniu, najwyżej raz w miesiącu. Synteza, mała usługa pomocnicza, integracja, której nikt nigdy nie używa, ale ma alarmy. Jeśli przeklikasz ją źle, dowiesz się za miesiąc, a do tego czasu masz przestrzeń do naprawy.

Najgłośniejsze źródła ostatnie. Te, które generują wezwanie przy każdym wdrożeniu, te, w których jest podstawowa działalność biznesowa. Do tego momentu zespół już zna nowe narzędzie. Łańcuch eskalacji jest sprawdzony w boju (poprzednie źródła przeszły przez nie wezwaniami w trakcie pracy dwutorowej). Ryzyko jest minimalne.

Konkretna kolejność, która działa w większości projektów, na które patrzyliśmy:

1. Monitoring syntetyczny (Pingdom, Better Stack)
2. Sentry albo Rollbar
3. Grafana
4. Prometheus / Alertmanager
5. Własne webhooki z waszych serwisów
6. Integracja z głównym serwisem przynoszącym przychód

Między krokami — dwa-trzy dni. Nie doba. Nie tydzień. Wystarczająco, żeby zdarzenie miało czas przylecieć, a łańcuch — odpracować. Na każdym kroku obowiązkowy test: wywołajcie sztuczne zdarzenie przez /api/v1/notifications/test lub równoważny endpoint nowego narzędzia. Nie sprawdzajcie tylko, że alarm pojawił się w interfejsie — przejdźcie pełną drogę aż do SMS-a lub dzwonka na telefon dyżurnego. Bez tego kroku nic się nie liczy.

Dzień przełączenia dla głównego źródła

Jeden czwartek, nie piątek. Nie wtorek rano po święcie. Zwykły roboczy czwartek o 14:00 waszego czasu.

Konkretne kroki:

1. W źródle #6 z waszej listy (tym przynoszącym przychód) wyłączcie webhook do PagerDuty.
2. Pozostawcie webhook do nowego narzędzia włączony.
3. Pozostawcie grafik dyżurów w PagerDuty włączony jeszcze tydzień. Kosztuje praktycznie nic, a daje ubezpieczenie, gdyby coś przegapić.
4. Poinformujcie zespół przez kanał drużyny. Jeden akapit: «od tej chwili źródło X wysyła wezwania przez [nowe narzędzie]. PagerDuty zostaje aktywny do następnego czwartku jako asekuracja».

Nie robicie ogłoszenia na zebraniu ogólnym. Nie piszecie wpisu na blogu. Nie zmieniacie procesu. Zwykły czwartek, zwykły dzień pracy, tylko jedno źródło wezwań pracuje teraz inaczej.

Tłumaczenie kierownictwu, kiedy ma sens, a kiedy nie

Migracja na nowe narzędzie powiadomień to nie jest decyzja techniczna. To decyzja finansowa, którą podejmuje ktoś, kto patrzy na faktury, nie na łańcuchy eskalacji. Argumenty techniczne mają wartość tylko wtedy, gdy potwierdzają lub obalają argument finansowy.

Argument finansowy jest prosty. Na planie PagerDuty Professional przy szesnastu wzywanych inżynierach roczny koszt to 4 032 dolary. Przy stałej opłacie — 348 dolarów. Różnica 3 684 dolary. Migracja trwa 22 godziny pracy, czyli mniej więcej 800 dolarów kosztu jednorazowego. Zwrot inwestycji następuje pomiędzy miesiącem siódmym a dziesiątym.

Na planie Business te same liczby wyglądają inaczej: 7 524 dolary oszczędności rocznej, zwrot około czwartego miesiąca. Na Digital Operations Plus — zwrot w trzecim miesiącu, oszczędność ponad 11 tysięcy dolarów rocznie.

Tu jest jedyny punkt, w którym warto się zatrzymać. Jeśli wasz zespół intensywnie korzysta z konkretnych funkcji PagerDuty, których nowe narzędzie nie ma — zintegrowana analiza po incydencie, sklep z setkami integracji, dojrzała aplikacja mobilna — kalkulacja wygląda inaczej. Nie kosztem migracji, tylko kosztem utraconej funkcjonalności. Jeśli te funkcje rzeczywiście są używane, a nie wykupione i zapomniane.

Co zostaje po migracji, czyli pytanie, które rzadko ktoś zadaje

Nie pytajcie, czy migracja jest tania. Jest. Nie pytajcie, czy oszczędność jest realna. Jest. Pytajcie raczej tego, czego migracja was nauczy o własnym zespole. W mojej obserwacji każda migracja z PagerDuty, która faktycznie się odbyła, wyciągała na światło dzienne dwie rzeczy — albo zespół, który źle skonfigurował łańcuchy eskalacji w starym narzędziu i przepisał je lepiej w nowym, albo zespół, który dobrze skonfigurował łańcuchy, ale przez lata bał się je upraszczać. Obie sytuacje są korzystne. Druga z nich, według mojego doświadczenia, częstsza.