«SRE - հիպ, թե՞ ապագա» վեբինարի արտագրում:

Վեբինարը վատ ձայն ունի, ուստի մենք այն արտագրել ենք:

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

Նախ, եկեք խոսենք այն մասին, թե ինչ է SRE - Site Reliability Engineering: Եվ ինչպես է այն հայտնվել որպես առանձին դիրք, որպես առանձին ուղղություն։ Ամեն ինչ սկսվեց նրանից, որ զարգացման ավանդական շրջանակներում Dev-ը և Ops-ը երկու բոլորովին տարբեր թիմեր են, սովորաբար երկու բոլորովին տարբեր նպատակներով: Զարգացման թիմի նպատակն է ներդնել նոր հնարավորություններ և բավարարել բիզնեսի կարիքները: Ops թիմի նպատակն է համոզվել, որ ամեն ինչ աշխատում է, և ոչինչ չի կոտրվում: Ակնհայտ է, որ այս նպատակներն ուղղակիորեն հակասում են միմյանց. որպեսզի ամեն ինչ աշխատի և ոչինչ չխախտի, հնարավորինս քիչ նոր հնարավորություններ տարածեք: Դրա պատճառով կան բազմաթիվ ներքին հակամարտություններ, որոնք փորձում է լուծել մեթոդաբանությունը, որն այժմ կոչվում է DevOps:

Խնդիրն այն է, որ մենք չունենք DevOps-ի հստակ սահմանում և DevOps-ի հստակ իրականացում։ Ես խոսեցի Եկատերինբուրգում 2 տարի առաջ տեղի ունեցած կոնֆերանսի ժամանակ, և մինչ այժմ DevOps բաժինը սկսվում էր «Ի՞նչ է DevOps» զեկույցով: 2017 թվականին Devops-ը գրեթե 10 տարեկան է, բայց մենք դեռ վիճում ենք, թե դա ինչ է։ Եվ սա շատ տարօրինակ իրավիճակ է, որը Google-ը փորձել է լուծել մի քանի տարի առաջ։

2016-ին Google-ը թողարկեց գիրք, որը կոչվում էր Site Reliability Engineering: Եվ փաստորեն, հենց այս գրքով սկսվեց SRE շարժումը: SRE-ը DevOps պարադիգմի հատուկ իրականացումն է կոնկրետ ընկերությունում: SRE ինժեներները պարտավորվում են ապահովել, որ համակարգերը հուսալիորեն աշխատեն: Նրանք հիմնականում գալիս են ծրագրավորողներից, երբեմն էլ ադմինիստրատորներից, որոնք ունեն զարգացման ուժեղ նախապատմություն: Եվ նրանք անում են այն, ինչ անում էին նախկինում համակարգի ադմինիստրատորները, բայց համակարգի զարգացման և կոդի առումով համակարգի իմացության ուժեղ ֆոնը հանգեցնում է նրան, որ այդ մարդիկ հակված չեն սովորական վարչական աշխատանքի, այլ հակված են ավտոմատացման:

Ստացվում է, որ SRE թիմերում DevOps պարադիգմն իրականացվում է նրանով, որ կան SRE ինժեներներ, որոնք լուծում են կառուցվածքային խնդիրներ։ Ահա այն նույն կապը Dev-ի և Ops-ի միջև, որի մասին մարդիկ խոսում էին 8 տարի: SRE-ի դերը նման է ճարտարապետի դերին, որովհետև նորեկները չեն դառնում SRE: Իրենց կարիերայի սկզբում մարդիկ դեռ չունեն փորձ, չունեն գիտելիքների անհրաժեշտ լայնություն։ Քանի որ SRE-ն պահանջում է շատ նուրբ գիտելիքներ այն մասին, թե կոնկրետ ինչ և երբ կարող է սխալվել: Ուստի այստեղ որոշակի փորձ է պետք, որպես կանոն, թե՛ ընկերության ներսում, թե՛ դրսում։

Նրանք հարցնում են, թե արդյոք SRE-ի և devops-ի տարբերությունը նկարագրվելու է: Նրան հենց նոր են նկարագրել: Մենք կարող ենք խոսել կազմակերպությունում SRE-ի տեղի մասին: Ի տարբերություն DevOps-ի այս դասական մոտեցման, որտեղ Ops-ը դեռ առանձին բաժին է, SRE-ը մշակողների թիմի մի մասն է: Նրանք ներգրավված են արտադրանքի մշակման մեջ: Նույնիսկ կա մի մոտեցում, որտեղ SRE-ն դեր է, որը անցնում է մի մշակողից մյուսին: Նրանք մասնակցում են կոդի վերանայումներին այնպես, ինչպես, օրինակ, UX դիզայներները, իրենք՝ ծրագրավորողները, երբեմն՝ արտադրանքի մենեջերները։ SRE-ները աշխատում են նույն մակարդակով: Մենք պետք է հաստատենք դրանք, մենք պետք է վերանայենք դրանք, որպեսզի յուրաքանչյուր տեղակայման համար SRE-ն ասի. «Լավ, այս տեղակայումը, այս արտադրանքը բացասաբար չի ազդի հուսալիության վրա: Իսկ եթե այդպես է, ապա որոշ ընդունելի սահմաններում։ Այս մասին նույնպես կխոսենք։

