Six Days, Three GitHub Incidents, One CI/CD Warning - blog cover illustration

Altı Gün, Üç GitHub Olayı, Bir CI/CD Uyarısı

yazar

7 Ekim 2026 tarihinde, UTC saatiyle 16:52'de, GitHub genelindeki yazma işlemleri o gün ikinci kez başarısız oldu. İşlemler, Git İşlemleri, Sorunlar ve Çekme İstekleri 17:01 UTC'ye kadar etkilendi. İlk önlem bir süre kazandırmıştı; ancak sorunu ortadan kaldırmamıştı.

Olayın tekrarı dokuz dakika sürdü. Bu, bir olay zaman çizelgesinde yazıldığında küçük görünebilir. Ancak bir dağıtımın bir itme işlemi, bir kontrol veya bir iş akışının ilerlemesini beklediği zaman, bu süre çok daha az küçükmüş gibi gelir.

Bu haber için beş olay URL'si önerildi, ancak sağlanan kaynak materyalde yalnızca üç olay metni yer alıyordu. Eksik olan ikisini uydurmayacağım. Mevcut üç rapor yine de bize faydalı bir sıralama sunuyor: 7 Ekim'de tekrarlanan bir yazma kesintisi, 12 Ekim'de bir veritabanı kapasite sorunu ve 13 Ekim'de gecikmiş iş akışı kayıtları.

Sinyal farklı semptomlara yayıldı.

Sunulan üç rapordaki ortak bileşen "Eylemler" idi. Bu, tek bir ortak temel nedenin olduğunu kanıtlamaz. GitHub, 7 Ekim'deki iki kesintiyi açıkça aynı temel nedene bağlarken, daha sonraki raporlar farklı arızaları tanımlamaktadır.

Beni ilgilendiren şey operasyonel yapı. 7 Ekim'de yazma işlemleri iki kez başarısız oldu. 12 Ekim'de kullanıcılar yeni Eylem çalıştırmalarını sıraya koymakta ve Kontroller API'si ile etkileşimde sorun yaşayabiliyordu. 13 Ekim'de iş akışları normal şekilde çalıştı, ancak günlükleri geç göründü.

Bunlar bir CI/CD hizmetinin farklı katmanlarıdır. Biri işi kabul eder veya kaydeder. Diğeri işi yürütmeye alır. Bir diğeri ise işin ilerlediğine dair kanıtları ortaya koyar. Sadece nihai iş akışı sonucuna bakarsak, bu katmanlar tek bir belirsiz şikayete dönüşür: "CI yine yavaşladı." Çok bilimsel. Neredeyse bir gösterge paneli başlığı için uygun.

Dolayısıyla, gözden kaçan sinyal, GitHub içindeki eksik bir uyarı olmak zorunda değildi. Herkese açık raporlar, GitHub'ın dahili ölçümlerini veya uyarı geçmişini sağlamaz. Durum sayfasını okuyan bizler için gözden kaçan sinyal, olayların dizisinin kendisidir: altı gün boyunca yazma yolları, kuyruk girişi, paylaşılan veritabanı kapasitesi ve işleme birikimleri yakınında tekrarlanan sorunlar.

Altı gün boyunca neler oldu?

7 Ekim tarihli raporda, daha önce yaşanan bir yazma işlemi kesintisinin tekrarlandığı belirtiliyor. GitHub, 16:52 ile 17:01 UTC saatleri arasında İşlemler, Git İşlemleri, Sorunlar ve Çekme İstekleri genelinde yaygın bir etki gözlemledi. Raporda, her iki kesintinin de aynı temel nedene dayandığı ve kalıcı bir çözümün hazırlandığı ifade ediliyor.

“Tüm sistemler normale döndü. Önlemleri aldık ve bir daha tekrarlanmasını beklemiyoruz.”

Beş gün sonra, 12 Ekim'de saat 11:51 UTC'de GitHub, çeşitli uygulama sayfalarında yüksek HTTP 500 yanıtları vermeye başladı. Sorunlar, Çekme İstekleri, Projeler ve Eylemler başarısız oldu. Müşteriler ayrıca web ve e-posta bildirimlerinde gecikmeler yaşadı.

