วิกฤติระบบไอทีล่มทั่วโลก เป็นสัญญาณเตือนว่าถึงเวลาทบทวน BCP แล้ว
จากเหตุการณ์จอฟ้าของระบบปฏิบัติการ (Blue Screen of Dead, BSoD) ทำให้ระบบไอทีล่มกระจายตัวไปทั่วโลก ส่งผลให้กระบวนการทำงานขององค์กรต่าง ๆ ในหลากหลายอุตสาหกรรมรวมถึงภาครัฐบางส่วน เกิดการหยุดชะงัก
เหตุการณ์นี้เป็นตัวบ่งชี้สำคัญว่า องค์กรในยุคปัจจุบันมีการพึ่งพิงระบบไอทีสูงมาก นอกจากนั้นระบบไอทียังเชื่อมโยงกันข้ามองค์กรเป็นเครือข่าย (software supply chain) ตามห่วงโซ่คุณค่า ก่อให้เกิดความซับซ้อนทั้งกระบวนการทำงานและตัวเทคโนโลยีเอง
คำถามคือหากเกิดเหตุการณ์แบบนี้อีกครั้ง เราจะพร้อมรับมือมากน้อยแค่ไหน เพื่อลดผลกระทบให้น้อยที่สุด
การบริหารความต่อเนื่องทางธุรกิจ (Business Continuity Plan, BCP) เป็นกระบวนการวางแผนล่วงหน้าเพื่อรองรับสถานการณ์ภัยคุกคามที่รุนแรง อันอาจส่งผลให้การดำเนินงานขององค์กรใด ๆ ทั้งเอกชน หน่วยงานภาครัฐหรือแม้กระทั่งองค์กรไม่แสวงหากำไรต้องหยุดชะงักลง
ทั้งนี้ BCP จะคำนึงถึงผลกระทบและระยะเวลาของการหยุดชะงักจากภัยคุกคาม 3 กลุ่มที่มีโอกาสเกิดน้อยมาก เช่น
1) แผ่นดินไหว น้ำท่วม ไฟไหม้ การก่อการร้าย ฯลฯ ส่งผลให้ธุรกิจหยุดชะงักจากสำนักงานใหญ่เสียหายหรือไม่สามารถเข้าไปใช้งานได้
2) ระบบไอทีล่ม อันเกิดจากตัวระบบเสียหาย หรือเกิดจากภัยไซเบอร์อย่าง Ransomware
3) ภัยจากโรคระบาดร้ายแรงทำให้พนักงานไม่สามารถปฎิบัติหน้าที่ได้ เป็นต้น
ทั้งนี้ตัวแปรด้านระยะเวลาการหยุดชะงักจะส่งผลกระทบแปรผันแบบทวีคูณ (exponential) โดยจะมีระยะเวลาสำคัญตัวหนึ่งคือ Maximum Tolerable Period of Disruption, MTPD เป็นระยะเวลาของการหยุดชะงักสูงสุดที่ธุรกิจหากมาถึงจุดนี้แล้วจะต้องปิดตัวลงไป ไม่สามารถฟื้นฟูกลับมาได้อีก
นอกจากนี้ยังมีกระบวนการสำคัญซ้อนอยู่กับแผน BCP อีก 2 กระบวนการ ตัวแรกคือ กระบวนการตอบสนองแบบเร่งด่วน (Emergency Response) อันประกอบไปด้วยการประเมินขอบเขตความเสียหายและผลกระทบ และค้นหาสาเหตุพร้อมแนวทางแก้ไขหรือบรรเทาปัญหาในเบื้องต้น
กระบวนการที่ต่อเนื่องมาคือ การบริหารเหตุการณ์ (Incident Management) ที่คลอบคลุมกระบวนการฟื้นฟู (Business Recovery) ไว้ด้วย
โดยทั้ง 3 ส่วนต้องมีแผนชัดเจนล่วงหน้า ระบุผู้รับผิดชอบและภารกิจอย่างชัดเจน ตลอดจนกระบวนการสื่อสารภายในที่เรียกว่า Call Tree เพื่อส่งข่าวถึงการประกาศใช้แผน BCP (และควรมีการซ้อมทดสอบแผนมาล่วงหน้า)
รวมไปถึงแผนการสื่อสารถึงผู้มีส่วนได้ส่วนเสียภายนอกองค์กร ทั้งนี้เพื่อไม่ให้เกิดความสับสนอลหม่านและสามารถฟื้นฟูกลับมาดำเนินการต่อเนื่องไปได้โดยเร็วนั่นเอง
สำหรับการฟื้นฟูในแผน BCP แยกเป็น 3 ส่วน ส่วนแรกคือ การฟื้นฟูธุรกรรมสำคัญ (Critical Business Functions, CBFs) ขึ้นมาก่อน และไล่เรียงฟื้นฟูตามลำดับความสำคัญและความต่อเนื่องของกระบวนการลงไป ระบบสำรองพื้นฐานสำหรับกรณีระบบไอทีล่มคือการทำงานแบบ manual (ที่มีการออกแบบกระบวนการไว้ล่วงหน้าแล้ว) โดยสะสมเอกสารหลักฐานไว้เป็น backlog ที่จะนำไป key in ระบบไอทีในภายหลัง
ส่วนที่ 2 คือการฟื้นฟูระบบไอทีที่รองรับธุรกรรมสำคัญข้างต้น (โชคร้ายที่กรณี BSoD จะต้องแก้ไขโดยให้คนไปไล่แก้ที่หน้าเครื่องโดยตรง) และเป้าหมายสุดท้ายคือทำให้ระบบไอทีทั้งหมดได้รับการฟื้นฟูกลับคืนสู่สภาพปรกติเต็มรูปแบบ สำหรับกรณีระบบไอทีล่มทั่วไป เช่นเกิดไฟไหม้ทำความเสียหายต่อศูนย์ข้อมูลหลัก (Data Center, DC)
เราจะออกแบบให้ใช้ศูนย์ข้อมูลสำรอง (Disaster Recovery, DR) เป็นระบบรองรับแทน ส่วนที่ 3 คือการฟื้นฟูระบบสื่อสารต่าง ๆ หากมีความเสียหาย หรือต้องย้ายไปที่ระบบสำรอง เพื่อให้ระบบไอทีเชื่อมโยงถึงกันและเชื่อมถึงอุปกรณ์ปลายทาง
ตัวแปร 2 ตัวที่ใช้ในการวางแผนแนวทางการฟื้นฟูคือ Recovery Time Objective (RTO) ระยะเวลาเป้าหมายที่ธุรกรรมสำคัญชุดแรกจะต้องสามารถดำเนินการได้ เพื่อให้กระบวนการทำงานเดินหน้าไปได้บางส่วนก่อน ทั้งนี้หาก RTO ยิ่งสั้นเราก็จำเป็นต้องลงทุนในระบบสำรองมากขึ้น
สำหรับไอทีจะมีอีกตัวแปรหนึ่งคือ Recovery Point Objective, RPO คือข้อมูลที่ใช้สำหรับ CBFs โดยเราจะต้องสำรองข้อมูลไว้อีกอย่างน้อย 1 ชุด หากข้อมูลชุดหลักเสียหาย หรือโดน Ransomware เป็นต้น โดย RPO เท่ากับศูนย์หมายถึงต้องมีการสำรองแบบเวลาจริงอย่างต่อเนื่อง
ปรกติแผน BCP จะเชื่อมโยงกับแผน IT-DR (Disaster Recovery) ซึงเราต้องมีการทบทวน IT-DR เป็นการเฉพาะ เนื่องจากการทำ Digital Transformation ทำให้การดำเนินงานขององค์กรพึ่งพาระบบไอทีสูงมาก
อีกทั้งระบบไอทีในปัจจุบันก็มีความซับซ้อนจากการประมวลผลแบบกระจายผ่านโครงสร้างพื้นฐานที่อาจไปถึง Hybrid และ Multi-Cloud รวมถึงการใช้โปรแกรมประยุกต์ยุคใหม่ที่เป็นแบบ micro services
ตัวอย่าง การออกแบบโครงสร้างพื้นฐานให้มีอย่างน้อย 2 Availability Zones ใน Cloud Region เดียวกัน หรือต่าง region กันไปเลย แม่กระทั่งแยกไปยัง cloud provider คนละราย
ส่วนกรณีการ scaling ของ containers สำหรับโปรแกรมประยุกต์ใหม่ก็อาจใช้ทั้งการ scale up และ scale out เพื่อให้มั่นใจได้ว่าจะสามารถฟื้นฟูระบบงานสำคัญกลับมาได้ ส่วนสุดท้ายในการฟื้นฟูระบบสื่อสารก็อาจใช้บริการจาก DNS providers เพื่อปรับเปลี่ยนเส้นทางการสื่อสาร (Reroute DNS Requests) เป็นต้น
ประโยคภาษาอังกฤษที่เราได้ยินบ่อย ๆ คือ “Hope for the best and prepare for the worst” คือสิ่งที่ขอนำเสนอเป็นแนวคิดเบื้องต้นของบทความนี้ ผู้เขียนไม่แน่ใจว่าเราเตรียมรับกับสถานการณ์เลยร้ายที่สุดไว้มากน้อยแค่ไหน
แต่คิดว่าถึงเวลาแล้วที่ต้องทบทวนแผน BCP IT-DR สำหรับเหตุการณ์ภัยคุกคามที่มีโอกาสเกิดขึ้นน้อยมาก แต่หากเกิดแล้วจะมีผลกระทบสูงมหาศาลแบบที่เราประสบเจอมาแล้วนั่นเอง.
