Phân tích hậu sự cố ngừng dịch vụ Tarsnap

• Máy chủ trung tâm của Tarsnap bị dừng tại Amazon EC2 us-east-1 do failed system status check, khiến dịch vụ bị gián đoạn khoảng 26 giờ 16 phút kể từ khoảng 2023-07-02 13:07:58 UTC
• Sự cố được phát hiện lúc 13:10 UTC, nhưng sau một lần khởi động lại ngoài dự kiến, chính sách vận hành yêu cầu con người trực tiếp kiểm tra nên đã tắt tự động khởi động mã máy chủ
• Việc khôi phục được thực hiện bằng cách đọc header metadata từ hệ thống tệp cấu trúc log trên Amazon S3 và phát lại tuần tự các tác vụ ở máy cục bộ; giai đoạn đầu hoàn tất vào 2023-07-03 01:49:49 UTC
• Trong quá trình tái dựng trạng thái, đã lộ ra một trường hợp chưa được kiểm chứng của xử lý machine re-owned được viết từ năm 2014, cùng với việc bỏ sót khởi tạo logic tiếp tục chạy; giới hạn thông lượng đĩa cũng làm chậm việc khôi phục
• Dù Tarsnap không có SLA rõ ràng, theo chính sách cấp credit cho các sự cố được xem là công bằng, ngày 2023-07-13 công ty đã cấp 50% credit chi phí lưu trữ của một tháng cho mọi tài khoản

---

Sự cố xảy ra và phản ứng ban đầu

• Khoảng 2023-07-02 13:07:58 UTC, máy chủ trung tâm của Tarsnap bị offline tại region Amazon EC2 us-east-1
  • Trạng thái EC2 là failed system status check
  • Với máy ảo, trạng thái này có thể chỉ ra nhiều nguyên nhân như mất điện, lỗi phần cứng máy chủ vật lý, hoặc sự cố mạng EC2
  • Không thấy báo cáo sự cố EC2 diện rộng vào cùng thời điểm, nên khả năng cao nhất được cho là lỗi phần cứng cục bộ
• Hệ thống giám sát phát hiện sự cố lúc 2023-07-02 13:10 UTC
  • Việc giám sát được thực hiện bằng cách ghi, đọc và xóa archive mỗi 5 phút từ một region EC2 khác
  • Cảnh báo SMS lúc 13:10 UTC không đánh thức được người vận hành, nhưng cảnh báo cuộc gọi lúc 13:15 UTC đã bắt đầu quá trình ứng phó
  • Điều tra ban đầu không cho thấy lỗi tạm thời rõ ràng, nên kết luận rằng hệ thống đã chết và bắt đầu chuẩn bị một EC2 instance thay thế

Nguyên tắc vận hành tránh tự động khởi động lại

• Khoảng 2023-07-02 13:52 UTC, Amazon khởi động lại máy chủ gặp sự cố trên một EC2 instance mới
  • Đây là khoảng 45 phút sau khi sự cố bắt đầu
  • Hệ điều hành FreeBSD đã khởi động, nhưng mã máy chủ Tarsnap không tự động chạy
• Lý do tắt tự động khởi động là để tự tay xác nhận trạng thái trước khi nhận lưu lượng sau một lần khởi động lại ngoài dự kiến
  • Theo nguyên tắc vận hành, “ngăn mất dữ liệu khi có thứ gì đó bị hỏng” quan trọng hơn “tối đa hóa tính sẵn sàng của dịch vụ”
• Sau khi khởi động lại, log máy chủ cho thấy có hỏng hệ thống tệp
  • Điều này được xem là cho thấy nguyên nhân sự cố либо đã làm hỏng phần cứng, либо đã ngắt kết nối giữa máy chủ và Elastic Block Store chứa hệ thống tệp
  • Nhóm vận hành quyết định tiếp tục cấu hình máy chủ mới thay vì cố khôi phục máy chủ cũ

Cấu trúc log trên S3 và quy trình khôi phục

• Dịch vụ Tarsnap lưu trữ dữ liệu trên Amazon S3 dưới dạng hệ thống tệp cấu trúc log
  • Mỗi đối tượng S3 chứa một header mang metadata của toàn bộ các mục log và, nếu có, cả dữ liệu của mục log
  • Mục log start write transaction chỉ có header nhận diện máy và transaction nonce, không có dữ liệu log
  • Mục log store data block có cả header nhận diện máy và tên block, cùng với dữ liệu block
