Uçtan Uca Entegrasyon: Bir Olayı Baştan Sona Yönetmek

Kazanimlar:

• Bir olayı tespit, teşhis, azaltma, kalıcı çözüm ve öğrenme aşamalarında yapay zeka desteğiyle uçtan uca yönetebilme
• Her aşamada yapay zekaya devredilebilen ile insan kararı gerektiren adımları ayırıp panik anında bile doğrulama disiplinini koruyabilme
• Yapay zekanın 'ne oluyor, nasıl yazılır' sorularında, insanın 'yapmalı mıyım, kim kefil' sorularında öncelikli olduğu altın kuralını iş refleksine dönüştürebilme

Uçtan Uca Entegrasyon: Bir Olayı YZ ile Baştan Sona Yönetmek

Önceki on ünitede parçaları öğrendiniz: script yazma, log analizi, izleme, yapılandırma, IaC, dokümantasyon, kestirimci bakım, değişiklik yönetimi ve güvenlik. Ama gerçek dünyada bu parçalar tek tek değil, bir olayın içinde iç içe gelir. Bu son ünitede parçaları birleştiriyoruz: gece yarısı başlayan bir olayı, tespitten kök nedene, düzeltmeden dokümantasyona kadar uçtan uca ve YZ'yi her aşamada doğru dozda kullanarak nasıl yöneteceğinizi bir bütün olarak göreceksiniz. Amaç yeni bir teknik öğretmek değil; öğrendiklerinizi bir mühendisin refleksi olarak birbirine bağlamak ve modül boyunca tekrarlanan tek gerçeği pekiştirmek: YZ her aşamada hızlandırır, aydınlatır ve taslaklar; ama teşhisi doğrulayan, komutu çalıştıran, değişikliği onaylayan ve sonucun sorumluluğunu taşıyan her zaman insandır.

Bu ünitede bir olayın yaşam döngüsünü — tespit, teşhis, müdahale, çözüm, öğrenme — ve YZ'nin her aşamadaki rolü ile sınırlarını bir örnek üzerinden bütünleştireceksiniz.

Bir olayın yaşam döngüsü

Her ciddi olay benzer aşamalardan geçer ve her aşamada YZ'nin farklı bir rolü vardır. Tespit: bir alarm öter, bir kullanıcı şikâyet eder, bir metrik baseline'dan sapar (Ünite 4). Onaylama ve kapsam: gerçekten bir sorun mu, ne kadar geniş? Teşhis: loglardan ve metriklerden kök nedene inme (Ünite 3). Müdahale ve azaltma: hasarı durdurma, geçici çözüm. Kalıcı çözüm: değişiklik yönetimiyle (Ünite 9) düzeltme, gerekiyorsa script (Ünite 2) veya yapılandırma (Ünite 5). Öğrenme: post-mortem ve runbook güncelleme (Ünite 7). YZ tespitte anomaliyi işaretler, teşhiste hipotez üretir, müdahalede seçenek sunar, çözümde taslak yazar, öğrenmede belge üretir — ama her aşamada karar noktasında insan durur.

İpucu: Bir olayın en tehlikeli anı, stresin en yüksek olduğu teşhis ve müdahale anıdır — tam da YZ'ye körü körüne güvenme dürtüsünün en güçlü olduğu an. Ne kadar acele ederseniz, "oku, doğrula, geri dönüşü hazırla" refleksine o kadar sıkı sarılın. Panik anında atlanan tek doğrulama, olayı ikiye katlar.

Baştan sona bir örnek

Somutlaştıralım. Saat 02:10'da bir alarm: ödeme servisi p99 yanıt süresi baseline'ın (250–400 ms) çok üstünde, 6 saniye. Tespit doğru: izleme çalıştı. Onaylama: birden çok bölgeden teyit, gerçek bir olay. Teşhis: mühendis son 20 dakikanın maskelenmiş logunu ve metriklerini YZ'ye verir; YZ bir zaman çizelgesi kurar ve yavaşlamanın 02:08'deki bir dağıtımdan hemen sonra başladığını işaretler — güçlü bir korelasyon, ama henüz hipotez. Mühendis bunu dağıtım kaydıyla doğrular: evet, 02:08'de bir sürüm çıkmış. Müdahale: en hızlı azaltma, dağıtımı geri almaktır; change request'teki rollback adımı hazırdır (Ünite 9). Mühendis rollback'i canary mantığıyla önce bir sunucuda uygular, yanıt süresi düzelir, sonra yayar. Kalıcı çözüm: gerçek kök neden (yeni sürümdeki indekssiz sorgu) sonraki gün sakin kafayla düzeltilecek. Öğrenme: YZ ile suçlamasız bir post-mortem taslaklanır ve "dağıtım sonrası p99 izleme" adımı runbook'a eklenir. Her aşamada YZ hızlandırdı; her karar noktasında insan doğruladı.

İnsan-YZ iş bölümünün altın kuralı

Modül boyunca gördüğünüz ayrım burada bir kurala dönüşür: YZ "ne oluyor, ne olabilir, nasıl yazılır" sorularında öndedir; "bunu şimdi yapmalı mıyım, buna kim kefil" sorularında insan öndedir. YZ yorulmaz, hızlıdır, geniş bilgiyi tarar ve taslak üretir — ama bağlamı tam bilmez, halüsinasyon üretebilir, sorumluluk taşıyamaz ve sizin kurumunuzun gizli bağımlılıklarını görmez. İnsan yavaştır ama bağlamı, sorumluluğu ve yargıyı taşır. En iyi sonuç ikisinin doğru iş bölümündedir: tekrarlayan, metinsel, üretilebilir işleri YZ'ye devredin; doğrulama, karar ve icrayı insanda tutun.

Üç mini vaka

Vaka 1 — Uçtan uca 40 dakika. Bir disk dolma olayında bir SRE tüm zinciri YZ ile hızlandırdı: alarmı baseline'la teyit etti (5 dk), maskeli logu YZ'ye özetletip ilk hatayı buldu (5 dk), YZ'nin "log rotasyonu durmuş" hipotezini gerçek sistemde doğruladı (5 dk), hazır bir temizleme scriptini dry-run ile çalıştırıp uyguladı (10 dk), post-mortem taslağını YZ'ye yazdırıp olguları doğruladı (15 dk). Toplam 40 dakika; YZ olmadan tahminen iki katı. Ama her aşamada doğrulama adımı vardı.

Vaka 2 — Panik anında atlanan doğrulama. Başka bir ekip, bir kesintide acele etti. YZ'nin ilk kök neden hipotezini (bir bağımlılık servisi) doğrulamadan kabul edip o servisi yeniden başlattı. Sorun düzelmedi çünkü gerçek neden başkaydı; üstelik gereksiz yeniden başlatma ikinci bir kesinti yarattı. Ders: acele, doğrulamayı atlamanın gerekçesi değildir; YZ hipotezi doğrulanmadan aksiyon, olayı büyütür.

Vaka 3 — Sınırın farkında olmak. Bir mühendis, karmaşık bir ağ sorununda YZ'nin ısrarla önerdiği bir yapılandırma değişikliğini uygulamak üzereydi. Ama değişiklik geri alınamaz görünüyordu ve YZ kurumun özel yönlendirme kurallarını bilmiyordu. Mühendis durdu, kıdemli bir ağ uzmanına danıştı ve YZ'nin önerisinin bu özel topolojide bir yönlendirme döngüsü yaratacağını öğrendi. YZ'nin sınırını bilmek, bir kesintiyi önledi.

Dört kopyalanabilir şablon

1) Olay tetikleme özeti (triyaj):

Rolün: kıdemli SRE, olay komutanı asistanı. Aktif bir olayvar. Sana vereceğim maskeli alarm/metrik/log'dan bana hızlıbir triyaj çıkar: (1) belirti nedir, (2) etki kapsamı nekadar, (3) ilk bakılması gereken 3 alan, (4) her biri içinsalt-okunur bir kontrol komutu. Karar ve icra bende; senyol göster. Veri: [maskeli]

2) Aşamalı olay yönetimi rehberi:

Şu belirti için [belirti] beni olay yaşam döngüsünde adımadım yönlendir: tespit teyidi, teşhis, azaltma, kalıcı çözüm,öğrenme. HER aşamada bana (a) ne yapmam gerektiğini, (b) YZ'yeneyi güvenle devredebileceğimi, (c) hangi kararı MUTLAKA kendimvermem gerektiğini söyle. Acele etsem bile atlamamam gerekendoğrulama adımlarını işaretle.

3) Karar noktası kontrolü:

Bir olayın ortasındayım ve şu aksiyonu almak üzereyim:[aksiyon]. Uygulamadan önce bana sor: (1) bu geri alınabilirmi, (2) hangi doğrulamayı yaptım/yapmadım, (3) rollback planımvar mı, (4) bu aksiyonun kök nedeni gerçekten çözdüğüne dairkanıtım var mı? Eksik bir şey görüyorsan beni durdur.

4) Olay sonrası bütünleşik öğrenme:

Az önce çözülen olay için [özet] bana: (1) suçlamasız birpost-mortem taslağı, (2) bu olayı önleyecek 3 kalıcı iyileştirme(izleme/otomasyon/yapılandırma), (3) güncellenmesi gerekenrunbook adımları, (4) benzer olay için erken uyarı sinyaliönerisi çıkar. Kanıtsız kök neden yazma; olgulara dayan.

Zayıf prompt / Güçlü prompt

Zayıf prompt:

Sistem çöktü, ne yapayım?

Panik hâlinde, bağlamsız ve doğrulama içermeyen bu istem, YZ'den genel ve muhtemelen tehlikeli tavsiyeler alır. Acele, en çok bu anda hataya yol açar.

Güçlü prompt:

Rolün: olay komutanı asistanı. Aktif olay: ödeme servisip99 yanıt süresi 02:10'dan beri baseline'ın (250-400 ms)15 katı. 02:08'de bir dağıtım yapıldığını biliyorum. Bana:(1) en olası hipotezi ve onu SALT-OKUNUR nasıl doğrulayacağımı,(2) en hızlı ve GERİ ALINABİLİR azaltma seçeneğini, (3) buazaltmayı uygulamadan önce kontrol etmem gereken riskleri ver.Icra ve onay bende. Ek veri: [maskeli metrik/log]

Olay aşaması

YZ'nin rolü

İnsanın kritik kararı

Tespit

Anomaliyi işaretleme

Gerçek olay mı, kapsam ne?

Teşhis

Hipotez üretme

Hangi hipotez doğrulandı?

Azaltma

Seçenek sunma

Hangi azaltmayı, geri alınabilir mi?

Kalıcı çözüm

Taslak/script

Değişikliği onaylama ve icra

Öğrenme

Post-mortem taslağı

Olguları ve dersleri doğrulama

Sık yapılan hatalar

• Panikte doğrulamayı atlamak. Acele, "oku-doğrula-geri dönüşü hazırla" refleksini bırakmanın gerekçesi değildir; stres arttıkça disiplin artmalı.
• Hipotezi kanıt sanmak. YZ'nin ilk kök neden önerisini teyit etmeden aksiyon almak olayı büyütür.
• YZ'nin bağlam sınırını unutmak. Kurumun gizli bağımlılıklarını YZ bilmez; kritik değişiklikte insan yargısı öndedir.
• Öğrenme aşamasını atlamak. Post-mortem ve runbook güncellemesi yapılmayan olay, aynı gece tekrar başlar.
• Sorumluluğu YZ'ye yıkmak. "YZ öyle dedi" bir savunma değildir; icranın sorumluluğu her zaman insandadır.

Dikkat: YZ'yi olay yönetiminde kullanmak, olay yönetimini öğrenmiş olmanın yerini almaz. Araç çökebilir, yanılabilir veya erişilemez olabilir. Temeli bilen mühendis YZ ile daha hızlıdır; temeli bilmeyen mühendis YZ ile daha hızlı hata yapar. Önce disiplini kurun, sonra hızı YZ'den alın.

Özetle

Gerçek dünyada parçalar tek tek değil bir olayın içinde iç içe gelir. Bir olayı tespitten öğrenmeye kadar yönetirken YZ her aşamada hızlandırır: anomaliyi işaretler, hipotez üretir, seçenek sunar, taslak yazar, post-mortem hazırlar. Ama her karar noktasında insan durur — teşhisi doğrular, azaltmayı seçer, değişikliği onaylar, sonucu sahiplenir. Altın kural nettir: YZ "ne oluyor, nasıl yazılır" sorularında, insan "yapmalı mıyım, kim kefil" sorularında öndedir. Panik anında disiplini artırın, hipotezi kanıttan ayırın, YZ'nin bağlam sınırını hatırlayın ve her olaydan bir runbook dersi çıkarın. Bu modülün özü tek cümledir: YZ güçlü bir asistandır; mühendislik sorumluluğu devredilemez.

Uygulama görevi

