อดีตพนักงาน CrowdStrike: “การควบคุมคุณภาพไม่ได้เป็นส่วนหนึ่งของกระบวนการ”

• อดีตพนักงานกล่าวว่า ก่อนเหตุขัดข้องครั้งใหญ่ในเดือนกรกฎาคม 2024 พวกเขาได้แจ้งผู้บริหารมาโดยตลอดถึง กำหนดเวลาที่บีบคั้น ปริมาณงานที่มากเกินไป และปัญหาทางเทคนิคที่เพิ่มขึ้น
• ในบรรดาอดีตพนักงาน 24 คนที่ให้สัมภาษณ์ หลายคนมองว่าผู้บริหารให้ความสำคัญกับ ความเร็วมากกว่าคุณภาพ และพนักงานบางส่วนได้รับมอบหมายงานเขียนโค้ดและงานปฏิบัติการโดยไม่มีการฝึกอบรมที่เพียงพอ
• CrowdStrike ปฏิเสธคำบอกเล่าของอดีตพนักงานเป็นส่วนใหญ่ โดยโต้แย้งว่าแหล่งข้อมูลคือ “อดีตพนักงานบางส่วนที่ไม่พอใจ ซึ่งถูกเลิกจ้างเพราะละเมิดนโยบายบริษัทอย่างชัดเจน”
• ข้อบกพร่องในการอัปเดต Falcon Sensor เดือนกรกฎาคมทำให้คอมพิวเตอร์ 8.5 ล้านเครื่องหยุดทำงาน สร้างความเสียหายแก่บริษัทใน Fortune 500 สูงสุด 5.4 พันล้านดอลลาร์ และทำให้ CrowdStrike พลาดสัญญาที่คาดไว้ในไตรมาสนั้นราว 60 ล้านดอลลาร์
• แม้ยังไม่ได้ยืนยันความเชื่อมโยงโดยตรงระหว่างปัญหาคุณภาพและการปฏิบัติการระยะยาวกับเหตุขัดข้องเดือนกรกฎาคม แต่หลังจากนั้น CrowdStrike เผชิญกับการปรับลดคาดการณ์รายได้และกำไร การให้การต่อสภาคองเกรส และแรงกดดันจากคดีความ

---

ความกังวลด้านคุณภาพที่สะสมมาตั้งแต่ก่อนเหตุขัดข้อง

• อดีตวิศวกรซอฟต์แวร์ของ CrowdStrike กล่าวว่า พวกเขาได้แจ้งผู้บริหารระดับสูงถึง เดดไลน์ที่บีบคั้น ปริมาณงานที่มากเกินไป และปัญหาทางเทคนิคที่เพิ่มขึ้น มานานกว่าหนึ่งปีก่อนเหตุขัดข้องครั้งใหญ่ในเดือนกรกฎาคม
• อดีตพนักงานระบุว่า การหยิบยกปัญหาเกิดขึ้นซ้ำ ๆ ในที่ประชุม อีเมล และการสัมภาษณ์ก่อนออกจากงาน
• Jeff Gardner อดีตนักออกแบบประสบการณ์ผู้ใช้อาวุโส กล่าวว่า “ความเร็วคือสิ่งสำคัญที่สุด” และ การควบคุมคุณภาพไม่ได้เป็นส่วนหนึ่งของกระบวนการหรือบทสนทนา
• อดีตผู้จัดการอาวุโสรายหนึ่งระบุว่า ในการประชุมหลายครั้ง พนักงานเตือนว่าหากเปิดตัว “ผลิตภัณฑ์ที่ไม่สามารถซัพพอร์ตได้” ก็อาจทำให้ลูกค้า “ล้มเหลว” ได้

คำให้การของอดีตพนักงานที่ขัดแย้งกันและคำโต้แย้งของบริษัท

• อดีตพนักงานที่ Semafor สัมภาษณ์มีทั้งหมด 24 คน
  • 10 คนกล่าวว่าถูกไล่ออกหรือถูกเลิกจ้างจากการปรับลดพนักงาน
  • 14 คนกล่าวว่าลาออกโดยสมัครใจ
  • คนหนึ่งยังอยู่กับบริษัทจนถึงฤดูร้อนปี 2024
