2014年10月16日木曜日

システム管理のお勉強(その1)

最近マネージングのお仕事が多くなり、システム管理についていろいろ考えないと
行けなくなりました。
そこで、システム管理について、調べてみましたので、簡単にまとめてみました。

 ●システム管理者の仕事
「情報システムの管理体系を計画・確立し、日常の運用管理を行うお仕事」
といわれています。

これではなんだかわかりませんが、お仕事的にいうと、
「システムの導入、ユーザートレーニング、障害監視、障害の早急対応」
といった日常業務の為に、システム管理を行う作業となります。

システム管理の仕事を大まかに述べると以下となります。
(いろいろ調べると、本当はもっと細かく分類されていますが、小さい会社で、プログラマが知っているべきレベルで分類しました)
1)インシデント管理
2)問題管理 
)変更管理
リリース管理
構成管理
サービスデスク
)障害監視/管理
8)バッチ処理スケジュールの管理と保守
9)ストレージ管理(バックアップとリストアを含む)
10)アクセス管理(ユーザーに対するアクセス制限の管理を含む)
11)個人情報保護、データの保護、ウイルス対策、セキュリティ対策


今回は、「1)インシデント管理」についてまとめてみました。


●インシデント管理とは
よく、お客様からインシデント管理を尋ねられるますが、実際には「問題管理」と「インシデント管理」を一緒に思われ場合が多いです。
そこで、インシデント管理って何?というところから始めます。

それでは、インシデント(incident)の定義は?
ITIL ver3における定義】
 「予定していないITサービスの中断、または、ITサービス品質の低下。ITサービスに影響をもたらす可能性のあるITサービスを構成するコンポーネントの障害(例:ミラーリングしているハードディスクのうちの1台が故障する場合など)」

簡単に述べると、利用者にとって、「システムを使ってやりたいことができない状態」を意味します。

注意すべきは、故障などはインシデントの原因であってインシデント自体ではありません。

「インシデント=障害では決して、思わない」ことです。


インシデント対応としては、インシデント発生時、可能な限り迅速にサービスを元の状態に戻すことを目標とします(現状復帰)

サービスが元の状態に戻る(インシデントが解決する)まで、インシデントを管理する責任を持ち、根本原因の究明は含みません。
原因究明は、次回説明する「問題管理」となります。

例えば、
「コンピュータが故障して使えない」という事態が発生した場合、「コンピュータが使えない」ことがインシデントであり、「コンピュータの故障」はその原因となます。
「コンピュータを使えるように対応した」ことが、インシデントの完結となります。
インシデント管理では、原因追求やその原因を取り除くための措置というのは考えないことです。

インシデント対策では、「最悪でも24時間以内には修理します」ということを決めておき、その時間内の解決を目指します。
そのような合意は、SLA(Service Level Agreement)という文書を作成して明記しておきます。

完了したら、インシデント管理表などに記録して、後に同じ現象が起こったときに役立てるようにします。
インシデント管理表はどのようなものかな?とおもったら、次のURLがいい例と思います。
 http://www.ctct.co.jp/service/itlifegear_saas/function.html
※この中の「基本情報と対応履歴の管理(管理項目)」の「拡大する」をクリック

 上記URLで記載しているインデント管理項目は、以下となっています。
・案件名
・インシデント管理番号
・案件内連番
・発生日時
・受付日時
・SLA完了日時
・所要時間
・SLA対応時間
・インシデント担当者
・インシデント対応者
・ホスト名/局舎
・件名
・現象
・原因
・対応まとめ
・サービス影響
・重要度
・影響度
・優先度
・対応レベル
・ステータス
・ステータスの履歴
・お客様承認者
・お客様承認日時
・原因対処
・現在のエスカレーション
・依頼元
・依頼元担当者
・備考
・担当部署
・添付ファイル
・更新日時
これらの項目にて、自分の会社にあった項目を選択、追加してインシデント管理表を作りましょう。


 インシデント管理について、もっと詳しく知りたいと思ったら、次のURLなど参照してください。
http://www.newton-consulting.co.jp/itilnavi/glossary/incident_m.htm

次回は、問題管理についてまとめます。


0 件のコメント:

コメントを投稿