• Ở trạng thái bình thường, metadata của các mục log được cache trên EC2 và không được đọc lại từ Amazon S3
  • Việc đọc Amazon S3 chỉ xảy ra khi cần đọc dữ liệu block để phản hồi yêu cầu từ client tarsnap
• Việc khôi phục trạng thái của EC2 instance được chia thành hai giai đoạn
  • Trước tiên đọc toàn bộ header metadata từ S3
  • Sau đó phát lại (replay) toàn bộ tác vụ trên máy cục bộ
  • Trong kho lưu trữ cấu trúc log, khi xóa dữ liệu thì các mục log sẽ được ghi lại để giải phóng dung lượng, nên không thể thực hiện đồng thời hai giai đoạn này
  • Các mục log có số thứ tự để có thể phát lại theo đúng trình tự, nhưng sau khi tìm thấy vẫn phải sắp xếp trước

Các lỗi và điểm nghẽn lộ ra trong quá trình khôi phục

• Giai đoạn đầu diễn ra suôn sẻ và hoàn tất vào 2023-07-03 01:49:49 UTC
  • Tiến trình khôi phục được cấu hình gửi 250 yêu cầu đồng thời tới Amazon S3
  • Giá trị này được đặt theo mức Amazon S3 có thể chịu được từ 10 năm trước, và hiện nay có lẽ đã có thể tăng cao hơn đáng kể
• Giai đoạn hai gần như thất bại ngay lập tức
  • Xuất hiện lỗi cho biết mục log được phát lại đang ghi dữ liệu thuộc về một máy không tồn tại
  • Nguyên nhân là mã xử lý việc chuyển máy giữa các tài khoản được viết vào năm 2014
  • Khi người dùng Tarsnap cần chuyển máy giữa các tài khoản, hệ thống lưu một mục log machine registration mới và xóa mục cũ
  • Dù đã có kiểm thử, vẫn thiếu trường hợp tái dựng trạng thái máy chủ sau khi một máy đã bị re-owned trong lúc đã có dữ liệu được lưu
  • Vì số thứ tự của mục đăng ký máy mới cao hơn, nên trong quá trình replay nó trông như thể dữ liệu đang được ghi cho một máy chưa tồn tại
• Sau khi xác định nguyên nhân, nhóm vận hành tắt “seatbelt” tương ứng và tiếp tục tái dựng trạng thái
  • Sau đó lập tức lại gặp lỗi không tìm thấy dữ liệu trên Amazon S3
  • Nguyên nhân là trong lần thử tiếp tục, bước tải dữ liệu từ S3 đã bị bỏ qua nhưng giá trị maximum log entry sequence number không được khởi tạo lại, nên vẫn là 0
  • Sau khi sửa lỗi này, việc tái dựng trạng thái tiếp tục bình thường
• Việc tái dựng trạng thái diễn ra chậm hơn mức cần thiết
  • Nếu sớm nhận ra thông lượng đĩa là điểm nghẽn, có thể đã tăng thông lượng cho volume EBS liên quan
  • Do thiếu ngủ, người vận hành không theo dõi tiến trình đủ sát; nếu không thì có thể đã phát hiện điểm nghẽn qua gstat(8) và Amazon CloudWatch để cấu hình lại volume EBS

Khôi phục dịch vụ và cấp credit

• Khoảng 2023-07-03 15:10 UTC, tiến trình tái dựng trạng thái hoàn tất
  • Không có ghi chép về thời điểm hoàn tất chính xác
  • Máy chủ được đặt ở chế độ chỉ đọc và thực hiện kiểm tra nhanh
  • So với trạng thái của máy chủ cũ, xác nhận rằng dữ liệu khớp nhau ngoại trừ vài giây dữ liệu cuối cùng mà hệ thống tệp của máy cũ đã mất tại thời điểm sự cố
• Lưu lượng sản xuất thực tế đầu tiên sau sự cố xuất hiện lúc 2023-07-03 15:25:58 UTC
  • Đây là thời điểm sau khoảng 26 giờ 16 phút kể từ khi sự cố bắt đầu
• Tarsnap không có SLA rõ ràng, nhưng áp dụng chính sách cấp credit cho các sự cố được xem là hợp lý
  • Ngày 2023-07-13, mọi tài khoản Tarsnap được cấp 50% chi phí lưu trữ của một tháng dưới dạng credit
  • Việc cấp credit được thực hiện sau khi xử lý xong sự cố và nghỉ ngơi

