インシデント管理の用語

インシデント確認 (ack)

インシデント アラートが生成されると、ユーザーはほとんどのオンコール アラート ツールでアラートを確認 (「ack」) できます。これは、ユーザーが問題に対する責任を引き受けて、問題の解決に取り組むことを意味します。

実践に繋がるアラート

実践に繋がるアラートとは、問題とその影響を明確に記述して、チームが即時に対処できるようにするために、適切な担当者に適切なタイミングで送信されるアラートです。

アクティブ モニタリング

アクティブ モニタリング機能を備えたシステムは、インシデントに繋がる可能性のあるパフォーマンスの変化について、ソフトウェアを使用して定期的にチェックするか自動的に監視しています。

行動後レビュー (AAR)

行動後レビューは、イベントの後に行われる体系化されたレビュー プロセスです。このプロセスでは通常、何が起こったのかを詳細に説明してその理由の究明を試みることで、今後、同様または類似するイベントの発生を防止するための改善領域を特定します。行動後レビューは、一般に事後分析やインシデント後レビューとも呼ばれます。

合意されたサービス時間 (AST)

合意されたサービス時間は、サービスが利用可能であることが期待される時間で、通常は年間の時間数で測定されます。この合意内容は通常、ベンダーとクライアントの間で交わされるサービス レベル アグリーメント (SLA) に記載されています。高可用性サービスでは 通常 99.99% のアップタイムが確約されるため、1 年間に許容されるダウンタイムは 1 時間未満です。

アラート

監視ツールが IT 環境における変化、リスクの高いアクション、障害を特定したときに生成されるアラームまたは警告。

アラート ノイズ

アラート ノイズは、短時間に膨大な数のアラートが作成されてどのサービスが影響を受け、どのように作業の優先順位を付けるのかを応答者が正確に特定するのが容易ではない場合に発生します。アラート ノイズは、アラートによる疲弊を引き起こす要因となる可能性があります。

アラートによる疲弊

アラートによる疲弊は、インシデント応答者が過剰な量や頻度のアラートに圧倒された場合に生じます。アラートによる疲弊が生じると、応答者は常時アラートが作成されるのを通常の状態と見なすようになり、しばしば対応の遅れや無視に繋がります。

常時稼働サービス

継続的な運用が期待されるサービス。

アセット/アセット管理

ビジネス価値を持つシステムまたはネットワークのコンポーネント。アセット管理とは、作業者またはチームがシステムの更新または削除の影響を理解するために、これらのコンポーネントを事前に評価することです。

監査

システムまたはプロセスの可用性と使用状況、およびポリシー、ガイドライン、ベスト プラクティスが順守されているかについての正式な調査です。

可用性

製品またはシステムが利用可能で、期待どおりに機能している状態。システムのアップタイムとも呼ばれます。

バックアウト

サービスを以前の信頼できる状態または基準に復元するプラクティス。これは通常、アップデートまたはリリースによってシステムに不可欠なものが損なわれた際に適用される応急措置です。

バックアップ

元のデータが損なわれた場合や紛失した場合に使用できる、保存されているデータのコピーまたは冗長システム。

ベースライン

予期される動作の基準点。チームが変更と改善を測定するのに役立ちます。

ベンチマーク

進捗を測定したり結果を比較したりするために、ベースラインと同様に機能する基準点。たとえば、業界の標準が 99.99% のアップタイムであれば、それを競合他社や顧客の期待に照らして自社を評価するためのベンチマークとして使用できます。

根絶

ソフトウェア、コード、プログラムなどの意図しない問題。異常な動作や障害を引き起こす可能性があります。

事業影響度分析 (BIA)

事業影響度分析 (BIA) とは、重大インシデントに起因するサービスの中断やダウンタイムの影響の体系的な評価のことです。BIA の目標は、各サービスが事業に与える影響を理解してインシデントが発生した場合の復旧要件を定義することです。

キャパシティ

ネットワーク間で転送できる、またはサービスを介して配信できる情報の最大量。キャパシティ超過は、インシデントの一般的なインジケーターです。

変更

IT サービス、構成、ネットワーク、またはプロセスに加えられた変更。多くの場合は変更管理と呼ばれるプラクティスで追跡されます。

変更履歴

ライフサイクルの開始から現在の状態まで、IT サービス、構成、ネットワーク、またはプロセスに加えられた変更の包括的な記録。

変更管理

重要なシステムおよびサービスの変更/アップデート中の中断を最小限に抑えることに重点を置いた、IT のプラクティス。チームによっては、このプラクティスによって技術的なことから人員やプロセスに関することまで、変更のあらゆる側面に対処します。ITIL 4 ガイドラインに基づき、変更管理では変更の人的側面や文化的側面の管理を中心に行い、変更コントロールと呼ばれる別のプラクティスによってリスク評価、スケジュール、変更承認を行うチームもあります。

ChatOps

チャットとコラボレーションの各ツールを使用したインシデント管理のプラクティス。Atlassian の Sean Regan は次のように説明しています。

「ChatOps は、人、ツール、プロセス、自動化を透明性のあるワークフローに結びつけるコラボレーション モデルです。このフローによって、必要な作業、実行中の作業、完了した作業が、人間の担当者、ボット、関連ツールが配備された固定された場所で結びつけられます」

クローズ済み状態

すべての必要な行動が実行されて課題がクローズされると、インシデントはクローズ済み状態になります。

コールド スタンバイ (段階的な復旧)

コールド スタンバイは、あるシステムが別のシステムのバックアップとして機能している場合に使用されます。プライマリ システムで障害が発生すると、そのシステムが修復されている間、コールド スタンバイが代理します。これは、コンピューティング ハードウェアを交換してセットアップする必要があるイベントが発生して、プライマリ システムの障害の復旧に段階的な復旧 (数週間かかる可能性がある復旧) が必要な場合に、特に役立つ戦略です。

コールド スタート

コールド スタートとは、実行されていないアプリケーションの起動が「ウォーム」状態にあり、すでに実行されているアプリケーションよりも時間がかかる状態です。

コミュニケーション リード

インシデントの発生時にコミュニケーションを担当するチーム メンバー。

コンプライアンス

規制への準拠。監視システムは多くの場合、コンプライアンスの問題を監視して、システムがコンプライアンスに準拠していない場合にアラートをトリガーするようにプログラムされます。

構成要素障害影響分析 (CFIA)

1 つのコンポーネントまたは構成が期待どおりに動作しなくなった場合に、サービスへの影響を判断するプロセス。

同時実行性

1 つのシステム内で同じアクションが同時にいくつ行われているかを示す指標。たとえば、同じ操作にアクセスしているユーザー数や、同じトランザクションを実行しているユーザー数です。

コントロール

リスクを管理して製品やサービスが期待どおりに動作するようにし、コンプライアンスを確保する手順とポリシー。

コア サービス

ユーザー/顧客に中心的機能を提供するサービス。

対策

システムを保護または運用を復旧するために行われる特定のリアクティブなアクション。

顧客向けサービス

顧客が使用して操作するサービス。

Cynefin フレームワーク

インシデント管理プロセスに対応した意思決定構造で、マネージャーが最も効果的な対応を編成するのに役立ちます。このフレームワークは、インシデントの複雑度に基づいて状況を 5 つのカテゴリに分類します。カテゴリごとに独自の (異なる) 次に行う一連のステップがあります。

ダッシュボード

システム、アラート、インシデントの単一画面における表示。さまざまなツールからの情報をコンテキスト情報付きで、簡潔な分かりやすい形式で整理して表示することを目的として設計されています。

依存関係

機能するために互いを必要とする 2 つのサービス、プロセス、構成間の関係。

廃止

機能またはツールが提供されなくなった、使用されなくなった、またはそれ以上アップデートされなくなった状態。

診断

インシデントとその根本原因を理解するプロセスと結果。

診断

インシデントの診断に繋がる症状または徴候。

ダウンタイム/停止

サービスが期待どおりに実行されていないか、利用できない時間。

緊急変更

通常はインシデント解決の一貫として、迅速にデプロイされるアップデートまたはパッチ。緊急変更では、承認を待機するリスクのほうが変更をデプロイするリスクよりも大きいため、多くの場合は変更の承認プロセスがスキップされます。

有効化サービス

コア サービスが機能するために必要であるが、それ単体では顧客に提供されないサービス。

テスト環境*

サービス、機能、プロセス、構成アイテムなどが期待どおりに機能していることをテストするインフラストラクチャ。この環境は本番環境を模倣するように細かく制御されます。

本番環境

顧客へのサービスの提供が行われるインフラストラクチャ。この環境における成果物はライブであるため、ライブ環境と呼ばれることもあります。

エラー

構成アイテムまたはサービスの障害を引き起こす間違い。これには、誤設計、処理の間違い、人為的ミスなどがあります。

エスカレーション

インシデント管理の担当者を、より関連性の高いスキルや経験を持つチームまたは個人に移行するためのプロセス。機能エスカレーションでは、より豊富な専門知識を持つ個人またはチームにアラートまたはインシデントが移行されます。階層エスカレーションでは、当該アラートまたはインシデントが下級スタッフから上級スタッフに移行されます。

イベント

注意が必要なシステムまたはサービスの状況。イベントは通常、ユーザーのアクションまたはインシデントのいずれかによって発生します。

例外レポート

主要業績指標 (KPI) がしきい値を超えているか、期待を満たしていない場合に生成されるレポート。

耐障害性

耐障害性とは、構成アイテムまたは個々の部分に障害が発生してもサービスが運用を継続できる能力を示します。

フォールト ツリー解析

インシデントに繋がったイベントを判別して、どのようなイベントが将来インシデントを引き起こす可能性があるかを予測するために使用されるテクニック。重大インシデントの根本原因を見つけるためによく使用されます。

1 次サポート

インシデントに最初に対応することが期待される応答者。これは通常、オンコールのスタッフです。

修正

修復のアクションや方法。

固定資産

オフィス、コンピューター、ライセンスなど、物理的に存在して、価値のある、ビジネスに長期的に関与するものです。

24 時間態勢スケジュール

カスタマー サポートまたはインシデント管理の方法。異なるタイムゾーン間でオンコールの担当者を交代することで、真夜中にオンコールを担当するチームなしで年中無休の対応を可能にします。

フォレンジクス調査

インシデントの原因を特定することを目的とした、コンピューター システムの科学的な証拠に基づく調査。

機能的

サービスを期待どおりに実行できる場合、そのサービスは機能的であると表されます。

段階的な復旧

段階的な復旧は、通常より長くかかる (数時間ではなく数週間) 復旧プロセスです。このプロセスが行われる場合、通常はコールド スタンバイ (バックアップ システム) がオンラインになって、影響を受けるシステムと交代します。

ホット スタンバイ

ホット スタンバイは、障害が発生した場合に IT サービスをサポートするために冗長資産が同時に実行されている復旧オプションです。アクティブ システムに障害が発生した場合は、チームが操作を行わなくても、すでに実行されているホット スタンバイがダウンタイムなしでそのシステムと交代できます。即時復旧とも呼ばれます。

ホットフィックス

問題の解決またはバグの修正のためにソフトウェアに適用されるアップデート。これは通常、顧客から報告された問題を修正するために使用されます。

影響

サービスの中断、インシデント、または変更によって生じるコスト (金銭、時間、評判) の測定値。ダウンタイムのコストとも呼ばれます。

実践に繋がらないアラート

応答者が行動を起こせないアラート。これは一般に、アラートにコンテキスト情報が不足しているか、誤った担当者に転送されたか、スコープが不明確であることを意味します。実践に繋がらないアラートは、アラートによる疲弊の原因となることがあります。

インシデント

サービスの中断またはサービス品質の低下を引き起こす、緊急の対応が必要なイベント。ITIL または ITSM の実施基準に従うチームでは、重大インシデントという用語を使用することがあります。

インシデント対応

チームによるインシデントへの対応方法。通常は事前設定プロセスであるインシデント対応は、インシデントが発生する前にルール、役割、ベスト プラクティスを定義します。

インシデント管理

DevOps と IT の各運用チームが予期せぬイベントまたはサービス中断に対応して、サービスを運用状態に復旧するために使用するプロセス。

インシデント指揮官

インシデント指揮官は、インシデント対応を管理する責任を持つ IT チームまたは DevOps チームのメンバーです。インシデント指揮官はインシデント管理チームの責任者であり、インシデントに関するすべての決定に対して完全な監督権と最終的な決定権を持ちます。この役割はよくインシデント マネージャーとも呼ばれます。

インシデント ライフサイクル

インシデントの作成、検出から解決までの全プロセス。

入出力指標

入出力を測定する一連の指標。このカテゴリの一般的な指標には、IO 待機 (CPU が IO リクエストを待機する時間) と IOPS (1 秒当たりの IO リクエスト数) があります。

インシデント対応の連携

OpsGenie 機能。チームによる迅速かつ効果的な問題の特定、適切な担当者への通知、事業部間のコミュニケーションの促進、インシデント管理に関するチーム間のコラボレーションを可能にします。

インシデント レコード

特定のインシデントの詳細とその発生中に使用されたプロセスの記録。

インシデント応答者

インシデントの調査と解決を担当する個人やチーム。

インシデント関係者/閲覧者

インシデントがその人の職務や職務遂行能力に影響するため、インシデントについて常に連絡を受ける必要がある個人。このような個人は、インシデントの解決に影響することもしないこともありますが、アクティブな応答者ではありません。

中間的復旧

ウォーム スタンバイとも呼ばれます。このタイプの復旧には通常、24 ～ 72 時間かかります。復旧時間が比較的長くなる主な理由は、データの復元またはハードウェアとソフトウェアの構成、あるいはこの両方です。

IT インフラストラクチャ ライブラリ (ITIL)

広く採用されている IT サービスに関するベスト プラクティスを文書化したもの。

IT サービス管理 (ITSM)

顧客に IT サービスを提供するために必要なプロセスと手順のあらゆる側面。設計から提供やインシデント管理まで、サービス ライフサイクルのあらゆる側面が含まれます。

Kepner Tregoe 手法 (KT 手法)

課題に関する最終的な決定とは別に問題を評価するための、根本原因分析および意思決定手法。

主要業績指標 (KPI)

システムまたは製品の成功の指標。KPI は事前に決定されて定期的に追跡され、多くの場合、予期されるしきい値から逸脱した場合にアラートが生成されます。たとえば、平均故障間隔 (MTBF) が連続して短くなり始めたら、チームが問題を特定して調べられるように、アラートが生成されます。

既知のエラー

すでに回避策がある既存の課題。

レイテンシ

データの転送中に発生した遅延。

ログ

サービスまたはアプリケーションに関連するすべてのイベントの記録。転送されたデータ、日時、インシデント、変更、エラーなどが含まれます。

保守性

変更をサービスまたは機能に正常に適用することがどの程度容易であるかを示す指標。

手動の回避策

(自動ではなく) 手動で実装されたソリューション。

平均故障間隔 (MTBF)

技術製品の修復可能な故障間の平均時間。これは平均サービス インシデント間隔 (MTBSI) とも呼ばれます。

平均確認時間 (MTTA)

アラートがトリガーされてから課題への対応が開始されるまでの平均時間。

平均故障時間 (MTTF)

技術製品の修復不能な故障間の平均時間。

平均修復時間 (MTTR)

