Linux Sunucu Yönetimi: Sıfırdan Üretime Yol Haritası

Kısa cevap: Linux sunucu yönetimi, bir makineyi yayına alıp ayakta tutmanın altı katmanıdır: dağıtım seçimi, ilk sertleştirme, servis yayını, izleme, yedekleme ve değişiklik disiplini. Katmanlar birbirinin üstüne biner ve sıra pazarlığa kapalıdır: erişim güvenliği, servis yayınından önce kurulur. Komut ezberleyerek değil, altı katmanı bir kez uçtan uca kurarak öğrenilir.

Linux sunucu yönetimi tam olarak neyi kapsar?

Sunucu yönetimi, “makineyi kurmak” değil, bir servisi kesintisiz ve güvenli biçimde ayakta tutmaktır. İşin kendisi altı katmana ayrılır ve bu katmanlar birbirinin üstüne biner; alttaki eksikse üsttekinin bir anlamı kalmaz.

Katman	Sorusu	Eksikse ne olur
1. Temel	Hangi dağıtım, hangi kaynak, nerede duruyor	Yanlış temelde her şey yamalı ilerler
2. Erişim ve sertleştirme	Kim, nereden, nasıl giriyor	Sunucu haftalar içinde tarama botlarının hedefi olur
3. Servis yayını	Uygulama nasıl çalışıyor, yeniden başlatmada ne oluyor	Elektrik kesintisinden sonra servis geri gelmez
4. İzleme	Bozulduğunu nasıl öğreniyorsunuz	Sorunu müşteri size haber verir
5. Yedekleme	Kaybettiğinizde nereden dönüyorsunuz	Tek disk arızası projeyi bitirir
6. Değişiklik disiplini	Ne değişti, kim değiştirdi, geri nasıl alınır	“Dün çalışıyordu” sarmalı

Sıra rastgele değil. Yeni bir sunucuda servisi yayına almadan önce erişimi kapatmak zorundasınız; çünkü açık bir SSH portu, üzerinde tek bir servis olmasa bile kurulumun ilk saatinden itibaren otomatik parola denemesi alır. Honeypot ağımdan topladığım veride yeni açılan bir sunucunun ilk yirmi dört saatte gördüğü SSH giriş denemesi sayısı dört haneli mertebede seyrediyor ve bu denemeler insan değil, tamamen otomatik tarama altyapıları tarafından yapılıyor. Bu yüzden 2. katman her zaman 3. katmandan önce gelir.

Hangi Linux dağıtımı seçilmeli?

Doğru cevap “en sevdiğiniz” değil, destek süresi projenizin ömründen uzun olan dağıtımdır. Sunucu tarafında pratikte üç aile vardır ve seçim genellikle ekosisteminize göre yapılır.

• Debian stable: Muhafazakâr, sürprizi az, paketleri görece eski. Uzun süre dokunmadan çalışacak altyapı sunucuları (yönlendirici yardımcıları, izleme, yedek deposu) için tercih ediyorum.
• Ubuntu Server LTS: Debian tabanlı, beş yıllık destek, en geniş üçüncü taraf doküman ve resmi kurulum betiği desteği. Konteyner ve uygulama sunucularında varsayılan seçimim; çoğu proje kurulum yönergesini önce Ubuntu için yazıyor.
• RHEL ve türevleri (Rocky, AlmaLinux): Kurumsal destek sözleşmesi, SELinux’un varsayılan sıkı yapılandırması ve uzun yaşam döngüsü. Denetime tabi kurumsal ortamlarda güçlü tercih.

Karar verirken üç şeye bakın: (1) kullanacağınız yazılımın resmi kurulum belgesi hangi dağıtımı örnekliyor, (2) güvenlik güncellemesi kaç yıl gelecek, (3) ekipteki insanlar hangisini biliyor. Üçü aynı yöne işaret ediyorsa tartışmaya gerek yok.

Bir uyarı: sunucuda masaüstü dağıtımı (ör. Ubuntu Desktop veya Fedora Workstation) kullanmayın. Grafik arayüz RAM tüketmekle kalmaz, sunucuda bulunmaması gereken onlarca servisi de beraberinde açar. Sunucuda kural nettir: ne kadar az paket, o kadar az saldırı yüzeyi.

VPS mi, kendi donanımım mı, sanallaştırma mı?

Bu üç seçenek rakip değil; farklı maliyet ve sorumluluk dağılımlarıdır.

Seçenek	Avantaj	Bedeli	Ne zaman
Paylaşımlı hosting	Sıfır yönetim	Kök erişim yok, esneklik yok	Yalnız statik veya basit CMS sitesi
VPS / bulut sunucu	Dakikalar içinde hazır, esnek ölçek	Aylık maliyet, komşu etkisi	Değişken yük, hızlı başlangıç, coğrafi dağıtım
Kendi donanımı + hipervizör	Uzun vadede en düşük birim maliyet, veri sizde	Elektrik, yedeklilik, fiziksel bakım sizde	Sabit yük, veri yerelliği, çok sayıda VM