• อดีตพนักงาน 3 คนไม่เห็นด้วยกับคำบอกเล่าของพนักงานคนอื่น ๆ
  • Joey Victorino ซึ่งลาออกในปี 2023 ประเมินว่า CrowdStrike “พิถีพิถันมากกับทุกสิ่งที่ทำ”
• บริษัทปฏิเสธเนื้อหารายงานเป็นส่วนใหญ่
  • ระบุว่าข้อมูลมาจาก “อดีตพนักงานบางส่วนที่ไม่พอใจ ซึ่งถูกเลิกจ้างเพราะละเมิดนโยบายบริษัทอย่างชัดเจน”
  • ระบุว่าบริษัทดำเนิน การทดสอบและควบคุมคุณภาพอย่างเข้มงวด เพื่อรับประกันความยืดหยุ่นของผลิตภัณฑ์ และปฏิเสธคำอธิบายที่ขัดแย้งกันโดยสิ้นเชิง

เหตุขัดข้องเดือนกรกฎาคมที่ปะทุหลังการเติบโตอย่างรวดเร็ว

• CrowdStrike ก่อตั้งในปี 2011 และเติบโตเป็นบริษัทสำคัญในอุตสาหกรรมไซเบอร์ซีเคียวริตี้หลังเปิดตัวแพ็กเกจแอนติไวรัส Falcon ในปี 2013
• หลังเข้าตลาดหลักทรัพย์ในปี 2019 บริษัทเพิ่มจำนวนพนักงานอีกหลายพันคน และรายได้เพิ่มขึ้นมากกว่า 1,000% จนถึงสิ้นปีงบประมาณ 2024
• การอัปเดตซอฟต์แวร์ที่ผิดพลาดในเดือนกรกฎาคม 2024 นำไปสู่ เหตุการณ์ที่อาจเป็นเหตุขัดข้องด้าน IT ครั้งใหญ่ที่สุดในประวัติศาสตร์
  • คอมพิวเตอร์ 8.5 ล้านเครื่องหยุดทำงาน
  • ความเสียหายต่อบริษัทใน Fortune 500 อาจสูงถึง 5.4 พันล้านดอลลาร์
  • ผู้โดยสารสายการบินติดค้างที่สนามบิน การเข้าถึงธนาคารออนไลน์ถูกปิดกั้น และ ศูนย์รับสายฉุกเฉินออฟไลน์
• CFO Burt Podbere กล่าวในการประกาศผลประกอบการวันที่ 28 สิงหาคมว่า บริษัทพลาดสัญญาราว 60 ล้านดอลลาร์ที่คาดว่าจะปิดได้ในไตรมาสที่สิ้นสุดวันที่ 31 กรกฎาคม
• CEO George Kurtz ระบุเมื่อวันที่ 19 กรกฎาคมว่าจะไม่ลืมขนาดของเหตุการณ์นี้ และจะทำให้แน่ใจว่าเรื่องเช่นนี้จะไม่เกิดขึ้นอีก

การทดสอบ ข้อมูลลูกค้า และกรณี LogScale

• อดีตพนักงานบางคนกล่าวว่า ในกระบวนการเร่งให้ทันความเร็วของการเปิดตัวผลิตภัณฑ์ บางครั้ง การตรวจสอบคุณภาพซอฟต์แวร์ ถูกเร่งรัด
• Preston Sego ซึ่งทำงานตั้งแต่ปี 2019 ถึง 2023 ระบุว่า บางครั้งเป็นเรื่องยากที่จะโน้มน้าวให้ผู้คนทดสอบอย่างเพียงพอ
  • งานของเขาคือการตรวจสอบว่า ก่อนที่การเปลี่ยนแปลงโค้ดจะถูกปล่อยให้ลูกค้า การทดสอบของนักพัฒนาประสบการณ์ผู้ใช้สามารถแจ้งบั๊กได้อย่างถูกต้องหรือไม่
  • Sego กล่าวว่าเขาถูกเลิกจ้างในฐานะ “insider threat” ในเดือนกุมภาพันธ์ 2023 หลังวิจารณ์นโยบายกลับเข้าทำงานที่ออฟฟิศใน Slack ภายใน
  • CrowdStrike ระบุว่าจะไม่หารือเรื่องบุคลากรรายบุคคล
