Chủ đề 3.9 — Liên tục kinh doanh và phục hồi sau thảm họa

Trong y tế và chăm sóc, một sự cố ngừng hoạt động hệ thống lớn là một sự kiện an toàn bệnh nhân trước khi nó là một vấn đề CNTT, vì vậy khả năng tiếp tục cung cấp chăm sóc khi một hệ thống ngừng — và phục hồi nó đầy đủ, nhanh chóng — là một năng lực cốt lõi về lâm sàng và niềm tin công chúng, không phải chú thích kỹ thuật.

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

Chăm sóc không dừng lại khi công nghệ dừng. Khi một hồ sơ bệnh nhân điện tử, một nền tảng kê đơn điện tử, hay một hệ thống kết quả xét nghiệm thất bại trên toàn bệnh viện, bác sĩ không được tạm dừng điều trị trong lúc kỹ sư làm việc. Họ phải tiếp tục khám bệnh nhân, kê thuốc và ra quyết định — thường không có các cảnh báo dị ứng, kiểm tra liều và tiền sử mà hệ thống hỏng thường cung cấp. Đó là lý do một sự cố ngừng hoạt động không chỉ được đo bằng giờ ngừng và tín dụng dịch vụ; nó được đo bằng chẩn đoán bị chậm, tương tác thuốc bị bỏ sót, ca mổ bị hủy, và rủi ro thêm mà mọi bác sĩ làm việc mù mịt phải gánh. Liên tục kinh doanh là ngành bảo đảm rằng khi điều tồi tệ nhất xảy ra, việc chăm sóc vẫn an toàn nhất có thể.

Rủi ro mang tính quốc gia và được ghi nhận rõ. Cuộc tấn công mã độc tống tiền WannaCry năm 2017 đã làm gián đoạn khoảng một phần ba các bệnh viện NHS ở Anh, buộc hủy hàng nghìn cuộc hẹn và ca mổ, chuyển hướng xe cứu thương, và khóa nhân viên khỏi chính các thiết bị — gồm một số thiết bị chẩn đoán hình ảnh và bệnh học — mà họ cần để điều trị người bệnh. Nó tốn NHS ước tính 92 triệu bảng và, quan trọng hơn, cho thấy một cuộc tấn công mạng vào hạ tầng y tế đáp xuống như một cuộc khủng hoảng lâm sàng, không chỉ một sự cố an ninh dữ liệu. Từ đó, khả năng chống chịu đã chuyển từ phòng máy chủ sang bàn hội đồng, và đúng như vậy.

Chủ đề này mở rộng kỷ luật vận hành của Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp, nhưng chuyển trọng tâm từ vận hành thường ngày sang gián đoạn lớn: hỏa hoạn, lũ lụt, tấn công mạng, sụp đổ nhà cung cấp, hay sự cố khu vực đe dọa làm một dịch vụ then chốt ngừng hoạt động hàng giờ hay hàng ngày. Nó nối chặt với Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng (vì phục hồi sau mã độc tống tiền nay là kịch bản liên tục trung tâm), với Chủ đề 4.0 — Kiến trúc kỹ thuật, đám mây và hệ thống cũ (vì khả năng chống chịu được thiết kế vào, không gắn thêm), và với Chủ đề 6.4 — Quản trị và đảm bảo (vì ai đó phải sở hữu, kiểm thử và chịu trách nhiệm về kế hoạch). Làm đúng thì gián đoạn là một ngày tồi tệ; làm sai thì nó là một cuộc điều tra công khai.

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

Liên tục kinh doanh và phục hồi sau thảm họa. Hoạch định liên tục kinh doanh (BCP) là năng lực tiếp tục cung cấp sản phẩm hoặc dịch vụ — trong trường hợp của bạn, chăm sóc an toàn — ở các mức chấp nhận được đã xác định trước trong và sau một sự cố gây gián đoạn. Phục hồi sau thảm họa CNTT (DR) là tập con kỹ thuật hẹp hơn liên quan đến việc khôi phục các hệ thống, dữ liệu và hạ tầng làm nền cho các dịch vụ đó. Liên tục kinh doanh là lời hứa rộng hơn ("bệnh nhân vẫn tiếp tục được điều trị"); phục hồi sau thảm họa là một trong các phương tiện ("hệ thống kết quả quay lại trong vòng bốn giờ"). Bạn cần cả hai, và không được nhầm một máy chủ được khôi phục với một dịch vụ được khôi phục.

Quản lý liên tục kinh doanh và phân tích tác động kinh doanh. Quản lý liên tục kinh doanh (BCM) là quá trình quản lý liên tục — không phải một tài liệu một lần — xác định các mối đe dọa và xây dựng khả năng chống chịu của tổ chức. Nền tảng của nó là phân tích tác động kinh doanh (BIA): một đánh giá có cấu trúc về từng dịch vụ hỏi việc mất nó gây tác hại không chấp nhận được nhanh đến đâu, nó phụ thuộc vào gì, và bạn có thể chịu mất dữ liệu lùi lại bao xa. BIA là nơi phán đoán lâm sàng bước vào kỹ thuật: bác sĩ, không chỉ nhà công nghệ, phải xác định "không chấp nhận được" nghĩa là gì với một hệ thống sản khoa so với mạng nội bộ của nhân viên.

