საცდელი თამაშის სერვერი production-ის გვერდით

საცდელი სერვერი შენი თამაშის სერვერის მეორე, უფრო პატარა ასლია - იგივე თამაშის ვერსია, იგივე mod-ები, სამყაროს ბოლოდროინდელი ასლი - სხვა სახელით, საკუთარი პაროლებითა და token-ებით და ისე, რომ მოთამაშეებმა შემთხვევით ვერ მიაგნონ. ყოველი თამაშის განახლება, mod-ის განახლება და სარისკო კონფიგის ცვლილება ჯერ იქ მიდის; მხოლოდ მაშინ, როცა ის ჩაირთვება, სამყაროს ჩატვირთავს და შენი ერთსაათიანი ჩხრეკის შემდეგ ცოცხალი დარჩება, მიდის იგივე ცვლილება რეალურ სერვერზე. mod-ებიანი სერვერისთვის ეს განსხვავებაა გატეხილი mod-ის აღმოჩენას შორის სამშაბათს შუადღისას შენს მაგიდასთან და პარასკევ საღამოს, როცა Discord-ში ორმოცი ადამიანი კითხულობს, რა მოხდა. ეს ერთი დამატებითი პატარა გეგმა ღირს, და თვის უმეტეს ნაწილს შეიძლება გაჩერებული იდგეს.

ეს პოსტი იდეის თამაშის სერვერის ვერსიაა. staging გარემოს ზოგადი პრინციპები - ძირითადად ვებ-აპლიკაციებისთვის დაწერილი - მოცემულია სტატიაში staging და production ერთ ანგარიშზე. აქ საზრუნავი თამაშისთვის სპეციფიკურია: სამყაროს ასლები, mod-ების თანხვედრა კლიენტებზე, token-ები, რომლებიც ერთდროულად მხოლოდ ერთ სერვერს შეუძლია გამოიყენოს, და გაზიარებული მონაცემთა ბაზები, რომელთა გამოც საცდელი სერვერი ჩუმად ცვლის რეალურს.

რას იჭერს საცდელი სერვერი და რას არა#

ნათლად გესმოდეს, რას ყიდულობ, რადგან საცდელი სერვერი ზოგ რამეში შესანიშნავია, ზოგში კი უსარგებლო.

ის საიმედოდ იჭერს:

• mod-ებს, რომლებიც თამაშის განახლებაზე ტყდება. mod-ებიანი სერვერის გათიშვის ყველაზე გავრცელებული მიზეზი და ყველაზე ადვილად დასაჭერი: განაახლე საცდელი სერვერი, ჩართე, წაიკითხე ლოგი.
• სამყაროს გარდაქმნის პრობლემებს. თამაშის დიდი განახლებები save-ს პირველი ჩატვირთვისას გარდაქმნის. ჯერ ასლზე ამის გაკეთება გეუბნება, მუშაობს თუ არა და რამდენ ხანს გრძელდება.
• კონფიგის შეცდომებს. შეცდომა YAML ფაილში, დაკარგული ფრჩხილი INI-ში, პარამეტრი, რომელიც არ აკეთებს იმას, რაც დოკუმენტაციიდან ჩანდა.
• plugin-ებისა და mod-ების კონფლიქტებს. ორი plugin, რომელიც ერთსა და იმავე მოვლენაზე ან ბრძანებაზე ჩხუბობს, ჩნდება მაშინვე, როგორც კი ორივე ჩაიტვირთება.
• პროცედურებს. რამდენ ხანს გრძელდება განახლება სინამდვილეში, რომელი ფაილების კოპირებაა საჭირო, რა თანმიმდევრობით მიდის ყველაფერი. ამას გაიგებ ისე, რომ არავინ გიყურებს.

ის ვერ იჭერს:

• დატვირთვის პრობლემებს. ორი ტესტერი ორმოც მოთამაშეს ვერ გაიმეორებს. ცვლილება, რომელიც მხოლოდ დატვირთვისას ლაგავს, ყველა ტესტს გაივლის.
• დროსა და იღბალს. ავარიები, რომლებსაც მოვლენების კონკრეტული კომბინაცია სჭირდება - raid შენახვის დროს restart-ის დროს - მშვიდ სერვერზე იშვიათია.
• მოთამაშეების ქცევას. exploit-ს, რომელსაც ვინმე ახალი mod-ის პირველივე საათში იპოვის.

საცდელი სერვერი სიურპრიზებს ამცირებს; არ აქრობს. production-ის ყოველი ცვლილების წინ backup მაინც გააკეთე, როგორც აღწერილია სტატიაში თამაშის სერვერის backup-ის სტრატეგია.

ზომა და ღირებულება#

საცდელ სერვერს production-თან თანხვედრა არ სჭირდება. მას სჭირდება საკმარისი მეხსიერება იმავე სამყაროსა და mod-ების ჩასატვირთად და ძალიან ცოტა CPU, რადგან მასზე არავინ თამაშობს.

RE:NODE-ზე თამაშის ყველაზე პატარა გეგმები თვეში $3-იდან იწყება ყველაზე მსუბუქი თამაშებისთვის და მეტი ღირს მძიმეებისთვის (თითოეული თამაშის გვერდი თამაშის სერვერების განყოფილებაში მიმდინარე ფასებს აჩვენებს), ყველა გეგმას ერთი და იგივე პანელი აქვს და საფეხურის მიხედვით არაფერია შეზღუდული, ამიტომ პატარა საცდელ სერვერს იგივე კონსოლი, ფაილები, განრიგები და backup-ები აქვს, რაც დიდს. სერვერი, რომელსაც მხოლოდ ტესტირებისას რთავ, მაინც თავის თვიურ ფასს ღირს - საათობრივი გადახდა არ არსებობს - ამიტომ დანაზოგი პატარა საფეხურის არჩევიდან მოდის და არა გაჩერებული სერვერიდან.

ალტერნატივა, მსუბუქი ცვლილებისთვის, მეორე სერვერის საერთოდ არქონაა: აიღე ჩაკეტილი backup, სცადე ცვლილება production-ზე მშვიდ საათში და აღადგინე, თუ ჩავარდება. ეს ლეგიტიმური მიდგომაა პატარა ჯგუფისთვის. ის აღარ არის ასეთი, როცა სერვერი დატვირთულია, როცა ცვლილება ათეულობით mod-ს ეხება ან როცა წარუმატებელი განახლების გაუქმებას რამდენიმე წუთზე მეტი სჭირდება.

მომზადება: დააკოპირე production, შემდეგ შეგნებულად შეცვალე#

ერთგული ასლის შექმნის ყველაზე სწრაფი გზა რეალური სერვერის backup-იდანაა:

1. გააკეთე production-ის backup, იდეალურად შენახვის ბრძანების შემდეგ, რომ სამყარო თანმიმდევრული იყოს.
2. ჩამოტვირთე ის პანელიდან.
3. ახალ სერვერზე ატვირთე არქივი ფაილების მენეჯერით და ადგილზე გახსენი, ან ატვირთე საქაღალდეები SFTP-ით. SFTP და ფაილების მენეჯერი ორივეს აღწერს.
4. დააყენე startup ცვლადები production-ის შესაბამისად: თამაშის ვერსია ან branch, მეხსიერების ფლაგები, mod-ების სიის პარამეტრები.
5. პირველ ჩართვამდე გააკეთე შემდეგ სექციაში აღწერილი ცვლილებები. საცდელ სერვერს, რომელიც production-ის იდენტობით ირთვება, შეუძლია თავი საჯარო სერვერების სიაში გამოაცხადოს, production-ის token-ი დაისაკუთროს ან production-ის მონაცემთა ბაზაში ჩაწეროს.

შემდეგ ჩართე, დაადასტურე, რომ დაკოპირებულ სამყაროს ტვირთავს (ლოგი ასახელებს სამყაროს, რომელიც ჩატვირთა), და ისევ გააჩერე.

