GitHub durduğunda, yazılım teslimatı durur: dokuz saatlik kesintiden yönetici dersleri

6 Ağustos 2026'da 15:22 UTC'de GitHub, milyonlarca kuruluş için yazılım oluşturan, test eden ve teslim eden otomasyon hizmeti GitHub Actions için düşük performans bildirmeye başladı. Birkaç saat içinde kesinti GitHub Pages, Actions REST API, Copilot code review, Copilot coding agent, hosted ve self-hosted runner'lar, webhook teslimatları ve GitHub Enterprise Importer geçişlerine yayıldı. GitHub, başlangıcından yaklaşık dokuz saat sonra, 7 Ağustos'ta 00:06 UTC'de düşüşün kontrol altına alındığını duyurdu. Bir iş gününün büyük bölümünde, dünyanın yazılım teslim kapasitesinin önemli bir kısmı aksadı.

Bu neden şimdi önemli

GitHub artık sadece bir kod deposu değil. Modern yazılım teslimatının operasyonel siniri: kodun yaşadığı, sürekli entegrasyonun çalıştığı, dağıtımların tetiklendiği ve giderek artan şekilde yapay zeka kodlama ajanlarının işini yaptığı yer. Copilot code review ve Copilot coding agent, Actions ile birlikte çevrimdışı olduğunda, teslim süreçlerine yapay zeka desteğini dokumuş kuruluşlar, pipeline'ları durduğu anda bu yeteneği de kaybetti. Geliştirmeyi, otomasyonu ve yapay zeka araçlarını tek bir platformda ne kadar çok yoğunlaştırırsak, tek bir olay ekonomi çapında bir olay gibi o kadar çok davranır.

Ne oldu

GitHub'ın resmi durum sayfasına göre, altta yatan arıza runner'ların geçersiz iş atamaları almasını içeriyordu; self-hosted runner'lar iş alamadı ve kayıt sırasında hatalarla ve hız sınırlamasıyla karşılaştı. Workflow çalıştırmaları başlayamadı veya tamamlanamadı, kuyruktaki işlerin süresi doldu, Actions REST API hatalar döndürdü ve webhook tetikli workflow'lar gecikti. Kurtarma, sistem genelinde birikmiş kuyrukları boşaltmayı, runner iş ataması için düzeltmeler dağıtmayı, webhook tetikli workflow verimini geri yüklemeyi ve self-hosted runner'ları kademeli olarak yeniden etkinleştirmeyi gerektirdi. GitHub henüz ayrıntılı bir kök neden analizi yayımlamadı. Bu olay, zorlu bir güvenilirlik olayları zincirinin ardından geldi: The Register nisanda 26, mayısta 23, haziranda 23 ve temmuzda 26 olay kaydediyor ve GitHub'ın kendi durum sayfası Actions için 90 günlük çalışma süresini yüzde 99,42 olarak gösteriyor; bu, işletmelerin tüm teslimat zincirlerini tek bir tedarikçiye yüklediklerinde bekledikleri seviyenin belirgin şekilde altında.

Teknoloji ve mimari sonuçları

Mimari dersi bağlanma (coupling) hakkında. Birçok işletme sessizce tek bir tedarikçinin kaynak kodu, derleme, test, dağıtım, dokümantasyon barındırma ve yapay zeka desteği için kontrol düzlemi (control plane) haline gelmesine izin verdi. Bunların her biri tek başına mantıklı. Birlikte, tek bir arızalı zamanlayıcının aşağı akıştaki her şeyi durdurduğu bir bağımlılık grafiği oluşturuyorlar. Özellikle, birçok ekibin tam olarak GitHub altyapısına bağımlılığı azaltmak için çalıştırdığı self-hosted runner'lar da etkilendi, çünkü iş ataması ve kayıt için hâlâ GitHub'ın kontrol düzlemine bağımlılar. Kendi hesaplama gücünüze sahip olmak, kendi kullanılabilirliğinize sahip olmak anlamına gelmez. Mimarların hangi yeteneklerin birlikte arızalandığını haritalaması, düşük modda çalışma yöntemlerini tanımlaması ve birincil platformdan geçmeyen acil dağıtım yollarının var olduğundan emin olması gerekir.

Ticari ve rekabetçi sonuçlar

