เคยซ้อมหนีไฟกันมั้ยครับ ? เชื่อว่าใครหลายคนน่าจะรู้ขั้นตอนในการหนีไฟ ว่าควรปฏิบัติตัวยังไงเมื่อเจอกับสถานการณ์ฉุกเฉิน หลายคนอาจจะรู้ไปถึงแม้กระทั่งการใช้ถังดับเพลิง แล้วในฐานะผู้ดูแลระบบล่ะ ? ถ้าเกิดเหตุการณ์ไม่คาดฝันขึ้นมาจริง ๆ เราจะจัดการยังไง จะต้องติดต่อใครเพื่อที่จะให้ระบบยังสามารถใช้การได้ หรือกลับมาใช้งานได้ให้เร็วที่สุดเพื่อลดความเสียหายให้น้อยที่สุด แบบไม่เสียความต่อเนื่องไป …
เรื่องของเรื่องก็คือ ผมได้มีโอกาสไปมีส่วนร่วมกับการซ้อมแผนรับมือในสถานการณ์ฉุกเฉินที่อาจจะเกิดขึ้นได้กับระบบที่ดูแลอยู่ ซึ่งชื่ออย่างเป็นทางการของการทำ protocol แบบนี้ คือ
BCP = Business Continuity Plan
ชื่อก็ค่อนข้างจะตรงตัวมาก ๆ ว่าเป็นแผนการทำงานที่มุ่งเน้นให้ธุรกิจสามารถรันต่อเนื่องไปได้
โดยเหตุการณ์ที่เราอาจจะพอจินตนาการกันได้ ก็อาจจะเป็นเคสที่มีตึกไฟไหม้ หรือตึกถล่ม แล้วลองคิดดูว่า ตึกนั้นดันเป็นตึกที่ cloud ของเราอยู่ที่นั่นพอดิบพอดี !? จินตนาการตาม… ก็พอนะครับ หวังว่าอย่าให้เกิดขึ้นเลย…
. .
แล้วต้องทำอะไรบ้างล่ะ ?? ถ้าเป็นระบบที่ service ไม่ได้เกี่ยวข้องกับระบบอื่น ๆ ภายนอกสักเท่าไรก็อาจจะไม่ใช่เรื่องยากอะไร แต่ถ้าเป็นระบบที่ต้องคุยกับระบบภายนอกด้วยล่ะ ? เราจะ recover กลับมายังไงให้ใช้เวลาได้มีประสิทธิภาพมากที่สุด
. .
Day 1
ประชุมเพื่อชี้แจงการขั้นตอนการทำ BCP สรุปโดยภาพรวม ว่าระบบที่เกี่ยวข้องทั้งหมดของธุรกิจมีอะไรอยู่บ้าง ซี่งข้อมูลตรงนี้ หน้าที่หลักจะเป็นของทีม Infrastructure ในกรณีของผมคือ ผู้ให้บริการ cloud เป็นผู้รับผิดชอบในการชี้แจงในส่วนนี้ ซึ่งในหน้าที่ของผู้รับผิดชอบของแต่ละ Application
โดยตามแผนเพื่อจะ Simulate เรื่องนี้ให้คล้ายเหตุการณ์จริงมากที่สุด ทีม cloud จะทำการสร้าง instance ขึ้นมาใหม่ โดย instance นี้ก็คือ DR site (Disaster-Recovery Site)
โดยจุดประสงค์หลักของเรื่องนี้
เพื่อการจำลองว่าถ้าเครื่องหลักล่มไป เราจะสามารถ Recover ระบบได้ทั้งหมดภายในระยะเวลาเท่าไร
สิ่งที่ต้องไปเตรียมตัวเพิ่มเติมของแต่ละ App ก็จะเป็นขั้นตอนการ recover ที่จะทำออกมาเป็นเอกสาร ในที่นี้จะขอเรียกว่า Run book
.
Run book ต้องมีอะไรบ้าง ?
- ขั้นตอนแต่ละขั้นว่าจะต้องทำอะไรบ้าง เพื่อให้ Service สามารถรันขึ้นมาได้ - สิ่งที่ควรจะมีใน Run book ควรจะต้องระบุ ละเอียดลงไปถึงวิธีการ รวมถึงคำสั่งที่จะต้องใช้ ** สิ่งสำคัญคือ Run book ควรจะต้องละเอียดถึงขั้นสามารถส่งให้คนอื่นและสามารถทำตามขั้นตอนแล้วรันระบบขึ้นมาได้เลย
แล้วหลังจากนั้นต้องเตรียมอะไรกันต่อล่ะ ?
. .
Day 2
เตรียมความพร้อมภายในทีม เฉพาะแต่ละ App ว่าใครจะทำอะไรกันในขั้นตอนไหนบ้าง เพราะนอกจากระบบที่รันขึ้นมาได้แล้ว จำเป็นจะต้องมี การตรวจสอบ functional ว่าหน้าระบบสามารถทำงานได้เต็ม loop มั้ย, API service ยังเชื่อมต่อกันได้ครบรึเปล่า, Report engine ในระบบยังทำงานได้ปกติมั้ย, etc… โดยหลักก็เป็นการแบ่งหน้าที่รับผิดชอบกันภายในว่าใครจะต้องทำอะไรในจังหวะไหนบ้างเพื่อให้ระบบสามารถกลับมาใช้งานได้ให้เร็วที่สุด
. .
Day 3 วันจริง
หลังจากที่เตรียมตัวกันมาเรียบร้อย พอถึงวันจริง เพื่อจะ Simulate เหตุการณ์ทั้งหมด ขั้นตอนที่ทำจริงก็เลยจะเป็นแบบนี้ Down Production -> Move to DR site -> Back to Production
คือถ้าเป็นเหตุการณ์จริงเลย ก็จะเหลือจุดเดียวที่เราต้องทำคือที่ DR site แต่อย่างที่บอกว่านี่เป็นการซ้อม เพื่อรับมือ สุดท้ายเราก็ต้อง เอา Production เดิมกลับมาด้วยอ่ะนะครับ จะ Down ไปยาวเลยก็จะยังไงอยู่ 5555
. .
เริ่ม !! เมื่อมีทางทีม Infra ทำการ recover เครื่องที่ DR site เรียบร้อยแล้ว ทีม App แต่ละส่วนก็แยกย้ายกันเข้าไปที่เครื่องที่ตัวเองรับผิดชอบ
- รัน service - รันเช็ค service ว่าสามารถ on มาได้ครบมั้ย - ในที่นี้ทางทีมผมใช้เป็น docker สิ่งที่ต้องเช็คก็จะเป็น docker service แล้วหลังจากที่รัน docker compose เรียบร้อยก็เช็คว่า container ออนมาครบแล้วยัง - หลังจากนั้นก็ส่งไม้ต่อให้ทีม functional ทำการเข้าระบบ เช็คหน้า ui ว่าสามารถเข้าหน้าจอได้ครบทุกหน้ามั้ย, ทดสอบAPI, ทดสอบการออก report
ที่สำคัญ คือระหว่างการทำทั้งหมดนี้ เนื่องจากนี่เป็นการซักซ้อม เพราะฉะนั้นสิ่งที่จะต้องทำเพิ่มก็คือการ tracking เรื่องเวลาที่ใช้ในแต่ละ Tasks
เพื่อนำข้อมูลเหล่านี้มาใช้เพื่อการ improve เวลาที่ใช้ไปทั้งหมดกับการ recovery app ให้กลับมาออนได้สมบูรณ์
สมมติว่า มีระบบอื่นที่จำเป็นจะต้องใช้ service ต่อจากระบบของเรา เพื่อจะทำให้ระบบสามารถทำงานได้สมบูรณ์ แต่มีการใช้เวลาในส่วนของการ start service นั้นค่อนข้างนาน ซึ่งจะทำให้เกิดเวลาที่เป็น overhead เกิดขึ้น
จุดประสงค์ของการที่จะต้องจดเวลา ก็เพื่อใช้ในการ improve เวลาทั้งหมดให้ดีขึ้น ไม่ใช่เพื่อการจับผิดแต่อย่างใด เพราะฉะนั้น เมื่อเข้าขั้นตอนในการซักซ้อมลักษณะนี้ สิ่งที่ควรทำคือ mark เวลาและเหตุการณ์ที่เกิดขึ้นจริง
.
เมื่อทุก App สามารถออนกลับมาได้ ก็ถือเป็นการจบกระบวนการในการซ้อมรับมือกับเรื่องที่ไม่คาดฝันไปได้
ก็ถือเป็นอีกเรื่องหนึ่งที่ระบบควรจะต้องทำ ถึงโอกาสเหล่านี้จะเกิดขึ้นได้น้อยมากก็ตาม แต่ถ้าถึงเวลาที่เกิดขึ้น อย่างน้อยก็พออุ่นใจได้ ว่าเรามีวิธีการในการรับมือกับเรื่องนี้เอาไว้แล้ว ซึ่งลูกค้าก็อุ่นใจไปมากขึ้นด้วย ถึงเราจะไม่อยากให้เกิดขึ้นก็ตามเถอะ …
. .
Keywords ที่ควรรู้
- BCP = Business Continuity Plan - DR site = Disaster-Recovery site
>_JV
