Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp

Trong y tế và chăm sóc, phần lớn vòng đời, chi phí và rủi ro lâm sàng của một dịch vụ nằm sau khi vận hành — nên cách bạn chạy, giám sát và hỗ trợ một dịch vụ đang vận hành là một quyết định an toàn bệnh nhân, không phải điều nghĩ sau ở hậu trường.

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

Ra mắt là khởi đầu, không phải kết thúc. Một dịch vụ số dành vài tháng để được xây dựng và, nếu thành công, nhiều năm hay nhiều thập kỷ để được vận hành — và việc vận hành là nơi phần lớn tiền chảy đi và nơi tác hại thực sự xảy ra. Một hồ sơ chăm sóc dùng chung, một hệ thống kê đơn điện tử, hay một nền tảng hồ sơ thai sản chỉ mang lại giá trị khi nó hoạt động, đúng và đáp ứng. Khi nó suy giảm hay thất bại, hậu quả không phải bất tiện mà là điều trị bị chậm, dị ứng bị bỏ sót, phòng khám bị hủy, và bác sĩ quay về các cách xoay xở bằng giấy lạ lẫm dưới áp lực.

Y tế và chăm sóc chạy 24 giờ một ngày, bảy ngày một tuần, và không thể tạm dừng. Khi hệ thống thanh toán của một siêu thị thất bại, khách hàng chờ; khi hệ thống quản lý bệnh nhân của một bệnh viện thất bại, xe cứu thương có thể bị chuyển hướng và các danh sách mổ có kế hoạch bị hoãn. Điều này trao cho vận hành trực tiếp một sức nặng đặc thù: ngừng hoạt động là một sự kiện an toàn lâm sàng, và kế hoạch bạn phát hiện, leo thang, truyền thông và phục hồi từ nó là một phần của nghĩa vụ chăm sóc. Cuộc tấn công mã độc tống tiền WannaCry năm 2017 — buộc hủy hàng nghìn cuộc hẹn và ca mổ của NHS — là trường hợp tham chiếu cho cách một thất bại vận hành trở thành khủng hoảng an toàn bệnh nhân và niềm tin công chúng (xem Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng).

Các nhà lãnh đạo cũng cần tài trợ và bố trí nhân sự cho vận hành trực tiếp một cách trung thực. Thất bại dai dẳng trong công nghệ y tế là ăn mừng một lần vận hành, giải tán nhóm, và xem dịch vụ đang chạy là "đã xong". Một dịch vụ vận hành không có nhóm thường trực, không giám sát và không trực không tiết kiệm tiền — nó lặng lẽ tích lũy rủi ro lâm sàng cho đến ngày nó thất bại ầm ĩ. Quản lý dịch vụ là ngành giữ cho một dịch vụ vận hành an toàn, và nó xứng đáng sự nghiêm ngặt như việc xây dựng.

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

Quản lý dịch vụ và giai đoạn "Vận hành". Quản lý dịch vụ CNTT (ITSM) là tập hợp các thực hành để thiết kế, vận hành, hỗ trợ và cải tiến các dịch vụ CNTT xuyên suốt vòng đời của chúng. Trong mô hình giai đoạn GOV.UK và NHS, Vận hành (Live) là giai đoạn một dịch vụ chạy liên tục — vẫn lặp lại, vẫn được tài trợ, vẫn có người sở hữu — cho đến khi nó nghỉ hưu (xem Chủ đề 3.5 — Vòng đời triển khai). Vận hành không phải trạng thái nghỉ; đó là phần dài nhất và đắt nhất của vòng đời.

ITIL 4. ITIL là khung ITSM được dùng rộng rãi nhất. Phiên bản hiện tại, ITIL 4, định khung lại các phiên bản nặng quy trình cũ quanh một "hệ thống giá trị dịch vụ" và các thực hành linh hoạt, và được thiết kế để nằm cạnh Agile, DevOps và Lean thay vì cạnh tranh với chúng. Hãy xem ITIL là vốn từ vựng và danh sách kiểm tra các thực hành để áp dụng một cách tương xứng — không phải một bộ máy quan liêu để nhập khẩu nguyên xi.

Quản lý sự cố, vấn đề và thay đổi. Quản lý sự cố khôi phục dịch vụ bình thường nhanh nhất có thể sau một gián đoạn ngoài kế hoạch — ưu tiên là phục hồi, không phải chẩn đoán. Quản lý vấn đề điều tra nguyên nhân gốc của một hay nhiều sự cố để ngăn tái diễn, và duy trì hồ sơ các lỗi đã biết và cách xoay xở. Quản lý thay đổi (theo nghĩa ITSM) kiểm soát cách các thay đổi với hệ thống đang vận hành được đánh giá, phê duyệt và phát hành để sửa một thứ không làm hỏng thứ khác. Ba thực hành này là cốt lõi vận hành, và chúng đan xen: một sự cố có thể đặt ra một vấn đề, mà bản sửa của nó được giao như một thay đổi.

