Trước khi ký SLA 99,9%: tính ngân sách downtime, chuỗi phụ thuộc và cái giá của failover

Cuộc họp gần xong thì người phụ trách mua hàng bên khách hỏi: “Bên anh cam kết 99,9% được không?”. Cả phòng nhìn về phía bạn, vì bạn là người dựng hệ thống. Bạn có thể gật đầu ngay vì con số nghe khá an toàn, hoặc xin mười phút để tính.

Với một FDE, đây là lúc kỹ năng kỹ thuật biến thành cam kết trên hợp đồng. Gật đầu sai thì đội bạn trả giá bằng những đêm trực và một khách hàng mất niềm tin. Tính đúng thì bạn biết chính xác cần thêm gì vào kiến trúc, hoặc cần sửa câu chữ nào trong hợp đồng.

Bài này đi qua đúng mười phút đó: đổi phần trăm ra phút, nhân availability qua chuỗi phụ thuộc, rồi quyết định failover và replication ở đâu.

99,9% thật ra là 43 phút mỗi tháng

AWS định nghĩa availability là tỉ lệ thời gian một workload dùng được trên tổng thời gian, tính trong một chu kỳ như tháng hoặc năm. Vì thế việc đầu tiên là đổi phần trăm ra đơn vị con người hiểu được.

Theo công cụ tính uptime.is, mức 99,9% tương ứng khoảng 43 phút 50 giây downtime mỗi tháng và 8 giờ 45 phút 57 giây mỗi năm. Chia nhỏ hơn, bạn có khoảng 10 phút 5 giây mỗi tuần và chỉ 1 phút 26 giây mỗi ngày.

Con số theo ngày mới là con số đáng nhớ. Một lần deploy làm service khởi động lại mất hai phút đã tiêu hết ngân sách của một ngày. Google SRE gọi khoản này là error budget, tức thước đo khách quan cho mức độ không tin cậy mà dịch vụ được phép có. Đã là ngân sách thì phải lên kế hoạch chi tiêu.

Cũng cần biết 99,9% nằm ở đâu trên thang đo. AWS xếp mức này cho các công cụ nội bộ như quản lý tri thức hay theo dõi dự án, còn thương mại điện tử và hệ thống bán hàng tại quầy được xếp ở 99,95%.

Nếu khách đang dựng một hệ thống thanh toán mà chỉ hỏi 99,9%, đó là dấu hiệu nên hỏi lại kỳ vọng thật của họ.

Chuỗi phụ thuộc ăn mòn cam kết thế nào?

Thử hình dung bạn triển khai một công cụ tra cứu tài liệu nội bộ cho khách. Cấu trúc tối giản gồm một app server và một database, mỗi thứ chạy một máy, mỗi thứ đạt 99,9%. Request nào cũng phải đi qua cả hai, nên đây là hai phụ thuộc cứng nối tiếp.

Availability nối tiếp bằng tích của các thành phần. System Design Primer tính sẵn: hai thành phần 99,9% nối tiếp chỉ còn 99,8%. Tự nhân tiếp, ngân sách downtime tăng gấp đôi, khoảng 1 giờ 27 phút mỗi tháng. Bạn chưa thêm gì mà đã vượt cam kết.

Chuỗi càng dài thì càng tệ. AWS đưa ví dụ ba thành phần 99,99% nối tiếp chỉ còn 99,97%. Ngoài đời, chuỗi của bạn còn có DNS, load balancer, dịch vụ xác thực của khách, và có thể cả một API bên thứ ba. Mỗi mắt xích đều phải nằm trong phép nhân.

Cách sửa là dư thừa độc lập. Theo AWS, hai thành phần độc lập chạy song song, mỗi cái 99,9%, cho availability hiệu dụng 99,9999%, vì hệ chỉ sập khi cả hai cùng sập.

Phương án	Availability ước tính	Downtime mỗi tháng (ước tính)
1 app + 1 database	99,8%	khoảng 1 giờ 27 phút
1 app + 2 database song song	khoảng 99,8999%	khoảng 43 phút 53 giây
2 app + 2 database song song	khoảng 99,9998%	vài giây

Dòng giữa là bài học chính. Nhân đôi database là chưa đủ, vì app server đơn lẻ ở mức 99,9% vẫn kéo cả hệ xuống ngay dưới cam kết. Thành phần đơn lẻ yếu nhất quyết định con số của bạn.

Dòng cuối thì đừng tin vội. Phép tính giả định hai bản sao hỏng độc lập và việc chuyển đổi xảy ra tức thì. Hai database cùng rack, cùng bản vá lỗi thì không độc lập. Còn việc chuyển đổi tức thì phụ thuộc vào cách bạn làm failover.

Failover và replication mua được gì, mất gì?

System Design Primer mô tả failover và replication là hai mẫu hình bổ trợ nhau để đạt high availability. Failover quyết định ai phục vụ khi một node chết. Replication quyết định node thay thế có dữ liệu mới nhất hay không.

