Աութսորսինգից մինչև զարգացում (Մաս 1)

Բարև բոլորին, ես Սերգեյ Եմելյանչիկ եմ: Ես Աուդիտ-Տելեկոմ ընկերության ղեկավարն եմ, Veliam համակարգի հիմնական մշակողը և հեղինակը։ Ես որոշեցի հոդված գրել այն մասին, թե ինչպես ես և իմ ընկերը ստեղծեցինք աութսորսինգ ընկերություն, գրեցինք ծրագրակազմ մեզ համար և այնուհետև սկսեցի տարածել այն բոլորին SaaS համակարգի միջոցով: Այն մասին, թե ինչպես ես կտրականապես չէի հավատում, որ դա հնարավոր է։ Հոդվածը կպարունակի ոչ միայն պատմություն, այլև տեխնիկական մանրամասներ, թե ինչպես է ստեղծվել Veliam արտադրանքը։ Ներառյալ կոդով որոշ հատվածներ: Ես ձեզ կասեմ, թե ինչ սխալներ ենք թույլ տվել և ինչպես ենք դրանք ուղղել ավելի ուշ: Նման հոդված հրապարակել-չհրապարակել կասկածներ կային։ Բայց ես մտածեցի, որ ավելի լավ է դա անել, հետադարձ կապ ստանալ ու կատարելագործվել, քան հոդվածը չհրապարակել ու մտածել, թե ինչ կլիներ, եթե...

նախապատմությանը

Աշխատել եմ մեկ ընկերությունում՝ որպես ՏՏ աշխատակից։ Ընկերությունը բավականին մեծ էր՝ ընդարձակ ցանցային կառուցվածքով։ Աշխատանքային պարտականություններիս վրա չանդրադառնամ, միայն կասեմ, որ դրանք հաստատ ոչ մի բանի զարգացում չեն ներառել։

Մոնիտորինգ ունեինք, բայց զուտ ակադեմիական հետաքրքրությունից ելնելով ես ուզում էի փորձել գրել իմ ամենապարզը: Գաղափարը հետևյալն էր. ես ուզում էի, որ այն լինի համացանցում, որպեսզի կարողանայի հեշտությամբ մտնել առանց որևէ հաճախորդ տեղադրելու և տեսնել, թե ինչ է կատարվում ցանցի հետ ցանկացած սարքից, ներառյալ շարժական սարքը Wi-Fi-ի միջոցով, և ես նույնպես իսկապես ուզում էի արագ հասկանալ, թե սենյակում ինչ սարքավորում կա, որը դարձել է «մպեյ», քանի որ... շատ խիստ պահանջներ կային նման խնդիրների արձագանքման ժամանակի համար: Արդյունքում, իմ գլխում մի ծրագիր ծնվեց՝ գրել մի պարզ վեբ էջ, որի վրա կա jpeg ֆոն՝ ցանցային դիագրամով, կտրել սարքերն իրենց IP հասցեներով այս նկարում և ցուցադրել դինամիկ բովանդակություն վերևում։ նկարը անհրաժեշտ կոորդինատներում կանաչ կամ թարթող կարմիր IP հասցեի տեսքով: Խնդիրը դրված է, եկեք սկսենք:

Նախկինում ես ծրագրավորում էի Delphi-ում, PHP-ում, JS-ում և շատ մակերեսորեն C++-ում։ Ես լավ գիտեմ, թե ինչպես են աշխատում ցանցերը։ VLAN, Routing (OSPF, EIGRP, BGP), NAT: Սա բավական էր, որ ես ինքս գրեմ պարզունակ մոնիտորինգի նախատիպ։

Ես գրել եմ այն, ինչ պլանավորել եմ PHP-ում։ Apache և PHP սերվերը Windows-ում էր, քանի որ... Linux-ն ինձ համար այդ պահին անհասկանալի և շատ բարդ բան էր, ինչպես հետո պարզվեց, ես շատ սխալվեցի և շատ տեղերում Linux-ը շատ ավելի պարզ է, քան Windows-ը, բայց սա առանձին թեմա է, և մենք բոլորս գիտենք, թե քանի հոլիվարի կա վրան այս թեման. Windows-ի առաջադրանքների ժամանակացույցը փոքր ընդմիջումով (ես ճիշտ չեմ հիշում, բայց մոտավորապես երեք վայրկյանը մեկ անգամ) քաշեց PHP սկրիպտ, որը բոլոր օբյեկտները հավաքում էր սովորական ping-ով և պահում վիճակը ֆայլում:

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

Այո, այո, այդ պահին տվյալների բազայի հետ աշխատելը նույնպես ինձ համար յուրացված չէր։ Ես չգիտեի, որ հնարավոր է զուգահեռացնել գործընթացները, և ցանցի բոլոր հանգույցներով անցնելը երկար ժամանակ պահանջեց, քանի որ… սա տեղի ունեցավ մեկ թեմայում. Հատկապես խնդիրներ առաջացան, երբ մի քանի հանգույցներ անհասանելի էին, քանի որ նրանցից յուրաքանչյուրը հետաձգել է սցենարը 300 ms-ով: Հաճախորդի կողմից կար պարզ շրջադարձային ֆունկցիա, որը մի քանի վայրկյան ընդմիջումներով ներբեռնում էր թարմացված տեղեկատվությունը սերվերից Ajax-ի խնդրանքով և թարմացնում ինտերֆեյսը: Դե, ուրեմն, 3 անընդմեջ անհաջող պինգից հետո, եթե համակարգչում մոնիտորինգով վեբ էջ բաց էր, մի ուրախ կոմպոզիցիա էր նվագում։

Երբ ամեն ինչ ստացվեց, ես շատ ոգեշնչվեցի արդյունքից և մտածեցի, որ կարող եմ ավելին ավելացնել դրան (շնորհիվ իմ գիտելիքների և հնարավորությունների): Բայց ես միշտ չէի սիրում միլիոնավոր գծապատկերներով համակարգեր, որոնք այն ժամանակ կարծում էի, և մինչ օրս կարծում եմ, որ շատ դեպքերում ավելորդ են: Ես ուզում էի այնտեղ դնել միայն այն, ինչը իսկապես կօգնի ինձ իմ աշխատանքում: Այս սկզբունքը մնում է հիմնարար Վելիամի զարգացման համար մինչ օրս: Ավելին, ես հասկացա, որ շատ լավ կլիներ, եթե ես ստիպված չլինեի մոնիտորինգը բաց պահել և իմանալ խնդիրների մասին, և երբ դա տեղի ունենա, ապա բացեմ էջը և տեսնեմ, թե որտեղ է գտնվում այս խնդրահարույց ցանցային հանգույցը և ինչ անել դրա հետ հետո: . Ինչ-որ կերպ ես այն ժամանակ չեմ կարդացել էլփոստը, ես պարզապես չեմ օգտագործել այն: Համացանցում հանդիպեցի, որ կան SMS gateway-ներ, որոնց կարելի է ուղարկել GET կամ POST հարցում, և նրանք իմ բջջային հեռախոսին SMS կուղարկեն իմ գրած տեքստով։ Ես անմիջապես հասկացա, որ ես իսկապես ուզում եմ սա: Եվ ես սկսեցի ուսումնասիրել փաստաթղթերը: Որոշ ժամանակ անց ինձ հաջողվեց, և այժմ բջջային հեռախոսիս վրա ստացա SMS հաղորդագրություն ցանցում առկա խնդիրների մասին՝ «ընկած առարկայի» անունով։ Թեև համակարգը պարզունակ էր, բայց այն գրել եմ ես ինքս, և ամենակարևորը, որն ինձ դրդեց զարգացնել այն, որ դա կիրառական ծրագիր էր, որն իսկապես օգնեց ինձ իմ աշխատանքում:

Եվ հետո եկավ այն օրը, երբ ինտերնետ-ալիքներից մեկը խափանվեց աշխատավայրում, և իմ մոնիտորինգն ինձ թույլ չտվեց իմանալ այդ մասին: Քանի որ Google DNS-ը դեռ կատարյալ ping էր: Ժամանակն է մտածել, թե ինչպես կարող եք հետևել, որ կապի ալիքը կենդանի է: Տարբեր գաղափարներ կային, թե ինչպես դա անել: Ես չունեի բոլոր սարքավորումների հասանելիությունը: Մենք պետք է պարզեինք, թե ինչպես հասկանալ, թե ալիքներից որն է ուղիղ եթերում, բայց չկարողանալով ինչ-որ կերպ դիտել այն հենց ցանցային սարքավորումների վրա: Այնուհետև գործընկերներից մեկը հանդես եկավ այն մտքով, որ հնարավոր է, որ երթուղիների հետագծումը դեպի հանրային սերվերներ կարող է տարբերվել՝ կախված նրանից, թե որ կապի ալիքն է ներկայումս օգտագործվում ինտերնետ մուտք գործելու համար: Ստուգեցի ու այդպես ստացվեց։ Հետագծման ժամանակ եղել են տարբեր երթուղիներ։

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

Այսպիսով, հայտնվեց մեկ այլ սցենար, ավելի ճիշտ, ինչ-ինչ պատճառներով հետքը ավելացվեց նույն սկրիպտի վերջում, որը պինգ էր անում ցանցի բոլոր սարքերը: Ի վերջո, սա ևս մեկ երկար գործընթաց է, որն իրականացվել է նույն թեմայում և դանդաղեցրել է ամբողջ սցենարի աշխատանքը: Բայց հետո դա այնքան էլ ակնհայտ չէր. Բայց այսպես թե այնպես, նա իր գործն արեց, օրենսգիրքը խստորեն սահմանում էր, թե ինչպիսի հետագծում պետք է լինի ալիքներից յուրաքանչյուրի համար։ Այսպես սկսեց աշխատել համակարգը, որն արդեն վերահսկում էր (բարձրաձայն ասում էր, որովհետև ոչ մի չափման հավաքածու չկար, այլ պարզապես ping) ցանցային սարքեր (երթուղիչներ, անջատիչներ, wi-fi և այլն) և արտաքին աշխարհի հետ կապի ուղիները։ . SMS հաղորդագրությունները պարբերաբար հասնում էին, և գծապատկերը միշտ հստակ ցույց էր տալիս, թե որտեղ է խնդիրը:

Բացի այդ, ամենօրյա աշխատանքում ես ստիպված էի խաչաձեւ խաչաձեւում կատարել: Եվ ես հոգնել էի ամեն անգամ գնալ Cisco-ի սվիչերի մոտ, որպեսզի տեսնեմ, թե որ ինտերֆեյսը օգտագործել: Որքան լավ կլիներ մոնիտորինգի ժամանակ սեղմել օբյեկտի վրա և տեսնել դրա միջերեսների ցանկը նկարագրություններով: Դա ինձ ժամանակ կխնայի: Ավելին, այս սխեմայում կարիք չի լինի գործարկել Putty կամ SecureCRT՝ հաշիվներ և հրամաններ մուտքագրելու համար: Ես ուղղակի սեղմեցի մոնիտորինգի վրա, տեսա, թե ինչ է պետք ու գնացի իմ գործն անելու։ Ես սկսեցի ուղիներ փնտրել անջատիչների հետ փոխազդելու համար: Անմիջապես հանդիպեցի 2 տարբերակի՝ SNMP կամ SSH-ի միջոցով մուտք գործել անջատիչ, մուտքագրել ինձ անհրաժեշտ հրամանները և վերլուծել արդյունքը: Ես հրաժարվեցի SNMP-ից դրա իրականացման բարդության պատճառով, ես անհամբեր էի արդյունք ստանալու համար: SNMP-ի հետ դուք պետք է երկար ժամանակ փորփրեք MIB-ը և այս տվյալների հիման վրա ստեղծեք տվյալներ միջերեսների մասին: CISCO-ում հիանալի թիմ կա

show interface status

Այն հստակ ցույց է տալիս, թե ինչ է ինձ անհրաժեշտ խաչմերուկների համար: Ինչու՞ անհանգստանալ SNMP-ով, երբ ես պարզապես ուզում եմ տեսնել այս հրամանի արդյունքը, մտածեցի: Որոշ ժամանակ անց ես հասկացա այս հնարավորությունը։ Սեղմված է վեբ էջի օբյեկտի վրա: Գործարկվեց մի իրադարձություն, որի արդյունքում AJAX հաճախորդը կապվեց սերվերի հետ, և այն, իր հերթին, SSH-ի միջոցով միացավ ինձ անհրաժեշտ անջատիչին (հավատարմագրերը կոշտ կոդավորված էին կոդի մեջ, այն ճշգրտելու ցանկություն չկար, որոշ առանձին ընտրացանկեր պատրաստելու համար հնարավոր կլիներ փոխել հաշիվները ինտերֆեյսից, ինձ արդյունքն էր պետք և արագ) Ես այնտեղ մուտքագրեցի վերը նշված հրամանը և այն հետ ուղարկեցի բրաուզեր: Այսպիսով, ես սկսեցի տեսնել ինտերֆեյսների մասին տեղեկատվությունը մկնիկի մեկ սեղմումով: Սա չափազանց հարմար էր, հատկապես, երբ դուք պետք է դիտեիք այս տեղեկատվությունը միանգամից տարբեր անջատիչների վրա:

Հետքի վրա հիմնված ալիքների մոնիտորինգն ի վերջո լավագույն գաղափարը չէր, քանի որ... երբեմն ցանցում աշխատանքներ էին իրականացվում, և հետագծումը կարող էր փոխվել, և մոնիտորինգը սկսեց բղավել ինձ վրա, որ ալիքի հետ կապված խնդիրներ կան: Բայց վերլուծությունների վրա շատ ժամանակ ծախսելուց հետո հասկացա, որ բոլոր ալիքներն աշխատում են, և իմ մոնիտորինգն ինձ խաբում էր։ Արդյունքում, ես խնդրեցի իմ գործընկերներին, ովքեր կառավարում էին ալիք ձևավորող անջատիչներ, պարզապես ուղարկել ինձ syslog, երբ հարևանների տեսանելիության կարգավիճակը փոխվի: Համապատասխանաբար, այն շատ ավելի պարզ, արագ և ճշգրիտ էր, քան հետևելը: Հարևան կորցրած նման իրադարձություն է եկել, և ես անմիջապես ծանուցում եմ ալիքի դադարեցման մասին:

Ավելին, օբյեկտի վրա սեղմելիս հայտնվեցին ևս մի քանի հրամաններ, և SNMP-ն ավելացվեց որոշ չափումներ հավաքելու համար, և դա հիմնականում այն ​​է: Համակարգն այդպես էլ չզարգացավ: Այն արեց այն ամենը, ինչ անհրաժեշտ էր, դա լավ գործիք էր: Շատ ընթերցողներ, հավանաբար, ինձ կասեն, որ ինտերնետում արդեն կա շատ ծրագրային ապահովում՝ այս խնդիրները լուծելու համար: Բայց իրականում ես այն ժամանակ չէի որոնում նման անվճար ապրանքներ google-ում, և ես իսկապես ցանկանում էի զարգացնել իմ ծրագրավորման հմտությունները, և որն ավելի լավ միջոց է դրան մղել, քան իրական կիրառման խնդիրը: Այս պահին ավարտվել է մոնիտորինգի առաջին տարբերակը և այլևս չի փոփոխվել:

Աուդիտ-Տելեկոմ ընկերության ստեղծում

Ժամանակի ընթացքում ես սկսեցի կես դրույքով աշխատել այլ ընկերություններում, բարեբախտաբար իմ աշխատանքային գրաֆիկը ինձ թույլ տվեց դա անել: Երբ աշխատում եք տարբեր ընկերություններում, ձեր հմտությունները տարբեր ոլորտներում շատ արագ են աճում, և ձեր հորիզոնները լավ են զարգանում: Կան ընկերություններ, որոնցում, ինչպես ասում են, դու շվեդ ես, հնձվոր, շեփորահար։ Մի կողմից դժվար է, մյուս կողմից, եթե ծույլ չես, դառնում ես գեներալիստ, և դա թույլ է տալիս ավելի արագ և արդյունավետ լուծել խնդիրները, քանի որ գիտես, թե ինչպես է աշխատում հարակից դաշտը։

Ընկերս՝ Պավելը (նաև ՏՏ մասնագետ) անընդհատ փորձում էր ինձ խրախուսել իր բիզնեսը սկսելու համար։ Կային անհամար գաղափարներ, որոնցով նրանք անում էին տարբեր տարբերակներ: Սա տարիներ շարունակ քննարկվել է։ Եվ, ի վերջո, ոչինչ չպետք է հասներ, որովհետև ես թերահավատ եմ, իսկ Պավելը՝ երազող։ Ամեն անգամ, երբ նա ինչ-որ գաղափար էր առաջարկում, ես միշտ չէի հավատում դրան և հրաժարվում էի մասնակցել: Բայց մենք շատ էինք ուզում բացել մեր սեփական բիզնեսը։

Ի վերջո, մենք կարողացանք գտնել մի տարբերակ, որը հարմար էր երկուսիս էլ և անել այն, ինչ գիտենք, թե ինչպես անել: 2016 թվականին մենք որոշեցինք ստեղծել ՏՏ ընկերություն, որը կօգնի բիզնեսին լուծել ՏՏ խնդիրները։ Սա ՏՏ համակարգերի (1C, տերմինալային սերվեր, փոստի սերվեր և այլն) տեղակայումն է, դրանց սպասարկումը, օգտագործողների համար դասական HelpDesk և ցանցի կառավարում:

Անկեղծ ասած, ընկերության ստեղծման ժամանակ ես դրան չէի հավատում մոտ 99,9%: Բայց ինչ-որ կերպ Պավելը կարողացավ ստիպել ինձ փորձել, և առաջ նայելով՝ պարզվեց, որ նա ճիշտ էր։ Ես և Պավելը յուրաքանչյուրը 300 ռուբլով չպեցինք, գրանցեցինք «Աուդիտ-Տելեկոմ» նոր ՍՊԸ, վարձեցինք փոքրիկ գրասենյակ, պատրաստեցինք հիանալի այցեքարտեր, լավ, ընդհանուր առմամբ, ինչպես հավանաբար ամենաանփորձ, սկսնակ գործարարները, և սկսեցինք հաճախորդներ փնտրել: Հաճախորդներ գտնելը բոլորովին այլ պատմություն է: Թերևս մենք առանձին հոդված գրենք որպես կորպորատիվ բլոգի մաս, եթե որևէ մեկը հետաքրքրված է: Սառը զանգեր, թռուցիկներ և այլն: Սա ոչ մի արդյունք չտվեց։ Ինչպես հիմա կարդում եմ բիզնեսի մասին բազմաթիվ պատմություններից, այսպես թե այնպես, շատ բան կախված է բախտից: Մեր բախտը բերեց։ իսկ ընկերության ստեղծումից բառացիորեն մի քանի շաբաթ անց մեզ մոտեցավ եղբայրս՝ Վլադիմիրը, ով մեզ բերեց առաջին հաճախորդին։ Ես ձեզ չեմ ձանձրացնի հաճախորդների հետ աշխատելու մանրամասներով, հոդվածը դրա մասին չէ, պարզապես կասեմ, որ մենք գնացինք աուդիտի, բացահայտեցինք կրիտիկական ոլորտները և այդ ոլորտները փլուզվեցին, մինչ որոշում կայացվեց՝ արդյոք համագործակցել մեզ հետ շարունակական հիմունքներով որպես աութսորսներ: Սրանից հետո անմիջապես դրական որոշում է կայացվել.

Հետո, հիմնականում ընկերների միջոցով բանավոր խոսքի միջոցով, սկսեցին հայտնվել այլ սպասարկող ընկերություններ։ 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-ի կամ ծեփամածիկի մեջ ներկառուցված ստանդարտ mstsc.exe-ը, որը «պլագին»-ի մաս էր կազմում: Ես պլագին բառը դրեցի չակերտների մեջ, քանի որ սա դասական իմաստով բրաուզերի պլագին չէ:

Գոնե դա ինչ-որ բան էր։ Հարմար հասցեագիրք. Ավելին, Putty-ի դեպքում, ընդհանուր առմամբ, ամեն ինչ լավ էր, նրան կարելի էր IP կապեր, լոգին և գաղտնաբառ տալ որպես մուտքային պարամետրեր։ Նրանք. Մենք արդեն միացել ենք մեր ցանցի Linux սերվերներին մեկ սեղմումով՝ առանց գաղտնաբառեր մուտքագրելու։ Բայց RDP-ի դեպքում դա այնքան էլ պարզ չէ: Ստանդարտ mstsc-ը չի կարող հավատարմագրեր տրամադրել որպես պարամետրեր: Օգնության եկավ Remote Desktop Plus-ը: Նա թույլ տվեց, որ դա տեղի ունենա: Այժմ մենք կարող ենք առանց դրա, բայց երկար ժամանակ դա հավատարիմ օգնական էր մեր համակարգում: HTTP(S) կայքերում ամեն ինչ պարզ է, նման օբյեկտները պարզապես բացվում են բրաուզերում և վերջ։ Հարմարավետ և գործնական։ Բայց սա երջանկություն էր միայն ներքին ցանցում։

Քանի որ մենք խնդիրների ճնշող մեծամասնությունը լուծում էինք գրասենյակից հեռակա կարգով, ամենահեշտը VPN-ները հաճախորդների համար հասանելի դարձնելն էր. Եվ հետո նրանց հնարավոր եղավ միանալ մեր համակարգից։ Բայց դա դեռ որոշ չափով անհարմար էր։ Յուրաքանչյուր հաճախորդի համար անհրաժեշտ էր յուրաքանչյուր համակարգչի վրա պահել հիշվող VPN կապեր, իսկ որևէ մեկին միանալուց առաջ անհրաժեշտ էր միացնել համապատասխան VPN-ը: Մենք բավականին երկար ժամանակ օգտագործել ենք այս լուծումը։ Բայց հաճախորդների թիվն ավելանում է, VPN-ների թիվը նույնպես ավելանում է, և այս ամենը սկսեց լարվել, և պետք էր ինչ-որ բան անել դրա դեմ: Հատկապես արցունքներս հոսեցին համակարգը նորից տեղադրելուց հետո, երբ ես ստիպված էի նորից մուտքագրել տասնյակ VPN միացումներ նոր Windows պրոֆիլում։ Դադարեցրեք դա համբերել, ասացի ես, և սկսեցի մտածել, թե ինչ կարող եմ անել դրա դեմ:

Այնպես եղավ, որ բոլոր հաճախորդները որպես երթուղիչներ ունեին հայտնի Mikrotik ընկերության սարքերը: Նրանք շատ ֆունկցիոնալ են և հարմար գրեթե ցանկացած առաջադրանք կատարելու համար։ Բացասական կողմն այն է, որ նրանք «առևանգված են»: Մենք լուծեցինք այս խնդիրը պարզապես փակելով բոլոր մուտքերը դրսից: Բայց պետք էր ինչ-որ կերպ մուտք ունենալ դրանց՝ առանց հաճախորդի մոտ գալու, քանի որ... երկար է։ Մենք պարզապես թունելներ պատրաստեցինք յուրաքանչյուր նման միկրոտիկի համար և դրանք բաժանեցինք առանձին լողավազանի մեջ։ առանց որևէ երթուղավորման, որպեսզի ձեր ցանցի կապ չլինի հաճախորդների ցանցերի և նրանց ցանցերի հետ միմյանց հետ:

Գաղափարը ծնվեց՝ համոզվելու համար, որ երբ ես սեղմում եմ համակարգում ինձ անհրաժեշտ օբյեկտի վրա, կենտրոնական մոնիտորինգի սերվերը, իմանալով Mikrotik-ի բոլոր հաճախորդների SSH հաշիվները, միանում է ցանկալիին, ստեղծում է փոխանցման կանոն դեպի ցանկալի հոսթ՝ պահանջվող նավահանգիստ: Այստեղ կան մի քանի կետեր. Լուծումը համընդհանուր չէ. այն կաշխատի միայն Mikrotik-ի համար, քանի որ հրամանի շարահյուսությունը տարբեր է բոլոր երթուղիչների համար: Բացի այդ, այդպիսի վերահասցեավորումներն այնուհետև պետք է ինչ-որ կերպ ջնջվեին, և մեր համակարգի սերվերի մասը, ըստ էության, չէր կարող որևէ կերպ հետևել, թե արդյոք ես ավարտել եմ իմ RDP նիստը: Դե, նման վերահասցեավորումը հաճախորդի համար անցք է։ Բայց մենք չհետևեցինք ունիվերսալությանը, քանի որ... արտադրանքը օգտագործվել է միայն մեր ընկերության ներսում, և այն հանրությանը ներկայացնելու մտքեր չեն եղել:

Խնդիրներից յուրաքանչյուրը լուծվեց յուրովի։ Երբ կանոնը ստեղծվեց, այս վերահասցեավորումը հասանելի էր միայն մեկ կոնկրետ արտաքին IP հասցեի համար (որից կապը սկզբնավորվել էր): Այսպիսով, խուսափվեց անվտանգության անցքից: Բայց ամեն նման միացումով NAT-ի էջին ավելանում էր Mikrotik կանոնը և չէր մաքրվում։ Եվ բոլորը գիտեն, որ որքան շատ կանոններ կան, այնքան ավելի շատ է բեռնված երթուղիչի պրոցեսորը: Ու ընդհանրապես չէի կարող ընդունել, որ մի օր գնամ ինչ-որ Միկրոտիկ, ու հարյուրավոր մեռած, անպետք կանոններ լինեն։

Քանի որ մեր սերվերը չի կարող հետևել կապի կարգավիճակին, թող 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
	}
}

Իհարկե կարելի էր ավելի գեղեցիկ դարձնել, ավելի արագ և այլն, բայց ստացվեց, չբեռնեց Mikrotik-ը և կատարեց հիանալի աշխատանք։ Մենք վերջապես կարողացանք միանալ հաճախորդների սերվերներին և ցանցային սարքավորումներին ընդամենը մեկ սեղմումով: Առանց VPN բացելու կամ գաղտնաբառեր մուտքագրելու: Համակարգն իսկապես հարմար է դարձել աշխատելու համար։ Սպասարկման ժամանակը կրճատվեց, և մենք բոլորս ժամանակ անցկացրինք աշխատելով, այլ ոչ թե միանալու անհրաժեշտ օբյեկտներին:

Mikrotik Backup

