Câu chuyện CTO đánh cược cả sự nghiệp, đi xuống đến cấp độ bit để hack cơ sở dữ liệu
(tech.devsisters.com)- Sự cố kéo dài 36 giờ của CookieRun: Kingdom, dài nhất trong lịch sử Devsisters
- Sử dụng CockroachDB làm DB phân tán chính: 4 node, 12TB lưu trữ, 7 bản sao
- Trong quá trình mở rộng cơ sở dữ liệu, một nửa số node bị sập
- Vì vậy đã xảy ra sự cố trên toàn bộ dịch vụ, và kỹ sư hỗ trợ phía CockroachDB đánh giá rằng không thể khôi phục
- Vì thế đây là bài viết tổng hợp những nỗ lực tự mình tìm lại dữ liệu được lưu trong storage
24 bình luận
Đây đúng là một bài viết gây tranh cãi khá nhiều nhỉ..? Không rõ ở khía cạnh dịch vụ thì sẽ thế nào, nhưng chắc những lập trình viên trực tiếp làm việc đó đã cảm thấy cực kỳ tự hào.
Không rõ phản ứng của người dùng ra sao, nhưng với tư cách là người dùng thì tôi muốn dành một lời khen vì đã cố gắng ngăn việc rollback máy chủ... Dù có thể thiệt hại còn lớn hơn nếu nghĩ đến lượng người dùng rời bỏ và trải nghiệm khách hàng trong suốt 36 giờ đó, nhưng từ góc độ lập trình viên thì tôi cho rằng đây là một thử thách thú vị. Nếu công ty đó không phải game mà là ngân hàng thì sẽ thế nào?
Nghe nói Pokémon Go dùng Spanner của GCP (https://cloud.google.com/blog/topics/…), nên đúng là trên AWS không có lựa chọn thay thế nào thực sự phù hợp.
Dựa trên tài liệu đó, khi hiểu được ý đồ của đội phát triển thì có vẻ dự án này lẽ ra không nên sử dụng CockroachDB.
Đáng lẽ nên dùng DB nào?
Tùy dịch vụ mà đây có thể là nội dung khiến người ta rợn người.
Đọc rất thú vị.
Có vẻ blog đó đã đăng một loạt bài về sự cố này. Đọc một mạch thì thấy trạng thái sụp đổ tinh thần mà những người xử lý vụ đó hẳn đã trải qua thực sự rất ấn tượng.
Tôi không chắc về mặt kinh doanh liệu việc khôi phục toàn bộ thông tin người dùng trong suốt 36 giờ có phải là quyết định đúng đắn hơn so với rollback, tức làm tổn hại trải nghiệm của một số người dùng để bảo vệ phần lớn còn lại. Nhưng xét từ góc độ nhà phát triển thì đây là những nội dung khá thú vị.
Trong phần nội dung có đoạn như thế này.
Sứ mệnh của chúng tôi là mang đến cho khách hàng trải nghiệm tốt nhất, và chúng tôi đã nỗ lực để thực sự thực hiện điều đó bằng tất cả sự chân thành. Không một ai nản lòng hay bỏ cuộc.
Thật không ngờ đến ở đây cũng phải nghe kiểu nói rằng vì tiền thì có thể bỏ rơi một bộ phận người dùng; điều đó lại một lần nữa khiến tôi cảm nhận được cách ngành game Hàn Quốc đối xử với người chơi.
Có vẻ như đó là cách nhìn quá gượng ép, và xét theo kết quả cuối cùng thì nếu không giải quyết được vấn đề, vừa lãng phí thời gian, vừa phải rollback dữ liệu, nên cũng sẽ bị oán trách thôi.
Và về quan điểm rằng nếu không thể vận hành dịch vụ thì trong khoảng thời gian đó cũng là đang bỏ rơi người dùng, điều đó cũng vẫn đúng như vậy.
Rất rất cực kỳ đồng cảm...
Từ góc nhìn của một lập trình viên, tôi đã đọc bài này với sự hứng thú rất lớn (bao gồm cả tiêu đề gây kích thích), nhưng bản thân tôi cũng nhìn nhận nó theo góc độ tương tự. Dù đây là nội dung được nhắc tới trong một bài viết đã đăng từ khá lâu nên có thể khác với thực tế, nhưng có vẻ doanh thu của CookieRun: Kingdom đã vượt 300 tỷ won, nên chắc hẳn đây là quyết định được đưa ra sau khi so sánh doanh thu kỳ vọng bị mất do 36 giờ downtime với số tiền bồi thường phải chi trả sau khi rollback.
Tôi cũng nghĩ việc đây là một tổ chức có văn hóa kỹ sư rất coi trọng giải quyết vấn đề đã phần nào tạo ảnh hưởng.
Nếu là tôi thì đến giờ tôi vẫn không chắc mình sẽ đưa ra quyết định nào.
Dạo này trong game, nhất là các game có kiểu quay gacha ngẫu nhiên, rollback thật sự là biện pháp chỉ có thể dùng trong trường hợp tệ nhất mà thôi... Trừ khi không quan tâm đến hình ảnh như game L nào đó, còn không thì gần như bất khả thi. Vì vậy trong vụ này, ngược lại, họ không rollback mà bù đắp lớn về sau, nên người chơi còn đùa với nhau kiểu “nếu thiếu tài nguyên thì máy chủ có nổ thêm lần nữa không?” nữa cơ... Cá nhân tôi cho rằng đó là một quyết định đúng đắn.
Vì là game nên nếu rollback về 36 giờ trước thì có vẻ thiệt hại tài chính do liên quan đến cash sẽ khá lớn.
Tôi nghiêng về phía cho rằng đây có lẽ không phải là một quyết định đúng đắn về mặt kinh doanh.
Lỗi cấu hình ngoài ý muốn (đây là lỗi con người ngớ ngẩn nhưng nghiêm trọng nhất. Gây ra một thao tác cực kỳ lớn kiểu này khiến bản sao không thể hoạt động, có lôi hết các nhà phát triển thiết kế DB đến thì chuyện này cũng không thể khôi phục được)
Vì vậy không thể xóa sạch toàn bộ dữ liệu được nên... đành chấp nhận bỏ tính nhất quán của dữ liệu mới nhất, rồi trực tiếp tìm dữ liệu DB ở dạng nhị phân đã được lưu cuối cùng (7 TB) và viết một chương trình go để chuyển nó sang csv... ?
Việc làm chương trình go chuyển đổi này thì dù có làm tốt đến đâu cũng có ý nghĩa gì không nhỉ..
Phù.. chỉ nghĩ thôi cũng đã thấy bức bối rồi. Tại sao lại phải đến mức này chứ..
Có lẽ quan trọng nhất vẫn là siết chặt quy trình để không xảy ra những lỗi con người như thế này. Đừng kể chuyện đã khổ sở thế nào vì phải chuyển đổi nhị phân trong lúc xử lý sự cố.
Có lý do gì khác để không nên kể những câu chuyện như thế này sao? Bản thân việc công khai bản postmortem đã có ý nghĩa rồi.
Theo tôi thấy, nếu viết một bài thực sự hữu ích thì có lẽ tiêu đề nên là thế này phải không?
"Phân tích nguyên nhân và bài học từ lỗi không thể tạo cluster do cấu hình node sai"
Những chuyện như vậy có thể viết thành bài riêng; còn “phân tích nguyên nhân sự cố” và “quá trình xử lý sự cố” là hai chủ đề tách biệt, và cả hai đều quan trọng, nên thật khó hiểu khi hạ thấp giá trị bài viết chỉ vì không có phần “phân tích nguyên nhân sự cố”...
Bạn hoàn toàn có thể nói rằng sẽ còn tốt hơn nếu tác giả viết thêm một bài tiếp theo về phân tích nguyên nhân, nhưng nói rằng bài viết không có giá trị ngay từ trước đó thì không phải là một thái độ tốt.
Nói chính xác thì đây không phải là "quá trình khắc phục sự cố", mà là quá trình "cày tay để khôi phục dữ liệu không hoàn chỉnh". Chỉ là giảm được phần nào phạm vi tổn thất? Cỡ vậy thôi.
Trong bài trên có chỗ nào nói việc khôi phục dữ liệu là “không hoàn chỉnh” vậy? Ít nhất thì theo nội dung bài trên, họ đã thành công trong việc khôi phục hoàn toàn mà. Và nếu việc khôi phục DB đã bị làm hỏng đó không phải là xử lý sự cố thì còn là gì nữa? Sau sự việc đó, dịch vụ tương ứng có ngừng vận hành luôn không?
Đó đâu phải là lý do để không kể câu chuyện này chứ?
Sống trên đời mà anh vất vả quá nhỉ