GitHub 17 Ağustos Kesintisi: Nedeni ve Sonraki Adımlar
GitHub, 17 Ağustos’ta 7 saat 47 dakika süren büyük bir kesinti yaşadı. Olay github.com’u, kimlik doğrulama servislerini, GitHub Actions’ı, API’leri, pull request ve issue akışlarını ve Copilot’u etkiledi; dünya genelinde geliştiricilerin ve kurumların iş akışı sekteye uğradı. GitHub Altyapı ekibinden Vlad Fedorov’un açıklaması olayın kök nedenlerini, alınan önlemleri ve önümüzdeki dönemin güvenilirlik çalışmalarını özetliyor.
Kesintide ne oldu?
GitHub’ın incelemesine göre kesinti, trafiğin yeni bir zirveye ulaştığı sırada Central US veri merkezindeki kritik bir altyapı bileşeninin bu artışla ölçeklenememesiyle başladı. Ortaya çıkan kapasite baskısı sistemler arasında yayıldı, kimlik doğrulama hataları tetiklendi ve birden fazla GitHub servisi bundan etkilendi.
Toparlanma koordineli müdahale gerektirdi. Ekipler trafiği yeniden yönlendirdi, etkilenen altyapıyı izole etti ve servisleri aşamalı olarak yeniden ayağa kaldırdı. Servislerin büyük bölümü aynı gün içinde normale döndü; Copilot servislerinin bir kısmının toparlanması ise daha uzun sürdü. Bu servislerdeki hatalar istemci tarafında bir yeniden deneme (retry) döngüsünü tetikleyip toparlanma sırasında trafiği daha da artırdı. Bu davranış azaltılmadan trafiğin güvenle geri yönlendirilmesi mümkün olmadı.
Fedorov’a göre ne 17 Ağustos ne de bir önceki 6 Ağustos’taki Actions arızası bir kod veya yapılandırma değişikliğinden kaynaklandı. Her iki olay da özünde kapasite arızası olarak sınıflandırılıyor: Kritik bileşenler, talep kapasitelerini aşmadan önce ölçeklenemedi.
Büyüyen yük ve altyapı baskısı
GitHub sistem üzerindeki baskıyı büyüme rakamlarıyla açıklıyor. Nisan’dan bu yana aylık commit sayısı 1,4 milyardan 2,9 milyara çıktı. Fedorov, bu büyümenin altyapı üzerinde ciddi bir baskı yarattığını kabul ediyor ama bunun yaşanan kesintileri mazur göstermediğini de ekliyor.
Yıl başında paylaşılan güvenilirlik taahhütleri kapsamında GitHub üç önceliğe odaklandığını belirtiyor: kapasite eklemek, verimliliği artırmak ve mimari darboğazları ortadan kaldırmak. Bu çerçevede eklenen kaynaklar şöyle:
- 3 milyondan fazla CPU çekirdeği
- 120 petabayt yüksek hızlı depolama
- Kayda değer ölçüde ek ağ kapasitesi
Ekip, mevcut veri merkezlerinde güç bütçesinin izin verdiği kadar donanım yerleştirdiğini ve aynı zamanda Azure’a geçişi hızlandırdığını aktarıyor. Bugün Azure, GitHub platform yükünün yaklaşık %58’ini ve tüm Git operasyonlarının yarısını karşılıyor. Bu oran Mayıs’ta platform yükü için yalnızca %12 seviyesindeydi. Genişleyen altyapı ayak izi, GitHub Actions iş çalıştırmalarındaki büyümenin sürdürülmesini de destekliyor.
Monorepo ölçeklendirme ve mimari değişiklikler
Azure’un altyapısı ve kapasitesi, GitHub’ın en büyük monorepo’ları ölçeklendirme çalışmalarını da hızlandırıyor. Sıradaki kilometre taşı, okuma kapasitesini okuyucu sayısıyla doğrusal ölçekleyen ve sınırsız okuma operasyonuna imkan veren bir mimari. Bu mimarinin, en büyük monorepo’lardan başlayarak aşamalı biçimde devreye alınacağı belirtiliyor.
Fedorov, sorunun yalnızca ölçekten ibaret olmadığına dikkat çekiyor. Değişim hızı ve karmaşıklığı artarken mevcut operasyonel pratikler buna ayak uyduramadı. Ekipler ve kaynaklar; kullanılabilirliği artırmak için daha güçlü test süreçlerine, daha güvenli sürüm yayınlarına (rollout), iyileştirilmiş gözlemlenebilirliğe (observability) ve daha etkili alarm mekanizmalarına yönlendirildi. Kritik sistemlerin birbirinden yalıtılması ve aralarındaki paylaşılan bağımlılıkların kaldırılması için de çalışma sürüyor. Bu adımların hem olası bir kesintinin ihtimalini azaltması hem de etkisini sınırlaması hedefleniyor.
6 ve 17 Ağustos olaylarından çıkan iki acil aksiyon
GitHub, her kesintiden çıkardığı derslerin doğrudan kullanılabilirlik iş akışına eklendiğini belirtiyor. Ağustos ayındaki iki olay iki acil değişikliği beraberinde getirdi:
- Tutarlı retry politikaları: Servisler arası etkileşimlerde tutarlı yeniden deneme limitleri, retry bütçeleri ve değişken zaman aşımı (timeout) değerleri uygulanıyor. Amaç, retry fırtınalarını ve zincirleme yük artışını önlemek.
- Düşük öncelikli alarmların gözden geçirilmesi: Ani trafik sıçramalarında arızalanma potansiyeli taşıyan bileşenleri belirlemek için düşük öncelikli CPU ve bellek alarmları yeniden değerlendiriliyor.
Güvenilirlik taahhüdü
Fedorov, yüksek kullanılabilirlik hedefinin yalnızca teknik bir taahhüt olmadığını vurguluyor. Geliştirici topluluğunun yazılım geliştirme, dağıtma ve işletme süreçlerinde GitHub’a bağımlı olduğunu belirten yazı, 17 Ağustos’ta bu güvenin karşılanamadığını açıkça kabul ediyor. Ekibin mesajı net: Güven, platformun ölçeklenmesi ve güvenilirliğiyle yeniden kazanılacak.
Kaynaklar ve İleri Okuma
- The August 17 outage, and the work ahead — GitHub Blog
- 17 Ağustos olayına ilişkin GitHub Status kök neden analizi
- 6 Ağustos GitHub Actions olayı — GitHub Status
- GitHub’ın kullanılabilirlik sorunlarına ilişkin önceki açıklama
- GitHub kullanılabilirliği hakkında güncelleme
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments