Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

AI Ajanları Kurumsal IT Operasyonlarını ve İş Akışlarını Nasıl Değiştiriyor

AI ajanları monitoring, incident response ve rutin admin işlerini otomatikleştirerek kurumsal operasyonları değiştiriyor. Pratik etkiler ve deployment tüyoları.

Yapay ZekaAI AgentsIT OperationsAutomationDevOpsLLMAIOps

AI ajanları kurumsal IT operasyonlarının çalışma şeklini baştan aşağı değiştiriyor. Eskiden günümünün büyük bir kısmını yiyen rutin monitoring, incident response ve sistem bakım işlerini devralıyorlar. Bir chatbot gibi sadece soruları yanıtlamak yerine, bu ajanlar altyapınızda çok adımlı iş akışlarını gerçekten çalıştırabiliyorlar. Prometheus alertlerini okuyor, sunuculara SSH ile giriyor, servisleri yeniden başlatıyor, ticketları güncelliyor ve ne olduğunu özetliyorlar — hepsi minimal insan müdahalesiyle.

Ben kendi ortamımda bu değişimi yakından takip ediyorum. Takım iş akışları üzerindeki etkisi gerçek, ama satıcıların size anlattığı o sihirli insan yerine geçme hikayesi değil. Daha çok, hiç uyumayan ama hala korkuluklara ihtiyaç duyan çok hızlı bir junior admin eklemek gibi.

AI Ajanları IT Operasyonlarında Gerçekte Ne Yapıyor

Bir ajanın standart bir LLM chat arayüzünden ne farkı olduğunu netleştirelim. Bir chatbot promptlara yanıt verir. Bir ajan ise görevleri tamamlamak için araçlara, belleğe ve özerkliğe sahiptir. API erişimi, shell çalıştırma ve karar döngüleriyle sarılmış bir LLM olarak düşünün.

Şu an production ortamlarında ajanların yaptıklarını şunlar olarak görüyorum:

  • Alert triage: monitoring stacklerinden alertleri alıp bunları son deploymentlarla ilişkilendirme ve incident kanalınıza ilk analiz taslağını yazma
  • Log analizi: bir deploy sonrası ELK veya Loki'de error spike'larını sorgulama ve soruna yol açan commit ile birlikte bir özet döndürme
  • Patch yönetimi: CVE feed'lerini envanterinizle karşılaştırma ve etkilenen hostlar için ticket açma
  • Kapasite raporlama: time-series DB'nizden metrikleri çekme ve haftalık kapasite raporları oluşturma

Bunların hiçbiri bilim kurgu değil. AI karar mekanizmalı Kubernetes operatörleri veya LangChain ve AutoGPT gibi frameworkler üzerine inşa edilmiş özel ajanlar gibi araçlar ciddi production ortamlarında zaten çalışıyor.

Ajanlar Operasyon Pipeline'ına Nereye Oturuyor

