ქაოსის ინჟინერია: განზრახ განადგურების ხელოვნება. Მე -2 ნაწილი

Შენიშვნა. თარგმნა: ეს სტატია აგრძელებს AWS ტექნოლოგიების ევანგელისტის ადრიან ჰორნსბის სტატიების დიდ სერიას, რომელიც მიზნად ისახავს მარტივად და ნათლად ახსნას ექსპერიმენტების მნიშვნელობა IT სისტემებში წარუმატებლობის შედეგების შესამცირებლად.

”თუ გეგმის მომზადებას ვერ ახერხებ, მაშინ გეგმავთ ჩავარდნას.” - ბენჯამინ ფრანკლინი

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

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

დიდი კითხვა! თუმცა, როგორც ჩანს, მას ეს პანდა განსაკუთრებით არ აწუხებს...

ნუ ერევი ქაოსის პანდას!

Მოკლე პასუხი: მიმართეთ კრიტიკულ სერვისებს მოთხოვნის გზაზე.

უფრო გრძელი, მაგრამ მკაფიო პასუხი: იმის გასაგებად, თუ სად უნდა დაიწყოთ ქაოსის ექსპერიმენტები, ყურადღება მიაქციეთ სამ სფეროს:

1. შეხედეთ ავარიის ისტორია და ნიმუშების ამოცნობა;
2. გადაწყვიტე კრიტიკული დამოკიდებულებები;
3. გამოიყენეთ ე.წ ზედმეტი თავდაჯერებულობის ეფექტი.

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

1. პასუხი წარსულშია

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

"აწმყოს გასაგებად, თქვენ უნდა იცოდეთ წარსული." - კარლ სეიგანი

შეხედეთ წარუმატებლობების ისტორიას, მონიშნეთ ისინი COE-ში ან postmortems-ში და დაალაგეთ ისინი. დაადგინეთ საერთო შაბლონები, რომლებიც ხშირად იწვევს პრობლემებს და თითოეული COE-სთვის დაუსვით საკუთარ თავს შემდეგი შეკითხვა:

„შეიძლება თუ არა ამის პროგნოზირება და, შესაბამისად, თავიდან აცილება შეცდომის ინექციით?

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

ნორმალურ პირობებში, backend ინსტანციები პასუხობენ ჯანმრთელობის შემოწმებებს დატვირთვის ბალანსერი (ELB)). ELB იყენებს ამ შემოწმებებს მოთხოვნის გადამისამართებისთვის ჯანსაღი შემთხვევებისთვის. როდესაც აღმოჩნდება, რომ ინსტანცია არის „არაჯანსაღი“, ELB წყვეტს მასზე მოთხოვნის გაგზავნას. ერთ დღეს, წარმატებული მარკეტინგული კამპანიის შემდეგ, ტრაფიკის მოცულობა გაიზარდა და ბექენდებმა დაიწყეს ჯანმრთელობის შემოწმებებზე ჩვეულებრივზე ნელა რეაგირება. უნდა ითქვას, რომ ეს ჯანმრთელობის შემოწმებები იყო ღრმა, ანუ შემოწმდა დამოკიდებულების მდგომარეობა.

თუმცა ცოტა ხნით ყველაფერი კარგად იყო.

შემდეგ, უკვე საკმაოდ სტრესულ პირობებში, ერთ-ერთმა შემთხვევამ დაიწყო არაკრიტიკული, რეგულარული ETL cron დავალების შესრულება. მაღალი ტრაფიკის და cronjob-ის კომბინაციამ CPU-ის გამოყენება თითქმის 100%-მდე აიყვანა. CPU-ს გადატვირთვამ კიდევ უფრო შეანელა პასუხები ჯანმრთელობის შემოწმებებზე, იმდენად, რომ ELB-მა გადაწყვიტა, რომ ინსტანციას მუშაობის პრობლემები ჰქონდა. როგორც მოსალოდნელი იყო, ბალანსერმა შეწყვიტა მასზე ტრაფიკის განაწილება, რამაც, თავის მხრივ, გამოიწვია ჯგუფში დარჩენილ ინსტანციებზე დატვირთვის ზრდა.

მოულოდნელად, ყველა სხვა შემთხვევამ ასევე დაიწყო ჯანმრთელობის შემოწმების ჩავარდნა.

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

შემდეგ ჩვენ სამუდამოდ გავიგეთ შემდეგი პუნქტები:

• ახალი ინსტანციის შექმნისას პროგრამული უზრუნველყოფის ინსტალაციას დიდი დრო სჭირდება, უმჯობესია უპირატესობა მიანიჭოთ უცვლელ მიდგომას და ოქროს AMI.
• რთულ სიტუაციებში, პასუხები ჯანმრთელობის შემოწმებებსა და ELB-ებზე უნდა იყოს პრიორიტეტული - ბოლო, რაც გსურთ, არის გაართულოთ ცხოვრება დანარჩენი შემთხვევებისთვის.
• ჯანმრთელობის შემოწმებების ლოკალური ქეშირება ბევრს ეხმარება (თუნდაც რამდენიმე წამით).
• რთულ ვითარებაში, ნუ აწარმოებთ კრონის ამოცანებს და სხვა არაკრიტიკულ პროცესებს - დაზოგეთ რესურსები ყველაზე მნიშვნელოვანი ამოცანებისთვის.
• ავტომატური სკალირებისას გამოიყენეთ უფრო მცირე ინსტანციები. 10 პატარა ეგზემპლარის ჯგუფი უკეთესია, ვიდრე 4 დიდი ეგზემპლარის ჯგუფი; თუ ერთი შემთხვევა ვერ მოხერხდა, პირველ შემთხვევაში ტრაფიკის 10% გადანაწილდება 9 წერტილზე, მეორეში - ტრაფიკის 25% სამ წერტილზე.