Mục tiêu thời gian phục hồi và mục tiêu điểm phục hồi. Hai con số neo mọi kế hoạch phục hồi. Mục tiêu thời gian phục hồi (RTO) là thời gian tối đa chấp nhận được để khôi phục một dịch vụ sau thất bại. Mục tiêu điểm phục hồi (RPO) là lượng mất dữ liệu tối đa chấp nhận được, biểu thị bằng thời gian — một RPO mười lăm phút nghĩa là bạn có thể chịu mất nhiều nhất mười lăm phút nhập liệu cuối. Với một hệ thống lâm sàng then chốt chúng có thể là vài phút; với một kho báo cáo chúng có thể là vài ngày. Đặt chúng một cách trung thực, theo từng dịch vụ, là quyết định liên tục hữu ích nhất bạn sẽ đưa ra.

Sao lưu và khôi phục đã kiểm thử. Một bản sao lưu là một bản sao dữ liệu lưu ở nơi khác để bản gốc có thể được khôi phục sau khi mất. Mức cơ sở của ngành là quy tắc 3-2-1: ba bản sao, trên hai loại phương tiện, với một bản giữ ngoài địa điểm (và, trong thời đại mã độc tống tiền, một bản bất biến hoặc ngoại tuyến). Điều then chốt là một bản sao lưu bạn chưa bao giờ khôi phục là hy vọng, không phải biện pháp kiểm soát. Mã độc tống tiền thường xuyên mã hóa các bản sao lưu có thể truy cập từ mạng, và các lần khôi phục chưa kiểm thử thường xuyên thất bại vào ngày thực. Kỷ luật không phải là "chúng ta có sao lưu không?" mà là "lần cuối chúng ta khôi phục thành công, đầu cuối, là khi nào, và nó mất bao lâu?"

Tính sẵn sàng cao, dư thừa và chuyển đổi dự phòng. Tính sẵn sàng cao (HA) là thuộc tính thiết kế giữ một hệ thống chạy qua thất bại của thành phần, thường đo bằng "số chín" thời gian hoạt động. Nó đạt được thông qua dư thừa — sự nhân đôi có chủ đích các thành phần then chốt — và chuyển đổi dự phòng (failover), việc tự động chuyển sang một thành phần hoặc địa điểm dự phòng khi thành phần chính thất bại. Tính sẵn sàng cao giảm tần suất ngừng hoạt động; phục hồi sau thảm họa xử lý những lần lọt qua. Chúng bổ sung cho nhau, không phải phương án thay thế, và nhầm lẫn chúng để lại những khoảng trống nguy hiểm.

Điểm lỗi đơn và các phụ thuộc then chốt. Một điểm lỗi đơn (SPOF) là bất kỳ thành phần nào mà thất bại của nó dừng cả dịch vụ — một đường mạng, một dịch vụ xác thực, một nhà cung cấp, một cơ sở dữ liệu, hay một người duy nhất biết cách thứ gì đó hoạt động. Vẽ bản đồ SPOF và các phụ thuộc then chốt (các dịch vụ thượng nguồn và bên thứ ba mà dịch vụ của bạn âm thầm dựa vào) là trái tim phân tích của khả năng chống chịu. Trong CNTT y tế hiện đại, các phụ thuộc hiếm khi mang tính địa phương: một dịch vụ đăng nhập một lần, một kết nối trục xương sống quốc gia, hay một vùng đám mây có thể làm nhiều hệ thống ngừng cùng lúc.

Ngừng hoạt động lâm sàng và các thủ tục liên tục kinh doanh. Y tế và chăm sóc có một biện pháp kiểm soát đặc thù mà CNTT chung thiếu: thủ tục ngừng hoạt động lâm sàng, một phương án dự phòng an toàn, được diễn tập — thường là giấy — để cung cấp chăm sóc khi một hệ thống số không khả dụng, cộng với quy trình nhập lại để đối chiếu hồ sơ giấy trở lại hệ thống khi nó quay lại. Đây là liên tục kinh doanh được cụ thể hóa tại giường bệnh, và là nơi các kế hoạch liên tục thường gặp thực tế nhất.

Mã độc tống tiền và phục hồi mạng. Mã độc tống tiền mã hóa dữ liệu của bạn và đòi tiền, và đã trở thành mối đe dọa liên tục xác định cho các hệ thống y tế. Cuộc tấn công mã độc tống tiền WannaCry năm 2017 là trường hợp tham chiếu: đó là lý do phục hồi mạng — cô lập, xây lại từ các bản sao lưu sạch, và xác thực tính toàn vẹn trước khi kết nối lại — nay là một kịch bản hạng nhất trong mọi kế hoạch nghiêm túc.

