ความผิดพลาดกับ Mars Rover มูลค่า 500 ล้านดอลลาร์ของผม

• ในเดือนกุมภาพันธ์ 2003 ที่ห้องคลีนรูมของ JPL ยานสำรวจดาวอังคาร Spirit เหลือเวลาอีก 2 สัปดาห์ก่อนถูกส่งไปยังฐานปล่อย และความผิดพลาดในการต่อ break-out-box เพียงครั้งเดียวอาจทำลายยานอวกาศมูลค่า 500 ล้านดอลลาร์ได้
• Spirit และ Opportunity คือภารกิจยานสำรวจดาวอังคารฝาแฝดของ NASA ที่ใช้งบเกือบ 1 พันล้านดอลลาร์ และแทบไม่มีเวลาเผื่อสำหรับซ่อมความเสียหายใหญ่ตามกำหนดการ
• ทันทีหลังพัลส์ไฟฟ้าไหลเข้าไปทางฝั่งยานอวกาศแทนที่จะเป็นมอเตอร์ เทเลเมทรีก็ขาดหายไป แต่ยังไม่สามารถยืนยันได้ทันทีว่ามีความเสียหายหรือสาเหตุคืออะไร
• วันถัดมามีการยืนยันว่าการสูญเสียเทเลเมทรีเกิดจากการถอดสายวัดของ Fluke 87III multimeter และประเด็น surge จริงยังคงถูกวิเคราะห์ในช่อง H-Bridge motor driver
• หลังการวิเคราะห์หลายสัปดาห์ โครงการตัดสินให้ฮาร์ดแวร์ Use As Is แก้ไขขั้นตอนการทำงาน แล้วทดสอบแบบเดิมต่อไป และมอเตอร์ตัวดังกล่าวของ Spirit ก็ทำงานได้ตามปกติบนดาวอังคาร

---

อุบัติเหตุระหว่างการทดสอบบน Spirit ก่อนปล่อยไม่นาน

• ในเดือนกุมภาพันธ์ 2003 ที่คลีนรูม Building 179 High Bay 1 ของ NASA JPL ยานสำรวจดาวอังคาร Spirit เหลือเวลาอีกเพียง 2 สัปดาห์ก่อนถูกขนส่งไป Cape Canaveral
• Spirit และ Opportunity เป็นภารกิจยานสำรวจดาวอังคารฝาแฝด และในเวลานั้นเป็นยานอวกาศที่ซับซ้อนซึ่ง NASA ลงทุนไปเกือบ 1 พันล้านดอลลาร์
• ในขั้นตอนประกอบและทดสอบ จำเป็นต้องทดสอบทุกระบบอย่างละเอียดและยืนยันว่าทำงานปกติก่อนปิดยานเป็นครั้งสุดท้ายบนโลก
• ยานทั้งสองลำมี brushed-type motor 62 ตัว
  • ขับเคลื่อนและบังคับเลี้ยวล้อ
  • ควบคุมแขนกล
  • เล็งกล้อง
  • หันทิศเสาอากาศไปทางโลก
  • กลไกกางและคลี่ตัวหลังลงจอด
• คืนนั้นอุปกรณ์ที่ทดสอบคือมอเตอร์ RAT-Revolve ภายใน Rock Abrasion Tool(RAT) ที่ปลายแขนกลของ Spirit
  • มอเตอร์ RAT-Revolve ทำหน้าที่หมุน grinder และ brush บนหินดาวอังคาร

ขั้นตอนตรวจสอบสถานะมอเตอร์ด้วยสัญญาณไฟฟ้า

• การถอดมอเตอร์ออกมาตรวจภายในหลังการทดสอบสภาพแวดล้อมทุกครั้งไม่ใช่วิธีที่ใช้งานได้จริง
• จึงแยกมอเตอร์ออกจากยานอวกาศ แล้วต่อเข้ากับแหล่งจ่ายไฟภายนอกและ strip chart recorder เพื่อตรวจสอบสมรรถนะทางไฟฟ้า
• มอเตอร์ปกติจะมีกระแสลดลงอย่างราบรื่นเป็นรูปเอ็กซ์โพเนนเชียลระหว่าง spin-up และหากมีความผิดปกติจะมี blip ปรากฏในสัญญาณ
• การทดสอบใช้ break-out-box และหากต่อผิด กระแสขนาดใหญ่สามารถไหลไปผิดที่และสร้างความเสียหายร้ายแรงได้
• ในการตรวจสอบล่วงหน้า มีการยืนยันแล้วว่าอินเทอร์เฟซการเชื่อมต่อ การตั้งค่าแหล่งจ่ายไฟ การตั้งค่า strip chart และพัลส์ทดสอบสั้น ๆ กับมอเตอร์อ้างอิง ล้วนถูกต้อง

พัลส์ไฟฟ้าที่ไหลเข้าไปผิดทิศทาง

• ทันทีที่จ่ายพลังงานให้มอเตอร์ RAT-Revolve สัญญาณบน strip chart แสดงรูปแบบที่ไม่คุ้นเคย และไม่เหมือนสัญญาณของมอเตอร์เสียตามปกติ
• เมื่อตรวจตามสาย จึงพบว่าเพราะ ความผิดพลาดของ break-out-box พัลส์ไฟฟ้าไม่ได้เข้าไปที่มอเตอร์ แต่ไหลย้อนเข้าไปทางฝั่งยานอวกาศซึ่งอยู่คนละด้านของอินเทอร์เฟซคอนเน็กเตอร์
• ขณะนั้น Spirit เหลือเวลาเพียง 2 สัปดาห์ก่อนขนย้ายเพื่อเตรียมปล่อย ดังนั้นถ้าเกิดปัญหาใหญ่ก็จะไม่มีเวลาฟื้นฟู
• เหตุการณ์ถูกแจ้งให้ Leo ซึ่งเป็น test conductor ทราบทันที และในเวลาเดียวกันก็ได้รับคำตอบว่าเทเลเมทรีจากยานอวกาศขาดหายไป
• ทีมจึงดำเนิน ขั้นตอนปิดฉุกเฉิน ทันที และได้รับคำสั่งให้ออกจากคลีนรูมเพื่อประเมินลำดับเหตุการณ์และความเสียหาย

การสูญเสียเทเลเมทรีและการประเมินเบื้องต้น

• ข้อเท็จจริงที่ยืนยันได้ทันทีหลังเหตุการณ์มีอยู่สองอย่าง
  • มีพัลส์ไฟฟ้าขนาดใหญ่ไหลเข้าไปผิดจุดจากที่ตั้งใจ
  • เทเลเมทรีของยานอวกาศหยุดทำงาน
