გამოშვების ამბავი, რომელმაც ყველაფერზე იმოქმედა

რეალობის მტრები 12f-2-ით

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

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

ფონი + რა ფუნქციონირებაა ეს?

ჩვენ ვაშენებთ ღრუბლოვან პლატფორმას Mail.ru Cloud Solutions (MCS), სადაც ვმუშაობ ტექნიკურ დირექტორად. ახლა კი დროა დავამატოთ IAM (იდენტობის და წვდომის მენეჯმენტი) ჩვენს პლატფორმას, რომელიც უზრუნველყოფს ყველა მომხმარებლის ანგარიშის, მომხმარებლის, პაროლების, როლების, სერვისების და სხვათა ერთიან მართვას. რატომ არის საჭირო ღრუბელში, აშკარა კითხვაა: მასში ინახება მომხმარებლის ყველა ინფორმაცია.

ჩვეულებრივ, ასეთი ნივთების აშენება იწყება ნებისმიერი პროექტის დასაწყისში. მაგრამ ისტორიულად ყველაფერი ოდნავ განსხვავებული იყო MCS-ში. MCS აშენდა ორ ნაწილად:

• Openstack საკუთარი Keystone ავტორიზაციის მოდულით,
• Hotbox (S3 საცავი) Mail.ru Cloud პროექტზე დაფუძნებული,

რომლის ირგვლივ შემდეგ გამოჩნდა ახალი სერვისები.

არსებითად, ეს იყო ორი განსხვავებული ტიპის ავტორიზაცია. გარდა ამისა, ჩვენ გამოვიყენეთ Mail.ru-ს ცალკეული განვითარება, მაგალითად, ზოგადი Mail.ru პაროლის შენახვა, ასევე თვითნაწერი openid კონექტორი, რომლის წყალობითაც SSO (ბოლოდან ბოლომდე ავტორიზაცია) იყო უზრუნველყოფილი ჰორიზონტის პანელში. ვირტუალური მანქანების (მშობლიური OpenStack UI).

ჩვენთვის IAM-ის შექმნა ნიშნავდა ამ ყველაფრის ერთ სისტემაში დაკავშირებას, სრულიად ჩვენს საკუთარს. ამავდროულად, ჩვენ გზაში არ დავკარგავთ არანაირ ფუნქციონირებას, მაგრამ შევქმნით მომავლის საფუძველს, რომელიც საშუალებას მოგვცემს გამჭვირვალედ დავხვეწოთ ის რეფაქტორაციის გარეშე და გავაფართოვოთ ფუნქციონალური თვალსაზრისით. ასევე დასაწყისში, მომხმარებლებს ჰქონდათ სერვისებზე წვდომის მისაბაძი მაგალითი (ცენტრალური RBAC, როლებზე დაფუძნებული წვდომის კონტროლი) და სხვა წვრილმანები.

ამოცანა არატრივიალური აღმოჩნდა: python და perl, რამდენიმე backends, დამოუკიდებლად დაწერილი სერვისები, რამდენიმე დეველოპერული გუნდი და ადმინი. და რაც მთავარია, საბრძოლო წარმოების სისტემაში ათასობით ცოცხალი მომხმარებელია. ეს ყველაფერი უნდა დაეწერა და, რაც მთავარია, მსხვერპლის გარეშე გაეშვა.

რის გამოტანას ვაპირებთ?

ძალიან უხეშად რომ ვთქვათ, დაახლოებით 4 თვეში მოვამზადეთ შემდეგი:

• ჩვენ შევქმენით რამდენიმე ახალი დემონი, რომლებმაც შეაგროვეს ფუნქციები, რომლებიც ადრე მუშაობდნენ ინფრასტრუქტურის სხვადასხვა ნაწილში. დანარჩენ მომსახურებას დაენიშნა ახალი ბექენდი ამ დემონების სახით.
• ჩვენ დავწერეთ პაროლებისა და გასაღებების საკუთარი ცენტრალური საცავი, რომელიც ხელმისაწვდომია ჩვენი ყველა სერვისისთვის, რომელიც თავისუფლად შეიძლება შეიცვალოს საჭიროებისამებრ.
• ჩვენ დავწერეთ 4 ახალი ბექენდი Keystone-სთვის ნულიდან (მომხმარებლები, პროექტები, როლები, როლების დავალებები), რომელმაც, ფაქტობრივად, შეცვალა მისი მონაცემთა ბაზა და ახლა მოქმედებს როგორც ერთიანი საცავი ჩვენი მომხმარებლის პაროლებისთვის.
• ჩვენ ვასწავლეთ ყველა ჩვენს Openstack სერვისს წასვლა მესამე მხარის პოლიტიკის სერვისზე მათი პოლიტიკისთვის, ნაცვლად იმისა, რომ წაიკითხონ ეს წესები ადგილობრივად თითოეული სერვერიდან (დიახ, ასე მუშაობს Openstack ნაგულისხმევად!)

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

როგორ გავაფართოვოთ ასეთი ცვლილებები და არ გააფუჭოთ? ჯერ გადავწყვიტეთ, ცოტა მომავალს შეგვეხედა.

გავრცელების სტრატეგია

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

დიგრესია: რა არის rollout?

<სიფრთხილე, ფილოსოფია>

ყველა IT სპეციალისტს შეუძლია მარტივად უპასუხოს რა არის rollout. თქვენ დააინსტალირეთ CI/CD და ყველაფერი ავტომატურად მიეწოდება მაღაზიას. 🙂

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

და მთელი სურათი ასეთია. Rollout შედგება ოთხი ძირითადი ასპექტისგან:

1. კოდის მიწოდება, მონაცემთა მოდიფიკაციის ჩათვლით. მაგალითად, მათი მიგრაცია.
2. კოდის უკან დაბრუნება არის შესაძლებლობა დაბრუნდეთ თუ რამე არასწორედ მოხდება. მაგალითად, სარეზერვო ასლების შექმნის გზით.
3. ყოველი გაშვების/დაბრუნების ოპერაციის დრო. თქვენ უნდა გესმოდეთ პირველი ორი წერტილის ნებისმიერი ოპერაციის დრო.
4. დაზარალდა ფუნქციონირება. აუცილებელია შეფასდეს როგორც მოსალოდნელი დადებითი, ასევე შესაძლო უარყოფითი ეფექტები.

ყველა ეს ასპექტი მხედველობაში უნდა იქნას მიღებული წარმატებული გაშვებისთვის. ჩვეულებრივ ფასდება მხოლოდ პირველი, ან საუკეთესო შემთხვევაში მეორე პუნქტი და შემდეგ განლაგება განიხილება წარმატებულად. მაგრამ მესამე და მეოთხე კიდევ უფრო მნიშვნელოვანია. რომელ მომხმარებელს მოეწონება, თუ გაშვებას ერთი წუთის ნაცვლად 3 საათი დასჭირდა? ან თუ რაიმე არასაჭირო გავლენას მოახდენს გაშვების დროს? ან ერთი სერვისის შეფერხება გამოიწვევს არაპროგნოზირებად შედეგებს?

აქტი 1..n, მომზადება გათავისუფლებისთვის

თავიდან ვფიქრობდი მოკლედ აღმეწერა ჩვენი შეხვედრები: მთელი გუნდი, მისი ნაწილები, დისკუსიების გროვა ყავის წერტილებზე, არგუმენტები, ტესტები, ტვინის შტორმები. მაშინ ვიფიქრე, რომ ეს ზედმეტი იქნებოდა. განვითარების ოთხი თვე ყოველთვის შედგება ამისგან, განსაკუთრებით მაშინ, როდესაც თქვენ არ წერთ რაღაცას, რომლის მიწოდებაც მუდმივად შეიძლება, არამედ ერთ დიდ ფუნქციას ცოცხალი სისტემისთვის. რაც გავლენას ახდენს ყველა სერვისზე, მაგრამ მომხმარებლებისთვის არაფერი არ უნდა შეიცვალოს, გარდა „ერთი ღილაკის ვებ ინტერფეისში“.

