როგორ გავუმკლავდეთ სირთულეს პროგრამული სისტემების დიზაინის დროს

რაზეა საუბარი?

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

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

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

რა არის ჯვარედინი შეშფოთება?

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

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

ის კარგად აღწერს რა არის, მაგრამ მინდა გავაფართოვო და ცოტათი გავამარტივო:

ჯვარედინი საზრუნავი არის სისტემის/ორგანიზაციის კონცეფცია ან კომპონენტი, რომელიც გავლენას ახდენს (ან „ჭრის“) ბევრ სხვა ნაწილზე.

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

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

ასპექტების კლასიფიკაცია

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

ასე რომ, მე ვაპირებ ასპექტების დაყოფას მაკრო და მიკროში .

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

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

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

ამ სტატიაში ჩემი ძირითადი აქცენტი მაკრო ასპექტებზე იქნება.

მაკრო ასპექტები

ორგანიზაციული სტრუქტურა

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

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

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

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

კონვეის კანონს რომ დავუბრუნდე, მასში რამდენიმე პრობლემა აღმოვაჩინე.

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

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

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

ტალახის დიდი ბურთი

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

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

სისტემის არქიტექტურა

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

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

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

Software Architecture Style არის პრინციპებისა და შაბლონების ერთობლიობა, რომელიც განსაზღვრავს პროგრამული უზრუნველყოფის შექმნას.

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

მაგალითად, როგორიცაა:

1. მონოლითური არქიტექტურა

2. დომენზე ორიენტირებული დიზაინი

3. კომპონენტზე დაფუძნებული

4. მიკროსერვისები

5. მილები და ფილტრები

6. მოვლენებზე ორიენტირებული

7. მიკროკერნელი

8. სერვისზე ორიენტირებული

   
   

და ასე შემდეგ…

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

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

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

1. თითქმის ყოველთვის იწყება მონოლითური არქიტექტურის სტილით, რადგან ის გამორიცხავს პრობლემების უმეტესობას, რომლებიც წარმოიქმნება განაწილებული სისტემების ბუნებიდან გამომდინარე. ასევე აზრი აქვს მოდულარული მონოლითის დაცვას, რათა ფოკუსირება მოახდინოთ მკაფიო საზღვრებით შენობის კომპონენტებზე. კომპონენტებზე დაფუძნებული მიდგომის გამოყენებამ შეიძლება დაეხმაროს მათ ერთმანეთთან კომუნიკაციაში მოვლენების გამოყენებით, მაგრამ პირდაპირი ზარების არსებობა (aka RPC) თავიდანვე ამარტივებს საქმეს. თუმცა, მნიშვნელოვანია კომპონენტებს შორის დამოკიდებულების თვალყურის დევნება, რადგან თუ კომპონენტმა A-მ ბევრი რამ იცის B კომპონენტის შესახებ, შესაძლოა აზრი ჰქონდეს მათ ერთში გაერთიანებას.
2. როდესაც მიუახლოვდებით იმ სიტუაციას, როდესაც გჭირდებათ თქვენი განვითარებისა და სისტემის მასშტაბირება, შეგიძლიათ გაითვალისწინოთ Stangler-ის ნიმუში, რათა თანდათან ამოიღოთ კომპონენტები, რომლებიც უნდა განლაგდეს დამოუკიდებლად ან თუნდაც მასშტაბური იყოს კონკრეტული მოთხოვნებით.
3. ახლა, თუ თქვენ გაქვთ მომავლის მკაფიო ხედვა, რაც ცოტათი წარმოუდგენელი იღბალია, შეგიძლიათ გადაწყვიტოთ სასურველი არქიტექტურა. ამ მომენტში, თქვენ შეგიძლიათ გადაწყვიტოთ მიკროსერვისების არქიტექტურაზე გადასვლა ორკესტრირებისა და ქორეოგრაფიის მიდგომების გამოყენებით, CQRS ნიმუშის ჩართვის დამოუკიდებელი მასშტაბის ჩაწერისა და წაკითხვის ოპერაციებისთვის ან თუნდაც მონოლითური არქიტექტურის გადაწყვეტით, თუ ის შეესაბამება თქვენს საჭიროებებს.

ასევე მნიშვნელოვანია გავიგოთ რიცხვები და მეტრიკები, როგორიცაა DAU (ყოველდღიური აქტიური მომხმარებლები), MAU (თვიური აქტიური მომხმარებლები), RPC (მოთხოვნა წამში) და TPC (ტრანზაქცია წამში), რადგან ეს დაგეხმარებათ არჩევანის გაკეთებაში, რადგან არქიტექტურა 100 აქტიური მომხმარებელი და 100 მილიონი აქტიური მომხმარებელი განსხვავებულია.

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