რა უნდა განსხვავდებოდეს#

ეს ყველაზე მნიშვნელოვანი ნაწილია, რადგან დაუდევარი ასლი რეალურ ზიანს იწვევს.

ზოგიერთი მათგანი მეტ დეტალს იმსახურებს.

სიაში გამოჩენა. Valheim-ს აქვს -public 0; Source-ის თამაშები sv_password-ს იღებს; Minecraft-ს შეუძლია სერვერების სიებს გარეთ დარჩეს, თუ არ არის რეკლამირებული და server.properties-ში დაყენებულია enable-status=false, რაც მას სიის ping-ებზე პასუხს უკრძალავს; Steam-ის თამაშების უმეტესობა browser-იდან იმალება, როცა პაროლით არის დაცული ან საკუთარ კონფიგში private-ზეა დაყენებული. პაროლი ყველგან მინიმუმია.

Steam-ის token-ები. Counter-Strike 2, Garry's Mod, Team Fortress 2 და სხვები იყენებს თამაშის სერვერის შესვლის token-ს (GSLT). token-ი ერთდროულად ერთ სერვერს შეუძლია გამოიყენოს, ამიტომ production-ის token-ით ჩართულმა საცდელმა სერვერმა შეიძლება რეალური სერვერი გათიშოს ან თავად ვერ დარეგისტრირდეს. შექმენი მეორე token-ი საცდელი სერვერისთვის; Steam-ის თამაშის სერვერის token-ები აღწერს, როგორ.

მონაცემთა ბაზები. ეს საშიშია. Minecraft-ის plugin-ები, როგორიცაა LuckPerms, CoreProtect და ეკონომიკის plugin-ები, შეიძლება გაზიარებულ ბაზაზე იყოს კონფიგურირებული; FiveM-ის framework-ები ყველაფერს ერთში ინახავს oxmysql-ით; Garry's Mod-ის DarkRP-ს შეუძლია გარე ბაზის გამოყენება. იგივე კავშირის პარამეტრებით დაკოპირებული საცდელი სერვერი რეალურ მონაცემებთანაა დაკავშირებული. საცდელ მოთამაშეს ადმინად აწევ და production-ზე აგიწევია. მიეცი საცდელ სერვერს საკუთარი ბაზა - RE:NODE-ზე თამაშის ყველა გეგმა მოიცავს მონაცემთა ბაზის სლოტს, რომელიც პანელში იქმნება საკუთარი ჰოსტით, მომხმარებლითა და პაროლით - და აღადგინე მასში production-ის მონაცემების ასლი. მონაცემთა ბაზის backup-ები და აღდგენა dump-სა და აღდგენას აღწერს.

Discord. დაკოპირებული DiscordSRV-ის კონფიგი ან webhook-ის URL საცდელი სერვერის ჩატს, სიკვდილებსა და კონსოლს შენი საზოგადოების რეალურ არხებში აქვეყნებს. მიმართე ის პირად საცდელ არხზე ან გამორთე.

კლიენტების სინქრონში შენარჩუნება#

საცდელი სერვერი თამაშისთვის, სადაც კლიენტებსაც სჭირდებათ mod-ები - Minecraft-ის modpack-ების უმეტესობა, Valheim gameplay mod-ებით, RimWorld-ის multiplayer - სასარგებლოა მხოლოდ მაშინ, თუ ტესტერებს აქვთ კლიენტი ზუსტად საცდელი სერვერის mod-ების ნაკრებით. ეს ნიშნავს კლიენტის ორ პროფილს ტესტერის მანქანაზე:

• Minecraft: ცალკე instance-ები Prism Launcher-ში, CurseForge აპში ან Modrinth აპში, თითო სერვერზე.
• Valheim: ცალკე პროფილები mod manager-ში, როგორიცაა r2modman ან Gale.
• Steam Workshop-ის თამაშები: უფრო რთულია, რადგან Workshop-ის გამოწერები ანგარიშზეა მიბმული. Workshop-ის mod-ის განახლების ტესტირება ჩვეულებრივ ნიშნავს განახლებული mod-ებით ტესტირებას და იმის მიღებას, რომ production მალე მიჰყვება.

