การตัดสินใจที่บั่นทอนความน่าเชื่อถือของ Azure – บันทึกจากอดีตวิศวกร Azure Core

 (isolveproblems.substack.com)
3 คะแนน โดย GN⁺ 27 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อดีตวิศวกรอธิบายอย่างละเอียดถึงกระบวนการที่ การตัดสินใจภายใน Microsoft Azure Core ที่ไม่สอดคล้องกับความเป็นจริง สะสมจนกลายเป็นความสับสนทางเทคนิคและการพังทลายของความเชื่อมั่น
  • ปัญหาตัวอย่างที่ถูกชี้ชัดคือ แผนพอร์ตฟีเจอร์ของ Windows ที่มองข้ามข้อจำกัดของฮาร์ดแวร์ และการมีอยู่ของ เอเจนต์จัดการ 173 ตัวอย่างไร้ระเบียบ
  • โครงสร้างที่ซับซ้อนเช่นนี้กำลังรองรับ เวิร์กโหลดสำคัญอย่าง OpenAI, Anthropic และคลาวด์ภาครัฐ ทำให้ความผิดพลาดเพียงจุดเดียวมีความเสี่ยงลุกลามเป็นเหตุขัดข้องระดับโลก
  • ท่ามกลางการไม่ตอบสนองจากผู้บริหาร ยังเกิดเหตุสืบเนื่อง เช่น ความสัมพันธ์กับ OpenAI ที่แย่ลง, การสูญเสียความเชื่อมั่นจากรัฐบาลสหรัฐฯ และ ความล่าช้าในการเปิดตัวฟีเจอร์
  • ท้ายที่สุด เรื่องนี้ถูกมองว่านำไปสู่ การหายไปของมูลค่าตลาดระดับ 1 ล้านล้านดอลลาร์ พร้อมตอกย้ำ ความสำคัญของการรับรู้ข้อเท็จจริงทางเทคนิคและการรักษาความเรียบง่าย ในการดำเนินงานโครงสร้างพื้นฐานคลาวด์

บันทึกภายในของการพังทลายแห่งความเชื่อมั่นของ Azure

  • บันทึกความทรงจำจากอดีตวิศวกรว่าด้วย กระบวนการตัดสินใจภายในทีม Microsoft Azure Core ที่ไม่สอดคล้องกับความเป็นจริง และความสับสนทั้งด้านเทคนิคและองค์กรที่ตามมา
  • ตั้งแต่วันแรกที่เข้าร่วม ทีม Overlake R&D ก็ได้เห็นการหารือเรื่อง แผนพอร์ตฟีเจอร์ของ Windows ไปยังการ์ด Overlake โดยไม่สนข้อจำกัดของฮาร์ดแวร์
  • มี เอเจนต์จัดการ 173 ตัว แต่ความซับซ้อนและความไม่โปร่งใสรุนแรงถึงขั้นแทบไม่มีใครรู้ว่ามันทำอะไรและจำเป็นเพราะเหตุใด
  • โครงสร้างลักษณะนี้กำลังรองรับ เวิร์กโหลดหลักอย่าง OpenAI, Anthropic และคลาวด์ภาครัฐ จึงมีความเสี่ยงที่ความผิดพลาดเพียงจุดเดียวจะลามเป็นเหตุขัดข้องระดับโลก
  • ผู้เขียนระบุว่าเรื่องทั้งหมดนำไปสู่ การสูญเสียความเชื่อมั่นจาก OpenAI, ความไม่ไว้วางใจจากกระทรวงกลาโหมสหรัฐฯ แบบเปิดเผย และการหายไปของมูลค่าตลาด 1 ล้านล้านดอลลาร์