Uygulama üzerindeki ani etki, bildirilen başlangıçtan elli dakika sonra, 12:41 UTC'de hafifletildi. Bildirimler ise çok daha uzun sürdü. 15:27 UTC'de toparlanmaya başladılar ve sistemin birikmiş işleri halletmesinin ardından 20:16 UTC'de tamamen ortadan kalktılar.

Teknik açıklama oldukça faydalı. Bildirim iletim hattındaki gizli bir durum, parçalara ayrılmış veritabanı kopyalarına karşı yüksek hacimli ve maliyetli bir sorgu oluşturdu. Bu da Sorunlar, Çekme İstekleri, Projeler ve Eylemler tarafından ihtiyaç duyulan veritabanı kapasitesini tüketti.

UTC saatiyle 12:33'te GitHub, Actions arayüzünün yüklenmesinde, Checks API'sinin kullanımında ve yeni Actions çalıştırmalarının kuyruğa alınmasında olası sorunlar olduğunu belirtti. Bu durum, çalıştırıcı eksikliği olarak tanımlanmadı. Bunun yerine, paylaşılan veritabanı kapasitesinin başka yerlerde tüketilmesi ve kuyruğa alma işlemlerinin de bu durumdan etkilenmesi söz konusu oldu.

13 Ekim'de, yaklaşık 20:42 UTC'de, bir altyapı arızası iş akışı çalıştırma günlüklerinin görüntülenmesini geciktirdi. GitHub, hiçbir günlüğün kaybolmadığını, iş akışlarının normal şekilde çalıştığını ve çalıştırmaların veya kontrollerin gecikmediğini belirtti. Sağlanan raporda gecikmenin ne kadar sürdüğü belirtilmiyor.

Bu ayrım önemlidir. İşlemler sağlıklı bir şekilde yürütülürken, görünürlük geride kalıyordu. Sadece gecikmiş kayıtları inceleyen bir operatör, takılıp kalmış işlerden şüphelenebilir; sadece tamamlanmış işlere bakan bir operatör ise kullanıcıların bu işleri anlamak için ihtiyaç duydukları kanıtları geçici olarak kaybettiklerini gözden kaçırabilir.

Bu desenin neden kolayca gözden kaçırılabildiği

Teknik olarak, bu raporlar üç tarih için de tek bir temel neden ortaya koymuyor. 7 Ekim'de tekrarlayan bir yazma işlemi hatası vardı. 12 Ekim'de veritabanı kapasitesini azaltan maliyetli bir sorgu durumu söz konusuydu. 13 Ekim'de ise log işleme altyapısında bir arıza meydana geldi.

Tüm bunları tek bir koşucu kapasitesi sorunu olarak adlandırmak, kanıtların ötesine geçmek olurdu. Kök nedenlerin farklı olması nedeniyle bunun önemsiz olduğunu söylemek de kötü bir operasyon olurdu. Ayrı ayrı hatalar aynı zayıf operasyonel sınırı ortaya çıkarabilir: işin beklenenden daha geç kabul edilmesi, başlatılması, kaydedilmesi veya görünür hale getirilmesi.

12 Ekim'deki bildirim birikimi bu sınırı özellikle net bir şekilde ortaya koyuyor. Uygulama üzerindeki etki hafifletildi, ancak biriken işler azalırken bildirimler saatlerce gecikmeye devam etti. Giriş kapısının toparlanması, arkasındaki kuyruğun da toparlanması anlamına gelmedi.

İnsan mantığı daha basittir. Durum sayfaları olayları ayrı ayrı kayıtlar olarak sunar. Her birine bir başlık, bir zaman çizelgesi ve sonunda çözülmüş etiketi verilir. Etiket yeşil renge döndüğünde, zihinsel bileti de kapatmaya meyilli oluruz.

