Chủ đề 3.6 — DevOps và xuất sắc kỹ thuật

Tóm lại trong một câu: Trong các hệ thống lâm sàng, kỹ thuật có kỷ luật — đường ống tự động, bản phát hành nhỏ có thể đảo ngược, hạ tầng dưới dạng mã và khả năng quan sát — là điều làm cho thay đổi an toàn hơn, không phải rủi ro hơn, và xem "cách chúng ta xây dựng và vận hành phần mềm" như một mối quan tâm về an toàn, công bằng và niềm tin công chúng là dấu hiệu của một tổ chức y tế số trưởng thành.

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

Cách bạn thiết kế kỹ thuật và vận hành phần mềm tự nó là một biện pháp kiểm soát an toàn lâm sàng. Khi một điều dưỡng khu vực không thấy được thay đổi thuốc, khi một chuyển tuyến điện tử lặng lẽ thất bại, hay khi một sự cố ngừng hoạt động khóa bác sĩ khỏi hồ sơ chăm sóc dùng chung, tác hại không phải bất tiện trừu tượng — đó là điều trị bị chậm, một dị ứng bị bỏ sót, một khoảng trống bảo vệ người dễ bị tổn thương. Các thực hành kỹ thuật trong chủ đề này quyết định một bản sửa cần thiết đến sản phẩm trong mười phút hay mười tuần, và một thay đổi xấu có thể được đảo ngược sạch sẽ hay để bác sĩ xoay xở quanh một hệ thống hỏng trong nhiều ngày.

Có một huyền thoại dai dẳng và nguy hiểm trong các lĩnh vực được quản lý rằng thay đổi là rủi ro, nên hệ thống an toàn nhất là hệ thống bạn chạm vào ít nhất. Bằng chứng chỉ theo hướng ngược lại. Các hệ thống hiếm khi thay đổi tích lũy các lỗ hổng chưa vá, các bước triển khai thủ công dễ vỡ và kiến thức bộ lạc không được ghi chép; khi thay đổi cuối cùng không thể tránh — một bản vá bảo mật, một hạn chót quy định, một nhà cung cấp rút lui — nó đến như một "vụ nổ lớn" quy mô lớn, rủi ro, hiểu kém. Các tổ chức triển khai các thay đổi nhỏ thường xuyên, với tự động hóa và quay lui nhanh, gặp ít thất bại hơn và phục hồi nhanh hơn. Trong y tế và chăm sóc, khác biệt đó được đo bằng an toàn bệnh nhân.

Xuất sắc kỹ thuật cũng là vấn đề công bằng và niềm tin công chúng. Phần mềm không quan sát được che giấu thực tế rằng một dịch vụ hoạt động kém hơn với người dùng trên thiết bị cũ hoặc ở các khu vực kết nối kém. Một chuỗi cung ứng phần mềm không an toàn đặt thông tin bệnh nhân bí mật vào rủi ro (xem Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng). Và vì đây là tiền công và dữ liệu công, ngành ngày càng kỳ vọng mã được xây theo các chuẩn mở, có thể kiểm tra — đôi khi theo nghĩa đen là công khai. Cách bạn làm việc do đó không phải chuyện kỹ thuật riêng tư; nó chịu trách nhiệm trước bệnh nhân, bác sĩ và công chúng.

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

DevOps. DevOps là một văn hóa và tập hợp các thực hành phá bỏ bức tường truyền thống giữa các lập trình viên xây dựng phần mềm và nhân viên vận hành chạy nó. Thay vì "ném mã qua tường" cho một nhóm riêng, cùng những người đó chia sẻ quyền sở hữu một dịch vụ từ thiết kế đến vận hành trực tiếp, được hỗ trợ bởi tự động hóa và phản hồi nhanh. Về cơ bản nó là một cách làm việc — trách nhiệm chung, học hỏi không đổ lỗi, các lô nhỏ — được tạo điều kiện bởi công cụ, không phải một công cụ bạn mua.

Tích hợp liên tục và giao hàng liên tục (CI/CD). Tích hợp liên tục (CI) nghĩa là mỗi lập trình viên thường xuyên gộp các thay đổi nhỏ vào một nhánh chính dùng chung, mỗi lần kích hoạt một lần xây dựng và chạy kiểm thử tự động để các vấn đề lộ ra trong vài phút. Giao hàng liên tục (CD) mở rộng điều này để phần mềm luôn ở trạng thái có thể phát hành và có thể được triển khai lên sản phẩm qua một đường ống tự động, lặp lại được. Triển khai liên tục đi thêm một bước, tự động phát hành mọi thay đổi vượt qua đường ống. Kiểm thử là bản chất của các cổng đường ống — được đề cập sâu ở Chủ đề 3.7 — Kiểm thử và đảm bảo chất lượng.

Phát triển dựa trên thân cây và các bản phát hành nhỏ, có thể đảo ngược. Phát triển dựa trên thân cây (trunk-based development) giữ mọi người làm việc gần một dòng chính duy nhất trong kiểm soát phiên bản, tích hợp nhiều lần mỗi ngày thay vì chăm sóc những nhánh sống lâu trôi xa nhau và gộp đau đớn. Kỷ luật đi kèm là giao các thay đổi nhỏ, thường xuyên, có thể đảo ngược độc lập. Một thay đổi nhỏ dễ rà soát, dễ kiểm thử, và — quan trọng trong một hệ thống lâm sàng — dễ quay lui sạch sẽ nếu có điều gì sai.

Hạ tầng dưới dạng mã (IaC). Thay vì cấu hình máy chủ bằng tay, bạn định nghĩa hạ tầng trong các tệp máy đọc được giữ dưới kiểm soát phiên bản. Môi trường trở nên có thể tái lập, rà soát và kiểm toán: bạn có thể xây lại nó giống hệt, thấy ai thay đổi gì và vì sao, và chứng minh môi trường kiểm thử và sản phẩm khớp nhau. Đây là nền tảng cho các môi trường đáng tin (xem Chủ đề 4.0 — Kiến trúc kỹ thuật, đám mây và hệ thống cũ).

Kỹ thuật nền tảng và trải nghiệm lập trình viên. Kỹ thuật nền tảng xem các công cụ nội bộ, đường ống và môi trường mà các nhóm triển khai phụ thuộc vào là một sản phẩm, với các nhóm là người dùng của nó. Một nền tảng nội bộ được xây tốt trao cho các nhóm một "con đường lát sẵn" — mặc định an toàn, mô thức được duyệt trước, triển khai một cú nhấp — để họ có thể đi nhanh và an toàn mà không phải mỗi nhóm tự phát minh lại việc tuân thủ. Trải nghiệm lập trình viên tốt không phải sự nuông chiều; đó là cách bạn biến con đường an toàn thành con đường dễ.

Các chỉ số DORA. DevOps Research and Assessment (DORA) xác định bốn thước đo phân biệt các nhóm hiệu suất cao: tần suất triển khai (bạn phát hành bao lâu một lần), thời gian dẫn cho thay đổi (từ commit đến sản phẩm mất bao lâu), tỷ lệ thất bại thay đổi (bao nhiêu phần trăm thay đổi gây ra vấn đề), và thời gian khôi phục dịch vụ (bạn phục hồi nhanh thế nào). Cùng nhau chúng cho thấy tốc độ và sự ổn định cùng tăng — các nhóm triển khai thường xuyên nhất cũng thất bại ít nhất và phục hồi nhanh nhất.

"Bạn xây, bạn vận hành", SRE và khả năng quan sát. Được Amazon phổ biến, "bạn xây, bạn vận hành" nghĩa là nhóm viết một dịch vụ cũng vận hành nó, mang máy nhắn tin, và cảm nhận các thất bại của nó — khép vòng phản hồi giữa các lựa chọn kỹ thuật và thực tế vận hành (xem Chủ đề 3.8 — Quản lý dịch vụ và vận hành trực tiếp). Kỹ thuật độ tin cậy trang web (SRE) là một cách triển khai cụ thể áp dụng kỹ thuật vào vận hành, với các mục tiêu độ tin cậy rõ ràng và ngân sách lỗi. Khả năng quan sát — khả năng hiểu trạng thái nội tại của một hệ thống từ đầu ra của nó (số đo, nhật ký, dấu vết) — là điều cho phép bạn phát hiện và chẩn đoán vấn đề trước bệnh nhân và bác sĩ.

Chuỗi cung ứng phần mềm an toàn. Phần mềm hiện đại được lắp ráp từ nhiều thành phần và phụ thuộc bên thứ ba. Một tấn công chuỗi cung ứng khai thác một thành phần đáng tin để làm tổn hại mọi thứ phụ thuộc vào nó. Quản lý phụ thuộc, quét tìm lỗ hổng đã biết và duy trì một bảng kê vật liệu phần mềm là vệ sinh kỹ thuật cốt lõi, không phải phần bổ sung bảo mật tùy chọn.

Lập trình công khai và phần mềm mã nguồn mở. Chính sách chính phủ Vương quốc Anh — được thể hiện trong Tiêu chuẩn Dịch vụ GDS và Tiêu chuẩn Dịch vụ NHS — yêu cầu các nhóm mở mã nguồn mới theo mặc định và dùng chuẩn mở. Với phần mềm y tế do công quỹ tài trợ, điều này cải thiện sự soi xét, tái sử dụng và niềm tin, miễn là dữ liệu bệnh nhân và bí mật thực sự được giữ nghiêm ngặt ngoài các kho công khai.

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

1. Xây một đường ống CI/CD trước khi xây dịch vụ. Thiết lập xây dựng, kiểm thử và triển khai tự động từ tuần đầu tiên, để mọi thay đổi chảy qua cùng một con đường lặp lại được, có thể kiểm toán đến sản phẩm. Đường ống là nơi các cổng an toàn lâm sàng, bảo mật và khả năng tiếp cận của bạn nằm dưới dạng các kiểm tra tự động, cho bạn một hồ sơ được ghi chép, chống can thiệp về chính xác thứ gì đã được triển khai và khi nào. Trong một hệ thống được quản lý, dấu vết kiểm toán này không phải chi phí chung — nó là bằng chứng cho hồ sơ an toàn lâm sàng của bạn (xem Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro).

