Teknik Olmayan Kurucular için Sunucu Yönetimi
16 Ağustos 2026 tarihinde yayımlandı
Ödeme sayfanız yavaş, bir müşteri hata bildiriyor ve geliştiriciniz çevrimdışı. Teknik olmayan kurucular için sunucu yönetiminin gerçek sınavı budur. Kahvaltıdan önce Linux yöneticisi olmanıza gerek yok. Açık sorumluluklara, erken uyarıya, kurtarılabilir yedeklere ve bir şeyler düzgün çalışmadığında harekete geçebilecek bir destek ekibine ihtiyacınız var.
Bir sunucu sadece bir web sitesinin barındığı yer değildir. Potansiyel müşterileri toplayan, siparişleri işleyen, müşteri işlerini teslim eden, dosyaları depolayan ve ekibinizi destekleyen sistemleri çalıştırır. Durursa, maliyet nadiren birkaç dakikalık kesintiyle sınırlı kalır. Bu; gelir kaybı, güvenin zedelenmesi ve yabancı grafiklerle dolu bir panoyu anlamaya çalışarak geçirilen uzun bir öğleden sonra anlamına gelebilir.
Pratik hedef basittir: neyin yönetilmesi gerektiğini bilin, buna kimin bakacağını belirleyin ve bir sorunun iş krizine dönüşmeden önce tespit edilip geri alınabildiğinden emin olun.
Sunucu yönetimi aslında neleri kapsar
Sunucu yönetimi, bir altyapı ortamını erişilebilir, güvenli, güncel ve kurtarılabilir tutmak için gereken sürekli çalışmadır. Bir VPS sağlamak yalnızca başlangıçtır. Bir sunucu çevrimiçi olabilir, ancak diski neredeyse dolu, yedeği başarısız olmuş, uygulaması hatalar veriyor veya SSL sertifikasının süresinin dolmasına az kalmış olabilir. Teknik olarak çalışıyordur. Operasyonel olarak ise sorun davet ediyordur.
Bu çalışma genellikle işletim sistemi güncellemelerini, güvenlik duvarı yapılandırmasını, erişim kontrolünü, kötü amaçlı yazılım kontrollerini, performans ayarını, hizmet izlemesini, günlük incelemesini, yedek doğrulamasını ve olay müdahalesini içerir. Bir e-ticaret işletmesi için buna veritabanı performansını ve ödemeyle ilgili uygulama hatalarını kontrol etmek de dahil olabilir. Bir ajans için öncelik, birden fazla müşteri sitesini yalıtılmış, güncel ve geri yüklemesi kolay tutmak olabilir.
Her şirket aynı düzeyde yönetime ihtiyaç duymaz. Basit bir tanıtım sitesi, müşteri hesapları ve zamanlanmış arka plan işleri olan bir SaaS platformuna kıyasla daha küçük bir risk yüzeyine sahiptir. Yine de ikisinin de temel konulardan sorumlu birine ihtiyacı vardır. Fatura ödendi diye sunucu kendini yönetmeye başlamaz. Sessiz bir makinedir, ama fikirleri vardır.
Teknik olmayan kurucular için sunucu yönetimi: sahiplenmeniz gerekenler
Komut satırını değil, iş kararlarını sahiplenmelisiniz. Bu, hangi sistemlerin kritik olduğunu, kimin erişimi bulunduğunu, ne kadar kesintinin kabul edilebilir olduğunu ve en son çalışan yedeğin nerede bulunabileceğini bilmek anlamına gelir. Bu kararlar tamamen dış kaynak kullanımına bırakılamaz çünkü müşterilerinize, operasyonlarınıza ve risk toleransınıza bağlıdır.
Yararlı bir başlangıç noktası, kritik yolunuzu belirlemektir. Bir mağaza için bu genellikle ana sayfa, ürün sayfaları, sepet, ödeme, işlemsel e-posta ve envanter bağlantısıdır. Bir SaaS işletmesi için buna uygulama, veritabanı, giriş sağlayıcısı, e-posta teslimatı ve arka plan kuyruğu dahil olabilir. Bir ajans için her müşteri sitesini, DNS kayıtlarını ve her türlü white-label kontrol paneli erişimini dahil edin.
Ardından her katman için bir sorumlu atayın. Barındırma sağlayıcınız sunucu işletim sistemini ve izlemeyi yönetebilir. Geliştiriciniz uygulama kodunu ve dağıtımları yönetebilir. İç ekibiniz alan adlarından, müşteri verilerinden ve hesap erişiminden sorumlu olabilir. Herkes bir sorunu başka birinin ele aldığını varsaydığında boşluklar ortaya çıkar.
Kısa bir operasyonel kaydı sunucunun dışında tutun. Burada alan adlarının nerede kayıtlı olduğu, sunucuyu hangi sağlayıcının barındırdığı, acil çalışmaları kimin onaylayabileceği, yedeklerin nerede saklandığı ve geliştiricinize nasıl ulaşılacağı belirtilmelidir. Bu, sırf prosedür olsun diye yapılan bir bürokrasi değildir. Kesinti sırasında eksik olan küçük ayrıntılar pahalı ayrıntılara dönüşür.
Erişim kolaylığa göre değil, bilinçli olarak verilmelidir
Mümkün olan her yerde bireysel hesaplar kullanın. Tek bir root parolasını sohbet mesajları, eski elektronik tablolar veya FINAL-final-2 adlı belge türleri üzerinden paylaşmaktan kaçının. Barındırma, alan adı, bulut depolama ve e-posta hesapları için çok faktörlü kimlik doğrulamayı etkinleştirin. Bir yüklenici veya çalışan ayrıldığında erişimi kaldırın.
Teknik iş ortağınız ortamı onarmak için yükseltilmiş erişime ihtiyaç duyabilir, ancak bu erişim kontrollü ve izlenebilir olmalıdır. SSH anahtarları, hesap düzeyi izinler, güvenlik duvarı kısıtlamaları ve etkinlik kayıtları kullanıp kullanmadıklarını sorun. Bunlar, birinin hayatı gereksiz yere zorlaştırdığının işaretleri değil, normal operasyonel uygulamalardır.
Yönetilen hizmeti güvene göre değil, riske göre seçin
Birçok kurucu, ucuz göründüğü ve bol miktarda kaynak sunduğu için unmanaged VPS ile başlar. Ekibinizde Linux bakımını yapma, uyarılara yanıt verme, güvenlik yamalarını uygulama ve hizmetleri elverişsiz saatlerde geri yükleme konusunda rahat olan biri varsa bu mantıklı bir seçim olabilir.
Bu kişi mevcut değilse, yönetilen hizmet genellikle daha düşük riskli seçenektir. Bu, rutin sunucu işlerini; ana makineyi izleyebilen, uyarıları inceleyebilen, temel hizmetlerin bakımını yapabilen ve normal çalışmayı geri getirmeye yardımcı olabilen altyapı teknisyenlerine kaydırır. İşi hâlâ siz kontrol edersiniz, ancak sabah 2:13'te başarısız olmuş bir veritabanı hizmetiyle baş başa kalmazsınız.
Yönetilen barındırma, her uygulama sorununun otomatik olarak düzeltileceği anlamına gelmez. Bir sağlayıcı sunucuyu sağlıklı tutabilir, ancak bir eklenti çakışması, bozuk dağıtım veya hatalı uygulama sorgusu yine de geliştirici dikkatine ihtiyaç duyabilir. Sınır, bir olay yaşanmadan önce net olmalıdır. İşletim sistemi, web sunucusu, veritabanı, yedekler, güvenlik sıkılaştırması ve uygulama düzeyinde sorun gidermede nelerin kapsandığını sorun.
kodu.cloud'da bu operasyonel orta yol; yönetilen hizmetler, otomatik yedekleme seçenekleri, FASTCARE monitoring ve yeni başlayanlar için uygun bir kontrol paneli ile desteklenir. Amaç teknik çalışmayı gizlemek değildir. Amaç, şansa bırakılmaması gereken bölümlerin yetkin kişiler tarafından izlendiğinden emin olmaktır.
İzleme, sorunları müşterilerden önce size söyler
Çalışırlık izlemesi, bir web sitesinin veya hizmetin dışarıdan yanıt verip vermediğini kontrol eder. Sunucu izlemesi daha derine bakar: CPU yükü, bellek baskısı, disk kullanımı, ağ trafiği, süreç hataları ve hizmet erişilebilirliği. İkisi de önemlidir.
Bir web sitesi, veritabanı bağlantı sınırına yaklaşmışken bile bir sayfa döndürebilir. Bir sunucunun CPU kullanımı düşük olabilirken diski dolu olabilir ve yeni siparişleri veya günlükleri yazamayabilir. İzleme, bu sessiz arızaları, destek gelen kutusunda şenliğe dönüşmeden önce kontrol edilebilecek uyarılara dönüştürür.
Çoğu işletme için uyarılar en azından erişilebilirliği, disk alanını, yedek başarısını, sertifika süresinin dolmasını, olağan dışı kaynak sıçramalarını ve temel hizmet arızalarını kapsamalıdır. Uyarıların ayrıca harekete geçebilecek bir alıcısı da olmalıdır. Terk edilmiş bir gelen kutusuna gönderilen mesaj, izleme tiyatrosudur.
Sağlayıcınıza uyarıların nasıl ele alındığını sorun. Kritik olaylar için 7/24 insan incelemesi var mı? Sunucu yalnızca erişilebilirlik açısından mı izleniyor, yoksa altyapı metrikleri de kontrol ediliyor mu? Teknik ekibiniz daha derin görünürlük gerektiğinde Prometheus ve Grafana gibi araçlar üzerinden metriklere erişebiliyor mu? Doğru yanıt ortamınıza bağlıdır, ancak belirsiz yanıtlar pek güven vermez.
Yedekler yalnızca geri yükleme çalışıyorsa faydalıdır
Bir yedek stratejisi üç soruya yanıt vermelidir: neler yedekleniyor, ne sıklıkla ve ne kadar hızlı geri yüklenebiliyor? Bunlara yanıt veremiyorsanız, bir yedek planından çok umudunuz var demektir.
Birçok işletme sitesi için günlük yedekler makul bir temel düzeydir. Hızla değişen veritabanları, yoğun mağazalar ve SaaS uygulamaları daha sık veritabanı yedeklerine ihtiyaç duyabilir çünkü tam bir günlük boşluk kabul edilemez olabilir. Saklama süresi de önemlidir. Yakın tarihli tek bir yedek bile zaten bozulmuş bir dosya veya ele geçirilmiş veriler içerebilir.
Yedek kopyalarını üretim sunucusundan ayrı tutun. Sunucu silinirse, fidye yazılımı tarafından şifrelenirse veya bir yapılandırma hatasıyla zarar görürse, yalnızca aynı sunucuda saklanan yedekler onunla birlikte ortadan kaybolabilir. Sunucu dışı depolama çok daha iyi bir kurtarma konumu sağlar.
Baskı oluşmadan önce bir geri yükleme testi yapın. Bir siteyi veya veritabanını güvenli bir test konumuna geri yükleyin ve gerçekten çalıştığını doğrulayın. Kullanıcı girişlerini, formları, siparişleri, dosya yüklemelerini ve zamanlanmış görevleri kontrol edin. Günlükler şimdi de aynı hikâyeyi anlatıyor, bu iyi bir şey. Başarıyla tamamlanan ama geri yüklenemeyen bir yedek, altyapı tarafındaki daha az güzel durumlardan biridir.
Basit bir olay planı isteyin
Başlamak için 40 sayfalık bir felaket kurtarma kılavuzuna ihtiyacınız yok. Hizmet kesildiğinde veya ihlal edildiğinde ne olacağını açıklayan kısa bir plana ihtiyacınız var. Birincil kişileri, barındırma destek kanalını, geliştirici iletişimini, alan adı kayıt kuruluşu erişimini, son bilinen yedek konumunu ve müşteri iletişimi için bir kuralı ekleyin.
Geri alma, bakım penceresi veya acil sunucu yeniden kurulumunu kimin onaylayabileceğine karar verin. Ayrıca hangi bilgilerin kamuya açık paylaşılması gerektiğine de karar verin. Birçok olayda sakin bir durum mesajı sessizlikten iyidir, ancak neden doğrulanmadan önce tahminde bulunmayın.
Önemli bir kesintiden sonra sade dille bir açıklama isteyin: ne başarısız oldu, ne yapıldı, ne kadar sürdü ve tekrar yaşanma olasılığını ne azaltacak. İyi bir sağlayıcı veya teknik iş ortağı bunu kısaltmaların arkasına saklanmadan açıklayabilmelidir. Teknik ayrıntı faydalıdır, ancak hesap verebilirlik daha faydalıdır.
Kurucunun aylık sunucu kontrolü
Ayda bir kez, sağlayıcınız veya teknik liderinizle operasyonel temelleri kontrol etmek için 20 dakika ayırın. Yedeklerin tamamlandığını ve geri yüklemenin planlandığı şekilde test edildiğini doğrulayın. Erişimi olan kullanıcıları, yaklaşan alan adı ve SSL yenilemelerini, açık güvenlik güncellemelerini, kaynak eğilimlerini ve tekrarlanan izleme uyarılarını gözden geçirin.
Bu aynı zamanda mevcut sunucu boyutunuzun hâlâ uygun olup olmadığını sormanın zamanıdır. Yeni bir mağaza için doğru olan bir VPS, mevsimsel trafik sırasında zorlanabilir. Daha fazla CPU veya bellek yardımcı olabilir, ancak yüke verimsiz kod veya bir veritabanı sorgusu neden oluyorsa optimizasyon daha iyi yanıt olabilir. Ölçekleme paniğe göre değil, kanıta göre yapılmalıdır.
Sizin işiniz her hizmeti onaran kişi olmak değildir. Sizin işiniz doğru kişilerin, korumaların ve kurtarma yollarının zaten yerinde olduğundan emin olmaktır. Böylece bir şey başarısız olduğunda hizmet hızla yeniden sakin hâle gelebilir ve siz de hiç ezberlemeniz gerekmeyen komutları çalıştırmak yerine işi yürütmeye devam edebilirsiniz.
Andres Saar Müşteri Hizmetleri Mühendisi