So sánh trách nhiệm trước sản phẩm
Đã hoàn tấtSo sánh trợ lý, platform bàn giao nội bộ và software factory. Xác định mỗi lựa chọn thực hiện công việc nào và trách nhiệm nào còn lại.
Xuất bản bởi TaigaCách chúng tôi viết
Kiểm tra mức hiểuNhà cung cấp tự động hóa viết mã và chạy test. Ai chịu trách nhiệm về yêu cầu kinh doanh?Làm bài tập
Bạn sẽ học gì
- So sánh các lựa chọn theo cùng kết quả bắt buộc.
- Phân biệt thực hiện công việc với nhận trách nhiệm về hậu quả.
- Nhận diện khoảng trống và phần chồng lấn trong mô hình vận hành đề xuất.
So sánh cùng một kết quả
Lựa chọn công cụ tạo prototype không nhất thiết quyết định mô hình vận hành production. Mọi người có thể khám phá bằng công cụ phù hợp công việc. Tổ chức vẫn cần cách được hỗ trợ để bảo mật, triển khai, bảo trì và vận hành kết quả hữu ích.
Trợ lý lập trình, platform nội bộ và software factory có thể giải quyết các phần khác nhau của vấn đề. So giá thuê bao mà không xác định phạm vi có thể dẫn đến quyết định sai lệch.
Bắt đầu với kết quả bắt buộc: bàn giao và vận hành dịch vụ nội bộ theo yêu cầu dữ liệu, bảo mật và độ tin cậy của công ty. Sau đó xác định công việc cần trên toàn vòng đời. Tính cả công việc sau màn trình diễn thành công đầu tiên.
Với dịch vụ hợp đồng giả định, tổ chức cần yêu cầu đã phê duyệt, quyền truy cập nhân viên, bản ghi riêng tư, bản phát hành đã xác minh, ứng phó sự cố và cập nhật liên tục. Công cụ sinh endpoint chỉ giải quyết một phần danh sách này.
Mô tả ba mô hình vận hành khả thi
Với trợ lý lập trình, lập trình viên dùng AI trong hệ thống kỹ thuật hiện có. Tổ chức cung cấp quy trình, tích hợp, năng lực platform và thu thập bằng chứng xung quanh. Cách này có thể phù hợp với tổ chức có dịch vụ dùng chung trưởng thành.
Với hệ thống bàn giao tự lắp ghép nội bộ, tổ chức tích hợp agent, ngữ cảnh, kiểm tra, triển khai và phản hồi vận hành. Tổ chức kiểm soát thiết kế, đồng thời sở hữu sản phẩm tích hợp, việc hỗ trợ và nâng cấp nó.
Với software factory mua ngoài, nhà cung cấp đưa ra quy trình kết nối rộng hơn. Xác minh phạm vi thực tế và tích hợp được hỗ trợ. Tổ chức vẫn cần quyết định sản phẩm và phân chia trách nhiệm rõ ràng.
Đây là mô hình so sánh, không phải nhóm sản phẩm cố định áp dụng cho mọi nơi. Nhà cung cấp hoặc platform nội bộ cụ thể có thể kết hợp năng lực khác nhau.
Xác minh lộ trình từ prototype đến dịch vụ vận hành
Dùng cùng kịch bản cụ thể cho mỗi lựa chọn. Với prototype ngân hàng, bắt đầu bằng giao dịch tổng hợp và không có quyền thật. Yêu cầu nhóm hoặc nhà cung cấp trình diễn các năng lực sau trước khi mở rộng truy cập:
- Đánh giá prototype và xác định mã cần sửa hoặc thay thế.
- Triển khai vào hạ tầng bắt buộc, gồm tài khoản cloud của bạn nếu chính sách yêu cầu.
- Xác minh quyền ứng dụng, xử lý secret và luồng dữ liệu khi phát triển và khi chạy.
- Tạo bằng chứng đáp ứng yêu cầu áp dụng và ghi quyết định phát hành.
- Giám sát dịch vụ, sửa lỗ hổng, kiểm thử khôi phục và ứng phó sự cố.
Chuyển mã vào tài khoản của bạn là một phần công việc. Xác minh ai có thể quản trị môi trường và dịch vụ bên ngoài nhận dữ liệu ở đâu. Đối chiếu biện pháp kiểm soát với nghĩa vụ của bạn; chỉ vị trí triển khai không chứng minh tuân thủ.
Để xem ranh giới do một nhà cung cấp công bố, so sánh mô tả trách nhiệm chung của Taiga với bản đồ của bạn. Đây là tài liệu của bên xuất bản trang này. Xác minh thỏa thuận và cấu hình áp dụng trước khi kích hoạt Taiga.
Tách thực hiện, kiểm tra và quyết định
Với mỗi hoạt động, ghi ai thực hiện, ai xác minh kết quả và ai chấp nhận hậu quả. Một bên có thể giữ nhiều vai trò, nhưng vai trò để trống là khoảng trống trách nhiệm.
| Hoạt động | Câu hỏi cho bản đồ trách nhiệm |
|---|---|
| Yêu cầu | Ai giải quyết quy tắc kinh doanh mơ hồ? |
| Xử lý dữ liệu | Ai phê duyệt bên nhận và điều kiện xử lý? |
| Viết mã | Ai bảo trì mã được sinh sau khi chấp nhận? |
| Xác minh | Ai kiểm tra bằng chứng bao phủ bản phát hành thực tế? |
| Triển khai | Danh tính của ai thay đổi môi trường nào? |
| Vận hành | Ai ứng phó khi dịch vụ gặp sự cố? |
| Cập nhật platform | Ai điều chỉnh tích hợp khi dependency thay đổi? |
Dịch vụ cloud cũng chia trách nhiệm giữa nhà cung cấp và khách hàng. Phân chia cụ thể tùy dịch vụ. Dùng điều này để yêu cầu bản đồ chính xác, không để mặc định mọi sản phẩm được quản lý có cùng ranh giới. Trách nhiệm chung của AWS.
Tìm khoảng trống và công việc trùng lặp
Giả sử nhà cung cấp tạo pipeline trong khi nhóm platform đã duy trì lộ trình triển khai được phê duyệt. Quyết định nhà cung cấp có nên dùng lộ trình đó không. Hai pipeline được duy trì độc lập có thể tạo kiểm soát xung đột và chi phí không cần thiết.
Ngược lại, nhà cung cấp có thể mặc định khách hàng có nhóm xử lý sự cố, còn khách hàng mặc định đã bao gồm vận hành. Giải quyết khoảng trống trước khi người dùng phụ thuộc dịch vụ.
Hướng dẫn platform của CNCF cho phép tổ chức kết hợp năng lực nội bộ và được quản lý. Câu hỏi liên quan là trải nghiệm tạo ra có đáp ứng nhu cầu người dùng với trách nhiệm rõ ràng không. Hướng dẫn CNCF.
Dùng bản đồ trong quyết định thương mại
Đính kèm bản đồ trách nhiệm vào ghi chú đánh giá và làm rõ trong thỏa thuận áp dụng. Tính giá công việc còn lại với tổ chức. Bao gồm chi phí duy trì kết nối giữa các thành phần.
Nhà cung cấp có phạm vi rộng hơn có thể có giá trị khi giảm công việc tích hợp và giữ bằng chứng xuyên vòng đời. Cách làm nội bộ có thể có giá trị khi yêu cầu riêng đủ để biện minh cho trách nhiệm sở hữu lâu dài. Quyết định dựa trên kết quả bắt buộc và phạm vi đã xác minh.
Làm bài tập
Tạo ba cột: trợ lý lập trình, hệ thống bàn giao tự lắp ghép nội bộ và software factory mua ngoài. Thêm hàng cho yêu cầu, chính sách, viết mã, xác minh, phát hành, vận hành và cập nhật. Ghi ai thực hiện, xác minh và chấp nhận từng hoạt động. Đánh dấu mọi điều chưa biết.
Tải worksheet (Markdown)Bỏ chọn sẽ xóa toàn bộ tiến độ đã lưu trong trình duyệt này.
Tiến độ ở trong trình duyệt này. Không tài khoản, không theo dõi.