Kazanimlar:
- Yapay zekanın DevOps zincirinin (pipeline, yapılandırma, betik, log) neresinde gerçek zaman kazandırdığını, neresinde prod'a etki eden kararların insana kaldığını görev risk düzeyine göre ayırt edebilme
- Her yapay zeka çıktısını kaynağa bağlama, kuru çalıştırma ve sistem süzgecinden geçirme adımlarıyla doğrulayan bir disiplin uygulayabilme
- Secret'ları asla isteme yapıştırmama, maskeleme ve yalnızca yetkili sistemlerde savunma amaçlı çalışma alışkanlığını edinebilme
Bir gece 03:14'te telefonunuz çalar: ödeme servisi düşmüştür, her dakika para ve itibar kaybediliyordur. Bir başka gün, tek bir yanlış komut binlerce sunucuyu yeniden başlatır. DevOps profesyonelinin dünyası budur — yazılımın kod deposundan (yazılımın kaynağının saklandığı yer) çıkıp müşterinin eline ulaşana kadar geçtiği bütün boruların, otomasyonun ve nöbetin sorumluluğu. DevOps, "Development" (geliştirme) ve "Operations" (işletme) kelimelerinin birleşimidir: yazılım geliştirme ile onu çalıştırma işini tek bir hızlı, güvenilir akışta buluşturan kültür ve pratikler bütünüdür. Bu akışın her adımı bir komut, bir yapılandırma dosyası, bir betik (script) üretir. İşte yapay zeka (YZ — geçmiş veriden örüntü çıkarıp metin, kod ve tahmin üreten yazılım) tam da bu metin bolluğunun içinde size müthiş zaman kazandırır.
Ama bu modülün en baştaki sözü nettir: YZ bir asistandır, taslak üreticidir ve karar destek aracıdır; canlı ortama (prod — production, gerçek müşterilerin kullandığı sistem) neyin, ne zaman gideceğine ve bir gece yarısı hangi düğmeye basılacağına karar veren, sorumluluğu taşıyan siz kalırsınız. DevOps'ta bir hatanın maliyeti dakikalar değil, kesinti, veri kaybı ve güvenlik ihlalidir. Bu yüzden bu ilk ünitede araca değil disipline odaklanacağız.
DevOps zincirinin neresinde YZ işe yarar?
DevOps işlerini iki büyük kümeye ayıralım. Birinci küme: tekrarlayan, metin ve yapılandırma üretilebilir işler. Bir CI/CD (Continuous Integration / Continuous Delivery — kodu otomatik test edip yayına hazırlayan boru hattı) tanımını yazmak, bir Dockerfile (bir uygulamayı konteynere paketleyen tarif dosyası) taslağı hazırlamak, karmaşık bir Terraform (altyapıyı kod olarak tanımlayan araç) bloğunu açıklamak, bir log yığınını (sistemlerin ürettiği olay kayıtları) özetleyip anormalliği işaretlemek, bir bash betiği taslağı üretmek. Bu işlerde YZ dakikaları saniyeye indirir ve yorulmaz.
İkinci küme: sonucu kesinti, para veya güvenlik olan kararlar. Bir sürümün prod'a çıkıp çıkmayacağı, bir gece yarısı hangi servisin yeniden başlatılacağı, bir gizli anahtarın (secret) nasıl saklanacağı, bir maliyet kesintisinin hangi kaynağı kapatacağı. Bu kararlar bağlam, sistem bilgisi ve sorumluluk ister. YZ burada seçenekleri ve riskleri görünür kılar — ama "uygula" tuşuna siz basarsınız.
Ayrımı bir cümleyle netleştirelim: YZ "bu yapılandırma ne yapıyor ve nasıl yazılır" sorularında güçlüdür; "bunu prod'a uygulayayım mı ve buna kim kefil" sorularında karar sizindir.
İpucu: Bir işi YZ'ye vermeden önce sorun: "Bu çıktı yanlışsa ne kaybederim?" Cevap "birkaç dakika" ise rahatça devredin. Cevap "prod kesintisi, veri kaybı veya sızıntı" ise YZ taslak üretsin, kararı ve uygulamayı siz doğrulayın.
Adım adım: bir YZ destekli DevOps işi nasıl yürür?
- Bağlamı topla. Hangi bulut (AWS, Azure, GCP), hangi araç sürümü, hangi kısıtlar? YZ'ye eksik bağlam verirseniz eksik ve tehlikeli çıktı alırsınız.
- Net görev tanımla. "Bir pipeline yaz" değil; "GitHub Actions ile, main dalına push'ta çalışan, testleri koşan, Docker imajı build eden ama deploy etmeyen bir workflow yaz" deyin.
- Taslağı üret. YZ ilk sürümü yazsın.
- Doğrula. Sözdizimini denetle, gizli bilgi sızmış mı bak, dry-run (kuru çalıştırma — gerçekten uygulamadan ne yapacağını gösteren mod) ile test et.
- Sandbox'ta dene. Asla ilk denemeyi prod'da yapmayın; bir test/staging ortamında koşun.
- Kademeli uygula ve izle. Metrikleri ve logları izleyerek yayına alın.
Doğrulama disiplini: üç adım
YZ akıcı ve kendinden emin konuşur; bu doğru olduğu anlamına gelmez. YZ zaman zaman halüsinasyon üretir — var olmayan bir komut bayrağını (flag), bir bulut servis adını veya bir yapılandırma anahtarını gerçekmiş gibi uydurur. DevOps'ta uydurma bir --force bayrağı veri silebilir, uydurma bir IAM (Identity and Access Management — kimlik ve erişim yetkilendirme) izni güvenlik açığı yaratır. Refleks:
- Kaynağa bağla. YZ'nin verdiği her komut ve bayrak resmi dokümanda gerçekten var mı? "Bu bayrağın hangi sürümde geldiğini ve resmi dokümandaki adını söyle" diye sorun; emin değilse güvenmeyin.
- Kuru çalıştır. terraform plan, kubectl --dry-run, --check gibi modlarla gerçekten uygulamadan ne olacağını görün.
- Sistem süzgecinden geçir. Çıktı sizin mimarinize, güvenlik politikanıza ve mevcut kaynak adlarına uyuyor mu? Alan bilginiz son filtredir.
Dikkat: "YZ öyle yazdı" bir gerekçe değildir. Bir prod kesintisinde sorumluluk YZ'ye değil, o komutu doğrulamadan çalıştıran kişiye aittir. Doğrulanmamış bir YZ komutu, okunmadan çalıştırılan bir rm -rf kadar risklidir.
Güvenlik ve secrets: asla sızdırmayın
DevOps'ta en kritik gizlilik kuralı secrets ile ilgilidir. Secret; parola, API anahtarı, veritabanı bağlantı dizesi, özel sertifika gibi ele geçirilirse tüm sisteminizi açan gizli bilgidir. Hiçbir gerçek secret'ı bir YZ istemine (prompt) yapıştırmayın. Bir kod bloğunda gerçek bir AWS erişim anahtarı, bir .env dosyasının içeriği veya bir üretim veritabanı parolası varsa, bunları YZ'ye vermeden önce AKIA... yerine <AWS_ACCESS_KEY> gibi yer tutucularla (placeholder) maskeleyin.
Ayrıca YZ'nin ürettiği kodu da denetleyin: YZ bazen kolaylık olsun diye secret'ı doğrudan koda gömen (hardcode) örnekler üretir. Bu bir güvenlik açığıdır. Doğrusu, secret'ların bir sır kasasında (Vault, AWS Secrets Manager, Azure Key Vault) tutulup çalışma anında ortam değişkeni (environment variable) olarak enjekte edilmesidir.
Bu alandaki bir başka etik ve yasal sınır: savunma amaçlı kullanım. YZ'yi sistemlerinizi sağlamlaştırmak, açık taramak, log'dan saldırı izi çıkarmak için kullanın. Başkasının sistemine izinsiz erişim, yetkisiz tarama veya saldırı aracı üretmek yasa dışıdır ve bu platformun kapsamı dışındadır. Her zaman yetkiniz olan, sözleşmeyle yazılı izin aldığınız sistemlerde çalışın.
Hangi veri hangi araca girer?
Veri türü
Örnek
Uygun araç
Açık veri
Resmi doküman, açık kaynak kod
Her araç
İç veri (sır değil)
Genel mimari şeması, jenerik pipeline
Kurum onaylı araç
Gizli/hassas
Secret, prod IP/topoloji, müşteri verisi
Yalnızca kurum sözleşmeli, verisi eğitime gitmeyen araç; maskeleyerek
Üç mini vaka
Vaka 1 — Zaman doğru yerde kazanıldı. Bir DevOps mühendisi, 300 satırlık eski bir Jenkins pipeline'ını GitHub Actions'a taşımak için 6 saat ayırmıştı. YZ'ye adım adım açıklatıp taslak ürettirerek işi 90 dakikaya indirdi. Kazanılan zamanı, YZ'nin ürettiği her adımı staging'de tek tek doğrulamaya harcadı. YZ mekanik çeviriyi aldı; doğrulama insanda kaldı.
Vaka 2 — Doğrulama felaketi önledi. Bir ekip, YZ'den bir Terraform temizlik betiği istedi. YZ akıcı bir kod verdi; ama mühendis terraform plan çalıştırınca betiğin kullanılan bir üretim veritabanını da silmeyi planladığını gördü — YZ kaynak filtresini yanlış yazmıştı. Kuru çalıştırma, saatlerce sürecek bir veri kaybını önledi.
Vaka 3 — Secret sızıntısından dönüş. Bir stajyer, "şu deploy hatası neden" diye sorarken tüm .env dosyasını, içindeki gerçek üretim veritabanı parolasıyla halka açık bir araca yapıştırdı. Kıdemli mühendis anahtarları anında iptal edip (rotate) yeniden üretti. Doğru yol: parolayı <DB_PASSWORD> ile maskeleyip yalnızca hata mesajını paylaşmaktı.
Dört kopyalanabilir şablon
1) İş uygunluğu değerlendirme:
Rolün: kıdemli DevOps/SRE danışmanı.Sana bir görev tarif edeceğim. Bana (1) bunun YZ'ye güvenledevredilebilir bir taslak/analiz işi mi, yoksa prod'a etki edenkritik bir karar mı olduğunu; (2) yanlış giderse en kötü sonucu;(3) uygulamadan önce yapılması gereken doğrulama adımlarını söyle.Görev: [BURAYA]
2) Güvenli bağlam verme (secret maskeleme):
Aşağıdaki hatayı analiz et. Tüm secret'ları <PLACEHOLDER> ilemaskeledim; sen de çözümde ASLA gerçek secret üretme, yer tutucukullan ve secret'ı koda gömme, sır kasasından okumayı öner.Hata/log: [MASKELENMİŞ İÇERİK]
3) Komut doğrulama:
Şu komutu bana açıkla: her bayrağın ne yaptığını, hangi araçsürümünde geçerli olduğunu ve en tehlikeli yan etkisini yaz.Sonunda bunu prod'da çalıştırmadan önce yapılacak 3 kontrolü listele.Komut: [BURAYA]
4) Öğrenme/kavram sorgusu:
Bana [KAVRAM: örn. blue-green deployment] kavramını bir DevOpsmühendisine anlatır gibi açıkla: ne işe yarar, ne zaman kullanılır,ne zaman kullanılmaz, tipik 2 hata. Kısa ve somut ol.
Zayıf prompt / Güçlü prompt
Zayıf: "Bana bir deploy scripti yaz."
Sonuç: hangi bulut, hangi araç, hangi ortam belli değil; YZ genel, muhtemelen prod'a uymayan, secret'ı koda gömen bir betik üretir.
Güçlü: "AWS ECS'e (Elastic Container Service) deploy eden bir bash betiği taslağı yaz. Bölge eu-central-1, imaj ECR'dan geliyor. Secret'ları asla koda gömme, AWS Secrets Manager'dan oku. Her adımda hata olursa dur (set -euo pipefail). Betiği prod'da çalıştırmadan önceki 3 doğrulama adımını da yaz."
Fark: ikinci istem bulutu, aracı, ortamı, güvenlik kuralını ve doğrulama beklentisini verir — çıktı doğrudan işe yarar ve güvenlidir.
Sık yapılan hatalar
- Gerçek secret'ı isteme yapıştırmak. En sık ve en tehlikeli hata. Her zaman maskeleyin.
- Bağlamsız istem. Bulut, sürüm, ortam belirtmeden istenen çıktı çoğu zaman yanlış sürüme veya yanlış mimariye aittir.
- Kuru çalıştırmayı atlamak. plan/--dry-run yapmadan uygulamak, DevOps'ta en pahalı kısayoldur.
- İlk denemeyi prod'da yapmak. Her yeni YZ çıktısı önce test/staging'de koşulmalı.
- "YZ dedi" ile sorumluluğu devretmek. Sorumluluk her zaman uygulayan mühendiste kalır.
- Halüsinasyon bayrağa güvenmek. Var olmayan bir komut bayrağını sorgusuz çalıştırmak.
Özetle
DevOps ve bulutta YZ; pipeline, yapılandırma, betik ve log gibi metin ağırlıklı işlerde büyük hız kazandıran bir asistandır. Ama prod'a etki eden kararların, secret yönetiminin ve son uygulamanın sorumluluğu yetkin mühendiste kalır. Üç adımlı doğrulama (kaynağa bağla, kuru çalıştır, sistem süzgecinden geçir), secret'ları asla sızdırmama ve yalnızca yetkili sistemlerde savunma amaçlı çalışma, bu modülün taşıyıcı ilkeleridir.
Uygulama görevi
Kendi işinizden (veya bir örnek projeden) son yaptığınız bir DevOps görevini seçin. (1) Bu görevi yukarıdaki "iş uygunluğu değerlendirme" şablonuyla YZ'ye tarif edin ve sınıflandırmasını okuyun. (2) İçinde secret geçiyorsa maskeleyerek bir bağlam metni hazırlayın. (3) YZ'nin verdiği çıktıyı üç adımlı doğrulama ile denetleyin ve hangi adımda ne düzelttiğinizi bir cümleyle not edin.
Kontrol listesi
- [ ] Görevimi "devredilebilir iş" mi "kritik karar" mı diye sınıflandırdım.
- [ ] İsteme hiçbir gerçek secret yapıştırmadım; hepsini yer tutucuyla maskeledim.
- [ ] Buluta, araç sürümüne ve ortama dair bağlamı isteme ekledim.
- [ ] YZ çıktısını uygulamadan önce kuru çalıştırma/plan ile denetledim.
- [ ] İlk denemeyi prod'da değil, test/staging ortamında yaptım.
- [ ] Yalnızca yetkim olan sistemlerde, savunma amacıyla çalıştım.