私は、IT チームが本番環境の変更計画にどのように取り組んでいるかに常に興味を持っています。通常、変更の主要な手順とバックアウト プランをレイアウトするためにランブックを使用します。他のチームから学べるかどうか、またランブックを最も効果的に文書化する方法について知りたいと思います。
答え1
私はコメントとプリント付きのスクリプトを好みます。
それらは文書化と自動化の二重の利点があります。
しかし、より総合的なアプローチをとると、通常は追跡すべきことがたくさんあり、
スクリプトは順番に実行する必要があるものに対してのみ使用されます。
大量のメモが含まれる場合は、ローカルでホストされているWiki（個人的またはグループ
）。
- リンクを使ってツールを参照し、簡単なメモを書く
- 連絡先とエスカレーションの参照を列挙する
- キーワードに基づいて緊急時の手順を文書化する
- バックアップ場所とリカバリシーケンス
- 定期的な要件とソリューションの検索可能な記録をホストします。人々はそれを確認した後にあなたに連絡します。
ただし、場所を安全な状態に保ってください。緊急時にデータにアクセスできなくなるのは避けたいものです。
これは古いMicrosoft Technet SQL Server ランブック一般的なアイデアをキャッチするためのページ。
答え2
私がやること：
インストールされた OS ベースラインから変更する必要があるすべてのサーバー構成は Chef によって管理され、モジュール (クックブックと呼ばれる) に保存され、Git を介してバージョン管理に保存されます。
ほとんどの構成はテスト システム (多くの場合、VM イメージまたは単純な EC2 インスタンス) で手動で行われ、その後、変更のさまざまなコンポーネントをすべてカバーするように構成レシピが作成されました。環境の更新ワークフローは次のようになります。
- 変更が必要な適切なシステムにチケットを作成します。
- 変更の理由と内容をすべて文書化します。
- ターゲット システムで変更を適用するために必要な構成レシピ、テンプレート、ファイルなどを編集します。
- 変更をローカル リポジトリにコミットし、マスター バージョン管理サーバーにプッシュします。
- 変更のピアレビューのためにチケットを更新します。
- 変更は承認され、その変更は Chef サーバーにデプロイされ、更新されたビットが認識されるようになります。
- クライアント上で Chef を手動で実行するか、変更の要件に応じて自動的に実行します (手動では、6 つ以上のシステムでは実行しません)。
Chef の動作モードでは、パッケージが存在しない、テンプレート ファイルが見つからない、その他多くの問題など、クライアントの実行中に問題が発生すると失敗します。問題を修正し、チケットに記録してから、クライアントを再実行します。
変更のビジネス要件を持つ担当者は、変更が成功したことを確認し、チケットをクローズします。
私が使用しているのは Chef なので、Chef に特化しています。環境に適したツールに置き換えてください。構成管理ツールを使用していない場合は、何かを検討する必要があります。そうすることで、プロセス全体がより堅牢で信頼性が高くなります。言うまでもなく、スケーラブルです。
答え3
本当に重要で繊細な変更の場合、私は通常、実際に使用するコマンドと、何が起こっているかを説明する #comments を記載したテキスト ファイルを用意します。こうすることで、それらをターミナルにすばやくカット アンド ペーストできます。
答え4
私は jtimberman の投稿の背後にある基本的な考え方に賛成し、puppet をツールとして選びます。