1 dòng mã khiến lãng phí 8.000 đô la

• Do lỗi cập nhật tự động của Screen Studio, ứng dụng quay màn hình cho macOS, đã xảy ra vấn đề tải lặp lại tệp 250MB mỗi 5 phút
• Kết quả là trong một tháng, 2PB (2.000.000GB) lưu lượng đã phát sinh trên Google Cloud, dẫn tới hóa đơn khoảng 8.000 USD
• Nguyên nhân là một thiếu sót đơn giản trong mã: bỏ quên logic dừng yêu cầu lặp lại sau khi tải xong bản cập nhật
• Với một số người dùng, sự cố còn gây ra thiệt hại thực tế như bị nhà cung cấp Internet chấm dứt dịch vụ, và đội ngũ phát triển đã thừa nhận hoàn toàn trách nhiệm
• Bài học được nhấn mạnh gồm thiết lập cảnh báo chi phí đám mây, rà soát mã có thể phát sinh chi phí, và chuẩn bị cơ chế kiểm soát máy chủ cho cập nhật

---

Tổng quan sự cố

• Screen Studio là ứng dụng quay màn hình desktop cho macOS và có tính năng cập nhật tự động
• Tệp cập nhật có dung lượng khoảng 250MB, và ứng dụng kiểm tra máy chủ mỗi 5 phút
• Do lỗi, ngay cả sau khi phát hiện bản cập nhật, các yêu cầu cách nhau 5 phút vẫn không dừng lại và tiếp tục tải xuống

Khởi đầu của một đợt refactor thảm họa

• Trước đây, cửa sổ bật lên cập nhật gây phiền trong lúc ghi hình nên có vấn đề về UX
• Trong quá trình refactor để cải thiện điều này, nhóm đã xóa mất logic dừng bộ hẹn giờ sau khi cập nhật
• Kết quả là trong ứng dụng đã tồn tại sẵn logic tải lặp lại tệp cập nhật

Bối cảnh đáng sợ: chạy nền

• Nhiều người dùng đã để ứng dụng chạy nền suốt nhiều tuần
• Trong trạng thái đó, hàng nghìn phiên bản ứng dụng tự động tải 250MB mỗi 5 phút

Thảm họa qua các con số

• Tải xuống mỗi 5 phút = 288 lần/ngày
• Lưu lượng tải xuống mỗi ngày cho mỗi người dùng = 72GB
• Nếu kéo dài khoảng 30 ngày với giả định 1.000 người dùng:
  • 250MB × 288 × 30 × 1.000 = khoảng 2PB lưu lượng
• Chi phí ước tính phát sinh trên Google Cloud: khoảng 8.000 USD

Chuỗi sai lầm liên tiếp

• Không thiết lập cảnh báo chi phí Google Cloud
• Chủ quan vì mức phí hàng tháng trước đó chỉ khoảng 300 USD
• Cuối cùng, chỉ khi giao dịch bị chặn do vượt hạn mức thẻ tín dụng thì vấn đề mới được nhận ra

Thiệt hại với người dùng

• Một người dùng đã nhận được thông báo bị ISP (nhà cung cấp dịch vụ Internet) chấm dứt hợp đồng dịch vụ vì lưu lượng này
• Khu vực đó không có nhà cung cấp thay thế → gây bất tiện nghiêm trọng trong cuộc sống
• Nhóm thừa nhận trách nhiệm và đề nghị bồi hoàn chi phí, may mắn là sự việc đã được giải quyết ổn thỏa
• Tuy vậy, trải nghiệm gây hại cho người dùng đã để lại sự day dứt sâu sắc với nhà phát triển

Tóm tắt bài học

• Cảnh báo chi phí đám mây là bắt buộc
• Logic cập nhật tự động phải được viết cực kỳ cẩn trọng
• Mọi đoạn mã có khả năng phát sinh chi phí cần được rà soát đặc biệt
• Hãy đưa tín hiệu điều khiển phía máy chủ (ví dụ: cờ ép cập nhật) vào thiết kế
• Kiểm tra định kỳ tình trạng sử dụng đám mây

[GN⁺]

Ý kiến trên Hacker News

• Dành cho những ai tìm thấy chủ đề này qua tìm kiếm web trong tương lai: screen.studio là phần mềm quay màn hình trên macOS, kiểm tra cập nhật mỗi 5 phút. Nhưng lỗi được mô tả trong bài này là cứ mỗi 5 phút lại tải xuống một tệp cập nhật 250MB

  • Các nhà phát triển xem toàn bộ việc này là bình thường, nhưng việc tải xuống thực tế đã gây ra $8000 chi phí băng thông
  • Tóm lại: phần mềm quay màn hình kiểm tra cập nhật mỗi 5 phút. Tức là 12 lần mỗi giờ
  • Tôi chọn phần mềm dựa trên mức độ tôi có thể tin vào phán đoán của nhà phát triển. Hãy cân nhắc liệu phán đoán này có hợp lý hay không

