Ձիիիին! Առավոտյան ժամը 3-ն է, դուք հիանալի երազ եք տեսնում, և հանկարծ զանգ է գալիս. Այս շաբաթ դուք հերթապահում եք, և, ըստ երևույթին, ինչ-որ բան է պատահել: Ավտոմատացված համակարգը զանգում է՝ պարզելու, թե ինչն է սխալ: Սա ժամանակակից համակարգչային համակարգերի կառավարման կարևոր ասպեկտ է, բայց եկեք տեսնենք, թե ինչպես կարելի է ավելի լավ դարձնել ծանուցումները մարդկանց համար:
Ծանոթացեք մոնիտորինգի փիլիսոփայությանը, որը ծնվել է տարբեր մոնիտորինգային թիմերում իմ պարտականությունների մի քանի տասնամյակների ընթացքում: Նրա վրա մեծապես ազդել է Ռոբ Եվաշչուկի իրական Աստվածաշունչը (Իմ ծանուցման փիլիսոփայությունը) ներառված է գրքում , և Ջոն Ալսպոյի գիրքը (Ծանոթագրություններ ազդանշանների տեղադրման վերաբերյալ):
, и — շնորհակալություն գրառումը խմբագրելու հարցում ձեր օգնության համար:
Ի՞նչ է CASE-ը:
Ես որոշեցի նման գեղեցիկ հապավումով հանդես գալ կամ . Ես դա անվանում եմ CASE մեթոդ. Նա նկարագրում է չորս կետ, որոնց պետք է ուշադրություն դարձնել ավտոմատ մոնիտորինգով աշխատելիս.
- (համատեքստը կապված)
- (գործնական արժեք)
- (շեշտադրումը ախտանիշների վրա)
- (դասարան)
Եթե դուք օգտագործում եք CASE, դուք առողջ անտարբերությամբ եք վերաբերվում ծանուցումներին և չեք արթնացնում մարդկանց գիշերը: Մոնիտորինգը պետք է պարբերաբար գնահատվի օգտակարության և արդյունավետության համար: Երբ մարդը ծանուցում ստանա, նա կունենա ավելի լավ մտավոր մոդելներ և ավելի վստահություն:
Որպեսզի ավելի հեշտ լինի հիշելը, պատկերացրեք, որ ձեզ անհրաժեշտ է ԴԵՊՔ [այսինքն՝ գործ, պատճառ. թարգմանչի գրառումը] յուրաքանչյուր ահազանգ արդարացնելու համար: :արևային ակնոցներ:
Իսկ ինչո՞ւ է այս ամենը։
. Շատ պատճառներով. Իսկ CASE-ը բոլորին չի վերացնի: Բայց դրա հետ մեկտեղ դուք գիշերը արթնանում եք ավելի լավ ծանուցումներ ստանալու համար: Այս մեթոդը ներառում է տարբեր կազմակերպչական գործընթացներ, որոնք նույնպես կօգնեն այս հարցում:
RED և USE մեթոդների գեղեցկությունն այն է, որ դրանց օգնությամբ մենք ոչ միայն գիտենք ինչպես աշխատել, այլև խոսում ենք նույն լեզվով միմյանց հետ: Ես հույս ունեմ, որ CASE մեթոդը կհեշտացնի ծանուցումների քննարկումը, որոնք պաշտպանում են մեր համակարգերը, բայց զբաղված են պահում մեր գործընկերներին:
Բանն այն է, որ դուք պետք է ձեր կազմակերպությունում մշակույթ ստեղծեք, որտեղ ծանուցումներին վերաբերվում են առողջ անտարբերությամբ: Ծանուցումները կարող են ստեղծվել կոնկրետ նպատակով, բայց փաստ չէ, որ դրանք հետագայում չեն կորցնի արժեքը։ Ինչու՞ մենք կարգավորեցինք այս ծանուցումը: Որքա՞ն ժամանակ առաջ են վերանայվել դրա չափանիշները։ CASE-ով այս հարցերին կարելի է պատասխանել:
Context-Heavy - համատեքստի պարտադիր կապ
Առավոտյան ժամը 3-ը լավագույն ժամանակը չէ շատ խելացի բառեր պարունակող հաղորդագրություններ կարդալու համար: Արդյունավետ արձագանքելու համար անհրաժեշտ է տեղեկատվություն: Իդեալում, սա պետք է լինի տեղեկատվություն կոնկրետ խնդրի մասին, որի համատեքստն անմիջապես պարզ է, և ծանուցումները պետք է կազմաձևվեն այնպես, որ դա հնարավոր լինի: Սա «դիտարկում» և «կողմնորոշում» է . Ամոթ չէ ժամանակ ծախսել այս կարգի վրա, քանի որ մարդու անընդհատ ուշադրությունը շեղելը նույնիսկ ավելի թանկ է: Եկեք հարգենք միմյանց.
Խնդիրները բազմաթիվ աղբյուրներ ունեն։ Հատկապես ուրվականներ:
Ինչպե՞ս կարող եմ օգնել հերթապահին: Առաջինը, ինչ տեսնում է հերթապահը, ծանուցումն է, ուստի բոլոր վարկածները կառուցում է դրա հիման վրա։ Հետո նա նայում է հրահանգներին և վահանակներին, բայց արդյոք միշտ կա՞ տվյալներ կոնկրետ ծանուցման վերաբերյալ, և ոչ միայն ընդհանուր տեղեկություններ: Ալսպոուն խորհուրդ է տալիս «մտածել այն մասին, թե ինչպես կարող եք մեկնաբանել կամ պատասխանել ծանուցմանը» (սլայդ 29). Լավ ծանուցումը կենտրոնացած է հերթապահ անձի վրա, այլ ոչ թե կարգավորվում է միայն շեմով:
Այսպիսով, ահա որոշ գաղափարներ, թե ինչպես բարելավել ծանուցման համատեքստը.
- Ցույց տվեք օգտվողին ինչ-որ օգտակար և հատուկ ստեղծված բան, և ոչ թե սովորական հրահանգներ կամ վահանակ: Նախկինում ես և տղաները օգտագործում էինք հատուկ ծանուցումների համար կազմաձևված հետաքննական վահանակներ: Սա կօգնի, եթե խնդիրը հայտնի լինի, բայց միայն շփոթեցնի մյուսներին: Այստեղ պետք է հավասարակշռություն գտնել:
- Կպատմե՞ք ծանուցման պատմության մասին՝ նորությո՞ւն է։ Հաճա՞խ է աշխատում: Արդյո՞ք դա սեզոնային է:
- Ցույց տալ համակարգի վիճակի վերջին փոփոխությունները: Վերջերս ինչ-որ բան փոխվե՞լ է: (Օրինակ՝ տեղակայում կամ միացնել/անջատել ֆունկցիոնալությունը):
- Ցույց տալ հարաբերությունները և տրամադրել տեղեկատվություն մտավոր մոդելի համար. համակարգի կախվածությունները պետք է հստակ տեսանելի լինեն, գերադասելի է ֆունկցիոնալության նշումով:
- Օգտատիրոջը արագ կապեք թիմի հետ. նրանք կարո՞ղ են տեսնել շարունակվող միջադեպերը, թե՞ կարող են պարզել, թե ընկերությունում ևս ով է ծանուցում ստացել: Ծրագիր ակտիվացված?
Իդեալում, միջադեպերի կառավարման ծրագիրը խորհուրդ կտա, թե ինչպես բարելավել միջադեպերի հետաքննության ծանուցման համատեքստը: Միշտ աշխատելու բան կա:
Գործող - գործնական արժեք
Ծանուցմանն ի պատասխան հերթապահը պետք է ինչ-որ բան անի. Եթե ձեզ ոչինչ պետք չէ անել, կամ անհասկանալի է, թե ինչ անել, ինչու եք արթնացրել նրան: Դուք պետք է խուսափեք ծանուցումներից, որոնք զայրացնում են հերթապահներին և գործողություն չեն պահանջում:
Ինչ պետք է անեմ? Ինչ ես դու ուզում?
Նախկինում, երբ համակարգերը պարզ էին, իսկ թիմերը՝ փոքր, մենք մշտադիտարկում էինք դնում՝ պարզապես ամեն ինչի վրա մնալու համար: Ծանուցումը, որ կույտի վրա ծանրաբեռնվածությունը մեծացել է, մեզ համատեքստ կտա, եթե ծառայությունը հետագայում անսարքություն գործի: Մեծ մասշտաբով նման ծանուցումները միայն շփոթություն կստեղծեն, քանի որ մեր համակարգերը միշտ գործում են տարբեր խստության դեգրադացիայի վիճակում: Սա արագ հանգեցնում է և, իհարկե, զգայունության կորստի համար: Հետևաբար, հերթապահն անտեսում կամ նույնիսկ զտում է նման ծանուցումները և միշտ չէ, որ անհրաժեշտության դեպքում արձագանքում դրանց: Մի ընկեք այս ծուղակը: Մի կարգաբերեք բոլոր ծանուցումները անընդմեջ և այնուհետև դրանք էլփոստով ուղարկեք ինչ-որ աստվածատուր թղթապանակ:
Ահա թե ինչ տեսք ունի գործնական արժեք ունեցող ծանուցումը.
- Ծանուցումը պահանջում է գործողություն, այլ ոչ թե պարզապես նորությունների հաղորդում:
- Այս գործողությունը դժվար է կամ ռիսկային է ավտոմատացնել: Եթե գործողությունը կարող է ավտոմատացվել, ապա ավտոմատացրե՛ք այն, դադարե՛ք նեղացնել մարդկանց:
- Ծանուցումը պարունակում է հրատապ առաջարկություններ ձևով (SLA) կամ (RTO): Այնուհետեւ հերթապահը կարող է ակտիվացնել կազմակերպության միջադեպերի կառավարման ծրագիրը:
Ես ուզում եմ պարզաբանել. ես չեմ ասում, որ ծանուցումները պետք է գան միայն ամենակարևոր SLO-ների (ծառայության մակարդակի նպատակների) համար API-ի համար: SLO մոնիտորինգը մշտապես մասնատված և բաժանված է և պահանջում է նույն մոտեցումը բոլոր ծառայությունների նկատմամբ: Պարզ է, որ դուք կհետևեք ձեզ վճարող հաճախորդների համար ամենակարևոր SLO-ներին: Սակայն ենթակառուցվածքային SLO-ները, ինչպիսիք են տվյալների բազաները, նույնպես պետք է մոնիտորինգի ենթարկվեն: Շուտով դուք ստիպված կլինեք գործ ունենալ ներքին հաճախորդների հետ և աջակցել նրանց: Եվ այսպես շարունակ անվերջ:
Ախտանիշների վրա հիմնված - ախտանշանների վրա շեշտադրում
Ուզես, թե չուզես, դու աշխատում ես բաշխված համակարգում (Կավաջ). Արդյունքում, դուք օգտագործում եք տարբեր մարտավարություններ ծառայությունները մեկուսացնելու և դրանք ձախողումից պաշտպանելու համար (Trainor et al.)3: Եվ չնայած աղբահանության հետաձգումը կամ տվյալների բազայի կասեցված հարցումը վկայում են խնդիրների մասին, կարիք չկա շտապել դրանք շտկելու համար, եթե օգտատերերը մոտ ապագայում խնդիրներ չունենան:
Սրանք կարևոր ազդանշաններ են և կարող են գործնական նշանակություն ունենալ, բայց եթե դրանք չեն անհանգստացնում օգտատերերին, ապա դա բավականաչափ հրատապ չէ սպասավորի ուշադրությունը շեղելու համար: Պատճառների վրա հիմնված ծանուցումները համակարգի ձախողման մասին մեր մտավոր մոդելների լուսանկարն են: Ավելի լավ է հետևել կարևոր ախտանիշներին, քան փորձել թվարկել ձախողման բոլոր հնարավոր պատճառները:
Ծանուցումները իմաստալից դարձնելու համար կենտրոնացեք , կարևոր օգտվողների համար: Եվաշչուկը սա անվանում է «մշտադիտարկում օգտատերերի համար»: Հիշեք, որ այս փիլիսոփայությունը պետք է կիրառվի ամբողջ կազմակերպությունում: Եթե ծառայությունը ենթակառուցվածքի խորքում ինչ-որ տեղ հրատապ խնդիրներ ունենա, համապատասխան թիմը կզբաղվի դրանցով: Նման խափանումներից համակարգերի պաշտպանությունը բոլորովին առանձին խնդիր է (Trainer et al., բաժին՝ կրիտիկական կախվածությունները նվազագույնի հասցնելու ռազմավարությունների մասին).
Ախտանիշները այնքան էլ փոփոխական չեն
Ռիչարդ Կուկը հիշեցնում է մեզ, որ բարդ համակարգերը լի են թերություններով, թերություններով և խնդիրներով. Բոլոր հնարավոր պատճառները թվարկելը սիզիփյան խնդիր է: Դուք փորձում եք նկարագրել խնդիրները, բայց դրանք անընդհատ փոխվում են։ Սինդի Սրիդարանը կարծում է, որ «համակարգերը չպետք է կատարյալ վիճակում լինեն ամեն վայրկյան», և ավելի լավ է օգտագործել ավելի մարդկային մոտեցում ( («Բաշխված համակարգերի մոնիտորինգ»), 7).
Խուսափեք միջադեպից հետո ծանուցումներից
Սովորաբար, պատճառների մասին ծանուցումները կազմաձևվում են միջադեպերը շտկելու համար: Եվ կատարվածի մասին այս սահմանափակ ծանուցումները ստեղծում են անվտանգության կեղծ զգացում, քանի որ համակարգը ամեն անգամ կոտրելու նոր ուղիներ է առաջարկում։
Մի խաբվեք պատճառների մասին ծանուցումներով: Ավելի լավ է մտածել.
- Ինչու՞ ախտանիշների վրա հիմնված ծանուցումը չի նկատել խնդիրը:
- Օգտակար կլինի՞ բարելավել կոնտեքստը օգտագործողի համար:
- Ինչպե՞ս կարող են մոնիտորինգի գործիքները կատարելագործվել՝ ավելի արագ ախտորոշում կատարելու համար, այլ ոչ թե կատարվածի մասին ծանուցումներ կուտակելու համար:
Ախտորոշման մոնիտորինգի գործիքները կօգնեն միայն այն դեպքում, եթե դրանք դիտարկեք որպես ախտանիշից լուծում անցնելու միջոց: Առանց այս արձագանքի, դուք պարզապես կհարձակվեք անցյալի անհաջողությունների մասին ուշ ծանուցումներով և գծապատկերներով, և ոչ մի խոսք ապագա անհաջողությունների մասին: Սա կազմակերպության համար պաշտպանությունից հարձակման անցնելու հիանալի հնարավորություն է: Իսկ մշակողները և արտադրանքի մենեջերները կունենան նույն ակնկալիքներն ու հստակ նպատակները: Գործը - CASE (:wink:) - պարզ է յուրաքանչյուր ծանուցման համար։
Պատճառների վրա հիմնված ծանուցումները չափավոր են տանելի
Երբեմն մեր համակարգը մեզ քիչ ընտրություն է թողնում պատճառների վրա հիմնված ծանուցումների առումով: Եվ երբեմն հերթապահները հիանալի հասկանում են, որ ախտանիշը անպայման կբերի ձախողման, հետևաբար գործնական արժեք է պարունակում։ Միգուցե դուք պարզապես վստահ չեք, թե ինչ է կատարվում և կարգավորում եք ծանուցումները՝ ապահով կողմում լինելու համար: Հուսով ենք, որ այս գործողությունը ժամանակավոր է, քանի դեռ մենք չենք կարող փոխել համակարգը՝ արդյունավետության խնդիրը լուծելու համար:
Այս իրավիճակների հետ գործ ունենալիս հիշեք CASE-ի մյուս բաղադրիչները: Միայն այն պատճառով, որ դա ժամանակավոր է, չի նշանակում, որ դուք կարող եք դադարել մտածել ձեր գլխով:
Գնահատված – գնահատում
Համակարգի ցանկացած փոփոխություն (նոր կոդ, նոր ենթակառուցվածք, ցանկացած նոր բան) ընդլայնում է խափանումների շրջանակը (Cook, 3): Այս ծանուցումը դեռևս աշխատում է այնպես, ինչպես սպասվում էր: Համակարգերի հստակ և ընթացիկ մտավոր մոդելներ և որոշ աջակցության ծանուցումներին արձագանքելու փորձ - սրանք են հիմնական հատկանիշները . Համակարգերի արատները մշտապես զարգանում են, և մենք պետք է հետևենք դրանց:
Դուք պետք է անընդհատ գնահատեք յուրաքանչյուր ծանուցման որակը՝ համոզվելու համար, որ դրանք աշխատում են այնպես, ինչպես սպասվում էր: Հարգելի առաջնորդներ. Ձեր թիմերի համար շատ ավելի հեշտ կլինի, եթե օգնեք նրանց հաստատել այս գործընթացը: Ահա որոշ գնահատման գաղափարներ.
- Օգտագործեք , կամ ծանուցման փորձարկման այլ մեթոդներ: Թիմը կարող է դա անել ինքնուրույն՝ առանց հենվելու ծանր միջադեպերի կառավարման համակարգի վրա:
- Ներառեք միջադեպերի հետ կապված բոլոր ծանուցումների հավաքածուն ձեր միջադեպերի կառավարման ծրագրում: Նշեք օգտակար, վնասակար, անպատշաճ, անհասկանալի և այլն: Օգտագործեք դրանք որպես հետադարձ կապ:
- Ճիշտ ծանուցումները հազվադեպ են գործարկվում և մանրակրկիտ փորձարկվում են: Համոզվեք, որ բոլոր հղումներն աշխատում են, մատնանշում են ճիշտ համատեքստը և այլն:
- Եթե ծանուցումը երբեք չի միանում կամ շատ հաճախ է հնչում, ինչ-որ բան այն չէ: Ուղղեք կամ հեռացրեք այն: Զգուշացեք ավելորդ պասիվությունից կամ ակտիվությունից:
- Սահմանեք ծանուցման ժամանակի դրոշմակնիքներ՝ պիտանելիության ժամկետներով: Եթե պիտանելիության ժամկետը լրացել է, գնահատեք ծանուցումը CASE մեթոդով և թարմացրեք ժամանակի դրոշմը: Ինչպես սնունդը, այնպես էլ կանոնավոր կերպով ստուգեք պիտանելիության ժամկետը։
- Պարզեցրեք ծանուցումների բարելավման գործընթացը: Օգտագործեք մոնիտորինգը որպես կոդ և պահեք ծանուցումները Git պահոցում: Ձգվող հարցումները օգնում են ներգրավել թիմին և տրամադրել անցյալի ծանուցումների պատմություն: Եվ դուք այլևս չեք վախենա փոխել ծանուցումները կամ թույլտվություն խնդրել դրանց համար պատասխանատուներից։
- Կարգավորեք հետադարձ կապ ծանուցումների համար, նույնիսկ եթե դա պարզ է , որպեսզի հերթապահները ծանուցումները նշեն որպես անօգուտ կամ ներխուժող։ Տեղադրեք հղումը կամ գործողության կոչը հենց ծանուցման մեջ և պարբերաբար վերանայեք ձեր կարծիքը:
- Թիմում կանոն սահմանեք՝ թող հերթապահողները աշխատեն պարզեցնել հերթապահությունը, երբ քիչ աշխատանք կա։ Թող քեզնից հետո ամեն ինչ մի փոքր ավելի լավ լինի, քան նախկինում էր:
Ամփոփում
Կարծում եմ, CASE մեթոդն օգնում է մշակողներին և կազմակերպություններին քննարկել ավտոմատ ծանուցումներ ստեղծելու և ուղարկելու հարցը: Մեկ մշակողը կարող է սկսել ծանուցումները գնահատել՝ օգտագործելով CASE մեթոդը, այնուհետև ամբողջ կազմակերպությունը կմիանա այլ մշակողների, կառավարման և միջադեպերի կառավարման ծրագրերին՝ ծանուցումները լավ վիճակում պահելու համար: Սա չի պահանջում որևէ հատուկ գործիք կամ բարդ գործընթաց:
Ողջ արդյունաբերությունը պետք է մտածի մարդկային գործոնի մասին աշխատանքային պարտականությունների կատարման ժամանակ՝ չզոհաբերելով հաճախորդների բարձրակարգ սպասարկումը: Այս բոլոր գործիքներն ու գործելակերպերը կարող են և պետք է բարելավվեն: Հուսով եմ, որ CASE մեթոդը կօգնի այս հարցում:
Վայելեք բարելավված ծանուցումները:
Source: www.habr.com