Sunucu Yapılandırmasını Belgelemek

Bir sunucunun nasıl yapılandırıldığı yalnız bir kişinin hafızasındaysa, o kişi şirketin en büyük tek nokta riskidir.

Belgeleme, bu riski ortadan kaldıran ve teknik olmayan yöneticinin talep etmesi gereken bir çıktıdır.

Belgeleme neden ertelenir?

• Acil değildir
• Görünür bir faydası yoktur (sorun çıkana kadar)
• Zaman alır
• Güncel tutmak ek iş gerektirir

Bu yüzden belgeleme, bir görev olarak atanmadıkça yapılmaz.

1. Adım — Sistem künyesi yazın

Her sunucu için tek sayfalık bir künye:

• ☐ Sistem adı ve amacı
• ☐ Nerede barınıyor (sağlayıcı, konum)
• ☐ Erişim adresleri
• ☐ İşletim sistemi ve sürümü
• ☐ Kaynaklar
• ☐ Üzerindeki hizmetler ve sürümleri
• ☐ Kritiklik düzeyi
• ☐ Sorumlu kişi
• ☐ Devreye alma tarihi

2. Adım — Bağımlılıkları yazın

• ☐ Bu sistem hangi sistemlere bağımlı?
• ☐ Hangi sistemler buna bağımlı?
• ☐ Dış entegrasyonlar neler?
• ☐ Hangi IP adresleri beyaz listede?
• ☐ Hangi zamanlanmış görevler çalışıyor?

Bu bölüm, bir değişiklik ya da kapatma öncesi en çok işe yarayan bölümdür.

3. Adım — Yapılandırma kararlarını yazın

Yalnız "ne yapıldı" değil, "neden yapıldı" da yazılmalıdır:

• Neden bu yapılandırma seçildi?
• Hangi alternatifler değerlendirildi?
• Özel ayarlar neden yapıldı?
• Bilinen kısıtlar neler?
• Geçici çözümler var mı?

Bu bölüm en değerli olanıdır ve neredeyse hiç yazılmaz. Gerekçesi bilinmeyen bir ayar, bir sonraki kişi tarafından "gereksiz" görülüp kaldırılır.

4. Adım — Rutin işlemleri yazın

• ☐ Sistem nasıl yeniden başlatılır?
• ☐ Servisler nasıl durdurulur/başlatılır?
• ☐ Yedek nasıl alınır?
• ☐ Yedekten nasıl dönülür?
• ☐ Güncelleme nasıl yapılır?
• ☐ Kayıtlara nasıl bakılır?
• ☐ Kapasite nasıl artırılır?

Bu bölüm, sorumlu kişi izindeyken bir başkasının müdahale edebilmesini sağlar.

5. Adım — Sorun giderme notları tutun

• Yaşanan sorunlar ve çözümleri
• Tekrar eden durumlar
• Bilinen hatalar ve geçici çözümler
• Hangi kayıt dosyasında ne aranır

Bu notlar, aynı sorun tekrarladığında saatler kazandırır.

6. Adım — Erişim bilgilerini ayrı tutun

• ☐ Parolalar belgede değil, parola yöneticisinde
• ☐ Belgede yalnız "hangi kayıtta" bilgisi var
• ☐ Erişim yetkisi olanlar listelenmiş
• ☐ İki adımlı doğrulama kurtarma kodları güvenli saklanmış

Kritik: Parolalar asla belgeye yazılmaz. Belge paylaşılabilir; parolalar paylaşılmaz.

7. Adım — Acil durum bilgilerini ekleyin

• ☐ Sağlayıcı acil iletişim bilgileri
• ☐ Destek talebi nasıl açılır
• ☐ Sözleşme ve müşteri numarası
• ☐ Kesinti hâlinde izlenecek yol
• ☐ Kimin bilgilendirileceği
• ☐ Geri dönüş prosedürü

Bu bölüm, kriz anında en çok başvurulan bölümdür.

8. Adım — Nerede saklanacağını belirleyin

• ☐ Merkezî ve erişilebilir bir konumda
• ☐ Yedeklenen bir yerde
• ☐ Belgelediği sistemden bağımsız bir yerde
• ☐ Yetkili kişilere erişim verilmiş
• ☐ Sürüm geçmişi tutuluyor

Üçüncü madde kritiktir: Sunucu belgeleri o sunucuda saklanıyorsa, sunucu çöktüğünde belgelere de erişilemez.

9. Adım — Güncel tutma düzeni kurun

• ☐ Her değişiklikten sonra güncellenir
• ☐ Güncelleme, değişiklik sürecinin bir adımıdır
• ☐ Üç ayda bir gözden geçirilir
• ☐ Bir sahibi var
• ☐ Son güncelleme tarihi belgede yazılı

Güncel olmayan belge, yanlış bilgi vererek zarar verebilir.

Belgeleme testi

Belgelerinizin yeterli olup olmadığını anlamanın pratik yolu:

Sistemi hiç görmemiş bir teknik kişiye belgeleri verin ve şu görevleri deneyin: sisteme erişmek, bir servisi yeniden başlatmak, yedekten dosya geri getirmek, bir destek talebi açmak.

Yapamıyorsa belgeler eksiktir.

Asgari belgeleme

Zamanınız çok kısıtlıysa şu dört madde bile kritik riski azaltır:

1. Hangi sistem ne yapıyor ve nerede barınıyor
2. Bağımlılıklar
3. Yedekten nasıl dönülür
4. Acil durum iletişim bilgileri

Devir teslimde belgelerin rolü

Sorumlu kişi değiştiğinde:

• Belgeler devrin temelini oluşturur
• Eksikler devir sırasında tamamlanır
• Yeni sorumlu belgelere bakarak çalışabilmelidir
• Devir sonrası belgeler güncellenir

İyi bir kural: Devir teslim, belgeler tamamlanmadan bitmiş sayılmaz.