ປະສົບການຂອງການປ່ຽນແປງ SAP hosting: ວິທີການຍ້າຍລະບົບໂດຍທີ່ມັນບໍ່ເຈັບປວດ excruciatingly

ຫຼືມັນເປັນໄປໄດ້? ແນ່ນອນ, ການເຄື່ອນຍ້າຍລະບົບ SAP ແມ່ນຂະບວນການທີ່ສັບສົນແລະມີຄວາມອົດທົນ, ຄວາມສໍາເລັດຂອງການປະຕິບັດທີ່ຕ້ອງການການປະສານງານທີ່ດີຂອງຜູ້ເຂົ້າຮ່ວມທັງຫມົດ. ແລະຖ້າການເຄື່ອນຍ້າຍໄດ້ຖືກດໍາເນີນໃນເວລາສັ້ນໆ, ວຽກງານຈະສັບສົນຫຼາຍ. ບໍ່ແມ່ນທຸກຄົນຕັດສິນໃຈເຮັດສິ່ງນີ້. ອາດຈະມີເຫດຜົນຫຼາຍຢ່າງ. ສໍາລັບຕົວຢ່າງ, ຂະບວນການຕົວມັນເອງແມ່ນຍາວແລະສະລັບສັບຊ້ອນຂອງອົງການຈັດຕັ້ງ. ນອກຈາກນັ້ນ, ມີຄວາມສ່ຽງຕໍ່ການຢຸດລະບົບທີ່ບໍ່ໄດ້ວາງແຜນໄວ້. ຫຼືລູກຄ້າບໍ່ແນ່ໃຈວ່າ, ໄດ້ດໍາເນີນການດັ່ງກ່າວ, ພວກເຂົາເຈົ້າຈະໄດ້ຮັບຜົນປະໂຫຍດທີ່ສົມທຽບກັບຄວາມພະຍາຍາມທີ່ໄດ້ໃຊ້ຈ່າຍ. ຢ່າງໃດກໍຕາມ, ມີຂໍ້ຍົກເວັ້ນ.

ຂ້າງລຸ່ມນີ້ການຕັດ, ພວກເຮົາຈະເວົ້າກ່ຽວກັບຄວາມຫຍຸ້ງຍາກທີ່ລູກຄ້າປະເຊີນໃນຂະບວນການເຄື່ອນຍ້າຍແລະຮັກສາລະບົບ SAP, ປຶກສາຫາລືວ່າເປັນຫຍັງ stereotypes ບໍ່ກົງກັບຄວາມເປັນຈິງ, ແລະແບ່ງປັນກໍລະນີສຶກສາກ່ຽວກັບວິທີທີ່ພວກເຮົາຈັດການການເຄື່ອນຍ້າຍລະບົບຂອງລູກຄ້າໄປສູ່. ໂຄງ​ລ່າງ​ພື້ນ​ຖານ​ໃຫມ່​ໃນ​ໄລ​ຍະ​ພຽງ​ແຕ່​ສາມ​ເດືອນ​.

ລະບົບ SAP hosting

ພຽງແຕ່ຫ້າປີກ່ອນຫນ້ານີ້, ມັນເປັນການຍາກທີ່ຈະຈິນຕະນາການວ່າລູກຄ້າຈະເລີ່ມໃຊ້ຊັບພະຍາກອນໂຮດຕິ້ງສໍາລັບຄໍາຮ້ອງສະຫມັກ SAP ຢ່າງຫຼວງຫຼາຍ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ພວກເຂົາເຈົ້າໄດ້ຖືກປະຕິບັດຢູ່ໃນສະຖານທີ່. ຢ່າງໃດກໍ່ຕາມ, ດ້ວຍການພັດທະນາແບບຈໍາລອງການອອກນອກແລະຕະຫຼາດການບໍລິການຟັງ, ທັດສະນະຂອງໂລກຂອງລູກຄ້າເລີ່ມປ່ຽນແປງ. ການໂຕ້ຖຽງທີ່ມີອິດທິພົນຕໍ່ທາງເລືອກໃນເງື່ອນໄຂຂອງຄລາວສໍາລັບ SAP ແມ່ນຫຍັງ?

• ສໍາລັບຜູ້ເລີ່ມຕົ້ນທີ່ພຽງແຕ່ວາງແຜນທີ່ຈະປະຕິບັດ SAP, ໂຄງສ້າງພື້ນຖານຂອງຄລາວແມ່ນເກືອບເປັນທາງເລືອກມາດຕະຖານ - ຄວາມສາມາດໃນການຂະຫຍາຍຊັບພະຍາກອນໃຫ້ກັບຄວາມຕ້ອງການຂອງລະບົບໃນປະຈຸບັນແລະຄວາມລັງເລທີ່ຈະຫັນປ່ຽນຊັບພະຍາກອນໄປສູ່ການພັດທະນາຄວາມສາມາດທີ່ບໍ່ແມ່ນຫຼັກ.
• ໃນບໍລິສັດທີ່ມີພູມສັນຖານຂອງລະບົບຂະຫນາດໃຫຍ່, ດ້ວຍການຊ່ວຍເຫຼືອຂອງການເປັນເຈົ້າພາບລະບົບ SAP, CIOs ບັນລຸລະດັບການຄຸ້ມຄອງຄວາມສ່ຽງທີ່ແຕກຕ່າງກັນ, ເພາະວ່າ. ຄູ່ຮ່ວມງານແມ່ນຮັບຜິດຊອບສໍາລັບ SLA.
• ການໂຕ້ຖຽງທົ່ວໄປທີ່ສາມແມ່ນຄ່າໃຊ້ຈ່າຍສູງຂອງການກໍ່ສ້າງພື້ນຖານໂຄງລ່າງເພື່ອປະຕິບັດການມີຢູ່ສູງແລະສະຖານະການ DR.
• ປັດໄຈ 2027 - ຜູ້ຂາຍໄດ້ປະກາດການສິ້ນສຸດການສະຫນັບສະຫນູນລະບົບມໍລະດົກໃນປີ 2027. ນີ້ຫມາຍຄວາມວ່າການໂອນຖານຂໍ້ມູນໄປຫາ HANA, ເຊິ່ງປະກອບມີຄ່າໃຊ້ຈ່າຍສໍາລັບຄວາມທັນສະໄຫມແລະການຊື້ພະລັງງານຄອມພິວເຕີ້ໃຫມ່.

ຕະຫຼາດໂຮດຕິ້ງ SAP ໃນລັດເຊຍໃນປັດຈຸບັນສາມາດໄດ້ຮັບການພິຈາລະນາຂ້ອນຂ້າງໃຫຍ່. ແລະນີ້ສະຫນອງໂອກາດພຽງພໍສໍາລັບລູກຄ້າທີ່ຕ້ອງການປ່ຽນເວທີການໂຮດຕິ້ງຂອງພວກເຂົາ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ໂຄງການດັ່ງກ່າວສາມາດເຮັດໃຫ້ເກີດຄວາມກັງວົນຕໍ່ບັນດາທຸລະກິດຢ່າງຖືກຕ້ອງເນື່ອງຈາກຄວາມສັບສົນຂອງຂັ້ນຕອນການເຄື່ອນຍ້າຍ. ນີ້ບັງຄັບໃຫ້ລູກຄ້າວາງຄວາມຕ້ອງການທີ່ເພີ່ມຂຶ້ນໃນຜູ້ໃຫ້ບໍລິການ, ຜູ້ທີ່ຕ້ອງມີຄວາມສາມາດພິເສດບໍ່ພຽງແຕ່ໃນການເປັນເຈົ້າພາບແລະການຮັກສາລະບົບ SAP, ແຕ່ຍັງປະສົບຄວາມສໍາເລັດໃນດ້ານການເຄື່ອນຍ້າຍ.

ຄວາມຫຍຸ້ງຍາກໃນການປ່ຽນແປງ SAP hosting ແມ່ນຫຍັງ?

ການເປັນເຈົ້າພາບແມ່ນແຕກຕ່າງກັນ. ຄວາມບໍ່ສອດຄ່ອງຂອງລະດັບການບໍລິການທີ່ປະກາດໄວ້, ຫຼາຍໆ "ແຕ່" ແລະຮູບດາວທີ່ມີການຈອງຢູ່ໃນຂໍ້ຄວາມຂະຫນາດນ້ອຍ, ຊັບພະຍາກອນທີ່ຈໍາກັດແລະຄວາມສາມາດຂອງຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງ, ການຂາດຄວາມຍືດຫຍຸ່ນໃນເລື່ອງການສື່ສານກັບລູກຄ້າ, ຫ້ອງການ, ຂໍ້ຈໍາກັດດ້ານວິຊາການ, ຄວາມສາມາດໃນການສະຫນັບສະຫນູນດ້ານວິຊາການຕ່ໍາ. ຜູ້ຊ່ຽວຊານ, ເຊັ່ນດຽວກັນກັບ nuances ອື່ນໆຈໍານວນຫຼາຍ - ເຫຼົ່ານີ້ແມ່ນພຽງແຕ່ສ່ວນຫນຶ່ງຂອງ pitfalls ທີ່ລູກຄ້າອາດຈະພົບໃນເວລາທີ່ປະຕິບັດລະບົບທຸລະກິດຂອງເຂົາເຈົ້າໃນ outsourcing ໂຄງສ້າງພື້ນຖານ. ເລື້ອຍໆ, ສໍາລັບລູກຄ້າ, ທັງຫມົດນີ້ຍັງຄົງຢູ່ໃນເງົາ, ຢູ່ໃນປ່າຂອງສັນຍາຫຼາຍຫນ້າ, ແລະເກີດຂື້ນໃນຂະບວນການໃຊ້ບໍລິການ.

