Atau adakah mungkin? Sudah tentu, pemindahan sistem SAP adalah proses yang kompleks dan teliti, yang mana kejayaannya memerlukan kerja yang diselaraskan dengan baik oleh semua peserta. Dan jika penghijrahan dilakukan dalam masa yang singkat, tugas itu menjadi lebih rumit. Tidak semua orang memutuskan untuk melakukan ini. Mungkin ada beberapa sebab. Sebagai contoh, proses itu sendiri adalah panjang dan kompleks dari segi organisasi. Tambahan pula terdapat risiko masa henti sistem yang tidak dirancang. Atau pelanggan tidak pasti bahawa, setelah menjalani operasi sedemikian, mereka akan menerima faedah yang setimpal dengan usaha yang dilakukan. Walau bagaimanapun, terdapat pengecualian.
Di bawah pemotongan, kami akan bercakap tentang kesukaran yang dihadapi pelanggan dalam proses pemindahan dan penyelenggaraan sistem SAP, membincangkan sebab stereotaip tidak selalu sepadan dengan realiti, dan berkongsi kajian kes tentang cara kami berjaya memindahkan sistem pelanggan kepada infrastruktur baharu dalam tempoh tiga bulan sahaja.
Pengehosan sistem SAP
Hanya lima tahun yang lalu, sukar untuk membayangkan bahawa pelanggan akan mula menggunakan sumber pengehosan untuk aplikasi SAP secara besar-besaran. Dalam kebanyakan kes ia dilaksanakan di premis. Walau bagaimanapun, dengan pembangunan model penyumberan luar dan pasaran perkhidmatan awan, pandangan dunia pelanggan mula berubah. Apakah hujah yang mempengaruhi pilihan yang memihak kepada awan untuk SAP?
- Bagi pemula yang baru merancang untuk melaksanakan SAP, infrastruktur awan hampir menjadi pilihan standard - kebolehskalaan sumber kepada keperluan semasa sistem dan keengganan untuk mengalihkan sumber kepada pembangunan kecekapan bukan teras.
- Dalam syarikat dengan landskap sistem yang besar, dengan bantuan pengehosan sistem SAP, CIO mencapai tahap pengurusan risiko yang berbeza secara kualitatif, kerana Rakan kongsi bertanggungjawab untuk SLA.
- Hujah ketiga yang paling biasa ialah kos tinggi untuk membina infrastruktur untuk melaksanakan ketersediaan tinggi dan senario DR.
- Faktor 2027 β vendor mengumumkan penamatan sokongan untuk sistem warisan pada 2027. Ini bermakna memindahkan pangkalan data kepada HANA, yang memerlukan kos untuk pemodenan dan pembelian kuasa pengkomputeran baharu.
Pasaran hosting SAP di Rusia kini boleh dianggap agak matang. Dan ini memberikan peluang yang luas untuk pelanggan yang ingin menukar platform pengehosan mereka. Walau bagaimanapun, projek sedemikian boleh menimbulkan kebimbangan dalam kalangan perniagaan kerana kerumitan prosedur migrasi. Ini memaksa pelanggan untuk meningkatkan permintaan terhadap penyedia perkhidmatan, yang mesti mempunyai bukan sahaja kecekapan luar biasa dalam mengehos dan menyelenggara sistem SAP, tetapi juga pengalaman yang berjaya dalam bidang migrasi.
Apakah kesukaran menukar pengehosan SAP?
Pengehosan adalah berbeza. Tidak konsisten dengan tahap perkhidmatan yang diisytiharkan, banyak "tetapi" dan asterisk dengan tempahan dalam teks kecil, sumber terhad dan keupayaan penyedia pengehosan, kekurangan fleksibiliti dalam hal komunikasi dengan pelanggan, birokrasi, batasan teknikal, kecekapan rendah sokongan teknikal pakar, serta banyak nuansa lain - ini adalah Ini hanyalah sebahagian kecil daripada masalah yang mungkin dihadapi oleh pelanggan apabila mengendalikan sistem perniagaan mereka dalam infrastruktur penyumberan luar. Selalunya, untuk pelanggan, semua ini kekal dalam bayang-bayang, di dalam hutan kontrak berbilang halaman, dan muncul dalam proses menggunakan perkhidmatan.
Pada satu ketika, ia menjadi jelas kepada pelanggan bahawa tahap perkhidmatan yang diterimanya adalah jauh dari jangkaannya. Ini adalah sejenis pemangkin untuk mencari penyelesaian untuk membetulkan keadaan dan, sekiranya berlaku kegagalan, apabila masalah terkumpul ke had dan ia menjadi sangat menyakitkan, mereka beralih kepada tindakan aktif untuk membangunkan pilihan alternatif ke arah menukar penyedia perkhidmatan. .
Mengapa mereka menunggu sehingga saat akhir? Sebabnya mudah - proses pemindahan sistem untuk pelanggan tidak selalunya telus dan boleh difahami. Adalah sukar untuk pelanggan menilai risiko sebenar yang berkaitan dengan proses migrasi. Kita boleh mengatakan bahawa penghijrahan untuk pelanggan adalah sejenis kotak hitam: tidak jelas, harga, masa henti sistem, risiko dan cara mengurangkannya, dan secara amnya ia adalah gelap dan menakutkan. Ia seperti, jika ia tidak berjaya, maka kepala akan bergolek di bahagian atas dan pada penghibur.
SAP ialah sistem peringkat perusahaan, kompleks dan, secara ringkasnya, bukan murah. Belanjawan yang layak dibelanjakan untuk pelaksanaan, pengubahsuaian dan penyelenggaraannya, dan hayat perusahaan bergantung pada ketersediaan dan operasi yang betul. Sekarang bayangkan akibat menghentikan beberapa pengeluaran besar. Ini adalah kerugian kewangan, yang boleh dikira dalam nombor dengan bilangan sifar yang besar, serta risiko reputasi dan risiko lain yang sama penting.
Kami akan menganalisis kesukaran yang mungkin timbul pada setiap peringkat dalam kes pemindahan sistem SAP daripada salah seorang pelanggan kami.
Penyediaan dan reka bentuk
Migrasi adalah formula dengan banyak bahagian yang berbeza. Dan salah satu yang paling penting ialah peringkat mereka bentuk dan menyediakan infrastruktur sasaran (baru).
Kami perlu menyelami pelaksanaan sistem sedia ada, seni binanya. Dalam infrastruktur sasaran, kami mengulangi penyelesaian sedia ada di suatu tempat, menambah dan menambah baiknya pada beberapa titik, menyusun semulanya di suatu tempat, memikirkan dan memilih penyelesaian untuk memastikan toleransi kesalahan dan ketersediaan, dan juga menyatukan semua sumber sebanyak mungkin.
Semasa proses reka bentuk, banyak latihan yang berbeza telah dilakukan, yang akhirnya memungkinkan untuk menyediakan sebanyak mungkin untuk penghijrahan dan mengambil kira semua jenis nuansa dan perangkap (lebih lanjut mengenainya kemudian).
Apa yang kami dapati ialah infrastruktur awan peribadi yang direka bentuk secara individu berdasarkan pusat data kami:
- pelayan fizikal khusus untuk SAP HANA;
- Platform virtualisasi VMware untuk pelayan aplikasi dan perkhidmatan infrastruktur;
- saluran komunikasi pendua antara pusat data untuk L2 VPN;
- dua sistem storan utama untuk mengasingkan produk dan "segala-galanya";
- SRC berdasarkan Veritas Netbackup dengan pelayan berasingan, rak cakera dan perpustakaan pita.
Dan inilah cara kami melaksanakan semua ini dari sudut teknikal.
SAP
- Untuk menggunakan storan untuk HANA yang produktif dengan berkesan, kami menggunakan cakera kongsi tanpa replikasi pangkalan data sistemik menggunakan SAP. Semua ini dibalut dalam kelompok SUSE HAE Bersedia Aktif berdasarkan Perentak Jantung. Ya, masa pemulihan adalah lebih lama sedikit berbanding dengan replikasi, tetapi kami menjimatkan ruang storan sebanyak separuh dan, akibatnya, menjimatkan belanjawan pelanggan.
- Dalam persekitaran pra-pengeluaran, kelompok HANA telah ditinggalkan, tetapi secara teknikal konfigurasi pengeluaran diulang.
- Persekitaran ujian dan pembangunan telah diedarkan merentasi beberapa lagi pelayan tanpa kelompok dalam konfigurasi MCOS.
- Semua pelayan aplikasi telah dimaya dan dihoskan dalam VMware.
Π‘Π΅ΡΠΈ
- Kami secara fizikal memisahkan kontur rangkaian kawalan dan pengeluaran dengan susunan suis, menjadikan suis yang produktif ke arah pusat data pelanggan.
- Kami memasang bilangan antara muka rangkaian yang mencukupi supaya tidak mencampurkan aliran trafik yang besar.
- Untuk memindahkan data daripada sistem storan, kami membuat kilang FC SAN klasik.
SHD
- Muatan SAP yang produktif dan pra-produktif ditinggalkan pada tatasusunan semua denyar.
- Persekitaran ujian pembangun dan perkhidmatan infrastruktur diletakkan pada tatasusunan hibrid yang berasingan.
IBS
- Dibuat menggunakan Veritas Netbackup.
- Kami menambah sedikit pada skrip terbina dalam untuk menyandarkan konfigurasi MCOS.
- Kami meletakkan salinan operasi pada rak cakera untuk pemulihan cepat, dan kami menggunakan pita untuk penyimpanan jangka panjang.
Pemantauan
- Semua perkakasan, OS dan SAP telah dipasang di bawah Zabbix.
- Kami telah mengumpulkan banyak papan pemuka berguna di Grafana.
- Apabila amaran berlaku, Zabbix boleh membuat permintaan dalam sistem pengurusan insiden; kami telah melaksanakannya di Jira. Maklumat itu juga disalin dalam saluran Telegram.
Telegram
Kesihatan umum HANA
Status Pelayan Aplikasi SAP:
Perkhidmatan infrastruktur
- Untuk memberi perkhidmatan ruang nama dalaman, sekumpulan pelayan DNS telah dibangkitkan, yang disegerakkan dengan pelayan pelanggan.
- Kami mencipta pelayan fail yang berasingan untuk pertukaran data.
- Untuk menyimpan pelbagai konfigurasi, Gitlab telah ditambahkan.
- Untuk pelbagai maklumat Sensitif kami mengambil HashiCorp Vault.
Proses migrasi
Secara umum, proses migrasi terdiri daripada peringkat berikut:
- penyediaan semua dokumentasi projek yang diperlukan;
- rundingan dengan pembekal semasa - menyelesaikan isu organisasi;
- pembelian, penghantaran dan pemasangan peralatan baru untuk projek itu;
- ujian migrasi dan proses penyahpepijatan;
- pemindahan sistem, memerangi penghijrahan.
Pada penghujung Oktober 2019, kami menandatangani kontrak, kemudian mereka bentuk seni bina, dan selepas bersetuju dengan pelanggan, kami memesan peralatan yang diperlukan.
Apa yang perlu anda perhatikan terlebih dahulu ialah masa penghantaran peralatan. Secara purata, penghantaran perkakasan diperakui untuk SAP NAHA yang memenuhi keperluan pengeluar perisian untuk platform perkakasan mengambil masa 10-12 minggu. Dan dengan mengambil kira bermusim (pelaksanaan projek itu jatuh tepat pada Tahun Baru), tempoh ini boleh meningkat sebulan lagi. Sehubungan itu, adalah perlu untuk mempercepatkan proses itu secepat mungkin: kami bekerjasama dengan pembekal pengedar dan bersetuju untuk penghantaran dipercepatkan melalui kapal terbang (bukan laluan darat dan laut).
November dan Disember dihabiskan untuk bersiap sedia untuk penghijrahan dan menerima beberapa peralatan. Kami menjalankan penyediaan di bangku ujian di awan awam kami, di mana kami bekerja melalui semua langkah utama dan menghadapi kemungkinan kesukaran dan masalah:
- menyediakan pelan terperinci untuk interaksi antara ahli pasukan projek dengan pemasaan minit demi minit;
- membina bangku ujian untuk pangkalan data dan pelayan aplikasi dengan cara yang lebih kurang sama seperti dalam infrastruktur sasaran;
- mengkonfigurasi saluran komunikasi dan perkhidmatan infrastruktur yang diperlukan untuk menguji operasi penyepaduan;
- menyelesaikan senario pemotongan;
- Awan juga membantu kami membuat templat mesin maya pra-konfigurasi, yang kemudian kami hanya mengimport dan menggunakan landskap sasaran.
Sejurus sebelum cuti Tahun Baru, kumpulan pertama peralatan tiba kepada kami. Ini memungkinkan untuk menggunakan beberapa sistem pada perkakasan sebenar. Oleh kerana tidak semuanya tiba, kami menyambungkan peralatan gantian, yang bekalannya kami berjaya bersetuju dengan vendor dan pengedar. Kami menerima sisa infrastruktur sasaran pada peringkat akhir.
Untuk memenuhi tarikh akhir, jurutera kami terpaksa mengorbankan cuti Tahun Baru dan mula bekerja untuk menyediakan infrastruktur sasaran pada 2 Januari, di tengah-tengah cuti. Ya, ini kadangkala berlaku apabila ia terbakar dan tiada pilihan lain. Yang dipertaruhkan ialah prestasi sistem yang bergantung kepada hayat perusahaan.
Susunan am penghijrahan kelihatan seperti ini: pertama, sistem paling tidak kritikal (landskap pembangunan, landskap ujian), kemudian sistem produktif. Peringkat terakhir penghijrahan berlaku pada akhir Januari dan awal Februari.
Proses penghijrahan telah dirancang hingga ke minit. Ini ialah pelan pemotongan dengan senarai semua tugas, masa penyiapan dan orang yang bertanggungjawab. Semua langkah telah diusahakan dalam migrasi ujian, jadi dalam migrasi langsung, hanya perlu mengikuti rancangan dan menyelaraskan proses.
Penghijrahan dilakukan secara sistematik dalam beberapa peringkat. Terdapat dua sistem dalam setiap peringkat.
Hasil daripada pecutan tiga bulan adalah sistem yang beroperasi sepenuhnya di pusat data CROC. Secara umumnya, keputusan positif dicapai melalui kerja berpasukan; sumbangan dan dedikasi semua peserta dalam proses adalah maksimum.
Peranan pelanggan dalam projek
Berkomunikasi dengan pembekal yang pelanggan kami akan pergi adalah tidak mudah. Ini boleh difahami; mereka adalah yang terakhir dalam senarai orang yang berminat untuk berjaya menyiapkan projek itu. Pelanggan mengambil tugas untuk meningkatkan dan mengayuh semua isu komunikasi dan mengatasi 100500% ini. Terima kasih khusus kepada beliau untuk ini. Tanpa penyertaan yang boleh dilaksanakan dalam proses itu, hasil projek itu mungkin berbeza sama sekali.
Disebabkan oleh pemformalan proses di sisi penyedia "bekas", sokongan infrastruktur telah dijalankan oleh pakar yang benar-benar jauh dari masalah, pada masa itu masih pelanggan mereka. Sebagai contoh, proses mengeksport pangkalan data yang sama boleh mengambil masa dari satu jam hingga lima. Kemudian nampaknya ini adalah sejenis sihir, rahsia yang tidak pernah didedahkan kepada kita. Mungkin jurutera sokongan teknikal terlibat dalam meditasi sementara itu, lupa bahawa di suatu tempat di Rusia yang jauh terdapat tarikh akhir, jurutera tanpa salad Tahun Baru, pelanggan menangis dan menderita...
Hasil projek
Langkah terakhir penghijrahan ialah pemindahan sistem untuk penyelenggaraan.
Kini kami menyediakan perkhidmatan tetingkap tunggal untuk permintaan pelanggan dan meliputi keseluruhan skop tugas yang berkaitan dengan komponen infrastruktur sokongan dan asas SAP bersama rakan kongsi kami - intelligence. Pelanggan telah tinggal di awan peribadi selama enam bulan. Berikut ialah statistik kes perkhidmatan pada masa ini:
- 90 insiden (20% diselesaikan tanpa melibatkan pelanggan)
- Selesai dalam SLA β 100%
- Penutupan sistem tidak berjadual β 0
Jika anda mempunyai masalah yang serupa dengan masalah pelanggan kami, dan anda ingin mengetahui lebih lanjut tentang cara menyelesaikannya, tulis kepada: [e-mel dilindungi]
Sumber: www.habr.com