Bu alışkanlık, bileşenler arasında tekrar eden sorunları gizler. Çarşamba günü yaşanan bir yazma kesintisi, Pazartesi günü yaşanan kuyruk sorunları ve Salı günü yaşanan gecikmiş günlükler farklı ekiplere ve farklı etiketlere yansıyabilir. CI/CD kullanıcısı, işi reddetme, kanıtları geciktirme ve ilerlemeyi değerlendirmeyi zorlaştırma arasında gidip gelen tek bir hizmetle karşılaşır.

Bu diziyi, kapasite ve kuyruk hipotezini test etmek için bir neden olarak ele alırdım, bir kanıt olarak değil. Testler kendi izleme sistemimizde yapılmalı. GitHub'ın iç telemetri verilerine erişime ihtiyacımız yok, olayların şeklinden ders çıkarmak için.

Koşucu havuzlarımızda aynı deseni yakalayacak olan ne olurdu?

Kendi kendini yöneten bir CI/CD ortamı için, kuyruk derinliği ve iş başlatma gecikmesi ayrı ölçümler olmalıdır. Bunlar birbiriyle ilişkili durumları tanımlar, ancak bize aynı şeyi söylemezler.

Yirmi işten oluşan bir kuyruk, eğer görevliler işlere hızlıca başlarsa zararsız olabilir. İki işten oluşan bir kuyruk ise, her ikisi de normal başlama saatinden çok daha uzun süre beklemişse ciddi bir sorun olabilir. Bir ölçüt bekleme süresini sayar; diğeri ise her bir bekleme işinin deneyimini ölçer.

  • Çalıştırıcı sınıfına göre kuyruk derinliğini ölçün. Her bir çalıştırıcı havuzu, yürütme sınıfı veya iş yükü türü için ayrı seriler tutun. Tek bir birleşik sayım, boşta duran genel amaçlı kapasitenin arkasında engellenmiş bir uzman havuzunu gizleyebilir.
  • İş başlatma gecikmesini bir dağılım olarak ölçün. Sıraya kabul ile gerçek yürütme arasındaki süreyi kaydedin. Sadece ortalama bir değer üzerinden değil, işlerin daha yavaş olan kısmındaki sürekli bozulma konusunda da uyarı verin.
  • Sıraya alınmış en eski işi takip edin. Sabit bir kuyruk derinliği, asla başlamayan bir öğeyi gizleyebilir. Yaş, basit bir sayımın gözden kaçırdığı açlık ve zamanlama hatalarını ortaya çıkarır.
  • Yürütme sağlığını görünürlük sağlığından ayırın. İşlemin çalışma süresini ve tamamlanmasını, günlük alım gecikmesinden bağımsız olarak izleyin, yayın ve durum güncellemelerini kontrol edin. Kanıtları geç gelse bile işlem normal şekilde çalışabilir.
  • Biriken işler azalana kadar uyarıyı açık tutun. API'yi veya zamanlayıcıyı tekrar hizmete döndürmek, kuyruğa alınmış işler, günlükler veya bildirimler geride kaldığında yalnızca kısmi bir kurtarma işlemidir. Kurtarma işlemi için birikmiş işlerin temizlenmesi gerekir.

12 Ekim tarihli rapor, son kontrolün neden önemli olduğunu gösteriyor. Uygulama işlevleri, bildirim gönderiminden önce kurtarıldı. Eğer olay, sağlıklı isteklerin ilk belirtisinde kapatılmış olsaydı, kalan birikmiş iş yükü görünmez bir kuyruk haline gelirdi.

Ayrıca eklenmesi gereken pratik bir korelasyon kuralı daha var. Yazma hataları, kuyruk derinliği, en eski işin yaşı ve iş başlatma gecikmesi birlikte hareket ettiğinde, bileşenlere ayrı ekipler sahip olsa bile tek bir operasyonel görünüm oluşturun. Bir sürüm sırada beklerken, görevli kişiyi dört sekmeden diziyi bir araya getirmeye zorlamayın.

Pazartesi günü, her bir çalıştırıcı havuzu için ayrı ayrı grafik kuyruk derinliği, en eski kuyruğa alınmış işin yaşı ve iş başlatma gecikmesi hesaplanacaktır.

Kaynaklar