システム管理業務における課題
システム管理業務は、その性格上、操作ミスや誤操作、あるいは不正操作がシステム障害などを招きかねない大きなリスクをはらんでいます。
情報システム管理者は、チェック体制の強化など日々細心の注意を払いながら、事故防止に取り組んでいます。しかしそれでも操作ミスや誤操作によるシステムトラブルや情報漏えいは後を絶ちません。
従来の手順書によるアプローチ
従来の手順書の限界
ミスを防止し、作業品質の向上を図る一般的な方法は手順書の整備です。作業の詳細について、誰もが理解できるよう作業ステップ、確認内容など詳しく手順にすることで、ある程度、ミスを減らすことが可能になります。しかし、従来の文書ベースでの手順書では、以下の点で課題が残ります。
手順書を維持管理する負荷・手間
誰が見ても理解できる分かりやすい手順書の作成・維持管理には工数がかかります。たとえばWindowsサーバーに対する作業を分かりやすく説明するには、画面キャプチャーなどをコピーして操作内容を視覚的に示すなどの必要があります。
最初に整備する時点では、工数を割いて手順書を作成しても、細かな変更が発生するたびに修正作業が必要です。そういった手順書の整備や維持管理には、かなりの負荷が発生します。
手順書通りに作業するかは、作業者の能力やコンディションに依存
分かりやすい手順書を作成しても、その通りに実施できるかどうかは最終的には人の問題になります。たとえ複雑なコマンドを正確に手順書に記述していても、その通りに操作しなければ、正しい作業を実行できません。ましてや意図的に予定外の操作を行おうとする者に対し、手順書はそれを防止する強制力を持ちません。
報告作業の負荷とリスク
システム管理作業では、作業結果を報告書を通して提出し、管理者や監査者によってチェックを受けることで、二重・三重の品質チェックを行う場合があります。この報告書の作成負荷は、企業によっては実際の作業時間以上に時間をかける必要があるなど、負担の一因にもなっています。 また、報告書は行った作業をすべて網羅的に記述する必要がありますが、作業者が意図的に不正作業を行った内容を報告書に記載しないといったリスクも懸念点となります。
手順書管理で陥りがちな状況
最終的に手順書による管理で陥る状況としては、せっかく整備した手順書が、実態が変更される度に反映されず実態とかい離してしまい、いつしか誰も参照しなくなってしまうといった状況です。
特に運用現場では、仕事に慣れ、より早く業務を実施するためには、手順書の内容を覚えることが必要です。手順書を参照せず実施しているうちに、本来重要なチェック箇所に注意がいかず、最終的に実際に行われる手順では省かれてしまう場合などもリスクとして想定されます。
完全自動化のアプローチ
一方で、人が実施することにより問題が発生するのであれば、人の介在をなくすというアプローチも考えられる方向性です。
運用管理の業務について、このような自動化を行う製品も実在します。しかし弊社では、この自動化のアプローチにも大きな落とし穴があるのではないかと考えています。
自動化シナリオのテスト・検証作業
これまで人によって結果を確認しながら進めていた業務を自動化するためには、人が行っていた確認作業を判別するよう完全に網羅されたロジックを確立する必要があります。人の操作の場合、手順書に誤りがあったとしても、その手順に従わず、臨機応変に作業を行うことができますが、自動化シナリオに瑕疵があることは許容されません。
したがって自動化を実現するためには、手順書の整備以上に、そのシナリオの正しさを繰り返しテストして検証する必要があります。
業務のブラックボックス化
これまで人によって行われてきた作業を自動化すると、業務内容は隠ぺいされて、結果だけが見える形になります。通常であれば問題は起きないのですが、システムに変更が発生した場合、自動化されている業務の内容に精通していないと、変更に伴う影響範囲が見えなくなってしまいます。特に自動化を実施した担当者が、異動により現場を離れた後などにそのような状況に陥りがちです。
システム変更後、自動化されたシステムから想定外のエラーが続出するなどといった状況にならないためには、自動化されていても、その処理内容が見える状態にしておく必要があります。
また極端な自動化は、非常時の対応の弱さにもつながります。災害発生時など、一部のシステムが稼働しないなど、通常と異なる状況において、通常は自動化されていた業務を手作業で行う必要が生じる可能性もあります。そのような時、あなたの企業の現場責任者は、うまく対応できるでしょうか?
変更への対応
初回自動化環境を構築したときと同様に、システム環境の変化によって、自動化された業務シナリオの変更が発生するたび、テスト検証作業を行う必要があります。
昨今、ビジネス環境の変化に合わせてシステム変更の頻度は上がってきており、自動化された部分の維持管理の負荷は、ますます高くなるものと想定されます。
ESS AutoQuality のActive RunBookコンセプト
弊社では、従来の手順書の課題を克服し、完全な自動化の問題点を排除した、まったく新しい手順書コンセプト「Active RunBook」を提唱、ESS AutoQualityを発表しました。
リハーサル結果が手順書になる
多くの場合、リハーサル環境にてリリース手順を実行して正しいリリース作業手順を確立します。このリハーサル環境での操作内容を記録しておけば、手順書作成がより効率的に行えます。
また、人がマニュアルで行う操作をそのまま手順書にするため、ブラックボックス化せず、必要に応じていつでもマニュアルで操作することも可能です。
実行可能である
ドキュメントベースの手順書との大きな違いは、実行可能な手順書であること。複雑なコマンド入力など手順書を見ながら人が操作することで起きてしまう問題を、手順書自らが正確に実行することで、問題発生を防止します。
また、手順以外に操作した内容も含め記録され、操作者によって意図的に報告書から削除することができないため、意図的な不正操作への対応にもつながります。
常に最新な状態である
結果として得られる最大のメリット、それは実態とかい離しない、常に最新の状態の手順書を維持できることです。Active RunBookは、それ自体を実行する形式の手順書であるため、変更された手続きを手順書に反映しなければなりません。文書化の最大の課題は、作成した時点と手続きが変更になっても、文書への反映がなおざりになり、実態とかい離した状態になってしまうことで、知っている人だけが実施できる属人的な業務遂行から脱却できないことです。