この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは植木和樹です。本日は先日行ったITIL社内勉強会の資料を公開します。
ITIL（Information Technology Infrastructure Library）はITサービスマネジメントにおけるベストプラクティスで・・・という説明で始まると、多くのエンジニアの方々は「面倒ください」という第一印象を持たれるようです。クラメソでも多分に漏れずそんな感じでした。
しかしAWSエンジニアのメンバーも増えてきたことから体系的なサービス提供プロセスというのが必要となってきたことと、安定してインフラ保守運用するためには構築段階からITIL（運用保守）を意識した仕組みづくりを理解してもらう必要があると感じていました。
というわけで、社内のAWSシニアエンジニア（主にSA Proな方々）を招いてITILとはなにか？という勉強会を行いました。
勉強会の進め方
ITILの意義や細かな説明をくどくどすると嫌がられそうだったので、説明をザックリ簡略化しました。
まずはじめにITILを構成する各プロセスの関係を図でみてもらいました。最初に視覚に訴えるのは大事です。参考にしたサイトは下記の通りです。
- ITILv2・・・ITILとは？: ITIL | NEC
- ITILv3・・・システム管理者の定番資格『ITIL』 | 株式会社ユニリタ
次にITILv2のサービス・サポートとサービス・デリバリーの各機能・プロセスについて説明しました。各プロセスの説明についてもポイントを3点に絞りました。
- プロセスの概要
- プロセスの説明を一言で説明しました。そのプロセスで重要となるキーワードもここで解説しました。
- KPI
- なにを定量的に評価するのか、計測内容がわかるとプロセスの理解が深まると思いいくつか紹介しました。
- CMでの取り組み
- クラスメソッドではそのプロセスがどのツールや仕組みにあたるのか、またAWSで提供されている関連サービスを紹介しました。
下記は各プロセスごとに上記ポイント3点をまとめたものとなります。実際は質問を受けつつ口頭でちょいちょい補足いれてます。あとプロセスの説明は、保守運用業務視点でわかりやすいという理由でITILv2ベースにしました。
1. サービス・サポート
1.1 サービスデスク
概要
- ユーザーに対するSPOC（Single Point Of Contact）
KPI
-
- 顧客満足度
- サービスデスクで解決されたコール数、一次解決率
- SLAを超過してしまったコール数
- 二次対応以降へエスカレーションされたコール数
CMでいうと
- オペレーションチーム
1.2 インシデント管理
概要
- インシデントの検知と記録
- 障害の調査、診断、復旧
- ワークアラウンド
KPI
- 一次解決率
- インシデント解決までの平均時間
- インシデントでなくサービス要求だった割合（監視一時停止や問い合わせ）
CMでいうと
- Zendesk
- OTRS
1.3 問題管理
概要
- 問題の根本解決
KPI
- 解決された問題の件数
- 未クローズのままの問題件数
- 問題が解決されるまでの平均時間
CMでいうと
- JIRA
- Backlog
1.4 変更管理
概要
- 変更プロセスの標準化、手順化
- 変更承認
KPI
- 変更の実装が失敗した件数
- 変更のバックログ数
CMでいうと
- 社内レビュー
- Stash（Pull Request）
- AWS Code Pipeline（に期待）
1.5 リリース管理
概要
- リリース作業の計画
- 関係する要員の確保と調整（オペトレ）
- 構成管理の更新
KPI
- 構成管理に保管されていないソフトウェアの数
- リリースの失敗件数
- リリース時間
CMでいうと
- リリース前レビュー（顧客含む）
- AWS CodeDeploy
1.6 構成管理
概要
- 構成管理データベース
- ライセンス管理
KPI
- 承認されていない構成アイテムの割合
- 不正確な構成アイテムの割合
CMでいうと
- Stash
- AWS Code Commit
- Ansible, Chefなどのツール類
- AWS Config
2. サービスデリバリ
2.1 サービスレベル管理
概要
- サービスカタログ
- サービスレベル合意書
- 社内別部署（OLA）、社外ITベンダー（請負契約)
- 顧客との定期レビュー
KPI
- サービスレベル未達成件数
- 社外ITベンダー要因の未達成件数
- SLAでカバーされていないサービスの件数
CMでいうと
- 個別契約書
- 運用支援サービスメニュー
- 協力会社からのサービス仕様書
2.2 可用性管理
概要
- 障害の予知、検出、診断、解決
- リスク分析
KPI
- サービスのダウンタイム
- インシデント発生から最初のアクションが起こされるまでの時間
- MTTR,MTBF
CMでいうと
- Design for Failure
- CloudWatch Logs
- HOOT24
2.3 ITサービス継続性管理
概要
- 災害発生時を想定としたサービス継続
- リスク管理
KPI
- カバーされないITサービス数
CMでいうと
- AZ障害の想定
- リージョン障害の想定
2.4 キャパシティ管理
概要
- サービス稼働率
- 利用状況の監視、分析、チューニング
- 監視ツール
KPI
- パフォーマンス不足に起因するSLA違反の数
- パフォーマンス不足に起因するインシデント件数
CMでいうと
- CloudWatch
- HOOT Lite
2.5 ITサービス財務管理
概要
- サービス提供にかかる費用
- 費用対効果の高いリソースの管理
KPI
- 予算の正確性
- コスト（TCO）
CMでいうと
- CMP（クラスメソッド メンバーズポータル）
- 予算と利用費の差異
- リザーブドインスタンス
- 料金超過アラーム（β）
3 セキュリティ管理
3.1 セキュリティ管理
概要
- セキュリティ方針の策定、導入
- セキュリティ違反の監視
KPI
- セキュリティ違反の件数
- 会社のセキュリティ方針と実際のセキュリティ管理の不適合件数
CMでいうと
- sshログインサーバー
- プロキシーサーバー
- 鍵管理方針
- CloudTrail
ITIL取り組みについて補足説明
Trusted Advisorを使いましょう！
セキュリティやコスト見直し、可用性のチェック等検討すべき点がたくさんありますがTrusted Advisorを使うと包括的にチェックできて便利です。システムを健全に保つ第1歩として、まずはTrusted Advisorをオールグリーンにするのが良いと思います。
人の動きを意識する
業務を改善しようとすると「◯◯というツールを導入しよう！」という話になりがちです。また導入したけど定着しないというケースも多いです。ツール整備だけでなく、契約書・手順書・業務プロセスフロー、メンバー教育などの整備も重要です。
またツールを導入してプロセスを改善する場合は、ツールの両端に「人」を配置した図を描いてみましょう。そのツールと人との関わり、つまりそのツールを用いて誰がいつ入力するのか？ツールからの出力を受け取った人が次になにをするのか？を意識すると良いと思います。
まとめ
勉強会終了後、参加してもらった某Apple信者の有力者からは「ITILは面倒だと思っていたけど興味がわいた」という感想をいただきました。またITILの各プロセスを理解してもらったことで、ここ1年くらいかけて取り組んできた社内業務インフラ整備の意図もわかっていただけたようです。うれしいですね。ITILという言葉だけ聞くとなかなか取っ付きづらいですが「変更管理」「リリース管理」「構成管理」あたりの内容は、アプリケーション開発者の方には興味を持っていただけると思います。
また「ITIL＝大量の文書」という誤解もあるようです。クラスメソッドではうまくツールやシステム化することで、エンジニアが興味を持って取り組めるようにしてきています。上長承認のためのハンコリレーを導入することはありません。
【クラメソ社員の方へ】勉強会に参加できなかった方へ第2回ITIL勉強会を予定しています。ぜひぜひ参加して、サービスの品質向上に向けて楽しい業務改善に取り組んでいきましょう！
0
