高度午前 - サービス・マネジメント - サービス・マネジメント のバックアップ(No.3)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 高度午前 - サービス・マネジメント - サービス・マネジメント へ行く。
  • 1 (2019-07-06 (土) 21:05:05)
  • 2 (2019-07-06 (土) 21:59:31)
  • 3 (2019-07-07 (日) 19:36:19)
  • 4 (2019-07-07 (日) 21:25:44)
  • 5 (2019-07-14 (日) 15:01:28)
  • 6 (2019-08-12 (月) 13:29:11)
  • 7 (2019-09-01 (日) 15:14:39)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

• サービス・マネジメントのサービス・マネジメント
• サービス・マネジメントの雰囲気を理解する。

JIS Q 20000 †

概要 †

ISO/IEC 20000は国際標準化機構 (ISO) が規定している国際規格

• ITサービスを提供する組織のITサービス・マネジメント
  が適切であるかどうかを評価するための認証基準、およびガイドライン。
• ITサービス・マネジメントの実現にあたって、プロセスという単位で
  必要な組織を横断的に管理し、プロセスごとに役割と責任を明確にする手法を採用。

• 2部からなる
  • ISO/IEC 20000-1:
    Information technology -- Service management -- Part 1: Specification
  • ISO/IEC 20000-2:
    Information technology -- Service management -- Part 2: Code of practice

• 次の日本工業規格になっている。
  • JIS Q 20000-1: 情報技術 ― サービスマネジメント ― 第1部：仕様
  • JIS Q 20000-2: 情報技術 ― サービスマネジメント ― 第2部：実践のための規範

第1部：仕様 †

• 情報セキュリティ管理プロセス
  次を特定するために、変更要求を評価しなければならない。
  • 新たな情報セキュリティ・リスク、又は、変化した情報セキュリティ・リスク
  • 既存の情報セキュリティ基本方針及び、管理策への潜在的影響。

• 問題管理プロセス
  サービス提供者は、根本原因及び、潜在的な予防措置を特定するために、
  インシデント・問題の、データ・傾向を分析しなければならない。

• 構成管理プロセス
  
  • CMDB（構成管理データベース）に記録されているCI（構成アイテム）
    の原本は、構成記録が参照しているセキュリティの保たれた
    物理的又は電子的な格納庫に格納しなければならない。
  • 原本には少なくとも、文書、ライセンス情報、ソフトウェア
    及び、入手可能な場合はハードウェア構成の配置図を含めなければならない。

• 変更管理プロセス
  • サービス提供者及び利害関係は、変更要求の受入について、決定しなければならない。
  • 意思決定では、リスク、サービス及び、顧客への潜在的影響、サービスの要求事項、
    事業利益、技術的実現可能性並びに財務的な影響を考慮しなければならない。

第2部：実践のための規範 †

• サービス・マネジメントの目的
  • トップ・マネジメントは、合意されたサービス・マネジメントの目的を定義することが望ましい。
  • 目的は、事業目的、および、サービス・マネジメントの方針に整合することが望ましい。

• サービスレベル合意書（SLA : Service Level Agreement）作成方針
  • サービス提供者と顧客がサービスの条件・目標に合意した内容を記載する。
  • サービス提供者と顧客の責任を規定し、複数のサービスを複数の顧客に提供可能。
  • 目標の数が多すぎると混乱が生じるため、目標の適切な部分のみ記載する。
  • サービスの説明、SLAの有効期限・変更管理はSLAからサービスカタログへリンク可。

ITIL †

ITIL (Information Technology Infrastructure Library)

• ITサービスの品質向上、中長期的なコストの削減などを目的として、
  実在する企業のベストプラクティス（成功事例）を収集し、書籍化したもの。
• ITサービス全体においてデファクトスタンダードとなりつつあり、重要となっている。

SMART †

SLAやプロジェクト目標の設定の留意事項をまとめたもの。

• Specific：具体的
• Measureable：測定可能
• Achievable：達成可能
• Relevant：適切
• Timely：適時

7ステップの改善プロセス †

1. 改善の戦略を識別する。
2. 測定するものを定義する。
3. データを収集する。
4. データを処理する。
5. 情報とデータを分析する。
6. 情報を提示して利用する。
7. 改善を実施する。

CSF・KPI †

各プロセスに対する

• 重要成功要因(CSF)
• 重要業績評価指標(KPI) を例示している。

設計・移行 †

サービス・ポートフォリオ †

ITIL 2011 Editionのサービス・ポートフォリオ

サービス・パイプライン †

検討中開発中でまだ提供できないサービス。

サービス・カタログ †

• 現時点で顧客に提供されていて利用可能なサービスの一覧
• サービス・ポートフォリオの中で唯一顧客に公開される。
• 納品物、価格、問い合わせ先、発注手順などの情報が含まれる。

廃止サービス †

消滅・廃止されたサービスの一覧で、以下のケースがある。

• 一切のサービスを終了するケース
• 新規受付を終了し、既存顧客サービスを維持するケース
• 既存顧客に当面のサービスを維持し移行を促すケース

サービス・ライフサイクル †

ITIL 2011 Editionのサービス・ライフサイクル

サービス・ストラテジ（Service Strategy） †

• ITサービスを提供する際の戦略。
  • 顧客に対して、どのような領域でビジネスを行うか、
  • そのサービスが実現可能か
  • サービス設計、開発、実装の有無など

• 構成
  • 戦略管理
  • ポートフォリオ管理
  • 財務管理
  • 需要管理
  • 事業関係管理

• プロセス
  • ビジネス領域の決定
  • 提供するサービスの定義
  • サービスを提供する必要資源の確保
  • 戦略の構築

サービス・デザイン（Service Design） †

サービス・ストラテジで作成した戦略を実現し、
高い品質と顧客満足度、費用対効果を保ちながら運用環境へ
スムーズに導入出来るITサービスを設計するプロセス。

• バランス
  • 機能性（サービスの機能、品質など）
  • リソース（費用、スタッフなど）
  • スケジュール（期間）

• 構成
  • 人（People）
  • 動き（Process）
  • 製品、技術（Product）
  • パートナー、サプライヤ（Partner）

• プロセス
  • サービスレベル管理
  • サービスカタログ管理
  • サプライヤ管理
  • キャパシティ管理
  • 可用性管理
  • ITサービス継続性管理
  • 情報セキュリティ管理

サービス・トランジション（Service Transition） †

• サービスデザインで設計されたサービスを
  本番環境へ移行・導入することをゴールとしたプロセス。
• または既存のサービス変更を確実に
  本番環境へ導入・移行するためのプロセス。

• プロセス
  • 移行計画立案とサポート
  • 変更管理
  • サービス資産および構成管理
  • リリースおよび展開管理
  • ナレッジ管理

サービス・オペレーション（Service Operation） †

顧客に対して実際にサービスを提供する

• プロセス
  • 技術管理
  • アプリケーション管理
  • IT運用管理
  • イベント管理
  • アクセス管理
  • サービスデスク
  • インシデント管理
  • 要求実現
  • 問題管理

継続的サービス改善（Continual Service Improvement） †

• 全ての活動を継続的に改善するプロセス。
• PDCAサイクルに基づく改善活動を通して、
  • 変化するビジネスニーズを捉え、
  • 顧客にとってより良い価値を提供・維持し、
  • 効率性、有効性、および費用対効果を向上させる。

プロセス †

サービス提供プロセス †

JIS Q 20000-1 > サービスマネジメントシステム要求事項 > サービス提供プロセス

サービスレベル管理 †

• サービス提供者は，顧客と合意しなければならない。
  • 提供するサービスについて
  • サービスカタログについて

• サービスカタログ
  • には，サービスとサービスコンポーネントとの依存関係を含めなければならない。
  • は，サービス及び SLA の変更後，それらが整合していることを確実にするために，維持しなければならない。

• 提供する各サービスについて，一つ以上の SLA を顧客と合意しなければならない。
  • SLA を作成する場合には，サービス提供者はサービスの要求事項を考慮しなければならない。
  • SLA には合意したサービス目標，作業負荷の特性及び例外を含めなければならない。
  • 文書化されたサービスの要求事項，サービスカタログ，SLA，及び他の
    合意文書に対する変更は，変更管理プロセスによって管理しなければならない。

• サービス提供者は，
  • 顧客とともに，あらかじめ定めた間隔で
    サービス及び SLA をレビューしなければならない。
  • あらかじめ定めた間隔で，
    サービス目標に照らして傾向及びパフォーマンスを監視しなければならない。
  • 内部グループ又は顧客が提供するサービスコンポーネントについて，
    それらの活動及び二者間のインタフェースを定義する合意文書を，
    策定，合意，レビュー及び維持しなければならない。
  • 合意したサービス目標及びその他の合意したコミットメントに照らして，
    内部グループ又は顧客のパフォーマンスを，あらかじめ定めた間隔で監視しなければならない。

• 結果は，
  不適合の原因及び改善の機会を特定するために
  記録し，レビューしなければならない。

サービスの報告 †

• 識別，目的，報告先，頻度及びデータの出所
  に関する詳細を含むサービス報告書の記載内容は，
  • サービス提供者が文書化し，
  • 利害関係者と合意

しなければならない。

• サービス報告書
  少なくとも次を含めなければならない。

• サービス目標に対するパフォーマンス

• 重要な事象に関する情報
  • 少なくとも，重大なインシデント，
  • 新規サービス又はサービス変更の展開，
  • 及び発動されたサービス継続計画

• 作業量及び定期的な変更を含む，作業負荷の特性

• この規格の要求事項，
  • SMS の要求事項又はサービスの
    要求事項に対して検出された不適合，
  • 及び特定されたそれらの原因

• 傾向情報

• 顧客満足度測定，
  サービスに対する苦情，
  並びに満足度測定及び苦情の分析結果

サービス継続及び可用性管理 †

• サービス継続及び可用性の要求事項
  • サービス提供者は，
    • リスクを評価し文書化しなければならない。
    • 要求事項について特定し，顧客及び利害関係者と合意しなければならない。

• 合意した要求事項では，以下を考慮しなければならない。
  • 適用可能な事業計画，
  • サービスの要求事項，
  • SLA 及びリスク

• 合意したサービス継続及び可用性の要求事項には，
  少なくとも次を含めなければならない。
  • サービスへのアクセス権
  • サービス応答時間
  • サービス全体（end-to-end）の可用性

• サービス継続及び可用性の計画
  
  • サービス提供者は，サービス継続計画を作成，導入，及び維持しなければならない。
  • これらの計画の変更は，変更管理プロセスで管理しなければならない。
  • サービス継続計画には，少なくとも次を含めなければならない。
    • 重大なサービスの停止の場合に実施する手順，又はその参照
    • 計画が発動された場合の可用性の目標c)復旧の要求事項
    • 平常業務の状態に復帰するための取組み

• サービス継続及び可用性の監視及び試験
  
  • サービスの可用性を監視し，その結果を記録して，合意した目標と比較しなければならない。
  • 計画外の可用性の喪失は，調査し，必要な処置をとらなければならない。
  • サービス継続計画は，サービス継続の要求事項に照らして試験しなければならない。
  • 可用性計画は，可用性の要求事項に照らして試験しなければならない。
  • サービス提供者がサービスを運用するサービス環境に重大な変更があった場合，
    サービス継続及び可用性の計画を再度試験しなければならない。
  • 試験の結果は記録しなければならない。
    • 各試験後，及びサービス継続計画の発動後，レビューを実施しなければならない。
    • 不備が見つかった場合には，サービス提供者は必要な処置をとり，とった処置について報告しなければならない。

サービスの予算業務及び会計業務 †

• 他の財務管理プロセスとの間に，定義されたインタフェースをもたなければならない。

• 次の事項について，方針及び文書化された手順をもたなければならない。

• 少なくとも次の事項を含む，サービスコンポーネントのための予算業務及び会計業務
  • サービスを提供するために使用する資産（ライセンスを含む。）
  • 共有資源
  • 間接工数
  • 資本及び運営経費
  • 外部から提供されるサービス
  • 要員
  • 設備

• 各サービスに全体的な費用を提供するための，
  サービスへの間接費の配賦及び直接費の割当て

• 効果的な財務管理及び承認
  • 費用は，提供するサービスについての効果的な財務管理及び意思決定ができるように予算化しなければならない。
  • サービス提供者は，予算に照らして費用を監視及び報告し，財務予測をレビューし，費用を管理しなければならない。
  • 変更要求にかかる費用の根拠として，変更管理プロセスに情報を提供しなければならない。
  • 注記 多くのサービス提供者はサービスに課金している。サービスの予算業務及び会計業務プロセスの範囲には，課金は含まない。

容量・能力管理 †

• サービス提供者は，
  • 容量・能力及びパフォーマンスの要求事項を特定し，
    これについて顧客及び利害関係者と合意しなければならない。
  • 人，技術，情報及び財務に関する資源を考慮して，
    容量・能力の計画を作成，実施及び維持しなければならない。

• 容量・能力の計画の変更は，変更管理プロセスで管理しなければならない。

• 容量・能力の計画には，少なくとも次を含めなければならない。
  • 現在及び将来の，サービスに対する需要
  • 可用性，サービス継続及びサービスレベルについて合意した要求事項から予想される影響
  • サービスの容量・能力を拡張させるための，期間，しきい（閾）値及び費用
  • 法令，規制，契約又は組織変更上の，潜在的影響
  • 新規技術及び新規技法による潜在的影響
  • 予測分析を可能にする手順，又はその参照
    サービス提供者は，
    • 容量・能力の利用を監視し，容量・能力のデータを分析し，パフォーマンスを調整しなければならない。
    • 合意した容量・能力及びパフォーマンスの要求事項を満たすために，十分な容量・能力を提供しなければならない。

情報セキュリティ管理 †

• 情報セキュリティ基本方針
  
  • 適切な権限をもつ経営者は，
    サービスの要求事項，法令・規制要求事項及び契約上の義務
    を考慮して，情報セキュリティ基本方針を承認しなければならない。
  • 経営者は次を実施しなければならない。
    • サービス提供者，顧客及び供給者の内部の適切な要員に，
      情報セキュリティ基本方針及びこの方針の順守の重要性を周知する。
    • 情報セキュリティマネジメントの目的が確立されていることを確実にする。
    • 情報セキュリティリスク及びリスク受容基準の管理のためになすべき取組みを定義する。
    • 情報セキュリティリスクアセスメントを，あらかじめ定めた間隔で実施することを確実にする。
    • 情報セキュリティ内部監査を実施することを確実にする。
    • 改善の機会を特定するため，監査結果をレビューすることを確実にする。

• 情報セキュリティ管理策
  サービス提供者は，次のために物理的，実務管理的，及び技術的な情報セキュリティ管理策を導入し，運用しなければならない。
  • 情報資産の機密性，完全性及びアクセス性を保つ。
  • 情報セキュリティ基本方針の要求事項を満たす。
  • 情報セキュリティ管理の目的を達成する。
  • 情報セキュリティに関連するリスクを管理する。
    サービス提供者は，
    • これらの情報セキュリティ管理策を文書化し，管理策が関連するリスク，管理策の運用及び維持について記述しなければならない。
    • 情報セキュリティ管理策の有効性をレビューしなければならない。
    • 必要な処置をとり，とった処置について報告しなければならない。
    • サービス提供者の情報又はサービスにアクセスし，利用又は管理する必要がある外部組織を特定しなければならない。
    • 情報セキュリティ管理策について，これらの外部組織と文書化し，合意し，実施しなければならない。

• 情報セキュリティの変更及びインシデント
  次を特定するために，変更要求を評価しなければならない。
  • 新たな情報セキュリティリスク，又は変化した情報セキュリティリスク
  • 既存の情報セキュリティ基本方針及び管理策への潜在的影響情報
    • セキュリティインシデントは，情報セキュリティリスクに適した優先度に従い，インシデント管理手順を用いて管理しなければならない。
    • サービス提供者は，情報セキュリティインシデントの種類，数及び影響を分析しなければならない。
    • 情報セキュリティインシデントは，改善の機会を特定するため，報告し，レビューしなければならない。
    • 注記 ISO/IEC 27000 ファミリー規格は，情報セキュリティマネジメントシステムの要求事項を規定し，導入及び運用を支援するための手引を提供する。

関係プロセス †

JIS Q 20000-1 > サービスマネジメントシステム要求事項 > 関係プロセス

事業関係管理 †

• サービス提供者は，サービスの顧客，利用者及び利害関係者を特定し，文書化しなければならない。
• 各顧客について，サービス提供者は顧客関係及び顧客満足を管理する責任をもつ個人を指名しなければならない。
• サービス提供者は，顧客との間にコミュニケーションの仕組みを確立しなければならない。
  • コミュニケーションの仕組みによって，
    サービスを運用する事業環境及び新規サービス又は
    サービス変更に対する要求事項の理解を促進しなければならない。
  • この情報は，サービス提供者のこれらの要求事項への対応を可能にするものでなければならない。

• サービス提供者は顧客とともに，あらかじめ定めた間隔で，サービスのパフォーマンスをレビューしなければならない。
• 文書化されたサービスの要求事項の変更は，変更管理プロセスで管理しなければならない。
• SLA の変更は，サービスレベル管理プロセスと連携しなければならない。
• サービスに対する苦情の定義について，顧客と合意しなければならない。
• 顧客からのサービスに対する苦情を管理する文書化された手順をもたなければならない。
• サービス提供者は，
  • サービスに対する苦情を記録，調査，対処，報告及び終了しなければならない。
    通常の経路ではサービスに対する苦情が解決しなかった場合には，顧客に別の経路を提供しなければならない。
  • サービス提供者は，顧客及びサービスの利用者の代表的なサンプルに基づき，
    あらかじめ定めた間隔で顧客満足度を測定しなければならない。
    その結果は，改善の機会を特定するために，分析し，レビューしなければならない。

供給者管理 †

• サービス提供者は，サービスマネジメントのプロセスの一部の導入及び運用のために供給者を用いてもよい。

• 各供給者について，サービス提供者は，
  供給者との関係，契約及び供給者のパフォーマンスの管理
  に責任をもつ個人を指名しなければならない。

• サービス提供者及び供給者は，契約文書について合意しなければならない。

• 契約には次を含めるか，又は参照しなければならない。
  • 供給者が提供するサービスの範囲
  • サービス，プロセス及び関係者の間の依存関係
  • 供給者が満たす要求事項
  • サービス目標
  • 供給者及び他の関係者が運用するサービスマネジメントのプロセス間のインタフェース
  • SMSの範囲内の供給者の活動の統合
  • 作業負荷の特性
  • 契約の例外及びその対処法
  • サービス提供者及び供給者の権限及び責任
  • 供給者が提供する報告及びコミュニケーション
  • 課金の根拠
  • 予定どおりの，又は早期の契約の終了，及び他の関係者へのサービスの移管に関する活動及び責任
    • サービス提供者は，サービス提供者と顧客との間の SLA を支え，整合を図るため，サービスレベルについて供給者と合意しなければならない。
    • サービス提供者は，統括供給者及び再請負契約先供給者の役割，及びそれらの関係が文書化されていることを確実にしなければならない。
    • 再請負契約先供給者が契約上の義務を果たすよう，統括供給者が管理していることを，サービス提供者は検証しなければならない。
    • サービス提供者は，あらかじめ定めた間隔で供給者のパフォーマンスを監視しなければならない。
    • パフォーマンスは，サービス目標及びその他の契約上の義務に照らして測定しなければならない。
      結果は記録し，不適合の原因及び改善の機会を特定するためにレビューしなければならない。
      レビューは，契約が最新の要求事項を反映していることも確実にしなければならない。
    • 契約の変更は，変更管理プロセスによって管理しなければならない。
    • サービス提供者と供給者との間の契約上の紛争を管理するための，文書化された手順をもたなければならない。
    • 注記 1 供給者管理プロセスの適用範囲には，供給者の選定及びサービスの調達は含まない。
    • 注記 2 サプライチェーン関係のその他の例については，ISO/IEC TR 20000-3 を参照。