Geçmişte yaşadığınız (veya kurguladığınız) bir olayı baştan sona ele alın. Yukarıdaki "Aşamalı olay yönetimi rehberi" şablonuyla YZ'den olayı tespit-teşhis-azaltma-çözüm-öğrenme aşamalarında yönlendirmesini isteyin; her aşamada YZ'ye devredebileceğiniz ile kendinizin karar vermesi gereken adımı ayrı ayrı yazın. Teşhis aşamasında en az bir YZ hipotezini bir doğrulama komutuyla teyit edin. Son olarak "Olay sonrası bütünleşik öğrenme" şablonuyla bir post-mortem ve runbook güncelleme taslağı üretin. Tüm süreçte insan-YZ iş bölümünü 7 maddede özetleyin.

Kontrol listesi

• [ ] Olayı tespit, teşhis, azaltma, çözüm ve öğrenme aşamalarına ayırdım mı?
• [ ] Her aşamada YZ'ye devredilebilen ile insan kararı gereken adımları ayırdım mı?
• [ ] Teşhiste YZ hipotezini kanıttan ayırıp bir doğrulama komutuyla teyit ettim mi?
• [ ] Azaltmayı geri alınabilirlik ve rollback planı açısından değerlendirdim mi?
• [ ] Panik anında bile "oku-doğrula-geri dönüşü hazırla" refleksini korudum mu?
• [ ] Olaydan bir post-mortem ve runbook dersi çıkardım mı?

Modul Sinavi

1. Sistem ve ağ yönetiminde yapay zeka için en doğru konumlandırma aşağıdakilerden hangisidir?

• A) Yapay zeka bir asistan ve karar destek aracıdır; kritik icra kararlarının sorumluluğu ve son onayı insandadır ✔
• B) Yapay zeka insan onayı olmadan üretimde komut çalıştırıp değişiklik uygulayabilir
• C) Yapay zeka yalnızca metin yazmakta işe yarar, sistem ve ağ işleriyle ilgisi yoktur
• D) Yapay zeka her zaman insandan daha doğru karar verir, bu yüzden doğrulama gereksizdir

Aciklama: Yapay zeka script, log analizi ve doküman gibi taslak ve analiz üreten bir asistan ve karar destek aracıdır. Bir komutu çalıştırmak, bir değişikliği onaylamak gibi kesinti, veri kaybı ve güvenlik etkileyen icra kararlarının sorumluluğu ve son onayı yetkin mühendise aittir.

2. Yapay zekanın ürettiği bir komutu üretimde çalıştırmadan önce uygulanması gereken doğrulama refleksinin dört adımı hangisidir?

• A) Kopyala, yapıştır, çalıştır, umut et
• B) Oku ve anla, belgeye bağla, izole ortamda dene, geri dönüşü hazırla ✔
• C) Beğen, paylaş, kaydet, arşivle
• D) Sil, yeniden yaz, sıkıştır, gönder

Aciklama: Kritik bir çıktıya uygulanacak dört adım: (1) komutu satır satır oku ve anla, (2) bayrak ve sözdizimini resmi belgeye bağla, (3) izole/test ortamında, mümkünse dry-run ile dene, (4) yanlış giderse geri dönüş planını (yedek, snapshot) hazırla.

3. Bir otomasyon scriptinin 'idempotent' olması ne demektir ve neden önemlidir?

• A) Scriptin her çalışmada farklı sonuç üretmesi
• B) Scriptin yalnızca bir kez çalışabilmesi ve sonra silinmesi
• C) Scriptin ikinci kez çalıştırılınca zarar vermemesi; tekrar tetiklense bile güvenli olması ✔
• D) Scriptin hata yönetimi içermemesi

Aciklama: Idempotency, aynı scriptin iki veya daha çok kez çalıştırılınca ikinci koşuda zarar vermemesi veya hata üretmemesidir. 'Kullanıcı zaten varsa atla', 'dizin yoksa oluştur varsa dokunma' gibi mantık kurulur. Bu, otomasyonun yanlışlıkla tekrar tetiklense bile güvenle çalışmasını sağlar.

4. Yıkıcı işlemler (silme, yeniden başlatma) içeren bir scripti güvenli hale getirmenin en temel yolu nedir?

• A) Scripti mümkün olduğunca hızlı çalıştırmak
• B) Hata mesajlarını gizlemek
• C) Scripti doğrudan üretimde test etmek
• D) Yıkıcı işlemleri varsayılan dry-run arkasına almak ve gerçek uygulamayı açık bir onay bayrağına bağlamak ✔