2. Triển khai các thay đổi nhỏ, thường xuyên, có thể đảo ngược. Ưu tiên nhiều bản phát hành nhỏ hơn thỉnh thoảng một bản lớn, và thiết kế mọi thay đổi để nó có thể được quay lui hoặc tắt nhanh chóng. Một thay đổi nhỏ thất bại dễ hiểu và đảo ngược; một bản phát hành khổng lồ hằng quý thất bại là một sự cố lâm sàng có cả trăm nghi phạm. Các kỹ thuật như cờ tính năng, phát hành canary và triển khai xanh-lục cho phép bạn phơi bày thay đổi dần dần và rút nó lại tức thì — biến triển khai từ một sự kiện đáng sợ thành một hành động thường lệ, ít kịch tính.

3. Biến quay lui nhanh, sạch thành một biện pháp kiểm soát an toàn hạng nhất. Diễn tập quay lui như bạn diễn tập diễn tập chữa cháy, và đo xem nó thực sự mất bao lâu. Trong một hệ thống lâm sàng, năng lực vận hành giá trị nhất là khả năng trở về trạng thái tốt đã biết trong vài phút khi một thay đổi gây hại. Quay lui chưa bao giờ được kiểm thử là hy vọng, không phải biện pháp kiểm soát; hãy chứng minh nó hoạt động và tiếp tục chứng minh.

4. Xem hạ tầng và cấu hình là mã. Định nghĩa môi trường, mạng và cấu hình một cách khai báo, dưới kiểm soát phiên bản, và cấp phát chúng tự động. Điều này cho bạn các môi trường tái lập được, các thay đổi được đồng nghiệp rà soát, và khả năng xây lại sau một thất bại hay thảm họa (xem Chủ đề 3.9 — Liên tục kinh doanh và phục hồi sau thảm họa). Các máy chủ "bông tuyết" chỉnh tay thủ công không lặp lại được, không được ghi chép, và là nguyên nhân thường gặp của "chạy được trong kiểm thử nhưng không chạy trong sản phẩm".

5. Dùng các chỉ số DORA để có những cuộc trò chuyện trung thực, không phải để xếp hạng con người. Theo dõi tần suất triển khai, thời gian dẫn, tỷ lệ thất bại thay đổi và thời gian khôi phục như một tín hiệu sức khỏe cấp hệ thống, và quan sát chúng cùng dịch chuyển về phía nhanh-hơn-và-an-toàn-hơn. Cưỡng lại việc biến chúng thành bảng xếp hạng cá nhân hay nhóm — chính các tác giả của DORA cảnh báo điều này, vì nó thúc đẩy gian lận và rủi ro bị che giấu. Cách dùng đúng là chẩn đoán: tỷ lệ thất bại thay đổi tăng đang nói với bạn điều gì đó về độ bao phủ kiểm thử hay cỡ lô mà một hội đồng nên muốn nghe.

6. Áp dụng "bạn xây, bạn vận hành", được hậu thuẫn bởi khả năng quan sát. Trao cho các nhóm triển khai quyền sở hữu thực sự các dịch vụ của họ trong sản phẩm, gồm trách nhiệm trực, để những người đưa ra các lựa chọn thiết kế sống với hậu quả vận hành. Hậu thuẫn điều này bằng khả năng quan sát — số đo, nhật ký có cấu trúc và dấu vết, cộng với cảnh báo có ý nghĩa gắn với tác động đến người dùng — để các nhóm tìm ra vấn đề trước khi bác sĩ báo cáo. Điều này khép vòng phản hồi làm cho các lựa chọn kỹ thuật tốt hơn theo thời gian và nối trực tiếp với quản lý dịch vụ (Chủ đề 3.8).

7. Bảo mật chuỗi cung ứng phần mềm liên tục. Duy trì một bản kiểm kê các phụ thuộc, quét tự động tìm lỗ hổng đã biết, ghim và xác minh phiên bản, và giữ một bảng kê vật liệu phần mềm để bạn có thể trả lời "chúng ta có bị ảnh hưởng không?" trong vài giờ sau lỗ hổng được công bố rộng rãi tiếp theo. Hạn chế ai và cái gì có thể đẩy lên sản phẩm, và bảo vệ bí mật cùng thông tin xác thực nghiêm ngặt (xem Chủ đề 4.2 — Quản lý danh tính và truy cập). Trong y tế và chăm sóc, một phụ thuộc bị xâm phạm là con đường đến dữ liệu bệnh nhân bí mật, nên vệ sinh chuỗi cung ứng là công việc an toàn bệnh nhân và quản trị thông tin.

8. Đặt ra và thực thi các chuẩn kỹ thuật, và quản lý nợ kỹ thuật một cách có chủ đích. Thống nhất chuẩn lập trình, linting tự động, rà soát mã và một "định nghĩa hoàn thành" rõ ràng, để chất lượng được xây vào thay vì kiểm tra vào sau. Theo dõi nợ kỹ thuật một cách rõ ràng và trả nó như công việc có kế hoạch, vì nợ không được quản lý trong một hệ thống lâm sàng lặng lẽ nâng chi phí và rủi ro của mọi thay đổi tương lai. Các chuẩn làm cho mã dễ đọc với kỹ sư kế tiếp — và với kiểm toán viên, cán bộ an toàn và người rà soát mã nguồn mở có thể cần đọc nó.