Tiêu chuẩn liên tục. ISO 22301 là tiêu chuẩn quốc tế cho các hệ thống quản lý liên tục kinh doanh. Nó cung cấp một cấu trúc được công nhận — bối cảnh, lãnh đạo, hoạch định, hỗ trợ, vận hành, đánh giá, cải tiến — để xây dựng và kiểm toán năng lực liên tục, và là một xương sống hữu ích dù bạn có tìm chứng nhận chính thức hay không.

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

1. Bắt đầu từ một phân tích tác động kinh doanh do bác sĩ sở hữu, không chỉ CNTT. Xếp hạng mọi dịch vụ theo tác hại lâm sàng gây ra khi nó thất bại và tác hại trở nên không chịu nổi nhanh đến đâu, rồi gán cho mỗi dịch vụ một RTO và RPO cụ thể. Làm việc này cùng các bác sĩ và quản lý vận hành gánh hậu quả, vì "chúng ta có thể chạy bao lâu mà không có thứ này một cách an toàn?" là câu hỏi chăm sóc, không phải hạ tầng. Đầu ra là một danh sách ưu tiên cho bạn biết nơi chi ngân sách chống chịu hữu hạn trước.

2. Thiết kế khả năng chống chịu tương xứng với mức độ then chốt. Khớp kỹ thuật với tác động: các hệ thống then chốt (khoa cấp cứu, quản lý bệnh nhân, kê đơn điện tử) đáng được tính sẵn sàng cao, dư thừa địa lý và chuyển đổi dự phòng tự động; các hệ thống ít then chốt hơn có thể chấp nhận phục hồi lâu hơn và sao lưu đơn giản hơn. Cưỡng lại cả việc thiết kế thiếu các hệ thống then chốt lẫn mạ vàng các hệ thống tầm thường. Kiến trúc và liên tục phải được thiết kế cùng nhau (xem Chủ đề 4.0 — Kiến trúc kỹ thuật, đám mây và hệ thống cũ), vì bạn không thể gắn khả năng chống chịu lên một thiết kế mong manh sau sự việc.

3. Săn lùng các điểm lỗi đơn và phụ thuộc ẩn. Vẽ bản đồ có hệ thống các phụ thuộc của từng dịch vụ then chốt — mạng, xác thực, DNS, kết nối quốc gia, điện, làm mát, nhà cung cấp then chốt, và người then chốt — và xác định nơi một thất bại lan truyền. Đặc biệt chú ý đến các dịch vụ dùng chung như đăng nhập một lần hay một bộ máy tích hợp chung, mà thất bại của chúng làm nhiều hệ thống ngừng cùng lúc. Một phụ thuộc bạn chưa vẽ bản đồ là phụ thuộc bạn sẽ khám phá trong sự cố ngừng hoạt động.

4. Sao lưu để sống sót qua mã độc tống tiền, và chứng minh khôi phục bằng cách kiểm thử. Theo quy tắc 3-2-1 và giữ ít nhất một bản sao lưu bất biến hoặc ngoại tuyến vật lý, để kẻ tấn công chạm đến mạng của bạn không thể mã hóa tuyến phòng thủ cuối cùng. Rồi kiểm thử khôi phục theo lịch, bấm giờ so với RTO và xác thực tính toàn vẹn dữ liệu so với RPO — một lần khôi phục mất hai ngày so với mục tiêu bốn giờ là một biện pháp kiểm soát thất bại mà bạn chỉ chưa nhận ra. Xem "lần khôi phục đầy đủ thành công cuối cùng" như một chỉ số bạn báo cáo, không phải một nhiệm vụ bạn giả định.

5. Viết, cấp nguồn lực và diễn tập các thủ tục ngừng hoạt động lâm sàng. Với mọi hệ thống lâm sàng then chốt, duy trì một phương án dự phòng giấy (hoặc ngoại tuyến) đã kiểm thử cho phép nhân viên tiếp tục cung cấp chăm sóc an toàn trong sự cố ngừng hoạt động, cộng với một quy trình rõ ràng để nhập lại dữ liệu đó sau đó mà không mất mát hay trùng lặp. Lưu các mẫu ngừng hoạt động ở nơi có thể với tới khi mạng và máy in cũng ngừng. Diễn tập chúng với nhân viên tuyến đầu, vì một thủ tục chỉ nằm trong một tập hồ sơ sẽ không được tìm thấy, hiểu hay tin tưởng lúc 3 giờ sáng trong khủng hoảng.

6. Duy trì một kế hoạch phục hồi sau thảm họa với chuyển đổi dự phòng địa điểm thực sự. Ghi chép, cho từng hệ thống then chốt, chính xác nó phục hồi thế nào: cái gì chạy ở đâu, theo thứ tự nào, ai quyết định kích hoạt nó, và cách chuyển ngược lại sau đó. Nơi tác động biện minh, hãy vận hành một địa điểm hoặc vùng đám mây phục hồi thực sự riêng biệt và chứng minh bạn có thể chuyển sang nó — thứ tự phục hồi quan trọng, vì các hệ thống có phụ thuộc quy định trình tự. Một địa điểm DR chưa kiểm thử là một giả định đắt tiền.

