AI SRE ve AI DevOps Uygulamada: PandaSi ile Agent'ın Birden Çok Sunucuyu Merkezi Olarak Yönetmesi

AI SRE ve AI DevOps, tek bir sunucu envanteri ve salt okunur incelemeyle hayata geçirilebilir. Bu makalede PandaSi, yönetim makinesindeki Agent'a bağlanır; mevcut SSH üzerinden birden çok sunucu tek tek doğrulanır, inceleme sonuçları özetlenir ve ardından değişiklikler tek sunucuda deneme, toplu onay ve geri alma süreçleriyle uygulanır.

PandaSiİlk yayınlanma tarihi Güncelleme tarihi
AI SRE ve AI DevOps Uygulamada: PandaSi ile Agent'ın Birden Çok Sunucuyu Merkezi Olarak Yönetmesi

PandaSi ile Agent'ın birden çok sunucuyu merkezi olarak yönetmesi, izin verilmiş tek bir yönetim makinesinden başlatılabilir: yönetim makinesinde PandaPaw ve Agent'ı çalıştırın; Agent, mevcut SSH, VPN veya bastion sunucusu üzerinden açıkça listelenen hedeflere erişsin, her birinin kimliğini tek tek doğrulasın, toplu salt okunur denetim yapsın ve sonuçları özetlesin; değişiklik gerektiğinde önce tek sunucuda deneyin, ardından onaylara göre partiler halinde ilerleyin. AI SRE güvenilirlik sorunlarını araştırmaya, AI DevOps ise teslimat ve altyapı değişikliklerine odaklanır; her ikisi de gözden geçirilebilir kanıtlara ve izin sınırlarına ihtiyaç duyar.

PandaSi cihazlar arası oturum ve onay giriş noktası sağlar, PandaPaw yürütme makinesine bağlanır, somut komutlar seçilen Agent ve araçları tarafından yürütülür. Erişimin tamamlanması şirket sunucuları için izin alındığı anlamına gelmez; 7/24 izleme, otomatik uyarı alma veya gözetimsiz onarım sistemlerinin kurulduğu anlamına da gelmez. Aşağıdaki bölüm, hâlihazırda sunucu işletim iznine sahip olan ve telefondan ya da başka bir bilgisayardan çalışmayı takip etmek isteyen geliştiriciler ve operasyon ekipleri için yönetim makinesi bağlantısı, çoklu sunucu salt okunur doğrulama, sonuç özetleme ve aşamalı değişiklik sürecini ele alır. Sunuculara ayrı ayrı doğrudan kurulum da yapılabilir, ancak bu makaledeki çoklu sunucu ana hattı yönetim makinesi yaklaşımını kullanır.

AI SRE ve AI DevOps: Agent hangi işlerde yardımcı olur?

Bu iki terim, örtüşen çalışma kapsamlarını tanımlar. Bu makalede bunları ayrı ayrı satın alınması gereken iki ürün olarak değil, aşağıdaki iş bölümüyle anlamak için kullanıyoruz.

Boyut AI SRE AI DevOps
Temel soru Hizmet güvenilir mi, arıza neden oluştu, nasıl kurtarılır ve tekrarı nasıl azaltılır Yazılım daha güvenli biçimde nasıl teslim edilir ve altyapı nasıl yönetilir
Tipik görevler Günlükleri düzenlemek, anormallikleri ilişkilendirmek, bağımlılıkları kontrol etmek, kurtarma önerileri sunmak, olay sonrası incelemeye yardımcı olmak CI/CD hattını okumak, dağıtım yapılandırmasını kontrol etmek, değişiklik hazırlamak, sürüm hatalarını analiz etmek
Agent girdisi Yetkilendirilmiş günlükler, metrikler, topoloji, arıza zaman çizelgesi ve işletim kılavuzları Depo, CI/CD hattı kayıtları, altyapı yapılandırması ve sürüm kuralları
Teslim edilmesi gereken sonuç Kanıtlar, olası nedenler, riskler, kurtarma ve doğrulama planı Gözden geçirilebilir farklar, yürütme planı, geri alma koşulları ve teslimat kanıtları
İnsanda kalması gereken kararlar İş etkisi, değişiklik onayı, kurtarma kabulü Sürüm onayı, erişim kontrolü, ortam ve kaynak sınırları

Örneğin, test hizmeti sürümlendikten hemen sonra 502 döndürürse: isteğin hangi katmanda başarısız olduğunu araştırmak AI SRE'ye daha yakındır; soruna yol açan sürüm yapılandırmasını gözden geçirip bir sonraki teslimatı hazırlamak AI DevOps'a daha yakındır. Aynı Agent oturumu iki tür işi de tamamlayabilir; kritik olan görev kapsamı, araç izinleri ve kabul koşullarıdır.

Adım 1: Yürütme konumunu seçin ve şirket yetkisini alın

Kurulumdan önce üç sorunun yanıtını netleştirin: hangi makineye bağlanmaya izin var, hangi sistem kullanıcısıyla çalışılacak, hangi dizinlere ve hizmetlere erişime izin var. Şirketin günlüklerin veya kodun harici bir modele gönderilmesine izin verip vermediği de bağlantıdan önce doğrulanmalıdır. Kişisel olarak SSH ile oturum açabilmek, şirketin kişisel hesabın uzak bir Agent'a bağlanmasına izin verdiği anlamına gelmez.

Yol A: Sunucuda doğrudan çalıştırma. Önce şirketin yalnızca kullanıcı düzeyindeki Agent hizmetine değil, varsayılan kurulum akışının içerdiği cihaz ağı yapılandırması ve ağ hizmeti değişikliklerine de izin verdiğini doğrulayın; mevcut kurulum betiği, uygun systemd ana makinelerinde sudo çağrısıyla sistem düzeyinde ağ hizmeti kaydı yapabilir. İlgili kurulum, yetki yükseltme ve ağ değişikliği izinlerini aldıktan ve ana makine mevcut destek koşullarını karşıladıktan sonra PandaPaw'ı sunucuya kurun. Sonrasında seçilen çalışma dizini, shell ve araçlar bu yürütme makinesine aittir. "İşlem daha kolay" diye varsayılan olarak root kullanmayın.

Yol B: Yetkili yönetim makinesinden sunucuya geçiş. Sunucuya kuruluma izin verilmiyorsa PandaPaw'ı şirketin onayladığı yönetim makinesine kurun; Agent da orada çalışsın. Yönetim makinesi, şirketin kabul ettiği SSH, VPN veya bastion sunucusu üzerinden hedef sunuculara zaten ulaşabiliyor ve ilgili hesap izinlerine sahip olmalıdır. Agent ardından bu mevcut kanalı çağırır; PandaSi sizin adınıza erişimi onaylamaz, bastion sunucusunu atlatmaz veya şirket iç ağını otomatik olarak açmaz.

Sunucuda doğrudan yürütme ve yönetim makinesinden mevcut erişim kanalıyla sunucuya geçiş olmak üzere iki yol
Erişim yolu şeması: önce Agent ana makinesini, sonra hedef sunucuyu belirleyin; oturum aktarımı sunucu izni vermez.

İki yol arasında en kolay karıştırılan şey "mevcut makine"dir. Yönetim makinesi yaklaşımında Agent varsayılan olarak bir kez pwd çalıştırır ve yönetim makinesinin dizinini görür; yalnızca açıkça SSH üzerinden yürütülen komutlar hedef sunucuda gerçekleşir. Oturumda sunucu adının görünmesi kimlik doğrulamasının yerini tutmaz.

Adım 2: PandaPaw'ı yürütme makinesine kurun

PandaSi üzerinden çalışma alanına girin, oturum açtıktan sonra cihazlar sayfasını /devices?add=1 açın, cihaz ekle'yi seçin ve sayfanın mevcut işletim sistemi için oluşturduğu tek kullanımlık kurulum komutunu kopyalayın. Varsayılan kurulum cihazlar arası bağlantı yapılandırmasını içerir; yetki yükseltme isteyebilir ve sistem ağ hizmetlerini değiştirebilir; önce şirket yöneticinize kurulum içeriğini inceletip ilgili izinleri onaylatın, ardından komutu önceki adımda seçtiğiniz yürütme makinesinde çalıştırın. Yalnızca kullanıcı düzeyinde erişim onaylanmış ve cihaz ağı yapılandırması onaylanmamışsa bu makaledeki varsayılan kurulum komutunu doğrudan çalıştırmayın; önce yöneticiyle onaylı kurulum yaklaşımını doğrulayın. Giriş noktası veya marka metni sürüme göre değişebilir; güncel çalışma alanında gösterilen esas alınmalıdır; ilgili ana makine akışları için Hızlı Başlangıç ile de karşılaştırma yapılabilir.

Tek kullanımlık komut cihaz eşleştirme kimlik bilgilerini içerir. Sohbete, iş emrine, herkese açık betiklere veya ekran görüntülerine yapıştırmayın; aynı komutu birden çok makineye bağlanmak için yeniden kullanmayın; kullanılmış veya süresi dolmuşsa cihazlar sayfasından yeniden alın.

Tek kullanımlık kimlik bilgileri içeren komutu kullanmıyorsanız macOS / Linux için temel kurulum girişi şudur:

bash
curl -fsSL https://cos.pandanpc.com/pandapaw/install.sh | sh

Bu, kurulum betiğini indirir ve yürütür; önce şirketin yazılım kurulum ve betik inceleme süreçlerine uyulmalıdır. Bu kez yalnızca mevcut belgeler ve kaynak koduyla doğrulama yapıldı; temiz bir ana makinede kurulum ve eşleştirme testi tamamlanmadı; herkese açık kurulum betiği indirme girişinin erişilebilir olduğu doğrulandı. Ana makine platformu uyumluluğu ve kurulum ayrıntıları için PandaPaw ana makine kılavuzu bölümüne bakın.

Temel kurulumda hesap yetkilendirmesi tamamlanmadıysa yürütme makinesinde devam edin:

bash
pandapaw login

Görüntülenen cihaz yetkilendirme akışına göre eşleştirmeyi tamamlayın, ardından kontrol edin:

bash
pandapaw status

Komut bulunamazsa önce yeni bir terminal açarak shell'in PATH'i yeniden yüklemesini sağlayın. "Denemek için" tekrar tekrar kurulum yapmayın veya zorla yeniden oturum açmayın; önce ikili dosyanın bulunamaması, hesabın bağlanmaması ve arka plan hizmeti arızası durumlarını ayırın.