Համապատասխանաբար, SRE-ն ունի վետո՝ փոխել կոդը: Եվ ընդհանրապես, սա նաև հանգեցնում է ինչ-որ փոքր կոնֆլիկտի, եթե SRE-ը սխալ է իրականացվում: Կայքի հուսալիության ճարտարագիտության մասին նույն գրքում շատ մասեր, նույնիսկ մեկը, պատմում են, թե ինչպես խուսափել այդ կոնֆլիկտներից:

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

Համակարգի բարդությունը, որի վրա ազդում է SRE-ն, բարդությունը, որն ազդում է շահագործման հուսալիության վրա, անհրաժեշտ է և պատահական: Անհրաժեշտ բարդությունն այն է, երբ ապրանքի բարդությունն աճում է այնքանով, որքանով պահանջվում է նոր ապրանքի հատկանիշներով: Պատահական բարդությունն այն է, երբ համակարգի բարդությունը մեծանում է, բայց արտադրանքի առանձնահատկությունը և բիզնեսի պահանջներն ուղղակիորեն չեն ազդում դրա վրա: Ստացվում է, որ կա՛մ ծրագրավորողը ինչ-որ տեղ սխալ է թույլ տվել, կա՛մ ալգորիթմը օպտիմալ չէ, կա՛մ ներմուծվում են որոշ լրացուցիչ հետաքրքրություններ, որոնք առանց հատուկ կարիքի մեծացնում են արտադրանքի բարդությունը։ Լավ SRE-ը միշտ պետք է կտրի այս իրավիճակը: Այսինքն՝ ցանկացած commit, ցանկացած տեղակայում, ցանկացած ձգման հարցում, որտեղ դժվարությունը մեծանում է պատահական ավելացման պատճառով, պետք է արգելափակվի։

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

Այժմ խոսենք SRE-ի շահագործման չափանիշների մասին: Եվ առաջին հերթին հուսալիության մասին: Փոքր ընկերություններում, ստարտափներում հաճախ է պատահում, որ մարդիկ ենթադրում են, որ եթե ծառայությունը լավ է գրված, եթե ապրանքը լավ ու ճիշտ է գրված, ապա կաշխատի, չի կոտրվի։ Վերջ, լավ կոդ ենք գրում, ուրեմն կոտրելու բան չկա։ Կոդը շատ պարզ է, կոտրելու բան չկա։ Սրանք այն նույն մարդկանց մասին են, ովքեր ասում են, որ մեզ թեստեր պետք չեն, քանի որ, տեսեք, սրանք երեք VPI մեթոդներն են, ինչու՞ կոտրել այստեղ:

Այս ամենը, իհարկե, սխալ է: Եվ այս մարդկանց գործնականում շատ հաճախ է կծում նման օրենսգիրքը, քանի որ ամեն ինչ կոտրվում է։ Իրերը երբեմն կոտրվում են ամենաանկանխատեսելի ձևերով: Երբեմն մարդիկ ասում են՝ ոչ, դա երբեք չի լինի։ Եվ դա տեղի է ունենում անընդհատ: Բավական հաճախ է պատահում: Եվ դա է պատճառը, որ ոչ ոք երբեք չի ձգտում 100% հասանելիության, քանի որ 100% հասանելիությունը երբեք չի լինում: Սա նորմ է։ Եվ հետևաբար, երբ մենք խոսում ենք ծառայության առկայության մասին, մենք միշտ խոսում ենք իննի մասին: 2 ինը, 3 ինը, 4 ինը, 5 ինը: Եթե ​​սա թարգմանենք որպես պարապուրդ, ապա, օրինակ, 5 ինը, ապա սա տարեկան 5 րոպեից մի փոքր ավելի է, 2 ինը 3,5 օր պարապուրդ է:

Բայց ակնհայտ է, որ ինչ-որ պահի նկատվում է POI-ի, ներդրումների վերադարձի նվազում։ Երկու ինը իննից երեք իննին անցնելը նշանակում է ավելի քան 3 օրով ավելի քիչ պարապուրդ: Չորս իննից հինգի անցնելը տարեկան 47 րոպեով կրճատում է պարապուրդի ժամանակը: Եվ պարզվում է, որ բիզնեսի համար դա կարող է կրիտիկական չլինել։ Իսկ ընդհանրապես, պահանջվող հուսալիությունը տեխնիկական խնդիր չէ, առաջին հերթին դա բիզնեսի խնդիր է, դա ապրանքային խնդիր է։ Ինչ մակարդակի պարապուրդն է ընդունելի արտադրանքի օգտագործողների համար, ինչ են նրանք ակնկալում, որքան են վճարում, օրինակ, որքան գումար են կորցնում, որքան գումար է կորցնում համակարգը:

Այստեղ կարևոր հարց է, թե որն է մնացած բաղադրիչների հուսալիությունը: Որովհետև 4-ի և 5-ի միջև տարբերությունը տեսանելի չի լինի 2 ինը հուսալիությամբ սմարթֆոնի վրա: Կոպիտ ասած, եթե սմարթֆոնի վրա ինչ-որ բան կոտրվում է ձեր ծառայության մեջ տարեկան 10 անգամ, ամենայն հավանականությամբ 8 անգամ խափանումը տեղի է ունեցել ՕՀ-ի կողմից: Օգտագործողը սովոր է դրան, և տարին ևս մեկ անգամ ուշադրություն չի դարձնի: Անհրաժեշտ է փոխկապակցել հուսալիության և շահույթի ավելացման գինը:
Պարզապես SRE-ի մասին գրքում կա 4 իննից 3 իննին ավելացնելու լավ օրինակ: Ստացվում է, որ մատչելիության աճը 0,1%-ից մի փոքր պակաս է։ Իսկ եթե ծառայության եկամուտը կազմում է տարեկան 1 մլն դոլար, ապա եկամուտների աճը կազմում է 900 դոլար։ Եթե ​​մեզ համար տարեկան 900 դոլարից պակաս է ծախսվում մատչելիությունը իննով ավելացնելը, ապա այդ աճը ֆինանսական իմաստ ունի: Եթե ​​տարեկան 900 դոլարից ավելի արժե, ապա դա արդեն իմաստ չունի, քանի որ եկամուտների ավելացումը պարզապես չի փոխհատուցում աշխատուժի, ռեսուրսների ծախսերը։ Իսկ մեզ բավական կլինի 3 ինը։

Սա, իհարկե, պարզեցված օրինակ է, որտեղ բոլոր հարցումները հավասար են: Իսկ 3 իննից 4 ինը գնալը բավական հեշտ է, բայց միևնույն ժամանակ, օրինակ, 2 իննից 3-ին անցնելը, սա արդեն 9 հազար դոլարի խնայողություն է, կարող է ֆինանսական իմաստ ունենալ։ Բնականաբար, իրականում գրանցման հարցման ձախողումը ավելի վատ է, քան էջը չցուցադրելը, հարցումները տարբեր կշիռներ ունեն։ Բիզնեսի տեսանկյունից դրանք կարող են բոլորովին այլ չափանիշ ունենալ, բայց ամեն դեպքում, որպես կանոն, եթե խոսքը կոնկրետ ծառայությունների մասին չէ, ապա սա բավականին վստահելի մոտարկում է։
Հարց ստացանք, թե արդյոք SRE-ն ծառայության համար ճարտարապետական ​​լուծում ընտրելիս համակարգողներից մեկն է։ Ասենք առկա ենթակառուցվածքին ինտեգրվելու առումով, որպեսզի դրա կայունության մեջ կորուստ չլինի։ Այո, SRE-ները, ճիշտ այնպես, ինչպես pull հարցումները, պարտավորությունները, թողարկումները ազդում են ճարտարապետության, նոր ծառայությունների, միկրոծառայությունների ներդրման, նոր լուծումների ներդրման վրա: Ինչո՞ւ էի նախկինում ասում, որ փորձ է պետք, որակավորում է պետք։ Փաստորեն, SRE-ն ցանկացած ճարտարապետական ​​և ծրագրային լուծումների արգելափակող ձայներից մեկն է: Համապատասխանաբար, SRE-ը որպես ինժեներ, առաջին հերթին, պետք է ոչ միայն հասկանա, այլև հասկանա, թե ինչպես որոշ կոնկրետ որոշումներ կազդեն հուսալիության, կայունության վրա և հասկանա, թե ինչպես է դա առնչվում բիզնեսի կարիքներին, և ինչ տեսանկյունից կարող է ընդունելի լինել և որը ոչ:

Հետևաբար, այժմ մենք կարող ենք պարզապես խոսել հուսալիության չափանիշների մասին, որոնք ավանդաբար SRE-ում սահմանվում են որպես SLA (Service Level Agreement): Ամենայն հավանականությամբ ծանոթ տերմին է: SLI (Ծառայության մակարդակի ցուցիչ): SLO (Ծառայության մակարդակի նպատակ): Ծառայության մակարդակի պայմանագիրը, հավանաբար, խորհրդանշական տերմին է, հատկապես, եթե դուք աշխատել եք ցանցերի, պրովայդերների, հոսթինգի հետ: Սա ընդհանուր համաձայնագիր է, որը նկարագրում է ձեր ամբողջ ծառայության կատարումը, տույժերը, սխալների համար որոշ տուգանքներ, չափումներ, չափանիշներ: Իսկ SLI-ն ինքնին հասանելիության չափանիշն է: Այսինքն, թե ինչ կարող է լինել SLI-ն՝ ծառայությունից պատասխանի ժամանակը, սխալների քանակը՝ որպես տոկոս: Դա կարող է լինել թողունակություն, եթե դա ինչ-որ ֆայլի հոստինգ է: Ինչ վերաբերում է ճանաչման ալգորիթմներին, ապա ցուցիչ կարող է լինել, օրինակ, նույնիսկ պատասխանի ճիշտությունը։ SLO (Service Level Objective) համապատասխանաբար SLI ցուցանիշի, դրա արժեքի և ժամանակաշրջանի համադրություն է:

Ենթադրենք, SLA-ն կարող է այսպիսին լինել. Ծառայությունը հասանելի է ժամանակի 99,95%-ով ամբողջ տարվա ընթացքում: Կամ 99 կրիտիկական աջակցության տոմսերը կփակվեն եռամսյակում 3 ժամվա ընթացքում: Կամ հարցումների 85%-ին կպատասխանեն ամեն ամիս 1,5 վայրկյանի ընթացքում: Այսինքն՝ մենք աստիճանաբար հասկանում ենք, որ սխալներն ու ձախողումները միանգամայն նորմալ են։ Սա ընդունելի իրավիճակ է, մենք դա ծրագրում ենք, նույնիսկ որոշ չափով հույս ունենք դրա վրա։ Այսինքն, SRE-ն կառուցում է այնպիսի համակարգեր, որոնք կարող են սխալվել, որոնք պետք է նորմալ արձագանքեն սխալներին, որոնք պետք է հաշվի առնեն դրանք: Եվ հնարավորության դեպքում նրանք պետք է այնպես վարվեն սխալների հետ, որ օգտագործողը կա՛մ չնկատի դրանք, կա՛մ նկատի, բայց կա ինչ-որ լուծում, որի շնորհիվ ամեն ինչ ամբողջությամբ չի ընկնի։

Օրինակ, եթե դուք տեսանյութ եք վերբեռնում YouTube-ում, և YouTube-ը չի կարող այն անմիջապես փոխարկել, եթե տեսանյութը չափազանց մեծ է, եթե ձևաչափը օպտիմալ չէ, ապա հարցումը բնականաբար չի ձախողվի ժամանակի վերջում, YouTube-ը 502 սխալ չի տա: , YouTube-ը կասի. «Մենք ստեղծել ենք ամեն ինչ, ձեր տեսանյութը մշակվում է։ Մոտ 10 րոպեից պատրաստ կլինի»։ Սա նրբագեղ դեգրադացիայի սկզբունքն է, որը ծանոթ է, օրինակ, front-end-ի մշակումից, եթե երբևէ դա արել եք:

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

Կրկին, կան շատ հոդվածներ, շատ մեթոդներ, շատ եղանակներ նույնիսկ հենց այն գրքում, որին ես հաճախ եմ անդրադառնում, թե ինչպես համոզվել, որ մյուս մշակողները չսկսեն ատել SRE-ն: Մյուս կողմից, MTTR-ն ձեր SLO-ների վրա աշխատելու մասին է (Service Level Objective): Եվ դա հիմնականում ավտոմատացում է: Քանի որ, օրինակ, մեր SLO-ն եռամսյակում 4 ինն է: Սա նշանակում է, որ 3 ամսվա ընթացքում մենք կարող ենք թույլ տալ 13 րոպե անգործություն: Եվ պարզվում է, որ MTTR-ը չի կարող ավելի քան 13 րոպե լինել։ Եթե ​​13 րոպեում արձագանքենք առնվազն 1 պարապուրդի, դա նշանակում է, որ մենք արդեն սպառել ենք եռամսյակի ողջ բյուջեն։ Մենք կոտրում ենք SLO-ն։ 13 րոպեն արձագանքելու և վթարը շտկելու համար շատ է մեքենայի համար, բայց շատ կարճ է մարդու համար: Որովհետև քանի դեռ մարդը ահազանգ չի ստանում, մինչև արձագանքում է, մինչև սխալը չի ​​հասկանում, արդեն մի քանի րոպե է։ Քանի դեռ մարդը չի հասկանում, թե ինչպես շտկել, կոնկրետ ինչ շտկել, ինչ անել, ապա սա դեռ մի քանի րոպե է։ Եվ իրականում, նույնիսկ եթե ձեզ պարզապես անհրաժեշտ է վերագործարկել սերվերը, ինչպես պարզվում է, կամ բարձրացնել նոր հանգույց, ապա ձեռքով MTTR-ն արդեն մոտ 7-8 րոպե է: Գործընթացը ավտոմատացնելիս MTTR-ը շատ հաճախ հասնում է վայրկյանի, երբեմն միլիվայրկյանների: Google-ը սովորաբար խոսում է միլիվայրկյանների մասին, բայց իրականում, իհարկե, ամեն ինչ այնքան էլ լավ չէ։

Իդեալում, SRE-ն պետք է գրեթե ամբողջությամբ ավտոմատացնի իր աշխատանքը, քանի որ դա ուղղակիորեն ազդում է MTTR-ի, դրա չափման, ամբողջ ծառայության SLO-ի և, համապատասխանաբար, բիզնեսի շահույթի վրա: Եթե ​​ժամանակը գերազանցում է, մեզ հարցնում են, թե արդյոք SRE-ն մեղավոր է: Բարեբախտաբար, ոչ ոք մեղավոր չէ։ Եվ սա առանձին մշակույթ է, որը կոչվում է բալասան հետմահու, որի մասին այսօր չենք խոսի, բայց կվերլուծենք Slurm-ում։ Սա շատ հետաքրքիր թեմա է, որի մասին կարելի է շատ խոսել։ Կոպիտ ասած, եթե եռամսյակի համար նախատեսված ժամանակը գերազանցում է, ուրեմն բոլորից մի քիչ մեղավոր են, ինչը նշանակում է, որ բոլորին մեղադրելը արդյունավետ չէ, փոխարենը, գուցե ոչ մեկին չմեղադրենք, բայց շտկենք իրավիճակը և աշխատենք մեր ունեցածով։ Իմ փորձով այս մոտեցումը փոքր-ինչ խորթ է թիմերի մեծ մասի համար, հատկապես Ռուսաստանում, բայց դա իմաստալից է և շատ լավ է աշխատում: Հետևաբար, ես խորհուրդ կտամ հոդվածի և գրականության վերջում, որը կարող եք կարդալ այս թեմայով: Կամ եկեք Slurm SRE:

Թույլ տուր բացատրեմ. Եթե ​​SLO-ի եռամսյակի ժամանակը գերազանցվում է, եթե պարապուրդը եղել է ոչ թե 13 րոպե, այլ 15, ո՞վ կարող է մեղավոր լինել դրա համար: Իհարկե, SRE-ն կարող է մեղավոր լինել, քանի որ նա ակնհայտորեն ինչ-որ վատ պարտավորություն կամ տեղակայում է արել: Դրա համար կարող է մեղավոր լինել տվյալների կենտրոնի ադմինիստրատորը, քանի որ նա ինչ-որ չպլանավորված սպասարկում է իրականացրել։ Եթե ​​դրանում մեղավոր է տվյալների կենտրոնի ադմինիստրատորը, ապա դրա մեղավորը Ops-ից է, ով SLO-ն համակարգելիս չի հաշվարկել սպասարկումը։ Դրա համար մեղավոր է մենեջերը, տեխնիկական տնօրենը կամ որևէ մեկը, ով ստորագրել է տվյալների կենտրոնի պայմանագիրը և ուշադրություն չի դարձրել այն փաստին, որ տվյալների կենտրոնի SLA-ն նախատեսված չէ պահանջվող պարապուրդի համար: Ըստ այդմ, այս իրավիճակում կամաց-կամաց բոլորն են մեղավոր։ Իսկ դա նշանակում է, որ այս իրավիճակում որեւէ մեկի վրա մեղքը բարդելը իմաստ չունի։ Բայց, իհարկե, պետք է շտկել։ Դրա համար էլ կան հետմահու։ Եվ եթե դուք կարդում եք, օրինակ, GitHub-ի հետմահուները, և սա միշտ շատ հետաքրքիր, փոքր և անսպասելի պատմություն է յուրաքանչյուր կոնկրետ դեպքում, կարող եք փոխարինել, որ ոչ ոք երբեք չի ասում, որ կոնկրետ այս մարդն է մեղավոր: Մեղքը միշտ բարդվում է կոնկրետ անկատար գործընթացների վրա։

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

Իրականում, դա գրեթե միշտ եղել է, և շատ քիչ դեպքեր կան, երբ ինչ-որ բան չպետք է ավտոմատացվի SRE-ի դերում: Հաջորդիվ կխոսենք այն մասին, ինչը կոչվում է սխալ բյուջե, սխալների բյուջե։ Փաստորեն, պարզվում է, որ եթե ձեզ համար ամեն ինչ շատ ավելի լավ է, քան SLO-ն, որը դուք ինքներդ եք սահմանել, սա նույնպես այնքան էլ լավ չէ: Սա բավականին վատ է, քանի որ SLO-ն աշխատում է ոչ միայն որպես ստորին, այլ նաև որպես մոտավոր վերին սահման: Երբ դուք ձեզ սահմանում եք 99% հասանելիության SLO, իսկ իրականում ունեք 99,99%, ստացվում է, որ դուք ունեք որոշակի տարածք փորձերի համար, որոնք ընդհանրապես չեն վնասի բիզնեսին, քանի որ դուք ինքներդ եք որոշել այս ամենը միասին, և դուք այս տարածքը չօգտագործել: Սխալների համար բյուջե ունեք, որը ձեր դեպքում չի սպառվում։

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

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

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

Պարզվում է, որ արտադրության մեջ փորձերը բավականին կարևոր և գրեթե անբաժանելի մասն են SRE-ի մեծ թիմերում: Եվ դա սովորաբար կոչվում է քաոսի ինժեներություն, որը գալիս է Netflix-ի թիմից, որը թողարկել է Chaos Monkey կոչվող օգտակար ծրագիրը:
Chaos Monkey-ը միանում է CI/CD խողովակաշարին և պատահականորեն խափանում է սերվերը արտադրության մեջ: Կրկին SRE կառուցվածքում մենք խոսում ենք այն մասին, որ խափանված սերվերն ինքնին վատ չէ, սպասելի է։ Իսկ եթե բյուջեի սահմաններում է, ընդունելի է ու բիզնեսին չի վնասում։ Իհարկե, Netflix-ն ունի բավականաչափ ավելորդ սերվերներ, բավականաչափ կրկնօրինակում, որպեսզի այս ամենը հնարավոր լինի շտկել, և որպեսզի օգտագործողն ամբողջությամբ չնկատի, և առավել եւս ոչ ոք չթողնի մեկ սերվեր որևէ բյուջեի համար:

Netflix-ը որոշ ժամանակ ուներ նման կոմունալ ծրագրերի մի ամբողջ փաթեթ, որոնցից մեկը՝ Chaos Gorilla-ն, ամբողջությամբ անջատում է Amazon-ի հասանելիության գոտիներից մեկը: Իսկ նման բաներն օգնում են բացահայտել, առաջին հերթին, թաքնված կախվածությունները, երբ լիովին պարզ չէ, թե ինչի վրա է ազդում, ինչից է կախված։ Եվ սա, եթե դուք աշխատում եք միկրոսերվիսի հետ, և փաստաթղթերը այնքան էլ կատարյալ չեն, սա ձեզ կարող է ծանոթ լինել: Եվ կրկին, սա շատ է օգնում կոդի մեջ սխալներ հայտնաբերելու համար, որոնք դուք չեք կարող բռնել բեմադրման ժամանակ, քանի որ ցանկացած բեմադրություն ճշգրիտ սիմուլյացիա չէ, քանի որ բեռի սանդղակը տարբեր է, բեռնվածքի օրինաչափությունը տարբեր է, սարքավորումները. նաև, ամենայն հավանականությամբ, այլ. Պիկ բեռները կարող են լինել նաև անսպասելի և անկանխատեսելի: Եվ նման փորձարկումը, որը կրկին չի անցնում բյուջեից, շատ լավ օգնում է ենթակառուցվածքում սխալներ հայտնաբերելուն, որոնք երբեք չեն բռնի բեմադրությունը, ավտոմատ փորձարկումները, CI / CD խողովակաշարը: Եվ քանի դեռ այդ ամենը ներառված է ձեր բյուջեում, կապ չունի, որ ձեր ծառայությունն այնտեղ է իջել, թեև շատ սարսափելի կթվա, սերվերը իջավ, ինչ մղձավանջ: Ոչ, դա նորմալ է, դա լավ է, դա օգնում է բռնել սխալները: Եթե ​​ունես բյուջե, ուրեմն կարող ես այն ծախսել։

Հարց: Ի՞նչ գրականություն կարող եմ խորհուրդ տալ: Ցուցակ վերջում։ Շատ գրականություն կա, մի քանի զեկույց խորհուրդ կտամ։ Ինչպե՞ս է այն աշխատում, և արդյոք SRE-ն աշխատում է ընկերություններում, որոնք չունեն իրենց սեփական ծրագրային արտադրանք կամ նվազագույն մշակում: Օրինակ՝ ձեռնարկությունում, որտեղ հիմնական գործունեությունը ծրագրային ապահովումը չէ։ Ձեռնարկությունում, որտեղ հիմնական գործունեությունը ծրագրակազմը չէ, SRE-ն աշխատում է ճիշտ այնպես, ինչպես ամենուր, քանի որ ձեռնարկությունում դուք նույնպես պետք է օգտագործեք, նույնիսկ եթե մշակված չեք, ծրագրային արտադրանք, դուք պետք է տարածեք թարմացումներ, դուք պետք է փոխեք: ենթակառուցվածքը, պետք է աճել, պետք է մասշտաբել: Եվ SRE-ներն օգնում են բացահայտել և կանխատեսել հնարավոր խնդիրները այս գործընթացներում և վերահսկել դրանք որոշակի աճի սկսվելուց և բիզնեսի կարիքները փոխվելուց հետո: Որովհետև բացարձակապես պարտադիր չէ ներգրավվել ծրագրային ապահովման մշակման մեջ՝ SRE ունենալու համար, եթե ունեք առնվազն մի քանի սերվեր և ակնկալվում է, որ գոնե որոշակի աճ կունենաք:

Նույնը վերաբերում է փոքր նախագծերին, փոքր կազմակերպություններին, քանի որ մեծ ընկերությունները ունեն բյուջե և տարածք փորձերի համար: Բայց միևնույն ժամանակ, փորձերի այս բոլոր պտուղները կարող են օգտագործվել ցանկացած վայրում, այսինքն՝ SRE-ն, իհարկե, հայտնվել է Google-ում, Netflix-ում, Dropbox-ում։ Բայց միևնույն ժամանակ փոքր ընկերություններն ու ստարտափներն արդեն կարող են կարդալ խտացված նյութ, կարդալ գրքեր, դիտել հաշվետվություններ։ Նրանք սկսում են ավելի հաճախ լսել այդ մասին, կոնկրետ օրինակներ են նայում, կարծում եմ՝ լավ է, իսկապես կարող է օգտակար լինել, սա մեզ էլ է պետք, հիանալի է։

Այսինքն՝ այս գործընթացների ստանդարտացման բոլոր հիմնական աշխատանքները արդեն կատարվել են ձեզ համար։ Մնում է, որ դուք որոշեք SRE-ի դերը հատուկ ձեր ընկերությունում և սկսեք իրականում իրականացնել այս բոլոր պրակտիկաները, որոնք, կրկին, արդեն նկարագրված են: Այսինքն, փոքր ընկերությունների համար օգտակար սկզբունքներից սա միշտ էլ SLA, SLI, SLO սահմանումն է: Եթե ​​դուք ներգրավված չեք ծրագրային ապահովման մեջ, ապա դրանք կլինեն ներքին SLA-ներ և ներքին SLO-ներ, սխալների ներքին բյուջե: Սա գրեթե միշտ հանգեցնում է թիմի և բիզնեսի ներսում որոշ հետաքրքիր քննարկումների, քանի որ կարող է պարզվել, որ դուք ծախսում եք ենթակառուցվածքների վրա, ինչ-որ իդեալական գործընթացների կազմակերպման վրա, իդեալական խողովակաշարը շատ ավելին է, քան անհրաժեշտ է: Եվ այս 4 ինը, որոնք դուք ունեք ՏՏ բաժնում, հիմա դրանք իրականում ձեզ պետք չեն: Բայց միևնույն ժամանակ կարող էիր ժամանակ ծախսել, բյուջեն ծախսել սխալների համար այլ բանի վրա։

Ըստ այդմ, մոնիտորինգը և մոնիտորինգի կազմակերպումը օգտակար է ցանկացած չափի ընկերության համար: Իսկ ընդհանրապես, այս մտածելակերպը, որտեղ սխալներն ընդունելի բան են, որտեղ բյուջե կա, որտեղ կան Նպատակներ, նորից օգտակար է ցանկացած չափի ընկերության համար՝ սկսած 3 հոգու ստարտափներից։

Խոսելու տեխնիկական նրբերանգներից վերջինը մոնիտորինգն է: Որովհետև եթե մենք խոսում ենք SLA-ի, SLI-ի, SLO-ի մասին, մենք չենք կարող հասկանալ առանց մոնիտորինգի, արդյոք մենք տեղավորվում ենք բյուջեի մեջ, համապատասխանում ենք արդյոք մեր Նպատակներին և ինչպես ենք ազդում վերջնական SLA-ի վրա: Ես շատ անգամ եմ տեսել, որ մոնիտորինգը տեղի է ունենում այսպես՝ կա որոշակի արժեք, օրինակ՝ սերվերին հարցման ժամանակը, միջին ժամանակը կամ տվյալների բազայի հարցումների քանակը։ Նա ունի ինժեների կողմից որոշված ​​չափորոշիչ: Եթե ​​ցուցանիշը շեղվում է նորմայից, ապա էլեկտրոնային նամակ է գալիս: Այս ամենը, որպես կանոն, բացարձակապես անիմաստ է, քանի որ դա հանգեցնում է ահազանգերի այնպիսի լիցքաթափման, մոնիտորինգից ստացված հաղորդագրությունների գերբնակեցման, երբ մարդը, առաջին հերթին, պետք է ամեն անգամ մեկնաբանի դրանք, այսինքն՝ որոշի, թե արդյոք չափիչի արժեքը նշանակում է. որոշակի գործողությունների անհրաժեշտություն. Եվ երկրորդ՝ նա պարզապես դադարում է նկատել այս բոլոր ահազանգերը, երբ հիմնականում նրանից որևէ գործողություն չի պահանջվում։ Դա լավ մոնիտորինգի կանոն է, և SRE-ի ներդրման առաջին կանոնն այն է, որ ծանուցումը պետք է լինի միայն այն դեպքում, երբ անհրաժեշտ է գործողություն:

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

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

Մոնիտորինգից մենք անցնում ենք մի տերմինի, որը կոչվում է դիտարկելիություն: Վերջին մի քանի տարիների ընթացքում այս բառի շուրջ նույնպես մի փոքր աղմուկ է բարձրացել: Եվ քչերն են հասկանում, թե դա ինչ է նշանակում կոնտեքստից դուրս: Բայց գլխավորն այն է, որ դիտարկելիությունը համակարգի թափանցիկության չափիչ է: Եթե ​​ինչ-որ բան սխալ է տեղի ունեցել, ապա որքան արագ կարող եք որոշել, թե կոնկրետ ինչն է սխալ եղել և ինչ վիճակում է եղել համակարգը այդ պահին: Կոդի առումով՝ որ ֆունկցիան ձախողվեց, որ ծառայությունը ձախողվեց: Ինչ վիճակում էին, օրինակ, ներքին փոփոխականները, կոնֆիգուրացիան: Ենթակառուցվածքի առումով սա այն է, թե որ հասանելիության գոտում է տեղի ունեցել խափանումը, և եթե ունեք որևէ Kubernetes տեղադրված, ապա որ pod-ում է տեղի ունեցել խափանումը, ինչ վիճակում է եղել pod-ը: Եվ համապատասխանաբար, Observability-ն անմիջական կապ ունի MTTR-ի հետ։ Որքան բարձր է ծառայության դիտարկելիությունը, այնքան ավելի հեշտ է բացահայտել սխալը, այնքան հեշտ է ուղղել սխալը, այնքան հեշտ է ավտոմատացնել սխալը, այնքան ցածր է MTTR-ը:

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

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

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

Հարց կար SRE գործիքների մասին։ Այսինքն՝ կա՞ ինչ-որ հատուկ բան, որը SRE-ները կօգտագործեին, ինչը բոլորը չէին օգտագործում: Փաստորեն, կան որոշ բարձր մասնագիտացված կոմունալ ծառայություններ, կա ինչ-որ ծրագրակազմ, որը, օրինակ, մոդելավորում է բեռները կամ զբաղվում է դեղձանիկի A/B փորձարկումով: Բայց հիմնականում SRE գործիքակազմն այն է, ինչ ձեր մշակողները արդեն օգտագործում են: Քանի որ SRE-ն անմիջականորեն համագործակցում է մշակողների թիմի հետ: Իսկ եթե ունեք տարբեր գործիքներ, կպարզվի, որ համաժամացման համար ժամանակ է պետք։ Հատկապես, եթե SRE-ները աշխատում են մեծ թիմերում, խոշոր ընկերություններում, որտեղ կարող են լինել մի քանի թիմեր, այստեղ մեծապես կօգնի ընկերության ստանդարտացումը, քանի որ եթե 50 թիմում օգտագործվում են 50 տարբեր կոմունալ ծառայություններ, դա նշանակում է, որ SRE-ը պետք է իմանա դրանք: բոլորը. Եվ իհարկե դա երբեք չի լինի։ Իսկ աշխատանքի որակը, թիմերից գոնե մի քանիսի հսկողության որակը էապես կնվազի։

Մեր վեբինարը մոտենում է ավարտին։ Ինձ հաջողվեց մի քանի տարրական բաներ պատմել. Իհարկե, SRE-ի մասին ոչինչ չի կարելի պատմել ու հասկանալ մեկ ժամում։ Բայց հուսով եմ, որ ինձ հաջողվեց փոխանցել այս մտածելակերպը, հիմնական առանցքային կետերը։ Եվ հետո, եթե հետաքրքրված է, հնարավոր կլինի խորանալ թեմայի մեջ, ինքնուրույն սովորել, տեսնել, թե ինչպես է այն իրականացվում այլ մարդկանց կողմից, այլ ընկերություններում: Եվ համապատասխանաբար, փետրվարի սկզբին, եկեք մեզ մոտ Slurm SRE:

Slurm SRE-ը եռօրյա ինտենսիվ դասընթաց է, որը կխոսի այն մասին, ինչի մասին ես հիմա խոսում եմ, բայց շատ ավելի խորությամբ, իրական դեպքերով, պրակտիկայով, ամբողջ ինտենսիվը միտված է գործնական աշխատանքին։ Մարդիկ կբաժանվեն թիմերի. Դուք բոլորդ կաշխատեք իրական դեպքերի վրա: Ըստ այդմ, մենք ունենք Booking.com-ի հրահանգիչներ Իվան Կրուգլովը և Բեն Թայլերը: Մենք ունենք հրաշալի Եվգենի Բարաբբա Google-ից, Սան Ֆրանցիսկոյից: Եվ ես էլ ձեզ մի բան կասեմ. Այսպիսով, անպայման այցելեք մեզ:
Այսպիսով, մատենագիտությունը. Հղումներ կան SRE-ի վերաբերյալ: Առաջին նույն գրքի վրա, ավելի ճիշտ՝ Google-ի կողմից գրված SRE-ի մասին 2 գրքի վրա։ Ուրիշ մեկը փոքր հոդված SLA, SLI, SLO մասին, որտեղ պայմանները և դրանց կիրառումը մի փոքր ավելի մանրամասն են։ Հաջորդ 3-ը տարբեր ընկերություններում SRE-ի վերաբերյալ հաշվետվություններ են: Առաջին - SRE-ի բանալիներ, սա Google-ի Ben Trainer-ի հիմնական նոտա է: Երկրորդ - SRE Dropbox-ում. Երրորդը կրկին SRE Google-ին. Չորրորդ զեկույցը SRE Netflix-ում, որն ունի ընդամենը 5 հիմնական SRE աշխատակից 190 երկրներում: Այս ամենին նայելը շատ հետաքրքիր է, քանի որ ինչպես DevOps-ը տարբեր ընկերությունների և նույնիսկ տարբեր թիմերի համար նշանակում է շատ տարբեր բաներ, SRE-ն ունի շատ տարբեր պարտականություններ, նույնիսկ նմանատիպ չափերի ընկերություններում:

Եվս 2 հղում քաոսային ճարտարագիտության սկզբունքների վերաբերյալ. (1), (2). Իսկ վերջում կա 3 ցուցակ Awesome Lists-ի մասին շարքից քաոսի ճարտարագիտությունմասին ՍԻՐ և դրա մասին SRE գործիքակազմ. SRE-ի ցանկը աներևակայելի հսկայական է, պետք չէ այդ ամենը անցնել, կա մոտ 200 հոդված։ Ես խիստ խորհուրդ եմ տալիս այնտեղից հոդվածներ կարողությունների պլանավորման և անմեղ հետմահու մասին:

Հետաքրքիր հոդված: SRE որպես կյանքի ընտրություն

Շնորհակալ եմ այս ամբողջ ընթացքում ինձ լսելու համար: Հուսով եմ, որ դուք ինչ-որ բան եք սովորել: Հուսով եմ, որ բավականաչափ նյութ ունեք՝ ավելին իմանալու համար: Եվ կտեսնվենք: Հուսանք՝ փետրվարին։
Վեբինարը վարում էր Էդուարդ Մեդվեդևը։

Հ.Գ.Կարդալ սիրողների համար Էդուարդը հղումների ցանկ է տվել։ Նրանք, ովքեր նախընտրում են գործնականում հասկանալ, ողջունելի են Slurme SRE.

Source: www.habr.com