การเข้าร่วม Azure Core และสถานการณ์ช่วงต้น

  • วันที่ 1 พฤษภาคม 2023 เข้าร่วมเป็นวิศวกรอาวุโสใน ทีม Overlake R&D ซึ่งรับผิดชอบการ์ด offloading ของ Azure Boost และตัวเร่งความเร็วเครือข่าย
  • ก่อนหน้านี้เคยทำงานในทีม Windows และ Core OS โดยมีส่วนร่วมใน การปรับปรุงเคอร์เนลและการพัฒนาแพลตฟอร์มคอนเทนเนอร์ พร้อมมีส่วนสำคัญกับ Docker, AKS, App Services, Windows Sandbox และเทคโนโลยีหลักอื่น ๆ
  • เคยมีส่วนร่วมกับการออกแบบการ์ด Overlake ระยะแรก (2020~2021) และมีประสบการณ์เสนอ โปรโตคอลการสื่อสารระหว่าง host OS กับการ์ดตัวเร่งความเร็ว
  • กลับมาร่วมงานในฐานะผู้เชี่ยวชาญที่ดูแลและพัฒนาแพลตฟอร์ม Azure โดยตรงมานานกว่า 10 ปี

แผนที่ไม่สอดคล้องกับความเป็นจริงซึ่งพบเห็นตั้งแต่การประชุมครั้งแรก

  • ในวันแรกของการเข้าทำงาน ระหว่างการประชุมวางแผนรายเดือนของทีม ได้เห็นแผนที่จะ พอร์ตองค์ประกอบของ Windows ไปยังการ์ด Overlake
  • แม้ว่า ความจุ RAM และงบพลังงาน ของการ์ด Overlake จะจำกัดอย่างมาก แต่ทีมก็ยังหารือถึงความพยายามในการย้ายฟังก์ชันของ Windows ลงไป
  • นี่เป็นแผนที่เป็นไปไม่ได้ตามสเปกฮาร์ดแวร์ และถึงขั้นมีคำพูดว่า “ลองให้ junior developer ไม่กี่คนทำดู”
  • องค์กรกำลังพิจารณาอย่างจริงจังถึงแนวทาง พอร์ต Windows ไปยัง Linux เพื่อคงเอเจนต์จัดการ VM เอาไว้
  • ผู้เขียนมองว่านี่คือ “แผนที่ห่างไกลจากความเป็นจริง” และตัดสินว่าองค์กรทั้งองค์กรกำลัง เดินขบวนไปสู่เป้าหมายที่เป็นไปไม่ได้

ข้อจำกัดทางเทคนิคและปัญหาเชิงโครงสร้าง

  • ในเวลานั้น สแตกดังกล่าว รองรับได้เพียง VM หลักสิบตัวบน Xeon CPU 400W ซึ่งห่างไกลจากข้อจำกัด 1,024 VM ของไฮเปอร์ไวเซอร์มาก
  • มีปัญหาด้านประสิทธิภาพ เช่น การใช้ทรัพยากรมากเกินไปจนเกิด jitter ใน VM ของลูกค้า
  • แผนที่จะย้ายสแตกที่ไม่มีประสิทธิภาพนี้ไปยัง ARM SoC ขนาดเล็ก เพื่อขยายระบบนั้นเป็นไปไม่ได้ทางเทคนิค
  • ผู้เขียนบอกว่า “แทนที่จะต้องเรียนรู้เทคโนโลยีใหม่ งานที่เร่งด่วนกว่าคือการพาทั้งองค์กรกลับสู่ความจริง”

บทสนทนาภายในเกี่ยวกับ Azure Linux และ Overlake

  • จากการสนทนา 90 นาทีกับหัวหน้ากลุ่ม Linux System Group พบว่ามีการระบุ เอเจนต์ 173 ตัวเป็นผู้สมัครสำหรับการพอร์ตไปยังการ์ด Overlake
  • เมื่อตรวจสอบแล้ว กลับพบว่าไม่มีใครภายใน Microsoft ที่สามารถอธิบาย บทบาท ปฏิสัมพันธ์ และเหตุผลของการมีอยู่ของเอเจนต์ทั้ง 173 ตัว ได้อย่างชัดเจน
  • แกนหลักของ Azure คือ VM, เครือข่าย และสตอเรจ ขณะที่บริการอื่น ๆ ถูกสร้างอยู่บนสิ่งเหล่านี้ แต่ความซับซ้อนที่ไม่จำเป็นกลับสะสมเพิ่มขึ้นเรื่อย ๆ
  • ชุดองค์ประกอบที่ควบคุมไม่ได้ นี้กำลังบริหารเวิร์กโหลดสำคัญอย่าง OpenAI, Anthropic และคลาวด์ภาครัฐ

การสูญเสียความเชื่อมั่นและเหตุการณ์ที่ตามมา

  • โครงสร้างที่ซับซ้อนนี้อยู่ในสภาพที่อาจก่อให้เกิดความเสี่ยงร้ายแรงต่อ ความมั่นคงของชาติและความต่อเนื่องทางธุรกิจ
  • หลังจากนั้น จดหมายที่ส่งถึง CEO, คณะกรรมการบริษัท และ EVP ฝ่าย Cloud+AI ก็ล้วนจบลงโดยไม่ได้รับการตอบกลับ
  • ผลที่ตามมาคือ ความสัมพันธ์กับ OpenAI ที่แย่ลง, การพังทลายของความเชื่อมั่นจากรัฐบาลสหรัฐฯ (รวมถึงคำกล่าวต่อสาธารณะของรัฐมนตรีกลาโหม), การสูญเปล่าทางวิศวกรรมและคำสั่งให้เปลี่ยนไปใช้ Rust, รวมถึง ความล่าช้าในการเปิดตัวฟีเจอร์
  • ผู้เขียนเรียกสิ่งนี้ว่า “เหตุการณ์ที่ทำให้มูลค่าตลาดหายไป 1 ล้านล้านดอลลาร์” และเตือนบริษัทที่ใช้งาน Azure ถึง ความเสี่ยงของการพึ่งพาใช้งานใน production environment

บทสรุป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 27 일 전
ความเห็นจาก Hacker News

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

    • เมื่อก่อนเคยทึ่งกับเอกสารของ Azure แต่หลังจากลองทำจริงอยู่สัปดาห์หนึ่งแล้ว GraphAPI ทำงานไม่ตรงกับเอกสาร จนการทดสอบในสภาพแวดล้อมทดสอบล้มเหลวทั้งหมด
      หลังจากนั้นก็ไม่เชื่อเอกสารอีกเลย
    • เคยทำงานกับคอนซัลแทนต์ Azure และพวกเขาเองก็เกลียด Azure
    • ผู้บริหารย้ายไป AKS เพราะมีเครดิตเยอะ แต่กลับเจอว่า pod แครชแบบสุ่ม และ latency ของดิสก์บน DB node ก็พุ่งสูง
      บริการที่เคยรันนิ่งบน GCP ได้เสถียร กลายเป็นระบบที่คาดเดาไม่ได้

  • เคยเห็น Azure OpenAI รั่วคำตอบจากพรอมป์ต์ของลูกค้ารายอื่น ตอนที่มีโหลดสูง
    มีทวีตที่เกี่ยวข้องด้วย
    แต่ดูเหมือนไม่มีใครสนใจเท่าไร

    • สงสัยว่า “Azure OpenAI” หมายถึงอะไรแน่ — GitHub Copilot, Microsoft Copilot, OpenAI API หรือ LLM ตัวใดตัวหนึ่งที่โฮสต์อยู่บน Azure?
      สถานการณ์มันเหมือน แดนเถื่อน มาก

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

    • ตอนนี้ ดูแล AWS, Azure และ GCP ทั้งหมดในฐานะ SRE และ 80~90% ของเหตุขัดข้องเกิดจาก Azure
      Azure ไม่รู้ด้วยซ้ำว่ามีปัญหา ไม่รู้สาเหตุ และดูเหมือนจะไม่สนใจด้วยซ้ำ
      ทั้งทีมเกลียด Azure
    • Azure มีปัญหาเรื่อง consistency และ race condition เยอะเกินไป
      เลยดีใจที่ตอนนี้ใช้โมเดล OpenAI ผ่าน AWS Bedrock ได้ จะได้เลี่ยง Azure
      ความน่าเชื่อถือยังเป็นปัญหาร้ายแรงอยู่เหมือนเดิม
    • บริษัทใหญ่ๆ มักตัดสินใจ เสียสละคุณภาพ เพื่อให้ตัวเลขระยะสั้นดูดี
      กลยุทธ์แบบ “ปล่อยให้เร็วแล้วค่อยกลับมาแก้” สุดท้ายก็นำไปสู่ผลลัพธ์แบบนี้
    • เคยเห็นรายงานความปลอดภัยที่หนีออกจากคอนเทนเนอร์บน Azure แล้วไปเจอ ช่องโหว่ใน management controller
      ตั้งแต่นั้นมาก็ไม่ไว้ใจอีกเลย
    • ต่อให้แจกเครดิตฟรี ก็ยังคิดว่าจ่ายเงินใช้ AWS หรือ GCP ยังดีกว่า

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

    • การส่งจดหมายตรงถึงบอร์ดเป็นพฤติกรรมที่ ไม่มีทางจบดีในองค์กร
      Azure อาจเละจริง แต่แนวทางของผู้เขียนก็อาจมีปัญหาเหมือนกัน
    • AWS กับ GCP มี UX/DX ดีกว่ามาก ส่วน Azure นั้น ไม่แม้แต่จะบอกว่าทำไมมันถึงใช้ไม่ได้
      ภาพจำที่มีต่อ Azure จึงเป็นลบทั้งหมด
    • Microsoft เป็นโซลูชันพื้นฐานของหน่วยงานรัฐ แต่การเสนอให้ รีไรต์ทั้งหมด ไม่ใช่เรื่องสมจริง
      วิธีเข้าหาของผู้เขียนกลับยิ่งทำให้ความน่าเชื่อถือลดลง
    • รู้สึกตกใจที่โครงสร้างปล่อยให้คนระดับตำแหน่งต่ำตามที่ผู้เขียนพูดถึง มาดูแลระบบแกนหลัก
    • มีคนประเภท “ทุกอย่างพังหมดแล้ว” อยู่เยอะ แต่บางทีมันอาจเป็น ปัญหาเรื้อรังจากความเฉื่อยขององค์กร
      ความถี่ที่พนักงานใหม่พูดว่า “wtf/day” ดูเหมือนจะเป็นตัวชี้วัดสุขภาพองค์กรอย่างหนึ่ง
      ต่อให้มองจากข้างนอก Azure ก็เห็นชัดว่า คุณภาพต่ำมาก
      เพราะรีบยัดฟีเจอร์เพื่อไล่ตาม AWS เลยจมอยู่ใน บึงหนี้ทางเทคนิค ขนาดใหญ่
      แม้แต่ฟังก์ชันพื้นฐานอย่าง IPv6, azcopy, การอัปเกรด VM ก็ยังไม่เสถียรอยู่ดี

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

  • ช่วงท้ายบทความที่บอกว่า Microsoft ปลดพนักงาน 15,000 คน ในปี 2025 นั้นน่าสนใจมาก
    ดูเหมือนเป็นตัวอย่างของความจริงหลังยุคบูม AI

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

  • ส่วนที่บอกว่าถ้าโฮสต์ถูกเจาะก็เข้าถึงหน่วยความจำของ VM ทั้งหมดได้ ฟังดู อันตรายมาก

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

  • การได้เห็นคำอ้างอิงจาก CNBC ว่าเงินเดือนของ Satya Nadella ขึ้น 22% เป็น 96.5 ล้านดอลลาร์
    วางคู่กับคำพูดของนักบินอวกาศ Artemis II ที่บอกว่า “Outlook สองตัวใช้ไม่ได้ทั้งคู่” มันช่างประชดประชันดี

    • “Outlook สองตัว” งั้นเหรอ แค่ตัวเดียวก็มากเกินพอแล้ว

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

  • เคยใช้ Azure ในปี 2018 แล้วพบว่ามัน ช้า แพง และคุณภาพแย่
    ตอนนั้นต้องไปพยายามแก้ปัญหาที่แม้แต่ฟังก์ชันพื้นฐานยังใช้ไม่ได้ ร่วมกับผู้ใช้คนอื่นในฟอรัม GitHub
    บทความนี้ช่วยคลายข้อสงสัยที่มีในตอนนั้น
    สำหรับผม Google Cloud คือแพลตฟอร์มที่ออกแบบมาดีที่สุด แต่ก็น่าเสียดายที่มี การซัพพอร์ตโดยมนุษย์น้อยกว่า AWS

    • ฝั่งซัพพอร์ตของ GCP ก็ แย่มากจริงๆ
      ผู้ดูแลบัญชีเปลี่ยนไปสามครั้งในสามเดือน และบางครั้งคำขอเพิ่ม quota หรือคำถามเรื่องข้อจำกัดของระบบก็ถูกเมินไปเลย