某所で見かけたシステム運用作業手順書の記事に、「作業直前に作業手順書の変更はしない」「手順書に無い作業をしない」といった事が書かれていました。
いや、それはあくまで心掛けの話であって、それも大事だけど、そもそも作業手順書はどうあるべきかという話が抜けおちているのではないか？それは世間ではあまり明文化されていないのではないか？と思いました。
不遜ながら、私が思う作業手順書のあり方を書いてみます。
1. 存在している
まさか、本番作業を勘とノリでやっちゃうなんて。まさかね…
2. 保存されている
Githubでも、Google Driveでも、Notionでも、Wikiでもいいですが、作業手順書は保管されていますね？えっ？保存していなかったら、同じような作業をもう１回することになったらどうなるんですか？障害が起きて、デプロイ手順に問題がなかったか調査したい時にどうするんですか？
なお、保存するなら、特別な理由が無い限り、Opsチームの他メンバーや開発エンジニアやQAエンジニアも閲覧可能にしましょう。改善活動のネタにつながるかもしれません。いや、つながらないかもしれないが、閲覧可能にすること自体はタダです。
生のパスワードが書かれているって？それは別の問題…
3. レビューされている
自分が書いた手順書に間違いが無いか、見落とした手順が無いか、心配になりませんか？心配になりますよね？「全く心配にならない私は完全無欠だ！」ですって？
ベテランでもミスをゼロにはできません。多数の目玉を通すことでミスを防ぎます。
また、レビューでの指摘を通じてチーム内でのノウハウが共有されます。レビューを受ける側も「自分用のメモ」ではなく「他人にも読める文章」を書かなければならないため、明快な文章を書く能力が鍛えられます。
4. テストされている
本番環境を変更する前に、本番同様の「ステージング環境」でも同じ作業を実施します。
なおここでいう「ステージング環境」は社内に複数設けることもできます。例えば、Dev向けの環境とOps向けの環境を別に用意したり、Ops向けの環境を複数（人数分）用意することも考えられます。
また、例えば本番がサーバー10台の構成だからといって、ステージング環境も10台構成にしなければならないとは限りません。「複数台のサーバーを同時に操作すること」をテストしたいだけなら、2・3台でも十分かもしれません。
5. 出力は全て記録する
コマンドの出力はすべて記録します。これも後で調査できるようにするためです。そして、手順書では出力＆記録の方法も決めておかなければなりません。
ターミナルに表示された内容をいちいちコピーするのは煩雑です。例えばiTerm2にはログを自動で保存する機能があります。
また、出力が膨大になって記録しきれない場合は、そもそも出力の仕方が悪いのかもしれません。そんな記録できないほどの出力を人間が目で見て確認できるはずがありません。うまくフィルタリングしましょう。
6. コピペで実行できる
システム運用作業は速さと正確さが命です。
判断するということは、判断に要するタイムロスが発生してしまうということです。また、判断の質はその人の知識や経験に左右されますから、作業者によっては誤った判断をしてしまうおそれがあります。
作業に必要な情報は全て書きましょう。URLを書きましょう。監視デーモンを一時停止するコマンドも書きましょう。最後に作業端末からログオフする指示も書きましょう。
なお、作業内容によっては実行するまで不確定な部分があることもありますが、想定ケースと対処方法を一覧表にしておきましょう。
7. 結果を確認するステップが設けられている
「判断させない」に関連していますが、確認を作業者の自主性に任せるのではなく、確認するステップを設けます。
一般的には、ログインした時にサーバーのIPアドレスを確認したり、デプロイ後にログの出力を確認したりします。
このとき、例えば「ログが正しいこと」ではなく、具体的に
- そのログを取得する方法（CLIコマンド）
- 期待されるログの内容
- 特に問題が起きそうな部分・今回の変更の影響を受ける部分
などを示します。確認を目視だけではなく、プログラムによって自動的に行えればなお良いでしょう。
8. 問題発生時の応急処置が指示されている
ファイルを消してしまう等の誤操作をした時や、サービスに異常が起きたときなどの、応急処置を指示します。
- 右手を高々と上げ、「メーデー！」と３回叫ぶ
- サービスをメンテナンスモードに切り替える
- 前のバージョンをデプロイする
なお、この手順は「問題を解決する」というよりは「システムを安定した状態にする」ことや「トラブルを拡大しないこと」を重視するべきです。
また、こういった応急処置はある程度定型化できるので、個別の手順書にいちいち書く必要は無いかもしれませんが、いざという時アクセスできるようURLを書いておくべきです。手順の最初に「リカバリ手順を復習する」というステップを設けても良いかもしれません。
9. 自動化されている
「誰でも実行できる明確な手順書」は次第に「実行可能な手順書」に近づいていきます。
terraformやJenkinsなどのツールを学習し、自社環境用にコードを作り込むのは大変なことですが、一度作ればすぐに元を取れるはずです。
むすび
名著 SQLアンチパターンに「外交特権」という、DBやSQLを職人芸扱いしてバージョン管理やテストをしないアンチパターンが紹介されていました。
システム運用も職人芸扱いされるきらいがあります。「作業直前に作業手順書の変更はしない」のような心掛けに、職人芸で満足してしまう風潮を感じ取り、深夜テンションでついカッとなって書いてしまいました。
むすび（追記）
しばらくして読み返したら、結局のところこの文章で言いたかったのは「インフラエンジニアにとっても『言語化する能力』は重要だ」ということだと思いました。
職人的勘だけでは、どこかで天井にぶつかります。
作業内容を文章に書き出すことは、見落としを客観的に検証したり、後輩を教育したり、自動化したりするといった、新たな次元に進む足がかりになります。