• Screen Studio là ứng dụng quay màn hình cho macOS. Đây là ứng dụng desktop. Họ cho rằng cần tự động cập nhật để giúp việc cài bản mới nhất dễ dàng hơn

  • Tuy nhiên, tự động cập nhật dẫn đến nhiều hệ quả tiêu cực
  • Tải cập nhật mà không có sự đồng ý của người dùng, tạo lưu lượng phía client
  • Việc tải xuống lặp lại cứ 5 phút một lần. Không rõ họ có phát hiện người dùng đang dùng kết nối tính phí theo lưu lượng hay không
  • Có lỗi khiến popup cập nhật làm gián đoạn luồng làm việc
  • Bản thân popup cũng mang lại trải nghiệm tệ cho người dùng. Tốt hơn là chỉ cho phép khi đóng ứng dụng và xử lý phần còn lại ở chế độ nền
  • Một số người dùng theo dõi rất kỹ các kết nối đi ra của ứng dụng, và việc kiểm tra cập nhật mỗi 5 phút là quá mức. Không cần làm điều đó khi ứng dụng đang chạy. Tốt hơn là kiểm tra lúc khởi động và hỏi lúc thoát
  • Sự phức tạp bổ sung trong ứng dụng đã gây ra tất cả các vấn đề trên. Điều này tạo chi phí cho nhà phát triển
  • App Store có thể là cách hoàn hảo để xử lý cập nhật trong trường hợp này

• Thật vô lý khi nhà phát triển của một ứng dụng không quan trọng như trình quay màn hình lại nghĩ rằng họ cần kiểm tra cập nhật mỗi 5 phút

  • Một ngày một lần là đủ

• Tôi thực sự nghi ngờ việc phải kiểm tra cập nhật mỗi 5 phút. Một lần khi khởi động là đủ, và ngay cả khi người dùng để ứng dụng mở trong nhiều ngày, vẫn có thể chỉ kiểm tra mỗi ngày một lần hoặc ít hơn

• Tôi luôn rất nghiêm khắc với code review. Có lần khi quản lý bảo hãy giao thêm cho QA, tôi đã trả lời: "Tất cả chúng ta đều có thể mất việc. Chúng ta luôn có thể mất việc chỉ vì một dòng code tệ"

  • Các lập trình viên junior hoặc dày dạn kinh nghiệm đều thường viết ra những thứ có thể gây rò rỉ PII. Trong hầu hết các hệ thống, điều đó có khả năng rất lớn dẫn đến rắc rối pháp lý

• Vấn đề về lượng băng thông bị tiêu tốn không cần thiết từ gói dữ liệu của hàng nghìn người dùng

  • Những sai lầm bất cẩn như vậy có thể gây tắc nghẽn cho tất cả người dùng Internet
  • Nếu sai lầm này không tạo ra chi phí $8000 mà được che lấp bởi free tier của Google Cloud hay một gói khác, tôi tự hỏi liệu họ vẫn có coi đây là lỗi nghiêm trọng và sửa gấp hay không
  • Có bao nhiêu thiết kế sai đang tạo ra lưu lượng và tiêu tốn tài nguyên dùng chung?

• Khi tôi từng phân phối một ứng dụng desktop cho Mac:

  • Chúng tôi dùng Sparkle để xử lý cập nhật. Việc họ chọn trình cập nhật tự làm của riêng mình là một lựa chọn tệ
  • Ứng dụng của chúng tôi rất phức tạp và được phân phối kèm Mono. Nhưng nó chỉ khoảng 10MB. Bản Windows là 2MB và bao gồm cả binary 32-bit lẫn 64-bit. Tôi tự hỏi vì sao họ lại phân phối một trình quay màn hình 250MB
  • Có vẻ họ đã không rút ra được bài học. Cả bài viết khiến họ trông rất ngớ ngẩn

• Thật ngạc nhiên khi phần tóm tắt không nhắc đến 'kiểm thử tốt hơn'

  • Gợi ý kiểu 'hãy viết code cẩn thận' nghe như một sai lầm sơ đẳng
  • Việc nhà phát triển dùng thiết bị của người dùng làm bãi thử là cực kỳ gây bực bội

• Tôi khá bảo thủ trong việc chấp nhận thư viện bên thứ ba (vì mỗi thư viện đều có thể gây vấn đề về lâu dài), nhưng cập nhật ứng dụng thì đáng để dùng

  • Về cơ bản đây là một edge case lớn, và nếu ứng dụng có lỗi nghiêm trọng thì đó là phần quan trọng của kế hoạch khôi phục
  • Lỗi này không phải vấn đề duy nhất trong trình tự cập nhật của họ. Việc kiểm tra mỗi 5 phút là điên rồ. Điều đó cho thấy họ chưa suy nghĩ thấu đáo về việc này

• Tôi đang vận hành một dịch vụ proxy chống kiểm duyệt dùng tệp Proxy Auto-Configuration (PAC)

  • Nếu tệp chứa JS lỗi, hoặc kích thước vượt quá 1MB, thì khi được cấu hình ở cấp toàn hệ thống, sẽ xảy ra vấn đề là mọi ứng dụng đều liên tục gửi request đến máy chủ
  • Điều này đã dẫn đến việc máy chủ của tôi bị DDoS và IP bị chặn ở cấp độ BGP
  • Có hơn 500.000 người dùng sử dụng mỗi ngày. Web server của tôi chạy trên VPS $20/tháng với lưu lượng không giới hạn. Nhờ vậy tôi đã không rơi vào tình huống như OP