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

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

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 高度午前 - サービス・マネジメント - サービス・マネジメント へ行く。
  • 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 の変更後，
  それらが整合していることを確実にするために，維持しなければならない。
• サービス提供者は，あらかじめ定めた間隔で，
  サービス目標に照らして傾向及びパフォーマンスを監視しなければならない。
• 結果は，不適合の原因及び改善の機会を特定するために，記録し，レビューしなければならない。

• サービス提供者は，
  内部グループ又は顧客が提供するサービスコンポーネントについて，
  それらの活動及び二者間のインタフェースを定義する合意文書を，
  策定，合意，レビュー及び維持しなければならない。

• サービス提供者は，合意したサービス目標及びその他の合意したコミットメントに照らして，
  内部グループ又は顧客のパフォーマンスを，あらかじめ定めた間隔で監視しなければならない。

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

サービスの報告 †

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

...。

• サービス継続及び可用性の要求事項
  ...。
• サービス継続及び可用性の計画
  ...。
• サービス継続及び可用性の監視及び試験
  ...。

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

容量・能力管理 †

情報セキュリティ管理 †

• 情報セキュリティ基本方針
  ...。
• 情報セキュリティ管理策
  ...。
• 情報セキュリティの変更及びインシデント
  ...。

その他のプロセス †

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

関係プロセス †

• 事業関係管理
  • サービス提供者は，サービスの顧客，利用者及び利害関係者を特定し，文書化しなければならない。
  • 各顧客について，サービス提供者は顧客関係及び顧客満足を管理する責任をもつ個人を指名しなければならない。

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

解決プロセス †

• インシデント及びサービス要求管理
  次の項目を規定する全てのインシデントに対する文書化された手順をもたなければならない。
  （記録、優先度の割当て、分類、記録の更新、段階的取扱い、解決、終了）

• 問題管理
  • 問題を特定し，インシデント及び問題の影響を最小化
    又は回避するための文書化された手順をもたなければならない。
  • 問題のための手順では，次の項目を規定しなければならない。
    （識別、記録、優先度の割当て、分類、記録の更新、段階的取扱い、解決、終了）

統合的制御プロセス †

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

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

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

サービス提供プロセス > サービスレベル管理 †

可用性の管理活動 †

• リアクティブ
  • サービス障害分析（SFA）

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

可用性、信頼性の目標とKPI †

ITIL 2011 Editionのサービス・ライフサイクルの、
サービス・デザインのプロセスに対応した目標とKPI

• サービスレベル管理
  • 目標：
  • KPI：目標を達成できなかったSLAの項目数
• キャパシティ管理
  • 目標：
  • KPI：処理能力不足に起因するインシデント数の削減率
• 可用性管理
  • 目標：
  • KPI：サービスの中断回数、及びそのインパクトの削減率
• ITサービス継続性管理
  • 目標：災害時にシステムを復旧し事業を継続させる。
  • KPI：災害を想定した復旧テストの回数

サービス提供プロセス †

JIS Q 20000-2 > 容量・能力の予測 †

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

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

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

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

ITIL 2011 Edition > キャパシティ管理 †

解決プロセス †

JIS Q 20000-1 > サービスマネジメントシステム要求事項 †

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

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

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

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

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

• プロセスの違い。

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

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

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

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

• ITIL 2011 Edition

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

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

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

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

統合的制御プロセス †

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

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

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

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

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

• 構成管理DB(CMDB)
  CIを管理するDB

• 構成管理システム(CMS)
  構成管理用のツール、DB

• 変更管理
  

• 変更要求
  • 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） †

単なる四則演算では。

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

• ３年稼働で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

運用 †

ファシリティ †

参考 †

• 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

     

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.081 sec.