GitHub ekim ayında sekiz performans olayı bildirdi

GitHub kullanılabilirlik raporu ne söylüyor?

GitHub kullanılabilirlik raporu, platformun ekim ayındaki güvenilirlik tablosunu yalnızca olay sayısıyla değil, altyapı geçişi ve kapasite ölçümleriyle birlikte ele alıyor. GitHub, ekimde hizmetlerinde performans düşüşüne yol açan sekiz olay yaşandığını bildirdi. Şirketin değerlendirmesine göre ay boyunca bağımsız biçimde ölçeklenebilen Azure kapasitesi eklendi ve arızaların daha geniş etki yaratmasına yol açabilecek bazı yollar kaldırıldı.

Bununla birlikte raporun temel sonucu, kapasite büyütmenin tek başına yeterli olmadığı yönünde. Yazma kesintileri, veri taşımaları sırasında izleme eksikleri ve bölgesel ağ aksaklığı; daha güvenli operasyonlar, daha güçlü bileşen yalıtımı ve doğrulanmış bölgesel kurtarma süreçlerine ihtiyaç olduğunu gösterdi. Bu, raporda yer alan şirket değerlendirmesi; sekiz olayın ortak bir tekil nedene bağlandığı anlamına gelmiyor.

Rapor, kullanılabilirliği ölçerken hangi olayların kayda alındığını veya sekiz olayın tamamının ayrıntılı metodolojisini sunmuyor. Bu nedenle veriler, GitHub’ın kendi aylık operasyon özeti olarak okunmalı; farklı platformların erişilebilirlik istatistikleriyle doğrudan karşılaştırma yapmak için yeterli ortak ölçüm çerçevesi bulunmuyor.

Azure Central US geçişinin ölçümleri

GitHub’ın 9 Kasım itibarıyla verdiği sayılara göre 151 üretim hizmetinin 140’ı ve 50 MySQL birincil sisteminin 32’si Azure Central US üzerinde çalışıyordu. Aynı ortam, taşınmış hizmetlerdeki okuma trafiğinin yüzde 63’ünü, monolit uygulamadaki okumaların yüzde 66’sını ve Git okumalarının yüzde 52’sini karşıladı.

Şirket, Central US bölgesindeki dokuz Kubernetes kümesinin tamamında işlem kapasitesini artırdığını ve toplam kapasiteyi iki katın üzerine çıkardığını belirtiyor. Rapor bu genişlemeyi, mevcut veri merkezinin daha önce karşıladığı en yüksek haftalık ortalama yükün üzerindeki büyümeyi Central US’in üstlenmesiyle ilişkilendiriyor. Bu ifade, eski ortamın önceki çalışma aralığının ötesine zorlanmadan büyüme için alan açıldığı yönündeki GitHub değerlendirmesini yansıtıyor.

Trafik tarafında öne çıkan ölçüm, taşınmış hizmet trafiğinin marttan beri yüzde 82 artmış olması. Ancak bu artışın nedenlerine, kullanıcı davranışına ya da belirli ürünlerin etkisine ilişkin raporda ek veri yer almıyor. Dolayısıyla yüzde 82’lik değişim, doğrudan Azure geçişinin sonucu olarak değil, geçiş sürecinde taşınan iş yükünün gözlenen büyümesi olarak değerlendirilmelidir.

Yük azaltma çalışmalarında bildirilen sonuçlar

GitHub, ekim döneminde bazı dar kapsamlı iyileştirmelerin ölçülebilir sonuçlar verdiğini aktardı. GitHub Actions tarafındaki değişikliklerin, kritik Azure kontrol düzlemi istekleri için kapasiteyi artırdığı belirtildi. Ayrı bir NAT ağ geçidi önlemi ise kullanım oranını yüzde 85 azalttı. Şirkete göre değişiklik sırasında dört üretim işi başarısız oldu; bu önlem olmadan yaklaşık 800 işin başarısız olmasının beklendiği ifade edildi.

Veritabanı yükünü azaltmak için de iki örnek verildi. Günlük 250 milyondan fazla isteği işleyen yüksek trafikli bir GitHub Actions uç noktası daha verimli bir hizmet yoluna taşındı; bunun tepe veritabanı okuma yükünü yüzde 85 düşürdüğü bildirildi. Depo konularında arama yapılabilmesi için en az üç karakter şartı getirilmesi de bu desenle ilişkili yavaş veya sonlandırılan sorguları yaklaşık yüzde 98 azalttı.

Bu rakamlar belirli müdahalelerin hedeflenen teknik metriklerdeki etkisini gösteriyor. Ancak rapor, bu değişikliklerin platformun genel kesinti oranını ne kadar düşürdüğünü hesaplamıyor. Ayrıca başarısız olması beklenen yaklaşık iş sayısı bir öngörü olduğundan, gerçekleşmiş olaylarla aynı türden bir ölçüm olarak ele alınmamalı.

5 Ekim’de Actions kuyrukları nasıl etkilendi?

Raporda ayrıntısı verilen olaylardan biri 5 Ekim’de 19.11 UTC’de başladı ve yaklaşık üç saat 45 dakika sürdü. Bu sürede GitHub tarafından barındırılan çalıştırıcılardaki GitHub Actions işleri olağandan çok daha uzun süre kuyrukta kaldı; bazı iş akışı çalıştırmaları başlayamadı. En kötü yaklaşık 90 dakikalık bölümde, bu çalıştırıcılardaki işlerin çoğu beş dakika içinde başlamadı.

GitHub, etkinin sağlıklı bölgelere yük devri yapılması ve kapasite eklenmesiyle hafiflediğini belirtti. Kullanıcıların kendi yönettiği çalıştırıcılar olaydan etkilenmedi. Actions ile derlenen GitHub Pages sitelerinin güncellenmesi yavaşladı; buna karşılık mevcut siteler normal şekilde hizmet vermeyi sürdürdü. Rapor ayrıca bazı kullanıcıların depo listelerinde, lisanslama ve faturalama sayfalarında ve bazı Copilot özelliklerinde hatalar gördüğünü kaydediyor.

Şirketin açıklamasına göre sorun, GitHub tarafından barındırılan çalıştırıcılara iş atayan hizmetin güvenilir çalışmamasından kaynaklandı. Kaynak metinde, bulut sağlayıcısı tarafındaki kısmi ağ arızasının bazı bağlantıları aksattığı belirtiliyor. Bu olay, bir kapasite sorununun ötesinde, bağlantı ve bağımlılık katmanındaki aksaklıkların geliştirici iş akışlarına nasıl yansıyabildiğine dair somut örnek oluşturuyor.

Yazma kesintileri ve bölgesel kurtarma gündemi

GitHub, 7 Ekim’deki yazma kesintilerinin veritabanı orkestrasyonu ile üretim yönlendirmesi arasındaki güvenli olmayan bir etkileşimi açığa çıkardığını bildirdi. 29 Ekim’deki Azure ağ aksaklığının ise Central US’in üç erişilebilirlik bölgesinin tamamını etkilediği ve en az 34.128 oturum açmış kullanıcıya yansıdığı kaydedildi. Kaynak metin, bu olayların daha ayrıntılı açıklamalarının raporun devamında bulunduğunu söylüyor; sağlanan metin bu ayrıntıları içermediğinden, neden veya etki konusunda bundan ileri bir sonuç çıkarmak mümkün değil.

Şirketin bir sonraki altyapı adımı East US 3 kurulumu. GitHub, bu çalışmanın planın yaklaşık bir hafta gerisinde olduğunu ve ilk doğrulanmış trafik artışını aralık ayının ilk haftasında hedeflediğini aktardı. Raporun öncelik sıralaması açık: önce erişilebilirlik, ardından kapasite, sonra özellikler. Ekim verileri de bu sıranın neden vurgulandığını gösteriyor; kapasite büyürken operasyon güvenliği, bağımlılık yalıtımı ve bölgesel toparlanma testleri eş zamanlı olarak kritik kalıyor.