ცალკე პროფილების გარეშე ტესტერი, რომელიც კლიენტს საცდელი სერვერისთვის განაახლებს, production-ზე ვერ შევა, სანამ ისიც არ განახლდება, რაც ზუსტად ის გადაბმაა, რისი თავიდან აცილებაც გინდოდა.

განახლების დღის პროცედურა#

საცდელი სერვერის არსებობისას თამაშის ან mod-ის განახლება ასე გამოიყურება:

1. განაახლე საცდელი სერვერი production-იდან, თუ ის ერთ კვირაზე მეტით მოძველებულია. გასული თვის სამყაროზე ტესტირება ამ თვის პრობლემებს გამოტოვებს.
2. გამოიყენე განახლება მხოლოდ საცდელ სერვერზე: თამაშის განახლება, შემდეგ მის შესაბამისი mod-ების განახლებები. Steam-ის თამაშებისთვის ეს ნიშნავს განახლების გაშვებას საცდელ სერვერზე, სანამ production ძველ build-ზე რჩება, ან საცდელი სერვერის გადართვას დეველოპერის beta branch-ზე რელიზამდე, სადაც ასეთი არსებობს. SteamCMD-ის ახსნა -beta-ს განიხილავს.
3. ჩართე და წაიკითხე ლოგი თავიდან ბოლომდე: ყველა mod-ი ჩაიტვირთა, exception-ები არ არის, სამყარო თავისი რეალური სახელით ჩაიტვირთა.
4. შედი და გამოსცადე, რაც შეიცვალა: განახლებული mod-ი, ტერიტორია, რომელიც ყველაზე სავარაუდოდ გატყდება, შენახვა და restart.
5. ზუსტად ჩაიწერე, რა შეცვალე: ფაილების სახელები, ვერსიები, კონფიგის გასაღებები. ეს არის სია, რომელსაც production-ზე გამოიყენებ.
6. გააკეთე production-ის ჩაკეტილი backup.
7. გამოიყენე სია production-ზე მშვიდ საათში, ჩართე და ლოგი იმავენაირად წაიკითხე.

განახლების დღე მთლიანად - patch notes, mod-ების ავტორები, განცხადებები - განხილულია სტატიაში თამაშის სერვერის განახლების დღის ჩამონათვალი.

როგორ არ დაშორდნენ ორი სერვერი ერთმანეთს#

საცდელი სერვერი სასარგებლოა მხოლოდ მანამ, სანამ production-ს ემთხვევა. ის პროგნოზირებადი გზებით შორდება: ვიღაც გათიშვის დროს production-ს პირდაპირ ასწორებს, ვიღაც mod-ს საცდელზე ცდის და არასოდეს შლის, თამაში ერთზე ახლდება და მეორეზე არა.

სამი ჩვევა ამას აცილებს:

• ცვლილებების ერთი სია. ყოველი ცვლილება ერთ თარიღიან ჟურნალში მიდის - ტექსტურ ფაილში სერვერის root-ში, მიმაგრებულ Discord-ის შეტყობინებაში, კონფიგების git-ის რეპოზიტორიაში. თუ სიაში არ იყო, არ მომხდარა.
• განაახლე და ნუ შეაკეთებ. როცა საცდელი დაშორდა, ნუ გაასწორებ მას ფაილ-ფაილ. ჩამოტვირთე production-ის ახალი backup და საცდელი სერვერი მისგან თავიდან ააწყვე, შემდეგ კი ხელახლა გამოიყენე იდენტობის ცვლილებები ზემოთ მოცემული ცხრილიდან.
• შეინახე ვერსიების manifest. ფაილი, რომელიც ჩამოთვლის თამაშის build-ს, mod loader-ის ვერსიას და თითოეული mod-ის ვერსიას, ორივე სერვერზე შენახული. ორი manifest-ის შედარებას ერთი წუთი სჭირდება; ორი mod-ების საქაღალდის თვალით შედარებას - ერთი საათი.

