เล่าเรื่องจริงจากทีมระบบของ Jane Street ว่าการสลับระบบไฟดับเพลิงอัตโนมัติทำให้ฝั่งเดียวกับ CRAC ที่ทำความร้อน ทำให้ต้องไถ่สายไฟทุกเครื่องในห้องเซิร์ฟเวอร์ก่อนเทียวศูนย์สูตรน้ำพุ่งลงมา
มีเรื่องเล่าคลาสสิกจากงานจริงที่ผมชอบมาก และเพิ่งเจอมาวันนี้ เป็นเรื่องของ Michael Bacarella อดีตสมาชิกทีมระบบของ Jane Street เรื่องที่เกิดขึ้นเมื่อปี 2012 (ช่วง Hurricane Sandy) และเพิ่งถูกเขียนออกมาเป็นบทความเมื่อ 10 พ.ย.
เรื่องคือ สัญญาณเตือนควันไฟหลอก ทำให้ระบบดับเพลิงอัตโนมัติตั้งใจเปิดน้ำท่วมห้องเซิร์ฟเวอร์ทั้งห้อง และคนที่ต้องแก้คือคนที่วิ่งกลับเข้าเมือง
Jane Street เคยย้าย machine room ไปไว้ติดกับ trading floor ด้วยเหตุผลสองข้อ:
เรื่องความปลอดภัยของ IP — กลัวเซิร์ฟเวอร์โดนขโมย แล้วศัตรูจะไปเรียนรู้กลยุทธ์การเทรด
เรื่องความเสี่ยงจากระบบอัตโนมัติ — ต้องการทางเลือกสำรองที่ปิดระบบได้ด้วยการ "วิ่งข้ามห้องไปถอดสายไฟ"
Michael เขียนว่าวัฒนธรรมความเสี่ยงแบบนี้ไม่ได้มาจากการอ่านบทความวิชาการ แต่มาจาก partner ที่เคยรับราชการในเรืออาบัตินิวเคลียร์ เขาเปรียบว่าบนเรือ คุณจะไม่เชื่อระบบอัตโนมัติถ้าไม่มี "คันโยกแดงที่เชื่อมกลไกจริง" ไว้ดึงเพื่อปิดมัน
Jane Street ก็เลยต้องการเครื่องที่ "ดึงสายไฟได้" และเมื่อครั้งหนึ่งก็ได้ใช้จริง ทั้งที่ไม่ได้คิดว่าจะต้องใช้ในแบบนี้
ขั้นตอนของระบบ sprinkler ในอาคารสำนักงาน (ตามที่ Michael อธิบาย) มี 3 ชั้น และชั้นที่สามคือจุดที่ทำให้เรื่องนี้น่าสนใจ:
ชั้นที่ 1 — ไม่เก็บน้ำไว้ตลอดเวลา เพื่อไม่ต้องเจอปัญหาน้ำรั่วในท่อที่ค้างอยู่เหนือหัวเวลาหลายปี
ชั้นที่ 2 — ประสาทไฟกับควันไฟแยกกัน สปริงเกลอร์ไม่มีเซ็นเซอร์ควันไฟติดตัว ระบบอื่นตรวจจับควันแล้วสั่งให้ท่อเต็มน้ำแรงดัน แต่ยังไม่พ่น
ชั้นที่ 3 — ความร้อนคือตัวสั่งพ่นน้ำ หัวสปริงเกลอร์แต่ละตัวมี plug ที่ sensitive กับความร้อน เมื่ออากาศรอบ ๆ ร้อนพอ plug จะแตก น้ำก็พุ่งออกมา
ตรรกะของมันคือ: "ถ้าควันไฟจริง ต้องร้อนจนไฟดับไม่ได้ น้ำจึงควรพุ่งมาดับ" ซึ่งเป็นเหตุผลที่ดี
แต่ก่อนถึงชั้นที่ 3 มีอีกก้าวหนึ่งที่พลิกเกม
ก่อนสปริงเกลอร์พ่นน้ำ ระบบตรวจจับควันไฟจะทำอย่างหนึ่งที่ดูเหมือนจะเป็นเรื่องปกติ: สั่งให้ปิด CRAC unit (เครื่องปรับอากาศห้องเซิร์ฟเวอร์)
เหตุผลก็สมเหตุสมผล ถ้ามีไฟจริง การหมุนอากาศในห้องจะช่วยเติมออกซิเจนให้ไฟ ดังนั้นต้องปิดการไหลเวียนอากาศ
แต่นี่คือปัญหา: ห้องเซิร์ฟเวอร์ต้องการความเย็นมาก และมันสร้างความร้อนตัวเองด้วย เมื่อปิด CRAC ทั้งหมด อุณหภูมิจะพุ่งขึ้น ขณะที่สปริงเกลอร์กลับเตรียมพร้อมแล้วเพราะระบบควันไฟทำงาน
แปลว่า: ไฟไม่มีจริง แต่น้ำพร้อมแล้ว และความร้อนกำลังขึ้น
Michael เขียนว่า "ถ้าคุณมองเห็นปัญหานี้แล้ว" ซึ่งแปลว่าคนที่อ่านคนอื่นก็คงพลิกไปมองเพดานก่อนจะเดินต่อ
บ่ายวันหนึ่ง ช่างกำลังเจาะทำเหมือนในห้องเตรียมอาหารข้าง ๆ ดาต้าเซ็นเตอร์ ฝุ่นที่ถูกเจาะขึ้นไปทำให้ สัญญาณเตือนควันไฟดัง
ตอนนั้น Michael กำลังจะขึ้นลิฟต์ที่บ้าน โทรศัพท์ดัง — ฝั่งฮ่องกงกง (เวลาที่ฮ่องกงมีปัญหา นิวยอร์กก็มีปัญหา ประเด็นคือหมายถึงเขาต้องแก้) มีเขาโทรหา
ภารกิจที่เขาได้รับ: ไปถอดสายไฟของทุกเครื่องในห้องนั้น ก่อนอุณหภูมิจะขึ้นถึง 150°F และสปริงเกลอร์จะทำลายทุกอย่าง
I ran down the (ironically named) Water Street in the Financial District faster than probably anyone has ever run down it, mashed the elevator button in the lobby of 1 NYP, waited very impatiently for the elevator to climb the 33 floors, slammed my keycard against the reader, booked through the main office door, took a hard right turn to the machine room door, slammed my keycard against that, stepped into what felt like a sauna and went row by row, cabinet by cabinet, yanking power cables out with both hands.
แล้วก็นั่งดูอุณหภูมิ:
141 F. 142. 143. 143.5. 143.6. Finally it stopped.
ที่น่าสนใจคือชื่อถนน — Water Street — ในย่านการเงิน ตลอดเวลาที่วิ่งไปถอดสายไฟกันน้ำท่วม เขาวิ่งอยู่บน Water Street
ตอนนั้นที่ตลาดนิวยอร์กปิดอยู่ ความเสียหายจึงจำกัดอยู่แค่นั้น และเช้าวันรุ่งขึ้นก็กลับมาทำงานได้ปกติ
Michael เขียนปิดท้ายว่าห้องเซิร์ฟเวอร์ถูกวางไว้ตรงข้ามห้องเทรดเพื่อให้ "คนวิ่งเข้ามาแล้วถอดสายไฟได้" — และคงไม่มีใครคิดว่าจะต้องทำแบบนั้นเพื่อ "ช่วยเซิร์ฟเวอร์จากสปริงเกลอร์"
หลังจากนั้นทีมงานเลยสร้างระบบเฝ้าดูอุณหภูมิขึ้นมา และ Michael เขียนมันด้วย OCaml
เหตุผลที่เขาเล่ามีน่าสนใจมาก:
No one server was configured to alert just because it was a little hot, since that happens from time to time. But an across the board increase in temperature on many servers means there is a generalized cooling failure.
We needed was a system monitor built for this exact purpose, one we could trust to be ultimately, unfailingly reliable at the task of asking each Linux server for its temperature and computing a simple mean. Bash wouldn't cut it for this. Nor would Perl. No, a job of this magnitude called for the most reliable and type-safe programming language imaginable.
Bash ไม่พอ, Perl ก็ไม่พอ เพราะงานนี้ต้องเชื่อถือได้ที่สุด ที่เขาต้องการคือค่าเฉลี่ยของอุณหภูมิจากทุกเครื่อง ถ้าค่าเฉลี่ยสูงขึ้นแปลว่า cooling ล้มเหลวทั้งระบบ แล้วก็แจ้งเตือนทุกคนในทีมระบบ
สิ่งที่เขาทำคือ OCaml ที่ทำงานทุกนาที: ถามทุกเซิร์ฟเวอร์ Linux ในทุก location ว่าอุณหภูมิเป็นเท่าไร ด้วยเซ็นเซอร์บนบอร์ดเอง แล้วเฉลี่ย ถ้าสูงเกินกำหนดก็ยิงแจ้งเตือน
เขายังอธิบายว่าทำไมถึงไม่แจ้งเตือนจาก CRAC ที่หยุดทำงานหรือจากเซ็นเซอร์อุณหภูมิเฉพาะในห้อง เพราะ telemetry ของพวกนั้นไม่น่าเชื่อถือ และ "unknown unknowns ก็ยังทำลายคุณได้" — ของที่ทนทานที่สุดคือถามเครื่อง Linux ของคุณเองว่าร้อนแค่ไหน แล้วตกใจเมื่อค่าเฉลี่ยสูงขึ้นนิดหน่อย
เรื่องนี้ไม่ใช่แค่เรื่องสนุก ๆ มีบทเรียนที่ใช้ได้จริง:
1. ระบบอัตโนมัติที่ "ป้องกัน" อาจสร้างปัญหาใหม่ การปิด CRAC อัตโนมัติเป็นการกระทำที่ถูกต้องในบริบทของไฟจริง แต่ในบริบทของ false positive มันกลายเป็นการเร่งให้เกิดหายนะ เรื่องนี้เรียกว่า cascade failure หรือ coupled failure — ระบบที่ "ช่วย" เราตอนเกิดปัญหากลายเป็นตัวเร่งปัญหา
2. การสังเกตที่ดีที่สุดมักไม่ใช่สัญญาณที่ตรงที่สุด เขาเลือกถามเซิร์ฟเวอร์แทนที่จะเชื่อ CRAC telemetry เพราะข้อมูลที่ซับซ้อนกว่าไม่ได้แปลว่าข้อมูลที่น่าเชื่อถือกว่า
3. คนเริ่มที่ดึงสายไฟ คือ feature ไม่ใช่ bug Jane Street ออกแบบให้ดึงสายไฟได้ แล้วมันก็ช่วยชีวิตจริง ถึงแม้ในสถานการณ์ที่ไม่ได้อยู่ในแผน
4. เทคโนโลยีที่เลือกสะท้อนวิธีคิด "Bash ไม่พอ Perl ก็ไม่พอ" — นี่คือคนที่เลือก OCaml เพราะอยากได้ type safety ไม่ใช่เพราะแฟนเชียร์ OCaml
Michael เขียนปิดท้ายว่าทีมไม่ค่อยได้คุยกับ partner คนที่มีประสบการณ์เรืออาบัตินิวเคลียร์ แต่หวังว่าเขาจะอนุมัติกับการเลือก OCaml
Michael ใส่ disclosure ไว้ว่าเรื่องนี้เขียนด้วยมือคนล้วน ๆ AI มีแค่ช่วยพิสูจน์อักษรและเก็บคำผิดเล็กน้อย พร้อมใส่ "รอยยับยี้อันสวยงาม" ทิ้งไว้เพื่อเพิ่มความรู้สึก Wabi-Sabi
ซึ่งตรงกับบรรยายของเขาเองที่ว่าทีมระบบเป็น "OCaml programmers ชั้นสีน้ำเงิน" ที่ไม่เคยอยู่เหนือการรับมือกับงานจริง
เรื่องแบบนี้ผมคิดว่าเป็นสิ่งที่หายากมากในวงการ — เรื่องเล่าวอร์สตอรีที่เล่าด้วยน้ำเสียงคน แบบยังไม่ได้กลายเป็นโพสต์ LinkedIn
Umami บน Coolify ขึ้น 0 Visitors: เจอ 3 บั๊กซ้อนกัน (503, Docker ARG และ Domain) แก้ทีละชั้น
16 Nov 2026 · 5 min read
AWS Emulator: ให้ AI Agent เขียนและทดสอบโค้ด AWS ได้ในเครื่องตัวเอง โดยไม่ต้องแตะบัญชีจริง
13 Nov 2026 · 5 min read
What is OpenClaw and How to Install OpenClaw in Docker
06 Apr 2025 · 5 min read