აუთსორსინგიდან განვითარებამდე (ნაწილი 1)

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

წინაისტორია

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

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

ადრე ვაპროგრამებდი Delphi-ში, PHP-ში, JS-ში და ძალიან ზედაპირულად C++-ში. მე კარგად ვიცი, როგორ მუშაობს ქსელები. VLAN, მარშრუტირება (OSPF, EIGRP, BGP), NAT. ეს საკმარისი იყო იმისთვის, რომ მე თვითონ დავწერო პრიმიტიული მონიტორინგის პროტოტიპი.

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

system(“ping -n 3 -w 100 {$ip_address}“); 

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

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

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

system(“tracert -d -w 500 8.8.8.8”);

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

გარდა ამისა, ყოველდღიურ სამუშაოში ჯვარედინი გადაკვეთა მიწევდა. და დავიღალე ყოველ ჯერზე Cisco-ს გადამრთველებთან სიარულით, რომ მენახა რომელი ინტერფეისი გამოვიყენო. რა მაგარი იქნებოდა მონიტორინგში დააწკაპუნოთ ობიექტზე და ნახოთ მისი ინტერფეისების სია აღწერილობებით. ეს დამიზოგავს დროს. უფრო მეტიც, ამ სქემაში არ იქნება საჭირო Putty-ის ან SecureCRT-ის გაშვება ანგარიშებისა და ბრძანებების შესაყვანად. უბრალოდ დავაჭირე მონიტორინგს, დავინახე რა იყო საჭირო და წავედი ჩემი საქმის გასაკეთებლად. დავიწყე გადამრთველებთან ურთიერთობის გზების ძებნა. მაშინვე წავაწყდი 2 ვარიანტს: SNMP ან SSH-ის საშუალებით გადამრთველში შესვლა, საჭირო ბრძანებების შეყვანა და შედეგის გარჩევა. მე გავათავისუფლე SNMP მისი განხორციელების სირთულის გამო, მე მოუთმენელი ვიყავი შედეგის მისაღებად. SNMP-ით, თქვენ მოგიწევთ MIB-ში დიდი ხნის განმავლობაში გათხრა და, ამ მონაცემების საფუძველზე, გენერირებული მონაცემები ინტერფეისების შესახებ. CISCO-ში შესანიშნავი გუნდია

show interface status

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

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

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

კომპანია აუდიტი-ტელეკომის შექმნა

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

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

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

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

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

განაგრძეთ მუშაობა თქვენი მონიტორინგის სისტემაზე

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

ასე რომ, ამოცანები:

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

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

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

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

შედეგები ხშირად არასწორი იყო და სკანირებას დიდი დრო სჭირდებოდა. პინგი სულ დამავიწყდა, ეს გაკეთდა fping-ით:

system("fping -r 3 -t 100 {$this->ip}");

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

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

როგორ მუშაობს რესურსების ბმულები Veliam-ში

დისტანციური კავშირები

ასე გამოიყურება მოქმედებაში Veliam-ის მიმდინარე ვერსიაში

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

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

იმის გათვალისწინებით, რომ ჩვენს სისტემაში კლიენტი იყო ბრაუზერი, რომელსაც არ აქვს წვდომა კომპიუტერის ლოკალურ რესურსებზე, იმისთვის, რომ უბრალოდ გაუშვათ პროგრამა, რომელიც გვჭირდებოდა გარკვეული ბრძანებით, გამოიგონეს ყველაფრის გაკეთება "Windows"-ის საშუალებით. მორგებული url სქემა”. ასე გამოჩნდა ჩვენი სისტემისთვის გარკვეული „მოდული“, რომელიც უბრალოდ მოიცავდა Putty-ს და Remote Desktop Plus-ს და ინსტალაციის დროს უბრალოდ დაარეგისტრირა URI სქემა Windows-ში. ახლა, როდესაც გვინდოდა ობიექტთან დაკავშირება RDP ან SSH მეშვეობით, ჩვენ დავაწკაპუნეთ ამ მოქმედებაზე ჩვენს სისტემაზე და Custom URI მუშაობდა. Windows-ში ან putty-ში ჩაშენებული სტანდარტული mstsc.exe, რომელიც „მოდულის“ ნაწილი იყო, ამოქმედდა. სიტყვა დანამატი ბრჭყალებში ჩავდე, რადგან ეს არ არის ბრაუზერის დანამატი კლასიკური გაგებით.

ყოველ შემთხვევაში ეს იყო რაღაც. მოსახერხებელი მისამართების წიგნი. უფრო მეტიც, Putty-ის შემთხვევაში, ზოგადად ყველაფერი კარგად იყო; მას შეიძლება მიეცეს IP კავშირები, შესვლა და პაროლი, როგორც შეყვანის პარამეტრები. იმათ. ჩვენ უკვე დავუკავშირდით Linux სერვერებს ჩვენს ქსელში ერთი დაწკაპუნებით პაროლების შეყვანის გარეშე. მაგრამ RDP-ით ეს არც ისე მარტივია. სტანდარტული mstsc არ შეუძლია სერთიფიკატების მიწოდება პარამეტრებად. დისტანციური დესკტოპ პლუსი მოვიდა სამაშველოში. მან ამის საშუალება მისცა. ახლა ჩვენ შეგვიძლია ამის გარეშე, მაგრამ დიდი ხნის განმავლობაში ის იყო ერთგული თანაშემწე ჩვენს სისტემაში. HTTP(S) საიტებზე ყველაფერი მარტივია, ასეთი ობიექტები უბრალოდ იხსნება ბრაუზერში და ეს არის. მოსახერხებელი და პრაქტიკული. მაგრამ ეს ბედნიერება მხოლოდ შიდა ქსელში იყო.

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

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

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

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

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

სხვათა შორის, აქ არის:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

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

Mikrotik სარეზერვო

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

სკრიპტის კოდი PHP-ში Mikrotik-დან სარეზერვო ასლის აღებისთვის:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

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

ეკრანის ანაბეჭდები, თუ როგორ გამოიყურებოდა იგი შიდა სისტემაში

გადასვლა ნორმალურ მონაცემთა ბაზაზე

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

Helpdesk - HelpDesk

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

ჩვენ მომხმარებლებს ვუკავშირდით ცნობილი TeamViewer-ის მეშვეობით. ყველა კომპიუტერს, რომლის მომხმარებლებსაც ვემსახურებით, დამონტაჟებულია ტელევიზორი. პირველი, რაც ჩვენ არასწორად გავაკეთეთ და შემდეგ წავშალეთ, იყო თითოეული HD კლიენტის დაკავშირება აპარატურასთან. როგორ შევიდა მომხმარებელი HD სისტემაში მოთხოვნის დასატოვებლად? ტელევიზორის გარდა, ყველას ჰქონდა კომპიუტერზე დაყენებული სპეციალური უტილიტა, რომელიც დაწერილი იყო Lazarus-ით (აქ ბევრს თვალებს ატრიალებენ და იქნებ წავიდნენ Google-ში რა არის, მაგრამ ყველაზე კარგი კომპილირებული ენა, რაც მე ვიცოდი, იყო Delphi და Lazarus თითქმის იგივე, მხოლოდ უფასო). ზოგადად, მომხმარებელმა გაუშვა სპეციალური პარტიული ფაილი, რომელმაც გაუშვა ეს პროგრამა, რომელიც თავის მხრივ წაიკითხა სისტემის HWID და ამის შემდეგ ბრაუზერი ამოქმედდა და მოხდა ავტორიზაცია. რატომ გაკეთდა ეს? ზოგიერთ კომპანიაში მომსახურე მომხმარებელთა რაოდენობა ინდივიდუალურად ითვლება, ხოლო მომსახურების ფასი ყოველთვიურად ემყარება ხალხის რაოდენობას. ეს გასაგებია, თქვენ ამბობთ, მაგრამ რატომ არის იგი მიბმული აპარატურასთან? ეს ძალიან მარტივია, ზოგიერთი ადამიანი მოვიდა სახლში და მოითხოვა თავისი სახლის ლეპტოპიდან სტილში "გააკეთე ყველაფერი ლამაზი ჩემთვის აქ". სისტემის HWID-ის წაკითხვის გარდა, კომუნალურმა პროგრამამ ამოიღო მიმდინარე Teamviewer ID რეესტრიდან და ასევე გადმოგვცა. Teamviewer-ს აქვს API ინტეგრაციისთვის. და ჩვენ გავაკეთეთ ეს ინტეგრაცია. მაგრამ იყო ერთი დაჭერა. ამ API-ების საშუალებით შეუძლებელია მომხმარებლის კომპიუტერთან დაკავშირება, როდესაც ის პირდაპირ არ იწყებს ამ სესიას და მასთან დაკავშირების მცდელობის შემდეგ მან ასევე უნდა დააჭიროს "დადასტურებას". იმ დროს ლოგიკურად გვეჩვენებოდა, რომ მომხმარებლის მოთხოვნის გარეშე არავინ დაკავშირებოდა და რადგან ადამიანი კომპიუტერთან იმყოფება, ის წამოიწყებს სესიას და დადებითად უპასუხებს დისტანციური კავშირის მოთხოვნას. ყველაფერი არასწორი აღმოჩნდა. აპლიკანტებს დაავიწყდათ სხდომის დაწყებაზე დაჭერა და ამის შესახებ სატელეფონო საუბარში უნდა ეთქვათ. ეს კარგავდა დროს და იყო იმედგაცრუებული პროცესის ორივე მხარეს. უფრო მეტიც, სულაც არ არის იშვიათი ასეთი მომენტები, როდესაც ადამიანი ტოვებს თხოვნას, მაგრამ დაკავშირება მხოლოდ მაშინ ეძლევა, როდესაც ის ლანჩზე მიდის. რადგან პრობლემა არ არის კრიტიკული და არ სურს, რომ მისი სამუშაო პროცესი შეფერხდეს. შესაბამისად, ის არ დააჭერს ღილაკებს კავშირის დასაშვებად. ასე გამოჩნდა დამატებითი ფუნქციონირება HelpDesk-ში შესვლისას - წაიკითხა Teamviwer-ის ID. ჩვენ ვიცოდით მუდმივი პაროლი, რომელიც გამოიყენებოდა Teamviwer-ის დაყენებისას. უფრო ზუსტად, ეს მხოლოდ სისტემამ იცოდა, რადგან ის ჩაშენებული იყო ინსტალერში და ჩვენს სისტემაში. შესაბამისად, აპლიკაციიდან იყო კავშირის ღილაკი, რომელზეც დაწკაპუნებით არ იყო საჭირო არაფრის ლოდინი, მაგრამ Teamviewer მაშინვე გაიხსნა და დაკავშირება მოხდა. შედეგად, იყო ორი სახის შესაძლო კავშირი. ოფიციალური Teamviewer API და ჩვენი საკუთარი ხელით შექმნილი API-ს მეშვეობით. ჩემდა გასაკვირად, მათ პირველის გამოყენება თითქმის მაშინვე შეწყვიტეს, თუმცა იყო ინსტრუქცია, რომ გამოეყენებინათ მხოლოდ განსაკუთრებულ შემთხვევებში და როცა თავად მომხმარებელი გასცემს ნებას. მაინც მომეცი ახლა უსაფრთხოება. მაგრამ აღმოჩნდა, რომ განმცხადებლებს ეს არ სჭირდებოდათ. ყველა მათგანი აბსოლუტურად კარგად არის დადასტურების ღილაკის გარეშე მათთან დაკავშირება.

Linux-ში მრავალნაკადზე გადასვლა

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

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

ახალი კომპანიების სწრაფი აუდიტი

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

მაგრამ აუდიტის შედეგი ჩვეულებრივ მოიცავს უამრავ განსხვავებულ ინფორმაციას და ერთ-ერთი მათგანია, თუ რა სახის მოწყობილობებია ქსელში. უპირველეს ყოვლისა, ჩვენ დაინტერესებული ვიყავით Windows სერვერებით და Windows სამუშაო სადგურებით, როგორც დომენის ნაწილი. ვინაიდან საშუალო და დიდ კომპანიებში დომენის ნაკლებობა ალბათ გამონაკლისია წესიდან. ერთ ენაზე საუბრისას საშუალოდ, ჩემი აზრით, 100+ ადამიანია. საჭირო იყო Windows-ის ყველა აპარატიდან და სერვერიდან მონაცემების შეგროვების გზა, მათი IP და დომენის ადმინისტრატორის ანგარიშის ცოდნით, მაგრამ თითოეულ მათგანზე რაიმე პროგრამული უზრუნველყოფის დაყენების გარეშე. WMI ინტერფეისი მოდის სამაშველოში. Windows Management Instrumentation (WMI) სიტყვასიტყვით ნიშნავს Windows მართვის ინსტრუმენტებს. WMI არის Windows-ის პლატფორმაზე გაშვებული კომპიუტერული ინფრასტრუქტურის სხვადასხვა ნაწილის მუშაობის ცენტრალიზებული მართვისა და მონიტორინგის ერთ-ერთი ძირითადი ტექნოლოგია. აღებულია ვიკიდან. შემდეგი, მე მომიწია ხელახლა დალაგება, რათა შემედგინა wmic (ეს არის WMI კლიენტი) Debian-ისთვის. მას შემდეგ რაც ყველაფერი მზად იყო, დარჩა მხოლოდ საჭირო კვანძების გამოკითხვა wmic-ის მეშვეობით საჭირო ინფორმაციის მისაღებად. WMI-ის საშუალებით შეგიძლიათ მიიღოთ თითქმის ნებისმიერი ინფორმაცია ვინდოუსის კომპიუტერიდან და მეტიც, მისი მეშვეობით კომპიუტერის მართვაც შეგიძლიათ, მაგალითად გაგზავნოთ გადატვირთვაზე. ასე გაჩნდა ჩვენს სისტემაში Windows სადგურებისა და სერვერების შესახებ ინფორმაციის შეგროვება. გარდა ამისა, იყო მიმდინარე ინფორმაცია სისტემის მიმდინარე დატვირთვის ინდიკატორების შესახებ. ჩვენ ვითხოვთ მათ უფრო ხშირად და ინფორმაციას აპარატურის შესახებ ნაკლებად ხშირად. ამის შემდეგ აუდიტი ცოტა უფრო სასიამოვნო გახდა.

პროგრამული უზრუნველყოფის განაწილების გადაწყვეტილება

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

განახლება

მეორე ნაწილი

წყარო: www.habr.com