ჩვენი გაგება იმის შესახებ, თუ როგორ უნდა გამოვიყენოთ, შეიცვალა ყოველი ახალი შეხვედრიდან და საკმაოდ მნიშვნელოვნად. მაგალითად, ჩვენ ვაპირებდით მთელი ჩვენი ბილინგის მონაცემთა ბაზის განახლებას. მაგრამ ჩვენ გამოვთვალეთ დრო და მივხვდით, რომ შეუძლებელი იყო ამის გაკეთება გონივრულ დროში. თითქმის დამატებითი კვირა დაგვჭირდა ბილინგის მონაცემთა ბაზის გატეხვასა და დაარქივებას. და როდესაც მოსალოდნელი გაშვების სიჩქარე ჯერ კიდევ არ იყო დამაკმაყოფილებელი, ჩვენ შევუკვეთეთ დამატებითი, უფრო მძლავრი აპარატურა, სადაც მთელი ბაზა გადაიწია. ეს არ არის ის, რომ ჩვენ არ გვინდოდა ამის გაკეთება ადრე, მაგრამ ამჟამინდელმა საჭიროებამ არ დაგვიტოვა არჩევანი.

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

იმავდროულად, ტექნიკური მხარდაჭერის ბიჭებმა ჩაატარეს საკუთარი დამოუკიდებელი ექსპერიმენტები, რათა დაეწერათ ინსტრუქციები კლიენტებისთვის კავშირის მეთოდებზე, რომლებიც უნდა შეიცვალოს გაშვების შემდეგ. იმუშავეს მომხმარებლის UX-ზე, მოამზადეს ინსტრუქციები და გაუწიეს პირადი კონსულტაციები.

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

Ამიტომაც…

საბოლოო მოქმედება, გაშვებამდე

...გამოშვების დროა.

როგორც ამბობენ, მხატვრული ნაწარმოების დასრულება შეუძლებელია, მხოლოდ მასზე მუშაობა დასრულდება. თქვენ უნდა ეცადოთ ნებისყოფას, გესმოდეთ, რომ ყველაფერს ვერ იპოვით, მაგრამ გჯეროდეთ, რომ თქვენ გააკეთეთ ყველა გონივრული ვარაუდი, გათვალისწინებული ყველა შესაძლო შემთხვევისთვის, დახურეთ ყველა კრიტიკული შეცდომა და ყველა მონაწილემ გააკეთა ყველაფერი, რაც შეეძლო. რაც უფრო მეტ კოდს გამოაქვეყნებთ, მით უფრო რთულია ამაში საკუთარი თავის დარწმუნება (გარდა ამისა, ყველას ესმის, რომ ყველაფრის განჭვრეტა შეუძლებელია).

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

1. იმოქმედეთ (ჩვენთვის წმინდა, ყველაზე ძვირფასი) მომხმარებლის ინფრასტრუქტურაზე,
2. ფუნქციონალობა: ჩვენი სერვისის გამოყენება გაშვების შემდეგ უნდა იყოს იგივე, რაც მანამდე.

მოძრავი გარეთ

ორი roll, 8 არ ჩაერიოთ

ჩვენ ვიღებთ შეფერხებას მომხმარებლის ყველა მოთხოვნაზე 7 საათის განმავლობაში. ამ დროისთვის ჩვენ გვაქვს როგორც გაშვების გეგმა, ასევე დაბრუნების გეგმა.

• თავად გაშვებას დაახლოებით 3 საათი სჭირდება.
• 2 საათი ტესტირებისთვის.
• 2 საათი - რეზერვი ცვლილებების შესაძლო დაბრუნებისთვის.

თითოეული მოქმედებისთვის შედგენილია განტის სქემა, რამდენი დრო სჭირდება, რა ხდება თანმიმდევრულად, რა კეთდება პარალელურად.

განლაგებული Gantt სქემის ნაწილი, ერთ-ერთი ადრეული ვერსია (პარალელური შესრულების გარეშე). ყველაზე ღირებული სინქრონიზაციის ინსტრუმენტი

ყველა მონაწილეს აქვს განსაზღვრული როლი განლაგებაში, რა ამოცანებს ასრულებენ და რაზე არიან პასუხისმგებელი. ჩვენ ვცდილობთ, რომ თითოეული ეტაპი ავტომატიზირებამდე მივიყვანოთ, გავაბრტყელოთ, გავაბრუნოთ, შევაგროვოთ გამოხმაურება და ისევ გავაფართოვოთ.

მოვლენების ქრონიკა

ასე რომ, კვირას, 15 აპრილს, საღამოს 29 საათზე 10 ადამიანი მივიდა სამსახურში. ძირითადი მონაწილეების გარდა, ზოგიერთი მოვიდა უბრალოდ გუნდის მხარდასაჭერად, რისთვისაც განსაკუთრებული მადლობა მათ.

ასევე აღსანიშნავია, რომ ჩვენი გასაღების ტესტერი შვებულებაშია. ტესტირების გარეშე გაშვება შეუძლებელია, ჩვენ ვიკვლევთ ვარიანტებს. კოლეგა თანახმაა გამოგვცადოს შვებულებიდან, რისთვისაც იგი იღებს უზარმაზარ მადლიერებას მთელი გუნდისგან.

00:00. გაჩერდი
ჩვენ ვწყვეტთ მომხმარებლის მოთხოვნას, ვკიდებთ აბრას ტექნიკურ სამუშაოზე. მონიტორინგი ყვირის, მაგრამ ყველაფერი ნორმალურია. ჩვენ ვამოწმებთ, რომ არაფერი დაეცა, გარდა იმისა, რაც უნდა დაეცა. და ჩვენ ვიწყებთ მუშაობას მიგრაციაზე.

ყველას აქვს დაბეჭდილი გავრცელების გეგმა წერტილი-პუნქტით, ყველამ იცის ვინ რას და რომელ მომენტში აკეთებს. ყოველი მოქმედების შემდეგ ვამოწმებთ ვადებს, რომ არ გადავაჭარბოთ მათ და ყველაფერი გეგმის მიხედვით მიდის. ისინი, ვინც უშუალოდ მიმდინარე ეტაპზე არ მონაწილეობენ, ემზადებიან ონლაინ სათამაშოს (Xonotic, ტიპის 3 quacks) გამოშვებით, რათა არ შეაწუხონ თავიანთი კოლეგები. 🙂

02:00 საათი. შემოვიდა
სასიამოვნო სიურპრიზი - ჩვენ ვასრულებთ გაშვებას ერთი საათით ადრე, ჩვენი მონაცემთა ბაზების და მიგრაციის სკრიპტების ოპტიმიზაციის გამო. გენერალური ტირილი, "გადავიდა!" ყველა ახალი ფუნქცია წარმოებაშია, მაგრამ ჯერჯერობით მხოლოდ ჩვენ შეგვიძლია მათი ნახვა ინტერფეისში. ყველა გადადის ტესტირების რეჟიმში, ახარისხებს მათ ჯგუფებად და იწყებს ნახოს რა მოხდა ბოლოს.

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

02:30. ორი დიდი პრობლემა ოთხი თვალის წინააღმდეგ
ჩვენ ვხვდებით ორ დიდ პრობლემას. ჩვენ მივხვდით, რომ მომხმარებლები ვერ ნახავდნენ ზოგიერთ დაკავშირებულ სერვისს და პრობლემები წარმოიქმნებოდა პარტნიორის ანგარიშებთან დაკავშირებით. ორივე განპირობებულია არასრულყოფილი მიგრაციის სკრიპტებით ზოგიერთი ზღვარის შემთხვევისთვის. ახლა უნდა გამოვასწოროთ.

ჩვენ ვწერთ შეკითხვებს, რომლებიც ამას ჩაწერენ, მინიმუმ 4 თვალით. ჩვენ ვამოწმებთ მათ წინასწარ წარმოების დროს, რათა დავრწმუნდეთ, რომ ისინი მუშაობენ და არ არღვევენ არაფერს. შეგიძლიათ გააფართოვოთ. ამავდროულად, ჩვენ ვაწარმოებთ რეგულარულ ინტეგრაციის ტესტირებას, რომელიც ავლენს კიდევ რამდენიმე საკითხს. ისინი ყველა პატარაა, მაგრამ ასევე საჭიროებს შეკეთებას.

