Firebase postmortem: İki satırlık flag temizliği iOS uygulamalarını çökertti, durum panelleri ise yeşil kaldı

Ne oldu

28 Eylül'de Firebase'in remote-config sistemindeki rutin bir bakım değişikliği, dünyanın dört bir yanındaki iOS uygulamalarını devre dışı bıraktı; Firebase bunu dört gün sonra, 2 Ekim'de kamuya açık şekilde açıkladı. Şirketin postmortem'ine göre, Pasifik Saati ile 17:38'de yapılan bir temizlikte eski bir legacy remote-config flag'i kaldırıldı. iOS SDK, silinen flag'e hâlâ bir referans tutuyordu ve istemciler onu getirmeye çalıştığında arama ölümcül bir hatayla sonuçlandı. Yaklaşık üç dakika içinde, ortaya çıkan hatalı yapılandırma payload'ı Firebase'in küresel müşteri tabanına ulaştı ve etkilenen uygulamalar açılışta çökmeye başladı.

Mobil ekipler remote-config flag'lerini kill switch olarak kullanır: hatalı bir özelliği yeni bir uygulama binary'si yayınlamadan devre dışı bırakmanın bir yolu. Raporun bir dev.to analizinin de belirttiği gibi, bu durum arıza modunu özellikle rahatsız edici kılıyor. Kesinti, flag'lerin koruduğu özelliklerden değil, flag'lerin kendisinde yapılan bakım işlemlerinden kaynaklandı — rapora göre yalnızca iki satırlık bir değişiklikten.

Dakika dakika zaman çizelgesi

dev.to tarafından özetlenen postmortem, olayın saatini şöyle ortaya koyuyor:

• 17:38 — eski flag kaldırılıyor
• 17:41 — hatalı payload küresel olarak yayılıyor; istemciler açılışta çöküyor
• 17:59 — çökme uyarıları yükseliyor ve ilk harici hata raporları GitHub'a düşüyor; nöbetçi mühendis sayfalıyor
• 19:16 — sorumlu değişiklik tespit ediliyor ve geri alma (rollback) süreci başlıyor
• 19:52 — rollback tamamen dağıtılıyor

Bu, tespitin yirmi dakikanın altında, hatalı payload'ın hizmet vermeye başlaması ile tam çözüm arasında ise iki saat on bir dakika geçtiği anlamına geliyor. Yükselen hata oranları bu pencerenin çok ötesinde devam etti; rapor bunu istemci tarafı hata raporlamasındaki gecikmeye bağlıyor.

Yeşil paneller, çöken telefonlar

Olayı Firebase'in müşteri tabanının ötesinde dikkat çekici kılan detay, durum panellerinin hiç kırmızıya dönmemesiydi. Postmortem bunun sebebini açıklıyor: paneller sunucu tarafı metrikleri izliyor ve sunucular sağlıklı kaldı. Arıza tamamen istemci tarafında yaşandı; panellerin bakmadığı yerde.

dev.to yazısına göre durum sayfasının güncellenmesi saatler süren manuel bir müdahale gerektirdi; bu da olay sırasında kesintinin en güncel kamuya açık kaydının bir GitHub issue başlığı olduğu anlamına geliyordu. dev.to yorumuna göre bu iletişim boşluğu, config hatasının kendisinden daha fazla, retrospektifte birinci sırada yer almayı hak eden bulgu.

Raporun söylemediği şeyler

dev.to analizi ayrıca postmortem'in söylemediği noktalara da dikkat çekiyor. Etki alanı yalnızca çok sayıda iOS uygulamasının etkilenmesi olarak tanımlanıyor — uygulama, cihaz veya SDK sürümü sayısı verilmiyor. Üçüncü taraf haberler rakamı binlerle ifade ediyordu, ancak bu sayı Google'ın kendi loglarından tam toplamı okuyabilecekken, muhabirlerin çökme raporlarını saymasından geldi. Rapor ayrıca mevcut testlerin değişiklikten geçtiğini belirtiyor ama test paketinin adını vermiyor veya neyi kapsadığını anlatmıyor; bu da diğer ekiplerin kendi testlerinin aynı hatayı yakalayıp yakalamayacağını değerlendirememesine yol açıyor.

Çözüm

Firebase, eksik veya bozuk flag'lerin çökme yerine önbelleğe alınmış varsayılanlara dönmesi için bir SDK yaması taahhüt etti. dev.to yazısı itibarıyla yamanın bir hafta içinde geleceği sözü verilmişti; bu da etkilenen SDK hattındaki her uygulamanın, yama yayınlanana kadar aynı gizli hatayı taşıdığı anlamına geliyor. Şirketin dile getirdiği ders, yapılandırma değişikliklerini küresel müşteri tabanının geniş bir kesimine hızlıca iletmenin gereksiz risk oluşturduğudur — ima edilen şu: flag'ler de en az binary'ler kadar aşamalı rollout ve canary'lere ihtiyaç duyuyor, çünkü kötü bir flag'i yakalayacak bir build adımı yok.

Neden önemli

İki ders Firebase'in çok ötesine genellenebilir. Birincisi, güvenlik mekanizmalarının da bir yaşam döngüsü var ve bir kontrolün temizliği, migrasyonu veya refactor'u neredeyse hiçbir zaman o kontrolün kendi testlerini devralmaz. Kill switch'ler, circuit breaker'lar ve yedeklerin hepsi tam olarak bu düzene maruzdur: sisteminizi bozan yapılandırma, sizi kurtarması beklenen yapılandırma olabilir. İkincisi, yalnızca sunucuları izleyen bir durum sayfası, herhangi bir istemci tarafı kesinti sırasında yeşil kalacaktır. İstemci yazılımı yayınlıyorsanız ve hiçbir istemci tarafı sinyal toplamıyorsanız — çökme raporlama, bir canary uygulaması, üçüncü taraf bir izleyici — bir sonraki olayınız birebir böyle görünebilir: sağlıklı paneller, çöken uygulamalar ve gerçek hikâyenin GitHub'da ortaya çıkması.