Adım 3: Makineyi, motoru ve çalışma dizinini seçin

Çalışma alanını /agent açın, yeni bağlanan yürütme makinesini, ardından Claude Code, Codex veya PandaCode'u ve izin verilen çalışma dizinini seçin. Önce bir test dizininde doğrulayın; başlangıçta doğrudan üretim yapılandırma dizinine girmeyin.

Cihaz eşleştirme ile model oturum açma iki ayrı şeydir. PandaPaw oturum açma, ana makine ile çalışma alanı hesabı arasında bağlantı kurulduğunu gösterir; seçilen motor yine de kullanılabilir model yetkilendirmesi, abonelik veya API yapılandırması gerektirir. Cihaz çevrimiçi görünüyor ancak model yanıt vermiyorsa önce motor oturum açma istemlerine, kotaya ve model yapılandırmasına bakın; yalnızca PandaPaw'ı yeniden kurmayın.

Aynı zamanda motorun araç izin ayarlarını kontrol edin. Sohbette "önce değiştirme" yazmak bir görev kısıtıdır; işletim sistemi izinlerinin veya motor onay mekanizmasının yerini tutmaz. Her seferinde onay gerekiyorsa ilgili izin modunu yapılandırın; her komutun otomatik olarak onay kartı göstereceğini varsaymayın.

Adım 4: Önce salt okunur istekle kimliği doğrulayın

İlk görevde "sunucuyu düzelt" yazmayın; önce şunu gönderin:

Yalnızca kimlik doğrulaması yap, dosyaları veya hizmetleri değiştirme. Geçerli ana makine adını, sistem kullanıcısını ve mutlak çalışma dizinini bildir, dizindeki üst düzey dosya adlarını listele. .env, özel anahtarlar veya diğer kimlik bilgilerini okuma. Hedef sunucuya erişim gerekiyorsa önce mevcut yürütme makinesi ile hedef arasındaki farkı açıkla ve ben kontrol edene kadar devam etme.

Linux / macOS için kullanılabilir kimlik doğrulama komutları şunlardır:

bash
hostname
id -un
pwd

Dönen değerleri beklentilerle tek tek karşılaştırın: aynı yürütme makinesi mi, izin verilen hesap mı, doğru proje dizini mi. Benzer dizin adı, cihazın çevrimiçi olması ve komut çıkış kodunun 0 olması tek başına bağlantının doğru olduğunu kanıtlamaz.

Yönetim makinesi yaklaşımında iki uç da ayrı ayrı doğrulanmalıdır. Aşağıda yalnızca şirketin zaten yapılandırdığı SSH takma adının kullanımı gösterilmektedir; company-test-server bir örnektir, yöneticinin onayladığı hedefle değiştirilmelidir:

bash
ssh company-test-server 'hostname; id -un; pwd'

İlk bağlantı istemini çözmek için ana makine anahtarı doğrulamasını kapatmayın; SSH parolasını veya özel anahtarını Agent'a yapıştırmayın. Uzak pwd hesabın ana dizini olabilir; buna dayanarak projenin seçildiğini varsaymayın; sonraki komutlar uzak projenin mutlak yolunu açıkça belirtmelidir.

Geçme ölçütü şudur: yanıt doğru ana makineye, kimliğe ve dizine karşılık gelir; neyin yürütüldüğünü görebilirsiniz; izin soruları mevcut izin modunda beklendiği gibi görünür. Ardından telefondan veya başka bir istemciden aynı oturuma yeniden girin ve geçmişin geri yüklenip yüklenmediğini kontrol edin. Bu, yalnızca çevrimiçi yeşil noktaya bakmaktan gerçek kullanım yoluna daha yakındır.

Adım 5: Önce sunucu envanteri oluşturun, ardından toplu salt okunur denetim yapın

Bir yönetim makinesindeki Agent mevcut SSH'i çağırarak envanterdeki birden çok sunucuya sırayla erişebilir; PandaSi bu araç işlemlerini ve sonuçlarını aynı oturumda takip etmenizi sağlar. Buradaki "merkezi yönetim" aynı yürütme girişinden, açık envanterden ve birleşik rapordan gelir; ürünün yerleşik sunucu varlık keşfi, bağlantılar arası otomatik iş dağıtımı veya tek tıkla toplu kontrol arayüzü sunduğu anlamına gelmez. Yönetim makinesinin her hedef için zaten yetkisi olmalıdır; bir makineye erişebiliyor olmak, aynı ağ segmentindeki diğer makinelere erişebileceği varsayımını doğurmaz.

Takma adlar ve ortam gruplarıyla hedefleri sabitleyin

Yöneticinin kimlik bilgisi içermeyen bir envanter tutmasını sağlayın. Aşağıdaki tüm adlar kurgusal örneklerdir; gerçek envanter şirketin onayladığı yerde bulunmalı, parola, özel anahtar veya tek kullanımlık cihaz komutu içermemelidir.

Ortam SSH takma adı Beklenen ana makine adı Beklenen kullanıcı Uzak proje dizini Bu turdaki yetki
test test-web-01 demo-test-web-01 opsread Proje A'nın onaylanmış mutlak yolu Kimlik doğrulama, belirtilen hizmette salt okunur kontrol
test test-worker-01 demo-test-worker-01 opsread Proje A'nın onaylanmış mutlak yolu Kimlik doğrulama, belirtilen hizmette salt okunur kontrol
production prod-web-01 demo-prod-web-01 opsread Proje A'nın onaylanmış mutlak yolu Bu turda kapsam dışı; ayrı başvuru gerekir
production prod-web-02 demo-prod-web-02 opsread Proje A'nın onaylanmış mutlak yolu Bu turda kapsam dışı; ayrı başvuru gerekir

SSH takma adı, yönetim makinesinin mevcut SSH yapılandırmasındaki addır, PandaSi cihaz adı değildir. Yönetici takma adın karşılık geldiği hedefi, hesabı, bağlantı noktasını ve gerekli erişim aktarımını doğrulamalıdır; adında test olması tek başına bunun test makinesi olduğunu doğrulamaz. OpenSSH, yapılandırmayı Host girdilerine göre eşleştirmeyi destekler; komut satırında belirtilen uzak komut hedef ana makinede yürütülür; ayrıntılar için SSH istemci yapılandırma kılavuzu ve SSH komut kılavuzu.

Bir yönetim makinesinin yetkili envantere göre mevcut SSH üzerinden test ve üretim sunucularına erişim şeması
Çoklu sunucu yönetimi şeması: her hedefi envantere göre doğrulayın, eşzamanlılığı sınırlayın, üretim erişimi ayrıca onaylanır; toplu kontrol arayüzü ekran görüntüsü değildir.

Her sunucuya ayrı ayrı PandaPaw kurulduysa çalışma alanından ilgili yürütme makinesini seçerek tek tek işlem yapabilirsiniz; ancak "birden çok makine çevrimiçi" ifadesini tek bir oturumun tüm bağlantıları otomatik olarak yönettiği şeklinde anlamayın. Bu makalenin devamında birleşik olarak yönetim makinesinin mevcut SSH üzerinden eriştiği yaklaşım kullanılır; böylece iki yürütme konumu aynı raporda karışmaz.

Önce sıralı doğrulama yapın, sonra denetim kalemlerini sınırlayın

İlk seferde envantere göre her makinede tek tek kimlik doğrulaması yapın; uygulama yapılandırmasını veya tam günlükleri okumayın. Aşağıda yönetim makinesi Bash için sıralı bir örnek verilmiştir; yalnızca bu turda izin verilen iki test makinesini listeler; otomatik ortam tanıma yapmaz ve beklenen kimliğin insan tarafından doğrulanmasının yerini almaz.

bash
for target in test-web-01 test-worker-01; do
  printf '\nTARGET %s\n' "$target"
  if ssh -T -o BatchMode=yes -o ConnectTimeout=5 "$target" \
    'hostname && id -un && pwd'; then
    printf 'IDENTITY_COMMAND_COMPLETED %s\n' "$target"
  else
    result=$?
    printf 'IDENTITY_COMMAND_FAILED %s exit=%s\n' "$target" "$result" >&2
  fi
done

Bu komutlar yalnızca düzenleme biçimini açıklamak içindir; bu makalede bu iki örnek ana makinede çalıştırılmamıştır. BatchMode=yes, kimlik doğrulama başarısız olduğunda etkileşimli giriş beklenmemesini sağlar; ConnectTimeout=5 yalnızca bağlantı kurulum aşamasını sınırlar, tüm uzak komutun toplam süresini sınırlamaz. Toplam yürütme süresi ayrıca izin verilen araç veya görev yürütücüsü tarafından ayarlanmalıdır. Toplu çalıştırma uğruna ana makine anahtarı doğrulamasını kapatmayın; etkileşimli MFA gerektiren bastion sunucuları için şirketin onayladığı erişim akışı kullanılmalı, bu etkileşimsiz örnek uygulanmamalıdır.

Komutlar tamamlandıktan sonra önce envanterdeki beklenen ana makine adını ve hesabı tek tek karşılaştırın, ardından izin verilen uzak proje yolunu doğrulayın. Yukarıdaki çıktıdaki pwd genellikle yalnızca uzak oturum açma dizinidir; proje yolunun doğru olduğunun kanıtı değildir. Komut çıkış kodunun 0 olması yalnızca bu komutların tamamlandığını gösterir; ana makine kimliğinin eşleştiğini, hatta iş yükünün sağlıklı olduğunu göstermez. Herhangi bir makinenin kimliği uyuşmazsa o hedefi engellenmiş olarak işaretleyin ve iş verilerini okumaya devam etmeyin; aynı ortamda veya erişim kanalında ortak bir şüphe varsa tüm toplu denetimi duraklatın.

Kimlik doğrulaması geçtikten sonra Agent'ın bu turdaki test makinelerinde aynı izinli salt okunur kontrolleri çalıştırmasını sağlayın: belirtilen hizmet durumu, beklenen dinleme bağlantı noktaları, kalan disk alanı, belirtilen zaman penceresindeki maskelenmiş hata özeti ve onaylanmış bir sağlık isteği. "Denetim"i prob kurulumuna, tüm dizinlerin özyinelemeli okunmasına veya otomatik onarıma genişletmeyin. Farklı sistemler, hizmet yöneticileri ve uygulamalar için kontrol komutları farklıdır; envantere göre tamamlanmalı, tek bir komut tüm ana makinelere zorla uygulanmamalıdır.

