現日常のIT保守運用＜稼働・障害・保守＞マネジメントの手法

日常におけるIT稼働・障害・保守とは

ITの稼働、障害ならびに保守とは、それぞれ別なものですので、それぞれマネジメントされるべきことです。

広い意味ではITが安定して稼働していることを維持するのが目的ですので、一括りとしてここでは説明します。

稼働とは

稼働とは、文字通りITが正しく動いていることです。ITはハードウェア、ソフトウェア、ネットワーク、プログラムモジュールといった作られたもので構成されています。

動いているという意味では、さらに広くとらえる必要があります。というのは、データ、ユーザ、オペレータというものも捉えてITということになります。

これらのITの構成要素は、すべてITの稼働に影響を及ぼします。

正しく動かす意味でも影響を及ぼしますし、エラーを起こす意味でも影響を及ぼします。

稼働が正しい度合としては稼働率のような指標があります。これは主にハードウェアなどの機械の部分での不具合で稼働できなかったものを差し引いた正常の度合いです。しかし広義の意味では、その他の要素、すなわちプログラムモジュール、データ、ユーザ、オペレータによる不具合も稼働を停止させる可能性がありますので、それらの原因による非稼働についても実際は、稼働率に影響します。

稼働率に影響するようなものがもしわかっているのであれば、予め監視しておきたいところです。

ITにおける障害とは

障害はITが正しく動作しなかった事象となります。よって先に説明した要素がすべて原因になり得ます。

障害には原因があり、原因が事象となって現れます。事象はITが正しく動いていないことから、利用に対して影響を及ぼします。

影響は、IT全体がストップしてしまうようなこともあれば、一つの機能の極めてレアなケースのみに影響するものもあります。

障害は影響の大小により優先度は変わってくるものの、事象、原因、影響、利用などについて状況を正しく認識して対処してく必要があります。

障害と不具合の違いとは

ちなみにIT界隈では不具合という言葉もよく出てきます。不具合もITが正しく動いていないという認識なので、同じことを言っているかのように見えます。しかし実際には違います。

不具合とはITが正しく動いていないと認識されたものです。

やっぱり同じことでは？と思ってしまいますが、認識されたというところがポイントであり、認識されただけであり、実際は不具合ではなかったというものも含まれます。

不具合は利用においてある意味不都合なわけですから、何らかの対処は必要です。

ユーザのITマネジメントとしては、不具合も見逃すわけにはいきません。それはビジネスに影響する可能性があるからです。よって、同じように重要度を考慮したうえで、対処が必要な場合はするというマネジメントが必要です。

保守とは

保守は稼働しているITに対して、何らか手を加えることになります。

保守の目的は様々です。実施に至る起因から考えるとわかりやすいです。

ユーザ要求起因、障害後対応起因、障害前対応起因といったものになります。

ユーザ要求に関しては、大小様々な要求があります。かなり大きな影響のものであれば、保守ではありますが、一つの大きなプロジェクトとして実行されることもあるでしょう。

障害後対応というのは、障害が起きたことに対して修正を行うことを示します。

障害前対応というのは、予防保守と呼ばれるもので、障害が起きるとわかっていることに対して、事前に修正を行うことになります。

IT稼働・障害・保守のマネジメントとは

IT稼働マネジメントとは

IT稼働マネジメントとは、ITが正しく動いている状態を保つためにマネジメントすることです。

まずはITが正しく動かなくなる起因となるものを認識します。次に重要な要素を見出します。そして重要な要素に対して監視します。

事前に監視に対して対処できることは実施します。

既に非稼働が起きてしまったものに対しても、またその状態が起きないように修正されるまで監視します。

IT障害マネジメントとは

障害は予めわかっているものも稀にありますが、大抵は突然起きます。

突然起きることに対してマネジメントすることは、非常に難しいものではありますが、何がわかるかはわからないにしても、どうするかは決めておいたほうがよいでしょう。

そして、突然起きた障害に対しては、決めた段取りに則り対処し、稼働を保ちます。

一旦稼働を保ったとしても、応急処置であることが多いです。よって完全化措置としての恒久対応を実施していくことになります。

さらに障害に対し似たような状況下にある他のITや機能もあったりしますから、それらに対しては未然防止策を打ちます。

これら一連の対応がきちんとできているかをマネジメントしていくということになります。

IT保守マネジメントとは

保守は、ユーザ要求起因、障害後対応起因、障害前対応起因からくると説明しました。

この内、ユーザ要求起因については、変更要求案件マネジメントとして別に詳しく説明します。

保守の実行起因となり得るものとしては、機械的ものから人的なものまであります。構築されたプログラムのみがITかというとそういうわけではなく、広く捉える必要があります。

