ყველა საუბრობს განვითარებისა და ტესტირების პროცესებზე, პერსონალის მომზადებაზე, მოტივაციის ამაღლებაზე, მაგრამ ეს პროცესები საკმარისი არ არის, როცა მომსახურების ერთი წუთი უზარმაზარ თანხას ჯდება. რა უნდა გააკეთოთ, როდესაც ფინანსურ ტრანზაქციებს ახორციელებთ მკაცრი SLA-ის პირობებში? როგორ გავზარდოთ თქვენი სისტემების საიმედოობა და შეცდომის ტოლერანტობა, განტოლებიდან ამოიღოთ განვითარება და ტესტირება?
Следующая конференция HighLoad++ пройдет 6 и 7 апреля 2020 года в Санкт-Петербурге. Подробности и билеты по . 9 ნოემბერი, 18:00 საათი. HighLoad++ მოსკოვი 2018, დელი + კოლკატა დარბაზი. თეზისები და .
Евгений Кузовлев (далее – ЕК): - მეგობრებო, გამარჯობა! მე მქვია კუზოვლევი ევგენი. მე ვარ EcommPay კომპანიისგან, კონკრეტული განყოფილებაა EcommPay IT, კომპანიების ჯგუფის IT განყოფილება. დღეს კი ვისაუბრებთ შეფერხებებზე - იმაზე, თუ როგორ ავიცილოთ თავიდან ისინი, როგორ შევამციროთ მათი შედეგები, თუ ამის თავიდან აცილება შეუძლებელია. თემა შემდეგნაირად არის გაწერილი: „რა უნდა გავაკეთოთ, როდესაც ერთი წუთი შესვენება 100 000 დოლარი ღირს“? წინსვლისას, ჩვენი რიცხვები შედარებითია.
რას აკეთებს EcommPay IT?
Ვინ ვართ ჩვენ? რატომ ვდგავარ აქ შენს წინ? რატომ მაქვს უფლება აქ რაღაც გითხრა? და რაზე ვისაუბრებთ აქ უფრო დეტალურად?
EcommPay კომპანიების ჯგუფი არის საერთაშორისო შემძენი. ჩვენ ვამუშავებთ გადახდებს მთელ მსოფლიოში - რუსეთში, ევროპაში, სამხრეთ-აღმოსავლეთ აზიაში (მთელი მსოფლიოს მასშტაბით). ჩვენ გვაქვს 9 ოფისი, სულ 500 თანამშრომელი და მათგან დაახლოებით ნახევარზე ცოტა ნაკლები IT სპეციალისტები არიან. ყველაფერს, რასაც ვაკეთებთ, რასაც ვშოულობთ ფულს, ჩვენ თვითონ გავაკეთეთ.
У нас все наши продукты (а их у нас достаточно много – в линейке больших IT-продуктов у нас порядка 16 различных компонент) мы написали сами; мы сами пишем, мы сами развиваем. И на данный момент мы проводим около миллиона транзакций в день (миллионы – наверное, так будет правильно сказать). Мы молодая компания достаточно – нам всего около шести лет.
6 წლის წინ ეს იყო ასეთი სტარტაპი, როცა ბიჭები წამოვიდნენ ბიზნესთან ერთად. მათ იდეით გააერთიანა (აზრის გარდა სხვა არაფერი იყო) და გავიქეცით. როგორც ნებისმიერი სტარტაპი, ჩვენ უფრო სწრაფად ვირბინეთ... ჩვენთვის სიჩქარე უფრო მნიშვნელოვანი იყო, ვიდრე ხარისხი.
რაღაც მომენტში გავჩერდით: მივხვდით, რომ ამ სისწრაფით და ამ ხარისხით ვეღარ ვიცხოვრებდით და პირველ რიგში ხარისხზე უნდა გაგვეკეთებინა აქცენტი. ამ მომენტში, ჩვენ გადავწყვიტეთ დაგვეწერა ახალი პლატფორმა, რომელიც იქნებოდა სწორი, მასშტაბური და საიმედო. მათ დაიწყეს ამ პლატფორმის წერა (დაიწყეს ინვესტირება, განვითარება, ტესტირება), მაგრამ რაღაც მომენტში მიხვდნენ, რომ განვითარება და ტესტირება არ გვაძლევდა საშუალებას მივსულიყავით მომსახურების ხარისხის ახალ დონეზე.
ახალ პროდუქტს ამზადებ, წარმოებაში აყენებ, მაგრამ მაინც სადღაც რაღაც არასწორედ წავა. დღეს კი ვისაუბრებთ იმაზე, თუ როგორ მივაღწიოთ ხარისხის ახალ დონეს (როგორ გავაკეთეთ ეს, ჩვენს გამოცდილებაზე), განვითარებისა და ტესტირების განტოლებიდან ამოღება; ჩვენ ვისაუბრებთ იმაზე, თუ რა არის ხელმისაწვდომი ოპერაციისთვის - რა შეუძლია ოპერაციას თავისთავად, რა შეუძლია შესთავაზოს ტესტირებას, რათა გავლენა მოახდინოს ხარისხზე.
შეფერხებები. ოპერაციის ბრძანებები.
ყოველთვის მთავარი ქვაკუთხედი, რაზეც დღეს რეალურად ვისაუბრებთ, არის დასვენების დრო. საშინელი სიტყვა. თუ შესვენება გვაქვს, ყველაფერი ცუდია ჩვენთვის. მის ასამაღლებლად მივრბივართ, ადმინები უჭირავთ სერვერს - ღმერთმა ქნას არ ჩამოვარდეს, როგორც ამბობენ იმ სიმღერაში. ეს არის ის, რაზეც დღეს ვისაუბრებთ.
როდესაც დავიწყეთ ჩვენი მიდგომების შეცვლა, ჩვენ ჩამოვაყალიბეთ 4 მცნება. მე მაქვს ისინი წარმოდგენილი სლაიდებზე:
ეს მცნებები საკმაოდ მარტივია:
- სწრაფად დაადგინეთ პრობლემა.
- მოიშორეთ კიდევ უფრო სწრაფად.
- დაეხმარეთ მიზეზის გაგებაში (მოგვიანებით, დეველოპერებისთვის).
- И стандартизировать подходы.
მე მინდა გავამახვილო თქვენი ყურადღება მე-2 პუნქტზე. ჩვენ პრობლემას ვიშორებთ და არა ვწყვეტთ. გადაწყვეტილების მიღება მეორეხარისხოვანია. ჩვენთვის უპირველესი ის არის, რომ მომხმარებელი დაცულია ამ პრობლემისგან. ის იარსებებს რაღაც იზოლირებულ გარემოში, მაგრამ ამ გარემოს მასთან არანაირი შეხება არ ექნება. რეალურად, ჩვენ გავივლით პრობლემის ამ ოთხ ჯგუფს (ზოგი უფრო დეტალურად, ზოგი ნაკლებად დეტალურად), გეტყვით რას ვიყენებთ, რა შესაბამისი გამოცდილება გვაქვს გადაწყვეტილებებში.
პრობლემების მოგვარება: როდის ხდება ისინი და რა უნდა გავაკეთოთ მათთან დაკავშირებით?
მაგრამ დავიწყებთ მწყობრიდან გამოსვლისას, დავიწყებთ No2 პუნქტით - როგორ სწრაფად მოვიშოროთ პრობლემა? არის პრობლემა - უნდა გამოვასწოროთ. "რა უნდა გავაკეთოთ ამის შესახებ?" - მთავარი კითხვა. და როდესაც დავიწყეთ ფიქრი იმაზე, თუ როგორ უნდა გამოგვესწორებინა პრობლემა, ჩვენ შევიმუშავეთ გარკვეული მოთხოვნები, რომლებსაც პრობლემების აღმოფხვრა უნდა მოჰყვეს.
ამ მოთხოვნების ჩამოსაყალიბებლად გადავწყვიტეთ საკუთარ თავს დავსვათ კითხვა: „როდის გვაქვს პრობლემები“? და პრობლემები, როგორც გაირკვა, ხდება ოთხ შემთხვევაში:
- აპარატურის უკმარისობა.
- Сбой внешних сервисов.
- პროგრამული უზრუნველყოფის ვერსიის შეცვლა (იგივე განლაგება).
- ფეთქებადი დატვირთვის ზრდა.
Про первые две мы с вами говорить не будем. Аппаратная неисправность решается достаточно просто: у вас должно быть всё дублировано. Если это диски – диски должны быть собраны в RAID, если это сервер – сервер должен быть дублирован, если у вас сетевая инфраструктура – вы должны поставить вторую копию сетевой инфраструктуры, то есть вы берёте и дублируете. И если у вас что-то отказывает, вы переключаетесь на резервные мощности. Здесь большее что-то сказать сложно.
მეორე არის გარე სერვისების წარუმატებლობა. უმეტესობისთვის სისტემა პრობლემას საერთოდ არ წარმოადგენს, მაგრამ ჩვენთვის არა. ვინაიდან ჩვენ ვამუშავებთ გადახდებს, ჩვენ ვართ აგრეგატორი, რომელიც დგას მომხმარებელს (რომელიც შეაქვს მისი ბარათის მონაცემებს) და ბანკებს, გადახდის სისტემებს (Visa, MasterCard, Mira და ა.შ.) შორის. ჩვენი გარე სერვისები (გადახდის სისტემები, ბანკები) მარცხისკენ მიდის. ვერც ჩვენ და ვერც თქვენ (თუ თქვენ გაქვთ ასეთი სერვისები) ვერ მოვახდენთ ამაზე გავლენას.
რა უნდა გააკეთოს მაშინ? აქ ორი ვარიანტია. პირველ რიგში, თუ შეგიძლიათ, ამ სერვისის დუბლირება უნდა გააკეთოთ. მაგალითად, თუ შეგვიძლია, გადავიტანთ ტრაფიკს ერთი სერვისიდან მეორეზე: მაგალითად, ბარათები მუშავდებოდა სბერბანკის საშუალებით, სბერბანკს პრობლემები აქვს - ტრაფიკს [პირობითად] გადავცემთ Raiffeisen-ს. მეორე რაც შეგვიძლია გავაკეთოთ არის ძალიან სწრაფად შევამჩნიოთ გარე სერვისების წარუმატებლობა და, შესაბამისად, რეაგირების სიჩქარეზე ვისაუბრებთ მოხსენების შემდეგ ნაწილში.
სინამდვილეში, ამ ოთხიდან ჩვენ შეგვიძლია კონკრეტულად ვიმოქმედოთ პროგრამული უზრუნველყოფის ვერსიების შეცვლაზე - მივიღოთ ქმედებები, რაც გამოიწვევს სიტუაციის გაუმჯობესებას განლაგების კონტექსტში და დატვირთვის ფეთქებადი ზრდის კონტექსტში. სინამდვილეში, ეს არის ის, რაც ჩვენ გავაკეთეთ. აი, კიდევ ერთხელ, პატარა შენიშვნა...
ამ ოთხი პრობლემისგან, რამდენიმე დაუყოვნებლივ მოგვარდება, თუ ღრუბელი გაქვთ. თუ თქვენ ხართ Microsoft Azhur-ში, ოზონის ღრუბლებში, ან იყენებთ ჩვენს ღრუბლებს Yandex-დან ან Mail-დან, მაშინ მაინც ტექნიკის გაუმართაობა ხდება მათი პრობლემა და ყველაფერი მაშინვე კარგად ხდება თქვენთვის ტექნიკის გაუმართაობის კონტექსტში.
Мы – немножечко нестандартная компания. Здесь все говорят про «Кубернетс», про облака – у нас нет ни «Кубернетса», ни облаков. У нас зато есть стойки с железом во множестве дата-центров, и на этом железе мы вынуждены жить, мы вынуждены отвечать за это всё. Поэтому в этом контексте будем разговаривать. Итак, про проблемы. Первые две вынесли за скобки.
პროგრამული უზრუნველყოფის ვერსიის შეცვლა. ბაზები
У нас разработчики не имеют доступа к продакшну. Почему так? А просто мы сертифицированы по PCI DSS, и у нас разработчики просто не имеют право лазить в «прод». Всё, точка. Совсем. Поэтому ответственность разработки заканчивается ровно в тот момент, когда разработка передала билд на релиз.
ჩვენი მეორე საფუძველი, რაც გვაქვს, რომელიც ასევე ძალიან გვეხმარება, არის უნიკალური დაუსაბუთებელი ცოდნის არარსებობა. იმედია შენთვისაც ასეა. რადგან თუ ეს ასე არ არის, პრობლემები შეგექმნებათ. პრობლემები წარმოიქმნება, როდესაც ეს უნიკალური, დაუსაბუთებელი ცოდნა არ იქნება საჭირო დროს საჭირო ადგილას. ვთქვათ, გყავთ ერთი ადამიანი, რომელმაც იცის როგორ განათავსოს კონკრეტული კომპონენტი - ადამიანი იქ არ არის, ის შვებულებაშია ან ავად არის - ესე იგი, პრობლემები გაქვთ.
И третий базис, к которому мы пришли. Мы пришли к нему через боль, кровь, слёзы – мы пришли к тому, что любой наш билд содержит ошибки, даже если он без ошибок. Мы для себя так решили: когда мы что-то деплоим, когда мы что-то катим в прод – у нас билд с ошибками. Мы сформировали требования, которым наша система должна удовлетворять.
Требования к смене версии ПО
არსებობს სამი მოთხოვნა:
- ჩვენ სწრაფად უნდა დავაბრუნოთ განლაგება.
- ჩვენ უნდა შევამციროთ წარუმატებელი განლაგების გავლენა.
- И мы должны иметь возможность быстро параллельно задеплоиться.
ზუსტად ამ თანმიმდევრობით! რატომ? რადგან, უპირველეს ყოვლისა, ახალი ვერსიის განლაგებისას, სიჩქარე არ არის მნიშვნელოვანი, მაგრამ თქვენთვის მნიშვნელოვანია, თუ რამე არასწორედ მოხდება, სწრაფად გადახვიდეთ უკან და მინიმალური გავლენა მოახდინოთ. მაგრამ თუ თქვენ გაქვთ ვერსიების კომპლექტი წარმოებაში, რისთვისაც აღმოჩნდება, რომ არის შეცდომა (ბუნებრივიდან, არ ყოფილა განლაგება, მაგრამ არის შეცდომა) - თქვენთვის მნიშვნელოვანია შემდგომი განლაგების სიჩქარე. რა გავაკეთეთ ამ მოთხოვნების დასაკმაყოფილებლად? ჩვენ მივმართეთ შემდეგ მეთოდოლოგიას:
ეს საკმაოდ კარგად არის ცნობილი, ჩვენ არასოდეს გამოგვიგონია - ეს არის ლურჯი/მწვანე განლაგება. რა არის ეს? თქვენ უნდა გქონდეთ ასლი სერვერების თითოეული ჯგუფისთვის, რომელზედაც დაინსტალირებულია თქვენი აპლიკაციები. ასლი "თბილია": მასზე ტრაფიკი არ არის, მაგრამ ნებისმიერ მომენტში ეს ტრაფიკი შეიძლება გაიგზავნოს ამ ასლზე. ეს ასლი შეიცავს წინა ვერსიას. და განლაგების დროს, თქვენ გააფართოვებთ კოდს არააქტიურ ასლში. შემდეგ გადართეთ ტრაფიკის ნაწილი (ან მთელი) ახალ ვერსიაზე. ამრიგად, იმისათვის, რომ შეცვალოთ მოძრაობის ნაკადი ძველი ვერსიიდან ახალზე, თქვენ უნდა შეასრულოთ მხოლოდ ერთი მოქმედება: თქვენ უნდა შეცვალოთ ბალანსერი ზემოთ დინების მიმართულებით, შეცვალოთ მიმართულება - ერთი ზემოდან მეორეზე. ეს ძალიან მოსახერხებელია და წყვეტს სწრაფი გადართვისა და სწრაფი დაბრუნების პრობლემას.აქ მეორე კითხვის გამოსავალი არის მინიმიზაცია: თქვენ შეგიძლიათ გაგზავნოთ თქვენი ტრაფიკის მხოლოდ ნაწილი ახალ ხაზზე, ხაზში ახალი კოდით (დაე იყოს, მაგალითად, 2%). და ეს 2% არ არის 100%! თუ დაკარგეთ თქვენი ტრაფიკის 100% წარუმატებელი განლაგების გამო, ეს საშინელებაა; თუ დაკარგეთ თქვენი ტრაფიკის 2%, ეს უსიამოვნოა, მაგრამ ეს არ არის საშინელი. უფრო მეტიც, მომხმარებლები დიდი ალბათობით ვერც კი შეამჩნევენ ამას, რადგან ზოგიერთ შემთხვევაში (არა ყველა) ერთი და იგივე მომხმარებელი, F5-ზე დაჭერით, გადაიყვანება სხვა, სამუშაო ვერსიაში.
ლურჯი/მწვანე განლაგება. მარშრუტიზაცია
თუმცა, ყველაფერი ასე მარტივი არ არის "ლურჯი/მწვანე განლაგება"... ყველა ჩვენი კომპონენტი შეიძლება დაიყოს სამ ჯგუფად:
- ეს არის წინა ნაწილი (გადახდის გვერდები, რომლებსაც ჩვენი კლიენტები ხედავენ);
- დამუშავების ბირთვი;
- адаптер для работы с платёжными системами (банки, «МастерКард», «Визу»…).
И здесь есть нюанс – нюанс заключается в роутинге между линиями. Если вы просто переключаете 100% трафика, у вас этих проблем нет. Но если вы хотите переключить 2%, у вас начинаются вопросы: «А как это сделать?» Самое простое, в лоб: вы можете по случайному выбору, Round Robin в nginx’е настроить, и у вас 2% – налево, 98% – направо. Но это не всегда подходит.
მაგალითად, ჩვენს შემთხვევაში, მომხმარებელი ურთიერთქმედებს სისტემასთან ერთზე მეტი მოთხოვნით. ეს ნორმალურია: 2, 3, 4, 5 მოთხოვნა - თქვენი სისტემები შეიძლება იყოს იგივე. და თუ თქვენთვის მნიშვნელოვანია, რომ მომხმარებლის ყველა მოთხოვნა მივიდეს იმავე ხაზთან, რომელზეც მოვიდა პირველი მოთხოვნა, ან (მეორე პუნქტი) მომხმარებლის ყველა მოთხოვნა გადართვის შემდეგ ახალ ხაზზე (მას შეეძლო უფრო ადრე დაეწყო მუშაობა) სისტემა, შეცვლამდე), - მაშინ ეს შემთხვევითი განაწილება არ არის თქვენთვის შესაფერისი. შემდეგ არის შემდეგი პარამეტრები:
პირველი ვარიანტი, უმარტივესი, ეფუძნება კლიენტის ძირითად პარამეტრებს (IP Hash). თქვენ გაქვთ IP და ყოფთ მას მარჯვნიდან მარცხნივ IP მისამართით. შემდეგ ჩემს მიერ აღწერილი მეორე შემთხვევა იმუშავებს თქვენთვის, როდესაც განლაგება მოხდა, მომხმარებელს უკვე შეეძლო დაეწყო მუშაობა თქვენს სისტემასთან და განლაგების მომენტიდან ყველა მოთხოვნა გადავა ახალ ხაზზე (იგივე, ვთქვათ).Если это по каким-то причинам вам не подходит и вам надо обязательно отправлять запросы на ту линию, куда пришёл первичный, инитный запрос пользователя, тогда у вас есть два варианта…
პირველი ვარიანტი: შეგიძლიათ შეიძინოთ ფასიანი nginx+. არსებობს Sticky სესიების მექანიზმი, რომელიც მომხმარებლის თავდაპირველი მოთხოვნით ანიჭებს სესიას მომხმარებელს და აკავშირებს მას ამა თუ იმ ზემო დინებაში. ყველა შემდგომი მომხმარებლის მოთხოვნა სესიის სიცოცხლის განმავლობაში გაიგზავნება იმავე ზემოთ, სადაც სესია გამოქვეყნდა.ეს არ შეგვეფერება, რადგან ჩვენ უკვე გვქონდა რეგულარული ნგინქსი. nginx+-ზე გადასვლა არ არის ის, რომ ეს ძვირია, უბრალოდ, ეს იყო ჩვენთვის გარკვეულწილად მტკივნეული და არც ისე სწორი. მაგალითად, „Sticks Sessions“ ჩვენთვის არ მუშაობდა იმ მარტივი მიზეზის გამო, რომ „Sticks Sessions“ არ იძლევა მარშრუტიზაციას „ან-ან“-ის საფუძველზე. აქ შეგიძლიათ მიუთითოთ, რას ვაკეთებთ ჩვენ „Sticks Sessions“, მაგალითად, IP მისამართით ან IP მისამართით და ქუქიებით ან პოსტპარამეტრით, მაგრამ „ან-ან“ უფრო რთულია იქ.
ამიტომ მივედით მეოთხე ვარიანტზე. ჩვენ ავიღეთ nginx სტეროიდებზე (ეს არის openresty) - ეს არის იგივე nginx, რომელიც დამატებით მხარს უჭერს ბოლო სკრიპტების ჩართვას. თქვენ შეგიძლიათ დაწეროთ ბოლო სკრიპტი, მისცეთ მას „ღია დასვენება“ და ეს უკანასკნელი სკრიპტი შესრულდება, როდესაც მომხმარებლის მოთხოვნა მოვა.
И мы написали, собственно, такой скриптик, поставили себе «опенрести» и в этом скрипте перебираем 6 различных параметров по конкатенации «Или». В зависимости от наличия того или иного параметра, мы знаем, что пользователь пришёл на одну страницу или на другую, на одну линию или на другую.
Blue/Green deploy. Достоинства и недостатки
რა თქმა უნდა, ალბათ, შესაძლებელი იყო ცოტათი გამარტივება (იგივე „Sticky Sessions“-ის გამოყენება), მაგრამ გვაქვს ისეთი ნიუანსიც, რომ არა მხოლოდ მომხმარებელი ურთიერთობს ჩვენთან ერთი ტრანზაქციის ერთი დამუშავების ფარგლებში... მაგრამ გადახდის სისტემები ასევე ურთიერთქმედებენ ჩვენთან: მას შემდეგ რაც ვამუშავებთ ტრანზაქციას (გადახდის სისტემაში მოთხოვნის გაგზავნით), ვიღებთ ქულბეკს.
და ვთქვათ, თუ ჩვენს წრეში შეგვიძლია მომხმარებლის IP მისამართის გადაგზავნა ყველა მოთხოვნაში და გავყოთ მომხმარებლები IP მისამართის მიხედვით, მაშინ ჩვენ არ ვიტყვით იგივე „ვიზას“: „მეგობარო, ჩვენ ისეთი რეტრო კომპანია ვართ, როგორც ჩანს. იყოს საერთაშორისო (საიტზე და რუსეთში)... გთხოვთ მოგვაწოდოთ მომხმარებლის IP მისამართი დამატებით ველში, თქვენი პროტოკოლი სტანდარტიზებულია“! გასაგებია, რომ არ დათანხმდებიან.
მაშასადამე, ეს არ გამოგვივიდა - ჩვენ გავაკეთეთ openresty. შესაბამისად, მარშრუტიზაციისას მივიღეთ მსგავსი რამ:ლურჯ/მწვანე განლაგებას აქვს, შესაბამისად, უპირატესობები, რაც აღვნიშნე და უარყოფითი მხარეები.
ორი მინუსი:
- თქვენ უნდა შეგაწუხოთ მარშრუტიზაცია;
- второй основной недостаток – это расходы.
თქვენ გჭირდებათ ორჯერ მეტი სერვერი, გჭირდებათ ორჯერ მეტი ოპერატიული რესურსი, თქვენ უნდა დახარჯოთ ორჯერ მეტი ძალისხმევა მთელი ამ ზოოპარკის შესანარჩუნებლად.
სხვათა შორის, უპირატესობებს შორის არის კიდევ ერთი რამ, რაც აქამდე არ მიხსენებია: დატვირთვის ზრდის შემთხვევაში გაქვს რეზერვი. თუ თქვენ გაქვთ დატვირთვის ფეთქებადი ზრდა, გყავთ მომხმარებლების დიდი რაოდენობა, მაშინ უბრალოდ ჩართავთ მეორე ხაზს 50-დან 50-მდე განაწილებაში - და დაუყოვნებლივ გექნებათ x2 სერვერები თქვენს კლასტერში, სანამ არ გადაწყვეტთ მეტი სერვერის არსებობის პრობლემას.
როგორ გავაკეთოთ სწრაფი განლაგება?
Мы поговорили, как решить проблему минимизации и быстрого отката, но вопрос остаётся: «А как быстро деплоиться»?
აქ მოკლე და მარტივია.- თქვენ უნდა გქონდეთ CD სისტემა (უწყვეტი მიწოდება) - თქვენ არ შეგიძლიათ მის გარეშე ცხოვრება. თუ თქვენ გაქვთ ერთი სერვერი, შეგიძლიათ ხელით განათავსოთ. ჩვენ გვაქვს დაახლოებით ათასნახევარი სერვერი და ერთი და ნახევარი ათასი სახელური, რა თქმა უნდა - ჩვენ შეგვიძლია გავაშენოთ ამ ოთახის ზომის განყოფილება მხოლოდ განსათავსებლად.
- განლაგება უნდა იყოს პარალელურად. თუ თქვენი განლაგება თანმიმდევრულია, მაშინ ყველაფერი ცუდია. ერთი სერვერი ნორმალურია, მთელი დღე ათასნახევარ სერვერს დააყენებთ.
- Опять же, для ускорения, это уже необязательно, наверное. При десплоее обычно выполняется сборка проекта. Есть у вас веб-проект, есть фронтенд-часть (вы там делаете веб-пак, npm собираете – что-то такое), и это этот процесс в принципе недолгий – минут 5, но эти 5 минут могут быть критичными. Поэтому мы, например, так не делаем: мы эти 5 минут убрали, мы деплоим артефакты.
რა არის არტეფაქტი? არტეფაქტი არის აწყობილი ნაგებობა, რომელშიც ყველა ასამბლეის ნაწილი უკვე დასრულებულია. ჩვენ ვინახავთ ამ არტეფაქტს არტეფაქტის საცავში. ერთ დროს ჩვენ ვიყენებდით ორ ასეთ საცავს - ეს იყო Nexus და ახლა jFrog Artifactory) თავდაპირველად ვიყენებდით Nexus-ს, რადგან დავიწყეთ ამ მიდგომის პრაქტიკა java აპლიკაციებში (მას კარგად შეეფერებოდა). შემდეგ PHP-ში დაწერილი აპლიკაციები ჩასვეს იქ; და "Nexus" აღარ იყო შესაფერისი და ამიტომ ავირჩიეთ jFrog Artefactory, რომელსაც შეუძლია თითქმის ყველაფრის არტიფაქტორიზაცია. ჩვენ იქამდეც მივედით, რომ ამ არტეფაქტის საცავში ჩვენ ვინახავთ საკუთარ ბინარულ პაკეტებს, რომლებსაც ვაგროვებთ სერვერებისთვის.
ფეთქებადი დატვირთვის ზრდა
ჩვენ ვისაუბრეთ პროგრამული უზრუნველყოფის ვერსიის შეცვლაზე. შემდეგი რაც გვაქვს არის დატვირთვის ფეთქებადი ზრდა. აქ, ალბათ, ვგულისხმობ დატვირთვის ფეთქებადი ზრდას, რაც არ არის სწორი...
ჩვენ დავწერეთ ახალი სისტემა - სერვისზე ორიენტირებული, მოდური, ლამაზი, ყველგან მუშები, ყველგან რიგები, ყველგან ასინქრონული. და ასეთ სისტემებში მონაცემების გადინება შესაძლებელია სხვადასხვა ნაკადების მეშვეობით. პირველი ტრანზაქციისთვის შეიძლება გამოყენებულ იქნას 1-ლი, მე-3, მე-10 მუშაკი, მეორე ტრანზაქციისთვის - მე-2, მე-4, მე-5. და დღეს, ვთქვათ, დილით თქვენ გაქვთ მონაცემთა ნაკადი, რომელიც იყენებს პირველ სამ მუშაკს, საღამოს კი ის მკვეთრად იცვლება და ყველაფერი იყენებს დანარჩენ სამ მუშაკს.
და აქ ირკვევა, რომ თქვენ გჭირდებათ როგორმე გააფართოვოთ მუშები, თქვენ უნდა როგორმე გააფართოვოთ თქვენი სერვისები, მაგრამ ამავე დროს თავიდან აიცილოთ რესურსების გაფუჭება.
ჩვენ განვსაზღვრეთ ჩვენი მოთხოვნები. ეს მოთხოვნები საკმაოდ მარტივია: არსებობდეს სერვისის აღმოჩენა, პარამეტრიზაცია - ყველაფერი სტანდარტულია ასეთი მასშტაბირებადი სისტემების შესაქმნელად, გარდა ერთი წერტილისა - რესურსის ცვეთა. ჩვენ ვთქვით, რომ არ ვართ მზად რესურსების ამორტიზაციისთვის, რათა სერვერებმა ჰაერი გაათბო. ავიღეთ „კონსული“, ავიღეთ „ნომადი“, რომელიც ჩვენს მუშებს მართავს.რატომ არის ეს ჩვენთვის პრობლემა? ცოტა უკან დავიხიოთ. ახლა ჩვენ გვაქვს დაახლოებით 70 გადახდის სისტემა. დილით, ტრაფიკი გადის სბერბანკში, შემდეგ სბერბანკი დაეცა, მაგალითად, და ჩვენ მას გადავდივართ სხვა გადახდის სისტემაზე. სბერბანკამდე გვყავდა 100 თანამშრომელი და ამის შემდეგ მკვეთრად უნდა გავზარდოთ 100 თანამშრომელი სხვა გადახდის სისტემისთვის. და სასურველია ეს ყველაფერი ადამიანის მონაწილეობის გარეშე მოხდეს. იმის გამო, რომ თუ არის ადამიანის მონაწილეობა, იქ უნდა იჯდეს ინჟინერი 24/7, რომელიც მხოლოდ ამას უნდა აკეთებდეს, რადგან ასეთი ჩავარდნები, როცა 70 სისტემა უკან გრჩება, რეგულარულად ხდება.
ამიტომ, ჩვენ გადავხედეთ Nomad-ს, რომელსაც აქვს ღია IP და დავწერეთ ჩვენი საკუთარი ნივთი, Scale-Nomad - ScaleNo, რომელიც დაახლოებით შემდეგს აკეთებს: აკონტროლებს რიგის ზრდას და ამცირებს ან ზრდის მუშაკთა რაოდენობას დინამიკის მიხედვით. რიგის. როდესაც ეს გავაკეთეთ, ვფიქრობდით: "იქნებ ჩვენ შეგვიძლია მისი გახსნა?" მერე შეხედეს – ორი კაპიკივით უბრალო იყო.
ჯერჯერობით ღია წყარო არ გვქონია, მაგრამ თუ მოულოდნელად მოხსენების შემდეგ, როცა მიხვდები, რომ ასეთი რამ გჭირდება, გჭირდება, ჩემი კონტაქტები ბოლო სლაიდშია - გთხოვთ მომწეროთ. თუ 3-5 კაცი მაინც იქნება, დავაფინანსებთ.
Როგორ მუშაობს? მოდით შევხედოთ! წინსვლა: მარცხენა მხარეს არის ჩვენი მონიტორინგის ნაწილი: ეს არის ერთი ხაზი, ზედა არის ღონისძიების დამუშავების დრო, შუაში არის ტრანზაქციების რაოდენობა, ბოლოში არის მუშაკთა რაოდენობა.თუ დააკვირდებით, ამ სურათზე არის ხარვეზი. ზედა ჩარტზე ერთ-ერთი ჩარტი 45 წამში ჩამოიშალა - ერთ-ერთი გადახდის სისტემა დაეცა. მაშინვე 2 წუთში შემოვიდა ტრაფიკი და რიგის ზრდა დაიწყო სხვა გადახდის სისტემაზე, სადაც მუშები არ იყვნენ (რესურსები არ გამოვიყენეთ - პირიქით, რესურსი სწორად განვკარგეთ). გათბობა არ გვინდოდა - იყო მინიმალური რაოდენობა, დაახლოებით 5-10 მუშა, მაგრამ ვერ გაართვეს თავი.
ბოლო გრაფიკზე ნაჩვენებია "კეხი", რაც მხოლოდ იმას ნიშნავს, რომ "სკალენომ" ეს თანხა გააორმაგა. შემდეგ კი, როდესაც გრაფიკი ოდნავ დაეცა, მან ოდნავ შეამცირა - მუშების რაოდენობა ავტომატურად შეიცვალა. ასე მუშაობს ეს საქმე. ჩვენ ვისაუბრეთ მე -2 პუნქტზე - "როგორ სწრაფად მოვიშოროთ მიზეზები".
Მონიტორინგი. როგორ სწრაფად ამოვიცნოთ პრობლემა?
ახლა პირველი წერტილი არის "როგორ სწრაფად ამოვიცნოთ პრობლემა?" Მონიტორინგი! რაღაცეები სწრაფად უნდა გავიგოთ. რა უნდა გავიგოთ სწრაფად?
სამი რამ!- Мы должны быстро понимать и быстро понимать работоспособность наших собственных ресурсов.
- ჩვენ სწრაფად უნდა გავიგოთ წარუმატებლობები და გავაკონტროლოთ ჩვენთვის გარე სისტემების მუშაობა.
- Третий пункт – выявление логических ошибок. Это когда система работает у вас, по всем показателям всё норм, но происходит что-то не так.
აქ ალბათ მაგარ რამეს არ გეტყვი. მე ვიქნები კაპიტანი აშკარა. ჩვენ ვეძებდით რა იყო ბაზარზე. ჩვენ გვაქვს "მხიარული ზოოპარკი". აი ასეთი ზოოპარკი გვაქვს ახლა:
ჩვენ ვიყენებთ Zabbix-ს აპარატურის მონიტორინგისთვის, სერვერების ძირითადი ინდიკატორების მონიტორინგისთვის. ჩვენ ვიყენებთ Okmeter-ს მონაცემთა ბაზებისთვის. ჩვენ ვიყენებთ "Grafana" და "Prometheus" ყველა სხვა ინდიკატორისთვის, რომლებიც არ შეესაბამება პირველ ორს, ზოგიერთი "Grafana" და "Prometheus", და ზოგიერთი "Grafana" ერთად "Influx" და Telegraf.Год назад мы хотели использовать New Relic. Классная штука, она умеет всё. Но насколько она всё умеет, настолько она и дорогая. Когда мы выросли до объёма в 1,5 тысячи серверов, к нам пришёл вендор, сказал: «Давайте заключать договор на следующий год». Мы посмотрели на цену, что нет, мы так делать не будем. Сейчас мы от «Нью-Релика» отказываемся, у нас около 15 серверов осталось под мониторингом «Нью-Релика». Цена оказалась совершенно дикой.
И есть один инструмент, который мы реализовали сами – это Debugger. Сначала мы его назвали «Баггер», но потом прошёл у нас учитель английского, дико засмеялся, и переназвали на «Дебаггер». Что это такое? Это инструмент, который по факту в 15-30 секунд на каждом компоненте, как «чёрный ящик» системы, запускает тесты на общую работоспособность компонента.
მაგალითად, თუ არის გარე გვერდი (გადახდის გვერდი), ის უბრალოდ ხსნის მას და უყურებს როგორ უნდა გამოიყურებოდეს. თუ ეს მუშავდება, ის აგზავნის სატესტო „ტრანზაქციას“ და დარწმუნდება, რომ ეს „ტრანზაქცია“ მოვა. თუ ეს არის კავშირი გადახდის სისტემებთან, ჩვენ შესაბამისად ვგზავნით სატესტო მოთხოვნას, სადაც შეგვიძლია, და ვხედავთ, რომ ჩვენთან ყველაფერი კარგადაა.
რა ინდიკატორებია მნიშვნელოვანი მონიტორინგისთვის?
რას ვაკვირდებით ძირითადად? რა მაჩვენებლებია ჩვენთვის მნიშვნელოვანი?
- Response time / RPS на фронтах – очень важный показатель. Он сразу отвечает, что у вас что-то не так.
- დამუშავებული შეტყობინებების რაოდენობა ყველა რიგში.
- მუშაკთა რაოდენობა.
- Основные метрики корректности.
ბოლო წერტილი არის "ბიზნესი", "ბიზნესი" მეტრიკა. თუ გსურთ ერთი და იგივეს მონიტორინგი, თქვენ უნდა განსაზღვროთ ერთი ან ორი მეტრიკა, რომელიც თქვენთვის მთავარი ინდიკატორია. ჩვენი მეტრიკა არის გამტარუნარიანობა (ეს არის წარმატებული ტრანზაქციის რაოდენობის თანაფარდობა ტრანზაქციის მთლიან ნაკადთან). თუ მასში რაღაც იცვლება 5-10-15 წუთის ინტერვალით, ეს ნიშნავს, რომ პრობლემები გვაქვს (თუ რადიკალურად იცვლება).
როგორ გამოიყურება ჩვენთვის, არის ჩვენი ერთ-ერთი დაფის მაგალითი:
მარცხენა მხარეს არის 6 გრაფიკი, ეს არის ხაზების მიხედვით - მუშათა რაოდენობა და რიგებში შეტყობინებების რაოდენობა. მარჯვენა მხარეს - RPS, RTS. ქვემოთ მოცემულია იგივე "ბიზნესის" მეტრიკა. და "ბიზნესის" მეტრიკაში ჩვენ შეგვიძლია დაუყოვნებლივ დავინახოთ, რომ რაღაც არასწორი იყო ორ შუა გრაფიკში... ეს არის კიდევ ერთი სისტემა, რომელიც ჩვენს უკან დგას და დაეცა.მეორე, რაც უნდა გაგვეკეთებინა, იყო გარე გადახდის სისტემების დაცემის მონიტორინგი. აქ ავიღეთ OpenTracing - მექანიზმი, სტანდარტი, პარადიგმა, რომელიც განაწილებული სისტემების კვალიფიკაციის საშუალებას გაძლევთ; და ცოტა შეიცვალა. სტანდარტული OpenTracing პარადიგმა ამბობს, რომ ჩვენ ვაშენებთ კვალს თითოეული ინდივიდუალური მოთხოვნისთვის. ჩვენ ეს არ გვჭირდებოდა და შემაჯამებელ, აგრეგაციის კვალში შევახვიეთ. ჩვენ გავაკეთეთ ინსტრუმენტი, რომელიც საშუალებას გვაძლევს თვალყური ადევნოთ ჩვენს უკან არსებული სისტემების სიჩქარეს.
გრაფიკი გვიჩვენებს, რომ ერთ-ერთმა გადახდის სისტემამ 3 წამში დაიწყო რეაგირება - პრობლემები გვაქვს. უფრო მეტიც, ეს ნივთი რეაგირებს პრობლემების დაწყებისას, 20-30 წამის ინტერვალით.და მონიტორინგის შეცდომების მესამე კლასი, რომელიც არსებობს, არის ლოგიკური მონიტორინგი.
Честно говоря, не знал, что на этом слайде нарисовать, потому что мы искали долго на рынке то, что нам подойдёт. Ничего не нашли, поэтому пришлось делать самим.
რას ვგულისხმობ ლოგიკურ მონიტორინგში? აბა, წარმოიდგინეთ: თქვენ თავად ქმნით სისტემას (მაგალითად, Tinder-ის კლონს); შენ გააკეთე, გაუშვი. წარმატებულმა მენეჯერმა ვასია პუპკინმა ტელეფონზე დადო, იქ ხედავს გოგონას, მოსწონს... და მსგავსი არ მიდის გოგონას - მსგავსი მიდის დაცვის თანამშრომელ მიხალიჩთან იმავე ბიზნეს ცენტრიდან. მენეჯერი ჩადის დაბლა და შემდეგ აინტერესებს: "რატომ ეღიმება მას ასე სასიამოვნოდ ეს დაცვის თანამშრომელი მიხალიჩი?"ასეთ სიტუაციებში... ჩვენთვის ეს სიტუაცია ცოტა სხვანაირად ჟღერს, რადგან (მე დავწერე) ეს არის რეპუტაციის დაკარგვა, რომელიც ირიბად იწვევს ფინანსურ ზარალს. ჩვენი მდგომარეობა საპირისპიროა: შეიძლება განვიცადოთ პირდაპირი ფინანსური ზარალი - მაგალითად, თუ ტრანზაქცია განვახორციელეთ წარმატებული, მაგრამ წარუმატებელი (ან პირიქით). მე მომიწია დამეწერა საკუთარი ხელსაწყო, რომელიც აკონტროლებს წარმატებულ ტრანზაქციებს დროთა განმავლობაში ბიზნეს ინდიკატორების გამოყენებით. ბაზარში ვერაფერი ვიპოვე! ეს არის ზუსტად ის იდეა, რისი გადმოცემაც მინდოდა. ბაზარზე არაფერია ამ პრობლემის გადასაჭრელად.
Это было к вопросу о том, как быстро выявить проблему.
როგორ განვსაზღვროთ განლაგების მიზეზები
პრობლემების მესამე ჯგუფი, რომელსაც ჩვენ ვხსნით, არის პრობლემის იდენტიფიცირების შემდეგ, მას შემდეგ რაც მოვიშორებთ, კარგი იქნება გავიგოთ განვითარების მიზეზი, ტესტირება და რამე გავაკეთოთ. შესაბამისად, უნდა გამოვიკვლიოთ, უნდა ავწიოთ მორები.
Если мы говорим про логи (основная причина – логи), основная часть логов у нас в ELK Stack – практически у всех так. У кого-то, можем, не в ELK, но если вы пишите логи гигабайтами, то рано или поздно придёте к ELK. Мы пишем их терабайтами.
Здесь есть проблема. Мы пофиксили, исправили для пользователя ошибку, начали раскапывать, что же там было такое, залезли в «Кибану», ввели там id-шник транзакции и получили вот такую портянку (показывает много). И в этой портянке непонятно ничего ровным счётом. Почему? Да потому что непонятно, какая часть относится к какому воркеру, какая часть относится к какому компоненту. И в этот момент мы поняли, что нам нужна трассировка – та самая OpenTracing, о которой я говорил.ეს ერთი წლის წინ ვიფიქრეთ, ყურადღება მივაქციეთ ბაზარს და იქ იყო ორი ინსტრუმენტი - "ზიპკინი" და "იაგერი". „იაგერი“ სინამდვილეში სწორედ ასეთი იდეოლოგიური მემკვიდრეა, „ზიპკინის“ იდეოლოგიური მემკვიდრე. Zipkin-ში ყველაფერი კარგია, გარდა იმისა, რომ არ იცის აგრეგაცია, არ იცის ლოგების ჩართვა კვალში, მხოლოდ დროის კვალი. და "ჯაგერმა" მხარი დაუჭირა ამას.
ჩვენ გადავხედეთ "Jager"-ს: შეგიძლიათ ინსტრუმენტული აპლიკაციები, შეგიძლიათ დაწეროთ Api-ში (აპი სტანდარტი PHP-სთვის იმ დროს, თუმცა, არ იყო დამტკიცებული - ეს იყო ერთი წლის წინ, მაგრამ ახლა უკვე დამტკიცებულია), მაგრამ იქ აბსოლუტურად არ იყო კლიენტი. "კარგი", - გავიფიქრეთ და ჩვენს კლიენტს მივწერეთ. რა მივიღეთ? დაახლოებით ასე გამოიყურება:
Jaeger-ში სპანები იქმნება თითოეული შეტყობინებისთვის. ანუ, როდესაც მომხმარებელი ხსნის სისტემას, ის ხედავს ერთ ან ორ ბლოკს თითოეული შემომავალი მოთხოვნისთვის (1-2-3 - მომხმარებლისგან შემოსული მოთხოვნების რაოდენობა, ბლოკების რაოდენობა). მომხმარებლებისთვის გასაადვილებლად, ჩვენ დავამატეთ ტეგები ჟურნალებსა და დროის კვალზე. შესაბამისად, შეცდომის შემთხვევაში, ჩვენი აპლიკაცია მონიშნავს ჟურნალს შესაბამისი Error tag-ით. თქვენ შეგიძლიათ გაფილტროთ შეცდომის ტეგით და ნაჩვენები იქნება მხოლოდ ბლოკები, რომლებიც შეცდომით შეიცავს ამ ბლოკს. ასე გამოიყურება, თუ გავაფართოვებთ დიაპაზონს:
Внутри спана есть набор трейсов. В данном случае это три тестовых трейса, и третий трейс говорит нам о том, что произошла ошибка. При этом здесь же мы видим временную трассировку: у нас сверху – временная шкала, и мы видим, на каком временном интервале у нас тот или иной лог был записан.შესაბამისად, ჩვენთვის საქმეები კარგად წავიდა. ჩვენ დავწერეთ ჩვენი საკუთარი გაფართოება და ჩვენ ის ღია წყაროებით შევქმენით. თუ გსურთ ტრასირებასთან მუშაობა, თუ გსურთ "Jager"-თან მუშაობა PHP-ში, არის ჩვენი გაფართოება, კეთილი იყოს თქვენი მობრძანება, როგორც ამბობენ:
ჩვენ გვაქვს ეს გაფართოება - ის არის კლიენტი OpenTracing Api-სთვის, ის მზადდება როგორც php-extence, ანუ დაგჭირდებათ მისი აწყობა და სისტემაზე ინსტალაცია. ერთი წლის წინ სხვა არაფერი იყო. ახლა არის სხვა კლიენტები, რომლებიც კომპონენტების მსგავსია. აქ ყველაფერი თქვენზეა დამოკიდებული: ან კომპოზიტორთან ერთად ამოიყვანთ კომპონენტებს, ან თქვენ იყენებთ გაფართოებას.კორპორატიული სტანდარტები
ვისაუბრეთ სამ მცნებაზე. მეოთხე მცნება არის მიდგომების სტანდარტიზაცია. Რაზეა? საუბარია ამაზე:
რატომ არის აქ სიტყვა "კორპორატიული"? არა იმიტომ, რომ ჩვენ ვართ დიდი ან ბიუროკრატიული კომპანია, არა! მე მინდოდა გამომეყენებინა სიტყვა „კორპორატიული“ აქ იმ კონტექსტში, რომ ყველა კომპანიას, ყველა პროდუქტს უნდა ჰქონდეს თავისი სტანდარტები, მათ შორის თქვენც. რა სტანდარტები გვაქვს?
- У нас есть регламент деплоеев. Мы без него никуда не движемся, не можем. Деплоимся мы порядка 60 раз в неделю, то есть у нас деплои происходят практически постоянно. При этом у нас есть, например, в регламенте деплоеев табу на деплои в пятницу – принципе, мы не деплоимся.
- ჩვენ ვითხოვთ დოკუმენტაციას. არც ერთი ახალი კომპონენტი არ შედის წარმოებაში, თუ არ არსებობს დოკუმენტაცია, თუნდაც ის დაბადებული იყოს ჩვენი RnD სპეციალისტების კალმის ქვეშ. ჩვენ მათგან ვითხოვთ განლაგების ინსტრუქციებს, მონიტორინგის რუკას და უხეშ აღწერას (როგორც პროგრამისტებს შეუძლიათ დაწერონ) როგორ მუშაობს ეს კომპონენტი, როგორ მოვაგვაროთ ის.
- ჩვენ ვხსნით არა პრობლემის მიზეზს, არამედ პრობლემას - რაც უკვე ვთქვი. ჩვენთვის მნიშვნელოვანია, დავიცვათ მომხმარებელი პრობლემებისგან.
- ჩვენ გვაქვს ნებართვები. მაგალითად, ჩვენ არ განვიხილავთ შეფერხების პერიოდს, თუ ორი წუთის განმავლობაში დავკარგეთ ტრაფიკის 2%. ეს ძირითადად არ შედის ჩვენს სტატისტიკაში. თუ პროცენტულად მეტია თუ დროებითი, უკვე ვითვლით.
- და ჩვენ ყოველთვის ვწერთ პოსტმოკვიდებს. რაც არ უნდა მოხდეს ჩვენთან, ნებისმიერი სიტუაცია, როდესაც ვინმე წარმოებისას არანორმალურად იქცეოდა, აისახება სიკვდილის შემდგომ. პოსტმორტემი არის დოკუმენტი, რომელშიც წერთ იმას, რაც დაგემართათ, დეტალურ ვადებს, რა გააკეთეთ მის გამოსასწორებლად და (ეს სავალდებულო ბლოკია!) რას გააკეთებთ, რომ ეს მომავალში არ მოხდეს. ეს სავალდებულოა და აუცილებელია შემდგომი ანალიზისთვის.
რა ითვლება შესვენების დროდ?
რას მოჰყვა ეს ყველაფერი?ამან განაპირობა ის, რომ (ჩვენ გვქონდა გარკვეული პრობლემები სტაბილურობასთან დაკავშირებით, ეს არ აწყობდა არც კლიენტებს და არც ჩვენ) ბოლო 6 თვის განმავლობაში ჩვენი სტაბილურობის მაჩვენებელი იყო 99,97. შეიძლება ითქვას, რომ ეს არც ისე ბევრია. დიახ, ჩვენ გვაქვს რაღაც, რისთვისაც უნდა ვისწრაფოდეთ. ამ მაჩვენებლის დაახლოებით ნახევარი არის სტაბილურობა, როგორც ეს იყო, არა ჩვენი, არამედ ჩვენი ვებ აპლიკაციის firewall-ი, რომელიც ჩვენს წინ დგას და გამოიყენება როგორც სერვისი, მაგრამ კლიენტებს ეს არ აინტერესებთ.
ღამით ძილი ვისწავლეთ. ბოლოს და ბოლოს! ექვსი თვის წინ ვერ შევძელით. და ამ შენიშვნაზე, შედეგებთან ერთად, მინდა ერთი შენიშვნა გავაკეთო. წუხელ იყო შესანიშნავი მოხსენება ბირთვული რეაქტორის მართვის სისტემის შესახებ. თუ მათ, ვინც დაწერეს ეს სისტემა, შეუძლიათ ჩემი მოსმენა, გთხოვთ დაივიწყოთ ის, რაც მე ვთქვი "2% არ არის შესვენება". შენთვის 2% არის შესვენება, თუნდაც ორი წუთით!
Სულ ეს არის! თქვენი კითხვები.
ბალანსერებისა და მონაცემთა ბაზის მიგრაციის შესახებ
Вопрос из аудитории (далее – В): – Добрый вечер. Спасибо большое за такой админский доклад! Вопрос коротенький, на тему ваших балансировщиков. Вы обмолвились, что у вас есть WAF, то есть, как я понимаю в качестве балансировщика вы используете какой-то внешний…
EK: – არა, ჩვენ ვიყენებთ ჩვენს სერვისებს, როგორც ბალანსის შემსრულებელი. ამ შემთხვევაში, WAF არის ჩვენთვის ექსკლუზიურად DDoS დაცვის ინსტრუმენტი.
In: – შეგიძლიათ ორიოდე სიტყვა თქვათ ბალანსერებზე?
EK: – როგორც უკვე ვთქვი, ეს არის სერვერების ჯგუფი openresty-ში. ჩვენ ახლა გვაქვს 5 სარეზერვო ჯგუფი, რომლებიც რეაგირებენ ექსკლუზიურად... ანუ სერვერი, რომელიც მუშაობს ექსკლუზიურად openresty, ის მხოლოდ მარიონეტულ ტრაფიკს ახორციელებს. შესაბამისად, იმის გასაგებად, თუ რამდენს ვფლობთ: ახლა გვაქვს რამდენიმე ასეული მეგაბიტიანი ტრაფიკის რეგულარული ნაკადი. თავს ართმევენ თავს, თავს კარგად გრძნობენ, თავსაც არ იძაბებიან.
In: - ასევე მარტივი კითხვა. აქ არის ლურჯი/მწვანე განლაგება. რას აკეთებთ, მაგალითად, მონაცემთა ბაზის მიგრაციასთან?
EK: - კარგი კითხვაა! შეხედეთ, ლურჯი/მწვანე განლაგებისას ჩვენ გვაქვს ცალკე რიგები თითოეული ხაზისთვის. ანუ, თუ ვსაუბრობთ მოვლენის რიგებზე, რომლებიც გადაეცემა მუშაკიდან მუშაკს, არის ცალკე რიგები ლურჯი ხაზისთვის და მწვანე ხაზისთვის. თუ ჩვენ ვსაუბრობთ თავად მონაცემთა ბაზაზე, მაშინ ჩვენ შეგნებულად შევამცირეთ ის, როგორც შეგვეძლო, გადავიტანეთ ყველაფერი პრაქტიკულად რიგებში; მონაცემთა ბაზაში მხოლოდ ტრანზაქციების დასტას ვინახავთ. და ჩვენი ტრანზაქციის სტეკი ყველა ხაზისთვის ერთნაირია. მონაცემთა ბაზა ამ კონტექსტში: ჩვენ არ ვყოფთ მას ლურჯ და მწვანედ, რადგან კოდის ორივე ვერსიამ უნდა იცოდეს რა ხდება ტრანზაქციასთან დაკავშირებით.
მეგობრებო, მეც მაქვს პატარა პრიზი, რომ წაგვეშუროთ - წიგნი. და საუკეთესო კითხვისთვის უნდა დაჯილდოვდეს.
In: - გამარჯობა. მადლობა მოხსენებისთვის. კითხვა არის ეს. თქვენ ადევნებთ თვალყურს გადახდებს, აკვირდებით იმ სერვისებს, რომლებთანაც ურთიერთობთ... მაგრამ როგორ ახორციელებთ მონიტორინგს, რომ ადამიანი როგორმე შემოვიდეს თქვენს გადახდის გვერდზე, განახორციელოს გადახდა და პროექტმა მას ფული დაურიცხოს? ანუ, როგორ აკვირდებით, რომ მარშანტი ხელმისაწვდომია და დაეთანხმა თქვენს გამოძახებას?
EK: – „მერჩანტი“ ჩვენთვის ამ შემთხვევაში არის ზუსტად იგივე გარე სერვისი, როგორც გადახდის სისტემა. ჩვენ ვაკვირდებით მოვაჭრის რეაგირების სიჩქარეს.
მონაცემთა ბაზის დაშიფვრის შესახებ
In: - გამარჯობა. ცოტა დაკავშირებული კითხვა მაქვს. თქვენ გაქვთ PCI DSS მგრძნობიარე მონაცემები. მინდოდა გამეგო, როგორ ინახავთ PAN-ებს რიგებში, რომლებშიც უნდა გადაიტანოთ? იყენებთ რაიმე დაშიფვრას? და ეს იწვევს მეორე კითხვას: PCI DSS-ის მიხედვით, ცვლილებების შემთხვევაში (ადმინისტრატორების გათავისუფლება და ა.შ.) პერიოდულად საჭიროა მონაცემთა ბაზის ხელახალი დაშიფვრა - რა ბედი ეწევა ხელმისაწვდომობას ამ შემთხვევაში?
EK: - მშვენიერი კითხვაა! პირველ რიგში, ჩვენ არ ვინახავთ PAN-ებს რიგებში. ჩვენ არ გვაქვს უფლება არსად შევინახოთ PAN მკაფიო ფორმით, პრინციპში, ამიტომ ვიყენებთ სპეციალურ სერვისს (ჩვენ მას "კადემონს" ვუწოდებთ) - ეს არის სერვისი, რომელიც აკეთებს მხოლოდ ერთს: ის იღებს შეტყობინებას შეყვანის სახით და აგზავნის. ამოიღეთ დაშიფრული შეტყობინება. და ჩვენ ყველაფერს ვინახავთ ამ დაშიფრული გზავნილით. შესაბამისად, ჩვენი გასაღების სიგრძე კილობაიტზე ნაკლებია, ასე რომ ეს სერიოზული და საიმედოა.In: – Сейчас уже 2 килобайта надо?
EK: – Вроде ещё вчера было 256… Ну куда ещё?!
შესაბამისად, ეს არის პირველი. და მეორეც, გამოსავალი, რომელიც არსებობს, მხარს უჭერს ხელახალი დაშიფვრის პროცედურას - არის ორი წყვილი "კექსი" (გასაღებები), რომლებიც იძლევა "გემბანებს", რომლებიც შიფრავს (გასაღები არის გასაღებები, dek არის გასაღებების წარმოებულები, რომლებიც შიფრავს) . და თუ პროცედურა დაწყებულია (ეს ხდება რეგულარულად, 3 თვიდან ± ზოგიერთამდე), ჩვენ ვტვირთავთ ახალ წყვილ „ტორტებს“ და ხელახლა ვაშიფრავთ მონაცემებს. ჩვენ გვაქვს ცალკეული სერვისები, რომლებიც ამოიღებს ყველა მონაცემს და დაშიფვრავს მათ ახლებურად; მონაცემები ინახება გასაღების იდენტიფიკატორის გვერდით, რომლითაც ის დაშიფრულია. შესაბამისად, როგორც კი დავშიფრავთ მონაცემებს ახალი კლავიშებით, ვშლით ძველ გასაღებს.
ზოგჯერ გადახდები ხელით უნდა განხორციელდეს...
In: – ანუ, თუ რაიმე ოპერაციისთვის თანხა დაბრუნდა, ისევ ძველი გასაღებით გაშიფრავთ?
EK: - დიახ.
In: - მაშინ კიდევ ერთი პატარა კითხვა. როდესაც რაიმე სახის მარცხი, დაცემა ან ინციდენტი ხდება, აუცილებელია ტრანზაქციის ხელით გატარება. არის ასეთი სიტუაცია.
EK: - Დიახ ზოგჯერ.
In: - საიდან გაქვთ ეს მონაცემები? ან თავად დადიხართ ამ საწყობში?
EK: – არა, კარგი, რა თქმა უნდა, ჩვენ გვაქვს რაიმე სახის back-office სისტემა, რომელიც შეიცავს ჩვენი მხარდაჭერის ინტერფეისს. თუ არ ვიცით, რა სტატუსით არის ტრანზაქცია (მაგალითად, სანამ გადახდის სისტემა არ უპასუხა თაიმაუტით), აპრიორი არ ვიცით, ანუ საბოლოო სტატუსს მხოლოდ სრული ნდობით ვანიჭებთ. ამ შემთხვევაში ჩვენ ტრანზაქციას ვანიჭებთ სპეციალურ სტატუსს ხელით დამუშავებისთვის. დილით, მეორე დღეს, როგორც კი მხარდაჭერა მიიღებს ინფორმაციას, რომ ასეთი და ასეთი ტრანზაქციები რჩება გადახდის სისტემაში, ისინი ხელით ამუშავებენ მათ ამ ინტერფეისში.
In: - ორიოდე კითხვა მაქვს. ერთ-ერთი მათგანია PCI DSS ზონის გაგრძელება: როგორ ხდება მათი ჩართვა? ეს კითხვა იმიტომ არის, რომ დეველოპერს შეეძლო რაიმე ჩაეტანა ჟურნალებში! მეორე შეკითხვა: როგორ გამოვაქვეყნოთ ცხელი შესწორებები? მონაცემთა ბაზაში სახელურების გამოყენება ერთი ვარიანტია, მაგრამ შეიძლება იყოს უფასო ცხელი შესწორებები - რა პროცედურაა იქ? და მესამე კითხვა, ალბათ, დაკავშირებულია RTO, RPO-სთან. თქვენი ხელმისაწვდომობა იყო 99,97, თითქმის ოთხი ცხრა, მაგრამ როგორც მე მესმის, თქვენ გაქვთ მეორე მონაცემთა ცენტრი, მესამე მონაცემთა ცენტრი და მეხუთე მონაცემთა ცენტრი... როგორ ახდენთ მათ სინქრონიზაციას, ტირაჟირებას და სხვა ყველაფერს?EK: - დავიწყოთ პირველით. პირველი შეკითხვა იყო ლოგის შესახებ? როდესაც ვწერთ ჟურნალებს, გვაქვს ფენა, რომელიც ნიღბავს ყველა მგრძნობიარე მონაცემს. ის უყურებს ნიღაბს და დამატებით ველებს. შესაბამისად, ჩვენი ჟურნალები გამოდის უკვე ნიღბიანი მონაცემებით და PCI DSS სქემით. ეს არის ერთ-ერთი რეგულარული დავალება, რომელიც აკისრია ტესტირების განყოფილებას. მათ მოეთხოვებათ შეამოწმონ თითოეული დავალება, მათ შორის ჩანაწერები, რომლებსაც ისინი წერენ, და ეს არის ერთ-ერთი რეგულარული დავალება კოდის განხილვის დროს, რათა გააკონტროლონ, რომ დეველოპერმა არ დაწერა რაიმე. ამის შემდგომი შემოწმებები რეგულარულად ტარდება საინფორმაციო უსაფრთხოების დეპარტამენტის მიერ კვირაში ერთხელ: ბოლო დღის ჟურნალები შერჩევით არის აღებული და ისინი გადის სპეციალური სკანერ-ანალიზატორის მეშვეობით სატესტო სერვერებიდან ყველაფრის შესამოწმებლად.
ცხელი გამოსწორების შესახებ. ეს შედის ჩვენი განლაგების წესებში. ჩვენ გვაქვს ცალკე პუნქტი ცხელი შესწორებების შესახებ. ჩვენ გვჯერა, რომ ჩვენ ვაყენებთ ცხელ გამოსწორებებს მთელი საათის განმავლობაში, როდესაც ეს გვჭირდება. ვერსიის აწყობისთანავე, გაშვებისთანავე, როგორც კი გვექნება არტეფაქტი, ჩვენ გვყავს მორიგე სისტემის ადმინისტრატორი მხარდაჭერის გამოძახებით და ის განათავსებს მას იმ მომენტში, როდესაც ეს აუცილებელია.დაახლოებით "ოთხი ცხრა". ის ფიგურა, რომელიც ახლა გვაქვს, ნამდვილად მიღწეულია და ჩვენ მისკენ ვისწრაფვით სხვა მონაცემთა ცენტრში. ახლა ჩვენ გვაქვს მეორე მონაცემთა ცენტრი და ვიწყებთ მათ შორის მარშრუტს და მონაცემთა ჯვარედინი ცენტრის რეპლიკაციის საკითხი ნამდვილად არა ტრივიალური საკითხია. ჩვენ შევეცადეთ მისი მოგვარება ერთდროულად სხვადასხვა საშუალებების გამოყენებით: ჩვენ ვეცადეთ გამოგვეყენებინა იგივე "ტარანტულა" - ეს არ გამოგვივიდა, მაშინვე გეტყვით. სწორედ ამიტომ დავასრულეთ „სენსების“ ხელით შეკვეთა. სინამდვილეში, ჩვენს სისტემაში თითოეული აპლიკაცია ასინქრონულად აწარმოებს აუცილებელ "ცვლილება - შესრულებული" სინქრონიზაციას მონაცემთა ცენტრებს შორის.
In: - თუ მეორე მიიღეთ, მესამე რატომ არ მიიღეთ? იმიტომ რომ ტვინი ჯერ არავის აქვს გაყოფილი...
EK: – А у нас нет «Сплит-брейна». Из-за того, что каждое приложение у нас гоняет мультимастер, нам не важно, в какой центр пришёл запрос. Мы готовы к тому, что, в случае, если у нас один дата-центр упал (мы на это закладываемся) и в середине запроса пользователя переключил на второй дата-центр, мы готовы потерять этого пользователя, действительно; но это единицы будут, абсолютные единицы.
In: - Საღამო მშვიდობისა. მადლობა მოხსენებისთვის. თქვენ ისაუბრეთ თქვენს გამართვის შესახებ, რომელიც აწარმოებს რამდენიმე სატესტო ტრანზაქციას წარმოებაში. მაგრამ გვითხარით სატესტო ტრანზაქციების შესახებ! რამდენად ღრმად მიდის?
EK: – Оно проходит полный цикл всего компонента. Для компонента нет различий между тестовой транзакцией и боевой. А с точки зрения логики это просто некий отдельный проект в системе, на котором только тестовые транзакции гоняются.
In: – А где вы её отсекаете? Вот Core отправил…
EK: – ჩვენ ამ შემთხვევაში სატესტო ტრანზაქციებზე „კორ“-ს უკან ვდგავართ... ჩვენ გვაქვს მარშრუტიზაცია: „კორმა“ იცის, რომელ გადახდის სისტემას გაუგზავნოს - ჩვენ ვაგზავნით ყალბ გადახდის სისტემას, რომელიც უბრალოდ იძლევა http სიგნალს და სულ ეს არის.
In: – მითხარით, გთხოვთ, თქვენი განაცხადი ერთ უზარმაზარ მონოლითში იყო დაწერილი, თუ დაყავით ის ზოგიერთ სერვისში ან თუნდაც მიკროსერვისში?
EK: – მონოლითი არ გვაქვს, რა თქმა უნდა, გვაქვს სერვისზე ორიენტირებული აპლიკაცია. ჩვენ ვხუმრობთ, რომ ჩვენი სერვისი დამზადებულია მონოლითებისგან - ისინი მართლაც საკმაოდ დიდია. ძნელია მას მიკროსერვისები ვუწოდოთ, მაგრამ ეს არის სერვისები, რომლებშიც მუშაობენ განაწილებული მანქანების მუშები.
თუ სერვერზე სერვისი გატეხილია...
In: - მაშინ მე მაქვს შემდეგი კითხვა. მაშინაც კი, თუ ეს იყო მონოლითი, თქვენ მაინც თქვით, რომ თქვენ გაქვთ მრავალი მყისიერი სერვერი, ისინი ძირითადად ამუშავებენ მონაცემებს და კითხვაა: ”ერთ-ერთი მყისიერი სერვერის ან აპლიკაციის კომპრომისის შემთხვევაში, ნებისმიერი ინდივიდუალური ბმული. , აქვთ რაიმე სახის წვდომის კონტროლი? რომელი მათგანი რისი გაკეთება შეუძლია? ვის უნდა მივმართო რა ინფორმაციისთვის?
EK: - Დიახ აუცილებლად. უსაფრთხოების მოთხოვნები საკმაოდ სერიოზულია. პირველ რიგში, ჩვენ გვაქვს ღია მონაცემთა გადაადგილება და პორტები არის მხოლოდ ის, რომლითაც წინასწარ ველოდებით ტრაფიკის მოძრაობას. თუ კომპონენტი დაუკავშირდება მონაცემთა ბაზას (ვთქვათ, Muskul-თან) 5-4-3-2-ით, მისთვის მხოლოდ 5-4-3-2 იქნება ღია და სხვა პორტები და სხვა სატრანსპორტო მიმართულებები არ იქნება ხელმისაწვდომი. გარდა ამისა, თქვენ უნდა გესმოდეთ, რომ ჩვენს წარმოებაში არის დაახლოებით 10 სხვადასხვა უსაფრთხოების მარყუჟი. და მაშინაც კი, თუ აპლიკაცია რაღაცნაირად კომპრომეტირებული იყო, ღმერთმა ქნას, თავდამსხმელი ვერ შეძლებს სერვერის მართვის კონსოლზე წვდომას, რადგან ეს არის სხვა ქსელის უსაფრთხოების ზონა.In: – და ამ კონტექსტში, ჩემთვის უფრო საინტერესო ის არის, რომ თქვენ გაქვთ გარკვეული კონტრაქტები სამსახურებთან – რისი გაკეთება შეუძლიათ მათ, რა „მოქმედებებით“ შეუძლიათ დაუკავშირდნენ ერთმანეთს... და ნორმალურ დინებაში ზოგიერთი კონკრეტული სერვისი ითხოვს გარკვეულ ნაწილს. რიგი, მეორეზე "მოქმედებების" სია. როგორც ჩანს, ისინი არ მიმართავენ სხვებს ნორმალურ სიტუაციაში და მათ აქვთ პასუხისმგებლობის სხვა სფეროები. თუ რომელიმე მათგანი კომპრომეტირებულია, შეძლებს თუ არა ამ სამსახურის „მოქმედებების“ ჩაშლას?..
EK: - Მე მესმის. თუ ნორმალურ სიტუაციაში სხვა სერვერთან კომუნიკაცია დაშვებული იყო, მაშინ დიახ. SLA ხელშეკრულების მიხედვით, ჩვენ არ ვაკვირდებით, რომ თქვენ მხოლოდ პირველი 3 „მოქმედების“ უფლება გაქვთ და არ გაქვთ 4 „მოქმედება“. ეს ჩვენთვის ალბათ ზედმეტია, რადგან უკვე გვაქვს 4 დონის დაცვის სისტემა, პრინციპში, სქემებისთვის. ჩვენ გვირჩევნია თავი დავიცვათ კონტურებით, ვიდრე შიდა დონეზე.
როგორ მუშაობს Visa, MasterCard და Sberbank
In: – მინდა განვმარტო პუნქტი მომხმარებლის გადართვის ერთი მონაცემთა ცენტრიდან მეორეზე. როგორც ვიცი, Visa და MasterCard მუშაობს 8583 ბინარული სინქრონული პროტოკოლით და იქ არის მიქსები. და მაინტერესებდა, ახლა ვგულისხმობთ გადართვას – ეს პირდაპირ “Visa” და “MasterCard” არის თუ გადახდის სისტემამდე, დამუშავებამდე?
EK: - ეს მიქსების წინ. ჩვენი მიქსები განლაგებულია იმავე მონაცემთა ცენტრში.
In: – უხეშად რომ ვთქვათ, გაქვთ ერთი კავშირის წერტილი?
EK: – „ვიზა“ და „მასტერკარდი“ - დიახ. უბრალოდ იმიტომ, რომ Visa და MasterCard მოითხოვს საკმაოდ სერიოზულ ინვესტიციებს ინფრასტრუქტურაში ცალკე კონტრაქტების გასაფორმებლად, მაგალითად, მეორე წყვილი მიქსების მისაღებად. ისინი რეზერვირებულია ერთ მონაცემთა ცენტრში, მაგრამ თუ ღმერთმა ქნას, ჩვენი მონაცემთა ცენტრი, სადაც არის მიქსები Visa-სა და MasterCard-თან დასაკავშირებლად, დაიღუპება, მაშინ ვიზასთან და MasterCard-თან კავშირი გვექნება დაკარგული...
In: – როგორ შეიძლება მათი დაჯავშნა? ვიცი, რომ Visa პრინციპში მხოლოდ ერთ კავშირს იძლევა!
EK: - აღჭურვილობას თავად აწვდიან. ნებისმიერ შემთხვევაში, ჩვენ მივიღეთ აღჭურვილობა, რომელიც მთლიანად ზედმეტია შიგნით.
In: – То есть стойка от их Connects Orange?..
EK: - დიახ.
In: – მაგრამ რაც შეეხება ამ შემთხვევას: თუ თქვენი მონაცემთა ცენტრი გაქრება, როგორ შეგიძლიათ გააგრძელოთ მისი გამოყენება? ან უბრალოდ ჩერდება მოძრაობა?
EK: - არა. ამ შემთხვევაში ჩვენ უბრალოდ გადავიყვანთ ტრაფიკს სხვა არხზე, რაც, ბუნებრივია, უფრო ძვირი დაგვიჯდება და ჩვენი კლიენტებისთვის. მაგრამ ტრაფიკი არ გაივლის ჩვენი პირდაპირი კავშირით Visa-სთან, MasterCard-თან, არამედ პირობითი Sberbank-ით (ძალიან გადაჭარბებული).
ბოდიშს ვიხდი, თუ სბერბანკის თანამშრომლებს ვაწყენინე. მაგრამ ჩვენი სტატისტიკის მიხედვით, რუსულ ბანკებს შორის, სბერბანკი ყველაზე ხშირად ეცემა. ერთი თვე არ გადის ისე, რომ სბერბანკში რაღაც არ ჩამოვარდეს.
რამდენიმე რეკლამა 🙂
გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, , საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).
Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ
წყარო: www.habr.com