• ในแผนกบริการวิชาชีพ มีกรณีที่ข้อมูลไม่เปิดเผยของลูกค้ารายหนึ่งเกือบถูกอัปโหลดผิดไปยังโฟลเดอร์ของลูกค้าอีกรายถึงสามครั้ง
  • CrowdStrike ยืนยันเหตุการณ์ดังกล่าว และระบุว่าสาเหตุคือ ข้อผิดพลาดจากการป้อนข้อมูลด้วยมือ
  • บริษัทอธิบายว่าข้อมูลดังกล่าวเป็นข้อมูลพื้นฐาน เช่น ชื่อโฮสต์ ที่อยู่ IP และชื่อโดเมน
  • บริษัทระบุว่าปัจจุบันมีการตรวจสอบเพื่อป้องกันไม่ให้ข้อมูลไม่เปิดเผยของลูกค้าถูกส่งผิด
• อดีตพนักงานหลายคนกล่าวว่า Falcon LogScale ก็มีปัญหาเช่นกัน
  • คนหนึ่งเล่าว่า การอัปเดตที่ผิดพลาดทำให้การแจ้งเตือนแบบเรียลไทม์ที่แจ้งกิจกรรมที่อาจเป็นอันตรายถูกปิดชั่วคราวอย่างน้อยสองครั้ง
  • วิศวกรบางคนกล่าวว่าในการประชุมภายใน พวกเขามองว่าเรื่องนี้เป็นผลจากกำหนดเวลาที่บีบคั้น
  • CrowdStrike ปฏิเสธกรณีดังกล่าว โดยระบุว่าไม่ทราบถึง “bad update” ที่ทำให้ลูกค้าไม่ได้รับการแจ้งเตือน
  • บริษัทระบุว่า LogScale ไม่ใช่บริการที่ออกแบบมาเพื่อแจ้งลูกค้าเกี่ยวกับการละเมิดข้อมูลที่อาจเกิดขึ้นแบบ “เรียลไทม์”

ข้อถกเถียงเกี่ยวกับการเปิดตัว Falcon OverWatch Cloud Threat Hunting

• อดีตพนักงานรายหนึ่งกล่าวว่า Falcon OverWatch Cloud Threat Hunting ซึ่งเปิดตัวในปี 2022 ถูกเร่งเปิดตัว
• บริการนี้เป็นบริการที่ผู้เชี่ยวชาญด้านความปลอดภัยของ CrowdStrike ค้นหาพฤติกรรมน่าสงสัยที่อาจบ่งชี้การบุกรุกในสภาพแวดล้อมคลาวด์ของลูกค้า เช่น Amazon Web Services
• อดีตผู้จัดการอาวุโสที่เข้าร่วมโครงการกล่าวว่า งานที่ปกติใช้เวลา 1 ปี ถูกมอบให้วิศวกรและ threat hunter ทำให้เสร็จภายใน 2 เดือน
• เขาระบุว่า ณ เวลาที่เปิดตัว threat hunter ขาดเครื่องมือภายในที่จำเป็นต่อการมอนิเตอร์ระบบคลาวด์ของลูกค้าอย่างสมบูรณ์ และจนถึงฤดูร้อนปีก่อน ซึ่งเป็นเวลาราว 1 ปีหลังเปิดตัว พวกเขายังคงตอบสนองต่อการแจ้งเตือนจากระบบความปลอดภัยเดิม
• อดีตผู้จัดการอาวุโสคนเดียวกันกล่าวว่า บริษัทนำพนักงานที่ได้รับการฝึกให้เฝ้าระวังระบบคอมพิวเตอร์ของลูกค้า เช่น แล็ปท็อปและเดสก์ท็อป ไปทำงานตรวจจับภัยคุกคามบนคลาวด์ โดยไม่ได้บังคับให้เข้ารับการฝึกอบรมใหม่
• CrowdStrike ยืนยันข้อเท็จจริงว่าใช้วิศวกรที่มีอยู่แทนการจ้างทีม “cloud threat hunters” ใหม่
  • บริษัทระบุว่า เนื่องจากเป็นบริการใหม่ จึงไม่สามารถหาผู้มีประสบการณ์เป็น “cloud threat hunters” ได้ และเป็นไปไม่ได้ที่จะจ้างคนที่ได้รับการฝึกอบรมเฉพาะด้านในสาขาที่ไม่เคยมีอยู่ก่อนที่ CrowdStrike จะพัฒนาขึ้น
  • บริษัทกล่าวว่าไม่ได้บังคับการฝึกอบรมใหม่ แต่จัดให้แก่พนักงานที่ต้องการ
  • พร้อมเสริมว่าพนักงานได้รับการฝึกอบรมที่เหมาะกับหน้าที่เป็นประจำ