9. Lập trình công khai nơi bạn có thể một cách an toàn. Theo kỳ vọng của GDS và NHS mở mã nguồn mới theo mặc định và tái sử dụng chuẩn mở, giữ dữ liệu bệnh nhân và bí mật nghiêm ngặt ngoài các kho công khai thông qua quản lý bí mật có kỷ luật. Mã mở mời gọi sự soi xét cải thiện chất lượng và bảo mật, cho phép tái sử dụng trong một hệ thống thiếu tiền, và xây dựng niềm tin công chúng rằng phần mềm tiêu tiền công đang làm điều nó tuyên bố. Nơi mã thực sự không thể mở (ví dụ một số thành phần nhạy cảm về bảo mật), hãy ghi lại lý do thay vì mặc định đóng do thói quen.

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

1. Chúng ta có thực sự tin rằng thay đổi các hệ thống lâm sàng thường xuyên hơn làm chúng an toàn hơn không — và hành vi của chúng ta có khớp với niềm tin đó không? Câu hỏi này buộc một nhóm đối diện với khoảng cách giữa bằng chứng và bản năng. Nghiên cứu DORA nói rõ rằng các nhóm triển khai các thay đổi nhỏ thường xuyên có tỷ lệ thất bại thấp hơn và phục hồi nhanh hơn, thế nhưng nhiều tổ chức y tế vẫn gom các thay đổi thành các bản phát hành hiếm hoi, bị đóng cổng nặng nề nhân danh an toàn, vô tình khiến mỗi bản lớn hơn và rủi ro hơn. Hãy tranh luận các quy trình tư vấn thay đổi của bạn thực sự giảm rủi ro ở đâu so với nơi chúng chỉ thêm độ trễ đẩy các nhóm về phía các bản phát hành "một vụ nổ lớn". Hãy nhìn thẳng vào vài sự cố gần nhất: chúng do các thay đổi nhỏ thường xuyên gây ra, hay do các thay đổi lớn hiếm hoi và sự bỏ bê chưa vá? Hãy cân nhắc liệu khả năng quay lui của bạn có thật và được diễn tập không, vì lập luận cho thay đổi thường xuyên hoàn toàn dựa vào khả năng đảo ngược nó nhanh. Một câu trả lời tốt không mang tính ý thức hệ; nó gọi tên các biện pháp kiểm soát cụ thể — kiểm thử tự động, phát hành canary, quay lui đã kiểm thử — sẽ cho phép bạn tăng tần suất thay đổi và đồng thời thỏa mãn các nghĩa vụ an toàn lâm sàng và đảm bảo của bạn.

2. Ai vận hành các dịch vụ của chúng ta trong sản phẩm lúc 2 giờ sáng, và điều đó nói gì về các lựa chọn kỹ thuật của chúng ta? "Bạn xây, bạn vận hành" dễ tán thành và khó sống theo. Câu hỏi này làm lộ ra liệu những người đưa ra quyết định kiến trúc và triển khai có thực sự cảm nhận hậu quả vận hành hay không, hay nỗi đau bị đẩy sang một nhóm vận hành hoặc bàn dịch vụ riêng không thể sửa nguyên nhân gốc. Hãy khám phá trạng thái khả năng quan sát của bạn: khi một hồ sơ chăm sóc dùng chung chậm đi, bạn biết từ bảng điều khiển và cảnh báo hay từ một bác sĩ giận dữ? Hãy thảo luận cả cái giá con người — trực phải nhân đạo, được tài trợ và chia sẻ, nếu không nó trở thành vấn đề kiệt sức và giữ chân nhân sự, mà trong một NHS thiếu nhân lực là rủi ro nghiêm trọng (xem Chủ đề 7.2 — Hoạch định nguồn nhân lực). Có một sự đánh đổi thực giữa quyền sở hữu toàn nhóm và thực tế là một số tổ chức và nhà cung cấp nhỏ hơn thực sự cần một nền tảng dùng chung hoặc dịch vụ được quản lý để vận hành mọi thứ đáng tin cậy. Một câu trả lời mạnh nối trách nhiệm vận hành trở lại thiết kế: nó xác định vòng phản hồi giữa xây và chạy bị gãy ở đâu, và bạn sẽ thay đổi gì để các lựa chọn kỹ thuật được thông tin bởi thực tế của vận hành trực tiếp.

3. Bao nhiêu mã của chúng ta, và thực hành kỹ thuật của chúng ta, có thể chịu được việc bị công khai — và câu trả lời tiết lộ điều gì? Chính sách chính phủ và NHS yêu cầu các nhóm lập trình công khai theo mặc định, và câu hỏi này dùng lăng kính đó như một chẩn đoán ngay cả khi chưa thể hoàn toàn cởi mở. Nếu viễn cảnh công bố các kho mã của bạn gây lo lắng, hãy hỏi chính xác vì sao: là bí mật mã hóa cứng, dữ liệu bệnh nhân nhúng, thiếu kiểm thử, quyết định không được ghi chép, hay chỉ đơn giản là chưa quen? Mỗi điều đó là một vấn đề chất lượng kỹ thuật hoặc quản trị thông tin thực sự mà việc đóng chỉ che giấu chứ không giải quyết. Hãy tranh luận các ràng buộc thực — một số mã nhạy cảm về bảo mật nên giữ đóng, và làm đúng quản lý bí mật là điều kiện tiên quyết — so với lợi ích của sự soi xét, tái sử dụng trong một hệ thống thiếu tiền, và niềm tin công chúng vào cách chi tiêu cho phần mềm y tế được dùng. Hãy cân nhắc giá trị về danh tiếng và an toàn của những cặp mắt bên ngoài tìm ra một lỗi trước khi kẻ tấn công làm. Một câu trả lời tốt, trung thực phân biệt mã bị đóng vì một lý do bảo vệ được, được ghi chép với mã bị đóng do thói quen hay xấu hổ, và cam kết sửa các vấn đề chất lượng và vệ sinh nền tảng dù theo cách nào.

