1C დეველოპერის ზღაპრები: ადმინისტრატორი

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

მაღალსიჩქარიანი საკომუნიკაციო არხი

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

ახალი კლიენტი მოვიდა 1C-ის მხარდასაჭერად და, სხვა საკითხებთან ერთად, კონტრაქტში შედიოდა პუნქტი, რომ ჩვენ ვიყავით პასუხისმგებელი სარეზერვო ასლებისთვის, თუმცა მათ ჰყავდათ საკუთარი სისტემის ადმინისტრატორი პერსონალში. კლიენტ-სერვერის მონაცემთა ბაზა, MS SQL როგორც DBMS. საკმაოდ სტანდარტული სიტუაცია, მაგრამ მაინც იყო ერთი ნიუანსი: ძირითადი ბაზა საკმაოდ დიდი იყო, მაგრამ ყოველთვიური ზრდა ძალიან მცირე იყო. ანუ მონაცემთა ბაზა შეიცავდა უამრავ ისტორიულ მონაცემს. ამ მახასიათებლის გათვალისწინებით, მე დავაყენე სარეზერვო ტექნიკური გეგმები შემდეგნაირად: ყოველი თვის პირველ შაბათს კეთდებოდა სრული სარეზერვო ასლი, საკმაოდ მძიმე იყო, შემდეგ ყოველ ღამე კეთდებოდა დიფერენციალური ასლი - შედარებით მცირე მოცულობა და ასლი. ტრანზაქციის ჟურნალი ყოველ საათში. უფრო მეტიც, სრული და დიფერენციალური ასლები არა მხოლოდ დაკოპირდა ქსელის რესურსზე, არამედ დამატებით აიტვირთა ჩვენს FTP სერვერზე. ეს არის სავალდებულო მოთხოვნა ამ სერვისის მიწოდებისას.

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

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

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

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

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

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

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

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

დაუკავშირდით თქვენი სისტემის ადმინისტრატორს

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

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

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

ერთი საფეხური უფრო ღრმა

გვყავდა კლიენტი - მცირე საწარმოო საწარმო. მათ ჰქონდათ სერვერი, ერთგვარი "კლასიკური" 3 in 1: ტერმინალის სერვერი + აპლიკაციის სერვერი + მონაცემთა ბაზის სერვერი. ისინი მუშაობდნენ UPP-ზე დაფუძნებული ინდუსტრიის სპეციფიკურ კონფიგურაციაში, დაახლოებით 15-20 მომხმარებელი იყო და სისტემის მუშაობა, პრინციპში, ყველას უხდებოდა.

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

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

გარკვეული პერიოდის შემდეგ, ადმინი მიგზავნის ახალი სერვერის IP მისამართს და შესვლის სერთიფიკატს. ის ამბობს, რომ MS SQL და 1C სერვერის კომპონენტები განლაგებულია იქ და საჭიროა მონაცემთა ბაზების გადატანა, მაგრამ ამ დროისთვის მხოლოდ DBMS სერვერზე, რადგან გარკვეული პრობლემები წარმოიშვა 1C გასაღებებთან დაკავშირებით.

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

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

ჰმ... ვირტუალური სერვერი? როგორც ჩანს, ვირტუალიზაცია არასდროს ყოფილა და არც ყოფილა... მახსოვს საკმაოდ ცნობილი პრობლემა 1C სერვერის გასაღების გადამისამართების შეუძლებლობაზე Hyper-V-ზე Windows Server 2008-ში. და აი. რაღაც ეჭვები იწყება ჩემში...

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

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

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

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

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

მყარი დისკის შვებულების განრიგი

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

უპირველეს ყოვლისა, აუცილებელია საწარმოო და ტესტირების მონაცემთა ბაზების განთავსება. დეველოპერმა მიიღო კავშირის მონაცემები, შედის სერვერზე, ხედავს დაყენებულ MS SQL, 1C სერვერს, ხედავს 2 ლოგიკურ დისკს: დისკი „C“ 250 გიგაბაიტიანი სიმძლავრით და დისკი „D“ 1 ტერაბაიტის ტევადობით. ისე, "C" არის სისტემა, "D" არის მონაცემებისთვის, დეველოპერი ლოგიკურად წყვეტს და განათავსებს იქ ყველა მონაცემთა ბაზას. მე კი შევქმენი ტექნიკური გეგმები, მათ შორის სარეზერვო, ყოველი შემთხვევისთვის (მიუხედავად იმისა, რომ ჩვენ არ ვართ პასუხისმგებელი ამაზე). მართალია, სარეზერვო ასლები დაემატა აქ "D". მომავალში დაიგეგმა მისი ხელახალი კონფიგურაცია ქსელის ცალკეულ რესურსზე.

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

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

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

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

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

მაგრამ ეს სულ სხვა ამბავია...

წყარო: www.habr.com