Ի՞նչ է բարձր հասանելիությունը: SLA IaaS-ի համար. իրական երաշխիքներ վիրտուալ ՏՏ ենթակառուցվածքի համար Բարձր հասանելիություն որպես ծառայություն:

Ծառայությունները «ՏՏ ենթակառուցվածքը որպես ծառայություն», IaaS, դառնում են ավելի տարածված կորպորատիվ հաճախորդներ, և դրանք արդեն օգտագործվում ենև կարևոր առաջադրանքների համար: Ժամանակն է պարզել այնինչ են երաշխավորում այդ ծառայությունների մատուցողները և ինչ պատասխանատվություն են կրում այն ​​դեպքերում, երբ վիրտուալ ՏՏ ենթակառուցվածքը դանդաղեցնում է աշխատանքը կամ դառնում է ամբողջովին անհասանելի:

Մենք հարցազրույց վերցրեցինք ձեռնարկությունների մակարդակի IaaS ենթակառուցվածքային ծառայություններ մատուցող առաջատարներից և վերլուծեցինք նրանց առաջարկները: Միևնույն ժամանակ, «կորպորատիվ մակարդակը» նշանակում է հետևյալը. ամպային հարթակը տեղակայված է տվյալների կենտրոնում, որը համապատասխանում է III մակարդակի պահանջներին (Uptime Institute-ի վկայագրի առկայությունը չիպահանջվում է), և ապահովում է անսարքությունների հանդուրժողականության բարձր մակարդակ բարձր հասանելիության (HA) մեխանիզմների և վիրտուալ մեքենաների տեղափոխման միջոցով աղետի դեպքում:

Հասանելիություն և պատասխանի ժամանակը

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

Որոշելով օգտվել վիրտուալ ՏՏ ենթակառուցվածքից՝ կարող եք ապահով հույս դնել 99,5% և ավելի բարձր հասանելիության վրա: Համենայն դեպս, մեր հարցված պրովայդերներից և ոչ մեկը ավելի ցածր ցուցանիշ չի նշել: Ավելին, շատ ընկերությունների ներկայացուցիչներ ընդգծել են, որ իրենց պատասխաններում նշված արժեքը (տե՛ս Աղյուսակ 1) բնորոշ է և, հաճախորդի խնդրանքով, մատչելիության մակարդակը կարելի է բարձրացնել՝ օգտագործելով տարբեր տեխնիկական միջոցներ:

Սովորաբար, ձեռնարկատիրական կարգի IaaS հարթակները տեղակայված են տվյալների կենտրոններում (սեփական կամ արտաքին), որոնք համապատասխանում են III մակարդակի սխալների հանդուրժողականությանը, որը, ինչպես հայտնի է, առաջարկում է 99,98% հասանելիություն: Պրովայդերների կողմից նշված IaaS վիրտուալ ենթակառուցվածքների հասանելիության արժեքները չեն գերազանցում ֆիզիկական կայքի համապատասխան բնութագրերը, ինչը միանգամայն բնական է:

Բացառություն է կազմում 99,99% հասանելիությունը, որը տրամադրվում է Dataline-ի կողմից մետրոյի կլաստերի ռեժիմում: Աղետի այս տարբերակը Ամպը ծածկում է ընկերության տվյալների երկու կենտրոնները. մետրոյի կլաստերի մասին լրացուցիչ տեղեկությունների համար տե՛ս «Աղետների դեմ պաշտպանված ամպը «ոչ ամպամած» գնով» նյութը, որը հրապարակվել է Journal of Networking Solutions / LAN ամսագրի 2013 թվականի հոկտեմբերի համարում ( ):

Սկզբունքորեն, մատակարարը կարող է SLA-ում նշել կամայականորեն բարձր հասանելիություն, նույնիսկ 100%, բայց հետո նա ռիսկի է դիմում կորցնել ավելին, քան վաստակել, քանի որ ցանկացած խելամիտ գնորդ կպահանջի, որ փոխհատուցման խիստ սխեման ներառվի պայմանագրում պահանջների չկատարման համար: համաձայնեցված պայմաններ. Թեև ստանդարտ սխեման դեռ չի մշակվել, յուրաքանչյուր մատակարար առաջարկում է այլ բան, ուստի գնորդը պետք է գնահատի առաջարկվող փոխհատուցումը` հաշվի առնելով ՏՏ ծառայությունների խափանումների դեպքում հնարավոր ֆինանսական կորուստները:

Շատ ընկերություններ առաջարկում են որոշակի քանակությամբ ամսական վճարման փոխհատուցում (որպես տոկոս) ծառայության անհասանելիության յուրաքանչյուր լրացուցիչ (SLA-ից դուրս) ժամի համար: Օրինակ, եթե SLA-ում նշված հասանելիության մակարդակը կազմում է 99,95% (ոչ ավելի, քան ամսական 1 ժամ), ծառայությունից անջատման յուրաքանչյուր լրացուցիչ ժամի համար, Inoventica-ն պատրաստ է փոխհատուցել ամսական վճարի 2%-ը: Cloud4Y-ը ստանդարտ տարբերակում փոխհատուցում է 1% 1 ժամ անգործության համար (հաշվարկների օգտագործում ընդհանուր արժեքըծառայություններ ամբողջությամբ օրացուցային ամիսնախորդող), բայց ոչ ավելի, քան ծառայության արժեքի 50%-ը:

Մի շարք մատակարարներ ներկայացրել են մանրամասն հաշվարկներ, թե ինչպես է փոխհատուցումը տատանվում ըստ հասանելիության մակարդակի (տես Աղյուսակ 2): Այս մակարդակի զգալի կրճատման դեպքում առաջարկվում է շատ էական փոխհատուցում: Օրինակ, եթե արժեքը 95%-ից պակաս է, Օնլանտան (Լանիթ ընկերությունների խումբ) թույլ է տալիս ծառայության դիմաց վճարման մակարդակը նվազեցնել մինչև 40%: Իսկ IT-Grad ընկերությունը, եթե հասանելիության մակարդակը իջնի 96,71%-ից, խոստանում է 50% փոխհատուցում։ Հասկանալի է, որ ծառայությունների որակի նման վատթարացումը մատակարարները քիչ հավանական են համարում։

«Մենք ներդրել ենք փոխհատուցման երկու անկախ սկզբունք՝ ծառայության պարամետրերի թիրախային ցուցիչները խախտելու և հարցումների մշակման թիրախային ցուցիչները», - ասում է Վիտալի Մզոկովը, Servionika-ի Cloud Services and Infrastructure Solutions-ի ղեկավարը (I-Teco Group): - Ծառայության պարամետրերի թիրախային ցուցանիշների խախտումը փոխհատուցվում է պրոգրեսիվ մասշտաբով. Կախված առկայության փաստացի մակարդակից՝ հաշվարկվում է փոխհատուցման ցուցիչ՝ արտահայտված որպես ծառայությունից օգտվելու համար ապրանքագրի գումարի տոկոս: Հարցումների մշակման թիրախների խախտման համար փոխհատուցումը հաշվարկվում է հաճախորդի սպասման տևողության հիման վրա՝ մինչև մեկ րոպե ճշգրտությամբ:

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

«Ըստ պայմանագրի՝ հաճախորդը մեզնից կարող է մի քանի ծառայություններ ստանալ։ Այդ իսկ պատճառով կանոնակարգը նկարագրում է ընդհանուր ցուցանիշներ«Հատուկ ծառայության համար SLA-ում սահմանված թիրախները համընկնում են կանոնակարգով սահմանված ցուցանիշների հետ»: Դա արվում է այնպես, որ անհրաժեշտության դեպքում հնարավոր լինի ճշտել (երկարացնել կամ կրճատել) ռեակցիայի ժամանակը և լուծման ժամանակը»,- ​​բացատրում է Վիտալի Մզոկովը։ - Մենք պարտավոր ենք ցանկացած տեսակի հարցումներին պատասխանել 15 րոպեի ընթացքում։ Լուծման առավելագույն ժամանակը, կախված հարցման տեսակից և առաջնահերթությունից, տատանվում է 1 ժամից (թիվ 1 առաջնահերթություն ունեցող միջադեպերի համար) մինչև 48 ժամ (հարցումների համար, որոնք պահանջում են հաճախորդի տեղեկատվության հարցման ամբողջական մշակում, օրինակ՝ տեղեկատվության տրամադրում: սակագների և այլ ծառայությունների, տարբեր պարզաբանումների և հրահանգների վերաբերյալ):

Դիմումին պատասխանելու ժամանակը սովորաբար կախված է դրա առաջնահերթությունից: Օրինակ, ահա առաջնահերթության մակարդակները, որոնք օգտագործում է Linxdatacenter-ը.

• Կրիտիկական - ծառայությունը լիովին հասանելի չէ, անհրաժեշտ է շտապ միջոցներ ձեռնարկել վերականգնման համար, արձագանքման ժամանակը 15 րոպե է, վերականգնման ժամանակը ոչ ավելի, քան 4 ժամ;
• Բարձր - սպասարկումը մասամբ անհասանելի է, արձագանքման ժամանակը մինչև 1 ժամ, բարձր առաջնահերթություն;
• Նորմալ - պատասխան պատրաստելու համար հատկացվում է ծառայության պարամետրերի պարզաբանում, ընթացիկ ոչ հրատապ հարցեր, պատասխանի ժամանակը մինչև 1 ժամ, 24 ժամ:

Աղյուսակ 3-ը ցույց է տալիս ևս մեկ օրինակ՝ Cloud4Y-ի կողմից օգտագործվող հարցումների դասակարգումը; արձագանքման ժամանակը `ոչ ավելի, քան 30 րոպե:

Անմիջապես փորձում է աշխատել T-Systems-ում: T-Systems RUS-ի ՏՀՏ բաժնի վաճառքի տնօրեն Վսևոլոդ Եգուպովի խոսքով, այս ընկերության մասնագետները «80% դեպքերում արձագանքում են 30 վայրկյանում» (!): Բայց, ինչպես մեր հարցվողներից շատերը, նա նշեց, որ արձագանքման ժամանակը կախված է իրավիճակի կրիտիկականությունից։

