Chủ đề 6.5 — Quản lý chi phí công nghệ và FinOps đám mây

Trong y tế và chăm sóc, chi phí vận hành của công nghệ là tiền công được chi mỗi giờ dù có ai theo dõi hay không, nên quản lý chi phí đó — đặc biệt trên đám mây — là một kỷ luật vận hành của sự quản lý, không phải một bài tập tài chính hằng năm.

Vì sao điều này quan trọng trong y tế và chăm sóc#

Trong phần lớn lịch sử công nghệ NHS, tiền được chi một lần. Bạn mua một máy chủ, một mảng lưu trữ hay một giấy phép, vốn hóa nó, và nó nằm trong tủ rack khấu hao lặng lẽ trong năm năm. Chi phí hiển thị, có giới hạn và phần lớn cố định. Điện toán đám mây đã phá mô hình đó. Nay đồng hồ chạy liên tục, hóa đơn thay đổi hằng ngày, hàng nghìn quyết định nhỏ của kỹ sư di chuyển tiền thật, và hóa đơn đến một tháng sau khi việc chi tiêu đã xong. Một tác vụ cấu hình sai bị bỏ chạy suốt cuối tuần nghỉ lễ, một môi trường kiểm thử không ai tắt, một kho lưu trữ lặng lẽ phình ra — mỗi cái là tiền công rò rỉ theo thời gian thực.

Điều này quan trọng trong y tế và chăm sóc vì ba lý do vượt ngoài sự tiết kiệm thông thường. Thứ nhất, đó là tiền công được giữ ủy thác: mỗi đồng bảng chi cho tính toán nhàn rỗi hay một giấy phép phần mềm trùng lặp là một đồng bảng không chi cho chăm sóc, và bạn chịu trách nhiệm về nó trước kiểm toán viên, hội đồng và cuối cùng là công chúng (xem Chủ đề 6.4 — Quản trị và đảm bảo). Thứ hai, tiền đi theo những quy tắc đặc thù. Ngân sách NHS tách cứng giữa vốn và chi thường xuyên, và sự chuyển từ mua tài sản sang thuê dịch vụ lặng lẽ chuyển cái này thành cái kia — một quyết định kỹ thuật có hệ quả ngân sách có thể phục kích giám đốc tài chính. Thứ ba, chi phí không được quản lý là rủi ro an toàn và liên tục ngụy trang: các nhóm sợ một hóa đơn bất ngờ sẽ cung cấp thiếu khả năng chống chịu, trì hoãn vá, hoặc không đủ khả năng chạy các môi trường mà một dịch vụ an toàn cần.

Kiểu thất bại đặc trưng và phổ biến. Các tổ chức chuyển lên đám mây mong tiết kiệm, ăn mừng việc di chuyển, rồi mười tám tháng sau phát hiện hóa đơn lớn hơn trung tâm dữ liệu nó thay thế — và không ai nói được vì sao. Vấn đề hiếm khi là công nghệ. Mà là không ai sở hữu chi phí vận hành như một kỷ luật sống: kỹ sư tối ưu cho tốc độ giao hàng, tài chính thấy một hóa đơn đục duy nhất, và vòng phản hồi giữa một quyết định thiết kế và chi phí của nó không bao giờ khép. Chủ đề này nói về việc khép vòng đó.

Các khái niệm cốt lõi#

Điện toán đám mây cung cấp tài nguyên tính toán — máy chủ, lưu trữ, cơ sở dữ liệu, mạng — như một dịch vụ theo yêu cầu, được đo lường thay vì thiết bị sở hữu. Đặc điểm thương mại xác định của nó là tính đàn hồi: bạn có thể thu nhận và giải phóng năng lực trong vài phút và chỉ trả cho những gì bạn tiêu thụ. Chính tính đàn hồi đó là lý do quản lý chi phí khó. Kiến trúc kỹ thuật của đám mây và hệ thống cũ được đề cập ở Chủ đề 4.0 (xem Chủ đề 4.0 — Kiến trúc kỹ thuật, đám mây và hệ thống cũ); chủ đề này sở hữu điều xảy ra với chi phí khi kiến trúc đó đang chạy.

Sự dịch chuyển kế toán trung tâm là từ chi tiêu vốn (capex) — tiền chi để mua một tài sản cố định rồi được khấu hao qua nhiều năm — sang chi phí hoạt động (opex), chi phí liên tục của việc vận hành một dịch vụ. Mua một máy chủ là capex; thuê năng lực đám mây tương đương là opex. Trong NHS đây không phải chi tiết kế toán trung tính: vốn và chi thường xuyên được phân bổ riêng, kiểm soát riêng, và hiếm khi thay thế được cho nhau, nên chuyển chi tiêu từ capex sang opex có thể giảm một áp lực trong khi tạo áp lực khác. Việc thẩm định trước các lựa chọn này — Mô hình Năm Hồ sơ, kiến thức cơ bản về vốn so với chi thường xuyên — thuộc về quản lý tài chính và lập luận kinh doanh (xem Chủ đề 6.0 — Quản lý tài chính và hồ sơ kinh doanh); chủ đề này tiếp nối nơi lập luận kinh doanh kết thúc và đồng hồ bắt đầu chạy.

FinOps — viết tắt của "vận hành tài chính đám mây" — là kỷ luật vận hành đưa các nhóm kỹ thuật, tài chính và kinh doanh lại với nhau để quản lý chi phí đám mây như một trách nhiệm chung, dựa trên dữ liệu. Được FinOps Foundation (một phần của Linux Foundation) thúc đẩy, nó thường được mô tả là một vòng đời với ba giai đoạn lặp: Thông báo (Inform) (cho mọi người thấy cái gì đang được chi và vì sao, qua phân bổ và báo cáo), Tối ưu (Optimize) (hành động trên khả năng hiển thị đó để loại bỏ lãng phí và mua rẻ hơn), và Vận hành (Operate) (nhúng nhận thức chi phí vào phương thức làm việc hằng ngày và quản trị). FinOps cố ý không chỉ là cắt giảm chi phí; mục tiêu của nó là tối đa hóa giá trị kinh doanh của từng đồng bảng chi đám mây, đôi khi nghĩa là chi nhiều hơn vì lợi tức biện minh cho nó.

Hai cơ chế phân bổ làm chi phí hiển thị. Showback báo cáo cho từng nhóm hay dịch vụ việc tiêu thụ công nghệ của nó tốn bao nhiêu, để minh bạch và thay đổi hành vi, mà không di chuyển tiền. Chargeback đi xa hơn và thực sự thu hồi chi phí từ ngân sách của đơn vị tiêu thụ — một dạng phân bổ chi phí nội bộ gán chi phí dịch vụ dùng chung cho trung tâm chi phí tiêu thụ chúng. Cả hai phụ thuộc vào gắn thẻ (tagging): dán nhãn mọi tài nguyên đám mây bằng siêu dữ liệu (dịch vụ, nhóm, môi trường, hướng tới bệnh nhân hay không) để một hóa đơn không phân biệt có thể được chia thành các dòng có ý nghĩa.

Ba ý tưởng nữa chạy xuyên chủ đề. Tổng chi phí sở hữu (TCO) là toàn bộ chi phí trực tiếp và gián tiếp của một công nghệ qua cả vòng đời — không chỉ giấy phép hay tính toán, mà cả con người, tích hợp, hỗ trợ, rút lui và ngừng hoạt động xung quanh nó. Quản lý tài sản phần mềm (SAM) là kỷ luật theo dõi và tối ưu phần mềm một tổ chức sở hữu và thuê, ngày càng bị thống trị bởi các đăng ký phần mềm như một dịch vụ (SaaS) và giấy phép phần mềm theo người dùng tự gia hạn lặng lẽ. Và kinh tế đơn vị biểu diễn chi phí như một tỷ lệ so với thứ tổ chức quan tâm — chi phí trên mỗi bệnh nhân, mỗi cuộc hẹn, mỗi chuyển tuyến, mỗi lần gọi API — để một hóa đơn tăng có thể được đánh giá so với giá trị tăng thay vì trong chân không. Tự động mở rộng quy mô, việc điều chỉnh tự động năng lực theo tải, và các thực hành quản lý tài chính rộng hơn của ITIL đứng cạnh những điều này như các đòn bẩy vận hành.

Thực hành tốt nhất#

1. Làm cho chi phí hiển thị trước khi bạn cố cắt nó — Thông báo trước. Bạn không thể quản lý thứ không ai thấy, và hóa đơn đám mây mặc định là một con số đục duy nhất đến muộn một tháng. Thiết lập khả năng hiển thị chi phí gần thời gian thực chia theo dịch vụ, nhóm, môi trường và, nơi có thể, theo dịch vụ lâm sàng, để những người đưa ra quyết định thiết kế có thể thấy chi phí của các quyết định đó trong vài ngày, không phải vài quý. Chỉ khả năng hiển thị đã thay đổi hành vi: các nhóm thấy chi tiêu của chính mình thường xuyên tìm ra lãng phí mà không báo cáo tài chính trung tâm nào bắt được.

2. Gắn thẻ mọi thứ, và xem chi tiêu không gắn thẻ là một khiếm khuyết. Phân bổ chi phí chỉ tốt bằng siêu dữ liệu bên dưới; một tài nguyên không gắn thẻ là tiền bạn không thể quy kết, chất vấn hay thu hồi. Thỏa thuận một chuẩn gắn thẻ bắt buộc — chủ sở hữu, dịch vụ, môi trường, trung tâm chi phí, phân loại dữ liệu — thực thi qua chính sách tự động để tài nguyên không tuân thủ bị đánh dấu hoặc chặn lúc tạo, và báo cáo tỷ lệ chi tiêu được phân bổ đúng như một chỉ số nổi bật. Trong bối cảnh y tế, gắn thẻ liệu một khối lượng công việc có hướng tới bệnh nhân hay then chốt lâm sàng cũng cho phép bạn bảo vệ đúng thứ khi tối ưu phần còn lại.

3. Chọn showback hay chargeback có chủ đích, và khớp nó với trách nhiệm giải trình của bạn. Showback xây nhận thức chi phí nhẹ nhàng và là điểm bắt đầu đúng cho hầu hết tổ chức; chargeback tạo hậu quả ngân sách thực nhưng cần phân bổ trưởng thành và ý chí chính trị để bảo vệ các con số. Quyết định hành vi bạn đang cố tạo ra — nhận thức, hay quyền sở hữu tài chính thực — và trung thực rằng chargeback vội vàng với dữ liệu lung lay sẽ tạo tranh chấp làm mất uy tín cả nỗ lực. Dù chọn gì, mục tiêu là một vòng khép kín nơi quyết định của một nhóm hiển nhiên ảnh hưởng một ngân sách nó nhận là của mình.

4. Loại bỏ lãng phí không ngừng: định cỡ lại, lên lịch và xóa. Một phần lớn chi tiêu đám mây trong hầu hết hệ thống là lãng phí thuần túy — phiên bản được cung cấp quá mức, cơ sở dữ liệu quá lớn, lưu trữ mồ côi, và môi trường không phải sản xuất chạy hai mươi bốn giờ một ngày cho một nhóm làm chín-đến-năm. Định cỡ lại tài nguyên theo tải quan sát được thay vì đỉnh đoán, lên lịch môi trường phát triển và kiểm thử tắt qua đêm và cuối tuần, và đặt vòng đời cho lưu trữ và ảnh chụp để không gì tích tụ mãi mãi. Đây là khoản tiết kiệm nhanh nhất, rủi ro thấp nhất có sẵn và nó lặp lại mỗi tháng một khi được tự động hóa.

5. Mua năng lực cam kết cho đường cơ sở dự đoán được của bạn. Các nhà cung cấp đám mây chiết khấu mạnh — thường đáng kể — đổi lấy cam kết một hay ba năm qua phiên bản dành trước, kế hoạch tiết kiệm hay thỏa thuận cam kết-sử dụng, và đường cơ sở ổn định của một dịch vụ y tế (hồ sơ bệnh án điện tử cốt lõi, bộ máy tích hợp luôn bật) chính xác là tải dự đoán được mà các công cụ này thưởng. Phân tích mức sử dụng ổn định của bạn, cam kết với nó để giành chiết khấu, và giữ năng lực theo yêu cầu hoặc tự động mở rộng cho đỉnh biến thiên bên trên. Rà soát các cam kết đều đặn để không khóa năng lực bạn đã tái kiến trúc bỏ, và phối hợp mua với đồng nghiệp mua sắm và thương mại (xem Chủ đề 6.3 — Mua sắm và thương mại).

6. Quản lý sự bành trướng SaaS và giấy phép có chủ đích như tính toán đám mây. Hóa đơn đám mây hiển thị; hai mươi đăng ký SaaS mua bằng thẻ của các ban, giấy phép theo chỗ ngồi giao cho người đã nghỉ, và các công cụ chồng lấn làm cùng một việc thì không — thế nhưng gộp lại chúng thường ngang với chi tiêu hạ tầng. Duy trì một sổ đăng ký sống các đăng ký phần mềm và quyền sử dụng, đối chiếu giấy phép với người dùng có tên và mức sử dụng thực, hủy hoặc hạ cấp những gì không dùng, và hợp nhất các công cụ trùng lặp. Quản lý tài sản phần mềm ở đây vừa là kỷ luật chi phí vừa là kỷ luật bảo mật, vì SaaS không biết cũng là luồng dữ liệu không được quản lý (xem Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng).

7. Đánh giá chi phí theo kinh tế đơn vị, không phải kích thước hóa đơn. Một hóa đơn tăng không tự động xấu và một hóa đơn giảm không tự động tốt; điều quan trọng là chi phí so với giá trị được giao. Xác định các chỉ số chi phí đơn vị có ý nghĩa về lâm sàng và vận hành — chi phí trên mỗi bệnh nhân được theo dõi, mỗi cuộc hẹn được đặt, mỗi chuyển tuyến được xử lý, mỗi nghìn lần gọi API — và theo dõi chúng theo thời gian để bạn phân biệt hiệu quả với tăng trưởng đơn thuần và bảo vệ chi tiêu thực sự xứng đáng chỗ của nó (xem Chủ đề 6.2 — Hiện thực hóa lợi ích và quản lý giá trị, và Chủ đề 10.1 — KPI). Kinh tế đơn vị cũng là cách bạn nối chi phí vận hành trở lại lập luận kinh tế y tế cho dịch vụ (xem Chủ đề 6.1 — Kinh tế học y tế).

8. Nghĩ theo tổng chi phí sở hữu khắp hệ thống, gồm cả rút lui. Giá niêm yết của một nền tảng là một phần nhỏ chi phí vòng đời của nó; tích hợp, di chuyển dữ liệu, nhân viên hỗ trợ, đào tạo, phí egress và chi phí rời đi cuối cùng đều thuộc bức tranh. Đánh giá các phương án theo tổng chi phí sở hữu qua một vòng đời thực tế, đặc biệt cảnh giác với phí egress dữ liệu và dịch vụ độc quyền làm tăng chi phí rút lui, và nhớ rằng khóa chặt là chi phí tương lai ngay cả khi hôm nay trông miễn phí (mua sắm sở hữu phía hợp đồng của khóa chặt — xem Chủ đề 6.3 — Mua sắm và thương mại). Một cái nhìn TCO cũng ngăn tổ chức tự khen về một nền tảng rẻ nhưng lặng lẽ đắt để vận hành.

9. Nhúng chi phí vào kỹ thuật và quản trị để nó vận hành liên tục. FinOps thất bại khi nó là chiến dịch dọn dẹp hằng quý và thành công khi chi phí là cân nhắc thường trực trong rà soát thiết kế, quyết định kiến trúc và đường ống giao hàng (xem Chủ đề 3.6 — DevOps và xuất sắc kỹ thuật). Trao cho các nhóm ngân sách chi phí và cảnh báo bất thường, đưa ước tính tác động chi phí vào các quyết định kiến trúc quan trọng, và đặt cảnh báo tự động và hàng rào chi tiêu cứng để một tác vụ chạy mất kiểm soát bị bắt trong vài giờ, không phải trên hóa đơn tháng sau. Mục tiêu của giai đoạn Vận hành là ý thức chi phí trở thành vệ sinh kỹ thuật thông thường thay vì một cuộc kiểm toán bên ngoài.