Daha önce ağ yavaşlığının gerçek nedenini bulma yazımda (https://furkanikkan.com/urun/ag-yavasliginin-gercek-nedenini-bulmanin-7-yolu-50) belirttiğim gibi, troubleshooting çoğunlukla doğru soruları hızlıca sormakla ilgilidir. Ajanlar birden fazla sistemi paralel olarak sorgulayabildikleri için bu konuda çok iyiler.

Benim pipeline'ımda tipik bir ajan iş akışı şuna benziyor:

# Simplified agent decision loop
alert = fetch_prometheus_alert()
host = parse_target_host(alert)

if alert.severity == "critical":
    logs = ssh_and_tail(host, "/var/log/syslog", lines=100)
    recent_deploys = query_deployment_api(host, window="1h")
    summary = llm_summarize(alert, logs, recent_deploys)
    post_to_incident_channel(summary)
    if is_safe_auto_remediate(alert):
        execute_remediation(host, alert.action)

Oradaki anahtar kelime is_safe_auto_remediation. Bir ajanın kendi inisiyatifiyle production veritabanlarını yeniden başlatmasını istemezsiniz. Henüz değil, en azından.

Sistem Yöneticileri için İş Akışı Değişiklikleri

İşte insan tarafının devreye girdiği yer. Ajanlar tier-1 işlerini üstlenmeye başladığında, admin rolü birkaç yönde değişiyor:

  1. Yapan değil, gözden geçiren olursunuz — her alerti incelemek yerine, ajanın analizini gözden geçirip onaylar veya düzeltirsiniz
  2. Prompt engineering bir ops becerisi olur — iyi incident response promptları yazmak, iyi Bash scriptleri yazmaktan çok farklı değil
  3. Korkuluk tasarımı yeni güvenlik anlayışıdır — ajanların neye dokunup neye dokunamayacağını tanımlamak kritik, tıpkı sudo en az yetki yazımda anlattığım gibi (https://furkanikkan.com/urun/root-yetkisi-vermeden-linux-sistem-yonetimi-sudo-ile-en-az-yetki-46)

AI Ajanları Deploy Ederken Sık Yapılan Hatalar

Takımların aynı hataları tekrar tekrar yaptığını gördüm. En çok can yakanları sayayım:

  • Ajanlara çok erken yazma erişimi vermek — tanıdığım bir takım bir ajana kullanılmayan Docker volume'larını "temizleme" izni verdi. Durdurulmuş ama kaldırılmamış bir container tarafından mount edilmiş bir volume'u sildi. Veri kaybı.
  • Ajan özetlerini doğrulamadan güvenmek — ajanlar tıpkı gerçekleri uydurduğu gibi root cause'ları da uydurabilir. Kritik iddiaları her zaman çapraz kontrol edin.
  • Rollback planının olmaması — bir ajan bir değişiklik yaptığında ve işler bozulduğunda, tam olarak neye dokunduğunu bilmeniz gerekir. Audit logları pazarlık konusu değil.
  • Maliyeti görmezden gelmek — incident başına LLM API'lerini yüzlerce kez çağıran ajan döngüleri ciddi faturalar çıkarabilir. Token bütçeleri belirleyin.

İpucu: her ajan eylemini değiştirilemez bir audit store'a loglayın. Ajanın ne yaptığını adım adım tekrar oynatabilmeniz gerekir, özellikle bir şeyler ters gittiğinde.

Pratik Bir Ajan Stack'i Kurmak

Sıfırdan başlıyorsanız, temel bir ops ajan stack'i için tavsiyelerim şunlar:

  • LLM backend: GPT-4o, Claude veya veri ikametgahı önemliyse Ollama üzerinden yerel bir model
  • Framework: Çoklu ajan orkestrasyonu için LangChain veya CrewAI
  • Araç katmanı: SSH, kubectl, ticketing API'niz ve monitoring sorguları için özel fonksiyonlar
  • Execution sandbox: Network policyli containerlar, host erişimi yok
  • Human-in-the-loop: Her yazma işlemi için Slack veya Teams onayı

Execution ortamı için minimal bir docker-compose yaklaşımı:

services:
  ops-agent:
    image: my-agent-runtime:latest
    environment:
      - LLM_API_KEY=${LLM_API_KEY}
      - ALLOWED_HOSTS=staging-db01,staging-web01
      - MAX_TOKENS_PER_RUN=50000
    volumes:
      - ./audit-logs:/var/log/agent:rw
      - ./ssh-keys:/root/.ssh:ro
    network_mode: "none"
    cap_drop:
      - ALL

Takım için Uzun Vadeli Değişiklikler

Takım yapısının kendisi de değişecek. Daha az adanmış tier-1 NOC rolü ve daha çok "agent operations engineer" — ajan davranışını tasarlayan, izleyen ve ayarlayan kişiler — göreceğimi tahmin ediyorum. Manuel sunucu yönetiminden infrastructure-as-code'a geçiş gibi düşünün, ama daha hızlı.

Daha küçük takımlar için bu aslında iyi haber. İyi tasarlanmış ajanlara sahip üç kişilik bir ops takımı, eskiden altı kişi gerektiren bir iş yükünü kaldırabilir. Ama o üç kişinin daha yetenekli olması gerekiyor — artık hem sistemleri hem de sistemleri yöneten ajanları yönetiyorlar.

Burada kazanan şirketler insanları ajanlarla değiştirenler olmayacak. Ajanları toil'i ortadan kaldırmak ve insanlarını mimari, güvenlik ve gerçekten insan kararı gerektiren problemlere odaklamak için kullananlar olacak.

Ops pipeline'ınızda henüz ajanlarla denemeler yapmıyorsanız, şu an tam zamanı. Küçük başlayın, her şeyi ölçün ve işe yarayanları ölçeklendirin.

Kapak görseli: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/51894347967