Operasyonel baskı çoğu kurumda “işin doğası” sanılır: aynı ticket’lar, aynı manuel kontroller, aynı gece çağrıları… Sonra ekip yorulur, değişiklik korkusu artar, sistem daha kırılgan hale gelir. Bu döngüyü kırmanın en pratik araçlarından biri: toil budget.
Toil budget, “ekibin zamanı nereye gidiyor?” sorusunu ölçülebilir bir disipline çevirir ve iyileştirme için korunan zaman yaratır.
1) Toil nedir (ve ne değildir)?
Toil; tekrar eden, manuel, otomasyonla azaltılabilir ve değer üretmeyen operasyonel iştir:
- Her gün aynı log taraması
- Aynı alarmları aynı şekilde kapatma
- Manuel kullanıcı/sertifika/ACL işlemleri
- “Şu sunucuya da bir şeyler kur” talepleri
Toil değildir:
- Tasarım/mimari kararlar
- Incident sonrası kalıcı düzeltme çalışmaları
- Kapasite planlama ve iyileştirme işleri
2) Neden “budget” yaklaşımı?
Çünkü toil, kendiliğinden azalmaz. Eğer sınır koymazsanız:
- Yeni işler toil’in üstüne biner
- İyileştirme hep “boş vakit”e kalır (ve o boş vakit hiç gelmez)
Budget yaklaşımı; toil’i sınırlayıp, iyileştirme zamanını güvence altına alır.
3) Minimum model: 3 metrik
Benim sevdiğim sade başlangıç:
- Toil zamanı (haftalık saat)
- Toil kaynakları (en çok tekrar eden 10 başlık)
- İyileştirme zamanı (korunan saat)
Bu üçü bile çoğu ekipte “gerçek tabloyu” ortaya çıkarır.
4) Haftalık ritim: toil review + iyileştirme slot’u
Pratik ritim önerisi:
- Haftada 1 kez (30 dk) Toil Review
- En çok zaman alan 3 toil kalemi
- “Bu hafta neyi otomatikleştireceğiz / kaldıracağız?”
- Haftada 1–2 blok (ör. toplam 4–6 saat) korunan iyileştirme zamanı
- Ticket alınmaz
- Meeting konmaz (istisna: Sev1)
Bu ritim, “iyileştirme bir gün yapılır” hayalini gerçek bir takvime dönüştürür.
5) Yönetimle sözleşme: toil budget nasıl savunulur?
En çok ihtiyaç duyulan cümle:
“Toil’i azaltmazsak, hızımız düşecek ve incident sayısı artacak.”
Somutlaştırmak için:
- Toil → deploy sıklığı düşer
- Toil → MTTR uzar (çünkü ekip yorgun)
- Toil → değişiklik riski artar (çünkü sistem anlaşılmaz)
Önerim: Toil’i “mühendis saatine” değil, iş etkisine çevirin. Örn. “Her hafta 12 saat manuel kullanıcı açma → ayda X gün kayıp → yeni ürün rollout gecikmesi.”
6) Toil’i azaltmanın 6 sahada çalışan yöntemi
- Standartlaştırma: aynı işi 5 farklı yöntemle yapmayı bitir
- Self-service: düşük riskli işleri form/portal üzerinden otomatikle
- Policy-as-code: “kim neyi yapabilir?” kararını dokümantasyondan pipeline’a taşı
- Runbook kalitesi: incident anında belirsizliği azalt
- Alert kalite programı: aksiyonsuz alarmı kapat (veya downgrade)
- Envanter/discovery: “ne var?” sorusu net değilse her iş toil’e dönüşür
7) 30 günlük küçük program (ekipleri yormayan)
Gördüğüm en sürdürülebilir format:
- Hafta: Toil kalemlerini yaz ve ölç (top 10)
- Hafta: Top 3 için “kaldır / otomatikle / delege et” kararı
- Hafta: 1–2 küçük otomasyon + 1 standart doküman
- Hafta: Sonuç metrikleri + yeni top 3
Bu programın gücü, büyük dönüşüm değil; sürekli küçük iyileştirme üretmesidir.
8) Son söz
Toil budget bir yönetim aracı değildir; bir hayatta kalma mekanizmasıdır. Operasyon ekibi, “yetişemiyoruz” dediğinde çoğu kurum daha fazla iş verir. Doğru refleks; toil’i görünür kılmak, bütçelemek ve iyileştirme zamanını korumaktır. Bu disiplin oturduğunda ekip daha az yorulur, sistem daha az kırılır ve teslimat hızı paradoksal biçimde artar.