ความยืดหยุ่นของแอปพลิเคชัน: รักษาแอป Windows ให้พร้อมใช้งาน

บทนำ

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

แอปพลิเคชันความยืดหยุ่นคืออะไร?

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

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

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

ความยืดหยุ่นของแอปพลิเคชันมากกว่าการทำงานของเซิร์ฟเวอร์

ความผิดพลาดทั่วไปคือการใช้ความพร้อมใช้งานของเซิร์ฟเวอร์เป็นตัวแทนของความพร้อมใช้งานของแอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์

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

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

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

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

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

ทำไมความยืดหยุ่นของแอปพลิเคชันจึงแตกต่างสำหรับแอปพลิเคชัน Windows?

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

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

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

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

ในกรณีใดที่ความพร้อมใช้งานของแอปพลิเคชัน Windows อาจล้มเหลว?

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

โฮสต์แอปพลิเคชัน

แอปพลิเคชันที่ทำงานบนเซิร์ฟเวอร์ Windows เดียวมีจุดล้มเหลวที่ชัดเจนเพียงจุดเดียว

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

ฐานข้อมูล, การจัดเก็บและความต้องการอื่น ๆ

หลายแอปพลิเคชัน Windows ขึ้นอยู่กับบริการภายนอกที่ไม่ใช่โฮสต์แอปพลิเคชัน บริการเหล่านี้อาจรวมถึง:

• ฐานข้อมูล SQL
• แชร์ไฟล์
• เซิร์ฟเวอร์การอนุญาต
• Active Directory
• ระบบชื่อโดเมน (DNS)
• ใบรับรอง
• API
• ซอฟต์แวร์กลาง
• การจัดเก็บข้อมูลในเครือข่าย
• โครงสร้างการพิมพ์

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

การตรวจสอบสิทธิ์และตัวตน

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

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

เครือข่ายและเส้นทางการเข้าถึงระยะไกล

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

มาร่วมจินตนาการถึงห่วงโซ่ทั้งหมดกันเถอะ:

อุปกรณ์ผู้ใช้ → อินเทอร์เน็ตหรือ LAN → เกตเวย์ → โฮสต์แอปพลิเคชัน → บริการแบ็กเอนด์

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

Endpoints

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

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

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

กระบวนการสร้างความยืดหยุ่นของแอปพลิเคชันสำหรับแอป Windows คืออะไร?

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

1. ระบุแอปพลิเคชันและกระบวนการทางธุรกิจที่สำคัญ

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

สองวัตถุประสงค์ในการกู้คืนแปลความต้องการทางธุรกิจเป็นข้อกำหนดทางเทคนิค แนวทางการวางแผนฉุกเฉินของ NIST กำหนดวัตถุประสงค์เวลาในการกู้คืน (RTO) และวัตถุประสงค์จุดในการกู้คืน (RPO) เป็นพารามิเตอร์หลักในการกำหนดความต้องการในการกู้คืน:

• ระยะเวลาเป้าหมายการกู้คืน (RTO): ระยะเวลาที่ยอมรับได้ของการหยุดทำงานก่อนที่จะมีการคืนบริการ
• จุดฟื้นฟูวัตถุประสงค์ (RPO): ช่วงเวลาของการสูญเสียข้อมูลที่ยอมรับได้ ซึ่งวัดเป็นเวลา

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

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

2. แผนที่ทั้งสายการพึ่งพาแอปพลิเคชัน

บันทึกทุกอย่างที่จำเป็นสำหรับแอปพลิเคชันในการทำงานของมัน

อย่าหยุดที่ไฟล์ปฏิบัติการหรือเซิร์ฟเวอร์ Windows อย่าลืมฐานข้อมูล การจัดเก็บ การตรวจสอบสิทธิ์ DNS เครือข่าย ใบรับรอง ระบบการอนุญาต การเชื่อมต่อ และบริการภายนอก

สำหรับแต่ละรายการ ให้ถามว่า:

แอปพลิเคชันจะเกิดอะไรขึ้นถ้าสิ่งนี้หายไป?

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

3. ลบจุดล้มเหลวที่สำคัญออก

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

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

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

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

4. แยกแอปพลิเคชันออกจากจุดสิ้นสุดแต่ละจุด

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

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

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

ให้วิธีการเข้าถึงที่ใช้งานได้มากกว่าหนึ่งวิธี

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

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

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

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

6. ตรวจสอบก่อนที่การเสื่อมสภาพจะกลายเป็นการหยุดทำงาน

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

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

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

การแจ้งเตือนเกณฑ์ช่วยให้ผู้ดูแลระบบสามารถตรวจสอบสัญญาณเบื้องต้นของเหตุการณ์ก่อนที่ผู้ใช้จะสูญเสียการเข้าถึง

7. วางแผนสำหรับการเพิ่มขึ้นของความจุและการเปลี่ยนผ่าน

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

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

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

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

8. ปกป้องข้อมูลและการตั้งค่า

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

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

กลยุทธ์จะเปลี่ยนแปลงไปตามวัตถุประสงค์เวลาในการกู้คืน (RTO) และวัตถุประสงค์จุดในการกู้คืน (RPO) ของแอปพลิเคชัน

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

9. ลดขอบเขตการระเบิดของการเปลี่ยนแปลง

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

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

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

10. การออกแบบเพื่อการลดคุณภาพอย่างมีระเบียบ

ความยืดหยุ่นไม่ได้หมายถึงการรักษาฟังก์ชันปกติ 100% ให้ทำงานตลอดเวลาเสมอไป

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

หากมีความจุที่สามารถใช้ได้ อาจมีเหตุผลที่จะจัดสรรให้กับการผลิต บริการลูกค้า การเงิน หรือฟังก์ชันอื่น ๆ ก่อน

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

ทีม IT ควรตรวจสอบความยืดหยุ่นของแอปพลิเคชันอย่างไร?

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

โมเดลที่สมจริงประกอบด้วยหลายชั้น:

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

ชั้นฟังก์ชันทางธุรกิจเป็นหนึ่งในชั้นที่ง่ายที่สุดที่จะมองข้าม

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

การทดสอบความยืดหยุ่นของแอปพลิเคชันควรทำอย่างไร?

สถาปัตยกรรมที่มีความยืดหยุ่นซึ่งไม่เคยประสบกับความล้มเหลวที่ควบคุมได้มีสมมติฐานที่ยังไม่ได้ทดสอบ

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

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

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

ความซ้ำซ้อนทางเทคนิคให้ประโยชน์น้อยมากหากกระบวนการในการกู้คืนการเข้าถึงยังไม่ได้รับการทดสอบ

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

ก่อนที่จะเริ่มต้นการใช้งานแอปพลิเคชัน Windows ที่มีความทนทาน ทีม IT ควรสามารถตอบคำถามต่อไปนี้ได้:

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

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

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

TSplus ช่วยให้แอปพลิเคชัน Windows พร้อมใช้งานได้อย่างไร?

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

TSplus Remote Access ยังสามารถรองรับการปรับใช้หลายเซิร์ฟเวอร์พร้อมการกระจายโหลดและการเข้าถึงที่ใช้เกตเวย์ เมื่อรวมกับฐานข้อมูลที่มีความยืดหยุ่น การจัดเก็บ บริการระบุตัวตน และเครือข่าย สถาปัตยกรรมนี้สามารถลดการพึ่งพาโฮสต์แอปพลิเคชันเดียวและช่วยรักษาการเข้าถึงแอปพลิเคชัน Windows ที่สำคัญในช่วงที่มีการหยุดชะงักของโครงสร้างพื้นฐาน

สรุป

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

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