10. Cân bằng chi phí với giá trị lâm sàng và tính bền vững, không chỉ chi phí. Phương án rẻ nhất không phải lúc nào cũng đúng: một khoản tiết kiệm quyết liệt loại bỏ khả năng chống chịu, trì hoãn một bản vá, hay làm suy giảm dịch vụ hướng tới bệnh nhân đổi tiền lấy rủi ro theo hướng sai. Cân nhắc rõ ràng các quyết định chi phí với giá trị lâm sàng và với carbon, vì tính toán bạn loại bỏ như lãng phí cũng là khí thải bạn tránh được — tối ưu chi phí và bền vững thường chỉ cùng một hướng (xem Chủ đề 8.5 — Bền vững và phát thải ròng bằng không). Làm cho các đánh đổi hiển thị và có chủ thay vì để áp lực chi phí lặng lẽ xói mòn an toàn.

Câu hỏi để thảo luận với nhóm của bạn#

1. Ai thực sự sở hữu chi phí vận hành công nghệ của chúng ta — và người sở hữu đó có cả khả năng hiển thị lẫn thẩm quyền để thay đổi nó không? Điều này quan trọng vì chi phí không có chủ là chi phí tăng không kiểm soát: kỹ sư tối ưu cho giao hàng, tài chính thấy một hóa đơn, và không ai chịu trách nhiệm cho khoảng cách giữa chúng. Tranh luận liệu quyền sở hữu chi phí nằm với một nhóm tài chính trung tâm không thể ảnh hưởng quyết định kỹ thuật, hay với kỹ sư không thấy hóa đơn, hay lý tưởng là một năng lực chung trải cả hai. Thăm dò liệu người sở hữu có thực sự hành động được — họ có thể tắt một môi trường nhàn rỗi, chặn một tài nguyên không gắn thẻ, hay từ chối một thiết kế đắt không cần thiết — hay chỉ có thể báo cáo sau khi tiền đã chi. Hãy cân nhắc căng thẳng riêng của y tế: người sở hữu chi phí không bao giờ được phép làm tổn hại an toàn lâm sàng hay liên tục nhân danh tiết kiệm, vậy hàng rào đó ở đâu. Một câu trả lời tốt, trung thực gọi tên một người sở hữu hay diễn đàn chịu trách nhiệm cụ thể, xác nhận nó có khả năng hiển thị gần thời gian thực và quyền quyết định thực, và thẳng thắn thừa nhận nơi hôm nay câu trả lời là "hóa đơn cứ đến và chúng tôi trả".

2. Bao nhiêu chi tiêu đám mây và phần mềm của chúng ta thực sự mang lại giá trị, và chúng ta sẽ biết bằng cách nào? Hầu hết tổ chức không trả lời được điều này, vì họ theo dõi tổng hóa đơn nhưng không phải giá trị nó mua, nên mọi chi phí đều có vẻ chính đáng ngang nhau hay đáng ngờ ngang nhau. Thảo luận liệu bạn có các chỉ số chi phí đơn vị nối chi tiêu với thứ gì đó lâm sàng hay vận hành — chi phí trên mỗi bệnh nhân, mỗi cuộc hẹn, mỗi lần gọi API — hay chỉ có một con số không phân biệt cứ tăng. Làm lộ sự đánh đổi giữa cắt chi phí và giá trị: mục đích không phải hóa đơn nhỏ nhất mà là lợi tức tốt nhất, đôi khi nghĩa là chi nhiều hơn cho một dịch vụ rõ ràng xứng đáng. Hãy cân nhắc bao nhiêu chi tiêu của bạn là lãng phí đo được — môi trường nhàn rỗi, phiên bản được cung cấp quá mức, giấy phép cho người đã nghỉ — so với tải thực sự hiệu quả, và trung thực về mức tự tin của bạn vào sự phân chia đó. Một câu trả lời tốt phân biệt lãng phí với giá trị bằng bằng chứng, có ít nhất vài chỉ số kinh tế đơn vị thực, và cưỡng lại phản xạ rằng hóa đơn nhỏ hơn tự động tốt hơn.

3. Khi chúng ta chuyển (hoặc sẽ chuyển) chi tiêu từ vốn sang chi hoạt động, ai hiểu các hệ quả ngân sách và dài hạn? Sự dịch chuyển capex-sang-opex thường được xem là một cuộc di chuyển thuần kỹ thuật, nhưng nó đổi ngân sách nào tiền đến từ đó, biến một chi phí một lần thành chi phí định kỳ vĩnh viễn, và có thể lặng lẽ cam kết tổ chức vào một khoản nợ tăng trong nhiều năm. Tranh luận liệu nhóm tài chính và số của bạn có cùng mô hình hóa điều này trước khi cam kết — có ai vẽ bản đồ quỹ đạo opex nhiều năm, chi phí rút lui, và tác động lên cân bằng vốn-so với-chi thường xuyên mà NHS kiểm soát chặt. Hãy cân nhắc cái bẫy trung thực: các cuộc di chuyển lên đám mây thường được bán trên khoản tiết kiệm giả định quản lý chi phí có kỷ luật rồi không bao giờ thành hiện thực, vậy lập luận kinh doanh của bạn có dựa trên một năng lực FinOps bạn thực sự đã xây không. Khám phá điều gì xảy ra khi hóa đơn định kỳ tăng nhanh hơn ngân sách tài trợ nó, và ai chịu trách nhiệm khi nó xảy ra. Một câu trả lời tốt cho thấy tài chính và số cùng lập luận về toàn vòng đời, không phải một nhóm kỹ thuật tối ưu cho tốc độ di chuyển trong khi tài chính phát hiện hệ quả sau (xem Chủ đề 6.0 — Quản lý tài chính và hồ sơ kinh doanh).

