IT Operasyonları İçin Yapay Zeka Ajanı: Dahili Talepler, Erişimler, İzleme ve Dokümantasyon

Sorun

Dahili IT operasyonları asla durmuyor, ama onları işleyen ekip duruyor. Yaklaşık 1.000 şirket üzerinde yürütülen ve destek sektöründe sıkça atıfta bulunulan bir Jitbit analizi, 2017'de bir teknisyenin yönettiği ortalama hacmi günde 21 bilet olarak konumlandırıyordu; ortalama 82 saatlik bir çözüm süresiyle birlikte. Bunlar, kendi yazarları tarafından güncel bir hedef yerine tarihi bir taban olarak sunulan, güncel bir rakam değil, bir büyüklük mertebesi olarak ele alınması gereken tarihli veriler.

Bilet başına harcanan süre konusunda, yönetilen destek sağlayıcısı Endsight, 12 ay boyunca izlediği kendi 10.923 kullanıcısı üzerinde ortalama 63 dakika öne sürüyor. Bu, tek bir şirkete özgü, üçüncü bir taraf tarafından doğrulanmamış bir veri: sektör normu değil, bir gösterge olarak dikkate alınmalı.

En sağlam belgelenen nokta erişimlerle ilgili. The Hacker News'in aktardığı Wing Security araştırması 2024'te, şirketlerin yüzde 63'ünün organizasyonun verilerine erişimi koruyan eski çalışanları olduğunu ve yüzde 43'ünün GitHub ya da GitLab üzerindeki kod depolarına erişimi olduğunu tahmin ediyor. Dahili talep kuyruğunda bekleyen her erişim ya da iptal talebi, tam olarak bu tür bir istatistiğin doğrudan bir adayı.

Bu işlem süresinin, güvenlik riskinden daha az görünür ikinci bir sonucu var: talep kuyruğunun kendisi okunmaz hale geliyor. Acil talepler (çalışmayı engelleyen bloke bir erişim) rutin taleplerle (bilgi tabanında on kez zaten yanıtlanmış bir soru) karıştığında, IT ekibi çözmeye ayırdığı kadar zamanı sınıflandırmaya da ayırıyor. Bu kuyruğun önemli bir kısmı hiçbir zaman bir insana ulaşmamalı: mevcut dokümantasyonu okuyan bir ajanın, bilet sırasını beklemeden önce absorbe edebileceği tam olarak bu tür bir sınıflandırma.

Ajanın Adım Adım Yaptıkları

IT operasyonlarına adanmış bir otonom yapay zeka ajanı, kendi izole ortamında sürekli çalışır ve hiç uyumadan talep kuyruğunu izler.

Önce Jira'daki gelen her bileti sınıflandırmaya başlar: zaten bilinen soru, erişim isteği, teknik olay. Zaten belgelenmiş talepler için, ekibin Notion tabanında bulduğu prosedürü belirterek doğrudan yanıt verir. Bir araca ya da bir depoya erişim isteği için, kendisi yürütmek yerine karara gereken tüm bilgilerle birlikte yapılandırılmış bir bilet açar.

İzleme tarafında, ajan Datadog'un ilettiği uyarıları izler ve bunları GitHub'da görünen son commit'ler ya da dağıtımlarla ilişkilendirir: bir dağıtımı yakından takip eden bir gecikme artışı, izole bir olay olarak işlenmez. İlişki net olduğunda, teknik ekip için faydalı bağlamla belgelenmiş bir GitHub issue'su açar. Bloke kalmış her bilet, kritik her uyarı ya da bekleyen her erişim isteği, IT ekibine bir Slack bildirimi tetikler. Her eylem, oluşturulan bilet, ilişkilendirilen uyarı, gönderilen mesaj, kesin durumuyla ajanın zaman çizelgesine kaydedilir.

Somut bir örnek mekaniği iyi gösteriyor: bir çalışan bir cuma akşamı, çapraz bir proje kapsamında kesin bir GitHub deposuna erişim istemek için bir bilet açıyor. Ajan talebi sınıflandırıyor, eksiksiz olduğunu doğruluyor (hedeflenen depo, gerekçe, istenen süre), ardından pazartesi sabahı bir IT sorumlusu tarafından onaylanmaya hazır, yapılandırılmış bir bilet hazırlıyor; talebin biri fark edene kadar genel bir kuyrukta uyumasına izin vermek yerine.

Kullanılan Entegrasyonlar

Jira, dahili taleplerin referans kuyruğu olmaya devam ediyor. Ajan burada talepleri arıyor (search_issues), ayrıntıya bakıyor (get_issue) ve grant'inin kapsadığı eylemlere göre yapılandırılmış yeni bir issue oluşturabiliyor.