そして、障害や不具合などでの稼働影響への対策として、事前なのか事後なのかを踏まえて、全体としてマネジメントします。

起因となるもの	事後対策例	事前対策例
ユーザ	ユーザの誤操作による不具合を改善	操作マニュアルの充実
データ	連携データエラーの改善	データエラーチェックの厳密化対応
オペレータ	作業手順書の改善	作業指示フローの改善
プログラムモジュール	恒久対策の実行	オーバーフローへの事前対策
ネットワーク	ネットワーク機器保守	リソース監視にる対策
ソフトウェア	バグによる障害復旧対応	メーカーパッチ適用
ハードウェア	故障による復旧	リソース増強

一つひとつの実施していることが、実行されていることと計画どおり進んでいることをマネジメントとして確認し、滞っているものがあれば、リスクに応じてテコ入れなどで対策します。

IT障害・不具合・トラブル発生時の対処方法とステップ

障害と不具合とトラブルと併記しましたが、これらは似たようで少し違います。ただ、ここで定義することよりも、何らか利用や稼働に影響しているという意味では同じですので、発生からの動きとしては同様に扱います。

インシデントなどとも言われます。

インシデントは突然起きます。

その場から何らかの対処が必要となります。初動はとても重要で、その後の影響に大きく響きます。
事象の発生からの流れはこうなります。

NO	行動	解説
1	検知	ITの監視から、あるいはエンドユーザ問い合わせ等より認識する。
2	影響調査	影響の広がりを調査する。必要に応じて調査できる人を収集し、指示する。
3	初動判断	影響に応じて対処レベルを決め、初動を判断する。
4	関係者通知	対処レベルに応じた通知を行う。経営やユーザなど影響に応じて通知するとともに、必要の応じて5と6を行う。
5	原因調査	２の状況から原因を探る。
6	応急処置の実施	対処可能な処置があれば実施する。対処がなければ影響が広がる可能性がある。
7	復旧方法調査	5の進捗度合いにより進める。いくつかの方法を模索する。
8	原因特定	5の結果として特定される。
9	復旧方法確定	8のより復旧計画を確定する。
10	復旧の実施	9により確定した計画を実行する。
11	定点観測と通知	4以降状況を定期的に共有、通知する10の後は復旧通知を行う。
12	影響先へのフォロー	ITの復旧後も利用上は残措置がある場合、復旧フォローする。
13	恒久対策の検討	復旧が暫定対応であった場合、恒久対応を検討する。
14	恒久対策の実施	13の結果を実行する。
15	教訓展開	教訓として他の対象にも展開し、必要に応じて予防対応を行う。

ここで見てきたステップの内、12まではトラブル発生時での出来事となります。ほんの20分以内の出来事のこともありますし、２，３日にわたっての対応のこともあるでしょう。

いずれにしろ、予定しなかったことが突然起き、緊急で対応を迫られることになります。さらに多くのステップを実施しないといけないということとなると、とてつもなく高いスキルが必要となることはわかりますでしょうか。

スキルがなければ、1の段階でストップしてしまいます。

さらに、ステップとして表現していませんが、各経過状況の記録が並行して必要となります。一人で対応することは困難な場合、短い期間での役割分担も必要となりますので、マネジメント力が問われる場面となります。

主要な場面についてさらに説明します。

対処レベル

インシデントに対しての対処レベルは何段階かで設定します。およそ3段階であればマネジメント可能と思います。

対処レベル	レベル感	対処方法
業務オペレーションレベル	特定のデータ入力や参照などの業務上操作に閉じた影響	特定の関係者に対しフォローしながら特定の業務を復旧
業務プロセスレベル	ある商品の会計や請求などの一部機能のトラブル	機能不全もしくは不正データを関係部門レベルで対処・復旧
ビジネスレベル	ITシステム機能の致命的欠陥などによる顧客を含めたトラブル	経営レベルで影響を考慮しつつ対処・復旧

この上のレベルとして災害レベルというものもあります。これについては別次元で検討が必要です。

初動判断と関係者通知とは

ステップの説明としては簡易的に記載していますが、この部分は、実際はかなり重要なパートとなっています。

検知し、ある程度影響が見えた段階で、点の影響なのか面の影響なのかを見極めないといけません。
面であれば広く関係者を集めて、いち早く通知しなくてはなりません。

突然準備もしていない段階でこのような判断を迫られるのは、大変なスキルを求められます。よって運用責任者がいればいいですが、いなくてもこのような手順を把握している人がいるようにしなければなりません。

その後のタスクは、場合によっては急ぐために並行タスクとなる場合もあります。よってそれが可能な体制を数分の内に組まないといけないことになります。