• SANS Institute ได้ให้บริการ หลักสูตรฝึกอบรม และ การบรรยาย ด้านความปลอดภัยคลาวด์มาตั้งแต่ปี 2020 ซึ่งเป็นเวลา 2 ปีก่อนที่บริการของ CrowdStrike จะเปิดตัว
• CrowdStrike ระบุว่าบริการ OverWatch ทำงานตามที่ตั้งใจไว้เสมอ และปฏิเสธคำอธิบายที่ว่าโครงการถูกเร่งหรือ threat hunter ขาดเครื่องมือที่จำเป็น

โค้ดเก่าและปริมาณงานที่เพิ่มขึ้น

• Sego กล่าวว่า โค้ดที่เขียนขึ้นชั่วคราวเพื่อให้โครงการเดินหน้ามักไม่ได้รับการปรับปรุงในภายหลัง
• อดีตวิศวกรอาวุโสรายหนึ่งระบุว่า เขาขอเวลาแก้โค้ดเก่ามากกว่า 20 ครั้ง แต่ไม่ได้รับการอนุมัติ
• CrowdStrike โต้แย้งว่า การเขียนโค้ดเป็น กระบวนการแบบวนซ้ำ และในอุตสาหกรรมซอฟต์แวร์เป็นเรื่องปกติที่จะปล่อยโค้ดโดยอิงจากประสบการณ์ใช้งานผลิตภัณฑ์จริงและปรับปรุงอย่างต่อเนื่อง
• อดีตพนักงานชี้ว่าหนึ่งในเหตุผลที่ไม่สามารถปรับปรุงโค้ดเก่าได้คือปริมาณงานที่เพิ่มขึ้น
  • บางคนกล่าวว่าหลังการลดพนักงานและปรับโครงสร้างองค์กร พวกเขาต้องรับงานมากขึ้น
  • CrowdStrike ปฏิเสธที่จะแสดงความคิดเห็นเรื่องการเลิกจ้าง และระบุว่าจำนวนพนักงานเพิ่มขึ้นอย่างต่อเนื่องทุกปี
  • บริษัทอธิบายว่า ค่าใช้จ่าย R&D เพิ่มจาก 371.3 ล้านดอลลาร์ในปีงบประมาณ 2022 เป็น 768.5 ล้านดอลลาร์ในปีงบประมาณ 2024 โดยส่วนใหญ่เกิดจากจำนวนพนักงานที่เพิ่มขึ้น
• บริษัทระบุว่าได้รับ ประเมิน และนำฟีดแบ็กที่หลากหลายจากทีมไปสะท้อนใช้งาน และมุ่งรักษาวัฒนธรรมที่เน้นผลงานสูง
• บริษัทเสริมด้วยว่าได้รับเลือกให้อยู่ใน Fortune 100 Best Companies to Work For ในช่วง 4 ปีที่ผ่านมา

ค่าใช้จ่ายและขั้นตอนต่อเนื่องหลังเหตุขัดข้อง

• CrowdStrike ระบุว่าสาเหตุของเหตุขัดข้องเดือนกรกฎาคมมาจากข้อบกพร่องในการอัปเดต Falcon Sensor
• เหตุการณ์ดังกล่าวทำให้มูลค่าตลาดหุ้นของบริษัทลดลงมากกว่า 21 พันล้านดอลลาร์
• มีคดีความหลายคดีตามมา และ Delta Airlines ประเมินความเสียหายหลังยกเลิกเที่ยวบินหลายพันเที่ยวไว้ที่ 550 ล้านดอลลาร์ พร้อมยกความเป็นไปได้ที่จะฟ้องร้อง
• Adam Meyers รองประธานอาวุโส มีกำหนด ให้การ ต่อสภาคองเกรสในช่วงเดือนกันยายน 2024
• Michael Sentonas ประธาน CrowdStrike รับรางวัล “Most Epic Fail” ในงานประชุมแฮ็กเกอร์เดือนสิงหาคม พร้อมกล่าวว่าเมื่อทำผิดพลาดอย่างร้ายแรง การยอมรับเรื่องนั้นเป็นสิ่งสำคัญมาก
• ความเชื่อมโยงระหว่างปัญหาระยะยาวที่อดีตพนักงานกล่าวถึงกับเหตุขัดข้องเดือนกรกฎาคมยังไม่ได้รับการยืนยัน

[GN⁺]

ความคิดเห็นบน Hacker News

• บทความที่อาศัยคำพูดของ อดีตพนักงานที่ไม่พอใจ ในทำนองว่า “ความเร็วคือสิ่งสำคัญที่สุด และการควบคุมคุณภาพไม่เคยเป็นส่วนหนึ่งของกระบวนการหรือบทสนทนาของเรา” ดูมีค่าแค่เท่ากับกิฟต์การ์ดขอโทษของ GrubHub เท่านั้น
  ผมไม่ได้มอง CrowdStrike ในแง่ดีนัก แต่ถ้ามีความแค้นและมีโอกาสได้เป็นจุดสนใจ ใครๆ ก็พูดอะไรก็ได้ ยิ่งกว่านั้นคนนี้เป็นดีไซเนอร์ และก็คงไม่ได้เกี่ยวข้องโดยตรงกับการควบคุมคุณภาพด้วย
  ในบทความก็ระบุว่า ในอดีตพนักงาน 24 คน มี 10 คนที่ถูกไล่ออกหรือเลิกจ้าง, 14 คนลาออกเอง และ 3 คนไม่เห็นด้วยกับคำให้การอื่นๆ Joey Victorino บอกว่า CrowdStrike “พิถีพิถันกับทุกเรื่อง” ดังนั้นท้ายที่สุดแล้ว แทบไม่มีอะไรที่แน่ชัด

  • จะบอกว่า “ไม่มีอะไรแน่ชัด” ก็คงยาก เพราะมันมี เหตุขัดข้องด้าน IT ครั้งใหญ่ที่สุดในประวัติศาสตร์ เกิดขึ้น และรายงานวิเคราะห์หลังเหตุการณ์ก็ชี้ว่าขาดการตรวจสอบยืนยัน
    ไม่มีแม้แต่การทยอยปล่อยแบบเป็นขั้นเป็นตอน แต่ผลักเข้า production ทั่วโลกทันที และไม่มีแล็บที่ติดตั้งและรันโค้ดใหม่จริงๆ ด้วย เมื่อเห็นควัน และมีคำให้การหลายส่วนว่ามีไฟไหม้ ก็สามารถมองในบริบทนี้ได้
  • หลังจากบริษัทอย่าง CrowdStrike ก่อ อุบัติเหตุใหญ่ระดับมหาศาล ขนาดนั้น ดูเหมือนจะไม่มีสิทธิ์มากนักที่จะไปแปะป้ายอดีตพนักงานว่าเป็น “คนไม่พอใจ”
    กลับกัน พนักงานแบบนั้นอาจมีแนวโน้มจะพูดถึงสภาพภายในอย่างตรงไปตรงมามากกว่า และต่อให้ไม่ได้อยู่ฝ่ายประกันคุณภาพหรือควบคุมคุณภาพ ก็ยังรับรู้บรรยากาศได้ ข้อมูลแบบนั้นน่าเชื่อถือกว่าคนที่คอยเออออตามบริษัท
  • สิ่งที่เรามีคือรายงานว่า Semafor เห็นว่าคนที่พวกเขาสัมภาษณ์น่าเชื่อถือ มีประเด็นที่น่าสนใจ และโดยรวมสอดคล้องกันเองหรือสอดคล้องกับหลักฐานอื่น
    จะอ้างว่า Semafor ทำงานไม่ดีหรือมีเจตนาร้ายก็ได้ แต่เมื่อดูว่าตัวบทที่อ้างถึงเองยังเสนอหลักฐานแย้งไว้ด้วย ก็ไม่ใช่ข้อกล่าวอ้างที่ทำได้ง่ายนัก
    ถ้าได้ยินจากอดีตพนักงานบริษัทคนเดียว อาจเป็นเรื่องส่วนตัว แต่ถ้า หลายคนพูดถึงความไม่พอใจแบบเดียวกัน ก็ควรพิจารณาอย่างจริงจังมากขึ้น
  • เรื่องนี้คล้ายรีวิวออนไลน์ ถ้าเลือกมาเฉพาะรีวิวบวกกับลบแล้วซ่อนส่วนที่เหลือ ก็ไม่มีประโยชน์ แต่ถ้ารายงานรีวิวทั้งหมดที่พบ ก็ยังมีประโยชน์อยู่
    คนที่ไม่พอใจมีแนวโน้มจะเขียนรีวิวมากกว่า และคนที่ออกจาก CrowdStrike ก็มีแนวโน้มจะเคยไม่พอใจเช่นกัน มันเป็น ข้อมูลที่มีอคติ แต่ก็ยังเป็นข้อมูลที่มีประโยชน์
  • ถ้างานออกแบบไม่ได้มีส่วนเกี่ยวข้องกับการควบคุมคุณภาพ ก็แปลว่าการควบคุมคุณภาพไม่ได้ทำได้ดี ถ้างานออกแบบเชื่อมกับกระบวนการพัฒนาแต่ไม่เข้าใจการควบคุมคุณภาพ ก็แปลว่างานออกแบบก็ทำได้ไม่ดีเช่นกัน

