Apo mund të bëhet? Sigurisht, migrimi i sistemeve SAP është një proces i ndërlikuar dhe i gjatë, për suksesin e të cilit është e rëndësishme që të gjithë pjesëtarët të punojnë së bashku. Dhe nëse migrimi kryhet brenda një periudhe të shkurtër kohe, detyra komplikohet shumë më tepër. Nuk të gjithë janë të gatshëm për këtë. Arsye mund të jenë disa. Për shembull, procesi vetë është i gjatë dhe organizativisht i ndërlikuar. Përveç kësaj, ka rrezikun e pezullimeve të paplanifikuara të sistemeve. Ose klientët nuk janë të sigurt se, pasi të përjetojnë një operacion të tillë, do të marrin përfitime që janë proporcionale me përpjekjet e shpenzuara. Sidoqoftë, ka edhe përjashtime.
Për më shumë, ne do të flasim mbi vështirësitë që hasin porositësit gjatë migrimit dhe mbështetjes së sistemeve SAP, do të diskutojmë se pse stereotipat nuk përputhen gjithmonë me realitetin, dhe do të ndajmë një rast se si arritëm të migrojmë sistemet e klientit në një infrastrukturë të re brenda pak më shumë se tre muajsh.
Hostimi i sistemeve SAP
Edhe pesë vite më parë ishte e vështirë të imagjinohej se klientët do të fillonin masivisht të përdorin resurset e hostingut për aplikacionet SAP. Në shumicën e rasteve, ato u implementuan on-premise. Megjithatë, me zhvillimin e modeleve të jashtëzbritjes dhe tregut të shërbimeve të cloud, mentaliteti i porositësve filloi të ndryshojë. Cilat janë argumentet që ndikojnë në zgjedhjen e cloud-it për SAP?
- PĂ«r fillestarĂ«t qĂ« sapo kanĂ« planifikuar implementimin e SAP, infrastruktura cloud Ă«shtĂ« praktikisht zgjedhja standarde â mundĂ«sia pĂ«r tĂ« shkallĂ«zuar resurset sipas nevojĂ«s aktuale tĂ« sistemit dhe dĂ«shira pĂ«r tĂ« mos e shqetĂ«suar burimet pĂ«r zhvillimin e kompetencave qĂ« nuk janĂ« thelbĂ«sore.
- Në kompanitë me një peizazh të madh sistemor, duke përdorur hostimin e sistemeve SAP, CIO-të arrijnë një nivel të ri të menaxhimit të rreziqeve, sepse për SLA-në është përgjegjës partneri.
- Faktori i tretë i argumenteve më të zakonshme është kostoja e lartë e ndërtimit të infrastrukturës për realizimin e skenarëve të disponueshmërisë së lartë dhe DR.
- Faktori 2027 â ndĂ«rprerja e mbĂ«shtetjes pĂ«r sistemet e vjetruara e shpallur nga producenti nĂ« vitin 2027. Kjo do tĂ« thotĂ« kalimin e DB-sĂ« nĂ« HANA, qĂ« do tĂ« pĂ«rfshijĂ« shpenzime pĂ«r modernizimin dhe blerjen e kapaciteteve tĂ« reja kompjuterike.
Tregu i hostimit të SAP-it në Rusi tani mund të konsiderohet mjaft i pjekur. Kjo ofron mundësi të gjera për klientët që dëshirojnë të ndryshojnë platformën e tyre të hostimit. Megjithatë, projekte të tilla mund të shkaktojnë shqetësime të arsyeshme për bizneset për shkak të kompleksitetit të procedurës së migrimit. Kjo e detyron klientin të kërkojë kërkesa më të larta nga ofruesit e shërbimeve, të cilët duhet të kenë jo vetëm kompetenca të jashtëzakonshme në fushën e hostimit dhe mbështetjes së sistemeve SAP, por edhe përvojë të suksesshme në migrim.
Cilat janë vështirësitë e ndryshimit të hostimit SAP?
Ka shumĂ« lloje hostimesh. MospĂ«rputhja me nivelin e deklaruar tĂ« shĂ«rbimit, njĂ« mori "po" dhe yjesh me kushte tĂ« vogla, kufizime nĂ« burime dhe mundĂ«si, ofruesi i hostimit, mungesa e fleksibilitetit nĂ« komunikimin me klientin, burokracia, kufizimet teknike, kompetenca e ulĂ«t e specialistĂ«ve tĂ« mbĂ«shtetjes teknike, si dhe shumĂ« nuanca tĂ« tjera â kĂ«to janĂ« vetĂ«m disa nga pengesat me tĂ« cilat mund tĂ« ndeshen klientĂ«t gjatĂ« operimit tĂ« sistemeve tĂ« tyre tĂ« biznesit nĂ« infrastruktura tĂ« jashtme. Shpesh pĂ«r klientin, tĂ« gjitha kĂ«to mbeten nĂ« hije, nĂ« labyrinth-in e njĂ« kontrate shumĂ«faqĂ«she, dhe dalin nĂ« pah vetĂ«m gjatĂ« procesit tĂ« shfrytĂ«zimit tĂ« shĂ«rbimeve.
Në një moment, për klientin bëhet e qartë se niveli i shërbimit që po merr është shumë larg pritshmërive të tij. Kjo është njëfarë katalizatori për kërkimin e zgjidhjeve për të rregulluar situatën dhe, në rastin e dështimit, kur problemet akumulohet deri në të fundit, ai kalon në veprime aktive për të eksploruar alternativa në drejtim të ndryshimit të ofruesit të shërbimit.
Pse presin deri nĂ« momentin e fundit? Arsyeja Ă«shtĂ« e thjeshtĂ« â procesi i transfertĂ«s sĂ« sistemeve pĂ«r klientĂ«t nuk Ă«shtĂ« gjithmonĂ« transparent dhe i kuptueshĂ«m. Klientit i vĂ«shtirĂ«sohet tĂ« vlerĂ«sojĂ« rreziqet reale tĂ« lidhura me procesin e migrimit. Mund tĂ« thuhet se migrimi pĂ«r klientĂ«t Ă«shtĂ« njĂ« kutĂ« e zezĂ«: nuk Ă«shtĂ« e qartĂ« çfarĂ« do tĂ« kushtojĂ«, koha e pezullimit tĂ« sistemeve, rreziqet dhe se si t'i minimizosh ato; dhe nĂ« tĂ« vĂ«rtetĂ« gjithçka duket e errĂ«t dhe frikshme. KĂ«tu Ă«shtĂ« si ndodh, nĂ«se nuk del, do tĂ« fluturojnĂ« kokat e drejtuesve dhe tĂ« ekzekutuesve.
SAP â janĂ« sisteme tĂ« nivelit korporativ, komplekse dhe nĂ« njĂ«farĂ« mĂ«nyre jo tĂ« lira. Implementimi, zhvillimi dhe mbĂ«shtetje e tyre kĂ«rkojnĂ« buxhete tĂ« konsiderueshme dhe funksionimi i saktĂ« i tyre Ă«shtĂ« kritik pĂ«r jetesĂ«n e ndĂ«rmarrjes. Tani imagjinoni pasojat e ndalimit tĂ« ndonjĂ« prodhimi tĂ« madh. KĂ«to janĂ« humbje financiare qĂ« mund tĂ« llogariten me numra me shumĂ« zero, si dhe rreziqe reputacioni dhe tĂ« tjera, po aq tĂ« rĂ«ndĂ«sishme.
Le të shqyrtojmë vështirësitë që mund të lindin në çdo fazë, duke iu referuar rastit të migrimit të sistemeve SAP për një nga klientët tanë.
PĂ«rgatitja dhe dizajni
Migrimi është një formulë me shumë komponentë të ndryshme. Një nga fazat më të rëndësishme është dizajni dhe përgatitja e infrastrukturës qëllimore (të re).
Na duhej të zhytëshim në realizimin ekzistues të sistemeve, arkitekturën e tyre. Në infrastrukturën qëllimore, ne herë pas here përsëritëm zgjidhjet ekzistuese, në disa raste i shtuam dhe i përmirësuam ato, dhe në disa vende i ripërpunuam, menduam dhe zgjodhëm zgjidhje për të siguruar qëndrueshmërinë dhe disponueshmërinë, si dhe maksimalisht konsoliduam të gjitha burimet.
Gjatë procesit të dizajnit janë kryer shumë ushtrime të ndryshme, të cilat në fund na lejuan të përgatitemi sa më mirë për migrimin dhe të marrim parasysh të gjitha nuancat dhe pengesat (për të cilat do flasim më vonë).
CfarĂ« arritĂ«m nĂ« pĂ«rfundim â njĂ« infrastrukturĂ« e projektuar individualisht e njĂ« cloud privat nĂ« bazĂ« tĂ« QendrĂ«s sonĂ« tĂ« TĂ« DhĂ«nave:
- serverë fizikë të dedikuar për SAP HANA;
- platforma e virtualizimit VMware për serverët e aplikacioneve dhe shërbimeve infrastrukturore;
- kanale të dyfishta komunikimi midis Qendrave të Të Dhënave për L2 VPN;
- dy sisteme të ruajtjes për ndarjen e prodhimit dhe 'gjithçkaje tjetër';
- SRK në bazë të Veritas Netbackup me një server të veçantë, raft disku dhe bibliotekë bandeshe.
Ja si e realizuam gjith këtë nga këndvështrimi teknik.
SAP
- Për përdorimin efikas të ruajtjeve për HANA produktive, përdorëm disqe të zakonshme pa replikim sistematik të DB përmes SAP. Të gjitha këto i ankoruam në një klaster Active-Standby SUSE HAE në bazë të Pacemaker. Po, koha e rikuperimit është pak më e gjatë se sa me replikim, por kështu kursen dyfish hapësirë në sistemin e ruajtjes dhe, si rezultat, buxhetin e klientit.
- Në mjediset e paraproductive është hequr dorë nga klasteret HANA, por teknikisht kemi përsëritur konfigurimin e produktit.
- Mjediset testuese dhe ato të zhvillimit janë shpërndarë në disa serverë pa klastere në konfigurimin MCOS.
- Të gjithë serverat e aplikacioneve janë virtualizuar dhe vendosur në VMware.
Rrjetet
- Kanë ndarë fizikisht konturet e rrjeteve të menaxhimit dhe rrjeteve produktive me grupe switch-esh, duke orientuar rrjetet produktive në drejtim të Qendrës së Të Dhënave të klientit.
- Kemi parashikuar një numër të mjaftueshëm të ndërfaqeve rrjetore për të shmangur përzierjen e flukseve të mëdha të trafikut.
- Për transfertën e të dhënave nga SAN, kemi krijuar fabrikat klasike FC SAN.
SCHED
- Ngarkesën produktive dhe paraproductive të SAP e kemi mbajtur në një masiv all-flash.
- Mjediset testuese të zhvilluesve dhe shërbimet infrastrukturore i kemi vendosur në një masiv hibrid të veçantë.
SRK
- Kemi bërë në bazë të Veritas Netbackup.
- Së shpejti kemi shkruar disa skenare të integruar për të kryer backup falë konfigurimeve MCOS.
- Kopjet operative i kemi vendosur në rafte diskësh për t'u rikuperuar shpejt, ndërsa për ruajtje afatgjatë përdorim kasetat.
Monitorimi
- Të gjithë harduerin, OS dhe SAP i kemi integruar në Zabbix.
- Kemi mbledhur shumë dashboard-e të dobishme në Grafana.
- Kur ndodh një alarëm, Zabbix di të krijojë një kërkesë në sistemin e menaxhimit të incidenteve, e cila te ne realizohet në Jira. Informacioni gjithashtu dublikohet në kanalin Telegram.
Telegram
Gjendja e përgjithshme HANA
Gjendja e serverit të aplikacioneve SAP:
Shërbimet infrastrukturore
- Për të mbajtur hapësirat e brendshme të emrave, kemi ngritur një klaster serverash DNS, i cili sinkronizohet me serverët e klientit.
- Kemi bërë një server të veçantë skedarësh për shkëmbimin e të dhënave.
- Për të ruajtur konfigurime të ndryshme, kemi shtuar Gitlab.
- Për informacione të ndryshme Sensitive, kemi marrë HashiCorp Vault.
Procesi i migrimit
Në përgjithësi, procesi i migrimit përbëhet nga këto etapa:
- preparimi i të gjithë dokumentacionit të nevojshëm të projektit;
- negociatat me ofruesin aktual â zgjidhja e çështjeve organizative;
- blerja, shpërndarja dhe instalimi i pajisjeve të reja për projektin;
- migrimi testues dhe rregullimi i procesit;
- transferimi i sistemeve, migrimi operativ.
Në fund të tetorit 2019, nënshkruam kontratën, më pas projektuam arkitekturën dhe, pas miratimit nga klienti, porositëm pajisjet e nevojshme.
NjĂ« nga gjĂ«rat mĂ« tĂ« rĂ«ndĂ«sishme pĂ«r t'u vĂ«nĂ« re janĂ« afatet e dorĂ«zimit tĂ« pajisjeve. NĂ« mesatare, dorĂ«zimi i harduerit tĂ« certifikuar pĂ«r SAP NAHA, qĂ« pĂ«rputhet me kĂ«rkesat e prodhuesit tĂ« softuerit pĂ«r platforma harduerike, zgjat 10-12 javĂ«. NdĂ«rsa duke marrĂ« parasysh sezonin (realizimi i projektit pĂ«rkohej saktĂ«sisht me Vitin e Ri) â ky afat mund tĂ« zgjatej edhe pĂ«r njĂ« muaj tjetĂ«r. Prandaj, ishte e nevojshme tĂ« maksimizohej shpejtĂ«sia e procesit: ne punuam me distribuesin-furnizues, duke u marrĂ« vesh pĂ«r dorĂ«zimin e shpejtĂ« me avion (nĂ« vend tĂ« rrugĂ«ve tokĂ«sore dhe detare).
Nëntori dhe dhjetori kaluan për të përfunduar përgatitjen për migrimin dhe për të marrë një pjesë të pajisjeve. Përgatitjen e realizuam në një stendë provuese në cloud-in tonë publik, ku përfunduam të gjithë hapat kryesorë dhe identifikuam mundësitë e vështirësive dhe problemeve:
- përgatitëm një plan të detajuar për bashkëpunimin e pjesëmarrësve të grupeve të projektit me orar minutë pas minute;
- ndërtuam një stendë provuese për bazën e të dhënave dhe serverët e aplikacioneve, ashtu si në infrastrukturën e synuar;
- konfiguruam kanalet e nevojshme të komunikimit dhe shërbimet infrastrukturore për të verifikuar funksionimin e integrimeve;
- përpunuam skenarët e cutover;
- cloud-i gjithashtu na ndihmoi të formulojmë shabllone me parametra të paracaktuar të makinave virtuale, të cilat më pas thjesht i importuam dhe i implementuam në peizazhin e synuar.
Pak para festave të Vitit të Ri, na erdhi partia e parë e pajisjeve. Kjo na mundësoi të implementonim një pjesë të sistemeve në harduerin real. Duke qenë se nuk erdhën të gjitha, ne lidhëm pajisje zëvendësuese, për të cilat arritëm të merrnim një marrëveshje me shitësin dhe distributorët. Të ardhurat e mbetura të infrastrukturës së synuar i morëm vetëm në fazën përfundimtare.
Për të arritur në afatin e parashikuar, inxhinierët tanë duhej të sakrifikonin pushimet e Vitit të Ri dhe të nisin punën përgatitore të infrastrukturës së synuar më 2 janar, pikërisht në kulmin e festimeve. Po, ndodh ndonjëherë, kur ka një urgjencë dhe nuk ka alternativa të tjera. Në lojë ishin funksionalitetet e sistemeve, nga të cilat varej jetesa e kompanisë.
Rendi i pĂ«rgjithshĂ«m i migrimit dukej kĂ«shtu: mĂ« sĂ« pari â sistemet mĂ« pak kritike (peizazhi i zhvillimit, peizazhi i_testimit), pastaj â sistemet prodhuese. Faza pĂ«rfundimtare e migrimit kaloi nĂ« fund tĂ« janarit-fillim tĂ« shkurtit.
Procesi i migrimit u përshkrua me precizitet deri në minutë. Ky është një plan cutover me një listë të të gjitha detyrave, kohës së realizimit dhe përgjegjësve. Të gjitha hapat tashmë ishin provuar në migrimin testues, prandaj në migrimin operativ ishte e nevojshme thjesht të ndiqej plani dhe të koordinohej procesi.
Migrimi u realizua sistematikisht në disa etapa. Në çdo etapë kishte dy sisteme.
Rezultati i sprintit tre mujor ishte një sistem, i cili funksionon plotësisht në Qendrën e Të Dhënave KROK. Në përgjithësi, rezultati pozitiv u arrit falë një pune të përbashkët, kontributi dhe përkushtimi i të gjithë pjesëmarrësve në proces ishte maksimal.
Roli i porositësit në projekt
Të komunikosh me ofruesin, nga i cili po largohej klienti ynë, nuk ishte e lehtë. E kuptueshme, ata ishin të fundit në listën e personave të interesuar për përfundimin e suksesshëm të projektit. Porositësi mori përsipër detyrat e eskalimit dhe menaxhimit të të gjitha çështjeve komunikative dhe e realizoi këtë me 100500%. Për këtë, një falënderim i veçantë. Pa një pjesëmarrje të tillë në proces, rezultati i projektit mund të kishte qenë krejtësisht ndryshe.
Për shkak të formalizimit të proceseve nga ana e ofruesit "të mëparshëm", mbështetje infrastrukturore po siguronin specialistë që, në një kuptim të drejtpërdrejtë, ishin të largët nga problemet e porositësit të atëhershëm. Për shembull, procesi i eksportimit të të njëjtës bazë të dhënash mund të zgjaste nga një orë deri në pesë. Atëherë dukej se kjo ishte një magji, sekret i cili nuk na u zbulua kurrë. Ndoshta inxhinierët e mbështetjes teknike mes të tjerash i ishin kushtuar meditimit, duke e harruar se diku në Rusi, afatet e fundit, inxhinierët pa sallata Vitit të Ri, qante dhe vuante porositësi...
PĂ«rfundimet e projektit
Akordi përfundimtar i migrimit ishte kalimi i sistemeve në mbështetje.
Tani ne ofrojmë një shërbim me një dritare për kërkesat e porositësit dhe mbulojmë të gjithë volumet e detyrave për mbështetje të komponentëve të infrastrukturës dhe SAP basis së bashku me partnerin - itelligence. Klienti ka jetuar në një cloud privat për gjashtë muaj. Ja statistika për rastet e shërbimit për këtë kohë:
- 90 incidente (20% zgjidhur pa angazhimin e porositësit)
- Zgjidhur brenda SLA - 100%
- Ndërprerje të pa-planifikuara të sistemeve - 0
Nëse keni detyra të ngjashme me ato të klientit tonë dhe dëshironi të dini më shumë se si t'i zgjidhni, shkruani: ahaidukov@croc.ru
Burimi: habr.com