game        Valheim <build> (public branch)loader      BepInExPack_Valheim <version>mods        Jotunn <version>            PlantEverything <version>updated     2026-10-04 by Mira - PlantEverything <old> -> <new>

ჩაწერე რეალური build-ისა და ვერსიების ნომრები გაშვების ლოგიდან და თითოეული mod-ის გვერდიდან.

ვის აქვს წვდომა საცდელ სერვერზე#

საცდელი სერვერი სწორი ადგილია წვდომის გულუხვად გასაცემად. დეველოპერს, რომელიც production-ზე ფაილებზე წვდომას არასოდეს მიიღებდა, შეიძლება საცდელზე სრული წვდომა ჰქონდეს - ფაილები, SFTP, კონსოლი, განრიგები - რადგან ყველაზე ცუდი შედეგი მისი backup-იდან თავიდან აწყობაა. RE:NODE-ზე ეს ცალკე grant-ია ცალკე სერვერზე: მიეცი გუნდს სრული უფლებები საცდელ სერვერზე და მხოლოდ კონსოლი, ან არაფერი, production-ზე. subuser-ები და მინიმალური უფლებები როლების დაპროექტებას განიხილავს.

ერთადერთი, რაც საცდელ სერვერს არასოდეს უნდა ჰქონდეს, production-ის საიდუმლოებებია. თუ ვინმეს, ვისაც საცდელზე წვდომა აქვს, შეუძლია წაიკითხოს კონფიგი, რომელიც შეიცავს production-ის RCON პაროლს, production-ის ბაზის პაროლს ან ცოცხალი Discord bot-ის token-ს, გამიჯვნა დეკორატიულია.

FAQ#

მართლა მჭირდება საცდელი სერვერი პატარა ჯგუფისთვის?

vanilla სერვერისთვის ან სერვერის მხარის რამდენიმე plugin-ისთვის ჩვეულებრივ არა. ჩაკეტილი backup ყოველი ცვლილების წინ და მშვიდი საათი მის საცდელად საკმარისია. საცდელი სერვერი თავს ამართლებს, როცა mod-ების სია გრძელია, სამყარო ძვირფასია ან რამდენიმე ადამიანზე მეტი არის დამოკიდებული სერვერის მუშაობაზე.

შეუძლია საცდელ სერვერს production-ის იგივე Steam token-ის გამოყენება?

არა. თამაშის სერვერის შესვლის token-ს ერთდროულად ერთი სერვერი იყენებს, ამიტომ ორი სერვერი ერთმანეთს გათიშავდა. შექმენი მეორე token-ი საცდელი სერვერისთვის.

შემიძლია საცდელი სერვერი production-ის იმავე გეგმაზე გავუშვა?

თამაშის პანელზე არა, სადაც თითოეული გეგმა ერთი სერვერია საკუთარი ლიმიტებით. VDS-ზე ორივეს გაშვება შეგიძლია, როგორც ორი საქაღალდე, ორი პორტი და იდეალურად ორი მომხმარებელი, იმ ფასად, რომ ისინი მანქანის მეხსიერებასა და CPU-ს იზიარებენ.

რამდენად ხშირად უნდა განვაახლო საცდელი ასლი?

ყოველი მნიშვნელოვანი ტესტის წინ, თუ ასლი ერთ-ორ კვირაზე ძველია. ტესტი მოძველებულ სამყაროზე გამოტოვებს პრობლემებს იმაში, რაც მოთამაშეებმა მას შემდეგ ააშენეს.

უნდა დავაკოპირო გამოცდილი სამყარო უკან production-ზე?

არა. დააკოპირე შეცვლილი ფაილები - mod-ები, კონფიგები - და production-ის სამყარო ხელუხლებლად დატოვე. საცდელი სამყარო უფრო ძველია და შენს საცდელ ცვლილებებს შეიცავს; მისი უკან კოპირება მოთამაშეებს უკან აბრუნებს.