Quản lý sự cố lớn và liên tục kinh doanh. Một sự cố lớn là một sự kiện tác động cao — một hệ thống lâm sàng ngừng hoạt động trên toàn bệnh viện — cần một phản ứng được tuyên bố, phối hợp với một chỉ huy sự cố xác định, truyền thông và lãnh đạo lâm sàng. Hoạch định liên tục kinh doanh (BCP) là năng lực rộng hơn để tiếp tục cung cấp chăm sóc ở mức chấp nhận được trong khi gián đoạn, gồm các thủ tục ngừng hoạt động lâm sàng đã kiểm thử (phương án dự phòng giấy an toàn) và phục hồi sau thảm họa. Trong y tế và chăm sóc đây không phải tùy chọn: giữ bệnh nhân an toàn khi hệ thống ngừng là toàn bộ điểm mấu chốt.

Kỹ thuật độ tin cậy trang web, SLI, SLO, SLA và ngân sách lỗi. Kỹ thuật độ tin cậy trang web (SRE), khởi nguồn từ Google, áp dụng kỷ luật kỹ thuật phần mềm vào vận hành. Nó đo độ tin cậy bằng một chỉ báo mức dịch vụ (SLI) — một số đo như tính sẵn sàng hay độ trễ — so với một mục tiêu mức dịch vụ (SLO), một mục tiêu nội bộ cho số đo đó. Một thỏa thuận mức dịch vụ (SLA) là lời hứa bên ngoài, thường mang tính hợp đồng, thường đặt lỏng hơn SLO nội bộ. Khoảng cách giữa 100% và SLO của bạn là ngân sách lỗi: lượng không đáng tin bạn có thể tiêu trước khi phải ngừng giao tính năng và ổn định. Trong các hệ thống lâm sàng, SLO phải được đặt cùng bác sĩ, vì thời gian ngừng hoạt động "chấp nhận được" là một phán đoán an toàn, không chỉ kỹ thuật.

Khả năng quan sát và giám sát. Khả năng quan sát là khả năng hiểu trạng thái nội tại của một hệ thống từ các đầu ra bên ngoài của nó — nhật ký, số đo và dấu vết — để bạn có thể phát hiện và chẩn đoán vấn đề, lý tưởng là trước người dùng. Giám sát và cảnh báo biến dữ liệu đó thành tín hiệu kịp thời cho những người trực. Bạn không thể vận hành an toàn một dịch vụ mà bạn không thể thấy.

Trực, lịch luân phiên và bàn dịch vụ. Các lịch trực bảo đảm một con người có năng lực có thể phản ứng với cảnh báo suốt ngày đêm; trong một môi trường chăm sóc 24/7 chúng là thiết yếu, và phải nhân đạo, bền vững. Một bàn dịch vụ (hay bàn trợ giúp) là đầu mối liên hệ duy nhất cho người dùng cuối — bác sĩ không đăng nhập được, nhân viên lễ tân có màn hình đặt lịch bị đơ — cung cấp hỗ trợ, ghi sự cố và chuyển tiếp chúng.

DevOps, quản lý cấu hình và CMDB. DevOps và nguyên tắc SRE "bạn xây, bạn vận hành" đặt nhóm xây dịch vụ phụ trách vận hành nó, đóng khoảng cách giữa phát triển và vận hành. Quản lý cấu hình giữ một hồ sơ chính xác về các thành phần tạo nên một dịch vụ và quan hệ của chúng, thường trong một cơ sở dữ liệu quản lý cấu hình (CMDB); nếu thiếu nó, không ai có thể trả lời một cách an toàn "thay đổi này sẽ ảnh hưởng gì?" trong một sự cố.

Vận hành so với xây dựng và cho nghỉ hưu. Các tổ chức tách kinh phí xây dựng (tạo năng lực mới) khỏi kinh phí vận hành (chạy cái đang có). Thiếu kinh phí vận hành là gốc rễ cấu trúc của hầu hết các thất bại vận hành. Và mọi dịch vụ cuối cùng đều đến lúc cho nghỉ hưu — nghỉ hưu an toàn, với dữ liệu được di chuyển hoặc lưu trữ theo luật lưu giữ và người dùng được chuyển hướng — tự nó là một kỷ luật vận hành.

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

1. Tài trợ và bố trí nhân sự cho "vận hành" như một cam kết hạng nhất, không phải phần còn dư. Lập ngân sách cho vòng đời vận hành của dịch vụ — giám sát, trực, bàn dịch vụ, vá bảo mật và lặp liên tục — trước khi vận hành, và bảo vệ nó khỏi các cuộc đột kích của bản dựng bóng bẩy tiếp theo. Quy tắc kinh nghiệm của ngành rằng vận hành một hệ thống tốn nhiều hơn nhiều so với xây dựng nó trong suốt vòng đời cũng đúng trong y tế. Một dịch vụ có kinh phí xây dựng mà không có kinh phí vận hành là một rủi ro lâm sàng có ngày ra mắt.

2. Tránh phản mẫu "ném qua tường cho bộ phận vận hành". Đừng để một nhóm dự án xây một dịch vụ rồi bàn giao cho một nhóm vận hành riêng chưa bao giờ thấy nó được tạo ra. Áp dụng "bạn xây, bạn vận hành": giữ nhóm hiểu dịch vụ chịu trách nhiệm về độ tin cậy của nó, hoặc ít nhất chạy một sự chuyển giao dịch vụ có chủ đích, được ghi chép với trực chung và một giai đoạn bảo hành. Bức tường giữa xây và chạy là nơi kiến thức, quyền sở hữu và an toàn rơi qua.

3. Đặt SLO cùng bác sĩ và quản lý một ngân sách lỗi. Xác định "đủ đáng tin" nghĩa là gì cho từng dịch vụ dưới dạng SLI và SLO đo lường được, và đặt chúng cùng các bác sĩ gánh hậu quả — mục tiêu sẵn sàng cho một hệ thống khoa cấp cứu không phải lựa chọn thuần kỹ thuật. Dùng ngân sách lỗi để phân xử căng thẳng muôn thuở giữa giao tính năng và giữ ổn định: khi độ tin cậy đã tiêu hết, hãy dừng và ổn định. Giữ SLA bên ngoài lỏng hơn SLO nội bộ để bạn có chỗ hành động trước khi vi phạm một lời hứa.

4. Làm cho dịch vụ quan sát được trước khi làm nó lớn hơn. Gắn công cụ cho nhật ký, số đo và dấu vết, và xây bảng điều khiển và cảnh báo phản ánh trải nghiệm của người dùng và bác sĩ, không chỉ sức khỏe máy chủ. Cảnh báo về các triệu chứng quan trọng (bệnh nhân không thể được đặt lịch) thay vì mọi nhấp nháy bên dưới, để tránh mệt mỏi vì cảnh báo vốn dạy người ứng phó phớt lờ các lời gọi. Bạn không thể giữ an toàn một dịch vụ mà bạn biết thất bại của nó từ những bác sĩ giận dữ.

5. Chạy quản lý sự cố, vấn đề và thay đổi có kỷ luật — một cách tương xứng. Trao cho sự cố các mức nghiêm trọng rõ ràng, mục tiêu phản ứng, một chỉ huy sự cố cho các sự cố lớn, và một nguồn sự thật duy nhất trong phản ứng. Đưa các sự cố nghiêm trọng vào các cuộc rà soát sau sự cố không đổ lỗi và một quy trình quản lý vấn đề sửa nguyên nhân gốc thay vì liên tục khởi động lại máy chủ. Kiểm soát các thay đổi qua một quy trình có kích cỡ phù hợp — thay đổi nhẹ, tiêu chuẩn, được duyệt trước cho công việc thường lệ rủi ro thấp; chỉ rà soát tư vấn thay đổi cho các thay đổi thực sự rủi ro — để quản trị bảo vệ an toàn mà không trở thành điểm nghẽn cám dỗ người ta đi vòng nó.

6. Diễn tập sự cố lớn và ngừng hoạt động lâm sàng, đừng chỉ ghi chép chúng. Viết, kiểm thử và thường xuyên thực hành các thủ tục liên tục kinh doanh và ngừng hoạt động lâm sàng: cách chăm sóc tiếp tục trên giấy, cách nhân viên được thông báo hệ thống đang ngừng, cách dữ liệu được đối chiếu khi phục hồi, và ai tuyên bố và chỉ huy một sự cố lớn. Các kế hoạch chưa kiểm thử thất bại vào ngày thực. Nối điều này rõ ràng với quản lý rủi ro lâm sàng và nhật ký mối nguy của bạn (xem Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro), vì ngừng hoạt động là một mối nguy lâm sàng với một biện pháp giảm thiểu bạn có thể diễn tập.

7. Xem việc học sau sự cố là không đổ lỗi và mang tính hệ thống. Sau mỗi sự cố đáng kể, chạy một cuộc rà soát hỏi hệ thống đã cho phép thất bại như thế nào, không phải ai để đổ lỗi — vì đổ lỗi đẩy việc báo cáo xuống ngầm và lặp lại tác hại. Ghi nhận các hành động, giao người sở hữu, và theo dõi chúng đến khi đóng; đưa các mô thức vào quản lý vấn đề và thiết kế. Một văn hóa học hỏi là một biện pháp kiểm soát an toàn bệnh nhân, phản chiếu "văn hóa công bằng" của báo cáo sự cố lâm sàng.

8. Giữ một hồ sơ cấu hình chính xác và quản lý toàn bộ hệ thống. Duy trì một CMDB hoặc bản kiểm kê tương đương về cái gì chạy, cái gì phụ thuộc vào cái gì, phiên bản nào được triển khai, và ai sở hữu từng dịch vụ, để trong một sự cố bạn có thể trả lời "việc này ảnh hưởng gì?" trong vài phút. Điều này nền tảng cho thay đổi an toàn, vá bảo mật và cấp phép, và là nơi hầu hết các hệ thống NHS lớn yếu nhất. Một hệ thống không rõ, chưa vá vừa là một sự cố ngừng hoạt động vừa là một sự cố an ninh mạng đang chờ xảy ra (xem Chủ đề 1.7).

