サービスマネジメント
作ったシステムを、約束した水準で毎日動かし続けるための仕組みです。止まったら早く戻すインシデント管理、原因を断つ問題管理、安全に変える変更管理の役割の違いがよく問われます。
要点
サービスマネジメント
- 目的と考え方
- サービスを計画・設計・移行・提供・改善して価値を届けるのがサービスマネジメント。この5つがサービスライフサイクルの段階。
- サービスは機器・ソフト・人などのサービスコンポーネントを組み合わせて作り、サービス品質で評価される。
- サービスマネジメントシステム
- その仕組みを作り、維持し、改善し続けるための要求事項を定めた規格がJIS Q 20000（ISO/IEC 20000）。
- ITIL
- ITILはITサービスの運用の成功事例をまとめたフレームワーク。世界で事実上の標準として使われている。
- SLA
- SLAはサービスの内容と水準を、提供者と顧客の間で取り決めた合意書。サービス可用性や応答時間を数で約束する。
- 目標の値がSLO、実際に測る指標がSLI。SLIが月の稼働率なら、SLOは「99.9%以上」のように決める。
サービスマネジメントシステムの計画及び運用
- 計画と支援
- PDCAで仕組みを回し、資源・力量・文書化した情報を整える。品質マネジメントの規格はJIS Q 9001。
- サービスの計画
- 要求事項と使える資源を考え、変更要求や新サービスの提案に優先順位を付ける。全サービスの一覧がサービスポートフォリオ。
- ポートフォリオのうち、計画中・開発中のものがサービス・パイプライン。
- サービスカタログ管理
- 顧客に出しているサービスの内容・成果・依存関係をサービスカタログにまとめ、最新に保つ。
- 資産管理
- サービスに使う機器やソフトを資産として管理する（ITAM）。ソフトの導入数とライセンスの数を照らすのがSAM。
- 構成管理
- 管理対象の機器やソフト（構成品目、CI）の版と関係を記録し、実物と合っているか定期的に確かめる。
- 事業関係管理
- 顧客との関係を保ち、顧客満足を測り、苦情を受け付けて対応する。
- サービスレベル管理
- 顧客とSLAを合意し、サービスレベル目標に対する実績を決まった間隔で監視・報告する。
- 供給者管理
- 外部の供給者とは契約、社内の内部供給者とは合意文書で水準を決めて監視する。クラウドサービスの利用もここで扱う。
- サービスの予算業務及び会計業務
- サービスの費用を予算にし、実績と比べて管理する。導入から運用・廃棄までにかかる総額がTCO。
- 需要管理
- サービスの今の需要を把握し、将来の需要を予測する（需要予測）。
- 容量・能力管理
- CPUやディスクの使用率を監視し、しきい値を超える前にキャパシティを増やす計画を立てる。
- 変更管理
- 変更要求（RFC）を記録し、リスクと効果を見て承認する。失敗に備えてロールバック（切り戻し）の手順も用意する。
- 決まった手順で済む標準変更、急ぐ緊急変更などの種類がある。助言するのがCAB、実施後の見直しがPIR。
- サービスの設計及び移行
- 新サービスを要求事項どおりに設計し、サービス受入れ基準を満たすかを試験してから本番へ移す。
- 移行計画を立て、移行リハーサルで確かめて移行判断をする。運用部門へは運用引継ぎをする。
- リリース及び展開管理
- 試験済みの変更をリリースにまとめ、稼働環境へ展開する。急ぐときは緊急リリースにする。
- インシデント管理
- インシデントは計画外の停止や品質の低下。原因の究明より先に、回避策などでサービスを早く元に戻す。
- 専門部署へ回すのが機能的エスカレーション、上位の管理者へ上げるのが階層的エスカレーション。
- 重大なインシデントは別に定めた手順で管理し、トップマネジメントに知らせる。
- サービス要求管理
- アカウント作成やパスワードの再設定など、障害ではない利用者の依頼（サービス要求）を手順どおりに実現する。
- 問題管理
- インシデントの傾向から問題を見つけ、根本原因を突き止めて再発を防ぐ。原因と回避策が分かったものが既知の誤り。
- サービス可用性管理
- 可用性（稼働率）＝MTBF÷（MTBF＋MTTR）。故障しにくさが信頼性、直しやすさが保守性。
- サービス継続管理
- 災害などに備えてサービス継続計画を作り、定期的に試験する。会社全体の計画はBCP（事業継続計画）。
- 何時間で戻すかがRTO、どの時点のデータまで戻すかがRPO、どの水準まで戻すかがRLO。
- 予備機を動かしておくホットスタンバイ、止めておくコールドスタンバイ、その中間がウォームスタンバイ。
- 情報セキュリティ管理
- 情報セキュリティ方針と管理策を決めて実施し、セキュリティのインシデントに対応する。規格はISO/IEC 27000シリーズ。
パフォーマンス評価及び改善
- パフォーマンス評価
- 要求事項に照らしてサービスの有効性を測り、傾向情報を含めたサービスの報告を作る。
- 改善
- 要求を満たさない不適合は修正して是正処置をとる。再発を防ぐ処置が要るかも評価する。
- 目標との差を調べるギャップ分析で継続的改善を進める。最終目標がKGI、途中の指標がKPI、成功の条件がCSF。
サービスの運用
- システム運用管理
- 日常の運用計画と障害時の計画を立て、要員・機器・データなどの資源を管理する。AIで運用を助けるのがAIOps。
- 運用オペレーション
- 作業指示書に従って監視と操作をする。処理を決まった順に動かすジョブスケジューリングやバックアップも行う。
- サービスデスク
- 問い合わせを一つの窓口（SPOC）で受け、記録して担当へ引き継ぐ。FAQやチャットボットで自己解決も助ける。
ファシリティマネジメント
- 目的と考え方
- データセンターなどの施設と設備を、費用・安全・快適さの面から計画して管理するのがファシリティマネジメント。
- 施設管理・設備管理
- 停電にはUPSと自家発電設備、雷にはサージ防護デバイス、地震には免震装置で備える。
- 吸気側と排気側の通路を分けるコールドアイル・ホットアイルで冷やす。通信線が集まる所がMDF・IDF。
- 施設・設備の維持保全
- 施設と設備を点検し、故障する前に修理・交換して、正しい状態に保つ。
- 環境側面
- 省電力の機器や仮想化で消費電力を減らすなど、環境に配慮したIT利用をグリーンITという。
さわって確かめる
稼働率の計算、インシデントの優先度、管理の仕分けを、次の3つで確かめます。
1. SLAの稼働率と、許される停止時間
99.9 を入れて、30日の月に許される停止時間が43.2分になることを確かめよう。
MTBFとMTTRから稼働率を出す
2. インシデントの優先度（影響度×緊急度）
影響度「大」・緊急度「低」と、影響度「小」・緊急度「高」の優先度が同じになることを確かめよう。
表の数は一例です。優先度の決め方は、組織ごとに手順として定めます。
3. どの管理の仕事か
8つの出来事を、インシデント管理・問題管理・変更管理・サービス要求管理に仕分けよう。
- 「メールが送れない」と連絡があり、まず別のサーバ経由で送れるようにした。
- 先月から同じエラーが何度も起きているので、ログを集めて根本原因を調べる。
- OSの更新プログラムを本番サーバに当てる前に、影響を評価して承認を得る。
- 新しく入った人から、アカウントを作ってほしいと依頼があった。
- 原因が分かった不具合を直すため、修正版を本番へ入れる計画を立てる。
- Webサイトが表示されないので、予備のサーバに切り替えて表示を戻した。
- 回避策で戻した障害について、再発を防ぐための恒久的な対策を決める。
- パスワードを忘れたので再設定してほしい、と問い合わせがあった。
× の付いた所の理由を読んで、選び直してみよう。
3問チェック
最初に選んだ答えで採点します。全問正解で、この単元に「済み」の印が付きます。
-
SLAで月の稼働率を99.5%以上と決めた。1か月を30日（24時間×30日）とすると、1か月に許される停止時間は最大どれだけか。
- 36分
- 43.2分
- 3時間36分
- 7時間12分
答えと解説
正解はウ。止まってよい割合は 100−99.5＝0.5%。720時間×0.005＝3.6時間＝3時間36分。43.2分は99.9%のとき、7時間12分は99%のときの値。36分は3.6時間の0.6時間だけを分に直した値。
-
同じ画面で処理が止まる障害が、先月から何度も起きている。そのたびに再起動で戻しているが、ログを集めて根本原因を調べ、再発を防ぐ処置を決めることにした。この活動はどれか。
- インシデント管理
- 問題管理
- サービス要求管理
- リリース及び展開管理
答えと解説
正解はイ。根本原因を調べて再発を防ぐのは問題管理。再起動でサービスを早く戻すまでがインシデント管理。サービス要求管理は障害でない依頼、リリース及び展開管理は試験済みの変更を本番へ入れる活動。
-
あるサーバのMTBFが480時間、MTTRが20時間のとき、稼働率はいくつか。
- 0.04
- 0.958
- 0.96
- 24
答えと解説
正解はウ。稼働率＝MTBF÷（MTBF＋MTTR）＝480÷500＝0.96。0.04は止まっている割合。0.958は（480−20）÷480 と式を取り違えた値。24はMTBF÷MTTRで、割合ではない。