- vừa được xem lúc

Làm thế nào một dòng mã gây ra tổn thất 60 triệu đô la

0 0 1

Người đăng: BSOD

Theo Viblo Asia

AT&T Inc. (American Telephone and Telegraph Company) là một tập đoàn viễn thông đa quốc gia của Mỹ, có trụ sở chính tại Whitacre Tower ở trung tâm thành phố Dallas, Texas. Đây là công ty viễn thông lớn thứ tư trên thế giới về doanh thu và là nhà cung cấp dịch vụ di động lớn nhất tại Hoa Kỳ.

Vào ngày 15 tháng 1 năm 1990, trung tâm điều hành New Jersey của AT&T đã phát hiện ra một sự cố trục trặc hệ thống lan rộng, được hiển thị bằng vô số cảnh báo màu đỏ trên màn hình mạng của họ.

Mặc dù đã cố gắng khắc phục tình hình, mạng vẫn bị lỗi trong 9 giờ, dẫn đến tỷ lệ kết nối cuộc gọi thất bại 50%.

AT&T đã thiệt hại hơn 60 triệu đô la do hậu quả này, với hơn 60.000 người Mỹ bị ngắt kết nối điện thoại hoàn toàn.

Ngoài ra, 500 chuyến bay thương mại đã bị trì hoãn, ảnh hưởng đến 85.000 người. Mạng đường dài của AT&T từng được coi là tấm gương về hiệu quả, xử lý một lượng lớn cuộc gọi của cả nước với hệ thống chuyển đổi điện tử và tín hiệu tiên tiến. Hệ thống này thường hoàn thành việc định tuyến cuộc gọi trong vài giây.

Tuy nhiên, vào ngày hôm đó, một lỗi bắt đầu từ một thiết bị chuyển đổi ở New York đã lan truyền khắp mạng. Nguyên nhân là do một lỗi phần mềm trong bản cập nhật gần đây chứa một lỗ hổng nghiêm trọng ảnh hưởng đến 114 thiết bị chuyển đổi của mạng. Khi thiết bị chuyển đổi New York tự khởi động lại và gửi tín hiệu, lỗi này gây ra hiệu ứng domino, dẫn đến gián đoạn mạng diện rộng.

Bản vá phần mềm này đã trải qua nhiều lớp kiểm tra mà không bị phát hiện. Sự cố này đặc biệt đáng ngạc nhiên vì AT&T nổi tiếng với các quy trình kiểm tra nghiêm ngặt của họ.

Vấn đề

Nguyên nhân gốc rễ được cho là do lỗi mã hóa trong bản cập nhật phần mềm được triển khai trên tất cả các thiết bị chuyển đổi của mạng.

Lỗi này, nằm trong một chương trình C, liên quan đến một câu lệnh "break" sai vị trí trong các câu lệnh điều kiện lồng nhau, dẫn đến ghi đè dữ liệu và reset lại hệ thống.

Mã giả:

1 while (ring receive buffer not empty and side buffer not empty): 2 Initialize pointer to first message in side buffer or ring receive buffer 3 get copy of buffer 4 switch (message): 5 case (incoming_message): 6 if (sending switch is out of service): 7 if (ring write buffer is empty): 8 send "in service" to status map 9 else: 10 break // The error was here! end if 11 process incoming message, set up pointers to optional parameters 12 break END SWITCH 13 do optional parameter work

Vấn đề:

  • Nếu ring write buffer KHÔNG rỗng, câu lệnh if ở dòng 7 bị bỏ qua và câu lệnh break ở dòng 10 được thực hiện.
  • Tuy nhiên, để chương trình hoạt động bình thường, dòng 11 nên được thực thi.
  • Khi câu lệnh break được thực hiện thay vì xử lý tin nhắn đến và thiết lập các con trỏ cho các tham số tùy chọn, thì dữ liệu (con trỏ nên được giữ) bị ghi đè.
  • Phần mềm sửa lỗi đã phát hiện ra lỗi ghi đè dữ liệu và reset bộ chuyển đổi. Vấn đề này trở nên nghiêm trọng hơn vì phần mềm sửa lỗi này có mặt trong tất cả các bộ chuyển đổi trên mạng, dẫn đến phản ứng dây chuyền khởi động lại, cuối cùng làm tê liệt toàn bộ hệ thống mạng.

