Koniec życia Opsgenie: wyłączenie w 2027 roku i alternatywy

Spis treści

• Daty końca życia Opsgenie
• Co przestanie działać po 5 kwietnia 2027 roku?
• Oficjalny zamiennik: Jira Service Management
• Kiedy lekka alternatywa dla Opsgenie ma sens
• Jak przetestować Echobell przed wyłączeniem Opsgenie
• 1. Wybierz jedno krytyczne źródło alertów
• 2. Utwórz kanał w Echobell
• 3. Dodaj drugi cel webhooka
• 4. Świadomie przypisz poziomy pilności
• 5. Prowadź obie ścieżki podczas prawdziwego dyżuru
• 6. Spisz, czego Echobell nie zastępuje
• Lista kontrolna migracji z Opsgenie
• Najczęściej zadawane pytania
• Czy Opsgenie jest wycofywane?
• Co zastępuje Opsgenie?
• Czy Echobell może w pełni zastąpić Opsgenie?
• Czy możemy korzystać z Echobell w trakcie migracji z Opsgenie?
• Kiedy zacząć migrację?
• Wybierz najmniejszy zamiennik, który wykonuje prawdziwą pracę

Opsgenie zostanie wyłączone 5 kwietnia 2027 roku. Po tej dacie produkt przestanie być dostępny, jego integracje i REST API przestaną działać, a dane klientów, które nie zostaną zmigrowane, zostaną usunięte.

Dla większości zespołów oficjalna ścieżka Atlassiana do Jira Service Management jest najbezpieczniejszym pełnym zamiennikiem. Jeśli jednak używasz Opsgenie głównie po to, aby zamieniać zdarzenia z monitoringu w pilne alerty na telefonie, to dobry moment, aby zdecydować, czy nadal potrzebujesz kompletnej platformy do zarządzania incydentami — czy raczej mniejszej warstwy powiadomień.

Ten przewodnik wyjaśnia, jaki jest termin, co się zmienia i jak wybrać ścieżkę migracji bez luki w pokryciu dyżurów.

Daty końca życia Opsgenie

Dotychczasowi klienci mogą korzystać z Opsgenie aż do daty wyłączenia, ale czekanie do ostatnich tygodni to ryzyko, którego łatwo uniknąć. Atlassian zaleca zakończenie przenosin przed 5 kwietnia 2027 roku. Aktualny harmonogram znajdziesz na oficjalnej stronie migracji Opsgenie oraz w FAQ o licencjonowaniu Opsgenie.

Co przestanie działać po 5 kwietnia 2027 roku?

Po wyłączeniu Opsgenie zespoły tracą dostęp do produktu i do wszystkich procesów, które wciąż od niego zależą. Obejmuje to:

• alertowanie i procesy dyżurów w Opsgenie,
• aplikację mobilną Opsgenie,
• pozostałe integracje Opsgenie,
• punkty końcowe REST API Opsgenie,
• dane i konfiguracje, które nie zostały zmigrowane.

Odcięcie dotyczy czegoś więcej niż panelu w przeglądarce. Monitor może dalej wykrywać awarię, podczas gdy jego stara integracja z Opsgenie po cichu staje się ślepą uliczką. Przewodnik Atlassiana co się dzieje po wyłączeniu Opsgenie zaleca przeniesienie w pierwszej kolejności wszystkich procesów alertowania i dyżurów.

Oficjalny zamiennik: Jira Service Management

Jira Service Management jest domyślnym wyborem, gdy chcesz zachować szerszy model pracy z Opsgenie: alerty, grafiki, zasady eskalacji, procesy obsługi incydentów i dane historyczne.

Właściciele Opsgenie mogą otworzyć Settings → Plan your move, aby zobaczyć rekomendowany plan Jira Service Management i zaplanować migrację. Atlassian deklaruje, że większość danych i konfiguracji Opsgenie można zsynchronizować automatycznie po wybraniu i zatwierdzeniu planu docelowego.

