Netflix chuyển lên đám mây AWS trong bảy năm (2008–2016): xây lại theo kiến trúc cloud-native thay vì "lift-and-shift"
Sau sự cố hỏng cơ sở dữ liệu tháng 8/2008 làm ngừng giao đĩa DVD ba ngày, Netflix chọn rời trung tâm dữ liệu riêng để sang AWS. Họ không chép nguyên hệ thống mà xây lại theo kiến trúc microservice, chuyển đổi dần suốt bảy năm và tắt những thành phần cuối vào đầu 2016. Một ví dụ di chuyển nền tảng thành công, với chiến lược theo đợt và bài học về thay đổi cách làm việc.
Bối cảnh thực tế
Tháng 8/2008, một sự cố hỏng cơ sở dữ liệu khiến Netflix không thể giao đĩa DVD trong ba ngày. Công ty nhận ra mô hình tập trung dựa trên trung tâm dữ liệu riêng chứa nhiều điểm lỗi đơn lẻ, và quyết định chuyển sang các hệ thống phân tán trên đám mây. Netflix chọn Amazon Web Services vì quy mô và độ rộng dịch vụ.
Theo bài viết đội ngũ Netflix đăng khi hoàn tất (2016):
- Công ty không chép nguyên hệ thống cũ lên đám mây mà xây lại gần như toàn bộ công nghệ theo hướng cloud-native: từ một ứng dụng nguyên khối thành hàng trăm microservice, dùng mô hình dữ liệu phi chuẩn hoá trên cơ sở dữ liệu NoSQL.
- Cách vận hành đổi từ phê duyệt ngân sách, điều phối phát hành tập trung và vài tuần cấp phát phần cứng sang phân phối liên tục và công cụ tự phục vụ cho các đội tự chủ.
- Các dịch vụ hướng khách hàng chuyển trước 2015; hạ tầng thanh toán và quản lý dữ liệu khách hàng, nhân viên là phần xử lý sau cùng.
- Đầu tháng 1/2016, sau bảy năm, Netflix tắt các thành phần trung tâm dữ liệu cuối cùng phục vụ streaming; việc phân phối video vẫn dựa vào mạng phân phối nội dung riêng Open Connect.
Cùng thời gian, số hội viên streaming tăng khoảng tám lần so với 2008. Bài viết nhấn mạnh tiết kiệm chi phí là lợi ích phụ, không phải mục tiêu chính; mục tiêu là khả năng mở rộng và độ sẵn sàng, tiến gần mục tiêu bốn số chín (99,99%) dù những năm đầu có trục trặc.
Phân tích vì sao dự án thành công theo chuẩn PMP
Mục tiêu kinh doanh rõ ràng từ sự cố gốc (Business Case, Benefits)
Động lực là loại bỏ điểm lỗi đơn lẻ và có khả năng mở rộng, không phải "chuyển lên cloud cho hợp thời". Mục tiêu rõ ràng giúp mọi quyết định thiết kế (ví dụ chấp nhận xây lại) được đánh giá bằng cùng một thước.
Chiến lược chuyển đổi theo đợt dài hạn (Phased Delivery, Program Management)
Chuyển từng dịch vụ theo thứ tự rủi ro, giữ phần nhạy cảm như thanh toán đến cuối. Chương trình bảy năm vẫn chạy được vì dịch vụ cũ và mới cùng tồn tại, mỗi bước đều có lợi ích riêng.
Quản lý thay đổi tổ chức đi cùng với công nghệ (Change Management)
Cách làm việc đổi từ phê duyệt tập trung sang đội tự chủ có công cụ tự phục vụ. Đây là phần ít công nghệ nhất nhưng quyết định hiệu quả của kiến trúc mới.
Kiểm thử khả năng chịu lỗi như một thực hành thường xuyên (Quality, Risk)
Các bài diễn tập lỗi trên môi trường thật (Simian Army) biến rủi ro từ "chờ xảy ra" thành "luyện tập thường xuyên", phù hợp tinh thần giảm thiểu rủi ro bằng kiểm thử liên tục.
PM có thể áp dụng gì cho dự án di chuyển của mình
- 1
Bước 1: Chọn chiến lược di chuyển theo mục tiêu, không theo thói quen
Trước khi chọn lift-and-shift hay xây lại, đánh giá mục tiêu kinh doanh của từng hệ thống:
- Chép nguyên (rehost)
Hệ thống ổn định, ít thay đổi, mục tiêu là rời trung tâm dữ liệu đúng hạn; chấp nhận mang theo vấn đề cũ.
- Xây lại (re-architect)
Hệ thống là lợi thế cạnh tranh, cần mở rộng và chịu lỗi tốt; đầu tư đáng giá nếu có đội đủ năng lực.
- Chép nguyên không giảm nợ
Mang nguyên nhược điểm sang cloud mà không có lộ trình cải thiện: chi phí vận hành cao hơn mà không có lợi ích.
- Chép nguyên (rehost)
- 2
Bước 2: Lập thứ tự chuyển đổi theo rủi ro và giá trị
Bắt đầu bằng dịch vụ ít rủi ro để học, giữ hệ thống nhạy cảm đến sau khi đội và công cụ đã trưởng thành.
- 3
Bước 3: Gắn thay đổi tổ chức vào kế hoạch dự án
Lên kế hoạch cho cách phát hành, trách nhiệm trực vận hành và công cụ tự phục vụ cùng với kế hoạch kỹ thuật.
PM Takeaway (Bài học rút ra)
Di chuyển nền tảng thành công khi bắt đầu từ lý do kinh doanh, chia nhỏ theo đợt và thay đổi cả cách làm việc của tổ chức. Chép nguyên hệ thống chỉ chuyển vấn đề sang chỗ mới.
Nguồn tham khảo
Nguồn: Netflix — Completing the Netflix Cloud Migration (2016) ↗ (mở trong thẻ mới)
Trắc nghiệm tình huống PMP
Câu 1/1Bạn chọn phương án nào?
Hệ thống lõi cần lên đám mây trong 12 tháng. Bạn ưu tiên cách nào?
Tình huống này hữu ích với bạn?
Bình luận (0)
Tình huống cùng lĩnh vực
Avon dừng dự án SMT toàn cầu: thí điểm Canada gây gián đoạn kinh doanh và quyết định cắt lỗ khoảng 125 triệu USD phần mềm
Avon khởi động chương trình Service Model Transformation (SMT) năm 2009 để đổi hệ thống quản lý đơn hàng cho đại diện bán hàng. Năm 2013, thí điểm tại Canada gây gián đoạn đáng kể và không cho thấy lợi tức đầu tư rõ ràng, nên Avon dừng triển khai và ghi giảm giá trị phần mềm. Một ví dụ về quyết định đóng dự án sớm dựa trên kết quả thí điểm, và cái giá của việc không kiểm tra giả định lợi ích trước.
GitHub nâng cấp MySQL 8.0 cho hơn 1.200 máy chủ: cutover từng cụm, giữ đường lui và kiểm soát thay đổi trong hơn một năm
GitHub chuẩn bị từ tháng 7/2022 để chuyển toàn bộ đội máy chủ MySQL (hơn 1.200 máy, trên 50 cụm, trên 300 TB) từ 5.7 sang 8.0 mà không vi phạm cam kết dịch vụ. Điểm đáng học không nằm ở công nghệ mà ở cách quản lý: danh mục kiểm tra sẵn sàng, đưa 8.0 vào CI, nâng cấp từng bước và luôn giữ khả năng quay về 5.7.
FBI Virtual Case File: 170 triệu USD, 700.000 dòng mã và bài học về kiểm soát thay đổi tích hợp
Sau sự kiện 11/9, FBI đặt cược vào hệ thống quản lý hồ sơ vụ án Virtual Case File. Bốn năm, năm đời CIO và khoảng 400 yêu cầu thay đổi sau, dự án bị huỷ năm 2005 với khoảng 105 triệu USD mã không dùng được. Phân tích dưới góc Quản lý tích hợp và những gì PM lẽ ra phải làm.