4. Nếu một lỗ hổng được công bố rộng rãi trong một phụ thuộc phổ biến được thông báo vào sáng mai, chúng ta sẽ mất bao lâu để trả lời "chúng ta có bị ảnh hưởng không, và ở đâu?" Câu hỏi này kiểm tra liệu vệ sinh chuỗi cung ứng có là năng lực thực hay chỉ là khát vọng, dùng loại sự kiện toàn ngành — một lỗ hổng kiểu Log4j — biến một rủi ro trừu tượng thành một tình huống khẩn cấp trong ngày. Câu trả lời trung thực phụ thuộc vào việc bạn có duy trì một bản kiểm kê chính xác các phụ thuộc và một bảng kê vật liệu phần mềm, hay bạn sẽ mất nhiều ngày lục kho mã và hỏi các nhà cung cấp có thể chính họ cũng không biết. Hãy khám phá bao nhiêu phần mềm của bạn được lắp ráp từ các thành phần bên thứ ba và mã nguồn mở, và bạn thực sự giám sát bao nhiêu bề mặt đó bằng quét tự động so với kiểm tra thủ công thỉnh thoảng. Hãy thảo luận cả chiều kích bên thứ ba và nhà cung cấp, vì trong y tế và chăm sóc phần lớn hệ thống được mua thay vì xây, và một phụ thuộc bị xâm phạm trong sản phẩm của nhà cung cấp là con đường đến dữ liệu bệnh nhân bí mật mà bạn không kiểm soát trực tiếp (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 liệu các đường ống và quyền đẩy lên sản phẩm của bạn có đủ chặt để một thành phần bị đầu độc không thể lặng lẽ được giao. Một câu trả lời mạnh nêu một thời gian trả lời thực tế đo bằng giờ, chỉ ra công cụ và bản kiểm kê cụ thể làm cho điều đó khả thi, và thẳng thắn về các phần của hệ thống — đặc biệt do nhà cung cấp cấp — nơi khả năng quan sát hiện còn yếu.

5. Các chỉ số kỹ thuật của chúng ta có nói sự thật, hay chúng đã lặng lẽ trở thành một mục tiêu hiệu suất mà người ta quản lý hướng lên trên? Các chỉ số DORA chỉ hữu ích như một tín hiệu cấp hệ thống trung thực, và câu hỏi này thăm dò liệu của bạn có sống sót qua va chạm với các động cơ tổ chức. Định luật Goodhart không khoan nhượng: khoảnh khắc tần suất triển khai hay tỷ lệ thất bại thay đổi trở thành một con số mà một nhóm bị đánh giá, người ta tối ưu con số thay vì thực tế nền tảng — tách các lần triển khai để thổi phồng tần suất, hoặc lặng lẽ phân loại lại sự cố để chúng không được tính là thất bại. Hãy tranh luận ai thấy các chỉ số này và vì sao, và chúng được dùng để chẩn đoán nhằm thúc đẩy đầu tư vào độ bao phủ kiểm thử hay cỡ lô, hay như một bảng xếp hạng thúc đẩy gian lận và rủi ro bị che giấu. Hãy cân nhắc cả mặt trái: các nhóm không đo gì và dựa vào giai thoại, nên tỷ lệ thất bại tăng là vô hình cho đến khi nó thành một sự cố lâm sàng. Có một căng thẳng thực giữa nhu cầu chính đáng của hội đồng về sự đảm bảo và thực tế rằng những chỉ số hữu ích nhất là những chỉ số mà các nhóm cảm thấy an toàn khi báo cáo trung thực. Một câu trả lời tốt mô tả cách việc đo lường được định khung và quản trị để nó làm lộ ra những sự thật khó chịu sớm thay vì thưởng cho người ta vì che giấu chúng.

6. Lần gần nhất chúng ta cố ý trả nợ kỹ thuật là khi nào, và chúng ta quyết định "đủ tốt" nghĩa là gì về kỹ thuật trong một hệ thống lâm sàng như thế nào? Nợ kỹ thuật trong một hệ thống lâm sàng không phải vấn đề gọn gàng; nó lặng lẽ nâng chi phí và rủi ro của mọi thay đổi tương lai, nên bản sửa lẽ ra mất một ngày lại mất hai tuần và chạm vào mã mà không ai dám tái cấu trúc. Câu hỏi này buộc một nhóm đối diện với việc nợ được quản lý như công việc hữu hình, có kế hoạch hay chỉ tích lũy cho đến khi có thứ gì đó hỏng, và liệu các chuẩn kỹ thuật — rà soát mã, linting, một định nghĩa hoàn thành rõ ràng — có được thực thi thực sự hay bị bỏ qua dưới áp lực triển khai. Hãy khám phá sự đánh đổi thực giữa việc giao tính năng mà một dịch vụ cần bây giờ và duy trì chất lượng nội tại giữ hệ thống an toàn để thay đổi về sau, vì trong y tế và chăm sóc cả hai đều chính đáng và sự cân bằng là một phán đoán, không phải khẩu hiệu. Hãy thảo luận cách các chuẩn làm mã dễ đọc không chỉ với kỹ sư kế tiếp mà với kiểm toán viên, cán bộ an toàn lâm sàng và người rà soát mã nguồn mở có thể cần đọc nó. Hãy cân nhắc liệu bạn thậm chí có thể thấy nợ của mình không: nó được gọi tên và theo dõi, hay là kiến thức bộ lạc về những mô-đun đáng sợ? Một câu trả lời trung thực chỉ ra việc khắc phục cụ thể, được tài trợ đã thực sự diễn ra, và một định nghĩa chung, bảo vệ được về ngưỡng chất lượng mà một hệ thống được quản lý đòi hỏi.

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 dịch vụ "điểm tiếp cận duy nhất" dùng chung định tuyến các chuyển tuyến chăm sóc cộng đồng khẩn cấp đến đúng nhóm. Trong hai năm đầu, dịch vụ được triển khai bằng tay khoảng một lần mỗi quý: một lập trình viên làm theo một trang wiki gồm các bước thủ công vào chiều muộn thứ Sáu, và mỗi bản phát hành là một sự kiện căng thẳng, huy động toàn bộ mọi người. Khi một lỗi định tuyến chuyển tuyến xuất hiện — thỉnh thoảng gửi các chuyển tuyến nhu cầu phức tạp đến sai nhóm — bản sửa nằm trong hàng đợi sáu tuần chờ cửa sổ phát hành tiếp theo, và các bác sĩ quản lý rủi ro bằng các cách xoay xở thủ công.

Trưởng bộ phận kỹ thuật mới định khung lại điều này là một vấn đề an toàn lâm sàng, không chỉ hiệu quả. Nhóm đưa vào một đường ống CI/CD: mọi thay đổi đều nhỏ, được đồng nghiệp rà soát, và được xây dựng cùng kiểm thử tự động, với các kiểm tra khả năng tiếp cận và bảo mật và một bước phê duyệt an toàn lâm sàng được mã hóa thành các cổng đường ống tạo ra một hồ sơ có thể kiểm toán cho nhật ký mối nguy. Hạ tầng được chuyển sang mã, nên môi trường kiểm thử và sản phẩm cuối cùng khớp nhau. Các lần triển khai chuyển từ hằng quý sang vài lần mỗi tuần, được phát hành đầu tiên cho một địa phương duy nhất như một canary, với một quay lui đã được kiểm thử trả về trạng thái tốt đã biết cuối cùng trong dưới năm phút.

Sáu tháng sau, các chỉ số DORA kể câu chuyện cho hội đồng bằng thuật ngữ đơn giản: thời gian dẫn cho một bản sửa đã giảm từ sáu tuần xuống dưới một ngày, tần suất triển khai tăng mười lần, và tỷ lệ thất bại thay đổi đã giảm vì các thay đổi nay nhỏ và quan sát được. Khi một lỗi định tuyến tinh vi tái diễn, bảng điều khiển khả năng quan sát đánh dấu bất thường trong vài phút, nhóm quay lui trước khi có chuyển tuyến nào bị định tuyến sai, giao một bản sửa vào sáng hôm sau, và ghi lại một cuộc rà soát sau sự cố không đổ lỗi. Nhóm cũng công bố bộ máy quy tắc định tuyến không nhạy cảm dưới dạng mã nguồn mở theo Tiêu chuẩn Dịch vụ NHS, và một ICS lân cận tái sử dụng nó. Thay đổi hệ thống thường xuyên hơn đã làm nó an toàn hơn một cách có thể chứng minh.

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ố có thể áp dụng thực hành kỹ thuật hiện đại ngay từ ngày đầu, không có nhóm vận hành cũ để thương lượng — phát triển dựa trên thân cây, CI/CD và hạ tầng dưới dạng mã thực chất là mặc định miễn phí trong một nhóm nhỏ, mới hoàn toàn, và đây là một lợi thế thực sự. Rủi ro là "đi nhanh" lặng lẽ bỏ các kỷ luật mà y tế đòi hỏi: kiểm thử tự động, quay lui đã kiểm thử, quản lý bí mật và quét phụ thuộc cảm giác như ma sát khi chưa có cơ quan quản lý nào dõi theo. Các nhà sáng lập phải nhận ra rằng nghĩa vụ an toàn lâm sàng và chuỗi cung ứng gắn bất kể quy mô công ty, và một bộ dữ liệu bệnh nhân bị rò rỉ hay một phụ thuộc không được quản lý có thể kết liễu công ty. Con đường thực dụng là dựa vào các nền tảng đám mây được quản lý và một "con đường lát sẵn" nhỏ, có chính kiến để một nhóm nhỏ nhận được an toàn-theo-mặc-định mà không phải xây một nhóm nền tảng mà nó chưa đủ khả năng chi.

Doanh nghiệp nhỏ#

Một nhà cung cấp hoặc nhà cung ứng 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ỏ đã qua giai đoạn chưa có doanh thu — thường có bệnh nhân thật và hoạt động thật nhưng không có chức năng kỹ thuật hay CNTT chuyên trách để chạy đường ống, khả năng quan sát hay trực. Với hầu hết các tổ chức như vậy, hình thức thực tế của xuất sắc kỹ thuật là mua tốt thay vì xây: chọn các nhà cung cấp và nền tảng được quản lý mà kỷ luật DevOps của chính họ bạn có thể kiểm tra, và biến cập nhật tự động, sao lưu đã kiểm thử và vá phụ thuộc thành kỳ vọng hợp đồng thay vì hy vọng. Nơi một nhà cung cấp nhỏ thực sự viết phần mềm, một đường ống CI/CD được cấu hình tốt trên một nền tảng đám mây được quản lý, với quét phụ thuộc tự động và bí mật được giữ ngoài kho mã, mang lại phần lớn lợi ích an toàn với chi phí mà một nhóm tinh gọn có thể duy trì. Cái bẫy là cho rằng quy mô nhỏ hạ thấp ngưỡng an toàn lâm sàng, bảo mật và quản trị thông tin — nó không, và một phụ thuộc chưa vá hay một thay đổi triển khai bằng tay đi sai gây hại cho bệnh nhân chắc chắn như nhau ở một phòng khám hai bác sĩ cũng như ở một cơ quan quốc gia. Mục tiêu thực tế là an toàn-theo-mặc-định thừa hưởng từ các nền tảng tốt và nhà cung cấp tốt, với sự chú ý hạn chế của phòng khám dành cho việc xác minh rằng các mặc định đó thực sự được bật.

Doanh nghiệp lớn#

Một bệnh viện NHS lớn hoặc nhà cung ứng công nghệ y tế lớn có nguồn lực để làm kỹ thuật nền tảng, khả năng quan sát và "bạn xây, bạn vận hành" đúng cách, nhưng bị kìm lại bởi các hệ thống cũ, các nhóm phát triển và vận hành rời rạc, và các quy trình tư vấn thay đổi được xây cho một thời đại chậm hơn. Thất bại đặc trưng là một hội đồng thay đổi nặng nề, trong khi cố kiểm soát rủi ro, buộc các bản phát hành gom lô lớn nguy hiểm hơn các bản nhỏ thường xuyên mà nó sợ. Cơ hội là đầu tư vào một nền tảng lập trình viên nội bộ nướng các cổng tuân thủ, bảo mật và an toàn lâm sàng vào một con đường lát sẵn, để hàng chục nhóm thừa hưởng thực hành tốt thay vì mỗi nhóm tự thương lượng. Quy mô ở đây là con dao hai lưỡi: bán kính ảnh hưởng của một lần triển khai xấu là rất lớn, đó chính là lý do tự động hóa, phát hành canary và quay lui đã kiểm thử là thiết yếu chứ không tùy chọn.

Chính phủ#

Một cơ quan quốc gia như NHS England hoặc một bộ y tế được phân quyền đặt ra các chuẩn mà người khác theo — Tiêu chuẩn Dịch vụ NHS và GDS, kiểm soát chi tiêu, kỳ vọng lập trình công khai — và chịu trách nhiệm trước Nghị viện và công chúng về cách phần mềm được xây và vận hành. Các lựa chọn kỹ thuật của nó lan tỏa khắp hệ thống: một nền tảng quốc gia vận hành tốt, các thành phần mã nguồn mở được công bố và hướng dẫn chuỗi cung ứng rõ ràng nâng mức sàn cho mọi bệnh viện và nhà cung cấp. Các ràng buộc là có thật — kinh phí nhiều năm, quy tắc mua sắm, và quy mô cùng độ nhạy cảm của dữ liệu quốc gia nghĩa là nhịp triển khai thận trọng hơn một công ty khởi nghiệp. Lăng kính chính phủ phải cân bằng sự minh bạch và tái sử dụng gương mẫu với an ninh của các hệ thống then chốt quốc gia, quyết định có chủ đích điều gì được mở và điều gì được bảo vệ, và ghi lại lập luận theo cả hai hướng.

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

• Tê liệt "thay đổi là rủi ro". Triển khai hiếm để cảm thấy an toàn, tạo ra các bản phát hành lớn, nguy hiểm, hiểu kém và sự bỏ bê chưa vá. Giải pháp: các thay đổi nhỏ, thường xuyên, có thể đảo ngược với quay lui đã kiểm thử.
• Bức tường giữa phát triển và vận hành. Lập trình viên "ném mã qua tường" cho một nhóm vận hành riêng không thể sửa nguyên nhân gốc; không ai sở hữu toàn bộ vòng lặp. Giải pháp: quyền sở hữu chung và "bạn xây, bạn vận hành", được hỗ trợ một cách nhân đạo.
• Triển khai thủ công, bông tuyết. Bản phát hành phụ thuộc vào một người và một trang wiki; môi trường trôi và "chạy trong kiểm thử, hỏng trong sản phẩm" là thường lệ. Giải pháp: CI/CD cộng hạ tầng dưới dạng mã.
• Chỉ số như cây gậy. Số liệu DORA dùng để xếp hạng các nhóm, thúc đẩy gian lận và rủi ro bị che giấu. Giải pháp: dùng chúng như chẩn đoán cấp hệ thống, theo chính hướng dẫn của DORA.
• Vận hành mù cảnh báo. Không có khả năng quan sát, nên bệnh nhân và bác sĩ phát hiện thất bại trước. Giải pháp: số đo, nhật ký, dấu vết và cảnh báo theo tác động đến người dùng.
• Chuỗi cung ứng bị bỏ bê. Phụ thuộc chưa vá và thành phần chưa quét trở thành vụ xâm phạm. Giải pháp: quét liên tục, một bảng kê vật liệu phần mềm và các đường ống được bảo vệ.
• Phơi bày vô tình. Lập trình công khai làm cẩu thả, làm rò rỉ bí mật hoặc dữ liệu bệnh nhân. Giải pháp: quản lý bí mật nghiêm ngặt và quét trước khi công bố, không phải rút về đóng-theo-mặc-định.

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

Danh sách kiểm tra#

• Một đường ống CI/CD xây dựng, kiểm thử và triển khai mọi thay đổi qua một con đường có thể kiểm toán, với các cổng an toàn/bảo mật/khả năng tiếp cận được mã hóa.
• Các thay đổi nhỏ, thường xuyên và có thể đảo ngược độc lập (cờ tính năng, phát hành canary hoặc xanh-lục).
• Quay lui về trạng thái tốt đã biết được kiểm thử định kỳ và hoàn tất trong một thời gian ngắn, được ghi chép.
• Hạ tầng và cấu hình được định nghĩa dưới dạng mã có kiểm soát phiên bản; môi trường kiểm thử và sản phẩm khớp nhau.
• Bốn chỉ số DORA được theo dõi như tín hiệu cấp hệ thống, không dùng để xếp hạng cá nhân hay nhóm.
• Các nhóm triển khai sở hữu dịch vụ của họ trong sản phẩm, với việc trực nhân đạo, được tài trợ và khả năng quan sát có ý nghĩa (số đo, nhật ký, dấu vết, cảnh báo).
• Các phụ thuộc được kiểm kê và quét tự động; một bảng kê vật liệu phần mềm tồn tại và bí mật được bảo vệ.
• Chuẩn kỹ thuật, rà soát mã và một định nghĩa hoàn thành được thống nhất; nợ kỹ thuật được theo dõi và trả như công việc có kế hoạch.
• Mã nguồn mới được mở theo mặc định nơi an toàn, với các kiểm tra nghiêm ngặt rằng không dữ liệu bệnh nhân hay bí mật nào bị phơi bày.
• Thực hành kỹ thuật được ghi chép để một kỹ sư mới, kiểm toán viên hoặc cán bộ an toàn có thể hiểu cái gì chạy và vì sao (xem Chủ đề 10.3).

Nguồn chính#

• Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and Development and DevOps — nghiên cứu DORA và bốn chỉ số chính.
• DORA (DevOps Research and Assessment) — các báo cáo State of DevOps hằng năm và danh mục năng lực — dora.dev.
• Jez Humble & David Farley, Continuous Delivery — đường ống triển khai và tự động hóa phát hành.
• Betsy Beyer và cộng sự (biên tập), Site Reliability Engineering — cuốn sách SRE của Google về vận hành các hệ thống sản phẩm.
• NHS England — Tiêu chuẩn Dịch vụ NHS và Sổ tay Dịch vụ Số của NHS (gồm lập trình công khai và chuẩn mở).
• Sổ tay Dịch vụ GOV.UK / Tiêu chuẩn Dịch vụ Chính phủ (GDS) — "make new source code open", giao hàng liên tục và vận hành một dịch vụ.
• Trung tâm An ninh Mạng Quốc gia (NCSC) — hướng dẫn về phát triển phần mềm an toàn và an ninh chuỗi cung ứng.
• NHS England — Các tiêu chuẩn quản lý rủi ro lâm sàng DCB0129 và DCB0160 (thay đổi kỹ thuật như một phần của hồ sơ an toàn lâm sàng).

Tài liệu tham khảo#

1. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
2. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
3. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
4. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
5. Version control — Wikipedia — https://en.wikipedia.org/wiki/Version_control
6. Infrastructure as code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
7. Platform engineering — Wikipedia — https://en.wikipedia.org/wiki/Platform_engineering
8. DevOps Research and Assessment (DORA) — Wikipedia — https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment
9. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
12. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
13. Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble & Gene Kim (IT Revolution) — https://itrevolution.com/product/accelerate/
14. DORA — DevOps Research and Assessment — Google Cloud / DORA — https://dora.dev/
15. Continuous Delivery — Jez Humble & David Farley — https://continuousdelivery.com/
16. Site Reliability Engineering — Google (O'Reilly) — https://sre.google/books/
17. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard-points
18. Making source code open and reusable — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
19. Secure software development and supply chain security — National Cyber Security Centre (NCSC) — https://www.ncsc.gov.uk/collection/developers-collection
20. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety