Аутсорсингтен әзірлеуге дейін (1 бөлім)

Барлығына сәлем, менің атым Сергей Емельянчик. Мен Audit-Telecom компаниясының басшысымын, Veliam жүйесінің негізгі әзірлеушісі және авторымын. Мен досым екеуміз аутсорсингтік компанияны қалай құрғанымыз, өзіміз үшін бағдарламалық жасақтама жазғанымыз және кейін оны SaaS жүйесі арқылы барлығына тарата бастағанымыз туралы мақала жазуды шештім. Мен бұл мүмкін екеніне мүлдем сенбедім. Мақалада тек оқиға ғана емес, сонымен қатар Veliam өнімі қалай жасалғаны туралы техникалық мәліметтер де болады. Бастапқы кодтың кейбір бөліктерін қоса. Мен сізге қандай қателіктер жібергенімізді және оларды қалай түзететінімізді кейінірек айтамын. Мұндай мақаланы жариялау керек пе деген күмән болды. Бірақ мен мақаланы жарияламай, егер...

тарихын

Мен бір компанияда IT қызметкері болып жұмыс істедім. Компания ауқымды желі құрылымымен өте үлкен болды. Мен өзімнің лауазымдық міндеттеріме тоқталмаймын, тек олардың ешнәрсені дамытуды қамтымағанын ғана айтайын.

Бізде мониторинг болды, бірақ мен тек академиялық қызығушылық үшін өзімнің қарапайымдыымды жазғым келді. Идея мынада: мен оның интернетте болуын қаладым, сонда мен ешбір клиентті орнатпай-ақ оңай кіріп, желіде не болып жатқанын кез келген құрылғыдан, соның ішінде Wi-Fi арқылы мобильді құрылғыдан көре аламын. Нені тез түсінгісі келді Бөлмеде «мопей» болған жабдық бар, өйткені... мұндай мәселелерге жауап беру уақытына өте қатаң талаптар қойылды. Нәтижесінде, менің басымда желі диаграммасы бар jpeg фоны бар қарапайым веб-парақ жазу, осы суреттегі IP мекенжайлары бар құрылғыларды қиып алу және жоғарғы жағында динамикалық мазмұнды көрсету жоспары пайда болды. жасыл немесе жыпылықтайтын қызыл IP мекенжайы түріндегі қажетті координаттардағы сурет. Тапсырма қойылды, бастайық.

Бұрын мен Delphi, PHP, JS және өте үстірт C++ тілінде бағдарламалаумен айналыстым. Мен желілердің қалай жұмыс істейтінін жақсы білемін. VLAN, Маршруттау (OSPF, EIGRP, BGP), NAT. Бұл маған қарапайым мониторинг прототипін жазу үшін жеткілікті болды.

Мен PHP тілінде жоспарлағанымды жаздым. Apache және PHP сервері Windows жүйесінде болды, себебі... Сол кезде мен үшін Linux түсініксіз және өте күрделі нәрсе болды, кейінірек мен қатты қателескенмін және көп жерде Linux Windows-қа қарағанда әлдеқайда қарапайым, бірақ бұл бөлек тақырып және бізде қанша голивар бар екенін бәріміз білеміз. бұл тақырып. Windows тапсырмаларын жоспарлаушы шағын аралықта (дәл есімде жоқ, бірақ үш секунд сайын бір рет) барлық нысандарды банальды пингпен сұрайтын және күйді файлға сақтайтын PHP сценарийін шығарды.

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

Иә, иә, ол кезде мәліметтер қорымен жұмыс істеу де мен үшін игерілмеген. Мен процестерді параллельдеуге болатынын білмедім және барлық желі түйіндері арқылы өту ұзаққа созылды, өйткені... бұл бір ағында болды. Мәселелер әсіресе бірнеше түйіндер қол жетімсіз болған кезде пайда болды, өйткені олардың әрқайсысы сценарийді 300 мс кешіктірді. Клиент жағында қарапайым цикл функциясы болды, ол бірнеше секунд аралықта Ajax сұрауы бар серверден жаңартылған ақпаратты жүктеп алып, интерфейсті жаңартты. Сонымен қатар, 3 сәтсіз пингтен кейін компьютерде мониторингі бар веб-парақ ашылған болса, көңілді композиция ойнады.

Барлығы ойдағыдай болған кезде мен нәтижеге қатты шабыттандым және мен оған көбірек қоса аламын деп ойладым (білім мен мүмкіндіктердің арқасында). Бірақ мен миллиондаған диаграммалары бар жүйелерді әрқашан ұнатпайтынмын, олар мен сол кезде ойладым және әлі күнге дейін көп жағдайда қажет емес деп ойлаймын. Мен оған жұмысыма шынымен көмектесетін нәрсені ғана салғым келді. Бұл қағида бүгінгі күнге дейін Велиамның дамуының негізі болып қала береді. Әрі қарай, мен бақылауды ашық ұстаудың және проблемалар туралы білудің қажеті жоқ болса, бұл өте жақсы болатынын түсіндім және ол орын алған кезде, бетті ашып, осы проблемалық желі түйіні қайда орналасқанын және онымен не істеу керектігін білемін. . Мен ол кезде электрондық поштаны оқымадым, мен оны пайдаланбадым. Интернетте мен SMS шлюздері бар екенін көрдім, оларға GET немесе POST сұрауын жібере аласыз, олар менің ұялы телефоныма мен жазған мәтінмен SMS жібереді. Мен мұны шынымен қалайтынымды бірден түсіндім. Ал мен құжаттаманы зерттей бастадым. Біраз уақыттан кейін мен сәтті болдым, енді ұялы телефоныма желідегі ақаулар туралы «құлаған зат» деген SMS келді. Жүйе қарапайым болғанымен, оны өзім жаздым және оны дамытуға түрткі болған ең бастысы, бұл менің жұмысыма шынымен көмектескен қолданбалы бағдарлама болды.

Сосын жұмыс орнында интернет-арналардың бірі істен шығып, менің бақылауым бұл туралы маған білдіртпеді. Google DNS әлі де тамаша пинг жүргізгендіктен. Байланыс арнасының тірі екенін қалай бақылауға болатыны туралы ойланатын кез келді. Мұны қалай жасау керектігі туралы әртүрлі идеялар болды. Мен барлық жабдыққа қол жеткізе алмадым. Біз арналардың қайсысы тікелей эфирде екенін қалай түсінуге болатынын анықтауға тура келді, бірақ оны желілік жабдықтың өзінде көре алмадық. Содан кейін бір әріптес қазір Интернетке кіру үшін қандай байланыс арнасы пайдаланылатынына байланысты жалпыға ортақ серверлерге бағытты іздеу әртүрлі болуы мүмкін деген идеяны ойлап тапты. Мен тексердім, ол солай болды. Бақылау кезінде әртүрлі маршруттар болды.

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 арқылы маған қажет коммутаторға қосылды (тіркеу деректері кодқа қатты кодталған, оны нақтылау, кейбір бөлек мәзірлерді жасау үшін қажет болған жоқ. интерфейстен тіркелгілерді өзгертуге болатын еді , маған нәтиже қажет болды және тез) Мен сол жерде жоғарыдағы пәрменді енгіздім және оны браузерге қайта жібердім. Сондықтан мен тінтуірдің бір рет басуымен интерфейстер туралы ақпаратты көре бастадым. Бұл өте ыңғайлы болды, әсіресе бұл ақпаратты бірден әртүрлі қосқыштарда қарау керек болғанда.

Бақылау негізіндегі арна мониторингі ең жақсы идея болмады, өйткені... кейде желіде жұмыс жүргізілді, ал бақылау өзгеруі мүмкін және мониторинг маған арнада ақаулар бар деп айқайлай бастады. Бірақ талдауға көп уақыт жұмсаған соң, барлық арналар жұмыс істеп тұрғанын, мониторингім мені алдайтынын түсіндім. Нәтижесінде, мен арна құру қосқыштарын басқаратын әріптестерімнен көршілердің көріну күйі өзгерген кезде маған жай ғана жүйе журналын жіберуді сұрадым. Тиісінше, ол бақылауға қарағанда әлдеқайда қарапайым, жылдам және дәлірек болды. Көрші жоғалған сияқты оқиға келді, мен дереу арнаның төмендегені туралы хабарлама жіберемін.

Әрі қарай, нысанды басқан кезде тағы бірнеше пәрмендер пайда болды және кейбір көрсеткіштерді жинау үшін SNMP қосылды және бұл негізінен. Жүйе ешқашан әрі қарай дамымаған. Бұл маған қажет нәрсенің бәрін жасады, бұл жақсы құрал болды. Көптеген оқырмандар Интернетте бұл мәселелерді шешуге арналған көптеген бағдарламалық жасақтама бар екенін айтатын шығар. Бірақ, шын мәнінде, мен мұндай тегін өнімдерді сол кезде google-де іздеген жоқпын және мен бағдарламалау дағдыларымды дамытқым келді және бұл үшін нақты қолданба мәселесінен гөрі итерудің қандай жақсы жолы бар. Осы кезде мониторингтің бірінші нұсқасы аяқталды және енді өзгертілмеді.

Аудит-Телеком компаниясының құрылуы

Уақыт өте келе мен басқа компанияларда толық емес жұмыс күнімен жұмыс істей бастадым, бақытымызға орай, менің жұмыс тәртібім мұны істеуге мүмкіндік берді. Сіз әртүрлі компанияларда жұмыс істегенде, әртүрлі салалардағы дағдыларыңыз өте тез өсіп, көкжиектеріңіз жақсы дамиды. Сіз шведсіз, орақшысыз, кернейшісіз дегендей компаниялар бар. Бір жағынан, қиын, екінші жағынан, егер сіз жалқау болмасаңыз, сіз жалпы маман боласыз және бұл сізге мәселелерді тезірек және тиімдірек шешуге мүмкіндік береді, өйткені сіз тиісті саланың қалай жұмыс істейтінін білесіз.

Менің досым Павел (сонымен қатар IT маманы) мені өз кәсібін ашуға ынталандыруға тырысты. Олар істеп жатқан нәрселердің әртүрлі нұсқалары бар сансыз идеялар болды. Бұл жылдар бойы талқыланып келеді. Ақырында, бұл ештеңеге келмеуі керек еді, өйткені мен скептикпін, ал Павел - армандаушы. Ол идеяны ұсынған сайын мен оған сенбей, қатысудан бас тарттым. Бірақ біз өз кәсібімізді ашқымыз келді.

Ақырында біз екеумізге де қолайлы нұсқаны тауып, өз білгенімізді істей алдық. 2016 жылы біз бизнеске АТ мәселелерін шешуге көмектесетін IT-компания құру туралы шешім қабылдадық. Бұл АТ жүйелерін (1С, терминал сервері, пошта сервері және т.б.) орналастыру, оларға техникалық қызмет көрсету, пайдаланушыларға арналған классикалық HelpDesk және желіні басқару.

Шынымды айтсам, компанияны құру кезінде мен оған 99,9% сенбедім. Бірақ әйтеуір Павел мені сынап көруге итермеледі, алға қарап, ол дұрыс болып шықты. Павел екеуміз әрқайсысымыз 300 000 рубльден ақша жинадық, жаңа «Аудит-Телеком» ЖШС тіркелдік, кішкентай кеңсені жалға алдық, керемет визиткаларды жасадық, жалпы, тәжірибесіз, жаңадан бастаған бизнесмендер сияқты, клиенттерді іздей бастадық. Клиенттерді табу - мүлде басқа әңгіме. Бәлкім, біреуді қызықтыратын болса, корпоративтік блогтың бір бөлігі ретінде жеке мақала жазатын шығармыз. Суық қоңыраулар, парақшалар және т.б. Бұл ешқандай нәтиже бермеді. Мен қазір бизнес туралы көптеген әңгімелерден оқығанымдай, көп нәрсе сәттілікке байланысты. Жолымыз болды. және компания құрылғаннан кейін екі аптадан кейін ағам Владимир бізге келді, ол бізге бірінші клиентті әкелді. Мен сізді клиенттермен жұмыс істеудің егжей-тегжейлерімен жалықтырмаймын, мақаланың мәні бұл емес, мен тек аудитке барғанымызды, маңызды аймақтарды анықтағанымызды және бұл учаскелер жұмыс істеу туралы шешім қабылданған кезде бұзылғанын айтқым келеді. аутсорсинг ретінде бізбен тұрақты негізде ынтымақтасады. Осыдан кейін бірден оң шешім қабылданды.

Одан кейін негізінен достар арқылы ауызша сөз арқылы басқа сервистік компаниялар пайда бола бастады. Анықтамалық қызмет бір жүйеде болды. Желілік жабдық пен серверлерге қосылулар әртүрлі, дәлірек айтқанда, әртүрлі. Кейбір адамдар төте жолдарды сақтаса, басқалары 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 арқылы кейбір қызметтерді орнату болды. Мысалы, MS Exchange ұсынған ECP. Негізінде бұл жай ғана сілтеме. Біз нақты клиенттің ECP-ге қалай қол жеткізуге болатынын құжаттамада немесе бетбелгілерде басқа жерде іздемеу үшін мұндай сілтемелерді тікелей жүйеге қосу мүмкіндігін алуымыз керек деп шештік. Жүйе үшін ресурстық сілтемелер тұжырымдамасы осылай пайда болды, олардың функционалдығы бүгінгі күнге дейін қол жетімді және өзгерген жоқ, дерлік.

Велиамда ресурс сілтемелері қалай жұмыс істейді

Қашықтағы қосылымдар

Велиамның қазіргі нұсқасында бұл әрекеттегідей көрінеді

Тапсырмалардың бірі серверлерге жылдам және ыңғайлы қосылу болды, олардың көпшілігі (жүзден астам) және миллиондаған алдын ала сақталған RDP таңбашалары арқылы сұрыптау өте ыңғайсыз болды. Құрал керек болды. Интернетте осындай RDP қосылымдары үшін мекенжай кітабы сияқты бағдарламалық құрал бар, бірақ олар мониторинг жүйесімен біріктірілмеген және тіркелгілерді сақтау мүмкін емес. Әртүрлі серверлерге күніне ондаған рет қосылған кезде әр түрлі клиенттер үшін тіркелгілерді енгізу таза тозақ болып табылады. SSH көмегімен бәрі біршама жақсарды; мұндай қосылымдарды қалталарға ұйымдастыруға және олардағы тіркелгілерді есте сақтауға мүмкіндік беретін көптеген жақсы бағдарламалық қамтамасыз ету бар. Бірақ 2 мәселе бар. Біріншісі, біз RDP және SSH қосылымдары үшін бір бағдарламаны таппадық. Екіншісі, егер бір сәтте мен компьютерде болмасам және тез қосылуым керек болса немесе жүйені жай ғана қайта орнатқан болсам, осы клиенттің тіркелгісін қарау үшін құжаттамаға кіруім керек. Бұл ыңғайсыз және уақытты босқа кетіреді.

Клиент серверлері үшін қажет иерархиялық құрылым біздің ішкі өнімде бұрыннан бар. Маған қажетті жабдыққа жылдам қосылымдарды қалай қосу керектігін анықтау керек болды. Жаңадан бастаушылар үшін, кем дегенде сіздің желіңізде.

Біздің жүйедегі клиент компьютердің жергілікті ресурстарына қол жеткізе алмайтын браузер болғанын ескере отырып, бізге қажетті қосымшаны қандай да бір пәрменмен жай ғана іске қосу үшін «Windows» арқылы бәрін жасау ойлап табылды. реттелетін URL схемасы». Осылайша, біздің жүйеміз үшін белгілі бір «плагин» пайда болды, оған жай ғана Putty және Remote Desktop Plus кіреді және орнату кезінде Windows жүйесінде URI схемасын тіркеді. Енді біз RDP немесе SSH арқылы нысанға қосылғымыз келгенде, жүйемізде осы әрекетті нұқып, пайдаланушы URI жұмыс істеді. Windows жүйесіне немесе «плагиннің» бөлігі болып табылатын putty ішіне орнатылған стандартты mstsc.exe іске қосылды. Мен плагин сөзін тырнақшаға қойдым, себебі бұл классикалық мағынада браузер плагині емес.

Кем дегенде, бұл бір нәрсе болды. Ыңғайлы мекен-жай кітабы. Сонымен қатар, Putty жағдайында бәрі жақсы болды, оған IP қосылымдары, логин мен пароль енгізу параметрлері ретінде берілуі мүмкін. Анау. Біз желідегі Linux серверлеріне құпия сөздерді енгізбей бір рет басу арқылы қосылып үлгердік. Бірақ RDP-мен бұл оңай емес. Стандартты mstsc тіркелгі деректерін параметр ретінде қамтамасыз ете алмайды. Remote Desktop Plus көмекке келді. Ол бұған жол берді. Енді біз онсыз жасай аламыз, бірақ ол ұзақ уақыт бойы біздің жүйеде сенімді көмекші болды. HTTP(S) сайттарында бәрі қарапайым, мұндай нысандар шолғышта жай ғана ашылады және бәрі де солай. Ыңғайлы және практикалық. Бірақ бұл тек ішкі желіде бақыт болды.

Біз мәселелердің басым көпшілігін кеңседен қашықтан шешкендіктен, ең оңай нәрсе VPN желілерін клиенттерге қолжетімді ету болды. Содан кейін оларға біздің жүйеден қосылуға болады. Бірақ бұл әлі де біршама ыңғайсыз болды. Әрбір клиент үшін әр компьютерде есте сақталатын VPN қосылымдарын сақтау қажет болды және кез келгеніне қосылмас бұрын сәйкес VPN қосу қажет болды. Біз бұл шешімді ұзақ уақыт қолдандық. Бірақ клиенттердің саны артып келеді, VPN саны да артып келеді және мұның бәрі шиеленісе бастады және бұл үшін бірдеңе істеу керек болды. Жүйені қайта орнатқаннан кейін, жаңа Windows профилінде ондаған VPN қосылымдарын қайта енгізуге тура келген кезде көзіме жас келді. Бұған шыдама, - дедім де, мен бұл туралы не істей аламын деп ойлай бастадым.

Осылайша, барлық клиенттерде маршрутизатор ретінде танымал Mikrotik компаниясының құрылғылары болды. Олар өте функционалды және кез келген тапсырманы орындауға ыңғайлы. Кемшілігі - олар «ұрланған». Біз бұл мәселені сырттан барлық қолжетімділікті жабу арқылы шештік. Бірақ клиенттің орнына келмей-ақ оларға қол жеткізу керек болды, өйткені... ол ұзақ. Біз әрбір микротикке туннель жасап, оларды бөлек бассейнге бөлдік. Сіздің желіңіздің клиенттер желілерімен және олардың желілерімен бір-бірімен байланысы болмайтындай етіп ешқандай маршруттаусыз.

Бұл идея жүйеде маған қажет нысанды басқан кезде, орталық бақылау сервері барлық Mikrotik клиентінің SSH тіркелгілерін біле отырып, қажеттіге қосылып, қажетті хостқа жіберу ережесін жасайтынына көз жеткізу үшін пайда болды. қажетті порт. Мұнда бірнеше нүктелер бар. Шешім әмбебап емес - ол тек Mikrotik үшін жұмыс істейді, өйткені команда синтаксисі барлық маршрутизаторлар үшін әртүрлі. Сондай-ақ, мұндай қайта жіберулер қандай да бір жолмен жойылуы керек болды және біздің жүйенің серверлік бөлігі менің RDP сеансын аяқтағанымды бақылай алмады. Ал, мұндай қайта жіберу клиент үшін саңылау болып табылады. Бірақ біз әмбебаптыққа ұмтылмадық, өйткені... өнім тек біздің компанияда ғана қолданылған және оны көпшілікке шығару ойлары болған жоқ.

Мәселелердің әрқайсысы өзінше шешілді. Ереже жасалғанда, бұл қайта жіберу тек бір сыртқы IP мекенжайы үшін қолжетімді болды (қосылу инициализацияланған). Осылайша, қауіпсіздік саңылауынан аулақ болды. Бірақ әрбір осындай қосылыммен 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 сақтық көшірмесі

Біз барлық Микротиктің сақтық көшірмесін FTP жүйесіне конфигурацияладық. Ал жалпы бәрі жақсы болды. Бірақ сақтық көшірмені алу қажет болғанда, осы FTP-ні ашып, оны сол жерден іздеу керек болды. Бізде барлық маршрутизаторлар қосылған жүйе бар, біз құрылғылармен SSH арқылы байланыса аламыз. Жүйенің өзі күн сайын барлық Микротиктен сақтық көшірмелерді алатындай етіп неге біз мұны жасамасқа деп ойладым. Және оны жүзеге асыруға кірісті. Біз қосылып, сақтық көшірме жасап, оны жадқа алдық.

Микротиктен сақтық көшірме жасау үшін PHP-дегі сценарий коды:

<?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 қолданбасының ағымдағы нұсқасында бұл функция әлі жоқ, бірақ біз оны жақын арада тасымалдаймыз.

Оның ішкі жүйеде қалай көрінетінінің скриншоттары

Қалыпты деректер базасын сақтауға көшу