• แปลกใจที่คอมเมนต์ที่นี่มองข้ามเรื่องนี้กันง่ายเกินไป อดีตพนักงาน รวมถึงวิศวกร กำลังบอกว่า วัฒนธรรมการพัฒนาที่เสี่ยงอันตราย ของอดีตบริษัทมีส่วนทำให้เกิดเหตุขัดข้องครั้งใหญ่ระดับโลกและเหตุขัดข้องในอดีต
  คำให้การแบบนี้ควรถูกมองว่าน่าเชื่อถือ หรืออย่างน้อยก็เป็นข้อมูลที่มีประโยชน์ แต่หลายคนดูเหมือนจะโจมตีแค่ UX designer ที่พูดว่า “การควบคุมคุณภาพไม่เคยเป็นส่วนหนึ่งของกระบวนการของเรา”
  บางทีหลายคนอาจฉายภาพตัวเองลงไปในประโยคว่า “ความเร็วในการปล่อยคือทุกอย่าง” หรือ “ขยับให้เร็วและทำของให้พัง” เพราะคุ้นเคยกับวัฒนธรรมของความสะใจในการ deploy โค้ด, การดับไฟ, การสร้าง impact แล้วโยนงานเก็บกวาดให้วิศวกรและผู้จัดการคนถัดไป
  จากมุมมองของ ยุคดอกเบี้ยศูนย์ ความล้มเหลวของกระบวนการแบบนี้อาจดูไม่ใช่บั๊ก แต่เป็นฟีเจอร์ การเน้น “คุณภาพ” ก็คงถูกมองเป็นกำแพงน่ารำคาญที่ขัดขวางการทำงานให้สนุกด้วยเงินลูกค้า

  • นี่ไม่ใช่เกม โดยปกติผมอาจเห็นด้วย แต่ถ้าเป็น ไดรเวอร์เคอร์เนลระดับล่าง เรื่องจะต่างออกไป และยิ่งเป็นบริษัทความปลอดภัยก็ยิ่งร้ายแรงกว่า
    ครั้งหนึ่งลูกค้าเคยสั่งทำโซลูชันความปลอดภัยสูงแบบปรับแต่งเฉพาะที่อิงกับไดรเวอร์เคอร์เนล โดยรันฐานข้อมูลสำคัญบนคอมพิวเตอร์ออฟไลน์ และต้องติดตาม system call ทั้งหมด เพื่อแจ้งเตือนและบันทึกรายละเอียดการเปลี่ยนแปลงอย่างถูกต้องเมื่อมีการเปลี่ยนข้อมูล แบ็กอัปก็ห้ามออกไปข้างนอกเด็ดขาด และยังต้องมีขั้นตอนความปลอดภัยก่อนติดตั้งหน้างาน เช่น ตรวจสอบว่า Windows มีการ hook ntdll หรือไม่ ไม่ยอมรับ exception, การค้าง, deadlock และถ้าพลาด system call แม้แต่ครั้งเดียวก็ถือเป็นหายนะ
    ดังนั้นทุกครั้งที่โค้ดไดรเวอร์เปลี่ยน เราจะทดสอบซ้ำตามขั้นตอนที่กำหนดบนคอมพิวเตอร์สำนักงาน 7 เครื่องที่มีฮาร์ดแวร์ต่างกัน และการทดสอบสุดท้ายก่อนปล่อยจริงก็ครอบคลุมกว่านั้นอีก
    เมื่อวัดด้วยมาตรฐานนี้ CrowdStrike แทบจะเป็นมือสมัครเล่นเต็มตัว ไม่ได้มีผลงานสนับสนุนชุมชนความปลอดภัย และระดับงานวิจัยก็ดูประมาณนักวิจัยความปลอดภัยระดับจูเนียร์ ท่าทีที่พูดเกินจริงอย่างโจ่งแจ้งหรือรีบด่วนสรุปก็ไม่ได้ถูกมองดีในชุมชน
    ควรดูบริษัทมืออาชีพตัวจริงอย่าง Kaspersky และ Checkpoint พวกเขาไม่เพียงสร้างโซลูชันความปลอดภัยระดับสูงที่พิสูจน์แล้ว แต่ยังมีงานวิจัยที่มีคุณค่าให้ชุมชนฟรีๆ เช่น ค้นพบ zero-day แล้วรายงานก่อนจะถูกนำไปใช้โจมตี CrowdStrike สมควรถูกวิจารณ์
  • มีคนที่ชอบการดับไฟในเชิงอุปมาแบบนั้นจริงหรือ? งานแก้ซ้ำ แบบนั้นค่อนข้างน่าหงุดหงิดนะ
  • ในฐานะอดีตวิศวกรประกันคุณภาพ ผมยืนยันได้ว่า คุณภาพมักถูกปฏิบัติเหมือนกำแพงน่ารำคาญที่ขวางหน้าคนที่ไล่ตามผลประโยชน์ของตัวเอง ภายนอกอาจถูกแต่งคำพูดว่าเป็นสิ่งที่ขัดขวางการสนุกกับเงินลูกค้า
    ในบรรดากลยุทธ์ปรับโครงสร้างองค์กรที่เห็นซ้ำๆ มาหลายปี สิ่งที่ติดใจที่สุดคือแนวคิดว่า “จะฝึกบุคลากรฝ่ายวิศวกรรมทั้งหมดให้เป็นคนที่ทดแทนกันได้ทันทีในแต่ละโดเมน” นั่นคือการย่ำอยู่กับที่โดยสมบูรณ์

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

  • สงสัยว่าคุณสังเกตไหมว่าซอฟต์แวร์ที่เป็นปัญหาถูกติดตั้งอยู่เป็นหลักในบริษัทที่กฎระเบียบและการตรวจสอบมีน้ำหนักเหนือสามัญสำนึกของผู้ดูแลระบบอยู่แล้ว คุณแน่ใจได้ไหมว่าคำตอบคือแค่ เพิ่มกฎระเบียบแบบเดิม เข้าไปอีก?
  • เหตุผลที่บริษัทเหล่านั้นรัน CrowdStrike ตั้งแต่แรกก็เพราะ กฎระเบียบ นั่นแหละ
  • ได้ยินหลายครั้งว่ามีคนตอบว่า “ถ้ากำกับดูแลอุตสาหกรรม สหรัฐฯ จะแพ้จีน” หรือ “กฎระเบียบจะฆ่าความได้เปรียบในการแข่งขันของสหรัฐฯ” ซึ่งน่าหงุดหงิดจริงๆ
    ถ้าเป็นพื้นที่ที่สำคัญต่อความปลอดภัย ก็ควรถูกพิจารณาอย่างเข้มงวดกว่าสิ่งอื่น และไม่ควรปล่อยให้เป็นกระบวนการประกันคุณภาพแบบกำกับดูแลตัวเองของบริษัทแสวงกำไร ต้องมีการตรวจทานมากขึ้นก่อนกดปุ่มใหญ่
    เพิ่มเติมคือ ประโยคในเครื่องหมายคำพูดไม่ใช่คำพูดของผม แต่เป็นข้อโต้แย้งที่ได้ยินจากคนอื่นเวลาพูดถึงกฎระเบียบ
  • เหมือนทุกเรื่อง คือกฎที่ให้เลือกได้แค่สองอย่างจาก ถูก เร็ว ดี
    ซอฟต์แวร์แทบจะถูกสร้างแบบถูกและเร็วเสมอ แม้แต่ NASA ก็ยังเคยมีจรวดระเบิดกลางอากาศเพราะความผิดพลาดของซอฟต์แวร์

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

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

• น่าสงสัยที่คนที่ถูกอ้างว่าเป็นผู้เชี่ยวชาญด้านกระบวนการวิศวกรรมกลับเป็น นักออกแบบ UX อาวุโส ดูไม่น่าจะใกล้ชิดกับกระบวนการปล่อยแพตช์เคอร์เนลมากนัก

  • โอกาสที่จะใกล้ชิดโดยตรงคงต่ำ แต่ก็ยังสะท้อนวัฒนธรรมโดยรวมของบริษัท และสอดคล้องกับวัฒนธรรมวิศวกรรมเคอร์เนลเท่าที่เรารู้ เช่น การทดสอบแบบจำกัด ไม่มีการรีวิว และไม่ใช้ กลไกป้องกันความปลอดภัย ทั่วไป

• ไม่ได้จะหาเหตุผลให้การควบคุมคุณภาพของ CrowdStrike แต่ในหลายที่ทำงานด้านพัฒนาซอฟต์แวร์ที่ผมเคยเจอ ก็มีกรณีที่ ขาดการควบคุมคุณภาพ อยู่ไม่น้อย
  อ่านบทความแล้วอาจรู้สึกเหมือนทุกโปรเจกต์ซอฟต์แวร์ได้รับการทดสอบอย่างดี แต่จากประสบการณ์ของผม ส่วนใหญ่ถูกเร่งปล่อยออกมา

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

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

  • ในบริษัทอย่าง Boeing รายชื่อพนักงานที่พึงพอใจอาจสั้นกว่าด้วยซ้ำ