• ความเชื่อมโยงระหว่างสองเหตุการณ์นี้ยังไม่ชัดเจนในทันที
• ทีมมองว่ามีความเป็นไปได้สูงที่ surge ไฟฟ้าจะเข้าไปในวงจร H-Bridge motor driver
  • H-Bridge เป็นวงจรที่ใช้ควบคุมการไหลของกระแสไฟฟ้า
  • และเป็นหนึ่งในส่วนที่ออกแบบให้ทนพลังงานเพิ่มจาก back-EMF บนยานสำรวจได้
• ยานอวกาศถูกปิดอยู่แล้ว และทีมตัดสินใจตรวจว่าปัญหาจะหายไปหรือไม่เมื่อจ่ายไฟกลับเข้าไปใหม่
• ใกล้เที่ยงคืน รายงานเหตุการณ์ได้ถูกส่งต่อไปถึงผู้จัดการโครงการ Pete และมีความเป็นไปได้ว่าต้องวางแผนใหม่สำหรับโครงการขนาดประมาณ 1,000 คน

การรีบูตที่ไม่สำเร็จและสาเหตุจริงที่พบในวันถัดมา

• มีการรันขั้นตอนจ่ายไฟให้ยานอวกาศตามมาตรฐานอีกครั้ง แต่หลังจากอุปกรณ์อิเล็กทรอนิกส์และซอฟต์แวร์เริ่มทำงานแล้ว เทเลเมทรีก็ยังไม่กลับมา
• ที่ rack ของ ground support equipment มีไฟสีแดงที่ติดขึ้นเมื่อได้รับพัลส์ในแต่ละ clock cycle และทำหน้าที่เหมือนการเต้นของหัวใจของหุ่นยนต์ที่ความถี่ 8 ครั้งต่อวินาที
• แหล่งจ่ายไฟแสดงระดับแรงดันและการเปลี่ยนแปลงกระแสตามที่คุ้นเคย แต่ไฟแสดงสถานะไม่ติด และเทเลเมทรีก็ไม่ออกมา
• วันถัดมา ระหว่างทบทวนลำดับเหตุการณ์อีกครั้ง Fluke 87III digital multimeter กลายเป็นเบาะแสสำคัญ
• ระหว่างค้นหา multimeter ที่จำเป็นต่อการทดสอบในวันก่อน มีการถอดสายวัดของ multimeter ที่ดูเหมือนกำลังมอนิเตอร์ bus voltage ใกล้ยานอวกาศออก
  • แท้จริงแล้ว multimeter เครื่องนี้กำลังทำให้วงจรไฟเลี้ยงเทเลเมทรีสำหรับการทดสอบภาคพื้นของยานอวกาศครบวงจร
  • ทันทีที่ถอดสายวัด การเชื่อมต่อไฟเลี้ยงเทเลเมทรีก็ถูกตัด

Spirit ยังมีชีวิตอยู่ และฮาร์ดแวร์ถูกใช้งานต่อไปตามเดิม

• ทีมทำให้ multimeter กลับไปทำหน้าที่เดิม แล้วเปิดไฟให้ยานอวกาศอีกครั้ง
• เทเลเมทรีกลับมาทำงานอีกครั้ง และยืนยันได้ว่า Spirit ไม่ได้ตาย
• ความเสียหายจริงกินเวลาเพียงไม่กี่ชั่วโมง และการทดสอบก็กลับมาดำเนินต่อ
• หลังจากนั้นอีกหลายสัปดาห์ มีการวิเคราะห์ ช่อง H-Bridge ของมอเตอร์ RAT-Revolve และมีการอภิปรายเชิงลึกเกี่ยวกับความเป็นไปได้ของ thin-film demetallization
• ในที่สุดโครงการตัดสินให้ฮาร์ดแวร์ดังกล่าวเป็น Use As Is
• การเตรียมปล่อยยานดำเนินต่อไป และหลังจาก Spirit ไปถึงดาวอังคาร มอเตอร์ RAT-Revolve ก็ทำงานได้ตามปกติ

วิธีรับมือกับประสบการณ์ความล้มเหลว

• เหตุการณ์นี้นำไปสู่ความเชื่อว่าการแบ่งปันประสบการณ์ความล้มเหลวสามารถเป็นบทเรียนได้ทั้งต่อผู้เล่าและผู้ฟัง
• ที่ Planetary Resources มีการขอให้ผู้สมัครแบ่งปัน failure story ของตนเองในกระบวนการรับสมัครและวัฒนธรรมทีม
• ระหว่างวิกฤต Ernie พูดไว้ว่า “ครั้งหน้าที่ต้องอนุมัติว่าอะไรสักอย่างโอเค ให้จำความรู้สึกนี้ไว้”
• หลังเหตุการณ์ บางคนมองว่าควรหยุดการทดสอบที่เสี่ยงอันตราย แต่เพราะความสำคัญของการยืนยันว่าสามารถให้มอเตอร์ทำงานได้ตามปกติบนดาวอังคาร การทดสอบจึงดำเนินต่อ
• ผู้จัดการโครงการ Pete ให้คนเดิมเป็นผู้นำการทดสอบต่อ โดยตัดสินในทำนองว่า “เราได้จ่ายค่าเล่าเรียนของเขาไปแล้ว และเขาคือคนที่มีโอกาสน้อยที่สุดที่จะทำผิดพลาดแบบนี้ซ้ำอีก”
• หลังจากนั้นได้มีการแก้ไขขั้นตอนเพื่อไม่ให้เกิดความผิดพลาดเดิมซ้ำ และทำการทดสอบแบบเดียวกันนี้ซ้ำอีกหลายครั้ง
• ประสบการณ์นี้กลายเป็นจุดอ้างอิงที่ทำให้นึกถึงความกลัวและความเสียใจในตอนนั้นทุกครั้งที่ต้องให้การอนุมัติหรือรับรองสิ่งสำคัญ

[GN⁺]

ความเห็นจาก Hacker News

• เขียนได้ดีมาก
  ในฐานะวิศวกรซอฟต์แวร์ มันทำให้นึกถึงเหตุการณ์คล้ายกันที่เจอช่วงต้นอาชีพจนถึงทุกวันนี้ ราว 10 ปีก่อนตอนเป็นที่ปรึกษาให้ลูกค้ารายหนึ่ง ผมใช้เวลาหลายเดือนทำเวอร์ชันใหม่ของเว็บเซอร์วิสของพวกเขา และรับหน้าที่ deploy ในวันเปิดตัว ตอนนั้นขั้นตอนพัฒนาและ deploy เกือบทั้งหมดเป็นงานทำมือ ผมทำส่วนที่พอทำอัตโนมัติได้ด้วยสคริปต์และ SQL แล้วพอกด Enter เพื่อรันการทดสอบสุดท้ายก่อน deploy ก็เพิ่งนึกได้ว่าผมเพิ่งสลับไปใช้ credentials ของ production
  พอ error เริ่มกองและบริการไม่ตอบสนอง ผมมั่นใจว่าเผลอลบฐานข้อมูลไปแล้ว แต่โชคดีที่ไม่กี่ชั่วโมงก่อนหน้านั้นมีคนเพิ่งทำแบ็กอัปไว้รับการเปิดตัว จึงกู้กลับมาได้เกือบทั้งหมด หลังจากนั้นเวลาต้องแตะฐานข้อมูลหรือระบบ production คำว่า ระวัง ยังไม่พอด้วยซ้ำ และผมก็ตั้งใจว่าจะไม่ให้เกิดแบบนั้นอีก

  • ที่เราก็ใช้ event sourcing architecture เลยแทบไม่ต้องเข้าถึงฐานข้อมูล production โดยตรง ถ้าจำเป็นก็จะใช้เชลล์สคริปต์เปิด tunnel ผ่าน bastion host และ export environment variables มาตรฐานสำหรับตั้งค่า Postgres client
    test suite จะลบแล้วสร้างตารางใหม่ หรือไม่ก็ล้างตารางระหว่างรัน วันหนึ่งหัวหน้าทีม dev เข้าไปไล่แก้บั๊กบน production DB แล้วรัน make test ต่อทันที โค้ดทดสอบเลยตาม environment variables เดิมและไปต่อ production แทน Docker จากนั้นก็กระหน่ำลบและสร้างตาราง production เหล่านั้นใหม่หลายสิบรอบ
  • ราว 10 ปีก่อน ที่บริษัทที่ผมไปเป็นที่ปรึกษา มีพนักงานภายในที่ดูแลอีกผลิตภัณฑ์หนึ่งล็อกอินทั้ง dev DB และ production DB ไว้พร้อมกันคนละหน้าต่าง แล้วเผลอลบ ฐานข้อมูล production ผิดตัว พอจะกู้ก็พบว่าแบ็กอัปล้มเหลวมาหลายเดือนแล้ว เลยยิ่งชัดว่าทำไมถึงต้องจ้างที่ปรึกษามาช่วยผลิตภัณฑ์ใหม่
    โชคดีที่แต่ละไซต์ลูกค้ามี local DB ที่ซิงก์กับ DB กลาง ทำให้ตัวผลิตภัณฑ์ยังทำงานได้แม้การเชื่อมต่อจะขาด เขาเลยทำงานหนักอยู่ 3-4 วัน เอาแบ็กอัปเก่ามาผสมกับข้อมูลจากลูกค้าเพื่อสร้าง master DB ขึ้นใหม่
  • ผมเคยรัน migration ใส่ฐานข้อมูล production จากใน Visual Studio พอย้อนคิดก็กู้ได้อยู่หรอก แต่ตอนเห็นทุกตารางใน tree view ของ VS เริ่มหายไปทีละอัน หัวใจแทบหยุดเต้น
    อีก 1 วินาทีต่อมามันกลับมาหมด ที่จริงแค่ view รีเฟรชใหม่ UI แย่มากจริง ๆ
  • เมื่อประมาณ 15 ปีก่อน ตอนกำลังจะกลับบ้านก่อนวันหยุดยาว เพื่อนร่วมงานฝ่ายการตลาดที่สนิทกันขอให้ช่วยแก้อะไรเล็กน้อยบนไซต์ลูกค้า บริษัทมีคนแค่ราว 15 คน และมีลูกค้ามากเกินกว่าจะรับมือไหว ผมเลยมี สิทธิ์เข้าถึงฐานข้อมูล production ที่ไม่ควรมี
    ผมเขียนคำสั่ง UPDATE สั้น ๆ เพื่อเปลี่ยนข้อความการตลาดของสินค้า แต่ทันทีที่มันไม่จบทันที ผมก็รู้ว่าพังแล้ว เพราะผมอัปเดตทั้งชุดโดยไม่มีเงื่อนไข ทำให้คำอธิบายสินค้าหลายพันรายการถูกเปลี่ยนทั้งหมด DBA ที่เข้าถึงแบ็กอัปได้อยู่คนละเขตเวลาและเลิกงานไปแล้ว ต้องโทรตามอยู่นานกว่าชั่วโมงถึงจะกู้กลับมาได้
    การแก้เร็ว ๆ ตอนเดินออกจากออฟฟิศกลายเป็นงานกู้สถานการณ์หลายชั่วโมง เพื่อนฝ่ายการตลาดขอโทษไม่หยุด แต่ความผิดเป็นของผมเอง ที่ลูกค้าไม่ว่าอะไรมากคงเพราะตอนนั้นเป็นวันศุกร์ 5 โมงเย็นก่อนสุดสัปดาห์วันหยุด
  • ที่ทำงานเมื่อราว 20 ปีก่อนมีนโยบายว่า เวลาใช้คำสั่ง sudo ก่อนกด Enter ต้องมี อีกคนหนึ่งช่วยตรวจคำสั่ง ก่อน อาจเอานโยบายหรือธรรมเนียมคล้ายกันไปใช้กับทุกอย่างที่ทำบน production ได้

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

  • ที่โบรกเกอร์หลักทรัพย์รายใหญ่แห่งหนึ่ง เคยมี test script ไปโดน production โดยไม่ได้ตั้งใจ จนสร้าง ธุรกรรมทดสอบ FX ปลอม มูลค่าหลายล้านดอลลาร์
    ในสาย postmortem ประโยคแรกคือ “เราจะไม่โทษคนที่สร้างธุรกรรมพวกนั้น มันเป็นความผิดพลาดโดยสุจริต ทีนี้มาคุยกันดีกว่าว่าทำไมนักพัฒนาถึงเรียก production trading API ได้โดยไม่ต้องยืนยันตัวตน”
  • ในความล้มเหลวระดับองค์กรแบบนี้ ไม่ควรโทษปัจเจก มองเห็นปัญหาเชิง process อยู่สองอย่าง: ถ้าสามารถเสียบปลั๊กกลับด้านได้ ก็ควรออกแบบให้ทำแบบนั้นไม่ได้ตั้งแต่แรก หรืออย่างน้อยต้องระบุความเสี่ยงไว้และให้มีคนสองคนขึ้นไปช่วยยืนยันทิศทาง และเครื่องมืออย่างมัลติมิเตอร์ที่ใช้อยู่ก็ไม่ควรถูกถอดออกเด็ดขาด
    ถ้าโทษแต่คน คนคนนั้นก็จะถูกไล่ออกและทั้งองค์กรก็อ่อนแอลง เหมือนคุณปล่อยคนเดียวที่ได้บทเรียนราคาแพงที่สุดออกไป ช่วงเดียวที่ควรเอาผิดกับตัวบุคคลคือเมื่อมีเจตนาจะก่ออันตราย ซึ่งกรณีนั้นกฎหมายอาจเข้ามาเกี่ยวข้องได้
  • วันแรกของงานเว็บดีเวลลอปเมนต์งานแรกหลังเรียนจบ ผมก็ทำให้ เว็บไซต์ production ล่มตั้งแต่วันแรก มีผู้เข้าชมหลายหมื่นคนได้รับผลกระทบและ sales lead ทั้งหมดหยุดลง แต่เราก็พามันกลับมาได้ภายในไม่กี่นาที ผ่านช่วงเวลาหนัก ๆ ที่ทั้งทีมและ CEO ห้องข้าง ๆ ยืนดูอยู่
    หลายปีต่อมาตอนใกล้ลาออก ผมได้เปลี่ยนไซต์ที่เปราะบางและไม่น่าไว้ใจนั้นให้กลายเป็นระบบที่มี automated tests, แบ็กอัปหลายชั้น, ระบบ failover ข้ามหลายดาต้าเซ็นเตอร์, รวมถึงการฝึกและ onboarding นักพัฒนาใหม่ ตอนนั้นยังเป็นยุคแรก ๆ ของ AWS ยังไม่ใช่สมัยที่ deploy เว็บไซต์ production ได้ในคลิกเดียว
    เพราะประสบการณ์นั้น ผมจึงได้เรียนรู้เรื่อง version control ที่เหมาะสม, development environment, Redis, sharding และ clustering, VM, replication ของ Postgres และ MySQL, wiki, monit, DNS, load balancer, reverse proxy และอีกมากมาย ก็เพราะไม่อยากทำเว็บไซต์ล่มอีกแล้ว
    มันเป็นบริษัทเล็ก ๆ ที่จ้างเด็กมัธยมปลายไม่จบซึ่งพอมีประสบการณ์ WordPress อยู่บ้างด้วยค่าแรงชั่วโมงละ 15 ดอลลาร์ ให้มาดูแลเว็บไซต์ production แต่หลังความผิดพลาด พวกเขาไม่ไล่ผมออก กลับให้ทั้งอิสระและความไว้วางใจให้เรียนรู้หน้างานและปรับปรุงระบบ ซึ่งผมยังรู้สึกขอบคุณจนถึงทุกวันนี้
  • กรณีนี้ต่างออกไป มันคือ รถสำรวจแบบคัสตอมที่มีอยู่คันเดียว ซึ่งเพิ่งได้ชื่อเป็นครั้งแรก และถึงจะมี process มากมายอยู่แล้ว ก็ใช่ว่าจะคาดการณ์ได้ทุกอย่าง หลังจากนั้นพวกเขาคงปรับ process กันแน่ แต่ต้องจำไว้ว่านี่ก็เป็นครั้งแรกของพวกเขาเหมือนกัน
    การมีกฎเยอะและ process ดีขึ้นไม่ได้แปลว่าดีเสมอไป บางครั้งระบบราชการก็ทำให้ NASA ที่ช้าอยู่แล้วช้าลงไปอีก ในภารกิจแบบที่ไม่เคยมีมาก่อน บางครั้งคุณก็ต้องพึ่งคนมากกว่า process และยอมรับความเสี่ยง
  • อดคิดไม่ได้ว่าถ้ารถสำรวจพังไปจริง ๆ จะเกิดอะไรขึ้น สิ่งที่หยุดมันไว้ดูเหมือนเป็นแค่โชคล้วน ๆ และก็ดูเหมือนอาจไปต่อเข้ากับสายผิดเส้นอื่นที่ไม่มีวงจรป้องกันได้เหมือนกัน
    แปลว่ามีส่วนหนึ่งที่อยู่นอกเหนือความสามารถของผู้เขียนในการตัดสินใจ และเขาก็อาจถูกจดจำไปตลอดกาลว่าเป็นคนที่ทำรถสำรวจพังอย่างที่เขากลัวไม่ต่างกัน

