ความพร้อมใช้งานสูงคืออะไร? SLA สำหรับ IaaS: การรับประกันที่แท้จริงสำหรับโครงสร้างพื้นฐานไอทีเสมือน ความพร้อมใช้งานสูงในฐานะบริการ

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

เราได้สัมภาษณ์ผู้ให้บริการโครงสร้างพื้นฐาน IaaS ระดับองค์กรชั้นนำและวิเคราะห์ข้อเสนอของพวกเขา ในเวลาเดียวกัน “ระดับองค์กร” หมายถึงสิ่งต่อไปนี้: แพลตฟอร์มคลาวด์ถูกปรับใช้ในศูนย์ข้อมูลที่ตรงตามข้อกำหนดของ Tier III (การมีอยู่ของใบรับรองจาก Uptime Institute ไม่ใช่จำเป็น) และให้ความทนทานต่อข้อผิดพลาดในระดับสูงผ่านกลไก High Availability (HA) และการย้ายตำแหน่งเครื่องเสมือนในกรณีที่เกิดภัยพิบัติ

ความพร้อมใช้งานและเวลาตอบสนอง

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

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

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

ข้อยกเว้นคือความพร้อมใช้งาน 99.99% ของ Dataline ในโหมดคลัสเตอร์เมโทร ภัยพิบัติรุ่นนี้ ระบบคลาวด์ครอบคลุมศูนย์ข้อมูลสองแห่งของบริษัท - สำหรับข้อมูลเพิ่มเติมเกี่ยวกับคลัสเตอร์เมโทร โปรดดูเนื้อหา "ระบบคลาวด์ที่ป้องกันภัยพิบัติในราคา "ไม่มีเมฆ" ที่เผยแพร่ในวารสาร Journal of Networking Solutions / LAN ( ).

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

หลายบริษัทเสนอการชำระเงินคืนรายเดือนจำนวนหนึ่ง (เป็นเปอร์เซ็นต์) สำหรับแต่ละชั่วโมงเพิ่มเติม (นอกเหนือจาก SLA) ที่ไม่พร้อมให้บริการ ตัวอย่างเช่น ด้วยระดับความพร้อมใช้งานที่ระบุไว้ใน SLA ที่ 99.95% (เวลาหยุดทำงานไม่เกิน 1 ชั่วโมงต่อเดือน) สำหรับแต่ละชั่วโมงเพิ่มเติมของการยกเลิกการเชื่อมต่อจากบริการ Inoventica พร้อมที่จะคืนเงิน 2% ของการชำระเงินรายเดือน Cloud4Y ในเวอร์ชันมาตรฐานจะชดเชย 1% สำหรับการหยุดทำงาน 1 ชั่วโมง (ใช้การคำนวณ ค่าใช้จ่ายทั้งหมดบริการแบบครบวงจร เดือนปฏิทินก่อนหน้านี้) แต่ไม่เกิน 50% ของค่าบริการ

ผู้ให้บริการหลายรายได้ให้การคำนวณโดยละเอียดว่าค่าตอบแทนจะแตกต่างกันไปตามระดับของความพร้อมจำหน่ายสินค้าอย่างไร (ดูตารางที่ 2) ในกรณีที่การลดลงอย่างมีนัยสำคัญในระดับนี้ จะมีการเสนอค่าตอบแทนจำนวนมาก ตัวอย่างเช่น หากมูลค่าน้อยกว่า 95% ออนลันตา (กลุ่มบริษัทล้านิต) ยอมลดระดับการชำระค่าบริการเป็น 40% และบริษัท IT-Grad หากระดับความพร้อมใช้งานลดลงต่ำกว่า 96.71% สัญญาว่าจะชดเชย 50% เป็นที่ชัดเจนว่าการเสื่อมสภาพในคุณภาพของการบริการนั้นไม่น่าเป็นไปได้โดยผู้ให้บริการ

"เราได้แนะนำหลักการชดเชยอิสระสองประการ: สำหรับการละเมิดตัวบ่งชี้เป้าหมายของพารามิเตอร์บริการและตัวบ่งชี้เป้าหมายสำหรับการประมวลผลคำขอ" Vitaly Mzokov หัวหน้าฝ่ายบริการคลาวด์และโซลูชันโครงสร้างพื้นฐานของ Servionika (I-Teco Group) กล่าว - การละเมิดตัวบ่งชี้เป้าหมายของพารามิเตอร์การบริการจะได้รับการชดเชยในระดับโปรเกรสซีฟ ตัวบ่งชี้ค่าตอบแทนจะคำนวณโดยแสดงเป็นเปอร์เซ็นต์ของจำนวนเงินในใบแจ้งหนี้สำหรับการใช้บริการทั้งนี้ขึ้นอยู่กับระดับความพร้อมที่แท้จริง การชดเชยสำหรับการละเมิดเป้าหมายสำหรับการประมวลผลคำขอจะคำนวณตามระยะเวลาการรอของลูกค้าด้วยความแม่นยำสูงสุดหนึ่งนาที

ตามแนวทางปฏิบัติของ Servionika ประเภทของคำขอของลูกค้า ตลอดจนเป้าหมายทั่วไปสำหรับเวลาตอบสนองสูงสุดสำหรับคำขอและเวลาสูงสุดในการแก้ไขปัญหา ได้อธิบายไว้ในระเบียบการปฏิสัมพันธ์ของบริการ และในข้อตกลง SLA เอง ตัวชี้วัดเหล่านี้ถูกกำหนดไว้สำหรับบริการเฉพาะ

“ตามสัญญา ลูกค้าสามารถรับบริการหลายอย่างจากเรา นั่นคือเหตุผลที่กฎเกณฑ์อธิบาย ตัวชี้วัดทั่วไปพร้อมหมายเหตุ: “เป้าหมายที่กำหนดไว้ใน SLA สำหรับบริการเฉพาะจะทับซ้อนกับตัวบ่งชี้ที่ระบุในข้อบังคับ” สิ่งนี้ทำเพื่อที่ว่าหากจำเป็น เป็นไปได้ที่จะชี้แจง (ขยายหรือลด) เวลาตอบสนองและเวลาในการแก้ปัญหา - Vitaly Mzokov อธิบาย - เราจำเป็นต้องตอบกลับคำขอทุกประเภทภายใน 15 นาที เวลาในการแก้ไขสูงสุด ขึ้นอยู่กับประเภทและลำดับความสำคัญของคำขอ มีตั้งแต่ 1 ชั่วโมง (สำหรับเหตุการณ์ที่มีลำดับความสำคัญที่ 1) ถึง 48 ชั่วโมง (สำหรับคำขอที่ต้องมีการประมวลผลคำขอข้อมูลของลูกค้าโดยสมบูรณ์ - เช่น การให้ข้อมูล เกี่ยวกับภาษีและบริการอื่น ๆ คำชี้แจงและคำแนะนำต่างๆ)

