เมื่อวันที่ 28 เมษายน 2026 มิตเชล ฮาชิโมโตะ ได้ประกาศว่า Ghostty ซึ่งเป็นอีมูเลเตอร์เทอร์มินัลโอเพนซอร์สของเขา กำลังจะย้ายออกจาก GitHub เขาเป็นผู้ใช้ GitHub ลำดับที่ 1299 เขาเข้าร่วมเมื่อเดือนกุมภาพันธ์ 2008 และใช้แพลตฟอร์มนี้เกือบทุกวันมานานกว่า 18 ปี ไม่มีสิ่งใดมีความหมายในวันที่เขาเขียนโพสต์ดังกล่าว เพราะเขาได้บันทึกเหตุการณ์ระบบล่มที่เกิดขึ้น "เกือบทุกวัน" และความล้มเหลวของ GitHub Actions ในวันประกาศก็ทำให้เขาไม่สามารถตรวจสอบ PR ได้เป็นเวลาสองชั่วโมง คำตัดสินของเขาชัดเจนว่า: "นี่ไม่ใช่สถานที่สำหรับทำงานจริงจังอีกต่อไป หากมันทำให้คุณทำงานไม่ได้วันละหลายชั่วโมง ทุกวัน"
หากคุณเป็นผู้สร้างเครื่องมือสำหรับนักพัฒนา นี่คือประกาศที่คุณควรอ่านซ้ำสอง ฮาชิโมโตะไม่ใช่ผู้ใช้ GitHub ทั่วไป เขาเป็นผู้ร่วมก่อตั้ง HashiCorp บน GitHub ได้จัดส่ง Terraform, Vagrant, Vault, Consul และ Boundary ผ่านแพลตฟอร์มนี้ และเป็นผู้ใช้ GitHub ลำดับที่ 1299 เมื่อผู้ใช้ที่มีประวัติเช่นนี้เดินออกจากแพลตฟอร์มสำหรับนักพัฒนาที่โดดเด่นที่สุดในโลก เรื่องราวนี้จึงยิ่งใหญ่กว่าการที่อีมูเลเตอร์เทอร์มินัลหนึ่งตัวจะเลือกบ้านใหม่ มันเป็นสัญญาณเกี่ยวกับความน่าเชื่อถือ การผูกขาด และต้นทุนในการสร้างเครื่องมือที่นักพัฒนาคนอื่นๆ ต้องพึ่งพาอยู่ทุกวัน บทความนี้จะวิเคราะห์สิ่งที่ฮาชิโมโตะกล่าว ความหมายสำหรับผู้ที่จัดส่งเครื่องมือสำหรับนักพัฒนา และรูปแบบที่ช่วยปกป้องระบบของคุณจากกับดักเดียวกัน
สำหรับบริบทที่กว้างขึ้นเกี่ยวกับวิธีที่เครื่องมือสำหรับนักพัฒนาในยุค AI กำลังเปลี่ยนแปลงเวิร์กโฟลว์ที่ใช้ GitHub เป็นหลัก โปรดดู วิธีการเขียนไฟล์ AGENTS.md และ การใช้งานและ API การเรียกเก็บเงินของ GitHub Copilot สำหรับทีม สำหรับมุมมองของทีมหนึ่งเกี่ยวกับการทำงานอัตโนมัติเพื่อแก้ไขช่องโหว่ด้านความน่าเชื่อถือของ GitHub โปรดดู บทความเกี่ยวกับบอทคัดแยก Clawsweeper
สรุป (TL;DR)
- มิตเชล ฮาชิโมโตะ ประกาศเมื่อวันที่ 28 เมษายน 2026 ว่า Ghostty จะย้ายออกจาก GitHub ไปยังแพลตฟอร์มที่ยังไม่ระบุชื่อ
- เหตุผลของเขา: GitHub Actions และแพลตฟอร์มล่มบ่อยครั้ง ซึ่งเขาบันทึกไว้ในสมุดบันทึกส่วนตัวว่า "เกือบทุกวันมีการขัดข้อง" ในวันประกาศเกิดการล่มของ Actions สองชั่วโมง ซึ่งทำให้ไม่สามารถตรวจสอบ PR ได้
- เขาเก็บ Ghostty เวอร์ชันอ่านอย่างเดียวไว้บน GitHub และกำลังย้ายการพัฒนาหลักไปทีละน้อย ส่วนโปรเจกต์อื่นๆ ของเขายังคงอยู่บน GitHub ในขณะนี้
- เรื่องราวนี้ไม่ได้สำคัญที่ว่า Ghostty จะไปอยู่ที่ใด แต่สำคัญตรงที่ฮาชิโมโตะ ผู้ใช้ GitHub ลำดับที่ 1299 ได้เดินจากไปเพราะเหตุผลด้านความน่าเชื่อถือ ไม่ใช่เพราะเหตุผลด้านฟีเจอร์
- สำหรับผู้สร้างเครื่องมือสำหรับนักพัฒนา บทเรียนคือความน่าเชื่อถือมีความสำคัญกว่าฟีเจอร์เมื่อเครื่องมือของคุณอยู่ในเส้นทางวิกฤตของใครบางคน การแสดงบนหน้าสถานะและการทวีตว่า “เรากำลังตรวจสอบ” ไม่สามารถซื้อความไว้วางใจกลับคืนมาได้
- โดยเฉพาะสำหรับทีม API กลยุทธ์คือการแยกส่วนประกอบ: ไคลเอ็นต์ที่ไม่ขึ้นกับผู้ให้บริการ, การจำลองการพึ่งพิงในช่วงที่ระบบล่ม และเส้นทางการย้ายข้อมูลที่คุณฝึกฝนไว้ก่อนที่จะต้องใช้จริง Apidog สร้างขึ้นบนรูปแบบนี้
สิ่งที่ฮาชิโมโตะกล่าวในโพสต์
โพสต์ประกาศนั้นสั้น ซึ่งเป็นส่วนหนึ่งของสารที่ต้องการสื่อ ไม่มีแถลงการณ์ ไม่มีคำตำหนิ Microsoft และไม่มีการแนะนำแพลตฟอร์มทางเลือก ฮาชิโมโตะเล่าลำดับเหตุการณ์อย่างตรงไปตรงมา: เขาเริ่มบันทึกการล่มของ GitHub สมุดบันทึกเต็มเร็วกว่าที่เขาคาดไว้ และในเช้าวันที่เขาเขียนโพสต์ ความล้มเหลวของ GitHub Actions ได้ขัดขวางไม่ให้เขาสามารถตรวจสอบ PR ได้เป็นเวลาสองชั่วโมง เขาจึงสรุปว่าแพลตฟอร์มนี้ไม่น่าเชื่อถือเพียงพอสำหรับการทำงานที่เขาทำบน Ghostty อีกต่อไปแล้ว
ข้อมูลที่เกี่ยวข้องกับประกาศนี้ควรได้รับการพิจารณาอย่างละเอียด เมื่อวันที่ 27 เมษายน 2026 หนึ่งวันก่อนโพสต์ของฮาชิโมโตะ GitHub ประสบปัญหาการล่มครั้งใหญ่ที่ส่งผลกระทบต่อ Actions, packages และ API สมุดบันทึกที่เขาอ้างถึงในโพสต์นั้นบันทึกเหตุการณ์ก่อนหน้าการล่มครั้งนั้น ซึ่งหมายความว่าเขาได้ติดตามรูปแบบนี้มาหลายเดือนแล้ว เขาอธิบายการย้ายครั้งนี้ว่าเป็นการวางแผนอย่างเงียบๆ ไม่ใช่การตอบสนองต่อวันที่เลวร้ายเพียงวันเดียว การล่มเมื่อวันที่ 27 เมษายนเป็นเพียงปัจจัยเร่งเวลา ไม่ใช่ตัวตัดสินใจ
เขายังได้ระบุขอบเขตไว้อย่างชัดเจน Ghostty จะย้ายออกไป ส่วนโปรเจกต์อื่นๆ ของเขายังคงอยู่บน GitHub ในขณะนี้ Ghostty repository จะยังคงเป็นเวอร์ชันอ่านอย่างเดียวที่ URL ปัจจุบัน และแพลตฟอร์มใหม่จะเป็นที่สำหรับการพัฒนาหลัก ซึ่งรวมถึงประเด็น (issues), การร้องขอการรวมโค้ด (pull requests) และ CI เขาอยู่ระหว่างการพูดคุยกับผู้ให้บริการหลายราย ทั้งเชิงพาณิชย์และ FOSS และยังไม่ได้ตัดสินใจเลือกปลายทาง การย้ายข้อมูลจะดำเนินการทีละน้อย ไม่ใช่เป็นการเปลี่ยนในครั้งเดียว
การละเว้นบางสิ่งบอกคุณได้มากพอๆ กับคำพูดที่เอ่ยออกมา ฮาชิโมโตะไม่ได้กล่าวถึงฟีเจอร์ ราคา หรือทิศทางผลิตภัณฑ์ ข้อร้องเรียนคือพื้นผิวที่เขาพึ่งพาหยุดการตอบสนองเป็นเวลาหลายชั่วโมง และโครงการที่จัดส่งซอฟต์แวร์ไม่สามารถทำงานบนพื้นฐานที่ไม่ทำงานได้
ทำไมมุมมองด้านความน่าเชื่อถือจึงสำคัญกว่าการย้ายแพลตฟอร์ม
การรายงานข่าวส่วนใหญ่เกี่ยวกับประกาศนี้กำลังตั้งคำถามผิดประเด็น คำถามที่น่าสนใจไม่ใช่ว่า Ghostty จะไปอยู่ที่ใด แต่เป็นคำถามว่าแพลตฟอร์มที่มีความลึกซึ้งทางวิศวกรรมอย่าง GitHub มาถึงจุดที่ผู้ใช้ OG ที่โดดเด่นเป็นอันดับสองต้องเดินจากไปเพราะเหตุผลด้านความน่าเชื่อถือได้อย่างไร คำถามที่น่าสนใจเป็นอันดับสองคือสิ่งนี้บอกอะไรเกี่ยวกับเครื่องมือที่พวกเราที่เหลือส่วนใหญ่กำลังสร้าง
มีสามสิ่งที่ทำให้ประกาศนี้แตกต่างจากโพสต์ “ฉันกำลังจะย้ายออกจาก X” ทั่วไป
- ผู้ใช้. ฮาชิโมโตะไม่ใช่นักพัฒนาหน้าใหม่ เขาได้สร้างเครื่องมือโครงสร้างพื้นฐานที่บริษัท Fortune 500 ใช้ เมื่อเขากล่าวว่า GitHub ไม่น่าเชื่อถือ กลุ่มเป้าหมายที่ได้รับข้อความนั้นรวมถึงผู้ที่ตัดสินใจว่าซอร์สโค้ดของบริษัทของตนจะอยู่ไหน รายชื่ออีเมลของ CTO เต็มไปด้วยโพสต์ดังกล่าวตั้งแต่เช้าวันที่ 29 เมษายน
- เหตุผล. เขาไม่ได้ย้ายออกเพราะ Copilot, Microsoft, การฝึกอบรม AI, สัญญา ICE, ราคา หรือหัวข้อการย้ายออกทั่วไปอื่นๆ เขาจากไปเพราะบริการยังคงเสียอยู่ตลอดเวลา ซึ่งทำให้การสนทนาเหลือเพียงประเด็นเดียวที่ทุกคนเห็นพ้องต้องกันว่าสำคัญ: เครื่องมือนั้นใช้งานได้จริงหรือไม่เมื่อคุณต้องการมัน?
- น้ำเสียง. ไม่มีอารมณ์โกรธเคือง โพสต์นี้อ่านแล้วรู้สึกเหมือนรายงานวิเคราะห์หลังเหตุการณ์ที่เขียนโดยคนที่พยายามอย่างเต็มที่ที่จะอยู่ต่อ การไร้ซึ่งดราม่าทำให้โพสต์นี้มีน้ำหนักมากกว่าโพสต์ที่เสียงดังอื่นๆ ผู้คนเชื่อในสิ่งที่เขากล่าว
สำหรับผู้ที่ดูแลเครื่องมือสำหรับนักพัฒนา การผสมผสานนี้คือสัญญาณของสถานการณ์ที่เลวร้ายที่สุด ผู้ใช้ที่อยู่มานาน ไม่มีเป้าหมายทางการเมืองที่จะบดขยี้ ไม่มีการทะเลาะวิวาทสาธารณะ เพียงแต่มีการสะสมบันทึก “วันนี้ใช้งานไม่ได้” อย่างเงียบๆ จนกระทั่งคณิตศาสตร์ไม่สมเหตุสมผลอีกต่อไป ไม่มีคำตอบจากฝ่ายประชาสัมพันธ์สำหรับสมุดบันทึก
สิ่งนี้หมายความว่าอย่างไรหากคุณสร้างเครื่องมือสำหรับนักพัฒนา
หากผลิตภัณฑ์ของคุณอยู่ในเส้นทางวิกฤตของนักพัฒนา ประกาศของฮาชิโมโตะคือตัวกระตุ้นการทดสอบความเครียด ลองนำไปใช้กับบริการของคุณเอง
คำถามที่หนึ่ง: ผู้ใช้ของคุณกี่เปอร์เซ็นต์ที่สามารถเขียนบันทึกประจำวันแบบเดียวกันเกี่ยวกับคุณได้?
ดึงเหตุการณ์ที่เกิดขึ้นในหน้าสถานะของคุณในช่วง 90 วันที่ผ่านมา รวมถึงการทำงานที่ลดลงซึ่งทีมของคุณทราบแต่ไม่ได้รายงานในหน้าสถานะ จับคู่ข้อมูลเหล่านั้นกับชั่วโมงการทำงานของลูกค้า 20 อันดับแรกของคุณ นับว่ามีกี่ชั่วโมงที่เสียไปกับการรอคุณ หากคำตอบคือ “มากกว่าศูนย์ชั่วโมงต่อสัปดาห์ต่อผู้ใช้ที่ใช้งานหนัก” แสดงว่าคุณกำลังอยู่ในเส้นทางเดียวกัน
คำถามที่สอง: ค่าอนุพันธ์อันดับสองของความน่าเชื่อถือของคุณคืออะไร?
ความน่าเชื่อถือที่คงที่นั้นดี แต่ความน่าเชื่อถือที่เสื่อมถอยอย่างเงียบๆ คือกับดัก สมุดบันทึกของฮาชิโมโตะบันทึกรูปแบบ ไม่ใช่เหตุการณ์เดียว หากคุณไม่มีงบประมาณข้อผิดพลาดต่อส่วนประกอบที่ใครบางคนอ่านในเช้าวันจันทร์ คุณก็ไม่สามารถบอกได้ว่าตัวเลขของคุณกำลังเคลื่อนที่ไปในทิศทางใด
คำถามที่สาม: คุณเผยแพร่ข้อมูลเพียงพอที่ผู้ใช้ไม่จำเป็นต้องจดบันทึกหรือไม่?
สมุดบันทึกมีอยู่เพราะผู้ใช้ไม่เชื่อสัญญาณสาธารณะ หน้าสถานะของคุณควรอัปเดตอย่างสม่ำเสมอ ไม่ใช่ปล่อยทิ้งไว้ หากฟีเจอร์ใดทำงานด้อยลง ให้ทำเครื่องหมายไว้ หากภูมิภาคใดทำงานช้า ให้ทำเครื่องหมายไว้ หากคิวแบ็กกราวนด์ของคุณล่าช้าไป 30 นาที ให้ทำเครื่องหมายไว้ ผู้ใช้ที่สามารถเห็นความจริงแบบเรียลไทม์จะไม่เริ่มต้นจดบันทึก
คำถามที่สี่: คุณมีความน่าเชื่อถือสำหรับการทำงานจริงจัง หรือเพื่อการสาธิต?
การทำงาน 99.95% ที่รวมช่วงเวลาหยุดทำงานทั้งหมดไว้ในชั่วโมงทำงานของนักพัฒนานั้นแย่กว่าการทำงาน 99.9% ที่กระจายอย่างสม่ำเสมอ หากปริมาณงานของคุณคือการตรวจสอบ PR สี่ชั่วโมง การหยุดทำงานสองชั่วโมงในช่วงเวลาใดๆ ก็ไม่เกี่ยวข้อง แต่การหยุดทำงานสองชั่วโมงระหว่างเซสชันนั้นเท่ากับทั้งเซสชัน วัดความพร้อมใช้งานตามเส้นโค้งการใช้งานจริงของลูกค้า ไม่ใช่ของคุณ
การผูกขาดและต้นทุนของ “ต้องเป็น GitHub เสมอ”
วลีที่ฮาชิโมโตะใช้พูดถึงตัวเองคือประโยคที่น่าจดจำที่สุดในโพสต์: “สำหรับผมแล้ว ไม่เคยมีคำถามเลยว่าจะวางโปรเจกต์ไว้ที่ไหน: ก็ต้อง GitHub เสมอ” นั่นคือต้นทุนของความเคยชิน และเป็นต้นทุนที่นักพัฒนาส่วนใหญ่ไม่ได้ประเมินค่าอย่างถูกต้อง
เมื่อแพลตฟอร์มเดียวเป็นค่าเริ่มต้นสำหรับ repos, issues, PRs, CI, การแจกจ่ายแพ็กเกจ, releases และ identity พื้นที่ผิวของการ “ผูกขาด” ก็จะกว้างกว่าพื้นที่ผิวของ “ประวัติ git” มาก คุณสามารถโคลน git repo ไปที่ใดก็ได้ แต่คุณไม่สามารถโคลน issue tracker, ประวัติการตรวจสอบ PR, กระทู้ Discussions, ที่เก็บข้อมูลลับของ GitHub Actions หรือเวิร์กโฟลว์การตรวจสอบที่ผูกกับ CODEOWNERS ด้วยคำสั่งเดียวได้ ต้นทุนการย้ายข้อมูลมีรูปร่างเหมือนภูเขาน้ำแข็ง
ต้นทุนนั้นเพิ่มขึ้นสำหรับผู้สร้างเครื่องมือ หากเครื่องมือสำหรับนักพัฒนาของคุณทำงานภายใน GitHub Action, แจกจ่ายผ่าน Marketplace, ยืนยันตัวตนด้วย GitHub OAuth และจัดส่งรุ่นผ่าน GitHub Packages ความน่าเชื่อถือของเครื่องมือคุณก็ขึ้นอยู่กับความน่าเชื่อถือของ GitHub งบประมาณข้อผิดพลาดของคุณเป็นเพียงส่วนเล็กๆ ของพวกเขา ลูกค้าของคุณจะประสบปัญหาช่วงที่ระบบของคุณหยุดทำงานเมื่อพวกเขาใช้เครื่องมือของคุณ แต่พวกเขาก็จะประสบปัญหาช่วงที่ระบบหยุดทำงานเมื่อ GitHub ล่มและเครื่องมือของคุณหยุดตอบสนอง การระบุความผิดพลาดอาจไม่ถูกต้องเสมอไป แต่ประสบการณ์ของลูกค้าคือสิ่งสำคัญ
งานแยกส่วนประกอบเป็นงานที่ไม่น่าดึงดูดใจแต่ก็เป็นงานที่ต้องทำ ทำให้ทุกการพึ่งพิงสามารถแทนที่ได้ ปฏิบัติต่อ GitHub เหมือนเป็นผู้ให้บริการหนึ่งในหลายๆ ราย ไม่ใช่เป็นโครงสร้างพื้นฐาน ทดสอบเส้นทางทางเลือกทุกไตรมาส ย้ายส่วนที่เหมาะสมกับแพลตฟอร์มอื่นได้ดีกว่า และเก็บส่วนที่ไม่เหมาะสมไว้ คำกล่าวของฮาชิโมโตะเรื่อง “การย้ายแบบค่อยเป็นค่อยไป” เป็นแนวทางที่ถูกต้องสำหรับทุกคน ไม่ใช่แค่ตัวเขาเอง
แพลตฟอร์มทางเลือกโดยสังเขป
จุดหมายปลายทางที่เป็นไปได้สำหรับ Ghostty เป็นที่รู้กันในวงกว้างในแง่ของรูปแบบ แม้จะยังไม่ระบุชื่อก็ตาม ตัวเลือกที่น่าเชื่อถือ ณ สิ้นเดือนเมษายน 2026:
- Forgejo. เป็น Hard fork ของ Gitea, เป็น FOSS โดยสมบูรณ์, บำรุงรักษาโดยองค์กรไม่แสวงหากำไร Codeberg e.V. การเชื่อมโยงผ่าน ActivityPub อยู่ในแผนงานและถูกจัดส่งบางส่วน เป็นตัวเลือกเริ่มต้นสำหรับโครงการที่สอดคล้องกับ FOSS
- Codeberg. เป็น Forgejo ที่โฮสต์โดยองค์กรไม่แสวงหากำไร ฟรีสำหรับโอเพนซอร์ส ยังไม่มีคุณสมบัติเทียบเท่า Actions ในระดับ GitHub
- GitLab. มี CI/CD ที่แข็งแกร่ง, มีฟีเจอร์เทียบเท่า GitHub ในเวิร์กโฟลว์ส่วนใหญ่, มีการสนับสนุนเชิงพาณิชย์ เป็นตัวเลือกที่ถกเถียงกันสำหรับชุมชน FOSS เนื่องจากการเปลี่ยนแปลงใบอนุญาตเมื่อเร็วๆ นี้
- Sourcehut. เวิร์กโฟลว์ที่ขับเคลื่อนด้วยอีเมล, เรียบง่าย, รวดเร็ว มีกลุ่มผู้ใช้งานเฉพาะทาง แต่ผู้ที่ใช้มันก็หลงรักมัน การเมืองของ Drew DeVault เป็นทั้งฟีเจอร์หรือข้อผิดพลาดขึ้นอยู่กับความเชื่อเดิมของคุณ
- Forgejo หรือ Gitea แบบ Self-hosted บน Bare Metal. การควบคุมสูงสุด, ความรับผิดชอบในการดำเนินงานสูงสุด เป็นตัวเลือก “ทำงานโดยไม่เปิดเผย”
- Radicle. แบบ Peer-to-peer ไม่มีโฮสต์ส่วนกลาง ยังเป็นช่วงเริ่มต้น แต่แนวคิดการเชื่อมโยงเครือข่ายเป็นจุดแข็งที่สุดที่นี่ น่าจะยังเร็วเกินไปสำหรับโปรเจกต์ที่เปิดเผยต่อสาธารณะ
ฮาชิโมโตะไม่ได้ให้คำมั่นว่าจะเลือกแพลตฟอร์มใดแพลตฟอร์มหนึ่งอย่างชัดเจน สัญญาณที่อยู่ในความเงียบคือไม่มีตัวเลือกใดที่สามารถแทนที่ทุกสิ่งที่ GitHub ทำได้อย่างสมบูรณ์ ซึ่งเป็นประเด็นสำคัญ: เมื่อแพลตฟอร์มหนึ่งดูดซับสแต็กทั้งหมด การแทนที่มันอย่างสะอาดหมดจดจึงเป็นเรื่องยากโดยธรรมชาติ
บทเรียนสำหรับทีม API
หากคุณสร้าง API หรือเครื่องมือ API แทนที่จะเป็นอีมูเลเตอร์เทอร์มินัล รูปแบบเดียวกันนี้ก็ยังคงใช้ได้ เพียงแค่เปลี่ยนชื่อ แทนที่ “GitHub Actions” ด้วย “API ต้นน้ำที่ผลิตภัณฑ์ของคุณพึ่งพา” แทนที่ “issues and PRs” ด้วย “กล่องขาเข้าที่ลูกค้าของคุณแจ้งว่ามีบางอย่างผิดปกติ” คำถามเชิงโครงสร้างยังคงเหมือนเดิม: งานของลูกค้าของคุณพึ่งพิงบริการที่คุณไม่สามารถควบคุมได้มากน้อยเพียงใด และคุณจะยังคงมีประโยชน์ได้อย่างไรเมื่อบริการนั้นขัดข้อง?
สามรูปแบบที่สามารถอยู่รอดได้ในความเป็นจริง
- จำลองทุกสิ่งที่คุณพึ่งพา. ลูกค้าของคุณควรจะสามารถสร้างต่อได้เมื่อ API ต้นน้ำล่ม นั่นหมายความว่าชุดทดสอบ, ลูปการพัฒนาในเครื่อง และไปป์ไลน์ CI ทั้งหมดต้องมีเซิร์ฟเวอร์จำลองที่ส่งคืนการตอบสนองที่สมจริงโดยไม่ต้องเรียกเครือข่าย Apidog นำเสนอสิ่งนี้เป็นฟีเจอร์หลัก; คำจำกัดความข้อมูลเดียวกับที่คุณใช้ทดสอบ API จริงจะสร้างการจำลอง รูปแบบนี้ตรงไปตรงมาและมีค่าใช้จ่ายเพียงครั้งเดียว ดูการเปรียบเทียบกับระบบนิเวศที่มีลักษณะคล้าย OpenAI ใน วิธีใช้ GPT-5.5 API สำหรับตัวอย่างการจำลองหลายผู้ให้บริการในทางปฏิบัติ
- ทดสอบกับผู้ให้บริการหลายราย. OpenAI, Anthropic, Mistral, DeepSeek, Google และ xAI ล้วนเปิดเผยเอนด์พอยต์การสนทนาที่ซ้อนทับกัน หากผลิตภัณฑ์ของคุณครอบคลุมผู้ให้บริการรายใดรายหนึ่ง ความแตกต่างระหว่าง “เราหยุดทำงานเนื่องจาก OpenAI หยุดทำงาน” กับ “เราเปลี่ยนเส้นทางไปยังผู้ให้บริการสำรองอย่างโปร่งใส” คือการทำงานร่วมกันสองวัน เรียกใช้ชุดทดสอบของคุณกับผู้ให้บริการทุกรายที่คุณสนับสนุน ไม่ใช่แค่ผู้ให้บริการหลัก ตัวแปรสภาพแวดล้อมของ Apidog ทำให้การสลับเปลี่ยนเป็นการเปลี่ยนแปลงการกำหนดค่าเพียงบรรทัดเดียว
- แยกไปป์ไลน์การเผยแพร่ของคุณออกจากแพลตฟอร์มโฮสติ้งของคุณ. หาก CI ของคุณทำงานทั้งหมดบน GitHub Actions และ GitHub Actions มีปัญหาในช่วงบ่าย การเผยแพร่ของคุณก็ไม่สามารถดำเนินต่อไปได้ การทำมิเรอร์ CI ไปยังตัวรันที่สอง หรือการโฮสต์เส้นทางวิกฤตด้วยตัวเอง อย่างน้อยที่สุด จะช่วยขจัดจุดที่อาจเกิดความล้มเหลวเพียงจุดเดียวได้ ต้นทุนนั้นมีอยู่จริง แต่ทางเลือกอื่นคือการไม่สามารถจัดส่งได้ในขณะที่หน้าสถานะของผู้ให้บริการหลักของคุณเปลี่ยนสี
เวิร์กโฟลว์แบบ Apidog สำหรับการทำงาน API ที่ยืดหยุ่นเป็นอย่างไร
โดยเฉพาะอย่างยิ่ง นี่คือรูปแบบที่ทีมส่วนใหญ่ใช้เพื่อป้องกันตัวเองจากการหยุดชะงักของผู้ให้บริการต้นน้ำ
- ดาวน์โหลด Apidog และสร้างหนึ่งโปรเจกต์ต่อ API ต้นน้ำที่คุณพึ่งพา
- กำหนด Request และ Response Schemas เพียงครั้งเดียว Apidog จะสร้าง Mock Server จาก Schema ทำให้วงจรการพัฒนาไม่เคยติดขัดที่บริการต้นน้ำ
- จัดเก็บข้อมูลรับรองเป็นความลับที่จำกัดขอบเขตตามสภาพแวดล้อม รูปแบบคำขอเดียวกันจะทำงานกับ
dev(จำลอง),staging(แซนด์บ็อกซ์) และprod(ใช้งานจริง) โดยการเปลี่ยนสภาพแวดล้อม - เขียน Contract Tests ที่ทำงานในทุกๆ การเผยแพร่; การทดสอบเดียวกันนี้จะทำงานกับผู้ให้บริการทุกรายที่คุณสนับสนุน เพื่อให้ข้อบกพร่องของผู้ให้บริการ A ถูกตรวจพบก่อนที่ลูกค้าจะเห็น
- เมื่อ API ต้นน้ำมีปัญหา ให้สลับสภาพแวดล้อมเป็น mock และทำงานต่อไป ผลิตภัณฑ์ยังคงจัดส่งได้แม้ว่า API ต้นน้ำจะหยุดทำงานก็ตาม
รูปแบบนี้ไม่ได้เฉพาะเจาะจงกับ Ghostty หรือ AI แต่มันคือรูปแบบ API ที่ยืดหยุ่นซึ่งให้ผลตอบแทนกับทุกทีมที่นำไปใช้ก่อนที่จะจำเป็น โพสต์ของฮาชิโมโตะเป็นเครื่องเตือนใจล่าสุดว่าคุณควรนำไปใช้ก่อนที่คุณจะต้องการมัน ไม่ใช่หลังจากนั้น
สิ่งที่นักพัฒนากำลังอ่านจากประกาศ
ปฏิกิริยาในช่วง 48 ชั่วโมงแรกแบ่งออกได้เป็นหลายกลุ่ม
- กลุ่มที่คิดว่า “ดีแล้วสำหรับเขา”. ผู้ใช้ GitHub ระดับสูงที่รู้สึกไม่พอใจอย่างเงียบๆ มาหลายเดือน และมองว่าโพสต์นี้เป็นเหมือนการอนุญาตให้พวกเขาเผยแพร่ความไม่พอใจของตนเอง หลายคนในกลุ่มนี้ได้ทำมิเรอร์ไปยังแพลตฟอร์มที่สองอยู่แล้ว; โพสต์นี้ทำให้พวกเขาหันมาพิจารณาที่จะทำให้มิเรอร์นั้นเป็นแพลตฟอร์มหลัก
- กลุ่มที่ “นี่มันแค่ระบบล่มครั้งเดียว” ไม่เชื่อ. คนที่ชี้ให้เห็นว่าเวลาการทำงานโดยรวมของ GitHub นั้นแข่งขันได้กับมาตรฐานอุตสาหกรรม และแพลตฟอร์มขนาดใหญ่ใดๆ ก็มีวันที่ไม่ดีได้ พวกเขาไม่ได้ผิดในเรื่องตัวเลขภาพรวม แต่พวกเขามองข้ามประเด็นอนุพันธ์อันดับสอง: แนวโน้มต่างหาก ไม่ใช่ตัวเลขสัมบูรณ์ ที่เป็นสิ่งกระตุ้นฮาชิโมโตะ
- กลุ่ม “การย้ายออกจากแพลตฟอร์มเป็นเรื่องยาก เจอกันใหม่ในหกเดือน” ผู้ปฏิบัติ. วิศวกรที่เคยทำการย้ายแพลตฟอร์มและรู้ว่าตัวติดตามปัญหา ประวัติ PR และพื้นที่ผิว CI คือที่อยู่ของต้นทุนการย้ายข้อมูล พวกเขาพูดถูก และแผน “การย้ายแบบค่อยเป็นค่อยไป พร้อมมิเรอร์แบบอ่านอย่างเดียว” ของฮาชิโมโตะเป็นรูปแบบที่เหมาะสมสำหรับข้อจำกัดนั้น
- กลุ่มที่กังวล “แล้ว repos ของฉันล่ะ”. ผู้ดูแลโครงการขนาดเล็กสงสัยว่าโครงการของตนมีความเสี่ยงเดียวกันหรือไม่ คำตอบคือ ใช่ในด้านรูปแบบ ไม่ใช่ในด้านขนาด การหยุดทำงานที่ทำให้ฮาชิโมโตะเสียรายได้หนึ่งวันที่ HashiCorp เป็นเพียงความไม่สะดวกเล็กน้อยสำหรับโครงการช่วงวันหยุดสุดสัปดาห์ การคำนวณการย้ายข้อมูลของคุณจะแตกต่างออกไป
ปฏิกิริยาที่สำคัญไม่ได้อยู่บนโซเชียลมีเดีย แต่อยู่ภายในองค์กรวิศวกรรมที่เลือก GitHub เป็นฐานสำหรับทุกสิ่งที่พวกเขาจัดส่ง การสนทนากำลังเกิดขึ้นบน Slack ในตอนนี้: เราจะลดความเสี่ยงนี้ได้อย่างไร นโยบายภายในของเราเกี่ยวกับการทำมิเรอร์ไปยังแพลตฟอร์มที่สองเป็นอย่างไร และแผนการออกจากแพลตฟอร์มคืออะไร?
ข้อคิดเชิงปฏิบัติสำหรับระบบของคุณเอง
รายการตรวจสอบสั้นๆ ที่เป็นความคิดเห็นส่วนตัว:
- ทำมิเรอร์ repository ที่ใช้งานอยู่ของคุณไปยังแพลตฟอร์มที่สองทุกสัปดาห์ Forgejo และ Codeberg ฟรีสำหรับโอเพนซอร์ส ต้นทุนคือหนึ่งงาน CI; คุณค่าคือการนอนหลับได้อย่างสบายตลอดช่วงเวลาที่ระบบล่มสี่ชั่วโมงครั้งถัดไป
- ตรึงการพึ่งพา หากคุณจัดส่งเครื่องมือสำหรับนักพัฒนาที่เรียกใช้ GitHub APIs ให้ถือว่าไคลเอ็นต์ GitHub เป็นอะแดปเตอร์ที่สามารถสลับเปลี่ยนได้ ไม่ใช่การนำเข้าแบบตายตัว เพิ่มอะแดปเตอร์ Forgejo หรือ GitLab ที่อยู่เบื้องหลังอินเทอร์เฟซเดียวกัน
- จัดทำเอกสารการย้อนกลับด้วยตนเอง เมื่อไปป์ไลน์การเผยแพร่แบบอัตโนมัติไม่สามารถทำงานได้ เส้นทางด้วยตนเองคืออะไร? หากไม่มีเอกสารกำกับ คำตอบคือ “เราไม่สามารถเผยแพร่ได้” และคำตอบนั้นเป็นสิ่งที่ยอมรับไม่ได้สำหรับเครื่องมือใดๆ ที่มีลูกค้าที่ต้องชำระเงิน
- ตรวจสอบสิ่งที่คุณพึ่งพา ระบุบริการภายนอกทุกอย่างที่อยู่ในเส้นทางวิกฤต สำหรับแต่ละบริการ ให้เขียนคำตอบของคำถามว่า “เราจะทำอย่างไรหากบริการนี้หยุดทำงานเป็นเวลาสี่ชั่วโมง?” นำเสนอช่องว่างที่พบต่อผู้บริหาร
- เฝ้าระวังอนุพันธ์อันดับสอง หากความถี่ของเหตุการณ์เพิ่มขึ้นทุกเดือน แม้ในบริการที่ยังคงเป็นไปตาม SLA ก็ตาม ให้วางแผนการย้ายข้อมูลก่อนที่จะถูกบังคับ
สำหรับตัวอย่างการใช้งานเฉพาะด้านเครื่องมือ API โพสต์เรื่อง การสร้างเวิร์กโฟลว์ที่ทนทานต่อการหยุดทำงานของผู้ให้บริการ อธิบายรูปแบบเดียวกันนี้พร้อมโค้ด โดยใช้ DeepSeek และ OpenAI เป็นตัวอย่างของผู้ให้บริการสองราย รูปแบบอาจเปลี่ยนไป แต่หลักการยังคงเดิม
คำถามที่พบบ่อย
- Ghostty จะย้ายไปที่ใด? ฮาชิโมโตะไม่ได้ระบุปลายทางที่ชัดเจนในโพสต์ประกาศ เขากล่าวว่าการหารือกำลังดำเนินอยู่กับผู้ให้บริการหลายราย ทั้งเชิงพาณิชย์และ FOSS และการย้ายข้อมูลจะดำเนินการทีละน้อย ไม่ใช่การเปลี่ยนในครั้งเดียว GitHub repository ปัจจุบันของ Ghostty จะยังคงเป็นเวอร์ชันอ่านอย่างเดียว เพื่อให้โคลน ลิงก์ และการอ้างอิงที่มีอยู่ยังคงใช้งานได้
- GitHub ไม่น่าเชื่อถือขนาดนั้นเลยหรือ? ตัวเลขเวลาทำงานที่ประกาศของ GitHub นั้นแข่งขันได้กับแพลตฟอร์มคู่แข่ง แต่แพลตฟอร์มนี้มีเหตุการณ์ระบบล่มที่ยาวนานหลายครั้งในปี 2025 และ 2026 ซึ่งส่งผลกระทบต่อ Actions, Packages และ API คำร้องเรียนของฮาชิโมโตะคือรูปแบบของการล่มบางส่วน แม้แต่ละครั้งจะสั้น แต่ก็สะสมเป็นชั่วโมงการทำงานที่สูญเสียไปหลายชั่วโมงต่อสัปดาห์สำหรับผู้ใช้ที่อยู่ในเส้นทางวิกฤต
- ฉันควรย้าย repos ออกจาก GitHub ตอนนี้เลยหรือไม่? การทำมิเรอร์แทบจะคุ้มค่าอย่างแน่นอน งาน CI รายสัปดาห์ที่ผลักไปยังแพลตฟอร์มที่สองแทบไม่มีค่าใช้จ่าย และให้การสำรองข้อมูลที่ใช้งานได้ในครั้งต่อไปที่ GitHub Actions หยุดทำงานเป็นเวลาสองสามชั่วโมง การที่คุณจะทำให้แพลตฟอร์มที่สองเป็นแพลตฟอร์มหลักหรือไม่นั้นขึ้นอยู่กับความอดทนของคุณต่อต้นทุนการย้ายข้อมูลเกี่ยวกับปัญหา ประวัติ PR และการกำหนดค่า CI สำหรับทีมส่วนใหญ่ ต้นทุนนั้นยังไม่ได้รับการพิสูจน์ความคุ้มค่าจากช่องว่างด้านความน่าเชื่อถือ
- สิ่งนี้ส่งผลต่อการใช้งาน GitHub Copilot หรือ GitHub Actions ของฉันหรือไม่? โพสต์ของฮาชิโมโตะไม่ได้กล่าวถึงผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งโดยเฉพาะ แม้ว่าการล่มของ Actions ในวันที่มีการโพสต์จะเป็นตัวกระตุ้นทันที Copilot เป็นพื้นผิวผลิตภัณฑ์ที่แยกต่างหากจากแพลตฟอร์ม; ความน่าเชื่อถือของมันถูกติดตามแยกต่างหาก หากทีมของคุณใช้ GitHub Copilot การเปลี่ยนแปลงการเรียกเก็บเงินที่เกี่ยวข้องจะถูกบันทึกไว้ใน การใช้งานและ API การเรียกเก็บเงินของ GitHub Copilot สำหรับทีม
- สิ่งนี้หมายความว่าอย่างไรสำหรับเครื่องมือสำหรับนักพัฒนาในยุค AI ที่พึ่งพา GitHub APIs? เครื่องมือที่ครอบคลุม GitHub API (บอทตรวจสอบ, การคัดแยกปัญหา, เซิร์ฟเวอร์ MCP) จะได้รับโปรไฟล์ความน่าเชื่อถือของ GitHub โดยโครงสร้าง การลดผลกระทบก็เหมือนกับการพึ่งพาบุคคลที่สาม: ใช้แคชอย่างจริงจัง, อนุญาตให้ทำงานต่อเมื่อเกิดข้อผิดพลาด, และจำลองระบบต้นน้ำในชุดทดสอบของคุณ รูปแบบเซิร์ฟเวอร์จำลอง Apidog เป็นวิธีที่ประหยัดในการทำเช่นนี้; บทความเกี่ยวกับบอทคัดแยก Clawsweeper ครอบคลุมตัวอย่างที่ใช้งานได้จริง
- นี่เป็นแนวโน้ม “ออกจาก GitHub” หรือเป็นเหตุการณ์ครั้งเดียว? น่าจะเป็นจุดเริ่มต้นของแนวโน้ม แต่เป็นแนวโน้มที่ช้า การย้ายโครงการที่ไม่เล็กน้อยออกจาก GitHub เป็นโครงการที่ใช้เวลาหลายสัปดาห์ มีไม่กี่ทีมที่ทำเพื่อความสนุก สัญญาณในโพสต์ของฮาชิโมโตะคือการแลกเปลี่ยนได้เปลี่ยนไปมากพอที่ผู้ใช้รายหนึ่งที่ใช้งานแพลตฟอร์มมานานที่สุดตัดสินใจว่าต้นทุนการย้ายข้อมูลนั้นคุ้มค่าที่จะจ่าย โครงการที่มีชื่อเสียงอื่นๆ มีแนวโน้มที่จะตามมาในอีก 12 เดือนข้างหน้า
- “ผู้สร้างเครื่องมือสำหรับนักพัฒนา” ในบริบทนี้หมายถึงอะไร? ใครก็ตามที่จัดส่งซอฟต์แวร์ที่นักพัฒนาคนอื่นใช้เป็นส่วนหนึ่งของเวิร์กโฟลว์ประจำวัน ซึ่งรวมถึงกรณีที่ชัดเจน เช่น เทอร์มินัล, ตัวแก้ไขโค้ด และ CI runners; นอกจากนี้ยังรวมถึงไคลเอ็นต์ API, เครื่องมือตรวจสอบ, registries แพ็กเกจ และผู้ช่วยเขียนโค้ด AI หากลูกค้าของคุณคือนักพัฒนา และเครื่องมือของคุณอยู่ระหว่างพวกเขากับการจัดส่ง คุณคือผู้สร้างเครื่องมือสำหรับนักพัฒนา และบทเรียนด้านความน่าเชื่อถือจากโพสต์ของฮาชิโมโตะก็สามารถนำไปใช้ได้โดยตรง