7. Diễn tập kế hoạch; một kế hoạch chưa bao giờ được kiểm thử là một kế hoạch sẽ thất bại. Chạy các cuộc diễn tập đều đặn trên một dải: các buổi đi qua kịch bản trên bàn, kiểm thử chuyển đổi dự phòng kỹ thuật, và thỉnh thoảng các mô phỏng trực tiếp đầy đủ gồm cả phương án dự phòng lâm sàng. Các cuộc diễn tập làm lộ ra những khoảng trống — danh sách liên lạc lỗi thời, bước phục hồi cần một mật khẩu mà không ai có, giả định rằng nhân viên biết quy trình giấy — trong khi còn an toàn để tìm ra chúng. Ghi nhận các bài học, sửa chúng và kiểm thử lại; một cuộc diễn tập không có hành động tiếp theo là sân khấu.

8. Mở rộng liên tục đến các nhà cung cấp và đám mây của bạn. Khả năng chống chịu của bạn chỉ mạnh bằng các bên thứ ba mà các dịch vụ then chốt của bạn phụ thuộc, nên hãy biến liên tục thành vấn đề hợp đồng và đảm bảo: yêu cầu nhà cung cấp chứng minh RTO/RPO, kiểm thử DR và phục hồi mạng của chính họ, và hiểu mô hình trách nhiệm chung của nhà cung cấp đám mây — các vùng sẵn sàng và khu vực bảo vệ khỏi một số thất bại nhưng không khỏi cấu hình sai hay xâm phạm tài khoản mà bạn sở hữu. Lên kế hoạch cho chính sự thất bại của nhà cung cấp, gồm kịch bản khi một nhà cung cấp then chốt là bên bị mã độc tống tiền tấn công (xem Chủ đề 6.3 — Mua sắm và thương mại).

9. Áp dụng một tiêu chuẩn được công nhận và đặt liên tục dưới quản trị. Dùng ISO 22301 làm xương sống có cấu trúc và hướng dẫn của NHS và quốc gia làm lớp phủ đặc thù ngành, và trao trách nhiệm cho một lãnh đạo có tên về liên tục kinh doanh, báo cáo cho hội đồng quản trị. Liên tục mà không ai sở hữu, tài trợ hay rà soát lặng lẽ mục nát cho đến khi sự cố làm lộ ra. Nối nó vào khung đảm bảo của bạn (xem Chủ đề 6.4 — Quản trị và đảm bảo) để các kế hoạch được duy trì, kiểm thử và cải tiến như thường lệ, không phải được khám phá lại trong khủng hoảng.

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

1. Với từng hệ thống lâm sàng then chốt, chúng ta thực sự đã thỏa thuận RTO và RPO nào với bác sĩ — và hiện chúng ta có đáp ứng được không? Câu hỏi này đưa khoảng cách giữa khát vọng và năng lực ra ánh sáng. Nhiều tổ chức chưa bao giờ đặt các mục tiêu phục hồi rõ ràng, hoặc đặt chúng trong CNTT mà không có đóng góp lâm sàng, nên thời gian ngừng "chấp nhận được" thực chất chỉ là bất cứ điều gì kiến trúc hiện tại tình cờ mang lại. Hãy tranh luận nơi nhu cầu lâm sàng (vài phút cho một hệ thống cấp cứu) va chạm với điều sao lưu và DR của bạn thực sự đạt được (có lẽ một ngày), vì khoảng cách đó là rủi ro lâm sàng không được quản lý mà bạn đang mang dù có gọi tên hay không. Hãy xem cụ thể lần phục hồi thực hay đã kiểm thử gần nhất của bạn: nó mất bao lâu, bạn sẽ mất bao nhiêu dữ liệu, và ai đã phê duyệt rằng điều này an toàn? Một câu trả lời tốt, trung thực gọi tên các con số cụ thể cho từng hệ thống, thừa nhận nơi bạn chưa thể đáp ứng, và biến mỗi khoảng cách thành một hành động được tài trợ thay vì một sự im lặng dễ chịu.

