ไฟฟ้าดับ

ไฟฟ้าดับเป็นเหตุการณ์ที่คนส่วนใหญ่มองว่าเป็นปัญหาของการไฟฟ้าหรือผู้ให้บริการสาธารณูปโภค แต่สำหรับวิศวกรซอฟต์แวร์และผู้ดูแลโครงสร้างพื้นฐาน เหตุการณ์ไฟฟ้าดับคือ ตัวทดสอบความเปราะบางของระบบที่แท้จริง ไม่ว่าคุณจะรัน Kubernetes cluster บนคลาวด์ ดูแล API gateway ในศูนย์ข้อมูล หรือปล่อยเฟิร์มแวร์ให้อุปกรณ์ IoT หลายพันตัว ไฟฟ้าดับจะเผยให้เห็นทุกจุดที่เราละเลยการออกแบบ resilience ไว้

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

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

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

ไฟฟ้าดับกับชั้นพลังงานที่ซ่อนอยู่ใต้ซอฟต์แวร์

นักพัฒนาส่วนใหญ่เขียนโค้ดโดยสมมติว่า process จะทำงานต่อเนื่องจนกว่าจะถูก kill หรือ exception จะเกิดขึ้นอย่างเป็นระเบียบ แต่ในโลกความจริง ไฟฟ้าดับทำให้ทุกอย่างหายไปแบบไม่มีคำเตือน ไม่มี graceful shutdown ไม่มี error log ไม่มี trace ว่าการเชื่อมต่อค้างไว้ที่ไหนบ้าง นี่คือเหตุผลที่เราต้องเข้าใจว่าแอปพลิเคชันของเราพึ่งพาชั้นพลังงานอย่างไร

ในสถาปัตยกรรม cloud-native แม้เราจะย้าย workload ไปบนผู้ให้บริการคลาวด์แล้ว ไฟฟ้าดับก็ยังตามเรามาในรูปของ availability zone failure, instance termination หรือ network partition ที่เกิดจากความล้มเหลวของโรงไฟฟ้าระดับภูมิภาค ผู้ให้บริการอย่าง AWS, Google Cloud และ Azure ต่างเผชิญเหตุการณ์แบบนี้มาแล้วหลายครั้ง และทั้งสามรายต่างมี publish post-incident report ที่ยืนยันว่าพลังงานเป็นหนึ่งในจุดล้มเหลวที่พบบ่อย

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

ในทีมที่ผมเคยทำงานด้วย เราพบว่าปัญหาใหญ่สุดหลังเหตุการณ์ไฟฟ้าดับไม่ใช่เซิร์ฟเวอร์ที่บูตกลับมาแล้ว database corrupt แต่เป็นระบบที่บูตกลับมาในลำดับที่ไม่ถูกต้อง หลาย service เริ่มทำงานก่อนที่ database จะพร้อม ทำให้เกิด connection storm และ process หลายตัวรันซ้ำซ้อนกันโดยไม่มี distributed lock ที่ถูกปลดล็อก

กายวิภาคของเหตุการณ์ไฟฟ้าดับในศูนย์ข้อมูลระดับมืออาชีพ

ศูนย์ข้อมูลที่ได้มาตรฐานไม่ได้พึ่งไฟจากการไฟฟ้าเพียงแหล่งเดียว แต่มีชั้นซ้อนหลายระดับ ได้แก่ ระบบไฟฟ้าหลัก (utility power) เครื่องสำรองไฟแบบ UPS (Uninterruptible Power Supply) เครื่องปั่นไฟดีเซลหรือแก๊ส และระบบจัดการพลังงานอัจฉริยะที่คอยสลับแหล่งจ่ายไฟโดยอัตโนมัติผ่าน ATS (Automatic Transfer Switch)

ลำดับเหตุการณ์เมื่อเกิดไฟฟ้าดับในดาต้าเซ็นเตอร์ทั่วไปมีดังนี้: วินาทีที่ 0 ไฟจาก utility หายไป ATS ตรวจจับ voltage drop ได้ในเวลา 2-10 มิลลิวินาที จากนั้น UPS จะรับภาระโหลดทันทีในเวลาที่เรียกว่า transfer time ซึ่งปกติอยู่ที่ 0-4 มิลลิวินาทีสำหรับแบบ online double-conversion UPS ที่มีประสิทธิภาพสูง ขณะเดียวกัน controller จะสั่งสตาร์ทเครื่องปั่นไฟ ซึ่งใช้เวลา 10-60 วินาทีในการขึ้นรอบและซิงโครไนซ์ความถี่

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

UPS และแบตเตอรี่สำรอง: แนวป้องกันด่านแรกของระบบซอฟต์แวร์

UPS ไม่ใช่แค่กล่องแบตเตอรี่ขนาดใหญ่ แต่มันคือระบบแปลงไฟที่ทำงานตลอดเวลา โดยเฉพาะแบบ online double-conversion ที่ไฟ AC เข้ามาจะถูกแปลงเป็น DC เพื่อชาร์จแบตเตอรี่ แล้วแปลงกลับเป็น AC ใหม่เพื่อจ่ายให้โหลด วิธีนี้ช่วยกรองสัญญาณรบกวน แก้ไขแรงดันตกชั่วขณะ (sag/swell) และให้การป้องกันที่ต่อเนื่องเมื่อเกิดไฟฟ้าดับ

