A është e mundur? Patjetër, migrimi i sistemeve SAP është një proces i ndërlikuar dhe i gjatë, për suksesin e të cilit është e rëndësishme puna e mirë e të gjithë pjesëmarrësve. Dhe nëse migrimi bëhet brenda një kohe të shkurtuar, detyra komplikohet shumëfish. Nuk janë të gjithë të gatshëm për këtë. Mund të kenë disa arsye. Për shembull, procesi vetë është i gjatë dhe organizativisht i ndërlikuar. Përveç kësaj, ka rrezik nga pezullimet e paplanifikuara të sistemeve. Ose klientët nuk janë të sigurt se, pas një operacioni të tillë, do të fitojnë përfitime që janë të barabarta me përpjekjet e shpenzuara. Megjithatë, ka përjashtime.
Nën këtë lidhje, do të flasim për vështirësitë me të cilat përballen klientët gjatë migrimit dhe mbështetjes së sistemeve SAP, do të diskutojmë pse stereotipet 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 në vetëm pak më shumë se tre muaj.
SAP-hosting
Në pesë vitet e fundit, ishte e vështirë të imagjinohej se klientët do të fillonin masivisht përdorimin e resurseve të hostingut për aplikacionet SAP. Në shumicën e rasteve, ato implementoheshin on-premise. Megjithatë, me zhvillimin e modeleve të outsourcing dhe tregut të shërbimeve në cloud, perceptimi i porositësve filloi të ndryshonte. Cilat janë argumentet që ndikojnë në zgjedhjen e cloud për SAP?
- PĂ«r fillestarĂ«t qĂ« sapo kanĂ« planifikuar implementimin e SAP, infrastruktura cloud Ă«shtĂ« praktikisht zgjedhja standarde â shkallĂ«zimi i resurseve sipas nevojave aktuale tĂ« sistemit dhe mos dĂ«shira pĂ«r tĂ« shpĂ«rndarĂ« burimet nĂ« zhvillimin e kompetencave qĂ« nuk janĂ« kryesore.
- Në kompanitë me një peizazh të madh sistemor, me ndihmën e hostingut të sistemeve SAP, CIO-të arrijnë në një nivel tjetër të menaxhimit të rrezikut, pasi partneri është përgjegjës për SLA-në.
- Argumenti i tretë më i zakonshëm ë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 â njoftimi nga ofruesi pĂ«r ndalimin e mbĂ«shtetjes pĂ«r sistemet e vjetra nĂ« vitin 2027. Kjo do tĂ« thotĂ« kalimi i DB nĂ« HANA, qĂ« sjell shpenzime pĂ«r modernizim dhe blerjen e kapaciteteve tĂ« reja tĂ« llogaritura.
Tregu i SAP-hosting në Rusi tani mund të konsiderohet mjaft i zhvilluar. Kjo ofron mundësi të mëdha për klientët që dëshirojnë të ndryshojnë platformat e tyre të hostingut. Megjithatë, këto projekte mund të shkaktojnë shqetësim te bizneset për shkak të komplexitetit të procedurës së migrimit. Kjo i detyron klientët të vendosin kërkesa të larta ndaj ofruesve të shërbimeve, të cilët duhet të kenë jo vetëm aftësi të përjashtueshme në hosting dhe mbështetje të sistemeve SAP, por edhe përvojë të suksesshme në fushën e migrimit.
Cilat janë vështirësitë e kalimit në SAP-hosting?
Ka shumĂ« lloje hosting-Ă«sh. MospĂ«rputhje me nivelin e shĂ«rbimit tĂ« deklaruar, shumĂ« 'po' dhe yje me kushte nĂ« tekst tĂ« vogĂ«l, si dhe kufizime tĂ« burimeve dhe mundĂ«sive. ofruesi i hostingut, mungesa e fleksibilitetit nĂ« çështjet e komunikimit me klientin, burokracia, kufizimet teknike, niveli i ulĂ«t i kompetencĂ«s sĂ« 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Ă« pĂ«rballen klientĂ«t gjatĂ« pĂ«rdorimit tĂ« sistemeve tĂ« tyre tĂ« biznesit nĂ« infrastrukturat e jashtme. Shpesh pĂ«r klientin, gjithçka kjo mbetet nĂ« hijet e njĂ« kontrate shumĂ«faqĂ«she dhe del nĂ« pah vetĂ«m gjatĂ« pĂ«rdorimit tĂ« shĂ«rbimeve.
Në një moment, për porositësin bëhet e qartë se niveli i shërbimit që po merr është larg pritshmërive të tij. Kjo bëhet një lloj katalizatori për kërkimin e zgjidhjeve për të korrigjuar situatën dhe në rast të dështimit, kur problemet akumulohen deri në një pikë kritike dhe bëhet shumë e dhimbshme, ata kalojnë në veprime aktive për të eksploruar alternativa në drejtim të ndryshimit të ofruesit të shërbimeve.
Pse e vonojnĂ« deri nĂ« fund? Arsyet janĂ« tĂ« thjeshta â procesi i transferimit tĂ« sistemeve pĂ«r klientĂ«t nuk Ă«shtĂ« gjithmonĂ« transparent dhe i kuptueshĂ«m. Klientit i Ă«shtĂ« e vĂ«shtirĂ« tĂ« vlerĂ«sojĂ« rreziqet reale tĂ« lidhura me procesin e migrimit. Mund tĂ« thuhet se migrimi pĂ«r klientĂ«t Ă«shtĂ« njĂ« lloj kuti e zezĂ«: e pabesueshme, pa informacion pĂ«r çmimin, kohĂ«n e ndalesĂ«s sĂ« sistemeve, rreziqet dhe si t'i menaxhojĂ« ato, dĂ«shpĂ«ruese dhe e frikshme. NdonjĂ«herĂ« nuk ia vlen rreziku, sepse nĂ«se diçka nuk shkon siç duhet, atĂ«herĂ« do tĂ« ketĂ« pasoja pĂ«r menaxhimin e lartĂ« dhe pĂ«r ekzekutorĂ«t.
SAP janë sisteme të nivelit korporativ, të ndërlikuara dhe, për ta thënë lehtësisht, jo të lira. Për implementimin, përshtatjen, dhe mbështetje janë investuar buxhete të konsiderueshme, dhe disponueshmëria dhe funksionaliteti i tyre janë thelbësore për jetën e kompanisë. Tani, imagjinoni pasojat e ndalimit të ndonjë prodhimi të madh. Këto janë humbje financiare që mund të matën me numra me shumë zero, si dhe rreziqe reputacioni dhe të tjera, po aq të rëndësishme.
Le të shqyrtojmë sfidat që mund të shfaqen në çdo hap të procesit për migrimin e sistemeve SAP të njërit prej klientëve tanë.
PĂ«rgatitja dhe projektimi
Migrimi është një formulë me shumë përbërës të ndryshëm. Një nga fazat më të rëndësishme është projektimi dhe përgatitja e infrastrukturës përkatëse (të re).
Na nevoitet të thellohemi në implementimin ekzistues të sistemeve, arkitekturën e tyre. Në infrastrukturën që synonim, disa vendime ekzistuese i kemi ritheksuar, në disa raste i kemi plotësuar dhe përmirësuar, dhe në disa të tjera i kemi riparuar, menduar dhe zgjedhur zgjidhje për të siguruar qëndrueshmërinë dhe disponueshmërinë, si dhe për të konsoliduar sa më shumë burimet.
Gjatë procesit të projektimit janë kryer shumë ushtrime të ndryshme, të cilat në përfundim 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ë).
ĂfarĂ« arritĂ«m nĂ« fund â njĂ« infrastrukturĂ« e projektuar individualisht e njĂ« cloud privat mbi bazĂ«n e qendrĂ«s sonĂ« tĂ« tĂ« dhĂ«nave:
- servera të dedikuar fizikë për SAP HANA;
- platforma e virtualizimit VMware për serverat e aplikacioneve dhe shërbimeve infrastrukturore;
- kanale të dyfishta komunikimi mes qendrave të të dhënave për L2; VPN;
- dy sisteme kryesore të ruajtjes për të ndarë produktivitetin nga 'gjithçka tjetër';
- SRK mbi Veritas Netbackup me server të veçantë, raft disku dhe bibliotekë kasetash.
Ja si e realizuam këtë nga pikëpamja teknike.
SAP
- Për përdorim efikas të depozitave për HANA produktive, përdorëm disqe të zakonshme pa replikimin e sistemit DB me mjetet SAP. Të gjitha këto i vendosëm në një klaster Active-Standby SUSE HAE mbi Pacemaker. Po, koha e rikuperimit është pak më e gjatë se me replikim, por fitojmë një kursim të hapësirës së ruajtjes në dyfish dhe si pasojë kursim të buxhetit të klientit.
- Në ambientet e paraprodsavës, hoqëm dorë nga klasteret HANA, por teknologjikisht e përsëritëm konfigurimin e prodhimit.
- Ambientet testuese dhe ato të zhvillimit i shpërndamë edhe në disa servera pa klastere në konfigurimin MCOS.
- Të gjitha serverët e aplikacioneve i virtualizuam dhe i vendosëm në VMware.
Rrjetet
- Fizikisht e ndamë konturin e rrjeteve të menaxhimit dhe rrjeteve produktive me grupe switch-esh, duke vendosur rrjetet produktive në drejtimin e Qendravë të të Dhënave të klientit.
- Përfshirëm numër të mjaftueshëm ndërfaqesh rrjetesh për të mos e përzier trafikun e madh.
- Për transferimin e të dhënave nga SHK bëmë fabrika klasike FC SAN.
Sistemi i Ruajtjes
- Ngarkesën produktive dhe paraproduktive të SAP e lanë në një sistem all-flash.
- Mjediset testuese të zhvilluesve dhe shërbimet infrastrukturore i vendosën në një sistem hibrid të veçantë.
SRK
- E realizuam mbi bazën e Veritas Netbackup.
- Shtuam pak disa skripte të integruar për të bërë kopje rezervë të konfigurimeve të MCOS.
- Kopjet operative i vendosëm në raftin e diskëve për t'u rikuperuar shpejt, ndërsa për ruajtjen afatgjatë përdorim kasetat.
Monitorimi
- Të gjitha pajisjet, OS dhe SAP i regjistruam nën Zabbix.
- Krijuam shumë panele të dobishme në Grafana.
- Kur ndodh një alert, Zabbix mund të krijojë një kërkesë në sistemin e menaxhimit të incidenteve, që te ne është realizuar në Jira. Po ashtu, informacioni përsëritet 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, ngritëm një grumbull serverësh DNS që sinkronizohet me serverët e porositësit.
- Krijuam një server të veçantë skedari për shkëmbimin e të dhënave.
- Për të ruajtur konfigurime të ndryshme, shtuam Gitlab.
- Për informacionin e ndryshëm Sensitive, përdorëm HashiCorp Vault.
Procesi i migrimit
Në përgjithësi, procesi i migrimit përbëhet nga hapat e mëposhtëm:
- përgatitja e gjithë dokumentacionit të nevojshëm të projektit;
- negocimi me ofruesin aktual - zgjidhja e çështjeve organizative;
- blerja, dorëzimi dhe instalimi i pajisjeve të reja për projektin;
- migroni testuese dhe rregullimi i procesit;
- transferimi i sistemeve, migrimi aktiv.
Në fund të tetorit 2019 nënshkruam kontratën, më pas dizajnuam arkitekturën dhe pasi u miratua nga klienti, porosituam pajisjet e nevojshme.
ĂfarĂ« duhet tĂ« kemi parasysh nĂ« radhĂ« tĂ« parĂ« - afatet e dorĂ«zimit tĂ« pajisjeve. NĂ« mesatare, dorĂ«zimi i harduerit tĂ« certifikuar pĂ«r SAP NAHA, qĂ« plotĂ«son kĂ«rkesat e prodhuesit tĂ« softuerit pĂ«r platformat harduerike, merr 10-12 javĂ«. Dhe duke marrĂ« parasysh sezonin (realizimi i projektit ra pikĂ«risht nĂ« fundvit) - ky afat mund tĂ« zgjatej edhe pĂ«r njĂ« muaj tjetĂ«r. Prandaj, ishte e nevojshme tĂ« pĂ«rshpejtohej procesi sa mĂ« shumĂ« qĂ« tĂ« ishte e mundur: punuam me distributorin-supplier, u dakordĂ«suam pĂ«r dorĂ«zim tĂ« pĂ«rshpejtuar me avion (nĂ« vend tĂ« rrugĂ«ve tokĂ«sore dhe detare).
Nëntori dhe dhjetori u shpenzuan për përgatitjen e migrimit dhe për të marrë një pjesë të pajisjeve. Përgatitjen e realizuam në një skenë testi në cloud-in tonë publik, ku punuam të gjitha hapat kryesorë dhe kapëm mundësitë për vështirësi e probleme:
- përgatitëm një plan të detajuar për bashkëpunimin e anëtarëve të ekipeve të projekteve me kohën minut për minutë;
- ndërtuam një skenë testi për DB-në dhe serverët e aplikacioneve pikërisht si në infrastrukturën që synonim;
- konfiguruam kanalet e nevojshme të komunikimit dhe shërbimet infrastrukturore për të verifikuar funksionimin e integrimeve;
- praktikuam skenarët e cutover;
- cloud-i gjithashtu na ndihmoi të formojmë modele të parakonfiguruara të makinave virtuale, të cilat më pas i importuam dhe i zbatuam në peizazhin e synuar.
Pak para festave të fundvitit, na erdhi partia e parë e pajisjeve. Kjo na lejoi të zbatojmë një pjesë të sistemeve në pajisje reale. Duke qenë se nuk erdhën të gjitha, lidhëm pajisje të përkohshme, për të cilat arritëm të bisedojmë me distributorët dhe furnizuesit. Pjesët e mbetura të infrastrukturës synuese i morëm në fazën përfundimtare.
Për të përfunduar në kohë, inxhinierët tanë u detyruan të flasin për pushimet e Krishtlindjeve dhe të fillojnë punën për përgatitjen e infrastrukturës së synuar më 2 janar, në kulmin e festave. Po, ndodh ndonjëherë kur ka një emergjencë dhe nuk ka mundësi të tjera. Në lojë ishin funksionalitetet e sistemeve, nga të cilat varet aktiviteti i ndërmarrjes.
Renditja e migrimit ishte si mĂ« poshtĂ«: nĂ« fillim â sistemet mĂ« pak kritike (peizazhi i zhvillimit, peizazhi i testimit), pastaj â sistemet prodhuese. Faza pĂ«rfundimtare e migrimit u zhvillua nĂ« fund tĂ« janarit - fillim tĂ« shkurtit.
Procesi i migrimit ishte planifikuar me saktësi deri në minutë. Ky është një plan cutover me një listë të të gjitha detyrave, kohës së realizimit dhe osebashëve përgjegjës. Të gjithë hapat ishin përgatitur tashmë në migrimin testues, prandaj, në migrimin e vërtetë, duhej thjesht të ndiqeshin planet dhe të koordinohej procesi.
Migrimi u krye sistematikisht në disa faza. Në çdo fazë ishin dy sisteme.
Rezultati i sprintit tre-mujor ishte një sistem plotësisht funksional në Qendrën e të Dhënave KROK. Në përgjithësi, është arritur një rezultat pozitiv falë bashkëpunimit, kontributit dhe përkushtimit maksimal nga të gjithë pjesëmarrësit në proces.
Roli i porositësit në projekt
Të komunikosh me ofruesin nga i cili largohej klienti ynë ishte e vështirë. E kuptueshme, ata ishin të fundit në listën e palëve të interesuara për përfundimin me sukses të projektit. Porositësi mori përsipër detyrat e eskalimit dhe menaxhimit të të gjitha çështjeve të komunikimit dhe e realizoi këtë me 100500%. Falë tij për këtë angazhim të çmuar në proces, rezultati i projektit mund të ishte krejt ndryshe.
Për shkak të formalizimit të proceseve te "ish" ofruesi, mbikëqyrja e infrastrukturës u bëjë nga specialistë që, në sensin e drejtpërdrejtë, ishin të largët nga problemet e klientëve të tyre në atë kohë. Për shembull, procesi i eksportit të të njëjtës DB mund të zgjaste nga një orë deri në pesë. Atëherë dukej se ishte një magji, një sekret që as nuk na u zbulua. Ndoshta inxhinierët e mbështetjes teknike, përmes punës, merreshin me meditimin, duke harruar se diku atje në Rusi ka afate, inxhinierë pa sallata për festa, duke qarë dhe vuajtur klienti...
PĂ«rmbledhja e projektit
Akordi përfundimtar i migrimit ishte kalimi i sistemeve në mbikëqyrje.
Tani ne ofrojmĂ« shĂ«rbimin e njĂ« dritareje pĂ«r kĂ«rkesat e klientĂ«ve dhe mbulojmĂ« tĂ« gjithĂ« volumin e detyrave pĂ«r mbikĂ«qyrjen e komponenteve tĂ« infrastrukturĂ«s dhe SAP basis sĂ« bashku me partnerin â itelligence. Klienti jeton nĂ« njĂ« cloud privat pĂ«r gjashtĂ« muaj. Ja statistika pĂ«r rastet e shĂ«rbimit gjatĂ« kĂ«saj periudhe:
- 90 incidente (20% të zgjidhura pa përfshirjen e klientit)
- Zgjidhur brenda SLA â 100%
- NdĂ«rprerje tĂ« paplanifikuara tĂ« sistemeve â 0
Nëse keni detyra që janë të ngjashme me ato që kishte klienti ynë dhe dëshironi të dini më shumë se si t'i zgjidhni, shkruani: ahaidukov@croc.ru
Burimi: habr.com