• เรื่องนี้เชื่อมโยงกับประสบการณ์ของผมมากเหมือนกัน ผมมักเลือกทำโปรเจกต์ที่ยากและเสี่ยงที่สุดในสายการบินขนาดใหญ่ และหนึ่งในนั้นคือการเร่งติดตั้ง ผู้ให้บริการชำระเงิน รายใหม่ให้กับเว็บไซต์ เว็บไซต์นั้นขายตั๋วมูลค่าหลายล้านยูโรต่อวัน
  หลัง deploy ไปไม่กี่วินาที ผมพลาดความต่างระหว่าง environment ทดสอบกับ production และพบว่าตัวแปรสำคัญตัวหนึ่งว่างเปล่าใน production เป็นเรื่องที่น่าจะคาดได้ถ้าอ่านเอกสารและเตรียมตัวให้มากกว่านี้ ยอดขายหยุดสนิทและใจผมหายวาบ หลังขั้นตอน rollback อันยาวนาน การขายหยุดไปหลายชั่วโมง ลูกค้าโกรธกันมาก และความเสียหายสูงถึงหลายล้านยูโร
  ผมดัก CEO ที่ลิฟต์แล้วบอกว่าเป็นความผิดของผมทั้งหมด และผมยอมรับผลทุกอย่างรวมถึงการถูกไล่ออก เขากลับหัวเราะแล้วตอบทำนองว่า “จะไล่คุณออกไปทำไม? เราเพิ่งจ่ายเงินหลายล้านเพื่อฝึกคุณนะ ตอนนี้คุณทำงานได้ดีกว่าเมื่อวานแล้ว” ประสบการณ์นี้หล่อหลอมผมในหลายด้าน รวมถึงทำให้เห็นภาวะผู้นำที่แท้จริง และหลังจากนั้นผมก็ปิดโปรเจกต์ความเสี่ยงสูงอีกหลายงานได้สำเร็จ

  • สำนวนมันธรรมดาเกินไป และรายละเอียดอย่างการไปหา CEO ตรงๆ หรือการมีทั้ง “พนักงานผลงานเด่น” กับ “บริษัทเสียหายหลายล้าน” อยู่ด้วยกัน ก็ดูไม่น่าเชื่อนิดๆ จนรู้สึกว่า LLM เขียน หรืออย่างน้อยก็เป็นเรื่องแต่ง
  • ผมรู้สึกบ่อยมากว่าหน้าจองตั๋วเครื่องบินพังอยู่ที่ไหนสักแห่งเกินครึ่งของเวลา ถึงจะไม่ถึงขั้นจอว่างเปล่าทั้งหมด แต่เสียจนจองตั๋วไม่ได้ก็เกิดขึ้นบ่อยมาก และผมว่าจอว่างไปเลยยังดีกว่า อย่างน้อยก็ไม่ต้องเสียเวลา 30 นาที
    อินเทอร์เน็ตโดยรวมก็พังบ่อยเหมือนกัน ตอนจ่ายเงินช่วง Black Friday เว็บช็อปของ Nike ก็ error แล้วทางช่วยเหลือก็บอกประมาณว่า “ให้ใช้แอป”
  • ความเสียหายอาจไม่ได้มากอย่างที่คิด ช่วงที่ไม่มีใครซื้อตั๋วได้หลายชั่วโมงนั้น ในทางทฤษฎีอาจเท่ากับเสียรายได้หลายล้านในช่วงเวลานั้น แต่ก็มีสมมติฐานว่าคนเหล่านั้นจะไม่กลับมาลองใหม่ทีหลัง
    ในความเป็นจริง ผมไม่คิดว่าเวลาระบบล่มจะถูกแปลงเป็นความสูญเสียทั้งหมดตรงๆ Twitter ยุคแรกๆ ก็ล่มบ่อยเพราะความนิยมและสถาปัตยกรรมของมัน แต่คนก็ไม่ได้เลิกใช้ Twitter
    สำหรับบริการออนไลน์ การล่มไม่ใช่หายนะหรือจุดจบของบริษัทเสมอไป จะต่างออกไปถ้าเป็นอุปกรณ์อวกาศหรือซอฟต์แวร์ซื้อขายความถี่สูงที่อาจทำให้บริษัทล้มละลายได้ ซึ่งนั่นยิ่งต้องมีมาตรการควบคุมที่เข้มงวดกว่า ในทางทฤษฎีก็ใช่ แต่ในความจริง บางครั้งระบบในวงการอวกาศหรือการซื้อขายความถี่สูงกลับแย่กว่า CRUD เว็บเซอร์วิสหละหลวมที่อ้างว่าทำตามแนวปฏิบัติที่ดีซึ่งเรียนมาจากวงการเหล่านั้นเสียอีก
  • ถ้าเป็นผู้รับผิดชอบของสายการบิน ผมคงอยากให้ปฏิกิริยาใกล้เคียงกับแนวคิดของ การวิเคราะห์หลังอุบัติเหตุการบิน มากกว่านี้ คือควรหาสาเหตุเชิงระบบแล้วแก้ให้ถูกจุด
    การ deploy ขึ้น production อาจต้องมีคนอีกคนที่ทำหน้าที่เหมือนนักบินผู้ช่วย คอยตรวจร่วมกันและมีสิทธิ์หยุด rollout ได้ พร้อมกับมีมาตรการป้องกันแบบ DevOps ทั่วไปประกอบกัน
  • ทำให้นึกถึงมุกเก่าที่ลงท้ายว่า “จะไล่ออกทำไม? เพิ่งเสียเงินหลายล้านไปกับการฝึกเขานะ!”
    คนที่รับงาน ความเสี่ยงสูง มักถูกประเมินค่าต่ำไป ผู้จัดการหลายคนชอบพนักงานที่เสถียรแต่ไม่สร้างคุณค่าอะไรเลย มากกว่าคนที่มีค่าคาดหวังเป็นบวกแต่มีความผันผวน

• ผมทำงานในวงการทีวี เมื่อ 30 ปีก่อนในงานแรกที่สถานีโทรทัศน์ท้องถิ่นเล็กๆ ผมได้รับการฝึกเป็น tape operator สำหรับรายการข่าว ม้วนเทปออกอากาศถูกกองเป็นตั้งใหญ่ และมี VTR สำหรับ playback อยู่สี่เครื่อง หน้าที่ของผมคือใส่เทปแต่ละม้วนแล้วตั้งไปที่จุด preroll 1 วินาที
  พอเทปเล่นจบและถึงเวลาต้องเอาออก มันง่ายมากที่จะเผลอกดปุ่ม eject ของ VTR ที่กำลังออกอากาศอยู่ตอนนั้น แทนที่จะเป็นเครื่องที่เพิ่งเล่นจบ คนที่ฝึกผมจะส่งเสียงเตือนดังๆ แบบกัดฟันสูดลมหายใจทุกครั้งที่เห็นผมเอื้อมมือไปที่ปุ่ม eject และเพราะเสียงนั้นผมจึงหยุดแล้วเช็กสองรอบสามรอบก่อนเอาเทปออก
  มันน่ารำคาญมาก แต่ได้ผลในการฝึกให้ระวังตัวจริงๆ นโยบายของสถานีคือ ถ้าดึงเทประหว่างออกอากาศเป็นครั้งแรก จะถูกพักงานหนึ่งวันโดยไม่รับค่าจ้าง ครั้งที่สองคือติดภาคทัณฑ์ ครั้งที่สามคือไล่ออก เพื่อนร่วมงานบางคนตกงานและทำข่าวพังเพราะความสะเพร่าเรื้อรัง ต้องขอบคุณเทรนเนอร์ที่น่ารำคาญคนนั้น ผมเลยติดนิสัยตรวจแล้วตรวจอีก และไม่เคยดึงเทประหว่างออกอากาศเลย

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

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

  • ถูกแล้วที่ควรออกแบบให้เสียบผิดไม่ได้ อันที่จริงผมก็คิดว่าส่วนใหญ่คงออกแบบแบบนั้น แต่การจัดวางที่ผิดพลาดซึ่งไม่ได้นึกถึงตอนออกแบบก็ยังเกิดขึ้นได้
    โดยเฉพาะระหว่างการทดสอบ มักต้องจัดการกับสายเคเบิล ขั้วต่อ และวงจรแบบปรับแต่งที่ต่างจาก “การจัดวางปกติ” ผมคิดว่าบทเรียนคือ งานสำคัญควรใช้ หลัก 4-eyes ให้มากที่สุด คือให้คนหนึ่งทำ อีกคนตรวจทุกขั้นก่อนเดินหน้าต่อ วิธีนี้มีประสิทธิภาพมากในการจับ “ความผิดพลาดงี่เง่า” แบบในบทความ
    อย่างไรก็ดี เพราะแรงกดดันด้านกำหนดการและปัจจัยอื่น ๆ ในทางปฏิบัติไม่อาจให้คนสองคนมาดูการทดสอบเดียวกันได้เสมอไป ดังนั้นความผิดพลาดแบบนี้จึงเกิดขึ้นได้ ต้องทำให้ทั้งระบบมีความทนทาน
  • ตอนแรกผมก็คิดแบบนั้นเหมือนกัน เพียงแต่ถ้าเป็น อุปกรณ์ใช้ครั้งเดียว ที่ผ่านรอบการทดสอบแบบมีแค่ครั้งเดียว การตัดสินใจก็ยากอยู่
    ในงานคอมพิวติ้งก็มีงานคล้ายกันมากมาย เช่น การอัปเกรดหรือย้ายระบบที่ต้องทำกับฐานข้อมูล production หรือการตั้งค่าเราเตอร์เพียงครั้งเดียว บางครั้งต้นทุนในการสร้างระบบป้องกันสูงกว่าการระมัดระวังตั้งแต่แรก เราไม่อาจระวังได้สมบูรณ์แบบเสมอไป แต่เราก็สร้างระบบป้องกันได้ไม่สมบูรณ์แบบเสมอเช่นกัน และบางทีก็พลาดในทำนองเดียวกันเพราะไว้ใจระบบป้องกันที่มีข้อบกพร่อง
    ในสถานการณ์ในเรื่องนี้ อาจควรมีคู่หูแบบฮาร์ดแวร์เวอร์ชันของ pair programming ที่มีหน้าที่เพียงตรวจสอบว่าทุกอย่างที่ผู้เขียนทำถูกต้อง ไม่ใช่ผู้ช่วยที่แบ่งบทบาทช่วยกันแบบ Mary แต่เป็นคนที่มีหน้าที่เดียวคือคอยตามดูและยืนยัน
  • ถ้าอ่านละเอียด จะเห็นว่าไฟฟ้าเข้าไปที่สายเอาต์พุตกำลังของ H-bridge และ H-bridge เป็นวงจรอิเล็กทรอนิกส์ที่ทนทาน จึงสุดท้ายไม่มีอะไรเสียหาย การ shutdown ไม่เกี่ยวข้องกัน
    ถ้าไฟเข้าไปที่สายข้อมูลของตัวควบคุมมอเตอร์ มีโอกาสสูงว่าจะมีอะไรไหม้ไปแล้ว จะตัดความเป็นไปได้เรื่องชนิดขั้วต่อที่ต่างกันออกไปไม่ได้ แต่ขั้วต่อสองตัวที่ถูกต่อผิดนั้นก็น่าจะถูกกำหนดให้เป็นชนิดเดียวกันจริง
  • ตอนที่มนุษย์ลงจอดบนดวงจันทร์ครั้งแรก อายุเฉลี่ย ของวิศวกร Mission Control คือ 28 ปี
  • ผมทำงานในอุตสาหกรรมนี้ เลยอธิบายได้ว่าทำไมเรื่องแบบนี้ถึงเกิดขึ้น แม้จะเป็นโปรเจ็กต์ราคาแพง ก็ไม่อาจบังคับให้ใช้ขั้วต่อเฉพาะไม่ซ้ำกันทุกจุดได้ เพราะข้อกำหนดต่าง ๆ แข่งขันกันเอง
    โดยเฉพาะขั้วต่อ มักมีข้อกำหนดแบบอนุรักษนิยมมากมาย เช่น ต้องเป็นผลิตภัณฑ์ที่ผ่านการรับรองแล้ว ต้องมี derating เฉพาะ ระยะห่างขา และ backshell แบบต่อลงกราวด์ สุดท้ายจึงเหลือซีรีส์ขั้วต่อที่ใช้งานและเก็บสต็อกจริงแค่ไม่กี่แบบ และไม่ว่าทุ่มต้นทุนแค่ไหน ก็ไม่สมจริงที่จะทำให้ไม่มีส่วนซ้ำกันเลย โดยทั่วไปจึงมักพยายามทำให้สัญญาณแบบเดียวกันเป็นมาตรฐานเดียวกัน หรือพยายามทำให้แต่ละจุดไม่ซ้ำกันเท่าที่ทำได้
    ตัวอย่างเช่น ขั้วต่อภายนอกยานอวกาศต้องใช้ขั้วต่อแบบซ็อกเก็ตเพื่อป้องกันการลัดวงจรระหว่างการหยิบจับ และ harness ตรงกลางจะไม่ถูกถอดออกเลย ทำให้ขั้วต่อแบบพินอาจมาต่อกันแบบสมมาตรได้ แล้วพอมีความจำเป็นต้องใช้ breakout box สำหรับการทดสอบ ก็เกิดโอกาสที่จะเสียบกล่องกลับด้าน
    หรือ breakout box ด้านหนึ่งอาจเป็นขั้วต่อ 100 พิน แต่อีกด้านต้องต่อเข้ากับอุปกรณ์ทดสอบ 25 ชิ้น คุณก็ไม่มีขั้วต่ออีก 25 แบบให้เลือก และก็ไม่อาจบังคับข้อกำหนดเฉพาะกับอุปกรณ์ทดสอบทุกชิ้นได้
    ทุกวันนี้ยานอวกาศกำลังค่อย ๆ เปลี่ยนไปใช้ไมโครคอนโทรลเลอร์ภายในเครื่องและระบบวินิจฉัยภายในมากขึ้น ทำให้อุปกรณ์ทดสอบแบบนี้สำหรับสัญญาณอนาล็อกทั้งหมดลดลง มอเตอร์เองถ้าเป็นปัจจุบันก็น่าจะเป็นแบบ brushless มากกว่า และน่าจะพึ่งข้อมูล telemetry จากไดรเวอร์มอเตอร์ระหว่างทดสอบและระหว่างบิน แทน breakout box แบบนี้
    ขั้วต่อสำหรับงานอากาศยานอวกาศเองก็เริ่มปรับแต่งได้มากขึ้นตอนสั่งซื้อเหมือนในอุตสาหกรรมอื่น สามารถเพิ่ม key เพื่อให้ถึงจะมีขั้วต่อ “แบบเดียวกัน” 10 ตัว ก็เสียบได้เฉพาะตำแหน่งของตัวเอง ถึงอย่างนั้น การกำหนดให้อุปกรณ์ทดสอบทั้งหมดต้องคอนฟิกแบบนั้นก็ยังไม่สมจริงอยู่ดี

• ขอเล่าเรื่องของตัวเองไว้เป็นบันทึกด้วย งานแรกหลังเรียนจบมหาวิทยาลัยของผมคือสตาร์ตอัปด้าน content marketing ที่ใช้ PHP กับ PerconaDB(MySQL) ผมไม่ได้มีประสบการณ์กับ PHP มากนัก แต่ก็มีความมั่นใจแบบเด็กจบใหม่ที่ไร้เหตุผล และเพราะหลังเรียนจบหางานไม่ได้อยู่ 6 เดือน ก็ยิ่งอยากสร้างความประทับใจที่ดี
  ผมได้รับมอบหมายให้อัปเดต feature flag เพื่อเปิดฟีเจอร์ใหม่ให้ลูกค้าทุกราย ยกเว้นเฉพาะลูกค้าที่ต้องการปิดไว้อย่างชัดเจน โดย flag ถูกเก็บในฐานข้อมูลเป็นค่า 4 และ 5 แบบจำนวนเต็มภายในอาร์เรย์สตริง
  เพื่อทำงานที่ต้องการ ผมใช้ฟังก์ชัน PHP array_reverse แต่เพราะไม่ได้อ่านเอกสาร จึงไม่รู้ว่าถ้าไม่มีอาร์กิวเมนต์ตัวที่สอง มันจะกลับเฉพาะค่า ไม่ใช่คีย์ ผลคือฐานข้อมูลพังในทางตรงกันข้ามกับสิ่งที่ต้องการเป๊ะ ๆ และที่แปลกคือมันผ่าน QA ด้วย
  ผมมารู้ไม่กี่ชั่วโมงให้หลัง ตอนนั้นผมเดินทางไปกลับที่ทำงานเกือบ 3 ชั่วโมงต่อเที่ยว ดังนั้นตอนนั้นฝ่ายบริหารก็เข้ามาเกี่ยวข้องแล้ว แก้ได้ง่ายด้วยสคริปต์ย้อนกลับ แต่ก็ทำให้ปัญหาหลายอย่างโผล่มา เช่น QA และ ความล้มเหลวของการสำรองฐานข้อมูล
  ผมยังจำได้และรู้สึกขอบคุณจนถึงตอนนี้ที่วันถัดมา lead architect เข้ามาบอกว่านี่เป็นความผิดพลาดแบบพิธีผ่านด่านของการทำงานกับ PHP และเขาเองก็เคยทำตอนต้นอาชีพเหมือนกัน สุดท้ายผมก็โดนไล่ออก และแม้มันจะช่วยให้ผมเติบโตในฐานะวิศวกร แต่ช่วงเวลานั้นกับอีกหลายสัปดาห์หลังจากนั้นก็ทำให้หมดกำลังใจไปมากจริง ๆ

  • โดนไล่ออกเพราะความผิดพลาดเรื่อง array_reverse นั่นเลยเหรอ

