Lỗi một mili giây làm ngừng giao thông hàng không Vương quốc Anh. Sáu giờ đồng hồ.

Nội dung video này đề cập

• 10:00: một yêu cầu, bị gián đoạn trong khoảng thời gian 1 ms
• Dòng thời gian: 10:00 squawk → 10:02 blip → 12:45 dừng khởi hành → 13:32 mất liên kết
• Giải pháp: khởi động lại dữ liệu chuyến bay của cả nước
• Cơ chế: tạm dừng giữa chừng một thao tác ghi
• Tại sao một tính năng an toàn lại làm ngừng hoạt động bầu trời

Bản ghi đã dịch

Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.

10:00: một yêu cầu, bị gián đoạn trong khoảng thời gian 1 ms

0:00 Vào mười giờ sáng, một yêu cầu thông thường trong hệ thống dữ liệu chuyến bay của Anh bị gián đoạn đúng vào mili giây sai, và đến tối hơn hai nghìn chuyến bay bị trì hoãn, hủy bỏ hoặc chuyển hướng. Đó là từ báo cáo sơ bộ của Nats, dịch vụ không lưu của Vương quốc Anh. Không có dấu hiệu tấn công, và không ai nhấn nhầm nút. Chỉ là một lỗi cũ, và một mili giây rất cụ thể. Nó đã xảy ra như thế nào, tại sao một mili giây là đủ, và ai thực sự chịu trách nhiệm. Đây là The Daily Diff, postmortem.

0:31 Mười giờ. Ai đó tự yêu cầu một mã squawk, số bốn chữ số đó

Dòng thời gian: 10:00 squawk → 10:02 blip → 12:45 dừng khởi hành → 13:32 mất liên kết

0:36 liên kết một tín hiệu radar với kế hoạch bay của nó. Yêu cầu hợp lệ, và kế hoạch cũng vậy. Mười giờ hai phút. Liên kết giữa Trung tâm Kiểm soát Khu vực London và hệ thống lõi bị mất, sau đó tự quay lại sau bốn mươi lăm giây. Phiếu ghi nói đã khôi phục, ổn định, không ảnh hưởng hoạt động. Mười hai giờ ba mươi hai phút. Liên kết bắt đầu mất lại, nhanh hơn mỗi lần, và các kiểm soát viên mất một số tự động hóa.

0:56 Đến mười hai giờ bốn mươi lăm phút, các chuyến bay khởi hành từ Vương quốc Anh bị dừng. Vào một giờ ba mươi hai phút, liên kết bị mất và duy trì tình trạng đó. Giải pháp là một khởi động lại có kiểm soát, và đó là phần tốn kém,

Giải pháp: khởi động lại dữ liệu chuyến bay của cả nước

1:06 vì cùng một hệ thống cấp dữ liệu cho các trung tâm kiểm soát và sân bay trên toàn quốc. Lỗi nằm trong không phận London. Các hạn chế bao trùm toàn bộ Vương quốc Anh. Việc khởi động lại kéo dài từ ba giờ mười lăm đến bốn giờ mười phút, và việc gỡ rối các kế hoạch bay trùng lặp mất đến sáu giờ năm mươi phút. Vậy tại sao một mili giây là đủ?

Cơ chế: tạm dừng giữa chừng một thao tác ghi

1:23 Hệ thống xử lý các công việc theo mức độ ưu tiên, và việc tạm dừng một công việc nhỏ để thực hiện một công việc khẩn cấp là bình thường. Nhưng công việc này đang trong quá trình cập nhật một giá trị. Thông báo khẩn cấp đến trong mili giây đó, và quá trình cập nhật dừng giữa chừng. Khi nó tiếp tục, nó không tiếp tục đúng cách. Dữ liệu xấu sau đó rò rỉ vào một số cập nhật chuyến bay sau này.

Tại sao một tính năng an toàn lại làm ngừng hoạt động bầu trời

1:40 London cố gắng đọc một cái, mất quá nhiều thời gian và hết giờ. Một lỗi hết giờ sẽ làm mất liên kết, theo thiết kế, để bảo vệ cả hai hệ thống. Tính năng an toàn hoạt động hoàn hảo. Đó là vấn đề. Lời của báo cáo. Nếu thông báo khẩn cấp đến sớm hơn hoặc muộn hơn một mili giây, quá trình cập nhật đã hoàn thành bình thường. Trên Hacker News, một lập trình viên gọi một mili giây là một khoảng thời gian vô tận,

2:02 đảm bảo sẽ xảy ra vào thứ Ba tuần này. Đó là một ngày thứ Ba.

git blame — mã cũ 50 · kế hoạch khởi động lại 30 · báo động 10:02 15 · 1 ms 5

2:05 git blame. Mã cũ, năm mươi phần trăm, cho một cập nhật có thể bị tạm dừng giữa chừng và trả về sai. Kế hoạch khởi động lại, ba mươi, vì một bản ghi xấu ở London có nghĩa là phải khởi động lại dữ liệu chuyến bay của cả nước. Báo động mười giờ hai phút, mười lăm, vì tự phục hồi và được ghi nhận là không ảnh hưởng. Năm phần trăm cho mili giây, vì thời điểm của nó. Phạm vi ảnh hưởng. Nats đã lên kế hoạch cho khoảng tám nghìn chuyến bay trong ngày đó và đã xử lý

Phạm vi ảnh hưởng: 8.000 dự kiến, 6.094 đã xử lý, thất bại thứ ba trong ba năm

2:27 khoảng sáu nghìn. Các chuyến bay khởi hành từ Vương quốc Anh bị dừng khoảng bốn tiếng rưỡi, và lượng công việc tồn đọng phải mất hơn hai ngày để giải quyết. Đây là sự cố không lưu thứ ba của Anh trong ba năm, và giám đốc điều hành gọi lỗi này là rất, rất khó phát hiện.

Phán quyết + dòng Thứ Hai: ghi nguyên tử, báo động lớn

2:41 Phán quyết, postmortem: NEEDS REVIEW. Báo cáo nhanh và cụ thể, và bản sửa lỗi đã được viết và đang thử nghiệm. Nhưng kế hoạch là một khởi động lại nhanh hơn, không phải nhỏ hơn. Dòng Thứ Hai: nếu một công việc có thể bị tạm dừng, hãy làm cho thao tác ghi của nó nguyên tử, và coi một báo động tự phục hồi là một báo động. Hãy gửi cho tôi sự cố mà bạn vẫn chưa được phép nói về, trong phần bình luận, hoặc tại thedailydiff.dev. Và đó là thông tin khác biệt trong ngày hôm nay.

3:02 Tôi là Niko từ Axrisi. Hợp nhất có trách nhiệm.

Nguồn

1. NATS, Major Incident Preliminary Investigation Report, NAS incident 08 September 2026 (report date Sep 16)www.nats.aero
2. NATS press release, "NATS publishes preliminary report on technical incident of 8 September" (Sep 18, 2026)www.nats.aero
3. NATS on X, 8 Sepx.com
4. BBC, "Flight chaos caused by 'millisecond' software defect, report says"www.bbc.co.uk
5. The Guardian (Sep 18, 2026)www.theguardian.com
6. Hacker News thread on the reportnews.ycombinator.com