Bölüm 31: Günlük Operasyon Kontrolleri¶

Bu bölüm, v1.3.1 panosuyla uyumlu bir operatör rutini tanımlar: her maddede önce hangi sayfaya bakılacağı, sonra neyin "normal" olduğu söylenir. Kurulum ve yükseltme akışları Bölüm 4'te ve yükseltme bölümünde; bu bölümdeki kontrollerin çoğu bir panelden, tek bir turla yapılır.

Sistem Sağlık Kontrolü¶

Her gün işletim başlangıcında şu kontroller yapılmalıdır:

Panel (Dashboard, /admin) — KPI kartlarını (İstek Hacmi, Tehdit Azaltma, PII Kalkanı Yakalamaları, Ort. Gecikme) günlük tabanla karşılaştırın; engellenen istek ve ret oranı eğiliminde sıçrama arayın. Sistem durumu satırında "Tüm ağ geçitleri çalışıyor" beklenir; "Yapay zekâ host'ları çözülemiyor" amber bandı DNS sorununa işaret eder (Bölüm 6, Host Ağı & Zaman). Son olaylar akışında "policy" veya "approval" içeren olaylar turuncu badge ile vurgulanır.
Aktif Uyarılar — Performans sayfasındaki "Aktif Uyarılar" kartı ("şu anda tetikleniyor" sayısı) ve Ayarlar → Uyarılar & Sağlık → Aktif Uyarılar listesi kontrol edilir. Tetiklenen her uyarının nedeni aynı gün açıklığa kavuşturulmalı; koşul düzeldiğinde kayıt kendiliğinden düşer. Uyarı eşiği değişikliği de bu ekrandan yapılır.
/readyz durumu — Tarayıcıdan https://<ARCERIS_HOST>:8443/readyz istenir; "degraded" ya da yavaş yanıt alınıyorsa nedeni Bölüm 33'teki hazır-bulunurluk rehberindedir. Derin kontrolleri panelden çalıştırmak için Ayarlar → Uyarılar & Sağlık → Kontrolleri Çalıştır kullanılır (sonuçlar her zaman tazedir, önbellek atlanır): veritabanı, önbellek, OCR taraması, DLP/ICAP, SIEM İleticisi, Sunucu TLS Sertifikası, TLS CA Sertifikası, Yukarı Akış Sağlayıcı, Lisans Hub, Sağlayıcı DNS çözümlemesi ve PII NLP motoru.
Sistem Bilgisi — Ayarlar → Sistem Bilgisi sekmesinde lisans durumunun ("Lisans Planı: Doğrullandı" yerine "Doğrulandı"), şeffaf proxy'nin ("Etkin") ve syslog entegrasyonunun doğru olduğunu doğrulayın (Bölüm 6).
Denetim Kayıtları — Son 24 saatteki CRITICAL ve ERROR seviyeli olayları filtreleyin (Bölüm 25). Günlük turda öne çıkan üç desen:
ANON satırları: İstek Olayları'nda "ANON" çipli satırlar, hiçbir kullanıcıya bağlanamayan isteklerdir. Tek tek ANON satırları normal olabilir; sürekli artan bir ANON yoğunluğu ACL kuralı değil kimlik sorunu demektir — Bölüm 25'teki Kimlik Provenansı bölümüyle nedenini bulup makine/oturum tarafında çözün.
"Oturum açma başarısız" (auth_login_fail) birikimi: Aynı kullanıcı veya IP üzerinden kısa sürede tekrarlanan kayıtlar kaba kuvvet denemesi ya da bozuk bir istemci işaretidir.
Makine komut hataları: Makineler sayfasının komut geçmişinde "başarısız", "süresi doldu" veya "no_ack" (helper yanıtlamıyor — çok eski ya da çalışmıyor ajan) durumuna düşen komutlar izlenmeli (Bölüm 13, Komut Kuyruğu).

Makine ve Ajan Filosu Kontrolü¶

Günlük turun ikinci yarısı uç noktalara bakar:

Makineler sayfası — Liste üstündeki iki uyarı rozeti kontrol edilir: "Kullanıcı kimliği yok (n)" (helper geçerli bir Arceris kullanıcı kimliği olmadığını bildiriyor; bu makinelerin trafiği kimliksiz değerlendirilir) ve "Kayıt takıldı (n)" (sessiz kayıt Kerberos bileti bekliyor ya da reddedildi). Rozet sayıları sıfıra inmeli; inmiyorsa satır detayındaki kimlik satırı nedenlerine (cihaz iptal edildi, kayıt süresi doldu, kimlik bilgisi dosyası yok…) bakıp Bölüm 13'teki akışla düzeltün.
Ajan güncelleme onayı — Geliştirici Araçları → Agent Güncelleme Dağıtımı bölümünde dağıtım durumu kontrol edilir (Bölüm 24). "Onay güncel değil" (approval_stale) rozeti, onay verildikten sonra bu platformdaki cihazların yeni bir build check-in'i yaptığını gösterir — onayı tazelemek için onayı yenileyin. "Sonuç bekleniyor" durumdaki dağıtımlar ve filo özetindeki güncel olmayan cihaz sayısı takip edilmelidir.
Disk ve hacim durumu — Ayarlar → Syslog'daki SIEM spool istatistiğinde "Diskte bekleyen" sayısı sıfır kalmalı; büyüyen bir kuyruk SIEM tarafına teslimat kopukluğuna işaret eder (Bölüm 25). Makineler'de "Disk dolu" hata sınıfı görünen uç noktalarda yer açılmalıdır; ağ geçidinin kendi host'unun disk/RAM/CPU metrikleri SNMP ile dış izleme aracına açılabilir (Bölüm 6).

Kimlik Kaybı Filo Alarmı¶

v1.3.1, kimliğini kaybeden kullanıcıları tek yerden gösteren user_identity_missing filo alarmını getirir (#1409). Alarm, Ayarlar → Uyarılar & Sağlık altındaki "Kullanıcısı Kimliğini Kaybeden Makine" eşikleriyle yönetilir: varsayılan olarak 1 ve üzeri makine uyarı, 5 ve üzeri makine kritik üretir ve mevcut uyarı hattını (panel, webhook) izler.

Sayımın kapsamı bilinmelidir: alarm, son 15 dakikada oturum durumu bildiren makineler arasından kimliği gerçekten kaybedenleri sayar — helper "yeniden kayıt gerekli" bildirmiştir ya da önceki dolu bir oturumun ardından "kullanıcı kimliği yok" rapor etmiştir. Hiç kaydolmamış kullanıcı kayıp sayılmaz; bu yüzden alarm, hiç kaydolma yaşamamış bir filoda yükseltme sonrası boşuna tetiklenmez. Alarm değeri en fazla üç makine adını sayar; kimlik sorgusu başarısız olsa bile ağ zorlaması alarmı kendi son iyi sayımını korur.

Rutin: Alarm tetiklendiğinde Makineler sayfasındaki "Kullanıcı kimliği yok (n)" rozetiyle makineleri eşleştirin, kimlik satırındaki nedeni okuyun (Bölüm 13) ve gerekiyorsa yeniden kaydı tetikleyin. Kritik eşiğin sık tetiklendiği filolarda eşikler kurum politikasına göre ayarlanır; alarm kapalıysa (eşikler sıfır) bu kontrol listeden çıkarılabilir.

Haftalık ve Aylık Rutinler¶

Haftalık:

Raporlar — Raporlar sayfasında (Bölüm 27) zamanlanmış üretimden çıkan raporların Geçmiş sekmesinde "tamamlandı" olarak listelendiği doğrulanır; eksik ya da başarısız üretim varsa Zamanlamalar sekmesindeki tanım ve E-posta/SMTP ayarları (Bölüm 6) gözden geçirilir. Talep üzerine haftalık özet raporu üretilip arşivlenir; zamanlanmış üretim denetimi (rapor üretiminin kendisinin çalıştığının kontrolü) de bu turda yapılır.
Filo özeti — Makineler'deki rozet sayıları ve Geliştirici Araçları'ndaki filo güncelleme matrisi haftalık trendle değerlendirilir; sürekli "Onay güncel değil" ya da "Kayıt takıldı (n)" üreten gruplar kök nedeniyle çözülür.

Aylık:

Sertifika süreleri — Ayarlar → Sertifikalar → Web TLS panelindeki "Geçerlilik Bitişi" tarihi kontrol edilir; TLS Sertifika Uyarı Günleri eşiği (varsayılan 30 gün) dolan sertifika için yenileme takvimi açar. Yenileme, SPKI pin'i doğrulayan ajanları koparmamak için Bölüm 6'daki Ajan PIN Dağıtımı runbook'u (önce pin dağıt, bekle, sonra sertifikayı yükle) ile planlanmalıdır.
Lisans kalan günü — Lisans sekmesindeki "Kalan Gün" değeri kontrol edilir; 30 günün altındaki lisanslar için yenileme süreci başlatılır ve hub erişimi doğrulanır.
Uyarı eşikleri gözden geçirme — Uyarı Eşikleri (gecikme, reddetme oranı, güvenlik olayları, kimlik kaybı) aylık turda gerçek trafik profiline göre gözden geçirilir; hazır-bulunurluk probu kademelemesi (hangi kontrollerin /readyz içinde kritik olacağı) de bu turda doğrulanır.

Politika Değişikliği Sonrası Doğrulama¶

Her politika, kural veya erişim değişikliğinden sonra:

Değişikliğin etkilediği modülün sayfasına gidin (Model Rules, PII Rules, Access Management vb.) ve kuralın durumunun enabled olduğunu kontrol edin.
Etkilenen kullanıcı veya grup için User Management → Effective Policy modalını açarak politika çözülümünü (resolution) doğrulayın.
Denetim Kayıtları üzerinde değişikliğin loglandığını kontrol edin.

Transparent Proxy Değişikliği Sonrası Kontrol¶

Transparent proxy veya intercept domain değişikliğinden sonra:

System Settings → Runtime sekmesinde "Transparent Proxy" durumunun "Active" olduğunu kontrol edin.
INTERCEPT_DOMAINS ortam değişkeninde listelenen domainlere test isteği göndererek trafiğin Arceris üzerinden geçtiğini doğrulayın.
Captive Portal aktifse, kimlik doğrulamasız bir tarayıcıdan intercept domain'e erişmeyi deneyerek captive login akışının çalıştığını doğrulayın.

Kimlik Entegrasyonu Sonrası Kontrol¶

LDAP veya rol eşleme değişikliğinden sonra:

Test kullanıcısı ile admin login (https://<ARCERIS_HOST>:8443/login) ve user login (https://<ARCERIS_HOST>:8443/user/login) akışlarını doğrulayın.
Kullanıcının doğru role atandığını User Management sayfasından kontrol edin.
Proxy token erişimi için kullanıcı profilinde proxy token oluşturmayı deneyin.