4. Chúng ta tự tin đến đâu rằng một khoản chi phí chạy mất kiểm soát sẽ bị bắt trong vài giờ chứ không phải trên hóa đơn tháng sau? Mối nguy xác định của đám mây được đo lường là độ trễ giữa một sai lầm và việc phát hiện nó: một tác vụ cấu hình sai, một cung cấp quá mức tình cờ, hay một môi trường kiểm thử bị bỏ chạy có thể đốt tiền công trong im lặng nhiều tuần trước khi hóa đơn tháng lộ ra. Thảo luận liệu bạn có cảnh báo bất thường và hàng rào chi tiêu cứng nối với những người có thể hành động, hay cơ chế phát hiện duy nhất của bạn là hóa đơn đến muộn một tháng. Thăm dò sự cân bằng giữa hàng rào thực sự chặn lãng phí và các kiểm soát quá quyết liệt bóp nghẹt một khối lượng công việc lâm sàng chính đáng vào sai lúc — cảnh báo kêu sói sớm bị phớt lờ, và hàng rào chặn một dịch vụ an toàn tệ hơn khoản chi nó ngăn. Hãy cân nhắc ai nhận cảnh báo bất thường lúc 2 giờ sáng và liệu họ có cả thẩm quyền và sự tự tin hành động mà không sợ phá thứ gì hướng tới bệnh nhân. Một câu trả lời tốt mô tả một vòng phát hiện-và-phản ứng đã kiểm thử đo bằng giờ, gọi tên ai sở hữu nó, và trung thực về việc bao nhiêu bất ngờ trong quá khứ chỉ được phát hiện khi hóa đơn đến.

5. Chúng ta đang trả tiền cho bao nhiêu phần mềm mà chúng ta không thấy — và ai sẽ nhận ra nếu một đăng ký gia hạn cho một công cụ không ai dùng? Hóa đơn tính toán đám mây ít nhất hiển thị; sự bành trướng của các đăng ký SaaS mua bằng thẻ của các ban, giấy phép theo chỗ ngồi vẫn giao cho người đã nghỉ, và các công cụ chồng lấn làm cùng một việc thì không, thế nhưng gộp lại chúng thường ngang với chi tiêu hạ tầng. Thảo luận liệu bạn có giữ một sổ đăng ký sống các quyền sử dụng phần mềm được đối chiếu với người dùng có tên thực, hay các lần gia hạn qua lặng lẽ vì không ai sở hữu toàn bộ bức tranh. Làm lộ chiều bảo mật cũng như chi phí: SaaS không biết cũng là luồng dữ liệu không được quản lý, nên phần mềm bóng vừa là tiền rò rỉ vừa là khoảng trống quản trị thông tin (xem Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng). Hãy cân nhắc lý do tổ chức khiến điều này xảy ra — ngân sách phân quyền và thanh toán thẻ dễ dàng làm việc có được phần mềm không ma sát và việc thanh lý nó gần như bất khả — và cần thay đổi gì để ai đó chịu trách nhiệm cho tổng. Một câu trả lời tốt thừa nhận bao nhiêu chi tiêu phần mềm của hệ thống thực sự đã được ánh xạ, phân biệt công cụ có chủ đích với bành trướng tích tụ, và có thể chỉ ra một lần đối chiếu thực sự đã hủy thứ gì đó.

6. Khi áp lực chi phí và an toàn lâm sàng kéo ngược chiều, làm sao chúng ta bảo đảm an toàn thắng — và chúng ta có thể chứng minh nó đã thắng không? Mọi đòn bẩy tối ưu trong chủ đề này — định cỡ lại, tắt đi, trì hoãn chi tiêu, mua phương án rẻ nhất — nếu áp dụng cẩu thả có thể loại bỏ khả năng chống chịu, trì hoãn một bản vá, hay làm suy giảm một dịch vụ hướng tới bệnh nhân, đổi tiền lấy rủi ro theo đúng hướng sai. Tranh luận liệu các quyết định chi phí của bạn có mang một kiểm tra an toàn rõ ràng, để một khối lượng công việc gắn thẻ then chốt lâm sàng được rà soát riêng trước khi bất kỳ thay đổi nào chạm vào nó, hay mục tiêu chi phí được phép xói mòn an toàn lặng lẽ và vô hình. Hãy cân nhắc góc độ bền vững thường căn chỉnh hơn là xung đột: tính toán loại bỏ như lãng phí cũng là carbon tránh được, nên tối ưu chi phí và phát thải ròng bằng không thường chỉ cùng một hướng (xem Chủ đề 8.5 — Bền vững và phát thải ròng bằng không) — nhưng hãy trung thực về các trường hợp chúng phân kỳ và có thứ phải nhường. Khám phá ai giữ ranh giới khi một mục tiêu tiết kiệm và một yêu cầu chống chịu va nhau, và liệu sự đánh đổi đó được thực hiện công khai và có chủ hay lặng lẽ dưới áp lực ngân sách. Một câu trả lời tốt cho thấy an toàn và liên tục được xem là ràng buộc mà chi phí không được ghi đè, với một cơ chế thực để thực thi, không chỉ một giá trị được nêu mà uốn cong khi hóa đơn tăng.

Trong thực tế: một ví dụ về y tế và chăm sóc#

Hệ thống Chăm sóc Tích hợp Northmarsh chuyển nền tảng phân tích, vài dịch vụ hướng tới bệnh nhân và một hồ dữ liệu lớn lên đám mây công cộng trong hai năm, được tài trợ bởi một lập luận kinh doanh hứa một khoản tiết kiệm khiêm tốn so với trung tâm dữ liệu già cỗi mà nó thay thế. Cuộc di chuyển được giao đúng hạn và được ăn mừng. Mười tám tháng sau hóa đơn đám mây hằng tháng chạy ở gần gấp đôi con số trong lập luận kinh doanh, tăng mỗi quý, và khi giám đốc tài chính yêu cầu nhóm số giải thích mức tăng, không ai chia nhỏ được con số. Hóa đơn là một dòng duy nhất từ nhà cung cấp, và không gì bên dưới được gắn thẻ.