解決プロセス †

JIS Q 20000-1 > サービスマネジメントシステム要求事項 > 解決プロセス

インシデント及びサービス要求管理 †

問題管理 †

• 次の項目を規定する全てのインシデントに対する文書化された手順をもたなければならない。
  • 記録
  • 優先度の割当て
  • 分類
  • 記録の更新
  • 段階的取扱い

• 解決
• 終了
  • 記録作成から終了に至るまで，サービス要求の実現を管理するための文書化された手順をもたなければならない。
  • インシデント及びサービス要求はこれらの手順に従って管理しなければならない。
  • インシデント及びサービス要求の優先度付けを行う場合は，サービス提供者はインシデント又はサービス要求の影響及び緊急度を考慮しなければならない。
  • サービス提供者は，インシデント及びサービス要求管理プロセスに関与する要員が，関連する情報にアクセスし，使用できることを確実にしなければならない。
  • 関連する情報には，サービス要求管理の手順，既知の誤り，問題解決策及び CMDB を含めなければならない。
  • リリース及び展開管理プロセスから得られる，リリースの成功又は失敗，及び将来のリリースの期日に関する情報は，インシデント及びサービス要求管理プロセスによって使用されなければならない。
  • サービス提供者は，報告されたインシデント又はサービス要求の進捗状況について，継続的に顧客に情報を提供しなければならない。
  • サービス目標が達成されない場合は，サービス提供者は顧客及び利害関係者に通知し，手順に従って段階的取扱いを行わなければならない。
  • サービス提供者は，重大なインシデントの定義について文書化し，顧客と合意しなければならない。
  • 重大なインシデントは，文書化された手順に従って分類し，管理しなければならない。
  • トップマネジメントに，重大なインシデントについて通知しなければならない。
  • トップマネジメントは，重大なインシデントの管理に責任をもつ特定の個人が指名されていることを確実にしなければならない。
  • 合意されたサービスの回復後，改善の機会を特定するために，重大なインシデントをレビューしなければならない。

統合的制御プロセス †

構成管理 †

• CIの種類ごとの定義について文書化しなければならない。
• 各 CI について記録した情報は，効果的な管理を確実にし，
  少なくとも次を含まなければならない。

変更管理 †

変更管理方針を確立し，次を定義しなければならない。

リリース及び展開管理 †

サービス提供者は，リリースの頻度及び種類を記述した
リリース方針を策定し，顧客と合意しなければならない。

サービス提供 / デリバリ †

• JISでは、サービス提供
• ITILでは、サービス・デリバリ

ITIL 2011 Edition > 可用性、信頼性 †

• 可用性の管理活動
  • リアクティブ
    • サービス障害分析（SFA）

• プロアクティブ
  • 故障樹解析（FTA）
  • 単一障害点分析（SPOF分析）
  • コンポーネント障害インパクト分析（SFA）

• 可用性、信頼性の目標とKPI
  サービス・ライフサイクルの、サービス・デザインのプロセスに対応した目標とKPI

• サービスレベル管理
  • 目標：
  • KPI：目標を達成できなかったSLAの項目数

• キャパシティ管理
  • 目標：
  • KPI：処理能力不足に起因するインシデント数の削減率

• 可用性管理
  • 目標：
  • KPI：サービスの中断回数、及びそのインパクトの削減率

• ITサービス継続性管理
  • 目標：災害時にシステムを復旧し事業を継続させる。
  • KPI：災害を想定した復旧テストの回数

JIS Q 20000 > 容量・能力管理 †

容量・能力の予測

• ベースラインのモデル化
  • モデル化の第一段階
  • 達成されているパフォーマンスを正確に反映する，ベースラインのモデルの作成に使用する。
  • このベースラインのモデルが作成された場合，予測モデル化の開発が可能となる。

• 傾向分析
  収集された資源の活用及びサービスのパフォーマンス情報を使って完了する。

• 分析モデル化
  コンピュータシステムのパフォーマンスを分析するために数学的手法を用いる。

• シミュレーションのモデル化
  所定のシステム構成を基準にした
  トランザクション到着率など，
  離散事象のモデル化を伴う。

インシデントと問題の管理 †

JIS Q 20000 †

• インシデントと問題の違い

• 問題管理はインシデント管理と利害が対立する可能性がある

• インシデントと問題の用語の定義は以下の様になっている。

• インシデント（incident）
  サービスに対する計画外の中断，サービスの品質の低下，
  又は顧客へのサービスにまだ影響していない事象。

• 問題（problem）
  一つ以上のインシデントの根本原因。
  問題の記録が作成された時点では，
  通常はその根本原因は不明であり，
  問題管理プロセスは更なる調査に対して責任をもつ。

• プロセスの違い。

• インシデント及びサービス要求管理
  既知の誤り記録の作成、顧客対応（優先度付け、暫定対策 / 代替手段の提供）。

• 問題管理
  根本原因の特定、解決とサービスの回復、傾向分析と予防措置

• インシデント及びサービス要求管理
  
  • インシデントの段階的取り扱い
    • 機能的エスカレーション
      技術的に一次対応窓口で対応できないものを二次対応窓口へ。

• 階層的エスカレーション
  業務上の重要性や緊急性によって、
  上位にエスカレーションして対応を委ねる。

ITIL 2011 Edition †

• インシデント
  サービス中断や品質低下の事象、可能性

• プロセス
  識別 => 記録 => 分類 => 優先度決定 => 初期診断
  => エスカレーション => 調査と診断 => 解決と復旧 => クローズ

• エスカレーション
  • 機能エスカレーション
    • 専門知識を持つ部隊へのエスカレーション
    • 1次:サービスデスク
    • 2,3次:専門知識を持つ部隊

• 階層エスカレーション
  上位の管理者へのエスカレーション

• インシデント・モデル定義
  よくあるインシデントに対して以下を定義する。
  • 処理の実施事項
  • 時系列の手順
  • 対応責任者

• ワークアラウンド
  （根本原因の判明していない）インシデントのビジネスへの
  悪影響を最小限におさえるための、回避手順の提供。

• インシデント・レコード
  • 過去のインシデントを検索で容易に参照可能。
  • 履歴、カテゴリ、解決の措置

• CSFとKPI（→KGI）
  • 管理プロセスと、その運用の改善
  • 効率性 / 有効性の要点（CSF）/評価指標（KPI）

統合的制御プロセス †

構成管理 †

構成監査、切り戻しのための基準の提供

• 構成アイテム
  Configuration Item(CI)
  ITサービス提供のために必要なもの全て

• 確定版メディアライブラリ
  Definitive Media Library (DML)
  確定バージョン

• 構成モデル
  CI間の関係を含むサービス、資産、インフラのモデル

• 構成ベースライン
  合意済みのCIのスナップショット

• 構成管理DB(CMDB)
  

• 構成管理システム(CMS)
  CIを管理するツール

変更管理 †

• 変更モデル
  特定の変更の手順などが定義されたもの

• 変更要求
  • Request For Change (RFC)
  • インシデントの根本原因を取り除くため
    IT構成の変更が必要になった場合、作成し、
    変更管理プロセスに従って変更する。
  • 変更要求の種類
    • 標準（手順が確立している）
    • 緊急、通常（その他）

• 変更提案
  概要説明、ビジネス・ケース、スケジュールを含む変更提案書

• 修復計画
  変更失敗時の切り戻し計画

• 変更管理の7R
  • Raised:提起
  • Reason:理由
  • Return:見返り
  • Risk:リスク
  • Resource:リソース
  • Responsible:責任者
  • Relationship:関係

• 変更マネージャ
  変更管理の責任者

• 変更委員会
  Change Advisory Board (CAB)
  各ステークホルダーの代表者で構成

• 緊急変更委員会
  Emergency Change Advisory Board (ECAB)
  緊急時のCABより小規模な委員会

• 変更レコード
  単一の変更ライフサイクル詳細

リリース及び展開管理 †

• 単位

• リリースユニット
  通常、同時にリリースされるコンポーネント群

• リリースパッケージ
  １つのリリースに含まれる構成アイテム

• タイミング
  • ビッグバンリリース
    一斉リリース
    

• 段階リリース
  ユーザー、場所、時間で段階リリース

• 配置方法

• プッシュ
  中央から配信

• プル
  ユーザーが必要時に取得

その他 †

高信頼設計 †

• フェイル・XXXX

• バックアップサイト
  • 相互協定
  • コールド・スタンバイ
    ハード毎機材を持ち込む。
  • ウォーム・スタンバイ
    アクティブ・パッシブ的な
  • ホット・スタンバイ
    アクティブ・アクティブ的な

計算問題 †

単なる四則演算では。

稼働品質率 †

• 稼働品質率 = 迷惑回数 / システム資産規模
  • 単位規模辺りの迷惑回数。
  • 資産規模には、総運用費用を用いる。
  • 値が低い程、品質が高い。

• 計算

  システム	迷惑回数（回/年）		稼働時間（千時間/年）	総運用費用（百万円/年）	稼働品質率
  	オンライン	バッチ
  A	3	12	6	120	(3 + 12) / 120 = 0.125
  B	4	8	3	100	(4 + 8) / 100 = 0.12
  C	6	2	4	80	(6 + 2) / 80 = 0.1
  D	6	3	2	60	(6 + 3) / 60 = 0.15

TCO（Total Cost of Ownership） †

• 以下を全てを含む、システムの総所有コスト。
  • イニシャル（システム構築のハード・ソフトの導入費用など
  • ランニング（運用後の維持費・管理費・人件費など

• 3年稼働でTCOが最小のものはどれか

  費用	A案	B案	C案	D案
  ハードウェア導入費用	30	30	40	40
  システム開発費用	30	50	30	40
  導入教育費用	5	5	5	5
  ネットワーク通信費用 / 年	20	20	15	15
  保守費用 / 年	6	5	5	5
  システム運用費用 / 年	6	4	6	4

• 計算
  • 案１：30+30+5+20*3+6*3+6*3=161
  • 案２：30+50+5+20*3+5*3+4*3=172
  • 案３：40+30+5+15*3+5*3+6*3=153
  • 案４：40+40+5+15*3+5*3+4*3=157

システム改善案の評価 †

• 案

  評価項目		案１	案２	案３	案４
  効果	作業コスト削減	5	4	2	4
  	システム運用品質向上	2	4	2	5
  	セキュリティ強化	3	4	5	2
  リスク	作業コスト削減	4	1	5	1
  	作業コスト削減	2	4	1	5

• 重み

  評価項目		重み
  効果	作業コスト削減	3
  	システム運用品質向上	2
  	セキュリティ強化	4
  リスク	作業コスト削減	3
  	作業コスト削減	8

• 計算
  • 案１：5*3+2*2+3*4-(4*3+2*8)=3
  • 案２：4*3+4*2+4*4-(1*3+4*8)=1
  • 案３：2*3+2*2+5*4-(5*3+1*8)=7
  • 案４：4*3+5*2+2*4-(1*3+5*8)=-13

運用 †

ファシリティ †

参考 †

• ITIL 2011 Editionまとめ - Qiita
  https://qiita.com/itagakishintaro/items/eeb8b3d6df6d5e8dc21d

kikakurui.com †

• JIS Q 20000-1:2012 情報技術－サービスマネジメント－
  第１部：サービスマネジメントシステム要求事項
  https://kikakurui.com/q/Q20000-1-2012-01.html

• JIS Q 20000-2:2013 情報技術－サービスマネジメント－
  第２部：サービスマネジメントシステムの適用の手引
  https://kikakurui.com/q/Q20000-2-2013-01.html

ビジネス+IT †

• 【連載】ITILとは
  • （1）：ITIL、その本質
    https://www.sbbit.jp/article/cont1/14344
  • （2）：ISO化とJIS Q 20000の制定
    https://www.sbbit.jp/article/cont1/14428
  • （3）：ベストプラクティスと規格の関係
    https://www.sbbit.jp/article/cont1/15051

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.102 sec.