ՄՈՆԻՏՈՐԻՆԳԻ ԳՈՐԾԻՔՆԵՐ

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

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

Շատ ընկերություններ, ըստ լռելյայն, ամիսը մեկ անգամ տրամադրում են ծառայության առողջության մասին հաշվետվություններ, բայց կարող են դա անել ավելի հաճախ՝ հաճախորդների խնդրանքով: Onlanta-ի կողմից առաջարկված հաշվետվության օրինակը ներկայացված է Նկար 1-ում: Ըստ Միխայիլ Լյապինի՝ իր ամպային ստորաբաժանման ղեկավարի, Onlanta-ն միակ ընկերությունն է Ռուսաստանում, որը հաճախորդներին տրամադրում է հաշվետվություն ամպային ռեսուրսների առկայության մասին այս մակարդակի մանրամասնությամբ: Նրա խոսքով, ծառայություններ մատուցողների մեծ մասը յոլա է գնում վիրտուալ մեքենաների հասանելիության մակարդակի վիճակագրությամբ։

Մի շարք ընկերություններ հաճախորդներին առաջարկում են առցանց ինքնասպասարկման վահանակ: Croc-ի գլխավոր տնօրենի տեղակալ, Տվյալների կենտրոնի և Cloud Computing-ի ղեկավար Ռուսլան Զաեդինովի խոսքերով, IaaS ծառայության յուրաքանչյուր սպառող ունի մուտք դեպի նման կոնսոլ՝ ներկառուցված առցանց որոշ բաղադրիչների աշխատանքը վերահսկելու ունակությամբ: Օրինակ, վիրտուալ մեքենաների դեպքում, հաճախորդի ՏՏ մասնագետները կարող են հետևել, թե որքանով է զբաղված պրոցեսորը, ինչպես է աշխատում I/O-ն, որքան հիշողություն է օգտագործվում և այլն: Այս տվյալները հասանելի են իրական ժամանակում, ինչպես նաև. հարցում - ցանկացած ժամանակաշրջանի վիճակագրության տեսքով:

ԿԱՏԱՐՈՒՄԸ ՊԵՏՔ Է ԵՐԱՇԽԱՎՈՐՎԻ

Ակնհայտ է, որ մատակարարի IaaS պլատֆորմի վրա բեռի ավելացման դեպքում վիրտուալ մեքենայի կատարողականի մակարդակը կարող է նվազել: Ծառայություններ մատուցողները անում են ամեն ինչ, որպեսզի դա տեղի չունենա: Այս հարցում համաձայն են բոլոր ընկերությունները։ Այնուամենայնիվ, ոմանք SLA-ում ներառում են կատարողականի պարամետրեր, իսկ մյուսները համարում են, որ նման չափումը ավելորդ է:

Ահա թե ինչ է ասում Inoventica-ի տնօրենների խորհրդի անդամ Վիտալի Սլիզենն այս մասին. «Մենք չենք նկատում [կատարման] դեգրադացիան նույնիսկ բեռի ավելացման դեպքում, քանի որ մենք ընդլայնում և արդիականացնում ենք տվյալների կենտրոնների կարողությունները ժամանակին. Առանձին-առանձին, SLA-ում այս պարամետրերը (VM և պահեստավորման կատարում) արտացոլված չեն, քանի որ դրանց պահպանումը մեր հիմնական պարտականությունն է՝ անկախ հաճախորդի խնդրանքներից: Inoventica-ի մասնագետները մշտապես վերահսկում են վարձակալված ենթակառուցվածքի օբյեկտների բոլոր հիմնական պարամետրերը, ինչը թույլ է տալիս արագ տեղեկատվություն ստանալ հնարավոր խնդիրներև կանխատեսել դրանք ժամանակին:

Դեգրադացիայի բացակայության մասին խոսում է նաև մենեջեր Իգոր Դրոզդովը տեխնիկական աջակցություն Linxdatacenter-ի վաճառքի մասին. «Մեր ընկերությունը տրամադրում է երաշխավորված հաշվողական ռեսուրսներ օգտագործման համար: Դրանք պահվում են ամպի մեջ և աճում են, քանի որ հաճախորդների թիվը մեծանում է, ուստի վիրտուալ մեքենաների և պահեստավորման աշխատանքը մնում է հետևողականորեն բարձր մակարդակի վրա: Բացի այդ, մենք ժամանակին կատարում ենք սերվերի արդիականացում և կատարում ենք աշխատանքի մոնիտորինգ՝ օգտագործելով VMware մասնագիտացված արտադրանքները»:

Orange Business Services-ը նույնպես ծառայություններ մատուցողներից է, որը չի կարգավորում ստանդարտ SLA-ի կատարողականի պարամետրերը: Միևնույն ժամանակ, ինչպես նշում է Ռուսաստանում և ԱՊՀ-ում Orange Business Services-ի միասնական կապի և տեղեկատվական տեխնոլոգիաների արտադրանքի զարգացման բաժնի ղեկավար Դմիտրի Դորոդնիխը, «եթե հաճախորդը պահանջում է, որ որոշակի հաշվողական ռեսուրսներ երաշխավորված լինեն իր վիրտուալ համար. մեքենաներ, դիմում ենք ստանդարտ միջոցներժամանակակից վիրտուալացման հարթակներ, որոնք ռեսուրսների համար վիճաբանության դեպքում թույլ են տալիս վիրտուալ մեքենաները տեղափոխել այլ սերվերներ:

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

Կան նաև բազմաթիվ ընկերություններ, որոնք կարծում են, որ SLA-ներին կատարողական բնութագրեր ավելացնելն իմաստ ունի: Խցանման վիզը Վիրտուալացված ՏՏ միջավայրում շատ փորձագետներ հաշվի են առնում պահեստավորման արդյունավետությունը, այդ իսկ պատճառով վաճառողներից շատերը մեծ ուշադրություն են դարձնում պահեստավորման բնութագրերին, ինչպիսիք են մուտքային/ելքային գործողությունները վայրկյանում (IOPS):և սկավառակի մուտքի ժամանակը (latency):

Dataline-ը թվարկում է յուրաքանչյուր SLA-ում պահեստավորման և վիրտուալ մեքենաների կատարողականի ցուցանիշները (տես Աղյուսակ 4): Միևնույն ժամանակ, ինչպես նշում է այս ընկերության ծառայությունների զարգացման բաժնի ղեկավար Դմիտրի Տիշինը, «կախված հաճախորդի կողմից համակարգի լանդշաֆտին առաջադրված պահանջներից, չափումները կարող են փոխվել»: IOPS արժեքները չափվում են NetApp DFM մոնիտորինգի համակարգով, իսկ սկավառակի մուտքի ժամանակները չափվում են՝ կանոնավոր միջոցներՎիրտուալիզացիայի ծրագրակազմ (vCenter): Վիրտուալ մեքենայի հետ կապված խնդրի դեպքում հերթափոխը և վիրտուալացման թիմի ինժեներները ստանում են համապատասխան նախազգուշացում։ Բացի այդ, Dataline-ն ապահովում է տարբեր պարամետրերի մոնիտորինգ օպերացիոն համակարգի և դրանում աշխատող ծառայությունների մակարդակով։ Եթե ​​հաճախորդը օգտվում է ընկերության ՕՀ-ի և ծառայությունների կառավարման ծառայությունից, ապա նման մոնիտորինգը կատարվում է լռելյայն:

Վիրտուալ մեքենաների կատարողականի վատթարացումը կանխելու համար Dataline-ի մասնագետները կիրառում են մի շարք միջոցառումներ: Այսպիսով, կլաստերի համար օգտագործվում է բաշխված ռեսուրսների ժամանակացույց (DRS) մեխանիզմը, որը վերահսկում է ֆիզիկական սերվերների ծանրաբեռնվածությունը՝ ըստ հիմնական պարամետրերի. . Կլաստերը պահպանում է սերվերի ավելորդությունը, որպեսզի ամբողջ կլաստերի ծանրաբեռնվածությունը լինի ոչ ավելի, քան 70%: Սարքավորումների մատակարարների հետ կնքված սպասարկման պայմանագրերի շրջանակներում կլաստերների ռեսուրսային հզորությունները կարող են մեծացվել ըստ ժամանակացույցի։

Safedata-ն նաև կարգավորում է կատարողականի բնութագրերը, ինչպիսիք են IOPS-ը և MIPS-ը SLA-ում: «Մենք չենք կարող նվազեցնել կատարողականը SLA-ում նշված արժեքներից ցածր», - ասում է Safedata-ի վաճառքի բաժնի ղեկավար Անտոն Անտոնովը: «Եթե ծառայության դեգրադացիան տեղի է ունենում, երբ ֆիզիկական սերվերների ծանրաբեռնվածությունը մեծանում է, գործարկվում են լրացուցիչ պահեստային EXSi հոսթեր»:

SLA Cloud4Y-ում կարգավորվող պահեստային սկավառակի համակարգի կատարողական բնութագրերը ներկայացված են Աղյուսակ 5-ում: Ըստ Cloud4Y մարքեթինգի բաժնի ղեկավար Եվգենի Բեսսոնովի, երաշխավորվածի խախտման դեպքում. նախատեսվում է փոխհատուցում, որը սակարկվում է առանձին կամ վճարվում է ստանդարտ պայմաններով՝ ամսական ծախսի 1%-ը 1 ժամի համար։