Hội đồng ủy thác một sáng kiến FinOps nhỏ thay vì một lệnh cắt giảm chi phí đại trà. Việc đầu tiên của nó là Thông báo: nhóm dựng một công cụ hiển thị chi phí, bắt buộc một chuẩn gắn thẻ, và dành sáu tuần gắn thẻ hồi tố cho tài nguyên và đối chiếu chúng với các dịch vụ sở hữu. Bức tranh hiện ra quen thuộc. Các môi trường phát triển và kiểm thử của nhóm khoa học dữ liệu — phiên bản lớn, đắt — chạy liên tục, gồm cả đêm và cuối tuần khi không ai dùng. Hồ dữ liệu đã di chuyển được nhấc-và-đặt lên lưu trữ cao cấp không có chính sách vòng đời, nên năm năm ảnh chụp đã bị thay thế tích tụ ở giá đầy đủ. Ba nhóm riêng biệt đang trả tiền cho các công cụ phân tích SaaS chồng lấn mua trên các ngân sách khác nhau. Và một tác vụ hàng loạt cấu hình sai trong lúc di chuyển đã xử lý lại cùng một tập dữ liệu mỗi đêm trong nhiều tháng.

Giai đoạn Tối ưu cố ý được sắp theo rủi ro. Các môi trường không phải sản xuất được lên lịch tắt ngoài giờ làm việc, tiết kiệm một khoản định kỳ lớn không có tác động lâm sàng nào. Lưu trữ được phân tầng và được trao một vòng đời để các ảnh chụp cũ tự lão hóa. Tải đường cơ sở ổn định của các dịch vụ hướng tới bệnh nhân luôn bật được phân tích và được bao phủ bằng chiết khấu cam kết-sử dụng ba năm, thương lượng cùng đồng nghiệp mua sắm. Các công cụ SaaS trùng lặp được hợp nhất thành một. Quan trọng là, trước khi bất kỳ thay đổi nào chạm vào một khối lượng công việc hướng tới bệnh nhân hay then chốt lâm sàng, thẻ của nó đánh dấu để một cuộc rà soát riêng, thận trọng — chi phí không bao giờ được phép ghi đè an toàn hay khả năng chống chịu.

Rồi đến Vận hành, điều quan trọng nhất. Mỗi nhóm dịch vụ được trao một báo cáo showback hằng tháng và một ngân sách chi phí, cảnh báo bất thường được nối để đánh dấu bất kỳ cú nhảy đột ngột nào trong vòng vài giờ, và một kiểm tra chi phí gọn nhẹ được thêm vào danh sách kiểm tra rà soát kiến trúc để thiết kế mới mang ước tính chi phí vận hành. Trong hai quý hóa đơn đã giảm xuống dưới đường cơ sở trung tâm dữ liệu ban đầu và, quan trọng hơn, nó thôi là một điều bí ẩn — mỗi đồng bảng đều quy được về một dịch vụ, và ICS nay có thể báo cáo chi phí trên mỗi người dùng đang hoạt động của nền tảng phân tích và bảo vệ nó như giá trị. Khoản tiết kiệm là thật, nhưng chiến thắng bền vững là vòng khép kín: các quyết định nay có hệ quả tài chính hiển thị, có chủ.

Góc nhìn theo khu vực#

Công ty khởi nghiệp#

Với một công ty khởi nghiệp y tế số, chi phí đám mây là toán sinh tồn: nó thường là dòng hạ tầng lớn nhất, và tốc độ đốt tiền trực tiếp quyết định đường băng. Lợi thế của người sáng lập là kỷ luật FinOps có thể được xây vào từ lần commit đầu — gắn thẻ từ ngày đầu, bảng điều khiển chi phí mà mọi kỹ sư thấy, và kinh tế đơn vị (chi phí phục vụ một bệnh nhân hay một khách hàng) được theo dõi như một chỉ số kinh doanh cốt lõi mà nhà đầu tư sẽ soi xét. Rủi ro là tối ưu quá sớm, tiêu thời gian kỹ thuật khan hiếm vào việc cạo vài xu khỏi một hóa đơn vẫn nhỏ, hay khóa vào các cam kết dài trước khi kiến trúc ổn định. Kỷ luật mở rộng được là văn hóa: xem chi phí là chỉ số sản phẩm, không phải điều nghĩ sau của tài chính, để khi công ty khởi nghiệp giành một hợp đồng NHS, chi phí phục vụ của nó đã biết và bảo vệ được.

Doanh nghiệp nhỏ#

