Ölümden Sonra: Kullanıcı oturumu açarken beklenmedik bir 500 hatası meydana geldi

Özet#

18 Temmuz 2024 tarihinde, Logto Cloud kimlik doğrulama hizmetlerinden 500 Internal Server Error hatasıyla bir hizmet kesintisi yaşandı.

• Etkilenen kullanıcılar: Kimlik doğrulamaya çalışan tüm Cloud kullanıcıları
• Etkilenen bölgeler: Avrupa ve ABD
• Ciddiyet: Kritik, kullanıcı oturumu açma deneyimini bozuyor

Temel neden#

Son Cloud dağıtımı sırasında, veritabanı şeması ile ilgili bir kırılma değişikliği, aşama ve üretim ortamları arasındaki geçiş sırasında oturum açma deneyimi API'sinin başarısız olmasına neden oldu.

Zaman Çizelgesi#

• 2024-07-18 08:57 (UTC): Logto Cloud'a güncellemeler dağıtıldı
• 2024-07-18 09:28 (UTC): İlk kullanıcı bir 500 hatası bildirdi
• 2024-07-18 09:31 (UTC): Geliştirme ekibi sorunu fark etti ve araştırmaya başladı
• 2024-07-18 09:32 (UTC): Sorun otomatik olarak çözüldü
• 2024-07-18 09:40 (UTC): Temel neden tespit edildi

Olay analizi#

Veritabanı kırılma değişikliği nedir ve neden?#

Şu anda kullanıcıların kendi web sayfalarıyla Logto oturum açma deneyimini özelleştirmelerine olanak tanıyan "Kendi UI'ni Getir" adlı yeni bir özellik geliştiriyoruz. Bu özellik, özel UI yapılandırmasını depolamak için sign-in-exp tablosuna yeni bir sütun eklenmesini gerektiriyor.

Geliştirme sırasında bazı gereksinim değişiklikleri nedeniyle özellik yayını ertelendi, ancak şema değişikliğinin ilk kısmı birkaç hafta önce üretime dağıtılmıştı, henüz kullanılmıyor olmasına rağmen. Bir veritabanı sütunu güncellemesi, bu PR'de tanıtıldı.

Maalesef, bu değişiklik geriye dönük uyumlu değildi ve eski koddan gelen API isteklerinin yeni veritabanı ile iletişim kurarken başarısız olmasına neden oldu.

Logto Cloud'un yeni bir versiyonu nasıl dağıtılır?#

Logto Cloud'un yeni bir sürümünü dağıtırken, önce onu aşama ortamına dağıtırız ve ardından aşama ve üretim ortamlarını değiştiririz. Süreç şu şekildedir:

1. Veritabanı değişiklik komut dosyasını çalıştırın ve veritabanını güncelleyin.
2. Yeni kaynak kodunu aşama sunucusuna dağıtın.
3. Aşama sunucusunu çalıştırın ve testleri gerçekleştirin.
4. Aşama ve üretim sunucularını değiştirin, böylece "aşama" üretim haline gelir ve kullanıcılar hiç kesinti olmadan yeni sürüme erişebilir.

Ancak, her iki ortam da aynı veritabanını paylaşıyor ve tüm süreç zaman alıyor. Bu nedenle, veritabanı güncellemesi ve ortam değişimi arasındaki zaman aralığında, çevrimiçi kullanıcılar eski kodla üretim ortamında kalırken yeni veritabanı ile iletişim kurmaya çalışır.

Bu, olayın temel nedeniydi ve 35 dakika içinde otomatik olarak çözülmesinin nedeniydi.

Bu, kod inceleme sürecinde neden ele alınmadı?#

Veritabanı değişikliklerinin geriye dönük uyumluluğunu kontrol etmek için bir CI görevi VAR. Ancak, daha önce PR'yi birleştirmeden önce CI kontrolünü geçmesi gerekmiyordu. Bunun nedeni, genellikle geliştirme aşamasının birkaç sprint içinde kısa olması ve şema değişikliklerinin ilk ve ikinci kısmının genellikle aynı sürüm aşamasına dahil edilmesi gerektiğidir.

Bu sefer, özellik yayını ertelendi ve şema değişiklikleri iki dağıtım arasında yayıldı. Geliştirici, CI başarısızlığının beklenen bir durum olduğunu varsaydı ve incelemecilere PR'yi birleştirmelerini engellememesi gerektiğini bildirdi.

Kesinlikle bir iletişim açığı vardı ve sonuçta gerekli geriye dönük uyumluluk desteği sağlanmadan PR birleştirildi.

Alınan dersler#

• Veritabanı şemasıyla ilgili bir kırılma değişikliği yaparken, her zaman eski sürüm kaynak kodu ile geriye dönük uyumluluğu dikkate almalıyız.
• Bir veritabanı sütununu değiştirirken, şemayı doğrudan değiştirmek yerine, eskiyi kullanımdan kaldırma ve geçiş yaklaşımını kullanmalıyız.
• Geliştiricinin, yayın süreci ve zaman çizelgesi hakkında daha fazla farkındalığa sahip olması gerekir.

Düzeltici ve önleyici tedbirler#

• ✅ Veritabanı geriye dönük uyumluluk CI kontrolünün, şema değişikliği içeren bir PR'yi birleştirmeden önce geçmesi gerekiyor.
• ✅ Ekip içinde geriye dönük uyumluluğun önemi vurgulanmalı.