---
# System prepended metadata

title: ITIL PPO研修　2022/08/22-26

---

# ITIL PPO研修　2022/08/22-26

講師：木村祐さん　tasuku.kimura@earnest-tech.co.jp

オンライン試験のみ

Shimizu Makotoさん：ITベンダ。社内向けIaaSの運用改善ミッション。

- 不合格の場合、再試験は可能。
- ITIL4
    - 2022年10月までにCDSが日本語化予定、2023年3月～6月くらいに他も日本語化していく見込み。その後、半年くらいは旧Verが継続されるはず。
    - つまり2023年12月まで現行v3が動いていく見込み。

## PPOの概要

- 目的(Purpose)：長期、最終目標。
- 達成目標(Objective)：短期達成目標。
---
- 有用性と保証＝価値創出の要素。
- SSサイクルのサービス企画：QCDの定義(Quality, Cost, Delivery)。
- 事業(Business)：顧客or社内事業部門。
- 顧客向けサービスは、支援サービスによって成り立っている。
    - 顧客向けサービス：Email
        - 支援サービス：
            - サーバ管理
            - NW管理
            - Exchange
            - User Support
- 4つのP：People, Process, Product, Partner
    - 改善提案はすべてのPをケアするものが最善だが、優先順位は下記。
        1. Process
        2. People
        3. Product (Tools)：★ツールのみ改善する回答は5点回答になりにくい
- Design Coordination：PMOがデザインプロセスの基準や定義を統一する。
- TCO Total Cost of Operation 総所有コスト
- ★KPIの表現：良いことが増える(向上率)、悪いことが減る(削減率)、改善、という表記が正解。～の数、～の割合、で終わっている表現は不正解(OSAではそのような表現もある(ITILのバグ？))。～を実施すること、という表記もあり(ゼロイチKPI)
- ★傾聴はGood. 話し合う、相談する。
- 良いデザイン → インシデント削減 → 運用コストの削減
- 新技術の調査はGood.

## キャパシティ管理

- 事業キャパシティ管理(BCM)：事業目線の需要や計画をサービスに反映。
- サービスキャパシティ管理(SCM)：サービス目線(End-to-end)の管理。
- コンポーネントキャパシティ管理(CCM)：技術要素目線の管理。
- --
- Keywords：キャパシティ・パフォーマンス(容量・性能管理)
- 人的資源の配置、スキルレベル管理を含む。
- 合意済み要件(SLA)を提供する - 需要管理との連携が必要。
- ムーアの法則：技術革新に合わせて適切なタイミングで対応すべき。
- キャパシティ計画＝投資計画
- ★コンポーネントキャパシティ管理だけに重点を置いた選択肢は5点になりにくい。他の2要素、特にサービスキャパシティ管理を考慮した選択肢がBetter.
- 耐障害弾力性の設計：キャパ管理と可用性管理が連携してデザイン段階で行う。
- ★モニタリングのしきい値はSLAや過剰使用量より低く設定し、それらを超える前に是正処理を取る。
- Application Sizing：Design/Transitionで終了すべきプロセス。モデル化技法を使う。
    - 運用開始以降はMonitoring, Tuningで対応すべき。(ワークブックp.95)
- ベースライン作成：現在のパフォーマンスをモデル化。仮定(What if?)を分析できるようになる。
- モデル化技法：
    - 傾向分析：過去のデータ。直線的なデータに有効。
    - 分析モデル化：数学的技法でシステムの動作を表現。
    - シミュレーションモデル化：正確だがコストが高い。
- --
ISではService Design teamがキャパシティ管理をしていない？
→ 人員の稼働率、A365などの技術要素は渓さんが関わっている！

## 可用性管理

- 可用性管理：通常運用 ⇔ 事業継続性管理(BCP)：災害時
    - これらは別プロセスだが、対策が共通なことが多いので連携する。
- サービス可用性：サービス目線(End-to-end)。
- コンポーネント可用性：技術要素目線。
    - 重要度：サービス＞＞コンポーネント
- 障害の発生(可用性の低下)は避けられない場合もある。それへの対応の方がユーザ満足度に影響が大きく、重要である。
- 可用性管理は設計の初期段階でサービスレベル管理と連携し、事業の要件を特定すべき。
- 信頼性：サービス中断無しで稼働した時間。(⇔可用性はPercentage)
    - MTBF：Mean time between failures
    - MTBSI：Mean time between service incidents
- 保守性：障害をどれだけ早く復旧できるか
    - MTRS：Mean time to restore service
    - MTTR：Mean time to repair (一般に広く使われているが、修理完了してもサービスが利用可能にならなければ意味が無いので、ITILはMTRSの使用を推奨。)
- サービス性：SLA, OLA, UC(サプライヤとのUnderpinning Contract)を守る能力。
- SFA-サービス障害分析：可用性管理へのインプット。
- VBF-Vital Business Factor 重要事業機能。VBFの可用性が重要。
- CFIA-Component Failure Impact Analysis. SPOF(Single Point of Failure)の洗い出し。
- FTA-Failure Tree Analysis 故障樹分析。AND,OR gateなどを使う。
- PSO-Projected Service Outage サービス停止計画：変更等を行うために通常のサービス提供時間の中で停止時間を設定する。(24365サービスの場合、デザイン段階では決められないことが多い。)