Nie zakładaj, że każda funkcja przeniesie się bez zmian. Porównanie funkcji przygotowane przez Atlassiana wskazuje metody kontaktu zależne od planu, funkcje wycofywane, integracje wymagające ręcznej konfiguracji oraz punkty końcowe API, które trzeba zaktualizować.

Ważne ograniczenie: wbudowane narzędzie migracyjne obsługuje cele w Atlassian Cloud, a nie Jira Service Management Data Center. Zespoły pozostające na Data Center muszą rozważyć inną drogę, zamiast liczyć na bezpośrednią migrację. Atlassian opisuje to ograniczenie w przewodniku po planowaniu migracji.

Kiedy lekka alternatywa dla Opsgenie ma sens

Nie każde konto Opsgenie korzysta z rotacji, drzew eskalacji, osi czasu incydentów i analityki. Część małych zespołów używa go do węższego zadania:

1. Narzędzie monitorujące wykrywa krytyczne zdarzenie.
2. Integracja przekazuje je dalej.
3. Telefon robi wystarczająco dużo hałasu, aby ktoś zareagował.

Jeśli tak wygląda Twoja konfiguracja, wymiana całej platformy może dołożyć więcej procesu, niż potrzebujesz. Echobell to skupiona warstwa dostarczania, która przyjmuje wyzwalacze webhook lub e-mail i wysyła zwykłe, czasowo krytyczne albo telefoniczne alerty na urządzenia mobilne.

Echobell nie jest zamiennikiem Opsgenie jeden do jednego. Nie zastąpi zaawansowanego planowania dyżurów, zasad eskalacji, dowodzenia incydentem ani raportowania poincydentalnego. Do tych procesów użyj Jira Service Management albo innej pełnej platformy zarządzania incydentami.

Echobell może się sprawdzić, gdy:

• Twoje źródło monitoringu samo decyduje, które zdarzenia są krytyczne.
• Za dyżury odpowiada mała, stabilna grupa osób.
• Chcesz dostarczać alerty prosto z webhooka na telefon, bez przebudowy monitoringu.
• Potrzebujesz różnych poziomów pilności dla zdarzeń krytycznych, ostrzegawczych i informacyjnych.
• Chcesz przetestować samo dostarczanie alertów, zanim zmienisz resztę stosu.

Decyzję funkcja po funkcji ułatwi porównanie Echobell a Opsgenie.

Jak przetestować Echobell przed wyłączeniem Opsgenie

Najbezpieczniejsza migracja to test równoległy, a nie jedno przełączenie tuż przed terminem.

1. Wybierz jedno krytyczne źródło alertów

Zacznij od usługi produkcyjnej z jasną odpowiedzialnością i przewidywalną liczbą alertów. Nie przenoś wszystkich integracji naraz.

2. Utwórz kanał w Echobell

Utwórz kanał dla tej usługi i udostępnij go osobom, które mają dostawać alert. Każdy subskrybent może wybrać na swoim urządzeniu odpowiednie zachowanie powiadomień.

3. Dodaj drugi cel webhooka

Zostaw działającą ścieżkę do Opsgenie i dodaj w źródle monitoringu webhook kanału Echobell. Podstawowy testowy payload wygląda tak:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Production API is down",
    "body": "Health check failed in us-east-1",
    "severity": "critical",
    "externalLink": "https://status.example.com/incidents/123"
  }'

W skryptach i menedżerach sekretów używaj tokena zastępczego; nie zapisuj prawdziwego adresu URL webhooka kanału w repozytorium. Dokumentacja webhooków opisuje zmienne payloadu i szablony.

Jeśli źródło obsługuje pocztę, ale nie webhooki, użyj zamiast tego wyzwalacza e-mail.

4. Świadomie przypisz poziomy pilności

Alerty w formie połączenia zarezerwuj dla zdarzeń wymagających natychmiastowej reakcji. Alerty czasowo krytyczne przeznacz na ważne ostrzeżenia, a zwykłe powiadomienia na zdarzenia informacyjne. Dzięki temu pilna ścieżka pozostanie wiarygodna, zamiast odtwarzać zmęczenie alertami w nowej aplikacji.