Pratikte en sağlıklı kurgu karışıktır: kritik veri ve iç servisler kendi donanımınızdaki sanallaştırma katmanında, dışa bakan ve coğrafi dağıtım isteyen servisler bulutta. Kendi donanımınıza gidiyorsanız bir sonraki karar hipervizör seçimidir; bunun tamamını sanallaştırma rehberinde ve Proxmox VE kurulumunda ayrı ayrı anlattım.

Sık yapılan hata, tek bir güçlü fiziksel sunucu alıp her şeyi doğrudan onun üzerine kurmaktır. Bu makine bir kez yeniden kurulmak zorunda kaldığında (donanım değişimi, disk arızası, sürüm yükseltmesi) üzerindeki her servis birlikte durur. Aynı donanımı hipervizöre çevirip servisleri ayrı sanal makinelere bölmek, aynı maliyetle taşınabilirlik ve snapshot imkânı kazandırır.

Yeni sunucuda ilk oturum: hangi işler hangi sırayla?

İlk oturumda yapılacaklar bir alışkanlık listesidir; ezberden değil listeden yapılır. Sıralama şu:

1. Sistemi güncelle. Kurulum imajı her zaman eskidir; ilk iş depoyu tazeleyip güvenlik yamalarını almaktır.
2. Kendine sudo yetkili bir kullanıcı aç ve o kullanıcının SSH anahtarını yerleştir.
3. Root ile parola girişini kapat, anahtar tabanlı kimlik doğrulamaya geç.
4. Firewall’u varsayılan kapalı kur, yalnız gerekli portları aç.
5. Otomatik güvenlik güncellemesini etkinleştir.
6. Saat senkronizasyonunu doğrula (sertifika ve log doğruluğu buna bağlıdır).

Bu altı adımın komut düzeyinde tam karşılığını, kopyalanabilir bir kontrol listesiyle birlikte yeni VPS’te ilk 30 dakika yazısında adım adım verdim. Erişim katmanının derinliği (anahtar üretimi, iki faktörlü doğrulama, otomatik ban) ise SSH sertleştirme rehberinin konusudur.

En sık gördüğüm hata sıranın tersine dönmesidir: önce uygulama kurulur, “sonra güvenliğe bakarız” denir. Sonra bakılmaz. Sunucuya bir servis kurulduğu andan itibaren dışarıdan görünür hâle gelir; sertleştirme, servisten sonra yapılan bir bakım işi değil, servisten önce atılan bir zemindir.

Servisleri nasıl yayına almalı: paket, konteyner yoksa el ile derleme?

Üç yol vardır ve seçim, güncelleme sorumluluğunu kimin taşıyacağını belirler.

• Dağıtım paketi (apt/dnf): Güvenlik güncellemesini dağıtım üstlenir, en düşük bakım yükü. Sürümü eski olabilir. Altyapı servisleri için varsayılan tercihim.
• Konteyner (Docker/Compose): Sürüm ve bağımlılıklar uygulamayla birlikte gelir, taşınabilirlik yüksek. Güncelleme sorumluluğu size geçer. Uygulama servisleri için varsayılan tercihim; üretim ayarlarının tamamı Docker Compose üretim rehberinde.
• Kaynaktan derleme: Yalnız başka yolu kalmadığında. Güvenlik yamasını her seferinde elle takip etmek zorundasınız; unutulduğunda sunucudaki en eski ve en açık bileşen bu olur.

Hangi yolu seçerseniz seçin bir koşul değişmez: servis yeniden başlatmada kendiliğinden ayağa kalkmalıdır. Pakette bunu systemd, konteynerde restart politikası sağlar. Sunucu bir gün mutlaka beklenmedik biçimde yeniden başlar; o an servisin elle başlatılmayı beklediğini fark etmek, kesinti süresini dakikalardan saatlere çıkarır.

Uygulamalarınızı sürekli deploy ediyorsanız Compose’u elle yönetmek yerine kendi sunucunuzda çalışan bir dağıtım katmanı kurmak işi ciddi biçimde kolaylaştırır; bunun için Coolify ile self-hosted PaaS yazısına bakın.

İzleme ve yedekleme: hangisi önce, ne kadarı yeterli?

Bu ikisi “sonra yaparız” listesinin klasik üyeleridir ve sunucu yönetiminin gerçek sınavı buradadır.

İzlemede ölçüt basittir: uyarı gerçekten size ulaşıyor mu? Ekranda kırmızı gösteren ama kimseye bildirim göndermeyen bir panel, izleme değil dekorasyondur. Minimum sette dört şey izlenir: erişilebilirlik (servis ayakta mı), disk doluluğu, bellek ve yük, sertifika bitiş tarihi. Bu dördü kurulmadan gelişmiş metriklere geçmenin faydası yok. Araç seçimi ve gerçek eşik değerleri için sunucu izleme rehberi.

