rmm otomasyonu: scriptler vs agent tabanlı iyileştirme

Bilişim operasyonlarını yürütüyorsanız, bu zorluğu bilirsiniz: düzeltmeleri kısmen uygulayan güvenilmez scriptler, döngüye giren uyarılar veya bir sezgi tarafından işaretlendiği için 02:00'de sunucuyu yeniden başlatmaya karar veren bir agent. Bu kılavuz, RMM otomasyonunda — klasik betikler ile modern agent tabanlı iyileştirme — pratik ödünleşmeleri ayırır ve güvenilirlik, güvenlik ve maliyet hakkında doğrudan yanıtlar sunar.

İki yaklaşım: "RMM scripting" ve "agent remediation" derken neyi kastediyoruz

"RMM scripting" derken klasik modeli kastediyorum: yöneticiler PowerShell, Bash veya Python betikleri yazar ve bunlar merkezi bir RMM konsolundan isteğe bağlı veya zamanlanmış olarak çalıştırılır. Betikler push veya pull şeklinde çalışır: konsol bir betiği bir makineye iter veya bir agent bir iş çeker ve çalıştırır. Buna karşılık, "agent-driven remediation" yerleşik bir agent'ın daha zengin bir yerel çalışma zamanı ve politikalarla koşulları tespit edip otomatik olarak düzeltme yapabilmesi anlamına gelir — bazen düzeltileri öneren veya uygulayan AI ajanları ile desteklenir.

Çoğu araç zincirinde her iki model de bir arada bulunur. Klasik RMM betikleri açık, denetlenebilir komut dizileridir. Agent remediation ise durumu, kuralları ve bazen makine öğrenimi modellerini kapsüller; insanın bir defalık betik yazmasına gerek kalmadan sorunları sınıflandırıp çözüm seçebilir.

Klasik RMM scripting: gücü, sınırlamaları ve yaygın hata modları

Betikler size neler kazandırır:

• Tahmin edilebilirlik: bir betik okunabilecek, test edilebilecek ve sürüm kontrolüne alınabilecek koddur. Tipik diller PowerShell 7 (Windows), Bash veya sh (POSIX), Python 3.11 (platformlar arası yardımcılar)dır.
• Düşük sürtünme: tek bir yönetici, agent mantığını yeniden yazmadan hedefe yönelik değişikliği hızlıca itebilir.
• Şeffaflık: yürütme günlükleri hangi komutların çalıştığını ve çıkış kodlarını gösterir — uyumluluk ve sorun giderme için kullanışlıdır.

Scriptlerin pratikte başarısız olduğu noktalar:

• İdempotentlik ve durum: birçok betik temiz varsayıma dayanır. Aynı betiği yeniden çalıştırmak, hedef durum sürüklenmişse (kısmi kurulumlar, kilitli dosyalar, farklı PATH'ler) farklı sonuçlar doğurabilir.
• Ölçek ve zamanlama: ağır betikleri (paket kurucuları gibi) yüzlerce makinede aynı anda çalıştırmak eşiklenmeye, ağ içeriği sıkışmasına veya paylaşılan kaynaklarda kilitlenmelere neden olabilir.
• Hata işleme: geçici, ad hoc hata işleme genellikle betiğin yarıda durmasına ve makinenin yarım-onarılmış durumda kalmasına yol açar. Tespiti ve geri almayı otomatikleştirmezseniz manuel müdahale gerekir.
• Güvenlik duruşu: betikler genellikle yükseltilmiş kimlik bilgileri ister. Bu kimlik bilgilerini güvenli biçimde saklamak ve döndürmek operasyonel yük getirir.

Somut örnek: bir agent'ı güncelleyen ve bir servisi yeniden başlatan PowerShell betiği makinelerin %95'inde çalışabilir, ancak daha eski .NET runtime'larına veya kilitli dosyalara sahip %5'te sessizce başarısız olur. Bu hataların tespiti ek prob'lar veya zamanlanmış doğrulama işleri gerektirir.

Agent tabanlı iyileştirme: farkı ve vaat ettikleri

Agent tabanlı iyileştirme, izleyen, politika değerlendiren ve yerel düzeltmeleri çalıştıran bir yerleşik süreçtir. Modern agent'lar şu özellikleri içerir:

• Yerel durum farkındalığı: agent'lar envanterin yerel önbelleğini, son iyi durum kayıtlarını ve bağımlılık grafilerini tutabilir; bu sayede daha güvenli kararlar alırlar.
• Kural motorları ve orkestrasyon: tek bir betik yerine agent'lar politika ağaçları uygular (ör. CPU > %90 ve süreç X kontrolsüzse önce sınırla, sonra bildir).
• Önceliklendirme ve gerileme: agent'lar üstel geri çekilme, devre kesiciler ve hız sınırları uygulayarak iyileştirme döngüsünün cihazı veya ağı boğmasını engeller.
• AI destekli triyaj: bazı satıcılar agent'ları yerel veya buluttaki modellerle zenginleştirerek düzeltileri önceliklendirir veya operatörlere öneriler sunar.

Agent remediation pratikte şunları sağlar:

• Büyük ölçekte kısmi başarısızlıkların azalması; çünkü agent idempotentlik ve tekrarları yerelde değerlendirir.
• Ortak hatalar için ortalama düzeltme süresinin kısalması — ör. servis yeniden başlatma, disk temizliği, sertifika yenileme — çünkü agent merkezi bir işe beklemeden hemen hareket eder.
• Per-cihaz politikalar ve daha iyi hız sınırlama, kitlesel iyileştirme denemelerinin yan etkilerini azaltır.

Ancak agent'lar sihirli değildir. Politika tasarımında karmaşıklık ve her uç noktada daha büyük bir güvendiğiniz kod tabanı getirir. Kötü yazılmış agent kuralları istenmeyen otomatik eylemlere neden olabilir: kontrolsüz yeniden başlatmalar, kimlik bilgisi sızıntıları veya salınan politika çatışmaları.

Hata modları, denetlenebilirlik ve relay'ler ile TLS hakkında güvenlik gerçeği

Script veya agent kullanıyor olun, şu dürüst hata ve güvenlik sınırlarını anlayın:

• TLS ve relay'ler: bağlantılar cihaz başına sertifikalarla TLS kullanır. Doğrudan peer-to-peer bağlantı cihazlar arasında uçtan uca şifrelemedir, ancak trafik bir relay'e düştüğünde TLS relay'de sonlanır. Relay'i işleten herkes oturum trafiğini ve meta veriyi inceleme pozisyonunda olur.
• Kimlik bilgisi açığa çıkması: betikler genellikle kasalanmış kimlik bilgilerine ihtiyaç duyar. Agent'lar genellikle otonom hareket etmek için daha uzun ömürlü token'lar tutar. Her iki durumda da sıkı kasa (vault) yönetimi, döndürme ve minimum ayrıcalık gerekiyor.
• Denetim izleri: betikler açık komut günlükleri sağlar; agent'lar daha yüksek seviyede olaylar üretebilir (Politika X tetiklendi, İyileştirme Y uygulandı). Agent günlüklerinizin komut seviyesi ayrıntı, zaman damgaları ve otomatik ya da manuel eylemler için operatör kimliğini içermesini sağlayın.
• Onay kapıları: yüksek riskli iyileştirmeler (yeniden başlatmalar, firewall kuralları, ayrıcalık değişiklikleri) için açık onay kapıları uygulayın. Refleks onaylı agent otomasyonu kazara kesintilere giden en hızlı yoldur.

Operasyonel olarak bu, relay'i veya bulut hizmetini işletenlere güvenmeyi gerektirir. Tenvo'nun konumlanışı açıktır: yönetilen relay'imiz, yama uygulama, anahtar yönetimi ve sertifika yenileme iş yükünü azaltması ve çok bölge failover'ı desteklemesi nedeniyle varsayılan öneridir. Kuruluşunuzun üçüncü taraf relay'leri yasaklayan yazılı bir gereksinimi varsa — veri yerleşimi, izole ağlar veya belirli düzenlemelere tabi uyumluluk gibi — kendi sunucunuzda barındırma (self-hosting) doğru tercih olacaktır. Aksi takdirde, personel zamanı ve güvenilirliği hesaba kattığınızda yönetilen relay genellikle daha az maliyetlidir.

Operasyonel maliyetler, ölçekleme ve dikkate alınacak gerçek sayılar

RMM otomasyonu sadece yazılım maliyeti değildir — insan, süreç ve risktir. Modellemek için pratik girdiler şunlardır:

• Mühendis zamanı: tek bir başarısız betik veya gürültülü uyarı 1–3 saatlik triage maliyeti çıkarabilir. Sıklıkla çarpın ve haftalık personel yükünü tahmin edin.
• Yama orkestrasyonu: aşamalı dağıtımları ve otomatik geri almayı yöneten agent'lar manuel sahnelemeyi azaltır. 1.000 endpoint için olgun bir agent insan müdahalesini onlarca saatten birkaç on-call kontrolüne indirebilir.
• Altyapı maliyetleri: relay'ler, iş kuyruğu ve kasa hizmetlerini self-host etmek 7/24 yama ve sertifika yönetimi gerektirir. Küçük çok bölge relay altyapısı genelde birkaç VM + load balancer ve bunları çalıştıracak personel zamanıyla başlar.
• Ürün fiyatlandırması (Tenvo örneği): Tenvo yönetilen relay ve macOS/Windows/Linux için yerel istemciler, genel beta'da tarayıcı istemcisi ve basit fiyat katmanları sunar — Free $0 / Lite $2.99/mo / Pro $7.99/mo — böylece SaaS yönetimli seçeneğin maliyetini iç barındırma TCO'su ile karşılaştırabilirsiniz.

Başka bir deyişle: yönetilen relay aylık cihaz başına bir ücret ekleyebilir, fakat bu on-call zamanı, sunucu bileşenlerinin güvenlik yamaları, sertifika yenileme ve tek bölge kesintisi riskini ortadan kaldırır. 3 yıllık TCO'yu modelleyin: olay müdahalesi için insan emeğini ve kitlesel iyileştirme başarısızlığı olasılığını hesaba katın.

Daha güvenli ve daha güvenilir kılmak için tasarım uygulamaları

Hangi tarafı tercih ederseniz edin, şu somut uygulamaları benimseyin:

• Varsayılan olarak idempotentlik: betikleri ve agent eylemlerini tekrar çalıştırmak durumu kötüleştirmeyecek şekilde yazın. İdempotentliği sürümlenmiş imajlara karşı test edin.
• Gözlemlenebilirlik: yapılandırılmış günlükler, çıkış kodları ve bir iyileştirme eylemini cihaza, politikaya ve operatöre bağlayan korelasyon ID'leri ekleyin. Metrikleri izleme yığınına aktarın.
• Onay kapıları ve kuru çalışma: yüksek riskli değişiklikler için insan onayı zorunlu kılın; değişiklik yapmadan ne olacağını raporlayan bir kuru çalışma (dry-run) modu ekleyin.
• Hız sınırlama ve devre kesiciler: hatalı bir düzeltmenin patlama alanını önlemek için bölge ve hesap başına eşzamanlılık limitleri uygulayın.
• Kimlik bilgisi hijyeni: sırları kasada tutun, anahtarları döndürün ve kısa ömürlü token'ları tercih edin. Bir agent'a izin verenin kim olduğunu kaydedin.
• Geri alma planları: kitlesel herhangi bir iyileştirme için sağlık prob eşiğine (ör. >%5 hata oranı tetiklemesi) bağlı otomatik bir geri alma yolu bulundurun.

Ne zaman script kullanmalı, ne zaman agent, ne zaman self-host

Hızlı, pratik karar rehberi:

• Tek seferlik, düşük riskli veya açık insan kontrolü gerektiren değişikliklerde script kullanın (göçler, özel yapılandırma değişiklikleri, soruşturma triage).
• Tekrarlanabilir, hızlı ve düşük sürtünme gerektiren rutin düzeltmeler için agent tabanlı iyileştirme kullanın (disk temizliği, servis yeniden başlatma, sertifika otomatik yenileme), özellikle ölçek büyüdüğünde.
• Riskli eylemler için insan gözetimini korumak istiyorsanız, daha hızlı ortalama düzeltme süresi için agent + sıkı onay kapıları ve gözlemlenebilirlik kombinasyonunu seçin.
• Relay'i yalnızca yazılı uyumluluk gereksiniminiz (veri yerleşimi, izole ağ) veya güvenlik politikanız üçüncü taraf altyapıyı yasaklıyorsa kendi sunucunuzda barındırın. Aksi halde, yama, yüksek erişilebilirlik, anahtar yönetimi ve on-call iş gücünü hesaba kattığınızda yönetilen relay genellikle daha ekonomik olur.

Daha derin bir self-hosting incelemesi isterseniz, bakınız Self-Hosted Remote Desktop: Why, How, and What Breaks. MSP yığını seçimleri ve otomasyonun destek iş akışına nasıl uyduğunu öğrenmek için MSP remote support tools: choosing the right stack for 2026 makalemiz yardımcı olacaktır. Çalıştırma kitapları ve güvenlik en iyi uygulamaları için Remote IT Support Best Practices'a bakın.

Agent + AI: faydalı iyileştirmeler ve gerçek riskler

AI, uyarıları önceliklendirmeye ve düzeltme adımlarını önermeye yardımcı olabilir, ancak güçlü korunmalarınız yoksa bunu bir yardımcı olarak görün; otonom operatör gibi davranmasına izin vermeyin. İşe yarayan pratik desenler:

• Öner-ve-onayla: AI bir düzeltme önerir, insan onayladıktan sonra yürütülür.
• Gözlemlenebilirlik-öncelikli modeller: AI hipotezleri işaretler ve komut çıkarmak yerine loglara/metriklere işaret eder.
• Gizlilik hassasiyeti için yerelde çalıştırın veya modelleri sıkı günlükleme ve onay kapılarıyla kendi bulutunuzda çalıştırın.

Dikkat edilmesi gereken gerçek riskler: model kayması (AI önerilerinin zamanla kötüleşmesi), insan gözetimi olmadan refleks otomasyon ve agent'lar tarafından kimlik bilgisi yükseltmesi. Agent tabanlı uzaktan kontrol için politika düzeyinde rehberlik arıyorsanız, AI troubleshooting workflow yazılarımız güvenli onay kapıları ve kaydetmeniz gereken denetim verilerini açıklar.

Kontrol listesi: rmm otomasyonu için operasyonel çalışma kitabı

• Envanter: yazılım sürümlerini bilin (PowerShell 7.x vs Windows PowerShell 5.1, Python 3.11 vs 3.8), OS yamalarını ve ağ topolojisini kaydedin.
• Test: betikleri bir staging filosuna veya sanal imajlara karşı çalıştırın ve idempotentliği doğrulayın.
• Günlükleme: her iyileştirme olayının bir operatörü, zaman damgası ve sonucu olsun; günlükleri 90+ gün merkezileştirin.
• Onay: yeniden başlatmalar, ayrıcalık değişiklikleri ve ağ/firewall düzenlemeleri için onay gerektirin.
• Hız limitleri: eşzamanlı iyileştirmeleri güvenli bir sayıda sınırlandırın (ör. bant genişliğine göre bölge başına paralel kurulumlar için 5–20 arası).
• Geri alma: sağlık metriğine bağlı otomatik geri alma tetikleyici (servis çalışma süresi, hata oranı) bulundurun.

Bu maddeler, otomasyonun bir kesintiyi büyütmek yerine düzeltme ihtimalini artırır.

Son tavsiyeler

Eğer ekibiniz küçük ve değişiklikler seyrekse, betik temelli çalışma kitaplarıyla başlayın ve teste, günlüklemeye ve kasaya yatırım yapın. Yüzlerce veya binlerce endpoint'e ölçeklendikçe politika tabanlı bir agent ekleyerek düzeltme süresini kısaltın, geri çekilme ve yerel durumu koruyun. AI'yı triage ve düzeltme önerileri için kullanın; yüksek riskli değişiklikleri insan onayı olmadan yürütmesine izin vermeyin.

Operasyonel olarak: varsayılan olarak yönetilen bir relay tercih edin, yazılı uyumluluk veya ağ izolasyonu zorunluluğu olmadıkça kendi sunucunuzda barındırma gerektirmeyin. Yönetilen relay çok sayıda gizli operasyon maliyetini ortadan kaldırır: çok bölge failover, sertifika yaşam döngüsü ve relay sunucusunun günlük yamaları. Tenvo macOS, Windows ve Linux için yerel istemciler, genel beta'da bir tarayıcı istemcisi ve çok bölge yönetilen relay sunar. Değerlendirilecek fiyat katmanları Free $0, Lite $2.99/mo ve Pro $7.99/mo'dur.

RMM otomasyonu, teknolojiden çok operasyonel bir disiplin işidir. Risk sınırlarınızı tanımlayın, her şeyi enstrümante edin ve büyük değişiklikler yerine kademeli, gözlemlenebilir değişiklikleri tercih edin.

Script temelli çalışma kitaplarını ve agent tabanlı iyileştirmeyi yönetilen relay seçeneğiyle birlikte destekleyen bir RMM iş akışını denemeye hazır mısınız? Tenvo'yu indirin ve başlayın: Download Tenvo.