Với việc áp dụng AI, các trường hợp sử dụng phân bổ sử dụng và bồi hoàn đang gia tăng. Các doanh nghiệp hiện đại cũng mong muốn thu thập và chỉ định dữ liệu sử dụng cho khách hàng và bộ phận nội bộ của họ, để thúc đẩy thanh toán, bán hàng, phát triển sản phẩm và phân tích chi phí đám mây.  Quỹ FinOps gần đây cũng đã công bố bản thảo ban đầu của   (Thông số chi phí mở và sử dụng). Tại sao dữ liệu sử dụng có thể phức tạp và điều gì phân biệt đo lường sự kiện với đo lường chuỗi thời gian?  FOCUS  Trường hợp sử dụng dữ liệu sử dụng  Trước khi đi sâu vào sự phức tạp của các trường hợp sử dụng thanh toán, phân tích và giám sát, hãy xác định ý nghĩa của dữ liệu sử dụng. Cách sử dụng mô tả ai đó tiêu thụ hàng hóa trong một khoảng thời gian. Ví dụ: từ 1 giờ chiều đến 2 giờ chiều, Alice đã gửi 100 SMS qua API Twillio.  Việc sử dụng thường được mô tả trong một khoảng thời gian thay vì một ngày duy nhất vì máy tính thì nhanh nhưng con người thì chậm. Hãy xem xét một số trường hợp sử dụng phổ biến yêu cầu dữ liệu sử dụng:    Điều này yêu cầu dữ liệu sử dụng chính xác vì khách hàng bị tính phí dựa trên các điều khoản hợp đồng ràng buộc về mặt pháp lý. Mặc dù kích thước dữ liệu thường bị hạn chế, nhưng số lượng dữ liệu cao do dữ liệu sử dụng phải được theo dõi cho mọi khách hàng. Thanh toán:  Dữ liệu thời gian thực là tùy chọn, nhưng cần có thông báo nhanh khi người dùng đạt đến ngưỡng thanh toán. Việc lưu giữ dữ liệu là rất quan trọng để xác thực các hóa đơn, mặc dù điều này trở nên ít quan trọng hơn sau khi hóa đơn được thanh toán.    Điều này yêu cầu dữ liệu sử dụng theo thời gian thực cho mục đích cảnh báo. Độ chính xác là quan trọng nhưng linh hoạt hơn thanh toán. Các hệ thống giám sát thường bị giới hạn xung quanh tính chính xác. Giám sát:  Thời gian lưu giữ dữ liệu thường ngắn do chi phí lưu trữ khối lượng lớn dữ liệu giám sát, dữ liệu này hiếm khi được sử dụng sau một vài tuần.    Các trường hợp sử dụng điển hình như chi phí đám mây, phân tích lợi nhuận và định giá yêu cầu dữ liệu lịch sử chính xác từ ba đến năm năm qua để đào tạo mô hình và xác định xu hướng một cách hiệu quả. Analytics hiếm khi theo thời gian thực. Phân tích:  Tóm tắt dưới dạng bảng:  Trường hợp sử dụng  Sự chính xác  hồng y  Thời gian thực  Giữ lại  thanh toán  Cao  Cao  Vừa phải  1-2 năm  Giám sát  Vừa phải  Thấp  Cao  tuần  phân tích  Cao  Vừa phải  Thấp  hơn 3 năm  Như bạn có thể thấy, mỗi trường hợp sử dụng có các nhu cầu khác nhau, điều này có thể gây nhầm lẫn khi thảo luận về dữ liệu sử dụng.  Hiểu dữ liệu có thể kiểm toán và hoạt động  Khái niệm phân loại dữ liệu là có thể kiểm tra hoặc hoạt động lần đầu tiên được tôi chú ý vào năm 2018 thông qua một   của Charity Majors, đồng sáng lập của   . tweet Honeycomb.io    được phân loại như vậy khi việc mất bất kỳ bản ghi dữ liệu nào là không thể chấp nhận được và việc lưu giữ đầy đủ các bản ghi là cần thiết. Khi sử dụng một bộ dữ liệu có thể kiểm tra, nó phải toàn diện và đầy đủ. Dữ liệu có thể kiểm tra  Ví dụ về dữ liệu có thể kiểm tra bao gồm nhật ký giao dịch, nhật ký sao chép và sự kiện thanh toán/tài chính.  Ngược lại,   không yêu cầu tính đầy đủ nghiêm ngặt. Để duy trì chi phí có thể quản lý được, việc lấy mẫu thường được sử dụng và một số mức độ mất dữ liệu có thể chấp nhận được. dữ liệu hoạt động  Các công cụ được thiết kế để quản lý dữ liệu vận hành thường ưu tiên hiệu quả nỗ lực, bỏ qua các lần thử lại và đảm bảo tốn kém về chính xác một lần gửi. Ví dụ về dữ liệu vận hành bao gồm phép đo từ xa, chỉ số và dữ liệu theo ngữ cảnh mô tả từng yêu cầu và thành phần hệ thống.  Trước khi quyết định phương pháp thu thập, xử lý và lưu trữ dữ liệu sử dụng của bạn, điều quan trọng là phải xác định xem dữ liệu của bạn có cần kiểm tra được hay không.  Trong phần sau, chúng ta sẽ so sánh hai chiến lược thu thập dữ liệu: đo lường theo sự kiện, thường phù hợp hơn với các trường hợp sử dụng có thể kiểm tra và giám sát chuỗi thời gian, phương pháp ưa thích để thu thập dữ liệu sử dụng vận hành.  Đo sáng theo hướng sự kiện so với Đo lường theo chuỗi thời gian  Có hai cách chính để thu thập dữ liệu sử dụng:    và đo lường theo hướng sự kiện    . hệ thống giám sát chuỗi thời gian  Đây là cách họ so sánh:    Các công ty thanh toán dựa trên mức sử dụng ủng hộ phương pháp này vì nó có thể kiểm tra được do tính nhất quán vốn có của nó trong việc xử lý các sự kiện duy nhất. Các sự kiện có thể được phân phối hai lần trong các hệ thống phân tán và được loại bỏ trùng lặp bằng cách sử dụng các mã định danh duy nhất để ngăn việc thanh toán thừa hoặc thiếu. Đo lường theo hướng sự kiện:  Đo sáng xử lý tốt với cardinality cao, cần thiết để theo dõi việc sử dụng của mọi khách hàng. Tuy nhiên, thách thức nằm ở việc thu thập dữ liệu. Ngành này có các công cụ thu thập cơ sở hạ tầng mạnh mẽ để giám sát, nhưng chúng được thiết kế với mục đích khác ngoài các sự kiện.  Hầu hết các nhà cung cấp cung cấp API POST để gửi sự kiện, để lại quá trình thu thập tùy thuộc vào người dùng.    Các hệ thống giám sát như bộ đếm phế liệu Prometheus và biểu đồ để lưu trữ và cung cấp số liệu dưới dạng dữ liệu hoạt động theo chuỗi thời gian. Giám sát chuỗi thời gian:  Nên giữ cardinality ở mức thấp, gây khó khăn cho việc theo dõi mức tiêu thụ tài nguyên của từng người dùng trên quy mô lớn. Bộ sưu tập chỉ số là một con đường trải sẵn trong ngành, với các trình trích xuất chỉ số sẵn dùng cho hầu hết các thành phần cơ sở hạ tầng.  Các nhà cung cấp APM đã đầu tư đáng kể vào các tiêu chuẩn như OpenTelemetry để hợp lý hóa việc thu thập dữ liệu. Thách thức nằm ở các đảm bảo hạn chế của công cụ thu thập số liệu xung quanh việc phân phối và chống trùng lặp do chúng được thiết kế có lưu ý đến các trường hợp sử dụng dữ liệu vận hành.  Những người đóng góp cho Prometheus chia sẻ một số suy nghĩ về độ chính xác   . Nếu bạn muốn tìm hiểu sâu hơn, bạn cũng có thể tìm thấy một số cuộc tranh luận về việc điều chỉnh cạo để tăng độ chính xác của bộ đếm   . tại đây tại đây  Tóm tắt dưới dạng bảng:  thu thập sử dụng  có thể kiểm tra  Tính nhất quán  Nhà sưu tập và tiêu chuẩn  đo lường sự kiện  Đúng  Cao  Thấp  Số liệu chuỗi thời gian  KHÔNG  Vừa phải  Cao  Tương lai của việc sử dụng: Hợp nhất  Thách thức hiện tại nằm ở việc thu thập và tích hợp dữ liệu sử dụng. Các tác vụ này rất phức tạp vì bộ sưu tập mức sử dụng phải cân bằng giữa độ chính xác, số lượng và các khía cạnh thời gian thực khác nhau cho mỗi trường hợp sử dụng (như được minh họa trong phần so sánh sự kiện so với chỉ số), trong khi việc tích hợp tốn nhiều thời gian do cần có tiêu chuẩn đặc tả mức sử dụng.  Chỉ cần nghĩ về tất cả các API của nhà cung cấp tùy chỉnh hoặc giao diện PromQL chung. Việc thiếu hợp nhất này tạo ra khó khăn trong việc tích hợp dữ liệu sử dụng vào các trường hợp sử dụng thanh toán, bồi hoàn và phân tích chi phí, thường dẫn đến các hệ thống riêng biệt để thu thập dữ liệu sử dụng thay vì chia sẻ lẫn nhau.  FOCUS của FinOps: Thông số kỹ thuật mới để tích hợp sử dụng  FOCUS (Thông số sử dụng và chi phí mở) của FinOps nhằm mục đích giải quyết các thách thức tích hợp của dữ liệu sử dụng. FOCUS phác thảo một đặc điểm kỹ thuật để sản xuất và tiêu thụ dữ liệu sử dụng được chuẩn hóa và thanh toán của Nhà cung cấp dịch vụ đám mây và nhà cung cấp SaaS.  FOCUS sẽ cho phép bạn tích hợp liền mạch dữ liệu sử dụng giữa các nhà cung cấp, cho các trường hợp sử dụng phân tích chi phí và thanh toán trên đám mây.  Thông số kỹ thuật FOCUS hiện đang được phát triển; phiên bản xem trước 0,5 vừa được phát hành vào cuối tháng 6 năm 2023 và thông số kỹ thuật hiện tập trung nhiều hơn vào việc thanh toán hơn là dữ liệu sử dụng.  Bạn có thể theo dõi hoặc tham gia nhóm làm việc FOCUS   . tại đây  Điều hòa độ chính xác, tính chính xác và tính kịp thời  Tôi không lường trước được sự hội tụ của các hệ thống đo lường và đo lường sự kiện vì mỗi hệ thống này đều cân bằng các đánh đổi kinh doanh và kỹ thuật riêng biệt để phục vụ cho các trường hợp sử dụng của chúng. Chỉ cần nghĩ về sự khác biệt giữa dữ liệu có thể kiểm toán và hoạt động.  Nhưng tôi mong đợi sự hội tụ về các tiêu chuẩn xung quanh việc tích hợp dữ liệu sử dụng giữa các nhà cung cấp như FOCUS của FinOps.  Chúng tôi cần đầu vào của bạn. OpenMeter có nên nhập số liệu và tích hợp với Prometheus để hợp lý hóa các trường hợp sử dụng thanh toán và bồi hoàn không?  Hãy cho chúng tôi biết trong kho lưu trữ mã nguồn mở của chúng tôi:  https://github.com/openmeterio/openmeter

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Check out OpenMeter.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Make resilience your competitive advantage

Sự khác biệt giữa dữ liệu sử dụng có thể kiểm tra và hoạt động

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

94 Stories To Learn About John Locke

223 Stories To Learn About Science

581 Stories To Learn About Non Fiction

309 Stories To Learn About Smart Contracts

94 Stories To Learn About John Locke

223 Stories To Learn About Science

581 Stories To Learn About Non Fiction

309 Stories To Learn About Smart Contracts

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps