Sunucularda Otomatik Müdahale ve Self-Healing: İzleme, Alarm ve Onarım Rehberi

Son Güncelleme: Mart 2026

Otomatik müdahale (automatic remediation) ve self-healing yaklaşımları, modern sunucu altyapılarında kesinti süresini azaltmak ve operasyonel maliyeti düşürmek için kritik hale gelmiştir. Bu rehberde izleme, alerting, otomatik onarım stratejileri ve pratik uygulama senaryoları adım adım anlatılacaktır.

İçindekiler

• Sunucu Otomatik Müdahale: Genel Bakış
• Neden Gerekli: Faydalar ve Riskler
• Mimari ve Komponentler: Temel Bileşenler
• Alerting ve İzleme: Metodoloji ve Araçlar
• Self-Healing Stratejileri: Otomatik Onarım Yöntemleri
• Uygulama Örnekleri: Komut ve Playbook Örnekleri
• Karşılaştırma Tablosu: Yöntem Karşılaştırması
• SSS: Sıkça Sorulan Sorular
• Sonuç: Corelux Hizmetlerine Yönlendirme

Sunucu Otomatik Müdahale: Genel Bakış

Otomatik müdahale, bir izleme aracı veya olay algılama sistemi tarafından tetiklenen ve belirli koşulların gerçekleşmesi durumunda sistemin kendisini veya ilişkili servisleri onarmaya yönelik otomatik adımların bütünüdür. Bu yaklaşım; kesinti süresini azaltma, operasyonel rutinleri otomasyona bağlama ve insan hatasını azaltma amacı taşır.

Neden Gerekli: Faydalar ve Riskler

Faydalar:

• Kesinti Süresi Azalır: Otomatik müdahale, insan müdahalesi için geçen zamanı ortadan kaldırır veya kısaltır.
• Tekrarlayan İşler Otomatikleşir: Sık görülen arıza tipi için önceden tanımlı onarım adımları uygulanır.
• Operasyonel Maliyet Düşer: Müdahale gerektiren durumlarda insan müdahalesine ihtiyaç azalır.
• Gözlemlenebilirlik Artar: İzleme ve loglama süreçleri daha disiplinli hale gelir.

Riskler:

• Yanlış Müdahale: Yanlış alarm sonucu otomatik eylem alınması sistem durumunu kötüleştirebilir.
• Güvenlik Riskleri: Otomatik script veya playbook'ların yetkileri yanlış yapılandırılırsa yetki yükseltme (privilege escalation) riski doğar.
• Rollback Eksikliği: Otomatik değişikliklerin geri alınamaması sorun yaratabilir.

Mimari ve Komponentler

Etkin bir otomatik müdahale mimarisi şu temel bileşenleri içerir:

• İzleme (Monitoring): Kaynak, uygulama ve altyapı metriklerinin toplanması (ör. CPU, RAM, disk, uygulama hata oranı).
• Log Yönetimi: Olayların (events) ve hata mesajlarının toplanıp aranabilir hale getirilmesi.
• Alerting: İzleme kurallarıyla eşleşen durumlarda bildirim oluşturma ve eylem tetiklemesi.
• Otomatik Eylem Katmanı: Script, sistemd servisleri, configuration management (Ansible, Salt), veya orchestration (Kubernetes, Nomad) ile onarım adımlarının uygulanması.
• İnsan Onayı / Escalation: Bazı kritik durumlar için otomatik eylem yerine insan onayı akışı.
• Audit ve Geri Alma (Rollback): Yapılan otomatik değişikliklerin kayıt altına alınması ve gerekirse geri alınması.

Alerting ve İzleme: Metodoloji ve Araçlar

İzleme ve alerting tasarımında dikkat edilmesi gerekenler:

• Doğru Eşik Değerleri: Çok hassas eşikler noise (gereksiz alarm) üretir; çok gevşek eşikler gerçek problemi kaçırır.
• Multi-metric Korrelasyon: CPU spike tek başına değil; disk IO, load average ve uygulama hata oranı ile birlikte değerlendirilmelidir.
• Backoff ve Deduplication: Aynı alarmın tekrar tekrar tetiklenmesini önlemek için gecikme (backoff) ve deduplication uygulanmalı.

Kullanılabilecek araç örnekleri:

• Prometheus + Alertmanager: Zaman serisi metrik toplama ve esnek alarm kuralları.
• Grafana: Gözlem panoları ve bildirim entegrasyonları.
• ELK / OpenSearch: Log toplama, arama ve korelasyon.
• PagerDuty / OpsGenie: Escalation ve insan müdahalesi akışları.

Self-Healing Stratejileri

Self-healing (kendi kendini iyileştirme) için uygulanabilecek temel stratejiler:

• Simple Restart: Hata tespitinde servisi yeniden başlatma (ör. systemctl restart nginx).
• Process Recycling: Uzun süreli bellek sızıntıları için process restart veya worker cycle uygulama.
• Auto-Scaling / Replace: VM/VPS yerine yeni instance oluşturup trafiği yönlendirme (stateless servislerde uygundur).
• Failover: Aktif-Pasif mimaride sağlık kontrolü başarısızsa VIP veya load balancer yönlendirmesi değiştirme.
• Canary ve Gradual Rollback: Yapılandırma değişiklikleri canary ile test edilip sorun görünürse otomatik rollback uygulama.

Uygulama Örnekleri: Komut ve Playbook Örnekleri

Aşağıda günlük kullanımda işe yarayan örnekler bulunmaktadır.

Basit systemd bazlı restart tetikleyicisi

Prometheus Alertmanager veya başka bir sistemden webhook ile tetiklenen basit bir endpoint, hedef sunucuda systemctl restart komutunu çalıştırabilir. Örnek bir webhook handler (bash):

#!/bin/bash
# /usr/local/bin/auto-restart.sh
SERVICE="$1"
logger "Auto-restart triggered for $SERVICE"
if systemctl is-active --quiet $SERVICE; then
  systemctl restart $SERVICE && logger "$SERVICE restarted"
else
  systemctl start $SERVICE && logger "$SERVICE started"
fi

Bu script'i güvenli hale getirmek için sadece belirli IP'lerden gelen webhook'ları kabul eden bir reverse-proxy veya authentication katmanı ekleyin.

Ansible playbook ile self-healing workflow

Bir servis hatası gözlemlendiğinde Ansible ile hedef sunucuda onarım uygulamak için örnek playbook:

- name: Self-healing webserver
  hosts: webservers
  become: true
  tasks:
    - name: Check nginx process
      shell: pgrep -f nginx || true
      register: nginx_pid

    - name: Restart nginx if not running
      service:
        name: nginx
        state: restarted
      when: nginx_pid.stdout == ""

    - name: Clear cache if disk usage high
      shell: rm -rf /tmp/cache/*
      when: ansible_mounts | selectattr('mount','equalto','/') | map(attribute='size_available') | first | int < 5000000000

Disk doluluk için otomatik uyarı ve temizlik

Disk doluluk alarmı tetiklendiğinde önce en büyük dosyaları listeler, ardından eğer otomatik politika izin veriyorsa geçici dosyaları temizler:

# disk-cleanup.sh
THRESHOLD=90
USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
  logger "Disk usage $USAGE% - running cleanup"
  find /tmp -type f -mtime +3 -delete
fi

Karşılaştırma Tablosu

Güvenlik ve Audit (Not: Bu baslik id icindekilerde listelenmedi ama kurala gore her h2 id olmali)

Otomatik müdahale sistemleri planlanırken güvenlik birincil önceliktir:

• Minimum Yetki İlkesi (Least Privilege): Otomatik eylemler için özel servis hesapları kullanın ve sadece gerekli izinleri verin.
• İmzalı Playbook ve Scriptler: Değişikliklerin kaynağını doğrulamak için imza veya checksum kontrolü uygulayın.
• Audit Logları: Her otomatik eylem kayıt altına alınmalı; kim, ne zaman, ne yaptı bilgisi tutulmalı.

Test ve Validation

Otomatik müdahale mekanizmalarını üretime almadan önce şu testleri yapın:

• Kaos Mühendisliği (Chaos Testing): Kontrollü hata senaryoları ile sistemin beklenen şekilde tepki verip vermediğini doğrulayın.
• Dry-Run Modu: Değişiklikleri uygulamadan önce simülasyon çalıştırın.
• Rollback Testleri: Otomatik onarım sonrası geri alma senaryolarını test edin.

Uygulama Senaryoları

Pratikte sık karşılaşılan senaryolar ve öneriler:

• Webserver Crash: Öncelikle process restart, ardından 3 tekrar başarısızsa yeni instance oluşturma.
• Yüksek CPU: Sadece CPU spike değil; thread dump, garbage collection ve IO metriklerini kontrol ederek root cause bulunmalı.
• Disk Full: Kritiklik seviyesine göre uyarı, ardından otomatik temp temizliği veya yeni disk ekleme prosedürü.
• Memory Leak: İşçi süreçleri periyodik olarak recycle edilip, uzun vadeli çözüm için kod düzeltmesi planlanmalı.

Sıkça Sorulan Sorular

Sonuç

Otomatik müdahale ve self-healing stratejileri, doğru tasarlandığında operasyonel güvenilirliği artırır ve kesinti sürelerini kısaltır. Başarı için izleme, alerting, güvenlik ve geri alma (rollback) mekanizmalarının birlikte tasarlanması gerekir. Corelux'un Sanal Sunucu ve Türkiye Kiralık Sunucu çözümleri, yedekleme ve SSL gibi hizmetlerle altyapınızı otomatik müdahale için hazır hale getirmede destek sunar.

Eğer isterseniz mevcut altyapınızı değerlendirip, risk-temelli self-healing planı ve örnek playbook ile test senaryoları hazırlayabilirim. Hangi platformu (ör. systemd, Ansible, Kubernetes) kullandığınızı belirtin, size özel bir yol haritası hazırlayayım.