ໃນບາງຈຸດ, ມັນຈະກາຍເປັນທີ່ຊັດເຈນສໍາລັບລູກຄ້າວ່າລະດັບການບໍລິການທີ່ລາວໄດ້ຮັບແມ່ນຢູ່ໄກຈາກຄວາມຄາດຫວັງຂອງລາວ. ນີ້ແມ່ນປະເພດຂອງ catalyst ສໍາລັບການຊອກຫາວິທີແກ້ໄຂເພື່ອແກ້ໄຂສະຖານະການແລະ, ໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວ, ເມື່ອບັນຫາໄດ້ສະສົມເຖິງຂອບເຂດຈໍາກັດແລະມັນຈະກາຍເປັນຄວາມເຈັບປວດຫຼາຍ, ພວກເຂົາເຈົ້າກ້າວໄປສູ່ການປະຕິບັດຢ່າງຫ້າວຫັນເພື່ອພັດທະນາທາງເລືອກໃນທິດທາງຂອງການປ່ຽນແປງຜູ້ໃຫ້ບໍລິການ. .

ເປັນຫຍັງພວກເຂົາຈຶ່ງລໍຖ້າຈົນກ່ວານາທີສຸດທ້າຍ? ເຫດຜົນແມ່ນງ່າຍດາຍ - ຂະບວນການຂອງລະບົບການເຄື່ອນຍ້າຍສໍາລັບລູກຄ້າແມ່ນບໍ່ໂປ່ງໃສແລະເຂົ້າໃຈສະເຫມີ. ມັນເປັນການຍາກສໍາລັບລູກຄ້າທີ່ຈະປະເມີນຄວາມສ່ຽງທີ່ແທ້ຈິງທີ່ກ່ຽວຂ້ອງກັບຂະບວນການການເຄື່ອນຍ້າຍ. ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າການເຄື່ອນຍ້າຍສໍາລັບລູກຄ້າແມ່ນປະເພດຂອງກ່ອງດໍາ: ມັນບໍ່ຊັດເຈນ, ລາຄາ, ການຢຸດເຊົາຂອງລະບົບ, ຄວາມສ່ຽງແລະວິທີການຫຼຸດຜ່ອນພວກມັນ, ແລະໂດຍທົ່ວໄປແລ້ວມັນກໍ່ແມ່ນຄວາມມືດແລະຫນ້າຢ້ານ. ມັນຄ້າຍຄື, ຖ້າມັນບໍ່ໄດ້ຜົນ, ຫຼັງຈາກນັ້ນຫົວຈະມ້ວນທັງຢູ່ເທິງສຸດແລະໃນນັກສະແດງ.

SAP ແມ່ນລະບົບລະດັບວິສາຫະກິດ, ສະລັບສັບຊ້ອນແລະ, ເຮັດໃຫ້ມັນອ່ອນໂຍນ, ບໍ່ແມ່ນລາຄາຖືກ. ງົບປະມານທີ່ເຫມາະສົມແມ່ນໃຊ້ເຂົ້າໃນການປະຕິບັດ, ການແກ້ໄຂ, ບໍາລຸງຮັກສາ, ແລະຊີວິດຂອງວິສາຫະກິດແມ່ນຂຶ້ນກັບຄວາມພ້ອມແລະການປະຕິບັດທີ່ຖືກຕ້ອງ. ຕອນນີ້ຈິນຕະນາການເຖິງຜົນສະທ້ອນຂອງການຢຸດເຊົາການຜະລິດຂະຫນາດໃຫຍ່ບາງຢ່າງ. ເຫຼົ່ານີ້ແມ່ນການສູນເສຍທາງດ້ານການເງິນ, ເຊິ່ງສາມາດຄິດໄລ່ເປັນຕົວເລກທີ່ມີຈໍານວນສູນຫຼາຍ, ເຊັ່ນດຽວກັນກັບຄວາມສ່ຽງດ້ານຊື່ສຽງແລະຄວາມສ່ຽງອື່ນໆທີ່ເທົ່າທຽມກັນ.

ພວກເຮົາຈະວິເຄາະຄວາມຫຍຸ້ງຍາກທີ່ອາດຈະເກີດຂື້ນໃນແຕ່ລະຂັ້ນຕອນໃນກໍລະນີຂອງການເຄື່ອນຍ້າຍລະບົບ SAP ຈາກຫນຶ່ງໃນລູກຄ້າຂອງພວກເຮົາ.

ການກະກຽມແລະການອອກແບບ

ການເຄື່ອນຍ້າຍແມ່ນສູດທີ່ມີຫຼາຍພາກສ່ວນທີ່ແຕກຕ່າງກັນ. ແລະຫນຶ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນຂັ້ນຕອນຂອງການອອກແບບແລະການກະກຽມໂຄງສ້າງພື້ນຖານ (ໃຫມ່) ເປົ້າຫມາຍ.

ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ dive ເຂົ້າ​ໄປ​ໃນ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ມີ​ຢູ່​ແລ້ວ​ຂອງ​ລະ​ບົບ​, ສະ​ຖາ​ປັດ​ຕະ​ຂອງ​ເຂົາ​ເຈົ້າ​. ໃນໂຄງສ້າງພື້ນຖານເປົ້າຫມາຍ, ພວກເຮົາໄດ້ເຮັດຊ້ໍາການແກ້ໄຂທີ່ມີຢູ່ແລ້ວຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ, ເສີມແລະປັບປຸງມັນໃນບາງຈຸດ, ແກ້ໄຂມັນຄືນໃຫມ່ບາງບ່ອນ, ຄິດຜ່ານແລະເລືອກວິທີແກ້ໄຂເພື່ອຮັບປະກັນຄວາມທົນທານແລະຄວາມພ້ອມ, ແລະຍັງໄດ້ລວບລວມຊັບພະຍາກອນທັງຫມົດເທົ່າທີ່ເປັນໄປໄດ້.

ໃນລະຫວ່າງຂະບວນການອອກແບບ, ການອອກກໍາລັງກາຍທີ່ແຕກຕ່າງກັນຫຼາຍໄດ້ຖືກປະຕິບັດ, ເຊິ່ງໃນທີ່ສຸດເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະກະກຽມຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ສໍາລັບການເຄື່ອນຍ້າຍແລະຄໍານຶງເຖິງທຸກປະເພດຂອງ nuances ແລະ pitfalls (ເພີ່ມເຕີມກ່ຽວກັບໃຫ້ເຂົາເຈົ້າຕໍ່ມາ).

ສິ່ງທີ່ພວກເຮົາຈົບລົງແມ່ນໂຄງສ້າງພື້ນຖານຄລາວທີ່ອອກແບບສະເພາະສ່ວນບຸກຄົນໂດຍອີງໃສ່ສູນຂໍ້ມູນຂອງພວກເຮົາ:

• ເຊີບເວີທີ່ອຸທິດຕົນສໍາລັບ SAP HANA;
• ເວທີ virtualization VMware ສໍາລັບເຄື່ອງແມ່ຂ່າຍຄໍາຮ້ອງສະຫມັກແລະການບໍລິການພື້ນຖານໂຄງລ່າງ;
• ຊ່ອງທາງການສື່ສານທີ່ຊ້ໍາກັນລະຫວ່າງສູນຂໍ້ມູນສໍາລັບ L2 VPN;
• ສອງລະບົບການເກັບຮັກສາຕົ້ນຕໍສໍາລັບການແຍກຜະລິດຕະພັນແລະ "ທຸກສິ່ງທຸກຢ່າງອື່ນ";
• SRC ອີງໃສ່ Veritas Netbackup ກັບເຊີບເວີແຍກຕ່າງຫາກ, ຊັ້ນວາງແຜ່ນແລະຫ້ອງສະຫມຸດ tape.

ແລະນີ້ແມ່ນວິທີທີ່ພວກເຮົາປະຕິບັດທັງຫມົດນີ້ຈາກທັດສະນະດ້ານວິຊາການ.

SAP

• ເພື່ອນຳໃຊ້ບ່ອນເກັບຂໍ້ມູນໃຫ້ມີປະສິດທິພາບ HANA, ພວກເຮົາໄດ້ໃຊ້ແຜ່ນທີ່ແບ່ງປັນໂດຍບໍ່ມີການຈຳລອງຖານຂໍ້ມູນລະບົບໂດຍໃຊ້ SAP. ທັງໝົດນີ້ໄດ້ຖືກຫໍ່ຢູ່ໃນກຸ່ມ Active-Standby SUSE HAE ໂດຍອີງໃສ່ Pacemaker. ແມ່ນແລ້ວ, ໄລຍະເວລາການຟື້ນຕົວແມ່ນຍາວກວ່າການຈໍາລອງເລັກນ້ອຍ, ແຕ່ພວກເຮົາປະຫຍັດພື້ນທີ່ຈັດເກັບຂໍ້ມູນເຄິ່ງໜຶ່ງ ແລະ, ດັ່ງນັ້ນ, ປະຫຍັດງົບປະມານຂອງລູກຄ້າ.
• ໃນສະພາບແວດລ້ອມກ່ອນການຜະລິດ, ກຸ່ມ HANA ຖືກປະຖິ້ມ, ແຕ່ໃນທາງດ້ານວິຊາການ, ການຕັ້ງຄ່າການຜະລິດແມ່ນຊ້ໍາກັນ.
• ສະພາບແວດລ້ອມການທົດສອບ ແລະການພັດທະນາໄດ້ຖືກແຈກຢາຍໃນທົ່ວເຊີບເວີຫຼາຍອັນໂດຍບໍ່ມີກຸ່ມຢູ່ໃນການຕັ້ງຄ່າ MCOS.
• ເຊີບເວີແອັບພລິເຄຊັນທັງໝົດຖືກສ້າງເປັນ virtualized ແລະໂຮດຢູ່ໃນ VMware.

ບັນທຶກການເຂົ້າ

• ພວກ​ເຮົາ​ໄດ້​ແຍກ​ຮູບ​ຮ່າງ​ຂອງ​ການ​ຄວບ​ຄຸມ ແລະ​ເຄືອ​ຂ່າຍ​ການ​ຜະ​ລິດ​ອອກ​ດ້ວຍ​ສະ​ຫຼັບ​ສະ​ຫຼັບ, ປ່ຽນ​ຮູບ​ແບບ​ຜະ​ລິດ​ຕະ​ພັນ​ໄປ​ຫາ​ສູນ​ຂໍ້​ມູນ​ຂອງ​ລູກ​ຄ້າ.
• ພວກ​ເຮົາ​ໄດ້​ຕິດ​ຕັ້ງ​ຈໍາ​ນວນ​ທີ່​ພຽງ​ພໍ​ຂອງ​ການ​ໂຕ້​ຕອບ​ເຄືອ​ຂ່າຍ​ເພື່ອ​ບໍ່​ໃຫ້​ປະ​ສົມ​ການ​ຈະ​ລາ​ຈອນ​ຂະ​ຫນາດ​ໃຫຍ່​.
• ເພື່ອໂອນຂໍ້ມູນຈາກລະບົບການເກັບຮັກສາ, ພວກເຮົາໄດ້ສ້າງໂຮງງານຜະລິດ FC SAN ຄລາສສິກ.

SHD

• ການໂຫຼດຂອງ SAP ທີ່ມີຜົນຜະລິດແລະກ່ອນການຜະລິດໄດ້ຖືກປະໄວ້ຢູ່ໃນອາເລ flash ທັງຫມົດ.
• ສະພາບແວດລ້ອມການທົດສອບຂອງຜູ້ພັດທະນາ ແລະການບໍລິການພື້ນຖານໂຄງລ່າງໄດ້ຖືກວາງໄວ້ໃນອາເຣແບບປະສົມແຍກຕ່າງຫາກ.

IBS

• ຜະລິດໂດຍໃຊ້ Veritas Netbackup.
• ພວກ​ເຮົາ​ໄດ້​ເພີ່ມ​ເລັກ​ນ້ອຍ​ໃນ​ຕົວ​ອັກ​ສອນ​ໃນ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ການ​ຕັ້ງ​ຄ່າ MCOS​.
• ພວກເຮົາເອົາສໍາເນົາປະຕິບັດການຢູ່ໃນຊັ້ນວາງຂອງແຜ່ນສໍາລັບການຟື້ນຕົວໄວ, ແລະພວກເຮົາໃຊ້ tapes ສໍາລັບການເກັບຮັກສາໃນໄລຍະຍາວ.

ການຕິດຕາມ

• ຮາດແວ, OS ແລະ SAP ທັງໝົດຖືກຕິດຕັ້ງພາຍໃຕ້ Zabbix.
• ພວກເຮົາໄດ້ເກັບກໍາ dashboards ທີ່ເປັນປະໂຫຍດຫຼາຍໃນ Grafana.
• ເມື່ອການແຈ້ງເຕືອນເກີດຂຶ້ນ, Zabbix ສາມາດສ້າງຄໍາຮ້ອງຂໍໃນລະບົບການຈັດການເຫດການ; ພວກເຮົາໄດ້ປະຕິບັດມັນຢູ່ໃນ Jira. ຂໍ້ມູນຍັງຊໍ້າກັນຢູ່ໃນຊ່ອງທາງ Telegram.

ໂທລະເລກ

ສຸຂະພາບທົ່ວໄປຂອງ HANA

ສະຖານະ SAP Application Server:

ການບໍລິການພື້ນຖານໂຄງລ່າງ

• ເພື່ອໃຫ້ບໍລິການ namespaces ພາຍໃນ, ກຸ່ມຂອງເຄື່ອງແມ່ຂ່າຍ DNS ໄດ້ຖືກຍົກຂຶ້ນມາ, ເຊິ່ງ synchronized ກັບເຄື່ອງແມ່ຂ່າຍຂອງລູກຄ້າ.
• ພວກເຮົາສ້າງເຄື່ອງແມ່ຂ່າຍໄຟລ໌ແຍກຕ່າງຫາກສໍາລັບການແລກປ່ຽນຂໍ້ມູນ.
• ເພື່ອເກັບຮັກສາການຕັ້ງຄ່າຕ່າງໆ, Gitlab ໄດ້ຖືກເພີ່ມ.
• ສໍາລັບຂໍ້ມູນລະອຽດອ່ອນຕ່າງໆ, ພວກເຮົາເອົາ HashiCorp Vault.

ຂະບວນການຍົກຍ້າຍ

ໂດຍທົ່ວໄປ, ຂະບວນການເຄື່ອນຍ້າຍປະກອບດ້ວຍຂັ້ນຕອນດັ່ງຕໍ່ໄປນີ້:

• ການກະກຽມເອກະສານໂຄງການທີ່ຈໍາເປັນທັງຫມົດ;
• ການເຈລະຈາກັບຜູ້ໃຫ້ບໍລິການໃນປະຈຸບັນ - ແກ້ໄຂບັນຫາອົງການຈັດຕັ້ງ;
• ການຊື້, ການຈັດສົ່ງແລະການຕິດຕັ້ງອຸປະກອນໃຫມ່ສໍາລັບໂຄງການ;
• ການທົດສອບການເຄື່ອນຍ້າຍແລະຂະບວນການ debugging;
• ການ​ຍົກ​ຍ້າຍ​ລະ​ບົບ​, ການ​ເຄື່ອນ​ຍ້າຍ​ການ​ຕໍ່​ສູ້​.

ໃນທ້າຍເດືອນຕຸລາ 2019, ພວກເຮົາໄດ້ເຊັນສັນຍາ, ຫຼັງຈາກນັ້ນໄດ້ອອກແບບສະຖາປັດຕະຍະກໍາ, ແລະຫຼັງຈາກຕົກລົງກັບລູກຄ້າ, ພວກເຮົາສັ່ງຊື້ອຸປະກອນທີ່ຈໍາເປັນ.

ສິ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່ທໍາອິດແມ່ນເວລາການຈັດສົ່ງຂອງອຸປະກອນ. ໂດຍສະເລ່ຍ, ການຈັດສົ່ງຮາດແວທີ່ໄດ້ຮັບການຮັບຮອງສໍາລັບ SAP NAHA ທີ່ຕອບສະຫນອງຄວາມຕ້ອງການຂອງຜູ້ຜະລິດຊອບແວສໍາລັບເວທີຮາດແວໃຊ້ເວລາ 10-12 ອາທິດ. ແລະຄໍານຶງເຖິງລະດູການ (ການຈັດຕັ້ງປະຕິບັດໂຄງການຫຼຸດລົງແນ່ນອນໃນປີໃຫມ່), ໄລຍະເວລານີ້ສາມາດເພີ່ມຂຶ້ນອີກຫນຶ່ງເດືອນ. ຕາມ​ນັ້ນ​ແລ້ວ, ຕ້ອງ​ເລັ່ງລັດ​ຂະ​ບວນການ​ດັ່ງກ່າວ​ໃຫ້​ໄວ​ເທົ່າ​ທີ່​ຈະ​ເປັນ​ໄປ​ໄດ້: ພວກ​ເຮົາ​ໄດ້​ເຮັດ​ວຽກ​ຮ່ວມ​ກັບ​ຜູ້​ຈັດ​ຈຳໜ່າຍ ​ແລະ ຕົກລົງ​ໃນ​ການ​ສົ່ງ​ສິນຄ້າ​ໂດຍ​ຍົນ​ໂດຍ​ໄວ (​ແທນ​ເສັ້ນທາງ​ທາງບົກ ​ແລະ ທາງ​ທະ​ເລ).

ເດືອນ​ພະ​ຈິກ​ແລະ​ເດືອນ​ທັນ​ວາ​ໄດ້​ໃຊ້​ເວ​ລາ​ໃນ​ການ​ກະ​ກຽມ​ສໍາ​ລັບ​ການ​ເຄື່ອນ​ຍ້າຍ​ແລະ​ໄດ້​ຮັບ​ອຸ​ປະ​ກອນ​ບາງ​ສ່ວນ​. ພວກເຮົາໄດ້ປະຕິບັດການກະກຽມຢູ່ໃນຫ້ອງທົດລອງຢູ່ໃນເມຄສາທາລະນະຂອງພວກເຮົາ, ບ່ອນທີ່ພວກເຮົາໄດ້ເຮັດວຽກໂດຍຜ່ານຂັ້ນຕອນຕົ້ນຕໍທັງຫມົດແລະຈັບຄວາມຫຍຸ້ງຍາກແລະບັນຫາທີ່ເປັນໄປໄດ້:

• ກະກຽມແຜນການລະອຽດສໍາລັບການພົວພັນລະຫວ່າງສະມາຊິກທີມງານໂຄງການທີ່ມີເວລານາທີຕໍ່ນາທີ;
• ການກໍ່ສ້າງ bench ການທົດສອບສໍາລັບຖານຂໍ້ມູນແລະເຄື່ອງແມ່ຂ່າຍຂອງຄໍາຮ້ອງສະຫມັກໃນລັກສະນະດຽວກັນກັບໂຄງສ້າງພື້ນຖານເປົ້າຫມາຍ;
• ກໍານົດຊ່ອງທາງການສື່ສານທີ່ຈໍາເປັນແລະການບໍລິການພື້ນຖານໂຄງລ່າງເພື່ອທົດສອບການດໍາເນີນງານຂອງການເຊື່ອມໂຍງ;
• ໄດ້ເຮັດວຽກອອກສະຖານະການ cutover;
• ຄລາວຍັງໄດ້ຊ່ວຍພວກເຮົາສ້າງແມ່ແບບເຄື່ອງ virtual ທີ່ຖືກຕັ້ງຄ່າໄວ້ກ່ອນ, ເຊິ່ງພວກເຮົາພຽງແຕ່ນໍາເຂົ້າແລະນໍາໃຊ້ກັບພູມສັນຖານເປົ້າຫມາຍ.

ບໍ່ດົນກ່ອນວັນພັກປີໃຫມ່, ອຸປະກອນຊຸດທໍາອິດມາຮອດພວກເຮົາ. ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະນໍາໃຊ້ບາງລະບົບໃນຮາດແວທີ່ແທ້ຈິງ. ເນື່ອງຈາກບໍ່ໄດ້ມາຮອດທຸກສິ່ງທຸກຢ່າງ, ພວກເຮົາເຊື່ອມຕໍ່ອຸປະກອນທົດແທນ, ການສະຫນອງທີ່ພວກເຮົາໄດ້ຕົກລົງເຫັນດີກັບຜູ້ຂາຍແລະຜູ້ຈັດຈໍາຫນ່າຍ. ພວກເຮົາໄດ້ຮັບຊາກຂອງໂຄງສ້າງພື້ນຖານເປົ້າຫມາຍໃນຂັ້ນຕອນສຸດທ້າຍ.
ເພື່ອໃຫ້ໄດ້ຕາມກໍານົດເວລາ, ວິສະວະກອນຂອງພວກເຮົາຕ້ອງເສຍສະລະວັນພັກປີໃຫມ່ແລະເລີ່ມເຮັດວຽກໃນການກະກຽມພື້ນຖານໂຄງລ່າງເປົ້າຫມາຍໃນວັນທີ 2 ມັງກອນ, ໃນທ່າມກາງວັນພັກ. ແມ່ນແລ້ວ, ບາງຄັ້ງນີ້ເກີດຂື້ນໃນເວລາທີ່ໄຟໄຫມ້ແລະບໍ່ມີທາງເລືອກອື່ນ. ຄວາມສ່ຽງແມ່ນການປະຕິບັດຂອງລະບົບທີ່ຊີວິດຂອງວິສາຫະກິດຂຶ້ນກັບ.

ຄໍາສັ່ງທົ່ວໄປຂອງການເຄື່ອນຍ້າຍເບິ່ງຄືວ່າ: ທໍາອິດ, ລະບົບທີ່ສໍາຄັນຫນ້ອຍ (ພູມສັນຖານການພັດທະນາ, ພູມສັນຖານການທົດສອບ), ຫຼັງຈາກນັ້ນລະບົບການຜະລິດ. ຂັ້ນຕອນສຸດທ້າຍຂອງການເຄື່ອນຍ້າຍໄດ້ຈັດຂຶ້ນໃນທ້າຍເດືອນມັງກອນແລະຕົ້ນເດືອນກຸມພາ.

ຂະບວນການເຄື່ອນຍ້າຍໄດ້ຖືກວາງແຜນລົງເຖິງນາທີ. ນີ້​ແມ່ນ​ແຜນ​ການ​ຕັດ​ສິນ​ມີ​ບັນ​ຊີ​ລາຍ​ການ​ຂອງ​ວຽກ​ງານ​ທັງ​ຫມົດ​, ເວ​ລາ​ສໍາ​ເລັດ​ຮູບ​ແລະ​ຜູ້​ຮັບ​ຜິດ​ຊອບ​. ຂັ້ນຕອນທັງຫມົດໄດ້ຖືກປະຕິບັດແລ້ວໃນການເຄື່ອນຍ້າຍການທົດສອບ, ດັ່ງນັ້ນໃນການເຄື່ອນຍ້າຍແບບສົດໆມັນເປັນສິ່ງຈໍາເປັນພຽງແຕ່ປະຕິບັດຕາມແຜນການແລະປະສານງານຂະບວນການ.

ການເຄື່ອນຍ້າຍໄດ້ຖືກປະຕິບັດຢ່າງເປັນລະບົບໃນຫຼາຍຂັ້ນຕອນ. ມີສອງລະບົບໃນແຕ່ລະຂັ້ນຕອນ.

ຜົນໄດ້ຮັບຂອງການແລ່ນສາມເດືອນແມ່ນລະບົບທີ່ເຮັດວຽກຢ່າງເຕັມທີ່ຢູ່ໃນສູນຂໍ້ມູນ CROC. ໂດຍທົ່ວໄປ, ຜົນໄດ້ຮັບໃນທາງບວກແມ່ນບັນລຸໄດ້ໂດຍຜ່ານການເຮັດວຽກເປັນທີມ; ການປະກອບສ່ວນແລະການອຸທິດຕົນຂອງຜູ້ເຂົ້າຮ່ວມທັງຫມົດໃນຂະບວນການແມ່ນສູງສຸດ.