ტექნოლოგიის წყობის შერჩევა

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

ეს არის ძირითადი მოსაზრებების ჩამონათვალი ტექნოლოგიური დასტას არჩევისთვის:

• პროექტის მოთხოვნები და სირთულე. მაგალითად, მარტივი ვებ აპლიკაციის აშენება შესაძლებელია Blazor Framework-ით, თუ თქვენს დეველოპერებს აქვთ ამის გამოცდილება, მაგრამ WebAssembly-ის სიმწიფის არარსებობის გამო, React-ისა და Typescript-ის არჩევა გრძელვადიანი წარმატებისთვის შეიძლება იყოს უკეთესი გადაწყვეტილება.
• მასშტაბურობა და შესრულების საჭიროებები. თუ თქვენ ელოდებით დიდი რაოდენობის ტრაფიკის მიღებას, ASP.NET Core-ის არჩევა Django-ს ნაცვლად შეიძლება იყოს გონივრული არჩევანი, მისი უმაღლესი შესრულების გამო ერთდროულად მოთხოვნების დამუშავებაში. თუმცა, ეს გადაწყვეტილება დამოკიდებულია ტრაფიკის მასშტაბზე, რომელსაც ელოდებით. თუ თქვენ გჭირდებათ პოტენციურად მილიარდობით მოთხოვნის მართვა დაბალი შეყოვნებით, Garbage Collection-ის არსებობა შეიძლება იყოს გამოწვევა.
• დაქირავება, განვითარების დრო და ღირებულება. უმეტეს შემთხვევაში, ეს ის ფაქტორებია, რაზეც უნდა ვიზრუნოთ. ბაზარზე გასვლის დრო, ტექნიკური მომსახურების ღირებულება და დაქირავების სტაბილურობა იწვევს თქვენი ბიზნესის საჭიროებებს დაბრკოლებების გარეშე.
• გუნდის ექსპერტიზა და რესურსები. თქვენი განვითარების გუნდის უნარების ნაკრები გადამწყვეტი ფაქტორია. ზოგადად უფრო ეფექტურია იმ ტექნოლოგიების გამოყენება, რომლებსაც თქვენი გუნდი უკვე იცნობს, თუ არ არსებობს ახალი სტეკის შესწავლაში ინვესტირების ძლიერი მიზეზი.
• სიმწიფე. ძლიერ საზოგადოებას და ბიბლიოთეკებისა და ხელსაწყოების მდიდარ ეკოსისტემას შეუძლია მნიშვნელოვნად შეამსუბუქოს განვითარების პროცესი. პოპულარულ ტექნოლოგიებს ხშირად აქვთ საზოგადოების უკეთესი მხარდაჭერა, რაც შეიძლება ფასდაუდებელი იყოს პრობლემების გადასაჭრელად და რესურსების მოსაძებნად. ამრიგად, თქვენ შეგიძლიათ დაზოგოთ რესურსები და ფოკუსირება მოახდინოთ ძირითადად პროდუქტზე.
• გრძელვადიანი მოვლა და მხარდაჭერა. განვიხილოთ ტექნოლოგიის გრძელვადიანი სიცოცხლისუნარიანობა. ტექნოლოგიები, რომლებიც ფართოდ არის მიღებული და მხარდაჭერილი, ნაკლებად სავარაუდოა, რომ მოძველდება და ზოგადად მიიღებს რეგულარულ განახლებებსა და გაუმჯობესებას.

როგორ შეიძლება გავლენა იქონიოს ბიზნესის ზრდაზე მრავალი ტექნოლოგიის დასტას?

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

მაგრამ რა არის კონკრეტული პრობლემისთვის საუკეთესო ხელსაწყოს შერჩევის პრინციპი?

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

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

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

მარცხის ერთი წერტილი (SPOF)

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

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

