
この記事の要点
- 資料が古くなるのは、環境を変える手続きと、資料を直す手続きが別になっているからです。変更の手続きの中に、資料の更新を組み込みます。
- 構成は、実際の環境の記録や、基盤を作るコードから確かめられるようにし、人が描く図は全体を説明するものに絞ります。
- 手順書は1か所に置き、持ち主を決め、別の人が実行して確かめます。障害や変更の記録も、同じ置き場所で後からたどれるようにします。
構成図や手順書を「生きた資料」にするとは、資料が実際の環境と同じ状態に保たれ、担当が替わっても、その資料だけで運用を引き継げる状態にしておくことです。そのためには、資料をきれいに作ることより、環境を変えるたびに資料も一緒に直る仕組みをつくることが大切です。
資料は、なぜ古くなるのか
資料が古くなるのは、環境を変える作業と、資料を直す作業が、別々に行われているからです。急ぎの変更を先に済ませ、資料は後で直すつもりのまま残る、ということがくり返されると、資料と環境の差は広がっていきます。
AWS の Well-Architected の運用の柱は、手順書(ランブック)について避けるべき例として、記憶に頼って作業を進めること、同じ作業を人によって違う手順で行うこと、システムの変更や自動化に合わせて手順書を直さずに、ずれたままにしておくことを挙げています。
出典:OPS07-BP03 Use runbooks to perform procedures(AWS)
古い資料は、資料がないより困ることがあります。障害のときに資料を信じて作業し、実際の構成と違っていたために、復旧が遅れるおそれがあるからです。
残しておく資料
クラウドの運用で残しておく資料は、おおむね次のとおりです。すべてを細かく書くより、引き継ぎと障害のときに困らないことを基準に、必要なものから整えます。
| 資料 | 内容 | 主に使う場面 |
|---|---|---|
| 全体の構成図 | システムの役割、つながる先、データの流れ | 引き継ぎ、変更の影響の確認 |
| 設定の一覧 | アカウント、ネットワーク、主な設定の値 | 障害の調査、点検 |
| 手順書 | 定期の作業、障害のときの作業、戻す手順 | 日々の運用、障害の対応 |
| 連絡先と役割 | 担当、外部の会社、事業者の窓口、判断する人 | 障害のとき |
| 変更と障害の記録 | いつ、誰が、何を、なぜ変えたか。障害の経過と対策 | 原因の調査、再発の防止、監査 |
手順書の役割はランブックの用語の説明でも整理しています。
構成は、実際の環境とコードから確かめる
設定の値のように細かく変わる情報は、人が書き写すのではなく、実際の環境の記録やコードから確かめられるようにします。
AWS Config は、アカウントの中にどのような資源があり、どう設定されているかを詳しく見られる仕組みです。過去の設定の履歴を残し、問題のあった資源の、直近の正常な設定を確かめることもできます。また、変えようとする資源がほかの資源とどうつながっているかを見て、変更の影響を確かめられる、と説明されています。
基盤をコードで作る方法(Infrastructure as Code)を使っている場合は、コードそのものが構成の記録になります。Microsoft Azure の Well-Architected は、基盤の変更(設定の変更を含む)は、コードを通じてだけ行う、という厳格な決まりを持つことを勧めています。コードを通さない変更が混ざると、コードと実際の環境がずれていきます。
出典:Architecture strategies for using infrastructure as code(Microsoft Learn)
コード化の考え方は、インフラのコード化(IaC)とはで説明しています。人が描く全体の構成図は、細部を書き込むより、役割とつながりが分かることを優先します。細部は、上の記録やコードを見に行けばよい形にしておくと、図を直す頻度が下がります。
変更の手続きの中で、資料を直す
資料を生きたままにする決まりは、変更の手続きの中に、資料の更新を入れることです。
同じ AWS の運用の柱は、手順書には期待する結果と、必要な権限や道具、うまくいかないときの対応と連絡先を書き、持ち主を決めて1か所に公開すること、書いたら別の人に実行してもらって確かめること、手順が変わったら変更の手続きに沿って直すことを勧めています。置き場所がまだなければ、変更の履歴を残せる場所(バージョン管理)から始めるとよい、としています。
出典:OPS07-BP03 Use runbooks to perform procedures(AWS)
手順が変わったときに、手順書を直す流れ
- 直す手順が変わったら、変更の手続きに沿って手順書を直す
- 書く中身期待する結果、必要な権限や道具、うまくいかないときの対応と連絡先
- 確かめる別の人に実行してもらい、手順書だけで進められるかを確かめる
- 公開する持ち主を決め、1か所(変更の履歴を残せる場所)に置く
変更の申請の書式に「直した資料」の欄を設け、空のままでは変更を終えられないようにするのも、手軽な方法の一つです。
運用の記録を残す
運用の記録は、後から「なぜこうなっているのか」をたどるための資料です。変更の記録には、何を変えたかだけでなく、なぜ変えたかを書きます。理由が残っていないと、後の担当が設定を元に戻してよいのか判断できません。
障害の記録には、経過、影響の範囲、原因、とった対策、残っている課題を書きます。毎月の報告は、その月の変更と障害、監視の傾向、次の月に行うことをまとめ、同じ置き場所に残します。こうした記録は、担当が替わるときの引き継ぎや、上場の準備などで管理の状況を説明するときにも使えます。障害のときの動き方は障害が起きたときの一次対応で説明しています。
当社のご支援
アメリア・テクノロジーのクラウドの構築と運用管理では、いまの環境の調査にもとづく構成図と設定の一覧の作成、手順書の整備、変更の手続きに資料の更新を組み込む決まりづくりをご支援しています。運用管理の月額の中で、変更と障害の記録と月次の報告をお渡しします。いまの資料の状況は、無料のクラウドの自己診断でもおおまかに確かめられます。
- クラウド
- 運用管理
- 手順書
- ドキュメント
この記事に出てくる用語
- AWS(Amazon Web Services)
- Well-Architected Framework
- 運用手順書(ランブック)
- クラウド
- Infrastructure as Code(IaC)
- Microsoft Azure
- Git(バージョン管理)
- 監視
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。