Atlassian, Opsgenie verilerini servis Nisan 2027'de kapanırken migrate edilmeyenleri silecek

Atlassian, nöbet (on-call) uyarı servisi Opsgenie'yi 5 Nisan 2027'de kapatacak ve o tarihe kadar migrate edilmemiş tüm verileri silecek. Fluidify blogundan alınıp dev.to'da yayımlanan bir geçiş rehberi, ekipleri bu çıkış sürecinde yönlendiriyor ve Atlassian'ın Jira Service Management'a giden otomatik yolunun bile önemli miktarda yapılandırmayı geride bıraktığı konusunda uyarıyor.

Rehber işi beş aşamaya bölüyor — envanter, dışa aktarma, yeniden inşa, paralel çalıştırma ve geçiş — ve gerçekten yavaş kısımların nöbet çizelgeleri değil, Opsgenie'nin payload formatı etrafında kurulan özel yönlendirme, otomasyon ve entegrasyonlar olduğunu savunuyor.

Otomatik Jira geçişi geride ne bırakıyor

Rehberde anlatıldığı üzere Atlassian'ın geçiş sayfasına göre otomatik geçiş, Opsgenie verilerini müşterinin planladığı bir tarihte Jira Service Management'a senkronize ediyor; öncesinde 14 günlük bir demo geçişi, sonrasında ise 120 günlük paralel Opsgenie erişimi bulunuyor.

Ancak rehber, Atlassian'a atıf yaparak aktarılmayanları sıralıyor: Slack ve Microsoft Teams entegrasyonları elle yeniden bağlanıp yeniden kimlik doğrulaması gerektiriyor; action policy'ler taşınmıyor ve Jira Automation kuralları olarak yeniden inşa edilmek zorunda; çift yönlü entegrasyonlar yalnızca JSM Premium veya Enterprise'ta çalışıyor, dolayısıyla Free veya Standard'daki ekipler giden yönü kaybediyor; yaklaşık iki düzine güncel olmayan entegrasyon sürümü taşınabiliyor ama JSM'de yeniden oluşturulamıyor; takım atanmamış eski heartbeat'ler geride kalıyor; ve özel Opsgenie rolleri JSM'nin standart User rolüne düşürülebilir.

Geçmiş bir diğer zayıf nokta. Rehberde alıntılanan bir Atlassian topluluk başlığı, bir JSM geçişinde uyarılar ve rotasyonlar aktarılmasına rağmen incident ve postmortem kayıtlarının aktarılamadığını bildiriyor; bu yüzden rehber, aracın bunu kapsadığını varsaymak yerine uyumluluk veya postmortem kayıtları için gereken her şeyin dışa aktarılmasını öneriyor.

Daralan kesişim penceresi

Paralel erişim 5 Nisan 2027 kapanışının ötesine uzatılamayacağı için rehberin yazarı, 6 Aralık 2026'dan sonra planlanan geçişlerin vaat edilen 120 günden daha kısa bir kesişim süresi alacağını hesaplıyor. Yazar, Atlassian'ın bu rakamı yayımlamadığını açıkça belirtiyor ve ekiplere geçişi rezerve ederken kesin bitiş tarihlerini talep etmelerini öneriyor.

Beş aşama ve yavaş olanlar çizelgeler değil

Önce envanter geliyor: ekipler ve özel roller, rotasyonları ve aktif override'larıyla çizelgeler, escalation policy'ler, takım yönlendirme kuralları, entegrasyonlar ve API anahtarları, heartbeat'ler ve Opsgenie API'sini çağıran her script veya Terraform workspace — rehber, repository'lerde api.opsgenie.com ve GenieKey araması yapılmasını öneriyor. Her nesne tutulacak, yeniden inşa edilecek veya emekliye ayrılacak olarak işaretlenmeli.

Sonra, otomatik geçişten bağımsız olarak dışa aktarma geliyor. Çizelgeler iCalendar dosyaları olarak çekilebiliyor; ancak bunlar rotasyon kurallarını değil oluşan vardiyaları içeriyor. Bu yüzden rehber, yeniden inşa için referans olarak API üzerinden çizelge tanımlarının, uyarı ve incident geçmişinin ve tüm yapılandırmanın JSON olarak da alınmasını öneriyor.

İşin büyük kısmı yeniden inşa aşamasında: chat entegrasyonları, hedef platform için yeniden yazılacak otomasyon, 'sonraki veya önceki nöbetçi kullanıcı' gibi gelişmiş escalation alıcıları — bu bir Opsgenie Standard ve Enterprise özelliği olup başka yerde sadeleştirilmesi gerekebilir — ve Opsgenie'nin birebir JSON yapısına veya nesne kimliklerine göre kurulmuş her entegrasyon.

Atlassian'da kalmayacak ekipler için rehber hedef olarak PagerDuty, incident.io, Grafana Cloud IRM ve self-hosted açık kaynak seçeneklerini sayıyor. Çoğu rakip bir tür Opsgenie içe aktarıcısı sunuyor; ancak her birinin okuduğu şeyler önemli ölçüde farklılık gösteriyor. Bu nedenle rehber, satıcılardan içe aktarılan nesnelerin tam listesini istemeyi ve herhangi bir sözleşme imzalamadan önce içe aktarıcıyı kendi kurulumunuzun bir kopyası üzerinde test etmeyi öneriyor.

Geçişten önce paralel çalıştırma

Rehberin güvenlik ağı iki sistemi aynı anda çalıştırmak. Önce Opsgenie almaya devam ederken staging veya dahili bir araç gibi düşük riskli bir uyarı kaynağını yeni sisteme yönlendirin ve tüm yolu doğrulayın: uyarı geliyor, doğru takıma yönlendiriliyor, doğru gecikmeyle escalate ediliyor ve doğru kişiye doğru kanaldan ulaşıyor. Ardından üretim kaynaklarını tek tek ekleyin, en az bir tam nöbet rotasyonu boyunca ikisini birden çalıştırın; saat dışı devir teslimlere, geçişte hayatta kalmayan override'lara ve farklılaşan escalation zaman aşımlarına dikkat edin. Mühendislerin kesişim sırasında hangi sistemin yetkili olduğu konusunda de netliğe ihtiyacı var; böylece bir sistemde onaylanan uyarı diğerinde göz ardı edilmez.

Neden önemli

Opsgenie, üretim ortamı bozulduğunda insanları sayfa ile uyaran katman; bu yüzden bir yönlendirme kuralını veya escalation yolunu düşüren bir geçiş, bir incident bunu ortaya çıkarana kadar sessizce başarısız olur. Son tarih acımasız: migrate edilmeyen veriler Nisan 2027'de silinecek, yani yedek olarak kullanılmak üzere uykuda bir hesap bırakmak mümkün değil. Otomatik Jira geçişi ise gerçek olmakla birlikte adının ima ettiğinden daha dar — chat entegrasyonları, action policy'ler, çift yönlü senkronizasyon ve rol eşlemeleri hepsi elle çalışma gerektiriyor. Rehberin pratik mesajı şu: kapanışı tek tıkla bir aktarım değil, planlı bir paralel çalıştırmalı proje olarak ele alın ve kontrol listesinin gözden kaçırdıklarını tam bir rotasyon döngüsünün yakalayabileceği kadar erken başlayın.