Bir istemle yürütme sınırlarını netleştirin

Yönetim makinesinde çalışıyorsun. Yalnızca onaylı sunucu envanterindeki test grubunda yer alan test-web-01 ve test-worker-01'e eriş; yeni adres tarama, production grubuna erişme. Önce her ana makinenin adını, kullanıcıyı ve uzak projenin mutlak yolunu sıralı olarak doğrula; envanterle uyuşmazsa o hedefi engelle. Geçtikten sonra yalnızca envanterde açıkça yetkilendirilmiş hizmet durumunu, bağlantı noktalarını, diski ve sağlık isteğini kontrol et; günlüklerden yalnızca belirtilen zaman penceresindeki maskelenmiş parçaları al. İlk seferde baştan sona sıralı çalış, yapılandırmayı değiştirme, yeniden başlatma, bağımlılık kurma, otomatik yetki yükseltme. Tek makine bağlantısı başarısız olursa hatayı koru ve diğer doğrulanmış hedeflerin bağımsız salt okunur kontrollerine devam et; ortam aidiyeti veya ortak erişim kanalında anormallik bulursan tüm toplu işlemi duraklat. Her makine için zaman ve saat dilimini, komutu, çıkış durumunu, temel kanıtları ve tamamlanmayan kalemleri ayrı ayrı kaydet, sonunda sunucuya göre özetle. Herhangi bir onarım için ayrıca öneri ver, uygulama.

Bu bir görev kısıtıdır; salt okunur hesapla, motor araç onayıyla ve ağ erişim kısıtlarıyla birlikte kullanılmalıdır. "Değişikliği yasakla" ifadesini isteme yazmak, yazılabilir bir hesabı otomatik olarak salt okunur hesaba dönüştürmez.

Eşzamanlılığı sınırlayın, hataları ilgili hedefte bırakın

İlk denetimde sıralı çalışmak doğrulamayı kolaylaştırır; hedef sayısı fazlaysa şirketin izin verdiği araç yürütme biçiminde küçük bir eşzamanlılık üst sınırı belirlenebilir, örneğin aynı anda en fazla iki makine kontrol edilebilir. Buradaki "iki makine" örnek bir işlem bütçesidir; PandaSi'nin ürün sınırı veya performans garantisi değildir. Seçilen Agent veya araç eşzamanlılığı güvenilir biçimde sınırlayamıyorsa sıralı çalışmaya devam edin; geçici sınırsız arka plan görevleriyle değiştirmeyin.

Her kontrol için bağımsız zaman aşımı ve sonuç kaydı tanımlayın; bir hedefin başarısız olması diğer makinelerde yeniden başlatma, yeniden kurulum veya tüm parti için sonsuz yeniden deneme başlatmamalıdır. Bağlantı zaman aşımı, kimlik uyuşmazlığı, yetersiz izin ve kontrol komutu hatasını ayrı ayrı kaydedin; hepsini "çevrimdışı" olarak birleştirmeyin. Hata ortak bastion sunucusundan, kimlik doğrulama kaynağından veya belirsiz ortam aidiyetinden kaynaklanıyorsa durup ortak nedeni doğrulayın; eşzamanlılığı artırmaya devam etmeyin.

Özet tablo her makine için kimliğin eşleşip eşleşmediğini, hangi kontrollerin gerçekten yürütüldüğünü, temel kanıtları ve bilinmeyen kalemleri listelemelidir. Aşağıda yalnızca kayıt biçimi gösterilmiştir; tablodaki metinler doldurma talimatıdır, ölçülmüş sonuç değildir:

Hedef Kimlik doğrulaması Hizmet ve sağlık kontrolleri Tamamlanmama nedeni Sonraki adım
test-web-01 Gerçek kanıt doldurulacak Yürütülmeden önce bilinmiyor olarak işaretle Duruma göre doldur Doğrulamadan sonra karar ver
test-worker-01 Gerçek kanıt doldurulacak Yürütülmeden önce bilinmiyor olarak işaretle Duruma göre doldur Doğrulamadan sonra karar ver

Rapor "kaç makine kontrol edilmesi planlandı, kaçı tamamlandı, kaçı başarısız oldu, kaçı atlandı" bilgisini vermeli ve her hedefin kanıtlarını sunmalıdır. Sonuç eksikse varsayılan olarak sağlıklı kabul edilemez; toplu komutun nihai çıkış kodunun 0 olması, yol ortasında bir makinenin zaten başarısız olduğunu gizleyemez.

Adım 6: Önce bir test hizmetinde 502 araştırmasını ve kurtarmayı tamamlayın

Aşağıdakiler öğretici bir örnektir; bu makalede ölçülmüş bir olay değildir ve tüm sunuculara kopyalanabilecek bir onarım komutları seti değildir. İzin verilen bir test hizmetinin sürümünden sonra 502 döndürdüğünü varsayalım; test alan adını, hizmet adını ve proje dizinini bildiğinizi varsayalım.

