minsuchae 2025-12-06 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) ขอเสริมไว้เป็นข้อมูลว่า ครั้งก่อนที่ล่มคือทุกที่ที่ใช้ Cloudflare CDN ล่มกันหมด ดังนั้นในมุมนี้จึงต้องดูว่า ล่มทั้งระบบหรือว่าล่มแค่บางส่วนในนั้น minsuchae 2025-12-06 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) ผมเข้าใจผู้เขียนโพสต์ต้นฉบับนะ แต่ไม่เข้าใจว่าทำไมบางคนถึงประชดประชันกันแบบไม่มีหลักฐานรองรับ ที่นี่เป็นคอมมูนิตี้สายพัฒนาที่เหลืออยู่ไม่กี่แห่งและยังรักษามารยาทกันได้อย่างดีด้วย ผมได้เปิดเผยรายละเอียดโดยรวมเพิ่มเติมผ่านการอัปเดตในโพสต์แรกที่เขียนไว้แล้ว มีผู้ใช้บางส่วน (28% ของทราฟฟิกทั้งหมด) ได้รับผลกระทบ และระบุว่าสาเหตุเกิดขึ้นระหว่างความพยายามป้องกันช่องโหว่ของ React Server Components ถ้าเป็นนักพัฒนา ไม่ใช่แค่เขียนโค้ดอย่างเดียว แต่เวลาวิเคราะห์สาเหตุหรือออกแบบลอจิก ก็ควรทำอย่างมีเหตุมีผล หรืออย่างน้อยก็ต้องสามารถแสดงหลักฐานที่ชัดเจนได้ไม่ใช่หรือครับ เหตุผลที่ผมเขียนคอมเมนต์แรกแบบนั้นก็เพราะหลังจากตรวจสอบตอนที่โพสต์นี้ถูกเขียนแล้ว เซิร์ฟเวอร์ที่ผมดูแลอยู่ใช้ CDN แต่ไม่พบความผิดปกติ มีประกาศอย่างเป็นทางการว่ามีข้อผิดพลาดที่ API และแดชบอร์ด แบบนั้นถือว่าเป็นข้อมูลที่ผิดหรือครับ เมื่อเป็นข้อผิดพลาดของแดชบอร์ด ก็เป็นธรรมดาที่อาจเกิดปัญหากับ Cloudflare ได้ และ DownDetector เองก็จัดการเป็นปัญหาที่เกี่ยวข้องกับ Cloudflare จึงอาจมีการรายงานเหตุขัดข้องได้ (แต่เดิมครั้งก่อนก็เคยล่มมาแล้ว) ไม่ใช่แบบนั้นหรือครับ? แทนที่จะมองแค่ว่าถูกหรือผิด การเข้าใจเหตุผลที่ชัดเจนน่าจะสำคัญกว่าไม่ใช่หรือครับ? https://blog.cloudflare.com/5-december-2025-outage/ redmi 2025-12-06 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) Cloudflare โพสต์ในบล็อกว่าทราฟฟิก HTTP 28% ตอบกลับเป็น 500 ฝั่งผมเองก็เจอข้อผิดพลาด Cloudflare 500 ในบริการโปรดักชันเหมือนกัน grenade 2025-12-05 | ความคิดเห็นหลัก | ใน: AI กำลังเปลี่ยนวิธีทำงานที่ Anthropic อย่างไร (anthropic.com) ผมเห็นด้วยมากทีเดียวกับส่วนที่บอกว่าในบทความ AI ช่วยเรื่องการแก้ปัญหาจุกจิกเล็ก ๆ น้อย ๆ ได้ แทนที่จะให้มันรับงานชิ้นใหญ่ ดูเหมือนว่าผมจะได้ความช่วยเหลือจาก AI เยอะมากเวลาเพิ่มฟีเจอร์อำนวยความสะดวกเล็ก ๆ งานเขียนสคริปต์ รีแฟกเตอร์ริง และงานที่น่ารำคาญแต่ถ้าทำไว้ล่วงหน้าจะสบายขึ้นในภายหลัง minsuchae 2025-12-05 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) https://www.cloudflarestatus.com/incidents/k9ppxftx8bs5 ดูเหมือนว่าจะมีอีกปัญหาหนึ่งตามมาติด ๆ ด้วยนะครับ น่าเสียดายที่ไม่มีทางเลือกอื่น. superwoou 2025-12-05 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) แม้แต่ Orange Cloud ที่ไม่เกี่ยวกับ API ก็ขัดข้องครั้งใหญ่เช่นกัน Notion, LinkedIn และอื่น ๆ คุณเป็นคนเขียนข้อมูลที่ไม่ถูกต้องไว้ในคอมเมนต์เอง minsuchae 2025-12-05 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) ข่าวนั้นพูดถึงข้อเท็จจริงเพียงบางส่วน แต่เป็นบทความที่ชวนให้ผู้อ่านสับสน เพราะพาไปยังลิงก์ของเหตุการณ์ในอดีต ผมไม่ได้ปฏิเสธทุกอย่าง แต่ปฏิเสธแค่ข้ออ้างที่ว่า "ล่มไปทั้งหมด" เท่านั้น ถ้าดูจากการกู้คืนบน Downdetector จริง ๆ จะเห็นว่า Cloudflare ยังมีบันทึกการล่มคงอยู่ แต่ถ้าเลื่อนลงไปด้านล่างจะเห็นว่า Roblox หรือ Instagram ไม่ได้รับผลกระทบ ผมเลยพูดแบบนั้นเท่านั้น ถ้าจะไม่เชื่อข้อมูลทางการของ Cloudflare ก็ช่วยไม่ได้ครับ พวกเขาอาจจะโกหกก็ได้ แต่สิ่งที่ผมต้องการจะพูดคือ ไม่ว่าจะใช้ Cloudflare API ผ่านไลบรารีหรือเรียกใช้โดยตรง สิ่งที่ได้รับผลกระทบก็คือตรงส่วนนั้นที่ล่ม เท่านั้นเอง ตามข้อมูลทางการครับ นี่ไม่ใช่คอมเมนต์ที่เขียนมาเพื่อจะทะเลาะกันครับ gpdir16 2025-12-05 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) มีระบุไว้แค่ว่าเป็นแดชบอร์ดกับ API แต่ก่อนหน้านี้เข้า Claude, เว็บไซต์ Cloudflare, เว็บไซต์ของผม และ Downdetector ไม่ได้ทั้งหมด ตอนนี้น่าจะกู้คืนแล้ว เพราะตอนนี้เข้าใช้งานได้ตามปกติทั้งหมด ลองดูข่าวครับ https://independent.co.uk/tech/… minsuchae 2025-12-05 | ความคิดเห็นหลัก | ใน: Cloudflare ล่มอีกครั้ง (cloudflarestatus.com) คราวนี้ไม่ได้ล่มทั้งหมด ดูเหมือนว่าฝั่งที่ใช้ Cloudflare API กับ Cloudflare Dashboard จะล่มครับ https://www.cloudflarestatus.com/incidents/lfrm31y6sw9q bakyeono 2025-12-05 | ความคิดเห็นหลัก | ใน: ทีมพัฒนาของ Helldivers 2 ลดขนาดการติดตั้งจาก 154GB เหลือ 23GB (tomshardware.com) น่าอนาถอยู่เหมือนกัน แต่ก็ยังดีที่แก้ไขแล้ว ดูเหมือนว่าจะมีกรณีแบบนี้อีกมาก เพียงแค่ยังไม่เป็นที่รู้จักเท่านั้น nayounsang1 2025-12-05 | ความคิดเห็นหลัก | ใน: ดาร์กแพตเทิร์นแรกของ LLM คือการประจบ (sycophancy) (seangoedecke.com) ประเด็นนี้โดนใจมากจริง ๆ jjw9512151 2025-12-05 | ความคิดเห็นหลัก | ใน: เหตุผลที่ผมหยุดใช้ JSON ใน API ของตัวเองแล้วเปลี่ยนมาใช้ Protobuf (aloisdeniel.com) เครื่องมือทุกอย่างก็เหมือนกัน ไม่มีอะไรที่ใช้ได้สารพัดอย่าง แต่ผมก็คิดว่า Protobuf เป็นเครื่องมือที่ดีมากพอครับ โดยเฉพาะตอนที่เคยต้องส่งข้อมูลปริมาณมากและมีความถี่สูง (20 ครั้งต่อวินาที) ไปยังหลายภาษา/ไคลเอนต์ในสภาพแวดล้อมแบบ embedded ตอนนั้นใช้ nanopb ได้อย่างเรียบร้อยมากครับ ifmkl 2025-12-05 | ความคิดเห็นหลัก | ใน: เหตุผลที่ผมหยุดใช้ JSON ใน API ของตัวเองแล้วเปลี่ยนมาใช้ Protobuf (aloisdeniel.com) ถ้าเข้มงวดขนาดนั้น เดี๋ยวก็กลายเป็นส่งมาแบบ XML ใช่ไหมครับ 555 colus001 2025-12-05 | ความคิดเห็นหลัก | ใน: AI กำลังเปลี่ยนวิธีทำงานที่ Anthropic อย่างไร (anthropic.com) ก็เป็นกาแฟที่ร้านผมชงเอง จะขายก็ต้องบอกว่าอร่อยสิครับ bakyeono 2025-12-05 | ความคิดเห็นหลัก | ใน: เหตุผลที่ผมหยุดใช้ JSON ใน API ของตัวเองแล้วเปลี่ยนมาใช้ Protobuf (aloisdeniel.com) รูปแบบไบนารีในอุดมคติที่ผมอยากได้คือเป็นแบบอิงสคีมาและในขณะเดียวกันก็มีสคีมารวมอยู่ในข้อความด้วย แบบนี้ก็จะอ่านได้ทันทีผ่านปลั๊กอิน vim ถ้าต้องจัดการอ็อบเจ็กต์หลายล้านชิ้น การแนบสคีมาขนาด 1KB ไปกับข้อความขนาด 2GB ก็ไม่ใช่ภาระใหญ่แต่อย่างใด แต่ในบริการเว็บกลับมักมีกรณีที่สคีมามีขนาด 200KB แต่ข้อความมีแค่ 1KB ซึ่งในกรณีนี้จะไม่มีประสิทธิภาพ => ยังไงก็ต้องส่งสคีมาอย่างน้อย 1 ครั้งอยู่แล้วไม่ใช่หรือ? ต่อให้เป็น JSON ก็ไม่ได้แปลว่าไม่มีสคีมา เพียงแต่สคีมาถูกรวมอยู่ในข้อมูลแบบแฝง ๆ ดังนั้นจึงไม่ใช่ว่าไม่ได้ส่งสคีมาเสียทีเดียว กลับกัน มันยิ่งไม่มีประสิทธิภาพกว่าเพราะส่งสคีมาซ้ำในแต่ละรายการด้วยซ้ำ รูปแบบที่ "อิงสคีมาและในขณะเดียวกันก็มีสคีมารวมอยู่ในข้อความด้วย" ดูจะเป็นไอเดียที่ค่อนข้างดีเลยนะ kunggom 2025-12-05 | ความคิดเห็นหลัก | ใน: Starlink เริ่มให้บริการในเกาหลี (starlink.com) เป็นเนื้อหาที่ GeekNews เคยแนะนำไปแล้วครั้งหนึ่งครับ ดิจิทัลโบท็อกซ์! สนุกกับดิจิทัลโบท็อกซ์ในมองโกเลียด้วย Starlink Mini (รวมประสบการณ์ใช้งานในเกาหลี) (tech.ssut.me) semjei 2025-12-05 | ความคิดเห็นหลัก | ใน: Starlink เริ่มให้บริการในเกาหลี (starlink.com) อา.. อย่างนั้นเหรอครับ? ผมยังไม่เคยลองแพ็กเกจโรมมิ่งเลยครับ เคยเห็นคนใช้แบบโรมมิ่งอยู่ในอเมริกาใต้ แต่คนนั้นยังไม่ได้ออกจากทวีปอเมริกาใต้เลย... คงต้องลองไปดูสักหน่อยแล้วครับ ขอบคุณสำหรับข้อมูลเพิ่มเติมครับ kunggom 2025-12-05 | ความคิดเห็นหลัก | ใน: Starlink เริ่มให้บริการในเกาหลี (starlink.com) เท่าที่ผมได้ยินมา Starlink จะรับส่งทราฟฟิกทั้งหมดผ่าน PoP ที่สังกัดกับภูมิภาคที่สมัครใช้งานครั้งแรกเท่านั้น ไม่ว่าจะนำไปใช้ที่ไหนในโลกก็ตาม ดังนั้นถ้าผมเข้าใจถูก Starlink ที่สมัครในเกาหลี เมื่อนำไปใช้ที่ไหนในโลกก็น่าจะแสดงหน้าเว็บไซต์แจ้งเตือนของรัฐบาลเกาหลี princox 2025-12-05 | ความคิดเห็นหลัก | ใน: พบช่องโหว่มูลค่า $2,418 ด้วยพรอมป์ตราคา $5 (new-blog.ch4n3.kr) เป็นกรณีศึกษาที่ดีมากจนถึงขั้นสามารถนำไปอ้างอิงในสไลด์นำเสนอภายนอกได้เลย ควรเก็บไว้ครับ skageektp 2025-12-05 | ความคิดเห็นหลัก | ใน: คำพูดของผู้ก่อตั้งสื่อสารได้อย่างชัดเจนถึงทีมงานได้กี่เปอร์เซ็นต์กันแน่? (online.kru.community) ตั้งคำถามชวนสนใจไว้ในชื่อเรื่อง แต่ในเนื้อหาดันไม่มีคำตอบของคำถามนั้นเลย เลยโคตรหงุดหงิด โหลดความคิดเห็นเพิ่มเติม
ขอเสริมไว้เป็นข้อมูลว่า ครั้งก่อนที่ล่มคือทุกที่ที่ใช้ Cloudflare CDN ล่มกันหมด
ดังนั้นในมุมนี้จึงต้องดูว่า ล่มทั้งระบบหรือว่าล่มแค่บางส่วนในนั้น
ผมเข้าใจผู้เขียนโพสต์ต้นฉบับนะ แต่ไม่เข้าใจว่าทำไมบางคนถึงประชดประชันกันแบบไม่มีหลักฐานรองรับ
ที่นี่เป็นคอมมูนิตี้สายพัฒนาที่เหลืออยู่ไม่กี่แห่งและยังรักษามารยาทกันได้อย่างดีด้วย
ผมได้เปิดเผยรายละเอียดโดยรวมเพิ่มเติมผ่านการอัปเดตในโพสต์แรกที่เขียนไว้แล้ว
มีผู้ใช้บางส่วน (28% ของทราฟฟิกทั้งหมด) ได้รับผลกระทบ และระบุว่าสาเหตุเกิดขึ้นระหว่างความพยายามป้องกันช่องโหว่ของ React Server Components
ถ้าเป็นนักพัฒนา ไม่ใช่แค่เขียนโค้ดอย่างเดียว แต่เวลาวิเคราะห์สาเหตุหรือออกแบบลอจิก ก็ควรทำอย่างมีเหตุมีผล หรืออย่างน้อยก็ต้องสามารถแสดงหลักฐานที่ชัดเจนได้ไม่ใช่หรือครับ
เหตุผลที่ผมเขียนคอมเมนต์แรกแบบนั้นก็เพราะหลังจากตรวจสอบตอนที่โพสต์นี้ถูกเขียนแล้ว เซิร์ฟเวอร์ที่ผมดูแลอยู่ใช้ CDN แต่ไม่พบความผิดปกติ
มีประกาศอย่างเป็นทางการว่ามีข้อผิดพลาดที่ API และแดชบอร์ด แบบนั้นถือว่าเป็นข้อมูลที่ผิดหรือครับ
เมื่อเป็นข้อผิดพลาดของแดชบอร์ด ก็เป็นธรรมดาที่อาจเกิดปัญหากับ Cloudflare ได้ และ DownDetector เองก็จัดการเป็นปัญหาที่เกี่ยวข้องกับ Cloudflare จึงอาจมีการรายงานเหตุขัดข้องได้ (แต่เดิมครั้งก่อนก็เคยล่มมาแล้ว) ไม่ใช่แบบนั้นหรือครับ?
แทนที่จะมองแค่ว่าถูกหรือผิด การเข้าใจเหตุผลที่ชัดเจนน่าจะสำคัญกว่าไม่ใช่หรือครับ?
https://blog.cloudflare.com/5-december-2025-outage/
Cloudflare โพสต์ในบล็อกว่าทราฟฟิก HTTP 28% ตอบกลับเป็น 500
ฝั่งผมเองก็เจอข้อผิดพลาด Cloudflare 500 ในบริการโปรดักชันเหมือนกัน
ผมเห็นด้วยมากทีเดียวกับส่วนที่บอกว่าในบทความ AI ช่วยเรื่องการแก้ปัญหาจุกจิกเล็ก ๆ น้อย ๆ ได้
แทนที่จะให้มันรับงานชิ้นใหญ่ ดูเหมือนว่าผมจะได้ความช่วยเหลือจาก AI เยอะมากเวลาเพิ่มฟีเจอร์อำนวยความสะดวกเล็ก ๆ งานเขียนสคริปต์ รีแฟกเตอร์ริง และงานที่น่ารำคาญแต่ถ้าทำไว้ล่วงหน้าจะสบายขึ้นในภายหลัง
https://www.cloudflarestatus.com/incidents/k9ppxftx8bs5
ดูเหมือนว่าจะมีอีกปัญหาหนึ่งตามมาติด ๆ ด้วยนะครับ
น่าเสียดายที่ไม่มีทางเลือกอื่น.
แม้แต่ Orange Cloud ที่ไม่เกี่ยวกับ API ก็ขัดข้องครั้งใหญ่เช่นกัน
Notion, LinkedIn และอื่น ๆ
คุณเป็นคนเขียนข้อมูลที่ไม่ถูกต้องไว้ในคอมเมนต์เอง
ข่าวนั้นพูดถึงข้อเท็จจริงเพียงบางส่วน แต่เป็นบทความที่ชวนให้ผู้อ่านสับสน เพราะพาไปยังลิงก์ของเหตุการณ์ในอดีต
ผมไม่ได้ปฏิเสธทุกอย่าง แต่ปฏิเสธแค่ข้ออ้างที่ว่า "ล่มไปทั้งหมด" เท่านั้น
ถ้าดูจากการกู้คืนบน Downdetector จริง ๆ จะเห็นว่า Cloudflare ยังมีบันทึกการล่มคงอยู่ แต่ถ้าเลื่อนลงไปด้านล่างจะเห็นว่า Roblox หรือ Instagram ไม่ได้รับผลกระทบ ผมเลยพูดแบบนั้นเท่านั้น
ถ้าจะไม่เชื่อข้อมูลทางการของ Cloudflare ก็ช่วยไม่ได้ครับ
พวกเขาอาจจะโกหกก็ได้
แต่สิ่งที่ผมต้องการจะพูดคือ ไม่ว่าจะใช้ Cloudflare API ผ่านไลบรารีหรือเรียกใช้โดยตรง สิ่งที่ได้รับผลกระทบก็คือตรงส่วนนั้นที่ล่ม เท่านั้นเอง
ตามข้อมูลทางการครับ
นี่ไม่ใช่คอมเมนต์ที่เขียนมาเพื่อจะทะเลาะกันครับ
มีระบุไว้แค่ว่าเป็นแดชบอร์ดกับ API แต่ก่อนหน้านี้เข้า Claude, เว็บไซต์ Cloudflare, เว็บไซต์ของผม และ Downdetector ไม่ได้ทั้งหมด
ตอนนี้น่าจะกู้คืนแล้ว เพราะตอนนี้เข้าใช้งานได้ตามปกติทั้งหมด
ลองดูข่าวครับ
https://independent.co.uk/tech/…
คราวนี้ไม่ได้ล่มทั้งหมด ดูเหมือนว่าฝั่งที่ใช้ Cloudflare API กับ Cloudflare Dashboard จะล่มครับ
https://www.cloudflarestatus.com/incidents/lfrm31y6sw9q
น่าอนาถอยู่เหมือนกัน แต่ก็ยังดีที่แก้ไขแล้ว ดูเหมือนว่าจะมีกรณีแบบนี้อีกมาก เพียงแค่ยังไม่เป็นที่รู้จักเท่านั้น
ประเด็นนี้โดนใจมากจริง ๆ
เครื่องมือทุกอย่างก็เหมือนกัน ไม่มีอะไรที่ใช้ได้สารพัดอย่าง แต่ผมก็คิดว่า Protobuf เป็นเครื่องมือที่ดีมากพอครับ
โดยเฉพาะตอนที่เคยต้องส่งข้อมูลปริมาณมากและมีความถี่สูง (20 ครั้งต่อวินาที) ไปยังหลายภาษา/ไคลเอนต์ในสภาพแวดล้อมแบบ embedded ตอนนั้นใช้ nanopb ได้อย่างเรียบร้อยมากครับ
ถ้าเข้มงวดขนาดนั้น เดี๋ยวก็กลายเป็นส่งมาแบบ XML ใช่ไหมครับ 555
ก็เป็นกาแฟที่ร้านผมชงเอง จะขายก็ต้องบอกว่าอร่อยสิครับ
=> ยังไงก็ต้องส่งสคีมาอย่างน้อย 1 ครั้งอยู่แล้วไม่ใช่หรือ? ต่อให้เป็น JSON ก็ไม่ได้แปลว่าไม่มีสคีมา เพียงแต่สคีมาถูกรวมอยู่ในข้อมูลแบบแฝง ๆ ดังนั้นจึงไม่ใช่ว่าไม่ได้ส่งสคีมาเสียทีเดียว กลับกัน มันยิ่งไม่มีประสิทธิภาพกว่าเพราะส่งสคีมาซ้ำในแต่ละรายการด้วยซ้ำ รูปแบบที่ "อิงสคีมาและในขณะเดียวกันก็มีสคีมารวมอยู่ในข้อความด้วย" ดูจะเป็นไอเดียที่ค่อนข้างดีเลยนะ
เป็นเนื้อหาที่ GeekNews เคยแนะนำไปแล้วครั้งหนึ่งครับ ดิจิทัลโบท็อกซ์!
อา.. อย่างนั้นเหรอครับ? ผมยังไม่เคยลองแพ็กเกจโรมมิ่งเลยครับ
เคยเห็นคนใช้แบบโรมมิ่งอยู่ในอเมริกาใต้ แต่คนนั้นยังไม่ได้ออกจากทวีปอเมริกาใต้เลย...
คงต้องลองไปดูสักหน่อยแล้วครับ ขอบคุณสำหรับข้อมูลเพิ่มเติมครับ
เท่าที่ผมได้ยินมา Starlink จะรับส่งทราฟฟิกทั้งหมดผ่าน PoP ที่สังกัดกับภูมิภาคที่สมัครใช้งานครั้งแรกเท่านั้น ไม่ว่าจะนำไปใช้ที่ไหนในโลกก็ตาม
ดังนั้นถ้าผมเข้าใจถูก Starlink ที่สมัครในเกาหลี เมื่อนำไปใช้ที่ไหนในโลกก็น่าจะแสดงหน้าเว็บไซต์แจ้งเตือนของรัฐบาลเกาหลี
เป็นกรณีศึกษาที่ดีมากจนถึงขั้นสามารถนำไปอ้างอิงในสไลด์นำเสนอภายนอกได้เลย ควรเก็บไว้ครับ
ตั้งคำถามชวนสนใจไว้ในชื่อเรื่อง แต่ในเนื้อหาดันไม่มีคำตอบของคำถามนั้นเลย เลยโคตรหงุดหงิด