--- title: "Tekrarlayan İşleri Otomatikleştirmek: Ne Zaman Script Yazmalı?" url: "https://cilginyazilim.com/blog/tekrarlayan-isleri-otomatiklestirmek-ne-zaman-script-yazmali" description: "Otomasyon yatırımı ne zaman geri döner? Süre hesabı, bakım maliyeti, otomatikleştirilmemesi gereken işler ve dayanıklı script yazma pratikleri." published: "2026-10-04T10:00:00+03:00" modified: "2026-10-04T10:00:03+03:00" author: "Çılgın Yazılım" category: "Geliştirici Araçları" tags: ["otomasyon", "ci/cd", "verimlilik", "ekip çalışması", "Yazılım Araçları", "bakım maliyeti", "otomatikleştirmek", "shell script", "makefile", "geliştirici deneyimi", "komut satırı", "onboarding", "araç seçimi"] site: "Çılgın Yazılım" language: "tr" --- # Tekrarlayan İşleri Otomatikleştirmek: Ne Zaman Script Yazmalı? Her tekrarlayan iş otomatikleştirilmeyi hak etmez. Yatırımın geri döneceği eşiği hesaplamanın basit yolu. 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. ![Otomasyon karar hesabı](https://cilginyazilim.com/uploads/blog/2026/07/tekrarlayan-isleri-otomatiklestirmek-ne-zaman-script-yazmali-ozet.png) *Süre kazancı tek ölçüt değildir; hata riskini azaltmak çoğu zaman daha değerlidir.* ## 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](https://cilginyazilim.com/blog/yedekleme-var-ama-geri-donus-denenmemis) 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](https://cilginyazilim.com/blog/ci-cd-nedir-kucuk-ekipler-icin-otomatik-dagitim) 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](https://cilginyazilim.com/blog/gelistirici-araclari-verimli-kurulum) bakabilirsiniz. Kabuk betiği yazarken başvurulacak pratik bir kaynak olarak [DigitalOcean topluluk rehberleri](https://www.digitalocean.com/community/tutorials) ö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? ## Sıkça Sorulan Sorular ### Otomasyon için hangi dili seçmeliyim? Ekibin okuyabildiği dil en iyisidir. Kısa sistem işleri için kabuk betiği yeterlidir; mantık karmaşıklaştığında veya hata yönetimi gerektiğinde Python gibi bir dile geçmek bakımı kolaylaştırır. ### Betikleri kim bakacak? Sahipsiz betikler bozulduğunda terk edilir. Her otomasyona bir sahip atamak ve betiği uygulama koduyla aynı depoda tutmak, bakımın sürmesini sağlar. ### Yapay zekâ araçlarıyla üretilen betiklere güvenilir mi? İlk taslak için hızlıdır, ancak yıkıcı işlemler içeren betikleri satır satır okumadan çalıştırmak risklidir. Özellikle silme ve üzerine yazma adımlarını mutlaka doğrulayın. ### Otomasyonun çalıştığını nasıl bilirim? Sessiz başarısızlığı engellemek için başarı sinyali izleyin: iş tamamlandığında bir kayıt veya bildirim üretsin, beklenen sürede gelmezse uyarı çıksın. --- Kaynak: [Tekrarlayan İşleri Otomatikleştirmek: Ne Zaman Script Yazmalı?](https://cilginyazilim.com/blog/tekrarlayan-isleri-otomatiklestirmek-ne-zaman-script-yazmali)