post mortems
1.0.0
Allegro เว็บไซต์อีคอมเมิร์ซลดลงหลังจากการจราจรติดขัดอย่างฉับพลันที่เกิดจากแคมเปญการตลาด การหยุดทำงานเกิดจากข้อผิดพลาดการกำหนดค่าในการจัดการทรัพยากรคลัสเตอร์ซึ่งป้องกันไม่ให้อินสแตนซ์บริการเริ่มต้นจากการเริ่มต้นแม้ว่าจะมีทรัพยากรฮาร์ดแวร์ก็ตาม
Cloudflare การกำหนดค่าที่ไม่ดี (กฎของเราเตอร์) ทำให้เราเตอร์ขอบทั้งหมดของพวกเขาล้มเหลวทำให้ CloudFlare ทั้งหมดลง
Cloudflare ในระหว่างการบำรุงรักษาเครือข่ายกระดูกสันหลังส่วนตัวของพวกเขาวิศวกรได้พิมพ์ผิดในการกำหนดค่าเครือข่าย Datacenter Atlanta ทำให้การรับส่งข้อมูลทั้งหมดมาจากอเมริกาและยุโรปที่ไหลไปยังศูนย์ข้อมูลเพียงอย่างเดียว
Cloudflare การสั่งซื้อที่ไม่ถูกต้องของคำนำหน้าโฆษณา BGP ที่ปิดใช้งานทำให้เกิดความผิดปกติใน 19 ดาต้าเซ็นเตอร์
Cloudflare การเปลี่ยนแปลงระบบแคชที่มีระดับของเราทำให้คำขอบางอย่างล้มเหลวสำหรับผู้ใช้ที่มีรหัสสถานะ 530 ผลกระทบนั้นดำเนินไปเป็นเวลาเกือบหกชั่วโมง เราประเมินว่าประมาณ 5% ของคำขอทั้งหมดล้มเหลวที่จุดสูงสุด เนื่องจากความซับซ้อนของระบบของเราและจุดบอดในการทดสอบของเราเราจึงไม่ได้เห็นสิ่งนี้เมื่อการเปลี่ยนแปลงถูกปล่อยไปสู่สภาพแวดล้อมการทดสอบของเรา
Cloudflare บริการ CloudFlare หลายแห่งไม่สามารถใช้งานได้เป็นเวลา 121 นาทีในวันที่ 24 มกราคม 2566 เนื่องจากข้อผิดพลาดในการปล่อยรหัสที่จัดการโทเค็นบริการ เหตุการณ์ที่เกิดขึ้นทำให้ผลิตภัณฑ์ CloudFlare หลากหลายรวมถึงแง่มุมต่าง ๆ ของแพลตฟอร์มคนงานของเราโซลูชันศูนย์ความน่าเชื่อถือของเราและฟังก์ชั่นการควบคุมระนาบในเครือข่ายการส่งเนื้อหาของเรา (CDN)
Cloudflare ในวันที่ 4 ตุลาคม 2566 CloudFlare ประสบปัญหาการแก้ปัญหา DNS เริ่มต้นเวลา 07:00 UTC และสิ้นสุดเวลา 11:00 UTC ผู้ใช้บางคนของ 1.1.1.1 หรือผลิตภัณฑ์เช่น Warp, Zero Trust หรือตัวแก้ไข DNS ของบุคคลที่สามซึ่งใช้ 1.1.1.1 อาจได้รับการตอบกลับ ServFail DNS สำหรับการสืบค้นที่ถูกต้อง เราเสียใจมากสำหรับการหยุดทำงานนี้ การหยุดทำงานนี้เป็นข้อผิดพลาดของซอฟต์แวร์ภายในและไม่ใช่ผลของการโจมตี ในบล็อกนี้เราจะพูดถึงความล้มเหลวทำไมมันเกิดขึ้นและสิ่งที่เรากำลังทำเพื่อให้แน่ใจว่าสิ่งนี้จะไม่เกิดขึ้นอีก
Datadog การกำหนดค่าการค้นพบบริการที่ไม่ดีในหนึ่งในลูกค้าที่นำการค้นพบบริการลงไปทั่วโลกเมื่อลูกค้าที่พึ่งพาได้ลดลง
enom เมื่อวันที่ 15 มกราคม 2565 เวลา 9:00 น. ET ทีมวิศวกรรมของ Tucows เริ่มวางแผนการบำรุงรักษาเพื่อโยกย้ายแพลตฟอร์ม Enom ไปยังโครงสร้างพื้นฐานคลาวด์ใหม่ เนื่องจากความซับซ้อนของการลัดเยียดทีมพบปัญหามากมายทำให้เกิดความล่าช้าอย่างต่อเนื่อง หน้าต่างการบำรุงรักษาถูกขยายออกไปหลายครั้งเพื่อแก้ไขปัญหาที่เกี่ยวข้องกับการจำลองข้อมูลการกำหนดเส้นทางเครือข่ายและปัญหาการแก้ปัญหา DNS ส่งผลกระทบต่อการเข้าถึงเว็บไซต์และการส่งอีเมล
Etsy การส่งทราฟฟิกแบบมัลติคาสต์โดยไม่ต้องกำหนดค่าสวิตช์อย่างถูกต้องทำให้เกิดการหยุดทำงานทั่วโลก ETSY
Facebook. การเปลี่ยนแปลงการกำหนดค่าเป็นเราเตอร์กระดูกสันหลังของ Facebook ทำให้เกิดการหยุดทำงานทั่วโลกของคุณสมบัติ Facebook และเครื่องมือภายในทั้งหมด
Facebook. การกำหนดค่าที่ไม่ดีทำให้ทั้ง Facebook และ Instagram
Firefox เมื่อวันที่ 13 มกราคม 2565 เส้นทางรหัสเฉพาะในสแต็กเครือข่ายของ Firefox ทำให้เกิดปัญหาในการใช้งานโปรโตคอล HTTP/3 การสื่อสารเครือข่ายที่ถูกบล็อกนี้และทำให้ Firefox ไม่ตอบสนองไม่สามารถโหลดเนื้อหาเว็บได้เกือบสองชั่วโมง
GoCardless การกำหนดค่าที่ไม่ดีรวมกับชุดความล้มเหลวที่ผิดปกตินำไปสู่การหยุดทำงานของคลัสเตอร์ฐานข้อมูลโดยใช้ API และแดชบอร์ดออฟไลน์
[Google] (https://cloud.google.com/blog/products/infastructure/details-of-google-cloud-gcve-incident) การจัดเตรียม GCVE เริ่มต้นดำเนินการด้วยตัวเลือกมรดกซึ่งนำไปสู่สัญญา 'คำคงที่' ด้วยการลบอัตโนมัติในตอนท้ายของช่วงเวลานั้น
Google. การกำหนดค่าที่ไม่ดี (Autogenerated) ลบบล็อก IP ของ Google Compute ทั้งหมดจากการประกาศ BGP
Google. การกำหนดค่าที่ไม่ดี (Autogenerated) ได้ลงบริการ Google ส่วนใหญ่
Google. การกำหนดค่าที่ไม่ดีทำให้บริการโควต้าล้มเหลวซึ่งทำให้บริการหลายรายการล้มเหลว (รวมถึง Gmail)
Google. / ถูกตรวจสอบในบัญชีดำ URL ทำให้ URL ทุกตัวแสดงคำเตือน
Google. ข้อผิดพลาดในการกำหนดค่าการเปิดตัวไปยังตัวโหลดบาลานซ์นำไปสู่อัตราความผิดพลาดที่เพิ่มขึ้นเป็นเวลา 22 นาที
Google. การเปลี่ยนแปลงการกำหนดค่ามีวัตถุประสงค์เพื่อจัดการกับความต้องการที่เก็บข้อมูลเมตาดาต้าซึ่งมีบางส่วนของระบบการค้นหา Blob ซึ่งทำให้เกิดความล้มเหลวในการเรียงซ้อนกับผลกระทบการบริการที่มองเห็นได้จากผู้ใช้ Gmail, Google Photos, Google Drive และบริการ GCP อื่น ๆ ขึ้นอยู่กับการจัดเก็บ BLOB
Google. การกำหนดความผิดพลาดสองครั้งรวมถึงข้อผิดพลาดซอฟต์แวร์ทำให้เกิดความล้มเหลวของเครือข่าย Google Cloud ขนาดใหญ่บนชายฝั่งตะวันออกของสหรัฐอเมริกา
Google. บริการโหลดบาลานซ์ส่วนหน้าของ Google ประสบความล้มเหลวส่งผลกระทบต่อบริการ Google Cloud หลายสายในยุโรป จากการวิเคราะห์เบื้องต้นสาเหตุที่แท้จริงของปัญหาเกิดจากคุณลักษณะโครงสร้างพื้นฐานใหม่ที่ก่อให้เกิดปัญหาแฝงภายในรหัสโหลดบาลานซ์เครือข่ายภายใน
Google. Google Cloud Networking ปัญหาที่มีประสบการณ์ด้วยบริการ Google Cloud Load Balancing (GCLB) ส่งผลกระทบต่อบริการ Google Cloud หลายระบบ ลูกค้าที่ได้รับผลกระทบสังเกตข้อผิดพลาดของ Google 404 บนเว็บไซต์ของพวกเขา จากการวิเคราะห์เบื้องต้นสาเหตุของปัญหาคือข้อผิดพลาดแฝงในบริการการกำหนดค่าเครือข่ายซึ่งถูกกระตุ้นในระหว่างการทำงานของระบบตามปกติ
Google. Google Cloud Networking มีประสบการณ์ลดลงสำหรับการรับส่งข้อมูลที่มีลำดับความสำคัญต่ำกว่าเช่นแบทช์การสตรีมและการถ่ายโอนการดำเนินงานตั้งแต่ 19:30 น. สหรัฐ/แปซิฟิกในวันพฤหัสบดีที่ 14 กรกฎาคม 2565 ถึง 15:02 สหรัฐอเมริกา/แปซิฟิกในวันศุกร์ที่ 15 กรกฎาคม 2565 การหยุดชะงักของบริการนี้เป็นผลมาจากปัญหาที่พบในระหว่างการรวมกันของงานซ่อมและการเปิดตัวซอฟต์แวร์เครือข่ายประจำ เนื่องจากลักษณะของความสามารถในการหยุดชะงักและความยืดหยุ่นของผลิตภัณฑ์ของ Google Cloud ภูมิภาคที่ได้รับผลกระทบและ Windows ผลกระทบของแต่ละบุคคลนั้นแตกต่างกันอย่างมาก
Heroku การเปลี่ยนแปลงการกำหนดค่าระยะไกลอัตโนมัติไม่ได้เผยแพร่อย่างสมบูรณ์ ไม่สามารถเริ่มต้นเว็บได้
Heroku กระบวนการปรับใช้ที่ไม่ถูกต้องทำให้ตัวแปรกำหนดค่าใหม่ไม่ควรใช้เมื่อรหัสต้องการ
Keepthescore วิศวกรลบฐานข้อมูลการผลิตโดยบังเอิญ ฐานข้อมูลเป็นฐานข้อมูลที่ได้รับการจัดการจาก DigitalOcean พร้อมการสำรองข้อมูลวันละครั้ง 30 นาทีหลังจากหายนะมันกลับมาออนไลน์ แต่ข้อมูลกระดานคะแนน 7 ชั่วโมงหายไปตลอดกาล
Microsoft การกำหนดค่าที่ไม่ดีลงที่เก็บ Azure
NPM การเปลี่ยนแปลงการกำหนดค่าอย่างรวดเร็วทำให้เกิดปัญหาการกำหนดเส้นทางแบ็กเอนด์ เพื่อให้แน่นอนปัญหาคือเรากำลังตั้งค่า req.backend ในฟังก์ชัน vcl_fetch จากนั้นเรียกรีสตาร์ทเพื่อเปลี่ยนกฎใหม่ อย่างไรก็ตามการเรียกรีสตาร์ทจะรีเซ็ต req.backend เป็นรายการแรกที่ได้รับการสนับสนุนในรายการซึ่งในกรณีนี้เกิดขึ้นเป็น Manta แทนที่จะเป็นเซิร์ฟเวอร์ CouchDB ที่สมดุล
Owasa การกดปุ่มที่ไม่ถูกต้องนำไปสู่โรงบำบัดน้ำที่ปิดตัวลงเนื่องจากฟลูออไรด์ในระดับสูงเกินไป
Pagerduty ในวันที่ 15 ธันวาคม 2564 เวลา 00:17 UTC เราได้ปรับใช้การเปลี่ยนแปลงการกำหนดค่า DNS ในโครงสร้างพื้นฐานของ Pagerduty ที่ส่งผลกระทบต่อคลัสเตอร์การประสานคอนเทนเนอร์ของเรา การเปลี่ยนแปลงนี้มีข้อบกพร่องที่เราไม่ได้ตรวจพบในสภาพแวดล้อมการทดสอบของเราซึ่งทำให้บริการทั้งหมดทำงานในคลัสเตอร์คอนเทนเนอร์ orchestration ทันทีที่ไม่สามารถแก้ไข DNS ได้
Razorpay ความล้มเหลวของฮาร์ดแวร์ RDS เน้นการกำหนดค่า MySQL ที่ไม่ถูกต้องซึ่งส่งผลให้เกิดการสูญเสียข้อมูลครั้งใหญ่ในระบบการเงิน
Rust-lang ในวันพุธที่ 2023-01-25 เวลา 09:15 UTC เราได้ปรับใช้การเปลี่ยนแปลงโครงสร้างพื้นฐานการผลิตสำหรับ Crates.io ในระหว่างการปรับใช้บันทึก DNS สำหรับ Static.crates.io ไม่สามารถแก้ไขได้เป็นเวลาประมาณ 10-15 นาที มันเป็นเพราะความจริงที่ว่าทั้งใบรับรองและบันทึก DNS ถูกสร้างขึ้นอีกครั้งในระหว่างการหยุดทำงาน
Rust-lang เมื่อวันที่ 2023-07-20 ระหว่าง 12:17 ถึง 12:30 UTC ดาวน์โหลดลังทั้งหมดจาก Crates.io ถูกทำลายเนื่องจากการปรับใช้ที่มีข้อผิดพลาดในการสร้าง URL ดาวน์โหลด ในช่วงเวลานี้เรามีคำขอเฉลี่ย 4.71k ต่อวินาทีไปยัง Crates.io ส่งผลให้มีการร้องขอที่ล้มเหลวประมาณ 3.7 ล้านครั้งรวมถึงความพยายามลองอีกครั้งจากการขนส่งสินค้า
สแต็คล้น การกำหนดค่าไฟร์วอลล์ที่ไม่ดีปิดกั้น stackexchange/stackoverflow
ยาม การตั้งค่า Amazon S3 ที่ไม่ถูกต้องในการสำรองข้อมูลนำไปสู่การรั่วไหลของข้อมูล
Travisci ปัญหาการกำหนดค่า (การหมุนรหัสผ่านที่ไม่สมบูรณ์) นำไปสู่ "การรั่วไหล" VMs ซึ่งนำไปสู่เวลาสร้างคิวการสร้างที่สูงขึ้น
Travisci ปัญหาการกำหนดค่า (งานการทำความสะอาดภาพ VM ของ Google Compute Age Age Age) ทำให้ภาพ VM ฐานที่เสถียรถูกลบ
Travisci การเปลี่ยนแปลงการกำหนดค่าทำให้ Builds เริ่มล้มเหลว การย้อนกลับด้วยตนเองพัง
Travisci ตัวแปรสภาพแวดล้อมโดยไม่ตั้งใจทำการทดสอบลดฐานข้อมูลการผลิต
Tui. ก่อนที่จะมีการบินของเหตุการณ์ระบบการจองซึ่งมีการอัพเกรดแผ่นโหลด ความผิดพลาดในระบบทำให้ผู้โดยสารหญิงเช็คอินด้วยชื่อเรื่อง 'Miss' ถูกนับเป็นเด็ก ระบบจัดสรรน้ำหนักมาตรฐานของเด็ก 35 กิโลกรัมเมื่อเทียบกับน้ำหนักมาตรฐานหญิงที่ถูกต้อง 69 กิโลกรัม ดังนั้นเมื่อมีผู้หญิง 38 คนตรวจสอบอย่างไม่ถูกต้องและไม่ถูกต้องในฐานะเด็กมวลการบินขึ้นของ G-TAWG จากแผ่นโหลดอยู่ที่ 1,244 กิโลกรัมต่ำกว่ามวลที่เกิดขึ้นจริงของเครื่องบิน
Turso ตัวระบุการสำรองข้อมูล DB ที่กำหนดค่าไม่ถูกต้องนำไปสู่การรั่วไหลของข้อมูลสำหรับลูกค้าระดับฟรีและการแก้ไขที่ตามมาส่งผลให้เกิดการสูญเสียข้อมูลที่เป็นไปได้
วาล์ว. แม้ว่าจะไม่มีการชันสูตรศพอย่างเป็นทางการ แต่ดูเหมือนว่าการเชื่อมต่อ BGP ที่ไม่ดีจะตัดการเชื่อมต่อของวาล์วกับระดับ 3, Telia และ Abovenet/Zayo ซึ่งส่งผลให้เกิดการหยุดทำงานของไอน้ำทั่วโลก
อเมซอน เหตุการณ์ที่ไม่รู้จักทำให้หม้อแปลงล้มเหลว หนึ่งใน PLCs ที่ตรวจสอบว่าพลังเครื่องกำเนิดไฟฟ้าอยู่ในเฟสล้มเหลวด้วยเหตุผลที่ไม่ทราบสาเหตุซึ่งป้องกันไม่ให้ชุดเครื่องกำเนิดไฟฟ้าสำรองข้อมูลออนไลน์ สิ่งนี้ส่งผลกระทบต่อ EC2, EBS และ RDS ใน EU West
อเมซอน สภาพอากาศเลวร้ายทำให้เกิดความล้มเหลวของพลังงานตลอด AWS East East เครื่องกำเนิดไฟฟ้าสำรองข้อมูลเดียวล้มเหลวในการส่งพลังงานที่เสถียรเมื่อพลังงานสลับไปเป็นสำรองและโหลดเครื่องกำเนิดไฟฟ้า นี่คือแม้จะผ่านการทดสอบโหลดเมื่อสองเดือนก่อนและผ่านการทดสอบพลังงานทุกสัปดาห์
อเมซอน เวลา 22:25 น. PDT เมื่อวันที่ 4 มิถุนายนการสูญเสียพลังงานที่โรงงาน AWS ซิดนีย์อันเป็นผลมาจากสภาพอากาศที่รุนแรงในพื้นที่นั้นนำไปสู่การหยุดชะงักของอินสแตนซ์จำนวนมากในเขตว่าง เนื่องจากลายเซ็นของการสูญเสียพลังงานเบรกเกอร์แยกพลังงานไม่ได้มีส่วนร่วมส่งผลให้พลังงานสำรองสำรองที่ไหลลงสู่กริดพลังงานที่เสื่อมโทรม
Arpanet ข้อมูลการกำหนดเส้นทางที่ผิดปกติ (โปรเซสเซอร์ข้อความอินเตอร์เฟส) เสียหายข้อมูลการตรวจสอบซอฟต์แวร์ที่คำนวณได้ซ้ำการแพร่กระจายข้อมูลที่ไม่ดีด้วยการตรวจสอบที่ดีหมายเลขลำดับที่ไม่ถูกต้องทำให้บัฟเฟอร์เติมเต็มบัฟเฟอร์เต็มทำให้สูญเสียแพ็คเก็ตและโหนด จากปี 1980
Cloudflare สวิตช์บางส่วนที่ไม่เหมาะสมทำให้เกิดความล้มเหลวของไบเซนไทน์ซึ่งส่งผลกระทบต่อความพร้อมใช้งานของ API และแดชบอร์ดเป็นเวลาหกชั่วโมงและ 33 นาที
Cloudflare ความล้มเหลวของศูนย์ข้อมูลแบบยืดหยุ่น โพสต์นี้สรุปเหตุการณ์ที่ทำให้เกิดเหตุการณ์นี้
FirstEnergy / General Electric FirstEnergy มีความล้มเหลวในท้องถิ่นเมื่อมีการส่งสัญญาณบางสายเข้ามา กระบวนการปกติคือการปิดการเตือนภัยซึ่งทำให้ผู้ปฏิบัติงานของมนุษย์สามารถแจกจ่ายพลังงานได้อีกครั้ง แต่ระบบ GE ที่ตรวจสอบสิ่งนี้มีข้อผิดพลาดซึ่งป้องกันไม่ให้เกิดการเตือนภัยซึ่งในที่สุดก็ทำให้เกิดความล้มเหลวในที่สุดซึ่งส่งผลกระทบต่อผู้คน 55 ล้านคน
GitHub เมื่อวันที่ 28 มกราคม 2016 GitHub ประสบปัญหาการหยุดชะงักของอำนาจที่ศูนย์ข้อมูลหลักของพวกเขา
Google. การโจมตีด้วยฟ้าผ่าอย่างต่อเนื่องในดาต้าเซ็นเตอร์ยุโรป (Europe-West1-B) ทำให้สูญเสียพลังงานไปสู่ระบบการจัดเก็บเครื่องยนต์ของ Google ในภูมิภาคนั้น ข้อผิดพลาด I/O ถูกสังเกตในชุดย่อยของดิสก์แบบถาวรมาตรฐาน (HDDs) และการสูญเสียข้อมูลถาวรถูกพบในส่วนเล็ก ๆ ของเหล่านั้น
Google. เมื่อวันอังคารที่ 19 กรกฎาคม 2565 เวลา 06:33 น./มหาสมุทรแปซิฟิกความล้มเหลวพร้อมกันของระบบทำความเย็นที่ซ้ำซ้อนหลายครั้งในศูนย์ข้อมูลแห่งหนึ่งที่เป็นเจ้าภาพจัดงานโซนยุโรป-ตะวันตก 2-A ส่งผลกระทบต่อบริการของ Google Cloud หลายแห่ง สิ่งนี้ส่งผลให้ลูกค้าบางรายประสบกับบริการที่ไม่พร้อมใช้งานสำหรับผลิตภัณฑ์ที่ได้รับผลกระทบ
Pythonanywhere ความล้มเหลวของปริมาณการจัดเก็บข้อมูลบนเซิร์ฟเวอร์การจัดเก็บข้อมูลหนึ่งทำให้เกิดการหยุดทำงานจำนวนมากเริ่มต้นด้วยไซต์ Pythonanywhere และด้วยโปรแกรมของผู้ใช้ของเรา (รวมถึงเว็บไซต์) ที่ขึ้นอยู่กับปริมาณนั้นและต่อมาแพร่กระจายไปยังไซต์โฮสต์อื่น ๆ
ดวงอาทิตย์. ซันมีชื่อเสียงไม่ได้รวม ECC ในชิ้นส่วนเซิร์ฟเวอร์สองสามชั่วอายุคน สิ่งนี้ส่งผลให้ข้อมูลทุจริตและล่ม หลังจาก MO ทั่วไปของ Sun พวกเขาทำให้ลูกค้าที่รายงานข้อผิดพลาดลงนาม NDA ก่อนที่จะอธิบายปัญหา
เกม CCP การพิมพ์ผิดและความขัดแย้งชื่อทำให้ผู้ติดตั้งบางครั้งลบไฟล์ boot.ini ในการติดตั้งการขยายตัวสำหรับ อีฟออนไลน์ - ด้วยผลที่ตามมา
GitHub พาร์ติชันเครือข่าย 43 วินาทีในระหว่างการบำรุงรักษาทำให้ MySQL Master Failover แต่อาจารย์ใหม่ไม่ได้มีการเขียนหลายวินาทีที่เสนอให้กับมันเนื่องจากเวลาแฝงข้ามทวีป 24 ชั่วโมงของการฟื้นฟูงานเพื่อรักษาความสมบูรณ์ของข้อมูล
GoCardless การสืบค้นทั้งหมดบนตาราง postgreSQL ที่สำคัญถูกบล็อกโดยการรวมกันของการย้ายฐานข้อมูลที่รวดเร็วมากและการอ่านการอ่านระยะยาวทำให้เกิดการหยุดทำงาน 15 วินาที
Google. การเปลี่ยนแปลงจำนวนมากกับโหลดบาลานซ์ที่ได้รับการดัดแปลงไม่ค่อยถูกนำไปใช้ผ่านเส้นทางรหัสที่ช้ามาก การเปลี่ยนแปลงที่อยู่สาธารณะทั้งหมดนี้ทำให้เกิดการเปลี่ยนแปลงทั้งหมดเป็นเวลา ~ 2 ชั่วโมง
Google. ความล้มเหลวของส่วนประกอบบนเส้นทางไฟเบอร์จากหนึ่งในวิทยาเขตเกตเวย์กลางของสหรัฐอเมริกาในกระดูกสันหลังการผลิตของ Google นำไปสู่การลดลงของแบนด์วิดท์เครือข่ายที่มีอยู่ระหว่างเกตเวย์และสถานที่หลายแห่งทำให้แพ็คเก็ตสูญเสียในขณะที่กระดูกสันหลังย้ายการจราจรโดยอัตโนมัติไปยังเส้นทางที่เหลือ
Knight Capital การรวมกันของเวอร์ชันที่ปรับใช้ที่ขัดแย้งกันและการใช้บิตที่ใช้ก่อนหน้านี้ทำให้เกิดการสูญเสีย $ 460M ดูการเขียนอีกต่อไป
ที่เก็บรหัส WebKit ที่เก็บ WebKit ซึ่งเป็นที่เก็บการโค่นล้มที่กำหนดค่าให้ใช้การซ้ำซ้อนไม่สามารถใช้งานได้หลังจากสองไฟล์ที่มีแฮช SHA-1 เดียวกันถูกตรวจสอบเป็นข้อมูลทดสอบโดยมีความตั้งใจที่จะดำเนินการตรวจสอบความปลอดภัยสำหรับการชน ไฟล์ทั้งสองมีผลรวม MD5 ที่แตกต่างกันดังนั้นการชำระเงินจะล้มเหลวในการตรวจสอบความสอดคล้อง สำหรับบริบทการปะทะกันของ SHA-1 ครั้งแรกที่ได้รับการประกาศเมื่อเร็ว ๆ นี้โดยมีตัวอย่างของสองไฟล์ที่ชนกัน
Azure ใบรับรองที่ถูกต้องเป็นเวลาหนึ่งปีถูกสร้างขึ้น แทนที่จะใช้ห้องสมุดที่เหมาะสมมีคนเขียนโค้ดที่คำนวณหนึ่งปีเป็นวันที่ปัจจุบันบวกหนึ่งปี เมื่อวันที่ 29 กุมภาพันธ์ 2555 สิ่งนี้ส่งผลให้มีการสร้างใบรับรองด้วยวันหมดอายุของวันที่ 29 กุมภาพันธ์ 2013 ซึ่งถูกปฏิเสธเนื่องจากวันที่ไม่ถูกต้อง สิ่งนี้ทำให้เกิดการหยุดทำงานของ Azure ทั่วโลกซึ่งกินเวลาเกือบตลอดทั้งวัน
Cloudflare ย้อนเวลาย้อนกลับไปจากการติดตามการกระโดดครั้งที่สองที่ 27 ในปี 2016-12-31T23: 59: 60Z ทำให้เกิดการเลือก Round-Robin แบบถ่วงน้ำหนักของ DNS Resolvers (RRDNS) เพื่อความตื่นตระหนกและล้มเหลวในการค้นหา CNAME บางตัว time.Now() ถูกสันนิษฐานว่าเป็นโมโนโทนิกอย่างไม่ถูกต้อง การฉีดค่าลบนี้ลงในการโทรไปยัง rand.Int63n() ซึ่งตื่นตระหนกในกรณีนั้น
Linux รหัสที่สอง Leap ถูกเรียกจากตัวจับเวลาอินเตอร์รัปต์ตัวจับเวลาซึ่งจัดขึ้น xtime_lock รหัสนั้นทำ printk เพื่อบันทึกการกระโดดครั้งที่สอง printk ตื่นขึ้นมา klogd ซึ่งบางครั้งอาจพยายามหาเวลาซึ่งรออยู่ที่ xtime_lock ทำให้เกิดการหยุดชะงัก
Linux เมื่อเกิดการกระโดดครั้งที่สอง CLOCK_REALTIME จะกลับมาอีกครั้งในหนึ่งวินาที สิ่งนี้ไม่ได้ทำผ่านกลไกที่จะอัปเดต hrtimer base.offset นั่นหมายความว่าเมื่อมีการขัดจังหวะตัวจับเวลาตัวจับเวลา Timer_abstime นาฬิกา _realtime ได้หมดอายุหนึ่งวินาทีก่อนรวมถึงตัวจับเวลาที่ตั้งไว้น้อยกว่าหนึ่งวินาที สิ่งนี้ทำให้แอพพลิเคชั่นที่ใช้การนอนหลับน้อยกว่าหนึ่งวินาทีในการวนซ้ำไปยังสปินวอทโดยไม่ต้องนอนทำให้โหลดสูงในหลาย ๆ ระบบ สิ่งนี้ทำให้บริการเว็บจำนวนมากลดลงในปี 2012
Mozilla Add-On Firefox ส่วนใหญ่หยุดทำงานประมาณวันที่ 4 พฤษภาคม 2019 เมื่อใบรับรองหมดอายุ Firefox ต้องการห่วงโซ่ใบรับรองที่ถูกต้องเพื่อป้องกันมัลแวร์ ประมาณเก้าชั่วโมงต่อมา Mozilla ผลักดันการใช้งานที่มีสิทธิพิเศษซึ่งฉีดใบรับรองที่ถูกต้องลงในร้านประกาศนียบัตรของ Firefox สร้างห่วงโซ่ที่ถูกต้องและไม่ปิดกั้นส่วนเสริม คนพิการนี้มีประสิทธิภาพทั้งหมดประมาณ 15,000 และความละเอียดใช้เวลาประมาณ 15-21 ชั่วโมงสำหรับผู้ใช้ส่วนใหญ่ ข้อมูลผู้ใช้บางส่วนหายไป ก่อนหน้านี้ Mozilla โพสต์เกี่ยวกับรายละเอียดทางเทคนิค
GitHub แพลตฟอร์ม GitHub พบโหมดความล้มเหลวใหม่เมื่อประมวลผลการโยกย้ายสคีมาบนตาราง MySQL ขนาดใหญ่ การย้ายถิ่นของสคีมาเป็นงานทั่วไปที่ GitHub และมักจะใช้เวลาหลายสัปดาห์กว่าจะเสร็จสมบูรณ์ ขั้นตอนสุดท้ายในการย้ายถิ่นคือการเปลี่ยนชื่อเพื่อย้ายตารางที่อัปเดตไปยังสถานที่ที่ถูกต้อง ในระหว่างขั้นตอนสุดท้ายของการโยกย้ายครั้งนี้ส่วนสำคัญของ MySQL Read Replicas ของเราเข้าสู่การหยุดชะงักของเซมาฟอร์ กลุ่ม MySQL ของเราประกอบด้วยโหนดหลักสำหรับการรับส่งข้อมูลการเขียนแบบจำลองการอ่านหลายแบบสำหรับปริมาณการผลิตและแบบจำลองหลายรายการที่ให้บริการการรับส่งข้อมูลภายในเพื่อการสำรองข้อมูลและการวิเคราะห์ แบบจำลองการอ่านที่กระทบกับการหยุดชะงักเข้าสู่สถานะการกู้คืนความผิดพลาดทำให้โหลดเพิ่มขึ้นในแบบจำลองการอ่านที่ดีต่อสุขภาพ เนื่องจากลักษณะการเรียงซ้อนของสถานการณ์นี้มีแบบจำลองการอ่านที่ใช้งานไม่เพียงพอที่จะจัดการคำขอการผลิตซึ่งส่งผลกระทบต่อความพร้อมใช้งานของบริการหลัก GitHub
Heroku เมื่อเวลา 15:05 UTC เมื่อวันที่ 8 มิถุนายน 2566 มีข้อผิดพลาดฐานข้อมูลเกิดขึ้นเมื่อคีย์ต่างประเทศใช้ประเภทข้อมูลที่เล็กกว่าคีย์หลักที่อ้างอิง ข้อผิดพลาดนี้ทำให้เกิดการล้นเมื่อคีย์หลักเกินค่าที่อนุญาตส่งผลให้ไม่สามารถสร้างการอนุญาตใหม่ภายใน Heroku ข้อผิดพลาดนี้ยังทำให้ลูกค้าไม่สามารถสร้างการปรับใช้ใหม่ได้ การดำเนินการของ Oncall นั้นก่อให้เกิดการหยุดทำงานอย่างเต็มรูปแบบของ Heroku API
Allegro แพลตฟอร์ม Allegro ประสบความล้มเหลวของระบบย่อยที่รับผิดชอบในการประมวลผลงานแบบกระจายแบบอะซิงโครนัส ปัญหาส่งผลกระทบต่อหลายพื้นที่เช่นคุณสมบัติเช่นการซื้อข้อเสนอมากมายผ่านการแก้ไขข้อเสนอรถเข็นและการแก้ไขข้อเสนอจำนวนมาก (รวมถึงการแก้ไขรายการราคา) ไม่ทำงานเลย ยิ่งกว่านั้นบางส่วนล้มเหลวในการส่งจดหมายข่าวรายวันพร้อมข้อเสนอใหม่ นอกจากนี้ยังได้รับผลกระทบจากแผงการบริหารภายในบางส่วน
อเมซอน ความผิดพลาดของมนุษย์ เมื่อวันที่ 28 กุมภาพันธ์ 2017 9:37 น. PST ทีม Amazon S3 กำลังแก้ไขปัญหาเล็กน้อย แม้จะใช้ playbook ที่จัดตั้งขึ้นหนึ่งในคำสั่งที่ตั้งใจจะลบเซิร์ฟเวอร์จำนวนน้อยออกด้วยการพิมพ์ผิดโดยไม่ตั้งใจทำให้เซิร์ฟเวอร์ขนาดใหญ่ถูกลบออก เซิร์ฟเวอร์เหล่านี้สนับสนุนระบบ S3 ที่สำคัญ เป็นผลให้ระบบที่ต้องพึ่งพาจำเป็นต้องรีสตาร์ทอย่างเต็มรูปแบบเพื่อให้ทำงานอย่างถูกต้องและระบบได้รับการขัดข้องอย่างกว้างขวางสำหรับ US-East-1 (เวอร์จิเนียตอนเหนือ) จนถึงการลงมติสุดท้ายเวลา 13:54 น. PST เนื่องจากบริการของอเมซอนเช่น EC2 และ EBS พึ่งพา S3 เช่นกันทำให้เกิดความล้มเหลวอย่างมากซึ่งส่งผลกระทบต่อ บริษัท หลายร้อยแห่ง
อเมซอน การทุจริตข้อความทำให้ฟังก์ชั่นสถานะเซิร์ฟเวอร์แบบกระจายไปทั่วทรัพยากรในกองทัพเรือการประมวลผลการร้องขอ S3
อเมซอน ข้อผิดพลาดของมนุษย์ในระหว่างการอัพเกรดเครือข่ายประจำนำไปสู่การวิกฤติของทรัพยากรซึ่งรุนแรงขึ้นโดยข้อบกพร่องของซอฟต์แวร์ซึ่งในที่สุดก็ส่งผลให้เกิดการหยุดทำงานในโซนความพร้อมใช้งานของสหรัฐตะวันออกทั้งหมดรวมถึงการสูญเสียปริมาณ 0.07%
อเมซอน ไม่สามารถติดต่อเซิร์ฟเวอร์การรวบรวมข้อมูลได้เรียกแมลงการรั่วไหลของหน่วยความจำแฝงในเอเจนต์การรายงานบนเซิร์ฟเวอร์ที่เก็บข้อมูล และไม่มีการจัดการที่เสื่อมโทรมอย่างสง่างามดังนั้นตัวแทนการรายงานจึงติดต่อเซิร์ฟเวอร์คอลเลกชันอย่างต่อเนื่องในลักษณะที่ใช้หน่วยความจำระบบอย่างช้าๆ นอกจากนี้ระบบการตรวจสอบไม่สามารถเตือนการรั่วไหลของหน่วยความจำเซิร์ฟเวอร์ EBS ของเซิร์ฟเวอร์นี้ได้ทั้งเซิร์ฟเวอร์ EBS มักใช้การใช้งานหน่วยความจำทั้งหมดแบบไดนามิก ในเช้าวันจันทร์อัตราการสูญเสียหน่วยความจำค่อนข้างสูงและสับสนหน่วยความจำเพียงพอสำหรับเซิร์ฟเวอร์ที่เก็บข้อมูลที่ได้รับผลกระทบซึ่งไม่สามารถติดตามกระบวนการจัดการคำขอได้ ข้อผิดพลาดนี้ได้รับการตัดออกไปอีกโดยการไม่สามารถทำล้มเหลวซึ่งส่งผลให้เกิดการหยุดทำงาน
อเมซอน Load Balancer ยืดหยุ่นพบปัญหาเมื่อ "กระบวนการบำรุงรักษาที่ทำงานโดยไม่ได้ตั้งใจกับข้อมูลการผลิต ELB State"
อเมซอน "การหยุดชะงักของเครือข่าย" ทำให้บริการเมตาดาต้าได้สัมผัสกับการโหลดที่ทำให้เวลาตอบสนองเกินกว่าค่าหมดเวลาทำให้โหนดจัดเก็บข้อมูลลง โหนดที่ทำให้ตัวเองลงไปอย่างต่อเนื่องเพื่อลองใหม่เพื่อให้มั่นใจว่าการโหลดบริการข้อมูลเมตาไม่สามารถลดลงได้
อเมซอน การปรับขนาดแคช Front-end Fleet สำหรับ kinesis ทำให้เซิร์ฟเวอร์ทั้งหมดในกองเรือเกินจำนวนเธรดสูงสุดที่อนุญาตโดยการกำหนดค่าระบบปฏิบัติการ บริการดาวน์สตรีมที่สำคัญหลายอย่างได้รับผลกระทบจาก Cognito ถึง Lambda ถึง CloudWatch
อเมซอน เวลา 7:30 น. PST กิจกรรมอัตโนมัติเพื่อขยายความจุของหนึ่งในบริการ AWS ที่โฮสต์ในเครือข่าย AWS หลักทำให้เกิดพฤติกรรมที่ไม่คาดคิดจากลูกค้าจำนวนมากภายในเครือข่ายภายใน สิ่งนี้ส่งผลให้เกิดกิจกรรมการเชื่อมต่อจำนวนมากที่ทำให้อุปกรณ์เครือข่ายระหว่างเครือข่ายภายในและเครือข่าย AWS หลักส่งผลให้เกิดความล่าช้าในการสื่อสารระหว่างเครือข่ายเหล่านี้ ความล่าช้าเหล่านี้เพิ่มความล่าช้าและข้อผิดพลาดสำหรับบริการที่สื่อสารระหว่างเครือข่ายเหล่านี้ส่งผลให้ความพยายามในการเชื่อมต่อและการตอบกลับมากขึ้น สิ่งนี้นำไปสู่ความแออัดและปัญหาด้านประสิทธิภาพอย่างต่อเนื่องบนอุปกรณ์ที่เชื่อมต่อเครือข่ายทั้งสอง
AppNexus การอัปเดตฐานข้อมูลฟรีสองครั้งทำให้เซิร์ฟเวอร์ "Impression Bus" ทั้งหมดหยุดทำงานพร้อมกัน สิ่งนี้ไม่ได้ติดอยู่ในการจัดเตรียมและทำให้การผลิตเนื่องจากการหน่วงเวลาเป็นสิ่งจำเป็นในการกระตุ้นข้อผิดพลาดและระยะเวลาการจัดเตรียมไม่ได้มีความล่าช้าในตัว
AT&T. บรรทัดที่ไม่ดีของรหัส C แนะนำอันตรายจากการแข่งขันซึ่งในเวลาอันควรจะยุบเครือข่ายโทรศัพท์ หลังจากการหยุดทำงานที่วางแผนไว้ข้อความการเริ่มต้นใหม่ของ QuickFire ทำให้เกิดการแข่งขันทำให้เกิดการรีบูตมากขึ้นซึ่งทำให้เกิดปัญหามากขึ้น "ปัญหาซ้ำ ๆ ซ้ำ ๆ ตลอดสวิตช์ 114 ในเครือข่ายปิดกั้นการโทรมากกว่า 50 ล้านครั้งในเก้าชั่วโมงที่ใช้เพื่อทำให้ระบบมีเสถียรภาพ" จากปี 1990
Atlassian ในวันอังคารที่ 5 เมษายน 2565 เริ่มต้นเวลา 7:38 UTC, 775 ลูกค้า Atlassian สูญเสียการเข้าถึงผลิตภัณฑ์ Atlassian ของพวกเขา การดับครอบคลุมถึง 14 วันสำหรับชุดย่อยของลูกค้าเหล่านี้โดยมีลูกค้าชุดแรกที่ได้รับการฟื้นฟูในวันที่ 8 เมษายนและเว็บไซต์ลูกค้าทั้งหมดได้รับการฟื้นฟูอย่างต่อเนื่องภายในวันที่ 18 เมษายน
Basecamp ดูเพิ่มเติม เครือข่ายของ Basecamp อยู่ภายใต้การโจมตีของ DDOS ในช่วงหน้าต่าง 100 นาทีในวันที่ 24 มีนาคม 2014
Basecamp ดูเพิ่มเติม ในเดือนพฤศจิกายนปี 2018 ฐานข้อมูลมีข้อ จำกัด จำนวนเต็มออกจากบริการในโหมดอ่านอย่างเดียว
BBC Online ในเดือนกรกฎาคม 2014 BBC Online ประสบกับการหยุดทำงานที่ยาวนานของบริการออนไลน์ยอดนิยมหลายแห่งรวมถึง BBC iPlayer เมื่อแบ็กเอนด์ฐานข้อมูลมากเกินไปมันก็เริ่มที่จะร้องขอเค้นจากบริการต่าง ๆ บริการที่ไม่ได้แคชการตอบสนองฐานข้อมูลในพื้นที่เริ่มกำหนดเวลาออกไปและในที่สุดก็ล้มเหลวอย่างสมบูรณ์
Bintray ในเดือนกรกฎาคม 2560 แพ็คเกจ Maven ที่เป็นอันตรายหลายแห่งรวมอยู่ใน JCenter ด้วยการโจมตีแบบไม่มีตัวตน แพ็คเกจเหล่านั้นอาศัยอยู่ใน JCenter มานานกว่าหนึ่งปีและได้รับผลกระทบแอพ Android หลายตัวที่ส่งผลให้มีการฉีดยามัลแวร์รหัสโดยการพึ่งพาเหล่านั้นจาก JCenter
บิต โฮสต์ซอร์สโค้ด repo มีข้อมูลรับรองที่อนุญาตให้เข้าถึงการสำรองข้อมูลบิตลี่รวมถึงรหัสผ่านแฮช
Browserstack เครื่องต้นแบบเก่าที่มีช่องโหว่ Shellshock ยังคงใช้งานอยู่มีปุ่มลับซึ่งในที่สุดก็นำไปสู่การละเมิดความปลอดภัยของระบบการผลิต
Buildkite การลดระดับความจุของฐานข้อมูลในความพยายามที่จะลดการใช้จ่าย AWS ทำให้ขาดความสามารถในการสนับสนุนลูกค้า BuildKite ที่จุดสูงสุดซึ่งนำไปสู่การล่มสลายของเซิร์ฟเวอร์ที่พึ่งพา
Bungie ผลข้างเคียงของการแก้ไขข้อผิดพลาดสำหรับการประทับเวลาที่ไม่ถูกต้องทำให้เกิดการสูญเสียข้อมูล การกำหนดค่าความผิดพลาดของเซิร์ฟเวอร์สำหรับ HotFix ทำให้การสูญเสียข้อมูลปรากฏขึ้นอีกครั้งในเซิร์ฟเวอร์หลายตัวในการอัปเดตต่อไปนี้
เกม CCP ช่องการบันทึกที่มีปัญหาทำให้โหนดคลัสเตอร์กำลังจะตายในระหว่างลำดับการเริ่มต้นของคลัสเตอร์หลังจากเปิดตัวแพทช์เกมใหม่
เกม CCP เอกสารข้อผิดพลาดในการใช้ Memory Python ที่ใช้สแต็คที่ใช้เวลาหลายปีในการติดตาม
Chef.io. ซูเปอร์มาร์เก็ตไซต์ชุมชนสูตรล้มเหลวสองชั่วโมงหลังจากเปิดตัวเนื่องจากการไม่ตอบสนองต่อไม่ต่อเนื่องและเวลาแฝงที่เพิ่มขึ้น หนึ่งในเหตุผลหลักสำหรับความล้มเหลวที่ระบุไว้ในการชันสูตรคือการหมดเวลาตรวจสุขภาพต่ำมาก
Circleci การหยุดทำงานของ GitHub และการกู้คืนทำให้ภาระที่เข้ามาขนาดใหญ่โดยไม่คาดคิด ด้วยเหตุผลที่ไม่ได้ระบุโหลดขนาดใหญ่ทำให้ระบบคิวของ Circleci ช้าลงในกรณีนี้เพื่อจัดการธุรกรรมหนึ่งรายการต่อนาที
Circleci เมื่อวันที่ 4 มกราคม 2566 การสอบสวนภายในของเราได้กำหนดขอบเขตของการบุกรุกโดยบุคคลที่สามที่ไม่ได้รับอนุญาตและเส้นทางการเข้าโจมตี จนถึงปัจจุบันเราได้เรียนรู้ว่าบุคคลที่สามที่ไม่ได้รับอนุญาตใช้ประโยชน์จากมัลแวร์ที่นำไปใช้กับแล็ปท็อปของวิศวกร Circleci เพื่อขโมยเซสชัน SSO ที่ได้รับการสนับสนุน 2FA เครื่องนี้ถูกบุกรุกเมื่อวันที่ 16 ธันวาคม 2565 มัลแวร์ไม่ได้ตรวจพบซอฟต์แวร์ป้องกันไวรัสของเรา การตรวจสอบของเราระบุว่ามัลแวร์สามารถดำเนินการขโมยคุกกี้เซสชันทำให้พวกเขาสามารถปลอมตัวเป็นพนักงานเป้าหมายในสถานที่ห่างไกลจากนั้นเพิ่มการเข้าถึงชุดย่อยของระบบการผลิตของเรา
Cloudflare ข้อผิดพลาดของตัวแยกวิเคราะห์ทำให้เซิร์ฟเวอร์ CloudFlare Edge กลับหน่วยความจำที่มีข้อมูลส่วนตัวเช่นคุกกี้ HTTP, โทเค็นการตรวจสอบ, HTTP โพสต์ร่างกายและข้อมูลที่ละเอียดอ่อนอื่น ๆ
Cloudflare ความอ่อนเพลียของซีพียูเกิดจากกฎ WAF เดียวที่มีการแสดงออกปกติที่เขียนได้ไม่ดีซึ่งจบลงด้วยการสร้างการย้อนรอยมากเกินไป กฎนี้ถูกนำไปใช้อย่างรวดเร็วในการผลิตและชุดของเหตุการณ์นำไปสู่การหยุดทำงานของบริการ CloudFlare 27 นาทีทั่วโลก
Datadog หลังจากการอัพเกรดอัตโนมัติกฎเครือข่ายทั้งหมดจะถูกลบออกและทำให้เกิดการหยุดทำงานตลอด 24 ชั่วโมงของกลุ่ม Kubernetes ที่ได้รับการป้องกัน cilium ทั้งหมดในทุกภูมิภาคและผู้ให้บริการคลาวด์
ความไม่ลงรอยกัน บริการกระพือปีกนำไปสู่ฝูงฟ้าร้องที่เชื่อมต่อกับมันอีกครั้งเมื่อมันเกิดขึ้น สิ่งนี้นำไปสู่ข้อผิดพลาดที่เรียงซ้อนซึ่งบริการส่วนหน้าหมดหน่วยความจำเนื่องจากคิวภายในเติมเต็ม
ความไม่ลงรอยกัน "เมื่อเวลาประมาณ 14:01 น. อินสแตนซ์ของ Redis ทำหน้าที่เป็นหลักสำหรับคลัสเตอร์ที่มีความสามารถสูงที่ใช้โดยบริการ API ของ Discord ถูกอพยพโดยอัตโนมัติโดยแพลตฟอร์มคลาวด์ของ Google การย้ายถิ่นนี้ทำให้โหนดลดลงอย่างไม่ถูกต้อง ระบบเรียลไทม์ของ Discord
Dropbox การชันสูตรศพนี้ค่อนข้างบางและฉันไม่แน่ใจว่าเกิดอะไรขึ้น ดูเหมือนว่าการอัพเกรดระบบปฏิบัติการตามกำหนดเวลาจะทำให้เครื่องบางเครื่องถูกเช็ดออกซึ่งนำฐานข้อมูลออกมา
คู่ ความล้มเหลวของการเรียงซ้อนเนื่องจากคิวการร้องขอมากเกินไปความจุฐานข้อมูลที่มีอยู่และไม่เพียงพอ การวางแผนและการตรวจสอบความสามารถไม่เพียงพออาจเกิดขึ้นได้เช่นกัน
เกมมหากาพย์ โหลดมาก (จุดสูงสุดใหม่ของผู้ใช้ที่เกิดขึ้นพร้อมกัน 3.4 ล้านคน) ส่งผลให้เกิดการหยุดชะงักของการบริการบางส่วนและทั้งหมด
สำนักงานอวกาศยุโรป การล้นเกิดขึ้นเมื่อแปลงหมายเลข 16 บิตเป็นตัวเลข 64 บิตในระบบคำแนะนำระหว่าง Ariane 5 ทำให้จรวดชน การล้นที่เกิดขึ้นจริงเกิดขึ้นในรหัสที่ไม่จำเป็นสำหรับการดำเนินการ แต่กำลังทำงานอยู่แล้ว ตามบัญชีหนึ่งสิ่งนี้ทำให้เกิดข้อความแสดงข้อผิดพลาดในการวินิจฉัยที่จะพิมพ์ออกมาและข้อความแสดงข้อผิดพลาดในการวินิจฉัยถูกตีความว่าเป็นข้อมูลที่ถูกต้องจริง ตามบัญชีอื่นไม่มีการติดตั้งตัวจัดการกับดักสำหรับล้น
ยืดหยุ่น ลูกค้าคลาวด์ที่ยืดหยุ่นด้วยการปรับใช้ในภูมิภาค AWS EU-WEST-1 (ไอร์แลนด์) ประสบกับการเข้าถึงกลุ่มของพวกเขาอย่างรุนแรงเป็นเวลาประมาณ 3 ชั่วโมง ในช่วงเวลาเดียวกันนี้มีระยะเวลาประมาณ 20 นาทีในระหว่างที่การปรับใช้ทั้งหมดในภูมิภาคนี้ไม่สามารถใช้งานได้อย่างสมบูรณ์
ยืดหยุ่น ลูกค้าคลาวด์ที่ยืดหยุ่นด้วยการปรับใช้ในภูมิภาค AWS US-East-1 ประสบกับการเข้าถึงกลุ่มของพวกเขา
eslint เมื่อวันที่ 12 กรกฎาคม 2561 ผู้โจมตีได้ทำลายบัญชี NPM ของผู้ดูแล ESLINT และเผยแพร่แพ็คเกจที่เป็นอันตรายไปยังรีจิสทรี NPM
Etsy ก่อนอื่นการปรับใช้ที่ควรจะเป็นข้อผิดพลาดในการปรับใช้ Bugfix ยังทำให้ฐานข้อมูลสดเพื่อรับการอัพเกรดในการทำงานของเครื่องจักรการผลิต เพื่อให้แน่ใจว่าสิ่งนี้ไม่ได้ทำให้เกิดการทุจริตใด ๆ Etsy หยุดให้บริการทราฟฟิกเพื่อตรวจสอบความสมบูรณ์ ประการที่สองการล้นใน IDS (เซ็นต์ INT 32 บิต) ทำให้การดำเนินการฐานข้อมูลบางอย่างล้มเหลว Etsy ไม่เชื่อว่าสิ่งนี้จะไม่ส่งผลให้เกิดการทุจริตข้อมูลและลงเว็บไซต์ในขณะที่การอัพเกรดได้รับการผลักดัน
อย่างรวดเร็ว การดับทั่วโลกเนื่องจากข้อผิดพลาดซอฟต์แวร์ที่ยังไม่ได้เปิดซึ่งปรากฏขึ้นในวันที่ 8 มิถุนายนเมื่อมีการเปลี่ยนแปลงการกำหนดค่าลูกค้าที่ถูกต้อง
Flowdock การส่งข้อความโต้ตอบแบบทันทีของ Flowdock ไม่สามารถใช้งานได้ประมาณ 24 ชั่วโมงระหว่างวันที่ 21-22 เมษายน 2020 การระบาดของโรค Covid-19 ทำให้เกิดการเพิ่มขึ้นอย่างฉับพลันและรุนแรงในการทำงานจากที่บ้านซึ่งทำให้การใช้งาน Flowdock สูงขึ้นซึ่งทำให้เกิดการใช้งาน CPU สูง ข้อมูลผู้ใช้บางส่วนหายไปอย่างถาวร
Foursquare MongoDB ตกอยู่ภายใต้การโหลดเมื่อมันหมดความทรงจำ ความล้มเหลวเป็นหายนะและไม่สง่างามเนื่องจากรูปแบบการสืบค้น AA ที่เกี่ยวข้องกับการอ่านโหลดที่มีระดับต่ำ (การเช็คอินของผู้ใช้แต่ละคนทำให้การอ่านทั้งหมดตรวจสอบประวัติของผู้ใช้และบันทึกคือ 300 ไบต์โดยไม่มีพื้นที่เชิงพื้นที่ซึ่งหมายความว่าข้อมูลส่วนใหญ่ที่ดึงมาจากแต่ละหน้าไม่จำเป็น) การขาดการตรวจสอบในอินสแตนซ์ของ MongoDB ทำให้ภาระสูงไม่ถูกตรวจพบจนกระทั่งภาระกลายเป็นหายนะทำให้เกิดการหยุดทำงาน 17 ชั่วโมงซึ่งประกอบไปด้วยเหตุการณ์สองเหตุการณ์ในสองวัน
Gentoo. เอนทิตีได้รับการเข้าถึงองค์กร Gentoo GitHub ลบการเข้าถึงนักพัฒนาทั้งหมดและเริ่มเพิ่มการกระทำในที่เก็บข้อมูลต่างๆ
GitHub เมื่อวันที่ 28 กุมภาพันธ์ 2018 GitHub ประสบกับการโจมตี DDOS โดยตีเว็บไซต์ด้วยการรับส่งข้อมูล 1.35Tbps
Gitlab หลังจากการล็อคหลักและเริ่มต้นใหม่มันก็ถูกนำกลับมาพร้อมกับระบบไฟล์ที่ไม่ถูกต้องทำให้เกิดการหยุดทำงานทั่วโลก ดูการสนทนา HN
Gitlab การไหลเข้าของคำขอมากเกินไปฐานข้อมูลทำให้เกิดการจำลองแบบล่าช้าผู้ดูแลระบบเหนื่อยลบไดเรกทอรีที่ไม่ถูกต้องหกชั่วโมงของข้อมูลที่หายไป ดูรายงานก่อนหน้านี้และการอภิปราย HN
Google. ระบบเมลส่งอีเมลถึงผู้คนมากกว่า 20 ครั้ง สิ่งนี้เกิดขึ้นเพราะจดหมายถูกส่งไปพร้อมกับงานแบทช์ cron ที่ส่งจดหมายถึงทุกคนที่ถูกทำเครื่องหมายว่ารออีเมล นี่คือการดำเนินการที่ไม่ใช่อะตอมและงานแบทช์ไม่ได้ทำเครื่องหมายคนว่าไม่รอจนกว่าข้อความทั้งหมดจะถูกส่ง
Google. Filestore บังคับใช้ขีด จำกัด ทั่วโลกเกี่ยวกับคำขอ API เพื่อ จำกัด ผลกระทบในสถานการณ์โอเวอร์โหลด การดับเกิดขึ้นเมื่อบริการของ Google ภายในที่จัดการโครงการ GCP จำนวนมากทำงานผิดปกติและ overloaded Filestore API ด้วยคำขอทำให้เกิดการควบคุมกระแสไฟฟ้าทั่วโลกของ Filestore API สิ่งนี้ยังคงดำเนินต่อไปจนกระทั่งบริการภายในถูกหยุดด้วยตนเอง อันเป็นผลมาจากการควบคุมปริมาณการเข้าถึง API แบบอ่านอย่างเดียวนี้ไม่สามารถใช้งานได้สำหรับลูกค้าทุกคน ลูกค้านี้ได้รับผลกระทบในทุกสถานที่เนื่องจากโควต้าทั่วโลกที่ใช้กับ FileStore คอนโซล, GCLOUD และ API Access (รายการ, GetOperation, ฯลฯ ) การโทรทั้งหมดล้มเหลวตลอดระยะเวลา 3 ชั่วโมง 12 นาที Mutate operations (CreateInstance, UpdateInstance, CreateBackup, etc.) still succeeded, but customers were unable to check on operation progress.
Google. The Google Meet Livestream feature experienced disruptions that caused intermittent degraded quality of experience for a small subset of viewers, starting 25 October 2021 0400 PT and ending 26 October 2021 1000 PT. Quality was degraded for a total duration of 4 hours (3 hours on 25 October and 1 hour on 26 October). During this time, no more than 15% of livestream viewers experienced higher rebuffer rates and latency in livestream video playback. We sincerely apologize for the disruption that may have affected your business-critical events. We have identified the cause of the issue and have taken steps to improve our service.
Google. On 13 October 2022 23:30 US/Pacific, there was an unexpected increase of incoming and logging traffic combined with a bug in Google's internal streaming RPC library that triggered a deadlock and caused the Write API Streaming frontend to be overloaded. And BigQuery Storage WriteAPI observed elevated error rates in the US Multi-Region for a period of 5 hours.
GPS/GLONASS. A bad update that caused incorrect orbital mechanics calculations caused GPS satellites that use GLONASS to broadcast incorrect positions for 10 hours. The bug was noticed and rolled back almost immediately due to (?) this didn't fix the issue.
Healthcare.gov. A large organizational failure to build a website for United States healthcare.
Heroku. Having a system that requires scheduled manual updates resulted in an error which caused US customers to be unable to scale, stop or restart dynos, or route HTTP traffic, and also prevented all customers from being able to deploy.
Heroku. An upgrade silently disabled a check that was meant to prevent filesystem corruption in running containers. A subsequent deploy caused filesystem corruption in running containers.
Heroku. An upstream apt update broke pinned packages which lead to customers experiencing write permission failures to /dev .
Heroku. Private tokens were leaked, and allowed attackers to retrieve data, both in internal databases, in private repositories and from customers accounts.
Heroku. A change to the core application that manages the underlying infrastructure for the Common Runtime included a dependency upgrade that caused a timing lock issue that greatly reduced the throughput of our task workers. This dependency change, coupled with a failure to appropriately scale up due to increased workload scheduling, caused the application's work queue to build up. Contributing to the issue, the team was not alerted immediately that new router instances were not being initialized correctly on startup largely because of incorrectly configured alerts. These router instances were serving live traffic already but were shown to be in the wrong boot state, and they were deleted via our normal processes due to failing readiness checks. The deletion caused a degradation of the associated runtime cluster while the autoscaling group was creating new instances. This reduced pool of router instances caused requests to fail as more requests were coming in faster than the limited number of routers could handle. This is when customers started noticing issues with the service.
Homebrew. A GitHub personal access token with recently elevated scopes was leaked from Homebrew's Jenkins that allowed access to git push on several Homebrew repositories.
รังผึ้ง. A tale of multiple incidents, happening mostly due to fast growth.
รังผึ้ง. Another story of multiple incidents that ended up impacting query performance and alerting via triggers and SLOs. These incidents were notable because of how challenging their investigation turned out to be.
รังผึ้ง. On September 8th, 2022, our ingest system went down repeatedly and caused interruptions for over eight hours. We will first cover the background behind the incident with a high-level view of the relevant architecture, how we tried to investigate and fix the system, and finally, we'll go over some meaningful elements that surfaced from our incident review process.
รังผึ้ง. On July 25th, 2023, we experienced a total Honeycomb outage. It impacted all user-facing components from 1:40 pm UTC to 2:48 pm UTC, during which no data could be processed or accessed. The full details of incident triage process is covered in here.
incident.io. A bad event (poison pill) in the async workers queue triggered unhandled panics that repeatedly crashed the app. This combined poorly with Heroku infrastructure, making it difficult to find the source of the problem. Applied mitigations that are generally interesting to people running web services, such as catching corner cases of Go panic recovery and splitting work by type/class to improve reliability.
Indian Electricity Grid. One night in July 2012, a skewed electricity supply-demand profile developed when the northern grid drew a tremendous amount of power from the western and eastern grids. Following a series of circuit breakers tripping by virtue of under-frequency protection, the entire NEW (northern-eastern-western) grid collapsed due to the absence of islanding mechanisms. While the grid was reactivated after over 8 hours, similar conditions in the following day caused the grid to fail again. However, the restoration effort concluded almost 24 hours after the occurrence of the latter incident.
Instapaper. Also this. Limits were hit for a hosted database. It took many hours to migrate over to a new database.
Intel. A scripting bug caused the generation of the divider logic in the Pentium to very occasionally produce incorrect results. The bug wasn't caught in testing because of an incorrect assumption in a proof of correctness. (See the Wikipedia article on 1994 FDIV bug for more information.)
Joyent. Operations on Manta were blocked because a lock couldn't be obtained on their PostgreSQL metadata servers. This was due to a combination of PostgreSQL's transaction wraparound maintenance taking a lock on something, and a Joyent query that unnecessarily tried to take a global lock.
Joyent. An operator used a tool with lax input validation to reboot a small number of servers undergoing maintenance but forgot to type -n and instead rebooted all servers in the datacenter. This caused an outage that lasted 2.5 hours, rebooted all customer instances, put tremendous load on DHCP/TFTP PXE boot systems, and left API systems requiring manual intervention. See also Bryan Cantrill's talk.
Kickstarter. Primary DB became inconsistent with all replicas, which wasn't detected until a query failed. This was caused by a MySQL bug which sometimes caused order by to be ignored.
Kings College London. 3PAR suffered catastrophic outage which highlighted a failure in internal process.
Launchdarkly. Rule attribute selector causing flag targeting web interface to crash.
Mailgun. Secondary MongoDB servers became overloaded and while troubleshooting accidentally pushed a change that sent all secondary traffic to the primary MongoDB server, overloading it as well and exacerbating the problem.
Mandrill. Transaction ID wraparound in Postgres caused a partial outage lasting a day and a half.
ปานกลาง. Polish users were unable to use their "Ś" key on Medium.
Metrist. Azure published a breaking change that affected downstream systems like Metrist's service without warning them, the post covers how to identify the issue and how to recover from it.
นาซ่า A design flaw in the Apollo 11 rendezvous radar produced excess CPU load, causing the spacecraft computer to restart during lunar landing.
นาซ่า Use of different units of measurement (metric vs. English) caused Mars Climate Orbiter to fail. There were also organizational and procedural failures[ref] and defects in the navigation software[ref].
นาซ่า NASA's Mars Pathfinder spacecraft experienced system resets a few days after landing on Mars (1997). Debugging features were remotely enabled until the cause was found: a priority inversion problem in the VxWorks operating system. The OS software was remotely patched (all the way to Mars) to fix the problem by adding priority inheritance to the task scheduler.
Netflix. An EBS outage in one availability zone was mitigated by migrating to other availability zones.
North American Electric Power System. A power outage in Ohio around 1600h EDT cascaded up through a web of systemic vulnerabilities and process failures and resulted in an outage in the power grid affecting ~50,000,000 people for ~4 days in some areas, and caused rolling blackouts in Ontario for about a week thereafter.
Okta. A hackers group got access to a third-party support engineer's laptop.
OpenAI. Queues for requests and responses in a Redis cache became corrupted and out of sequence, leading to some requests revealing other people's user data to some users, including app activity data and some billing info.
Pagerduty. In April 2013, Pagerduty, a cloud service proving application uptime monitoring and real-time notifications, suffered an outage when two of its three independent cloud deployments in different data centers began experiencing connectivity issues and high network latency. It was found later that the two independent deployments shared a common peering point which was experiencing network instability. While the third deployment was still operational, Pagerduty's applications failed to establish quorum due to to high network latency and hence failed in their ability to send notifications.
PagerDuty. A third party service for sending SMS and making voice calls experienced an outage due to AWS having issues in a region.
Parity. $30 million of cryptocurrency value was diverted (stolen) with another $150 million diverted to a safe place (rescued), after a 4000-line software change containing a security bug was mistakenly labeled as a UI change, inadequately reviewed, deployed, and used by various unsuspecting third parties. See also this analysis.
Platform.sh. Outage during a scheduled maintenance window because there were too much data for Zookeeper to boot.
Reddit. Experienced an outage for 1.5 hours, followed by another 1.5 hours of degraded performance on Thursday August 11 2016. This was due to an error during a migration of a critical backend system.
Reddit. Outage for over 5 hours when a critical Kubernetes cluster upgrade failed. The failure was caused by node metadata that changed between versions which brought down workload networking.
Roblox. Roblox end Oct 2021 73 hours outage. Issues with Consul streaming and BoltDB.
Salesforce. Initial disruption due to power failure in one datacenter led to cascading failures with a database cluster and file discrepancies resulting in cross data center failover issues.
Salesforce. On September 20, 2023, a service disruption affected a subset of customers across multiple services beginning at 14:48 Coordinated Universal Time (UTC). As a result, some customers were unable to login and access their services. A policy change executed as a part of our standard security controls review and update cycle to be the trigger of this incident. This change inadvertently blocked access to resources beyond its intended scope.
Sentry. Transaction ID Wraparound in Postgres caused Sentry to go down for most of a working day.
Shapeshift. Poor security practices enabled an employee to steal $200,000 in cryptocurrency in 3 separate hacks over a 1 month period. The company's CEO expanded upon the story in a blog post.
Skyliner. A memory leak in a third party library lead to Skyliner being unavailable on two occasions.
หย่อน. A combination of factor results in a large number of Slack's users being disconnected to the server. The subsequent massive disconnection-reconnection process exceeded the database capacity and caused cascading connection failures, leading to 5% of Slack's users not being able to connect to the server for up to 2 hours.
หย่อน. Network saturation in AWS's traffic gateways caused packet loss. An attempt to scale up caused more issues.
หย่อน. Cache nodes removal caused the high workload on the vitness cluster, which in turn cased the service outage.
Spotify. Lack of exponential backoff in a microservice caused a cascading failure, leading to notable service degradation.
สี่เหลี่ยม. A cascading error from an adjacent service lead to merchant authentication service being overloaded. This impacted merchants for ~2 hours.
Stackdriver. In October 2013, Stackdriver, experienced an outage, when its Cassandra cluster crashed. Data published by various services into a message bus was being injested into the Cassandra cluster. When the cluster failed, the failure percolated to various producers, that ended up blocking on queue insert operations, eventually leading to the failure of the entire application.
Stack Exchange. Enabling StackEgg for all users resulted in heavy load on load balancers and consequently, a DDoS.
Stack Exchange. Backtracking implementation in the underlying regex engine turned out to be very expensive for a particular post leading to health-check failures and eventual outage.
Stack Exchange. Porting old Careers 2.0 code to the new Developer Story caused a leak of users' information.
Stack Exchange. The primary SQL-Server triggered a bugcheck on the SQL Server process, causing the Stack Exchange sites to go into read only mode, and eventually a complete outage.
Strava. Hit the signed integer limit on a primary key, causing uploads to fail.
Stripe. Manual operations are regularly executed on production databases. A manual operation was done incorrectly (missing dependency), causing the Stripe API to go down for 90 minutes.
สวีเดน. Use of different rulers by builders caused the Vasa to be more heavily built on its port side and the ship's designer, not having built a ship with two gun decks before, overbuilt the upper decks, leading to a design that was top heavy. Twenty minutes into its maiden voyage in 1628, the ship heeled to port and sank.
Tarsnap. A batch job which scans for unused blocks in Amazon S3 and marks them to be freed encountered a condition where all retries for freeing certain blocks would fail. The batch job logs its actions to local disk and this log grew without bound. When the filesystem filled, this caused other filesystem writes to fail, and the Tarsnap service stopped. Manually removing the log file restored service.
Telstra. A fire in a datacenter caused SMS text messages to be sent to random destinations. Corrupt messages were also experienced by customers.
Therac-25. The Therac-25 was a radiation therapy machine involved in at least six accidents between 1985 and 1987 in which patients were given massive overdoses of radiation. Because of concurrent programming errors, it sometimes gave its patients radiation doses that were thousands of times greater than normal, resulting in death or serious injury.
trivago. Due to a human error, all engineers lost access to the central source code management platform (GitHub organization). An Azure Active Directory Security group controls the access to the GitHub organization. This group was removed during the execution of a manual and repetitive task.
Twilio. In 2013, a temporary network partition in the redis cluster used for billing operations, caused a massive resynchronization from slaves. The overloaded master crashed and when it was restarted, it started up in read-only mode. The auto-recharge component in This resulted in failed transactions from Twilio's auto-recharge service, which unfortunately billed the customers before updating their balance internally. So the auto-recharge system continued to retry the transaction again and again, resulting in multiple charges to customer's credit cards.
Twilio. Twilio's incident of having high filtering on SMS towards AT&T Network In United States.
วาล์ว. Steam's desktop client deleted all local files and directories. The thing I find most interesting about this is that, after this blew up on social media, there were widespread reports that this was reported to Valve months earlier. But Valve doesn't triage most bugs, resulting in an extremely long time-to-mitigate, despite having multiple bug reports on this issue.
Yeller. A network partition in a cluster caused some messages to get delayed, up to 6-7 hours. For reasons that aren't clear, a rolling restart of the cluster healed the partition. There's some suspicious that it was due to cached routes, but there wasn't enough logging information to tell for sure.
Zerodha. The Order Management System (OMS) provided to Zerodha, a stock broker, collapsed when an order for 1M units of a penny stock was divided into more than 0.1M individual trades against the typical few hundreds, triggering a collapse of the OMS, which was not encountered prior by its provider - Refinitiv (formerly Thomson Reuters), a subsidiary of the London Stock Exchange.
Zerodha. A failure of the primary leased line to a CTCL between a stock broker and a stock exchange led to the activation of a backup leased line that was operating sporadically over the following hour, affecting bracket and cover orders. Subsequently, the process of placing and validating orders had been modified to incorporate the unreliability of the CTCL's leased lines, but the reliability of the primary and the backup leased lines was not fundamentally improved by the providers.
Unfortunately, most of the interesting post-mortems I know about are locked inside confidential pages at Google and Microsoft. Please add more links if you know of any interesting public post mortems! is a pretty good resource; other links to collections of post mortems are also appreciated.
AWS Post-Event Summaries
Availability Digest website.
Postmortems community (with imported archive from the now-dead G+ community).
John Daily's list of postmortems (in json).
Jeff Hammerbacher's list of postmortems.
NASA lessons learned database.
Tim Freeman's list of postmortems
Wikimedia's postmortems.
Autopsy.io's list of Startup failures.
SRE Weekly usually has an Outages section at the end.
Lorin Hochstein's list of major incidents.
Awesome Tech Postmortems.
Nat Welch's parsed postmortems is an attempt to build a database out of this markdown file.
Postmortem Templates is a collection of postmortem templates from various sources.
How Complex Systems Fail
John Allspaw on Resilience Engineering