Մենք կազմաձևեցինք ամբողջ Mikrotik-ի կրկնօրինակը FTP-ին: Եվ ընդհանուր առմամբ ամեն ինչ լավ էր: Բայց երբ դուք պետք է ստանաք կրկնօրինակ, դուք պետք է բացեիք այս FTP-ն և փնտրեք այն այնտեղ: Մենք ունենք համակարգ, որտեղ բոլոր երթուղիչները միացված են, մենք կարող ենք շփվել սարքերի հետ SSH-ի միջոցով: Ինչու՞ մենք այնպես չենք անում, որ համակարգն ինքն ամեն օր կրկնօրինակումներ վերցնի ամբողջ Mikrotik-ից, մտածեցի ես: Եվ նա սկսեց դա իրականացնել։ Մենք միացրինք, պահուստավորում արեցինք և տարանք պահեստ:

Script կոդը 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-ում բազմաթելային

Ցանցային սկաների անցումը արագացնելու հարցը նավահանգիստների կանխորոշված ​​ցուցակի բաց լինելու և ցանցի օբյեկտների պարզ պինգինգի համար վաղուց սկսել է առաջանալ: Այստեղ, իհարկե, առաջին լուծումը, որը գալիս է մտքին, բազմաթելային է: Քանի որ ping-ի վրա ծախսված հիմնական ժամանակը սպասում է փաթեթի վերադարձին, և հաջորդ պինգը չի կարող սկսվել մինչև նախորդ փաթեթը վերադարձվի, այն ընկերություններում, որոնք նույնիսկ ունեին 20+ սերվեր և ցանցային սարքավորումներ, սա արդեն բավականին դանդաղ էր աշխատում: Բանն այն է, որ մեկ փաթեթ կարող է անհետանալ, բայց դրա մասին անմիջապես չծանուցել համակարգի ադմինիստրատորին։ Նա պարզապես շատ արագ կդադարի նման սպամ ընդունել։ Սա նշանակում է, որ դուք պետք է յուրաքանչյուր օբյեկտի մի քանի անգամ պինգ կատարեք՝ նախքան անմատչելիության մասին եզրակացություն անելը։ Առանց շատ մանրամասնելու, անհրաժեշտ է զուգահեռացնել այն, քանի որ եթե դա չկատարվի, ապա, ամենայն հավանականությամբ, համակարգի ադմինիստրատորը խնդրի մասին կիմանա հաճախորդից, և ոչ թե մոնիտորինգի համակարգից:

PHP-ն ինքնին չի աջակցում տուփից դուրս բազմաթելային: Բազմամշակման ընդունակ, կարող եք պատառաքաղել: Բայց, փաստորեն, ես արդեն գրված ունեի հարցման մեխանիզմ և ուզում էի այնպես անել, որ մի անգամ հաշվեմ տվյալների բազայից ինձ անհրաժեշտ բոլոր հանգույցները, ամեն ինչ միանգամից ping, սպասեմ պատասխանի յուրաքանչյուրից և միայն դրանից հետո անմիջապես գրեմ: տվյալները։ Սա խնայում է կարդալու հարցումների քանակը: Multithreading-ը հիանալի տեղավորվում է այս գաղափարի մեջ: PHP-ի համար կա PThreads մոդուլ, որը թույլ է տալիս իրական multithreading անել, թեև PHP 7.2-ի վրա սա տեղադրելու համար պահանջվեց բավականին մեծ ծավալ, բայց դա արվեց: Նավահանգիստների սկանավորումն ու պինգն այժմ արագ են: Եվ փոխարեն, օրինակ, 15 վայրկյան մեկ շրջան ավելի վաղ, այս գործընթացը սկսեց տևել 2 վայրկյան: Լավ արդյունք էր։

Նոր ընկերությունների արագ աուդիտ

Ինչպե՞ս է առաջացել տարբեր չափումների և ապարատային բնութագրերի հավաքման ֆունկցիոնալությունը: Դա պարզ է. Երբեմն մեզ ուղղակի պատվիրում են աուդիտ իրականացնել ՏՏ ներկայիս ենթակառուցվածքում: Դե, նույնը անհրաժեշտ է նոր հաճախորդի աուդիտը արագացնելու համար։ Մեզ պետք էր մի բան, որը թույլ կտար գալ միջին կամ մեծ ընկերություն և արագ պարզել, թե ինչ ունեն: Իմ կարծիքով ներքին ցանցում պինգն արգելափակում են միայն նրանք, ովքեր ցանկանում են բարդացնել սեփական կյանքը, իսկ մեր փորձով նրանք քիչ են։ Բայց կան նաև այդպիսի մարդիկ։ Համապատասխանաբար, դուք կարող եք արագ սկանավորել ցանցերը սարքերի առկայության համար պարզ պինգով: Այնուհետև մենք կարող ենք դրանք ավելացնել և փնտրել մեզ հետաքրքրող բաց նավահանգիստները: Փաստորեն, այս ֆունկցիոնալությունն արդեն գոյություն ուներ, միայն անհրաժեշտ էր կենտրոնական սերվերից հրաման ավելացնել ստրուկին, որպեսզի այն սկանավորեր նշված ցանցերը և ավելացներ այն ամենը, ինչ գտել էր ցուցակում: Մոռացա նշել, ենթադրվում էր, որ մենք արդեն ունեինք պատրաստի պատկեր՝ կազմաձևված համակարգով (ստրուկ մոնիտորինգի սերվեր), որը կարող էինք ուղղակի աուդիտի ժամանակ դուրս հանել հաճախորդից և միացնել այն մեր ամպին։

