Tekrarlayan İşleri Otomatikleştirmek: Ne Zaman Script Yazmalı?

Tekrarlayan bir işi otomatikleştirmek, geliştiricilerin en sevdiği faaliyetlerden biridir — ve tam da bu yüzden sık sık yanlış yerde yapılır. İki dakikalık bir işi otomatikleştirmek için üç gün harcamak, mühendislik zevki verir ama net bir kayıptır. Öte yandan, her sürümde elle yapılan ve arada bir yanlış yapılan bir adımı otomatikleştirmemek çok daha pahalıya mal olur. Bu yazıda kararı sezgiden çıkarıp basit bir hesaba bağlıyoruz.

Temel hesap ve eksik bıraktığı şey

Klasik hesap şudur: işin bir seferlik süresi × yapılma sıklığı × işin kalan ömrü = toplam kazanılacak süre. Bu sayı, otomasyonu yazma süresinden büyükse yatırım mantıklıdır.

Ancak bu hesap iki önemli kalemi atlar. Birincisi bakım maliyetidir: yazdığınız betik de bir yazılımdır, bozulur, ortam değişince güncellenmesi gerekir. İkincisi ise ekip çarpanıdır: aynı işi beş kişi yapıyorsa kazanç beşe katlanır. Bu yüzden gerçek hesap şöyle olmalıdır:

(Süre × Sıklık × Kalan ömür × Kişi sayısı) > (Yazma süresi + Tahmini bakım)

Süre hesabının geçersiz kaldığı durumlar

Bazı işlerde süre kazancı hiç önemli değildir; otomasyon başka bir sebeple gereklidir:

• Hata riski yüksekse. Elle yapılan bir üretim dağıtımı iki dakika sürebilir, ama bir adımın atlanması saatlerce kesintiye yol açabilir. Burada otomasyonun değeri süre değil, tutarlılıktır.
• İş nadir ama kritikse. Yılda iki kez yapılan bir geri yükleme işlemi, süre hesabına göre otomatikleştirmeye değmez. Ancak nadir yapıldığı için kimse adımları hatırlamaz — ve tam da bu yüzden yazılı ve çalıştırılabilir olması gerekir. Bu mantık yedek geri dönüş yazımızda ayrıntılı ele alınıyor.
• Yeni katılanlar için giriş engeliyse. Yerel ortamı kurmak yeni geliştiricinin iki gününü alıyorsa, bunu tek komuta indirmek her yeni katılımda geri öder.
• Bilgi tek kişide kilitliyse. "Bunu sadece Ahmet yapabiliyor" durumu bir risktir; betik hâline getirmek bilgiyi ekibe açar.

Ne otomatikleştirilmemeli?

Tersi de doğrudur. Şu durumlarda otomasyon genellikle zarar getirir:

Kuralları sürekli değişen işler. Her ay farklı bir istisna eklenen bir raporlama işi, betiği sürekli bakım gerektiren bir yüke dönüştürür.

Yargı gerektiren işler. Kod incelemesi, tasarım kararları veya müşteri iletişimi otomatikleştirilemez; yalnızca desteklenebilir.

Yakında ortadan kalkacak işler. Üç ay sonra kaldırılacak bir sistemin bakım işlemini otomatikleştirmek, ömrü kısa bir yatırımdır.

Dayanıklı betik yazmanın kuralları

Otomasyon kararı verildiyse, betiğin kendisinin bakım yükü olmaması için birkaç kural yeterlidir:

1. Hatada dur. Kabuk betiklerinde set -euo pipefail kullanmak, sessizce yanlış iş yapmayı engeller. Bir adım başarısız olduğunda devam eden betik, hiç olmayan betikten tehlikelidir.
2. Tekrar çalıştırılabilir olsun. Betiği iki kez çalıştırmak zarar vermemeli. Yarıda kalan bir işi baştan başlatabilmek, olay anında büyük rahatlıktır.
3. Önce ne yapacağını söylesin. Yıkıcı işlemler için bir "kuru çalıştırma" (dry run) seçeneği, betiğe duyulan güveni belirgin artırır.
4. Yolları ve sırları gömmeyin. Ortama bağlı değerler parametre veya ortam değişkeni olmalı; kimlik bilgileri asla betiğin içinde durmamalıdır.
5. Tek giriş noktası kurun. On ayrı betik yerine, tek bir make hedefi veya tek bir komut altında toplanan alt komutlar, ekibin ne olduğunu hatırlamasını kolaylaştırır.
6. Betiği de sürüm kontrolüne alın. Birinin kendi makinesinde duran betik, ekip için var sayılmaz.

Bu ilkeler, düzenli olarak çalışması gereken işler dağıtım hattına taşındığında daha da önemli hâle gelir; CI/CD yazımız bu geçişi ele alıyor.

Zamanlanmış işlerin sessiz başarısızlığı

Otomasyonun en tehlikeli hâli, çalıştığını sandığınız ama aslında hiç çalışmayan bir zamanlanmış görevdir. Cron veya görev zamanlayıcı kurulmamışsa, komut ne kadar doğru yazılmış olursa olsun hiçbir şey olmaz — ve hata da üretilmediği için kimse fark etmez. Bu yüzden her zamanlanmış işin bir başarı sinyali üretmesi ve beklenen sürede sinyal gelmediğinde uyarı çıkması gerekir. "Hata olursa haber ver" kurgusu, iş hiç çalışmadığında sessiz kalır.

Komut satırı verimliliğini artıran kısayollar için terminal kısayolları yazımıza, genel araç kurulumu için ise geliştirici araç seçimi yazımıza bakabilirsiniz. Kabuk betiği yazarken başvurulacak pratik bir kaynak olarak DigitalOcean topluluk rehberleri önerilebilir.

Sonuç

Otomasyon kararı, "bu iş sıkıcı mı?" sorusuyla değil, "kazanç yatırımı aşıyor mu?" hesabıyla verilir — ve bu hesaba bakım maliyetini, ekipteki kişi sayısını ve işin kalan ömrünü katmak şarttır. Süre kazancının küçük olduğu durumlarda bile, hata riskini azaltan veya bilgiyi tek kişiden kurtaran otomasyonlar neredeyse her zaman değerlidir. Bu hafta yaptığınız işleri kısaca gözden geçirin: üç kereden fazla tekrarladığınız ve her seferinde aynı adımları izlediğiniz bir iş varsa, otomasyon adayınız bulunmuş demektir. Ama önce şunu hesaplayın: yazması ne kadar sürer, ve kim bakacak?