Hedef doğrulamadan salt okunur araştırmaya, değişiklik önerisine, insan onayına, yürütmeye ve kurtarma kabulüne kadar altı adımlı akış
Sorun giderme akışı şeması: somut değişikliği onaylayın, kurtarma sırasında sağlık arayüzünü ve gerçek kullanıcı isteklerini birlikte doğrulayın.

Önce araştırma kapsamını sınırlayın

Görevi şöyle yazabilirsiniz:

Test hizmetinin sürümünden sonraki 502'yi araştır. Önce hedef ana makineyi, kullanıcıyı ve dizini doğrula; son sürüm kaydını, ilgili hizmet durumunu, dinleme bağlantı noktalarını, belirtilen zaman penceresindeki proxy ve uygulama günlüklerini salt okunur olarak kontrol et. Yeniden başlatma, yapılandırma değiştirme, bağımlılık kurma veya başka ortamlara erişme. Yalnızca bu arızayla ilgili maskelenmiş parçaları döndür; kanıtları, olası nedenleri ve hâlâ eksik olan bilgileri listele.

Önce zaman penceresini ve açık günlük kaynaklarını verin; Agent'ın tüm sunucuyu özyinelemeli olarak taramasını önleyin. Salt okunur erişim de veri sızdırabilir: günlüklerdeki token'lar, müşteri bilgileri ve istek gövdeleri model bağlamına girmeden önce filtrelenmelidir; gönderildikten sonra modelin "unutmasını" beklemeyin.

502, proxy'nin kullanılabilir bir üst kaynaktan yanıt alamadığını gösterir; ancak yalnızca durum koduna bakarak süreç sonlanması, bağlantı noktası uyuşmazlığı, bağımlılık anormalliği veya bağlantı sorunu olduğu anlaşılamaz. Agent'ın proxy üst kaynak adresini, gerçek dinlemeyi ve aynı zaman aralığındaki günlükleri hizalamasını sağlayın; makineler arası günlüklerde önce saat dilimini birleştirin. "Makine çevrimiçi" ifadesini "uygulama sağlıklı" olarak değerlendirmeyin; eşleşen günlük olmamasını da doğrudan hatanın oluşmadığı şeklinde yorumlamayın.

Gözden geçirilebilir onarım önerisi isteyin

Kanıtlar "sürüm yapılandırmasındaki üst kaynak bağlantı noktasının gerçek dinlemeyle uyuşmadığı" tezini destekliyorsa Agent'tan somut dosyayı ve en küçük farkı, yürütülmesi planlanan komutları, etkilenen test hizmetini, yapılandırma kontrol yöntemini ve geri alma koşullarını sunmasını isteyin. Bu hâlâ koşullu bir örnektir; kanıtlar desteklemiyorsa araştırmaya devam edin.

Onay nesnesi "her şeyi sen yönet" değil, somut bir değişiklik olmalıdır. Örneğin belirtilen test proxy yapılandırmasının değiştirilmesini ve yapılandırma kontrolü geçtikten sonra bu test proxy'sinin yeniden yüklenmesini onaylayın; buna bağımlılık yükseltme, veritabanı temizliği, üretim yapılandırması değişikliği veya tüm ana makinenin yeniden başlatılması eklenmemelidir. Gerçek komutlar kullanılan süreç yöneticisine ve dağıtım düzenine göre belirlenmelidir.

Yürütmeden sonra kullanıcı yolunu doğrulayın

Yürütme onaylandıktan sonra kabul en az şunları kapsamalıdır: yapılandırma kontrolünün geçip geçmediği, ilgili süreçlerin ve bağlantı noktalarının beklendiği gibi olup olmadığı, sağlık arayüzünün normal olup olmadığı ve bağımsız bir istemciden özgün giriş üzerinden yapılan gerçek test isteğinin geri dönüp dönmediği. Sağlık arayüzü 200 döndürürken iş yolu, kimlik doğrulama veya veritabanı isteği hâlâ başarısızsa "sorun çözüldü" yazılamaz.

Son olarak Agent'ın yürütülen komutları, gerçek değişiklikleri, doğrulama sonuçlarını ve kalan riskleri özetlemesini sağlayın; doğrulanmayan kalemleri açıkça bilinmiyor olarak yazın. Doğrulanmış nedeni ve tekrarı önleme önlemlerini şirketin kayıt sistemine geri verin. Araştırma aşamasında AI SRE desteği verilir; düzeltmenin yapılandırma deposuna ve sürüm sürecine dahil edilmesi AI DevOps'a uzanır.

Adım 7: Tek sunucu geçtikten sonra diğer sunucuları aşamalı olarak değiştirin

Toplu denetim ve toplu değişiklik yetkileri ayrılmalıdır. Birden çok hizmet sürümünün tutarsız olduğunu görmek, hepsinin doğrudan yükseltilebileceği anlamına gelmez; aynı adlı hizmetler farklı roller üstlenebilir veya farklı yapılandırmalar kullanabilir. Önce farklılıkların beklenen olup olmadığını doğrulayın, ardından hedefe göre kalem kalem listelenen bir değişiklik planı önerin.