აქედან გამომდინარე, შეიძლებოდა თუ არა ამის პროგნოზირება და, შესაბამისად, თავიდან აცილება პრობლემის დანერგვით?

დიახდა რამდენიმე გზით.

პირველი, CPU-ს მაღალი მოხმარების სიმულირებით ისეთი ინსტრუმენტების გამოყენებით, როგორიცაა stress-ng ან cpuburn:

❯ stress-ng --matrix 1 -t 60s

სტრესი

მეორეც, ინსტანციის გადატვირთვით wrk და სხვა მსგავსი კომუნალური საშუალებები:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

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

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

სიზმარი იყო თუ მართლა მოხდა?

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

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

2. შექმენით დამოკიდებულების რუკა

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

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

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

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

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

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

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

❯ netstat -a | more 

AWS-ში შეგიძლიათ გამოიყენოთ ნაკადის ჟურნალები (ნაკადის ჟურნალები) VPC არის მეთოდი, რომელიც საშუალებას გაძლევთ შეაგროვოთ ინფორმაცია IP ტრაფიკის შესახებ, რომელიც მიდის ან ქსელის ინტერფეისებიდან VPC-ში. ასეთი ჟურნალები ასევე დაგეხმარებათ სხვა ამოცანების შესრულებაში - მაგალითად, პასუხის პოვნა კითხვაზე, თუ რატომ არ აღწევს გარკვეული ტრაფიკი ინსტანციაში.

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

AWS რენტგენის კონსოლი

ქსელის დამოკიდებულების რუკა მხოლოდ ნაწილობრივი გამოსავალია. დიახ, ის გვიჩვენებს, რომელ აპლიკაციას აქვს კომუნიკაცია, მაგრამ არსებობს სხვა დამოკიდებულებები.

ბევრი აპლიკაცია იყენებს DNS-ს დამოკიდებულებებთან დასაკავშირებლად, ზოგი კი შეიძლება გამოიყენოს სერვისის აღმოჩენა ან თუნდაც მყარი კოდირებული IP მისამართები კონფიგურაციის ფაილებში (მაგ. /etc/hosts).

მაგალითად, შეგიძლიათ შექმნათ DNS შავი ხვრელი via iptables და ნახეთ რა იშლება. ამისათვის შეიყვანეთ შემდეგი ბრძანება:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNS შავი ხვრელი

თუ /etc/hosts ან სხვა კონფიგურაციის ფაილებს, თქვენ იპოვით IP მისამართებს, რომელთა შესახებაც არაფერი იცით (დიახ, სამწუხაროდ, ეს ასევე ხდება), შეგიძლიათ კვლავ მიხვიდეთ სამაშველოში iptables. ვთქვათ, აღმოაჩინე 8.8.8.8 და არ ვიცი, რომ ეს არის Google-ის საჯარო DNS სერვერის მისამართი. Გამოყენებით iptables თქვენ შეგიძლიათ დაბლოკოთ შემომავალი და გამავალი ტრაფიკი ამ მისამართზე შემდეგი ბრძანებების გამოყენებით:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

წვდომის დახურვა

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

შენიშვნა: ამ კონკრეტულ შემთხვევაში უკეთესი იქნება გამოყენება whois 8.8.8.8, მაგრამ ეს მხოლოდ მაგალითია.

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

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

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

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

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

3. უფრთხილდით ზედმეტ თავდაჯერებულობას

"ვინც რაზე ოცნებობს, მას სჯერა." - დემოსთენე

გსმენიათ ოდესმე ზედმეტი თავდაჯერებულობის ეფექტი?

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

ინსტინქტისა და გამოცდილების საფუძველზე...

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

უფრთხილდით ზედმეტად თავდაჯერებულ ოპერატორს:

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

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

შეჯამება

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

ამით მთავრდება მეორე ნაწილი. გთხოვთ დაწეროთ მიმოხილვები, გააზიაროთ მოსაზრებები ან უბრალოდ დაუკრათ ტაში საშუალო. შემდეგ ნაწილში ი ნამდვილად მე განვიხილავ ინსტრუმენტებსა და მეთოდებს სისტემებში წარუმატებლობის შესატანად. Მანამდე!

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ქაოსის ინჟინერია: განზრახ განადგურების ხელოვნება. Მე -1 ნაწილი";
• «რამდენად მაღალი ხელმისაწვდომობაა უზრუნველყოფილი Kubernetes-ში";
• «მონიტორინგი და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)";
• «მიმდინარეობს ექსპერიმენტი kube-პროქსისა და კვანძის მიუწვდომელობაზე Kubernetes-ში".

წყარო: www.habr.com