[GN⁺]

Ý kiến trên Hacker News

• Tôi thật sự không ngờ bài này lại lên đầu HN. Tôi muốn trả lời các câu hỏi, nhưng giờ đã 10 giờ tối, con tôi lại ngủ từ 5 giờ chiều, nên nếu may mắn thì có lẽ tôi ngủ được khoảng 4 tiếng trước khi cháu thức dậy
  Sáng mai tôi sẽ kiểm tra lại và trả lời các câu hỏi

  • Tôi tò mò lý do vì sao nên dùng dịch vụ này thay vì restic. Rất cảm ơn Colin, nhưng đọc bài này thì có vẻ người chịu trách nhiệm hạ tầng của dịch vụ này trên thực tế chỉ có một người
    Việc nói rõ là không có SLA thì tốt, nhưng tôi có cảm giác có một rủi ro lớn chen vào giữa tôi và các bản sao lưu của tôi
  • Nếu sau này anh lại viết phân tích hậu sự cố, dù tất nhiên tôi mong là rất hiếm hoặc không bao giờ có, thì sẽ tốt hơn nếu ghi rõ những bài học rút ra để thấy mục nào vì sao sẽ không lặp lại nữa
  • Một bản phân tích hậu sự cố thật sự được viết rất tốt và chu đáo, nhưng tôi hy vọng sẽ không bao giờ phải thấy bài như thế này nữa :)
  • Đã đến lúc giao hỗ trợ 24/7 cho con anh rồi ;)
    Tôi đã đọc https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... và thấy cũng có hiệu quả phần nào. Có thể tìm thấy ở bất kỳ thư viện nào, tức kiểu Blockbuster dành cho sách
  • Tôi tò mò transaction log được giữ trong bao lâu trước khi bị ghi đè
    Vài tuần gần đây tôi cũng gặp vài instance EC2 bị sập với triệu chứng như bị ngắt khỏi EBS, trường hợp của tôi là ở eu-west

• Theo chính sách khá mơ hồ rằng “Tarsnap không có SLA, nhưng sẽ cấp credit cho sự cố nếu thấy công bằng”, việc Percival đã cộng vào tài khoản Tarsnap của mọi người 50% chi phí lưu trữ một tháng vào ngày 2023-07-13 cho thấy rõ anh ấy là người như thế nào
  Khoản credit này có vẻ khá hào phóng theo hướng bồi thường đủ cho khách hàng, và khác với các nhà cung cấp cloud lớn, họ cũng không bắt từng khách hàng phải đến năn nỉ riêng. Hơn nữa còn có một bản phân tích hậu sự cố rõ ràng, mang tính kỹ thuật và chi tiết. Tôi nghĩ nơi nào cũng nên làm như vậy

  • Câu “cảm ơn vì đã là ngọn hải đăng trong bóng tối” rất đúng
    Tôi khá vui khi được sống trong một thế giới nơi Tarsnap tồn tại và được định giá theo đơn vị picodollars

• Nếu quy trình khôi phục sau thảm họa được thiết lập và kiểm thử đúng cách, thời gian downtime đã có thể giảm đi nhiều
  Cần có một hệ thống staging hoàn toàn tách biệt, có thể hạ xuống rồi dựng lại, kiểm thử định kỳ nhiều chế độ lỗi khác nhau và tài liệu hóa toàn bộ các bước chi tiết để khôi phục hệ thống
  Về dài hạn, cũng đáng cân nhắc liệu có thể tăng doanh thu để thuê nhân sự bán thời gian, điều sẽ giúp ích rất nhiều nếu chuyện tương tự xảy ra
  Chúng tôi cũng là một nhà cung cấp giải pháp cloud nhỏ và tập trung vào ML API; qua từng năm, ngày càng rõ rằng khi dùng phần cứng cloud, dù dedicated hay virtual, sự cố vẫn sẽ xảy ra định kỳ. RAM, HDD hoặc các linh kiện phần cứng khác có thể hỏng bất cứ lúc nào, nên về lâu dài, khi vận hành dịch vụ online có tính sẵn sàng cao, điều này phải được tính đến 100%

