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

講師：木村祐さん　[e-mail]

オンライン試験のみ

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部門はサポートする。