ประสบการณ์ในการเปลี่ยนแปลงโฮสติ้ง SAP: วิธีโยกย้ายระบบโดยไม่ต้องเจ็บปวดแสนสาหัส

หรือเป็นไปได้? แน่นอนว่าการย้ายระบบ SAP เป็นกระบวนการที่ซับซ้อนและต้องใช้ความอุตสาหะ ซึ่งความสำเร็จนั้นต้องอาศัยการทำงานร่วมกันอย่างดีของผู้เข้าร่วมทุกคน และหากดำเนินการย้ายข้อมูลภายในระยะเวลาอันสั้น งานก็จะซับซ้อนมากขึ้น ไม่ใช่ทุกคนที่ตัดสินใจทำเช่นนี้ อาจมีสาเหตุหลายประการ ตัวอย่างเช่น กระบวนการนั้นมีความยาวและซับซ้อนในองค์กร อีกทั้งยังมีความเสี่ยงที่ระบบจะหยุดทำงานโดยไม่ได้วางแผนไว้อีกด้วย หรือลูกค้าไม่แน่ใจว่าเมื่อดำเนินการดังกล่าวแล้วจะได้รับผลประโยชน์สมกับความพยายามที่ใช้ไป อย่างไรก็ตาม มีข้อยกเว้นอยู่

ด้านล่างสุด เราจะพูดถึงความยากลำบากที่ลูกค้าเผชิญในกระบวนการย้ายและบำรุงรักษาระบบ SAP อภิปรายว่าทำไมภาพเหมารวมจึงไม่สอดคล้องกับความเป็นจริงเสมอไป และแบ่งปันกรณีศึกษาว่าเราจัดการอย่างไรเพื่อย้ายระบบของลูกค้าไปยัง โครงสร้างพื้นฐานใหม่ในเวลาเพียงสามเดือน

โฮสติ้งระบบ SAP

เมื่อห้าปีที่แล้ว เป็นเรื่องยากที่จะจินตนาการว่าลูกค้าจะเริ่มใช้ทรัพยากรโฮสติ้งสำหรับแอปพลิเคชัน SAP เป็นจำนวนมาก ในกรณีส่วนใหญ่ จะมีการใช้งานในสถานที่ อย่างไรก็ตาม ด้วยการพัฒนาโมเดลเอาท์ซอร์สและตลาดบริการคลาวด์ โลกทัศน์ของลูกค้าก็เริ่มเปลี่ยนไป ข้อโต้แย้งที่มีอิทธิพลต่อการเลือกใช้ระบบคลาวด์สำหรับ SAP คืออะไร

• สำหรับผู้เริ่มต้นที่เพิ่งวางแผนที่จะใช้ SAP โครงสร้างพื้นฐานคลาวด์เกือบจะเป็นทางเลือกมาตรฐาน - ความสามารถในการปรับขนาดของทรัพยากรให้ตรงกับความต้องการในปัจจุบันของระบบและไม่เต็มใจที่จะเปลี่ยนทรัพยากรไปสู่การพัฒนาความสามารถที่ไม่ใช่ระบบหลัก
• ในบริษัทที่มีภูมิทัศน์ระบบขนาดใหญ่ ด้วยความช่วยเหลือจากการโฮสต์ระบบ SAP CIO เข้าถึงระดับการบริหารความเสี่ยงที่แตกต่างกันในเชิงคุณภาพ เนื่องจาก คู่ค้ามีหน้าที่รับผิดชอบ SLA
• ข้อโต้แย้งที่พบบ่อยที่สุดประการที่สามคือต้นทุนที่สูงในการสร้างโครงสร้างพื้นฐานเพื่อปรับใช้สถานการณ์ความพร้อมใช้งานสูงและ DR
• ปัจจัยปี 2027 – ผู้จำหน่ายประกาศสิ้นสุดการสนับสนุนระบบเดิมในปี 2027 นี่หมายถึงการถ่ายโอนฐานข้อมูลไปยัง HANA ซึ่งมีค่าใช้จ่ายสำหรับการปรับปรุงให้ทันสมัยและการซื้อพลังการประมวลผลใหม่

ตลาดโฮสติ้ง SAP ในรัสเซียตอนนี้ถือว่าค่อนข้างสมบูรณ์แล้ว และนี่เป็นโอกาสที่เพียงพอสำหรับลูกค้าที่ต้องการเปลี่ยนแพลตฟอร์มโฮสติ้งของตน อย่างไรก็ตาม โครงการดังกล่าวสามารถก่อให้เกิดความกังวลในหมู่ธุรกิจได้อย่างถูกต้อง เนื่องจากขั้นตอนการย้ายถิ่นมีความซับซ้อน สิ่งนี้บังคับให้ลูกค้าวางความต้องการที่เพิ่มขึ้นจากผู้ให้บริการ ซึ่งไม่เพียงแต่ต้องมีความสามารถพิเศษในการโฮสต์และบำรุงรักษาระบบ SAP เท่านั้น แต่ยังต้องมีประสบการณ์ที่ประสบความสำเร็จในด้านการย้ายข้อมูลด้วย

ความยากในการเปลี่ยนโฮสติ้ง SAP คืออะไร?

โฮสติ้งจะแตกต่างกัน ความไม่สอดคล้องกับระดับการบริการที่ประกาศ, “แต่” และเครื่องหมายดอกจันจำนวนมากพร้อมการจองเป็นข้อความขนาดเล็ก, ทรัพยากรและความสามารถของผู้ให้บริการโฮสติ้งที่จำกัด, ขาดความยืดหยุ่นในเรื่องของการสื่อสารกับลูกค้า, ระบบราชการ, ข้อจำกัดทางเทคนิค, ความสามารถต่ำในการสนับสนุนทางเทคนิค ผู้เชี่ยวชาญ รวมถึงความแตกต่างอื่นๆ อีกมากมาย นี่เป็นเพียงส่วนเล็กๆ ของข้อผิดพลาดที่ลูกค้าอาจพบเมื่อใช้งานระบบธุรกิจในโครงสร้างพื้นฐานเอาท์ซอร์ส บ่อยครั้งสำหรับลูกค้า ทั้งหมดนี้ยังคงอยู่ในเงามืด อยู่ในป่าของสัญญาหลายหน้า และปรากฏในกระบวนการใช้บริการ

เมื่อถึงจุดหนึ่ง ลูกค้าจะเห็นได้ชัดว่าระดับการบริการที่เขาได้รับนั้นอยู่ไกลจากความคาดหวังของเขา ถือเป็นตัวเร่งในการหาแนวทางแก้ไขสถานการณ์ และหากล้มเหลว เมื่อปัญหาสะสมจนเกินขีดจำกัดจนเจ็บปวดมากก็จะเดินหน้าไปสู่การดำเนินการเชิงรุกเพื่อพัฒนาทางเลือกทางเลือกในทิศทางการเปลี่ยนแปลงผู้ให้บริการ .

ทำไมพวกเขาถึงรอจนถึงนาทีสุดท้าย? เหตุผลนั้นง่ายมาก - กระบวนการย้ายระบบสำหรับลูกค้าไม่โปร่งใสและเข้าใจได้เสมอไป เป็นเรื่องยากสำหรับลูกค้าที่จะประเมินความเสี่ยงที่แท้จริงที่เกี่ยวข้องกับกระบวนการย้ายข้อมูล เราสามารถพูดได้ว่าการย้ายข้อมูลสำหรับลูกค้าเป็นเหมือนกล่องดำ: มันไม่ชัดเจน, ราคา, การหยุดทำงานของระบบ, ความเสี่ยงและวิธีบรรเทาผลกระทบ โดยทั่วไปแล้วมันมืดมนและน่ากลัว มันเหมือนกับว่าถ้าไม่ได้ผล หัวก็จะกลิ้งทั้งด้านบนและที่นักแสดง

SAP เป็นระบบระดับองค์กร ซับซ้อน และพูดง่ายๆ ว่าไม่ถูก มีการใช้งบประมาณที่เหมาะสมไปกับการใช้งาน การปรับเปลี่ยน และการบำรุงรักษา และอายุการใช้งานขององค์กรขึ้นอยู่กับความพร้อมใช้งานและการดำเนินการที่ถูกต้อง ลองจินตนาการถึงผลที่ตามมาจากการหยุดการผลิตจำนวนมาก สิ่งเหล่านี้คือความสูญเสียทางการเงิน ซึ่งสามารถคำนวณเป็นตัวเลขโดยมีค่าศูนย์จำนวนมาก รวมถึงความเสี่ยงด้านชื่อเสียงและความเสี่ยงอื่นๆ ที่มีนัยสำคัญเท่าเทียมกัน

เราจะวิเคราะห์ปัญหาที่อาจเกิดขึ้นในแต่ละขั้นตอนในกรณีของการย้ายระบบ SAP จากลูกค้าของเรารายหนึ่ง

การเตรียมการและการออกแบบ

การย้ายถิ่นเป็นสูตรที่มีส่วนต่างๆ มากมาย และที่สำคัญที่สุดประการหนึ่งคือขั้นตอนของการออกแบบและเตรียมโครงสร้างพื้นฐานเป้าหมาย (ใหม่)

เราจำเป็นต้องเจาะลึกถึงการใช้งานระบบและสถาปัตยกรรมที่มีอยู่ ในโครงสร้างพื้นฐานเป้าหมาย เราได้ทำซ้ำโซลูชันที่มีอยู่บางแห่ง เสริมและปรับปรุงในบางจุด แก้ไขใหม่ที่ไหนสักแห่ง คิดอย่างรอบคอบและเลือกโซลูชันเพื่อให้แน่ใจว่าทนทานต่อข้อผิดพลาดและความพร้อมใช้งาน และยังรวบรวมทรัพยากรทั้งหมดให้มากที่สุด

ในระหว่างขั้นตอนการออกแบบ ได้มีการดำเนินการฝึกซ้อมต่างๆ มากมาย ซึ่งท้ายที่สุดแล้วทำให้สามารถเตรียมการโยกย้ายได้มากที่สุดเท่าที่จะเป็นไปได้ และคำนึงถึงความแตกต่างและข้อผิดพลาดทุกประเภท (จะมีรายละเอียดเพิ่มเติมในภายหลัง)

สิ่งที่เราได้คือโครงสร้างพื้นฐานคลาวด์ส่วนตัวที่ออกแบบเฉพาะตัวโดยอิงตามศูนย์ข้อมูลของเรา:

• ฟิสิคัลเซิร์ฟเวอร์เฉพาะสำหรับ SAP HANA;
• แพลตฟอร์มการจำลองเสมือน VMware สำหรับแอปพลิเคชันเซิร์ฟเวอร์และบริการโครงสร้างพื้นฐาน
• ช่องทางการสื่อสารที่ซ้ำกันระหว่างศูนย์ข้อมูลสำหรับ L2 VPN
• ระบบจัดเก็บข้อมูลหลักสองระบบสำหรับแยกผลิตภัณฑ์และ "อย่างอื่น"
• SRC ที่ใช้ Veritas Netbackup พร้อมด้วยเซิร์ฟเวอร์ ชั้นวางดิสก์ และไลบรารีเทปที่แยกจากกัน

และนี่คือวิธีที่เราปรับใช้ทั้งหมดนี้จากมุมมองทางเทคนิค

SAP

• ในการใช้พื้นที่จัดเก็บข้อมูลเพื่อ HANA ที่มีประสิทธิภาพ เราใช้ดิสก์ที่ใช้ร่วมกันโดยไม่มีการจำลองฐานข้อมูลอย่างเป็นระบบโดยใช้ SAP ทั้งหมดนี้รวมอยู่ในคลัสเตอร์ Active-Standby SUSE HAE ที่ใช้ Pacemaker ใช่ ระยะเวลาการกู้คืนจะนานกว่าการจำลองแบบเล็กน้อย แต่เราประหยัดพื้นที่จัดเก็บข้อมูลได้ครึ่งหนึ่ง และเป็นผลให้ประหยัดงบประมาณของลูกค้า
• ในสภาพแวดล้อมก่อนการผลิตจริง คลัสเตอร์ HANA ถูกยกเลิก แต่ในทางเทคนิคแล้ว การกำหนดค่าการผลิตซ้ำแล้วซ้ำอีก
• สภาพแวดล้อมการทดสอบและการพัฒนาถูกกระจายไปยังเซิร์ฟเวอร์อื่นๆ อีกหลายเซิร์ฟเวอร์โดยไม่มีคลัสเตอร์ในการกำหนดค่า MCOS
• แอปพลิเคชันเซิร์ฟเวอร์ทั้งหมดได้รับการจำลองเสมือนและโฮสต์ใน VMware

Сети

• เราแยกโครงร่างของเครือข่ายการควบคุมและการผลิตออกทางกายภาพด้วยสแต็คสวิตช์ เพื่อเปลี่ยนสวิตช์ที่มีประสิทธิผลให้เป็นศูนย์ข้อมูลของลูกค้า
• เราติดตั้งอินเทอร์เฟซเครือข่ายในจำนวนที่เพียงพอเพื่อไม่ให้กระแสการรับส่งข้อมูลจำนวนมากปะปนกัน
• ในการถ่ายโอนข้อมูลจากระบบจัดเก็บข้อมูล เราได้สร้างโรงงาน FC SAN แบบคลาสสิก

SHD

• โหลดที่มีประสิทธิภาพและก่อนการผลิตของ SAP ถูกทิ้งไว้บนอาเรย์แบบแฟลชทั้งหมด
• สภาพแวดล้อมการทดสอบของนักพัฒนาและบริการโครงสร้างพื้นฐานถูกวางไว้บนอาเรย์ไฮบริดที่แยกจากกัน

โรคไอบีเอส

• สร้างโดยใช้ Veritas Netbackup
• เราได้เพิ่มสคริปต์ในตัวเล็กน้อยเพื่อสำรองข้อมูลการกำหนดค่า MCOS
• เราวางสำเนาการปฏิบัติงานไว้บนชั้นวางดิสก์เพื่อการกู้คืนที่รวดเร็ว และเราใช้เทปสำหรับการจัดเก็บข้อมูลระยะยาว

การตรวจสอบ

• ฮาร์ดแวร์ ระบบปฏิบัติการ และ SAP ทั้งหมดได้รับการติดตั้งภายใต้ Zabbix
• เราได้รวบรวมแดชบอร์ดที่มีประโยชน์มากมายใน Grafana
• เมื่อมีการแจ้งเตือนเกิดขึ้น Zabbix สามารถสร้างคำขอในระบบการจัดการเหตุการณ์ ซึ่งเราได้นำไปใช้กับ Jira แล้ว ข้อมูลดังกล่าวจะถูกทำซ้ำในช่องโทรเลขด้วย

Telegram

สุขภาพโดยทั่วไปของ HANA

สถานะเซิร์ฟเวอร์แอปพลิเคชัน SAP:

บริการโครงสร้างพื้นฐาน

• ในการให้บริการเนมสเปซภายใน คลัสเตอร์ของเซิร์ฟเวอร์ DNS ได้ถูกยกขึ้น ซึ่งซิงโครไนซ์กับเซิร์ฟเวอร์ของลูกค้า
• เราสร้างเซิร์ฟเวอร์ไฟล์แยกต่างหากสำหรับการแลกเปลี่ยนข้อมูล
• เพื่อจัดเก็บการกำหนดค่าต่างๆ มีการเพิ่ม Gitlab
• สำหรับข้อมูลที่ละเอียดอ่อนต่างๆ เราใช้ HashiCorp Vault

ขั้นตอนการโยกย้าย

โดยทั่วไป กระบวนการย้ายประกอบด้วยขั้นตอนต่อไปนี้:

• การเตรียมเอกสารโครงการที่จำเป็นทั้งหมด
• การเจรจากับผู้ให้บริการปัจจุบัน - การแก้ไขปัญหาขององค์กร
• การจัดซื้อ จัดส่ง และติดตั้งอุปกรณ์ใหม่สำหรับโครงการ
• ทดสอบการโยกย้ายและการดีบักกระบวนการ
• การถ่ายโอนระบบ การย้ายถิ่นการต่อสู้

เมื่อปลายเดือนตุลาคม 2019 เราได้เซ็นสัญญา จากนั้นจึงออกแบบสถาปัตยกรรม และหลังจากตกลงกับลูกค้าแล้ว เราก็สั่งซื้ออุปกรณ์ที่จำเป็น