• Xin bày tỏ sự kính trọng vì bản phân tích hậu sự cố trung thực và cách xử lý tốt trong một tình huống khó khăn. Tuy nhiên, về chuyện thiếu ngủ, nếu chỉ có một người có thể sửa vấn đề, thì không cần phải xấu hổ khi chấp nhận thêm một chút thời gian gián đoạn để giữ đầu óc tỉnh táo
  Đi ngủ một lát trong lúc báo động đang reo nghe có vẻ kỳ lạ, nhưng khi adrenaline cộng với thiếu ngủ, rất dễ làm vấn đề tệ hơn

  • Không cần lo đâu, tôi đã chợp mắt vài lần ở giữa. “Việc này có vẻ đang chạy ổn, nhưng sẽ mất thêm vài giờ, nên mình sẽ đặt báo thức sau 2 tiếng và ngủ một chút” là một trong những lý do khiến tôi không nhận ra bước thứ hai đang bị nghẽn I/O một cách không cần thiết

• Chỉ dựa trên phần mô tả, quá trình khôi phục này có vẻ tương đối dễ kiểm thử định kỳ, và có lẽ có thể bắt được các bug còn sót hoặc đánh giá thời gian khôi phục
  Như người ta thường nói, chỉ bản backup đã được kiểm thử mới là backup thật sự

  • Với tư cách người chỉ sau khi kiểm thử mới biết quy trình khôi phục sau thảm họa của mình không hoạt động, tôi đồng ý 100%. Kế hoạch duy nhất có khả năng thực sự hoạt động là kế hoạch có thể lặp lại và đã được kiểm thử
  • Đúng vậy. Tôi đã định làm một thời gian, nhưng luôn có việc khác ưu tiên cao hơn. Trước sự cố này, tôi không nhận ra là mình gần như đã không kiểm thử trong 10 năm
    Từ giờ tôi chắc chắn sẽ đặt việc diễn tập hằng năm ở mức ưu tiên cao

• Lúc nào cũng thật tốt khi thấy một bản phân tích hậu sự cố chuyên nghiệp, lịch sự và trung thực kiểu này

• Có thể đây là nói dựa trên thông tin cũ về công ty Tarsnap, nhưng yếu tố duy nhất khiến tôi do dự khi nghiêm túc dùng Tarsnap là một sự cố Colin Percival bất ngờ, tức rủi ro nhân sự chủ chốt
  Tôi nghĩ không chỉ mình tôi như vậy

  • Nó tương tự phép tính về thời gian trung bình giữa các lần hỏng hóc. Vấn đề là nên tin vào một giải pháp được thiết kế tốt của một công ty một người, ít bộ phận chuyển động và được thiết kế tốt, hay tin vào một giải pháp của một công ty lớn hơn nhiều nhưng có nhiều bộ phận chuyển động hơn nhiều và có lẽ được thiết kế kém hơn
    Cá nhân tôi sẽ chọn giải pháp đơn giản hơn. Theo kinh nghiệm của tôi, để đạt đến mức độ tin cậy của một hệ thống đơn giản thì cần thêm một lượng độ phức tạp khổng lồ, và phần lớn độ phức tạp đó làm tình hình tệ hơn
    Điều này thể hiện rõ trong clustering máy chủ. Một máy chủ đơn lẻ có nguồn điện và mạng ổn định sẽ đáng tin cậy hơn bất kỳ nỗ lực nào nhằm dự phòng hóa dịch vụ đó, cho đến khi chi phí và độ phức tạp tăng lên khoảng 5 lần. Đến mức đó mới có thời gian trung bình giữa các lần hỏng tương tự máy chủ đơn lẻ, và chỉ sau đó mới có thể cải thiện thực sự
    Tôi tin mạnh mẽ rằng con đường tốt nhất để có độ tin cậy thật sự là đơn giản nhất có thể và sao lưu tốt. Nếu cần khả dụng 24/7 quanh năm, các công nghệ có thể lựa chọn sẽ bị giới hạn khá nhiều
  • Tôi hiểu đây là rủi ro, nhưng không chắc nó nhất thiết rủi ro hơn so với một doanh nghiệp lớn hơn
    Đây là công việc của Colin, gắn với tên tuổi của Colin, và rất quan trọng với Colin
    Ở BigBackupCorp thì khó nhận được cùng loại dịch vụ như vậy. Nhân viên có thể thay thế, ban lãnh đạo cũng có thể thay thế, và nói thật thì tôi với tư cách khách hàng cũng là thứ có thể thay thế nếu công ty đổi hướng và quyết định trở thành BigFlowerArrangementShippingCorp
    Điểm hay của doanh nghiệp nhỏ là nó vận hành hoàn toàn vì lợi ích của chính nó. Không có trò thao túng giá cổ phiếu hay mánh khóe kiểu VC. Nếu đó là một doanh nghiệp có lãi, sẽ có ai đó đến mua lại, gắn tên mình vào và biến nó thành công việc của mình. Tôi nghĩ Internet mở hưởng lợi rất lớn từ những điều như thế
  • Nếu lập danh sách các đối thủ đã biến mất trước Tarsnap, phép tính có thể sẽ khác đi một chút. Rủi ro cần đánh giá không nên là “nếu có chuyện gì xảy ra với người vận hành thì sao?”, mà là “nếu có chuyện xảy ra với anh ta, dịch vụ cũng sập, và tôi cũng không có bản sao lưu của bản sao lưu thì sao?”
    Rủi ro này có thể được giảm nhỏ đến mức bạn muốn nếu lập kế hoạch cẩn thận
  • Nếu bạn theo dõi HN, có lẽ trong vòng 24 giờ bạn sẽ biết nếu Colin gặp vấn đề. Thực tế là, vấn đề thật sự chỉ xảy ra nếu kho lưu trữ chính, Tarsnap và Colin đều đồng thời thất bại trong khoảng cửa sổ 24 giờ trước khi bạn chuyển sang nhà cung cấp sao lưu mới
  • Tôi không định tin tưởng nhà cung cấp sao lưu hơn mức đó. Vì ngay khi phụ thuộc vào nó, nó sẽ thất bại vào thời điểm khó khăn nhất
    Tốt hơn là xem một dịch vụ như Tarsnap là một trong nhiều lớp, xây dựng sao lưu nhiều tầng và kiểm chứng định kỳ