## ITサービス継続性管理 (ITSCM)

- ITSCMは事業継続性管理(BCM)を支援するプロセス。
- BCM,BCP策定は事業が主導すべき。ITSCMはサポート。
- リスク管理のために事業、可用性管理、情報セキュリティ管理と連携する。
- ITSCMは「災害」(インシデント管理の範囲を超えるイベント)に対処する。
- ITSCMライフサイクル
    1. 開始
    2. 要件と戦略：BIA,リスクアセスメント
    3. 導入
    4. 継続的運用
    5. 発動(災害時)
- BIA Business Impact Assessment ビジネスインパクト分析：事業への影響を定量化。
- M_o_R Management of Risk リスクの管理
- テスト
    - 初期テスト：計画策定時に実施。
    - Walk through test：計画策定時に机上シミュレーションの確認を実施。
    - 全体テスト：少なくとも毎年必ず実施。抜き打ちでもあり。
    - 部分テスト：全体テストに追加できるが、全体テストの代わりにはなり得ない。
    - シナリオテスト：シナリオを定義して実施。網羅的なテストはできない。
- 復旧オプション：要件に応じて適切に選択する。
    - 手作業ワークアラウンド
    - 相互協定：他組織と事前に握っておく。
    - 段階/中間的/高速復旧
    - 即時的復旧

## 情報セキュリティ管理

- CIA: Cofidentiality, Integrity, Availabilityの担保。
- 情報セキュリティ方針：事業とITのトップが承認。最低年に一回はレビューする。
- セキュリティの責任は事業とITが共同で負う。
- サービスプロバイダのタイプ
    - タイプ１：内部プロバイダ(部門別にITチーム)
    - タイプ２：シェアードITサービス部門
    - タイプ３：外部プロバイダ
- タイプ1,2では会社全体で情報セキュリティ方針を推進する。
- タイプ3では顧客企業の情報セキュリティ方針は機密事項。
- 脅威への対策：
    - 予防：アクセス権の限定など。
    - 低減：損害を最小限にとどめる。定期バックアップ、侵入テストなど。
    - 検出：モニタリング、アラート。
    - 抑制：被害自体or拡がりを抑制。何度もPWを間違えたらブロック、検出後にロックダウンなど。
    - 是正：損害の修正、処置。バックアップリストア、ロールバック
- ★RACI：試験問題ではAが最重要。


## 需要管理

- 事業活動パターン分析 PBA Pattern of Business Activities
- ユーザプロファイル分析。PBAを組み合わせて作成する。
- キャパシティ管理と密接に連携。
- サービスパッケージ
    - コアサービス：ビジネスに必須。eg.宿泊サービス
    - 実現サービス：コアサービスを実現するために必須。eg.部屋、ベッド、チェックイン
    - 強化サービス：オプション的なもの。eg.朝食、大浴場
- 需要管理活動の流れ：
    1. PBAを識別、文書化。
    2. PBAを含む ユーザプロファイルの定義。分析-サービスへの需要パターン特定。
    3. 需要パターンを満たすキャパシティを用意。
        - 準備できない場合、需要を管理or影響を与える対策。eg.格差課金

## 役割と責任

- プロセスオーナー(A)
- プロセスマネージャー
- プロセス実務者(R)
- 兼務も可

## 技術と導入に関する検討事項

- ツールよりもプロセスの方が重要。
- ツールは統合されたものが良い。(複数プロセス)
- ツールベンダーによるサポートが望ましい。
- 運用要件(MSC)を80%満たせば良い。
    - M：100%必要
- カスタマイズは好ましくない。
- 可能なら既存ツールを再利用する。
- 事業要件を優先する。
- 導入で影響を受ける相手とコミュニケーションをとる。
- 対応グループを立ち上げ、サポートを得られるようにする。
- 上級マネジメントからコミットメントを得る。
- アーキテクチャは個別最適ではなく全体最適を目指す。
- 技術のカテゴリ：(これらがサービスを形成する)
    - アプリケーション
    - データ
    - インフラ
    - 環境
- CSIアプローチ：ビジョンを短期目標にブレイクダウンして目標達成を目指す。

## 模擬問題のポイント

### 模擬試験1
#### 問題5
- キャパシティ管理において新技術の調査はGood.ムーアの法則に取り残されない計画が必要。

#### 問題7
- キャパシティ管理担当者は技術的ナレッジが必須。
- 可用性、セキュリティ、ITSCM管理担当者はリスクアセスメント能力が必須。

### 模擬試験2
#### 問題2
- 既存ベンダを優先しつつ、ベンダロックしないソリューションが良い。

#### 問題4
- PSOはデザイン段階では決められない。
- デザイン段階での重要性は、PBA理解＞テスト計画。

#### 問題5
- BCM, BCPは事業が主体となって定めるべきで、IT部門はサポートする。