เวลาตอบสนองต่อแอปพลิเคชันมักจะขึ้นอยู่กับลำดับความสำคัญ ตัวอย่างเช่น นี่คือระดับความสำคัญที่ Linxdatacenter ปฏิบัติ:

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

ตารางที่ 3 แสดงตัวอย่างอื่น - การจัดหมวดหมู่ข้อความค้นหาที่ใช้โดย Cloud4Y เวลาตอบสนอง - ไม่เกิน 30 นาที

พยายามทำงานใน T-Systems ทันที ตามที่ Vsevolod Yegupov ผู้อำนวยการฝ่ายขายของแผนก ICT ของ T-Systems RUS ผู้เชี่ยวชาญของบริษัทนี้ "ใน 80% ของกรณีตอบสนองภายใน 30 วินาที" (!) แต่เช่นเดียวกับผู้ตอบแบบสอบถามส่วนใหญ่ของเรา เขาตั้งข้อสังเกตว่าเวลาตอบสนองขึ้นอยู่กับวิกฤตของสถานการณ์

เครื่องมือตรวจสอบ

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

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

โดยค่าเริ่มต้น บริษัทหลายแห่งจะจัดทำรายงานสถานภาพการบริการเดือนละครั้ง แต่สามารถทำได้บ่อยกว่านั้น - ตามคำขอของลูกค้า ตัวอย่างของรายงานที่นำเสนอโดย Onlanta แสดงในรูปที่ 1 ตามที่ Mikhail Lyapin หัวหน้าแผนกคลาวด์ของบริษัท Onlanta เป็นบริษัทเดียวในรัสเซียที่ให้บริการลูกค้าด้วยรายงานเกี่ยวกับความพร้อมใช้งานของทรัพยากรระบบคลาวด์ที่มีรายละเอียดในระดับนี้ ตามที่เขาพูดผู้ให้บริการส่วนใหญ่ได้รับสถิติเกี่ยวกับระดับความพร้อมใช้งานของเครื่องเสมือน

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

ควรรับประกันประสิทธิภาพ

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

นี่คือสิ่งที่ Vitaly Slizen สมาชิกคณะกรรมการบริหารของ Inoventica กล่าวเกี่ยวกับเรื่องนี้: "เราไม่สังเกตเห็นความเสื่อมโทรม [ของประสิทธิภาพ] แม้ว่าจะมีการเพิ่มภาระงาน เนื่องจากเรากำลังขยายและปรับปรุงขีดความสามารถของศูนย์ข้อมูลใน อย่างทันท่วงที แยกจากกัน ใน SLA พารามิเตอร์เหล่านี้ (VM และประสิทธิภาพการจัดเก็บ) จะไม่สะท้อนให้เห็น เนื่องจากการปฏิบัติตามข้อกำหนดเหล่านี้เป็นความรับผิดชอบหลักของเรา โดยไม่คำนึงถึงคำขอของลูกค้า ผู้เชี่ยวชาญของ Inoventica ตรวจสอบพารามิเตอร์หลักทั้งหมดของสิ่งอำนวยความสะดวกโครงสร้างพื้นฐานที่เช่าอย่างต่อเนื่อง ซึ่งช่วยให้พวกเขาได้รับข้อมูลเกี่ยวกับ ปัญหาที่อาจเกิดขึ้นและทำนายได้ทันท่วงที

Igor Drozdov ผู้จัดการยังพูดถึงการขาดความเสื่อมโทรม การสนับสนุนทางเทคนิคของการขาย Linxdatacenter: “บริษัทของเราจัดหาทรัพยากรการประมวลผลที่รับประกันสำหรับการใช้งาน สิ่งเหล่านี้ถูกสงวนไว้บนคลาวด์และเติบโตตามจำนวนไคลเอนต์ที่เพิ่มขึ้น ดังนั้นประสิทธิภาพของเครื่องเสมือนและพื้นที่จัดเก็บข้อมูลจึงยังคงอยู่ในระดับสูงอย่างต่อเนื่อง นอกจากนี้ เราทำการอัพเกรดเซิร์ฟเวอร์ในเวลาที่เหมาะสม และทำการตรวจสอบประสิทธิภาพโดยใช้ผลิตภัณฑ์ VMware เฉพาะทาง”

Orange Business Services ยังเป็นหนึ่งในผู้ให้บริการที่ไม่ได้ควบคุมพารามิเตอร์ประสิทธิภาพใน SLA มาตรฐาน ในเวลาเดียวกัน ดังที่ Dmitry Dorodnykh หัวหน้าแผนกพัฒนาผลิตภัณฑ์การสื่อสารแบบรวมศูนย์และไอทีของ Orange Business Services ในรัสเซียและ CIS บันทึกว่า “หากลูกค้าต้องการให้ทรัพยากรการคำนวณบางอย่างได้รับการรับประกันว่าจะได้รับการจัดสรรสำหรับเสมือนจริงของเขา เครื่องเราสมัคร มาตรฐานหมายถึงแพลตฟอร์มเวอร์ชวลไลเซชันที่ทันสมัยซึ่งในกรณีที่มีการแย่งชิงทรัพยากร อนุญาตให้คุณย้ายเครื่องเสมือนไปยังเซิร์ฟเวอร์อื่น

Vsevolod Egupov เชื่อว่าการรวมคุณลักษณะด้านประสิทธิภาพไว้ใน SLA นั้นไม่สมเหตุสมผล เนื่องจากความเสื่อมโทรมส่งผลต่อระดับความพร้อมใช้งานของบริการที่ควบคุมโดยข้อตกลง ที่ T-Systems ประสิทธิภาพของเครื่องเสมือนและระบบสตอเรจถูกควบคุมโดยฝ่ายจัดการความจุ ซึ่งผู้เชี่ยวชาญมีหน้าที่รับผิดชอบในการป้องกันการเสื่อมสภาพ

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

Dataline แสดงรายการตัวชี้วัดประสิทธิภาพสำหรับการจัดเก็บและเครื่องเสมือนในแต่ละ SLA (ดูตารางที่ 4) ในเวลาเดียวกัน ดังที่ Dmitry Tishin หัวหน้าแผนกพัฒนาบริการของบริษัทนี้กล่าวว่า "เมตริกสามารถเปลี่ยนแปลงได้ขึ้นอยู่กับข้อกำหนดที่ลูกค้านำเสนอ" ค่า IOPS จะถูกวัดโดยระบบตรวจสอบ NetApp DFM และเวลาการเข้าถึงดิสก์จะถูกวัดโดย หมายถึงปกติซอฟต์แวร์เวอร์ชวลไลเซชัน (vCenter) ในกรณีที่เกิดปัญหากับเครื่องเสมือน กะหน้าที่และวิศวกรของทีมเวอร์ชวลไลเซชันจะได้รับคำเตือนที่เหมาะสม นอกจากนี้ Dataline ยังให้การตรวจสอบพารามิเตอร์ต่าง ๆ ที่ระดับของระบบปฏิบัติการและบริการที่ทำงานอยู่ในนั้น หากลูกค้าใช้ระบบปฏิบัติการและบริการดูแลระบบของบริษัท การตรวจสอบดังกล่าวจะดำเนินการตามค่าเริ่มต้น

