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

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

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 高度午前 - サービス・マネジメント - サービス・マネジメント へ行く。
  • 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部：実践のための規範

目次 †

JIS Q 20000-1, 2で共通

• 序文
• サービスマネジメントシステムの適用の手引
• 適用範囲
  • 一般
  • 適用
• 引用規格
• 用語及び定義
• サービスマネジメントシステム（SMS）の一般要求事項
  • 経営者の責任
  • 他の関係者が運用するプロセスのガバナンス
  • 文書の運用管理
  • 資源の運用管理
  • SMS の確立及び改善
• 新規サービス又はサービス変更の設計及び移行プロセス
  • 一般
  • 新規サービス又はサービス変更の計画
  • 新規サービス又はサービス変更の設計及び開発
  • 新規サービス又はサービス変更の移行
  • 文書及び記録
  • 権限及び責任
• サービス提供プロセス
  • サービスレベル管理
  • サービスの報告
  • サービス継続及び可用性管理
  • サービスの予算業務及び会計業務
  • 容量・能力管理
  • 情報セキュリティ管理
• 関係プロセス
  • 事業関係管理
  • 供給者管理
• 解決プロセス
  • インシデント及びサービス要求管理
  • 問題管理
• 統合的制御プロセス
  • 構成管理
  • 変更管理
  • リリース及び展開管理

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 > 設計・移行 †

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

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 > プロセス †

サービス提供プロセス †

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の種類ごとの定義について文書化しなければならない。
• 各 CI について記録した情報は，効果的な管理を確実にし，
  少なくとも次を含まなければならない。
  • CIについての記述
  • CIと他の CI との関係
  • CIとサービスコンポーネントとの関係
  • 状態
  • 版
  • 場所
  • ひも（紐）付けされた変更要求
  • ひも（紐）付けされた問題及び既知の誤り

• CIは一意に特定し，CMDB に記録しなければならない。
  • CIの版を記録，制御及び追跡するための文書化された手順をもたなければならない。
  • CMDB は更新アクセスの制御を含め，その信頼性及び正確性を確実にするために管理しなければならない。
  • サービス提供者は，あらかじめ定めた間隔で，CMDB に保管されている記録を監査しなければならない。
  • CMDBからの情報は，変更要求のアセスメントを支援するために，変更管理プロセスに提供しなければならない。
  • CIの変更は，CI 及び CMDB にあるデータの完全性を確実にするため，追跡可能かつ監査可能でなければならない。
  • CMDBに記録されている CI の原本
    • は，構成記録が参照している，セキュリティが保たれた物理的又は電子的な格納庫に収納しなければならない。
    • には，少なくとも，文書，ライセンス情報，ソフトウェア，
      及び入手可能な場合は，ハードウェア構成の配置図を含めなければならない。

• 制御の程度は，サービスの要求事項及び CI に関連するリスクを考慮して，
  サービス及びサービスコンポーネントの完全性を維持するものでなければならない。
• 欠陥がある場合には，サービス提供者は必要な処置をとり，とった処置について報告しなければならない。
• 影響を受ける CI の構成ベースラインは，稼働環境へのリリースの展開に先立ってとらなければならない。
• 構成管理プロセスと財務資産管理プロセスとの間には定義されたインタフェースをもたなければならない。
  注記 構成管理プロセスの適用範囲には，財務資産管理を含まない。

変更管理 †

• 変更管理方針を確立し，次を定義しなければならない。
  • 変更管理が制御している CI
  • サービス又は顧客に重大な影響を及ぼす可能性のある変更を判断する基準

• 影響
  • サービスの廃止は，重大な影響を及ぼす可能性のあるサービス変更として分類しなければならない。
  • サービス提供者から顧客又は他の関係者へのサービスの移管は，重大な影響を及ぼす可能性のある変更として分類しなければならない。

• 変更要求
  • サービス又はサービスコンポーネントへの全ての変更は，
    変更要求を用いて提起しなければならない。
• 変更管理方針で定義された，CI に対する他の全ての変更要求は，
  変更管理プロセスを用いて管理しなければならない。
  • 変更要求は定義された適用範囲をもたなければならない。
  • 全ての変更要求は記録し，分類しなければならない。
  • 変更要求を記録し，分類し，評価し，承認する文書化された手順をもたなければならない。
  • 変更要求は，変更管理プロセス及びその他のプロセスからの情報を用いて評価しなければならない。
  • 変更要求は，傾向を検知するため，あらかじめ定めた間隔で分析しなければならない。
  • サービス又は顧客に重大な影響を及ぼす可能性があるとして分類された変更要求は，
    新規サービス又はサービス変更の設計及び移行プロセスを用いて管理しなければならない。

• 緊急変更
  • サービス提供者は，緊急変更の定義について文書化し，顧客と合意しなければならない。
  • 緊急変更を管理する文書化された手順をもたなければならない。

• 利害関係者
  サービス提供者及び利害関係者は，
  • 変更要求の受入れについて決定しなければならない。
  • 有効性について変更をレビューし，合意した処置をとらなければならない。

• 変更スケジュールは，リリース展開の計画立案の基礎として使用しなければならない。

• 承認
  • 意思決定では，以下を考慮しなければならない。
    • リスク
    • サービス及び顧客への潜在的影響
    • サービスの要求事項
    • 事業利益
    • 技術的実現可能性
    • 並びに財務的な影響

• 承認された変更
  • は，開発し，試験しなければならない。
  • の詳細及びその展開の
    期日案を含む変更スケジュールを策定し，
    利害関係者に周知しなければならない。

• 成功・失敗

• 成功
  変更の展開の成功後にCMDBの記録を更新しなければならない。

• 失敗
  • 失敗した変更を元に戻す，又は修正するために
    必要な活動を計画し，可能な場合には，試験しなければならない。
  • 変更が失敗した場合には，元に戻すか，又は修正しなければならない。
  • 失敗した変更は，調査し，合意した処置をとらなければならない。

• 分析から導き出された結果及び結論は記録し，
  改善の機会を特定するためにレビューしなければならない。

リリース及び展開管理 †

• 方針・計画

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

• サービス提供者は，以下について，顧客及び利害関係者とともに計画を策定しなければならない。

• 新規サービス又はサービス変更，
• 及びサービスコンポーネントの稼働環境への展開

• 計画立案には，各リリースの展開の日付，成果物及び展開方法を含めなければならない。

• 緊急のリリース
  • サービス提供者は，緊急のリリースの定義について文書化し，顧客と合意しなければならない。
  • 緊急のリリースは緊急変更手順とのインタフェースが図られている文書化された手順に従って管理しなければならない。

• リリースは，展開の前に構築し，試験しなければならない。
  • リリースの構築及び試験には，制御された受入れ試験環境を使用しなければならない。
  • 受入れ基準
    • リリースの受入れ基準について，顧客及び利害関係者と合意しなければならない。
    • リリースは，合意した受入れ基準に基づいて検証し，展開前に承認しなければならない。
    • 受入れ基準を満たしていない場合には，サービス提供者は
      必要な処置及び利害関係者への展開について決定しなければならない。

• 稼働環境に展開
  リリース展開の場合にハードウェア，ソフトウェア及びその他のサービスコンポーネントの
  完全性が維持されるように，リリースを稼働環境に展開しなければならない。

• 成功・失敗
  • リリース展開の失敗を元に戻す，又は修正するために必要な活動を
    計画し，可能な場合には，試験しなければならない。
  • リリース展開が失敗した場合には，元に戻すか，又は修正しなければならない。
  • リリースの失敗は調査し，合意した処置をとらなければならない。
  • リリースの成功又は失敗は，監視し，分析しなければならない。

• 測定・分析
  • 測定には，リリース展開後のリリースに関連するインシデントを含めなければならない。
  • 分析には，リリースの顧客への影響のアセスメントを含めなければならない。
  • 分析から導き出された結果及び結論は記録し，改善の機会を特定するためにレビューしなければならない。

• 他プロセスとの連携
  • 計画立案は変更管理プロセスと連携しなければならず，関連する
    変更要求，既知の誤り及びリリースによって終了する問題の参照を含めなければならない。
  • リリースの成功又は失敗に関する情報，及び将来のリリース期日についての情報を，
    変更管理プロセス，並びにインシデント及びサービス要求管理プロセスに提供しなければならない。
  • 変更要求がリリース及び展開計画に及ぼす影響のアセスメントを支援するため，
    変更管理プロセスに情報を提供しなければならない。

JIS, ITILプロセス †

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

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

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

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

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

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

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

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

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

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

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

容量・能力の予測

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

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

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

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

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

JIS Q 20000-1, 2 †

• インシデントと問題の違い（JIS Q 20000-1）

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

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

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

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

• プロセスの違い

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

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

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

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

ITIL 2011 Edition †

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

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

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

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

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

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

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

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

サービス・サポート（統合的制御プロセス †

ITIL 2011 Edition > サービス資産管理および構成管理 †

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

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

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

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

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

• 構成管理DB(CMDB)
  

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

ITIL 2011 Edition > 変更管理 †

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

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

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

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

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

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

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

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

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

ITIL 2011 Edition > リリース及び展開管理 †

• 単位

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

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

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

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

• 配置方法

• プッシュ
  中央から配信

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

その他 †

高信頼設計 †

• フェイル・XXXX

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

その他 †

運用 †

データ管理者の役割 †

• データ管理者（DA : Data Administrator）
  • DBMSの評価・選択、論理データベース設計
  • データ項目の設計・管理・標準化
  • 個々のデータ項目へのアクセス権の管理

• データベース管理者（DBA : DataBase? Administrator）
  データベースの構築と運用・保守を行う。
  • データ増加を見積もり、ディスク増設など計画・実施
  • データベースのパフォーマンス・チューニング
  • 障害時、データベースの復旧と整合性のチェック

データベースのバックアップ †

更新頻度の少ないデータベースのフルバックアップ取得間隔を２倍に伸ばした場合。

• ×：フルバックアップ１回あたりの容量が2倍になる。
• ×：フルバックアップ１回あたりの容量が1/2倍になる。
• ×：フルバックアップ１回あたりの時間が2倍になる。
• 〇：ログを用いた復旧時間が2倍になる。

データベースのバックアップと復旧についての知識があればOK

ITILのサービスデスク配置方法 †

• 中央サービス・デスク
  コロケーションによる同床化（単一の拠点に集約化）。

• フォロー・ザ・サン
  • 地理的に分散したサービス・デスクを組み合わせて２４時間体制を引く。
  • フォロー・ザ・サンでは（、昼間帯）、夜間帯のシフトは組まない。

• バーチャル・サービス・デスク
  インターネットを使用して単一のサービス・デスクのように運用。

ファシリティ †

UPS設備の冗長化に関するティア構成 †

JDCC（日本データセンター協会）が制定する
「データセンター・ファシリティ・スタンダード」
において、UPS設備の冗長化に関するティア構成がある。

• ティア 1
  • UPSの冗長性 : N
  • 瞬間的な停電に対し、コンピューティング・サービスを継続して提供できる設備がある。

• ティア 2
  • UPSの冗長性 : N
  • 長期的な停電に対し、コンピューティング・サービスを継続して提供できる設備がある。

• ティア 3
  • UPSの冗長性 : N + 1
  • UPSのメンテナンスなど、UPS設備の一時停止時も、
    コンピューティング・サービスを継続して提供できる設備がある。

• ティア 4
  
  • UPSの冗長性 : N + 2
  • UPSのメンテナンスなど、UPS設備の一時停止時に、
    更に、一部のUPS設備に障害が発生しても、
    コンピューティング・サービスを継続して提供できる設備がある。

計算問題 †

稼働品質率 †

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

• 計算

  システム	迷惑回数（回/年）		稼働時間（千時間/年）	総運用費用（百万円/年）	稼働品質率
  	オンライン	バッチ
  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

オペレータの必要人数 †

オペレータの必要人数

• シフト勤務条件
  • サービス
    24時間365日
  • 勤務
    週休2日(5/7)
  • シフト
    • 3シフト（８時間 / 人）
    • 各シフトで２人以上

• 計算
  • シフト
    3 * 2 = 6人
  • 勤務
    6 / (5/7) = 42 / 5 = 8.4人 = 9人

バックアップに必要な磁気テープ数 †

• 要件
  • バックアップ
    • 月初にフルバックアップ、媒体は１本必要。
    • 翌月まで、差分バックアップ、媒体は１本 / 月必要。
  • 復元
    • 6か月前の同一日までのデータを復元
    • 同一の月末日（29 - 31）が無い場合、月末日の状態に復元
    • 例えば、10/31の場合、4/30 - 10/31の指定日のデータを復元可能。

• 計算
  • 6か月分ではなくて7か月分を保持
  • 7 * (1 + 1) = 14

参考 †

• 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.140 sec.