Google SRE Bölüm 5 — Eliminating Toil

Chapter 1'de tohumunu attığımız "Toil" kavramına şimdi kendi bölümünde derinlemesine bakıyoruz. Bu bölüm, SRE'nin belki de en gündelik, en elle tutulur fikrini içeriyor.

Toil Nedir, Nasıl Tanınır?

Google, bir işin "Toil" sayılması için birkaç kritere bakıyor. Bir işin şu özelliklerin çoğuna sahip olması, onu toil yapıyor:

• Manuel : Elle yapılıyor.
• Tekrar eden : Bir kere değil, defalarca yapılıyor.
• Otomatikleştirilebilir : Bir script/araç bunu yapabilir, gerçek insan zekasına ihtiyaç yok.
• Geçici değeri var, kalıcı değeri yok : Sorunu anlık çözüyor ama sistemi kalıcı olarak iyileştirmiyor.
• Servisin büyümesiyle orantılı büyüyor : Sistem büyüdükçe bu iş de artıyor.
• Kalıcı bir katkısı yok : İşi yaptıktan sonra geriye somut bir değer kalmıyor.

Elle yapılan deploy'lar, tekrar eden ticket'lara elle cevap vermek, kapasiteyi elle ayarlamak. Hepsi bu tanıma giriyor.

Toil Neden Sadece "Sıkıcı" Değil, Gerçekten Zararlı?

Google bunu çok boyutlu ele alıyor. Toil kariyer gelişimini durduruyor, çünkü toil'e giden zaman öğrenme ve büyüme fırsatını yiyor. Moral bozucu, çünkü tekrar eden iş motivasyonu düşürüyor. Ve en kritik olanı: Toil servisle orantılı büyüdüğü için, önlem alınmazsa bir noktada ekibin tüm zamanı toil'e gidiyor ve kalıcı hiçbir iyileştirme yapılamıyor. Bu, Chapter 1'de konuştuğumuz sysadmin modelinin krizinin aynısı.

%50 Kuralı: Hedef Değil, Alarm

Önceki bölümlerde bahsettiğim "toil %50'yi geçmemeli" kuralı burada operasyonel hale geliyor. Google bunu bir hedef olarak değil, bir alarm sinyali olarak görüyor: Bir ekibin toil oranı sürekli %50'yi geçiyorsa, bu ekibin yapısal bir sorunu olduğunun göstergesi ya yeterli otomasyon yatırımı yapılmıyor ya da ekip yanlış işlere atanıyor.

Sıfır Toil de Her Zaman Doğru Değil

Google'ın kurduğu ilginç bir denge var: Toil'in tamamen sıfır olması her zaman doğru değil. Bazen az miktarda toil, yeni başlayanlar için sistemi öğrenmenin bir yolu olabiliyor. Bazen de otomasyonun maliyeti, toil'in maliyetinden yüksek olabiliyor. Özellikle nadir, tek seferlik işler için. Burada bir maliyet/fayda analizi yapmak gerekiyor; her toil'i otomatikleştirmeye çalışmak da başlı başına bir toil'e dönüşebilir.

Sonuç

Chapter 5, SRE'nin en somut ve en ölçülebilir fikirlerinden birini sunuyor: Toil'i tanımlamak, ölçmek ve sistematik olarak azaltmak. Bu tek fikir, kitabın geri kalanındaki otomasyon ve Release Engineering bölümlerinin de zeminini oluşturuyor.

2026 Merceğinden: Toil'i Kod Olarak Yok Etmek

Bu bölümü bugün okuduğumda en çok şunu düşündüm: Infrastructure as Code ve GitOps akımının tamamı, aslında bu bölümün tezinin endüstri çapında bir uygulaması. Terraform, Crossplane, ArgoCD ile günlük çalışan herkes, farkında olmadan "toil'i otomasyonla yok et" prensibini hayata geçiriyor. On yıl önce bu bir Google iç pratiğiyken, bugün her ölçekteki şirketin standart iş akışı.

Asıl ilginç soru şu: AI'nın bu denklemi nasıl değiştirdiği. Kitap "Otomasyonun maliyeti bazen toil'den yüksek olabilir" diyor. Özellikle nadir, tek seferlik işler için otomasyon yazmaya değmeyebilir. Ama AI destekli araçlar (Claude Code, Copilot gibi) bu maliyet/fayda dengesini kökten değiştiriyor: Bir script yazmanın maliyeti artık dakikalar mertebesine indi. Bu da şu soruyu gündeme getiriyor. 2016'da "Otomatikleştirmeye değmez" denilen pek çok iş, 2026'da AI ile birkaç dakikada otomatikleştirilebilir hale geldi mi? Muhtemelen evet ve bu da toil'in tanımının kendisinin zamanla daralması gerektiği anlamına geliyor: Dün "Otomatikleştirilemez" sayılan bazı işler bugün toil kategorisine bile girmiyor.

Ama burada bir uyarı da eklemem lazım: AI'nın kendisi de yeni bir toil türü yaratabiliyor. AI'nın ürettiği otomasyon kodunu gözden geçirmek, doğrulamak, hatalı kararlarını düzeltmek.. Bu da yeni, henüz kitapta tanımlanmamış bir "AI-toil" kategorisi olabilir.

Sıradaki yazımda Chapter 6'ya geçiyoruz: Monitoring Distributed Systems. Teşekkür ederim.