Metin2 PvP Server Açılış Planı: Açılıştan Önceki 30 Gün

Bir Metin2 PvP sunucusunun açılış günü, önceki dört haftada yapılanların sınavıdır. Bu yazıdaki plan 30 günü dört haftaya böler: altyapı ve güvenlik, ayar ve içerik denetimi, beta ve yük testi, destek hazırlığı ve açılış provası. Plan bir örnektir; ekip küçükse haftalar uzar ama sıra pek değişmez.

30 gün bir bakışta

Duyuru ve reklam tarafının takvimi server reklamı yazısındadır; bu yazı teknik ve operasyon tarafını anlatır.

1. hafta: altyapı ve güvenlik

Sunucu; giriş sunucusu (auth), veritabanı çekirdeği (db), kanalların oyun çekirdekleri ve MySQL'den oluşur. Kurulumun kendisi server kurulumu, portların dağılımı kanal ve portlar yazısında anlatılır. İlk haftanın işi bu yapıyı canlıya hazırlamaktır:

• Dışarıya yalnız oyuncunun bağlanacağı portları aç: giriş sunucusunun ve kanalların portları. MySQL, db çekirdeğinin portu ve çekirdekler arası (P2P) portlar yalnız iç ağda kalmalı.
• MySQL'de her bağlantı için güçlü ve ayrı parolalar kullan, root hesabını uzaktan bağlantıya kapat.
• İşletim sistemini ve MySQL'i güncel tut, sunucuya parolayla değil anahtarla bağlan.
• Oyun çekirdekleri bir yönetim bağlantısı üzerinden duyuru, bağlantı kesme, yeniden yükleme, olay bayrağı ve kapatma komutları kabul eder. Bu bağlantıyı CONFIG'teki adminpage_ip satırlarıyla yalnız kendi yönetim adreslerine aç ve adminpage_password değerini varsayılanında bırakma.
• Oyun trafiği için DDoS koruması olan bir barındırma seç; oyun sunucusunun IP adresini sitenin IP adresiyle aynı yapma.

Yedek ve kapatma sırası

db çekirdeği oyuncu ve eşya verisini önbellekte tutar ve MySQL'e belli aralıklarla yazar. İncelenen kaynakta varsayılan aralık oyuncu verisi için 7 dakika, eşya verisi için 5 dakikadır; db klasöründeki conf.txt dosyasında PLAYER_CACHE_FLUSH_SECONDS ve ITEM_CACHE_FLUSH_SECONDS satırlarıyla değiştirilir. db süreci normal kapatma sinyaliyle (SIGTERM) kapandığında önbellekteki her şeyi MySQL'e yazar. kill -9 ile öldürülen db ise son dakikaların verisini kaybettirebilir. Ayrıntılar db conf yazısındadır.

Bu yüzden kapatma sırası şöyle olmalı:

1. Oyunculara geri sayımlı duyuru yap. GM'in /shutdown komutu sohbete "... saniye sonra oyun kapanacak." diye geri sayar.
2. Oyun çekirdeklerini normal kapatma sinyaliyle kapat.
3. Giriş sunucusunu ve en son db'yi kapat. db'nin günlüğünde önbelleği yazmaya başladığını gösteren "Starting cache flushing" satırını gör ve sürecin tamamen çıkmasını bekle.
4. Yedeği al. Bütün süreçler kapandıktan sonra alınan bir döküm şöyle olabilir (veritabanı adların farklıysa değiştir):

mysqldump --databases account common player log > yedek_$(date +%F).sql

Yedek dosyası hesap verisi içerir: şifreli, erişimi sınırlı ve sunucudan ayrı bir yerde sakla. Yedeğin işe yaradığı ancak geri yüklenince anlaşılır; ilk hafta boş bir makinede en az bir kez geri yükleme dene. Paketle gelen yedek betiğinin tuzakları yedekleme yazısında.

Günlükler ve izleme

Her çekirdek kendi klasörüne syslog ve syserr günlüklerini yazar. Çekirdek çalışırken eski günlükler 3 günde kendiliğinden silinir; CONFIG'teki log_keep_days yalnız çekirdek açılırken yapılan temizliği belirler, çalışırken bu süreyi uzatmaz. Açılış haftasında çökme ve hata incelemesi için günlükleri düzenli olarak başka bir yere kopyala. Disk doluluğunu da izle; dolan disk hem günlükleri hem veritabanını durdurur.

2. hafta: ayar ve içerik denetimi

Bütün ayarların anlamı CONFIG ayarları yazısındadır. Canlıya çıkmadan önce şu satırlara özellikle bak:

test_server açık kalırsa etkisi oyuncunun gözüne batar: görevlerin hata ayıklama satırları sohbet penceresine düşer, lonca kurma ve katılma bekleme süresi, isim değiştirme süresi gibi kısıtlar atlanır, boşanma süresi bir gün yerine 60 saniyeye iner.

İstemci sürüm denetiminde istemci, derlenirken içine yazılmış bir sürüm değerini gönderir ve sunucu bunu check_version_value ile karşılaştırır. Tutmazsa oyuncu "İstemci versionunuz hatalı. Lütfen normal sürümü yükleyin." mesajıyla oyundan çıkarılır. Yeni bir istemci programı dağıtırken bu değeri de değiştirirsen eski istemcilerle girişi kapatmış olursun; yalnız veri dosyalarını değiştiren yamalarda değer değişmez.

İçerik tarafında kontrol edilecekler:

• Oranlar ve etkinlik bayrakları: varsayılan değerler ve premiumlu oyuncular için ayrı bayraklar. Oranların ekonomiye etkisi ve NPC fiyatlarının nasıl denetleneceği server ekonomisi yazısında anlatılır.
• Drop ve kutu dosyaları: bu dosyalardaki bir yazım hatası çekirdeğin açılışta kapanmasına yol açar. Her değişiklikten sonra çekirdeği test ortamında yeniden başlat; dosya biçimleri drop dosyaları yazısındadır.
• Görevler: derlendikten sonra syserr günlüğünde görev hatası kalmamalı.
• GM hesapları: yalnız gereken kişilere ve gereken yetki düzeyinde. Yetkilendirme GM yapma yazısında anlatılır.

3. hafta: beta ve yük testi

Önce küçük ve güvendiğin bir grupla kapalı beta, sonra herkese açık beta yap. Betaya başlamadan iki şeyi duyur: beta karakterleri açılışta silinecek mi ve betada hata bildirene ne verilecek.

Bulunan hataları herkesin görebildiği bir "bilinen sorunlar" listesinde topla ve düzeltildikçe işaretle.

Kanal planı ve yük

Her çekirdek, CONFIG'teki MAP_ALLOW satırında yazan haritaları yükler. Açılış saatinde yükün büyük kısmı krallıkların ilk köylerindedir; bu haritalar tek çekirdekte toplanırsa o çekirdek darboğaz olur. Örneğin incelenen sunucu dosyalarında tek kanal var ve üç krallığın birinci ve ikinci köyleri ile lonca alanları aynı çekirdekte duruyor (MAP_ALLOW: 1 3 4 21 23 24 41 43 44). Böyle bir düzende ilk günün yükü o çekirdeğe biner; kanal sayısını ve harita dağılımını beta sırasında ölçerek belirle.

Kanal seçim ekranındaki "Kalabalık" ve "Dolu" yazıları, sunucunun toplam çevrimiçi sayısı (bütün kanallar birlikte) iki eşikle karşılaştırılarak beş dakikada bir hesaplanır. İncelenen kaynakta eşikler 500 ve 10'dur, yani 11 kişide bile kanallar "Kalabalık" görünür. Eşikler çekirdeğin klasöründeki state_user_count dosyasıyla değişir; dosyaya önce "Dolu", sonra "Kalabalık" eşiği yazılır ve GM'in /reload u komutuyla çekirdek yeniden başlatılmadan okunur:

800 300

Yukarıdaki sayılar örnektir; kendi kapasitene göre seç. Toplam oyuncu sayısını sınırlamak istersen CONFIG'teki user_limit satırı bu sayıya ulaşıldığında yeni girişleri "Çok fazla kullanıcı bağlı olduğu için bağlanamazsınız." mesajıyla reddeder. İncelenen kaynakta varsayılanı 32768'dir, yani pratikte sınır yoktur.

Yük provası için betada belli bir saatte herkesi aynı anda girişe çağır ve şunlara bak: girişin ne kadar sürdüğü, çekirdeklerin işlemci ve bellek kullanımı, syserr günlüğüne düşen hatalar. Çöken çekirdeği yeniden başlatan bir betik hazırla ve çökme anının günlüklerini sakla.

4. hafta: destek, kurallar ve prova

Destek ekibi

Rolleri baştan ayır: destek, moderatör, GM ve teknik sorumlu. Açılış günü ve sonraki 72 saat boyunca her saatte en az bir destek görevlisi ve bir teknik kişi çevrimiçi olsun. Discord'da talepleri kategorilere böl: giriş sorunu, istemci hatası, hesap, hata bildirimi, şikâyet.

Sık gelecek sorular için hazır cevaplar yaz; istemci tarafındaki yaygın hatalar istemci hataları yazısında toplanır. Teknik bir sorunda takılırsan M2MMO gibi geliştirici forumlarındaki hata çözümleri ve soru-cevap bölümleri işe yarar.

İstemci dağıtımı

İndirme için bir ana, bir yedek bağlantı kullan ve sitede dosyanın SHA-256 özetini yayımla. İstemci Windows Defender'a takılırsa oyuncuya antivirüsünü kapatmasını söyleme; dosyayı Microsoft'un Security Intelligence dosya gönderme sayfasından yanlış pozitif olarak bildir. Diğer antivirüs üreticilerinin bildirim sayfaları da aynı amaçla kullanılır.

İlk gün kuralları

Şunları açılıştan önce yaz, sitede ve Discord'da sabitle:

• Açılış saati ve saat dilimi.
• Geri alma (rollback) politikası: hangi durumda yapılır, en fazla ne kadar geri gidilir, nasıl duyurulur.
• Tazminat politikası: kesinti olursa herkese aynı şekilde ne verileceği.
• Hata bildirimi: bildirene ödül, istismar edene ceza.
• GM davranışı: GM'ler oynamaz, ticaret yapmaz, eşya dağıtmaz. Oyun, GM yetkili karakterlerin GM komutlarını log veritabanındaki command_log tablosuna yazar.
• Çoklu hesap ve çoklu istemci kuralı.
• İlk haftanın oran ve etkinlik planı; açılış günü sürpriz oran değişikliği yapılmaz.
• Hile ve ceza politikası.

Açılış provası

Açılıştan bir iki gün önce tam bir kapatma ve açma yap, yedekten geri dönüşü bir kez daha dene, sunucu saatini ve saat dilimini kontrol et, duyuru metinlerini hazırla.

Girişleri açılış saatine kadar kapalı tutmak istersen CONFIG'e eklenen shutdowned satırı, çekirdek açıkken bütün girişleri "Sunucu henüz açılmadı." mesajıyla reddeder; bu satır GM hesaplarını da içeri almaz. CONFIG yalnız açılışta okunduğu için açılıştan birkaç dakika önce satırı kaldırıp çekirdekleri yeniden başlatman gerekir.

Açılış günü ve ilk 72 saat

• Saatinde aç. İlk saatte syserr günlüklerini, kanal yoğunluğunu ve destek kanallarını izle.
• Birkaç saatte bir kısa bir durum duyurusu yap; sorun yoksa bile "sorun yok" demek oyuncuyu rahatlatır.
• İlk gece için kısa bir bakım penceresi planla ve önceden duyur; ilk günün hataları bu pencerede düzeltilir.
• Bir çekirdek çökerse yeniden başlat, hemen duyur, sebebini inceledikten sonra açıkla.
• Ekonomiyi bozan bir hata fark edilirse (sınırsız Yang ya da eşya çoğaltma gibi) sorunlu sistemi hemen kapat, log kayıtlarıyla etkilenen hesapları bul ve önceden duyurduğun geri alma politikasına göre davran. Hatanın nasıl yapıldığını kamuya yazma.

Akılda kalsın

• Canlıda test_server 0 olur.
• MySQL ve iç portlar dışarıya kapalı, yönetim bağlantısı yalnız tanımlı adreslere açıktır.
• Önce oyun çekirdekleri, en son db kapatılır; db zorla öldürülmez.
• Geri yüklenmemiş yedek, yedek sayılmaz.
• İlk gün kuralları açılıştan önce yazılı olarak duyurulur.