9. Làm cho việc trực bền vững và hỗ trợ mang tính con người. Thiết kế lịch trực có đủ người, được trả công công bằng và nhân đạo, với leo thang rõ ràng và kỳ vọng thực tế — người ứng phó kiệt sức đưa ra quyết định chậm, dễ sai ngay vào những khoảnh khắc quan trọng nhất. Cấp nguồn lực cho bàn dịch vụ theo nhu cầu thực của một lực lượng lâm sàng 24/7, và trao cho nhân viên tuyến đầu một con đường nhanh, được tôn trọng để báo cáo vấn đề. Chất lượng hỗ trợ của bạn là chất lượng chăm sóc mà nhân viên trải nghiệm từ dịch vụ của bạn.

10. Lên kế hoạch cho nghỉ hưu như một hoạt động được kiểm soát. Quyết định, khi dịch vụ còn đang chạy, nó sẽ cuối cùng được cho nghỉ hưu ra sao: di chuyển hoặc lưu trữ dữ liệu theo luật lưu giữ hồ sơ, chuyển hướng người dùng, thông báo bác sĩ, và bảo tồn nhật ký mối nguy và dấu vết kiểm toán. Một sự nghỉ hưu không có kế hoạch để lại dữ liệu và người dùng bị bỏ rơi và có thể vi phạm các nghĩa vụ lưu giữ luật định. Một sự nghỉ hưu có kế hoạch là một dự án vận hành có thể kiểm toán, không phải một cuộc chạy đua khi sản phẩm thay thế đến.

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

1. Khi một hệ thống lâm sàng then chốt ngừng hoạt động lúc 3 giờ sáng ngày lễ, chính xác ai làm gì — và chúng ta đã bao giờ kiểm thử chưa? Câu hỏi này buộc phân biệt giữa một kế hoạch được ghi chép và một năng lực thực. Trong y tế và chăm sóc, ngừng hoạt động là một sự kiện lâm sàng: các câu hỏi thực tế là ai được gọi, phản ứng nhanh đến đâu, ai có thẩm quyền tuyên bố một sự cố lớn, nhân viên lâm sàng được bảo chuyển sang thủ tục ngừng hoạt động ra sao, bệnh nhân giữ an toàn trên giấy thế nào, và dữ liệu được đối chiếu khi phục hồi như thế nào. Hãy tranh luận lịch trực của bạn có thực sự có sự bao phủ có năng lực vào giờ bất tiện và ngày lễ không, hay nó mỏng đi thành một người kiệt sức khi rủi ro cao nhất. Hãy cân nhắc liệu các bác sĩ có biết thủ tục ngừng hoạt động và đã từng diễn tập nó chưa, hay nó nằm trong một tập hồ sơ chưa ai mở. Một câu trả lời tốt, trung thực mô tả một phản ứng đã được kiểm thử — với các vai trò có tên, một cuộc diễn tập thực trong năm qua, và các bài học đã được hành động — không phải một tài liệu chính sách chưa từng gặp một sự cố ngừng hoạt động. Nơi câu trả lời trung thực là "chúng tôi thực sự không biết", đó tự nó là phát hiện quan trọng nhất để nêu với hội đồng.

2. Chúng ta có thực sự tài trợ và bố trí nhân sự cho "vận hành", hay đã ăn mừng lần vận hành rồi lặng lẽ bỏ đi? Phần lớn chi phí và rủi ro lâm sàng của một dịch vụ nằm sau khi ra mắt, thế nhưng các mô hình kinh phí thưởng cho việc xây thứ mới và bỏ đói việc vận hành thứ cũ. Căng thẳng cần tranh luận là sức kéo cấu trúc của kinh phí xây dựng so với công việc không hào nhoáng, thiết yếu của giám sát, vá, hỗ trợ và lặp một dịch vụ đang vận hành trong nhiều năm. Hãy nhìn thẳng vào hệ thống đang vận hành của bạn: bao nhiêu dịch vụ có một người sở hữu có tên, một nhóm được tài trợ, các bản vá bảo mật hiện hành và giám sát hoạt động — và bao nhiêu dịch vụ mồ côi, chạy trên phần mềm không được hỗ trợ, không ai chịu trách nhiệm? Hãy cân nhắc mô thức "ném qua tường cho bộ phận vận hành" và liệu những người vận hành từng dịch vụ có hiểu nó được xây thế nào không. Một câu trả lời tốt có thể chỉ ra ngân sách vận hành được bảo vệ, những người sở hữu dịch vụ có tên cho vòng đời vận hành, và một sự chuyển giao dịch vụ có chủ đích thay vì một sự bỏ rơi, và có thể gọi tên trung thực các dịch vụ mồ côi để chúng có thể được nhận nuôi, thay thế hoặc cho nghỉ hưu thay vì để thất bại.