• Những lỗi kiểu mục log được phát lại đang ghi dữ liệu của một máy không tồn tại có vẻ có thể bắt được nếu viết mô hình TLA+

• Dùng tổ hợp như restic+backblaze thì chi phí thấp hơn vài bậc độ lớn, nên tôi tò mò lợi ích của việc dùng Tarsnap là gì. Tôi không biết phải có nhu cầu cụ thể nào mới tạo động lực trả 3000 USD mỗi TB-năm

  • Một số người trong chúng tôi có khá dư tiền, và thích có cái cớ để đưa tiền cho cperciva để anh ấy không phải làm ở một công việc tệ hại mà có thể dùng kỹ năng và tài năng của mình cho những việc lớn hơn, tốt hơn
    Với những người hỏi về bus factor thấp: hẳn bạn sẽ không để bản sao lưu chỉ ở một dịch vụ hay một vị trí chứ? Bạn sẽ dùng Tarsnap cùng với Restic+Backblaze, Rsync.net, S3, v.v. chứ? “Sao lưu là khoản thuế trả để được hưởng sự xa xỉ mang tên khôi phục”
  • Chống trùng lặp hoạt động rất tốt, nên chi phí cho tập dữ liệu lõi cực kỳ quan trọng mà tôi sao lưu lên Tarsnap là không đáng kể. Nếu dữ liệu thay đổi thường xuyên hơn thì phép tính có lẽ sẽ khác
    Ví dụ, tôi dùng dịch vụ khác cho thư viện video và ảnh, nhưng sao lưu cơ sở dữ liệu kế toán và các tài liệu quan trọng lên Tarsnap
    Tôi đã dùng Tarsnap được 10 năm, hầu như không có vấn đề về tính khả dụng và theo tôi nhớ thì gần như không có vấn đề thuộc bất kỳ loại nào

• Nghe như phần lớn 26 giờ downtime được dùng để khôi phục bản sao lưu. Trùng hợp là đây chính xác là lý do tôi không thể dùng Tarsnap trong môi trường vận hành
  Từ góc nhìn người dùng, việc khôi phục bản sao lưu chậm đến mức khó chịu. Khi hệ thống của tôi đang offline, tôi không có kiên nhẫn chờ hàng giờ vì dịch vụ sao lưu. Có thể bây giờ đã tốt hơn, nhưng lần cuối tôi dùng vài năm trước, khôi phục bản sao lưu vài GB mất cỡ hàng giờ