(通常は技術的または機械的な) システムの修復にかかる平均時間。修復時間とテスト時間の両方が含まれます。

平均復旧時間 (MTTR)

製品の故障またはシステム障害からの復旧にかかる平均時間。システムの障害または製品の故障が発生した時点から再び完全に動作可能になった時点までの停止時間全体が含まれます。

平均解決時間 (MTTR)

障害を完全に解決するのにかかる平均時間。障害が再発しないことを確認するのにかかった時間も含まれます。

平均対応時間 (MTTR)

製品の故障またはシステムの障害が最初に通知された時点から復旧までにかかる平均時間。アラート システムのタイム ラグは含まれません。

モデル/モデリング

実際のシステム、サービス、アプリケーションなどの表現。

監視

サービスまたはプロセスが期待どおりに機能していることを繰り返し確認するプロセス。

通常変更

定義されて事前承認されたプロセスのない、非緊急の変更。

オンコール スケジュール

昼夜を問わず常に適切な担当者がインシデントや停止に迅速に対応できるようにするスケジュール。医療と技術両方の分野で一般的に使用されます。

オペレーション ブリッジ

IT サービスの監視が行われる物理的な場所。

オペレーション リード

日常の運用を監督する責任者。この人物がインシデント解決を指揮するインシデント マネージャー (またはインシデント指揮官) を兼ねる場合もあります。

結果

IT 関連のイベント、プロセス、または変更の結果。チームは通常、期待される成果と実際の成果の両方について話し合います。

ペイン バリュー分析

インシデントのビジネスに対する影響を特定するために使用される分析。この分析では通常、ダウンタイムのコスト、インシデントの継続時間、ユーザーに対する影響、影響を受けたユーザーの数が要因として考慮されます。

パッシブ モニタリング

サービスの機能が自動的に監視されている状態 (アクティブな監視または手動の監視ではなく)。

平時

サービスと運用が中断されることなく期待どおりに機能している状態。

パフォーマンスの低下

イベントまたはインシデントが原因でシステムのパフォーマンスがどの程度低下したかを示す指標。

計画されるダウンタイム

保守またはアップデートのために、IT サービスを意図的に使用不可にする期間。

プレイブック

一連の「プレイ」または特定のアクション。特定の問題、インシデント、または目標に対処するためにチームが実行できます。

事後分析/インシデント後分析/インシデント後レビュー

インシデントの解決後に、そのインシデントを理解するためのプロセス。事後分析の目標は、対応プロセスの改善、将来のインシデントの防止、最近のインシデントの原因の理解です。

Priority

インシデントへの対応順序。優先度の高いアイテムには、優先度の低いアイテムよりも緊急の対応が必要です。優先度は、緊急度、重大度、ビジネスに与える可能性のある影響によって決まります。

問題レコード

検出から解決まで、問題レコードは問題のあらゆる側面を記述する文書です。

サービス停止の予測

将来の保守またはテストが通常のサービス レベルにどの程度の影響を与えるかを記述した文書。

品質保証

新機能からハウツー ガイドまで、IT 関連のあらゆるものについて基準が満たされていることを確認するテストのプロセス。

品質管理システム

品質保証を提供するために設定されるフレームワークまたはシステム。

リアクティブ モニタリング

イベントまたはインシデントへの応答として行われる監視。

リカバリ

サービスをベースラインの機能と状態に戻すプロセス。

目標復旧地点

復旧中に許容される最大データ損失量。

目標復旧時間

サービスの中断が許容される最大時間。

リリースする

ユーザーにデプロイされる変更。

リリース管理

変更の計画、設計、テスト、スケジュール、トラブルシューティング、デプロイ。

弾力性

インシデントが発生した場合に障害に耐えて迅速に復旧できるシステムの能力。

応答時間

アラートが生成されてからチームによって最初のアクションが実行されるまでの時間。

リスク評価

