我一直對 IT 團隊如何規劃生產變更感興趣。通常，我們使用操作手冊來佈局變更的關鍵步驟以及撤銷計劃。我很想知道我們是否可以向其他人學習以及如何最好地記錄操作手冊。
答案1
我更喜歡帶有註釋和列印的腳本。
他們具有文檔化和自動化的雙重優勢。
但是，採用更全面的方法，通常有很多事情需要跟踪，
腳本僅適用於需要按順序完成的事情。
當涉及很多註釋時，我更喜歡本地託管的 Wiki (個人的或者團體）。
它可以用來
- 透過連結引用您的工具並編寫快速註釋
- 列舉聯絡人和升級參考
- 根據關鍵字記錄緊急步驟
- 備份位置和還原順序
- 託管常規需求和解決方案的可搜尋記錄；所以人們在檢查完之後會來找你
但是，只要保證位置安全即可—您不希望在緊急情況下無法存取資料。
這裡有一個舊的Microsoft Technet SQL Server 操作手冊用於捕捉通用想法的頁面。
答案2
我做什麼：
所有需要從已安裝作業系統基線變更的伺服器配置均由 Chef 管理，這些配置儲存在模組（稱為說明書）中，然後透過 Git 儲存在版本控制中。
大多數配置都是在測試系統（通常是 VM 映像或簡單的 EC2 執行個體）上手動完成，然後編寫配置方案來涵蓋變更的所有個別元件。更新環境工作流程如下：
- 在需要進行更改的適當系統中建立票證。
- 記錄所有變更的原因和內容。
- 編輯在目標系統上進行更改所需的配置配方、範本、文件等。
- 將變更提交到本機儲存庫並推送到主版本控制伺服器。
- 更新票證以進行更改的同儕審查。
- 更改被簽署，更改被部署到 Chef 伺服器，以便它了解更新的位元。
- 在客戶端上手動執行 Chef，或根據更改的要求讓它自動運行。 （我不會手動運行超過六個系統）。
如果執行客戶端出現問題，例如套件不存在、找不到範本檔案或許多其他問題，Chef 的操作模式就會失敗。解決問題，記錄在票證中，然後重新運行客戶端。
具有更改業務需求的人員驗證更改是否成功，然後關閉票證。
廚師專用，因為那是我用的。為您的環境取代適當的工具，如果您沒有使用組態管理工具，則需要查看一些東西，因為它使整個過程更加健壯和可靠。更不用說可擴展性了。
答案3
對於真正關鍵和敏感的更改，我通常會擁有一個文字文件，其中包含我將使用的實際命令和 #comments 來解釋發生的情況。這樣，我可以快速將它們剪下並貼上到終端中。
答案4
我同意 jtimberman 貼文背後的基本想法，puppet 是我選擇的工具。