03:00. -2 პრობლემა +2 პრობლემა
წინა ორი დიდი პრობლემა მოგვარებულია და თითქმის ყველა უმნიშვნელო პრობლემაც. ყველა, ვინც არ არის დაკავებული შესწორებებით, აქტიურად მუშაობს თავის ანგარიშებში და აცნობებს იმას, რასაც აღმოაჩენს. ჩვენ ვანიჭებთ პრიორიტეტს, ვანაწილებთ გუნდებს შორის და ვტოვებთ არაკრიტიკულ ნივთებს დილისთვის.

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

03:20. გადაუდებელი სინქრონიზაცია
დაფიქსირდა ერთი ახალი პრობლემა. მეორესთვის, ჩვენ ვაწყობთ საგანგებო სინქრონიზაციას. ჩვენ გვესმის, რა ხდება: წინა გამოსწორებამ გაასწორა ერთი პრობლემა, მაგრამ შექმნა მეორე. ჩვენ ვისვენებთ, რათა გავიგოთ, როგორ გავაკეთოთ ეს სწორად და უშედეგოდ.

03:30. ექვსი თვალი
ჩვენ გვესმის, როგორი უნდა იყოს ბაზის საბოლოო მდგომარეობა, რათა ყველაფერი კარგად იყოს ყველა პარტნიორისთვის. ვწერთ მოთხოვნას 6 თვალით, გავაბრტყელებთ წინასწარ წარმოებაში, ვამოწმებთ, გავაბრტყელებთ საწარმოებლად.

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

04:30. უკუქცევის წერტილი
უკუგების წერტილი ახლოვდება, ანუ ის დრო, როცა უკან დახევას რომ დავიწყებთ, ჩვენთვის მიცემულ უქმობას ვერ შევხვდებით. ბილინგის პრობლემაა, რომელმაც ყველაფერი იცის და აღრიცხავს, ​​მაგრამ კლიენტებისგან თანხის ჩამოწერაზე ჯიუტად უარს ამბობს. ცალკეულ გვერდებზე, მოქმედებებსა და სტატუსებზე რამდენიმე შეცდომაა. ძირითადი ფუნქციონირება მუშაობს, ყველა ტესტი წარმატებით გადის. ჩვენ გადავწყვიტეთ, რომ გაშვება მოხდა, ჩვენ არ დავბრუნდებით.

06:00. ღიაა ყველასთვის UI-ში
შეცდომები გამოსწორდა. ზოგიერთი, რომელიც არ იზიდავს მომხმარებლებს, დარჩა მოგვიანებით. ჩვენ ვხსნით ინტერფეისს ყველასთვის. ჩვენ ვაგრძელებთ ბილინგის მუშაობას, ველოდებით მომხმარებლის გამოხმაურებას და მონიტორინგის შედეგებს.

07:00 საათი. პრობლემები API ჩატვირთვასთან დაკავშირებით
ნათელი ხდება, რომ ჩვენ ოდნავ არასწორად დავგეგმეთ დატვირთვა ჩვენს API-ზე და გამოვცადეთ ეს დატვირთვა, რამაც ვერ შეძლო პრობლემის იდენტიფიცირება. შედეგად, მოთხოვნების ≈5% ვერ ხერხდება. მობილიზებული ვიყოთ და ვეძებოთ მიზეზი.

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

08:00. შეასწორეთ API
ჩვენ გავაფართოვეთ დატვირთვა, ავარია გაქრა. ჩვენ ვიწყებთ სახლში წასვლას.

10:00. ყველა
ყველაფერი გამოსწორებულია. მონიტორინგში მშვიდია და კლიენტების ადგილზე გუნდი თანდათან იძინებს. ბილინგი რჩება, ხვალ აღვადგენთ.

შემდეგ დღის განმავლობაში იყო გამოშვებები, რომლებმაც დააფიქსირეს ჟურნალები, შეტყობინებები, დაბრუნების კოდები და პერსონალიზაცია ჩვენი ზოგიერთი კლიენტისთვის.