เพื่อป้องกันไม่ให้ประสิทธิภาพของเครื่องเสมือนลดลง ผู้เชี่ยวชาญของ Dataline จะใช้ชุดของมาตรการ ดังนั้นสำหรับคลัสเตอร์จึงใช้กลไก Distributed Resource Scheduler (DRS) ซึ่งตรวจสอบโหลดของเซิร์ฟเวอร์จริงตามพารามิเตอร์หลัก - หากถึงโหลดที่แน่นอนบนเซิร์ฟเวอร์ เครื่องเสมือนบางเครื่องจะถูกย้ายไปยังอีกเครื่องหนึ่งโดยอัตโนมัติ . คลัสเตอร์รักษาความซ้ำซ้อนของเซิร์ฟเวอร์เพื่อให้โหลดในคลัสเตอร์ทั้งหมดไม่เกิน 70% ภายในกรอบของสัญญาบริการที่สรุปไว้กับซัพพลายเออร์อุปกรณ์ ความจุทรัพยากรของคลัสเตอร์จะเพิ่มขึ้นตามกำหนดการ

Safedata ยังควบคุมคุณลักษณะด้านประสิทธิภาพ เช่น IOPS และ MIPS ใน SLA Anton Antonov หัวหน้าแผนกขาย Safedata กล่าวว่า "เราไม่สามารถลดประสิทธิภาพการทำงานที่ต่ำกว่าค่าที่ระบุใน SLA ได้ “หากบริการลดลงเกิดขึ้นเมื่อโหลดบนเซิร์ฟเวอร์จริงเพิ่มขึ้น โฮสต์ EXSi สำรองเพิ่มเติมจะถูกนำไปใช้งาน”

ลักษณะประสิทธิภาพของระบบดิสก์จัดเก็บข้อมูลที่ควบคุมใน SLA Cloud4Y แสดงไว้ในตารางที่ 5 ตาม Evgeny Bessonov หัวหน้าแผนกการตลาด Cloud4Y ในกรณีที่มีการละเมิดการรับประกัน มีการคิดค่าชดเชยซึ่งมีการเจรจาแยกกันหรือจ่ายตามเงื่อนไขมาตรฐาน: 1% ของค่าใช้จ่ายรายเดือนเป็นเวลา 1 ชั่วโมง

“เรารับประกันประสิทธิภาพของเครื่องเสมือนที่ขีดจำกัดล่าง โดยไม่จำกัดจากด้านบน” Ruslan Zaedinov กล่าว “ดังนั้น หากเซิร์ฟเวอร์ที่เครื่องเสมือนตั้งอยู่มีทรัพยากรการคำนวณฟรีเกินกว่าที่รับประกัน ลูกค้าจะพร้อมใช้งาน” สำหรับระบบจัดเก็บข้อมูล ปัจจุบันลูกค้า Croc ทั้งหมดใช้ช่องทางการสื่อสารร่วมกับระบบจัดเก็บข้อมูล การทำเช่นนี้ไม่ได้ทำให้เกิดปัญหามาเป็นเวลานาน แต่ตอนนี้ เพื่อตอบสนองความต้องการที่เพิ่มขึ้นของลูกค้า บริษัทกำลังย้ายที่เก็บข้อมูลบนคลาวด์จากดิสก์ Fibre Channel และ SATA ไปยังแฟลชไดรฟ์ที่เข้าถึงได้โดยตรงจากเครื่องเสมือนผ่านเครือข่าย Infiniband ในขณะเดียวกัน ซอฟต์แวร์ก็ถูกนำไปใช้งานเพื่อรับประกันทรูพุตของระบบจัดเก็บข้อมูลในคลาวด์ การเปลี่ยนแปลงที่สอดคล้องกับ SLA จะทำในฤดูใบไม้ร่วงนี้

ตามข้อตกลงกับลูกค้า Servionika จะแก้ไขตัวบ่งชี้ประสิทธิภาพของส่วนประกอบแต่ละส่วนของแพลตฟอร์มคลาวด์ใน SLA ของแต่ละโครงการ นอกจากนี้ ข้อตกลงยังได้ระบุวิธีการวัดตัวชี้วัดเหล่านี้และความถี่ของการวัด ตัวดำเนินการใดๆ สามารถเขียน "รับประกัน 100,500 OP ต่อพื้นที่ดิสก์ 1 GB" ได้ แต่ทุกคนไม่สามารถพิสูจน์ได้ว่าเป็นไปตามเกณฑ์นี้ เรามีไว้สำหรับความสัมพันธ์ที่โปร่งใสที่สุดระหว่างผู้ดำเนินการแพลตฟอร์มคลาวด์และผู้บริโภค” Vitaly Mzokov เน้นย้ำ ประสิทธิภาพของเครื่องเสมือนและระบบจัดเก็บข้อมูลถูกกำหนดใน Servionika SLA โดยตัวบ่งชี้ IOPS และ Latency

ดังที่ แม็กซิม ซาคาเรนโก กล่าวไว้ว่า ผู้จัดการทั่วไปผู้ให้บริการ "Oblakoteka" ในสัญญาที่พวกเขาสรุปตัวชี้วัดประสิทธิภาพสูงสุดจะถูกควบคุมในลักษณะที่โหลดบนแบนด์วิดท์ I / O และเครือข่ายไม่เกิน 80% การตรวจสอบดำเนินการโดยใช้ระบบ Microsoft SCOM เขาตั้งข้อสังเกตว่าสำหรับ ระบบต่างๆตัวบ่งชี้ต่างๆ มีความสำคัญ: สำหรับเว็บไซต์ - เวลาตอบสนอง สำหรับการโฮสต์โครงสร้างพื้นฐานด้านไอที - ตัวบ่งชี้การโหลดสูงสุดของโปรเซสเซอร์ หน่วยความจำ เครือข่ายเสมือน ฯลฯ ใน SLA บริษัทนี้ยังรวมถึงพารามิเตอร์สำรอง วิธีการและข้อกำหนดในการจัดหาและการรับประกัน จัดเก็บข้อมูลผู้ใช้ ("การจากกันอย่างซื่อสัตย์")

SLA ตั้งแต่ต้นจนจบ

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