2. Nếu mã độc tống tiền mã hóa các hệ thống cốt lõi và cả sao lưu của chúng ta tối nay, làm sao chúng ta giữ bệnh nhân an toàn vào ngày mai — và bao lâu cho đến khi chúng ta phục hồi hoàn toàn? Đây là kịch bản đã đánh vào các hệ thống y tế thực, nên nó xứng đáng một cuộc đi qua cụ thể, không né tránh thay vì sự trấn an. Hãy khám phá cả hai nửa một cách trung thực: sự liên tục lâm sàng tức thì (các thủ tục ngừng hoạt động có được diễn tập, cấp nguồn lực và đủ tin để chạy cả một bệnh viện trên giấy trong nhiều ngày không?) và sự phục hồi kỹ thuật (các bản sao lưu có bất biến và ngoại tuyến không, bạn đã kiểm thử việc xây lại từ các bản sao sạch chưa, và bạn có biết thứ tự phục hồi không?). Làm lộ các phụ thuộc khó chịu — nếu đăng nhập một lần, bộ máy tích hợp hay một nhà cung cấp then chốt ngừng, bao nhiêu thứ khác rơi cùng? Hãy cân nhắc ai tuyên bố sự cố lớn, ai nói chuyện với nhân viên, bệnh nhân và truyền thông, và ai quyết định một hệ thống an toàn để kết nối lại. Một câu trả lời mạnh mô tả một kế hoạch được diễn tập với các vai trò có tên và khôi phục đã kiểm thử; một câu trả lời yếu giả định các bản sao lưu ổn và quy trình giấy sẽ tự hoạt động.

3. Lần gần nhất chúng ta kiểm thử các kế hoạch liên tục và phục hồi sau thảm họa từ đầu đến cuối là khi nào, và chúng ta đã học được gì? Mục đích ở đây là phân biệt một năng lực sống với một tài liệu trên giá. Một kế hoạch chưa được diễn tập là chưa kiểm thử, và các kế hoạch chưa kiểm thử thường xuyên thất bại khi chạm thực tế — danh sách liên lạc lỗi thời, bước phục hồi cần thông tin xác thực mà không ai có, các mẫu ngừng hoạt động được lưu trên chính hệ thống đang ngừng. Hãy thảo luận dải diễn tập bạn thực sự làm: kịch bản trên bàn, kiểm thử chuyển đổi dự phòng kỹ thuật, và các mô phỏng đầy đủ gồm cả phương án dự phòng lâm sàng tuyến đầu, không chỉ khôi phục máy chủ. Thăm dò liệu bài học từ các sự cố và cuộc diễn tập trước có thực sự được sửa và kiểm thử lại, hay được ghi nhận rồi quên. Một câu trả lời tốt cho thấy một lịch diễn tập đều đặn, bằng chứng các khoảng trống được tìm ra và đóng, và sự trung thực về những phần nào của kế hoạch vẫn chưa được chứng minh.

4. Những phụ thuộc then chốt nào chúng ta không kiểm soát — và kế hoạch của chúng ta cho ngày một trong số chúng thất bại là gì? CNTT y tế hiện đại hiếm khi thất bại một mình; nó thất bại qua các dịch vụ và nhà cung cấp bên dưới. Hãy đẩy nhóm vượt qua các hệ thống bạn sở hữu đến những hệ thống bạn chỉ dựa vào: kết nối trục xương sống quốc gia, nhà cung cấp đăng nhập một lần, vùng đám mây, bộ máy tích hợp, trung tâm dữ liệu thuê ngoài, đối tác dịch vụ được quản lý nắm chìa khóa phục hồi. Với mỗi cái, hỏi điều gì xảy ra với chăm sóc nếu nó biến mất một ngày, hợp đồng có buộc bên thứ ba vào một mục tiêu phục hồi khớp với nhu cầu lâm sàng của bạn không, và bạn đã từng thấy bằng chứng về việc kiểm thử DR của họ thay vì một đoạn văn trấn an trong một hồ sơ dự thầu không. Sự thật khó chịu là bạn có thể mang rủi ro còn lại mà bạn chưa bao giờ định giá, vì thất bại nằm trong hệ thống của người khác. Một câu trả lời trung thực gọi tên các phụ thuộc bên ngoài cụ thể của từng dịch vụ then chốt, nêu cái nào được bảo đảm bằng hợp đồng và cái nào chỉ được tin, và xác định một phương án dự phòng — dù thủ công — cho các phụ thuộc bạn không thể làm cho chống chịu.

5. Khi một sự cố lớn xảy ra, ai quyết định gì, ai truyền thông cho ai, và mọi người có biết vai trò của mình trước ngày đó không? Liên tục kinh doanh là về chỉ huy và truyền thông nhiều như về sao lưu, và đây là nơi các kế hoạch được diễn tập và sự hỗn loạn ứng biến phân kỳ. Hãy đi qua vũ đạo con người: ai có thẩm quyền tuyên bố một sự cố lớn và kích hoạt kế hoạch, ai điều hành phản ứng vận hành, ai quyết định một hệ thống an toàn để kết nối lại, và ai nói chuyện với nhân viên, bệnh nhân, báo chí, cơ quan quản lý, và — trong một cuộc tấn công mạng — cơ quan thực thi pháp luật. Hãy cân nhắc sự thất bại của chính các công cụ của bạn trong sự cố, vì sự ngừng hoạt động có thể làm sập email, danh bạ điện thoại hay mạng nội bộ mà bạn thường dùng để phối hợp. Làm lộ căng thẳng giữa đi nhanh và đi an toàn, và rủi ro danh tiếng của việc đưa ra sai thông điệp công khai. Một câu trả lời mạnh chỉ ra một cấu trúc chỉ huy sự cố được kiểm thử với các vai trò có tên, có người dự phòng, các kênh liên lạc ngoài băng tần và các mẫu thông điệp thỏa thuận trước; một câu trả lời yếu giả định đúng người sẽ tập hợp và biết phải làm gì.

