はじめに
みんなが知っておくべき運用設計のノウハウを読んで非機能要件の一部である運用要件について調べたのでメモしてみました
運用とは
決まりに従って効率よく人や物を動かすこと
まとめ
ITシステム運用とは
ITシステムをうまく働かせて使うこと
利用者に安定してサービスを提供するためにシステムを安定して稼働させる。安定稼働、効率的な対応を実現させるために、運用設計を考えて、必要なドキュメント、運用フローに落とし込み、日々の運用を実施していく
以下で運用における考え方を記載する
運用にかかわる登場人物
運用担当者
- システム利用者からの問い合わせ対応を行うサービスデスクを実施
- 手順書を元に、日時や週次で行う定型作業
- 依頼を元にアカウント作成や、パッチ適用、ログ取得といった否定形作業
インシデントが集まる箇所でもあるので
システムの稼働状況やインシデント発生件数などの報告も行う
監視オペレータ
不具合発生時に一時切り分け、エスカレーション
保守担当者
機器販売ベンダーが保守担当者になっていることが多い
運用がITコストの大半を占める
運用要件とは
非機能要件の一部
非機能要件は、インフラと運用チームがつくる。
非機能要件の運用・保守に関して運用設計書を運用チームが作る
要件定義時に決めておいたほうがよい運用項目
運用体制
誰がどのように運用しているのか
役割や責任分界点
サービスデスクの場所、運用担当者の作業場所、DCの運用体制
ユーザーアカウント管理方法
セキュリティ対策
脆弱性対策
ウイルス対策
パスワードルール
セキュリティパッチ適用方針
バックアップ/リストア運用
監視運用
稼働設計運用
月次、週次報告書などの定期報告のありなし
この条件を実現するために、運用設計を作成していく
運用設計とは
-
要件定義で運用・保守に関する項目があり、お客さんと取り決めた運用要件がある。
その運用要件を実現するための具体的な施策が運用設計 -
運用要件は要件定義時に決められるので、運用に関する必要な情報を取りまとめ
運用に必要な項目を運用項目として一覧にまとめる
いつ、どこで、だれが、何を、なぜ
システム運用上発生する問題をあらかじめ想定して対応方法を決めておく。
運用設計担当者がインフラ、アプリチームの設計したものを基に
サービスを継続的に提供できるような運用の仕組みを考える
運用設計の項目
- インフラの基本設計と被る箇所もある
- 実運用でITILから必要な項目が項目としてある
- インフラ構築チームと連携して、運用設計していく項目をシステム基盤項目
システムについて
システム概要とシステム構成図
運用体制
運用開始後の関係者の役割、所属組織、対応時間、連絡方法、勤務場所など、運用していく上で必要な情報を取りまとめていきます。
保守運用
HW、ソフトウェアの問い合わせ先など
保守運用時のフロー図など
お客様 －＞問い合わせ －＞保守員 －＞ 各ベンダ
インシデント管理
インシデント管理は利用者がITを使用できる状態を維持するITサービスマネジメントの重要なプロセスの一つとされ、ITILやISO/IEC 20000といった規格やガイドラインにより標準的な体制やプロセスの体系が定められている。
どのような場合に、どの連絡
インシデントとは
http://e-words.jp/w/%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E7%AE%A1%E7%90%86.html
利用者にとって、「システムを使ってやりたいことができない状態」
また、機器やシステムの側に不備や不具合がない場合でも、「このソフトウェアのこの機能の使い方が分からない」「ログインのためのパスワードを忘れてしまった」といった状況が生じる場合があり、これもインシデント管理の対象となる。
インシデント管理とは？
インシデント管理とは、ビジネスへの影響を最小限に抑え、迅速にITサービス/ITシステムを復旧することを目的とした、システム部門が担う以下のプロセスのことをいいます。
インシデント発生を認識する
状況を適切に把握する
解決策を立案する
解決策を実施
状況を回復させる
前述の事例では、「メモリを解放する」が、インシデント管理プロセスにおける解決策となります。その他にも「経理システムの代わりにメールでエビデンスを残し決済処理を実施する」などが考えられます。
問題管理
- インシデントの中で根本的に解決が必要なもの。インシデント管理と連続性がある
- 問題管理プロセスではインシデントの根本原因を解決することを目指します。従って、問題管理プロセスで問題を解決すると、インシデントは再発しなくなります。
インシデント管理と問題管理の違い
インシデント管理プロセスでは、インシデントを解決して事業へのマイナスのインパクトを抑えることが目的とされます。
前述の事例の場合、「メモリを解放する」はあくまでも一時的な回避策です。問い合わせのあった経理部門担当者の決済処理の実行は達成され、ビジネスへのマイナスインパクトを抑えることができますが、経理システムの不具合が解消されたわけではありません。そのため、同様のインシデント報告が再発することが考えられます。
これに対して、問題管理プロセスではインシデントの根本原因を解決することを目指します。従って、問題管理プロセスで問題を解決すると、インシデントは再発しなくなります。
構成管理(サービス資産管理)
構成管理とは、ITシステムがどのような「要素」で構成されており、それらの要素のライフサイクルがどうなっているかまで把握・管理をすることです。
構成管理を行う目的は、とある1つの要素で発生した変更やトラブルが、他の構成要素に影響を与え、更なる大きなトラブルへとつながりかねないことが理由として挙げられます。
【ITシステムを構成する要素】
●ハードウェア
●ソフトウェア
●ネットワーク
●ライセンス
●サーバ
●電源などの設備
SLA管理(SLM:サービスレベル管理)
『要求されたサービスレベルが達成されているかどうか、および達成されていない場合はなぜかを確認する為の監視を開始できるようにする為に、あらゆる組織において必須である。』
顧客とサービス提供者の間でITサービスの取り決めについて、目標及び責任を明確にし、合意した文書のことです。
SLAはどちらかが不利益になる契約ではなく、お互いがサービス責任範囲や内容について合意する事が重要になります。
機能要件や非機能要件の項目に対してSLAを定義しておかないと、何か起きた時に責任範囲があいまいになり、擦り付け合いになってしまうことも
可用性管理
一般にITシステムの可用性を高めるには、システムを構成する各コンポーネントを多重化したり、余裕を持たせたりという方法が用いられるが、これらはいずれもコストが掛かる。可用性管理はITシステム、管理プロセス、ツール、コストが可用性に関するSLAの目標値に対して最適化されるように常時見直していく作業を行うことになる。
変更管理
変更管理の目的
変更管理の目的は、大きく分けて次の3つがあります。
変更により障害が起きた際に特定をするために変更履歴を残す
変更によるダウンタイムを最小限に抑える
変更対象外のシステムをコントロールする
サービスレポート
- 報告対象となるものを顧客と合意しなければなりません。
- インシデント件数
- 問題解決件数
- 可用性報告
- 情報セキュリティ報告
- SLA
システム基盤項目
インフラ構築チームと連携して、運用設計していく項目のことを「システム基盤項目」と呼んでいます。
- 監視
- 自動化管理（ジョブ管理）
- バックアップ
- ログ管理
運用に必要な台帳
上記の運用設計をしたうえで、実際に運用していくときに必要な台帳について
- NW
- IPアドレス一覧
- ポート管理表
- ケーブル結線管理表
- サーバー/ストレージ
- 機器管理表
- サーバー構成管理表
- ソフトウェアライセンス一覧
- 運用系
- 監視対象一覧
- バックアップ/リストア一覧
- 連絡先一覧
- 保守管理一覧
- パスワード一覧
- 端末管理台帳