ทักษะเจ็ดประการที่ทีมของคุณต้องการหากคุณกำลังดำเนินการด้วย Open Source High Availability

ในขอบเขตของ High Availability (HA) มีทักษะที่สำคัญบางอย่างที่ทีมของคุณต้องการหากคุณตัดสินใจที่จะไปสู่เส้นทางของโอเพ่นซอร์ส โอเพนซอร์สตามคำจำกัดความหมายถึงซอฟต์แวร์ที่สามารถใช้ได้อย่างอิสระ

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

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

นี่คือทักษะเจ็ดประการที่ทีมของคุณอาจต้องการเพื่อย้ายไปยัง Open Source HA:

1. ทักษะการเขียนโค้ด

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

• ข้อกำหนดการออกแบบและสถาปัตยกรรม
• บทวิจารณ์การออกแบบ
• การตรวจสอบรหัส / รหัสและการทดสอบหน่วย (โดยเฉพาะอย่างยิ่งอัตโนมัติ)

2. ความรู้เกี่ยวกับสภาพแวดล้อมของเทคโนโลยี

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

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

3. ความรู้กระบวนการทางธุรกิจ

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

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

4. มีประสบการณ์กับระบบปฏิบัติการแอพพลิเคชั่นและโครงสร้างพื้นฐาน

หากคุณต้องการเปิดกว้างทีมของคุณจะต้องมีประสบการณ์ในการทำความเข้าใจระบบปฏิบัติการแอปพลิเคชันและโครงสร้างพื้นฐานคุณจะต้องเข้าใจรอบการเผยแพร่ OS ต่างๆรวมถึงเวอร์ชันเคอร์เนลสำหรับ Linux การอัปเดตและโปรแกรมแก้ไขด่วนสำหรับ Windowsคุณมีแอปพลิเคชันอยู่ในบ้านที่จำเป็นต้องได้รับการสนับสนุน แต่คุณจะต้องขยันหมั่นเพียรเพื่อทำความเข้าใจวงจรการอัปเดตแอปพลิเคชันการอ้างอิงและจุดตัดของแอปพลิเคชันและเมทริกซ์การสนับสนุนระบบปฏิบัติการหากสภาพแวดล้อมของคุณเป็นเนื้อเดียวกันก็ยิ่งดีมิฉะนั้นทีมของคุณจะต้องทราบความแตกต่างระหว่างอนุพันธ์ RHEL, RHEL และ SUSEหากคุณเป็นทั้ง Linux และ Windows คุณจะต้องรู้สิ่งเหล่านี้ด้วยเช่นกันนอกจากนี้คุณยังต้องเข้าใจความแตกต่างที่โครงสร้างพื้นฐานจะเกิดขึ้นกับแอปพลิเคชันและระบบปฏิบัติการร่วมกันAWS และ Azure แสดงความแตกต่างสำหรับความพร้อมใช้งานสูงซึ่งแตกต่างจาก GCP ในองค์กรและไฮเปอร์ไวเซอร์อื่น ๆ

5. เปลี่ยนความสามารถในการจัดการ

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

6. การวิเคราะห์ข้อมูลและประสบการณ์การแก้ไขปัญหา

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

7. การเชื่อมต่อ (Dev, QA, Partners, Community)

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

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

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า

ผลิตซ้ำจาก SIOS

ขั้นตอนของการกู้คืนข้อมูลจากภัยพิบัติด้านไอที

ความเศร้าโศกในการกู้คืนจากภัยพิบัติอาจทำให้คุณไม่รู้ตัวหากคุณไม่ได้ใช้สถาปัตยกรรมความพร้อมใช้งานขององค์กรที่เหมาะสม พบกับ Dave เพื่อนของเราด้านไอทีเพื่อนำเราผ่าน 5 ขั้นตอนของความเศร้าโศกจากภัยพิบัติ

ขั้นที่ 1: การปฏิเสธ

Dave in IT:“ อ๊ะนั่นคือการแจ้งเตือนอะไรแอพพลิเคชั่นขัดข้องเพียงเล็กน้อยใช่ไหมไม่ใช่เรื่องใหญ่.ฉันจะมีสิ่งต่างๆพร้อมใช้งานในเวลาไม่นาน”

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

ขั้นที่ 2: ความโกรธ

Dave in IT:“ คุณล้อเล่นฉันหรือเปล่าจากทั้งหมด…[censored] … ครั้งวันนี้แอปพลิเคชันไม่เริ่มต้นฮึฉันเกลียดแอป[censored]พลิ[censored]เคชันนี้ ……เดี๋ยวก่อนการแจ้งเตือนใหม่นี้คืออะไรเอาจริงๆตอนนี้ดาต้าเซ็นเตอร์ไม่ทำงาน!”

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

รัฐที่ 3: การต่อรอง

Dave in IT:“ เฮ้ Ard ในแอพพลิเคชั่นนี่คือเดฟด้านไอทีพวกคุณมีการสำรองข้อมูลสำหรับสภาพแวดล้อม App1 หรือไม่? . . . คุณแน่ใจเหรอ?คุณช่วยตรวจสอบอีกครั้งได้ไหมฉันรู้ว่าคุณได้ตรวจสอบสองครั้ง แต่คุณสามารถตรวจสอบอีกครั้งได้ไหมฉันจะซื้อเครื่องดื่มใน Taco วันอังคาร!”

Dave in IT:“ เฮ้ Donna DBA นี่คือ Dave ในด้านไอที Art in Applications บอกว่าคุณอาจช่วยฉันได้คุณได้ตั้งค่าการจำลองฐานข้อมูลโดยบังเอิญสำหรับฐานข้อมูลทางการเงินหรือระบบการจัดการสินค้าคงคลังหรือไม่? . . . คุณแน่ใจไหม?อืมคุณจำได้ไหมว่าเรามีวิธีใดในการกู้คืนจากอืม . . ศูนย์ข้อมูลขัดข้องหรือไม่”

เมื่อลูกสาวของฉันมีปัญหาการต่อรองเป็นครั้งแรกที่เธอไปเอาล่ะประการที่สองอย่างแรกคือการหายตัวไป แต่คุณฉลาดเกินกว่าที่จะเดินออกไปจากเปลวไฟแต่ Dave ด้านไอทีไม่ใช่คนเดียวที่รู้ว่าการต่อรองและการขอทานเป็นสิ่งที่ไม่ดีสำหรับกลยุทธ์ที่กำหนดไว้อย่างดีสำหรับความพร้อมใช้งานที่สูงและการกู้คืนจากภัยพิบัติข้ามการต่อรองและขอร้องเกี่ยวกับหายนะของคุณเพราะ“ 80% ของผู้คนไม่สนใจและ 20% ดีใจที่เป็นคุณ (ถอดความจาก Les Brown)”

ขั้นที่ 4: ความเศร้า

Dave in IT:“ นี่ยอดเยี่ยมมากเซิร์ฟเวอร์แอปพลิเคชันขัดข้องดาต้าเซ็นเตอร์หยุดทำงานและการสำรองข้อมูลหากฉันพบและหากสามารถโหลดได้จะใช้เวลาหลายชั่วโมงในการกู้คืนไม่มีทางที่ฉันจะออกจากสิ่งนี้…ฉันเอาเรซูเม่ที่อัปเดตนั้นไปไว้ที่ไหน”

แน่นอนคุณมีข้อมูลสำรองและคุณได้ตรวจสอบความถูกต้องแล้วแต่มีผลกระทบของ RTO และ RPO ในการย้อนกลับไปยังการสำรองข้อมูลเหล่านั้นคุณสามารถดูดซับครั้งนี้ได้หรือไม่?แน่นอนว่าหลังจากที่ศูนย์ข้อมูลของคุณกู้คืน

ขั้นตอนที่ 5: การยอมรับ

Dave in IT:“ เป็นเวลาสองชั่วโมงแล้วฉันไม่เคยรู้เลยว่าเรามีผู้มีส่วนได้ส่วนเสียจากผู้บริหารมากขนาดนี้มาก่อนไม่มีทางที่ฉันจะครบรอบ 2 ปีหลังจากนี้ฉันเดาว่าฉันจะทำความสะอาดสำนักงานของฉันในวันพรุ่งนี้ไม่มีทางที่ฉันจะผ่านมันไปได้!”

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

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

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า

ผลิตซ้ำจาก SIOS