Apo është e mundur? Natyrisht, migrimi i sistemeve SAP është një proces kompleks dhe i mundimshëm, suksesi i të cilit kërkon punën e mirëkoordinuar të të gjithë pjesëmarrësve. Dhe nëse migrimi kryhet brenda një kohe të shkurtër, detyra bëhet shumë më e ndërlikuar. Jo të gjithë vendosin ta bëjnë këtë. Mund të ketë disa arsye. Për shembull, vetë procesi është i gjatë dhe kompleks organizativ. Plus, ekziston rreziku i ndërprerjes së paplanifikuar të sistemit. Ose klientët nuk janë të sigurt se, pasi i janë nënshtruar një operacioni të tillë, do të marrin përfitime në përpjesëtim me përpjekjet e shpenzuara. Megjithatë, ka përjashtime.
Më poshtë, ne do të flasim për vështirësitë me të cilat përballen klientët në procesin e migrimit dhe mirëmbajtjes së sistemeve SAP, do të diskutojmë pse stereotipet nuk korrespondojnë gjithmonë me realitetin dhe do të ndajmë një rast studimor se si arritëm të migronim sistemet e një klienti në një infrastrukturë të re në pak më shumë se tre muaj.
Pritja e sistemeve SAP
Vetëm pesë vjet më parë, ishte e vështirë të imagjinohej që klientët do të fillonin masivisht të përdorin burimet e pritjes për aplikacionet SAP. Në shumicën e rasteve ato u zbatuan në premisë. Megjithatë, me zhvillimin e modeleve të outsourcing dhe tregun e shërbimeve cloud, botëkuptimi i klientëve filloi të ndryshojë. Cilat janë argumentet që ndikojnë në zgjedhjen në favor të cloud për SAP?
- Për fillestarët që sapo kanë planifikuar të zbatojnë SAP, infrastruktura cloud është pothuajse një zgjedhje standarde - shkallëzueshmëria e burimeve sipas nevojave aktuale të sistemit dhe hezitimi për të devijuar burimet në zhvillimin e kompetencave jo thelbësore.
- Në kompanitë me një peizazh të madh të sistemit, me ndihmën e sistemeve pritëse SAP, CIO-të arrijnë një nivel cilësisht të ndryshëm të menaxhimit të rrezikut, sepse Partneri është përgjegjës për SLA.
- Argumenti i tretë më i zakonshëm është kostoja e lartë e ndërtimit të infrastrukturës për të zbatuar skenarët e disponueshmërisë së lartë dhe DR.
- Factor 2027 – shitësi njoftoi fundin e mbështetjes për sistemet e vjetra në 2027. Kjo nënkupton transferimin e bazës së të dhënave në HANA, gjë që kërkon kosto për modernizimin dhe blerjen e fuqisë së re kompjuterike.
Tregu i pritjes SAP në Rusi tani mund të konsiderohet mjaft i pjekur. Dhe kjo ofron mundësi të mjaftueshme për klientët që duan të ndryshojnë platformat e tyre të pritjes. Megjithatë, projekte të tilla me të drejtë mund të shkaktojnë shqetësim tek bizneset për shkak të kompleksitetit të procedurës së migrimit. Kjo i detyron klientët të vendosin kërkesa në rritje për ofruesit e shërbimeve, të cilët duhet të kenë jo vetëm kompetenca të jashtëzakonshme në pritjen dhe mirëmbajtjen e sistemeve SAP, por edhe përvojë të suksesshme në fushën e migrimit.
Cilat janë vështirësitë e ndryshimit të hostimit të SAP?
Pritjat janë të ndryshme. Mospërputhje me nivelin e deklaruar të shërbimit, shumë "por" dhe yllza me rezervime në tekst të vogël, burime dhe aftësi të kufizuara të ofruesit të pritjes, mungesë fleksibiliteti në çështjet e komunikimit me klientin, burokracia, kufizimet teknike, kompetenca e ulët e mbështetjes teknike specialistë, si dhe shumë nuanca të tjera - këto janë Kjo është vetëm një pjesë e vogël e kurtheve që klientët mund të hasin kur operojnë sistemet e tyre të biznesit në infrastrukturat e jashtme. Shpesh, për klientin, e gjithë kjo mbetet në hije, në xhunglën e një kontrate me shumë faqe dhe shfaqet në procesin e përdorimit të shërbimeve.
Në një moment, klientit i bëhet e qartë se niveli i shërbimit që ai merr është larg pritshmërive të tij. Ky është një lloj katalizatori për gjetjen e zgjidhjeve për korrigjimin e situatës dhe, në rast dështimi, kur problemet grumbullohen në kufi dhe bëhet shumë e dhimbshme, ata kalojnë në veprime aktive për të zhvilluar opsione alternative në drejtim të ndryshimit të ofruesit të shërbimit. .
Pse presin deri në minutën e fundit? Arsyeja është e thjeshtë - procesi i migrimit të sistemeve për klientët nuk është gjithmonë transparent dhe i kuptueshëm. Është e vështirë për klientin të vlerësojë rreziqet aktuale që lidhen me procesin e migrimit. Mund të themi se migrimi për klientët është një lloj kutie e zezë: është e paqartë, çmimi, kohëzgjatja e sistemit, rreziqet dhe mënyrat për t'i zbutur ato, dhe në përgjithësi është i errët dhe i frikshëm. Është sikur, nëse nuk funksionon, atëherë kokat do të rrokullisen si në majë ashtu edhe tek interpretuesit.
SAP është një sistem i nivelit të ndërmarrjes, kompleks dhe, për ta thënë butë, jo i lirë. Buxhetet e duhura shpenzohen për zbatimin, modifikimin dhe mirëmbajtjen e tyre, dhe jeta e ndërmarrjes varet nga disponueshmëria dhe funksionimi korrekt i tyre. Tani imagjinoni pasojat e ndalimit të një prodhimi të madh. Këto janë humbje financiare, të cilat mund të llogariten në numra me një numër të madh zero, si dhe rreziqe të reputacionit dhe rreziqe të tjera po aq të rëndësishme.
Ne do të analizojmë vështirësitë që mund të lindin në çdo fazë në rastin e migrimit të sistemeve SAP nga një prej klientëve tanë.
Përgatitja dhe projektimi
Migrimi është një formulë me shumë pjesë të ndryshme. Dhe një nga më të rëndësishmet është faza e projektimit dhe përgatitjes së infrastrukturës së synuar (të re).
Ne duhej të zhyteshim në zbatimin ekzistues të sistemeve, arkitekturën e tyre. Në infrastrukturën e synuar, ne përsëritëm diku zgjidhjet ekzistuese, i plotësuam dhe i përmirësonim ato në disa pika, i rishikuam diku, menduam dhe zgjodhëm zgjidhje për të siguruar tolerancën dhe disponueshmërinë e gabimeve, si dhe konsoliduam të gjitha burimet sa më shumë që të ishte e mundur.
Gjatë procesit të projektimit, u kryen shumë ushtrime të ndryshme, të cilat në fund të fundit bënë të mundur përgatitjen sa më shumë të jetë e mundur për migrimin dhe marrjen parasysh të të gjitha llojeve të nuancave dhe grackave (më shumë për to më vonë).
Ajo me të cilën përfunduam është një infrastrukturë private cloud e krijuar në mënyrë individuale e bazuar në qendrën tonë të të dhënave:
- serverë fizikë të dedikuar për SAP HANA;
- Platforma e virtualizimit të VMware për serverat e aplikacioneve dhe shërbimet e infrastrukturës;
- kanale të dyfishta komunikimi ndërmjet qendrave të të dhënave për L2 VPN;
- dy sisteme kryesore të ruajtjes për ndarjen e produktit dhe "çdo gjë tjetër";
- SRC bazuar në Veritas Netbackup me një server të veçantë, raft disku dhe bibliotekë shiritash.
Dhe ja si e zbatuam të gjithë këtë nga pikëpamja teknike.
SAP
- Për të përdorur në mënyrë efektive hapësirën ruajtëse për HANA produktive, ne përdorëm disqe të përbashkëta pa përsëritje sistematike të bazës së të dhënave duke përdorur SAP. E gjithë kjo ishte e mbështjellë në një grup Active-Standby SUSE HAE bazuar në Pacemaker. Po, koha e rikuperimit është pak më e gjatë se me përsëritjen, por ne kursejmë hapësirën e ruajtjes përgjysmë dhe, si rezultat, kursejmë buxhetin e klientit.
- Në mjediset e para-prodhimit, grupet HANA u braktisën, por teknikisht konfigurimi i prodhimit u përsërit.
- Mjediset e testimit dhe zhvillimit u shpërndanë nëpër disa serverë të tjerë pa grupime në një konfigurim MCOS.
- Të gjithë serverët e aplikacioneve u virtualizuan dhe u mbajtën në VMware.
Сети
- Ne ndamë fizikisht konturet e rrjeteve të kontrollit dhe prodhimit me tufa çelësash, duke i kthyer ato produktive drejt qendrave të të dhënave të klientit.
- Ne instaluam një numër të mjaftueshëm ndërfaqesh rrjeti për të mos përzier flukse të mëdha trafiku.
- Për të transferuar të dhëna nga sistemet e ruajtjes, ne bëmë fabrikat klasike të FC SAN.
SHD
- Ngarkesa produktive dhe paraproduktive e SAP u la në grupin e të gjitha flasheve.
- Mjediset e testimit të zhvilluesve dhe shërbimet e infrastrukturës u vendosën në një grup të veçantë hibrid.
IBS
- Bërë duke përdorur Veritas Netbackup.
- Ne shtuam pak skriptet e integruara për të rezervuar konfigurimet MCOS.
- Ne vendosim kopje operative në një raft disku për rikuperim të shpejtë dhe përdorim kaseta për ruajtje afatgjatë.
Monitorimi
- I gjithë hardueri, OS dhe SAP u instaluan nën Zabbix.
- Ne kemi mbledhur shumë tabela të dobishme në Grafana.
- Kur ndodh një alarm, Zabbix mund të krijojë një kërkesë në sistemin e menaxhimit të incidentit; ne e kemi zbatuar atë në Jira. Informacioni kopjohet edhe në kanalin Telegram.
Telegram
Shëndeti i përgjithshëm i HANA
Statusi i serverit të aplikacionit SAP:
Shërbimet e infrastrukturës
- Për të shërbyer hapësirat e brendshme të emrave, u ngrit një grup serverësh DNS, i cili sinkronizohet me serverët e klientit.
- Ne krijuam një server të veçantë skedarësh për shkëmbimin e të dhënave.
- Për të ruajtur konfigurime të ndryshme, u shtua Gitlab.
- Për informacione të ndryshme të ndjeshme morëm HashiCorp Vault.
Procesi i migrimit
Në përgjithësi, procesi i migrimit përbëhet nga fazat e mëposhtme:
- përgatitja e të gjithë dokumentacionit të nevojshëm të projektit;
- negociatat me ofruesin aktual - zgjidhja e çështjeve organizative;
- blerja, dorëzimi dhe instalimi i pajisjeve të reja për projektin;
- testimi i migrimit dhe korrigjimi i procesit;
- transferimi i sistemeve, luftimi i migrimit.
Në fund të tetorit 2019 ne nënshkruam një kontratë, më pas projektuam arkitekturën dhe pasi ramë dakord me klientin, porositëm pajisjet e nevojshme.
Ajo që duhet t'i kushtoni vëmendje së pari është koha e dorëzimit të pajisjeve. Mesatarisht, dorëzimi i pajisjeve të certifikuara për SAP NAHA që plotëson kërkesat e prodhuesit të softuerit për platformat e harduerit zgjat 10-12 javë. Dhe duke marrë parasysh sezonalitetin (zbatimi i projektit ra pikërisht në Vitin e Ri), kjo periudhë mund të ishte rritur me një muaj tjetër. Prandaj, ishte e nevojshme të shpejtohej procesi sa më shumë që të ishte e mundur: ne punuam me shpërndarësin-furnizues dhe ramë dakord për dërgimin e përshpejtuar me avion (në vend të rrugëve tokësore dhe detare).
Nëntori dhe dhjetori u shpenzuan duke u përgatitur për migrimin dhe duke marrë disa nga pajisjet. Ne e kryem përgatitjen në një stol testimi në renë tonë publike, ku punuam të gjithë hapat kryesorë dhe kapëm vështirësitë dhe problemet e mundshme:
- përgatiti një plan të detajuar për ndërveprimin ndërmjet anëtarëve të ekipit të projektit me orare minutë pas minutë;
- ndërtoi një grup testimi për bazën e të dhënave dhe serverët e aplikacioneve në të njëjtën mënyrë si në infrastrukturën e synuar;
- konfiguroi kanalet e nevojshme të komunikimit dhe shërbimet e infrastrukturës për të testuar funksionimin e integrimeve;
- përpunuar skenarë të ndërprerjes;
- Reja gjithashtu na ndihmoi të krijonim shabllone të para-konfiguruar të makinës virtuale, të cilat më pas thjesht i importuam dhe vendosëm në peizazhin e synuar.
Pak para festave të Vitit të Ri, na mbërriti grupi i parë i pajisjeve. Kjo bëri të mundur vendosjen e disa sistemeve në pajisje reale. Meqenëse jo gjithçka mbërriti, lidhëm pajisjet zëvendësuese, furnizimin e të cilave arritëm të biem dakord me shitësin dhe shpërndarësit. Ne morëm mbetjet e infrastrukturës së synuar në fazën përfundimtare.
Për të përmbushur afatin, inxhinierët tanë duhej të sakrifikonin festat e Vitit të Ri dhe të fillonin punën për përgatitjen e infrastrukturës së synuar më 2 janar, në mes të festave. Po, kjo ndodh ndonjëherë kur është në zjarr dhe thjesht nuk ka mundësi të tjera. Në rrezik ishte performanca e sistemeve nga të cilat varet jeta e ndërmarrjes.
Rendi i përgjithshëm i migrimit dukej kështu: së pari, sistemet më pak kritike (peizazhi i zhvillimit, peizazhi testues), pastaj sistemet prodhuese. Faza përfundimtare e migrimit u zhvillua në fund të janarit dhe në fillim të shkurtit.
Procesi i migrimit ishte planifikuar deri në minutë. Ky është një plan prerës me një listë të të gjitha detyrave, kohën e përfundimit dhe personat përgjegjës. Të gjithë hapat ishin përpunuar tashmë në migrimin testues, kështu që në migrimin e drejtpërdrejtë ishte thjesht e nevojshme të ndiqni planin dhe të koordinoni procesin.
Migrimi u krye sistematikisht në disa faza. Ekzistojnë dy sisteme në secilën fazë.
Rezultati i një sprinti tre mujor ishte një sistem që është plotësisht funksional në qendrën e të dhënave CROC. Në përgjithësi u arrit një rezultat pozitiv me punën ekipore, kontributi dhe përkushtimi i të gjithë pjesëmarrësve në proces ishte maksimal.
Roli i klientit në projekt
Komunikimi me ofruesin që klienti ynë po largohej nuk ishte i lehtë. Kjo është e kuptueshme, ata ishin të fundit në listën e personave të interesuar për përfundimin me sukses të projektit. Klienti mori përsipër detyrën e përshkallëzimit dhe pedalimit të të gjitha çështjeve të komunikimit dhe e përballoi këtë 100500%. Falënderime të veçanta për këtë. Pa një pjesëmarrje të tillë të mundshme në proces, rezultati i projektit mund të kishte qenë krejtësisht i ndryshëm.
Për shkak të zyrtarizimit të proceseve nga ana e “ish-ofruesit”, mbështetja në infrastrukturë u krye nga specialistë që ishin fjalë për fjalë larg problemeve, në atë kohë ende klientë të tyre. Për shembull, procesi i eksportimit të së njëjtës bazë të dhënash mund të zgjasë nga një orë në pesë. Pastaj u duk se kjo ishte një lloj magjie, një sekret që nuk na u zbulua kurrë. Ndoshta inxhinierët e ndihmës teknike i janë dhënë ndërkoh meditimit, duke harruar se diku në Rusinë e largët ka afate, inxhinierë pa sallata të Vitit të Ri, klienti po qan dhe po vuan...
Rezultatet e projektit
Hapi i fundit i migrimit ishte transferimi i sistemeve për mirëmbajtje.
Tani ne ofrojmë një shërbim me një dritare të vetme për kërkesat e klientëve dhe mbulojmë të gjithë fushën e detyrave që lidhen me mbështetjen e komponentëve të infrastrukturës dhe bazës SAP së bashku me partnerin tonë - inteligjencën. Klienti ka gjashtë muaj që jeton në një re private. Këtu janë statistikat për rastet e shërbimit gjatë kësaj kohe:
- 90 incidente (20% të zgjidhura pa përfshirë klientin)
- Zgjidhet brenda SLA - 100%
- Mbylljet e paplanifikuara të sistemit - 0
Nëse keni probleme të ngjashme me ato të klientit tonë dhe dëshironi të mësoni më shumë se si t'i zgjidhni ato, shkruani në: [email mbrojtur]
Burimi: www.habr.com