Lợi nhuận:
- Khả năng tạo runbook, bộ khung tài liệu kiến trúc và khám nghiệm tử thi từ các ghi chú rải rác bằng trí tuệ nhân tạo
- Khả năng thực thi kỷ luật áp đặt 'lệnh cấm chế tạo' cũng như kiểm tra và đánh dấu kỹ lưỡng từng sổ sách trong môi trường thực tế
- Khả năng hiểu rằng một runbook sai còn nguy hiểm hơn là không có và giữ cho tài liệu tồn tại trong suốt quá trình thay đổi
Quản lý tài liệu và thông tin: Runbook, Kiến trúc và bộ nhớ thể chế với AI
Nhiệm vụ quan trọng nhất nhưng lại bị bỏ quên nhất trong quản lý hệ thống là tài liệu. Khi một hệ thống gặp sự cố và người xây dựng nó đang đi nghỉ và không có văn bản nào hướng dẫn cách khắc phục, đó là một đêm dài đối với tất cả mọi người. Tài liệu là bộ nhớ của tổ chức giúp ghi lại và sẵn sàng cách thiết lập hệ thống, cách thức hoạt động và những việc cần làm nếu xảy ra sự cố. Loại quan trọng nhất của bộ nhớ này là runbook: hướng dẫn vận hành cho bạn biết từng bước phải làm gì trong một tình huống cụ thể (dịch vụ bị hỏng, ổ đĩa đầy, sao lưu không thành công). Ở đây AI giải quyết vấn đề "trang trống" và "sự lười biếng", vốn là kẻ thù lớn nhất của việc viết tài liệu: nó tạo ra một sổ tay có tổ chức từ các ghi chú rải rác của bạn, một quy trình từ lịch sử lệnh, một mô tả từ một kiến trúc. Nhưng nguyên tắc quan trọng: AI tạo ra các bản thiết kế và khung sườn; Bạn là người thử nghiệm và xác thực từng bước để xem liệu nó có thực sự đúng hay không — một sổ sách chạy sai còn nguy hiểm hơn là không có sổ sách chạy nào cả.
Trong đơn vị này, sổ ghi chép, khám nghiệm tử thi (báo cáo điều tra sau sự kiện), tài liệu kiến trúc và viết cơ sở kiến thức; Tạo bản nháp bằng AI; và quan trọng nhất là bạn sẽ biết được những rủi ro của tài liệu chưa được xác minh.
Tại sao sử dụng sai runbook còn tệ hơn là không có runbook?
Đây là khái niệm quan trọng nhất của đơn vị này. Một đội không có sổ sách sẽ thận trọng và nghi ngờ trong lúc hoảng loạn; suy nghĩ kỹ về mọi lệnh. Nhưng ai đó có sổ ghi chép “chính thức” lại tin tưởng nó một cách mù quáng - vào lúc nửa đêm, bị căng thẳng, thực hiện các bước mà không cần thắc mắc. Nếu runbook đó được phát hành mà không được AI sản xuất và kiểm tra và sai một bước (sai lệnh, thiếu điều kiện tiên quyết, bỏ qua bước dự phòng), kết quả sẽ rất tai hại. Đó là lý do tại sao mọi runbook được tạo bằng AI phải được chạy từ đầu đến cuối trong môi trường thực và mọi bước đều phải được xác minh trước khi xuất bản. Một runbook chưa được kiểm tra giống như một lời hứa trấn an nhưng trống rỗng.
Thận trọng: Đóng dấu runbook bằng "đã kiểm tra: [ngày], [người]". Đánh dấu rõ ràng các bản nháp chưa được kiểm tra bằng nhãn “Bản nháp - KHÔNG ĐƯỢC XÁC MINH”. Vì vậy, không ai có thể áp dụng các bước chưa được xác minh một cách an toàn trong một cuộc khủng hoảng thực sự.
Cấu trúc của một cuốn sách chạy tốt
Một sổ tay tốt bao gồm các phần cụ thể và AI rất giỏi trong việc xây dựng bộ khung đó: tiêu đề và mục đích (cho tình huống nào), điều kiện tiên quyết (quyền truy cập nào, công cụ cần thiết), triệu chứng (khi nào tôi sử dụng sổ tay này), các bước (với các lệnh được đánh số, có thể sao chép), xác thực (cách nhận biết thành công sau mỗi bước), khôi phục (cách hoàn tác nếu một bước xấu đi) và báo cáo (tôi sẽ gọi cho ai nếu tôi không thể tìm ra). Bạn có thể đưa cho AI những ghi chú rải rác của bạn và yêu cầu nó đưa nó vào cấu trúc này; Bạn chỉ đảm bảo tính chính xác của nội dung.
Từng bước: Sản xuất tài liệu bằng AI
- Thu thập nguyên liệu thô. Lịch sử lệnh, ghi chú của bạn, email cũ, nhật ký trò chuyện—tài liệu thực, ngay cả khi lộn xộn, vẫn tốt hơn so với việc chế tạo AI.
- Yêu cầu cấu trúc. “Hãy biến cuốn sách này thành một cuốn sổ tay với các tiêu đề sau: mục đích, điều kiện tiên quyết, triệu chứng, các bước, xác minh, khôi phục, leo thang.”
- Cấm chế tạo. "Đừng thêm bất kỳ lệnh, IP, phiên bản hoặc bước nào mà tôi chưa cung cấp cho bạn; hãy đánh dấu bất kỳ phần còn thiếu nào là [ĐỂ ĐƯỢC ĐIỀN]." Điều này ngăn ngừa sai lầm nguy hiểm nhất - những bước dàn dựng có vẻ hợp lý.
- Mặt nạ. Sử dụng trình giữ chỗ thay vì máy chủ, IP, người dùng thực tế; Nếu tài liệu được chia sẻ thì bí mật sẽ không bị rò rỉ.
- Kiểm tra nó. Chạy runbook từ đầu đến cuối trong môi trường thực tế (tốt nhất là thử nghiệm). Sửa bất kỳ bước nào không hoạt động, bị thiếu hoặc không rõ ràng.
- Đóng dấu và xuất bản. Thêm ngày kiểm tra, người kiểm tra và cập nhật lần cuối. Tài liệu rất sống động; Nó phải được cập nhật khi hệ thống thay đổi.
ba trường hợp nhỏ
Trường hợp 1 - 2 giờ làm việc, 15 phút. Một quản trị viên đã trì hoãn việc ghi lại quy trình khôi phục bản sao lưu trong nhiều tháng. Anh ta đưa ra lịch sử lệnh terminal (được che giấu) và một vài ghi chú rải rác cho AI rồi chèn nó vào runbook framework. AI tạo ra một bản phác thảo gọn gàng trong 15 phút. Quản trị viên đã dành 45 phút tiếp theo để chạy bản nháp từ đầu đến cuối trên máy chủ thử nghiệm và sửa hai bước còn thiếu. Kết quả: một cuốn sổ tay đã được thử nghiệm và đáng tin cậy.
Trường hợp 2 - Bị bắt nhầm. Một nhóm đã yêu cầu AI viết runbook khởi động lại dịch vụ nhưng lại quên cấm "chế tạo". YZ đã thêm lệnh "xóa bộ nhớ đệm trước", lệnh này có vẻ hợp lý nhưng không tồn tại trong dịch vụ đó. May mắn thay, kỹ sư đã chạy runbook trong môi trường thử nghiệm; Lệnh đó đã báo lỗi. Bước kiểm tra là một bước dàn dựng có thể gây nhầm lẫn trong một cuộc khủng hoảng thực sự.
Trường hợp 3 - Gia tốc sau khi chết. Sau một đợt ngừng hoạt động lớn, nhóm cần viết bản khám nghiệm tử thi, nhưng không ai có thể bắt đầu. Họ giao dòng thời gian sự kiện và nhật ký bị che giấu cho AI và yêu cầu một bộ xương khám nghiệm tử thi vô tội - tóm tắt, tác động, dòng thời gian, nguyên nhân gốc rễ, hành động khắc phục. Bản thiết kế AI giảm thời gian làm việc một giờ xuống còn mười phút; Nhóm đã cống hiến sức lực của mình để xác minh sự thật và làm rõ các mục hành động.
Bốn mẫu có thể sao chép
1) Tạo khung runbook:
Vai trò của bạn: SRE cấp cao. Tạo một sổ ghi chép từ lịch sử lệnh/ghi chú ẩn bên dưới. Các tiêu đề: Mục đích, Điều kiện tiên quyết, Triệu chứng (khi sử dụng), Các bước (được đánh số, có thể sao chép), Xác minh tại mỗi bước, Khôi phục, Nâng cấp. QUY TẮC: Không tạo ra bất kỳ lệnh/IP/phiên bản/bước nào mà tôi không cung cấp cho bạn; viết những phần còn thiếu [ĐIỀN]. Chất liệu: [ghi chú đeo mặt nạ]
2) Khám nghiệm tử thi không đổ lỗi:
Vai trò của bạn: người hỗ trợ điều tra sự cố. Viết bản phác thảo khám nghiệm tử thi MIỄN PHÍ từ dòng thời gian và nhật ký bị che giấu sau đây: Tóm tắt, Tác động (thời lượng/phạm vi), Dòng thời gian, Nguyên nhân gốc rễ (nếu đã được xác minh), Các yếu tố góp phần, Hành động khắc phục (chủ sở hữu + mức độ ưu tiên). Đừng đổ lỗi cho con người, hãy tập trung vào hệ thống. Đừng viết nguyên nhân gốc rễ mà không có bằng chứng. Dữ liệu: […]
3) Mô tả kiến trúc/dịch vụ:
Viết tài liệu dịch vụ từ thông tin sơ đồ/cấu hình ẩn sau đây: dịch vụ làm gì, bao gồm những thành phần nào, các phụ thuộc của nó là gì, luồng dữ liệu như thế nào, cổng/giao thức nào. Giữ nó kỹ thuật nhưng có thể đọc được. Đánh dấu mối quan hệ mà bạn không chắc chắn là "cần xác minh". Thông tin: [đeo mặt nạ]
4) Kiểm toán bồi dưỡng tài liệu:
Xem lại tài liệu hiện có sau đây và kiểm tra tính phổ biến: (1) phần nào bị thiếu/tối nghĩa, (2) bước nào có vẻ chưa được kiểm tra, (3) thông tin nào có thể đã lỗi thời? Viết ra những gì tôi nên hỏi/xác minh cho mỗi phát hiện. Tài liệu: [tài liệu bị che giấu]
Dấu nhắc yếu / Dấu nhắc mạnh
Dấu nhắc yếu:
Viết cho tôi một sổ tay bảo trì máy chủ.
Không có vật liệu thực sự. AI tạo ra một văn bản, hoàn toàn từ kiến thức chung của chính nó, không phù hợp với môi trường của bạn hoặc thậm chí chứa các bước bịa đặt. Đây là một nguồn nguy hiểm của sự tự tin sai lầm.
Lời nhắc mạnh mẽ:
Vai trò của bạn: SRE cấp cao. Dưới đây là lịch sử lệnh bị che và các ghi chú mà tôi đã triển khai trong sự kiện "đĩa dịch vụ thanh toán đầy". Tạo sổ quản lý từ những mục sau: Mục đích, Điều kiện tiên quyết (quyền truy cập/công cụ), Triệu chứng, Các bước được đánh số (với lệnh của tôi), Xác minh ở mỗi bước, Khôi phục, Nâng cấp. Đừng bắt tôi làm theo mệnh lệnh mà tôi không đưa ra; Điền vào chỗ trống [ĐỂ ĐƯỢC ĐIỀN]. Đặt cảnh báo "chưa được kiểm tra" ở cuối. Chất liệu: [lịch sử lệnh bị che giấu]
Loại tài liệu
Đóng góp của AI
Sự đóng góp bắt buộc của con người
sổ chạy
Bộ xương + bố cục
Kiểm tra trong môi trường thực tế, độ chính xác
Khám nghiệm tử thi
Đề cương + cấu trúc
Xác minh sự thật và nguyên nhân gốc rễ
tài liệu kiến trúc
Mô tả + dòng chảy
Xác nhận mối quan hệ và sự phụ thuộc
Bài viết cơ sở kiến thức
dự thảo nhanh
Kiểm tra tính hiện tại và độ chính xác
Những lỗi thường gặp
- Xuất bản runbooks chưa được kiểm tra. Các bước chưa được xác minh được thực hiện một cách mù quáng trong khủng hoảng; Runbook sai là thảm họa.
- Không áp đặt lệnh cấm chế tạo. Nếu bạn không nói với AI “đừng thêm những gì tôi chưa cho”, nó sẽ đưa ra những bước đi hợp lý nhưng không thực tế.
- Bỏ qua việc đắp mặt nạ. Bí mật bị rò rỉ khi tài liệu chứa máy chủ, IP và người dùng thực được chia sẻ.
- Không cập nhật tài liệu. Các tài liệu không được cập nhật khi hệ thống thay đổi sẽ trở nên sai lệch theo thời gian.
- Xuất bản không có tem. Không rõ tài liệu không có ngày và trạng thái kiểm tra là đáng tin cậy hay là bản nháp.
Mẹo: Cách tốt nhất để giữ cho tài liệu luôn “hoạt động” là gắn nó với quy trình thay đổi: khi hệ thống thay đổi, hãy để việc cập nhật sổ tay liên quan là một trong những tiêu chí hoàn thành cho thay đổi. AI tăng tốc độ cập nhật nhưng bạn mới là người kích hoạt.
Tóm lại
Tài liệu là bộ nhớ thể chế; Cuốn sổ tay này là một hướng dẫn vận hành giúp cứu mạng sống trong thời kỳ khủng hoảng. AI tạo ra các bản nháp có tổ chức từ những ghi chú lộn xộn của bạn, giải quyết vấn đề trang trống và sự lười biếng. Nhưng sự thật quan trọng nhất là: viết sai sổ sách còn nguy hiểm hơn là không viết gì vì nó được áp dụng một cách mù quáng trong thời kỳ khủng hoảng. Vì vậy, hãy cấm AI "chế tạo", che giấu nó, đồng thời kiểm tra và đóng dấu kỹ lưỡng từng runbook trong môi trường thực. Giữ tài liệu tồn tại khi hệ thống thay đổi. AI xây dựng khuôn khổ; Bạn là người đảm bảo tính chính xác và thử nghiệm.
Nhiệm vụ ứng dụng
Chọn một quy trình chưa được ghi lại trong nhóm của bạn (ví dụ: khởi động lại dịch vụ hoặc khôi phục bản sao lưu). Che dấu lịch sử lệnh và ghi chú có liên quan của bạn và yêu cầu AI tạo bản nháp bằng cách sử dụng mẫu "Tạo bộ xương Runbook" ở trên; Hãy chắc chắn để áp đặt lệnh cấm đối với việc bịa đặt. Chạy bản nháp trong môi trường thử nghiệm và gắn cờ cũng như sửa mọi bước bị hỏng/thiếu. Thêm ngày kiểm tra và thông tin người kiểm tra vào sổ tay. Viết ra những khác biệt mà AI tạo ra và bạn sửa trong quá trình đó thành 5 mục.
danh sách kiểm tra
- [ ] Tôi đã tạo runbook từ tài liệu thực tế (ghi chú, lịch sử lệnh), chẳng phải tôi đã làm lại từ đầu sao?
- [ ] Tôi đã cấm AI "thêm lệnh/IP/bước mà tôi chưa đưa ra" chưa?
- [ ] Tôi đã che giấu thông tin nhạy cảm như máy chủ, IP và người dùng chưa?
- [ ] Tôi đã chạy và xác thực runbook trong môi trường thực tế/thử nghiệm chưa?
- [ ] Tôi đã thêm ngày thi, người kiểm tra và thông tin cập nhật mới nhất chưa?
- [ ] Tôi đã lên kế hoạch liên kết tài liệu với quá trình thay đổi hệ thống và cập nhật nó chưa?