GitHub, teknik bir uyarıyı bir kod değişikliğiyle ilişkilendirmeye yarıyor: son commit'lerin listesi (list_commits), bir pull request'in ayrıntısı (get_pull_request) ve ilişki kurulduğunda belgelenmiş bir issue oluşturma (create_issue).

Datadog, ham izleme sinyalini sağlıyor; ajan bunu izleme aracının kendisinin yerini asla almadan danışıyor. Notion, ajanın bir talebe yanıt vermeden önce danıştığı prosedürleri ve runbook'ları barındırıyor, Slack ise IT ekibine gerçek zamanlı bildirimleri taşıyor.

İnsanda Kalan Kısım

Ajan hazırlar ve uyarır, kendi girişimiyle bir erişim ya da altyapı değişikliğini asla yürütmez. Bir erişimi fiilen vermek ya da iptal etmek insani bir eylem olarak kalıyor: ajan Jira'da belgelenmiş talebi açıyor, IT'den bir kişi onu yürütüp kapatıyor.

Hiçbir belirlenebilir son dağıtımla eşleşmeyen belirsiz bir uyarının gerçek kritikliği, herhangi bir Slack bildiriminin ötesindeki bir yükseltmeden önce bir insan tarafından karara bağlanıyor. Bir kod ya da altyapı düzeltmesine karar vermek ve bunu uygulamak, hiç şaşırtıcı olmayan biçimde, bir mühendisin işi olarak kalıyor. Ve her Atako ajanında olduğu gibi, bir yönetici Jira, GitHub ve Datadog üzerindeki grant'leri, eylem eylem, açıkça tanımlanmış salt okunur ya da okuma ve yazma kapsamıyla vermeli ve ayarlamalıdır.

Bu sınır ajanın kendisi için de geçerli: iş bağlamının kapsadığından çıkan bir durumla karşılaştığında, alışılmadık bir lisans yenilemesi, belgelenmemiş bir sisteme erişim talebi, yaklaşık bir yanıtı zorlamaz. IT ekibini bilgilendirir ve bileti, bilgi tabanında var olmayan bir prosedürü tahmin etmek yerine insani bir işlem için açık bırakır.

Ölçülebilir Sonuç

En doğrudan fayda, bir bilet ya da uyarının gelişi ile ilk işleme alınması arasındaki ölü zamanın azalmasıdır. Günün 24 saati çalışan bir ajan, bir pazar akşamı açılan bir bileti sınıflandırabilir ve karşılık gelen erişim talebini, talebin kuyrukta beklemesine izin vermek yerine, ekibin pazartesi gelişinden önce hazırlayabilir.

İkinci fayda, doğrudan Wing Security'nin belgelediği soruna dokunuyor: bir ayrılış bildirildiği anda bir iptal biletinin açılmasını sistematikleştirerek, ajan tetikleyici olay ile IT eylemi arasındaki gecikmeyi azaltıyor; bu da yukarıda anılan tespitlere göre, sürekli izleme olmadan haftalar hatta aylar boyunca uzayabilen, bir erişimin gereksiz yere aktif kaldığı zaman penceresini sınırlıyor.

Açılan her bilet, ilişkilendirilen her uyarı, gönderilen her mesaj, IT ekibi için 50.000 satıra kadar CSV olarak dışa aktarılabilen Atako'nun audit trail'inde danışılabilir kalıyor. Bu eksiksiz izlenebilirlik, dahili güvenlik denetimlerini de kolaylaştırıyor: kimin ne zaman bir erişim istediğini ve talebin hangi temelde biçimlendirildiğini bulmak, artık birden fazla farklı araçtan bir kronoloji yeniden kurmayı gerektirmiyor.

Bir IT ajanı Standard plana giriyor: slot başına ayda 20 avro, model çağrılarını karşılayacak her ay dahil 1000 kredi ile birlikte. İşlenen bilet sayısının ya da ajanla etkileşime giren çalışan sayısının bu fiyata hiçbir etkisi yok, yalnızca aynı anda aktif ajan sayısı sayılıyor. Küçük bir IT ekibi böylece dahili biletlerinin, izleme uyarılarının ve erişim isteklerinin tamamı üzerinde tek bir ajan çalıştırabiliyor; her akışı ayrı ayrı kapsamak için slotları çoğaltmadan, bu da ajanın kapsamı zamanla yeni araçlara ya da yeni dahili ekiplere kademeli olarak genişlese bile maliyeti öngörülebilir tutuyor.