ขณะนี้เรามีแอปพลิเคชันระดับ n คลาสสิก: DB / บริการเว็บ / ส่วนหน้า มันมีส่วนประกอบอื่น ๆ แต่มันเป็นเค้าโครงพื้นฐาน

เราต้องการปรับปรุงความพร้อมใช้งานของแอปพลิเคชันด้วยเหตุผลหลัก 3 ข้อ:

1. โฮสต์ของเราบางครั้งประสบปัญหาขัดข้อง (ตามที่พวกเขาทำทั้งหมด) และเราต้องการลดผลกระทบต่อลูกค้าของเราดังนั้นตัวอย่างเช่นพวกเขาจะเปิดดาต้าเซ็นเตอร์ B หากดาต้าเซ็นเตอร์ A หยุดทำงาน
2. เมื่อเราอัปเกรดเวอร์ชันเราจะปิดเว็บไซต์เพื่อการบำรุงรักษาและโดยปกติจะใช้เวลาสองสามชั่วโมง (สคริปต์การย้ายข้อมูล ฯลฯ ) เราต้องการให้ผู้ใช้มีช่วงการเปลี่ยนภาพที่ราบรื่นยิ่งขึ้นโดยมีเวลาหยุดทำงานน้อยที่สุดเท่าที่จะเป็นไปได้ (พวกเขาใช้เซิร์ฟเวอร์ B ในขณะที่กำลังอัปเกรดเซิร์ฟเวอร์ A)
3. Optionnaly ลูกค้าของเราตั้งอยู่ทั่วโลกและเราต้องการให้พวกเขามีประสบการณ์ที่ดีที่สุดเท่าที่จะเป็นไปได้แม้จะมีการเชื่อมต่อเส็งเคร็ง (ใครก็ตามที่ทำงานกับผู้พัฒนาอินเดียควรรู้ว่าฉันหมายถึงอะไร) ตามหลักการแล้วเราต้องการเชื่อมต่อเซิร์ฟเวอร์ในสำนักงานของพวกเขา (หรือใช้ดาต้าเซ็นเตอร์ใกล้เมือง) และมันจะรวมเข้ากับสถาปัตยกรรมของเราได้อย่างราบรื่น

เราไม่ต้องการความพร้อมใช้งานจากระยะไกล 99% หรือแม้แต่ 95% มันเป็นแอพจัดการเอกสาร ไม่มีใครสนใจ. แต่เนื่องจากการย้ายข้อมูลอาจใช้เวลาสักครู่และมีลูกค้าทั่วโลกบางครั้งเราป้องกันไม่ให้ลูกค้าทำงานเกือบตลอดทั้งวัน

สำหรับส่วนของ SQL แม้ว่าจะไม่มี DBA ที่ "ถูกต้อง" แต่เรารู้เกี่ยวกับความเป็นไปได้ของ SQL : การจำลองแบบ, การทำมิเรอร์และอื่น ๆ ทางด้าน DB มันค่อนข้างง่ายในการค้นหาแหล่งข้อมูลสำหรับเรื่องนี้ อะไรคือสิ่งที่ยากกว่า: การจัดเก็บเซสชันรหัส ฯลฯ หากเซิร์ฟเวอร์เว็บเซอร์ของฉันล่ม UI ของฉันจะรู้ได้อย่างไรว่าต้องสลับ เซสชันของฉันยังคงอยู่ในเซิร์ฟเวอร์อย่างไร

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

เรากำลังใช้ ASP.Net และ SQL Server กับ WCF webservice ตรงกลาง เรามีบริการ Windows มากมาย แต่พวกเขาไม่ได้เป็นภารกิจที่สำคัญและฉันคิดว่าวิธีการจัดการกับเว็บไซต์จะมีผลบังคับใช้กับบริการ

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

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

เพียงแค่เดาตามความต้องการของคุณและ SLA ความพร้อมในการทำงาน 95-99%:

• การย้ายฐานข้อมูลควรจะเกิดขึ้นในเวลาจริงสำหรับการเปลี่ยนแปลงส่วนใหญ่ การปฏิบัติงานการออกแบบฐานข้อมูลวิวัฒนาการ สำหรับการเปลี่ยนแปลงที่ต้องมีพฤติกรรมที่รุกรานมากขึ้นคุณมีตัวเลือกน้อย หนึ่งคือการหยุดทำงาน หากเป็นไปได้การเรียกใช้บริการของคุณในโหมดอ่านอย่างเดียวอาจใช้งานได้ สำหรับการใช้งานเต็มรูปแบบฉันอยากลองใช้ ScaleArc ซักพัก ดูเหมือนว่าเป็นเครื่องมือที่ลื่นมากสำหรับการปรับขนาดและความยืดหยุ่นในโลกของ SQL Server
• การวางเซิร์ฟเวอร์ไว้ในเว็บไซต์ของลูกค้าเป็นสูตรสำหรับภัยพิบัติที่ไม่สามารถจัดการได้เว้นแต่คุณจะมีกลยุทธ์การปรับใช้ระดับโลก (ซึ่งขึ้นอยู่กับคำอธิบายการโยกย้ายของคุณคุณยังไม่มี) อย่าผลักดันบริการคลาวด์ในสถานที่เพราะคุณมีปัญหาด้านประสิทธิภาพ แก้ไขปัญหาด้านประสิทธิภาพในตอนนี้จากนั้นคุณจะไม่ต้องจัดการกับคนที่มีค่าใช้จ่ายสูง
• เซิร์ฟเวอร์สถานะของคุณควรเป็นฐานข้อมูลบางประเภท ปฏิบัติตามแนวทาง HA ของพวกเขา คุณสามารถใช้ SQL Server สำหรับสิ่งนี้เนื่องจากคุณมีให้คุณแล้ว
• การพูดของฐานข้อมูลการจำลองแบบไม่ได้เปิดใช้งาน HA อันที่จริงการจำลองแบบ SQL จะทำให้คุณปวดหัวทุกรอบ (พูดจากประสบการณ์กับสถานการณ์การจำลองแบบโหนดหลาย) การมิร์เรอร์สามารถทำงานได้ แต่สุดท้ายฉันจำได้ว่าการทำคลัสเตอร์ SQL ใช้เวลา 1-5 นาทีในการล้มเหลวไปยังเซิร์ฟเวอร์ใหม่ ฉันเคยได้ยินสิ่งดีๆเกี่ยวกับ AlwaysOn แต่ฉันยังคงสงสัยว่าได้รับบันทึกการติดตามของ Microsoft สิ่งที่คล้ายกับ ScaleArc อาจช่วยได้มากขึ้นที่นี่
• เว็บเซิร์ฟเวอร์ของคุณควรไร้รัฐ หมุนสามหรือสี่และวางไว้ด้านหลังโหลดบาลานเซอร์ ที่ช่วยแก้ปัญหาสถานะการออนไลน์ของคุณที่นั่น ดังที่ Frederik ได้กล่าวถึงก่อนหน้านี้คุณยังสามารถทำการปรับใช้แบบนี้ได้
• บริการเว็บของคุณอาจไร้สัญชาติ ถ้าไม่ใช่ดูว่าคุณสามารถแยกมันออกเป็นบิตไร้สัญชาติและไร้รัฐได้หรือไม่ การวางหลายอินสแตนซ์ไว้ด้านหลังตัวโหลดบาลานเซอร์เดียวกันช่วยแก้ปัญหาสถานะการออนไลน์อีกครั้งและเปิดใช้งานสถานการณ์การปรับใช้ที่สนใจมากขึ้น (เช่นการปรับใช้สีน้ำเงิน / เขียว)

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

รับระดับ HA บนเว็บและแอปพลิเคชันของคุณ:

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

2. เว็บไซต์และแอปพลิเคชันระดับของคุณแต่ละคนควรมี load balancer อิสระต่อหน้าพวกเขา NGINX จะทำเคล็ดลับ แต่ IIS ก็สามารถทำได้เช่นกัน (ARR)

3. หากฐานข้อมูลเดียวไม่สามารถรองรับการโหลดให้ใช้ประโยชน์จากการแบ่งสถานะเซสชัน (หรือการแบ่งส่วนหรือการแปลงแป้นพิมพ์ที่สอดคล้องกัน) เพื่อกำหนดเส้นทางคำขอเฉพาะไปยังกล่องฐานข้อมูลเฉพาะ

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

ในด้านการอัพเกรด:

1. ออกแบบสคริปต์ฐานข้อมูลของคุณในลักษณะที่การอัพเกรดฐานข้อมูลสามารถทำได้ในขณะที่ระบบกำลังทำงานหรือกล่าวอีกนัยหนึ่งคือรักษาความเข้ากันได้ย้อนหลัง รูปแบบที่ใช้งานได้ดีสำหรับ "ขยายจากนั้นทำสัญญา" -> ทำการเพิ่มเฉพาะการเปลี่ยนแปลงที่เข้ากันได้ย้อนหลัง แต่เอาการอ้างอิงในเขตข้อมูล (ฯลฯ ) ที่คุณต้องการกำจัดออก จากนั้นอัพเกรดไคลเอ็นต์ทั้งหมดของฐานข้อมูลเป็น v-latest; จากนั้นทำการอัพเกรด db อื่นเพื่อกำจัดเขตข้อมูลเก่า (ฯลฯ ) ในฐานข้อมูล นี่อาจเป็นกระบวนการที่ช้าถ้าคุณมีฐานข้อมูลขนาดใหญ่และคุณต้องระวังไม่ให้ scupper ประสิทธิภาพของระบบของคุณ

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

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

