Toil'i tespit etmek ve azaltmak: tekrarlı manuel işten mühendisliğe

Toil tam olarak nedir

Toil, bir üretim hizmetini çalıştırmaya bağlı operasyonel işin belirli bir türüdür. Google SRE kitabına göre şu özelliklerle tanınır: manueldir, yani işi bir insan elle yürütür; tekrarlıdır, aynı işi defalarca yaparsınız; otomatikleştirilebilir, yani bir makine aynı işi yapabilir ya da ihtiyaç tasarımla ortadan kaldırılabilir; taktiktir, yani stratejik değil, tepkisel ve kesintiye dayalıdır; kalıcı değer üretmez, iş bittikten sonra hizmet aynı durumda kalır; hizmet büyüdükçe iş de doğrusal biçimde büyür.

Her toil görevi bu özelliklerin hepsini taşımaz; ne kadar çoğunu taşıyorsa toil olma olasılığı o kadar yüksektir. Toil, sevilmeyen iş demek de değildir. Toplantılar, hedef belirleme ve eğitim gibi idari işler yük sayılır ama toil değildir. Sıkıcı ama kalıcı değer üreten iş de toil değildir: bir hizmetin tüm uyarı yapılandırmasını baştan temizlemek zahmetlidir, ama hizmeti kalıcı olarak iyileştirir.

Toil'i tespit etmek: ayırt edici sorular

Bir işin toil olup olmadığını anlamak için şu soruları sorun:

• Bu işi ilk kez mi yapıyorum, yoksa tekrar eden bir iş mi?
• Bir makine yapabilir mi, ya da ihtiyaç tasarımla ortadan kaldırılabilir mi?
• İş bittikten sonra hizmet aynı durumda mı kalıyor?
• İş, hizmet büyüklüğü ya da trafikle birlikte artıyor mu?

İlk karşılaşılan görev toil değildir; yeni bir sorunu çözmek öğrenme ve mühendislik gerektirir. Aynı görev yeniden geldiyse artık toil adayıdır. İnsan yargısı gerektiren iş de toil dışı kalma eğilimindedir, ama kötü tasarlanmış bir hizmetin her uyarısında aynı karmaşık yargıyı tekrar tekrar uygulamak, hâlâ toil sayılır.