อย่างไรก็ตาม ตามที่ Vsevolod Yegupov ตั้งข้อสังเกต การลดหรือการรักษาระดับความพร้อมใช้งานนั้นขึ้นอยู่กับวิธีการจัดระเบียบช่องทางการสื่อสาร - หากช่องนั้นสงวนไว้ ความพร้อมใช้งานจะไม่ลดลง มิฉะนั้น ระดับความพร้อมใช้งานใน SLA ตั้งแต่ต้นทางถึงปลายทางจะลดลงเหลือระดับความพร้อมใช้งานของช่องทาง T-Systems RUS มีเครือข่ายศูนย์ข้อมูลเป็นของตัวเองตั้งอยู่ทั่วโลก ลูกค้าชาวรัสเซียส่วนใหญ่ให้บริการจากศูนย์ประมวลผลข้อมูลที่ตั้งอยู่ในเยอรมนีและออสเตรีย บริษัทได้ลงนามใน SLA กับ Rostelecom, Beeline และยังร่วมมือกับผู้ให้บริการโทรคมนาคมรายอื่นๆ

ผู้ให้บริการ IaaS ซึ่งเป็นผู้ให้บริการโทรคมนาคมก็ใช้ประโยชน์จากสิ่งนี้เช่นกัน ดังนั้น ในฐานะผู้ให้บริการโทรคมนาคมระหว่างประเทศ Orange Business Services จึงปฏิบัติตาม SLA แบบครบวงจรซึ่งครอบคลุม IaaS และบริการโทรคมนาคม ระดับความพร้อมใช้งานใน SLA ดังกล่าวคือ 99.95% แต่ดังที่ Dmitry Dorodnykh อธิบาย ลักษณะนี้ขึ้นอยู่กับตำแหน่งทางภูมิศาสตร์ของลูกค้า - ตัวอย่างเช่น ในภาคกลาง ระดับนี้สูงกว่าระดับนอกเหนือเทือกเขาอูราลและในไซบีเรีย ไมล์สุดท้ายอาจมีพารามิเตอร์ SLA ของตัวเอง แผนงานและกลไกการควบคุม SLA บนช่องทางการสื่อสารได้ดำเนินการมาเป็นเวลาหลายทศวรรษแล้ว ดังนั้นปัญหาในการตรวจสอบจึงไม่ใช่ปัญหาสำหรับ Orange Business Services

ตามที่ Vitaly Slizen กล่าวไว้ Inoventica มีช่องทางการสื่อสารหลักและเครือข่ายศูนย์ข้อมูลที่กระจายอยู่ตามภูมิศาสตร์ ซึ่งทำให้สามารถใช้ geoclusters ได้ ซึ่งช่วยให้คุณบันทึกข้อมูลและประสิทธิภาพการบริการแม้ในกรณีที่ศูนย์ข้อมูลแห่งใดแห่งหนึ่งถูกทำลายทางกายภาพ ตามที่เขากล่าว Inoventica เป็น “บริษัทเดียวใน ตลาดรัสเซียซึ่งให้บริการครบวงจร "DPC - ช่อง - บริการ - ลูกค้า (AWP)" ตาม SLA ซึ่งเป็น ขั้นต่ำความล่าช้าในการส่งแพ็กเก็ต (ล่าช้าไป - กลับ) น้อยกว่า 10 ms และการสูญเสียแพ็กเก็ตเกือบเป็นศูนย์ ปัจจุบัน โซลูชันที่ซับซ้อนของ Inoventica พร้อมให้บริการแก่ลูกค้าใน 5 เขตของรัฐบาลกลางของสหพันธรัฐรัสเซีย

ผู้ให้บริการ IaaS ที่ไม่ใช่ผู้ให้บริการกำลังให้ความร่วมมืออย่างจริงจัง ดังนั้น Servionika จึงได้จัดทำ SLA เพื่อทำงานร่วมกับผู้ให้บริการโทรคมนาคมที่ให้บริการศูนย์ข้อมูล (ผู้ให้บริการโทรคมนาคมรายใหญ่มากกว่า 10 ราย) บริษัทเผยแพร่ข้อกำหนดของ SLA เหล่านี้ในสัญญากับลูกค้าที่ใช้บริการด้านการสื่อสาร และการควบคุมการปฏิบัติตาม SLA นั้นมาจากบริการทางเทคนิคของศูนย์ข้อมูล TrustInfo Vitaly Mzokov กล่าวว่า "เราระบุพารามิเตอร์ SLA เดียวกันกับของผู้ให้บริการในสัญญาของเรา นั่นคือเรารับผิดชอบต่อคุณภาพของงานของพวกเขาและการจัดหาช่องทางการสื่อสารอย่างต่อเนื่อง" Vitaly Mzokov กล่าว

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

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

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

Alexander Barskov- บรรณาธิการชั้นนำของ Journal of Network Solutions / LAN สามารถติดต่อได้ที่

, ผู้เขียน สจ๊วต Rens(สจ๊วต แรนซ์).

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

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

ปัญหาเกี่ยวกับเปอร์เซ็นต์ความพร้อมใช้งาน

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

หาก AST คือ 100 ชั่วโมงและเวลาหยุดทำงาน 2 ชั่วโมง ความพร้อมใช้งานจะเป็น:

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

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

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

การตั้งเป้าหมายการช่วยสำหรับการเข้าถึง

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

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

การสื่อสารกับลูกค้า

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

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

1. หน้าที่ทางธุรกิจใดที่สำคัญและมีความสำคัญสูงสุดสำหรับการป้องกันเวลาหยุดทำงาน
2. เวลาหยุดทำงานส่งผลกระทบต่อธุรกิจอย่างไร
3. ความถี่ของการหยุดทำงานส่งผลต่อธุรกิจอย่างไร?
4. เวลาหยุดทำงานมีผลกระทบต่อประสิทธิภาพองค์กรอย่างไร
5. ลูกค้าขององค์กรรับรู้ถึงการบังคับให้หยุดทำงานอย่างไร?

หน้าที่ทางธุรกิจที่สำคัญ

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

คุณต้องพูดคุยกับลูกค้าและพิจารณาว่าคุณลักษณะต่างๆ มีความสำคัญต่อธุรกิจอย่างไร คุณสามารถสร้างตารางที่แสดงรายการผลกระทบทางธุรกิจของการหยุดทำงานสำหรับแต่ละฟังก์ชันเหล่านี้ ตัวอย่าง:

ตารางที่ 1 - ความสำคัญของบริการในรูปเปอร์เซ็นต์

NB: ตัวเลขต้องรวมกันได้ไม่เกิน 100%

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

ระยะเวลาและความถี่ของการหยุดทำงาน

คุณต้องค้นหาว่าธุรกิจของลูกค้าได้รับผลกระทบจากความถี่และระยะเวลาของการหยุดทำงานอย่างไร

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

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

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

ตารางที่ 2 - ระยะเวลาการเดินทางและความถี่สูงสุด

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

เวลาหยุดทำงานและประสิทธิภาพ

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

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

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

วิธีหนึ่งในการพิจารณาผลกระทบคือการคำนวณเปอร์เซ็นต์ของนาทีที่ผู้ใช้เสียไป เพื่อทำสิ่งนี้:

• คำนวณ PotentialUserMinutes นี้ ทั้งหมดผู้ใช้ที่ทำงานต่อหน่วยเวลา ตัวอย่างเช่น หากคุณมีพนักงาน 10 คนที่ทำงานเป็นเวลา 8 ชั่วโมง PotentialUserMinutes ก็คือ 10 x 8 x 60 = 4800
• คำนวณ UserOutageMinutes นี่คือจำนวนผู้ใช้ที่ไม่สามารถทำงานได้ คูณด้วยเวลาที่พวกเขาไม่สามารถทำงานได้ ตัวอย่างเช่น หากเหตุการณ์ขัดขวางไม่ให้พนักงาน 5 คนทำงานเป็นเวลา 10 นาที UserOutageMinutes จะเท่ากับ 50
• คำนวณเปอร์เซ็นต์ความพร้อมใช้งานโดยใช้สูตรที่คล้ายคลึงกันมากกับสูตรที่เราเห็นก่อนหน้านี้

ในตัวอย่างข้างต้น เราได้การช่วยสำหรับการเข้าถึงดังต่อไปนี้:

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

การวัดและการรายงานความพร้อมใช้งาน

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

• คุณจะวัดอะไร
• คุณจะรวบรวมข้อมูลอย่างไร?
• คุณจะจัดทำเอกสารและสื่อสารสิ่งที่คุณค้นพบได้อย่างไร?

คุณวัดอะไรฉันเป็น

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

โดยทั่วไป เป้าหมายเหล่านี้เป็นส่วนหนึ่งของข้อตกลงระดับการให้บริการ (SLA) ระหว่างฝ่ายไอทีกับลูกค้า แต่คุณต้องระมัดระวังว่าตัวเลขจาก SLA จะไม่กลายเป็นเป้าหมายของคุณ เป้าหมายที่แท้จริงของคุณคือการให้บริการที่ตรงตามความต้องการของลูกค้า

วิธีรวบรวมข้อมูล

มีหลายวิธีในการรวบรวมข้อมูลเกี่ยวกับความพร้อมใช้งานของบริการไอที บางอันเรียบง่ายแต่ไม่แม่นยำมาก บางอันก็ค่อนข้างแพง คุณสามารถใช้ได้เพียงแนวทางเดียว หรือรวมหลายๆ วิธีเข้าด้วยกันเพื่อสร้างรายงานของคุณเอง

การเก็บรวบรวมข้อมูลในการสนับสนุนทางเทคนิค

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

วิธีนี้มักจะมีราคาไม่แพงนัก อย่างไรก็ตาม อาจทำให้เกิดข้อโต้แย้งเกี่ยวกับความถูกต้องของข้อมูลความพร้อมได้

การวัดโครงสร้างพื้นฐานและความพร้อมใช้งานของแอปพลิเคชัน

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

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

ลูกค้าจอมปลอม

บางบริษัทใช้ลูกค้าจำลองเพื่อส่งธุรกรรมที่ทราบจากจุดเฉพาะบนเครือข่ายเพื่อทดสอบความพร้อมใช้งาน

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

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

การพัฒนาโปรแกรมประยุกต์

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

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

วิธีการจัดทำเอกสารและสื่อสารสิ่งที่คุณค้นพบ

เมื่อคุณรวบรวมข้อมูลความพร้อมแล้ว คุณต้องคิดถึงวิธีสื่อสารผลลัพธ์ให้กับลูกค้าของคุณ

วางแผนการหยุดทำงาน

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

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

ไม่ว่าคุณจะตัดสินใจทำอะไร สิ่งสำคัญคือ SLA ของคุณจะกำหนดวิธีพิจารณาการหยุดทำงานตามแผนอย่างชัดเจน

ข้อตกลงรอบระยะเวลาบัญชี

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

ตัวอย่างเช่น พิจารณาบริษัทไอทีที่ยอมรับบริการ 24x7 และความพร้อมใช้งาน 99% สมมติว่ามีการพักแปดชั่วโมง:

• หากเรารายงานความพร้อมใช้งานเป็นรายสัปดาห์ AST (เวลาให้บริการที่ตกลงกัน) คือ 24 x 7 ชั่วโมง = 168 ชั่วโมง
• AST รายเดือน (24 x 365) / 12 = 730 ชั่วโมง
• AST รายไตรมาส (24 x 365) / 4 = 2190 ชั่วโมง

การใส่ตัวเลขเหล่านี้ลงในสมการความพร้อมใช้งานจะทำให้:

• ความพร้อมใช้งานรายสัปดาห์ = 100% x (168-8) / 168 = 95.2%
• ความพร้อมใช้งานรายเดือน = 100% x (730 - 8) / 730 = 98.9%
• ความพร้อมใช้งานรายไตรมาส = 100% x (2190-8) / 2190 = 99.6%

สิ่งเหล่านี้เป็นตัวบ่งชี้ความพร้อมใช้งานของบริการที่ถูกต้อง แต่มีเพียงตัวเดียวเท่านั้นที่ระบุว่าบรรลุเป้าหมายแล้ว

อยู่ในความดูแล

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

นี่เป็นบทความยาว ด้านล่างเป็นประเด็นสำคัญที่กล่าวถึงในนั้น:

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

คุณต้องการเพิ่มคำแนะนำอะไรอีก? กรุณาเขียนในความคิดเห็น

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

การเข้าถึง: การแนะนำเรื่อง

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

ความพร้อมใช้งาน = (AST - DT)/AST×100 = ความพร้อมใช้งานของบริการหรือส่วนประกอบ (%)

ที่ไหน
AST (เวลาให้บริการที่ตกลงกัน)- เวลาที่ตกลงกันไว้สำหรับการให้บริการ
DT (หยุดทำงานจริงในช่วงเวลาให้บริการที่ตกลงกันไว้)- เวลาจริงเมื่อไม่สามารถให้บริการได้ในช่วงเวลาที่ตกลงกันในการให้บริการ

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

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

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

จากข้อมูลข้างต้น เราเลือกความไม่พร้อมให้บริการเป็นเวลา 4 ชั่วโมงทุกๆ สี่สัปดาห์ นั่นคือ AST = 4 สัปดาห์ DT = 4 ชั่วโมง ความพร้อมใช้งานคือ:

ความพร้อมใช้งาน = (24×7×4–4)/(24×7×4)×100% = 99.40%

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