ບົດບາດຂອງລູກຄ້າໃນໂຄງການ

ການສື່ສານກັບຜູ້ໃຫ້ບໍລິການທີ່ລູກຄ້າຂອງພວກເຮົາໄດ້ອອກໄປບໍ່ແມ່ນເລື່ອງງ່າຍ. ນີ້ແມ່ນເຂົ້າໃຈໄດ້; ພວກເຂົາເປັນຄົນສຸດທ້າຍໃນບັນຊີລາຍຊື່ຜູ້ທີ່ສົນໃຈໃນການສໍາເລັດໂຄງການ. ລູກຄ້າໄດ້ປະຕິບັດວຽກງານຂອງ escalating ແລະ pedaling ບັນຫາການສື່ສານທັງຫມົດແລະຮັບມືກັບນີ້ 100500%. ຂໍ​ຂອບ​ໃຈ​ລາວ​ເປັນ​ພິ​ເສດ​ສໍາ​ລັບ​ການ​ນີ້​. ໂດຍບໍ່ມີການມີສ່ວນຮ່ວມທີ່ເປັນໄປໄດ້ໃນຂະບວນການດັ່ງກ່າວ, ຜົນໄດ້ຮັບຂອງໂຄງການອາດຈະແຕກຕ່າງກັນຫມົດ.

ເນື່ອງຈາກຂະບວນການຢ່າງເປັນທາງການຢູ່ຂ້າງຂອງຜູ້ໃຫ້ບໍລິການ "ອະດີດ", ການສະຫນັບສະຫນູນພື້ນຖານໂຄງລ່າງໄດ້ຖືກປະຕິບັດໂດຍຜູ້ຊ່ຽວຊານທີ່ຮູ້ຫນັງສືຢູ່ໄກຈາກບັນຫາ, ໃນເວລານັ້ນຍັງເປັນລູກຄ້າຂອງພວກເຂົາ. ຕົວຢ່າງ, ຂະບວນການສົ່ງອອກຖານຂໍ້ມູນດຽວກັນສາມາດໃຊ້ເວລາຈາກຫນຶ່ງຊົ່ວໂມງຫາຫ້າ. ຫຼັງຈາກນັ້ນ, ມັນເບິ່ງຄືວ່ານີ້ແມ່ນບາງປະເພດຂອງ magic, ຄວາມລັບທີ່ບໍ່ເຄີຍເປີດເຜີຍໃຫ້ພວກເຮົາ. ອາດຈະເປັນວິສະວະກອນສະຫນັບສະຫນູນດ້ານວິຊາການ indulged ໃນສະມາທິໃນເວລານີ້, ລືມວ່າບາງບ່ອນໃນລັດເຊຍຫ່າງໄກມີກໍານົດເວລາ, ວິສະວະກອນທີ່ບໍ່ມີສະຫຼັດປີໃຫມ່, ລູກຄ້າແມ່ນຮ້ອງໄຫ້ແລະທຸກທໍລະມານ ...

ຜົນໄດ້ຮັບຂອງໂຄງການ

ຂັ້ນຕອນສຸດທ້າຍຂອງການເຄື່ອນຍ້າຍແມ່ນການໂອນລະບົບສໍາລັບການບໍາລຸງຮັກສາ.

ໃນປັດຈຸບັນພວກເຮົາໃຫ້ບໍລິການປ່ອງຢ້ຽມດຽວສໍາລັບການຮ້ອງຂໍຂອງລູກຄ້າແລະກວມເອົາຂອບເຂດທັງຫມົດຂອງວຽກງານທີ່ກ່ຽວຂ້ອງກັບການສະຫນັບສະຫນູນອົງປະກອບໂຄງສ້າງພື້ນຖານແລະພື້ນຖານ SAP ຮ່ວມກັບຄູ່ຮ່ວມງານຂອງພວກເຮົາ - itelligence . ລູກຄ້າໄດ້ອາໄສຢູ່ໃນເມຄສ່ວນຕົວເປັນເວລາຫົກເດືອນ. ນີ້ແມ່ນສະຖິຕິກ່ຽວກັບກໍລະນີການບໍລິການໃນຊ່ວງເວລານີ້:

• 90 ເຫດການ (20% ແກ້ໄຂໂດຍບໍ່ມີການພົວພັນກັບລູກຄ້າ)
• ແກ້ໄຂພາຍໃນ SLA – 100%
• ການປິດລະບົບທີ່ບໍ່ໄດ້ກຳນົດເວລາ – 0

ຖ້າທ່ານມີບັນຫາທີ່ຄ້າຍຄືກັນກັບລູກຄ້າຂອງພວກເຮົາ, ແລະທ່ານຕ້ອງການຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວິທີແກ້ໄຂບັນຫາ, ຂຽນໄປທີ່: [email protected]

ແຫຼ່ງຂໍ້ມູນ: www.habr.com