Ինչպես ես մեկ շաբաթ անցկացրեցի որպես SRE ինժեներ ստաժոր: Պարտականություն ծրագրային ապահովման ինժեների աչքերով

SRE ինժեներ - պրակտիկանտ

Նախ, թույլ տվեք ներկայանալ. Ես - @tristan.read, ճակատային ինժեներ խմբում Մոնիտոր::Առողջություն GitLab. Անցյալ շաբաթ ես պատիվ ունեցա պրակտիկա անցնելու մեր SRE ինժեներներից մեկի մոտ: Նպատակն էր դիտարկել, թե ինչպես է հերթապահը արձագանքում միջադեպերին ամեն օր և ձեռք բերել իրական կյանքի փորձ: Մենք կցանկանայինք, որ մեր ինժեներները ավելի լավ հասկանան օգտագործողների կարիքները գործառույթները Մոնիտոր::Առողջություն.

Ես ստիպված էի մեկ շաբաթ շարունակ ամենուր հետևել SRE ինժեներին: Այսինքն՝ ես ներկա եմ եղել հանձնմանը, վերահսկել եմ նույն ահազանգման ուղիները և արձագանքել միջադեպերին, եթե դրանք եղել են և երբ եղել են:

Միջադեպեր

Մեկ շաբաթվա ընթացքում 2 միջադեպ է եղել.

1. Cryptominer

Չորեքշաբթի օրը GitLab.com-ի օգտագործման մեջ թռիչք է գրանցվել GitLab Runner«ա, որը առաջացել է վազորդի րոպեները կրիպտոարժույթի արդյունահանման համար օգտագործելու փորձերից: Միջադեպը լուծվել է խախտումների չեզոքացման մեր սեփական գործիքի միջոցով, որը դադարեցնում է վազորդի առաջադրանքները և ջնջում դրա հետ կապված նախագիծն ու հաշիվը:

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

2. Կանարյան և հիմնական հավելվածների արդյունավետության վատթարացում

Միջադեպը տեղի է ունեցել դանդաղման և Gitlab.com-ում կանարյան և հիմնական վեբ հավելվածների սխալների հաճախականության պատճառով: Apdex-ի մի քանի արժեքներ են խախտվել։

Բաց միջադեպի առաջադրանք. https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Հիմնական գտածոներ

Ահա մի քանի բան, որ ես սովորեցի իմ հերթապահության շաբաթվա ընթացքում:

1. Ահազանգերն առավել օգտակար են նորմայից շեղումներ հայտնաբերելիս:

Զգուշացումները կարելի է բաժանել մի քանի տեսակի.

• Ծանուցումներ՝ հիմնված որոշակի շեմային արժեքի վրա, օրինակ՝ «10 5xx սխալ է տեղի ունեցել վայրկյանում»:
• Զգուշացումներ, որոնցում շեմը տոկոսային արժեք է, օրինակ՝ «5xx սխալների հաճախականությունը տվյալ պահին հարցումների ընդհանուր ծավալի 10%-ի դիմաց»:
• Ծանուցումներ՝ հիմնված պատմական միջինի վրա, օրինակ՝ «5xx սխալներ 90-րդ տոկոսում»:

Ընդհանրապես, 2-րդ և 3-րդ տիպերն ավելի օգտակար են հերթապահություն իրականացնող SRE-ների համար, քանի որ դրանք գործընթացում բացահայտում են նորմայից շեղումներ:

2. Շատ ահազանգեր երբեք չեն վերածվում միջադեպերի:

SR ինժեներները գործ ունեն ահազանգերի մշտական ​​հոսքի հետ, որոնցից շատերը իրականում կրիտիկական չեն:

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

Հերթական SRE-ի խնդիրն է որոշել, թե որ ահազանգերն իրականում ցույց են տալիս ինչ-որ լուրջ բան, և արդյոք դրանք պետք է ընդլայնվեն և լուծվեն: Կասկածում եմ, որ դա պայմանավորված է նաև ահազանգերի անճկունությամբ. լավ կլիներ, որ լինեին մի քանի մակարդակ կամ «խելացի» եղանակներ՝ կարգավորելու ազդանշանները վերը նկարագրված իրավիճակին համապատասխան:

Հատկանիշի առաջարկ. https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Մեր հերթապահ SRE-ները շատ գործիքներ են օգտագործում:

Ներքին:

• GitLab ինֆրա նախագիծ. runbooks ապրում են այստեղ, հերթափոխ/շաբաթյա առաջադրանքներ, միջադեպերի արձագանքման առաջադրանքներ:
• GitLab-ի խնդիրներ. հետաքննությունները, վերանայումները և սպասարկումը նույնպես հետագծվում են խնդիրների դեպքում:
• GitLab պիտակներ. Ավտոմատացման առաջադրանքները գործարկվում են հատուկ պիտակների միջոցով, որոնք բոտերն օգտագործում են առաջադրանքների գործունեությունը հետևելու համար:

Արտաքին:

• PagerDuty. ահազանգեր
• Slack. PagerDuty/AlertManager հաղորդագրությունների հոսքը գնում է այստեղ: Ինտեգրում կտրատող հրամանների հետ՝ մի շարք առաջադրանքներ կատարելու համար, ինչպիսիք են ազդանշանի փակումը կամ միջադեպի սրումը:
• Գրաֆանա. չափումների վիզուալիզացիա՝ կենտրոնանալով երկարաժամկետ միտումների վրա:
• Kibana. Տալիս է վիզուալիզացիա/մատյանների որոնում, կոնկրետ իրադարձությունների մեջ ավելի խորը փորփրելու ունակություն:
• Zoom. Zoom-ում կա անընդհատ գործող «բրեկուտ սենյակ»: Սա թույլ է տալիս SRE-ի ինժեներներին արագ քննարկել իրադարձությունները՝ չվատնելով արժեքավոր ժամանակ՝ ստեղծելով սենյակ և կապելով մասնակիցներին:

Եվ շատ շատ ուրիշներ:

4. GitLab.com-ի մոնիտորինգը GitLab-ի միջոցով ձախողման մեկ կետ է

Եթե ​​GitLab.com-ը սպասարկման լուրջ ընդհատում ունենա, մենք չենք ցանկանում, որ դա ազդի խնդիրը լուծելու մեր ունակության վրա: Այն կարող է դադարեցվել՝ գործարկելով GitLab-ի երկրորդ օրինակը՝ GitLab.com-ը կառավարելու համար: Փաստորեն, սա արդեն աշխատում է մեզ համար. https://ops.gitlab.net/.

5. GitLab-ին ավելացնելու մի քանի առանձնահատկություններ

• Բազմակի օգտատերերի առաջադրանքների խմբագրում, Google Docs-ի նման: Սա կօգնի իրադարձության ընթացքում տեղի ունեցած միջադեպերի, ինչպես նաև ամփոփման առաջադրանքների հարցում: Երկու դեպքում էլ մի քանի մասնակիցների կարող է անհրաժեշտ լինել իրական ժամանակում ինչ-որ բան ավելացնել:
• Ավելի շատ վեբ-կեռիկներ առաջադրանքների համար: GitLab-ի աշխատանքային հոսքի տարբեր քայլեր ներսից գործարկելու ունակությունը կօգնի նվազեցնել ձեր կախվածությունը Slack ինտեգրումներից: Օրինակ՝ PagerDuty-ում զգուշացում թույլ տալու հնարավորությունը GitLab-ի հարցում կտրատող հրամանի միջոցով:
  Ամփոփում

SRE ինժեներները դժվարանում են բազմաթիվ բարդությունների հետ: Հիանալի կլիներ տեսնել GitLab-ի ավելի շատ արտադրանքներ, որոնք վերաբերում են այս խնդիրներին: Մենք արդեն աշխատում ենք արտադրանքի որոշ հավելումների վրա, որոնք կհեշտացնեն վերը նշված աշխատանքային հոսքերը: Մանրամասները հասանելի են Ops Product Vision բաժինը.

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

Source: www.habr.com