• เรื่องเขียนได้น่าติดตาม แต่ก็ชวนสับสนด้วย
  ดูเหมือนว่าทีมนี้ไม่ได้พลาดแค่ครั้งเดียว แต่พลาดหลายครั้ง สิ่งที่ยังไม่ชัดคือผลลัพธ์นั้นสามารถทำให้ยานเสียหายจริงได้หรือไม่ หรือแค่ทำให้เสียเวลาและเกิดความสับสนกับสาเหตุที่ยานไม่ยอมเปิดเท่านั้น
  ความผิดพลาดครั้งแรกคือไม่รู้ว่ามัลติมิเตอร์ไม่ได้แค่ทำการวัด แต่กำลัง ทำให้วงจรครบ อยู่ด้วย ฟังดูเหมือนการออกแบบที่แย่มาก และถ้าจำเป็นต้องทำแบบนั้นจริง ก็ไม่ควรแตะมัลติมิเตอร์นั้นเด็ดขาด นี่ไม่ใช่ความผิดของคนคนเดียว แต่เป็นปัญหาที่เกี่ยวข้องอย่างน้อยสองคน คนที่ดูแลพวกเขา และผู้รับผิดชอบที่ปล่อยให้มีระบบแบบนั้น
  ความผิดพลาดครั้งที่สองอยู่ที่ฝั่ง breakout box พวกเขารายงานว่าส่งพลังงานผิดไปทางยาน และเมื่อยานไม่เปิดก็ตัดสินว่ากระแสไฟกระชากได้ทำให้ยานเสียหาย แต่จริง ๆ แล้วก็ไม่มั่นใจว่ากระแสไหลไปทางไหนและอะไรเสียหายบ้าง สุดท้ายก็สรุปผิด
  เหตุผลที่ยานไม่เปิดคือก่อนเกิดเหตุพวกเขาได้ถอดมัลติมิเตอร์ออกจากวงจรไปแล้ว ประโยคที่บอกว่ามีการวิเคราะห์ช่อง H-bridge ของมอเตอร์ RAT-Revolve อยู่หลายสัปดาห์ รวมถึงการถกเรื่องความเป็นไปได้ของการ de-metallization ของฟิล์มบาง ก็ยังทำให้งงอยู่ว่าหมายถึงพวกเขาตัดสินว่ากระแสไฟกระชากที่ผิดพลาดอาจไหลเข้าช่องนั้นและทำให้เสียหายหรือไม่

  • ยังขาดประเด็นที่ Leo ผู้ดูแล telemetry ไม่ได้แจ้งเรื่อง การสูญเสีย telemetry จนกว่าคนเล่าเรื่องจะบอกว่าเขาทำพลาด ไม่ควรยกเลิกการทดสอบทั้งหมดจนกว่า telemetry จะกลับมาหรือ?
  • ตัวยานเองเปิดได้ตามปกติ เพียงแต่พวกเขาไม่ได้รับข้อมูลจนกว่าจะกู้วงจรนั้นกลับมา เพราะมัลติมิเตอร์กำลังเชื่อมวงจร telemetry อยู่
    ไฟฟ้าได้เข้าสู่วงจรนั้นจริง และตอนนั้นพวกเขากำลังพยายามประเมินว่ามันเสียหายหรือไม่ เพียงแต่มองว่า motor driver น่าจะไม่เสียหาย เพราะมันควรจะต้องทนต่อพลังงานที่ไหลย้อนกลับมาจากมอเตอร์ได้อยู่แล้ว