Dokuz saatlik pipeline kesintisi bir mühendislik rahatsızlığı değildir. Ertelenen sürümler, geciken düzeltmeler, atıl ekipler ve müşteriye dönük değişiklikleri sürekli teslim eden firmalar için doğrudan ticari etkidir. Rekabet açısı da aynı derecede gerçek: test edilmiş yedek yolları olan kuruluşlar diğerleri beklerken teslim etmeye devam etti. Teslimat zinciri güvenilirliği kendi başına bir farklılaştırıcı haline geliyor ve önde gelen sesler platform bağımlılığını şimdiden sorguluyor. The Register, geliştirici Mitchell Hashimoto'nun GitHub'ın artık geliştiricilerin ciddi işlerini barındıracak bir yer olmadığını söylediğini aktarıyor. Katılsanız da katılmasanız da, etkili mühendisler arasındaki bu duygu, yönetim kurullarının kaydetmesi gereken bir sinyaldir.

Risk ve yönetişim hususları

Çoğu kurumsal risk kaydı GitHub'ı kritik altyapı yerine bir geliştirme aracı olarak görür. Bu olay, yeniden sınıflandırma için gerekçe sağlıyor. Yönetişim soruları doğal olarak ortaya çıkıyor. Kuruluş, teslimat platformu çevrimdışıyken gerçek kurtarma süresinin ne olduğunu biliyor mu? Yapay zeka kodlama ajanlarına ve otomatik inceleme adımlarına değişiklik yönetiminde tek hata noktası olmalarına izin verildi mi? Özellikle operasyonel dayanıklılık çerçeveleri altındaki finansal hizmetlerde düzenleyici yükümlülükler yazılım teslimat zincirine kadar uzanıyor mu? Ve kaynak, derleme, dağıtım ve yapay zeka araçları için tek bir tedarikçiyle yoğunlaşma, tedarikçi stratejisine bir risk olarak dahil edildi mi, yoksa varsayılan olarak mı birikti?

CEO'lar ne yapmalı

Önce teknoloji liderliğinize tek bir soru sorun: GitHub veya eşdeğeri tam bir gün çevrimdışı kalırsa, müşterilere verdiğimiz taahhütlere ne olur? Güvenceler yerine net, kanıta dayalı bir yanıt isteyin. İkinci olarak, geliştirici platformu bağımlılığını tedarikçi yoğunlaşma riski olarak ele alın ve bulut yoğunlaşması kadar yönetim kurulu görünürlüğü verin. Üçüncü olarak, dayanıklılık çalışmalarını açıkça finanse edin. Yedek yollar, yansıtılmış depolar ve prova edilmiş düşük mod yöntemleri sigorta primleri gibidir ve her zaman yokluklarını kanıtlayan kesintiden daha ucuzdur.

CTO'lar ne yapmalı

Teslimat platformunuzun patlama yarıçapını (blast radius), artık inceleme ve kodlama iş akışlarına gömülü yapay zeka araçları da dahil olmak üzere dürüstçe haritalayın. En kritik hizmetleriniz için bağımsız bir acil dağıtım yolu bulundurun ve üç ayda bir provasını yapın. Kaynak kodunu düzenli olarak ikincil bir konuma yansıtın. Self-hosted kapasiteyi, tedarikçinin kontrol düzlemi kullanılamadığında zarifçe bozulacak şekilde tasarlayın; self-hosting'in bağımsızlık anlamına geldiğini varsaymayın. Son olarak, aklınızdaki pazarlama rakamları yerine tedarikçinin gerçek yayımlanmış çalışma süresine göre dahili kullanılabilirlik beklentilerini belirleyin ve buna göre hata bütçeleri (error budgets) oluşturun.

Stratejik sonuç

Bu kesinti birkaç gün içinde manşetlerden kaybolacak. Ortaya çıkardığı bağımlılık kaybolmayacak. Yön daha az değil, daha fazla yoğunlaşma: yapay zeka ajanları teslim sürecinin daha büyük bir bölümünü üstlenecek ve bu hafta arızalanan aynı platformlarda çalışacaklar. Liderler bu olayı ücretsiz bir stres testi olarak görmeli. Kuruluşunuz hakkında ne ortaya çıkardığını inceleyin, boşlukları bilinçli olarak kapatın ve platform dayanıklılığını acil müdahale yerine teknoloji stratejisinin kalıcı bir parçası yapın.

Bu hafta teslimat platformunuz sustuğunda, kuruluşunuz teslim etmeye devam etti mi, yoksa hiç değerlendirmediği bir tek hata noktası mı keşfetti? Ekiplerinizin bunu nasıl yönettiğini duymak isterim.

Matematiksel düşünün. Akıllıca mühendislik yapın. Stratejik liderlik edin. Sorumlu şekilde inşa edin. Küresel ölçeklenin. Yapay zeka aracılığıyla gerçek ticari değer yaratın.

#GitHub #DevOps #EnterpriseArchitecture #TechnologyStrategy #BusinessContinuity #PlatformEngineering #ArtificialIntelligence #RiskManagement #CTO #CEO

Originally published on LinkedIn by Keshavan Thiagaraja. Read the original on LinkedIn.