3. Chúng ta quyết định "đủ đáng tin" nghĩa là gì như thế nào — và ai được lên tiếng? Độ tin cậy không miễn phí, và đuổi theo thêm một số chín về tính sẵn sàng có thể tốn hơn tác hại nó ngăn chặn; nhưng trong các hệ thống lâm sàng, thời gian ngừng hoạt động "chấp nhận được" là một phán đoán an toàn mà kỹ sư không thể tự đưa ra. Câu hỏi này hỏi liệu bạn có SLI và SLO rõ ràng không, chúng có được đặt cùng các bác sĩ và lãnh đạo vận hành gánh hậu quả không, và bạn có dùng thứ gì như ngân sách lỗi để cân bằng giữa giao cải tiến và giữ ổn định không. Hãy tranh luận sự khác biệt giữa mục tiêu nội bộ bạn quản lý theo và SLA bên ngoài bạn hứa, và liệu việc giám sát của bạn đo điều bác sĩ thực sự trải nghiệm hay chỉ điều máy chủ báo cáo. Hãy cân nhắc liệu "chúng tôi nhắm 99,9%" có răng không — một phép đo xác định, một hậu quả khi vi phạm, một người sở hữu hành động. Một câu trả lời tốt nối một mục tiêu độ tin cậy với một lập luận an toàn lâm sàng, cho thấy số đo được đo và có người sở hữu, và mô tả nhóm làm khác đi thế nào khi ngân sách đã tiêu hết, thay vì một con số trên một bản trình chiếu mà không ai quản lý theo.

4. Chúng ta có thực sự biết mình đang chạy gì — và có thể trả lời "thay đổi này sẽ ảnh hưởng gì?" giữa một sự cố không? Hầu hết các hệ thống y tế và chăm sóc lớn yếu nhất chính xác ở nơi đau nhất: không ai nắm một bức tranh chính xác, hiện hành về cái gì chạy, cái gì phụ thuộc vào cái gì, phiên bản nào được triển khai, và ai sở hữu từng dịch vụ. Câu hỏi này thăm dò liệu bạn có duy trì một hồ sơ cấu hình — một CMDB hoặc tương đương — hay kiến thức đó nằm trong đầu một nhúm người và cả thập kỷ tích hợp không được ghi chép. Hãy tranh luận hậu quả thực: một thay đổi lặng lẽ làm hỏng một hệ thống hạ nguồn, một bản vá bảo mật không thể áp dụng vì không ai biết nó sẽ chạm vào gì, một máy chủ không được hỗ trợ chỉ bị phát hiện khi nó hỏng hoặc bị khai thác. Căng thẳng là quản lý cấu hình không hào nhoáng, không bao giờ xong và dễ hoãn, nhưng nó nền tảng cho thay đổi an toàn, vá, cấp phép và khả năng chống chịu mạng — cùng điểm mù đã biến WannaCry thành khủng hoảng. Một câu trả lời trung thực mô tả một bản kiểm kê được duy trì với người sở hữu và các phụ thuộc mà người ta tin và dùng trong các sự cố, và gọi tên những phần của hệ thống vẫn còn tối, thay vì tuyên bố một mức hoàn chỉnh mà không tổ chức lớn nào thực sự có.

5. Khi có điều gì sai, chúng ta học hỏi hay chúng ta tìm ai đó để đổ lỗi? Văn hóa của các cuộc rà soát sự cố quyết định liệu cùng một tác hại có tái diễn. Câu hỏi này hỏi liệu các sự cố nghiêm trọng có kích hoạt một cuộc rà soát không đổ lỗi, mang tính hệ thống hỏi hệ thống đã cho phép thất bại như thế nào — hay chúng lặng lẽ săn lùng một cá nhân để quy lỗi, điều đẩy việc báo cáo xuống ngầm và đảm bảo sự lặp lại. Hãy tranh luận các suýt xảy ra và thất bại nhỏ có được nêu ra không, hay chỉ những sự cố ngừng hoạt động quá lớn để giấu; các hành động rà soát có được giao người sở hữu và theo dõi đến khi đóng, hay được viết ra rồi quên; và các mô thức có phản hồi vào quản lý vấn đề và thiết kế không. Hãy cân nhắc sự song song với báo cáo sự cố lâm sàng và "văn hóa công bằng": cùng một tổ chức có thể giữ một lập trường trưởng thành, không đổ lỗi với các sự cố an toàn bệnh nhân nhưng một lập trường trừng phạt với các thất bại CNTT, hoặc ngược lại. Một câu trả lời tốt cho thấy một văn hóa học hỏi có bằng chứng — các cuộc rà soát đã thay đổi hệ thống, các hành động đã đóng, sự tái diễn giảm — và một sự thừa nhận trung thực về nơi nỗi sợ vẫn kìm hãm việc báo cáo, vì một văn hóa học hỏi tự nó là một biện pháp kiểm soát an toàn bệnh nhân, không phải phần phụ mềm mỏng.