資産のリスクを判定するプロセス。資産の価値、潜在的な脅威、それらの脅威の潜在的な影響を評価することで判定します。

リスク管理

脅威を識別して制御することにより、脅威に対処するプロセス。

根本原因

根本原因 (root cause) は一般に、サービスまたはアプリケーションで障害が発生した唯一の原因であると考えられています。しかし相互に関係する多数の要因が障害を引き起こすことが多々あるため、インシデント管理においてこの用語が役立つかどうかが問われ始めています。多くのチームは、複数形の root causes という用語を代わりに使用するようになっています。

ランブック

ランブックは、インシデント管理の詳細な手順を定めたものです。これらは通常、システム管理者またはネットワーク運用制御 (NOC) チームによって管理されます。ランブックには、デジタル版または印刷版があります。

スコープ

問題、解決策、プロジェクト、能力などの範囲。

2 次サポート

最初の応答者の能力では対応できない可能性がある問題を解決するための追加能力 (時間、経験、知識、リソースなど) を持つ人物。

サービスの変更

サービスのアップデート、修正、廃止、またはサービスに加えられるその他の変更。

サービスデスク

カスタマー サポート リクエストを受け付けて、顧客と IT 部門の間の連絡窓口として機能するチーム。

サービス障害分析

サービスの中断を調べてその原因を特定するプロセス。

サービス レベル アグリーメント (SLA)

アップタイム、応答性、責任などの測定可能な指標に関するプロバイダーとクライアント間の合意。

サービス レベル アグリーメント モニタリング (SLAM) チャート

サービス レベル目標に関する進捗状況とデータを記録する文書。

サービス レベル目標 (SLO)

アップタイムなどの特定の指標に関する SLA 内の合意。

重大度 (SEV) レベル

インシデントによってサービスが受ける影響の程度。チームは通常、3 ～ 5 階層の SEV レベル構造を使用します。1 が重大度が最も高く、3 ～ 5 はそれほど緊急の対応は不要な、重大度がより低い課題を示します。

単一障害点

システムが機能するために必要な 1 つの変数。たとえば、必須の構成アイテムです。

仕様

IT 関連の構成に関する要件の公式な記録。

サイト信頼性エンジニア (SRE)

運用を任されているソフトウェア エンジニア。SRE は一般に、手動タスクの自動化、SLO の管理、インシデントの管理を担当します。

標準変更

メモリやストレージの追加など、一般的に繰り返される低リスクの事前承認済みの変更。

スタンバイ

インシデント管理をサポートするために使用できる非アクティブなリソース。

状況

サービスの現在の状態。

ステータスページ

サービスの現在の状態を通知するための専用のホーム。インシデントのステータスに関する最新情報が定期的に掲載されます。

対象分野のエキスパート (SME)

特定の課題やサービスなどに関する特定の知識を有する個人。

技術スタック

アプリケーションを構成するプログラミング言語、ソフトウェア、コンポーネント。技術スタックには、フロントエンド (顧客向け) とバックエンド (開発者向け) の 2 つの面があります。

対立関係の指標

1 つのデータ セットまたはデータ ポイントが変更された場合に、他のデータ ポイントに悪影響を与えるデータ。

しきい値

その値を超えるとアラートが生成される、事前定義済みのレベルまたは数値。たとえば、サインイン ページの読み込みのしきい値が 3 秒の場合は、ページの読み込み時間がこれより長くなるとアラートが生成されます。

タイムライン

イベント、変更、修正、結果、これらがそれぞれインシデント発生中にいつ行われたかの包括的なリスト。

トレンド分析

時間関連のパターンの調査。トレンド分析では、過去のパターンからデータの将来のパターンを予測できると仮定しています。このため、インシデントを防止するための有用なプラクティスとなります。

回避策

根底にあるインシデントがまだ解決されていない場合でも、システムの機能を元に戻して稼働させる応急措置を実装するための適切な方法。

ワークロード

IT サービスを提供するために必要な、人的および機械両方のリソース。