ความหวาดระแวงของคุณเมฆมีเหตุผล - ผู้ให้บริการเช่น AWS ร่วมกับการปฏิบัติที่ดีในส่วนของคุณสามารถควบคุม / ลดความเสี่ยงมากที่สุด - มีลักษณะที่หน้าการปฏิบัติของพวกเขาที่จะได้รับความรู้สึกสิ่งที่กฎระเบียบของพวกเขาสอดคล้องอยู่กับ: https: // AWS .amazon.com / การปฏิบัติ /

TL; DR: สร้างซ้ำซ้อนโมดูลาร์; ทดสอบความพร้อมใช้งาน ตรวจสอบอย่างใกล้ชิด

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

การซักถามหลักฐาน

ระบบคลาวด์เป็นยาครอบจักรวาล

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

เราไม่ต้องการใช้ระบบคลาวด์เนื่องจาก x / y / z

หากคุณไม่ได้เป็นองค์กรขนาดใหญ่เป็นพิเศษคุณจะดีขึ้นโดยใช้ระบบคลาวด์ ระบบคลาวด์ชั้นนำ 3 (AWS, MSFT, Google) จ้างวิศวกรหลายพันคนเพื่อให้ SLA ที่สัญญาไว้แก่คุณและจัดการแดชบอร์ดได้ง่าย จริง ๆ แล้วมันเป็นการต่อรองราคาที่ดีเพื่อใช้แทนการใช้จ่ายเล็กน้อยในบ้านนี้

ปัญหาในการกำหนดขอบเขตและการออกแบบ

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

การกำหนดและการวัด 'ความพร้อมใช้งาน' นั้นยากกว่าที่คาดไว้

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

คนดูถูกความซับซ้อนของระบบที่มีอยู่เสมอ

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

ผู้คนประเมินค่าสูงเกินไป / ความสามารถของวิศวกร

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

การสร้างระบบที่พร้อมใช้งานจากบริเวณโดยรอบ

ตรวจสอบให้แน่ใจว่าคุณจะประกาศข่าวประเสริฐแก่ทุกสถาปัตยกรรมและทีมออกแบบเกี่ยวกับความสำคัญของความพร้อมใช้งานตามความต้องการของระบบ

คุณสมบัติของระบบช่วยให้มีความพร้อมใช้งาน

ลักษณะของระบบต่อไปนี้แสดงให้เห็นว่ามีส่วนร่วมในความพร้อมของระบบ:

ความฟุ่มเฟือย

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

modularity

RESTแบบแยกส่วนนั้นดีกว่า SOA แบบเสาหิน MICROSERVICE แม้ modular เป็นจริงมีมากขึ้นกว่าปกติHATEOS REST เหตุผลสามารถพบได้ในการอภิปรายที่เกี่ยวข้องกับผลตอบแทนในหัวข้อถัดไป หากคุณทำการประมวลผลแบบแบตช์ดีกว่าการประมวลผลแบบกลุ่มในชุดที่เหมาะสมที่ 10 เมื่อเทียบกับการจัดการกับชุด 1,000,000

ความยืดหยุ่น

"I am always angry"
                    - Hulk

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

บันทึกเส้นทาง

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

คุณสมบัติของความพร้อม

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

ความถูกต้อง

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

ผล

ข้ามจุดนี้หากคุณตอบถูกต้องเสมอสำหรับคำถามหัวข้อก่อนหน้า บางครั้งคำตอบของคำถามไม่จำเป็นต้องแม่นยำเช่นตอนนี้ฉันมีเพื่อนบน Facebook กี่คน? แต่คำตอบคาดว่าจะอยู่ใน ballpark +/- 1 ตลอดเวลา เมื่อคุณสร้างผลลัพธ์ที่คาดหวังผลตอบแทนของคุณคือ 100

ความมั่นคง

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

ราคา

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

การปรับปรุงความพร้อมใช้งานของระบบที่มีอยู่

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

1. กำหนดสิ่งที่ 'ว่าง' กับผู้มีส่วนได้เสียของคุณ
2. คุณจะวัดสิ่งที่คุณกำหนดไว้อย่างไร
3. การวิเคราะห์สาเหตุที่แท้จริงเพื่อระบุคอขวด
4. ภารกิจสำหรับการปรับปรุง
5. การตรวจสอบอย่างต่อเนื่อง ( ควบคุม ) ของระบบ

สาเหตุของการไม่พร้อมใช้งาน

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