1. Patch Yönetimi Nedir, Neden Kritik?
Patch yönetimi; işletim sistemi, paketler, runtime ve servislerdeki güvenlik güncellemelerini planlı biçimde uygulama disiplinidir. Kritik olmasının nedeni basit: güncellenmeyen sistem, bilinen zafiyetleri taşır. Bu zafiyetler “teorik” değildir; otomatik tarama/bot trafiği tarafından sürekli yoklanır.
Patch yönetimi nedir, web sunucuları için neden önemlidir?
Patch yönetimi; güvenlik ve stabilite güncellemelerini belirli bir süreçle uygulamaktır. Web sunucuları için önemlidir çünkü internete açık bileşenler bilinen açıklar üzerinden hızlıca istismar edilebilir; düzenli patch döngüsü hem saldırı riskini hem de acil kriz yamaları ihtiyacını azaltır.
“Rastgele patch” kaosu neden olur?
Sheet’te de vurgulanan sorun: test eksikliği. Rastgele patch;
- •Üretimde beklenmedik kırılmalar
- •Acil geri alma (rollback) panikleri
- •Bakım penceresi belirsizliği
- •“Kim neyi güncelledi?” sorusunda iz kaybı
üretir. Bunun panzehiri pipeline’dır.
☑ Mini Check: Patch olgunluğu hızlı kontrol
- •Patch politikası (kritik/önemli/düşük) tanımlı mı?
- •Staging/test ortamından geçiyor mu?
- •Bakım penceresi planlı mı?
- •Rollback adımı yazılı ve testli mi?
- •Patch sonrası health-check ve izleme var mı?
Ne yapmalıyım?
- • Patch’i “iş” değil “süreç” yap: politika + takvim + ölçüm.
- • Staging olmadan prod patch yapma; zorunluysa kontrollü yap.
- • Rollback’ı prosedürleştir; tatbik et.
- • Patch sonrası uptime ve performans etkisini izle (Internal link: /tr/seo/teknik-seo).
2. Zafiyet Taraması (Vulnerability Scan) Nasıl Konumlanır?
Vulnerability scanning, patch yönetiminin “radarı”dır. Ama tarama tek başına güvenlik değildir; “bul → önceliklendir → düzelt → doğrula” döngüsünün ilk adımıdır. Ayrıca tarama çıktıları; iş önceliği ve bakım penceresi kararlarını besler.
Zafiyet taraması ne sıklıkla yapılmalı?
Genel yaklaşım; düzenli periyodik tarama (haftalık/aylık) ve büyük değişikliklerden sonra (release/upgrade) ek tarama yapmaktır. Kritik sistemlerde tarama daha sık, düşük riskli ortamlarda daha seyrek olabilir; önemli olan taramanın “aksiyona” bağlanmasıdır.
Tarama kapsamı: sadece OS değil
- •OS paketleri ve kernel seviyeleri
- •Web server ve runtime (PHP/Node/Java)
- •Container image’leri (varsa)
- •Dışa açık servisler ve konfigürasyon (misconfig)
- •Entegrasyon bileşenleri (PMS/portal gateway)
Vulnerability scanner araçları ve “çıktı yönetimi”
Araç isimleri değişebilir; prensip sabit:
- •False-positive ve risk seviyesi ayrımı
- •CVSS/etki + “internete açıklık” + “kritik iş akışı” birlikte değerlendirme
- •“Sahip ekip” atama ve kapanma SLA’ları
☑ Mini Check: Tarama konumlandırma
- •Tarama periyodu ve tetikleyiciler net mi?
- •Kapsam (OS/runtime/container) tanımlı mı?
- •Çıktılar owner’a atanıyor mu?
- •SLA’lar risk seviyesine göre var mı?
- •Fix sonrası doğrulama taraması yapılıyor mu?
Ne yapmalıyım?
- • Tarama → aksiyon bağlantısını kur: her bulgu bir owner ve tarih alsın.
- • Risk önceliklendirmede “internet exposure + iş kritikliği”ni ekle.
- • Fix sonrası doğrulama taramasını standart yap.
- • Log ve kayıtları KVKK kapsamında sakla (Internal link: /tr/raporlama/kvkk-veri-guvenligi).
3. Güncelleme Pencereleri ve Rollback Planı
“Güncelleme yapalım mı, bozulur mu?” sorusunun cevabı; bakım penceresi ve rollback planıdır. Güncelleme penceresi, işi iş sürekliliğiyle uyumlu hale getirir. Rollback, riski yönetilebilir kılar.
Patch’leri doğrudan canlıya almak riskli mi, nasıl planlamalıyım?
Evet, staging/test olmadan doğrudan canlıya almak risklidir; çünkü bağımlılıklar ve konfigürasyon farklılıkları sürpriz çıkarabilir. En sağlıklı plan; önce tarama sonuçlarına göre önceliklendirmek, staging’de test etmek, planlı bakım penceresinde deploy etmek ve bozulursa hızla geri dönecek rollback adımını hazır tutmaktır.
Rollback planı “yedek” değil “geri dönüş yolu”
Rollback; eski pakete dönmek, snapshot/AMI geri almak veya sürüm geri çekmek gibi farklı yöntemler içerir. Hangi yöntem olursa olsun iki şart:
- •Adımlar yazılı ve erişilebilir
- •En azından periyodik olarak tatbik edilmiş
Patch sonrası sağlık kontrolleri
- •Servis health-check
- •Loglarda hata artışı
- •p95 latency ve 5xx trendi
- •Kritik akış testi (login/booking/portal)
☑ Mini Check: Bakım penceresi + rollback
- •Bakım penceresi takvimi var
- •Değişiklik kaydı tutuluyor (kim/ne zaman/ne)
- •Rollback adımı yazılı ve testli
- •Patch sonrası health-check checklist’i var
- •Gözlem süresi (post-deploy monitoring) tanımlı
Ne yapmalıyım?
- • Bakım penceresini iş takvimine bağla (otel sezonu/B2B SLA).
- • Rollback’ı “sadece doküman” değil “tatbikat” yap.
- • Patch sonrası ölçüm (uptime/perf) raporu çıkar.
- • Büyük upgrade’lerde CWV ve uptime etkisini izle (Internal link: /tr/seo/teknik-seo).
4. Otel ve B2B İçin Patch Süreçleri
Patch yönetimi “tek tip” değildir; otel ve B2B’de kritik sistemler farklı olabilir. Buradaki hedef; Tier bazlı yaklaşım kurmaktır.
Otel — PMS/rezervasyon sunucuları
- •Tier-1: rezervasyon/ödeme/availability
- •Daha sıkı SLA ve daha dikkatli bakım penceresi
- •Entegrasyon bağımlılıkları (PMS/OTA) nedeniyle staging testleri daha kritik
B2B — portal/API sunucuları
- •Portal login ve API gateway kritik
- •Export/rapor işleri patch sonrası performansa duyarlı olabilir
- •SLA’lar ve iş saatleri bakım penceresini belirler
Fark yaratan mini bölüm (Competitor Gap): “Kaosu azaltan” 5 karar
- Risk sınıfı → hedef süre (SLA)
- Staging zorunluluğu ve test kapsamı
- Bakım penceresi takvimi
- Rollback yöntemi ve tatbikat
- Post-deploy gözlem ve raporlama
☑ Mini Check: Süreç standardı
- •Tier-1 sistemler net
- •Risk bazlı SLA tanımlı
- •Staging testleri kapsamlı
- •Rollback yöntemi seçili ve tatbik edilmiş
- •Bakım-destek süreciyle senkron (Internal link: /tr/yazilim/bakim-ve-destek)
Ne yapmalıyım?
- • Otel/B2B kritik sistemleri tier’le; patch önceliğini buna göre belirle.
- • Risk bazlı SLA koy; kritik bulgu = hızlı kapanış.
- • Bakım-destek ile patch takvimini birleştir (Internal link: /tr/yazilim/bakim-ve-destek).
- • Büyük patch’lerde teknik SEO etkisini gözlemle (redirect/caching/CWV).
5. İçerik İçi Tablo: Risk Seviyeleri ve Hedef Patch Süreleri
| Risk seviyesi | Örnek durum | Hedef patch süresi (çerçeve) | Not |
|---|---|---|---|
| Kritik | İnternete açık, aktif istismar riski | Saat–gün bandı | Acil bakım penceresi + hızlı rollback |
| Önemli | Doğrudan istismar zor ama etkili | Gün–hafta bandı | Planlı bakım penceresi |
| Düşük | Düşük etki / sınırlı maruziyet | Haftalar | Toplu bakım döngüsünde |
Varsayım: Hedef süreler; altyapı kritiklik ve maruziyete göre değişir; tablo bir çerçeve sunar.
6. Patch Pipeline & Vulnerability Scan Checklist Şablonunu İndir
Patch Pipeline & Vulnerability Scan Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset, patch yönetimini rastgele uygulamadan çıkarıp scan→plan→test→deploy→rollback pipeline’ına dönüştürmek için hazırlanmıştır. Risk seviyelerine göre hedef süre (SLA) tanımlar ve staging testlerini zorunlu hale getirir. Rollback adımlarını yazılı ve tatbik edilebilir bir runbook’a bağlayarak kesinti riskini azaltır.
Kim Kullanır?
Sistem yöneticisi, DevOps/BT, otel IT ve B2B platform ekipleri.
Nasıl Kullanılır?
- Tarama periyodu ve risk SLA’larını doldur.
- Patch’leri staging’de test edip bakım penceresine planla.
- Deploy sonrası health-check uygula; gerekirse rollback’i çalıştır ve raporla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Tarama periyodu (haftalık/aylık + değişiklik sonrası) tanımlı
- ▢ ✅ Risk sınıfları ve SLA’lar yazılı
- ▢ ✅ Owner ataması (sistem/uygulama) net
- ▢ ✅ Staging/test akışı var
- ▢ ✅ Bakım penceresi takvimi var
- ▢ ✅ Rollback yöntemi seçili (snapshot/paket geri alma)
- ▢ ✅ Post-deploy health-check checklist’i var
- ▢ ✅ 24–72 saat gözlem planı var
- ▢ ✅ Rapor ve kayıtlar KVKK uyumlu saklanıyor
- ▢ ✅ Büyük upgrade’lerde CWV/uptime izleniyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •Patch politikası + risk SLA
- •Tarama planı + ticket akışı
- •Staging test planı
- •Rollback runbook
- •Post-deploy rapor şablonu
Bir Sonraki Adım
Kritik zafiyetleri kesinti riskini büyütmeden kapatmak ve scan→fix pipeline’ını otel/B2B sunucularında standardize etmek isteyen ekipler için.
Sık Sorulan Sorular
Patch yönetimi nedir, web sunucuları için neden önemlidir?▾
Zafiyet taraması ne sıklıkla yapılmalı?▾
Patch’leri doğrudan canlıya almak riskli mi, nasıl planlamalıyım?▾
Otel ve B2B sistemleri için patch ve tarama checklist’i nasıl olmalı?▾
“Sunucu güncellemesi yapsak mı, bozulur mu?” kaygısını nasıl yönetirim?▾
İlgili Yazılar