Một nhà cung cấp nhỏ đã thành lập — một phòng khám bác sĩ gia đình, một hiệu thuốc cộng đồng, một nhà dưỡng lão, một phòng khám đơn lẻ hoặc một nhà cung cấp công nghệ y tế nhỏ — trả cùng các hóa đơn đám mây và SaaS được đo lường như một quỹ lớn nhưng không có năng lực FinOps hay CNTT chuyên trách để quản lý chúng, nên ưu tiên thực tế là một nhúm thói quen đòn bẩy cao hơn là một kỷ luật đầy đủ. Các thắng lợi thực tế là loại bỏ lãng phí hiển nhiên (tắt những gì không dùng, xóa lưu trữ cũ), giữ một danh sách đơn giản mọi đăng ký và giấy phép cùng ngày gia hạn để không gì gia hạn mà không ai để ý, và cảnh giác với các cam kết dài hay khóa chặt mà một tổ chức nhỏ khó tháo gỡ. Khả năng hiển thị chi phí thường nghĩa là nhìn bảng điều khiển của nhà cung cấp mỗi tháng hơn là một bảng điều khiển thời gian thực, và phần lớn hệ thống có thể là SaaS chọn để người khác vận hành, chuyển kỷ luật từ tinh chỉnh hạ tầng sang quản lý đăng ký và đọc hợp đồng. Căng thẳng không thể tránh là cùng nghĩa vụ quản trị thông tin và liên tục áp dụng như với tổ chức lớn, nhưng với tiền eo hẹp và nhân sự mỏng thì cám dỗ trì hoãn một bản vá hay bỏ khả năng chống chịu để tiết kiệm tiền là thật — nên ngay cả ở đây, một quy tắc rõ ràng rằng an toàn không bị đánh đổi lấy chi phí là quan trọng, lý tưởng được hỗ trợ bởi mua theo khung hoặc dùng chung để nhà cung cấp nhỏ không phải thương lượng giá đám mây và giấy phép một mình (xem Chủ đề 4.1 — Nền tảng và dịch vụ dùng chung).

Doanh nghiệp lớn#

Một bệnh viện NHS lớn hay ICS vận hành một hệ thống rộng lớn — trung tâm dữ liệu cũ, nhiều tài khoản đám mây, hàng trăm đăng ký SaaS mua qua hàng chục ngân sách — và thách thức của nó là phối hợp và phân bổ ở quy mô lớn. Mục tiêu thực tế là một năng lực FinOps trung tâm trao cho các nhóm liên bang khả năng hiển thị và hàng rào mà không thành nút thắt: một chuẩn gắn thẻ chung, showback cho mọi dịch vụ, mua cam kết-sử dụng thương lượng tập trung, và chi phí được nhúng vào quản trị kiến trúc. Vấn đề khó nhất thường mang tính tổ chức, không phải kỹ thuật — khiến kỹ thuật và tài chính, vốn nói ngôn ngữ khác nhau và báo cáo cho các giám đốc khác nhau, chia sẻ một cái nhìn về sự thật. Ở quy mô này những thắng lợi lớn nhất đến từ một số ít kỷ luật toàn hệ thống áp dụng nhất quán (gắn thẻ, loại bỏ lãng phí, cam kết-sử dụng, hợp lý hóa SaaS) hơn là tối ưu anh hùng cho bất kỳ dịch vụ đơn lẻ nào, và công việc chi phí phải được giới hạn rõ ràng để nó không bao giờ xói mòn an toàn hay liên tục lâm sàng.

Chính phủ#

Một cơ quan quốc gia — NHS England, một bộ y tế được phân quyền, một tổ chức dịch vụ dùng chung — định hình môi trường chi phí mà mọi nhà cung cấp vận hành. Đòn bẩy của nó là tập hợp: thương lượng các thỏa thuận đám mây và cấp phép quốc gia để các bệnh viện riêng lẻ không mỗi nơi mặc cả từ vị thế yếu, công bố hướng dẫn FinOps và TCO để thực hành tốt là mặc định, và xây các nền tảng dùng chung mà chi phí đơn vị giảm khi nhiều tổ chức dùng (xem Chủ đề 4.1 — Nền tảng và dịch vụ dùng chung). Chính phủ cũng sở hữu quy tắc vốn-so với-chi thường xuyên làm sự dịch chuyển capex-sang-opex có hệ quả đến vậy, và có thể làm dịu hay làm tệ ma sát đó qua cách nó phân bổ và uốn dẻo ngân sách. Trách nhiệm giải trình của nó hướng về Nghị viện và công chúng về giá trị đồng tiền khắp hệ thống, nên nó mang nghĩa vụ làm chi phí minh bạch và so sánh được giữa các tổ chức, và bảo đảm áp lực chi phí không lặng lẽ nới rộng bất bình đẳng trong các dịch vụ bệnh nhân nhận được.

Các kiểu thất bại thường gặp#

• Hóa đơn bí ẩn. Một hóa đơn đục duy nhất đến hằng tháng, không ai chia nhỏ được, và khi nó bị chất vấn thì tiền đã chi từ lâu. Sửa bằng gắn thẻ và khả năng hiển thị gần thời gian thực trước bất cứ điều gì khác.
• Nhấc-và-đặt rồi ngạc nhiên. Di chuyển máy chủ lên đám mây không đổi, giữ chúng chạy ở cỡ đầy đủ suốt ngày đêm, và mong kinh tế đám mây xuất hiện như phép màu. Đám mây chỉ tiết kiệm tiền khi bạn dùng tính đàn hồi của nó — định cỡ lại, lên lịch và mở rộng.
• Cắt chi phí thay vì quản lý chi phí. Một đợt thanh lọc hoảng loạn một lần tiết kiệm tiền một quý, làm hỏng khả năng chống chịu, và lặng lẽ mọc lại vì không gì thay đổi hành vi nền tảng. FinOps là vòng liên tục, không phải chiến dịch.
• Tối ưu bỏ qua an toàn. Tắt dự phòng, trì hoãn bản vá, hay cung cấp thiếu một dịch vụ lâm sàng để đạt mục tiêu chi phí. Các quyết định chi phí phải được cân rõ ràng với giá trị lâm sàng và không bao giờ ghi đè nó.
• SaaS trong bóng tối. Hàng chục đăng ký trên thẻ của các ban, giấy phép vẫn giao cho người đã nghỉ, và ba công cụ làm một việc — vô hình vì chúng không có trên hóa đơn đám mây. Giữ một sổ đăng ký phần mềm sống và đối chiếu nó.
• Chargeback vội vàng. Thu hồi chi phí từ các nhóm bằng dữ liệu phân bổ chưa trưởng thành, bị tranh cãi, tạo ra tranh luận làm mất uy tín cả nỗ lực. Bắt đầu với showback; giành chất lượng dữ liệu trước khi di chuyển tiền.
• Cam kết mù. Mua đặt trước ba năm cho năng lực bạn tái kiến trúc bỏ sáu tháng sau, hoặc không bao giờ mua cam kết cho đường cơ sở ổn định và trả giá theo yêu cầu đầy đủ mãi mãi. Khớp cam kết với tải thực sự dự đoán được và rà soát nó.