6. Chúng ta đã quyết định dịch vụ này sẽ cuối cùng được cho nghỉ hưu ra sao — khi nó còn sống để lên kế hoạch chưa? Mọi dịch vụ cuối cùng đều được thay thế hoặc tắt đi, thế nhưng cho nghỉ hưu hầu như luôn là điều nghĩ sau, được chạy đua khi sản phẩm kế nhiệm đến và hệ thống cũ đã là chướng ngại. Câu hỏi này hỏi liệu, với mỗi dịch vụ đang vận hành, bạn có kế hoạch cho sự nghỉ hưu an toàn không: dữ liệu được di chuyển hoặc lưu trữ theo luật lưu giữ hồ sơ, người dùng được chuyển hướng, bác sĩ được thông báo, và nhật ký mối nguy cùng dấu vết kiểm toán được bảo tồn. Hãy tranh luận các rủi ro y tế và chăm sóc cụ thể của việc làm sai — hồ sơ bị bỏ rơi vi phạm nghĩa vụ lưu giữ luật định, dữ liệu mồ côi không ai truy cập được, một hệ thống cũ "tạm thời" kéo dài nhiều năm không vá vì không ai sở hữu sự kết thúc của nó. Hãy cân nhắc rằng ở các hệ thống quốc gia và doanh nghiệp, hàng thập kỷ hồ sơ lâm sàng có thể nằm trong một hệ thống phải được cho nghỉ hưu mà không mất một hồ sơ nào theo luật. Một câu trả lời trung thực xem nghỉ hưu là một hoạt động có tên, được tài trợ, có thể kiểm toán, được lên kế hoạch từ lúc vận hành, không phải một chi phí được khám phá sau, và có thể chỉ ra ít nhất một dịch vụ mà sự kết thúc vòng đời đã được quyết định thay vì hoãn.

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

Một hệ thống chăm sóc tích hợp (ICS) vận hành một hồ sơ chăm sóc dùng chung được các bác sĩ bệnh viện, bác sĩ gia đình, các nhóm cộng đồng và dịch vụ ngoài giờ trên cả khu vực sử dụng. Nó vận hành hai năm trước; chương trình xây dựng đã đóng và một nhóm sản phẩm-và-vận hành thường trực nay sở hữu nó. Nhóm đó đã học quản lý dịch vụ theo cách khó khăn.

Ban đầu, hồ sơ chỉ có giám sát thời gian hoạt động của máy chủ. Một buổi tối mùa đông, các máy chủ "xanh" trong khi một tích hợp bị hỏng lặng lẽ ngừng việc cập nhật thuốc của bác sĩ gia đình chảy qua — nên các bác sĩ bệnh viện thấy danh sách thuốc cũ trong vài giờ trước khi một dược sĩ nhận ra và gọi bàn dịch vụ. Cuộc rà soát sau sự cố không đổ lỗi và mang tính hệ thống: nó thấy vấn đề thực sự là thiếu một SLI phản ánh trải nghiệm của bác sĩ. Nhóm bổ sung khả năng quan sát đầu cuối, một SLO về độ mới của dữ liệu được thống nhất chung với một cán bộ an toàn lâm sàng, và một cảnh báo gọi người trực khi các cập nhật chậm vượt ngưỡng an toàn. Mối nguy này được thêm vào nhật ký mối nguy rủi ro lâm sàng (Chủ đề 1.6).

Sau đó họ điều chỉnh kích cỡ các thực hành. Các cập nhật cấu hình thường lệ, rủi ro thấp trở thành các thay đổi tiêu chuẩn được duyệt trước, giao qua một đường ống tự động với quay lui nhanh; chỉ các thay đổi thực sự rủi ro mới đến một buổi rà soát thay đổi hằng tuần có đại diện lâm sàng. Một lịch trực nhân đạo bao phủ đêm và ngày lễ, được hậu thuẫn bởi một bàn dịch vụ được cấp nguồn lực theo nhu cầu 24/7 thực. Quan trọng là họ đã viết và nay diễn tập hai lần mỗi năm một thủ tục ngừng hoạt động lâm sàng: một bản sao đệm chỉ đọc của các hồ sơ chính, một phương án dự phòng bằng giấy, một chuỗi SMS thông báo cho bác sĩ rằng hệ thống đang suy giảm, và một bước đối chiếu khi phục hồi. Khi một sự cố mất điện trung tâm dữ liệu làm hệ thống chính ngừng hoạt động bốn mươi phút mùa xuân vừa rồi, việc chăm sóc tiếp tục trên phương án dự phòng đã kiểm thử, chỉ huy sự cố điều hành một phản ứng bình tĩnh, phối hợp, và không bệnh nhân nào bị hại. Hội đồng thấy một báo cáo độ tin cậy gắn với các thước đo an toàn lâm sàng, không phải một lời trấn an mơ hồ — và quyền sở hữu dịch vụ cho đến khi nghỉ hưu cuối cùng đã được gọi tên và tài trợ.

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

Công ty khởi nghiệp#

