Kazanimlar:
- Bash, Python ve PowerShell'in güçlü olduğu alanları kavrayıp yapay zekaya güvenli, korumalı betik taslakları ürettirebilme
- Betiklere hata durdurması (set -euo pipefail), boş değişken kontrolü, dry-run modu ve loglama gibi korkuluklar ekleyebilme
- Yıkıcı komutları okuyup önce izole ortamda ve dry-run ile deneme, secret'ı betiğe gömmeme disiplinini uygulayabilme
DevOps'un ruhu tek bir cümlede özetlenir: "İki kez yaptığın işi otomatikleştir." Elle yapılan her tekrarlı iş — log temizleme, yedek alma, sunucu sağlık kontrolü, toplu dosya işleme — hem zaman yer hem de er geç insan hatasıyla bozulur. Bu işleri betikler (scripts) devralır: bir dizi komutu sırayla, güvenilir ve tekrarlanabilir biçimde çalıştıran küçük programlar. DevOps profesyoneli üç dili sıkça kullanır: Bash (Linux/Unix kabuk betikleri için), Python (karmaşık mantık, API çağrısı, veri işleme için) ve PowerShell (Windows ve bulut yönetimi için).
YZ, betik üretiminde belki de en pratik değeri sunduğu yerdedir: bir cümlelik tarifle çalışan bir taslak çıkarır, gizemli bir hatayı çözer, bir betiği başka dile çevirir. Ama bir betik körü körüne çalıştırıldığında tehlikelidir — yanlış bir rm, bir Remove-Item -Recurse, dosyaları geri dönüşü olmadan siler. Bu yüzden bu ünitenin şiarı: YZ betiği yazsın, sen oku, önce güvenli modda dene, sonra çalıştır.
Hangi dili ne zaman seçmeli? Kabaca bir kural: iş, birkaç sistem komutunu peş peşe çalıştırmaktan ibaretse (dosya kopyala, servis yeniden başlat, arşiv al) Bash en doğal seçimdir çünkü Linux sunucularda her yerde hazırdır. İş, karar mantığı, döngü, veri dönüştürme, bir API'ye istek atma veya JSON işleme içeriyorsa — yani 20 satırı aşan bir mantık varsa — Python okunabilirliği ve zengin kütüphaneleriyle öne çıkar; karmaşık bir Bash betiği hızla anlaşılmaz hale gelirken Python bakımı kolay kalır. İş Windows sunucuları, Active Directory veya Azure yönetimi içeriyorsa PowerShell doğal ortamdır çünkü nesne tabanlı yapısı bu platformlarla derinden bütünleşir. YZ'ye betik isterken hangi dili neden seçtiğinizi belirtmek, çıktının ortamınıza uygun ve idiyomatik olmasını sağlar.
Adım adım: güvenli betik üretimi
- Görevi ve ortamı tarif et. Ne yapacak, hangi işletim sistemi/kabuk, hangi kısıtlar?
- Güvenlik korkuluklarını iste. Bash'te set -euo pipefail (hata olunca dur, tanımsız değişkende dur), tehlikeli işlemler için onay sorusu, silme yerine önce taşıma.
- Kuru çalıştırma (dry-run) modu iste. Betik --dry-run ile ne yapacağını yazsın ama yapmasın.
- Oku ve anla. Her satırın, özellikle silme/taşıma/ağ işlemlerinin ne yaptığını doğrula.
- İzole ortamda dene. Test klasöründe, örnek veriyle çalıştır.
- Loglama ekle. Betik ne yaptığını kaydetsin ki sonradan izlenebilsin.
Güvenli betiğin olmazsa olmazları
Bir üretim betiği şu korkulukları içermelidir:
- Hata durumunda durma. Bash: set -euo pipefail. PowerShell: $ErrorActionPreference = 'Stop'. Bir adım başarısızsa sonrakiler çalışmasın.
- Idempotency (yinelenebilirlik). Betik iki kez çalışırsa iki kat hasar vermesin; "zaten varsa atla" mantığı.
- Onay ve dry-run. Yıkıcı işlemler için "emin misiniz?" veya --dry-run bayrağı.
- Girdi doğrulama. Parametreler beklenen biçimde mi? Boş bir değişken rm -rf "$DIR"/ ifadesini rm -rf / felaketine çevirebilir.
- Loglama. Ne, ne zaman yapıldı kaydı.
İpucu: Bash'te en tehlikeli hata, boş bir değişkenle silme yapmaktır. rm -rf "$DIR" ifadesinde $DIR boşsa kök dizini silmeye çalışır. set -u (tanımsız değişkende dur) ve silmeden önce [ -n "$DIR" ] kontrolü hayat kurtarır. YZ'den betik isterken bu korumaları açıkça isteyin.
Güvenlik: secret ve yıkıcı komutlar
İki büyük tehlike:
- Secret'ı betiğe gömmek. Parola, token betik içinde düz metin olmamalı; ortam değişkeninden veya kasadan okunmalı. Betikler Git'e girer; gömülü secret kalıcı sızıntıdır.
- Yıkıcı komutlar. rm -rf, Remove-Item -Recurse -Force, DROP TABLE, terraform destroy — bunları bir betikte gördüğünüzde durup iki kez düşünün. YZ'nin ürettiği yıkıcı komutu asla önce prod'da denemeyin.
Dikkat: YZ'ye "şu dosyaları temizleyen bir script yaz" dediğinizde, ürettiği find ... -delete veya rm komutunun kapsamını dikkatle okuyun. Bir joker (*) veya yanlış yol, silmek istediğinizden fazlasını siler. Her zaman önce betiği silme yerine "silinecekleri listele" moduyla çalıştırın.
Üç dilin karşılaştırması
Kriter
Bash
Python
PowerShell
En iyi olduğu yer
Linux kabuk, komut zinciri
Karmaşık mantık, API, veri
Windows, bulut yönetimi
Öğrenme eğrisi
Orta (tuzaklı)
Kolay
Orta
Hata yönetimi
set -euo pipefail
try/except
try/catch, -ErrorAction
Taşınabilirlik
Unix/Linux/mac
Her yerde
Çapraz platform (PS 7+)
Ne zaman
Kısa, sistem işleri
20 satırdan uzun mantık
Windows/AD/Azure
Üç mini vaka
Vaka 1 — 2 saatlik el işi 5 dakikaya. Bir mühendis her hafta 40 sunucudan log toplayıp arşivliyor, 2 saat harcıyordu. YZ'ye görevi ve set -euo pipefail + dry-run korumalarını tarif edip bir Bash betiği ürettirdi. Betiği önce dry-run'la doğruladı, sonra planlanmış göreve (cron) bağladı. Haftalık iş 5 dakikaya indi ve insan hatası ortadan kalktı.
Vaka 2 — boş değişken felaketi önlendi. YZ'nin ürettiği temizlik betiğinde rm -rf "$TARGET"/* vardı ama TARGET bir yerde atanmazsa boş kalıyordu. Mühendis okurken bunu fark etti; set -u ve [ -n "$TARGET" ] || exit 1 kontrolü ekledi. Test sırasında değişken boş kaldı ve betik felaket yerine güvenle durdu.
Vaka 3 — gömülü token yakalandı. YZ, bir API'ye istek atan Python betiğine kolaylık olsun diye TOKEN = "ghp_gerçekbirtokendi" satırı koydu (örnek olarak). Mühendis bunu kaldırıp os.environ["TOKEN"] ile ortam değişkeninden okumaya çevirdi ve token'ı iptal edip yeniledi. Betik Git'e gitseydi token herkese açık olurdu.
Dört kopyalanabilir şablon
1) Güvenli Bash betiği:
Bir Bash betiği yaz: [GÖREV]. Zorunlu kurallar:- Başta `set -euo pipefail`.- Silme/taşıma yapan her yerde değişkenin boş olmadığını kontrol et.- `--dry-run` bayrağı: bu modda ne yapacağını yazsın ama yapmasın.- Secret'ı gömme; ortam değişkeninden oku.- Her adımda bilgilendirici log bas.Betiği yorumlarla ver ve en tehlikeli satırı işaretle.
2) Betik açıklama/denetim:
Aşağıdaki betiği satır satır açıkla ve güvenlik açısından denetle:gömülü secret, yıkıcı komut (rm/Remove-Item/DROP), doğrulanmamışgirdi, hata yönetimi eksikliği var mı? Her riski önem sırasıylave düzeltmesiyle yaz. Betik: [KOD]
3) Dil çevirisi:
Şu [KAYNAK DİL] betiğini [HEDEF DİL]'e çevir. Davranışı bire birkoru, hedef dilin idiyomatik hata yönetimini kullan, gömülü secretvarsa ortam değişkenine taşı. Farklı davranabilecek noktaları not et.Betik: [KOD]
4) Planlı görev (cron/scheduled task):
Şu betiği [SIKLIK: ör. her gece 02:00] çalıştıracak bir zamanlamatanımı yaz ([cron / systemd timer / Windows Task Scheduler]).Başarısızlıkta beni nasıl uyaracağını (log/exit code/bildirim) veüst üste binmeyi (overlap) nasıl önleyeceğini de ekle.
Zayıf prompt / Güçlü prompt
Zayıf: "Eski dosyaları silen bir script yaz."
Sonuç: kapsamı belirsiz, korumasız, dry-run'sız bir rm betiği; yanlış klasörde çalışırsa geri dönüşü olmayan silme yapar.
Güçlü: "Bash betiği yaz: /var/log/app altında 30 günden eski .log dosyalarını silsin. set -euo pipefail kullan, hedef dizin boşsa dur, önce --dry-run ile silinecekleri listelesin, her işlemi logla, secret gömme. En tehlikeli satırı işaretle."
Fark: ikinci istem tam kapsamı, güvenlik korkuluklarını ve dry-run beklentisini verir; çıktı güvenle çalıştırılabilir.
Sık yapılan hatalar
- Betiği okumadan çalıştırmak. Özellikle silme/taşıma satırları felakete yol açar.
- Boş değişken kontrolü yapmamak. rm -rf "$X"/ ile kök dizini silme klasik felaketi.
- `set -euo pipefail` / `-ErrorAction Stop` atlamak. Bir adım patlar, betik körü körüne devam eder.
- Secret'ı betiğe gömmek. Git'e giden kalıcı sızıntı.
- Dry-run'sız yıkıcı işlem. Önce "ne yapacağını göster", sonra yap.
- İlk denemeyi prod'da yapmak. İzole test ortamı olmadan çalıştırmak.
Özetle
DevOps otomasyonun sanatıdır; tekrarlı işler Bash, Python ve PowerShell betiklerine devredilir. YZ, betik taslağı üretmekte, hata çözmekte ve dil çevirmekte son derece pratiktir — ama güvenli bir betik set -euo pipefail gibi hata korkuluklarını, boş değişken kontrolünü, dry-run modunu, gömülü secret'sızlığı ve loglamayı içermelidir. Her betiği, özellikle yıkıcı komutlar içerenleri, okuyup önce izole ortamda ve dry-run ile denemek sizin sorumluluğunuzdadır.
Uygulama görevi
Tekrarlı bir işinizi (log arşivleme, yedek, temizlik) seçin. (1) "Güvenli Bash betiği" şablonuyla YZ'den korumalı bir betik ürettirin. (2) "Betik açıklama/denetim" şablonuyla aynı betiği güvenlik açısından denetletin ve YZ'nin işaretlediği en tehlikeli satırı bulun. (3) Betiği bir test klasöründe örnek dosyalarla, önce --dry-run ile çalıştırıp davranışını doğrulayın.
Kontrol listesi
- [ ] İstememe görevi, işletim sistemini/kabuğu ve güvenlik korkuluklarını yazdım.
- [ ] Betikte set -euo pipefail / -ErrorAction Stop gibi hata durdurması var.
- [ ] Silme/taşıma öncesi boş değişken ve girdi kontrolü ekledim.
- [ ] Yıkıcı işlemler için --dry-run/onay mekanizması var.
- [ ] Betikte gömülü secret yok; değerler ortam değişkeninden/kasadan geliyor.
- [ ] İlk denemeyi izole test ortamında, dry-run ile yaptım.