Với mô hình active-passive, hai máy trao đổi heartbeat. Khi heartbeat đứt, máy passive nhận địa chỉ IP của máy active và tiếp tục phục vụ. Downtime trong lúc chuyển phụ thuộc vào việc máy passive là hot standby, đang chạy sẵn, hay cold standby, phải khởi động từ đầu.

Đây là chỗ ngân sách theo ngày trở nên thực tế. Một cold standby mất vài phút để lên là đã đốt hết hơn một ngày ngân sách cho mỗi lần sự cố. Trước khi ghi “có failover” vào tài liệu kiến trúc, hãy đo xem nó thực sự mất bao lâu.

Failover còn có giá khác. Nó cần thêm phần cứng, thêm độ phức tạp, và có thể mất dữ liệu nếu máy active hỏng trước khi dữ liệu mới kịp replicate sang máy passive. Với khách ghi đơn hàng hay hồ sơ, mất vài giây dữ liệu có thể nghiêm trọng hơn vài phút downtime, nên hãy hỏi họ điều nào đáng sợ hơn.

Ở đầu xa nhất là pattern Geode mà Microsoft mô tả: triển khai active-active ở nhiều vùng địa lý, dùng data replication để chịu được sự cố cả một vùng. Với cam kết 99,9% cho công cụ nội bộ, đó thường là quá mức cần thiết.

Còn một đòn bẩy hay bị quên là thời gian khôi phục. AWS cho biết có thể ước lượng availability từ MTBF, thời gian trung bình giữa hai lần hỏng, và MTTR, thời gian trung bình để sửa.

Với MTBF 150 ngày và MTTR 1 giờ, con số ước tính là 99,97%. Giảm MTTR bằng runbook, cảnh báo tốt và rollback tự động đôi khi rẻ hơn mua thêm máy.

Câu chữ trong hợp đồng quan trọng ngang kiến trúc

Cùng một hệ thống, hai cách định nghĩa SLA có thể cho hai kết quả khác hẳn nhau. Điểm đầu tiên cần soi là bảo trì có kế hoạch. Có khách chọn loại nó khỏi tổng thời gian, nhưng AWS nói rõ là không nên, vì người dùng vẫn muốn dùng dịch vụ lúc đó.

Lời khuyên thực tế: nếu khách là người đề xuất loại trừ, bạn có thêm chỗ thở. Nhưng đừng thiết kế hệ thống dựa vào khoảng thở đó. Nếu bảo trì hàng tháng cần một giờ dừng hệ thống, bạn đang có vấn đề kiến trúc chứ không phải vấn đề hợp đồng.

Điểm thứ hai là đơn vị đo. AWS gợi ý với nhiều service, đếm request thành công trên tổng request hợp lệ dễ hơn đo “thời gian dùng được”, thường theo cửa sổ 1 hoặc 5 phút. Cách này phản ánh trải nghiệm người dùng tốt hơn, nhưng bạn phải thống nhất với khách thế nào là request hợp lệ và thế nào là thất bại.

Năm bước trong mười phút đó

Quay lại cuộc họp. Trước hết, đổi con số khách hỏi ra phút theo ngày và theo tháng, rồi nói to lên để cả phòng cùng hiểu. Tiếp theo, vẽ chuỗi phụ thuộc cứng trên bảng, kể cả những thứ thuộc về khách như hệ thống đăng nhập.

Bước ba là nhân availability nối tiếp để tìm điểm yếu, rồi đề xuất dư thừa đúng chỗ đó. Bước bốn, hỏi khách sợ downtime hay sợ mất dữ liệu hơn để chọn hot standby hay cold standby và cách replicate. Bước cuối là chốt định nghĩa đo trên văn bản trước khi chốt con số.

Những lỗi hay gặp

Lỗi phổ biến nhất là cam kết bằng availability của riêng phần mình viết, quên các phụ thuộc. Lỗi thứ hai là nhân đôi một thành phần rồi tin con số 99,9999% mà không kiểm tra hai bản sao có thật sự độc lập. Lỗi thứ ba là có failover trên giấy nhưng chưa bao giờ đo thời gian chuyển đổi thật.

Nếu bạn đang chuẩn bị ứng tuyển FDE, hãy tìm trong JD những cụm như “own production deployments” hay “customer-facing SLAs”. Trong CV, một dòng như “tính lại SLA cho hệ thống ba thành phần, thêm hot standby cho database, đo failover dưới một phút” thuyết phục hơn nhiều so với “có kinh nghiệm high availability”.

Bài tập tuần này: chọn một hệ thống bạn đang vận hành, vẽ chuỗi phụ thuộc, nhân ra con số tổng, rồi tự hỏi liệu bạn có dám ký 99,9% cho nó không. Nếu câu trả lời là không, bạn đã biết chính xác phải sửa mắt xích nào.