Một công ty công nghệ y tế nhỏ thường không có chức năng vận hành riêng, nên "bạn xây, bạn vận hành" là mặc định chứ không phải khát vọng — chính những kỹ sư viết mã mang máy nhắn tin. Lợi thế là phản hồi nhanh và không có bức tường để ném công việc qua; mối nguy là một lịch trực hai người không bền vững cũng không an toàn, và giám sát dừng ở "máy chủ có chạy không?". Các công ty khởi nghiệp nên áp dụng SLO, khả năng quan sát cơ bản, rà soát sau sự cố không đổ lỗi và một thủ tục ngừng hoạt động bằng văn bản từ khách hàng NHS đầu tiên, vì một sự cố ngừng hoạt động lâm sàng có thể kết liễu cả hợp đồng lẫn công ty. Ngay cả khi không có nghi thức ITIL, ý định — thấy dịch vụ, phản ứng nhanh, học hỏi mang tính hệ thống, giữ bệnh nhân an toàn khi nó thất bại — là không thể thương lượng trong y tế.

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, hoặc một phòng khám đơn lẻ — chạy các hệ thống lâm sàng đang vận hành mỗi ngày nhưng thường không có chức năng CNTT chuyên trách và không ai có công việc là quản lý dịch vụ. Ở đây "vận hành" bị ép vào lề công việc lâm sàng và hành chính, việc trực thực chất là "điện thoại di động của người quản lý phòng khám", và giám sát là một bác sĩ nhận thấy màn hình đặt lịch bị đơ. Các ưu tiên thực dụng là vài thứ giữ bệnh nhân an toàn: một thủ tục ngừng hoạt động bằng văn bản, được diễn tập (cách phòng khám khám bệnh trên giấy và đối chiếu sau), một con đường đã biết để leo thang tới từng nhà cung cấp khi một hệ thống được lưu trữ thất bại, và sự rõ ràng về những SLA mà các nhà cung cấp đó thực sự nợ. Một nhà cung cấp công nghệ y tế độc lập nhỏ đã qua giai đoạn khởi nghiệp đối mặt với bức tranh phản chiếu — khách hàng thực phụ thuộc vào nó nhưng sự bao phủ vận hành mỏng — và phải đưa ra giờ hỗ trợ đáng tin cậy và ứng phó sự cố bất chấp tiền mặt eo hẹp. Nghĩa vụ chăm sóc giống hệt một bệnh viện lớn; nguồn lực thì không, nên kỷ luật là ưu tiên không khoan nhượng các điều cơ bản then chốt về an toàn hơn sự đầy đủ của ITIL.

Doanh nghiệp lớn#

Một bệnh viện NHS hoặc nhà cung ứng lớn chạy quản lý dịch vụ ở dạng đầy đủ nhất: một bàn dịch vụ chính thức, các thực hành sự cố/vấn đề/thay đổi theo ITIL, hội đồng tư vấn thay đổi, kế hoạch sự cố lớn và liên tục kinh doanh, và thường là một trung tâm vận hành 24/7. Thách thức đặc trưng là một hệ thống cũ trải rộng với hồ sơ cấu hình yếu, hệ thống chưa vá và quyền sở hữu không rõ — những điều kiện đã biến WannaCry thành khủng hoảng. Các thất bại kinh điển là quy trình thay đổi nặng đến mức nhân viên đi vòng, và "vận hành" liên tục bị bỏ đói để tài trợ bản dựng tiếp theo. Doanh nghiệp lớn có nguồn lực để làm khả năng quan sát, trực bền vững và liên tục được kiểm thử đúng cách, nên nhiệm vụ là giữ các thực hành tương xứng và thực sự do giới lâm sàng làm chủ thay vì một nghi thức giấy tờ mang lại sự đảm bảo giả.

Chính phủ#

Một cơ quan quốc gia vận hành các dịch vụ có thể chạm đến hàng triệu người, nên một sự cố ngừng hoạt động là một sự cố quốc gia với hậu quả về Nghị viện và niềm tin công chúng, và các mục tiêu độ tin cậy là vấn đề trách nhiệm giải trình công khai. Triển khai của chính phủ ghép ITSM với kỳ vọng của Sổ tay Dịch vụ GOV.UK rằng các dịch vụ đang vận hành được vận hành, giám sát và lặp lại đúng cách — không bị đóng băng lúc ra mắt — và với các nghĩa vụ luật định về lưu giữ hồ sơ và an ninh mạng (NCSC, DSPT). Kiểm soát chi tiêu và các thỏa thuận kinh phí nhiều năm định hình kinh phí "vận hành" trông ra sao, và quy mô thuần túy nâng rủi ro của liên tục kinh doanh, phản ứng sự cố lớn phối hợp, và việc cho nghỉ hưu an toàn các hệ thống quốc gia cũ với hàng thập kỷ hồ sơ. Sự đánh đổi là đảm bảo và khả năng chống chịu so với tốc độ và chi phí, được giải quyết công khai dưới sự soi xét.

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