«Մենք երաշխավորում ենք վիրտուալ մեքենաների աշխատանքը ներքևի սահմաններում՝ չսահմանափակելով այն վերևից», - ասում է Ռուսլան Զաեդինովը: «Այսպիսով, եթե սերվերը, որտեղ գտնվում է վիրտուալ մեքենան, ունենա երաշխավորվածից ավելի ազատ հաշվողական ռեսուրսներ, դրանք հասանելի կլինեն հաճախորդին»: Ինչ վերաբերում է պահեստավորման համակարգերին, ապա ներկայումս Croc-ի բոլոր հաճախորդներն օգտագործում են պահեստավորման համակարգերի հետ կապի ընդհանուր ալիք: Երկար ժամանակ դա խնդիրներ չէր առաջացնում, բայց այժմ, հաճախորդների աճող կարիքները բավարարելու համար, ընկերությունը տեղափոխում է ամպային պահեստավորում Fiber Channel-ից և SATA սկավառակներից դեպի ֆլեշ կրիչներ՝ վիրտուալ մեքենաներից Infiniband ցանցի միջոցով դրանց անմիջական հասանելիությամբ: Զուգահեռաբար ներդրվում է ծրագրային ապահովում՝ ապահովելու ամպի մեջ տվյալների պահպանման համակարգի երաշխավորված թողունակությունը: SLA-ում համապատասխան փոփոխությունները կկատարվեն այս աշնանը։

Հաճախորդի հետ համաձայնեցնելով՝ Servionika-ն յուրաքանչյուր նախագծի SLA-ում ամրագրում է ամպային հարթակի առանձին բաղադրիչների կատարողականի ցուցանիշները: Բացի այդ, համաձայնագրում նշվում են այդ ցուցանիշների չափման մեթոդները և չափումների հաճախականությունը։ Ցանկացած օպերատոր կարող է գրել «երաշխավորված 100,500 OPs 1 ԳԲ սկավառակի վրա», բայց ոչ բոլորն են կարողանում ապացուցել, որ այս չափանիշը բավարարված է: Մենք կողմ ենք ամպային հարթակի օպերատորի և դրա սպառողի միջև ամենաթափանցիկ հարաբերություններին»,- ընդգծում է Վիտալի Մզոկովը։ Վիրտուալ մեքենաների և պահեստավորման համակարգերի աշխատանքը որոշվում է Servionika SLA-ում IOPS և Latency ցուցանիշներով:

Ինչպես ասաց Մաքսիմ Զախարենկոն. Գլխավոր տնօրենԾառայությունների մատակարար «Oblakoteka», իրենց կնքած պայմանագրերում, կատարողականի առավելագույն ցուցանիշները կարգավորվում են այնպես, որ I/O թողունակության և ցանցի բեռը չի գերազանցում 80% -ը: Մոնիտորինգն իրականացվում է Microsoft SCOM համակարգի միջոցով: Նա նշում է, որ համար տարբեր համակարգերտարբեր ցուցանիշներ կարևոր են. վեբ կայքերի համար՝ արձագանքման ժամանակը, ՏՏ ենթակառուցվածքների հոսթինգի համար՝ պրոցեսորի պիկ բեռնվածության ցուցիչները, հիշողությունը, վիրտուալ ցանցը և այլն: Իր SLA-ում այս ընկերությունը ներառում է նաև երաշխավորված պահեստային պարամետրեր, մեթոդներ և տրամադրման պայմաններ և օգտագործողի տվյալների պահպանում («Ազնիվ բաժանում»):

END-TO-END SLA

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

Այնուամենայնիվ, ինչպես նշում է Վսևոլոդ Եգուպովը, հասանելիության մակարդակի նվազեցումը կամ պահպանումը կախված է կապի ուղիների կազմակերպման ձևից. եթե ալիքը վերապահված է, հասանելիությունը չի վատթարանում: Հակառակ դեպքում, վերջից մինչև վերջ SLA-ի հասանելիության մակարդակը կրճատվում է մինչև ալիքի հասանելիության մակարդակ: T-Systems RUS-ն ունի տվյալների կենտրոնների իր ցանցը, որոնք տեղակայված են ամբողջ աշխարհում: Ռուս հաճախորդները հիմնականում սպասարկվում են Գերմանիայում և Ավստրիայում տեղակայված տվյալների մշակման կենտրոններից: Ընկերությունը SLA պայմանագիր է կնքել Ռոստելեկոմի, Beeline-ի հետ, ինչպես նաև համագործակցում է հեռահաղորդակցության այլ օպերատորների հետ։

IaaS ծառայություններ մատուցողները, ովքեր նաև հեռահաղորդակցության օպերատորներ են, օգտվում են դրանից: Այսպիսով, լինելով հեռահաղորդակցության միջազգային օպերատոր՝ Orange Business Services-ը կիրառում է վերջից մինչև վերջ SLA-ներ, որոնք ծածկում են IaaS և հեռահաղորդակցության ծառայությունները: Նման SLA-ներում առկայության մակարդակը 99,95% է: Բայց, ինչպես բացատրում է Դմիտրի Դորոդնիխը, այս հատկանիշը կախված է հաճախորդի աշխարհագրական դիրքից, օրինակ՝ Կենտրոնական շրջանում այս մակարդակն ավելի բարձր է, քան Ուրալից այն կողմ և Սիբիրում: Վերջին մղոնը կարող է ունենալ իր SLA պարամետրերը: SLA-ի վերահսկման սխեմաներն ու մեխանիզմները կապի ուղիների վրա արդեն մշակվել են տասնամյակներ շարունակ, ուստի Orange Business Services-ի համար մոնիտորինգի հարցը խնդիր չէ:

Ինչպես նշում է Վիտալի Սլիզենը, Inoventica-ն ունի իր սեփական ողնաշարային կապի ուղիները և աշխարհագրորեն բաշխված տվյալների կենտրոնի ցանցը, ինչը հնարավորություն է տալիս իրականացնել գեոկլաստերներ: Սա թույլ է տալիս պահպանել տվյալները և ծառայության կատարողականը նույնիսկ տվյալների կենտրոններից մեկի ֆիզիկական ոչնչացման դեպքում: Նրա խոսքով, Inoventica-ն «միակ ընկերությունն է Ռուսական շուկա, որն ապահովում է ծառայությունների ամբողջական շղթա «DPC - ալիք - ծառայություն - հաճախորդ (AWP)» SLA-ի համաձայն, որը. նվազագույնըփաթեթների փոխանցման ուշացում (շրջագայության հետաձգում) 10 ms-ից պակաս և փաթեթի գրեթե զրոյական կորուստ: Ներկայումս Inoventica համալիր լուծումը հասանելի է Ռուսաստանի Դաշնության հինգ դաշնային շրջանների հաճախորդների համար:

IaaS ծառայություններ մատուցողները, որոնք օպերատոր չեն, ակտիվորեն համագործակցում են նրանց հետ: Այսպիսով, Servionika-ն ձևավորեց SLA՝ աշխատելու իր տվյալների կենտրոնը սպասարկող հեռահաղորդակցության օպերատորների հետ (ավելի քան 10 խոշոր հեռահաղորդակցական պրովայդերներ): Ընկերությունը հեռարձակում է այս SLA-ների պայմանները կապի ծառայություններից օգտվող հաճախորդների հետ պայմանագրերում: Իսկ SLA-ին համապատասխանության հսկողությունն իրականացվում է TrustInfo տվյալների կենտրոնի տեխնիկական ծառայությունների կողմից: «Մենք մեր պայմանագրերում նշում ենք SLA-ի նույն պարամետրերը, ինչ օպերատորներինը, այսինքն՝ պատասխանատվություն ենք կրում նրանց աշխատանքի որակի և կապի ուղիների անխափան տրամադրման համար», - նշում է Վիտալի Մզոկովը:

Հաճախորդներին կապի ուղիներ տրամադրելու համար Dataline-ն օգտագործում է հեռահաղորդակցության օպերատորների ծառայությունները ենթակապայմանագրային սխեմայով: Այս սխեմայով ընկերությունը վերահսկում է որակը օպերատորի հետ կնքած պայմանագրի շրջանակներում, մինչդեռ հաճախորդը նրանից ստանում է համապարփակ ծառայություն և գործ ունի միայն մեկ կոնտրագենտի հետ։ Մատչելիության մակարդակն է համալիր սպասարկումչի նվազում. Dataline-ը Մոսկվայում ունի տվյալների փոխանցման սեփական ցանց, որտեղ երաշխավորված են հետևյալ բնութագրերը՝ կորցրած փաթեթների տոկոսը ոչ ավելի, քան 0,2%, ցանցում միջին ուշացումը ոչ ավելի, քան 5 ms:

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

Այսպիսով, IaaS ծառայությունները Ռուսաստանում առաջարկվում են բավականին մեծ թվով ընկերությունների կողմից և միանգամայն հասկանալի և փաստաթղթավորված (SLA-ում) կանոններով: Արդյունաբերությունը դեռ պետք է համաձայնի, թե արդյոք SLA-ները պետք է անդրադառնան վիրտուալ ՏՏ ենթակառուցվածքների կատարողականի բնութագրերին, սակայն երաշխավորված հասանելիության դրույքաչափերը բավականին լավ տեսք ունեն նույնիսկ ամենախստապահանջ ձեռնարկությունների հաճախորդների համար: Բացի այդ, պրովայդերները հասկանում են հաճախորդների վերջնական SLA-ների կարիքը և աշխատում են դրանք բարելավելու ուղղությամբ:

Ալեքսանդր Բարսկով- Journal of Network Solutions / LAN ամսագրի առաջատար խմբագիր: Նրա հետ կարելի է կապ հաստատել հետևյալ հասցեով՝

, հեղինակ Ստյուարտ Ռենս(Ստյուարտ Ռենս):

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

ՏՏ անձնակազմը մեծ ջանքեր է գործադրում համոզվելու, որ նշված նպատակն իրագործվում է և հաճախորդներին հաշվետվություններում ցույց տալիս թվեր, որոնք հաստատում են դա: Սովորաբար ՏՏ ընկերությունները դրա համար տոկոսներ են օգտագործում, օրինակ՝ 99,999 տոկոս։ Ցավոք սրտի, դա հաճախ նշանակում է, որ նրանք կենտրոնանում են միայն տոկոսների վրա և կորցնում են իրենց իրական նպատակը՝ գնորդին արժեք մատուցել:

Տոկոսային հասանելիության խնդիր

Հասանելիությունը հաշվարկելու ամենապարզ եղանակներից մեկը հիմնված է երկու մասի վրա. Դուք համաձայնում եք այն ժամանակային ընդմիջումների մասին, որոնց ընթացքում ծառայությունը պետք է հասանելի լինի հաշվետու ժամանակաշրջան. Սա համաձայնեցված ծառայության ժամկետն է (ՀՍՏ): Դուք չափում եք պարապուրդի ժամանակը (DT) այս ժամանակահատվածում: Պայմանավորված ծառայության հասանելիության ժամանակից հանեք պարապուրդը և այն դարձրեք տոկոսի:

Եթե ​​ՀՍՏ-ը 100 ժամ է, իսկ պարապուրդը՝ 2 ժամ, ապա հասանելիությունը կլինի.

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

Ավելի վատ, հաճախորդի տեսանկյունից, դուք կարող եք տեղեկացնել, որ հասել եք համաձայնեցված նպատակներին՝ թողնելով հաճախորդին լիովին դժգոհ:

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

Մատչելիության թիրախների սահմանում

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

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

Հաղորդակցություն հաճախորդների հետ

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

Բայց կոնկրետ ի՞նչ պետք է ասեք ձեր հաճախորդներին: Զրույցի հիանալի մեկնարկային կետը կարող է լինել պարապուրդի ազդեցությունը: Ստորև ներկայացված են հինգ հարցեր, որոնք դուք պետք է տաք.

1. Ո՞ր բիզնես գործառույթներն են կարևոր և ունեն ամենաբարձր առաջնահերթությունը պարապուրդի պաշտպանության համար:
2. Ինչպե՞ս է պարապուրդն ազդում բիզնեսի վրա:
3. Ինչպե՞ս է անգործության հաճախականությունն ազդում բիզնեսի վրա:
4. Ի՞նչ ազդեցություն ունի պարապուրդը կազմակերպչական գործունեության վրա:
5. Ինչպե՞ս են կազմակերպության հաճախորդներն ընկալում այս հարկադիր պարապուրդները:

Բիզնեսի կարևոր գործառույթներ

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

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

Աղյուսակ 1 - Ծառայությունների նշանակությունը տոկոսային արտահայտությամբ

ՆԲԹվերը չպետք է գումարվեն մինչև 100%

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

Անգործության տևողությունը և հաճախականությունը

Դուք պետք է պարզեք, թե հաճախորդի բիզնեսի վրա ինչպես է ազդում պարապուրդի հաճախականությունը և տևողությունը:

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

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

Ահա մի օրինակ, թե ինչպես կարելի է չափել և փաստաթղթավորել հասանելիությունը՝ արտացոլելու այն փաստը, որ պարապուրդի ազդեցությունը տարբեր է.

Աղյուսակ 2 - Ուղևորության տևողությունը և առավելագույն հաճախականությունը

Եթե ​​դուք օգտագործում եք նման աղյուսակ՝ հաճախորդների հետ խափանումների հաճախականության և տևողության քննարկման ժամանակ, ապա այս թվերը, ամենայն հավանականությամբ, շատ ավելի օգտակար կլինեն, քան տոկոսային հասանելիությունը, և նրանք, անշուշտ, կունենան ավելի արժեքձեր հաճախորդների համար:

Դադարեցում և կատարում

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

Միջադեպերի մեծ մասը չի հանգեցնում ծառայության ամբողջական կորստի բոլոր օգտագործողների համար: Որոշ օգտատերեր կարող են չազդվել, մինչդեռ մյուսները լիովին անջատված են: Միգուցե կոտրված ԱՀ-ով միայն մեկ օգտվող կա, ով չի կարող մուտք գործել որևէ ծառայություն: Դուք նույնիսկ կարող եք դա դասակարգել որպես ծառայության 100% կորուստ, բայց դա ՏՏ-ի համար լիովին անհասանելի թիրախ կլինի և չի կարող լինել մատչելիության արդար չափանիշ:

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

Ազդեցությունը որոշելու եղանակներից մեկը կորցրած օգտատիրոջ րոպեների տոկոսը հաշվարկելն է: Անել դա:

• Հաշվարկել PotentialUserMinutes-ը: Սա ընդհանուրօգտվողներ, ովքեր աշխատում են մեկ միավորի ժամանակի համար: Օրինակ, եթե ունեք 10 աշխատակից, ովքեր աշխատում են 8 ժամ, ապա PotentialUserMinutes-ը 10 x 8 x 60 = 4800 է:
• Հաշվարկել UserOutageMinutes-ը: Սա անկարող օգտատերերի ընդհանուր թիվն է՝ բազմապատկած այն ժամանակի վրա, երբ նրանք չեն կարողացել աշխատել: Օրինակ, եթե միջադեպը թույլ չի տվել 5 աշխատակիցների աշխատել 10 րոպե, ապա UserOutageMinutes-ը 50 է:
• Հաշվեք տոկոսային հասանելիությունը՝ օգտագործելով շատ նման բանաձև, որը մենք տեսանք ավելի վաղ:

Վերոնշյալ օրինակում մենք ստացանք հետևյալ հասանելիությունը.

Դուք կարող եք օգտագործել նույն մեթոդաբանությունը զանգերի կենտրոնում կորցրած VoIP հասանելիության ազդեցությունը PotentialAgentPhoneMinutes-ի և LostAgentPhoneMinutes-ի առումով հաշվարկելու համար. Գործարքների կամ արտադրության հետ առնչվող հավելվածների համար դուք կարող եք օգտագործել նմանատիպ մոտեցում՝ միջադեպի բիզնես ազդեցությունը քանակականացնելու համար: Դուք համեմատում եք գործարքների քանակը, որոնք ակնկալվում էին առանց ժամանակի ընդմիջման, փաստացի գործարքների թվի հետ կամ ակնկալվող արտադրության քանակի հետ՝ փաստացի:

Հասանելիության չափում և հաշվետվություն

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

• Ի՞նչ եք չափելու։
• Ինչպե՞ս եք հավաքելու տվյալներ:
• Ինչպե՞ս կփաստաթղթավորեք և կհաղորդակցեք ձեր բացահայտումները:

Ինչ եք չափելես եմլինել

Շատ կարևոր է չափել և զեկուցել հասանելիությունը նույն տերմիններով, որոնք սահմանում են հաճախորդների հետ համաձայնեցված թիրախները և որոնք հիմնված են հաճախորդների հասանելիության իրական ըմբռնման վրա: Նպատակները պետք է իմաստալից լինեն նրա համար և ապահովեն, որ ՏՏ ջանքերը կենտրոնացած են նրա բիզնեսին աջակցելու վրա:

Սովորաբար, այս նպատակները ՏՏ-ի և հաճախորդի միջև սպասարկման մակարդակի համաձայնագրի (SLA) մաս են, բայց դուք պետք է զգույշ լինեք, որ SLA-ից ստացված թվերը չդառնան ձեր նպատակը: Ձեր իրական նպատակն է մատուցել ծառայություններ, որոնք կբավարարեն ձեր հաճախորդների սպասելիքները:

Ինչպես հավաքել տվյալներ

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

Տվյալների հավաքագրում տեխնիկական աջակցության մեջ

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

Այս մոտեցումը սովորաբար բավականին էժան է: Այնուամենայնիվ, դա կարող է հանգեցնել առկայության տվյալների ճշգրտության վերաբերյալ վեճերի:

Ենթակառուցվածքի և կիրառական հասանելիության չափում

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

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

Կեղծ հաճախորդներ

Որոշ ընկերություններ օգտագործում են կեղծ հաճախորդներ ցանցի հատուկ կետերից հայտնի գործարքներ ուղարկելու համար՝ հասանելիությունը ստուգելու համար:

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

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

Հավելվածի մշակում

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

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

Ինչպես փաստաթղթավորել և հաղորդել ձեր բացահայտումները

Հասանելիության տվյալները հավաքելուց հետո դուք պետք է մտածեք, թե ինչպես կարելի է արդյունքները հաղորդել ձեր հաճախորդներին:

Պլանավորեք պարապուրդի համար

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

Կան մի քանի եղանակներ՝ համոզվելու, որ պլանավորված պարապուրդը չի փչացնում վիճակագրությունը: Դրանցից մեկն այն է, որ ծրագրված չաշխատեն որոշակի ժամանակի համար, որը ներառված չէ առկայության հաշվարկում: Մյուսը պլանավորված պարապուրդի նշանակումն է: Օրինակ, որոշ կազմակերպություններ կարող են չհաշվառել ապագայի համար նախատեսված պարապուրդը մեկ ամիս առաջ:

Անկախ նրանից, թե ինչ եք որոշել անել, կարևոր է, որ ձեր SLA-ն հստակ սահմանի, թե ինչպես է հաշվառվելու պլանավորված պարապուրդը:

Հաշվետու ժամանակաշրջանի պայմանագիր

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

Օրինակ, հաշվի առեք ՏՏ ընկերություն, որը համաձայնել է 24x7 ծառայությանը և 99% հասանելիությանը: Ենթադրենք, որ կա ութժամյա ընդմիջում.

• եթե մենք շաբաթական կտրվածքով զեկուցում ենք առկայության մասին, ապա ՀՍՏ-ը (համաձայնեցված սպասարկման ժամանակը) կազմում է 24 x 7 ժամ = 168 ժամ:
• ամսական ՀՍՏ (24 x 365) / 12 = 730 ժամ
• եռամսյակային ՀՍՏ (24 x 365) / 4 = 2190 ժամ

Այս թվերը դնելով հասանելիության հավասարման մեջ՝ ստացվում է.

• Շաբաթական հասանելիություն = 100% x (168-8) / 168 = 95.2%:
• Ամսական հասանելիություն = 100% x (730 - 8) / 730 = 98,9%
• Եռամսյակային հասանելիություն = 100% x (2190-8) / 2190 = 99.6%

Սրանցից յուրաքանչյուրը ծառայության հասանելիության վավերական ցուցիչ է, բայց դրանցից միայն մեկն է ցույց տալիս, որ նպատակը կատարվել է:

կալանքի տակ

Գրեթե բոլոր ՏՏ ընկերությունները, որոնց ես աշխատել եմ, միջոցառումների և հաշվետվությունների հետ կապված իրենց ծառայությունների մատչելիության հետ: Իսկապես արդյունավետ ՏՏ բաժիններն աշխատում են իրենց հաճախորդների հետ՝ օպտիմալացնելու համար սեփական ներդրումներև ապահովել գերազանց հասանելիություն: Սակայն, ցավոք, շատ ՏՏ ընկերություններ կենտրոնանում են SLA-ի թվերի վրա և չեն կարողանում բավարարել իրենց հաճախորդների կարիքները, նույնիսկ եթե նրանք ի վերջո ցույց են տալիս հետևողական թվեր իրենց հաշվետվություններում:

Սա երկար հոդված է, ստորև ներկայացված են հիմնական կետերը, որոնք ընդգրկված են դրանում.

• Կարիք չկա հաճախորդին ասել, որ դուք մատուցել եք 98% հասանելիություն, եթե չեք հասկանում 2% պարապուրդի ազդեցությունը:
• Խոսեք ձեր հաճախորդների հետ և համոզվեք, որ հասկանում եք ցանկացած պարապուրդի ազդեցությունը նրանց և վերջնական հաճախորդների վրա
• Մտածեք ձեր հաճախորդների կարևոր բիզնես գործընթացները պաշտպանելու ուղիների մասին
• Գտեք եղանակներ՝ չափելու պարապուրդի հաճախականությունը և տևողությունը, ինչպես նաև աշխատանքի արդյունավետության վրա պարապուրդի ազդեցությունը, որոնք բավարարում են ձեր հաճախորդների կարիքները
• Համաձայնեք, փաստաթղթավորեք և նշեք հասանելիության չափորոշիչները այնպես, որ իմաստալից լինի ձեր հաճախորդների համար և օգնել պլանավորել
• Օգտագործեք համապատասխան գործիքներ՝ մատչելիությունը ճիշտ գնահատելու և դրա մասին հաղորդելու համար:

Էլ ի՞նչ կցանկանայիք ավելացնել իմ խորհուրդներին: Խնդրում ենք գրել մեկնաբանություններում։

«Հասանելիություն», «երեք ինը տասնորդական կետից հետո» - այս տերմինները հաճախ օգտագործվում են ՏՏ նոր լուծումները քննարկելիս: ՏՏ ճարտարապետները պատվիրատուին նախագիծ են առաջարկում նոր համակարգ, հատկապես ուշադրություն դարձնելով այն փաստին, որ այն ունի շատ բարձր հասանելիություն։ Պայմանագիրը կնքվել է, համակարգը կառուցվել է, համալիրի շահագործման վկայականները ստորագրվել են, և սկսվում է շահագործումը... Գործողության փուլում է, որ կարելի է ստուգել ստեղծված համակարգի «որակը», և հենց այդ ժամանակ կարող է սկսվել հիասթափությունը: Ի՞նչ է թաքնված կախարդական «ինըների» հետևում։ Ի՞նչ է իրականում խոստանում նախագծման փուլում։ Իսկ ո՞վ է պատասխանատու հասանելիության համար։

Մատչելիություն. թեմայի ներածություն

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

Հասանելիություն = (AST - DT)/AST×100 = Ծառայության կամ բաղադրիչի առկայություն (%)

որտեղ
AST (համաձայնեցված ծառայության ժամկետ)- ծառայության մատուցման համար նախատեսված ժամկետը.
DT (փաստացի պարապուրդը համաձայնեցված ծառայության ընթացքում)- փաստացի ժամանակը, երբ ծառայությունն անհասանելի է եղել դրա տրամադրման համաձայնեցված ժամանակահատվածում:

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

Բայց ո՞րն է լինելու ՀՍՏ-ը՝ ծառայության համաձայնեցված ժամանակը: Այս հարցին պատասխանելու համար անհրաժեշտ է հաշվի առնել, որ մարդիկ կարող են պատվերներ կատարել ոչ աշխատանքային ժամեր, և անպայման հաշվի առեք այն փաստը, որ Ռուսաստանն ունի 11 ժամային գոտի։ Ուստի ծառայությունը պետք է մատուցվի 24 ժամ, շաբաթը 7 օր։

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

Ելնելով վերոգրյալից՝ մենք ընտրում ենք ծառայության 4 ժամ անհասանելիություն չորս շաբաթը մեկ անգամ։ Այսինքն, ՀՍՏ = 4 շաբաթ, DT = 4 ժամ: Այնուհետև հասանելիությունը հետևյալն է.

Հասանելիություն = (24×7×4–4)/(24×7×4)×100% = 99,40%

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

Խնդրում ենք նկատի ունենալ, որ մենք որոշեցինք պահանջվող հասանելիությունը նախքան այն տրամադրող լուծման վրա աշխատելը, և ոչ հակառակը. մենք նախ ընտրեցինք լուծումը և սկսեցինք դիտարկել դրա հասանելիությունը: Տեխնիկական պայմանները առաջնային են, և պահանջվող հասանելիությունը դրանում ամրագրված պարամետրերից մեկն է։ Երբ համակարգը գործարկվում է, հասանելիությունը պետք է համապատասխանի պահանջվող արժեքին: Հետևաբար, մենք խորհուրդ ենք տալիս բիզնեսի հետ պայմանագրում (SLA -  Ծառայության մակարդակի պայմանագիր) մանրամասնորեն վերծանել, թե ինչ է նշանակում հասանելիության ցուցանիշը (մեր օրինակում. «Ծառայության անհասանելիությունից 4 ժամ մեկ (1) անգամ չորս (4) ընթացքում: ) շաբաթներ»), որպեսզի բոլոր կողմերը հստակ հասկանան, թե իրականում ինչ է թաքնված թվերի հետևում։

Մատչելիության երեք սյուներ

Առաջին բանը, որ պետք է հաշվի առնել լուծում ընտրելիս, այն է, թե ինչն է կազմում ՏՏ ծառայության հասանելիությունը: Գործողության ընթացքում մեծ հիասթափությունը պայմանավորված է նրանով, որ ծառայության հասանելիությունը, որը բիզնեսը ցանկանում է ստանալ, ուղղակիորեն կապված է սարքավորումների առկայության հետ: Այնուամենայնիվ, ՏՏ ծառայության հասանելիությունը երեք բաղադրիչների համակցություն է.
1) հուսալիություն - սովորաբար թարգմանվում է որպես հուսալիություն;
2) Maintainability - թարգմանվում է որպես «պահպանում»;
3) սպասարկելիություն՝ պահպանելիություն.
Եկեք քննենք այս կետերից յուրաքանչյուրը:

Հուսալիություն

Հուսալիությունը ենթակառուցվածքի կամ ապարատային և ծրագրային համալիրի առկայությունն է որպես ամբողջություն, ներառյալ հաղորդակցությունները: Օրինակ, առցանց խանութի համար մեզ անհրաժեշտ է վեբ սերվեր, հավելվածի սերվեր, DBMS, սկավառակի պահեստ և ինտերնետ հասանելիություն: Պարզության համար մենք կենթադրենք, որ «հավելված սերվեր» ծրագրաշարը ներառում է վեբ սերվեր և կտեղադրվի մեկ ապարատային սերվերի վրա, DBMS-ը՝ երկրորդում, իսկ սկավառակի պահեստը արտաքին սկավառակի զանգված է։

Մենք սկսում ենք ստեղծել՝ կառուցում ենք ենթակառուցվածքային նախագիծ։ Յուրաքանչյուր բաղադրիչի տակ մենք կգրենք դրա հասանելիության պարամետրերը։ Յուրաքանչյուր բաղադրիչի առկայությունը - այսուհետ մենք կօգտագործենք «հուսալիություն» տերմինը - պետք է ձեռք բերել բաղադրիչի մատակարարից (սարքավորումներ, ծրագրային ապահովումկամ ծառայություններ): Եթե ​​ինչ-ինչ պատճառներով դա հնարավոր չէ (օրինակ, ծրագրային ապահովման բաղադրիչների համար, հուսալիության արժեքը սովորաբար անհայտ է), ապա անհրաժեշտ արժեքը պետք է ինքնուրույն գնահատվի և նշանակվի: Յուրաքանչյուր բաղադրիչ իրենից ներկայացնում է խափանման մեկ կետ, ուստի հուսալիությունը հաշվարկելու համար դրանք հաջորդաբար միացված են աշխատանքային շղթայում (նկ. 1): Նկատի ունեցեք, որ սա ենթակառուցվածքի բաղադրիչները միացնելու սխեմա չէ, այլ միայն հուսալիության հաշվարկման սխեմա:

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

Հուսալիություն = (0,985×0,97×0,975×0,98×0,99×0,9999×0,99)×100%= 89,47%

Սա ակնհայտորեն բավարար չէ պահանջվող 99,40% արժեքի համեմատ: Այնուհետև մենք կփոխենք որոշումը՝ համակարգում կներառենք ինտերնետ հասանելիության ծառայությունների այլընտրանքային մատակարար (նկ. 2) և կհաշվարկենք դրա հուսալիությունը։ Քանի որ մենք զուգահեռ կապ ունենք ինտերնետ հասանելիության հետ կապված, ընդհանուր հուսալիությունը սահմանվում է հետևյալ կերպ.

Ընդհանուր հուսալիություն =

Հուսալիություն = ×100% = 91,72%

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

Օգտագործելով վերևում համառոտ քննարկված մեթոդները, կարող եք ընտրել անհրաժեշտ հասանելիությամբ լուծում:

Պահպանելիություն և սպասարկում

Եկեք անցնենք հասանելիության այլ բաղադրիչներին՝ պահպանման և սպասարկման հնարավորության: Նշում եմ, որ «պահպանում» և «վերանորոգում» թարգմանություններն անհաջող են, քանի որ նրանցից պարզ չէ, թե դա ինչ է նշանակում։ Ավելի լավ է օգտագործել ավելի հասկանալի թարգմանություններ՝ պահպանելիություն՝ կազմակերպության ներքին ՏՏ ծառայության գործունեությունը; սպասարկման հնարավորություն - արտաքին մատակարարների կողմից մատուցվող ծառայություններ:

Իրավիճակը պարզաբանելու համար դիտարկեք ծայրահեղ տարբերակներ։ Ո՞ր դեպքում է պահպանողականության իսպառ բացակայում (կազմակերպության ներքին ՏՏ ծառայության գործունեությունը): Դա տեղի է ունենում, երբ ընկերությունը աութսորսինգ է անում իր սեփական ՏՏ ծառայությունը: Այստեղ հասանելիությունը բաղկացած է միայն հուսալիությունից և արտաքին մատակարարների կողմից մատուցվող ծառայություններից:

Ո՞ր դեպքում է սպասարկման իսպառ բացակայում (արտաքին մատակարարների կողմից մատուցվող ծառայություններ): Դա տեղի է ունենում, օրինակ, ԱԴԾ-ում, որը գաղտնիության նկատառումներից ելնելով, ստիպված է բացառապես իր ՏՏ ստորաբաժանման կողմից իրականացնել բոլոր աշխատանքները՝ համակարգը աշխատունակ վիճակում պահելու համար, նույնիսկ պահեստամասերը գնում են ինքնուրույն և չեն մատակարարվում։ տեխնիկական աջակցության պայմանագրով: Այնուհետև հասանելիությունը բաղկացած է միայն համակարգի հուսալիությունից և կազմակերպության ներքին ՏՏ ծառայության գործունեությունից:

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

Մատչելիության բաղադրիչները շահարկելու ուղիներ

Հասկանալու համար, թե ինչպես կարելի է շահարկել հասանելիության բոլոր բաղադրիչները, եկեք դիտարկենք մեկ այլ գործնական օրինակ: Ընկերությունը, որն ունի տվյալների կենտրոններ Ռուսաստանի երկու քաղաքներում՝ Զելենոգրադում (Մոսկվայի արբանյակային քաղաք) և Իրկուտսկում, գնել է երկու միանման համակարգ: Հետևաբար, նրանց վստահելիությունը՝ վստահելիությունը, նույնն է նրանց համար։ Երկու ՏՏ համակարգերն էլ տրամադրվել են ապարատային և ծրագրային ապահովման տեխնիկական աջակցության նույն պայմանագրերով, ինչը նշանակում է, որ արտաքին մատակարարների կողմից մատուցվող ծառայությունները` սպասարկման հնարավորությունը, նույնպես նույնն էին: Այնուամենայնիվ, համակարգերի առկայությունը տարբեր էր: Եվ ընկերությունը սկսեց բողոքել մատակարարին Իրկուտսկում համակարգի վատ հասանելիության մասին՝ պնդելով, որ լուծումներից մեկը «թերի» է և պահանջելով, որ այն ենթարկվի աուդիտի:

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

Տարբերակ 1. Սարքավորումների խափանումները առաջացրել են հասանելիության կորուստ:Տվյալների կենտրոնների աշխարհագրական դիրքի պատճառով նույն ապարատային աջակցության պայմանագրերը իրականում կարող են տարբեր լինել: Օրինակ, Սպասարկման կենտրոնԱրտաքին մատակարարը գտնվում է Մոսկվայում, և տեխնիկական աջակցության պայմանագրում ասվում է, որ այն ուժի մեջ է միայն աշխատանքային օրերին, և ինժեները ժամանում է սարքավորումների տեղադրման վայր «առաջին հասանելի երկաթուղային կամ օդային թռիչքով»: Ակնհայտ է, որ Մոսկվայից մեկնող ինժեների համար այս արժեքը տարբեր կլինի Զելենոգրադի և Իրկուտսկի համար:

Այս դեպքում հասանելիության խնդրի հնարավոր լուծումները.

• փոխել ՏՏ համակարգի հուսալիությունը Իրկուտսկում, օրինակ, ավելացնել լրացուցիչ հանգույց կլաստերին.
• փոխել սպասարկման պարամետրը. ստեղծել պահեստ Իրկուտսկում, հնարավորություն ստանալ ընկերության ՏՏ մասնագետներին ինքնուրույն փոխել անսարք բաղադրիչները, եթե դա չի հակասում արտադրողի կանոններին:

Բացի այդ, իմաստ ունի ստուգել աշխատանքային պայմանները: Այս պայմանների բնորոշ խախտումների օրինակներ.

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

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

• բարձրացնել սպասունակությունը պահանջվող մակարդակի վրա. Իրկուտսկում ՏՏ անձնակազմին վերապատրաստել ՏՏ համակարգի մաս կազմող ծրագրային ապահովման և ապարատային արտադրանքի վերաբերյալ, կազմակերպել սեմինարներ Զելենոգրադից ՏՏ թիմի փորձը փոխանցելու համար, պատճենահանման գործընթացները և այլն;
• փոխհատուցել սպասարկման հնարավորությունը սպասարկման հնարավորության հաշվին. - գնեք առաջադեմ տեխնիկական աջակցության ծառայություններ, առաջադրանքների բարձրացման ծառայություններ և այլն:

Եթե ​​վերադառնանք առցանց խանութի մեր օրինակին, ապա հուսալիության, պահպանման և սպասարկման ո՞ր համադրությունը կլինի օպտիմալ: Այս հարցի պատասխանը կախված է յուրաքանչյուր կոնկրետ դեպքից: Օրինակ, դուք կարող եք խորհուրդ տալ հոսթինգ կատարել ամբողջ ենթակառուցվածքը (ՏՏ և տեխնիկական) ինքներդ ամբողջությամբ իրականացնելու փոխարեն: Ընդհանուր դեպքում մենք ունենք մատչելիության վերահսկման հետևյալ բնորոշ մեթոդները. 1. Փոխել հուսալիությունը (հուսալիություն):

• ՏՏ լուծումը փոխելով դեպի բարձր հասանելիություն (High Availability) - կլաստերների օգտագործում, «տաք» փոխարինման աջակցությամբ սարքավորումների օգտագործում, պոտենցիալ ձախողման կետերի կրկնվող կրկնօրինակում և այլն;
• ամբողջ ենթակառուցվածքի կամ դրա մի մասի վարձակալում արտաքին պրովայդերներից (հոսթինգ, կոլոկացիա):

2. Պահպանելիության փոփոխություն (ընկերության ՏՏ ծառայության գործունեության փոփոխություններ).

• կազմակերպության ներսում ՏՏ կառավարման սեփական լավագույն փորձի բաշխում.
• ՏՏ բաժնում գործընթացներ կազմակերպելու համար արտաքին խորհրդատուների հրավիրում.
• ՏՏ անձնակազմի վերապատրաստում.

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

ՏՏ ծառայությունների մատուցման վերաբերյալ բիզնեսի տեսակետների փոփոխությունը հանգեցնում է դրանց հասանելիության կառավարման գործընթացի իրականացման անհրաժեշտությանը:

ITIL-ի երրորդ տարբերակում ՏՏ ծառայությունների հասանելիության և շարունակականության կառավարման գործընթացները դիտարկվում են միասին (այսուհետ՝ գործընթաց): Այս համագործակցային գործընթացի ամենակարևոր հիմնական հասկացություններն են.

հասանելիություն- ՏՏ ծառայության կամ դրա բաղադրիչների կարողությունն իր գործառույթներն իրականացնելու որոշակի ժամանակահատվածում.

հուսալիություն- ՏՏ ծառայության կամ դրա բաղադրիչների կարողությունը՝ որոշակի գործառնական պայմաններով կատարել որոշակի գործառույթներ.

վերականգնելիություն- ՏՏ ծառայության կամ դրա բաղադրիչների կարողությունը վերականգնելու իր գործառնական բնութագրերը, որոնք մասամբ կամ ամբողջությամբ կորցրել են խափանման հետևանքով.

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

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

ՏՏ ծառայությունների պլանավորում և զարգացում՝ հաշվի առնելով բիզնեսի պահանջները մատչելիության մակարդակի համար.

ՏՏ ծառայությունների հասանելիության օպտիմալացում՝ ծախսարդյունավետ բարելավումների միջոցով.

ՏՏ ծառայությունների հասանելիության վրա ազդող միջադեպերի քանակի և տևողության կրճատում:

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

Պլանավորում

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

ՏՏ ծառայությունների մատչելիությունը նախագծելիս իրականացվում է ՏՏ ենթակառուցվածքի վերլուծություն՝ որոշելու առավել խոցելի բաղադրիչները, որոնք չունեն ավելորդություն, և որոնք ձախողման դեպքում կարող են բացասաբար ազդել տրամադրման վրա։ ՏՏ ծառայություններ. ITIL տերմինաբանության մեջ նման բաղադրիչները կոչվում են Single Point of Failure (SPOF), և դրանք որոշելու համար օգտագործվում է Component Failure Impact Analysis (CFIA) մեթոդը: Այս մեթոդը օգտագործվում է ՏՏ ծառայությունների վրա ՏՏ բաղադրիչների խափանումների ազդեցությունը գնահատելու և կանխատեսելու համար: CFIA-ի հիմնական նպատակներն են.

Բացահայտեք ձախողման կետերը, որոնք ազդում են հասանելիության վրա.

Բաղադրիչների ձախողման ազդեցության վերլուծություն բիզնեսի և օգտագործողների վրա;

Բաղադրիչների և անձնակազմի հարաբերությունների որոշում.

Բաղադրիչների վերականգնման ժամանակի որոշում;

Սահմանեք և փաստաթղթերի վերականգնման տարբերակները:

Ռիսկերի վերլուծության համար օգտագործվում է ռիսկի վերլուծության և կառավարման մեթոդը (CCTA Risk Analysis and Management Method, CRAMM), որտեղ վերլուծվում են ՏՏ բաղադրիչների հնարավոր սպառնալիքներն ու կախվածությունները, և գնահատվում է ոչ ստանդարտ իրավիճակների կամ արտակարգ իրավիճակների առաջացման հավանականությունը: .

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

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

Պլանավորման մեկ այլ ասպեկտը պարապուրդի որոշումն է: ՏՏ բոլոր բաղադրիչները պետք է ենթարկվեն պահպանման ռազմավարության: Կախված օգտագործվող ՏՏ-ից և որոշակի ՏՏ բաղադրիչի կողմից աջակցվող բիզնես գործառույթների կարևորությունից ու կարևորությունից, ծառայության հաճախականությունը և մակարդակը կարող են տարբեր լինել: Եթե ​​անհրաժեշտ է ծառայություն մատուցել 24x7 ռեժիմով, ապա անհրաժեշտ է գտնել օպտիմալ հավասարակշռություն ՏՏ բաղադրիչների սպասարկման պահանջների և սպասարկման ժամանակից առաջացած բիզնեսի կորուստների միջև: Հաստատված ծառայության ժամանակացույցերը պետք է փաստաթղթավորվեն Ծառայության մակարդակի պայմանագրերում (SLA):

ՏՏ ծառայությունների մատչելիության բարելավում

Ինչու՞ բարելավել հասանելիությունը: Պատճառները կարող են լինել բազմաթիվ. ՏՏ ծառայությունների որակի անհամապատասխանությունը SLA պահանջներին; ՏՏ ծառայությունների մատուցման անկայունություն. ՏՏ ծառայությունների մատչելիության նվազման միտումներ. վերականգնման անթույլատրելի երկար ժամանակներ; հարցումներ բիզնեսից՝ մատչելիության մակարդակը բարձրացնելու համար:

Մատչելիության բարելավումը պահանջում է ողջամիտ լրացուցիչ ֆինանսական ծախսերև ՏՏ ծառայությունների բարելավման հնարավորությունը որոշելու համար օգտագործվում են որոշակի մեթոդներ և տեխնոլոգիաներ, այդ թվում՝ անսարքության ծառի վերլուծությունը (Fault Tree Analysis, FTA) և համակարգի խափանումների վերլուծությունը (Systems Outage Analysis, SOA):

Սխալների ծառի վերլուծությունը բացահայտում է իրադարձությունների շղթան, որը հանգեցնում է ՏՏ բաղադրիչի կամ ՏՏ ծառայության ձախողմանը: Գրաֆիկորեն սխալների ծառը (տես նկարը) իրադարձությունների հաջորդականություն է, որը սկսվում է մեկնարկող իրադարձությամբ, որին հաջորդում են մեկ կամ մի քանի ֆունկցիոնալ իրադարձություններ և ավարտվում վերջնական վիճակով: Կախված իրադարձություններից, հաջորդականությունները կարող են տրամաբանորեն ճյուղավորվել:

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

ՏՏ ծառայությունների մատուցման ձախողումների հիմնական պատճառների բացահայտում.

ՏՏ ծառայությունների աջակցության արդյունավետության որոշում;

Հաշվետվությունների պատրաստում;

ընդունված առաջարկությունների իրականացման ծրագրի նախաձեռնում.

Համակարգի պարապուրդի վերլուծության միջոցով ձեռք բերված հասանելիության բարելավումների վերլուծություն:

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

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

ՏՏ ծառայությունների հասանելիության չափում

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

Ցուցանիշները, ինչպիսիք են ՏՏ ծառայությունների ընդհատումների հաճախականությունը, ընդհատման ընդհանուր տևողությունը, ՏՏ ծառայության ընդհատման ազդեցության տարածքը, կարող են հասկանալի լինել բիզնեսի համար:

Դերեր և պարտականություններ

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

Գործընթացի իրականացում

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

Ինչպես ցանկացած ծրագիր, գործընթացի իրականացումը սկսվում է նախագծային թիմերի ստեղծմամբ, ծրագրի կառավարման փաստաթղթերի մշակմամբ, ծրագրի պլանի մշակմամբ և այլն: «Նախանախագծային» աշխատանքի փուլում իրականացվում են մարքեթինգային գործունեություն՝ բիզնեսի ներկայացուցիչներին ITIL տեխնոլոգիաներին և առաջարկություններին ծանոթացնելու և բիզնեսի կողմից ՏՏ ծառայությունների հասանելիության կառավարման գործընթացի իրականացման անհրաժեշտությունը հիմնավորելու համար:

Գործընթացի իրականացման վերաբերյալ համաձայնեցնելուց և դրական պատասխան ստանալուց հետո որոշվում են գործընթացի առարկայական տարածքի նպատակներն ու սահմանները:

Ազդեցություն և խնդիրներ

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

Հնարավոր խնդիրները, որոնք կարող են բացասաբար ազդել գործընթացն իրականացնելու և գործարկելու որոշման վրա, սովորաբար կազմակերպչական բնույթ ունեն.

Իրավիճակի առկայություն, երբ յուրաքանչյուր ՏՏ մենեջեր պատասխանատու է իր պատասխանատվության տակ գտնվող ՏՏ համակարգերի կամ բաղադրիչների առկայության համար, մինչդեռ ՏՏ ծառայությունների ընդհանուր հասանելիությունը չի վերահսկվում և կարող է անբավարար լինել.

Գործընթացը չկատարելը, քանի որ ՏՏ ծառայությունների ներկայիս հասանելիությունը համարվում է ընդունելի.

Ենթադրություններ, որ եթե կան այլ իրականացված ITSM գործընթացներ, հասանելիության կառավարման գործընթացը կկատարվի ավտոմատ կերպով.

Դիմադրություն ՏՏ մենեջերների կողմից ՏՏ ենթակառուցվածքի կառավարման կենտրոնացմանը.

Գործընթացի ղեկավարի անբավարար լիազորությունները, ինչը հանգեցնում է պարտականությունների պատշաճ կատարման անկարողության:

Եվգենի Բուլիչև (Bulychev@i-teco.ru) - I-Teco Business Consulting-ի խորհրդատու (Մոսկվա):

Այս հոդվածը գրելու գաղափարը ծագել է խոշոր հաճախորդներից մեկի հետ խոսելուց հետո. գործընկերներից մեկը պատմել է իր ընկերության համար IaaS ամպային ծառայության մատակարար ընտրելու պատմությունը:

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

Վլադիմիր Կուրիլով, Օնլանտա ընկերություն.

Այսպիսով, խոսակցությունը հասավ հուսալիության ցուցանիշներին: Եվ դա իրականացվել է տվյալների կենտրոնների հասանելիության մակարդակների համեմատության շուրջ, որոնցում գտնվում էին ամպերը: Արագ պարզ դարձավ, որ միայն երկու թեկնածու ունեին տվյալների կենտրոններ՝ 99,98% հասանելիությամբ: Ընտրությունը կատարվել է արտասահմանյան ամպային ծառայություններ մատուցողի օգտին՝ գինը շահել է։ Գործընկերն ամեն ինչ պարզ բացատրեց. «Ի՞նչ իմաստ ունի ավելի շատ վճարել նույն հուսալիության ցուցանիշների համար»:

Հաշվի առնելով գոյությունը տարբեր տարբերակներ, այս հոդվածի շրջանակներում սահմանենք «Մատչելիություն» տերմինի մեկնաբանությունը։ Եկեք սահմանենք հասանելիությունը որպես համակարգի գործարկման ժամանակ որոշակի ժամանակային միջակայքում՝ արտահայտված որպես այս ընդմիջման տոկոս: Կամ դասական ձևով՝ «Օբյեկտի հատկությունը՝ տվյալ պայմաններում որոշակի ժամանակամիջոցում պահանջվող գործառույթ կատարելու համար»։ Ինչն, ընդհանուր առմամբ, ավելի մոտ է համակարգի «Պատրաստության» արդեն բավականին կայացած հայեցակարգին։

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

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

Այս հարցերի պատասխանները կփորձեմ ձևակերպել հետագա։

Կիրառման հուսալիություն - ինչից է այն բաղկացած ամպի մեջ

Հավելվածի ծառայության հուսալիություն

Եթե ​​փորձեք ձևակերպել հավելվածի հուսալիության սահմանումը, ապա այն կհնչի այսպես. «Հուսալիությունը հավելվածի հատկությունն է՝ ժամանակի ընթացքում պահպանել կատարողականությունը՝ դրանում ներկառուցված ամբողջ ֆունկցիոնալությամբ»:

Ի՞նչն է որոշում հավելվածի աշխատանքը և ինչպե՞ս է հավելվածի հուսալիությունը կապված տվյալների կենտրոնի առկայության հետ:

Հավելվածը հիմնված է ծրագրային հարթակի վրա, որն, իր հերթին, տեղակայված է ենթակառուցվածքային հարթակի վրա՝ օգտագործելով ինժեներական հարթակ, տես Նկ. Այս չորս շերտերը միասին ապահովում են «Application Service»:

Բրինձ. Դիմումի ծառայության մատչելիության հաշվարկման պարզեցված օրինակ

Ինչպես երևում է նկարից, մենք գործ ունենք հաջորդական տարրերի համակարգի հետ, որտեղ ցանկացած տարրի ձախողումը հանգեցնում է ամբողջ համակարգի ձախողմանը:

Նման համակարգի (As) առկայությունը սահմանվում է որպես բոլոր տարրերի առկայության ցուցանիշների արդյունք.

A i-ն յուրաքանչյուր սերիական միացված բաղադրիչի հասանելիությունն է:
A s = 0,99995 0,99995 0,993 0998 ≈ 0,99091 կամ 99,091

Ինչպես տեսնում եք, Application Service-ի առկայությունը կարևոր է տվյալների կենտրոնի ինժեներական հարթակի առկայությունից հեռու: Դուք կարող եք հասանելիության համարները վերածել համակարգի խափանումների: Պարզվում է, չնայած ինժեներական հարթակի թույլատրելի տարեկան դադարին՝ 1 ժամ։ 45 րոպե, դիմումի ծառայության տարեկան պարապուրդը կկազմի 86 ժամ 22 րոպե:

Համապատասխանաբար, տվյալների կենտրոնի բարձր հասանելիությունը չի վկայում այս տվյալների կենտրոնում գործող կիրառական ծառայությունների նույն բարձր հուսալիության մասին:

Ցանցի կիրառման հուսալիություն

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

Պարզվում է, որ ծրագրակազմ մշակողը կարողանում է ազդել մեկ հավելվածի հուսալիության (խափանումների, բեռների դիմադրություն) ապահովման վրա։ Օրինակ, ամպի մեջ հավելվածի հուսալիությունը կարող է զգալիորեն բարելավվել՝ օգտագործելով մասնագիտացված գրադարաններ, որոնք կենտրոնացած են կատարված հարցումների ուշացումների մշակման վրա: Ստանդարտ եղանակներով գրված հավելվածները համեմատաբար ավելի ցածր հուսալիության ցուցանիշներ կունենան:

Microsoft-ի կողմից մասնագիտացված գրադարանների օգտագործումն իրականացնելու տարբերակներից է Անցումային սխալների մշակման կիրառման բլոկը (տե՛ս http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx):

Ծրագրային հարթակի հուսալիությունը

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

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

Ենթակառուցվածքի հարթակի հուսալիությունը

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

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

Այնուամենայնիվ.

• Խնդրեք ենթակառուցվածքի պլատֆորմի ֆունկցիոնալ կառուցվածքի գծապատկեր՝ ձեր հատուկ Դիմումի ծառայությունը հյուրընկալելու համար: Այն պետք է ներառի.
  • ցանցային ենթակառուցվածք;
  • Պահպանման տարածքի ցանց;
  • հաշվողական ենթակառուցվածք:
• Խնդրեք այս սխեմայում նշել սարքավորումների ավելցուկային տեղերը: Անհրաժեշտ չէ նշել օգտագործվող սարքավորումների տեսակը:
• Խնդրեք մատչելիություն (կամ պատրաստակամություն) յուրաքանչյուր մակարդակի համար:
• Հաշվարկել հասանելիությունը որպես ենթակառուցվածքի հարթակի տարրերի առկայության արդյունք:

Այժմ դուք հնարավորություն ունեք հնարավորինս հուսալիորեն որոշել ձեր հավելվածի ծառայության առկայությունը: Ռուսաստանում համատեղ ձեռնարկությունների 90%-ը, մեր փորձից ելնելով, ունի 99%-ից ոչ ավելի ընդհանուր հասանելիություն։ Եվ սա տարեկան մինչև 87 ժամ պարապուրդի վտանգ է: Սրանք մատչելիության նորմալ ցուցանիշներ են, եթե դուք չունեք բիզնեսի համար կարևոր հավելվածներ, որոնց ժամային պարապուրդը ձեզ միլիոնավոր դոլարների վնաս է պատճառում: Եվ եթե մեկ ժամ տեւած անջատումը նման է աղետի ձեր բիզնեսի համար, ապա ձեզ համար մնում է մնացած 10%-ը՝ ՀՁ-ներ, որոնք ապահովում են ձեռնարկության մակարդակի ծառայություն՝ Application Service-ի 99,99% հասանելիությամբ: Ինչպես է դա ձեռք բերվում հաջորդ բաժնում:

Դիմումների սպասարկման բարձր հասանելիության լուծումներ

Արդյունքում, հաճախորդի համար կարևոր չէ, թե ինչպես է պահպանվում ինժեներական համակարգերի SLA-ն, նրա համար կարևոր է, թե որն է իր հավելվածների ծառայության հասանելիությունը, այսինքն. - Երաշխավորված հավելվածի վերականգնման ժամանակ:

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

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

Պատասխանն այն է, որ դուք կարող եք:

Օրինակ, ահա երկու մոտեցում, որոնք թույլ են տալիս դա անել.

• Աշխարհագրորեն բաշխված բարձր հասանելիության կլաստեր;
• Աշխարհագրորեն հեռավոր պահեստային տվյալների կենտրոնում մշակման վերականգնում (Աղետների վերականգնում):

Բրինձ. Աշխարհագրորեն բաշխված բարձր հասանելիության կլաստերի կառուցվածքային դիագրամ

Բրինձ. Աշխարհագրորեն հեռավոր պահեստային տվյալների կենտրոնում մշակման վերականգնման բլոկ դիագրամ

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

Երկու դեպքում էլ պետք է խոսել տվյալների կենտրոնների աշխարհագրական հեռավորության մասին՝ հնարավորինս խուսափելու փոխկապակցված ռեսուրսների հնարավորությունից։ Օրինակ՝ նույն ենթակայանների օգտագործումը, որոնք էներգիա են ապահովում տվյալների կենտրոններին։ Կարելի է հիշել 2008 թվականի մայիսին Մոսկվայի հարավ-արևելքում էլեկտրաէներգիայի անջատումը Նյու Յորքի Չագինսկայա ենթակայանում 2003 թվականին բռնկված հրդեհի պատճառով: Հետևաբար, պահեստային տվյալների կենտրոնը պետք է տեղակայված լինի հիմնականից հեռու:

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

Զուգահեռ համակարգի հիմնարար տարբերությունն այն է, որ հուսալիությունը մեծանում է համակարգի զուգահեռ տարրերի աճով: Զուգահեռ տարրերից բաղկացած համակարգի առկայությունը կարելի է հաշվարկել բանաձևով.

Որտեղ՝ A s - Ընդհանուր հասանելիություն, ամբողջ համակարգի առկայություն,
A i-ն զուգահեռ միացված յուրաքանչյուր բաղադրիչի առկայությունն է:

Օրինակ, եկեք հաշվարկենք երկու տվյալների կենտրոնների աշխարհագրորեն բաշխված բարձր հասանելիության կլաստերի համակարգը՝ յուրաքանչյուրը 99% հասանելիությամբ:

A s \u003d 1-(1-0,99) * (1-0,99) \u003d 0,9999 կամ 99,99

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

Որոշեք հավելվածի ծառայության առկայությունը աշխարհագրորեն հեռավոր պահուստային տվյալների կենտրոնում մշակումը վերականգնելու տարբերակում, 15 րոպե համաժամացման ընդմիջումով մեկ ձախողման դեպքում հաշվարկվում է հետևյալ կերպ. անհրաժեշտ է պահանջել հավելվածի ծառայության վերականգնման ժամանակը: երաշխավորված է SP-ի կողմից; այնուհետև մենք հաշվարկում ենք տարեկան միջակայքի տոկոսը, և արդյունքը հանում ենք միասնությունից: Մենք հասանելիություն ենք ստանում առաջին ձախողումից հետո: Օրինակ, 15 րոպե համաժամացման ընդմիջում ունեցող համակարգի համար.

Ժամերի ընդհանուր թիվը մեկ տարվա ընթացքում 365*24=8760
Երաշխավորված պարապուրդ = Առավելագույն պարապուրդ
15 րոպե կամ 0,25 ժամ, որը տարեկան ժամանակի ≈ 0,003-ն է

Նրանք. յուրաքանչյուր ձախողումը կունենա 0,003% կշիռ: Այսպիսով, համակարգը մինչև ձախողումը, համակարգը ունի 100% հասանելիություն, առաջին ձախողումից հետո՝ 99,997%, երկրորդ ձախողումից հետո՝ 99,994%: Եկեք նույնը հաշվարկենք ժամային համաժամացման ընդմիջում ունեցող համակարգի համար.

Վերականգնման երաշխավորված ժամանակ = Առավելագույն պարապուրդ = 1 ժամ, որը տարեկան ժամանակի ≈ 0.01 է

Յուրաքանչյուր ձախողում կունենա 0,01% կշիռ: Այսպիսով, համակարգը մինչև ձախողումը, համակարգը ունի 100% հասանելիություն, առաջին ձախողումից հետո՝ 99,99%, երկրորդ ձախողումից հետո՝ 99,98%: Ավելին, հավանականության տեսության հետևորդները կարող են գործնականում կիրառել առաջին, երկրորդ, երրորդ ձախողումների հավանականությունը գնահատելու հարցում: Արդյունքը ձեզ կհամոզի, որ այս գործոնի ազդեցությունն աննշան է ստացված արդյունքների վրա։ Սա թույլ է տալիս ինձ առաջարկել ամպի մեջ ձեր հավելվածների համար ծառայության հասանելիությունը գնահատելու առաջարկվող մեթոդաբանություն:

Ամփոփելով վերը նշվածը...

• Սկսեք գնահատելով այն հավելվածի բիզնեսի կարևորությունը, որը նախատեսում եք տեղադրել ամպի մեջ: Գնահատեք կիրառման ժամանակի արժեքը: Որքա՞ն կարժենա ձեզ դիմումի ծառայության բացակայությունը:
• Այստեղից գնահատեք պարապուրդի թույլատրելի արժեքը մեկ օրում, տարեկան: Հաշվարկեք հավելվածի ծառայության կարևոր հասանելիությունը:
• Համեմատեք հնարավոր պարապուրդի ծախսերը SP գների հետ, որոնք առաջարկում են մատչելի մատչելիություն ձեր հավելվածների համար:
• Համատեղ ձեռնարկություն ընտրելիս նախապատվությունը տվեք նրանց, ովքեր կարող են ապահովել ոչ միայն հասանելիության ներկայիս մակարդակը, այլ նաև ապահովել բարելավված հասանելիություն՝ որպես լրացուցիչ ծառայություն/ծառայություն: Հատկապես, եթե ձեր բիզնեսը աճում և զարգանում է:
• Եվ մնա գործնական: Վերցրեք այն, ինչ նրանք տալիս են ձեզ զգալու համար = փորձեք: Տեսությունն առանց պրակտիկայի այնքան էլ օգտակար չէ բիզնեսի համար։