Aciklama: Yıkıcı işlemleri varsayılan olarak dry-run (kuru çalışma) modunda tutmak ve gerçek uygulamayı yalnızca açık bir onay bayrağıyla (örneğin --apply) çalıştırmak, script çalıştığında ne olacağını önce görmeyi sağlar. Ayrıca boş değişken kontrolü (VAR:?) yol hatalarını önler.

5. Log analizinde 'korelasyon nedensellik değildir' ilkesi neyi ifade eder?

• A) Birlikte değişen iki olay illa neden-sonuç ilişkisinde değildir; nedensellik ayrıca doğrulanmalıdır ✔
• B) Loglarda korelasyon aramak zaman kaybıdır
• C) Birlikte değişen iki olaydan biri kesinlikle diğerinin nedenidir
• D) Nedensellik yalnızca yapay zeka tarafından belirlenebilir

Aciklama: İki olayın aynı anda gerçekleşmesi (korelasyon), birinin diğerine neden olduğu (nedensellik) anlamına gelmez; ikisi de üçüncü bir olayın sonucu olabilir. Yapay zekanın 'muhtemelen X, Y'ye neden oldu' önerisi bir hipotezdir ve sistemde doğrulanana kadar bulgu sayılmaz.

6. Performans izlemede yanıt süresini ölçerken neden ortalama yerine percentile (p95/p99) tercih edilir?

• A) Percentile hesaplaması ortalamadan daha kolaydır
• B) Ortalama, azınlığın yaşadığı kötü deneyimi gizler; percentile bu gizli sorunları ortaya çıkarır ✔
• C) Ortalama her zaman yanlıştır ve kullanılmamalıdır
• D) Percentile yalnızca CPU metrikleri için geçerlidir

Aciklama: Ortalama, kullanıcıların küçük bir kısmının yaşadığı çok kötü deneyimi gizler. Ortalama 200 ms görünse bile p99 6 saniye olabilir; bu, her yüz istekten birinin berbat yavaş olduğu anlamına gelir. Percentile, ortalamanın gizlediği bu azınlığın acısını görünür kılar.

7. Konfigürasyon yönetiminde 'drift' (yapılandırma kayması) nedir ve neden tehlikelidir?

• A) Ağ trafiğinin gece saatlerinde düşmesi
• B) Bir sunucunun fiziksel olarak yer değiştirmesi
• C) Sunucuların zamanla birbirinden ve standarttan sapması; sorun çıkana kadar görünmez olması ✔
• D) Yapılandırma dosyalarının otomatik yedeklenmesi

Aciklama: Drift, sunucuların zaman içinde belgelenmemiş elle değişikliklerle birbirinden ve standarttan sapmasıdır. Tehlikesi sessizliğidir: sorun çıkana kadar görünmez, sonra bir sunucu ötekilerden farklı davranır ve teşhisi saatler alır. Yapay zeka karşılaştırmayla drift'i görünür kılar; altın kaynak ilkesi önler.

8. IaC (Terraform gibi) araçlarında 'plan' adımı neden en hayati güvenlik korkuluğudur?

• A) Plan kodu daha hızlı çalıştırır
• B) Plan state dosyasını siler
• C) Plan yalnızca kod biçimlendirmesini düzeltir
• D) Plan, uygulamadan önce neyin ekleneceğini, değişeceğini ve SİLİNECEĞİNİ gösterir; veri kaybını önceden yakalatır ✔

Aciklama: Plan (terraform plan / ansible --check), kodu uygulamadan önce 'ne değişecek' önizlemesi verir: kaç kaynak eklenecek, değişecek, silinecek. Özellikle 'destroy' ve 'forces replacement' satırları veri kaybı riskini uygulamadan önce gösterir. Planı okumadan apply etmek en pahalı hatalardandır.

9. Terraform state dosyası neden özenle korunmalı ve yapay zekaya veya açık depolara yapıştırılmamalıdır?

• A) State dosyası içine düz metin sırlar düşebilir; sızarsa kimlik bilgileri ifşa olur ✔
• B) State dosyası çok büyük olduğu için
• C) State dosyası okunamaz biçimde şifrelidir zaten
• D) State dosyası paylaşıldığında kod daha hızlı çalışır

Aciklama: State dosyası, yönetilen altyapının mevcut durumunu tutar ve içine düz metin sırlar (veritabanı parolaları, anahtarlar) düşebilir. Bu yüzden şifreli, erişimi kısıtlı, kilitli bir uzak backend'de tutulmalı; asla halka açık bir araca veya depoya verilmemelidir, aksi halde sır sızar.

