- ITIL 2011 edition
- JIS Q 20000
- シフト勤務で必要な人数の割り出し
- 用語
- エスカレーション(段階的取扱)
- 階層的エスカレーション
- 機能的エスカレーション
- データセンターファシリティスタンダード
- 故障樹解析:FTA(Fault Tree Analysis)
- コンポーネント障害インパクト分析:CFIA(Component Failure Impact Analysis)
- サービス障害分析:SFA
- 単一障害点分析:SPOF分析(Single Point Of Failure)
- 責任分担マトリックス:RAM(Responsibility Assignment Matrix)
- コロケーション
- (プロジェクトにおける)コロケーション
- ダウンタイム
- 目標復旧時点(RPO:Recovery Point Objective)
- 目標復旧時間(RTO:Recovery Time Objective)
- 傾向分析
- SAN(Storage Area Network)
- NAS(Network Attached Storage)
- DAS(Direct Attached Storage)
- シリアルATA
- XML署名
- コードサイニング証明書
- シュリンクラップ契約
- SMART目標
- JIS X 0164
- バックアップサイト
- データセンタ空調
- チーミング
- オートネゴシエーション
- フロー制御
- 仮想NIC
- インタロック:interlock
- フェールオーバー
- リンクアグリケーション
- MIMO(Multiple Input Multiple Output)
- マルチパート
- JIS規格
- フェアユース(fair use)
- ライブマイグレーション
- Apache Hadoop
- ISO、JIS規格
- トランザクションの同時実行制御が適切に行われない場合
- DNS攻撃
- WAL(Write Ahead Log)
- 36協定
- 稼働品質率
- PUE(Power Usage Effectiveness:電力使用効率)
- MTBF、MTTR
- 午後問題の中で業務に使えそうなもの
- バックアップ
ITIL 2011 edition
ITILはInformation Technology Infrastructure Libraryの略
ITサービスマネジメントにおけるベストプラクティス(成功事例)をまとめたもの。
ITサービスマネジメントシステムに関する国際規格である、ISO/IEC20000のベースになっている。
ITサービスの立案から提供までのライフサイクルとして5つの段階を定義している。
ITILの歴史
- 1990年ごろ初版(V1)がリリースされる。40冊の書籍
- 2000年ごろV2がリリースされる。40冊の書籍が7冊にまとめられた。
- 2007年にV3がリリースされる。「サービスストラテジ」「サービスデザイン」「サービストランジション」「サービスオペレーション」「継続的なサービス改善」に体系化し5冊にまとめられた。
- 2011年にV3を改善した、ITIL2011がリリースされた。
- 2019年にITIL4がリリースされた。ビジネスの変化に対応するアジリティとベロシティに対応
サービスストラテジ(戦略)
顧客の事業を成功させるためにどのようなITサービスを提供するか、活用するか。
どのような領域でどのようなITサービスを提供するかを戦略的に決定する段階
組織の中長期的な方向性とリソース配分を決めること。
事業関係管理
顧客(事業部門)との良好な関係を維持する。
- 事業計画がリアルタイムにIT部門にも共有されれている。
- 事業部門内の人間関係を把握している。
- 事業戦略とIT戦略について意見交換を行っている。
ITサービス戦略管理
ITサービス全体の方針や指針を策定し、コントロールする。
需要管理
ITサービスに対する需要を把握、予測し、影響を与える。
- ITサービスへの需要を把握し、予測している。
- 需要予測をキャパシティ設計に連携している。
- 必要に応じて需要そのものをコントロールしている。
サービスポートフォリオ管理
適切な投資で、必要な事業成果を満たすITサービスの組み合わせを持つ。
ポートフォリオとは書類入れやそこに含まれる書類全てのことで、金融の世界では自身の所有する資産を全て含めたものを指す。
- サービス・ポートフォリオ(IT投資計画書)を作成している。
- サービス・ポートフォリオを関係者(IT部門のメンバーや顧客)に共有している。
- 各ITサービスの投資対効果を、運用費用も含めて計算し分析した上で、新規立ち上げや廃止を決定している。
サービスポートフォリオ
サービス・パイプライン:検討中、開発中で、まだ顧客に提供していないすべてのITサービスの情報が記載されているもの。
サービス・カタログ:稼働中や提供可能なもの。
廃止されるサービス:停止、廃止する(した)サービス。
「廃止されるサービス」が「サービスカタログ」に含まれるかどうかは議論があるようなので深く考えない。
ITサービス財務管理
ITサービスに関する資金を投資効果の高い方法で確保する。
- ITサービスごとの設計・移行にかかった金額を把握している。
- ITサービスごとの運用にかかった金額を把握している。
- 財務情報をサービス・ポートフォリオ管理に提供している。
サービスデザイン(設計)
サービスデザインとは、戦略をより具体的な設計に落とし込むこと。
サービスストラテジで決定した戦略にしたがって、ITサービスを設計する段階
サービスカタログ管理
最新のサービス・カタログを維持し、利用できるようにする。
- サービス・カタログを作成している。
- サービス・カタログの内容はユーザーから見てわかりやすい。
- サービス・カタログを定期的にチェック・改善しており、実際に提供しているサービスとズレがない。
サービスレベル管理
サービスレベルについて顧客と交渉・合意しSALを満たす。
組織及び顧客は、提供するサービスに合意しなければならない。
組織は1つ以上のSLAを顧客と合意しなければならない。SLAには作業負荷の限度及び例外を含めなければならない。
あらかじめ定めた感覚で、下記をレビューし報告しなければならない。
- サービスレベルの目標に照らしたパフォーマンス
- SLAの作業負荷限度と比較した実績及び周期的変化
チェック項目
- 顧客とSLA(または目標)について話し合い、合意している。
- 合意した目標を達成しているか、データを元に分析している。
- 合意した目標を達成するための改善を行っている。
可用性管理
事業が必要な時にITサービスを使えるよう管理する。
ITサービスの可用性がSLAで合意された目標値を達成できるよう活動する必要がある。
可用性とは必要な時に合意した機能を利用できること。
- サービスごとに必要なタイミング(日時、時間帯)について顧客とSLAで合意している。
- 合意した可用性の目標値を達成するために、システムの二十か、サービスデスク強化などサービス全体としての対策を行っている。
- 運用メンバーから可用性に関する測定データを受け取り、分析して改善策を検討している。
プロアクティブな(率先した)活動
サービス実行水準の維持・改善のための事前活動
- リスク・アセスメントとリスク管理
- 新規及び変更されるサービスの計画と設計
- コストを正当化できる対策の実施
- 全ての新規及び変更されるサービスのレビュー、並びに全ての可用性と、対障害弾力性メカニズムのテスト
リアクティブな(反応的な)活動
サービス実施中または実施後におけるサービス維持・改善活動
- サービスとコンポーネントの可用性モニタ、測定、分析、報告、レビュー
- 全てのサービスとコンポーネントの非可用性の調査及び是正処置の調査
ITサービス継続性管理
ITサービスに深刻な影響を与える可能性のあるリスクの管理を行う。
- 企業全体として、リスク分析を行なっている。
- リスク発生時の緊急事態体制が決められており、関係者が認識している。
- リスク発生時の訓練(データの避難、復旧訓練など)を行なっている。
キャパシティ管理
ITサービスのキャパシティとパフォーマンスを最適に管理する。
- キャパシティの設計は根拠を持った上で分析・予測している。
- SLAに基づき設計した通りのキャパシティの利用量やパフォーマンスかどうかを、運用に入ってから測定している。
- 測定データを元に、キャパシティの改善を行っている。
情報セキュリティ管理
ITサービスの「セキュリティ」を管理する。
セキュリティのCIAがニーズに対応している必要がある。
Confidentiality(機密性):情報を知るべき人のみが閲覧可能である。
Integrity(完全性):情報が完全で、無許可の修正から保護されていること。
Availability(可用性):必要時に情報を入手および利用可能であること。
- 情報セキュリティ方針が存在する。
- 情報セキュリティ方針に基づく運用がなされている。
サプライヤ管理
価値あるITサービスを提供するために、サプライヤ(外部サービス・プロバイダ)を管理する。
- サプライヤとの契約は、顧客とのSLAと整合が取れている。
- サプライヤが提供するITサービスの内容が契約と合致するかチェックしている。
- 契約更新時には、サプライヤと話し合いより良いITサービスを顧客に提供できるかを吟味している。
サプライヤのカテゴリ
戦略的サプライヤ:長期的な計画を促進するために、戦略の機密情報を共有する上級マネジメントが関与するカテゴリ。コンサルタントや大手インフラ業者など。
戦術的サプライヤ:顕著な商業活動及び事業とのやりとりがあり、中級マネジメントが関与するカテゴリ
運用上のサプライヤ:運用上の製品、またはサービスのサプライヤに対して、下級運用マネジメントによって管理するカテゴリ。
コモディティサプライヤ:比較的容易に代替ソーシングされ得る、価値が低く容易に入手できる製品とサービスを提供するサプライやに対するカテゴリ。プリンタ用紙の業者など。
サービストランジション(移行)
設顧客および利害関係者のサービス要件に基づき設計されたサービスを運用段階に移行する段階
変更管理
ITサービスを中断させずに有益な変更を実現できるよう管理する。
チェック項目
- 変更の手順が決まっている。
- 変更すべきかどうかの判断には事業側のメンバーも参加している。
- 変更についての判断と実装結果について記録し、分析したり、次回以降のCABの判断材料として活用している。
リリース管理及び展開管理
リリースの構築、テスト、展開を管理し、新しい機能性を提供する。
問題のあるリリースの稼働環境への展開の防止
チェック項目
- ITサービスを展開する際には計画を立ててから実行している。
サービス資産管理及び構成管理
資産を管理し、成果雨な情報を必要な時に利用できるようにする。
ITサービスはさまざまな様相で構成されている(サーバ、アプリケーション、PC、ネットワーク機器、SLA、マニュアル、サービス・カタログ、技術者、ライセンス)
これらが現在どのような構成になっているのかを把握することは良いサービスを提供し続けるために欠かせない。
ITサービスを構成するものの最新の状態やどのように繋がっているかを把握しておくべき対象をCI(Configuration Item:構成管理アイテム)と呼びその情報を管理することを「サービス資産及び構成管理」と呼ぶ。
サービス供給に必要な資産に関する正確な情報を、必要な時に必要な場所で利用できることを目的とする。
構成コントロールは、構成管理の活動の一つであり、構成管理データベース(CMDB:Configuration Management DataBase)を最新の状態に維持し、変更要求がなければ変更できないよう管理する活動。
構成コントロールが適切に行われていない場合、CMDBの内容が実際の状態と乖離してしまい、使用ソフトウェアライセンス数が超過する、脆弱性のある製品を利用しているシステムの抽出ができない、製品の保守期限を把握できないなどの問題が発生する。
チェック項目
- ITサービスの構成をまとめた文書やデータベースがあり、必要な人がアクセスできる。
- ITサービスの構成をまとめた文書と、実際の構成の差異がない。
- 構成情報を更新するタイミングが決まっており、運用されている。
ナレッジ管理
ITサービスに関わるナレッジ(知識)を管理する。
- 必要なデータや情報を記録し、定期的に分析している。
- 個人のナレッジを組織内で共有している。
- 適切な人が適切なナレッジに適切なタイミングでアクセスできる仕組みがある。
サービスオペレーション(運用)
合意されたサービスレベルで、顧客やユーザーに対してITサービスを提供する段階
要求実現
ユーザーからの要求を迅速かつ確実に実現する。
- ユーザーの問い合わせ方法、問い合わせ先が決まっている。
- 問い合わせ内容と対応履歴を記録している。
- FAQの作成や自動化などにより、問い合わせの対応を迅速化する施策を行なっている。
アクセス管理
必要な人が必要なITサービスにアクセスできるようにする
- 複数名でアカウントを共有していない。
- 個人のパスワードの管理が適切になされている。
- アクセス権が適切に設定されている。
- 部署異動、退職の際にアクセス権の変更、停止がなされている。
インシデント管理
迅速に復旧してITサービスの中断を短くする。
インシデントとは、「ITサービスに対する計画外の中断、または、ITサービスの品質の低下。サービスにまだ影響していない構成アイテムの障害もインシデントである。例えばミラー化されたディスクの1つに起きた障害など」
- インシデント・モデルは、誰が対応しても一定時間内にインシデントを解決できるように特定のインシデントに対して事前に対応方法や回復方法を定義しておくもの。
- 管理指標の明確化によって効率性と有効性を判断するための基準を明確にできる。
- インシデントの完全な記録によって、過去インシデントの履歴、カテゴリ、及び解決するためにとられた処置を容易に参照できる。
チェックポイント
- インシデントを受けたらいつ、どのような問い合わせを受けたか記録している。
- 事業側と合意した優先度を元に対応している。
- サービスが復旧したことをユーザーに知らせ、ユーザーからの同意を得ている。
- インシデントの発生件数や処理時間の傾向を分析する。
- 同じようなインシデントの対応が担当者ごとに違っていないか確認する。
- 対応手順を定型化した方が早く処理できそうなものはないかを調べる。
問題管理
インシデントの原因解決を管理し、発生や最初を防ぐ。
問題とは「1つまたは複数のインシデントの原因」
イベント管理
イベントを管理し、運用や設計など、他のプロセスに活用する。
ITシステム(サーバやネットワーク機器やPCなど)で発生している事象を、正常も異常も全てひっくるめてイベントと呼ぶ。
- 情報(Information):ユーザーのログインや、バッチの成功など確認するだけの通知。
- 警告(Warning):設定した閾値に近づいたときなど、注意や調査が必要な通知。
- 例外(Exception):サービスが正常に稼働していないときの通知。
- 必要なイベントを監視している。
- イベントの重要度はSLAに基づき設定している。
継続的なサービス改善
ビジネスニーズの変化に多王しながらITサービスを提供し続けるために、ITサービスおよびプロセスの継続的な改善を行う段階。他すべての段階で実施される。
7ステップの改善プロセス
ITILの継続的サービス改善における最も重要なプロセスであり、7ステップで構成される。
PDCAサイクルに適合している。
PDCAサイクル | ステップ | 概要 |
---|---|---|
計画(Plan) | 1.改善の戦略を識別する。 | 全体的なビジョン、ビジネス・ニーズ、戦略、戦術的及び運用上の最終目標を識別する。 |
2.測定するものを定義する。 | 測定するべきもの、実際に測定できるものを定義し、ギャップ分析を実施して実際の測定計画を決定する。 | |
実施(Do) | 3.データを収集する。 | 測定対象データを収集する。 |
4.データを処理する。 | 収集したデータを、特定の重要成功要因(CSF)及び重要業績評価指標(KPI)に整合するよう加工する。 | |
点検(Check) | 5.情報とデータを分析する。 | 達成目標に対する検証を実施し、改善の要否を見極める |
6.情報を提示して利用する。 | 分析した結果を、明確でわかりやすい方法で対象者に提示する。 | |
処置(Act) | 7.改善を実施する | 課題を識別し、解決策を実施する。 |
- IT組織は顧客よりもデータを理解していると誤解しているため、顧客の大きな不満につながらないよう、顧客とIT組織の間で測定するものを定義する活動が必要となる。
- 効果的にサービスを測定するためには経済的、定量的で求められる結果を出すために役立つ、重要で意味のある少数の指標に着目する。
- 実際に測定できるものを定義した上でデータを収集する。
- 指標が多すぎると組織は測定にこだわりすぎて結果の改善への焦点を失うため、最も重要なものを測定する。
JIS Q 20000
ITサービスマネジメントをに関するJIS規格である。
JIS Q 20000-1(サービスマネジメントシステム要求事項)とJIS Q 20000-2(サービスマネジメントシステムの適用の手引き)の2部で構成されている。
ITサービスマネジメントの国際規格であるISO/IEC20000が日本のJIS規格化されたもの。
ちなみにISO/IEC20000はITIL(Information Technology Infrastructure Library)を元に作成されている。
JIS Q 20000-1:2020(サービスマネジメントシステム要求事項)
全文URL(http://kikakurui.com/q/Q20000-1-2020-01.html)
情報サービスの提供者に対する要求事項を規定したもの。
用語の定義
継続的改善
パフォーマンスを向上させるために繰り返し行われる活動
組織の状況
組織及びその状況の理解
利害関係者のニーズ及び期待の理解
サービスマネジメントシステムの適用範囲の決定
サービスマネジメントシステム
リーダーシップ
リーダーシップ及びコミットメント
トップマネジメントは次に示す事項によってSMSに関するリーダーシップ及びコミットメントを実証しなければならない
- サービスマネジメントの目的を確立し、それが組織の戦略的な方向性と両立することを確立する。
- サービスマネジメント計画が作成、実施、維持されていることを確実にする。
- 適切なレベルの権限が割り当てられていることを確実にする。
方針
トップマネジメントはサービスマネジメントの方針を確立しなければならない。
組織の役割、責任及び権限
トップマネジメントは、SMS及びサービスに関連する役割に対して、責任及び権限が割り当てられ、組織内に伝達されることを確実にしなければならない。
計画
リスク及び機会への取り組み
リスクマネジメントの目的及びそれを達成するための計画策定
サービスマネジメントシステムの計画
SMSの支援
資源
力量
認識
コミュニケーション
文書化した情報
知識
SMSの運用
運用の計画及び管理
サービスポートフォリオ
- サービスの提供
- サービスの計画
- サービスのライフサイクルに関する関係者の管理
- サービスカタログ管理
- 資産管理
- 構成管理
サービス提供のために管理する必要がある構成品目を特定し、その属性及び構成品目の関係を構成管理データベースに記録して管理する。
関係及び合意
- 事業関係者管理
サービスの顧客,利用者及び他の利害関係者を特定し,文書化しなければならない。組織は,顧客関係を管理し,顧客満足を維持する責任をもつ者を一人以上指名しなければならない。
あらかじめ定めた間隔で組織はサービスのパフォーマンスの傾向及びサービスの成果をレビューしなければならない。
- サービスレベル管理
組織及び顧客は提供するサービスに合意しなければならない。
提供する組織は一つ以上のSLAを顧客と合意しなければならない。 - 供給者管理
組織は外部供給者との関係、契約及び外部供給者のパフォーマンスの管理に責任を持つものを一人以上指名しなければならない。
供給及び需要
- サービスの予算業務及び会計業務
予算に照らして費用を監視して報告し、財務予測をレビューし、費用を管理する。 - 需要管理
- 容量、能力管理
サービスの設計、構築及び移行
- 変更管理
緊急変更を含む変更のカテゴリ及びそれらの管理
変更要求の承認及び優先度について決定を行う(リスク、事業利益、実現可能性及び財務影響を考慮)
失敗した変更を元に戻す又は修正する活動を計画する。 - サービスの設計及び移行
- リリース及び展開管理
組織は緊急リリースを含むリリースの種類、頻度、それらの管理方法を定義しなければならない。
リリースは文書化された基準に基づいて検証し、展開前に承認しなければならない。
解決及び実現
- インシデント管理
インシデントを管理し、解決する。
重大なインシデントを特定する基準を持たなければならない。
重大なインシデントについて常に通知されるようになっていなければならない。 - サービス要求管理
サービス要求を管理し、解決する。
サービス要求の実現を管理するための手順を定めるとともに、サービス要求の優先度付けを行う場合には、影響及び緊急度を考慮する。 - 問題管理
インシデントのデータ及び傾向を分析、根本原因の分析に着手、インシデント発生防止を行う。
サービス保証
- サービス可用性管理
合意した条件のもとで要求された機能を果たせる状態にある能力について、定義し、分析し、計画し、測定し改善する活動を行う。
あらかじめ定められた間隔でサービス可用性のリスクアセスメントを行い、リスクを文章化しなければならない。
サービス可用性の要求事項及び目標を文章化し、維持しなければならない。
サービス可用性を監視し、結果を比較し、目標と比較し、必要であれば是正措置を行わなければならない。 - サービス継続管理
あらかじめ定められた間隔でサービス継続のリスクアセスメントを行い、リスクを文章化しなければならない。
組織は一つ以上のサービス継続計画書を作成し、実施し、維持しなければならない。 - 情報セキュリティ管理
パフォーマンス評価
監視、測定、分析及び評価
内部監査
マネジメントレビュー
サービスの報告
改善
不適合及び是正処置
継続的改善
JIS Q 20000-2:2013(サービスマネジメントシステムの適用の手引き)
全文URL(http://kikakurui.com/q/Q20000-2-2013-01.html)
4.サービスマネジメントシステム(SMS)の一般要求事項
4.1 経営者の責任
4.1.1.4 サービスマネジメントの目的
トップマネジメントは、合意されたサービスマネジメントの目的を定義することが望ましい。
- 事業目的及びサービスマネジメントの方針に整合する。
- 目的に対する達成度を正確に測定できるように定義する。
- サービスマネジメントの計画の主要なインプットとする。
- 一定の間隔でレビューする。
6.サービス提供プロセス
6.4 サービスの予算業務及び会計業務
会計報告書は、特定のサービスを支援するCIの総所有費用及び総減価償却費用を計算するために、CIの状態及びライフサイクルに関するCMDBからの情報を利用してもよい。
6.5 容量・能力管理
管理活動として、将来のコンポーネント、並びにサービスの容量・能力及びパフォーマンス予想は、採用する技法及び技術に応じて様々な方法で行うことが望ましい。
パフォーマンスの予想の例、4つのモデル化
ベースラインのモデル化 | 現在達成されているパフォーマンスを反映したモデルを作成する。このベースラインのモデルかが作成された場合、予測モデル化の開発が可能となる。 |
傾向分析 | 時間に関連した傾向を特定するための分析手法である。 |
分析モデル化 | 数学的手法を用いてパフォーマンスを分析・予測する。 |
シミュレーションのモデル化 | 所定のシステム構成を基準にしたトランザクション到着率など、離散事項(連続でない、とびとびの)をモデル化する。 |
統合的制御プロセス
9.1 構成管理
構成管理プロセスは、構成品目の特定、管理、記録、追跡、報告及び検証、並びにCMDBでのCI情報の管理を含むことが望ましい。
9.2 変更管理
変更管理プロセスが管理しているCIを定義する。変更管理方針を確立し、文書化することが望ましい。
CIに対する全ての変更要求はこのプロセスで管理されるのが望ましい。
- 緊急変更:早急に対応することが望ましいもので、例えば重大なインシデントの解決や情報セキュリティパッチの適用など
- 通常変更:一般的な変更管理のプロセスに則り実施するもの
- 標準変更:リスクが低く、比較的よくあり、手順または作業指示書に従う、事前認可済みの変更
変更が失敗した場合には、元に戻すか、又は修正すること。
失敗の成否に関わらず、展開後にCMDBを更新する。
9.3 リリース及び展開管理
正しい場所及び時間での、サービス及びサービスコンポーネントを支援するCIの配布及び提供
シフト勤務で必要な人数の割り出し
メンバー数 = 1週間に必要なコマ数 ÷ 1メンバーが1週間に勤務可能なコマ数
1週間に必要なコマ数 = 1日のシフト数✖️1シフトあたりの人数✖️7
(例)24時間365日の対応で、1日3シフト勤務、各シフトのオペレータ2人以上、各オペレータの勤務回数は7日あたり5回以上という条件で、必要となる最小オペレータ人数を求める。
1週間に必要なコマ数は、3(シフト)✖️2(人)✖️7(日)= 42コマとなる。
メンバー数は、42(コマ)÷ 5(コマ)= 8.4人となる。
用語
エスカレーション(段階的取扱)
他の部署や外部の組織に対する問い合わせや対応依頼のこと。
自部門だけでは解決できないインシデントについてエスカレーションを行う。
階層的エスカレーション
重大なインシデントについて、より権限を持つ上級マネージャにエスカレーションすること。
機能的エスカレーション
一時サポートグループでは解決できなかったインシデントの対応を、より専門的な知識を持つ2時サポートグループに委ねる。
データセンターファシリティスタンダード
ティアとはデータセンターの安全性を確認するための品質基準のことで、米国の民間団体によって作成された。
データセンターファシリティスタンダードはティアに日本の実情を反映させた基準であり、日本データセンター協会が定めている。
UPS設備の冗長性に関する基準
サービスレベル | UPS冗長性 | |
---|---|---|
ティア1 | 瞬間的な停電に対してコンピューティングサービスを継続して提供できる設備がある。 | N |
ティア2 | 長時間の停電に対してもコンピューティングサービスを継続して提供できる設備がある。 | N |
ティア3 | 機器のメンテナンスなどの一部設備の一時停止においても、コンピューティングサービスを継続して提供できる設備がある。 | N+1 |
ティア4 | 機器の故障やメンテナンスなどの一部設備の一時停止において、同時に一部機器に障害が発生しても、コンピューティングサービスを継続して提供できる、より高いレベルの冗長性構成の設備がある。 | N+2 |
※「N」はシステム構成として必要となる常用UPSの台数
故障樹解析:FTA(Fault Tree Analysis)
製品の故障、及びそれにより発生した事故の原因を特定する手法
故障原因の潜在危険を理論的にたどり、それぞれの発生確率を評価する手法でもある。
ITサービスの障害につながるイベントの連鎖を識別する手法で、プロアクティブな活動のリスク分析で利用される。
コンポーネント障害インパクト分析:CFIA(Component Failure Impact Analysis)
構成アイテムごとに障害時のインパクトを評価する技法
システムの弱点と対策を網羅的に洗い出すことができる。
プロアクティブな活動のリスク分析で利用される。
サービス障害分析:SFA
発生した障害の分析を行う手法
リアクティブな活動のリスク分析で利用される。
単一障害点分析:SPOF分析(Single Point Of Failure)
コンポーネント障害インパクト分析の結果から単一障害点:シングルポイント(そこが止まってしまうとシステム全体止まってしまう部分)を洗い出す手法
プロアクティブな活動のリスク分析で利用される。
責任分担マトリックス:RAM(Responsibility Assignment Matrix)
プロジェクトの目的を達成するために、プロジェクトの要因が担当する作業について、役割や責任を明確にする表のこと。
RACIチャート
RAMの一種でタスクごとにRACIの役割を誰が担当するか明確化したマトリクス
- Responsible(実行責任者)タスクの実行者、複数いてもOK
- Accountable(説明責任者)承認者ともとらえられる、責任の所在を明らかにするため原則一人
- Consulted(協業先、相談対応先)タスクを進める際の相談者、双方向
- Informerd(報告先、情報提供先)タスクの進捗状況の報告先、情報提供、一方向
コロケーション
データセンタ内に、顧客が所有するサーバやネットワーク機器を設置するスペースを借りることができるサービス
コロケーション | ハウジング | ホスティング (レンタルサーバ) | クラウドコンピューティング | |
サービス内容 | 自社サーバを設置するスペースのリース | 自社サーバを設置するラックのリース | 事業者サーバのリース | クラウドサーバ/クラウドストレージの利用 |
インフラ運用 | 自社 | 自社/事業者 | 事業者 | 事業者 |
サーバ所有者 | 自社 | 自社 | 事業者 | 事業者 |
(プロジェクトにおける)コロケーション
プロジェクトメンバーが物理的に1箇所に集まって作業すること。
同義語として「タイト・マトリックス」がある。
ダウンタイム
システムやサービスが保守や障害によって停止している時間。
目標復旧時点(RPO:Recovery Point Objective)
システム障害などデータの復旧が必要となった際に「どの時点の状態まで復旧させるのか」を定めた目標のこと。
目標復旧時間(RTO:Recovery Time Objective)
障害発生からの目標復旧時間。
傾向分析
数学的モデルに従い、過去の結果に基づいて将来を予測する手法。
株式投資などでも用いられる。プロジェクトのタスク消化状況をモデル化して、別のプロジェクトで参考にするなど。
PMBOKでは、品質マネジメントの品質管理として使われる。
(例)時間の経過に伴うプロジェクトのパフォーマンスの変動を分析する。
SAN(Storage Area Network)
複数のコンピュータとストレージを結ぶ高速ネットワークのこと。
FC-SANとIP-SANがある、FC-SANは機器間の通信にファイバチャネルを使い光ファイバーやFCスイッチを利用、IP-SANはIPネットワークの仕組みを利用する。
NAS(Network Attached Storage)
LANに直結されたRAIDなどのストレージに対し、サーバなどがCIFS(Common Internet File System)やNFS(Netword File System)といったファイル共有プロトコルを使ってアクセスする方式
DAS(Direct Attached Storage)
コンピュータとストレージを直接繋ぐ形態のこと。
シリアルATA
パソコンとハードディスクなどの内部ストレージを1対1に接続するものである。
XML署名
XMLにディジタル署名を埋め込むためにW3C(World Wide Web Consortium)によって標準化された署名技術である。
署名対象や証明書などをXMLの文法で統一表記することができる。
XML文書全体だけではなく、XMLの一部に対しても署名を付けられる。
コードサイニング証明書
ソフトウェアにディジタル署名を行う電子署名用の証明書である。
目的はソフトウェアの配布元を確認することと、ソフトウェアが改ざんされていないことを保証すること。
シュリンクラップ契約
商品であるCD-ROMや使用許諾契約書を包んだ透明な包装(シュリンクラップ)を解いた時点で、ソフトウェアの使用許諾契約が成立する契約のこと。
パッケージソフトウェアの販売方式を中心に採用されている。
ちなみにオンラインでソフトウェアを入手する際に同意するボタンをクリックして成立する使用強打区契約を「クリックラップ契約」と呼ぶ。
SMART目標
ITIL 2011 editionのサービスデザインにおいて、目標値が備えるべき5つの条件が挙げられている。
- Specific:具体的な内容であること
- Measurable:測定可能であること
- Achievable:達成可能であること
- Relevant:適切な内容であること
- Time-bound:時間的制限があること
JIS X 0164
ソフトウェア資産管理のための統合された一連のプロセスの基準を定めた規格であり、JIS X 0164-1、JIS X 0164-2の2部で構成される。
全てのソフトウェア資産及び関連資産に適用できる。
ソフトウェアを使用する上で必要となる特性を持つハードウェア資産は規格の対象に含むが、必要となる特性を持たないハードウェア資産は含まない。
ソースコードも規格の対象に含む
有償、無償ともに適用範囲に含まれる。
バックアップサイト
コールドスタンバイ
緊急時にはバックアップシステムを持ち込んでシステムを再開し、サービスを復旧する。
ウォームスタンバイ
待機系を起動状態にしておくが、本番系と同期は取らず、障害時にはデータを最新状態にする処理を行なった後にサービスを復旧する。
ホットスタンバイ
別の場所に常にデータの同期が取れているバックアップシステムを用意しておき、緊急時にはバックアップシステムに切り替えて直ちにサービスを復旧する。
データセンタ空調
クールピット(cool pit)
夏季の高温の外気を外気よりも低温な地下のピットと呼ばれる空間を通すことで冷却し建物内へ給気する。空調設備の省エネ技術のこと
アイルキャッピング(aisle capping)
データセンタ内のラックを屋根やパーテーションで区画し、空調からの給気と装置からの排気を分離することで効率的に装置を冷却する気流制御技術である。
英語の意味は「通路の表面を覆う」
タスクアンビエント空調(task/ambient air conditioning system)
空調を冷暖房の必要となるタスク域と、冷暖房が不要なアンビエント域に分割し、タスク域に集中して冷暖房することで空調負荷を効率化する技術である。ambientには常温保存可能なという意味がある。
フリークーリング(free cooling)
外気温の低い冬季・中間期に外部の冷却塔で冷水を製造し、空調や装置の冷却に充てることで省エネルギー化を実現する技術である。
英語のfreeには「暇な、忙しくない」の意味がある。
コールドアイル(cold aisle:冷たい通路)
データセンタやサーバールームで機器を冷却するための冷たい空気が流れる空間のこと。
チーミング
複数のNIC(Network Interface Card)を論理的に束ねて1つに見せる技術のこと。複数の物理NICに一つのIPアドレスを割り当てることが必要になる。
NICチーミングを行うことで、NICと外部スイッチを接続するリンクの負荷分散を行わせたり、耐障害性を向上させたりすることができる。
スペルはteamingなのでチームにするイメージ
Linux系ではチーミングのことをボンディングと呼ぶ。
オートネゴシエーション
接続相手のNICが対応している通信規格又は通信モードの違いを自動的に認識し、最適な速度で通信を行うようにする。
フロー制御
処理能力を超えてフレームを受信する可能性があるとき、一時的に送信の中断を要求し、受信バッファがあふれないようにする。
通常、pauseフレームを送信することによって、フレーム送信の中断を要求する。
仮想NIC
ソフトウェアでNICをエミュレートし、1台のコンピュータに搭載している物理NICの数以上のネットワークインタフェーズを使用できるようにする。
インタロック:interlock
フールプルーフ(fool proof)は人は必ず間違いを犯すので、人間がしようと異なる操作をしようとしてもできないようにすることでヒューマンエラーを回避する方法である。
インタロックはフールプルーフを実現する仕組みの一つであり、一定の条件を満たさなければ動作しないようにする安全機構のこと。
interlockの意味は組み合う、噛み合うなので、条件を満たした時に動作するイメージ
例えば、エレベータはドアが閉まらなければ昇降しないといったもの。
フェールオーバー
稼働中のシステムで問題が発生してシステムやサーバーが停止した際に自動的に待機系に切り替える仕組み。
フォールトトレラント設計に基づく
フォールトトレラントはシステムや機器の一部が故障、停止しても予備系の系統に切り替えるなどして機能を保ち正常に稼働し続ける仕組みのこと。
リンクアグリケーション
スイッチングハブ同士を接続する際に複数のポートを束ねて一つの論理ポートとして扱う技術
スイッチ間の通信を冗長化したり、負荷分散するのに利用される。
MIMO(Multiple Input Multiple Output)
送信と受信に複数のアンテナを使用し、電波を多重化することによって無線LANの高速化を図るための技術。
マルチパート
複数の異なるデータを1通のメールの中に混在させるようにしたMIMEの仕組み
JIS規格
JIS Q 15001
個人情報保護マネジメントシステム(PMS:Personal information protection Management System)の要求事項
JIS Q 20000-1
ITサービスマネジメントシステムの要求事項
ISO/IEC 20000-1を日本語化したもの
JIS Q 22301:2013
地震などの災害や金融危機、感染病の急激な拡大などに備えて、企業や組織が対策を立案し効率的かつ効果的に対応するための社会セキュリテイー事業継続マネジメントシステム(BCMS:Business Continuity Managemet System)の規格でISO 22301を日本語化したもの。
JIS Q 27001
情報セキュリティマネジメントシステム(ISMS:Information Security Management System)の要求事項
ISO 27001を日本語化したもの
フェアユース(fair use)
批評、解説、ニュース報道、教授、研究、調査など、構成な目的のためであれば、一定の範囲での著作物の利用は、著作権の侵害には当たらないと評価される考え方。
ライブマイグレーション
仮想サーバを稼働させたまま、物理サーバ間を移行(移動)させる機能。仮想サーバ上で稼働するサービスの停止を伴わない。
Apache Hadoop
大規模データの分散処理を実現するミドルウェア
ISO、JIS規格
ISO 22301(JIS Q 22301:2013)
地震などの災害や金融危機、感染病の急激な拡大などに備えて、企業や組織が対策を立案し効率的かつ効果的に対応するための社会セキュリティー事業継続マネジメントシステムの規格
ISO22301を日本語化したもの
JIS Q 15001
個人情報マネジメントシステムの要求事項を標準化している。
ISO 27001(JIS Q 27001)
情報セキュリティマネジメントシステムの要求事項
トランザクションの同時実行制御が適切に行われない場合
変更消失問題
複数のトランザクションから同じデータに更新処理を行ってしまい初めの変更内容が消えてしまう。
コミットされていない依存性の問題
トランザクションT1があるデータに更新処理を行った後、コミットする前にT2がそのデータを参照してしまった場合、トランザクションT1がロールバックされるとトランザクションT2の結果に矛盾が生じる。
不整合分析の問題
複数のトランザクションが同じデータを更新してしまい、結果に矛盾が生じる。
DNS攻撃
DNSキャッシュポイズニング攻撃
標的のDNSキャッシュサーバーにランダムかつ大量に生成した偽のサブドメインのDNS情報を注入する。
自分で問い合わせをすると、DNSキャッシュサーバーが問い合わせを行うので、その返答を偽装することで偽のDNS情報を注入する。
DNS水責め攻撃(ランアムサブドメイン攻撃)
標的の権威DNSサーバにランダムかつ大量に生成した存在しないサブドメイン名を問い合わせ、高負荷にさせる。
DNSリフレクション攻撃(DNS amp攻撃)
送信元を偽装したDNS問い合わせを、大量にDNSサーバに行うと、DNSサーバはその返答を(偽装された)送信元に送る。
送信元として使われたサーバは高負荷になる。
デザインコーディネーション
サービスデザインの全ての活動、プロセスリソースを調整する。
職務の分離(職務分掌)
内部統制の構築の一環として、重要な職務を兼務せず分離させることで、2つの職務者による相互牽制が働く。
例えば、開発プログラマが運用オペレータを兼務する場合、開発段階のバグが明らかになりにくく、不正の恩賞にもつながるため望ましくない。
WAL(Write Ahead Log)
データベースの更新の前に必ずログの書き込みを行うことによって、何かの障害が発生した場合でもログファイルからデータベースを復旧できるようにする仕組み。
- 障害時点でデータベースに反映されていなかった更新をログファイルから復旧させることができる。
- 障害時点で中途半端にデータベースに反映されている更新をREDO(もう一度行う)、UNDO(取り消す)ことでデータベースの一貫性を保つことができる。
- メモリ情報更新データをリアルタムにデータベースへ反映する必要がなく、更新処理を高速化できる。
36協定
労働基準法第36条に規定されている。
時間外労働、休日労度について労使協定を書面で締結し、労働基準監督署に届け出ることによって、法定労働時間外の労働が認められれる制度のこと。
時間外労働の上限は、月45時間・年360時間となり、臨時的な特別な事情がなければこれを超えることはできない。
臨時的な特別な事情があって、労使が合意する場合でも、年720時間、複数月平均80時間以内、月100時間未満を超えることはできない。
稼働品質率
日本情報システム・ユーザー協会(JUAS)によってシステムに求める性能や信頼性などの非機能要件の評価手法として定義されたシステムの停止が業務に与えた影響を評価することに主眼を置いた、システムの信憑性の評価項目
システムの利用者に迷惑をかけた回数を、システムの資産規模で割って算出し、0に近づくほど信頼性が高いと評価する。
品質稼働率 = 利用者に迷惑をかけた回数 ➗ システムの資産規模
PUE(Power Usage Effectiveness:電力使用効率)
データセンタの電力使用効率を表す指標
PUE = データセンタ全体の消費電力 ➗ IT機器の消費電力
MTBF、MTTR
MTBFはMean Time Between Failuresの略で平均故障間隔、故障が発生するための稼働時間
MTTRはMean Time To Repairの略で平均復旧時間、システムの復旧にかかる時間
午後問題の中で業務に使えそうなもの
問題解決率
問題解決率 = (問題総件数 ー 終了していない問題件数)/ 問題総件数
変更管理の項目
システム改善案の採点方法
バックアップ
JIS Q 20000-1:2012
全文URL(https://kikakurui.com/q/Q20000-1-2012-01.html)
JIS Q 20000-の2012バージョン
サービスマネジメントシステムの一般要求事項
経営者の責任
- 経営者のコミットメント
トップマネジメントは、サービスマネジメントシステム及びサービスの計画、確立、導入、運用、監視、レビュー維持及び改善に対するコミットメントの証拠を提供しなければならない。 - サービスマネジメントの方針
サービスマネジメントの方針がサービス提供者の目的に対し適切であることを確実にする。 - 権限、責任及びコミュニケーション
サービスマネジメントの権限及び責任が定めあられ維持されていることを確実にする - 管理責任者
サービス提供者の管理層の中から管理責任者を任命する。
新規サービス又はサービス変更の設計及び移行
サービス提供プロセス
サービスレベル管理
提供する個々のサービスを定義し、これを顧客と合意して、さらに、文章化する。
サービスの報告
サービス継続及び可用性管理
サービス提供者は、サービス継続及び可用性の要求事項について特定し、顧客及び利害関係者と合意しなければならない。
合意した要求事項では、適用可能な事業計画、サービスの要求事項、SLA及びリスクを考慮しなければならない。
サービスの予算業務及び会計業務
容量・能力管理(キャパシティ管理)
サービスの容量・能力を監視し、サービスのパフォーマンスを調整して、さらに十分な容量・能力を提供するための手順を明確にする。
情報性キュリティ管理
関係プロセス
事業関係管理
サービス提供者と顧客の関係を定義する。
供給者管理
サービス提供者と供給者の関係を定義する。
- 各供給者について、サービス提供者は供給者との関係、契約及び供給者のパフォーマンス管理に責任を持つ個人を指名しなければならない。
- サービスレベルの供給者との合意
- 供給者との関係の文書化
- パフォーマンス監視の実施
解決プロセス
インシデント及びサービス要求管理
インシデントが発生した際に迅速にその解決にあたり、サービスの復旧を行うこと及び顧客からのサービス改善要望などの要求に対応することを目的とする活動である。
問題管理
インシデント及び問題の影響を識別し、これを最小限に抑える、または回避するための手順を採用する。