GitHub arızası Actions, Pages, webhook'lar ve kod aramayı 90 dakika boyunca bozdu

GitHub'ın durum sayfası 30 Ekim'de bir çoklu servis arızası daha kaydetti; Actions, Pages, webhook'lar ve kod arama yaklaşık bir buçuk saat boyunca etkilendi. dev.to'da yayımlanan bir yazıya göre olay 17:50 UTC'de, GitHub'ın Actions ve Webhook'lardaki performans düşüşünü incelemeye başlamasıyla ortaya çıktı. On dakika sonra listedeye Pages eklendi ve 18:06 itibarıyla şirket geciken workflow çalıştırmaları, geciken Pages dağıtımları, geciken webhook teslimatları ile kod arama ve canlı güncellemelerde hatalar bildiriyordu. Olay 19:23 UTC'de çözüldü olarak işaretlendi.

Art arda gelen olaylar

dev.to yazısında atıf yapılan Hacker News yorumcuları, neredeyse aynı bir olayın 11 gün önce de yaşandığını ve GitHub'ın son iki hafta içinde birkaç Actions kesintisi geçirdiğini belirtti. Yazı ayrıca GitHub'ın durum sayfasının bir tuhaflığına dikkat çekiyor: kısmi bozulma kesinti sayılmadığı için 30 günlük çalışma süresi çubuğu kabul edilmiş bir olay sırasında bile yeşil kalabiliyor. Bir yorumcunun, Actions kullanılabilirliğine dair doğru bir tablo edinmek için üçüncü taraf bir durum izleyici bile yaptığı bildiriliyor.

GitHub durum verisi için herkese açık bir JSON API sunuyor ve dev.to yazarı, mühendislerin takılan workflow'ları yeniden çalıştırmadan veya commit'leri geri almadan önce GitHub'ın kendisinin bozuk olup olmadığını kontrol edebilmeleri için bu API'ye küçük bir curl ve jq içeren bir shell alias bağlamayı öneriyor.

Tam ihtiyaç duyduğunuz anda devreye girmeyen mirror kurulumu

En yaygın yedekleme deseni, her push işleminde başka bir forge'a git push --mirror çalıştıran bir GitHub Action'dır ve GitHub'ın kendi iş kuyruğuna bağımlıdır. Actions çöktüğünde mirror, tam da ihtiyaç duyulan anda güncellenmeyi durdurur. Yazarın kuralı şu: bir mirror, GitHub'ın dışındaki bir şey tarafından yönlendirilmeli; ya kendi makineniz ya da kendi zamanlamasıyla senkronize olan bir forge.

Bir kesintiden sağlam çıkan seçenekler

Yazı dört yaklaşım ortaya koyuyor:

Tek bir git remote'a birden fazla push URL'si eklemek, tek bir git push ile GitHub, Codeberg ve Tangled'a aynı anda ulaşmayı sağlar ve hiçbir altyapı gerektirmez. Catch, bunun yalnızca o klon üzerinden yapılan push'ları yansıtmasıdır; GitHub web arayüzü üzerinden tamamlanan merge'ler, biri pull ve push yapana kadar yayılmaz, bu da onu tek kişilik projeler için uygun ama ekipler için kırılgan kılar.

Codeberg, pull mirror'ları destekleyen Forgejo çalıştırıyor ancak Codeberg.org bunlara izin vermiyor. SSS'sinde, diğer barındırma servislerinden çeken mirror'ların sorunlara yol açtığını ve bunun yerine birden fazla remote ile manuel mirror'lamayı önerdiğini açıklıyor. Yazı, kimsenin hatayı yanlış yere açmaması için Codeberg yedeğinde issue'ların ve pull request'lerin devre dışı bırakılmasını tavsiye ediyor.

Kendi sunucusunda barındırılan bir Forgejo instance'ı, yazarın ekipler için seçeceği seçenek. New Migration akışından mirror bayrağı işaretlenerek oluşturulduğunda, GitHub'dan zamanlanmış bir şekilde, web arayüzünde yapılan değişiklikler dahil çeker ve ardından Codeberg, Tangled veya GitLab'a push mirror'ları dağıtabilir. Forgejo dokümanlarından iki uyarı: push mirror'lar zorla güncelleme yapar ve hedef remote'un üzerine yazar; ayrıca SSH üzerinden LFS uygulanmadığı için SSH push mirror'ları LFS objelerini taşımayacaktır.

Bluesky'nin temelini oluşturan AT Protocol üzerine inşa edilmiş bir forge olan Tangled, repoları "knot"larda barındırıyor ve CI'ı "spindle"larda çalıştırıyor. 30 Ekim sürümü, knot sunucusunun Rust ile yeniden yazılmış hali olan knot2'yi çıkardı ve issue'ları, pull request'leri, yorumları, tepkileri ve etiketleri, repodaki Git objelerinin zincirleri olarak tanımlanan iş birliği objeleri olarak knot üzerine taşıdı; böylece bir yedek, tartışmayı commit'lerin yanında taşıyor. Ancak yedekler için boşluklar önemli: özel repolar henüz mevcut değil, bir kurucu ortanın haftalar uzakta olduklarını söylüyor; HTTPS push çalışıyor ama belgelenmemiş; Windows, adında iki nokta bulunan dosyaları klonlayamıyor; ve kendi knot sunucusunu işletenler v1.20.0'a yükseltmek zorunda.

Bir CI yedeği

CI'sız bir mirror salt okunur bir arşivdir. Yazı, testleri çalıştırmak ve release'leri elle kesmek için pipeline'ın tam o kadarını taşımayı öneriyor; GitHub Actions kullanıcılarına tanıdık gelecek şekilde tasarlanmış ama onlarla uyumlu olmayan .forgejo/workflows/ dosyalarını kullanan Forgejo Actions'a ve Codeberg'in barındırılan instance'ı üzerinden Woodpecker CI'a işaret ediyor.

Neden önemli

GitHub iş birliğine dayalı yazılım geliştirmenin fiili merkezi olmaya devam ediyor ve tekrarlayan çoklu servis bozulmaları doğrudan kaybedilen mühendislik zamanı, geciken dağıtımlar ve bozulan entegrasyonlar anlamına geliyor. Durum sayfasının yeşil çalışma süresi çubuğunun kısmi kesintileri küçük göstermesi sorumuza bir de bunu ekliyor, çünkü ekipler platformdan şüphelenmeden önce kendi araçlarından şüphe edebiliyor. Bu olaydan çıkarılan pratik ders şu: yedeklediği sisteme bağımlı bir yedek, yedek değildir; Codeberg'e, kendi sunucunuzdaki Forgejo'ya veya Tangled'a ucuz ve bağımsız mirror'lama, bir sonraki kesintiyi kaybedilen bir akşamdan küçük bir gecikmeye dönüştürebilir. Zamanlama ayrıca alternatiflere taze cephane verdi: kesintinin olduğu gün Tangled, çalışma süreniz için başkasına güvenmenin iyi sonuç vermediğini savunan bir deneme yayımladı; dev.to yazarının iğneleyici notuyla bu, bir reklam olarak iş görüyor.