İlk partide yalnızca açıkça belirlenmiş bir test makinesi seçin. Planda hedef takma adı, doğrulanmış ana makine kimliği, özgün sürüm veya yapılandırma, değiştirilecek fark, beklenen etki, kontrol yöntemi, geri alma adımları ve durma koşulları sabitlenmelidir. Onaydan sonra bu tek makine yürütülür, sağlık arayüzü ve gerçek kullanıcı yolu kabulü beklenir; kurtarıldığına dair kanıt yoksa durum başarılı olarak işaretlenip sonraki partiye geçilemez.

Deneme geçtikten sonra sonraki partinin hedef listesi, parti boyutu ve eşzamanlılık üst sınırı açıkça belirlenir; envanterle değişen "kalan tüm makineler" gibi örtük bir kapsam kullanılamaz. Her parti sonunda gerçek sürüm ve istek sonuçları kontrol edilir; başarılı, başarısız ve yürütülmemiş hedefler kaydedilir. Kimlik uyuşmazlığı, yapılandırma kontrolü hatası, iş isteğinde bozulma veya geri alma hatası ortaya çıkarsa sonraki partiler durdurulur, kanıtlar korunarak sorumluya teslim edilir; test aşamasındaki onay üretim onayı olarak kullanılmaz.

Geri alma da makine bazında tanımlanmalıdır. Yapılandırma değişiklikleri onaylanan yöntemle önceki yapılandırmaya döndürülebilir; veritabanı geçişi, veri yazımı veya harici sistem yan etkileri söz konusuysa "eski sürüme dönmek" etkiyi geri alır diye varsayılmamalı, önce sorumlu kurtarma planını belirlemelidir. Yalnızca gerçekten değiştirilen ve geri alınması gereken hedefler geri alınmalı; tüm makine grubuna ayrım yapmadan ters komut çalıştırılmamalıdır.

Bir sonraki görevi şöyle yazabilirsiniz:

Bu seferki makine bazlı denetim kanıtlarına göre önce yalnızca test-web-01 için onarım planı öner, uygulama. Doğrulanmış ana makine kimliğini, somut farkı, tam komutları, etkiyi, geri alma adımlarını, kabul isteğini ve durma koşullarını listele. Ancak bu makine için açık onay alındıktan sonra yürütülebilir; tamamlandığında gerçek kanıtları sun ve sonraki parti hedefi yetkisini bekle. Onaylanmayan makineler yürütülmemiş olarak kalır. Üretim grubu bu turun kapsamı dışındadır; test onayını devralamaz.

Test ve üretim için de işlem gerektiğinde üretim, şirketin değişiklik sürecinden ayrıca geçer. Yönetim girişinin birleşik olması ortam izolasyonu, bakım penceresi, sürüm onayı veya denetim gereksinimlerini ortadan kaldırmaz.

Telefon bağlantısı kesildikten sonra önce görev durumunu doğrulayın

İstemcinin kapatılması, telefonun arka plana geçmesi veya ağın kesilmesi uzak komutun durduğu şeklinde yorumlanmamalıdır. Yürütme makinesindeki süreç çalışmaya devam ediyor olabilir; ana makinenin çevrimdışı olması, motorun çıkması veya uzak kanal sınırlaması nedeniyle de başarısız olabilir. Özgün oturuma dönünce önce araç sonuçlarına bakın, ardından süreçleri, çıktıları ve hizmet durumunu doğrulayın; kurulum, sürüm veya geçişi yinelenen şekilde başlatmaktan kaçının.

Uzak komut zincirinde "çıkış durumu dönmedi" durumu görülebilir: bağlantı katmanı zaman aşımı, komutun başlamadığını göstermez. Uzun görevlerde şirketin yürütme kanalında zaman aşımı, durum kaydı ve iptal yöntemi açıkça tanımlanmalıdır; özellikle birden çok SSH atlaması söz konusu olduğunda. Bu makale, belirli bir sürümün kanal zaman aşımı değerini tüm SSH araçları için genel kural olarak kabul etmez.

Durdurma gerektiğinde açık bir durdurma işlemi kullanın ve uzak yürütme durumunu doğrulayın; durumu belirsiz olan idempotent olmayan değişikliklerde önce insan devralıp doğrulamalıdır. Önceki işlemin başarılı olup olmadığını anlamak için tekrar tekrar tıklamaya veya aynı talimatı yeniden göndermeye güvenmeyin.

Şirket ve ev cihazlarının ağ yapılandırmasının bu makaleyle ilişkisi nedir?

Bu makale, yönetim makinesinden çeşitli sunuculara izin verilen erişim kanalının zaten var olduğunu varsayar; odak noktası Agent'ın işi hedeflere göre nasıl düzenlediğidir. Şirketteki ve evdeki birden çok cihazın ağa nasıl katılacağı, birbirine nasıl erişeceği ve ağ sınırlarının nasıl ele alınacağı ayrı bir bağlantı görevidir; burada birlikte yazılmaz; ağ yapılandırmasının başarılı olması, içindeki tüm cihazları işletme yetkisine sahip olduğunuz anlamına da gelmez. Cihaz bağlantısı hakkında bilgi için önce mevcut Cihazlar arası bağlantı açıklaması bölümüne bakın ve şirketin ağ onay sürecine uyun.

Şirket verileri, model ve aktarım sınırları

