Eski LinkedIn SRE'si, yapay zekâ ile olay yönetiminin mühendislerin sistem bilgisünü aşındırdığı konusunda uyarıyor

Eski bir LinkedIn site güvenilirliği mühendisi (SRE), Hacker News'te ilgi çeken bir yazı yayımladı: yapay zekâ araçları rutin olay müdahalesini devraldıkça, mühendisler otomasyonun çözemeyeceği arızalara hazırlayan uygulamalı deneyimi kaybediyor. Yazıda, 2012'de LinkedIn'te kendi kendini onaran bir prototip geliştiren ve şu anda olay yönetimi platformu Rootly'de çalışan Sylvain Kalache, bu eğilimi sektörün bütçesine dahil etmediği sessiz bir beceri aşınması sorunu olarak çerçeveliyor.

Yeni araçlar gerçekte ne yapıyor

Kalache, modern yapay zekâ olay müdahale araçlarını — kendisinin hoşlanmadığı bir terim olsa da piyasada yaygın biçimde "AI SRE" olarak pazarlanıyorlar — uçtan uca olarak tanımlıyor: uyarıları okuyor, olası nedenler hakkında hipotez yürütüyor, telemetri verisini sorguluyor, olayları son dağıtımlarla ilişkilendiriyor ve bazı durumlarda düzeltmeyi kendileri uyguluyorlar. Bunların çekiciliği hakkında açık sözlü: gece boyunca kimseyi uyandırmadan ele alınan rutin bir kapasite sorunuyla ilgili şikâyet etmek zor. Asıl endişesi, o rutin olayların eskiden ne sağladığı: müdahale edenlerin sistemlerinin nasıl davrandığına ve nasıl arıza verdiğini dair sezgi geliştirdikleri nispeten güvenli bir ortam. Araçlar rutin durumlarda ne kadar iyi olursa, bu pratiğin o kadar azı kalıyor.

1983'te tespit edilen bir ironi

Bu dinamik yeni değil. Kalache, insan faktörleri araştırmacısı Lisanne Bainbridge'in 1983 tarihli "The Ironies of Automation" (Otomasyonun İronileri) adlı makalesine işaret ediyor; Bainbridge, otomasyonun operatörleri rutin işleri pratik etme fırsatından yoksun bıraktığını ama onları yine de anormal durumlardan sorumlu tuttuğunu, dolayısıyla operatörlerin eskisinden daha az değil, daha yetenekli ve daha iyi eğitimli olmaları gerektiğini savunuyordu. Kalache'nin öngörüsü doğrudan buradan çıkıyor: yapay zekâ destekli müdahale yayıldıkça çoğu olay için ortalama MTTR düşecek, ancak karmaşık, daha önce hiç görülmemiş olayların çözüm süreleri artacak, çünkü devri devralan insanlar, artık yakından tanımadıkları sistemleri inceliyor olacak.

Havacılık paralelli

Buna nasıl yanıt verileceği için ticari havacılığa bakıyor. Otomasyon uçuşun büyük bölümünü yönetiyor, ama pilotlar otomasyonun baş edemediği olaylardan sorumlu olmaya devam ediyor: motor arızaları, güvenilir olmayan enstrümanlar, iptal edilen kalkışlar, stall. Bu tür olaylar son derece nadir — modern türbin motorları 100.000 motor uçuş saatinde ortalama birden az uçuş içi duruş yaşıyor — dolayısıyla bir pilot tüm kariyerini simülatör dışında bunlardan biriyle karşılaşmadan tamamlayabilir. Ama gerçekleştiğinde öğrenmeye zaman yoktur. Kalache, TransAsia Airways'in 235 sefer sayılı uçuşunu örnek veriyor: kalkıştan kısa süre sonra sağ motorun pervanesi otomatik olarak feather konumuna geçti; uçak sol motorla uçmaya devam edecek şekilde tasarlanmıştı, ancak mürettebat sorunu yanlış teşhis etti ve uçak ilk uyarıdan 117 saniye sonra stall yaparak düştü. Havacılığın yanıtı zorunlu provadır: ABD FAA kuralları uyarınca kaptan pilotlar altı ayda bir, kalkış sırasında motor arızası gibi senaryoları da içeren tekrar eğitim veya yeterlilik kontrolü tamamlar.

Pratik, açıklamadan üstündür

Yazılım olayları nadiren hayatları tehdit ediyor, diye belirtiyor Kalache, ama bu zanaatı atlamak için bir gerekçe değil. Önerdiği çözüm simülasyon. Rootly, Uptime Labs ile gerçekçi olay tatbikatları üzerine ortaklık kurdu: bir mühendir simüle edilmiş bir e-ticaret kesintisi sırasında olay komutanı koltuğuna oturuyor, gözlemlenebilirlik (observability) araçlarıyla çalışırken Slack'te LLM destekli ajanlar tarafından canlandırılan paydaşlarla — CEO, müşteri desteği — koordinasyon yürütüyor. Ayrıca yapay zekâyı bir eğitmen olarak kullanmayı da değerlendiriyor; bir ajandan attığı adımları ve teşhisinin ardındaki kanıtları açıklamasını istemek gibi, ama açıklamanın pratik olmadığını savunuyor: Serena Williams'ı izlemek sana tenis öğretmez. Bu kanaati, öğrenmeyi yaparak öğretmeye dayalı bir yazılım mühendisliği okulunu beş yıldan uzun süre yönetmesinden geliyor — Dropbox, okuldan işe aldığı kişilerin hâlâ sorun gidermede zayıf olduğunu bildirdiğinde, öğrencilere teşhis edip onarmaları için bozuk altyapı veren projelerle yanıt verdi.

Kavrama borcu

Yazı riske bir ad veriyor: "comprehension debt" (kavrama borcu), bir ekibin sistemlerinin gerçekte nasıl çalıştığı ile müdahale edenlerin onları ne kadar iyi anladığı arasındaki büyüyen uçurum. Önerileri somut — gözetimini yaptığın sistemlerle düzenli olarak etkileşime gir, bilinmeyen arızaları bilinçli olarak ele al, baskı altında çalışma pratiği yap ve masa başı tatbikatlar ile kaos mühendisliği yoluyla bir SEV0'ın gerektirdiği koordinasyon ve iletişimi prova et. Bu tekniklerin LLM'lerden önce geldiğini kabul ediyor, ama şimdi daha çok önem taşıyorlar. Bainbridge on yıllar önce aynı sonuca varmıştı: operatörlerin becerileri aşınmasın diye tam da bu yüzden düzenli uygulamalı kontrol ve simülasyona ihtiyaçları var.

Neden önemli

Yapay zekâ ile olay müdahalesi hızla benimseniyor, çünkü getirisi anında ve ölçmesi kolay: daha az sayfa (page), daha kısa MTTR, daha az yorucu iş. Kalache'nin tarif ettiği maliyet bunun ayna görüntüsü — yaygın, gecikmeli ve tam önemli olduğu ana, yani otomasyon bir duvara çarptığında ve az pratik yapmış bir insanın klavyeyi devralması gerektiğinde görünmez hâle gelen. Bu araçları devreye alan ekipler, simülatör süresini ve uygulamalı tatbikatları otomasyonun toplam maliyetinin bir parçası olarak görmeli; tıpkı havayollarının tekrar eğitimi uçuşun bir parçası olarak görmesi gibi. Aksi hâlde panolar ortalamaların iyileştiğini gösterirken, kuyruk riski — nadir, ağır, benzeri görülmemiş arıza — arkalarında sessizce büyüyecek.