Utawa iku bisa? Mesthine, sistem SAP migrasi minangka proses sing rumit lan angel, sing sukses mbutuhake karya sing koordinasi kabeh peserta. Lan yen migrasi ditindakake kanthi cepet, tugas kasebut dadi luwih rumit. Ora saben wong mutusake kanggo nindakake iki. Ana sawetara alasan. Contone, proses kasebut dawa lan rumit kanthi organisasi. Kajaba iku, ana risiko downtime sistem sing ora direncanakake. Utawa klien ora yakin manawa, sawise ngalami operasi kasebut, dheweke bakal entuk keuntungan sing cocog karo upaya sing ditindakake. Nanging, ana pangecualian.
Ing ngisor iki, kita bakal ngomong babagan kesulitan sing dialami para pelanggan sajrone proses migrasi lan njaga sistem SAP, ngrembug kenapa stereotip ora cocog karo kasunyatan, lan nuduhake studi kasus babagan carane kita bisa migrasi sistem pelanggan menyang a infrastruktur anyar mung liwat telung sasi.
SAP sistem hosting
Mung limang taun kepungkur, angel mbayangno manawa klien bakal mulai nggunakake sumber daya hosting kanggo aplikasi SAP. Ing sawetara kasus, padha dileksanakake ing panggonan. Nanging, kanthi pangembangan model outsourcing lan pasar layanan awan, pandangan jagad pelanggan wiwit owah. Apa bantahan sing mengaruhi pilihan sing cocog karo awan kanggo SAP?
- Kanggo pamula sing lagi wae ngrancang kanggo ngleksanakake SAP, infrastruktur maya meh dadi pilihan standar - skalabilitas sumber daya kanggo kabutuhan sistem saiki lan keengganan kanggo ngalihake sumber daya menyang pangembangan kompetensi non-inti.
- Ing perusahaan kanthi lanskap sistem gedhe, kanthi bantuan hosting sistem SAP, CIO tekan tingkat manajemen risiko sing beda-beda, amarga Partner tanggung jawab kanggo SLA.
- Argumentasi paling umum nomer telu yaiku biaya infrastruktur bangunan sing dhuwur kanggo ngetrapake kasedhiyan dhuwur lan skenario DR.
- Faktor 2027 - vendor ngumumake pungkasane dhukungan kanggo sistem warisan ing 2027. Iki tegese nransfer database menyang HANA, sing mbutuhake biaya kanggo modernisasi lan tuku daya komputasi anyar.
Pasar hosting SAP ing Rusia saiki bisa dianggep cukup diwasa. Lan iki menehi kesempatan akeh kanggo pelanggan sing pengin ngganti platform hosting. Nanging, proyek kasebut bisa nyebabake keprihatinan ing antarane bisnis amarga kerumitan prosedur migrasi. Iki meksa pelanggan kanggo nambah panjaluk panyedhiya layanan, sing kudu ora mung duwe kompetensi luar biasa ing hosting lan njaga sistem SAP, nanging uga pengalaman sukses ing bidang migrasi.
Apa kangelan ngganti hosting SAP?
Hosting beda-beda. Inkonsistensi karo tingkat layanan sing diumumake, akeh "nanging" lan tanda bintang kanthi leladen ing teks cilik, sumber daya lan kemampuan panyedhiya hosting sing winates, kurang keluwesan ing babagan komunikasi karo klien, birokrasi, watesan teknis, kurang kompetensi dhukungan teknis. spesialis, uga akeh nuansa liyane - iki mung bagean cilik saka pitfalls sing klien bisa nemokke nalika operasi sistem bisnis ing infrastruktur outsourcing. Asring, kanggo klien, kabeh iki tetep ana ing bayang-bayang, ing alas kontrak multi-halaman, lan muncul ing proses nggunakake layanan kasebut.
Ing sawetara titik, dadi jelas kanggo pelanggan yen tingkat layanan sing ditampa adoh saka pangarepan. Iki minangka jenis katalis kanggo nemokake solusi kanggo mbenerake kahanan kasebut lan, yen gagal, nalika masalah nglumpukake nganti wates lan dadi lara banget, dheweke pindhah menyang tumindak aktif kanggo ngembangake pilihan alternatif ing arah ngganti panyedhiya layanan. .
Napa dheweke ngenteni nganti menit pungkasan? Alesane prasaja - proses migrasi sistem kanggo klien ora mesthi transparan lan bisa dingerteni. Pancen angel kanggo klien kanggo netepake risiko nyata sing ana gandhengane karo proses migrasi. Kita bisa ngomong sing migrasi kanggo klien iku jenis kothak ireng: iku ora cetha, rega, sistem downtime, risiko lan carane ngurangi mau, lan ing umum iku peteng lan medeni. Kayane, yen ora bisa, banjur sirah bakal muter loro ing ndhuwur lan ing pemain.
SAP minangka sistem tingkat perusahaan, kompleks lan, kanthi gampang, ora murah. Anggaran sing layak digunakake kanggo implementasine, modifikasi lan pangopènan, lan umur perusahaan gumantung saka kasedhiyan lan operasi sing bener. Saiki bayangake akibat saka mungkasi produksi gedhe. Iki minangka kerugian finansial, sing bisa diwilang kanthi jumlah nol sing akeh, uga risiko reputasi lan risiko liyane sing padha.
Kita bakal nganalisa kesulitan sing bisa kedadeyan ing saben tahap nalika migrasi sistem SAP saka salah sawijining pelanggan.
Preparation lan desain
Migrasi minangka rumus kanthi macem-macem bagean. Lan salah siji sing paling penting yaiku tahap ngrancang lan nyiapake infrastruktur target (anyar).
Kita kudu nyilem menyang implementasi sistem sing ana lan arsitekture. Ing infrastruktur target, kita mbaleni solusi sing wis ana ing endi wae, nambah lan nambah ing sawetara titik, nggawe maneh ing endi wae, mikir lan milih solusi kanggo njamin toleransi lan kasedhiyan kesalahan, lan uga nggabungake kabeh sumber daya sabisa.
Sajrone proses desain, akeh latihan sing beda-beda sing ditindakake, sing pungkasane bisa nyiyapake migrasi sabisa-bisa lan njupuk kabeh nuansa lan pitfalls (luwih akeh babagan mengko).
Sing rampung yaiku infrastruktur awan pribadi sing dirancang kanthi individu adhedhasar pusat data kita:
- server fisik darmabakti kanggo SAP HANA;
- Platform virtualisasi VMware kanggo server aplikasi lan layanan infrastruktur;
- saluran komunikasi duplikat antarane pusat data kanggo L2 VPN;
- rong sistem panyimpenan utama kanggo misahake produk lan "kabeh liyane";
- SRC adhedhasar Veritas Netbackup karo server kapisah, beting disk lan perpustakaan tape.
Lan ing kene kita ngetrapake kabeh iki saka sudut pandang teknis.
SAP
- Kanggo nggunakake panyimpenan kanthi efektif kanggo HANA sing produktif, kita nggunakake disk sing dienggo bareng tanpa replikasi database sistemik nggunakake SAP. Kabeh iki kebungkus ing klompok Active-Standby SUSE HAE adhedhasar Pacemaker. Ya, wektu pemulihan luwih suwe tinimbang replikasi, nanging kita ngirit ruang panyimpenan kanthi setengah lan, minangka asil, ngirit anggaran pelanggan.
- Ing lingkungan pra-produksi, kluster HANA ditinggalake, nanging sacara teknis konfigurasi produksi diulang.
- Lingkungan tes lan pangembangan disebarake ing sawetara server liyane tanpa klompok ing konfigurasi MCOS.
- Kabeh server aplikasi wis virtualisasi lan dadi tuan rumah ing VMware.
Сети
- Kita misahake kontur kontrol lan jaringan produksi kanthi tumpukan switch, ngowahi sing produktif menyang pusat data pelanggan.
- Kita nginstal sawetara antarmuka jaringan sing cukup supaya ora nyampur arus lalu lintas sing gedhe.
- Kanggo mindhah data saka sistem panyimpenan, kita nggawe pabrik FC SAN klasik.
SHD
- Beban produktif lan pra-produktif SAP ditinggalake ing larik lampu kilat kabeh.
- Lingkungan tes pangembang lan layanan infrastruktur diselehake ing array hibrida sing kapisah.
IBS
- Digawe nggunakake Veritas Netbackup.
- We ditambahaké sethitik kanggo script dibangun ing konfigurasi MCOS serep.
- Kita sijine salinan operasional ing rak disk kanggo Recovery cepet, lan kita nggunakake tape kanggo panyimpenan long-term.
Ngawasi
- Kabeh hardware, OS lan SAP diinstal ing Zabbix.
- Kita wis nglumpukake akeh dashboard migunani ing Grafana.
- Nalika ana tandha, Zabbix bisa nggawe panjalukan ing sistem manajemen insiden; kita wis dileksanakake ing Jira. Informasi kasebut uga diduplikasi ing saluran Telegram.
Telegram
Kesehatan Umum HANA
Status Server Aplikasi SAP:
Layanan infrastruktur
- Kanggo nglayani ruang jeneng internal, klompok server DNS diunggahake, sing disinkronake karo server pelanggan.
- Kita nggawe server file sing kapisah kanggo ijol-ijolan data.
- Kanggo nyimpen macem-macem konfigurasi, Gitlab ditambahake.
- Kanggo macem-macem informasi Sensitif, kita njupuk HashiCorp Vault.
Proses migrasi
Umumé, proses migrasi kasusun saka tahapan ing ngisor iki:
- nyiapake kabeh dokumentasi proyek sing perlu;
- rembugan karo panyedhiya saiki - ngrampungake masalah organisasi;
- tuku, pangiriman lan instalasi peralatan anyar kanggo proyek kasebut;
- test migrasi lan proses debugging;
- transfer sistem, migrasi pertempuran.
Ing pungkasan Oktober 2019, kita mlebu kontrak, banjur ngrancang arsitektur, lan sawise setuju karo pelanggan, kita pesen peralatan sing dibutuhake.
Sing kudu digatekake dhisik yaiku wektu pangiriman piranti kasebut. Rata-rata, pangiriman hardware sing disertifikasi kanggo SAP NAHA sing nyukupi syarat produsen piranti lunak kanggo platform hardware mbutuhake 10-12 minggu. Lan njupuk menyang akun seasonality (implementasine saka project ambruk persis ing Taun Anyar), wektu iki bisa nambah dening liyane sasi. Patut, iku perlu kanggo nyepetake proses okehe: kita makarya karo distributor-supplier lan sarujuk ing pangiriman cepet dening pesawat (tinimbang darat lan segara rute).
Nopember lan Desember digunakake kanggo nyiapake migrasi lan nampa sawetara peralatan. Kita nindakake persiapan ing bangku tes ing awan umum, ing ngendi kita nggarap kabeh langkah utama lan ngalami kesulitan lan masalah:
- nyiapake rencana rinci kanggo interaksi antarane anggota tim proyek karo timing menit-by-menit;
- mbangun bangku tes kanggo database lan server aplikasi kanthi cara sing padha kaya ing infrastruktur target;
- ngatur saluran komunikasi lan layanan infrastruktur sing dibutuhake kanggo nguji operasi integrasi;
- nggarap skenario cutover;
- Awan uga mbantu kita nggawe template mesin virtual sing wis dikonfigurasi, sing banjur diimpor lan disebarake menyang lanskap target.
Sakcepete sadurunge preian Taun Anyar, batch pisanan saka peralatan teka kanggo kita. Iki ndadekake iku bisa kanggo masang sawetara sistem ing hardware nyata. Amarga ora kabeh teka, kita nyambungake peralatan panggantos, pasokan sing bisa disepakati karo vendor lan distributor. Kita nampa sisa-sisa infrastruktur target ing tahap pungkasan.
Kanggo ngrampungake tenggat wektu, insinyur kita kudu ngorbanake preian Taun Anyar lan miwiti nyiapake infrastruktur target tanggal 2 Januari, ing tengah-tengah preian. Ya, iki kadhangkala kedadeyan nalika kobong lan ora ana pilihan liyane. Sing dipertaruhake yaiku kinerja sistem sing gumantung marang urip perusahaan.
Urutan umum migrasi katon kaya mangkene: pisanan, sistem paling kritis (lanskap pembangunan, lanskap pengujian), banjur sistem produktif. Tahap pungkasan migrasi ditindakake ing pungkasan Januari lan awal Februari.
Proses migrasi wis direncanakake nganti menit. Iki minangka rencana pemotongan kanthi dhaptar kabeh tugas, wektu rampung lan wong sing tanggung jawab. Kabeh langkah wis digarap ing migrasi test, supaya ing migrasi urip mung perlu kanggo tindakake rencana lan koordinasi proses.
Migrasi ditindakake kanthi sistematis ing sawetara tahapan. Ana rong sistem ing saben tataran.
Asil saka sprint telung sasi yaiku sistem sing beroperasi kanthi lengkap ing pusat data CROC. Umumé, asil positif digayuh liwat kerja sama tim; kontribusi lan dedikasi kabeh peserta ing proses kasebut maksimal.
Peranan pelanggan ing proyek kasebut
Komunikasi karo panyedhiya sing ditinggal klien ora gampang. Iki bisa dingerteni; dheweke minangka sing terakhir ing dhaptar wong sing kasengsem ing sukses proyek kasebut. Pelanggan njupuk tugas escalating lan pedaling kabeh masalah komunikasi lan coped karo iki 100500%. Matur nuwun khusus kanggo dheweke. Tanpa partisipasi sing bisa ditindakake ing proses kasebut, asil proyek kasebut bisa uga beda.
Amarga proses formalisasi ing sisih panyedhiya "mantan", dhukungan infrastruktur ditindakake dening spesialis sing secara harfiah adoh saka masalah, ing wektu kasebut isih dadi pelanggan. Contone, proses ngekspor database sing padha bisa njupuk saka jam nganti limang. Banjur misale jek sing iki sawetara jenis sihir, rahasia sing ora tau dicethakaké kanggo kita. Mbokmenawa insinyur dhukungan teknis melu meditasi ing sauntara, lali yen ing ngendi wae ing Rusia sing adoh ana tenggat wektu, insinyur tanpa salad Taun Anyar, pelanggan nangis lan nandhang sangsara ...
Asil proyek
Langkah pungkasan saka migrasi yaiku transfer sistem kanggo pangopènan.
Saiki kita nyedhiyani layanan jendhela siji kanggo panjalukan customer lan nutupi kabeh orane katrangan saka tugas related kanggo ndhukung komponen infrastruktur lan basis SAP bebarengan karo partner kita - intelligence. Klien wis manggon ing awan pribadi sajrone nem wulan. Mangkene statistik babagan kasus layanan sajrone wektu iki:
- 90 insiden (20% ditanggulangi tanpa nglibatake pelanggan)
- Ditanggulangi ing SLA - 100%
- Mati sistem sing ora dijadwal - 0
Yen sampeyan duwe masalah sing padha karo klien kita, lan sampeyan pengin sinau luwih lengkap babagan cara ngatasi, nulis menyang: [email dilindhungi]
Source: www.habr.com