日本企業のITシステムは、「サイロ化」や「老朽化」などさまざまな問題を抱えています。特に旧来のシステムでは、業務のニーズや目的に合わせてシステムを開発した結果、運用保守の手順やルールが煩雑になっている例も見受けられます。また、コロナ禍の暫定処置として定めたルールが常態化してしまい、未だにアップデートされていない現場もあるでしょう。
これらは、運用保守コストの低減や安定稼働を妨げる要因のひとつでもあります。今回は、システム運用保守の現場でありがちなトラブルを挙げながら、その回避策としての手順書の価値について解説します。

手順書の質が悪く作業に遅滞が生ずる

システム運用において、手順書は非常に大きな存在です。新人担当者や赴任して間もないエンジニアにとっては、手順書こそがバイブルであり、行動指針となるはず。しかし、この手順書が正常にアップデートされていないと、彼らの「壁」になってしまうかもしれません。例えば、実際の作業で初めて発覚する以下のような間違いが、担当者の判断に迷いを生じさせます。

• 手順書上に記載されているファイル名と実際のファイル名が異なる
• ログインすべきサーバのIPアドレスやホスト名が違う
• コマンドラインのオプションが間違っている（戻り値が違う）

一般的に運用担当者は、「手順書に記載されていないことはやらない（もしくはエスカレーションする）」と教育されることが多いでしょう。そのため、手順書と実際の作業に齟齬があれば、その都度上位者に判断を仰ぐことになり、作業完了までの時間が延びてしまいます。

障害時は何をもって解決なのかが明確でない

昨今のシステムは分業化が進み、複数のサーバが異なる役割を持って稼働していることがほとんどです。また、物理/仮想サーバが入り乱れる環境では、障害の種類や復旧ラインも異なるため、「何をもって解決（ゴール）」なのかが明確になりにくいという問題があります。

一般的に障害対応では、障害内容によって異なる「復旧のライン」をクリアすることで顧客に復旧を報告します。具体的には、「このコマンドを入力し、プロセス数が○以下になれば解決」「CPUのロードアベレージが○%以下なら解決」など、定量的なラインが設けられているはずです。しかし、障害によってはこうしたラインが存在しないものもあります。

例えば、突発的に起こるサーバの物理障害の場合は、保守ベンダーに連絡した上で適宜パーツ交換作業を進めることになるでしょう。多くの場合、ベンダーが担うのは単体での動作確認と通常起動など、基本的な確認のみです。そのため、実際にサービスへ組み込める状態（=復旧）か否かは、自社で判断しなくてはなりません。

例えば「RAIDが正しく組めるか」「仮想サーバの立ち上げが正常に行えるか」など、故障したサーバの役割によって復旧ラインは異なります。全てのサーバが同一の役割を担っているわけではないので、個別に復旧ラインを明示しておく必要があるわけです。

開発部と運用部の認識違いで発生する手順書の齟齬

開発から運用までが連携する「DevOps」が叫ばれて久しいですが、開発と運用の間に溝がある企業はまだまだ少なくありません。一般的に開発と運用では、求められるスキルや知識の範囲が異なります。開発側からすれば「知っていて当然の知識」であっても、運用側からは「知らされていない情報」であることが少なくないのです。

例えば、開発側が作成した手順書に「管理画面からフル権限アカウントでログインして～」とだけ記載されていても、運用担当者は使用すべきアカウント情報を知らされていない場合があります。テストフェーズで作成したフル権限アカウントを指しているのか、個別に作成したアカウントを指しているのかわからないために、ログイン自体に時間がかかってしまうわけです。この場合は、アカウントIDを明示することで解決できますが、意外と単純なところで認識の齟齬が露呈してしまいます。

また「スキル水準が異なるために手順書の内容が不適切」といった問題も生じがちです。例えば、「AWSのマネジメントコンソールにログインしてEC2を操作する」といった開発側からすれば当たり前のスキルでも、普段AWSに触れることがない運用担当者には未知の領域です。

＜PR＞いざという時に備えて、適切な運用と保守管理でメンテナンスが必要なのは、手順書だって同じ。そのゆとりを生み出せるのが、統合運用管理サービス「UOM」です。詳しくはこちらへ

運用保守のトラブルを回避するための手順書とは

これらの、現場で発生しがちなトラブルを回避するには、やはり手順書（システム運用マニュアル）の整備が近道です。具体的には、以下のような事柄を意識して手順書をアップデートしていきましょう。

平時こそ小まめなチェックを

手順書は、初版のまま使われることはほとんどなく、数度のアップデートを経て成熟していきます。そのため、OSやOSSのバージョンアップ、サーバリプレイスといったイベントが発生した場合に加え、定期的なチェックも続けていくことが大切です。「常に実際の環境と比較し、見直し、検証する」という意識づけこそが、手順書の質を保つための最低条件です。

環境、条件をできるだけ明確にする

手順書ごとに「作業環境」「作業条件」を明確にすることで、作業ミスの発生やエスカレーションの手間を削減できます。

作業環境には「ログインURL」「管理画面のURL」「対象サーバ名（ホスト名）」など、実際に作業する舞台に関する情報が必要です。これに対して作業条件とは、「OSやアプリのバージョン」「アカウントの権限」など、作業を遂行するために最低限必要な要素を指します。

上記2つに加えて「想定するスキルレベル」に関する情報も付与しておくと、致命的なミスを防げます。「Linuxのログインやリブートなどを、コマンドラインのみで正常に行えること」「AWS上で、ansible-playbookを用いて構成管理ができること」など、作業ごとに必要とされるスキルレベルを明記しておきましょう。こうすることで、運用保守作業者が不足しているスキルや情報を自覚し、効率よく自己研鑽を積むきっかけになるでしょう。

ストーリー性を持たせるためのOJTも

エンジニアの中には、手順書には数値や文字列、操作順などの事実関係を正確に列挙していけばOKで、別に工夫する必要はほとんどないと誤解している人もいます。しかし、わかりにくい手順書は、「全体として何がしたいのか」「ゴールは何か」かが読み取りにくいものです。逆にストーリー性がある手順書は読み手の認知負荷を下げるだけでなく、「今自分が何をしていて、どこを目指すべきなのか」が分かりやすくなっています。
ストーリー性を持たせる方法としては、「全体の構成図を記載する」「復旧までのロードマップを全ページに配置する」などが挙げられるでしょう。実は、新人エンジニアを教育する上で不可欠な要素も、ストーリー性です。RPGをプレイする主人公キャラクターのように、成長過程の記録そのものが、「冒険の書」としての手順書のアップデートを兼ねます。

「情報格差を減らす手順書」でトラブルを防止！

運用保守フェーズでのトラブルは、その多くが「情報格差」によって生まれます。開発と運用の情報格差、運用（1次対応）と保守（2次対応）の情報格差など、意外と落とし穴は多いのです。

毎日が忙しいシステム運用や保守のエンジニアは、手順書のアップデートまで手が回らないのが現実だと思います。しかし、情報格差は「抜け」や「漏れ」として手順書内にあらわれ、トラブルの原因になります。裏を返せば、「書き手と読み手の情報格差を減らす」という視点で手順書を作成・編集していくことで、運用保守のトラブルは大きく減らすことができるはずです。DXを見据えた「攻めのシステム運用」が求められる今だからこそ、手順書を定期的に見直していきましょう。

＜PR＞重要な手順書も、忙しくて確認や更新の時間がない！後回しでさらに使えなくなっていく…。だったら、システム運用全体をラクにする統合運用管理サービス「UOM」！詳しくはこちらへ