สิ่งที่คุณต้องใส่ใจเป็นอันดับแรกคือเวลาในการจัดส่งอุปกรณ์ โดยเฉลี่ยแล้ว การส่งมอบฮาร์ดแวร์ที่ผ่านการรับรองสำหรับ SAP NAHA ซึ่งตรงตามข้อกำหนดของผู้ผลิตซอฟต์แวร์สำหรับแพลตฟอร์มฮาร์ดแวร์จะใช้เวลา 10-12 สัปดาห์ และเมื่อคำนึงถึงฤดูกาล (การดำเนินโครงการตรงกับปีใหม่พอดี) ระยะเวลานี้อาจเพิ่มขึ้นอีกเดือนหนึ่ง ดังนั้นจึงจำเป็นต้องเร่งกระบวนการให้มากที่สุด: เราทำงานร่วมกับผู้จัดจำหน่ายและซัพพลายเออร์และตกลงที่จะจัดส่งแบบเร่งด่วนทางเครื่องบิน (แทนเส้นทางทางบกและทางทะเล)

เดือนพฤศจิกายนและธันวาคมใช้เวลาในการเตรียมการอพยพและรับอุปกรณ์บางส่วน เราได้ดำเนินการเตรียมการบนม้านั่งทดสอบในระบบคลาวด์สาธารณะของเรา โดยเราได้ดำเนินการตามขั้นตอนหลักทั้งหมดและตรวจพบปัญหาและความยากลำบากที่อาจเกิดขึ้นได้:

• จัดทำแผนโดยละเอียดสำหรับการโต้ตอบระหว่างสมาชิกในทีมโครงการโดยกำหนดเวลาแบบนาทีต่อนาที
• สร้างม้านั่งทดสอบสำหรับฐานข้อมูลและเซิร์ฟเวอร์แอปพลิเคชันในลักษณะเดียวกับในโครงสร้างพื้นฐานเป้าหมาย
• กำหนดค่าช่องทางการสื่อสารและบริการโครงสร้างพื้นฐานที่จำเป็นเพื่อทดสอบการทำงานของการบูรณาการ
• คำนวณสถานการณ์การตัดทอน
• คลาวด์ยังช่วยให้เราสร้างเทมเพลตเครื่องเสมือนที่กำหนดค่าไว้ล่วงหน้า ซึ่งจากนั้นเราก็นำเข้าและปรับใช้กับแนวนอนเป้าหมาย

ก่อนวันหยุดปีใหม่ไม่นาน อุปกรณ์ชุดแรกก็มาถึงเรา ทำให้สามารถปรับใช้ระบบบางระบบกับฮาร์ดแวร์จริงได้ เนื่องจากยังมาไม่ถึงทุกอย่าง เราจึงเชื่อมต่ออุปกรณ์ทดแทน ซึ่งเป็นอุปกรณ์ที่เราจัดการเพื่อตกลงกับผู้ขายและผู้จัดจำหน่าย เราได้รับโครงสร้างพื้นฐานเป้าหมายที่เหลืออยู่ในขั้นตอนสุดท้าย
เพื่อให้เป็นไปตามกำหนดเวลา วิศวกรของเราต้องสละวันหยุดปีใหม่และเริ่มทำงานเพื่อเตรียมโครงสร้างพื้นฐานเป้าหมายในวันที่ 2 มกราคม ท่ามกลางวันหยุด ใช่ บางครั้งสิ่งนี้เกิดขึ้นเมื่อไฟลุกไหม้ และไม่มีทางเลือกอื่นเลย ความเสี่ยงคือประสิทธิภาพของระบบที่ชีวิตขององค์กรขึ้นอยู่กับ

ลำดับการโยกย้ายทั่วไปมีลักษณะดังนี้: อันดับแรก ระบบที่สำคัญที่สุด (ภาพรวมการพัฒนา ภาพรวมการทดสอบ) จากนั้นระบบที่มีประสิทธิผล ขั้นตอนสุดท้ายของการย้ายถิ่นเกิดขึ้นในช่วงปลายเดือนมกราคมถึงต้นเดือนกุมภาพันธ์

กระบวนการย้ายข้อมูลได้รับการวางแผนไว้จนถึงนาทีต่อนาที นี่คือแผนการตัดเฉือนพร้อมรายการงานทั้งหมด เวลาที่เสร็จสมบูรณ์ และผู้รับผิดชอบ ทุกขั้นตอนได้ดำเนินการไปแล้วในการทดสอบการย้ายข้อมูล ดังนั้นในการย้ายจริงจึงจำเป็นต้องปฏิบัติตามแผนและประสานงานกระบวนการ

การย้ายถิ่นดำเนินการอย่างเป็นระบบในหลายขั้นตอน มีสองระบบในแต่ละขั้นตอน

ผลลัพธ์ของการใช้เวลาสามเดือนทำให้ระบบทำงานได้เต็มรูปแบบในศูนย์ข้อมูล CROC โดยทั่วไปแล้ว การทำงานเป็นทีมจะได้รับผลลัพธ์เชิงบวก โดยการมีส่วนร่วมและการอุทิศตนของผู้เข้าร่วมทั้งหมดในกระบวนการนั้นมีค่าสูงสุด

บทบาทของลูกค้าในโครงการ

การสื่อสารกับผู้ให้บริการที่ลูกค้าของเรากำลังจะออกไปนั้นไม่ใช่เรื่องง่าย เป็นเรื่องที่เข้าใจได้เนื่องจากพวกเขาเป็นคนสุดท้ายในรายชื่อผู้ที่สนใจทำให้โครงการนี้สำเร็จ ลูกค้ารับหน้าที่ขยายและแก้ไขปัญหาการสื่อสารทั้งหมดและจัดการกับสิ่งนี้ได้ 100500% ขอขอบคุณเป็นพิเศษสำหรับสิ่งนี้ หากไม่มีการมีส่วนร่วมในกระบวนการดังกล่าว ผลลัพธ์ของโครงการอาจแตกต่างไปจากเดิมอย่างสิ้นเชิง

เนื่องจากกระบวนการที่เป็นทางการของผู้ให้บริการ "เดิม" การสนับสนุนโครงสร้างพื้นฐานจึงดำเนินการโดยผู้เชี่ยวชาญซึ่งห่างไกลจากปัญหาอย่างแท้จริง ซึ่งในขณะนั้นยังคงเป็นลูกค้าของพวกเขา ตัวอย่างเช่น กระบวนการส่งออกฐานข้อมูลเดียวกันอาจใช้เวลาตั้งแต่หนึ่งชั่วโมงถึงห้าชั่วโมง ดูเหมือนว่านี่เป็นเวทย์มนตร์บางอย่างซึ่งเป็นความลับที่ไม่เคยเปิดเผยแก่เรา ในระหว่างนี้อาจเป็นวิศวกรฝ่ายสนับสนุนด้านเทคนิคที่หมกมุ่นอยู่กับการทำสมาธิ โดยลืมไปว่าบางแห่งในรัสเซียอันห่างไกลมีกำหนดเวลา วิศวกรที่ไม่มีสลัดปีใหม่ ลูกค้าร้องไห้และทรมาน...

ผลลัพธ์ของโครงการ

ขั้นตอนสุดท้ายของการย้ายคือการโอนระบบเพื่อการบำรุงรักษา

ขณะนี้เราให้บริการแบบหน้าต่างเดียวสำหรับคำขอของลูกค้าและครอบคลุมขอบเขตงานทั้งหมดที่เกี่ยวข้องกับการสนับสนุนส่วนประกอบโครงสร้างพื้นฐานและพื้นฐานของ SAP ร่วมกับพันธมิตรของเรา - ความฉลาด ลูกค้าอาศัยอยู่ในคลาวด์ส่วนตัวเป็นเวลาหกเดือน สถิติกรณีการให้บริการในช่วงเวลานี้มีดังนี้:

• 90 เหตุการณ์ (20% แก้ไขโดยไม่เกี่ยวข้องกับลูกค้า)
• แก้ไขภายใน SLA – 100%
• การปิดระบบที่ไม่ได้กำหนดไว้ – 0

หากคุณมีปัญหาคล้ายกับปัญหาของลูกค้าของเรา และต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีแก้ปัญหา โปรดเขียนถึง: [ป้องกันอีเมล]

ที่มา: will.com