"Araçlar yerel makinede çalışır" ifadesi yürütme konumunu tanımlar; verilerin her zaman şirket dışına çıkmayacağını taahhüt etmez. Oturum mesajları ve onaylar ürün iletişim kanalından geçer; Agent'a sağlanan günlükler, kod ve araç çıktıları da seçilen model sağlayıcısının isteklerine girebilir. Bağlantıdan önce şirketin onayladığı modeli, veri işleme sözleşmelerini, günlük saklama ve erişim politikalarını doğrulayın.

Mevcut anahtar yönetimi ve denetim süreçlerini koruyun; kimlik bilgileri yürütme makinesinin izinli kimlik bilgisi altyapısından okunmalı, sohbete veya kod deposuna yapıştırılmamalıdır. Çalıştırma hesabını ve ağ erişim kapsamını sınırlayın; günlük ve dizin izinlerini ihtiyaç kadar sağlayın. İşten ayrılma, cihazın hurdaya çıkması veya izin değişikliği durumunda çalışma alanı cihaz yetkisini, yürütme makinesi hesabını ve hedef sunucu erişimini aynı anda ele alın; bir istemciyi silmek tüm yürütme izinlerini geri almaz.

FAQ

PandaSi otomatik nöbet tutabilir, uyarıları alabilir ve üretimi onarabilir mi?

Bu makale uzak oturumları, yetkili işlemleri ve insan takip sürecini ele alır. 7/24 izleme, uyarı entegrasyonu, otomatik tetikleme ve gözetimsiz onarım ek izleme sistemleri, tetikleyiciler, çalıştırma kılavuzları ve izin yönetişimi gerektirir; bağlantının başarılı olmasından bu yeteneklerin zaten mevcut olduğu sonucu çıkarılamaz.

Şirket sunucusuna yazılım kurulamıyorsa yine de kullanılabilir mi?

Hedefe yasal ağ ve kimlik izinleri zaten varsa onaylı yönetim makinesi yaklaşımı düşünülebilir. Şirket bu tür harici Agent bağlantılarını da yasaklıyorsa gizli bir bağlantı yolu bulmak yerine önce onay süreci yürütülmelidir.

Sunucuya genel ağa açık SSH bağlantı noktası açmak gerekir mi?

PandaPaw oturum bağlantısı iki tarafın etkin giden bağlantılarıyla kurulur; istemci bağlantısı için genellikle yeni bir genel ağ gelen bağlantı noktası açmak gerekmez. Ancak yönetim makinesinden hedef sunucuya şirketin kabul ettiği erişim kanalı yine gereklidir; giden bağlantılar kısıtlıysa ağ yöneticisi tarafından yapılandırılmalı, koruma kendiliğinden kapatılmamalıdır.

Her sunucuya PandaPaw kurmak zorunlu mu?

Bu makaledeki yönetim makinesi yaklaşımı her SSH hedefine PandaPaw kurulmasını gerektirmez; ancak yönetim makinesinde izinli ağ kanalı ve uzak hesap bulunmalıdır. Doğrudan kurulum yaklaşımında Agent ilgili ana makinede çalışır ve her biri ayrı bağlanır; iki yaklaşımı aynı otomatik toplu kontrol yeteneğiyle karıştırmayın.

Bir denetim başarısız olursa diğer makineler devam edebilir mi?

Kimliği doğrulanmış ve birbirinden bağımsız salt okunur kontrollerde o hedefin hata kanıtı korunarak diğer hedeflere devam edilebilir; ortak erişim arızası veya ortam aidiyeti şüphesi varsa tüm parti duraklatılmalıdır. Değişiklik aşamasında onaylanmış durma koşullarına göre hareket edilir; "denetim devam edebilir" kuralı uygulanamaz.

Bağlantıdan sonra ilk olarak ne kabul edilmeli?

Önce yönetim makinesi, model yanıtı ve oturum kurtarma doğrulanır; ardından envantere göre her makinede hedef kimliği, dizin ve izinler tek tek kontrol edilir, salt okunur denetim ve sonuç özeti tamamlanır; son olarak bir test hizmetinde onay, gerçek istek kabulü ve sonraki aşamalı süreç baştan sona yürütülür. Bağlantının değeri, yetkili görevlerin sürekli takip edilebilmesini sağlamasıdır; daha fazla hizmete genişletilip genişletilmeyeceğine bu kabul kanıtlarına göre karar verilmelidir.

Kaynaklar ve doğrulama kapsamı

Bu makalenin ilk taslağı 31 Ekim 2026 tarihinde proje hızlı başlangıcı, PandaPaw ana makine belgeleri, cihaz kurulum komutu oluşturma mantığı ve herkese açık kurulum betiği indirme girişiyle doğrulandı; 1 Kasım'da çoklu sunucu işlem akışı eklendi ve OpenSSH resmî kılavuzlarıyla SSH yapılandırması ve parametre anlamları karşılaştırıldı. Bu kez yalnızca mevcut belgeler ve kaynak koduyla doğrulama yapıldı; temiz bir ana makinede kurulum ve eşleştirme testi tamamlanmadı; gerçek çoklu sunucu ortamında bu makaledeki denetim, aşamalı değişiklik veya 502 örneği yürütülmedi; her şirketin ağı, motor onayı ve veri uyumu kendi test ortamında kabul edilmelidir. Görsellerin tümü AI tarafından üretilmiş kavram veya süreç şemalarıdır, arayüz ekran görüntüsü değildir.