จากมุมมองของวิศวกรซอฟต์แวร์ UPS คือเวลาที่เราซื้อเพื่อให้ระบบทำ graceful shutdown หรือ failover ไปยัง site อื่น แบตเตอรี่ VRLA ทั่วไปในดาต้าเซ็นเตอร์ให้ runtime ประมาณ 5-15 นาทีที่โหลดเต็ม ขณะที่แบตเตอรี่ลิเธียมไอออนเริ่มเข้ามาแทนที่เพราะอายุการใช้งานนานกว่าและรองรับวงจรชาร์จ-ดิสชาร์จถี่กว่า

เครื่องมือที่เราใช้ตรวจสอบสถานะ UPS มักเป็น SNMP ผ่าน agent card เช่น APC AP9630 หรือ Eaton Network Management Card ตามมาตรฐาน RFC 1628 (UPS Management Information Base) ซึ่งกำหนด OID สำหรับอ่านค่า battery capacity, estimated runtime และ alarm status เราสามารถดึงข้อมูลเหล่านี้เข้าสู่ Prometheus หรือ Zabbix เพื่อสร้าง alert เมื่อ runtime เหลือน้อยกว่าเวลาที่จำเป็นต่อการ failover

เครื่องปั่นไฟฉุกเฉินและการสลับโหลดอัตโนมัติ (ATS)

ATS คือสวิตช์อัตโนมัติที่ตัดสินใจเปลี่ยนแหล่งจ่ายไฟระหว่าง utility, UPS และ generator โดยไม่ต้องมีมนุษย์กดปุ่ม ในระบบที่ออกแบบมาดี ATS จะทำงานคู่กับ generator controller เพื่อให้แน่ใจว่าไฟจากเครื่องปั่นไฟมีความถี่และแรงดันที่เสถียรก่อนจะถูกสลับเข้าโหลด มาตรฐานทั่วไปคือ NFPA 110 สำหรับ emergency power systems

ปัญหาที่พบบ่อยในทางปฏิบัติคือการซิงโครไนซ์ระหว่าง ATS หลายตัว เมื่อดาต้าเซ็นเตอร์มี generator หลายเครื่องและ ATS หลายตัว การสลับที่ไม่ประสานกันอาจทำให้เกิด short-duration power glitch ที่ทำให้เซิร์ฟเวอร์บางตัว reboot แม้ UPS จะยังทำงานอยู่ก็ตาม เราเคยเจอเหตุการณ์ที่ server rack หนึ่ง reboot ทั้ง rack เพราะ ATS คู่หนึ่งมี timing mismatch กัน 300 มิลลิวินาที

การออกแบบที่ดีต้องทำ coordination study เพื่อกำหนด sequence การทำงานของ breaker และ ATS อย่างชัดเจน รวมถึงต้องมี bypass switch ที่ให้ maintenance โดยไม่ต้องตัดโหลด สำหรับทีม DevOps ที่ดูแลศูนย์ข้อมูลขนาดเล็กหรือห้อง server ภายในองค์กร การทบทวน single point of failure ที่เกี่ยวข้องกับพลังงานคือขั้นตอนแรกที่ควรทำ

SRE กับการเตรียมความพร้อมรับมือไฟฟ้าดับ

Site Reliability Engineering มีเครื่องมือที่ใช้จัดการความเสี่ยงจากไฟฟ้าดับโดยตรง นั่นคือการทำ risk analysis และกำหนด SLO (Service Level Objective) ที่สอดคล้องกับความสามารถทางพลังงานของ infrastructure ตัวอย่างเช่น หากดาต้าเซ็นเตอร์ของคุณมี generator ที่สตาร์ทได้ภายใน 60 วินาที SLO ของคุณต้องยอมรับช่วง downtime อย่างน้อย 60 วินาที ไม่เช่นนั้นคุณจะตั้งเป้าหมายที่ทำไม่ได้

งานสำคัญของ SRE ในการรับมือไฟฟ้าดับคือการเขียน runbook ที่ชัดเจน ตั้งแต่การตรวจสอบ UPS status ตามลำดับความสำคัญของ service ไปจนถึงขั้นตอนการ failover ไปยัง secondary site ผมแนะนำให้ใช้ discovery-driven runbook แทน runbook แบบตายตัว เพราะสถานการณ์จริงมักไม่ตรงกับที่ซ้อมไว้ เมื่อใดก็ตามที่ระบบพึ่งพา associative information ที่ไม่สมบูรณ์ การตัดสินใจแบบ dynamic ตามข้อมูลจาก monitoring จะช่วยลด MTTR ได้มาก

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

ระบบเฝ้าระวังและตรวจจับปัญหาไฟฟ้าแบบเรียลไทม์

การตรวจจับเหตุการณ์ ไฟฟ้าดับ ไม่ควรพึ่งมนุษย์สังเกตว่า "เซิร์ฟเวอร์ดับไปแล้ว" เราต้องมีระบบ telemetry ที่รายงานสถานะพลังงานเป็น metric ที่สามารถ query และ alert ได้ทันที ตัวเลือกยอดนิยมในวงการคือ DMTF Redfish API ซึ่งเป็นมาตรฐานเปิดสำหรับจัดการ hardware ผ่าน RESTful interface รวมถึงการอ่านค่า power consumption, thermal status