search
LoginSignup
622
Help us understand the problem. What are the problem?

posted at

updated at

僕が考えた最強の作業手順書

某所で見かけたシステム運用作業手順書の記事に、「作業直前に作業手順書の変更はしない」「手順書に無い作業をしない」といった事が書かれていました。

いや、それはあくまで心掛けの話であって、それも大事だけど、そもそも作業手順書はどうあるべきかという話が抜けおちているのではないか?それは世間ではあまり明文化されていないのではないか?と思いました。

不遜ながら、私が思う作業手順書のあり方を書いてみます。

1. 存在している

まさか、本番作業を勘とノリでやっちゃうなんて。まさかね…

2. 保存されている

Githubでも、Google Driveでも、Notionでも、Wikiでもいいですが、作業手順書は保管されていますね?えっ?保存していなかったら、同じような作業をもう1回することになったらどうなるんですか?障害が起きて、デプロイ手順に問題がないか調査したい時にどうするんですか?

なお、保存するなら、特別な理由が無い限り、Opsチームの他メンバーや開発エンジニアやQAエンジニアも閲覧可能にしましょう。改善活動のネタにつながるかもしれません。いや、つながらないかもしれないが、閲覧可能にすること自体はタダです。

生のパスワードが書かれているって?それは別の問題…

3. レビューされている

自分が書いた手順書に間違いが無いか、見落とした手順が無いか、心配になりませんか?心配になりますよね?「全く心配にならない私は完全無欠だ!」ですって?

ミスは新人の方が多いとは言え、ベテランでもミスをゼロにはできません。多数の目玉を通すことでミスを防ぎます。

また、開発でも言われることですが、レビューの効用はミス防止だけではありません。レビューでの指摘を通じてチーム内でのノウハウが共有されます。「自分用のメモ」ではなく「他人にも読める文章」を書かなければならないため、正確かつ明確に表現する能力が鍛えられます。

4. テストされている

内容にもよりますが、本番環境を変更する前に、本番同様のステージング環境でも同じ作業を実施します。

なお、意外と見落とされがちな観点ですが、ここで言う「ステージング環境」は1つである必要はありません。例えば、Dev向けの環境とOps向けの環境を別に用意したり、Ops向けの環境を複数(人数分)用意することも考えられます。

また、本番がサーバー100台だからといって、ステージング環境も100台用意しなければならないとは限りません。「複数台のサーバーを同時に操作すること」をテストしたいなら、サーバーは3台で十分かもしれません。

5. 出力は全て記録する

「作業手順書」そのものの話ではありませんが、コマンドの出力はすべて記録します。これも後で調査できるようにするためです。

ターミナルに表示された内容をいちいちコピーするのは煩雑です。例えばiTerm2にはログを自動で保存する機能があります。

また、出力が膨大になって記録しきれない場合は、そもそも出力の仕方が悪いのかもしれません。そんな記録できないほどの出力を人間が目で見て確認できるはずがありません。うまくフィルタを使って出力を絞りましょう。

6. コピペで実行できる

システム運用作業は速さと正確さが命です。

判断するということは、判断に要するタイムロスが発生してしまうということです。また、判断の質はその人の知識や経験に左右されます。

作業に必要な情報は全て書きましょう。作業者が知らなかったり、うっかりド忘れということもありえます。URLは全部書きましょう。監視デーモンを一時停止するコマンドも書きましょう。最後に作業端末からログオフする指示も書きましょう。

また、作業内容によっては実行するまで不確定な部分もあるかも知れません。その場合も、想定ケースと対処方法を一覧表にしておきましょう。

7. 確認ステップが設けられている

「判断させない」に関連していますが、確認を作業者の自主性に任せるのではなく、確認するステップを設けます。

一般的には、ログインした時にサーバーのIPアドレスを確認したり、デプロイ後にログの出力を確認したりします。

このとき、例えば「ログが正しいこと」ではなく、具体的に

  • そのログを取得する方法(CLIコマンド)
  • 期待されるログの内容
  • 特に問題が起きそうな部分・今回の変更の影響を受ける部分

などを示します。確認を目視だけではなく機械的に行えればなお良いでしょう。

8. 問題発生時の応急処置が指示されている

ファイルを消してしまう等の誤操作をした時や、誤操作をしていなくともサービスに異常が起きた時の、応急処置を指示します。

この応急処置は「問題を解決する方法」ではなく「問題をこれ以上広げない方法」であるべきです。例えば、このような処置です。

  • サーバーをフリートから切り離したまま、作業を中止する
  • 前のバージョンをデプロイする
  • サービスをメンテナンスモードに切り替える

なお、こういった応急処置はある程度は定型化できるので、個別の手順書にいちいち書く必要は無いかもしれませんが、いざという時に閲覧しやすいよう手順書にURLを書いておくべきですし、手順の最初に「リカバリ手順を復習する」というステップを設けても良いかもしれません。

9. 自動化されている

上で書いてきたポイントは、コード化・自動化することで解決するものです。手順・確認内容を明確化していけば「実行可能な手順書」との垣根は低くなっていきます。

terraformやJenkinsなどのツールを学び、自社環境用にコードを作り込むのは大変なことですが、一度作ればすぐに元を取れるはずです。また、今自動化が難しい複雑な作業も、それを可能にするツールが近い将来登場するかもしれません。

むすび

名著 SQLアンチパターンに「外交特権」という、DBやSQLを職人芸扱いしてバージョン管理やテストをしないアンチパターンが紹介されていました。

システム運用も職人芸扱いされるきらいがあります。「作業直前に作業手順書の変更はしない」のような精神論に、職人芸で満足してしまう風潮を感じ取り、深夜テンションでついカッとなって書いてしまいました。

むすび(追記)

しばらくして読み返したら、結局のところこの文章で言いたかったのは「インフラエンジニアにとっても『言語化する能力』は重要だ」ということだと思いました。

職人的勘だけでは、どこかで天井にぶつかります。
作業内容を文章に書き出すことは、見落としを客観的に検証したり、後輩を教育したり、自動化したりするといった、新たな次元に進む足がかりになります。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
622
Help us understand the problem. What are the problem?