手順書を直すことも、インフラエンジニアの仕事

こんにちは。グロトムの堀口夏希です。

前回は、アラートを受けた後の原因調査について考えました。今回は、その仕事をチームで支える「手順書」がテーマです。

手順書の価値は、操作の順番が書いてあることだけではありません。担当者が交代しても、必要な判断や確認を共有できることにもあります。この記事では、特定の顧客案件の事例ではなく、運用の仕事を考えるための例を紹介します。

操作が同じでも、判断がそろうとは限らない

たとえば、「ログを確認し、問題がなければ次へ進む」と書かれている手順を考えてみます。

どのログの、どの時間帯を見るのか。「問題がない」と判断できるのは、どのような状態なのか。経験のある人には分かっていても、初めて担当する人や久しぶりに対応する人は迷うかもしれません。

手順書を見直すときは、「作業者が何を判断しなければならないか」に目を向けると、補うべき情報が見えてきます。

「実行前・実行中・実行後」で見直す

確認するポイントを、三つの段階に分けてみます。

実行前

対象の環境やサーバー、作業の目的、必要な権限、承認の有無、影響範囲を確認できるか。作業を始めてよい条件が分かるか。

実行中

操作ごとの期待結果と、想定と違う結果になった場合の判断先が分かるか。中断すべき条件や、相談先が明確か。

実行後

何をもって完了とするか。稼働確認の方法、残す記録、関係者への報告内容が分かるか。切り戻しが必要な場合の手順につながっているか。

すべてを長い文章にする必要はありません。現場のルールに沿って、判断に必要な情報を探しやすくすることが大切です。

書き換えて終わりにしない

手順を更新したら、変更理由と変更箇所を残し、関係者のレビューを受けます。検証環境などで確認できる内容は、確認した条件や結果も記録します。

実施時に「ここで迷った」「この確認が役立った」という点があれば、次の見直しにつなげる。対象環境や設定が変わったときに、関連する手順も見直せるようにしておく。

手順書は、書いた時点の完成品というより、運用の変化と一緒に手入れしていくものだと考えています。

日々の疑問が、改善の入口になる

「毎回同じ問い合わせが発生する」
「特定の人に聞かないと判断できない」
「作業は終わったのに、完了の確認に時間がかかる」

こうした疑問を、そのままにせず整理してみる。背景を確かめ、小さな変更案を出し、チームで確認して取り入れる。その積み重ねも、インフラエンジニアの仕事の一つです。

自動化を考える際にも、入力条件、期待結果、例外時の対応が整理されていると、何を自動化し、どこに人の判断を残すかを検討しやすくなります。

運用を続けながら、運用を良くしていく

グロトムのインフラ募集で検討している参画候補には、監視オペレーター向けの指示書・手順書の作成、変更・リリースに伴う手順の整備やレビュー、運用上の改善提案などが含まれます。

担当範囲は経験や参画先によって異なります。「手順の曖昧な部分を整理した」「繰り返し起きる問題への対応を見直した」といった経験も、ぜひ聞かせてください。