โปรดทราบว่าเราได้กำหนดความพร้อมใช้งานที่จำเป็นก่อนที่เราจะเริ่มทำงานกับโซลูชันที่มีให้ ไม่ใช่ในทางกลับกัน - ก่อนอื่นเราเลือกโซลูชันและเริ่มพิจารณาความพร้อมใช้งาน ข้อกำหนดในการอ้างอิงเป็นหลัก และความพร้อมใช้งานที่จำเป็นเป็นหนึ่งในพารามิเตอร์ที่กำหนดไว้ เมื่อระบบเริ่มทำงาน ความพร้อมใช้งานควรสอดคล้องกับค่าที่ต้องการ ดังนั้นเราจึงแนะนำในข้อตกลงกับธุรกิจ (SLA - ข้อตกลงระดับบริการ) ให้ถอดรหัสโดยละเอียดว่าตัวเลขความพร้อมใช้หมายความว่าอย่างไร (ในตัวอย่างของเรา: "4 ชั่วโมงของบริการไม่พร้อมใช้งานหนึ่งครั้ง (1) ภายในสี่ (4 ชั่วโมง) ) สัปดาห์”) เพื่อให้ทุกฝ่ายเข้าใจอย่างชัดเจนถึงสิ่งที่ซ่อนอยู่เบื้องหลังตัวเลข

สามเสาหลักแห่งการเข้าถึง

สิ่งแรกที่ต้องพิจารณาเมื่อเลือกโซลูชันคือความพร้อมใช้งานของบริการไอที ความคับข้องใจมากมายระหว่างการดำเนินงานเกิดจากการที่ความพร้อมของบริการที่ธุรกิจต้องการได้รับนั้นเกี่ยวข้องโดยตรงกับความพร้อมของอุปกรณ์ อย่างไรก็ตาม ความพร้อมใช้งานของบริการด้านไอทีประกอบด้วยสามองค์ประกอบ:
1) ความน่าเชื่อถือ - มักจะแปลว่าความน่าเชื่อถือ
2) การบำรุงรักษา - แปลว่า "การบำรุงรักษา";
3) ความสามารถในการให้บริการ - การบำรุงรักษา
ลองตรวจสอบแต่ละประเด็นเหล่านี้กัน

ความน่าเชื่อถือ

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

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

มาดูความน่าเชื่อถือกัน เนื่องจากเรามีการเชื่อมต่อแบบอนุกรมของส่วนประกอบ ค่าความน่าเชื่อถือจึงถูกคูณ:

ความน่าเชื่อถือ = (0.985×0.97×0.975×0.98×0.99×0.9999×0.99)×100%= 89.47%

นี้ชัดเจนไม่เพียงพอเมื่อเทียบกับค่าที่ต้องการ 99.40% จากนั้นเราจะเปลี่ยนการตัดสินใจ - เราจะรวมผู้ให้บริการอินเทอร์เน็ตรายอื่นไว้ในระบบ (รูปที่ 2) และคำนวณความน่าเชื่อถือ เนื่องจากเรามีการเชื่อมต่อแบบขนานที่เกี่ยวกับการเข้าถึงอินเทอร์เน็ต ความน่าเชื่อถือโดยรวมจึงถูกกำหนดไว้ดังนี้:

ความน่าเชื่อถือโดยรวม =

ความน่าเชื่อถือ = ×100% = 91.72%

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

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

การบำรุงรักษาและการบริการ

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

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

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

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

วิธีจัดการส่วนประกอบการช่วยการเข้าถึง

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

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

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

วิธีแก้ไขที่เป็นไปได้สำหรับปัญหาการช่วยสำหรับการเข้าถึงในกรณีนี้:

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

นอกจากนี้ คุณควรตรวจสอบสภาพการทำงานด้วย ตัวอย่างการละเมิดเงื่อนไขเหล่านี้โดยทั่วไป:

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

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

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

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

• การเปลี่ยนโซลูชันไอทีไปสู่ความพร้อมใช้งานสูง (ความพร้อมใช้งานสูง) - การใช้คลัสเตอร์ การใช้อุปกรณ์ที่รองรับการเปลี่ยน "ร้อน" การทำซ้ำจุดที่อาจเกิดความล้มเหลวซ้ำๆ ฯลฯ
• การเช่าโครงสร้างพื้นฐานทั้งหมดหรือบางส่วนจากผู้ให้บริการภายนอก (โฮสติ้ง การจัดระเบียบ)

2. การเปลี่ยนแปลงในการบำรุงรักษา (การเปลี่ยนแปลงในกิจกรรมบริการไอทีของ บริษัท ):

• การกระจายภายในองค์กรของแนวปฏิบัติที่ดีที่สุดในการจัดการไอที
• เชิญที่ปรึกษาภายนอกมาจัดกระบวนการในแผนกไอที
• อบรมพนักงานไอที.

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

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

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

ความพร้อมใช้งาน- ความสามารถของบริการด้านไอทีหรือส่วนประกอบในการทำงานในช่วงระยะเวลาหนึ่ง

ความน่าเชื่อถือ- ความสามารถของบริการไอทีหรือส่วนประกอบเพื่อทำหน้าที่ที่ระบุภายใต้เงื่อนไขการทำงานที่ระบุ

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

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

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

การวางแผนและพัฒนาบริการด้านไอทีโดยคำนึงถึงข้อกำหนดทางธุรกิจสำหรับระดับความพร้อมใช้งาน

เพิ่มประสิทธิภาพความพร้อมของบริการด้านไอทีผ่านการปรับปรุงที่คุ้มค่า

การลดจำนวนและระยะเวลาของเหตุการณ์ที่ส่งผลต่อความพร้อมในการให้บริการด้านไอที

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

การวางแผน

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

เมื่อออกแบบความพร้อมใช้งานของบริการด้านไอที การวิเคราะห์โครงสร้างพื้นฐานด้านไอทีจะดำเนินการเพื่อกำหนดส่วนประกอบที่เปราะบางที่สุดซึ่งไม่มีความซ้ำซ้อน และในกรณีที่เกิดความล้มเหลว อาจส่งผลกระทบในทางลบต่อการจัดหา บริการด้านไอที ในคำศัพท์เฉพาะของ ITIL ส่วนประกอบดังกล่าวเรียกว่า Single Point of Failure (SPOF) และใช้วิธี Component Failure Impact Analysis (CFIA) เพื่อกำหนดองค์ประกอบเหล่านั้น วิธีนี้ใช้เพื่อประเมินและคาดการณ์ผลกระทบของความล้มเหลวของส่วนประกอบไอทีในบริการไอที วัตถุประสงค์หลักของ CFIA คือ:

ระบุจุดของความล้มเหลวที่ส่งผลต่อความพร้อมใช้งาน

การวิเคราะห์ผลกระทบของความล้มเหลวของส่วนประกอบที่มีต่อธุรกิจและผู้ใช้

การกำหนดความสัมพันธ์ของส่วนประกอบและบุคลากร

การกำหนดเวลาการกู้คืนของส่วนประกอบ

กำหนดและตัวเลือกการกู้คืนเอกสาร

