SAP հոսթինգի փոփոխման փորձ. ինչպես տեղափոխել համակարգեր՝ առանց դա չափազանց ցավոտ լինելու

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

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

SAP համակարգերի հոստինգ

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

• Սկսնակների համար, ովքեր նոր են ծրագրել SAP-ի ներդրումը, ամպային ենթակառուցվածքը գրեթե ստանդարտ ընտրություն է.
• Համակարգային մեծ լանդշաֆտ ունեցող ընկերություններում SAP համակարգերի հոսթինգի օգնությամբ CIO-ները հասնում են ռիսկերի կառավարման որակապես տարբեր մակարդակի, քանի որ. Գործընկերը պատասխանատու է SLA-ի համար:
• Երրորդ ամենատարածված փաստարկը ենթակառուցվածքների բարձր արժեքն է՝ բարձր հասանելիության և DR սցենարների իրականացման համար:
• Factor 2027 – վաճառողը հայտարարեց ժառանգական համակարգերի աջակցության ավարտի մասին 2027 թվականին: Սա նշանակում է տվյալների բազայի փոխանցում HANA-ին, ինչը ենթադրում է ծախսեր արդիականացման և նոր հաշվողական հզորության գնման համար:

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

Որո՞նք են SAP հոսթինգը փոխելու դժվարությունները:

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

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

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

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

Մենք կվերլուծենք այն դժվարությունները, որոնք կարող են առաջանալ յուրաքանչյուր փուլում մեր հաճախորդներից մեկից SAP համակարգերի արտագաղթի դեպքում:

Պատրաստում և ձևավորում

Միգրացիան շատ տարբեր մասերով բանաձև է: Իսկ ամենակարեւորներից մեկը թիրախային (նոր) ենթակառուցվածքի նախագծման ու պատրաստման փուլն է։

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

Նախագծման գործընթացում կատարվել են բազմաթիվ տարբեր վարժություններ, որոնք, ի վերջո, հնարավորություն են տվել հնարավորինս շատ պատրաստվել միգրացիային և հաշվի առնել բոլոր տեսակի նրբություններն ու թակարդները (դրանց մասին ավելի ուշ):

Այն, ինչով մենք ավարտեցինք, անհատական ​​նախագծված մասնավոր ամպային ենթակառուցվածք է, որը հիմնված է մեր տվյալների կենտրոնի վրա.

• հատուկ ֆիզիկական սերվերներ SAP HANA-ի համար;
• VMware վիրտուալացման հարթակ կիրառական սերվերների և ենթակառուցվածքային ծառայությունների համար;
• կրկնօրինակված կապի ալիքներ տվյալների կենտրոնների միջև L2 VPN-ի համար;
• երկու հիմնական պահեստավորման համակարգեր՝ արտադրանքը և «մնացած ամեն ինչ» բաժանելու համար.
• ՊԵԿ-ը հիմնված է Veritas Netbackup-ի վրա՝ առանձին սերվերով, սկավառակի դարակով և ժապավենի գրադարանով:

Եվ ահա թե ինչպես ենք մենք այս ամենը իրականացրել տեխնիկական տեսանկյունից.

SAP

• Արդյունավետ HANA-ի համար պահեստավորումն արդյունավետ օգտագործելու համար մենք օգտագործեցինք ընդհանուր սկավառակներ՝ առանց տվյալների բազայի համակարգային վերարտադրության SAP-ի միջոցով: Այս ամենը փաթաթված էր Active-Standby SUSE HAE կլաստերում, որը հիմնված է Pacemaker-ի վրա: Այո, վերականգնման ժամանակը մի փոքր ավելի երկար է, քան կրկնօրինակման դեպքում, բայց մենք կիսով չափ խնայում ենք պահեստային տարածքը և արդյունքում խնայում ենք հաճախորդի բյուջեն:
• Նախաարտադրական միջավայրերում HANA կլաստերները լքված էին, բայց տեխնիկապես արտադրական կոնֆիգուրացիան կրկնվեց:
• Փորձարկման և զարգացման միջավայրերը բաշխվել են ևս մի քանի սերվերների վրա՝ առանց կլաստերների MCOS կոնֆիգուրացիայի մեջ:
• Բոլոր հավելվածների սերվերները վիրտուալացվել և տեղակայվել են VMware-ում:

Сети

• Մենք ֆիզիկապես տարանջատեցինք կառավարման և արտադրական ցանցերի ուրվագծերը անջատիչների կույտերով՝ արտադրողականները շրջելով դեպի հաճախորդի տվյալների կենտրոններ:
• Մենք տեղադրեցինք բավարար թվով ցանցային միջերեսներ, որպեսզի չխառնվեն մեծ երթևեկության հոսքերը:
• Տվյալները պահեստավորման համակարգերից փոխանցելու համար մենք պատրաստեցինք դասական FC SAN գործարաններ:

SHD

• SAP-ի արտադրողական և նախաարտադրողական բեռը մնացել է ամբողջ ֆլեշ զանգվածի վրա:
• Մշակողների թեստային միջավայրերը և ենթակառուցվածքային ծառայությունները տեղադրվել են առանձին հիբրիդային զանգվածի վրա:

IBS

• Պատրաստված է Veritas Netbackup-ի միջոցով:
• Մենք մի փոքր ավելացրինք ներկառուցված սկրիպտներին՝ MCOS կոնֆիգուրացիաները կրկնօրինակելու համար:
• Մենք օպերատիվ պատճենները դնում ենք սկավառակի դարակում՝ արագ վերականգնման համար, իսկ երկարաժամկետ պահպանման համար օգտագործում ենք ժապավեններ:

Մոնիտորինգ

• Բոլոր սարքավորումները, ՕՀ-ն և SAP-ը տեղադրվել են Zabbix-ի տակ:
• Grafana-ում մենք հավաքել ենք շատ օգտակար վահանակներ:
• Երբ ահազանգ է լինում, Zabbix-ը կարող է հարցում ստեղծել միջադեպերի կառավարման համակարգում, մենք այն ներդրել ենք Jira-ում: Տեղեկությունը կրկնօրինակված է նաև Telegram ալիքում։

Telegram

ՀԱՆԱ-ի ընդհանուր առողջությունը

SAP հավելվածի սերվերի կարգավիճակը.

Ենթակառուցվածքային ծառայություններ

• Ներքին անվանատարածքները սպասարկելու համար ստեղծվել է DNS սերվերների կլաստեր, որը համաժամացվում է հաճախորդի սերվերների հետ:
• Մենք ստեղծել ենք առանձին ֆայլերի սերվեր տվյալների փոխանակման համար:
• Տարբեր կոնֆիգուրացիաներ պահելու համար ավելացվեց Gitlab-ը:
• Տարբեր զգայուն տեղեկությունների համար մենք վերցրեցինք HashiCorp Vault-ը:

Միգրացիոն գործընթաց

Ընդհանուր առմամբ, միգրացիոն գործընթացը բաղկացած է հետևյալ փուլերից.

• բոլոր անհրաժեշտ նախագծային փաստաթղթերի պատրաստում;
• բանակցություններ ընթացիկ մատակարարի հետ - կազմակերպչական հարցերի լուծում.
• Ծրագրի համար նոր սարքավորումների գնում, առաքում և տեղադրում.
• թեստային միգրացիա և գործընթացի վրիպազերծում;
• համակարգերի փոխանցում, մարտական ​​միգրացիա։

2019 թվականի հոկտեմբերի վերջին կնքեցինք պայմանագիր, ապա նախագծեցինք ճարտարապետությունը և պատվիրատուի հետ պայմանավորվելուց հետո պատվիրեցինք անհրաժեշտ սարքավորումները։

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

նոյեմբերն ու դեկտեմբերն անցել են միգրացիայի նախապատրաստման և տեխնիկայի մի մասի ստացման համար։ Մենք նախապատրաստությունն իրականացրեցինք մեր հանրային ամպի փորձարկման նստարանին, որտեղ աշխատեցինք բոլոր հիմնական քայլերով և հայտնաբերեցինք հնարավոր դժվարություններն ու խնդիրները.

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

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

Միգրացիայի ընդհանուր կարգն այսպիսի տեսք ուներ՝ սկզբում ամենաքիչ կարևոր համակարգերը (զարգացման լանդշաֆտ, փորձարկման լանդշաֆտ), հետո՝ արտադրողական համակարգեր: Միգրացիայի վերջնական փուլը տեղի ունեցավ հունվարի վերջին և փետրվարի սկզբին։

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

Միգրացիան իրականացվել է համակարգված մի քանի փուլով. Յուրաքանչյուր փուլում կա երկու համակարգ.

Եռամսյա սպրինտի արդյունքը համակարգ էր, որը լիովին գործում է CROC տվյալների կենտրոնում: Ընդհանուր առմամբ, թիմային աշխատանքով ձեռք է բերվել դրական արդյունք՝ գործընթացում բոլոր մասնակիցների ներդրումն ու նվիրումը առավելագույնն է եղել։

Հաճախորդի դերը նախագծում

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

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

Ծրագրի արդյունքները

Միգրացիայի վերջին քայլը սպասարկման համակարգերի փոխանցումն էր:

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

• 90 միջադեպ (20%-ը լուծվել է առանց հաճախորդին ներգրավելու)
• Լուծված է SLA-ի շրջանակներում – 100%
• Համակարգի չնախատեսված անջատումներ – 0

Եթե ​​ունեք խնդիրներ, որոնք նման են մեր հաճախորդի խնդիրներին, և ցանկանում եք ավելին իմանալ, թե ինչպես լուծել դրանք, գրեք. [էլեկտրոնային փոստով պաշտպանված]

Source: www.habr.com