Lợi nhuận:
- Khả năng soạn thảo yêu cầu thay đổi, đánh giá rủi ro và kế hoạch khôi phục bằng trí tuệ nhân tạo và làm cho thay đổi trở nên an toàn và có thể dự đoán được
- Khả năng mở rộng miền với thông tin phụ thuộc riêng, phân loại khả năng truy xuất và có khả năng lập kế hoạch triển khai dần dần với canary.
- Khả năng hiểu rằng chính con người là người phê duyệt, lên lịch và chịu trách nhiệm về sự thay đổi, đồng thời có được kỷ luật để không thực hiện nó nếu không có tiêu chí thành công và con đường quay trở lại.
Quản lý thay đổi: Cửa sổ đánh giá rủi ro, khôi phục và bảo trì bằng AI
Phần lớn các thảm họa trong hệ thống sản xuất phát sinh không phải do một cuộc tấn công mà do sự thay đổi: một bản vá, bản cập nhật cấu hình, bản phát hành, bản sửa lỗi “nhỏ”. Đó là lý do tại sao mọi tổ chức trưởng thành đều phải quản lý thay đổi: quy trình kỷ luật trong việc lập kế hoạch thay đổi sản xuất, đánh giá rủi ro, phê duyệt, triển khai và lùi lại khi cần thiết. Mục tiêu không phải là ngăn chặn sự thay đổi mà là làm cho nó an toàn và có thể dự đoán được. Ở đây, AI là trợ lý đắc lực trong việc soạn thảo yêu cầu thay đổi, liệt kê các rủi ro và hệ thống bị ảnh hưởng, thiết lập khung kế hoạch khôi phục và chuẩn bị danh sách kiểm tra triển khai. Nhưng nguyên tắc cơ bản vẫn là: AI tạo ra một kế hoạch chi tiết để ghi lại sự thay đổi và rủi ro; Người phê duyệt, lên lịch và chịu trách nhiệm về sự thay đổi.
Trong đơn vị này, các khái niệm về yêu cầu thay đổi, đánh giá rủi ro, kế hoạch khôi phục, thời hạn bảo trì, phân phối theo giai đoạn/canary và CAB (Ban cố vấn thay đổi); Bạn sẽ học cách lập kế hoạch thay đổi an toàn với AI.
Cấu trúc của một yêu cầu thay đổi tốt
Thay đổi không kiểm soát được là câu “Tôi đã cập nhật cái này”; Một sự thay đổi có kiểm soát là một kế hoạch. Một yêu cầu thay đổi tốt sẽ trả lời những câu hỏi sau: Điều gì đang thay đổi? (phạm vi), Tại sao? (biện minh), hệ thống nào bị ảnh hưởng? (tên miền và phần phụ thuộc), mức độ rủi ro là gì? (thấp/trung bình/cao), Khi nào? (cửa sổ bảo trì), Làm thế nào để áp dụng? (các bước), Làm thế nào để xác minh? (tiêu chí thành công), nếu hỏng thì làm sao lấy lại được? (rollback), Ai phê duyệt? (thẩm quyền). AI lấp đầy khung xương này một cách nhanh chóng - nhưng chính bạn là người thực sự biết lĩnh vực và rủi ro, là người biết tổ chức; Bạn hoàn thành danh sách AI bằng kiến thức phụ thuộc của riêng mình.
Mẹo: Hai phần thường bị bỏ qua nhất của một thay đổi là “kế hoạch khôi phục” và “tiêu chí xác minh thành công”. Nếu bạn không có câu trả lời bằng văn bản cho các câu hỏi "chính xác thì tôi phải chuyển lệnh nào nếu nó gặp sự cố" và "làm cách nào để chứng minh rằng nó đã thành công" trước khi thực hiện thay đổi, thì thay đổi đó vẫn chưa sẵn sàng.
Rollback: cổng thoát của mọi thay đổi
Trọng tâm của quản lý thay đổi là kế hoạch quay vòng. Mọi thay đổi đều phải có đường dẫn khôi phục: bản vá khôi phục, khôi phục cấu hình trước đó, khôi phục phiên bản về phiên bản trước, khôi phục từ ảnh chụp nhanh. Điểm khác biệt quan trọng là: một số thay đổi dễ hoàn nguyên (dòng cấu hình), một số thay đổi không thể đảo ngược hoặc rất khó khăn (di chuyển lược đồ cơ sở dữ liệu, xóa dữ liệu). Những thay đổi không thể đảo ngược là loại rủi ro cao nhất và đòi hỏi sự chú ý nhiều nhất, nhiều bản sao lưu nhất, thời gian bảo trì hẹp nhất. Hãy hỏi AI “thay đổi này có thể hoàn nguyên được không và nếu không, tôi nên thực hiện các biện pháp bảo mật bổ sung nào?”
Khoảng thời gian bảo trì và triển khai theo từng giai đoạn
Khoảng thời gian bảo trì là khoảng thời gian được thông báo trước trong đó thay đổi sẽ ảnh hưởng đến ít người dùng nhất — thường là vào ban đêm hoặc cuối tuần khi lưu lượng truy cập thấp. Nhưng chọn đúng thời điểm thôi chưa đủ; Dần dần triển khai thay đổi sẽ làm giảm rủi ro hơn nữa. Việc triển khai Canary trước tiên là áp dụng thay đổi cho một phần nhỏ (một máy chủ, 5% người dùng), giám sát và phổ biến thay đổi đó nếu không có vấn đề gì. Bằng cách này, một lỗi sẽ không ảnh hưởng đến toàn bộ hạm đội mà chỉ ảnh hưởng đến một phần nhỏ và sẽ được phát hiện sớm. Bạn có thể yêu cầu AI cung cấp kế hoạch triển khai theo từng giai đoạn và các số liệu để theo dõi ở từng giai đoạn.
Từng bước: Thay đổi với sự hỗ trợ của AI
- Soạn thảo yêu cầu. Ghi lại sự thay đổi với AI trong các tiêu đề ở trên.
- Mở rộng tác động. Hoàn thành danh sách các hệ thống bị ảnh hưởng của AI bằng bản đồ phụ thuộc của riêng bạn; "Những gì khác được kết nối với dịch vụ này?"
- Phân loại rủi ro. Thấp/trung bình/cao và có thể đảo ngược? Nó đòi hỏi quy trình nghiêm ngặt nhất, cao độ và không thể đảo ngược.
- Viết một rollback và kiểm tra nó. Viết ra các bước khôi phục và thử quay lại trong môi trường thử nghiệm nếu có thể - một “kế hoạch khôi phục” không thể khôi phục sẽ không được tính là một kế hoạch.
- Lập kế hoạch các cửa sổ và cấp độ. Xác định khoảng thời gian bảo trì và các giai đoạn canary cũng như các số liệu cần theo dõi ở mỗi giai đoạn.
- Xác nhận và giao tiếp. Nhận được sự chấp thuận của cơ quan có thẩm quyền (CAB nếu cần thiết), thông báo cho những người bị ảnh hưởng, thực hiện, giám sát, xác minh.
ba trường hợp nhỏ
Trường hợp 1 - Kế hoạch khôi phục đã cứu được đêm. Một nhóm áp dụng bản vá máy chủ web; Bản vá bất ngờ phá vỡ phần phụ thuộc và trang web bắt đầu báo lỗi 500. Nhưng có một bước khôi phục rõ ràng được chuẩn bị bằng AI trong yêu cầu thay đổi: "xóa bản vá, khôi phục gói trước đó, tải lại dịch vụ." Đội quay trở lại sau 6 phút. Nếu không có kế hoạch khôi phục, tình trạng ngừng hoạt động sẽ kéo dài hàng giờ trong khi tìm kiếm nguyên nhân cốt lõi vào lúc nửa đêm.
Trường hợp 2 - Canary gặp lỗi ở mức 5%. Một phiên bản mới sẽ được phân phối. Nhóm đã yêu cầu AI đưa ra kế hoạch triển khai so le: đầu tiên là 1 máy chủ, theo dõi, sau đó là 25%, sau đó là tất cả. Thời gian phản hồi đã tăng gấp đôi trên máy chủ Canary; việc phân phối đã bị dừng lại. Lỗi này chỉ tồn tại trên một máy chủ và 95% người dùng không bị ảnh hưởng. Nếu nó lan rộng cùng một lúc, toàn bộ dịch vụ sẽ sụp đổ.
Trường hợp 3 - Biện pháp bổ sung về sự thay đổi không thể đảo ngược. Việc di chuyển lược đồ cơ sở dữ liệu đã được lên kế hoạch — một thay đổi sẽ rất khó hoàn nguyên. Kỹ sư hỏi AI về rủi ro; YZ tuyên bố rằng thay đổi này là không thể thay đổi được và đề xuất sao lưu toàn bộ, chạy thử nghiệm riêng biệt và thu hẹp khoảng thời gian. Nhóm đã sao lưu toàn bộ ngay trước khi di chuyển, thử nó trên một bản sao trước. Đã xảy ra sự cố trong quá trình di chuyển nhưng nhờ sao lưu nên tính nhất quán đã được khôi phục trong vòng 20 phút.
Bốn mẫu có thể sao chép
1) Dự thảo yêu cầu thay đổi:
Vai trò của bạn: chuyên gia quản lý thay đổi. Soạn thảo yêu cầu thay đổi cho thay đổi sau: [thay đổi]. Các tiêu đề: Cái gì/Tại sao, Hệ thống bị ảnh hưởng và các yếu tố phụ thuộc, Mức độ rủi ro (thấp/trung bình/cao + biện minh), Có phải khôi phục không, Các bước triển khai, Tiêu chí xác minh thành công, Các bước khôi phục, Khuyến nghị về thời gian bảo trì, Phê duyệt bắt buộc. Đánh dấu phần phụ thuộc mà bạn không chắc chắn là "xác minh".
2) Đánh giá rủi ro và tác động:
Đánh giá sự thay đổi sau đây về mặt rủi ro: [thay đổi]. (1) Liệt kê các hệ thống có thể bị ảnh hưởng trực tiếp và gián tiếp, (2) trường hợp xấu nhất là gì, (3) có thể khắc phục được không, nếu không, tôi nên thực hiện các biện pháp bổ sung nào, (4) biện minh cho mức độ rủi ro. Giải thích rằng đây là đánh giá sơ bộ và quyết định là của tôi.
3) Tạo kế hoạch khôi phục:
Viết kế hoạch khôi phục từng bước cho [thay đổi]. Đảm bảo mọi bước đều có thể được sao chép và xác minh. Nếu có những phần thay đổi không thể thay đổi được, hãy nêu rõ điều đó và viết ra phương án dự phòng mà tôi nên thực hiện cho chúng. Thêm cách xác minh thành công của Rollback.
4) Kế hoạch phân phối theo giai đoạn (canary):
Đề xuất kế hoạch [triển khai] theo từng giai đoạn cho quá trình triển khai sau: giai đoạn nào (ví dụ: 1 máy chủ -> 25% -> tất cả), tôi nên đợi trong bao lâu ở mỗi giai đoạn và tôi nên theo dõi những chỉ số nào (thời gian phản hồi, tỷ lệ lỗi, v.v.)? Tôi nên dừng và khôi phục quá trình triển khai ở ngưỡng nào nếu vượt quá? Viết điểm quyết định của bạn một cách rõ ràng.
Dấu nhắc yếu / Dấu nhắc mạnh
Dấu nhắc yếu:
Tôi có nên áp dụng bản vá này?
Không có bối cảnh, không có tác động, không có sự dư thừa, không có cửa sổ. AI không biết hệ thống cũng như rủi ro của bạn; Câu trả lời "có/không" mà nó đưa ra là một phỏng đoán vô trách nhiệm.
Lời nhắc mạnh mẽ:
Vai trò của bạn: chuyên gia quản lý thay đổi. Tôi sẽ áp dụng bản vá bảo mật cho một nhóm máy chủ web đang được sản xuất (8 máy chủ, phía sau bộ cân bằng tải). Đưa cho tôi: (1) yêu cầu thay đổi dự thảo cho thay đổi này, (2) các phần phụ thuộc có thể bị ảnh hưởng (tôi sẽ xác nhận), (3) các bước khôi phục, (4) kế hoạch canary dưới dạng 1 máy chủ -> 25% -> tất cả và các số liệu tôi sẽ theo dõi ở từng giai đoạn. Biện minh cho mức độ rủi ro. Tôi chấp thuận và quyết định.
Thay đổi tính năng
rủi ro thấp
rủi ro cao
tính thuận nghịch
quay trở lại dễ dàng
không thể hủy bỏ/khó khăn
miền
Phục vụ đơn lẻ, bị cô lập
Chuỗi đa dịch vụ, phụ thuộc
Phân phối
có thể trực tiếp
Canary bắt buộc + cửa sổ hẹp
Phê duyệt
trong đội
CAB / phê duyệt hàng đầu
dự phòng
Tiêu chuẩn
Sao lưu đầy đủ bổ sung + chạy thử
Những lỗi thường gặp
- Thực hiện mà không có kế hoạch khôi phục. Thay đổi là một canh bạc nếu con đường quay trở lại không được viết ra.
- Giữ phạm vi ảnh hưởng thu hẹp. Việc bỏ qua các phần phụ thuộc ẩn gắn liền với một dịch vụ sẽ dẫn đến sự gián đoạn không mong muốn.
- Nhầm lẫn sự thay đổi không thể đảo ngược với sự thay đổi bình thường. Những thay đổi như di chuyển lược đồ và xóa dữ liệu yêu cầu quy trình nghiêm ngặt nhất và sao lưu toàn bộ.
- Truyền bá nó cho toàn bộ hạm đội cùng một lúc. Nếu không có Canary, lỗi sẽ tấn công tất cả người dùng cùng một lúc.
- Không xác định tiêu chí thành công Nếu "thành công" nghĩa là gì không được viết, bạn có thể nhầm một thay đổi bị hỏng với "hoàn thành".
Lưu ý: Danh sách các hệ thống bị ảnh hưởng do AI tạo ra chỉ là danh sách sơ bộ, không phải danh sách đầy đủ. AI không biết sự phụ thuộc của tổ chức bạn; Câu trả lời chính xác cho câu hỏi "Nếu dịch vụ này gặp sự cố, dịch vụ nào khác sẽ gặp sự cố?" nằm trong kiến thức về công ty của bạn. Giả sử danh sách của AI chưa đầy đủ và hãy mở rộng nó.
Tóm lại
Hầu hết các thảm họa trong sản xuất đều phát sinh từ sự thay đổi chứ không phải do tấn công; Quản lý thay đổi không ngăn cản sự thay đổi mà nó làm cho nó an toàn và có thể dự đoán được. AI; Nhanh chóng soạn thảo các yêu cầu thay đổi, đánh giá rủi ro, kế hoạch khôi phục và danh sách kiểm tra triển khai theo từng giai đoạn. Nhưng hãy mở rộng miền bằng kiến thức phụ thuộc thực sự của bạn, phân loại khả năng đảo ngược, viết khôi phục và kiểm tra nó nếu có thể, phân bổ rủi ro bằng cửa sổ bảo trì và canary, xác định tiêu chí thành công. Chính con người là người phê duyệt, lên lịch và chịu trách nhiệm về sự thay đổi; AI là đối tác đẩy nhanh kế hoạch.
Nhiệm vụ ứng dụng
Chọn một thay đổi sản xuất mà bạn dự định thực hiện sớm (hoặc vừa thực hiện gần đây). Yêu cầu AI chuẩn bị yêu cầu thay đổi hoàn chỉnh với mẫu "Bản nháp yêu cầu thay đổi" ở trên. Mở rộng danh sách "hệ thống bị ảnh hưởng" mà AI tạo ra ít nhất hai mục có thông tin phụ thuộc của riêng bạn. In ra các bước khôi phục bằng mẫu "Tạo kế hoạch khôi phục" và xác định xem có phần thay đổi nào không thể khôi phục được hay không. Cuối cùng, hãy đưa ra một kế hoạch chim hoàng yến. Tóm tắt toàn bộ kế hoạch trong 6 điểm và lưu ý những phê duyệt nào là cần thiết.
danh sách kiểm tra
- [ ] Tôi đã chuẩn bị yêu cầu thay đổi bao gồm nội dung/lý do, tác động, rủi ro, các bước, xác minh và khôi phục chưa?
- [ ] Tôi đã mở rộng danh sách các hệ thống bị ảnh hưởng của AI bằng thông tin phụ thuộc của riêng tôi chưa?
- [ ] Tôi đã phân loại liệu thay đổi đó có thể đảo ngược hay không thể đảo ngược chưa?
- [ ] Tôi đã viết các bước khôi phục và thử nó trong môi trường thử nghiệm, nếu có thể?
- [ ] Tôi đã xác định được khoảng thời gian bảo trì và kế hoạch triển khai canary cũng như các số liệu giám sát cho từng giai đoạn chưa?
- [ ] Tôi đã xác định được tiêu chí xác minh thành công và nhận được sự phê duyệt cần thiết chưa?