Մենք վերահսկում ենք Sportmaster-ը` ինչպես և ինչով

Մտածեցինք մոնիտորինգի համակարգ ստեղծելու մասին ապրանքային թիմերի ձևավորման փուլում։ Պարզ դարձավ, որ մեր բիզնեսը՝ շահագործումը, այս թիմերի մեջ չի մտնում։ Ինչո՞ւ է այդպես։

Փաստն այն է, որ մեր բոլոր թիմերը կառուցված են անհատական ​​տեղեկատվական համակարգերի, միկրոծառայությունների և ճակատների շուրջ, ուստի թիմերը չեն տեսնում ամբողջ համակարգի ընդհանուր առողջությունը որպես ամբողջություն: Օրինակ, նրանք կարող են չգիտեն, թե ինչպես է խորը հետնամասի որոշ փոքր մասն ազդում առջևի ծայրի վրա: Նրանց հետաքրքրության շրջանակը սահմանափակվում է այն համակարգերով, որոնց հետ իրենց համակարգը ինտեգրված է: Եթե ​​թիմը և նրա A ծառայությունը գրեթե կապ չունեն B ծառայության հետ, ապա այդպիսի ծառայությունը գրեթե անտեսանելի է թիմի համար:

Մեր թիմն իր հերթին աշխատում է համակարգերի հետ, որոնք շատ ամուր են ինտեգրված միմյանց հետ. նրանց միջև շատ կապեր կան, սա շատ մեծ ենթակառուցվածք է։ Իսկ առցանց խանութի շահագործումը կախված է այս բոլոր համակարգերից (որոնցից, ի դեպ, մենք ունենք հսկայական քանակություն)։

Այսպիսով, ստացվում է, որ մեր բաժինը ոչ մի թիմի չի պատկանում, այլ գտնվում է մի փոքր այն կողմ: Այս ամբողջ պատմության մեջ մեր խնդիրն է համակողմանիորեն հասկանալ, թե ինչպես են աշխատում տեղեկատվական համակարգերը, դրանց ֆունկցիոնալությունը, ինտեգրումները, ծրագրային ապահովումը, ցանցը, սարքաշարը և ինչպես են այս ամենը կապված միմյանց հետ:

Այն հարթակը, որտեղ գործում են մեր առցանց խանութները, ունի հետևյալ տեսքը.

• ճակատ
• միջին գրասենյակ
• ետ գրասենյակ

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

Իդեալում, պլատֆորմի ամբողջ առողջության մոնիտորինգը պետք է ավտոմատացված լինի: Եվ մենք եկանք մոնիտորինգին՝ որպես այս գործընթացի անխուսափելի մաս։ Սկզբում այն ​​կառուցված էր միայն առաջին գծի համար, մինչդեռ ցանցի մասնագետները, ծրագրային ապահովման և սարքավորումների ադմինիստրատորները ունեին և ունեն իրենց շերտ առ շերտ մոնիտորինգի համակարգերը։ Այս բոլոր մարդիկ դիտարկմանը հետևել են միայն իրենց մակարդակով, ոչ ոք նույնպես համակողմանի ըմբռնում չի ունեցել։

Օրինակ, եթե վիրտուալ մեքենան խափանում է, շատ դեպքերում դրա մասին գիտի միայն սարքավորման և վիրտուալ մեքենայի համար պատասխանատու ադմինիստրատորը: Նման դեպքերում առաջնագծի թիմը տեսել է հավելվածի խափանման փաստը, սակայն վիրտուալ մեքենայի խափանման մասին տվյալներ չի ունեցել։ Եվ ադմինիստրատորը կարող է իմանալ, թե ով է հաճախորդը և մոտավոր պատկերացում ունենալ, թե ինչ է ներկայումս աշխատում այս վիրտուալ մեքենայի վրա, պայմանով, որ դա ինչ-որ մեծ նախագիծ է: Նա, ամենայն հավանականությամբ, չգիտի փոքրիկների մասին: Ամեն դեպքում, ադմինիստրատորը պետք է գնա սեփականատիրոջ մոտ և հարցնի, թե ինչ կար այս մեքենայի վրա, ինչը պետք է վերականգնվի և ինչ պետք է փոխվի: Եվ եթե իսկապես ինչ-որ լուրջ բան խափանվեր, նրանք սկսեցին շրջել շրջանակներով, քանի որ ոչ ոք չէր տեսնում համակարգը որպես ամբողջություն:

Ի վերջո, նման անհամապատասխան պատմությունները ազդում են ողջ ճակատի, օգտատերերի և մեր հիմնական բիզնեսի վրա՝ առցանց վաճառքի վրա: Քանի որ մենք թիմի մաս չենք, այլ զբաղվում ենք էլեկտրոնային առևտրի բոլոր հավելվածների գործարկմամբ՝ որպես առցանց խանութի մաս, մենք ստանձնեցինք էլեկտրոնային առևտրի հարթակի մոնիտորինգի համապարփակ համակարգ ստեղծելու խնդիրը:

Համակարգի կառուցվածքը և կույտը

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

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

Ուստի որոշեցին փղին մաս-մաս ուտել։

Մեր համակարգը բաղկացած է.

• ապարատային;
• օպերացիոն համակարգ;
• ծրագրային ապահովում;
• UI մասեր մոնիտորինգի հավելվածում;
• բիզնեսի չափումներ;
• ինտեգրացիոն հավելվածներ;
• տեղեկատվական անվտանգություն;
• ցանցեր;
• երթեւեկության հավասարակշռող.

Այս համակարգի կենտրոնում ինքնին մոնիտորինգն է: Ամբողջ համակարգի վիճակը ընդհանուր առմամբ հասկանալու համար դուք պետք է իմանաք, թե ինչ է կատարվում հավելվածների հետ այս բոլոր շերտերում և հավելվածների ողջ փաթեթում:

Այսպիսով, բուրգի մասին:

Մենք օգտագործում ենք բաց կոդով ծրագրակազմ: Կենտրոնում մենք ունենք Zabbix, որը մենք օգտագործում ենք հիմնականում որպես ահազանգման համակարգ: Բոլորը գիտեն, որ այն իդեալական է ենթակառուցվածքների մոնիտորինգի համար: Ինչ է սա նշանակում? Հենց այն ցածր մակարդակի չափիչները, որոնք ունեն յուրաքանչյուր ընկերություն, որը պահպանում է իր սեփական տվյալների կենտրոնը (իսկ Sportmaster-ն ունի իր սեփական տվյալների կենտրոնները)՝ սերվերի ջերմաստիճանը, հիշողության կարգավիճակը, ռեյդը, ցանցային սարքի չափումները:

Մենք ինտեգրել ենք Zabbix-ը Telegram մեսենջերի և Microsoft Teams-ի հետ, որոնք ակտիվորեն օգտագործվում են թիմերում։ Zabbix-ը ծածկում է իրական ցանցի շերտը, սարքաշարը և որոշ ծրագրեր, բայց դա համադարման չէ: Մենք հարստացնում ենք այս տվյալները որոշ այլ ծառայություններից: Օրինակ, ապարատային մակարդակում մենք API-ի միջոցով ուղղակիորեն միանում ենք մեր վիրտուալացման համակարգին և հավաքում տվյալներ:

Էլ ինչ. Բացի Zabbix-ից, մենք օգտագործում ենք Prometheus-ը, որը թույլ է տալիս վերահսկել չափումները դինամիկ միջավայրի հավելվածում: Այսինքն՝ մենք կարող ենք ստանալ հավելվածի չափումներ HTTP վերջնակետի միջոցով և չանհանգստանալ, թե որ չափորոշիչները բեռնել դրա մեջ և որոնք՝ ոչ: Այս տվյալների հիման վրա կարող են մշակվել վերլուծական հարցումներ:

Այլ շերտերի տվյալների աղբյուրները, օրինակ՝ բիզնեսի չափումները, բաժանված են երեք բաղադրիչի.

Նախ, դրանք արտաքին բիզնես համակարգեր են, Google Analytics, մենք չափումներ ենք հավաքում տեղեկամատյաններից: Դրանցից մենք ստանում ենք տվյալներ ակտիվ օգտատերերի, փոխակերպումների և բիզնեսի հետ կապված մնացած ամեն ինչի մասին։ Երկրորդ, սա UI մոնիտորինգի համակարգ է: Այն պետք է ավելի մանրամասն նկարագրվի:

Ժամանակին մենք սկսեցինք ձեռքով թեստավորում, և այն վերածվեց ֆունկցիոնալության և ինտեգրման ավտոմատ թեստերի: Սրանից մենք մոնիտորինգ իրականացրեցինք՝ թողնելով միայն հիմնական ֆունկցիոնալությունը, և հիմնվեցինք հնարավորինս կայուն մարկերի վրա, որոնք ժամանակի ընթացքում հաճախ չեն փոխվում:

Թիմի նոր կառուցվածքը նշանակում է, որ կիրառման բոլոր գործողությունները սահմանափակվում են արտադրանքի թիմերով, ուստի մենք դադարեցինք մաքուր փորձարկումներ անել: Փոխարենը, մենք UI մոնիտորինգ ենք արել Java, Selenium և Jenkins լեզուներով գրված թեստերից (օգտագործվում է որպես հաշվետվություններ գործարկելու և ստեղծելու համակարգ):

Մենք շատ թեստեր անցկացրեցինք, բայց ի վերջո որոշեցինք գնալ գլխավոր ճանապարհ՝ վերին մակարդակի մետրիկ: Իսկ եթե մենք շատ կոնկրետ թեստեր ունենանք, ապա տվյալները թարմացնելը դժվար կլինի։ Յուրաքանչյուր հաջորդ թողարկում էապես կխախտի ամբողջ համակարգը, և այն ամենը, ինչ մենք կանենք, դա ուղղելն է: Հետևաբար, մենք կենտրոնացել ենք շատ հիմնարար բաների վրա, որոնք հազվադեպ են փոխվում, և մենք միայն վերահսկում ենք դրանք:

Վերջապես, երրորդը, տվյալների աղբյուրը կենտրոնացված անտառահատումների համակարգ է: Մենք օգտագործում ենք Elastic Stack-ը տեղեկամատյանների համար, այնուհետև մենք կարող ենք այս տվյալները ներգրավել մեր մոնիտորինգի համակարգ բիզնեսի չափումների համար: Ի հավելումն այս ամենի, մենք ունենք մեր սեփական Monitoring API ծառայությունը՝ գրված Python-ով, որը հարցում է անում ցանկացած ծառայության API-ի միջոցով և տվյալների հավաքում դրանցից Zabbix-ում:

Մոնիտորինգի մեկ այլ անփոխարինելի հատկանիշ է վիզուալիզացիան: Մերը հիմնված է Grafana-ի վրա: Այն առանձնանում է այլ վիզուալիզացիայի համակարգերից նրանով, որ թույլ է տալիս պատկերացնել չափումները տարբեր տվյալների աղբյուրներից վահանակի վրա: Մենք կարող ենք հավաքել առցանց խանութի վերին մակարդակի ցուցանիշներ, օրինակ՝ DBMS-ից վերջին ժամում կատարված պատվերների քանակը, OS-ի կատարողականի ցուցանիշները, որոնց վրա այս առցանց խանութն աշխատում է Zabbix-ից, և չափումներ այս հավելվածի օրինակների համար։ Պրոմեթևսից։ Եվ այս ամենը կլինի մեկ վահանակի վրա: Պարզ և մատչելի:

Անվտանգության մասին նշեմ. մենք ներկայումս վերջնական տեսքի ենք բերում համակարգը, որը հետագայում ինտեգրելու ենք գլոբալ մոնիտորինգի համակարգին։ Իմ կարծիքով, հիմնական խնդիրները, որոնց բախվում է էլեկտրոնային առևտուրը տեղեկատվական անվտանգության ոլորտում, կապված են բոտերի, վերլուծիչների և բիրտ ուժի հետ։ Մենք պետք է հետևենք դրան, քանի որ այս ամենը կարող է խիստ ազդել և՛ մեր հավելվածների աշխատանքի վրա, և՛ մեր հեղինակության վրա՝ բիզնեսի տեսանկյունից: Եվ ընտրված ստեկով մենք հաջողությամբ ծածկում ենք այս խնդիրները:

Մեկ այլ կարևոր կետ այն է, որ կիրառական շերտը հավաքվում է Պրոմեթևսի կողմից: Նա ինքը նույնպես ինտեգրված է Zabbix-ի հետ։ Եվ մենք նաև ունենք կայքի արագություն՝ ծառայություն, որը թույլ է տալիս մեզ դիտել այնպիսի պարամետրեր, ինչպիսիք են մեր էջի բեռնման արագությունը, խցանումները, էջի ցուցադրումը, բեռնման սկրիպտները և այլն, այն նաև ինտեգրված է API: Այսպիսով, մեր ցուցանիշները հավաքվում են Zabbix-ում, և, համապատասխանաբար, մենք նույնպես ահազանգում ենք այնտեղից: Բոլոր ծանուցումները ներկայումս ուղարկվում են ուղարկման հիմնական եղանակներին (այժմ դա էլփոստն ու հեռագիրն է, MS Teams-ը նույնպես վերջերս է միացվել): Նախատեսվում է արդիականացնել ահազանգը այնպիսի վիճակի, որ խելացի բոտերը աշխատեն որպես ծառայություն և մոնիտորինգի տեղեկատվություն տրամադրեն բոլոր շահագրգիռ արտադրանքի թիմերին:

Մեզ համար չափորոշիչները կարևոր են ոչ միայն առանձին տեղեկատվական համակարգերի համար, այլև ընդհանուր չափումները ամբողջ ենթակառուցվածքի համար, որն օգտագործում են հավելվածները. . Գումարած չափումներ մեր սեփական տվյալների կենտրոնների համար (մենք ունենք դրանցից մի քանիսը, և ենթակառուցվածքը բավականին մեծ է):

Մեր մոնիտորինգի համակարգի առավելություններն այն են, որ դրա օգնությամբ մենք տեսնում ենք բոլոր համակարգերի առողջական վիճակը և կարող ենք գնահատել դրանց ազդեցությունը միմյանց և ընդհանուր ռեսուրսների վրա: Եվ, ի վերջո, դա մեզ թույլ է տալիս ներգրավվել ռեսուրսների պլանավորման մեջ, ինչը նաև մեր պարտականությունն է: Մենք կառավարում ենք սերվերի ռեսուրսները՝ լողավազան էլեկտրոնային առևտրի շրջանակներում, նոր սարքավորումների շահագործում և շահագործումից հանում, լրացուցիչ նոր սարքավորումներ ձեռք բերում, ռեսուրսների օգտագործման աուդիտ և այլն: Ամեն տարի թիմերը պլանավորում են նոր նախագծեր, զարգացնում իրենց համակարգերը, և մեզ համար կարևոր է նրանց ռեսուրսներով ապահովելը:

Եվ չափումների օգնությամբ մենք տեսնում ենք մեր տեղեկատվական համակարգերի կողմից ռեսուրսների սպառման միտումը: Եվ դրանց հիման վրա մենք կարող ենք ինչ-որ բան պլանավորել։ Վիրտուալացման մակարդակում մենք հավաքում ենք տվյալներ և տեսնում ենք տվյալների առկա քանակի ռեսուրսների վերաբերյալ տեղեկատվություն տվյալների կենտրոնի կողմից: Եվ արդեն տվյալների կենտրոնի ներսում դուք կարող եք տեսնել ռեսուրսների վերամշակումը, իրական բաշխումը և սպառումը: Ավելին, ինչպես ինքնուրույն սերվերների, այնպես էլ վիրտուալ մեքենաների և ֆիզիկական սերվերների կլաստերների հետ, որոնց վրա այս բոլոր վիրտուալ մեքենաները ակտիվորեն պտտվում են:

Հեռանկարները

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

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

Այս իրավիճակում մենք ահազանգերից կստանանք սպամ, և դա այլևս չի տեղավորվում պատշաճ մոնիտորինգի համակարգի ձևաչափի մեջ: Հարաբերակցության հարց է առաջանում. Հետևաբար, իդեալականորեն, մեր մոնիտորինգի համակարգը պետք է ասի. «Տղե՛րք, ձեր ֆիզիկական մեքենան մահացել է, և դրա հետ մեկտեղ այս հավելվածն ու այս չափումները», մեկ ահազանգի օգնությամբ՝ մեզ հարյուրավոր ահազանգերով կատաղի ռմբակոծելու փոխարեն: Այն պետք է զեկուցի հիմնականը` պատճառը, որն օգնում է արագ վերացնել խնդիրը դրա տեղայնացման շնորհիվ:

Մեր ծանուցման համակարգը և ահազանգերի մշակումը կառուցված է շուրջօրյա թեժ գծի ծառայության շուրջ: Բոլոր ահազանգերը, որոնք համարվում են պարտադիր և ներառված են ստուգաթերթում, ուղարկվում են այնտեղ: Յուրաքանչյուր ահազանգ պետք է ունենա նկարագրություն՝ ինչ է տեղի ունեցել, իրականում ինչ է նշանակում, ինչի վրա է այն ազդում: Եվ նաև հղում դեպի վահանակ և հրահանգներ, թե ինչ անել այս դեպքում:

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

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

Ի լրումն մեր կողմից գործած համակարգերի մոնիտորինգի և մեր կողմից կարևոր համարվող չափանիշների հավաքագրմանը, մոնիտորինգի համակարգը թույլ է տալիս մեզ տվյալներ հավաքել արտադրանքի թիմերի համար: Նրանք կարող են ազդել չափումների կազմի վրա մեր մշտադիտարկվող տեղեկատվական համակարգերում:

Մեր գործընկերը կարող է գալ և խնդրել ավելացնել որոշ չափումներ, որոնք օգտակար կլինեն և՛ մեզ, և՛ թիմի համար: Կամ, օրինակ, թիմը կարող է բավարար չափով չունենալ մեր ունեցած հիմնական ցուցանիշները, նրանք պետք է հետևեն որոշ կոնկրետներին: Grafana-ում մենք ստեղծում ենք տարածք յուրաքանչյուր թիմի համար և տրամադրում ենք ադմինիստրատորի իրավունքներ: Բացի այդ, եթե թիմին անհրաժեշտ են վահանակներ, բայց նրանք իրենք չեն կարող/չգիտեն ինչպես դա անել, մենք օգնում ենք նրանց:

Քանի որ մենք դուրս ենք թիմի արժեքների ստեղծման, դրանց թողարկումների և պլանավորման հոսքից, մենք աստիճանաբար գալիս ենք այն եզրակացության, որ բոլոր համակարգերի թողարկումներն անխափան են և կարող են ամեն օր տարածվել առանց մեզ հետ համաձայնեցնելու: Եվ մեզ համար կարևոր է վերահսկել այս թողարկումները, քանի որ դրանք կարող են ազդել հավելվածի աշխատանքի վրա և ինչ-որ բան կոտրել, և դա կարևոր է: Թողարկումները կառավարելու համար մենք օգտագործում ենք Bamboo-ն, որտեղից մենք տվյալներ ենք ստանում API-ի միջոցով և կարող ենք տեսնել, թե որ թողարկումներն են թողարկվել տեղեկատվական համակարգերում և դրանց կարգավիճակը: Եվ ամենակարեւորն այն է, թե որ ժամին։ Հիմնական կրիտիկական չափանիշների վրա մենք տեղադրում ենք թողարկման մարկերներ, ինչը տեսողականորեն շատ ցուցիչ է խնդիրների դեպքում:

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

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

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

Եթե ​​դուք նաև վերահսկում եք խոշոր նախագծերը զգալի թվով ինտեգրացիաներով, ապա գրեք մեկնաբանություններում, թե ինչ արծաթե փամփուշտ եք գտել դրա համար:

Source: www.habr.com