ობოლი სერვისები: (მიკრო)მომსახურების არქიტექტურის უარყოფითი მხარე

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

ჭრილის ქვემოთ მოცემულია მოხსენების ტექსტური ვერსია.

გამარჯობა კოლეგებო! მე მქვია ანდრეი, მე ვხელმძღვანელობ ოპერაციებს Banki.ru-ზე.

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

მომსახურების დადებითი მხარეები

მე სწრაფად გადავხედავ სერვისების უპირატესობებს.

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

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

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

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

სერვისები შესაძლებელს ხდის სხვადასხვა პროგრამირების ენების გამოყენებას, რომლებიც უფრო შესაფერისია სხვადასხვა ამოცანებისთვის. ზოგიერთი სერვისი არის Go-ში, ზოგი არის Erlang-ში, ზოგი არის Ruby-ში, რაღაც არის PHP-ში, რაღაც არის Python-ში. ზოგადად, შეგიძლიათ ძალიან ფართოდ გააფართოვოთ. აქაც არის ნიუანსები.

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

მაგალითად, თქვენ გაქვთ 20 სერვისი და გჭირდებათ ხელით განლაგება, გაქვთ 20 კონსოლი და ერთდროულად აჭერთ "enter"-ს, როგორც ნინძა. არ არის ძალიან კარგი.

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

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

ჩვენ ვიყენებთ Ansible-ს განლაგების ავტომატიზაციისთვის, Puppet-ს კონვერგენციისთვის, Bamboo-ს განლაგების ავტომატიზაციისთვის და Confluence-ს, რომ როგორმე აღვწეროთ ეს ყველაფერი.

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

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

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

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

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

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

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

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

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

თითოეულ სერვისს ჰყავს საკუთარი გუნდი

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

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

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

და როდესაც თქვენ არღვევთ თქვენს სერვისს და ეს აუცილებლად ხდება, თქვენ არ ახდენთ გავლენას სხვა ადამიანების სერვისებზე და სხვა გუნდების დეველოპერები არ მოდიან თქვენთან და არ ამბობენ: „აი-აი, ნუ გააკეთებ ამას“.

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

თუ გუნდები მცურავია (ჩვენც ზოგჯერ ამას ვიყენებთ), არსებობს კარგი მეთოდი, რომელსაც ეწოდება "ვარსკვლავური რუკა".

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

როგორ ჩნდება ობოლი სერვისები?

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

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

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

როგორ ამოვიცნოთ ობოლი?

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

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

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

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

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

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

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

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

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

საჭიროა სერვისის შემოწმება, სერვისის გადახედვა, პაროლების შეცვლა. გვქონდა შემთხვევა, როცა მოგვცეს სერვისი, არის ადმინისტრატორის პანელი “if login == 'admin' && password == 'admin'...", წერია პირდაპირ კოდში. ჩვენ ვსხედვართ და ვფიქრობთ და ხალხი ამას წერს 2018 წელს?

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

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

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

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

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

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

რა პრობლემა აქვთ ობლებს?

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

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

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

რატომ არის საშიში ობოლი სერვისები:

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

რა ვუყოთ ობოლი სერვისებს?

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

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

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

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

დაგეგმეთ ობოლთა სამსახურთან მუშაობა

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

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

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

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

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

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

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

სლაიდებმა თქვეს, რომ თქვენ გააერთიანეთ ენები. მაგალითი იყო სურათების ზომის შეცვლა. მართლა აუცილებელია მისი მკაცრად შეზღუდვა ერთ ენაზე? იმის გამო, რომ სურათის ზომის შეცვლა PHP-ში, რეალურად შეიძლება გაკეთდეს Golang-ში.

სინამდვილეში, ეს არჩევითია, როგორც ყველა პრაქტიკა. შესაძლოა, ზოგიერთ შემთხვევაში არასასურველიც კი იყოს. მაგრამ თქვენ უნდა გესმოდეთ, რომ თუ თქვენ გაქვთ ტექნიკური განყოფილება 50 კაციან კომპანიაში, მათგან 45 არის PHP სპეციალისტი, კიდევ 3 არის დევოპი, რომლებმაც იციან Python, Ansible, Puppet და მსგავსი რამ, და მხოლოდ ერთი მათგანი წერს ზოგიერთში. ერთგვარი ენა. ზოგიერთი Go გამოსახულების ზომის შეცვლის სერვისი, შემდეგ როცა ის წავა, ექსპერტიზაც მიდის. და ამავე დროს, თქვენ უნდა მოძებნოთ ბაზრის სპეციფიკური დეველოპერი, რომელმაც იცის ეს ენა, განსაკუთრებით თუ ეს იშვიათია. ანუ ორგანიზაციული თვალსაზრისით ეს პრობლემატურია. დევოპსის თვალსაზრისით, თქვენ დაგჭირდებათ არა მხოლოდ მზა სათამაშო წიგნების კლონირება, რომლებსაც იყენებთ სერვისების განსათავსებლად, არამედ მოგიწევთ მათი ხელახლა დაწერა.

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

როგორ აკონტროლებთ თქვენს მომსახურებას? როგორ აგროვებთ და აკონტროლებთ ჟურნალებს?

ჩვენ ვაგროვებთ ჟურნალებს Elasticsearch-ში და ვათავსებთ მათ Kibana-ში და იმისდა მიხედვით, ეს არის საწარმოო თუ სატესტო გარემო, იქ გამოიყენება სხვადასხვა კოლექტორები. სადღაც ლამბერჯაკი, სადღაც სხვა რაღაც, არ მახსოვს. და კიდევ არის გარკვეული ადგილები გარკვეულ სერვისებში, სადაც ჩვენ ვაინსტალირებთ Telegraf-ს და ვიღებთ ცალ-ცალკე სხვაგან.

როგორ ვიცხოვროთ თოჯინასთან და ანსიბლთან ერთ გარემოში?

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

როგორ ინარჩუნებთ თავსებადობას? გაქვთ კონფიგურაციები როგორც Ansible-ში, ასევე Puppet-ში?

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

პრეზენტაცია რუბის სხვადასხვა ვერსიებს ეხებოდა. რა გამოსავალი?

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

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

მონაწილეთა რეგისტრაცია დაწყებულია, შემოგვიერთდით!

წყარო: www.habr.com