• ทุกสิ่งที่รู้เกี่ยวกับ CrowdStrike ทำให้นึกถึง Knight Capital ปัญหาวัฒนธรรมเล็ก ๆ ค่อย ๆ กลายเป็นความผิดปกติเต็มรูปแบบ และสุดท้ายนำไปสู่บั๊กที่จะทำลายบริษัท

  • Knight Capital ขาดทุน 10 ล้านดอลลาร์ต่อนาที
    ปัญหาการซื้อขายที่ทำให้ตลาดหุ้นปั่นป่วนเมื่อเช้าวันพุธมีต้นทุนถึงระดับนั้นอยู่แล้ว และ Knight Capital Group ประกาศว่าเสียเงิน 440 ล้านดอลลาร์จากการขายหุ้นทั้งหมดที่ซื้อมาโดยผิดพลาดเพราะข้อบกพร่องของคอมพิวเตอร์
    “ข้อบกพร่อง” งั้นเหรอ…
    https://en.wikipedia.org/wiki/Therac-25

• ที่บริษัทเก่า ลูกค้าบางรายและบริษัทประกันความรับผิดผลักดันอย่างหนักให้ใช้ CrowdStrike ด้วยเหตุผลด้าน compliance โดยเฉพาะ BCG ที่กำหนดให้ใช้ CrowdStrike
  การโน้มน้าวไม่ให้ใช้ CrowdStrike เป็นการต่อสู้ที่ยากจริง ๆ สุดท้ายก็ทำสำเร็จ แต่ต้องใช้การประชุมและเวลาเป็นจำนวนมากเพื่อโน้มน้าวผู้มีส่วนได้ส่วนเสียหลายฝ่าย ผมคิดว่าคนจำนวนมากคงยอมถอยแล้วติดตั้งไปเลย

  • สงสัยว่าสุดท้ายใช้โซลูชัน EDR ตัวอื่น หรือโน้มน้าวจนไม่ต้อง deploy เลยกันแน่

• ผมเคยทำงานในทีมที่ deploy เอเจนต์ CrowdStrike ให้กับองค์กร ปัญหาใหญ่ที่สุดอย่างหนึ่งคือ daemon ทิ้ง log ปริมาณมหาศาล แต่ไม่มี การตั้งค่า ให้หยุดหรือลดมันได้