Mặc dù có một hệ thống mạng được thiết kế với khả năng tự phục hồi, nhưng chỉ một dòng mã đã có thể hạ gục một nửa đường dây liên lạc chính của cả nước.

Cách khắc phục

Mất 9 giờ các kỹ sư mới đưa hệ thống của AT&T trở lại hoạt động hoàn toàn. Họ thực hiện điều này chủ yếu bằng cách rollback các thiết bị chuyển mạch về một phiên bản mã trước đó, phiên bản hoạt động bình thường.

Phải mất tới hai tuần để các kỹ sư phần mềm thực sự hiểu lỗi nằm ở đâu.

Tổng kết

Thật không may cho AT&T, sự cố này thậm chí còn không phải là sự cố sập hệ thống lớn nhất của họ trong thập niên 90. Họ đã gặp phải nhiều vấn đề khác nữa trong giai đoạn sau của thập kỷ.

Trên thực tế, không phải chỉ một dòng code mới khiến hệ thống sập. Đó là một thất bại trong cả quy trình.

Các công ty ngày nay có các quy trình thậm chí còn tốt hơn, và ngay cả như vậy, lỗi vẫn xảy ra. Google đã viết một bài hồi tưởng tuyệt vời về "20 years of Site Reliability Engineering", nơi họ phản ánh về lần gián đoạn toàn cầu đầu tiên của YouTube vào năm 2016.

Quy mô của các sự cố sập hệ thống đối với các công ty lớn là rất lớn và có nhiều bài học rút ra từ mỗi sự cố. Tuy nhiên, hầu hết các sự cố đều bắt nguồn từ lỗi của con người và những lỗ hổng trong quy trình.

Cám ơn các bạn đã dành thời gian đọc! Hi vọng qua câu chuyện thú vị trên sẽ mang đến cho mọi người bài học kinh nghiệm, góc nhìn thú vị về công nghệ.

CHÚC MỪNG NĂM MỚI ❤️

Bình luận

Bài viết tương tự

- vừa được xem lúc

Một số thủ thuật hay ho với Linux (1).

1. Ctrl + x + e. Giữ CTRL, nhấn phím x rồi nhấn phím e. Thao tác này sẽ mở ra editor mặc định (echo $EDITOR | $VISUAL để kiểm tra) chứa sẵn.

0 0 34

- vừa được xem lúc

How to deploy Amplication app to DigitalOcean

This article shows you the way to deploy an app generated by Amplication to DigitalOcean. Amplication provides the dockerfile to use containers for deployment, but this blog explains how to do it manu

0 0 39

- vừa được xem lúc

Có gì mới trong Laravel 9.0?

Laravel v9 là phiên bản LTS tiếp theo của Laravel và ra mắt vào tháng 2 năm 2022. Trong bài viết này, mình xin giới thiệu một vài tính năng mới trong Laravel trong Laravel 9.

0 0 65

- vừa được xem lúc

Xây dựng trang web tra cứu ảnh sử dụng phân cụm Spectral Clustering

1. Tổng quan tra cứu ảnh. 1.1.

0 0 32

- vừa được xem lúc

Scanning network 1 - quét mạng như một hacker

Chào mọi người mình là Tuntun. Một năm qua là một năm khá bận rộn nhỉ.

0 0 34

- vừa được xem lúc

Interpreter Design Pattern - Trợ thủ đắc lực của Developers

1. Giới thiệu. . Interpreter là một mẫu thiết kế thuộc nhóm hành vi (Behavioral Pattern).

0 0 32