6. Làm sao chúng ta tài trợ, sở hữu và giữ cho liên tục sống khi không có gì sai trong hai năm? Khả năng chống chịu phân rã lặng lẽ trong khoảng giữa các sự cố, và câu hỏi này đối diện với kỷ luật tổ chức giữ cho nó khỏi mục nát. Liên tục cạnh tranh về tiền và sự chú ý với các ưu tiên lâm sàng và số hữu hình, khẩn cấp, và tổ chức non trẻ-và-may mắn trông giống hệt tổ chức trưởng thành cho đến ngày nó không còn như vậy. Hãy tranh luận ai thực sự sở hữu liên tục ở cấp điều hành, nó có một dòng được tài trợ thay vì thiện chí vay mượn không, và các kế hoạch, bản đồ phụ thuộc và danh sách liên lạc được giữ cập nhật thế nào khi hệ thống và nhân sự thay đổi. Hỏi hội đồng thực sự thấy gì — sự đảm bảo đã kiểm thử và các khoảng trống trung thực, hay một xếp hạng xanh và một tài liệu đã lưu. Một câu trả lời tốt mô tả trách nhiệm giải trình có tên, một ngân sách định kỳ và lịch diễn tập, và một nhịp quản trị xem liên tục được duy trì, kiểm thử là thường lệ thay vì được khám phá lại trong cuộc khủng hoảng tiếp theo.

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

Quỹ NHS Meadowvale vận hành một bệnh viện cấp cứu 600 giường. Vào một sáng thứ Ba, nhân viên đến và thấy hồ sơ bệnh nhân điện tử (EPR), bệnh học và chẩn đoán hình ảnh bị khóa bởi một thư đòi tiền chuộc; kẻ tấn công đã vào qua một tài khoản truy cập từ xa của nhà cung cấp mười ngày trước đó. Giám đốc thông tin tuyên bố một sự cố lớn trong vòng một giờ, và kế hoạch liên tục kinh doanh của quỹ được kích hoạt.

Vì quỹ đã thực hiện phân tích tác động kinh doanh của mình, nó biết EPR và bệnh học là các hệ thống then chốt nhất, với các mục tiêu phục hồi đã thỏa thuận, trong khi các thủ tục ngừng hoạt động đã được diễn tập vào mùa thu trước. Các khoa chuyển sang biểu đồ thuốc giấy và biểu mẫu quan sát in sẵn — được cố ý lưu trong tủ vật lý ở mỗi khoa, không phải trên một ổ dùng chung — và khoa cấp cứu quay về lộ trình giấy của nó. Các ca mổ có kế hoạch trong tuần bị hoãn và thông báo cho bệnh nhân; xe cứu thương bị chuyển hướng khỏi những khoảng thời gian bận rộn nhất. Việc chăm sóc tiếp tục, suy giảm nhưng an toàn, vì nhân viên đã luyện tập làm việc theo cách này.

Phục hồi khó hơn khôi phục. Nhóm bảo mật cô lập mạng để ngăn lây lan, rồi xây lại các hệ thống then chốt từ các bản sao lưu bất biến giữ ngoại tuyến — những bản sao mà kẻ tấn công không thể chạm tới. Các bản sao lưu đó đã được kiểm thử khôi phục hằng quý, nên nhóm biết quy trình hoạt động và mất khoảng bao lâu; EPR quay lại trong RTO tám giờ, dù bệnh học, với các phụ thuộc phức tạp hơn, mất hai ngày. RPO mười lăm phút nghĩa là chỉ mất một khoảng dữ liệu ngắn, và nhân viên đối chiếu hồ sơ giấy trở lại hệ thống theo một quy trình nhập lại được kiểm soát, kiểm tra kỹ thuốc và kết quả.

Trong buổi tổng kết, quỹ tìm thấy các khoảng trống thực: đăng nhập một lần là một điểm lỗi đơn làm chậm truy cập của bác sĩ trong lúc phục hồi, và truy cập từ xa của nhà cung cấp chưa được bao phủ bởi sự đảm bảo liên tục của chính quỹ. Cả hai đi vào sổ đăng ký rủi ro của hội đồng với người sở hữu và ngày tháng, và cuộc diễn tập đầy đủ tiếp theo được lên lịch. Đó là một tuần tồi tệ — nhưng không phải thảm họa, vì kế hoạch tồn tại, được cấp nguồn lực và đã được kiểm thử.

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

Công ty khởi nghiệp#

Một công ty khởi nghiệp y tế số hiếm khi có trung tâm dữ liệu dư, nên chiến lược liên tục của nó dựa gần như hoàn toàn vào khả năng chống chịu gốc-đám-mây và sao lưu có kỷ luật. Hãy dùng các dịch vụ được quản lý với tính sẵn sàng cao tích hợp qua các vùng sẵn sàng, tự động hóa sao lưu với các bản sao bất biến, ngoài tài khoản để sống sót qua cả mã độc tống tiền lẫn một tài khoản đám mây bị xâm phạm, và thực sự diễn tập một lần khôi phục vào một môi trường sạch. Khách hàng của bạn — các bệnh viện NHS và hệ thống chăm sóc tích hợp — sẽ ngày càng đòi hỏi bằng chứng về RTO, RPO và kiểm thử DR qua các khung như DTAC và đảm bảo nhà cung cấp, vì vậy hãy xem liên tục là tài sản bán hàng, không phải chi phí chung. Rủi ro sống còn với một nhà cung cấp nhỏ là một sự cố duy nhất, hoặc nhà sáng lập duy nhất hiểu việc triển khai, trở thành điểm lỗi đơn của bạn.

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 cơ sở chăm sóc tại nhà hay một phòng khám đơn lẻ — mang cùng nghĩa vụ giữ bệnh nhân an toàn qua một sự cố ngừng hoạt động như một bệnh viện lớn, nhưng với bệnh nhân thật, tiền mặt eo hẹp, và thường không có nhân viên CNTT chuyên trách. Liên tục ở đây cố ý thực dụng: biết một hay hai hệ thống nào (hồ sơ lâm sàng, hệ thống phát thuốc hay eMAR) sẽ dừng việc chăm sóc an toàn nếu chúng thất bại, khăng khăng nhà cung cấp hệ thống của bạn chứng minh sao lưu, RTO và RPO của chính họ, và giữ một gói ngừng hoạt động in đơn giản — biểu đồ thuốc giấy, số điện thoại chính, danh sách bệnh nhân gần đây — ở nơi nhân viên với tới được khi màn hình tối. Vì một người quản lý phòng khám duy nhất hay một nhà thầu CNTT đơn độc thường là người duy nhất hiểu cách thiết lập, hãy viết các bước phục hồi ra và bảo đảm một người thứ hai có thể làm theo. Mã độc tống tiền và một đường băng thông rộng hỏng là các mối đe dọa hằng ngày, nên một bản sao lưu ngoại tuyến hoặc bất biến và một cách làm việc dự phòng quan trọng hơn bất kỳ địa điểm DR phức tạp nào bạn không đủ khả năng chi hay vận hành.

Doanh nghiệp lớn#

Một bệnh viện NHS lớn, một hệ thống chăm sóc tích hợp, hoặc một nhà cung cấp công nghệ y tế lớn mang một hệ thống trải rộng, phụ thuộc lẫn nhau nơi vấn đề khó nhất là vẽ bản đồ phụ thuộc và dịch vụ dùng chung, không phải bất kỳ hệ thống đơn lẻ nào. Hãy đầu tư vào một chương trình BCM chính thức phù hợp ISO 22301, một bản đồ phụ thuộc được duy trì, các địa điểm hoặc vùng DR cho hệ thống then chốt, và một lịch diễn tập luân phiên gồm cả phương án dự phòng lâm sàng. Quy mô nghĩa là các SPOF thường là dịch vụ dùng chung — danh tính, bộ máy tích hợp, lõi mạng — mà thất bại của chúng lan khắp hàng chục hệ thống. Quản trị là ràng buộc ràng buộc: với nhiều nhóm và nhà cung cấp, liên tục chỉ đứng vững nếu một lãnh đạo có tên sở hữu nó và hội đồng rà soát sự đảm bảo đã kiểm thử, không phải kế hoạch giấy.

Chính phủ#

Một cơ quan quốc gia — NHS England, một bộ y tế được phân quyền, hay UKHSA — phải nghĩ về khả năng chống chịu ở quy mô dân số và hệ thống, nơi thất bại của một dịch vụ quốc gia hoặc một nhà cung cấp được dùng rộng rãi tự nó là một sự kiện liên tục cho cả ngành. Hãy đặt các chuẩn và kỳ vọng (mục tiêu phục hồi, phục hồi mạng, diễn tập bắt buộc), tài trợ các năng lực bảo vệ dùng chung, và phối hợp phản ứng toàn ngành với các sự cố lớn như một chiến dịch mã độc tống tiền quốc gia. Phản ứng với WannaCry đã định hình lại chính sách quốc gia chính vì tác động vượt qua hàng trăm tổ chức cùng lúc, làm lộ các điểm yếu chung. Trách nhiệm giải trình ở đây mang tính công khai và Nghị viện, nên sự minh bạch về các rủi ro đã biết, và báo cáo trung thực về mức sẵn sàng, quan trọng không kém các biện pháp kiểm soát kỹ thuật.

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