ასე რომ, გაშვება წარმატებული იყო! ეს, რა თქმა უნდა, უკეთესიც შეიძლებოდა, მაგრამ ჩვენ გამოვიტანეთ დასკვნები იმის შესახებ, რაც არ იყო საკმარისი სრულყოფილების მისაღწევად.

საერთო ჯამში

2 თვიანი აქტიური მომზადების განმავლობაში, 43 დავალება შესრულდა, რომელიც გაგრძელდა რამდენიმე საათიდან რამდენიმე დღემდე.

გაშვების დროს:

• ახალი და შეცვლილი დემონები - 5 ცალი, 2 მონოლითის შეცვლა;
• ცვლილებები მონაცემთა ბაზებში - დაზარალდა ჩვენი 6-ვე მონაცემთა ბაზა მომხმარებლის მონაცემებით, ჩამოტვირთვები განხორციელდა სამი ძველი მონაცემთა ბაზიდან ერთ ახალში;
• მთლიანად გადამუშავებული წინა ნაწილი;
• გადმოწერილი კოდის რაოდენობა - 33 ათასი სტრიქონი ახალი კოდი, ≈ 3 ათასი სტრიქონი კოდი ტესტებში, ≈ 5 ათასი ხაზი მიგრაციის კოდი;
• ყველა მონაცემი ხელუხლებელია, არც ერთი მომხმარებლის ვირტუალური მანქანა არ დაზიანებულა. 🙂

კარგი პრაქტიკა კარგი გავრცელებისთვის

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

1. პირველი, რაც უნდა გააკეთოთ, არის იმის გაგება, თუ როგორ შეიძლება ან რა გავლენას მოახდენს გაშვება მომხმარებლებზე. იქნება შეფერხების დრო? თუ ასეა, რა არის შესვენების დრო? როგორ იმოქმედებს ეს მომხმარებლებზე? რა არის საუკეთესო და უარესი შესაძლო სცენარი? და დაფარეთ რისკები.
2. დაგეგმე ყველაფერი. თითოეულ ეტაპზე, თქვენ უნდა გესმოდეთ გაშვების ყველა ასპექტი:
   • კოდის მიწოდება;
   • კოდის დაბრუნება;
   • თითოეული ოპერაციის დრო;
   • გავლენა მოახდინა ფუნქციონირებაზე.
3. ითამაშე სცენარებით, სანამ გაშვების ყველა ეტაპი, ისევე როგორც რისკები თითოეულ მათგანზე, აშკარა გახდება. თუ ეჭვი გეპარებათ, შეგიძლიათ შეისვენოთ და საეჭვო ეტაპი ცალკე შეისწავლოთ.
4. თითოეული ეტაპი შეიძლება და უნდა გაუმჯობესდეს, თუ ის ჩვენს მომხმარებლებს დაეხმარება. მაგალითად, ეს შეამცირებს შეფერხების დროს ან მოხსნის ზოგიერთ რისკს.
5. უკან დაბრუნების ტესტირება ბევრად უფრო მნიშვნელოვანია, ვიდრე კოდის მიწოდების ტესტირება. აუცილებელია შეამოწმოთ, რომ დაბრუნების შედეგად სისტემა დაუბრუნდება პირვანდელ მდგომარეობას და დაადასტურეთ ეს ტესტებით.
6. ყველაფერი, რაც შეიძლება ავტომატიზირებული იყოს, უნდა იყოს ავტომატიზირებული. ყველაფერი, რისი ავტომატიზაცია შეუძლებელია, წინასწარ უნდა დაიწეროს მოტყუების ფურცელზე.
7. ჩაწერეთ წარმატების კრიტერიუმი. რა ფუნქცია უნდა იყოს ხელმისაწვდომი და რა დროს? თუ ეს არ მოხდა, შეასრულეთ უკან დაბრუნების გეგმა.
8. და რაც მთავარია - ხალხი. ყველამ უნდა იცოდეს, რას აკეთებს, რატომ და რა არის დამოკიდებული მის ქმედებებზე გაშვების პროცესში.

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

წყარო: www.habr.com