そういった意味でも、ITマネジメントのスキルの中でも最高スキルに値するものと言えます。

応急処置とは

トラブルが発生したとして、復旧はできていないですが、一旦なんらか食い止める、もしくは被害を減らすための措置を行うことになります。

例えば、ユーザの地域ブロック単位に影響が出る障害としたら、その地域では復旧できないとしても、他の地域への影響をださないために、ネットワークを切り離すといったものです。

復旧計画とは

復旧計画は原因が判明し、復旧方法が見つかったら、復旧までの実行計画を行うことを指します。

復旧するためには、ITを一旦止めて再起動が必要であったり、データを更新したりと、場合によって違ってきます。

復旧のタスクを実行するために、現状、正常に稼働している部分にも影響を出した上で、全体が復旧するということもあるわけです。復旧作業中に二次災害を出さないためにも、短い時間の間に綿密な計画を立てる必要があるということになります。

恒久対策とは

バグへの対応

原因がバグであった場合、復旧にあたっては、あくまでもその場しのぎの暫定対策である場合があります。

また翌月になれば起きてしまう、というような事象だとすれば、まだ対応が完了したとは言えません。
本格的な対応は時間を要するので暫定対策としたのであれば、恒久対策を行うこととなります。

恒久対策を実施しなければいずれまた障害となるため、監視対象として完了までマネジメントします。

ミスへの対応

人のミスによって障害となるケースもあります。

ミスは、その人の問題もありますが、マニュアルなどの問題もあり得ます。

この場合は、再発防止という意味で対策を打ちます。

再発防止策ができない間はまた障害事象が起きうるため、これもまた監視対象として完了までマネジメントします。

全方位思考による復旧へのマネジメント

ここの紹介したステップは結構多いため、経験した人でないと何も考えずにはできないです。しかも切羽詰まった状況下での行動となります。

基本ステップはありますが、その場面になったらできてしまう人もいます。

それは、全方位思考によりあらゆる可能性を考慮して行動ができるからです。

全方位とここでいったのは、影響と原因について、あらゆる考え得ることを考慮することと、各レイヤーのレベルで考えることです。

影響についても原因についても、広く可能性を考えるとともに、影響先のその先の影響先というようにレベルとして影響範囲を考えます。

経営、組織、ITの観点で、それぞれ外部先も含めて、考えを広げていくことで、真の原因、正しい対処ができるようになります。

IT稼働・障害・保守マネジメントの手順

稼働に関する基本的なマネジメント手順は以下となります。

障害・保守については都度発生します。障害発生時対応の対処マネジメントは先に説明したとおりですが、定常的に行うべきマネジメント手順は以下のとなります。

ITダウンへの保険

ITは内部の人為的な原因で利用できなくなることもありますし、クラウドだったとしてもサービスが突然停止することもあり得ます。

そのような際には、なんらかビジネスは対応できるように考えておかないといけません。このことを保険と言っています。何かあった時のバックアップ対策ということです。

事象のレベルによってどのくらいのことを考えるべきかが異なってきます。
3レベルくらいで考えてみましょう。

業務オペレーションレベルでのダウン

例えば100件の自動入力機能があるが、その機能が使えなかったら1件1件入力するといったバックアップ策になります。よって1件ずつ入力する機能は別に確保しておくというのが保険です。

業務プロセスレベルでのダウン

例えば請求書の顧客への自動発信ができず、会計システムへの計上もできなくなったということがあったとします。この発信や連携はネットワーク経由で行われるので、十分ネットワークによる障害は想定しうるものです。

この場合、請求書の手動発行とメール送信は確保したいです。また会計計上について手入力で諦めるというのも考え方の一つです。

ビジネスレベルでのダウン

ITが全体的にダウンした際にどうするかといことになります。

ITがなくても数日はなんとかなるということもあるでしょう。そうはいかないということであれば保険を掛けておかないといけません。

例えばバックアップシステムを準備しておくということになります。費用も掛かりますので、重要度は考慮の上、対策を検討することになります。

IT稼働・障害・保守マネジメントにおけるありがちな問題

原因がわからない

障害については、対処方法のステップやマネジメント方法を説明してはきましたが、あくまでも進めるための方法であって、実際の現場では様々な複雑な問題が起きています。

無事対応が完了できればいいですが、うまくいかないケースの一つとして、原因がわからないというものがあります。

原因がわからなければ対策の打ちようがないですが、実際にはよく起きます。
そのような際にも、事象から推測して対応策を打っていかないといけません。

改善したはずが障害となる

保守作業に関して、ソフトウェアのバージョンアップなどによる改善対応を行うことがあります。

基本的には内在している不具合などの改善ということになりますので、よいことをしているはずです。
しかし、このことにより今まで正常だった機能が機能しなくなるということもあります。それは、不具合が内在していたなりに、正常に動いていた部分が、改善されたことにより正常扱いでなくなったということになります。

何か変更を加える際には、変更マネジメントとしても説明してきましたが、変更後のテストや確認を十分に計画しておく必要があるということになります。

不具合と仕様の問題

不具合とは正しく動いていないと認識されることと定義しましたが、不具合とはやっかいなもので、ある見方においては正しくないということなのですが、別な見方をすると正しいということになります。

その別な見方というのは仕様に照らし合わせてみると、ということです。仕様とは今どのように作られているかということになり、それは考慮不足な面があったとしても、仕様どおり動いているということになってしまいます。

普通に使っているスマホのOSでもこのようなことは起きています。

ただビジネスに影響がなければいいですが、影響のあるような不具合もあり得ます。このようなこともある、ということで心構えは必要です。

わかっているが故のトラブル

社内であれ、外注であれ保守運用を行っているエンジニアが長らく担当していたとすると、よく知っていてパフォーマンスがよいということになりますが、時に問題を起こします。

よく知っていてわかっているが故に、計画や手順を怠って実行に走ってしまいます。

復旧を急いでいれば、それでうまくいくのであればいいのですが、急がば回れでトラブルを大きくしてしまうことも無くはありません。

慣れていても慎重かつ確実に対処するよう、手順を定めておきたいです。

IT内部をよく知っているエンドユーザ

わかっているが故のトラブルの別パターンとなります。

よくわかっているエンドユーザの強引な行動で、問題を起こしてしまうことがあります。

例えば、締め切りを過ぎたが売り上げ数字を間違ってしまったので、請求処理前に修正データをねじ込んで欲しい、といったことをITスタッフに言ってきたとします。

普通の人は知らなくても、以前関わったことがあり、知っているが故に無理なお願いをしてくるというものです。

結果的に不正データが入り込み、請求書100枚が出なくなったとなったら、問題は大きくなります。
よく知っていると簡単なことにも思えてしまうこと修正をねじ込むという行為ですが、非常に危険な行為です。

マネジメントとしては、このようなことは牽制していかないといけません。

対策を打ちたいが他の仕事がある

障害や保守の対策について、タスクが溜まってしまい、対策をしていないことで別な障害が発生してしまい、収集がつかなくなっているなんてことが稀にあります。

実行するスタッフの他の仕事の関係でそうなってしまうことがあります。つまり瞬間的に人手不足になっているということでしょう。

瞬間的でなければ雇用なり外注を増やすことになるでしょうが、そこまでではない、という場合はどうしましょう。

これはそうなってしまったら手遅れということです。

そうならないように日常的なマネジメントが必要ということでしょう。

どこまでを想定して保険を掛けておくか

ITダウンに対する保険について説明してきましたが、保険を掛けると言ってもピンからキリまであります。

いっそのことITをすべて2重化すればいいわけですが、すべてに保険を掛けると費用的には膨大になるはずです。

やはり重要度や優先度が必要となってきます。

ビジネス影響度に合わせて、もしなかったら致命的なものであれば確実に保険がある、という状態にしておきたいところです。

教訓が活かされない

発生したトラブルに対して、教訓として記録することを手順に入れています。

同じことが起きたら、同じ対処を行う、もしくは同じようなことが起きないような未然防止対応をとるといった理想的な話をする人がいます。

これはある局面においてはそういうことはあるでしょうが、実際は、障害はそんなにしょっちゅう起きないですし、同じことというのはなおさら起きないです。

極めて個別性の高いものであって、再現性が少ないということなります。そのようなことに対して、教訓として並べても実際は役に立たないということになります。

しかし教訓の捉え方次第では役に立ちます。具体的過ぎると個別の話になってしまい、再現性がありませんが、やや抽象度を上げると同時に分かり易いものにすれば、役に立つこともあります。

IT稼働・障害・保守マネジメントにおいて本当にやるべきこと

稼働・障害・保守の領域については、基本的には現状が問題ない状態にもっていくという比較的地味な行為の連続に見えます。

しかし、何の知識もなく実行できるものでもありません。むしろ高いスキルが必要な場面が多いです。
この領域で難しいのは、コストパフォーマンスです。

いつ起きるかわからない突発的な問題に対処できるようスキルが高い体制を構築するというのは、あまり得策ではありません。

やはり、突発的な問題が起きないよう、予め計画していくことが重要です。

さらに、予め計画するにせよ、最低限の突発的なことを想定するにせよ、コストパフォーマンスを考えて、対応レベルを決める必要があります。