• ในฐานะวิศวกรเครื่องกล/อากาศยาน ฉันหวังว่าเรื่องสยองที่สุดของฉันจะเป็นแค่การที่คอมพิวเตอร์หลักของโรเวอร์ไร้คนขับมูลค่า 500 ล้านดอลลาร์เกือบกลายเป็นก้อนอิฐ
  ฉันเคยเป็นวิศวกรอาวุโสที่ทำ การอนุมัติความปลอดภัยวิกฤต สำหรับสิ่งที่บรรทุกชีวิตผู้คน ต้องรับมือกับความรู้สึกเวลาเห็นรูปชิ้นส่วนที่แตกหักหลังอุบัติเหตุร่วงตก แล้วคิดว่า “ถ้านั่นเป็นเพราะการคำนวณของฉันผิดล่ะ?”, “ถ้าเป็นเพราะรอยต่อที่ฉันออกแบบลื่นไถลล่ะ?”, “ถ้าเป็นเพราะขั้นตอนการทดสอบที่ไม่เหมาะสมในการพยากรณ์อายุความล้าจากการเร่งหรือรอยร้าวจากการกัดกร่อนภายใต้ความเค้นล่ะ?”, “ถ้าเป็นสิ่งที่หลุดรอดไปก่อนส่งมอบเพราะเร่งเอาเข้าสู่การผลิตล่ะ?”
  การอ่านเรื่องราวความล้มเหลวในสายงานใกล้เคียงกันก็น่าสนใจอยู่ แต่เรื่องที่ถูกแชร์สาธารณะบน HN ทำให้ฉันรู้สึกว่า PTSD จากงานไม่ใช่เรื่องที่จะเอามาแข่งกัน สำหรับบางคนมันก็แค่ค่าบำบัดแพงกว่าเท่านั้น

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

    He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

    “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

    He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
    -- Lois McMaster Bujold, Falling Free

  • ฉันก็คิดเหมือนกันกับย่อหน้าสุดท้าย ตรงที่ต้นฉบับเขียนว่า “กลับไปยังช่วงเวลานั้นทันที — ห้อง แสงไฟ เก้าอี้ที่นั่ง โต๊ะ ความรู้สึกเหมือนท้องยุบ...” ฟังดูเหมือน ปฏิกิริยาจากบาดแผลทางใจ
    ดีแล้วที่สามารถเอาพลังนั้นไปใช้ในทางที่ทำได้ดีขึ้น แต่ไม่ใช่ทุกคนจะตอบสนองต่อบาดแผลทางใจในแบบเดียวกัน และก็ไม่ง่ายที่จะเอาปฏิกิริยาแบบนั้นมาเปรียบเทียบกัน เช่น หากจะใช้เป็นคำถามในการรับสมัครงานก็รู้สึกว่ามีตัวแปรทางสังคมมากเกินไป
  • ทำให้อยากรู้ว่าความรู้สึกแบบ “ต้องมองรูปชิ้นส่วนที่แตกหักหลังอุบัติเหตุแล้วคิดว่า ‘ถ้านั่นเป็นเพราะการคำนวณของฉันผิดล่ะ?’” สุดท้ายเป็นสิ่งที่หลีกเลี่ยงไม่ได้สำหรับใครสักคนหรือเปล่า
    ต่อให้เป็นรายละเอียดที่กระบวนการจับไม่ได้ ก็ต้องมีใครสักคนที่รับผิดชอบในการออกแบบกระบวนการที่ดี แม้อาจมีหลายปัจจัย แต่ท้ายที่สุดก็ดูเหมือนจะมีคนที่ต้องรับผิดชอบโดยตรงอยู่ดี
    พอมองในบริบทที่ความผิดพลาดส่วนบุคคลถูกทำให้เป็นของส่วนรวม เช่น วิศวกรรมซอฟต์แวร์หรือสังคมโดยรวม ก็เป็นประเด็นที่น่าสนใจ
  • ฉันหวังจริง ๆ ว่าในอุตสาหกรรมอากาศยานจะมีคนแบบคุณมากขึ้น และมีคนที่คิด ออกแบบ นำไปใช้ และอนุมัติ MCAS ของ Boeing 737 MAX ให้น้อยลง
  • น่าแปลกที่ไม่มี การบำบัดแบบกลุ่ม สำหรับวิศวกร หรือถึงมีก็คงหายาก ฉันไม่ได้ทำงานในสายที่มีความเสี่ยงสูง แต่เคยอยู่ในบทบาทที่มักต้องรับฟังเรื่องราวจากคนในสายการบินหรือรถไฟ
    ถ้าคุณมีความเห็นอกเห็นใจและไม่ได้ถือท่าทีว่า “หลังจากจรวดขึ้นไปแล้วมันจะตกที่ไหนไม่ใช่งานของแผนกฉัน” มันก็น่าจะหนักพอสมควร อยากให้มีกลุ่มสนับสนุนแบบเพื่อนช่วยเพื่อนสำหรับคนที่สร้างระบบความปลอดภัยวิกฤตหรือรับมือกับผลกระทบจากมัน บริษัทไม่ได้มีบริการให้คำปรึกษาที่ดีเสมอไป
    สมาคมวิศวกรรมหรือองค์กรวิศวกรมืออาชีพอาจให้บริการแบบนี้จากค่าสมาชิกได้ แต่ก็น่าจะมีคนลังเลที่จะใช้เพราะกลัวเสียใบอนุญาตหรือคุณวุฒิรับรอง สมัยก่อนคนอาจไปเมาคุยระบายกับเพื่อนร่วมงานที่บาร์ แต่การพึ่งพาแอลกอฮอล์หรือการทำงานวันถัดไปแบบไม่พร้อมไม่ใช่เรื่องดี และวัฒนธรรมบาร์ก็ไม่เหมือนเดิมแล้ว

• ทำให้นึกถึงเหตุการณ์ที่ดาวเทียม NOAA-N Prime ล้มคว่ำเพราะมีสลักเกลียวยึดกับแท่นทดสอบไม่เพียงพอ
  สาเหตุรากฐาน หากจำไม่ผิดก็ช่วยแก้ไขได้ แต่คือ สลักเกลียวสำหรับการตรวจสอบด้วยรังสีเอกซ์ ที่ใช้ยึดดาวเทียมนั้นมีราคาแพงเกินไป จึงถูก “ยืมไป” ใช้กับโครงการอื่นและไม่ได้นำกลับมาคืน พอพลิกดาวเทียมในแนวนอน มันก็ร่วงลงพื้น และค่าซ่อมอยู่ที่ 135 ล้านดอลลาร์
  https://en.m.wikipedia.org/wiki/NOAA-19

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

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