Yedeklemede ölçüt daha da basittir: en son ne zaman geri döndünüz? Yedek almak bir dosya işlemidir, yedeğin çalıştığını bilmek ise bir testtir. Alınmış ama hiç geri yüklenmemiş yedek, istatistiksel olarak yedek sayılmaz; şifreleme anahtarı kaybolmuş, arşiv bozulmuş veya veritabanı tutarsız anda alınmış olabilir. Kural: her yedek planı, en az bir kez boş bir makineye geri yükleme testinden geçmelidir.

Üçlü kural (3 kopya, 2 farklı ortam, 1 kopya dışarıda) hâlâ geçerlidir ve sanallaştırma kullanıyorsanız Proxmox tarafındaki snapshot ve yedekleme mekanizmalarıyla çok daha ucuza kurulur. Snapshot’ın yedek olmadığını unutmayın: snapshot aynı depolamada durur, depolama giderse ikisi birlikte gider.

Değişiklik disiplini nedir, sunucuyu nasıl yönetilebilir tutar?

Teknik olarak her şeyi doğru kurmuş olabilirsiniz; sunucu yine de altı ay içinde kimsenin dokunmaya cesaret edemediği bir kutuya dönüşebilir. Bunu engelleyen şey araç değil, disiplindir.

Uyguladığım üç kural şu:

• Elle yapılan her üretim müdahalesi yazılır. Ne yapıldı, neden yapıldı, geri alma adımı ne. Bu kaydı tutmanın maliyeti iki dakika, tutmamanın maliyeti bir sonraki arızada saatlerdir.
• Yapılandırma dosyaları sürüm kontrolünde durur. En azından /etc altındaki kritik dosyaların kopyası bir depoda olmalı. Böylece “dün çalışıyordu” sorusu bir diff ile cevaplanır.
• Değişiklik önce test ortamında yapılır. Sanallaştırma kullanıyorsanız bunun maliyeti neredeyse sıfırdır: snapshot alır, denersiniz, olmazsa geri dönersiniz.

Bu üçüncü madde tek başına sanallaştırmaya geçmenin en güçlü gerekçesidir. Fiziksel makinede riskli bir yükseltmeyi denemek cesaret ister; snapshot alınmış bir sanal makinede aynı işlem geri alınabilir bir denemeye dönüşür.

Yol haritası: hangi yazıyı hangi sırayla okumalı?

Bu kümedeki yazılar birbirinin üstüne biner. Sıfırdan başlıyorsanız önerdiğim sıra:

1. Bu sayfa (genel çerçeve ve karar noktaları).
2. Yeni VPS’te ilk 30 dakika (kopyalanabilir sertleştirme listesi).
3. SSH sertleştirme: anahtar, 2FA, fail2ban (erişim katmanının derinliği).
4. Linux firewall: ufw, firewalld, nftables (ağ katmanı; MikroTik tarafındaki karşılığı için MikroTik firewall yazısı).
5. Sunucu izleme ve ardından yedekleme testi.
6. Sanallaştırmaya geçiş: VM mi konteyner mi, sonra Proxmox kurulumu.
7. Uygulama yayını: Docker Compose üretim rehberi ve Coolify.

Kurumsal ölçekte bu katmanların tamamını kurmak ve işletmek ayrı bir iştir; sistem yönetimi hizmetleri sayfasında bu işi nasıl yürüttüğümü anlattım. Ağ tarafı da işin içindeyse network yönetimi sayfası bu haritanın ağ ayağını tamamlar.

Linux sunucu yönetiminde en sık yapılan hatalar neler?

Sahada tekrar tekrar gördüğüm hatalar, hepsi önlenebilir:

1. Servisten önce sertleştirme yapmamak. Sunucu açıldığı an taranmaya başlar.
2. Root ile parola girişini açık bırakmak. Otomatik saldırıların ilk denediği yol budur.
3. Firewall’u “her şeye izin ver” ile kurup sonra daraltmayı unutmak. Varsayılan kapalı kurulur, ihtiyaç doğdukça açılır.
4. Disk doluluğunu izlememek. Üretim sunucularında en sık gördüğüm kesinti nedeni donanım arızası değil, dolan disktir; log rotasyonu yapılmamış bir servis birkaç ayda diski bitirir.
5. Yedeği hiç geri yüklememek. Test edilmemiş yedek bir varsayımdır.
6. Otomatik güncellemeyi kapatıp elle takip edeceğini varsaymak. Elle takip birkaç hafta sürer, sonra unutulur.
7. Elle müdahaleyi kaydetmemek. Altı ay sonra o değişikliği hatırlamayacaksınız.

Bu yedi maddeyi kapatmış bir sunucu, çoğu küçük ve orta ölçekli kurulumun ihtiyacından fazlasını karşılar. Geri kalan her şey bu zeminin üstüne inşa edilir.

Kaynaklar

• Ubuntu Server Documentation (Canonical resmi sunucu dokümantasyonu)
• Debian Documentation (dağıtım politikaları ve sistem yönetimi)
• systemd.service manual (servis birimleri ve otomatik başlatma)