Բայց աուդիտի արդյունքը սովորաբար ներառում է տարբեր տեղեկությունների փունջ, և դրանցից մեկն այն է, թե ինչպիսի սարքեր կան ցանցում: Առաջին հերթին, մեզ հետաքրքրում էին Windows սերվերները և Windows աշխատանքային կայանները որպես տիրույթի մաս: Քանի որ միջին և խոշոր ընկերություններում դոմենի բացակայությունը, հավանաբար, բացառություն է կանոնից։ Մեկ լեզվով խոսելու համար միջինը, իմ կարծիքով, 100+ մարդ է։ Պետք էր գտնել մի միջոց՝ տվյալների հավաքագրելու բոլոր Windows մեքենաներից և սերվերներից՝ իմանալով նրանց IP-ի և տիրույթի ադմինիստրատորի հաշիվը, բայց առանց դրանցից յուրաքանչյուրի վրա որևէ ծրագիր տեղադրելու: WMI ինտերֆեյսը գալիս է օգնության: Windows Management Instrumentation (WMI) բառացիորեն նշանակում է Windows կառավարման գործիքներ: WMI-ն Windows պլատֆորմով աշխատող համակարգչային ենթակառուցվածքի տարբեր մասերի կենտրոնացված կառավարման և մոնիտորինգի հիմնական տեխնոլոգիաներից մեկն է: Վերցված է վիքիից։ Այնուհետև ես ստիպված էի նորից թակել, որպեսզի կազմեմ wmic (սա WMI հաճախորդ է) Debian-ի համար: Այն բանից հետո, երբ ամեն ինչ պատրաստ էր, մնում էր պարզապես անհրաժեշտ տեղեկության համար անհրաժեշտ հանգույցների հարցումը wmic-ի միջոցով: WMI-ի միջոցով կարելի է Windows համակարգչից ստանալ գրեթե ցանկացած տեղեկություն, ավելին, դրա միջոցով կարելի է նաև կառավարել համակարգիչը, օրինակ ուղարկել այն reboot-ի։ Այսպես հայտնվեց մեր համակարգի Windows կայանների և սերվերների մասին տեղեկատվության հավաքածուն։ Բացի սրանից, առկա էր ընթացիկ տեղեկատվություն համակարգի ընթացիկ բեռնվածության ցուցանիշների մասին: Մենք դրանք ավելի հաճախ ենք խնդրում, իսկ սարքավորումների մասին՝ ավելի քիչ տեղեկություններ: Սրանից հետո աուդիտը մի փոքր ավելի հաճելի դարձավ։

Ծրագրային ապահովման բաշխման որոշում

Մենք ինքներս օգտվում ենք համակարգից ամեն օր, և այն միշտ բաց է յուրաքանչյուր տեխնիկական աշխատողի համար։ Եվ մենք մտածեցինք, որ կարող ենք կիսվել ուրիշների հետ այն, ինչ արդեն ունենք: Համակարգը դեռ պատրաստ չէր բաշխման։ Շատ բան պետք էր վերամշակել, որպեսզի տեղական տարբերակը վերածվեր SaaS-ի։ Դրանք ներառում են համակարգի տարբեր տեխնիկական ասպեկտների փոփոխություններ (հեռակա միացումներ, աջակցության ծառայություն), լիցենզավորման մոդուլների վերլուծություն, հաճախորդների տվյալների բազաների փոխանակում, յուրաքանչյուր ծառայության մասշտաբավորում և բոլոր մասերի համար ավտոմատ թարմացման համակարգերի մշակում: Բայց սա կլինի հոդվածի երկրորդ մասը։

Թարմացումներ

Երկրորդ մասը

Source: www.habr.com