Артефактілердің пайда болғанын жоғарыда жазғанмын. Кейде жүйедегі барлық нысандар тізімі жай жоғалып кетті, кейде объектіні өңдеу кезінде ақпарат сақталмай қалады және нысанның атын үш рет өзгертуге тура келді. Бұл барлығын қатты тітіркендірді. Нысандардың жоғалуы сирек болды және дәл осы файлды қалпына келтіру арқылы оңай қалпына келтірілді, бірақ нысандарды өңдеу кезінде сәтсіздіктер жиі орын алды. Мүмкін, мен мұны бастапқыда дерекқор арқылы жасамаған шығармын, өйткені ол барлық қосылымдары бар ағашты тегіс кестеде қалай ұстауға болатыны туралы ойыма сәйкес келмеді. Ол тегіс, бірақ ағаш иерархиялық. Бірақ көп реттік қол жеткізу үшін жақсы шешім және кейіннен (жүйе күрделене түседі) транзакциялық, ДҚБЖ болып табылады. Мен бұл мәселеге бірінші рет тап болған жоқпын. Мен іздеуді бастадым. Маған дейін бәрі ойлап табылған және тегіс үстелден ағаш құрастыратын бірнеше алгоритмдер бар екені белгілі болды. Әрқайсысын қарап шыққаннан кейін мен олардың біреуін жүзеге асырдым. Бірақ бұл жүйенің жаңа нұсқасы болды, өйткені... Шындығында, осыған байланысты мен көп нәрсені қайта жазуға тура келді. Нәтиже табиғи болды, жүйенің кездейсоқ мінез-құлық мәселелері жойылды. Кейбіреулер бағдарламалық жасақтаманы әзірлеу саласында қателер өте әуесқойлық (бір ағынды сценарийлер, файлдағы әртүрлі ағындардан бір уақытта бірнеше рет қол жеткізілген ақпаратты сақтау және т.б.) деп айтуы мүмкін. Мүмкін бұл дұрыс шығар, бірақ менің негізгі жұмысым әкімшілік болды, ал бағдарламалау менің жанымды қинайтын нәрсе болды, менде бағдарламашылар тобында жұмыс істеу тәжірибем жоқ еді, мұндай қарапайым нәрселерді маған аға ағам бірден ұсынатын еді. жолдастар. Сондықтан, мен бұл төмпешіктердің барлығын өз бетімше толтырдым, бірақ мен материалды өте жақсы меңгердім. Сондай-ақ, менің жұмысым клиенттермен кездесулерді, компанияны алға жылжытуға бағытталған әрекеттерді, компаниядағы көптеген әкімшілік мәселелерді және тағы басқаларды қамтиды. Бірақ, қалай болғанда да, бұрыннан бар нәрсе сұранысқа ие болды. Жігіттер мен өзім өнімді күнделікті жұмысымызда қолдандық. Уақытты босқа кетіретін сәтсіз идеялар мен шешімдер болды, бірақ соңында бұл жұмыс істейтін құрал емес екені және оны ешкім пайдаланбағаны және Велиамға келмейтіні белгілі болды.

Анықтамалық қызмет – анықтамалық үстел

HelpDesk қалай құрылғанын айтудың қажеті жоқ. Бұл мүлдем басқа әңгіме, өйткені... Велиамда бұл 3-ші мүлдем жаңа нұсқа, ол барлық алдыңғы нұсқалардан ерекшеленеді. Енді бұл қарапайым жүйе, қажетсіз қоңыраулар мен ысқырықтарсыз интуитивті, доменмен біріктіру мүмкіндігі, сондай-ақ электрондық поштаның сілтемесі арқылы кез келген жерден бір пайдаланушы профиліне қол жеткізу мүмкіндігі. Ең бастысы, VNC арқылы өтініш берушіге кез келген жерден (үйде немесе кеңседе) VPN немесе портты бағыттаусыз тікелей қосымшадан қосылуға болады. Мен бұған қалай келгенімізді, бұрын не болғанын және қандай қорқынышты шешімдер қабылданғанын айтып беремін.

