ITIL/サービストラジション

ITIL－サービストラジション

・変更管理
・リリース管理および展開管理
・サービス資産管理および構成管理

☆サービスVモデル

サービスの構築・テストをする段階。


☆DIKW
データ・情報・知識・知恵。

☆サービス・ナレッジ管理システム（SKMS）

ナレッジ、情報の管理に使用される一連のデータベースのこと。KEDB、SCDなど・・・

ITIL/サプライヤ管理

☆サプライヤ管理

良質のITサービスを事業部門に途切れることなく提供できるように、サプライヤおよびサプライヤが提供するサービスを管理し、投資に見合う価値を得られるようにする。

・SLAを満たすサプライヤの契約について協議・合意

☆サプライヤ契約データベース（SCD）：サプライヤとの契約のライフサイクル（契約・更新・終了・評価）を通して、サプライヤ管理に使用するデータ化された文書。

・サプライヤとの契約内容、サプライヤが提供する製品やサービス

・サービス・ナレッジ管理システム（SKMS）に含まれる

☆アウトソーシング：ITサービスに必要なリソースを外部から調達
☆インソーシング：社内で全て賄う
☆コンソーシング：インソーシングとアウトソーシングの両方を使用

☆ビジネス・プロセス・アウトソーシング(BPO）：ビジネスのプロセスや機能をアウトソーシングする。

☆アプリケーションサービス供給：アプリケーションサービスプロバイダ(ASP)、共有コンピュータ・ベースのサービスをネットワークを通じて顧客の組織に提供する。

☆ナレッジ・プロセス・アウトソーシング（KPO）：高等な専門知識を必要とする領域のBPO。

マーケット・リサーチや証券取引など

ITIL/情報セキュリティ管理

☆情報セキュリティ管理

ITセキュリティを事業セキュリティと整合させること。サービスマネジメントにおいて情報セキュリティが効率よく管理されること。

☆CIA

◎機密性（Confidentiality）：情報を知る権限を持つ人だけ閲覧可能になっている、情報を知る権限を持つ人にだけ公開されている

認証の仕組みを利用した権限のチェック。アクセス・コントロール。

◎完全性（Integrity）：正確な情報であることを保障され、承認されていない修正から保護されていること。

Webクラッカーに対する防御など。

◎可用性(Availability)：必要とするときに情報の入手が可能なこと。情報を提供するシステムが攻撃に対して適切に対処し、障害を防御、またはすばやく復旧させること。

データセンタは地震の少ない場所に設置する。

ITIL/可用性管理

☆可用性管理

可用性：サービス・コンポーネント・構成アイテムが必要とされたときに、合意された機能を実行する能力のこと。

可用性(%)＝サービス稼働時間－停止時間／サービス稼働時間



日常のITサービスを維持するためにITサービス、ITインフラストラクチャ、サポートする組織の可用性を最適化・改善する。


※ITサービス継続性管理との違い

可用性管理：日常のITサービスを維持する。（耐障害弾力性、DBバックアップなどリスク低減策、復旧戦略）
→サービスの維持

☆DB、ネットワークのの二重化、電源の二重化やUPSの設置、外部媒体へのバックアップ


ITサービス継続性管理：規定外の障害や災害に備えるためのリスク低減策や復旧策
→サービスの復旧

☆設備や施設そのもののバックアップ、ディザスタリカバリ、セキュリティの強化

両方あわせて：事業継続性管理と呼ぶ

☆信頼性：サービス・コンポーネント・構成アイテムが必要とされたときに、どれだけ合意された機能を実行することが出来るか


MTBSI（平均サービス・インシデント間隔）＝サービス時間／中断回数

MTBF（平均故障間隔）＝サービス時間－総停止時間／中断回数


☆保守性：障害回復後、どれだけ早く回復できるか

MTRS（平均サービス回復時間）＝総停止時間／中断回数

☆サービス性：サプライヤの信頼性・保守性

☆VBF（Vital Business Function：重要ビジネス機能）

ITサービスによって支えられている、ビジネス・プロセス上重要な要素

☆拡張版インシデントライフサイクル：インシデントの検出・診断・修理・復旧・回復のライフサイクル。
インシデントのインパクトを増大させた全ての要因を把握し、インパクトを低減しする計画を立てるために用いる。

ITIL/変更管理

☆変更管理用語

・サービス変更：サービスやサービスの構成要素とその関連文書を追加・修正・削除すること。

問題が発生した場合と、使い勝手を改善するための変更と両方含む。


・RFC（Request for Change）：変更要求

変更理由、変更しない場合の影響・変更対象である構成アイテム

・FSC（Forward Schedule of Changes）：将来の変更スケジュール
変更の詳細と実施予定日のスケジュール。
通常の変更スケジュールはリリース管理において立案されるリリース計画にあわせて設定されるが、
問題対応など緊急のスケジュール変更などが入った場合、このプロセスでスケジュールを決める。

・変更管理７つのR

ビジネス・インパクトを探る質問

RAISED：変更を要請したのは誰か
REASON：変更の理由は何か
RETURN：変更の成果として要求されるものは何か
RISK：変更のリスクは何か
RESOURCE：変更を実施するために必要なリソースは何か
RESPONSIBLE：構築、テスト、実装の責任は誰にあるのか
RELATIONSHIP：この変更と他の変更の関係は何か

・変更モデル：変更のインパクト、大きさによる分類。「通常」「標準」「緊急」など。

・変更諮問委員会－CAB（Change Advisiory Boad）：ビジネス、技術、財務的な観点から変更要求を評価する組織。変更マネージャ、顧客、ユーザー部門、技術アドバイザ、外部ベンダー、スタッフ代表などが参加する。

・緊急会議－CAB/EC：障害事などの「緊急」変更が発生したときに召集する。

・PIR（Post Implemetation Review）：変更後のレビュー。変更の効果度、顧客満足度、可用性やキャパシティへの影響、コストの評価などを行う。

・変更マネージャ：変更を管理する人。