მოკლედ: სანამ სერვერის შექმნას ავტომატიზირებ, ჯერ ის ავტომატიზირე, როგორ დგება სერვერი ფეხზე ავარიის შემდეგ; tenant-ებს შორის იზოლაცია პროდუქტად მიიჩნიე და არა ერთ-ერთ ფუნქციად; ჩათვალე, რომ ყოველი ხელით შესასრულებელი ნაბიჯი საბოლოოდ support ticket-ად გადაიქცევა; როლები და უფლებები მეორე კლიენტამდე ააგე; ადამიანს მხოლოდ ისეთ საკითხზე გააღვიძებ, რომლის გამოსწორებაც მხოლოდ ადამიანს შეუძლია; backup კი ისე გაყიდე, რომ კლიენტმა ის დაინახოს და თვითონ დააჭიროს ღილაკს. RE:NODE-ის მართვისას ყველაფერი დანარჩენი, რაც ვისწავლეთ, თითქმის სრულად ამ ექვსის შედეგია.
პლატფორმა გაიზარდა 500+ კლიენტამდე და 1 200+ სერვერამდე: game, VDS, web, database და storage ჰოსტინგი, deploy-ის საშუალო დროით ხუთ წუთზე ნაკლები. cloud-ის მასშტაბებით ეს დიდი ფლოტი არ არის. ეს ზუსტად ის ზომაა, როცა ორმოცდაათ სერვერზე გაკეთებული ხრიკები აღარ არის იაფი და ელფოსტით გიგზავნის ანგარიშს.
ქვემოთ პრინციპები და ჩვენი შეხედულებებია და არა ისტორიები ბრძოლის ველიდან. სადაც მაგალითი გამოდგა, ცხადად ჰიპოთეტური ავირჩიეთ. თუ სხვებისთვის აწარმოებ სერვერებს - game community-ს, პატარა სააგენტოს, ჰოსტინგის გვერდით ბიზნესს - ამის უმეტესობა შენც გეხება, ათჯერ პატარა მასშტაბით.
ავტომატიზაცია ჯერ აღდგენას, მერე შექმნას#
ყველა ჰოსტინგ პროექტი სახალისო ნაწილით იწყება: ღილაკი, რომელიც სერვერს ქმნის. გადახდა გადის, container ჩნდება, port გამოიყოფა, password გენერირდება, კლიენტს წერილი მიდის. აშენება სასიამოვნოა და demo-შიც კარგად გამოიყურება.
ამავე დროს ეს პლატფორმის ყველაზე ნაკლებად მნიშვნელოვანი ავტომატიზაციაა. შექმნა ერთ სერვერზე ერთხელ ხდება. აღდგენა ხდება ყოველ ჯერზე, როცა პროცესი ვარდება, node-ი ირთვება თავიდან, დისკი ივსება ან განახლება ცუდად მიდის - სერვერის სიცოცხლის განმავლობაში ეს ბევრჯერ ხდება. თუ შექმნა ხელითაა, ყოველ შეკვეთაზე რამდენიმე წუთს კარგავ. თუ აღდგენაა ხელით, ღამეებს კარგავ.
წესი, რომელიც საბოლოოდ დავადგინეთ: სანამ ახალი ტიპის სერვერის გაყიდვას დავუშვებთ, პლატფორმამ მის შესახებ სამ კითხვას უნდა უპასუხოს ადამიანის გარეშე.
- უნდა მუშაობდეს თუ არა?
- მართლა მუშაობს თუ არა?
- თუ ეს ორი ერთმანეთს არ ემთხვევა, რა არის უსაფრთხო ნაბიჯი?
სწორედ მესამე კითხვაშია მთელი დიზაინი. "გადატვირთე" აშკარა პასუხია და ხშირად არასწორი. დავუშვათ, game server ვარდება გაშვებისას, რადგან mod გაფუჭებულია. მისი დაუსრულებლად გადატვირთვა მხოლოდ მოიხმარს CPU-ს საერთო node-ზე და ავსებს log-ს. ამიტომ აღდგენის ლოგიკას მეხსიერება სჭირდება: უნდა იცოდეს, რამდენჯერ სცადა უკვე, და როდის უნდა შეწყვიტოს და ვინმეს შეატყობინოს.
RE:NODE-ზე ეს გახდა watcher, რომელიც ყოველ ორ წუთში ამოწმებს, ხომ არ გაუარესდა uptime ან ხომ არ გავიდა სერვერი offline-ში. კლიენტის მიერ მოთხოვნილი გადატვირთვები არ ითვლება. საათში სამი არამოთხოვნილი გადატვირთვა სერვერის გვერდზე გაფრთხილებას აჩენს და ავტომატურად ხსნის ticket-ს; ექვსი სერვერს აჩერებს. რიცხვები ნაკლებად მნიშვნელოვანია, ვიდრე სქემა: ავტომატური აღდგენა, შემდეგ ავტომატური ესკალაცია, შემდეგ მკაცრი გაჩერება. თუ გინდა ამის კლიენტის მხრიდან ნახვა, დავწერეთ რატომ ირთვება შენი game server განუწყვეტლივ თავიდან.
აღდგენა კიდევ ერთს გაიძულებს: idempotency-ს. აღდგენის ქმედება განმეორდება - watcher-ის მიერ, ადამიანის მიერ, watcher-ის მეორე ასლის მიერ, რომელიც დაგავიწყდა, რომ გაშვებული იყო. "გაუშვი ეს სერვერი" ორჯერ გაშვებისას უსაფრთხო უნდა იყოს. "გამოყავი port" უნდა ამჩნევდეს, რომ port უკვე გამოყოფილია. ყოველი ჩვენი დაწერილი ქმედება, რომელიც idempotent არ იყო, საბოლოოდ ორჯერ გაეშვა და შედეგი ყოველთვის უარესი იყო, ვიდრე საერთოდ რომ არ გაშვებულიყო.
სასურველი მდგომარეობა და არა სკრიპტები#
მეორე პრინციპი პირველიდან გამომდინარეობს. თავიდან provisioning თანმიმდევრობა იყო: შექმენი container, მერე მიამაგრე storage, მერე გამოყავი port-ები, მერე ჩაწერე კონფიგურაცია. თანმიმდევრობის დაწერა მარტივია და აღდგენა - საშინელი, რადგან როცა მესამე ნაბიჯი ვარდება, გრჩება ნახევრად აგებული სერვერი და სკრიპტმა არ იცის, რომელი ნახევარია.
მოდელი, რომელსაც დღეს პირველივე დღიდან გამოვიყენებდით, არის სასურველი მდგომარეობა და reconciliation. მონაცემთა ბაზა ამბობს, რა უნდა არსებობდეს: ეს სერვერი, ამდენი მეხსიერება, ეს port-ები, ეს image, გაშვებული ან გაჩერებული. ციკლი ადარებს ამას იმას, რაც რეალურად არსებობს node-ზე, და უფსკრულს ხურავს ერთ-ერთ უსაფრთხო ნაბიჯით. შექმნა უბრალოდ reconciliation-ია არაფრიდან. აღდგენა - reconciliation გაფუჭებული მდგომარეობიდან. გეგმის ცვლილება, port-ის ცვლილება და მიგრაცია იგივე ციკლია სხვა მიზნით.
# The whole idea, minus the hard parts.def reconcile(server): want = desired_state(server) # from the database have = observed_state(server) # from the node for step in plan(have, want): # smallest safe steps first if not step.apply(): # every step is idempotent record_failure(server, step) return # retry on the next pass mark_converged(server)ამაში არაფერია ახალი - ასე ფიქრობენ Kubernetes, Terraform და კონფიგურაციის მართვის უმეტესობა. გაკვეთილი თავად ეს პატერნი არ არის, არამედ ის, რამდენად ადრე გჭირდება იგი. პირველ ნახევრად აგებულ სერვერს არ დაველოდებოდით. სკრიპტებზე აგებულ სისტემაში სასურველი მდგომარეობის მოგვიანებით ჩაშენება ბევრად ძვირია, ვიდრე მასთან დაწყება, რადგან იმ დროისთვის ყველა განსაკუთრებული შემთხვევა დამუშავებულია სკრიპტის სპეციალური ტოტით, რომელსაც არავინ უნდა შეეხოს.
tenant-ებს შორის იზოლაცია პროდუქტია#
კლიენტები container-ს არ ყიდულობენ. ისინი ყიდულობენ რწმენას, რომ მათი სერვერი ერთნაირად იქცევა, მეზობელი უქმად დგას თუ ცუდად დაწერილ plugin-ს ციკლში აგორებს. თუ ამას ვერ აძლევ, ფუნქციების სიაში დანარჩენს მნიშვნელობა არ აქვს.
სამი რესურსია, სადაც იზოლაცია წყვეტს, პლატფორმა სამართლიანად იგრძნობა თუ არა: CPU, მეხსიერება და დისკი. თითოეულზე ჩვენი მტკიცე შეხედულებები:
| რესურსი | რას გავაკეთებდით ყოველთვის | რატომ |
|---|---|---|
| CPU | მკაცრი ლიმიტი ნაყიდ წილზე | უფასო burst სასიამოვნოა, სანამ არ წაგართმევენ |
| მეხსიერება | შეჩერება ლიმიტზე, swap-ის გარეშე | swap ერთ tenant-ს ყველასთვის ანელებს |
| დისკი | quota თითო სერვერზე, აღსრულებადი | ერთი სავსე დისკი node-ის ავარია არ უნდა იყოს |
RE:NODE-ზე თითოეული სერვერი საკუთარი container-ია, CPU არის მკაცრი ლიმიტი ნაყიდ წილზე, ხოლო მეხსიერების ლიმიტზე kernel container-ს აჩერებს და ის სუფთად ირთვება თავიდან, swap-ის ნაცვლად - ეს upstream Pterodactyl-ის ნაგულისხმევის საპირისპიროა. ეს ბოლო ხალხს უკვირს. სერვერი, რომელიც ჩერდება და თავიდან ირთვება, იმ წუთში უარესად გამოიყურება, ვიდრე ის, რომელიც ნელა swap-ავს. პრაქტიკაში swap-ზე მყოფი სერვერი თან მიაქვს node-ზე ყველა სხვას დისკის I/O-ს, და ყველაზე მეტად იტანჯება კლიენტი, რომელსაც არაფერი დაუშავებია. მექანიკა განვიხილეთ წერილში Linux-ის swap და OOM killer, საერთო აპარატურის მხარე კი - გაზიარებული CPU და ხმაურიანი მეზობლები.
არასასიამოვნო ის არის, რომ მკაცრი იზოლაცია პლატფორმას ნაკლებ გულუხვად აჩენს. ჰოსტი, რომელიც უფასოდ გაძლევს 400% CPU-მდე burst-ს, benchmark-ში მოიგებს იმას, ვინც გზღუდავს იმ 200%-ზე, რაც გადაიხადე. მაგრამ burst მეზობლებისგან არის ნასესხები და ქრება ზუსტად მაშინ, როცა node დაკავებულია, ანუ ზუსტად მაშინ, როცა გჭირდება. ჩვენ გვირჩევნია უფრო პატარა რიცხვი გავყიდოთ, რომელიც პარასკევს საღამოს ცხრა საათზეც სიმართლეა.
იზოლაცია ეხება ყველაფერსაც, რაც რესურსი არ არის. credentials თითო სერვერზე და არა თითო ანგარიშზე. backup-ები იმ სერვერზე მიბმული, რომელმაც შექმნა. log-ები, საიდანაც სხვა tenant-ის გამოტანა ვერ გაჟონავს. port-ები გამოყოფილი და არა გამოცნობილი. თითოეული ეს ადგილია, სადაც მალსახმობი ერთ შუადღეს დაზოგავს და ბაგების კლასს ქმნის, როცა ერთი კლიენტი სხვის მონაცემებს ხედავს. ეს ერთადერთი კლასია, რომლისგანაც ჰოსტინგ პლატფორმა რეპუტაციულად ვერ გამოჯანმრთელდება.
ყოველი ხელით შესასრულებელი ნაბიჯი support ticket ხდება#
ეს პრინციპი კედელზე გამოვკიდებდით. კლიენტის გზის ნებისმიერი ნაბიჯი, რომელსაც ჩვენი მხრიდან ადამიანი სჭირდება, მასშტაბზე ticket იქნება. არა ხანდახან. ყოველ ჯერზე, გამრავლებული კლიენტების რაოდენობაზე, და ყველაზე ცუდ მომენტში მოვა.
არითმეტიკა მარტივი და სასტიკია. ნაბიჯი, რომელიც ხუთ წუთს ართმევს თანამშრომელს და ათიდან ერთ შეკვეთას სჭირდება, უწყინარად ჟღერს. რამდენიმე ასეულ კლიენტთან ეს არის ნახევარმუშაობის დღე, რომელიც შეფერხებებისგან შედგება. უარესი: კლიენტი ელოდება, სანამ ეს ხდება, ანუ ეს დაგვიანებაცაა, რომელსაც ამჩნევს.
როგორ ვისწავლეთ მისი გამოყენება: როცა ticket-ის კატეგორია რამდენიმეჯერ მეტჯერ ჩნდება, ეს support-ის პრობლემა აღარ არის - ეს გამოტოვებული ფუნქციაა. ticket არის bug report, დაწერილი ადამიანის მიერ, რომელმაც არ იცოდა, რომ ეს bug-ია. გავრცელებული შემთხვევები, დაახლოებით იმ თანმიმდევრობით, როგორც ჰოსტინგ პლატფორმა მათ აწყდება:
- "შეგიძლიათ port გამიხსნათ" - კლიენტს port-ების ეკრანი სჭირდება და არა ადამიანი.
- "შეგიძლიათ გუშინდელი backup აღადგინოთ" - backup-ებს ესაჭიროება restore ღილაკი, რომელსაც კლიენტი თვითონ დააჭერს.
- "ჩემს მეგობარს წვდომა სჭირდება, ოღონდ billing-ზე არა" - გჭირდება subuser-ები დეტალური უფლებებით.
- "არასწორი ფაილი ავტვირთე და სერვერი აღარ ირთვება" - გჭირდება ფაილების მენეჯერი და console, რომელიც რეალურ შეცდომას აჩვენებს.
- "ჩავარდა თუ ჩემთან არის პრობლემა" - გჭირდება status page და გრაფიკები თითო სერვერზე.
ყველა ხელით ნაბიჯის მოშორება შეუძლებელია. RE:NODE-ზე game, app, web და database სერვერები იქმნება გადახდისთანავე, ჩვეულებრივ ერთ წუთში, მაგრამ VDS ჯერ კიდევ ხელით მზადდება 24 საათის განმავლობაში. ეს შეგნებული კომპრომისია: მთლიან ვირტუალურ მანქანას საკუთარი ოპერაციული სისტემით მეტი გზა აქვს გაფუჭებისთვის, ვიდრე container-ს ცნობილი image-დან, ხოლო მოცულობა ავტომატიზაციას ჯერ არ ამართლებს. მთავარია, ეს კომპრომისი შეგნებულად მიიღო, დაყოვნება პროდუქტის გვერდზე დაწერო, რომ არავის გაუკვირდეს, და ციფრების შეცვლისას გადახედო.
შედეგი: პროდუქტის ინტერფეისი ძირითადად იმ support ticket-ების ინვენტარია, რომლებიც აღარ გიწევს. ახლა ჰოსტინგ პანელს რომ ვუყურებთ, მას ვკითხულობთ როგორც სიას იმისა, რისი ხელით კეთებითაც გუნდი დაიღალა.
RBAC პირველივე დღიდან და არა ორმოცდამეათე კლიენტიდან#
წვდომის კონტროლი ის ფუნქციაა, რომელსაც ყველა მოგვიანებით გეგმავს, და მოგვიანებით ყოველთვის გვიანია. მიზეზი უსაფრთხოების თეატრი არ არის. მიზეზი ის არის, რომ ნებისმიერი პანელის პირველი ვერსია მოდელირებას უკეთებს "მომხმარებელი ფლობს სერვერს", და როგორც კი ორი ადამიანი ერთ სერვერს ინაწილებს - game community სამი ადმინით, სააგენტო და მისი კლიენტი - ეს მოდელი ისე ინგრევა, რომ კოდის ყოველ ცხრილსა და უფლების შემოწმებაში აღწევს.
რას გავაკეთებდით პირველივე დღეს, თუნდაც ინტერფეისი ამას ჯერ არ აჩვენებდეს:
- უფლება არის ერთი ზმნა ერთი ტიპის ობიექტზე: სერვერის გაშვება, ფაილების წაკითხვა, ფაილების ჩაწერა, billing-ის ნახვა.
- როლი არის უფლებების დასახელებული ნაკრები.
- გუნდი არის ადამიანთა ნაკრები.
- grant აკავშირებს გუნდს სერვერთან როლით.
სწორედ ეს მოდელი ჩამოყალიბდა RE:NODE-ზე: როლები ინახავენ უფლებებს, გუნდები - ადამიანებს, grant-ები აკავშირებენ გუნდებს სერვერებთან; მოწვევა ბმულით, join code-ით ან ელფოსტით, დროში შეზღუდული წვდომა და თითო სერვერის activity log. ერთ კლიენტთან ერთი სერვერისთვის ზედმეტად რთულად გამოიყურება. ეს ერთადერთი ფორმაა, რომელიც რეალურ community-ებთან შეხვედრას გადაურჩა, სადაც გადამხდელი არ არის ის, ვინც სერვერს რთავს თავიდან, და ვინც რთავს თავიდან, არ უნდა შეეძლოს სამყაროს წაშლა.
ორი დეტალი უფრო მნიშვნელოვანია, ვიდრე ჩანს. დროში შეზღუდული წვდომა, რადგან წვდომის ყველაზე გავრცელებული შეცდომა ის კი არ არის, რომ ვინმეს ზედმეტს აძლევ, არამედ ის, რომ მოხსნა გავიწყდება. და activity log, რადგან როცა რამე ირღვევა, პირველი კითხვა ყოველთვის არის "ვინ გააკეთა", და log-ის გარეშე პასუხი კამათია. კლიენტის მხარის რჩევა არის subuser-ები და ყველაზე მცირე პრივილეგიები.
იგივე წესი თანამშრომლებზეც მოქმედებს. support-ს უნდა შეეძლოს სერვერის მდგომარეობის ნახვა მისი ფაილების წაკითხვის გარეშე, და გუნდში არავის უნდა სჭირდებოდეს node-ის root password ყოველდღიური სამუშაოსთვის. თუ თანამშრომლის წვდომა ან ყველაფერია ან არაფერი, ის იქნება ყველაფერი, ყველასთვის, სამუდამოდ.
მონიტორინგი, რომელიც სწორ რამეზე გაფრთხილებს#
მონიტორინგი, რომელიც ყველაფერზე გაფრთხილებს, გასწავლის მის იგნორირებას. მონიტორინგი, რომელიც არაფერზე გაფრთხილებს, დაფაა. სასარგებლო ვერსია ამ ორს შორისაა და ძირითადად გადაწყვეტილებაა იმაზე, ვინ უნდა გაიღვიძოს და რისთვის.
წესი, რომელზეც შევჩერდით: გაფრთხილება ადამიანამდე მიდის მხოლოდ მაშინ, როცა სამივე პირობა სრულდება. კლიენტებზე ზემოქმედებს ან მალე იმოქმედებს, პლატფორმა თავად ვერ აგვარებს და დილამდე ლოდინი ვითარებას აუარესებს. დანარჩენი ყველაფერი ticket-ია, გრაფიკი ან log-ის ხაზი.
| სიგნალი | ვინ იგებს | როდის |
|---|---|---|
| node მიუწვდომელია | მორიგე ადამიანი | დაუყოვნებლივ |
| node-ის დისკი სწრაფად ივსება | მორიგე ადამიანი | შევსებამდე |
| backup-ის დავალება ჩავარდა | staff-ის რიგი | შემდეგ სამუშაო საათში |
| ერთი სერვერი crash-loop-შია | კლიენტი, მერე ticket | ზღვრის მიღწევის შემდეგ |
| ერთი სერვერი 100% CPU-ზე | არავინ | მუშაობს ისე, როგორც გაიყიდა |
ბოლო სტრიქონზე ხალხი კამათობს. კლიენტის სერვერი თავისი CPU წილის 100%-ზე ნელია და არა გატეხილი, და პლატფორმამ ამის გამო არავის არ უნდა შეატყობინოს და არ უნდა შეაჩეროს. იგი აკეთებს ზუსტად იმას, რასაც ლიმიტი ამბობს. მასზე გაფრთხილება ქმნის ხმაურს, რომელიც მართლაც მნიშვნელოვან სიგნალებს მალავს.
მეორე წესი: გააფრთხილე სიმპტომსა და ტრენდზე და არა მხოლოდ ზღვარზე. დავუშვათ, node-ის დისკი ღამის სამ საათზე 85%-ზეა. ეს თავისთავად გადაუდებელი არ არის. თუ შუაღამეს 60% იყო, ძალიან გადაუდებელია. ცვლილების სიჩქარის შემოწმება დაიჭერს გაუთავებელ log-ს ან backup-ს, რომელმაც ძველების წაშლა დაივიწყა, ბევრად ადრე, ვიდრე ფიქსირებული ზღვარი, და არ ამოქმედდება node-ზე, რომელიც თვეა 85%-ზე მშვიდად დგას.
მესამე: ყოველ გაფრთხილებას runbook-ის ბმული აქვს, თუნდაც მოკლე. ნახევრად მძინარე ადამიანი კარგად არ ფიქრობს, და გაფრთხილება "node-ის დისკი ივსება" და სამი ხაზი იმის შესახებ, საიდან დაიწყო ძებნა, უფრო ღირს, ვიდრე ლამაზი დაფა. ამის ზოგადი ვერსია დავწერეთ წერილში მონიტორინგი, რომელიც რაღაცას გეუბნება.
გაფრთხილება, რომელზეც ადამიანს არაფრის გაკეთება არ სჭირდება, ალერტი არ არის. ეს ჩვევაა, რომელსაც ალერტების იგნორირებას უყალიბებ.
backup-ები პროდუქტის ფუნქციაა და არა ops-ის სამუშაო#
პლატფორმების უმეტესობა backup-ს აღიქვამს როგორც რაღაცას, რასაც ოპერაციები ჩუმად აკეთებს ფონზე. მიგვაჩნია, რომ ჰოსტინგ კომპანიისთვის ეს არასწორია, რადგან backup, რომელსაც კლიენტი ვერ ხედავს, არის backup, რომელსაც კლიენტი არ ენდობა, ხოლო backup, რომელიც კლიენტს თავად არ შეუძლია აღადგინოს, ყველაზე ცუდ მომენტში ticket-ად იქცევა.
ამიტომ რეალურად ორი backup სისტემაა, სხვადასხვა დანიშნულებით:
- პლატფორმის backup-ები იცავენ ბიზნესს: ყოველღამე, დამოუკიდებელ აპარატურაზე კოპირებული, გადამოწმებული, გრაფიკით გასუფთავებული. კლიენტები მათ არასოდეს ეხებიან. ისინი არსებობენ იმ დღისთვის, როცა node კვდება.
- კლიენტის backup-ები იცავენ კლიენტს საკუთარი თავისგან: slot-ები ყველა გეგმაზე, იქმნება მოთხოვნით ან გრაფიკით, აღდგება ღილაკით, ჩამოიტვირთება, შესაძლებელია rotation-ისგან დაბლოკვა და ინახება იმ მანქანის გარეთ, რომელსაც იცავს.
კლიენტისკენ მიმართული სწორედ ის არის, რომელიც support-ის მოცულობას ცვლის. ჰოსტინგ პლატფორმაზე მონაცემთა დაკარგვის უმეტესობა აპარატურის გაუმართაობა არ არის. ეს არის კლიენტი, რომელიც აყენებს plugin-ს, რომელიც სამყაროს ჭამს, ან შლის არასწორ საქაღალდეს, ან აახლებს თამაშის ვერსიას, რომელსაც ძველი save-ის წაკითხვა არ შეუძლია. restore ღილაკი, რომელსაც კლიენტი შუაღამეს ვინმეს ჰკითხვის გარეშე აჭერს, უფრო ღირს, ვიდრე ჩვენი მხრიდან ნებისმიერი რაოდენობის რედუნდანტობა.
ორი დიზაინის გადაწყვეტილება, რომლის გამეორებაც ღირს. დაბლოკვა: შესაძლებლობა, რომ ერთი backup დაამაგრო და rotation მას არასოდეს წაშლის, რადგან სასურველი backup ხშირად პრობლემის დაწყებამდელია, ანუ ზუსტად ის, რომლის წაშლასაც rotation აპირებს. და პატიოსანი წაშლა: RE:NODE-ზე სერვერის წაშლა შლის მის backup-ებსაც, დაბლოკილებიც ჩათვლით. ზოგს ეს უკვირს, მაგრამ backup, რომელიც ცოცხლობს იმ სერვერზე დიდხანს, რომელსაც ეკუთვნის, მონაცემია, რომელსაც უმიზეზოდ ინახავ, და ეს ღიად უნდა ეწეროს და არა აღმოჩნდეს.
ქვეშ მდებარე პრინციპი ჩვენი ცნობილი ფრაზაა: backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. გადამოწმება ავტომატური უნდა იყოს, რადგან ადამიანი, რომელიც აღდგენას ხელით ამოწმებს, ამას შეწყვეტს იმ კვირას, როცა დაკავდება. მექანიკას განიხილავს backup-ები, რომლებიც მართლა აღდგება და აღდგენის ტესტი სანამ საჭირო გახდება.
ინციდენტზე რეაგირება ძირითადად მომზადებაა#
თავად ინციდენტი ინციდენტზე რეაგირების ყველაზე პატარა ნაწილია. ნაწილები, რომლებიც გადაწყვეტენ, როგორ წარიმართება, კვირებით ადრე ხდება: შეგიძლია თუ არა თქვა, რომელი კლიენტებია დაზარალებული, შეგიძლია თუ არა მათ სწრაფად შეატყობინო და შეგიძლია თუ არა შემდეგ გაარკვიო, რა მოხდა სინამდვილეში.
რაზეც ამ ზომის ნებისმიერ პლატფორმაზე დავაჟინებდით:
- გზა "node X არაჯანსაღია"-დან "ეს კლიენტები არიან დაზარალებულები"-მდე ერთი მოთხოვნით. თუ ამას spreadsheet სჭირდება, status-ის განახლება დაგვიანებული და ბუნდოვანი იქნება.
- status page, რომელსაც ინციდენტის დროს ადამიანი ანახლებს, დანარჩენ დროს კი სისტემა, და რომელიც განთავსებულია სადმე, სადაც ის იმავე ბედს არ იზიარებს, რასაც აღწერს.
- ყოველი ავტომატური ქმედება ჩაწერილია event log-ში: რა, როდის, რატომ და რომელმა კომპონენტმა გააკეთა. როცა აღდგენის ციკლი რამეს თავიდან რთავს, ამის ახსნა კვირის შემდეგაც უნდა შეიძლებოდეს.
- მოკლე წერილობითი ანალიზი ყველაფერზე, რაც კლიენტებმა შეამჩნიეს, რომელიც ფოკუსირდება იმაზე, რა დაუშვა სისტემამ და არა იმაზე, ვინ რა დააჭირა.
ბოლო უფრო კულტურას ეხება, ვიდრე ინსტრუმენტებს. თუ ანალიზი ადამიანს ეძებს, ადამიანები თითქმის მომხდარი შემთხვევების შეტყობინებას წყვეტენ, ხოლო ასეთი შემთხვევები ერთადერთი უფასო გაკვეთილია.
რას გავაკეთებდით სხვაგვარად#
პლატფორმა ხვალ თავიდან რომ იწყებოდეს, იმის ცოდნით, რაც ახლა ვიცით, ამ ცვლილებებს შევთავაზებდით. არცერთი დრამატული არ არის. ყველა მათგანი პირველ დღეს უფრო იაფია, ვიდრე ათასე დღეს.
სასურველი მდგომარეობა პირველი commit-იდან
ეს ზემოთ განვიხილეთ, მაგრამ ყველაზე დიდია. სკრიპტად დაწერილი ყოველი provisioning ნაბიჯი მომავალი მიგრაციის პროექტია. თავიდანვე ერთ reconciliation ციკლს გავაკეთებდით და შექმნას, ცვლილებასა და აღდგენას ერთ კოდის გზად ვაქცევდით.
ლიმიტებისა და quota-ების ერთი ადგილი
ლიმიტები ბოლოს მიმოფანტული აღმოჩნდება: მეხსიერება container-ის აღწერაში, დისკი quota ინსტრუმენტში, backup slot-ები billing სისტემაში, port-ები გამოყოფის ცხრილში. თითოეული თავისთავად სწორია, მაგრამ ერთად ისინი განსხვავდებიან. გეგმის ყველა ლიმიტს ერთ ჩანაწერში შევინახავდით, რომელსაც ყველა კომპონენტი კითხულობს, რომ გეგმის შეცვლა ერთი ჩაწერა იყოს და არა ხუთი.
event log როგორც პირველი რანგის პროდუქტი
audit და event log-ს dashboard-მდე გავაკეთებდით. მას support კითხულობს, მას კლიენტის activity ხედი აჩვენებს, მასზეა დამოკიდებული ინციდენტების ანალიზი და ის გჭირდება ნებისმიერ compliance კითხვაზე. მოგვიანებით დამატება ნიშნავს ისტორიის გამოცნობას, რომელიც არ ჩაგიწერია.
მდებარეობა როგორც მონაცემი და არა დაშვება
პლატფორმა, რომელიც ერთ ადგილას მუშაობს, ამას კოდში არ უნდა ვარაუდობდეს. მდებარეობას თავიდანვე მოვახდენდით node-ისა და სერვერის თვისებად, რომ მეორის დამატება კონფიგურაციის ცვლილება იყოს და არა გადაწერა. არა იმიტომ, რომ მეორე იგეგმება, არამედ იმიტომ, რომ ხისტად ჩაწერილი დაშვებები ძვირი ტიპისაა.
აღდგენის გზის გრაფიკით ტესტირება
აღდგენის კოდი ის კოდია, რომელიც ყველაზე იშვიათად სრულდება და ყველაზე მნიშვნელოვანია, და ეს ცუდი კომბინაციაა. გრაფიკით შეგნებულად გავაფუჭებდით სატესტო სერვერს - გავაჩერებდით მის პროცესს, შევავსებდით დისკს, დავაზიანებდით კონფიგურაციას - და შევამოწმებდით, რომ პლატფორმა ამჩნევს და სწორად იქცევა, ისევე, როგორც restore-ები უნდა გამოიცადოს გრაფიკით. თუ აღდგენა მხოლოდ რეალური ავარიების დროს სრულდება, ის მხოლოდ რეალური ავარიების დროს გამოიცდება.
რას შევინარჩუნებდით ზუსტად ისე, როგორც არის
მკაცრი რესურსის ლიმიტები. watcher, რომელიც ესკალაციას აკეთებს და არა უსასრულოდ რთავს თავიდან. კლიენტის მიერ დასაჭერი backup-ები. დეტალური როლები. პანელი, რომელიც აჩვენებს რეალურ console-ის გამოტანას და არა მეგობრულ შეჯამებას. თითოეულმა მათგანმა პირველ დღეს პლატფორმა ნაკლებ გულუხვად აჩვენა და ბევრად მეტი დაზოგა, ვიდრე დაჯდა.
ამ ყველაფრის უკან ერთი ჩვევაა: დააპროექტო ჯერ ჩავარდნისთვის. ეს მაშინაც მართალია, როცა კოდის დიდ ნაწილს AI coding agent-ები წერენ: agent-ს შეუძლია შექმნის გზა ერთ შუადღეში დაწეროს, ხოლო აღდგენის გზა მაინც ის ნაწილია, რომელზეც ადამიანმა ღრმად უნდა იფიქროს.
FAQ#
რა არის multi-tenant ჰოსტინგ პლატფორმის მართვის ყველაზე რთული ნაწილი?
სამართლიანობა დატვირთვისას. სერვერების შექმნა მარტივია; იმის უზრუნველყოფა, რომ ერთი tenant-ის ცუდი დღე ყველას ცუდ დღედ არ იქცეს, მოითხოვს მკაცრ ლიმიტებს CPU-ზე, მეხსიერებასა და დისკზე და მზადყოფნას, ნაკლებ გულუხვად გამოიყურებოდე, ვიდრე ჰოსტები, რომლებიც კლიენტებს მეზობლებისგან სესხების საშუალებას აძლევენ.
პატარა ჰოსტმა ჯერ provisioning უნდა ავტომატიზიროს თუ აღდგენა?
აღდგენა. provisioning ერთხელ სრულდება თითო სერვერზე და ნელი ხელით ვერსია წუთებს ჰკარგავს. აღდგენა სრულდება ყოველთვის, როცა რამე ირღვევა, ჩვეულებრივ ღამით, და ხელით ვერსია გიკარგავს ძილს და კლიენტების ნდობას. სანამ შეკვეთის ღილაკს მყისიერს გახდი, დარწმუნდი, რომ პლატფორმას შეუძლია აღმოჩენა, ხელახლა ცდა და ესკალაცია.
ღირს თუ არა RBAC პლატფორმისთვის, რომელსაც მხოლოდ რამდენიმე კლიენტი ჰყავს?
დიახ, ყოველ შემთხვევაში მონაცემთა მოდელში. გაზიარებული წვდომის მოგვიანებით მიმაგრება "ერთი მომხმარებელი ფლობს ერთ სერვერს" დიზაინზე კოდის ყველა უფლების შემოწმებას ეხება. შეგიძლია როლები და გუნდები ინტერფეისში დამალო, სანამ კლიენტები არ მოითხოვენ, მაგრამ ცხრილები თავიდანვე უნდა არსებობდეს.
რამდენი გაფრთხილება უნდა აღწევდეს ადამიანამდე?
ძალიან ცოტა. გააფრთხილე მხოლოდ მაშინ, როცა კლიენტები დაზარალებულები არიან ან მალე იქნებიან, სისტემა თავად ვერ აგვარებს და ლოდინი ვითარებას აუარესებს. node-ის ჩავარდნა და სწრაფად შევსებადი დისკი აკმაყოფილებს. backup-ის წარუმატებლობა დილის ticket-ია. ერთი სერვერი სრულ CPU-ზე ალერტი საერთოდ არ არის.
რატომ ვაჩერებთ სერვერს მეხსიერების ლიმიტზე და არა swap-ს ვუშვებთ?
რადგან საერთო აპარატურაზე swap ერთი tenant-ის მეხსიერების პრობლემას ყველას დისკის პრობლემად აქცევს. სუფთა გადატვირთვა ხილულია და კლიენტს შეუძლია გამოასწოროს; node, რომელიც ჩუმად თრაშინგობს, მათ ზარალს აყენებს, ვინც არაფერი დაუშავებია, და ბევრად უფრო რთული დიაგნოსტიკაა.