Біз пайдаланушылармен танымал TeamViewer арқылы қосылдық. Біз қызмет көрсететін барлық компьютерлерде теледидар орнатылған. Біз қателескен бірінші нәрсе, содан кейін оны жойдық, әрбір HD клиентін аппараттық құралға байланыстыру болды. Сұраныс қалдыру үшін пайдаланушы HD жүйесіне қалай кірді? Теледидардан басқа, әркімнің компьютерінде Лазар тілінде жазылған арнайы утилита орнатылған (мұнда көптеген адамдар көздерін жұмып, тіпті Google-ге кіретін шығар, бірақ мен білетін ең жақсы құрастырылған тіл Delphi болды, ал Лазарус дерлік. бірдей нәрсе, тек тегін). Тұтастай алғанда, пайдаланушы осы қызметтік бағдарламаны іске қосатын арнайы пакеттік файлды іске қосты, ол өз кезегінде жүйенің HWID-ін оқиды, содан кейін шолғыш іске қосылды және авторизация орын алды. Бұл не үшін жасалды? Кейбір компанияларда қызмет көрсетілетін пайдаланушылар саны жеке есептеледі, ал әр айға қызмет көрсету бағасы адам санына негізделеді. Бұл түсінікті, сіз айтасыз, бірақ ол неге аппараттық құралға байланысты? Бұл өте қарапайым, кейбір адамдар үйге келіп, үйдегі ноутбугынан «осы жерде мен үшін бәрін әдемі ет» стилінде өтініш жасады. HWID жүйесін оқумен қатар, утилита ағымдағы Teamviewer идентификаторын тізілімнен шығарып, оны бізге жіберді. Teamviewer-де интеграцияға арналған API бар. Және біз бұл интеграцияны жасадық. Бірақ бір қулық болды. Осы API арқылы пайдаланушы компьютеріне қосылу мүмкін емес, егер ол осы сеансты нақты бастамаса және оған қосылуға әрекеттенгеннен кейін ол «растау» түймесін басу керек. Ол кезде бізге ешкім пайдаланушының сұрауынсыз қосылмауы қисынды болып көрінді және адам компьютерде болғандықтан, ол сеансты бастайды және қашықтан қосылу сұрауына оң жауап береді. Бәрі дұрыс емес болып шықты. Үміткерлер сессияны бастауды басуды ұмытып, бұл туралы телефон арқылы сөйлесуге мәжбүр болды. Бұл уақытты босқа кетірді және процестің екі жағын да ренжітті. Оның үстіне, адам өтініш қалдыратын мұндай сәттер сирек емес, бірақ түскі асқа кеткенде ғана қосылуға рұқсат етіледі. Өйткені мәселе сын көтермейді және жұмыс процесінің үзілгенін қаламайды. Тиісінше, ол қосылуға рұқсат беру үшін ешбір түймені баспайды. HelpDesk жүйесіне кіру кезінде қосымша функция осылай пайда болды - Teamviwer идентификаторын оқу. Біз Teamviwer орнату кезінде пайдаланылатын тұрақты құпия сөзді білдік. Дәлірек айтқанда, оны тек жүйе ғана білді, өйткені ол орнатушыға және біздің жүйеге енгізілген. Тиісінше, қолданбадан қосылым түймесі пайда болды, оны басу арқылы ештеңе күтудің қажеті жоқ, бірақ Teamviewer бірден ашылды және қосылым пайда болды. Нәтижесінде мүмкін болатын қосылыстардың екі түрі болды. Ресми Teamviewer API және өзіміз жасаған API арқылы. Мені таң қалдырғаны, олар біріншісін пайдалануды бірден тоқтатты, дегенмен оны тек ерекше жағдайларда және пайдаланушының өзі рұқсат бергенде пайдалану туралы нұсқау бар еді. Сонда да қазір маған қауіпсіздікті беріңіз. Бірақ бұл өтініш берушілерге қажет емес болып шықты. Олардың барлығы растау түймешігінсіз оларға қосылғанымен өте жақсы.

Linux жүйесінде көп ағындылыққа ауысу

Алдын ала анықталған порттар тізімінің ашықтығы және желілік объектілердің қарапайым пингі үшін желілік сканердің өтуін жылдамдату мәселесі көптен бері туындай бастады. Бұл жерде, әрине, ойға келетін бірінші шешім көп ағынды болып табылады. Пингке жұмсалған негізгі уақыт пакеттің қайтарылуын күтетіндіктен және келесі пинг алдыңғы пакет қайтарылмайынша басталуы мүмкін емес, тіпті 20+ серверлері және желілік жабдықтары бар компанияларда бұл өте баяу жұмыс істеді. Мәселе мынада, бір бума жоғалып кетуі мүмкін, бірақ бұл туралы жүйелік әкімшіге дереу хабарламаңыз. Ол мұндай спамды өте тез қабылдауды тоқтатады. Бұл қол жетімсіздік туралы қорытынды жасамас бұрын әрбір нысанға бірнеше рет пинг жасау керек дегенді білдіреді. Тым көп егжей-тегжейге тоқталмай, оны параллельдеу қажет, өйткені бұл жасалмаса, жүйелік әкімші мәселе туралы бақылау жүйесінен емес, клиенттен білуі мүмкін.

PHP өзі қораптан тыс көп ағынды қолдамайды. Көп өңдеуге қабілетті, сіз аша аласыз. Бірақ, шын мәнінде, менде дауыс беру механизмі жазылған және мен оны дерекқордан барлық қажетті түйіндерді бір рет санап, барлығын бірден пингтеп, әрқайсысынан жауап күтетін және содан кейін бірден жазатындай етіп жасағым келді. деректер. Бұл оқу сұрауларының санын үнемдейді. Көп ағынды бұл идеяға тамаша сәйкес келеді. PHP үшін нақты көп ағынды жасауға мүмкіндік беретін PThreads модулі бар, дегенмен оны PHP 7.2-де орнату үшін жеткілікті көлемде жұмыс қажет болды, бірақ ол орындалды. Портты сканерлеу және пинг қазір жылдам. Ал, мысалы, бұрын бір айналымға 15 секунд емес, бұл процесс 2 секундқа созыла бастады. Бұл жақсы нәтиже болды.

Жаңа компаниялардың жылдам аудиті

Әртүрлі көрсеткіштер мен аппараттық сипаттамаларды жинау функционалдығы қалай пайда болды? Бәрі оңай. Кейде бізге ағымдағы АТ-инфрақұрылымды тексеруді тапсырады. Жаңа клиенттің аудитін тездету үшін де дәл осылай қажет. Бізге орта немесе ірі компанияға келіп, оларда не бар екенін тез анықтауға мүмкіндік беретін нәрсе керек болды. Менің ойымша, ішкі желідегі пингті өз өмірін қиындатқысы келетіндер ғана бұғаттайды, ал біздің тәжірибемізде олардың саны аз. Бірақ мұндай адамдар да бар. Тиісінше, қарапайым пингі бар құрылғылардың болуы үшін желілерді жылдам сканерлеуге болады. Содан кейін біз оларды қосып, бізді қызықтыратын ашық порттарды іздей аламыз. Шын мәнінде, бұл функция бұрыннан бар еді; ол көрсетілген желілерді сканерлеп, тізімге тапқанның барлығын қосу үшін орталық серверден бағыныштыға пәрменді қосу керек болды. Айта кетуді ұмытып кеттім, бізде конфигурацияланған жүйесі бар дайын кескін бар деп болжанған (құлдық бақылау сервері), оны аудит кезінде клиенттен жай ғана шығарып, оны бұлтқа қоса аламыз.

Бірақ аудиттің нәтижесі әдетте көптеген әртүрлі ақпаратты қамтиды және олардың бірі желідегі құрылғылардың түрі болып табылады. Біріншіден, бізді домен бөлігі ретінде Windows серверлері мен Windows жұмыс станциялары қызықтырды. Орта және ірі компанияларда доменнің болмауы ережеден ерекшелік болуы мүмкін. Бір тілде сөйлеу үшін, менің ойымша, орташа көрсеткіш 100+ адам. Барлық Windows машиналары мен серверлерінен олардың IP және домен әкімші тіркелгісін біле отырып, бірақ олардың әрқайсысына ешқандай бағдарламалық жасақтаманы орнатпай-ақ деректерді жинау әдісін ойлап табу керек болды. WMI интерфейсі көмекке келеді. Windows Management Instrumentation (WMI) сөзбе-сөз Windows басқару құралдарын білдіреді. WMI – Windows платформасында жұмыс істейтін компьютерлік инфрақұрылымның әртүрлі бөліктерінің жұмысын орталықтандырылған басқару және бақылаудың негізгі технологияларының бірі. Викиден алынды. Әрі қарай, Debian үшін wmic (бұл WMI клиенті) компиляциялау үшін қайта өңдеуге тура келді. Барлығы дайын болғаннан кейін қажетті ақпарат алу үшін wmic арқылы қажетті түйіндерді сұрау ғана қалды. WMI арқылы сіз Windows компьютерінен кез келген дерлік ақпаратты ала аласыз, сонымен қатар компьютерді ол арқылы басқара аласыз, мысалы, оны қайта жүктеуге жібере аласыз. Біздің жүйедегі Windows станциялары мен серверлері туралы ақпарат жинағы осылай пайда болды. Бұған қоса, ағымдағы жүйе жүктеме көрсеткіштері туралы ағымдағы ақпарат болды. Біз оларды жиі сұраймыз, ал аппараттық құралдар туралы ақпаратты сирек сұраймыз. Осыдан кейін аудит біршама жағымдырақ болды.

Бағдарламаны тарату туралы шешім

Біз өзіміз жүйені күнделікті қолданамыз және ол әрбір техникалық қызметкер үшін әрқашан ашық. Ал бізде бар нәрсені басқалармен бөлісе аламыз деп ойладық. Жүйе таратуға әлі дайын емес еді. Жергілікті нұсқа SaaS-ке айналуы үшін көп нәрсені қайта өңдеу керек болды. Оларға жүйенің әртүрлі техникалық аспектілеріндегі өзгерістер (қашықтағы қосылымдар, қолдау қызметі), лицензиялауға арналған модульдерді талдау, тұтынушылардың деректер базасын бөлшектеу, әрбір қызметтің масштабтауы және барлық бөліктерді автоматты жаңарту жүйелерін әзірлеу кіреді. Бірақ бұл мақаланың екінші бөлімі болады.

Жаңарту

Екінші бөлім

Ақпарат көзі: www.habr.com