10. Dokümantasyonda 'yanlış bir runbook, hiç runbook olmamasından daha tehlikelidir' ifadesi neyi vurgular?

• A) Runbook yazmak zaman kaybıdır
• B) Test edilmemiş bir runbook krizde körü körüne uygulanır; yanlış bir adım felakete yol açabilir ✔
• C) Runbook'lar yalnızca yöneticiler için yazılır
• D) Dokümantasyon hiçbir zaman güncellenmemelidir

Aciklama: Runbook'suz ekip kriz anında dikkatli ve şüpheci davranır; ama 'resmi' bir runbook'a sahip kişi onu stres altında sorgulamadan uygular. Runbook test edilmemişse ve bir adımı yanlışsa, körü körüne uygulama felakete yol açar. Bu yüzden her runbook gerçek ortamda baştan sona test edilip damgalanmalıdır.

11. Kestirimci bakımda bir diskin arızaya yaklaştığını anlamak için hangisi doğru yaklaşımdır?

• A) Tek bir kötü SMART değerinde diski hemen değiştirmek
• B) SMART verisini tamamen görmezden gelmek
• C) Değerlerin zaman içindeki trendine bakmak; tutarlı ve hızlanan artışı sinyal saymak ✔
• D) Yalnızca disk tamamen çöktükten sonra harekete geçmek

Aciklama: Tek bir kötü SMART okuması panik sebebi değildir; disklerde ara sıra düzeltilen hatalar normaldir. Asıl sinyal trenddir: reallocated sector gibi değerlerin zaman içinde tutarlı ve hızlanan biçimde artması. Bu yüzden yapay zekaya tek okuma değil bir zaman serisi verilir.

12. Bir üretim değişikliğinde en çok atlanan ama en kritik iki parça hangisidir?

• A) Değişikliğin rengi ve adı
• B) Değişikliği yapan kişinin unvanı ve departmanı
• C) Değişikliğin sosyal medyada duyurulması
• D) Geri dönüş (rollback) planı ve başarı doğrulama kriteri ✔

Aciklama: Bir değişiklik uygulanmadan önce 'kötü giderse tam olarak nasıl geri dönerim' (rollback planı) ve 'başarılı olduğunu nasıl kanıtlarım' (başarı doğrulama kriteri) sorularına yazılı cevap yoksa, o değişiklik henüz hazır değildir. Bu ikisi olmadan bozuk bir değişiklik 'tamamlandı' sanılabilir.

13. Bir güvenlik dağıtımını (yeni sürüm/yama) tüm sunuculara aynı anda yaymak yerine 'canary' yaklaşımı neden tercih edilir?

• A) Değişiklik önce küçük bir kısma uygulanır; bir hata tüm filoyu değil küçük bir kısmı etkiler ve erken yakalanır ✔
• B) Canary dağıtım daha az elektrik tüketir
• C) Canary dağıtım doğrulamayı tamamen gereksiz kılar
• D) Canary dağıtım yalnızca veritabanları için geçerlidir

Aciklama: Canary dağıtım, değişikliği önce küçük bir kısma (bir sunucu, kullanıcıların %5'i) uygulayıp izlemektir. Böylece bir hata tüm filoyu değil küçük bir kısmı etkiler ve erken yakalanır. Tek seferde yayılan bir hata ise tüm kullanıcıları aynı anda vurur.

14. Yapay zekayı güvenlik işlerinde kullanırken değişmez etik ve yasal kural nedir?

• A) Yapay zeka her sistemde serbestçe zafiyet taraması için kullanılabilir
• B) Etik kurallar yalnızca büyük kurumlar için geçerlidir
• C) Yalnızca yetkili olunan sistemlerde ve savunma amacıyla kullanılır; yetkisiz erişim veya saldırı için kullanımı suçtur ✔
• D) Öğrenmek amacıyla başkasının sistemine sızmak serbesttir

Aciklama: Sistem ve ağ bilgisi çift kullanımlıdır. Yapay zeka yalnızca yazılı yetkinizin olduğu sistemlerde ve savunma amacıyla (log tehdit tespiti, sertleştirme, olay müdahalesi) kullanılabilir. Size ait olmayan bir sistemi taramak veya sızmak için kullanmak yetkisiz erişimdir ve suçtur; öğrenmek için izole bir laboratuvar kullanılmalıdır.