Tipik örnekler: bir betiği elle çalıştırmak (betik hızlı olsa bile elle başlatma emeği toil'dir), çağrı cihazı uyarılarına cevap vermek, acil olmayan mesaj ve e-posta kesintilerini karşılamak, sürüm ve dağıtımın elle yürütülen adımları. Mühendislik işi ise otomasyon betiği yazmak, yeniden kullanılabilir araç geliştirmek, bir kez kurulan ve kalıcı etki bırakan izleme yapılandırmasıdır.

Toil'i ölçmek ve önceliklendirmek

Ölçmeden azaltmak, tahminle yürümektir. Google'ın yaklaşımı, ekip üyelerine düzenli aralıklarla zamanlarını kategorilere ayırdıkları kısa anketler vermektir. Ortalama tek başına yanıltıcıdır: bazı kişiler neredeyse hiç toil görmezken bazıları zamanının büyük kısmını toil'e harcıyor olabilir. Yüksek bireysel oranlar çoğunlukla yöneticinin işi daha adil dağıtması gerektiğini gösterir.

Nöbet düzeni de toil için bir alt sınır oluşturur. Her mühendis birincil ve ikincil nöbet haftaları alıyorsa, nöbet rotasyonundaki kişi sayısı toil oranının alt sınırını belirler; rotasyon küçüldükçe sınır yükselir. Toil kaynaklarını sıralarken ekibin kendi verisine bakın. Kitapta anket sonuçlarında en büyük kaynak olarak acil olmayan kesintiler (mesaj ve e-postalar) görülmüş, onu acil nöbet müdahalesi ve sürüm işleri izlemiştir; kendi ekibinizde sıralama farklı çıkabilir.

Önceliklendirme için her toil kaleminin sıklığını, bir seferde alınan emeği ve otomasyon maliyetini yan yana koyun. Sık, uzun süren ve basit otomasyonla kapanan kalemler ilk sıraya, nadir ve otomasyonu pahalı kalemler sona gider.

Toil'i azaltma yolları

Toil'in azaltılması tek bir araç değil, bir mühendislik alışkanlığıdır. Başlıca yollar:

• İşi mühendislikle ortadan kaldırmak: otomasyon betikleri ve araçları yazmak, altyapı kodunu daha dayanıklı yapmak.
• Sistemi kalıcı olarak iyileştirmek: yapılandırma değişiklikleri, izleme güncellemeleri, ayarlama ve yük dengeleme gibi kalıcı kazanımlar.
• Gürültülü hizmeti yeniden tasarlamak: her biri karmaşık insan yargısı isteyen uyarılar üreten bir hizmette hata koşullarını ortadan kaldıracak ya da kendiliğinden ele alacak şekilde sadeleştirmek.
• Sürüm ve dağıtım adımlarını otomatikleştirmek.
• Yükü ekip içinde dengelemek ve mühendisleri mühendislik projelerine yönlendirmek.

Kritik nokta, işi sürdürülebilir hâle getirmektir: her hafta bir miktar toil'i mühendislikle ortadan kaldırmak, tek seferlik büyük projeden daha kalıcıdır. Otomasyon yazarken başarısız olduğunda ne olacağını da tasarlayın; kötü otomasyon yeni toil üretebilir.

Kurgusal örnek: tekrarlayan disk uyarısı

Örneğin bir ekip, haftalar boyunca aynı uyarıyı alıyor: bir depolama sunucusunun diski doluyor ve nöbetçi mühendis eski günlük dosyalarını elle siliyor. Soruları uygulayın: görev tekrar ediyor, bir betik yapabilir, iş bitince hizmet aynı durumda kalıyor ve veri arttıkça iş artıyor. Bu açıkça toil'dir.

Önce kısa vadeli çözümle başlanır: günlük temizliğini zamanlanmış bir göreve bağlamak. Sonra kök soruya dönülür: günlükler neden bu kadar büyüyor, saklama süresi neden tanımsız? Kalıcı çözüm, saklama politikasını yapılandırmak ve uyarıyı disk dolmadan önce tahminle tetikleyecek şekilde değiştirmektir. Böylece nöbetçi mühendis ne betiği çalıştırır ne de uyarıya cevap verir; iş ortadan kalkmıştır. Bu akış her toil kalemi için tekrarlanabilir: tespit et, sınıflandır, önceliklendir, ortadan kaldır, sonucu doğrula.

Neden önemli: toil ve ekip sağlığı

Google'ın SRE yaklaşımında toil, her mühendisin zamanının yarısının altında tutulmayı hedefler; kalan zaman, gelecekteki toil'i azaltan ya da özellik ekleyen mühendisliğe ayrılır. Kontrol edilmezse toil, kullanılabilir tüm zamanı doldurma eğilimindedir. Aşırı toil kariyeri durdurur, motivasyonu düşürür, tükenmişliğe yol açar. Ekip düzeyinde ise SRE'nin bir mühendislik organizasyonu olduğu mesajını bulandırır, özellik hızını yavaşlatır ve geliştiricilerin kendi operasyonel işlerini SRE'ye aktarmasına zemin hazırlar.

Bir miktar toil kaçınılmazdır ve küçük dozlarda kabul edilebilir. Sorun, büyümesine izin verildiğinde başlar. Bu nedenle toil oranı bir kez ölçülüp bırakılmaz; zamanla izlenir ve uzun vadede mühendislik zamanı hedefin belirgin altına düşüyorsa nedenleri araştırılır.

Sık yapılan hatalar

Başlıca hatalar: her sıkıcı işi toil saymak, tersine toil'i işin doğası diye kabul etmek, ölçmeden otomasyon projesine girmek, otomasyonun bakım yükünü hesaba katmamak, tek bir kişiye toil yığmak ve toil'in kaynağı olan zayıf hizmet tasarımını geliştirici ekibe aktarmamak.

En önemli ders şudur: toil'in kaynağı çoğu zaman operasyon değil, hizmetin kendisidir. Her uyarı karmaşık bir insan yargısı istiyorsa, hizmetin tasarımı sorgulanır. Geliştirici ekiple ortak güvenilirlik hedefleri belirlemek, toil'in kaynağında çözülmesini sağlar.

Bu beceri Mindset programlarında nerede çalışılır

Site Reliability Engineering (SRE) Pratikleri programında Toil Azaltma ve Otomasyon modülü, SRE Kültürü programında ise Toiling Azaltma ve Otomasyon Stratejisi modülü bu konuya ayrılmıştır. İçerik, operasyon yükünü azaltmak isteyen platform ve altyapı ekipleri ile nöbet ve otomasyon önceliklerine karar veren ekip liderleri için uygundur.