Մենք փղին ուտում ենք մաս-մաս: Կիրառեք առողջության մոնիտորինգի ռազմավարությունը օրինակներով

Hello everyone!

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

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

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

Մոնիտորինգի ռազմավարություն

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

Ինչպե՞ս կարելի է փիղ ուտել: Միայն մասերով! Մենք օգտագործում ենք այս մոտեցումը հավելվածների մոնիտորինգի համար:

Մեր մոնիտորինգի ռազմավարության էությունը.

Ձեր դիմումը բաժանեք բաղադրիչների:
Ստեղծեք հսկիչ ստուգումներ յուրաքանչյուր բաղադրիչի համար:

Բաղադրիչը համարվում է լավ վիճակում, եթե նրա բոլոր հսկիչ ստուգումները կատարվում են առանց սխալների: Հավելվածը համարվում է առողջ, եթե դրա բոլոր բաղադրիչները ֆունկցիոնալ են:

Այսպիսով, ցանկացած համակարգ կարող է ներկայացվել որպես բաղադրիչների ծառ: Բարդ բաղադրիչները բաժանվում են ավելի պարզների: Պարզ բաղադրիչներն ունեն ստուգումներ:

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

Հրաշքներ չկան, ստուգումների մեծ մասը պետք է ինքնուրույն մշակվի: Բայց մի վախեցեք, քանի որ շատ դեպքերում մեկ ստուգումը վերցնում է 5-10 տող կոդ, բայց դուք կարող եք իրականացնել ցանկացած տրամաբանություն և հստակ կհասկանաք, թե ինչպես է աշխատում ստուգումը:

Մոնիտորինգի համակարգ

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

Մեզ անհրաժեշտ կլինի մոնիտորինգի համակարգ. Նա կկատարի հետևյալ առաջադրանքները.

• Ստացեք թեստի արդյունքները և օգտագործեք դրանք բաղադրիչների կարգավիճակը որոշելու համար:
  Տեսողականորեն սա կարծես կարևորում է բաղադրիչի ծառը: Ֆունկցիոնալ բաղադրիչները դառնում են կանաչ, խնդրահարույցները՝ կարմիր։
• Կատարեք ընդհանուր ստուգումներ տուփից դուրս:
  Մոնիտորինգի համակարգը կարող է ինքնուրույն կատարել որոշ ստուգումներ: Ինչու՞ նորից հորինել անիվը, եկեք դրանք օգտագործենք: Օրինակ, կարող եք ստուգել, ​​որ վեբկայքի էջը բացվում է կամ սերվերը զանգում է:
• Խնդրի մասին ծանուցումներ ուղարկեք շահագրգիռ կողմերին:
• Մոնիտորինգի տվյալների պատկերացում, հաշվետվությունների, գրաֆիկների և վիճակագրության տրամադրում:

ASMO համակարգի համառոտ նկարագրությունը

Ավելի լավ է բացատրել օրինակով: Եկեք նայենք, թե ինչպես է կազմակերպվում ASMO համակարգի աշխատանքի մոնիտորինգը:

ASMO-ն օդերևութաբանական աջակցության ավտոմատացված համակարգ է: Համակարգն օգնում է ճանապարհային ծառայության մասնագետներին հասկանալ, թե որտեղ և երբ է անհրաժեշտ ճանապարհը մաքրել սառցակալման նյութերով: Համակարգը տվյալներ է հավաքում ճանապարհային կառավարման կետերից: Ճանապարհային կառավարման կետը ճանապարհի այն տեղն է, որտեղ տեղադրվում են սարքավորումներ՝ օդերեւութաբանական կայան, տեսախցիկ և այլն: Վտանգավոր իրավիճակները կանխատեսելու համար համակարգը եղանակի կանխատեսումներ է ստանում արտաքին աղբյուրներից:

Այսպիսով, համակարգի կազմը բավականին բնորոշ է՝ կայք, գործակալ, սարքավորում։ Սկսենք մոնիտորինգը.

Համակարգի բաժանումը բաղադրիչների

ASMO համակարգում կարելի է առանձնացնել հետևյալ բաղադրիչները.

1. Անձնական հաշիվ
Սա վեբ հավելված է: Առնվազն, դուք պետք է ստուգեք, որ հավելվածը հասանելի է ինտերնետում:

2. Տվյալների բազա
Տվյալների բազան պահում է տվյալներ, որոնք կարևոր են հաշվետվության համար, և դուք պետք է ապահովեք, որ տվյալների բազայի կրկնօրինակները հաջողությամբ ստեղծվեն:

3. Սերվեր
Սերվեր ասելով մենք հասկանում ենք այն սարքաշարը, որի վրա աշխատում են հավելվածները: Անհրաժեշտ է ստուգել HDD-ի, RAM-ի, CPU-ի կարգավիճակը:

4. Գործակալ
Սա Windows ծառայություն է, որը ժամանակացույցով կատարում է բազմաթիվ տարբեր առաջադրանքներ: Առնվազն, դուք պետք է ստուգեք, որ ծառայությունը աշխատում է:

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

6. Ճանապարհային կառավարման կետեր (բոլոր MPC-ների բեռնարկղերը)
Ճանապարհների կառավարման բազմաթիվ կետեր կան, ուստի եկեք միավորենք բոլոր MPC-ները մեկ բաղադրիչում: Սա ավելի հարմար կդարձնի մոնիտորինգի տվյալների ընթերցումը: «ASMO համակարգի» բաղադրիչի կարգավիճակը դիտելիս անմիջապես պարզ կդառնա, թե որտեղ են խնդիրները՝ հավելվածներում, ապարատում, թե առավելագույն կառավարման համակարգում:

7. Ճանապարհային կառավարման կետ (մեկ առավելագույն սահման)
Մենք այս բաղադրիչը կհամարենք սպասարկվող, եթե այս MPC-ի բոլոր սարքերը սպասարկելի են:

8. Սարք
Սա տեսախցիկ կամ եղանակային կայան է, որը տեղադրված է առավելագույն կոնցենտրացիայի սահմաններում: Անհրաժեշտ է ստուգել, ​​որ սարքը ճիշտ է աշխատում։

Մոնիտորինգի համակարգում բաղադրիչի ծառը կունենա հետևյալ տեսքը.

Վեբ հավելվածների մոնիտորինգ

Այսպիսով, մենք համակարգը բաժանել ենք բաղադրիչների, այժմ պետք է ստուգումներ մտցնել յուրաքանչյուր բաղադրիչի համար:

Վեբ հավելվածը վերահսկելու համար մենք օգտագործում ենք հետևյալ ստուգումները.

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

2. Դոմենի վճարման վերջնաժամկետի ստուգում
Շատ կարևոր ստուգում. Երբ տիրույթը մնում է չվճարված, օգտվողները չեն կարող բացել կայքը: Խնդրի լուծումը կարող է տեւել մի քանի օր, քանի որ... DNS փոփոխությունները անմիջապես չեն կիրառվում:

3. SSL վկայագրի ստուգում
Մեր օրերում գրեթե բոլոր կայքերը մուտք գործելու համար օգտագործում են https արձանագրությունը։ Որպեսզի արձանագրությունը ճիշտ աշխատի, ձեզ անհրաժեշտ է վավեր SSL վկայագիր:

Ստորև ներկայացված է «Անձնական հաշիվ» բաղադրիչը մոնիտորինգի համակարգում.

Վերոնշյալ բոլոր ստուգումները կաշխատեն հավելվածների մեծ մասի համար և կոդավորում չեն պահանջում: Սա շատ հիանալի է, քանի որ դուք կարող եք սկսել վերահսկել ցանկացած վեբ հավելված 5 րոպեում: Ստորև բերված են լրացուցիչ ստուգումներ, որոնք կարող են իրականացվել վեբ հավելվածի համար, սակայն դրանց իրականացումն ավելի բարդ է և հատուկ կիրառական, ուստի մենք դրանք չենք անդրադառնա այս հոդվածում:

Էլ ի՞նչ կարող եք ստուգել:

Ձեր վեբ հավելվածն ավելի ամբողջական վերահսկելու համար կարող եք կատարել հետևյալ ստուգումները.

• JavaScript-ի սխալների քանակը մեկ ժամանակահատվածում
• Ժամանակահատվածի համար վեբ հավելվածի կողմից սխալների քանակը (հետևում):
• Վեբ հավելվածի անհաջող պատասխանների քանակը (պատասխանի կոդը 404, 500 և այլն)
• Հարցման կատարման միջին ժամանակը

Windows ծառայության մոնիտորինգ (գործակալ)

ASMO համակարգում գործակալը խաղում է առաջադրանքների ժամանակացույցի դերը, որը կատարում է պլանավորված առաջադրանքները հետին պլանում։

Եթե ​​գործակալի բոլոր առաջադրանքները հաջողությամբ ավարտվեն, գործակալը ճիշտ է աշխատում: Ստացվում է, որ գործակալին վերահսկելու համար պետք է վերահսկել նրա առաջադրանքները: Հետևաբար, մենք «Գործակալ» բաղադրիչը բաժանում ենք առաջադրանքների: Յուրաքանչյուր առաջադրանքի համար մոնիտորինգի համակարգում կստեղծենք առանձին բաղադրիչ, որտեղ «Գործակալ» բաղադրիչը կլինի «ծնող»:

Մենք բաժանում ենք Agent բաղադրիչը մանկական բաղադրիչների (առաջադրանքներ).

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

ASMO համակարգում հարյուրից ավելի առաջադրանքներ կան, իսկապե՞ս անհրաժեշտ է յուրաքանչյուր առաջադրանքի համար յուրահատուկ ստուգումներ անել: Իհարկե, վերահսկողությունն ավելի լավ կլինի, եթե մենք յուրաքանչյուր գործակալի առաջադրանքի համար մշակենք և իրականացնենք մեր հատուկ ստուգումները, բայց շատ դեպքերում բավական է օգտագործել ունիվերսալ ստուգումներ:

ASMO համակարգը առաջադրանքների համար օգտագործում է միայն ունիվերսալ ստուգումներ, և դա բավարար է համակարգի աշխատանքը վերահսկելու համար:

Առաջընթացի ստուգում
Ամենապարզ և ամենաարդյունավետ ստուգումը կատարման ստուգումն է: Ստուգումը հաստատում է, որ առաջադրանքն ավարտված է առանց սխալների: Բոլոր առաջադրանքներն ունեն այս ստուգումը:

Ստուգման ալգորիթմ

Յուրաքանչյուր առաջադրանքի կատարումից հետո դուք պետք է ուղարկեք ՀԱՋՈՂՈՒԹՅԱՆ ստուգման արդյունքը մոնիտորինգի համակարգին, եթե առաջադրանքը կատարվեց հաջողությամբ, կամ ERROR, եթե կատարումն ավարտվեց սխալով:

Այս ստուգումը կարող է հայտնաբերել հետևյալ խնդիրները.

1. Առաջադրանքն աշխատում է, բայց ձախողվում է սխալով:
2. Առաջադրանքը դադարել է գործել, օրինակ՝ սառել է։

Եկեք նայենք, թե ինչպես են այս խնդիրները լուծվում ավելի մանրամասն:

Խնդիր 1 – Առաջադրանքն աշխատում է, բայց սխալմամբ ձախողվում է
Ստորև բերված է մի դեպք, երբ առաջադրանքը կատարվում է, բայց ձախողվում է 14:00-ից 16:00-ն ընկած ժամանակահատվածում:

Նկարը ցույց է տալիս, որ երբ առաջադրանքը ձախողվում է, ազդանշանն անմիջապես ուղարկվում է մոնիտորինգի համակարգ և մոնիտորինգի համակարգում համապատասխան ստուգման կարգավիճակը դառնում է ահազանգ:

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

Խնդիր 2 - Առաջադրանքը դադարեցվել է (սառեցված)
Ինչպե՞ս կհասկանա մոնիտորինգի համակարգը, որ առաջադրանքը խրված է:

Ստուգման արդյունքն ունի վավերականության ժամկետ, օրինակ՝ 1 ժամ։ Եթե ​​մեկ ժամ անցնի, և թեստի նոր արդյունք չլինի, մոնիտորինգի համակարգը թեստի կարգավիճակը կդնի տագնապի վրա:

Վերևի նկարում լույսերն անջատվել են ժամը 14:00-ին: Ժամը 15:00-ին մոնիտորինգի համակարգը կհայտնաբերի, որ թեստի արդյունքը (ժամը 14:00-ից) փտած է, քանի որ. Համապատասխան ժամանակը սպառվել է (մեկ ժամ), բայց նոր արդյունք չկա, և ստուգումը կփոխանցի տագնապի կարգավիճակի:

Ժամը 16:00-ին լույսերը նորից միացվեցին, ծրագիրը կկատարի առաջադրանքը և կատարման արդյունքը կուղարկի մոնիտորինգի համակարգ, թեստի կարգավիճակը կրկին հաջողված կդառնա։

Ինչ ստուգման համապատասխանության ժամանակ պետք է օգտագործեմ:

Համապատասխանության ժամանակը պետք է լինի ավելի մեծ, քան առաջադրանքի կատարման ժամկետը: Ես խորհուրդ եմ տալիս սահմանել համապատասխանության ժամանակը 2-3 անգամ ավելի երկար, քան առաջադրանքի կատարման ժամկետը: Սա անհրաժեշտ է կեղծ ծանուցումներ ստանալուց խուսափելու համար, երբ, օրինակ, առաջադրանքը սովորականից ավելի երկար է տևել կամ ինչ-որ մեկը վերբեռնել է ծրագիրը:

Առաջընթացի ստուգում

ASMO համակարգն ունի «Load Forecast» առաջադրանք, որը փորձում է ժամը մեկ անգամ ներբեռնել նոր կանխատեսում արտաքին աղբյուրից։ Արտաքին համակարգում նոր կանխատեսման հայտնվելու ճշգրիտ ժամանակը հայտնի չէ, սակայն հայտնի է, որ դա տեղի է ունենում օրական 2 անգամ։ Ստացվում է, որ եթե մի քանի ժամվա ընթացքում նոր կանխատեսում չկա, ապա դա նորմալ է, բայց եթե մեկ օրից ավելի նոր կանխատեսում չկա, ապա ինչ-որ տեղ ինչ-որ բան կոտրվել է։ Օրինակ, արտաքին կանխատեսման համակարգում տվյալների ձևաչափը կարող է փոխվել, ինչի պատճառով ASMO-ն չի տեսնի նոր կանխատեսումների թողարկում:

Ստուգման ալգորիթմ

Առաջադրանքը ՀԱՋՈՂՈՒԹՅԱՆ ստուգման արդյունքն ուղարկում է մոնիտորինգի համակարգ, երբ նրան հաջողվում է առաջընթաց գրանցել (ներբեռնել եղանակի նոր տեսություն): Եթե ​​առաջընթաց չկա կամ սխալ է տեղի ունենում, ապա մոնիտորինգի համակարգին ոչինչ չի ուղարկվում։

Չեկը պետք է ունենա համապատասխանության ընդմիջում, որպեսզի այդ ընթացքում երաշխավորվի նոր առաջընթաց ստանալը:

Խնդրում ենք նկատի ունենալ, որ խնդրի մասին կիմանանք ուշացումով, քանի որ մոնիտորինգի համակարգը սպասում է մինչև վերջին սկանավորման արդյունքի վավերականության ժամկետի ավարտը։ Հետևաբար, ստուգման վավերականության ժամկետը պետք չէ շատ երկարացնել։

Տվյալների բազայի մոնիտորինգ

ASMO համակարգում տվյալների բազան վերահսկելու համար մենք կատարում ենք հետևյալ ստուգումները.

1. Հաստատում է կրկնօրինակի ստեղծումը
2. Սկավառակի ազատ տարածքի ստուգում

Հաստատում է կրկնօրինակի ստեղծումը
Ծրագրերի մեծ մասում կարևոր է ունենալ տվյալների բազայի արդիական կրկնօրինակումներ, որպեսզի եթե սերվերը ձախողվի, կարողանաք ծրագիրը տեղակայել նոր սերվերի վրա:

ASMO-ն ստեղծում է կրկնօրինակը շաբաթը մեկ անգամ և ուղարկում պահեստ: Երբ այս ընթացակարգը հաջողությամբ ավարտվի, հաջողության ստուգման արդյունքն ուղարկվում է մոնիտորինգի համակարգ: Ստուգման արդյունքը ուժի մեջ է 9 օր: Նրանք. Կրկնօրինակների ստեղծումը վերահսկելու համար օգտագործվում է «առաջընթացի ստուգում» մեխանիզմը, որը մենք քննարկեցինք վերևում:

Սկավառակի ազատ տարածքի ստուգում
Եթե ​​սկավառակի վրա բավարար ազատ տարածք չկա, տվյալների բազան չի կարողանա ճիշտ աշխատել, ուստի կարևոր է վերահսկել ազատ տարածության քանակը:

Հարմար է օգտագործել չափումներ՝ թվային պարամետրերը ստուգելու համար։

Չափումներ թվային փոփոխական է, որի արժեքը փոխանցվում է մոնիտորինգի համակարգին։ Մոնիտորինգի համակարգը ստուգում է շեմային արժեքները և հաշվարկում մետրային կարգավիճակը:

Ստորև ներկայացված է մոնիտորինգի համակարգում «Տվյալների բազա» բաղադրիչի պատկերը.

Սերվերի մոնիտորինգ

Սերվերը վերահսկելու համար մենք օգտագործում ենք հետևյալ ստուգումները և չափումները.

1. Ազատ սկավառակի տարածություն
Եթե ​​սկավառակի տարածքը սպառվում է, ապա հավելվածը չի կարողանա աշխատել: Մենք օգտագործում ենք 2 շեմային արժեք՝ առաջին մակարդակը՝ ԶԳՈՒՇԱՑՈՒՄ, երկրորդը՝ ԱԶԳԱՆԳ:

2. RAM-ի միջին արժեքը ժամում տոկոսներով
Մենք օգտագործում ենք ժամային միջինը, քանի որ... մեզ չեն հետաքրքրում հազվագյուտ ցեղերը:

3. Պրոցեսորի միջին տոկոսը ժամում
Մենք օգտագործում ենք ժամային միջինը, քանի որ... մեզ չեն հետաքրքրում հազվագյուտ ցեղերը:

4. Պինգ ստուգում
Ստուգում է, որ սերվերը առցանց է: Մոնիտորինգի համակարգը կարող է կատարել այս ստուգումը, կոդ գրելու կարիք չկա:

Ստորև բերված է պատկեր, թե ինչպիսի տեսք ունի «Սերվեր» բաղադրիչը մոնիտորինգի համակարգում.

Սարքավորումների մոնիտորինգ

Ես ձեզ կասեմ, թե ինչպես են ստացվում տվյալները: Ճանապարհային հսկողության յուրաքանչյուր կետի համար (MPC) առաջադրանքների պլանավորողում կա առաջադրանք, օրինակ՝ «Հետազոտել MPC M2 km 200»: Առաջադրանքը տվյալներ է ստանում MPC-ի բոլոր սարքերից յուրաքանչյուր 30 րոպեն մեկ:

Կապի ալիքի խնդիր
Սարքավորումների մեծ մասը գտնվում է քաղաքից դուրս, տվյալների փոխանցման համար օգտագործվում է GSM ցանց, որը կայուն չի աշխատում (ցանց կա, կամ չկա):

Ցանցի հաճախակի խափանումների պատճառով, սկզբում, մոնիտորինգում MPC-ի հարցումը ստուգելը այսպիսի տեսք ուներ.

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

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

Ստորև բերված է նկար, թե ինչպիսի տեսք ունի սարքավորումները մոնիտորինգի համակարգում.

Կարեւոր!
Երբ GSM ցանցը դադարում է աշխատել, բոլոր MDC սարքերը չեն հետազոտվում: Մոնիտորինգի համակարգից էլ-նամակների քանակը նվազեցնելու համար մեր ինժեներները բաժանորդագրվում են «MPC» տեսակի, այլ ոչ «Սարք» տեսակի բաղադրիչների խնդիրների մասին ծանուցումներին: Սա թույլ է տալիս Ձեզ ստանալ մեկ ծանուցում յուրաքանչյուր MPC-ի համար, այլ ոչ թե յուրաքանչյուր սարքի համար առանձին ծանուցում ստանալ:

ASMO-ի մոնիտորինգի վերջնական սխեման

Եկեք ամեն ինչ հավաքենք ու տեսնենք, թե ինչպիսի մոնիտորինգի սխեմա ունենք։

Ամփոփում

Եկեք ամփոփենք.
Ի՞նչ տվեց մեզ ASMO-ի գործունեության մոնիտորինգը:

1. Արատների վերացման ժամանակը նվազել է
Մենք նախկինում լսել ենք օգտատերերից թերությունների մասին, բայց ոչ բոլոր օգտատերերն են հայտնում թերությունների մասին: Պատահեց, որ մենք տեղեկացանք համակարգի բաղադրիչի անսարքության մասին դրա հայտնվելուց մեկ շաբաթ անց: Այժմ մոնիտորինգի համակարգը մեզ ծանուցում է խնդիրների մասին՝ խնդիր հայտնաբերելուն պես:

2. Համակարգի կայունությունը մեծացել է
Քանի որ թերությունները սկսեցին ավելի վաղ վերացվել, համակարգը որպես ամբողջություն սկսեց շատ ավելի կայուն աշխատել:

3. Տեխնիկական աջակցության կանչերի քանակի կրճատում
Շատ խնդիրներ այժմ շտկված են, նախքան օգտատերերը նույնիսկ իմանան դրանց մասին: Օգտատերերը սկսեցին ավելի հազվադեպ կապվել տեխնիկական աջակցության հետ: Այս ամենը լավ է ազդում մեր հեղինակության վրա։

4. Հաճախորդների և օգտագործողների հավատարմության բարձրացում
Հաճախորդը դրական փոփոխություններ է նկատել համակարգի կայունության մեջ։ Օգտագործողները համակարգից օգտվելիս ավելի քիչ խնդիրներ են ունենում:

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

Կարեւոր!
Դուք չեք կարող մոնիտորինգի համակարգը տեղադրել նույն սերվերի վրա, որտեղ աշխատում են ձեր հավելվածները: Եթե ​​սերվերն անջատվի, հավելվածները կդադարեն աշխատել, և ոչ ոք չի լինի, ով ծանուցի այդ մասին:

Մոնիտորինգի համակարգը պետք է աշխատի առանձին սերվերի վրա մեկ այլ տվյալների կենտրոնում:

Եթե ​​դուք չեք ցանկանում օգտագործել հատուկ սերվեր նոր տվյալների կենտրոնում, կարող եք օգտագործել ամպային մոնիտորինգի համակարգը: Մեր ընկերությունն օգտագործում է Zidium ամպային մոնիտորինգի համակարգը, բայց դուք կարող եք օգտագործել ցանկացած այլ մոնիտորինգի համակարգ: Ամպային մոնիտորինգի համակարգի արժեքը ավելի ցածր է, քան նոր սերվեր վարձելը:

Առաջարկություններ:

1. Բաղադրիչների ծառի տեսքով հավելվածները և համակարգերը հնարավորինս մանրամասնորեն բաժանեք, այնպես որ հարմար կլինի հասկանալ, թե որտեղ և ինչն է կոտրված, և վերահսկումն ավելի ամբողջական կլինի:
2. Բաղադրիչի ֆունկցիոնալությունը ստուգելու համար օգտագործեք թեստեր: Ավելի լավ է օգտագործել շատ պարզ ստուգումներ, քան մեկ բարդ:
3. Կազմաձևեք մետրային շեմերը մոնիտորինգի համակարգի կողմում, այլ ոչ թե դրանք կոդով գրելու: Սա ձեզ կփրկի հավելվածը վերակազմավորելու, վերակազմավորելու կամ վերագործարկելու անհրաժեշտությունից:
4. Հատուկ ստուգումների համար օգտագործեք համապատասխանության ժամանակի սահման՝ կեղծ ծանուցումներ ստանալուց խուսափելու համար, քանի որ որոշ ստուգումների ավարտը սովորականից մի փոքր ավելի երկար տևեց:
5. Փորձեք այնպես անել, որ մոնիտորինգի համակարգում բաղադրիչները կարմրեն միայն այն դեպքում, երբ հաստատ խնդիր կա: Եթե ​​իզուր կարմրեն, ուրեմն կդադարեք ուշադրություն դարձնել մոնիտորինգի համակարգի ծանուցումներին, դրա իմաստը կկորչի։

Եթե ​​դեռ չեք օգտագործում մոնիտորինգի համակարգ, սկսեք: Դա այնքան էլ դժվար չէ, որքան թվում է: Հանգստացեք՝ նայելով կանաչ բաղադրիչների ծառին, որը դուք ինքներդ եք աճեցրել:

Good luck.

Source: www.habr.com