1. ჭარბი რაოდენობა. განახორციელეთ ჭარბი რაოდენობა კრიტიკული კომპონენტებისთვის. ეს ნიშნავს, რომ გქონდეთ სარეზერვო კომპონენტები, რომლებსაც შეუძლიათ დაიკავონ ძირითადი კომპონენტის წარუმატებლობის შემთხვევაში. სიჭარბე შეიძლება გამოყენებულ იქნას სისტემის სხვადასხვა ფენებში, მათ შორის აპარატურა (სერვერები, დისკები), ქსელში (ბმულები, გადამრთველები) და პროგრამული უზრუნველყოფა (მონაცემთა ბაზა, აპლიკაციის სერვერები). თუ თქვენ მასპინძლობთ ყველაფერს ერთ ღრუბლოვან პროვაიდერში და გაქვთ სარეზერვო ასლებიც კი, განიხილეთ რეგულარული დამატებითი სარეზერვო ასლის შექმნა სხვაში, რათა შეამციროთ დაკარგული ხარჯები კატასტროფის შემთხვევაში.
2. მონაცემთა ცენტრები. გაანაწილეთ თქვენი სისტემა მრავალ ფიზიკურ ადგილას, როგორიცაა მონაცემთა ცენტრები ან ღრუბლოვანი რეგიონები. ეს მიდგომა იცავს თქვენს სისტემას ადგილმდებარეობის სპეციფიკური წარუმატებლობისგან, როგორიცაა ელექტროენერგიის გათიშვა ან ბუნებრივი კატასტროფები.
3. Failover. გამოიყენეთ შეცდომის მიდგომა თქვენი ყველა კომპონენტისთვის (DNS, CDN, დატვირთვის ბალანსერები, Kubernetes, API Gateways და მონაცემთა ბაზები). იმის გამო, რომ პრობლემები შეიძლება მოულოდნელად წარმოიშვას, მნიშვნელოვანია გქონდეთ სარეზერვო გეგმა ნებისმიერი კომპონენტის მისი კლონით სწრაფად ჩანაცვლებისთვის.
4. მაღალი ხელმისაწვდომობის სერვისები. დარწმუნდით, რომ თქვენი სერვისები თავიდანვე ჰორიზონტალურად მასშტაბური და ხელმისაწვდომი იყოს შემდეგი პრინციპების დაცვით:
   • ივარჯიშეთ სერვისის მოქალაქეობის არარსებობაზე და მოერიდეთ მომხმარებლის სესიების შენახვას მეხსიერების ქეშებში. ამის ნაცვლად, გამოიყენეთ განაწილებული ქეში სისტემა, როგორიცაა Redis.
   • ლოგიკის შემუშავებისას მოერიდეთ მესიჯების მოხმარების ქრონოლოგიურ თანმიმდევრობას.
   • შეამცირეთ დარღვევის ცვლილებები API მომხმარებლების შეფერხების თავიდან ასაცილებლად. სადაც შესაძლებელია, აირჩიე უკუთავსებადი ცვლილებები. ასევე, გაითვალისწინეთ ღირებულება, რადგან ხანდახან, ავარიული ცვლილების განხორციელება შეიძლება უფრო ეფექტური იყოს.
   • მიგრაციის შესრულების ჩართვა განლაგების მილსადენში.
   • ჩამოაყალიბეთ სტრატეგია ერთდროული მოთხოვნების დამუშავებისთვის.
   • განახორციელეთ სერვისების აღმოჩენა, მონიტორინგი და შესვლა საიმედოობისა და დაკვირვების გასაუმჯობესებლად.
   • განავითარეთ ბიზნეს ლოგიკა, რომ იყოთ უძლური, აღიარეთ, რომ ქსელის უკმარისობა გარდაუვალია.
5. დამოკიდებულების მიმოხილვა. რეგულარულად გადახედეთ და შეამცირეთ გარე დამოკიდებულებები. თითოეულ გარე დამოკიდებულებას შეუძლია შემოიტანოს პოტენციური SPOF-ები, ამიტომ აუცილებელია ამ რისკების გაგება და შერბილება.
6. ცოდნის რეგულარული გაზიარება. არასოდეს დაივიწყოთ ცოდნის გავრცელების მნიშვნელობა თქვენს ორგანიზაციაში. ადამიანები შეიძლება იყვნენ არაპროგნოზირებადი და ერთ ინდივიდზე დაყრდნობა სარისკოა. წაახალისეთ გუნდის წევრები თავიანთი ცოდნის დიგიტალიზაციაში დოკუმენტაციის საშუალებით. თუმცა, ყურადღება მიაქციეთ ზედმეტ დოკუმენტაციას. გამოიყენეთ სხვადასხვა AI ინსტრუმენტები ამ პროცესის გასამარტივებლად.

დასკვნა

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

გმადლობთ, რომ კითხულობთ! შევხვდებით შემდეგ ჯერზე!