5. Prowadź obie ścieżki podczas prawdziwego dyżuru

Porównaj czas dostarczenia, czytelność komunikatów, liczbę fałszywych alarmów i zachowanie osób reagujących. Testuj też powiadomienia o powrocie do normy, nie tylko o awariach.

6. Spisz, czego Echobell nie zastępuje

Zanim usuniesz Opsgenie dla danej usługi, przypisz właściciela każdemu pozostałemu wymaganiu dotyczącemu grafików, eskalacji, potwierdzeń, audytu czy raportowania. Jeśli te wymagania są kluczowe, zostaw je w pełnym systemie zarządzania incydentami.

Lista kontrolna migracji z Opsgenie

Przejdź przez tę listę przed wyłączeniem 5 kwietnia 2027 roku:

• Zinwentaryzuj każdą integrację przychodzącą, heartbeat, klienta API i integrację e-mail.
• Wyeksportuj lub zmigruj dane historyczne, które Twój zespół musi zachować.
• Zapisz grafiki, zasady eskalacji, reguły powiadamiania i odpowiedzialności.
• Wskaż wycofywane funkcje i integracje wymagające ręcznego zastąpienia.
• Zaktualizuj skrypty odwołujące się do punktów końcowych opsgenie.com i opsgenie.net.
• Przetestuj alerty, powroty do normy, potwierdzenia i dostarczanie poza godzinami pracy.
• Prowadź starą i nową ścieżkę równolegle przez co najmniej jeden reprezentatywny cykl dyżuru.
• Usuń starą ścieżkę dopiero wtedy, gdy osoby dyżurujące potwierdzą, że zamiennik działa.

Najczęściej zadawane pytania

Czy Opsgenie jest wycofywane?

Tak. Sprzedaż nowych licencji zakończyła się 4 czerwca 2025 roku, a wsparcie dla Opsgenie kończy się 5 kwietnia 2027 roku. Atlassian zapowiada, że produkt zostanie wtedy wyłączony i przestanie być dostępny.

Co zastępuje Opsgenie?

Oficjalną ścieżką zamiany według Atlassiana jest Jira Service Management, w którym konsolidowane są funkcje alertowania i dyżurów z Opsgenie. Właściwa alternatywa zależy od tego, czy Twój zespół potrzebuje pełnego zarządzania incydentami, czy tylko niezawodnego dostarczania alertów.

Czy Echobell może w pełni zastąpić Opsgenie?

Nie. Echobell zastępuje warstwę pilnych powiadomień mobilnych w odpowiednich procesach. Nie odtwarza grafików Opsgenie, drzew eskalacji, procesów zarządzania incydentami ani raportowania.

Czy możemy korzystać z Echobell w trakcie migracji z Opsgenie?

Tak. Skieruj jedno źródło alertów do obu celów, sprawdź dostarczanie podczas prawdziwego cyklu dyżuru i utrzymuj Opsgenie aktywne, dopóki nowa ścieżka się nie sprawdzi.

Kiedy zacząć migrację?

Inwentaryzację i test pilotażowy zacznij już teraz. Ostateczna data migracji zależy od liczby integracji, wymagań zgodności oraz tego, czy przechodzisz na Jira Service Management, czy przeprojektowujesz cały stos alertowania.

Wybierz najmniejszy zamiennik, który wykonuje prawdziwą pracę

Wyłączenie Opsgenie wyznacza twardy termin, ale nie oznacza, że każdy zespół potrzebuje takiego samego zamiennika.

Wybierz Jira Service Management, jeśli polegasz na Opsgenie jako na kompletnym systemie dyżurów i zarządzania incydentami. Rozważ skupioną warstwę dostarczania, jeśli logika kierowania alertów jest już w Twoich monitorach, a głównym wymaganiem jest szybkie dostarczenie krytycznego zdarzenia na właściwe telefony.

Pobierz Echobell na iPhone'a albo zainstaluj z Google Play, a następnie przetestuj jeden produkcyjny alert, gdy dotychczasowa ścieżka Opsgenie jest jeszcze aktywna.