Edo posible al da? Jakina, SAP sistemak migratzea prozesu konplexu eta neketsua da, eta horren arrakastak parte hartzaile guztien lana ongi koordinatua eskatzen du. Eta migrazioa denbora gutxian gauzatzen bada, zeregina askoz zaildu egiten da. Denek ez dute hau egitea erabakitzen. Hainbat arrazoi egon daitezke. Adibidez, prozesua bera luzea eta antolakuntza konplexua da. Gainera, sistema planifikatu gabe gelditzeko arriskua dago. Edo bezeroek ez dakite ziur, operazio hori egin ostean, egindako ahaleginaren neurriko onurak jasoko dituztela. Hala ere, badira salbuespenak.
Ebakiaren azpian, bezeroek SAP sistemak migratzeko eta mantentzeko prozesuan dituzten zailtasunei buruz hitz egingo dugu, estereotipoak zergatik ez diren beti errealitatearekin bat datozen eztabaidatuko dugu eta bezero baten sistemak migratzea nola lortu genuen aztertuko dugu. azpiegitura berriak hiru hilabete pasatxoan.
SAP sistemen hostinga
Duela bost urte besterik ez, zaila zen imajinatzea bezeroak masiboki SAP aplikazioetarako hosting baliabideak erabiltzen hasiko zirela. Kasu gehienetan lokalean ezarri ziren. Hala ere, outsourcing ereduen garapenarekin eta hodeiko zerbitzuen merkatuarekin, bezeroen mundu ikuskera aldatzen hasi zen. Zeintzuk dira SAPen hodeiaren aldeko hautua eragiten duten argudioak?
- SAP ezartzea aurreikusi berri duten hasiberrientzat, hodeiko azpiegitura ia aukera estandarra da: baliabideen eskalagarritasuna sistemaren egungo beharretara eta baliabideak oinarrizkoak ez diren gaitasunen garapenera desbideratzeko errezeloa.
- Sistema-paisaia handia duten enpresetan, SAP sistemak ostatzearen laguntzaz, CIO-ak arriskuen kudeaketa maila kualitatibo desberdin batera iristen dira, izan ere Bazkidea da SLAren arduraduna.
- Hirugarren argudio ohikoena erabilgarritasun handiko eta DR eszenatokiak ezartzeko azpiegitura eraikitzearen kostu handia da.
- 2027 faktorea - saltzaileak 2027an antzinako sistemen laguntzaren amaiera iragarri zuen. Horrek datu-basea HANAra transferitzea esan nahi du, eta horrek modernizazio eta konputazio potentzia berria erosteko kostuak dakartza.
Errusiako SAP hosting merkatua nahiko heldutzat jo daiteke. Eta horrek aukera zabala eskaintzen die hosting plataformak aldatu nahi dituzten bezeroei. Hala ere, horrelako proiektuek arrazoiz kezka sor dezakete enpresen artean, migrazio prozeduraren konplexutasuna dela eta. Horrek bezeroak zerbitzu hornitzaileei eskakizun handiagoak jartzera behartzen ditu, SAP sistemak ostatatzeko eta mantentzeko aparteko gaitasunak ez ezik, migrazioaren arloan esperientzia arrakastatsua ere izan behar baitute.
Zeintzuk dira SAP hostinga aldatzeko zailtasunak?
Hostingak desberdinak dira. Adierazitako zerbitzu-mailarekin koherentzia eza, "baina" asko eta izartxoak testu txikian erreserbak dituztenak, ostalaritza-hornitzailearen baliabide eta gaitasun mugatuak, malgutasun falta bezeroarekin komunikazio gaietan, burokrazia, muga teknikoak, laguntza teknikoaren gaitasun baxua. espezialistak, baita beste hainbat Γ±abardura ere - hauek dira Hau bezeroek beren negozio-sistemak azpikontratazio-azpiegituretan jarduten dutenean topa ditzaketen akatsen zati txiki bat besterik ez da. Askotan, bezeroarentzat, hori guztia itzalean geratzen da, orrialde anitzeko kontratu baten oihanean, eta zerbitzuak erabiltzeko prozesuan azaleratzen da.
Noizbait, bezeroari begi-bistakoa zaio jasotzen duen zerbitzu maila bere itxaropenetatik urrun dagoela. Egoera zuzentzeko irtenbideak bilatzeko katalizatzaile moduko bat da hau eta, porrotaren kasuan, arazoak mugaraino pilatzen direnean eta oso mingarria bihurtzen denean, ekintza aktiboetara pasatzen dira, zerbitzu hornitzailea aldatzeko aukera alternatiboak garatzeko. .
Zergatik itxaron dute azken unera arte? Arrazoia sinplea da: bezeroentzako sistemak migratzeko prozesua ez da beti gardena eta ulergarria. Zaila da bezeroarentzat migrazio-prozesuarekin lotutako benetako arriskuak ebaluatzea. Bezeroentzako migrazioa kutxa beltz moduko bat dela esan dezakegu: ez dago argi, prezioa, sistemaren geldialdi-denbora, arriskuak eta nola arintzeko, eta, oro har, iluna eta beldurgarria da. Antza da, funtzionatzen ez badu, buruak goian eta antzezleetan jaurtiko direla.
SAP enpresa mailako sistema bat da, konplexua eta, nolabait esateko, ez merkea. Aurrekontu duinak ezartzeko, aldatzeko eta mantentzeko gastatzen dira, eta enpresaren bizitza haien erabilgarritasunaren eta funtzionamendu zuzenaren araberakoa da. Orain imajinatu ekoizpen handi batzuk gelditzearen ondorioak. Finantza-galerak dira, zero kopuru handia duten zenbakietan kalkula daitezkeenak, baita ospe-arriskuak eta beste arrisku berdintsu batzuk ere.
Gure bezeroetako batetik SAP sistemak migratzearen kasuan etapa bakoitzean sor daitezkeen zailtasunak aztertuko ditugu.
Prestaketa eta diseinua
Migrazioa hainbat zati dituen formula da. Eta garrantzitsuenetako bat xede-azpiegitura (berria) diseinatzeko eta prestatzeko etapa da.
Lehendik zeuden sistemen inplementazioan, haien arkitekturan murgildu behar genuen. Xede-azpiegituretan, lehendik zeuden irtenbideak errepikatu genituen nonbait, une batzuetan osatu eta hobetu, nonbait berregin, akatsen tolerantzia eta erabilgarritasuna bermatzeko irtenbideak pentsatu eta hautatu ditugu, eta baliabide guztiak ahalik eta gehien finkatu ere egin ditugu.
Diseinu prozesuan hainbat ariketa egin ziren, azken finean, migraziorako ahalik eta gehien prestatzea eta era guztietako Γ±abardurak eta hutsuneak kontuan hartzea (geroago gehiago).
Bukatu genuena banaka diseinatutako hodei pribatuko azpiegitura bat da, gure datu-zentroan oinarrituta:
- SAP HANArako zerbitzari fisiko dedikatuak;
- VMware birtualizazio plataforma aplikazio zerbitzarietarako eta azpiegitura zerbitzuetarako;
- datu-zentroen arteko komunikazio kanal bikoiztuak L2 VPNrako;
- produktua eta βgainerako guztiaβ bereizteko bi biltegiratze sistema nagusi;
- Veritas Netbackup-en oinarritutako SRC zerbitzari, disko-apal eta zinta liburutegi bereizi batekin.
Eta hona hemen nola gauzatu genuen hori guztia ikuspuntu teknikotik.
SAP
- HANA produktiborako biltegiratzea modu eraginkorrean erabiltzeko, SAP erabiliz datu-baseen erreplikazio sistemikorik gabeko disko partekatuak erabili ditugu. Hori guztia Pacemaker-en oinarritutako SUSE HAE kluster aktibo-standby batean bilduta zegoen. Bai, berreskuratzeko denbora erreplikarekin baino pixka bat handiagoa da, baina biltegiratze tokia erdira aurrezten dugu eta, ondorioz, bezeroaren aurrekontua aurrezten dugu.
- Aurre-ekoizpeneko inguruneetan, HANA klusterrak alde batera utzi ziren, baina teknikoki ekoizpen-konfigurazioa errepikatu zen.
- MCOS konfigurazio batean klusterrik gabeko hainbat zerbitzari gehiagotan banatu ziren proba eta garapen inguruneak.
- Aplikazio-zerbitzari guztiak birtualizatu eta VMware-n ostatatuta zeuden.
Π‘Π΅ΡΠΈ
- Kontrol- eta ekoizpen-sareen ingerada fisikoki etengailu-pilekin bereizi genituen, produktiboak bezeroaren datu-zentroetara bideratuz.
- Sareko interfaze kopuru nahikoa instalatu dugu, trafiko-fluxu handiak ez nahasteko.
- Biltegiratze sistemetatik datuak transferitzeko, FC SAN fabrika klasikoak egin ditugu.
SHD
- SAP-en karga produktiboa eta aurreproduktiboa flash array osoan utzi zen.
- Garatzaileen proba-inguruneak eta azpiegitura-zerbitzuak array hibrido bereizi batean jarri ziren.
IBS
- Veritas Netbackup erabiliz egina.
- MCOS konfigurazioen babeskopiak egiteko integratutako scriptei pixka bat gehitu dugu.
- Kopia operatiboak disko-apalategi batean jartzen ditugu azkar berreskuratzeko, eta zintak erabiltzen ditugu epe luzerako biltegiratzeko.
jarraipenaren
- Hardware, OS eta SAP guztiak Zabbix-en instalatu ziren.
- Grafanan panel erabilgarri asko bildu ditugu.
- Alerta bat gertatzen denean, Zabbixek eskaera bat sor dezake gertakariak kudeatzeko sisteman; Jiran inplementatu dugu. Informazioa Telegram kanalean ere bikoiztuta dago.
Telegrama
HANAren osasun orokorra
SAP aplikazio-zerbitzariaren egoera:
Azpiegitura zerbitzuak
- Barneko izen-espazioei zerbitzua emateko, DNS zerbitzarien multzo bat sortu zen, bezeroaren zerbitzariekin sinkronizatuta dagoena.
- Fitxategi zerbitzari bereizi bat sortu dugu datuak trukatzeko.
- Hainbat konfigurazio gordetzeko, Gitlab gehitu zen.
- Hainbat informazio sentikorra lortzeko HashiCorp Vault hartu genuen.
Migrazio prozesua
Oro har, migrazio prozesuak fase hauek ditu:
- beharrezko proiektuaren dokumentazio guztia prestatzea;
- egungo hornitzailearekin negoziatzea - ββantolaketa-arazoak konpontzea;
- proiekturako ekipamendu berriak erostea, entregatzea eta instalatzea;
- probaren migrazioa eta prozesuen arazketa;
- sistemen transferentzia, migrazioari aurre egitea.
2019ko urriaren amaieran kontratu bat sinatu genuen, gero arkitektura diseinatu genuen, eta bezeroarekin adostu ondoren, beharrezko ekipamendua eskatu genuen.
Lehenik eta behin arreta jarri behar duzuna ekipamenduaren entrega-epea da. Batez beste, 10-12 aste irauten du hardware-plataformetarako software fabrikatzailearen eskakizunak betetzen dituen SAP NAHArako hardware ziurtatua. Eta denboraldikotasuna kontuan hartuta (proiektuaren ezarpena Urte Berrian erori zen zehazki), epe hori beste hilabetez handitu zitekeen. Horrenbestez, beharrezkoa zen prozesua ahalik eta gehien bizkortzea: banatzaile-hornitzailearekin lan egin eta hegazkinez bizkortzea adostu genuen (lehorreko eta itsasoko bideak egin beharrean).
Azaroa eta abendua migrazioa prestatzen eta ekipamendu batzuk jasotzen igaro ziren. Prestaketa proba-banku batean egin genuen gure hodei publikoan, eta bertan urrats nagusi guztiak landu genituen eta izan litezkeen zailtasunak eta arazoak atzeman genituen:
- proiektuko taldekideen arteko elkarrekintzarako plan zehatza prestatu zuen minutuz minutuko denborarekin;
- datu-baserako eta aplikazio-zerbitzarietarako proba-banku bat eraiki zuen, gutxi gorabehera xede-azpiegituran bezala;
- beharrezko komunikazio-kanalak eta azpiegitura-zerbitzuak konfiguratu ditu integrazioen funtzionamendua probatzeko;
- ebakitzeko eszenatokiak landu zituen;
- Hodeiak aurrez konfiguratutako makina birtualeko txantiloiak sortzen ere lagundu zigun, gero inportatu eta helburuko paisaian inplementatu besterik ez genuen egin.
Urte Berriko oporrak baino pixka bat lehenago, lehen ekipamendu sorta iritsi zitzaigun. Horri esker, sistema batzuk benetako hardwarean hedatzea posible izan zen. Dena iritsi ez zenez, ordezko ekipoak konektatu genituen, hornidura hornikuntza saltzailearekin eta banatzaileekin hitzartzea lortu genuen. Helburuko azpiegituren aztarnak jaso genituen azken fasean.
Epea betetzeko, gure ingeniariek Urte Berriko oporrak sakrifikatu behar izan zituzten eta helburuko azpiegitura prestatzeko lanak hasi zituzten urtarrilaren 2an, oporren erdian. Bai, hori batzuetan sutan dagoenean gertatzen da eta beste aukerarik ez dago. Enpresaren bizitzaren menpe dauden sistemen errendimendua zegoen jokoan.
Migrazioaren ordena orokorra honelakoa zen: lehenik eta behin, sistema kritikoenak (garapen-paisaia, proba-paisaia), gero sistema produktiboak. Migrazioaren azken fasea urtarrilaren amaieran eta otsailaren hasieran gertatu zen.
Migrazio prozesua minutura arte planifikatu zen. Hau ebakuntza-plan bat da, zeregin guztien zerrenda, burutzeko denbora eta pertsona arduradunak. Probako migrazioan urrats guztiak landuak zeuden jada, beraz, zuzeneko migrazioan plana jarraitu eta prozesua koordinatzea besterik ez zen beharrezkoa.
Migrazioa sistematikoki egin zen hainbat fasetan. Etapa bakoitzean bi sistema daude.
Hiru hilabeteko esprint baten emaitza CROC datu-zentroan guztiz funtzionatzen duen sistema izan zen. Oro har, emaitza positiboa lortu da talde-lanaren bidez; prozesuan parte-hartzaile guztien ekarpena eta dedikazioa maximoa izan da.
Bezeroaren papera proiektuan
Gure bezeroak uzten ari zen hornitzailearekin komunikatzea ez zen erraza izan. Hori ulergarria da; proiektua arrakastaz burutzeko interesa zutenen zerrendako azkenak izan ziren. Bezeroak komunikazio-arazo guztiak areagotzeko eta pedaleatzeko zeregina hartu zuen eta %100500 horri aurre egin zion. Berari esker bereziak horregatik. Prozesuan halako parte-hartze bideragarririk izan ezean, proiektuaren emaitza guztiz bestelakoa izan zitekeen.
"Ohiko" hornitzailearen aldetik prozesuen formalizazioa dela eta, azpiegituraren laguntza arazoetatik literalki urrun zeuden espezialistek egin zuten, garai hartan oraindik bezeroak. Adibidez, datu-base bera esportatzeko prozesuak ordubetetik bostera iraun dezake. Orduan bazirudien hau magia moduko bat zela, sekula ezagutarazi ez zitzaigun sekretua. Seguruenik laguntza teknikoko ingeniariek bitartean meditazioan murgildu ziren, Errusia urruneko nonbait epeak daudela ahaztuta, Urteberriko entsaladarik gabeko ingeniariak, bezeroa negarrez eta sufritzen ari dela...
Proiektuaren emaitzak
Migrazioaren azken urratsa mantentze-sistemak transferitzea izan zen.
Orain leiho bakarreko zerbitzua eskaintzen dugu bezeroen eskaeretarako eta azpiegitura-osagaiekin eta SAP oinarriarekin lotutako zereginen esparru osoa estaltzen dugu gure bazkidearekin - itelligence. Bezeroak sei hilabete daramatza hodei pribatu batean bizitzen. Hona hemen aldi honetan zerbitzu kasuei buruzko estatistikak:
- 90 gorabehera (% 20 bezeroa inplikatu gabe konpondu dira)
- SLAren barruan konpondu da - % 100
- Programatu gabeko sistema itzaltzeak - 0
Gure bezeroaren antzeko arazoak badituzu, eta horiek konpontzeko moduari buruz gehiago jakin nahi baduzu, idatzi helbide honetara: [posta elektroniko bidez babestua]
Iturria: www.habr.com