Mô hình trưởng thành#

Danh sách kiểm tra#

• Chi tiêu đám mây và công nghệ hiển thị gần thời gian thực, chia theo dịch vụ và nhóm, cho những người đưa ra quyết định thiết kế.
• Một chuẩn gắn thẻ bắt buộc được thực thi tự động, và tỷ lệ chi tiêu được phân bổ đúng là một chỉ số được theo dõi.
• Showback (hoặc, nơi trưởng thành, chargeback) trao cho mỗi dịch vụ một cái nhìn nhận ra được về thứ công nghệ của nó tiêu thụ.
• Các môi trường không phải sản xuất được lên lịch tắt ngoài giờ làm việc; tài nguyên được định cỡ lại theo tải quan sát được; lưu trữ có vòng đời.
• Đường cơ sở dự đoán được được bao phủ bởi chiết khấu cam kết-sử dụng hoặc năng lực đặt trước, được rà soát đều đặn.
• Một sổ đăng ký tài sản phần mềm sống đối chiếu các đăng ký SaaS và giấy phép với người dùng và mức sử dụng thực.
• Chỉ số chi phí đơn vị (chi phí trên mỗi bệnh nhân, cuộc hẹn, chuyển tuyến, lần gọi API) được xác định và theo dõi so với giá trị.
• Các phương án được thẩm định theo tổng chi phí sở hữu qua một vòng đời thực tế, gồm chi phí egress và rút lui.
• Tác động chi phí là mục thường trực trong rà soát kiến trúc, và hàng rào tự động cùng cảnh báo bất thường bắt chi tiêu mất kiểm soát trong vài giờ.
• Quyết định chi phí ảnh hưởng đến khối lượng công việc hướng tới bệnh nhân hoặc then chốt lâm sàng được rà soát riêng và không bao giờ ghi đè an toàn, khả năng chống chịu hay tính bền vững.
• Tài chính và số cùng mô hình hóa quỹ đạo capex-sang-opex, gồm khoản nợ định kỳ nhiều năm, trước các cam kết lớn.

Nguồn chính#

• FinOps Foundation — FinOps Framework (vòng đời Thông báo / Tối ưu / Vận hành, nguyên tắc, năng lực và nhân vật) — khối tri thức được công nhận cho vận hành tài chính đám mây.
• HM Treasury — The Green Book (thẩm định và đánh giá) và các quy tắc chi tiêu công về sự phân biệt giữa chi tiêu vốn và chi thường xuyên (nguồn lực).
• NHS England — hướng dẫn về đám mây, công nghệ và chi tiêu số, gồm việc áp dụng đám mây và cách xử lý vốn và chi thường xuyên trong đầu tư số của NHS.
• Hướng dẫn tối ưu chi phí well-architected của các nhà cung cấp đám mây — AWS Well-Architected Cost Optimization Pillar, Microsoft Azure Well-Architected Framework (Cost Optimization), Google Cloud Architecture Framework (Cost optimization).
• AXELOS / PeopleCert — ITIL 4, thực hành IT financial management (lập ngân sách, kế toán và tính phí dịch vụ CNTT).
• Technology Business Management (TBM) Council — phân loại và chuẩn TBM để tính chi phí và quản lý chi tiêu công nghệ minh bạch.

Tài liệu tham khảo#

1. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
2. Capital expenditure — Wikipedia — https://en.wikipedia.org/wiki/Capital_expenditure
3. Operating expense — Wikipedia — https://en.wikipedia.org/wiki/Operating_expense
4. Cost allocation — Wikipedia — https://en.wikipedia.org/wiki/Cost_allocation
5. Cost centre — Wikipedia — https://en.wikipedia.org/wiki/Cost_centre_(business)
6. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
7. Software asset management — Wikipedia — https://en.wikipedia.org/wiki/Software_asset_management
8. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
9. Software license — Wikipedia — https://en.wikipedia.org/wiki/Software_license
10. Autoscaling — Wikipedia — https://en.wikipedia.org/wiki/Autoscaling
11. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
12. Unit cost — Wikipedia — https://en.wikipedia.org/wiki/Unit_cost
13. FinOps Foundation — FinOps Framework — FinOps Foundation (Linux Foundation) — https://www.finops.org/framework/
14. HM Treasury — The Green Book: appraisal and evaluation in central government — GOV.UK — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
15. NHS England — Cloud and technology guidance — NHS England — https://www.england.nhs.uk/
16. Amazon Web Services — Well-Architected Framework: Cost Optimization Pillar — AWS — https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
17. Microsoft — Azure Well-Architected Framework: Cost Optimization — Microsoft Learn — https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/
18. Technology Business Management Council — TBM Framework and taxonomy — TBM Council — https://www.tbmcouncil.org/