สำหรับการวิเคราะห์ความเสี่ยง จะใช้วิธีการวิเคราะห์และการจัดการความเสี่ยง (CCTA Risk Analysis and Management Method, CRAMM) ซึ่งจะมีการวิเคราะห์ภัยคุกคามและการพึ่งพาส่วนประกอบไอที และประเมินความน่าจะเป็นของการเกิดสถานการณ์ที่ไม่ได้มาตรฐานหรือเหตุการณ์ฉุกเฉิน .

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

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

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

ปรับปรุงความพร้อมใช้งานของบริการไอที

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

การปรับปรุงการช่วยสำหรับการเข้าถึงจำเป็นต้องมีการเพิ่มเติมที่เหมาะสม ต้นทุนทางการเงินและเพื่อกำหนดความเป็นไปได้ในการปรับปรุงบริการด้านไอที มีการใช้วิธีการและเทคโนโลยีบางอย่าง รวมถึงการวิเคราะห์แผนผังข้อบกพร่อง (Fault Tree Analysis, FTA) และการวิเคราะห์การหยุดทำงานของระบบ (Systems Outage Analysis, SOA)

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

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

การระบุสาเหตุของความล้มเหลวในการให้บริการด้านไอที

การกำหนดประสิทธิภาพของการสนับสนุนบริการไอที

การจัดทำรายงาน

การเริ่มต้นโปรแกรมเพื่อนำคำแนะนำที่เป็นที่ยอมรับไปปฏิบัติ

การวิเคราะห์การปรับปรุงความพร้อมใช้งานที่ได้รับจากการวิเคราะห์การหยุดทำงานของระบบ

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

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

การวัดความพร้อมใช้งานของบริการไอที

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

ตัวบ่งชี้ต่างๆ เช่น ความถี่ของการหยุดให้บริการด้านไอที ระยะเวลารวมของการหยุดทำงาน พื้นที่ของอิทธิพลจากการหยุดชะงักของบริการไอทีสามารถเข้าใจได้สำหรับธุรกิจ

หน้าที่และความรับผิดชอบ

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

การดำเนินการตามกระบวนการ

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

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

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

ผลกระทบและปัญหา

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

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

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

ความล้มเหลวในการดำเนินการตามกระบวนการเนื่องจากความพร้อมใช้งานของบริการไอทีในปัจจุบันถือว่ายอมรับได้

สมมุติฐานว่าหากมีกระบวนการ ITSM ที่ดำเนินการอื่น ๆ กระบวนการจัดการความพร้อมใช้งานจะถูกดำเนินการโดยอัตโนมัติ

ความต้านทานต่อการรวมศูนย์ในการจัดการโครงสร้างพื้นฐานด้านไอทีโดยผู้จัดการไอที

อำนาจหน้าที่ไม่เพียงพอของผู้จัดการกระบวนการ ทำให้ไม่สามารถปฏิบัติหน้าที่ได้อย่างถูกต้อง

Evgeniy Bulychev (Bulychev@i-teco.ru) - ที่ปรึกษาของ I-Teco Business Consulting (มอสโก)

แนวคิดในการเขียนบทความนี้เกิดขึ้นหลังจากได้พูดคุยกับลูกค้ารายใหญ่รายหนึ่ง - เพื่อนร่วมงานเล่าเรื่องการเลือกผู้ให้บริการคลาวด์ IaaS ให้กับบริษัทของเขา

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

วลาดิมีร์ คูริลอฟ บริษัทออนลันตา

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

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

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

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

ฉันจะพยายามกำหนดคำตอบสำหรับคำถามเหล่านี้เพิ่มเติม

ความน่าเชื่อถือของแอปพลิเคชัน - ประกอบด้วยอะไรในคลาวด์

ความน่าเชื่อถือของบริการแอพ

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

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

แอปพลิเคชันนี้ใช้แพลตฟอร์มซอฟต์แวร์ ซึ่งในทางกลับกันจะอยู่บนแพลตฟอร์มโครงสร้างพื้นฐานโดยใช้แพลตฟอร์มทางวิศวกรรม ดูรูปที่ สี่เลเยอร์เหล่านี้รวมกันเป็น "บริการแอปพลิเคชัน"

ข้าว. ตัวอย่างง่ายๆ ของการคำนวณความพร้อมใช้งานของ Application Service

ดังที่เห็นได้จากรูป เรากำลังจัดการกับระบบขององค์ประกอบตามลำดับ ซึ่งความล้มเหลวขององค์ประกอบใดๆ นำไปสู่ความล้มเหลวของระบบโดยรวม

ความพร้อมใช้งานของระบบดังกล่าว (As) ถูกกำหนดให้เป็นผลิตภัณฑ์ของตัวบ่งชี้ความพร้อมใช้งานขององค์ประกอบทั้งหมด:

A i คือความพร้อมใช้งานของส่วนประกอบที่เชื่อมต่อแบบอนุกรมแต่ละรายการ
A s = 0.99995 0.99995 0.993 0998 ≈ 0.99091 หรือ 99.091

อย่างที่คุณเห็น ความพร้อมใช้งานของ Application Service มีความสำคัญไกลจากความพร้อมใช้งานของแพลตฟอร์มวิศวกรรมของศูนย์ข้อมูล คุณสามารถแปลงหมายเลขความพร้อมใช้งานเป็นเวลาหยุดทำงานของระบบ ปรากฎว่าแม้ว่าแพลตฟอร์มวิศวกรรมจะหยุดทำงานประจำปีที่อนุญาตไว้ที่ 1 ชั่วโมงก็ตาม 45 นาที เวลาหยุดให้บริการแอปพลิเคชันรายปีคือ 86 ชั่วโมง 22 นาที

ดังนั้น ความพร้อมใช้งานสูงของศูนย์ข้อมูลไม่ได้บ่งชี้ถึงความน่าเชื่อถือสูงของบริการแอปพลิเคชันที่ทำงานอยู่ในศูนย์ข้อมูลนี้

ความน่าเชื่อถือของแอปพลิเคชันเครือข่าย

ดังนั้นในการเลือกผู้ให้บริการ ควรเน้นที่ความพร้อมใช้งานของบริการแอพพลิเคชั่นโดยรวม หรือไม่? น่าเสียดายที่ทุกอย่างไม่ง่ายนักที่นี่

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

ตัวเลือกหนึ่งสำหรับการนำไลบรารี่เฉพาะทางไปใช้โดย Microsoft คือ Transient Fault Handling Application Block (ดู http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx)

ความน่าเชื่อถือของแพลตฟอร์มซอฟต์แวร์

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

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

ความน่าเชื่อถือของแพลตฟอร์มโครงสร้างพื้นฐาน

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

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

อย่างไรก็ตาม:

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

ตอนนี้คุณมีโอกาสที่จะกำหนดความพร้อมใช้งานของบริการแอปพลิเคชันของคุณอย่างน่าเชื่อถือที่สุด 90% ของการร่วมทุนในรัสเซีย จากประสบการณ์ของเรา มีความพร้อมทั้งหมดไม่เกิน 99% และนี่คือความเสี่ยงของการหยุดทำงานสูงสุดถึง 87 ชั่วโมงต่อปี นี่เป็นตัวบ่งชี้ความพร้อมใช้งานปกติหากคุณไม่มีแอปพลิเคชันที่มีความสำคัญต่อธุรกิจซึ่งการหยุดทำงานรายชั่วโมงทำให้คุณขาดทุนหลายล้านดอลลาร์ และหากการหยุดทุกชั่วโมงคล้ายกับหายนะสำหรับธุรกิจของคุณ สำหรับคุณแล้ว ยังมีกิจการร่วมค้าอีก 10% ที่เหลือซึ่งให้บริการระดับองค์กรพร้อมความพร้อมใช้งานของ Application Service ที่ระดับ 99.99% วิธีนี้จะบรรลุผลในหัวข้อถัดไป

บริการแอพพลิเคชั่นโซลูชั่นความพร้อมใช้งานสูง

ด้วยเหตุนี้ ลูกค้าจึงไม่สนใจว่าจะปฏิบัติตาม SLA สำหรับระบบวิศวกรรมอย่างไร สิ่งสำคัญสำหรับเขาคือความพร้อมในการให้บริการของแอปพลิเคชันของเขา เช่น - รับประกันเวลาการกู้คืนแอปพลิเคชัน

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

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

คำตอบคือคุณทำได้

ตัวอย่างเช่น มีสองวิธีที่ช่วยให้คุณทำสิ่งนี้ได้:

• คลัสเตอร์ที่มีความพร้อมใช้งานสูงกระจายตามพื้นที่
• การกู้คืนการประมวลผลในศูนย์ข้อมูลสำรองระยะไกลทางภูมิศาสตร์ (การกู้คืนจากภัยพิบัติ)

ข้าว. ไดอะแกรมโครงสร้างของคลัสเตอร์ความพร้อมใช้งานสูงแบบกระจายตามภูมิศาสตร์

ข้าว. บล็อกไดอะแกรมสำหรับการกู้คืนการประมวลผลในศูนย์ข้อมูลสำรองทางไกลทางภูมิศาสตร์

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

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

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

ความแตกต่างพื้นฐานของระบบคู่ขนานคือความน่าเชื่อถือเพิ่มขึ้นพร้อมกับองค์ประกอบคู่ขนานของระบบที่เพิ่มขึ้น ความพร้อมใช้งานของระบบที่ประกอบด้วยองค์ประกอบคู่ขนานสามารถคำนวณได้โดยใช้สูตร:

โดยที่: A s - ความพร้อมใช้งานทั้งหมด ความพร้อมใช้งานของทั้งระบบ
A i คือความพร้อมใช้งานของแต่ละองค์ประกอบที่เชื่อมต่อแบบขนาน

ตัวอย่างเช่น มาคำนวณระบบคลัสเตอร์ความพร้อมใช้งานสูงแบบกระจายตามภูมิศาสตร์ของศูนย์ข้อมูลสองแห่งที่มีความพร้อมใช้งาน = 99% แต่ละแห่ง

A s \u003d 1- (1-0.99) * (1-0.99) \u003d 0.9999 หรือ 99.99

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

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

จำนวนชั่วโมงทั้งหมดในหนึ่งปี 365*24=8760
รับประกันการหยุดทำงาน = เวลาหยุดทำงานสูงสุด
15 นาทีหรือ 0.25 ชั่วโมง ซึ่งเท่ากับ ≈ 0.003 ของเวลาต่อปี

เหล่านั้น. ความล้มเหลวแต่ละครั้งจะมีน้ำหนัก 0.003% ดังนั้นระบบก่อนความล้มเหลวระบบมีความพร้อมใช้งานเท่ากับ 100% หลังจากความล้มเหลวครั้งแรก 99.997% หลังจากความล้มเหลวครั้งที่สอง 99.994% มาคำนวณกันสำหรับระบบที่มีช่วงเวลาการซิงโครไนซ์รายชั่วโมง:

รับประกันเวลาการกู้คืน = เวลาหยุดทำงานสูงสุด = 1 ชั่วโมง ซึ่งเท่ากับ ≈ 0.01 ของเวลาประจำปี

ความล้มเหลวแต่ละครั้งจะมีน้ำหนัก 0.01% ดังนั้นระบบก่อนความล้มเหลวระบบมีความพร้อมใช้งานเท่ากับ 100% หลังจากความล้มเหลวครั้งแรก 99.99% หลังจากความล้มเหลวครั้งที่สอง 99.98% นอกจากนี้ ผู้สนับสนุนทฤษฎีความน่าจะเป็นสามารถฝึกฝนในการประเมินความน่าจะเป็นของความล้มเหลวครั้งแรก ครั้งที่สอง และครั้งที่สาม ผลลัพธ์จะโน้มน้าวคุณว่าอิทธิพลของปัจจัยนี้ไม่มีนัยสำคัญต่อผลลัพธ์ที่ได้รับ ซึ่งช่วยให้ฉันสามารถแนะนำวิธีการที่แนะนำสำหรับการประเมินความพร้อมใช้งานของบริการสำหรับแอปพลิเคชันของคุณในคลาวด์ได้

สรุปข้างต้น...

• เริ่มต้นด้วยการประเมินความสำคัญทางธุรกิจของแอปพลิเคชันที่คุณวางแผนจะโฮสต์ในระบบคลาวด์ ประเมินค่าใช้จ่ายในการหยุดทำงานของแอปพลิเคชัน การขาดบริการสมัครจะเสียค่าใช้จ่ายเท่าไหร่?
• จากที่นี่ ให้ประเมินมูลค่าการหยุดทำงานที่อนุญาตต่อวันต่อปี คำนวณความพร้อมใช้งานที่สำคัญของบริการแอปพลิเคชัน
• เปรียบเทียบต้นทุนการหยุดทำงานที่เป็นไปได้กับราคา SP ที่ให้ความพร้อมใช้งานในราคาที่ไม่แพงสำหรับแอปพลิเคชันของคุณ
• เมื่อเลือกการร่วมทุน ให้ความพึงพอใจกับผู้ที่ไม่เพียงแต่ให้การเข้าถึงในระดับปัจจุบันเท่านั้น แต่ยังให้การช่วยสำหรับการเข้าถึงที่ดีขึ้นเป็นบริการ/บริการเพิ่มเติม โดยเฉพาะอย่างยิ่งหากธุรกิจของคุณเติบโตและพัฒนา
• และใช้งานได้จริง ใช้สิ่งที่พวกเขาให้คุณรู้สึก = ทดสอบ ทฤษฏีที่ปราศจากการปฏิบัติไม่เป็นประโยชน์ต่อธุรกิจมากนัก