• Sao lưu chưa bao giờ được khôi phục. Nhầm "chúng tôi sao lưu hằng đêm" với "chúng tôi có thể phục hồi". Các lần khôi phục chưa kiểm thử thường xuyên thất bại hoặc vượt RTO; hãy đo và báo cáo các lần khôi phục đầu cuối thành công, không phải việc hoàn tất sao lưu.
• Sao lưu mã độc tống tiền với tới được. Giữ mọi bản sao lưu trực tuyến và kết nối mạng, để kẻ tấn công mã hóa chúng cùng với sản phẩm. Hãy giữ ít nhất một bản sao bất biến hoặc ngoại tuyến.
• DR bảo vệ máy chủ, không phải dịch vụ. Khôi phục một cơ sở dữ liệu nhưng không khôi phục các phụ thuộc, tích hợp và truy cập làm nó thành một dịch vụ lâm sàng dùng được. Phục hồi và kiểm thử cả dịch vụ, theo thứ tự phụ thuộc.
• Thủ tục ngừng hoạt động chỉ tồn tại trên giấy nói về giấy. Các phương án dự phòng không bao giờ được diễn tập, được lưu trên hệ thống bị hỏng, hoặc nhân viên tuyến đầu không biết. Hãy diễn tập chúng ở nơi chăm sóc thực sự diễn ra.
• Phụ thuộc không được vẽ bản đồ và SPOF dùng chung. Phát hiện trong sự cố ngừng hoạt động rằng đăng nhập một lần, DNS, hoặc một nhà cung cấp làm nền cho mọi thứ. Hãy vẽ bản đồ phụ thuộc trước, không phải trong, sự cố.
• Một kế hoạch viết cho kiểm toán viên, không bao giờ được diễn tập. Liên tục như một tài liệu tuân thủ phân rã chưa kiểm thử cho đến ngày cần đến. Một kế hoạch chưa bao giờ được kiểm thử là một kế hoạch sẽ thất bại.
• Bỏ qua liên tục của nhà cung cấp và đám mây. Giả định các bên thứ ba của bạn chống chịu mà không có bằng chứng, và quên mô hình trách nhiệm chung. Hãy biến liên tục thành hợp đồng và được đảm bảo.

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

Danh sách kiểm tra#

• Một phân tích tác động kinh doanh, được sở hữu cùng bác sĩ, xếp hạng mọi dịch vụ và đặt một RTO và RPO rõ ràng cho từng hệ thống then chốt.
• Các hệ thống then chốt có tính sẵn sàng cao và dư thừa tương xứng với mức độ then chốt lâm sàng của chúng.
• Các điểm lỗi đơn và phụ thuộc then chốt (gồm dịch vụ dùng chung và nhà cung cấp) được vẽ bản đồ và giảm thiểu.
• Sao lưu theo quy tắc 3-2-1 với ít nhất một bản sao bất biến hoặc ngoại tuyến mà mã độc tống tiền không với tới được.
• Khôi phục được kiểm thử theo lịch và bấm giờ so với RTO/RPO, với "lần khôi phục thành công cuối cùng" được báo cáo như một chỉ số.
• Mọi hệ thống lâm sàng then chốt có một thủ tục ngừng hoạt động được diễn tập và một quy trình nhập lại dữ liệu được kiểm soát.
• Một kế hoạch phục hồi sau thảm họa xác định các bước phục hồi, thứ tự, thẩm quyền quyết định và chuyển ngược, và địa điểm/vùng DR được kiểm thử.
• Một kịch bản phục hồi mạng (cô lập, xây lại từ bản sao lưu sạch, xác thực, kết nối lại) được ghi chép và diễn tập.
• Liên tục của nhà cung cấp và đám mây được yêu cầu bằng hợp đồng, được chứng minh và đảm bảo, gồm mô hình trách nhiệm chung.
• Liên tục phù hợp ISO 22301, được một lãnh đạo có tên sở hữu, diễn tập theo lịch và báo cáo cho hội đồng quản trị.

Nguồn chính#

• NHS England — Business Continuity Management Toolkit và Khung Sẵn sàng, Chống chịu và Ứng phó Khẩn cấp (EPRR) cùng các Chuẩn Cốt lõi.
• Trung tâm An ninh Mạng Quốc gia (NCSC) — hướng dẫn về sao lưu ngoại tuyến/bất biến, giảm thiểu mã độc tống tiền và ứng phó sự cố.
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (Tổ chức Tiêu chuẩn hóa Quốc tế).
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity.
• Business Continuity Institute (BCI) — Good Practice Guidelines.
• Văn phòng Kiểm toán Quốc gia — Investigation: WannaCry cyber attack and the NHS (2017) và cuộc rà soát bài học kinh nghiệm của Bộ Y tế.
• NHS England / Bộ công cụ Bảo mật và Bảo vệ Dữ liệu (DSPT) — các chuẩn an ninh dữ liệu gồm liên tục kinh doanh và ứng phó sự cố.
• Sổ tay Dịch vụ GOV.UK — hướng dẫn về khả năng chống chịu, giám sát và phục hồi cho các dịch vụ đang vận hành.

Tài liệu tham khảo#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/