Hành trình quản lý chi phí AWS của đội phát triển AB180: Từ kiểm tra hóa đơn đến văn hóa FinOps

Được Gemini tóm tắt.

--

Trong quá trình vận hành 'Airbridge', một giải pháp đo lường hiệu quả marketing xử lý khối lượng dữ liệu khổng lồ, chúng tôi đã xây dựng văn hóa quản lý chi phí AWS (FinOps) một cách có hệ thống. Xin chia sẻ những kinh nghiệm và bí quyết đã tích lũy trong quá trình đó.

Cách AB180 vận hành quản lý chi phí:
Để thực sự "quản lý" chi phí, chúng tôi vận hành quy trình sau.

• Bảng điều khiển dựa trên Google Sheets: Chúng tôi xây dựng dashboard bằng Google Sheets để có thể dễ dàng xử lý và chia sẻ dữ liệu. Không chỉ hiển thị tình hình chi phí theo từng tag, hệ thống còn hiển thị cả lượng dữ liệu thu thập có ảnh hưởng trực tiếp đến chi phí, giúp nhận biết nguyên nhân biến động một cách trực quan. Ngoài ra, chúng tôi trực quan hóa tình trạng coverage của Savings Plan và mô phỏng trước kết quả khi thay đổi hợp đồng để hỗ trợ ra quyết định hợp lý.
• Kiểm tra chi phí định kỳ và tự động hóa: Cứ mỗi 2 tuần, chúng tôi rà soát các biến động chi phí qua một cuộc họp ngắn khoảng 30 phút. Các công việc lặp lại như tạo tài liệu họp, gửi thông báo Slack, viết biên bản cuộc họp đều được tự động hóa tối đa để nâng cao hiệu quả. Nếu biến động chi phí lớn, người phụ trách sẽ phân tích nguyên nhân và chia sẻ qua bình luận trong Google Sheets để đảm bảo tính minh bạch.
• Ước tính chi phí trước khi phát triển: Khi phát triển tính năng mới hoặc thay đổi kiến trúc, chúng tôi bắt buộc phải đưa ra chi phí dự kiến trong tài liệu 'Tech Spec'. Nhờ đó, ngay từ giai đoạn phát triển, chúng tôi có thể đưa ra các quyết định kỹ thuật tốt hơn với chi phí được cân nhắc trước.

Quá trình nâng cấp hệ thống quản lý chi phí:
Hệ thống hiện tại không được tạo ra chỉ sau một đêm. Nó đã phát triển qua các giai đoạn sau.

• Phase 0 (Kiểm tra hóa đơn): Ban đầu, chúng tôi chỉ dừng ở mức kiểm tra hóa đơn hàng tháng.
• Phase 1 (Phân loại tối thiểu): Chúng tôi bắt đầu phân loại tài nguyên ở mức tối thiểu bằng cách sử dụng tag Name.
• Phase 2 (Nâng cấp chiến lược tag): Chúng tôi thiết lập chiến lược tag dựa trên chính sách rõ ràng như Team, Service. Chỉ phát hành hướng dẫn là chưa đủ, vì vậy chúng tôi liên kết với chính sách IAM để bắt buộc thiết lập tag, đồng thời xây dựng cơ chế gửi cảnh báo tự động qua bot Slack đối với tài nguyên không có tag. Kết quả là chi phí từ tài nguyên không gắn tag được kiểm soát ở mức dưới 1% tổng chi phí.

5 bài học rút ra từ hành trình đã qua:

• Engineering phù hợp với bối cảnh là điều quan trọng. Thay vì theo đuổi một hệ thống hoàn hảo để kiểm soát chi phí, sẽ khôn ngoan hơn nếu từng bước xây dựng một cơ chế quản lý ở mức "phù hợp" với quy mô và tình hình của công ty.
• "Kiểm soát" và "tối ưu hóa" chi phí là hai việc khác nhau. "Kiểm soát" là nâng cao khả năng dự đoán chi phí, còn "tối ưu hóa" là giảm chính chi phí đó. Cần xác định rõ nên tập trung vào điều gì tùy theo mức độ ưu tiên của từng tình huống.
• Cần mạnh dạn tự động hóa. Không chỉ tự động hóa công việc lặp đi lặp lại đơn thuần, nếu xây dựng được môi trường "self-serve" để đồng nghiệp có thể tự tra cứu dữ liệu và xác định vấn đề, năng suất sẽ được tối đa hóa.
• Cần tạo ra "cơ chế". Thay vì chỉ nói "hãy gắn tag cho tốt", sẽ hiệu quả hơn nếu thiết kế các "thiết bị/cơ chế" khiến mọi người buộc phải tuân thủ chính sách, chẳng hạn như không có tag thì không được cấp quyền cho tài nguyên.
• FinOps cuối cùng là "văn hóa". Điều quan trọng nhất là liên tục nỗ lực và xây dựng văn hóa để mọi người nhận thức rằng quản lý chi phí không phải việc của riêng một cá nhân phụ trách, mà là trách nhiệm của tất cả những người cùng tạo ra sản phẩm.

[tujuc]

Ồ.. có vẻ chỉ cần gắn ngay cả những Tag cơ bản nhất thôi thì cũng quản lý được ở mức nào đó nhỉ.. :)

Nhưng việc cắt giảm bằng cách dùng những thứ như RI hay SP có phải cũng được xem là mặc định không nhỉ.... Phần phải cân nhắc xem kích cỡ nào sẽ được dùng trong hạ tầng của mình đúng là một vấn đề khá đau đầu...

[dongho42]

Dù nội dung này cũng có được nhắc đến trong bài, nhưng riêng tôi đã tự tạo một trình mô phỏng SP để tính toán dựa trên workload của n ngày gần đây xem nên mua thêm bao nhiêu SP để chi phí thấp nhất giữa "chi phí hiện tại + phần chi phí được cover nên sẽ giảm + phần chi phí bị lãng phí do phát sinh định kỳ", rồi dùng đó để ra quyết định.

[slave4salary]

Tôi hiện đang làm việc tại AWS Korea.

Một trong những khóa đào tạo quan trọng nhất mà tôi được nghe sau khi vào công ty là phải suy nghĩ về cách giúp khách hàng sử dụng chi phí cloud ít hơn, và một trong những phương pháp hiệu quả nhất được hướng dẫn là RI & SP.

[cocofather]

Hãy giảm phí cho chúng tôi..

[toughrogrammer]

Tôi không rõ về RI, nhưng với SP thì có thể áp dụng cho nhiều workload nên nếu có một khoản chi phí cố định phải trả, đây là điều rất đáng để cân nhắc. Thậm chí bên tôi còn từng mua với cả việc tính trước thời điểm tối ưu hóa dự kiến nữa... haha. Ví dụ, nếu dự đoán sau 9 tháng việc tối ưu hóa sẽ hoàn tất và chi phí máy chủ sẽ giảm còn một nửa, thì dù vậy mua trước gói 1 năm vẫn có lợi hơn nên sẽ mua theo kiểu đó.