• Ném qua tường cho bộ phận vận hành. Một nhóm xây bàn giao dịch vụ cho một nhóm vận hành chưa bao giờ thấy nó được tạo ra; kiến thức, quyền sở hữu và an toàn rơi qua khoảng trống. Giải pháp: "bạn xây, bạn vận hành", hoặc một sự chuyển giao có chủ đích với giai đoạn bảo hành và trực chung.
• Dịch vụ vận hành mồ côi. Dự án đóng, nhóm giải tán, kinh phí vận hành bốc hơi; dịch vụ mục nát, không vá, và tích lũy rủi ro lâm sàng và mạng một cách thầm lặng. Giải pháp: người sở hữu dịch vụ có tên và ngân sách vận hành được bảo vệ cho vòng đời vận hành.
• Giám sát máy chủ, không phải dịch vụ. Mọi thứ "xanh" trong khi bác sĩ thấy dữ liệu cũ hoặc thiếu. Giải pháp: SLI phản ánh trải nghiệm của người dùng và bác sĩ, với cảnh báo về các triệu chứng quan trọng.
• Kế hoạch liên tục chưa kiểm thử. Một thủ tục ngừng hoạt động lâm sàng tồn tại trên giấy nhưng chưa bao giờ được diễn tập, nên nó thất bại vào ngày thực. Giải pháp: diễn tập thường xuyên các kế hoạch sự cố lớn và ngừng hoạt động và sửa những gì hỏng.
• Rà soát sự cố do đổ lỗi dẫn dắt. Săn lỗi đẩy việc báo cáo xuống ngầm và lặp lại tác hại. Giải pháp: học sau sự cố không đổ lỗi, mang tính hệ thống với các hành động được theo dõi.
• Sân khấu quy trình thay đổi. Một hội đồng thay đổi nặng đến mức các nhóm đi vòng, hoặc nhẹ đến mức thay đổi rủi ro được giao không kiểm tra. Giải pháp: điều chỉnh kích cỡ — duyệt trước thay đổi tiêu chuẩn, dành rà soát cho thay đổi thực sự rủi ro.
• Không có hồ sơ cấu hình. Không ai trả lời được "thay đổi này sẽ ảnh hưởng gì?" trong một sự cố. Giải pháp: duy trì CMDB hoặc tương đương với quyền sở hữu và các phụ thuộc.

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

Danh sách kiểm tra#

• Mọi dịch vụ đang vận hành có một người sở hữu có tên và một ngân sách vận hành được bảo vệ cho vòng đời vận hành.
• Nhóm vận hành mỗi dịch vụ hiểu nó được xây như thế nào (hoặc có một sự chuyển giao được ghi chép với bảo hành và trực chung).
• SLI và SLO được xác định, và mục tiêu của các hệ thống lâm sàng được đặt cùng bác sĩ; SLA bên ngoài lỏng hơn SLO nội bộ.
• Khả năng quan sát (nhật ký, số đo, dấu vết) và cảnh báo theo triệu chứng phản ánh trải nghiệm của bác sĩ và người dùng, không chỉ sức khỏe máy chủ.
• Quản lý sự cố có mức nghiêm trọng, mục tiêu phản ứng, vai trò chỉ huy sự cố và một nguồn sự thật duy nhất trong phản ứng.
• Quản lý vấn đề sửa nguyên nhân gốc; các cuộc rà soát sau sự cố không đổ lỗi và hành động của chúng được theo dõi đến khi đóng.
• Quản lý thay đổi có kích cỡ phù hợp: thay đổi tiêu chuẩn được duyệt trước và tự động hóa; chỉ thay đổi rủi ro được rà soát, với đóng góp lâm sàng.
• Các thủ tục liên tục kinh doanh và ngừng hoạt động lâm sàng được viết, nối với nhật ký mối nguy, và diễn tập ít nhất hằng năm.
• Lịch trực có đủ người, nhân đạo và được trả công công bằng; bàn dịch vụ được cấp nguồn lực theo nhu cầu 24/7 thực.
• Một hồ sơ cấu hình (CMDB hoặc tương đương) liệt kê thành phần, phụ thuộc, phiên bản và người sở hữu, và hỗ trợ vá bảo mật.
• Một kế hoạch cho nghỉ hưu bao phủ di chuyển/lưu trữ dữ liệu theo luật lưu giữ, chuyển hướng người dùng, và bảo tồn hồ sơ an toàn và kiểm toán.

Nguồn chính#

• ITIL 4 — hệ thống giá trị dịch vụ và các thực hành quản lý (sự cố, vấn đề, thay đổi, bàn dịch vụ, quản lý mức dịch vụ) — PeopleCert / AXELOS.
• Google — Site Reliability Engineering và The Site Reliability Workbook (SLI, SLO, ngân sách lỗi, trực, post-mortem không đổ lỗi).
• Sổ tay Dịch vụ GOV.UK — vận hành và lặp một dịch vụ đang chạy; giám sát trạng thái của một dịch vụ; duy trì một dịch vụ sau khi ra mắt.
• NHS England — các tiêu chuẩn quản lý rủi ro lâm sàng DCB0129/DCB0160 và việc đối xử ngừng hoạt động hệ thống như một mối nguy lâm sàng (xem Chủ đề 1.6).
• NHS England / NCSC — vận hành an ninh mạng, Bộ công cụ Bảo mật và Bảo vệ Dữ liệu (DSPT), và các bài học từ sự cố WannaCry 2017 (xem Chủ đề 1.7).
• ISO/IEC 20000 (quản lý dịch vụ CNTT) và ISO 22301 (hệ thống quản lý liên tục kinh doanh).
• DevOps Research and Assessment (DORA) — các năng lực nối hiệu suất triển khai và vận hành (giám sát, thay đổi, độ tin cậy).
• OKR và KPI cho báo cáo vận hành và độ tin cậy cho lãnh đạo (xem Chủ đề 10.0 — Mục tiêu và kết quả chính (OKR)).

Tài liệu tham khảo#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/