İçeriğe geç
Blog

Alarm üretildi, kimse okumadı

5 dk okuma
Karanlık zeminde art arda sönen mor sinyal halkaları ve halkaları saymayan boş bir ölçek çizgisi
İçindekiler

12 Ağustos akşamı sitede bir yazı yayınlandı. Aynı akşam sosyal medya postları da çıktı, biri 16:14'te diğeri 16:19'da.

Ertesi sabah otomatik bir kayıt açıldı: yayın koşusu düşmüş.

Post gitmişti. Düşen tek şey arşivdi. Bu ayrımı anlamak yarım saatimi aldı ve o yarım saat bu yazının konusu.

Kuyrukta duran dosya "yayınlanmadı" demek değil

Sitenin sosyal hattı GitHub Actions üzerinde çalışan zincirlerden oluşuyor. Yazı yayına girince bir zincir post metnini üretip onay için bir birleştirme isteği açıyor. İsteği birleştirdiğimde ikinci zincir postu atıyor, sonra dosyayı queue/ klasöründen published/ klasörüne taşıyıp depoya yazıyor.

12 Ağustos'ta post atıldı. Kaydı duruyor: yayın kimliği urn:li:activity:7493337625265717248, damga 16:14 UTC. Arşiv adımı ise düştü. Sebep basit: iki zincir ayrı eşzamanlılık gruplarında çalışıyor, yani birbirlerinin varlığından habersizler. İkisi aynı anda ana dala yazmaya kalkınca yenilen taraf geri çevrildi.

Ortaya şu tuhaf durum çıktı. Post yayında, dosya hâlâ kuyrukta. Kuyrukta duran bir dosya ise bir sonraki koşuda yeniden işlenecek dosya demek. Aynı post ikinci kez gidecekti.

Buradaki tuzak teknik değil, yorumsal. Kuyruğa bakıp "demek çıkmamış" dersen yanlış yerden bakıyorsun. Doğru soru şu: hesabın akışında ne var.

Onarımın birinci parçası arşiv adımına beş denemelik, rebase'li bir yeniden deneme döngüsü koymak oldu. İkinci parçası daha önemliydi ve akışın içine yazdığım yorum satırında duruyor:

Arşiv push'u KRİTİK: buraya gelindiyse post zaten yayınlanmıştır.

Bir adımın neden kritik olduğunu koda yazmazsan, o adımı altı ay sonra sadeleştirip bozan kişi büyük ihtimalle sen olursun.

Asıl açık düşen koşu değildi

Yarış durumu bir hataydı ve düzeltilebilirdi. Beni rahatsız eden başka bir şeydi: o zincir düştüğünde hiçbir yere haber gitmiyordu.

Onay isteklerinde de aynı boşluk vardı. İki onay isteğinin açık kalma süresini kendi depomdan çıkardım. Biri 29 Temmuz'da açılmış, 12 Ağustos'ta birleştirilmiş: on dört gün. Diğeri 5 Ağustos'ta açılmış, yine 12 Ağustos'ta birleştirilmiş: yedi gün. Aynı dönemde diğer kanalın istekleri birer gün içinde birleştirilmişti.

Yani hat yarı yarıya durmuştu. Kimse birleştirmediği için içerik üretiliyor ama çıkmıyordu ve ben bunu fark etmedim. Durumu bana soran ben değildim.

Bir sistemin bozulduğunu sahibinin sorması gerekiyorsa o sistem izlenmiyordur.

Kurduğum karşılık mütevazı: her sabah 04:30 UTC'de koşan bir bekçi. Üç şeye bakıyor. Yirmi dört saatten uzun süredir açık duran onay istekleri, kuyrukta takılı kalmış dosyalar, son yirmi dört saatte düşmüş yayın koşuları. Bulgu varsa tek bir kayıt açıyor, üçünü birden o kayda yazıyor.

Bir de şunu yapıyor: temiz günlerde hiçbir şey yazmıyor.

Bu son cümle mekanizmanın kendisi. Her sabah "her şey yolunda" diyen bir bekçi iki hafta içinde okunmaz hale gelir, sonra gerçekten bir şey söylediği gün de okunmaz. Sessizlik iyi haber olmalı ki gürültü haber olsun.

Aynı deseni çok daha büyük bir yerde gördüm

Buradan sonrası için bir dürüstlük notu. Bu bölümdeki iki olayın ayrıntılarını paylaşamıyorum: kurum, ürün, tedarikçi ve kişi adı geçmeyecek. Süreler kendi kayıtlarımdan geliyor ama sen bunları doğrulayamazsın. Bu yazının doğrulanabilir kısmı yukarıda anlattığım depo; aşağısı bir saha gözlemi ve öyle okunmalı.

Birinci olayda izleme sistemi işini kusursuz yaptı. Sabah dokuz buçukta iki uyarı üretti, kök nedeni gösterdi, etkilenen servisi adlandırdı. Kriz masası öğleden sonra bir buçukta toplandı. Arada üç buçuk saat var.

Uyarı vardı. Uyarıyı okumakla yükümlü, adı yazılı bir kişi yoktu.

İkinci olay iki hafta sonraydı ve tam tersiydi. Uyarı hiç üretilmedi, çünkü ilgili izleme modülü abonelik tüketimini düşürmek amacıyla kapatılmıştı. Servis bir gece kesildi, kırk saati aşkın süre boyunca izleme tarafında hiçbir iz bırakmadı. Kesintiyi müşteri haber verdi.

İkisini yan yana koyunca çıkan sonuç ilk baktığımdan daha rahatsız edici. İkinci olayda kaybedilen süre birincisinin on katından fazla ve sebebi bir arıza değil, bir bütçe kalemi.

Geçen yazıda token sayacı için yazdığım şey burada da geçerli: görünürlüğü kapatmanın bedeli kapattığın kalemde görünmez. Başka bir yerde, olay süresinde görünür.

Değişen şey refleks değildi, kaydın yapısıydı

Şimdi asıl bulguya geliyorum ve bu bulgu bekçiden de önemli.

Birinci olayın tutanağında bir satır boş kaldı: ilk kullanıcı bildiriminin saati. Kimse tutmamıştı. Tutulmadığı için ilk müdahale süresi hesaplanamadı. Bunu günler sonra fark ettik ve bir aksiyon maddesi olarak yazdık. Yani ölçemediğimiz şeyi ölçemediğimizi de sonradan öğrendik.

İkinci olayın tutanağında aynı satır dolu. Yalnız dolu da değil, künyenin en üstünde zorunlu alan olarak duruyor: olay başlangıcı, ilk bildirim, ilk müdahale, tespit süresi. Hemen yanında da şu not var: izleme sisteminden alarm üretilmedi.

Arada geçen iki haftada kurumun refleksi düzelmedi. İkinci olay her ölçüde birincisinden kötüydü. Değişen tek şey kaydın yapısıydı.

İnsanın doldurduğu şablon bir dilektir.

Sistemin doldurduğu yapı bir kontroldür.

Bir alanı boş bırakabiliyorsan o alan er ya da geç boş kalır. Üstelik en kötü günde, en yorgun anda, en çok ihtiyaç duyduğun sırada boş kalır.

Bunun ikinci bir faydası var ve daha az konuşuluyor. Zorunlu alan yalnız veriyi toplamıyor, boşluğu da görünür kılıyor. İkinci olayın künyesindeki "alarm üretilmedi" notu bir itiraf. O notu yazmak zorunda kalmasaydık kör noktayı tartışmaya bile açmazdık.

Kendi hattımda da aynısını yaşadım. Kuyruğa bakıp yorum yapmak bana kalmıştı ve yanlış yorumladım. Bekçiyi kurduktan sonra o yorum benden alındı. Artık soruyu her sabah bir betik soruyor ve betiğin yorgun günü olmuyor.

Ne yapmalı

Üç madde, bu sırayla:

  • Kurduğun her otomatik akış için tek soruyu sor: bu düşerse kim öğrenir. Cevap "birinin dikkati" ise o akış izlenmiyordur, yalnızca çalışıyordur.
  • Bekçiyi temiz günlerde sustur. Her gün rapor üreten bir uyarı mekanizması, ürettiği ilk gerçek uyarıda da göz ardı edilir.
  • Kaydında boş bırakılabilen alanı bul. Olay kaydı, değişiklik kaydı, devir formu, fark etmez. O alanı ya zorunlu hale getir ya da sistemin doldurmasını sağla. Kontrol dediğimiz şey çoğu zaman bundan ibaret.

Asıl soru şu: kurumunda bir uyarı üretildiğinde onu okumakla yükümlü kişinin adı yazılı mı, yoksa o uyarı birinin o sabah doğru ekrana bakmasına mı bağlı?

Hayrettin Şendil

Hayrettin Şendil

15 Ağustos 2026 · 5 dk okuma

LinkedIn · X

Yazıyı paylaş
LinkedInX

İlgili Yazılar

Yorumlar