閾値を超える遅延が発生してもアラートが発火しない
導入時の実測値から決めた閾値が実際の遅延に対して高いまま残ると、障害に至る遅延でもアラートは発火せず、発見は利用者の申告が起点になります。
GENZ, Inc.
監視設定そのものを
APMツールの
監視設定そのものを
APMツールの異常検知設定を第三者が検証します
導入したAPMツールの閾値や計測範囲が実際の異常を検知できる状態かを、第三者の視点で異常を意図的に発生させて検証し、報告書として残します。
支援事例
支援実績5,000件以上
APMツールを導入したシステムでよくある不具合
APMツールを導入しても、監視設定そのものの妥当性を確かめなければ、異常を検知できない状態が残ります。導入・リリース・改修の各場面で起きやすい不具合を、設定の作り方に沿って整理します。
閾値を
非同期処理とバッチ処理がトレースに記録されない
APMエージェントは同期的なリクエストを追う設定で組み込まれるため、非同期処理やバッチ処理はトレースに含まれず、処理異常が記録に残りません。
機能追加したエンドポイントが計測対象に含まれないまま稼働する
リリースで追加したエンドポイントへのエージェント組み込みは、テスト項目書に含まれず見落とされます。新機能の応答時間とエラー率が計測されません。
合成監視のシナリオが画面変更に追従せず、正常時に失敗が計上される
合成監視のシナリオは登録時点の画面操作を模して作られます。項目名や遷移が改修で変わるとシナリオが追従せず、正常な操作を失敗として計上します。
深夜帯のアラートが通知先に届かず、翌朝まで誰も気づかない
アラートの発火が記録されていても、チャットツールやメールへの連携設定に不備があれば担当者へ届きません。深夜帯の異常は翌朝まで認識されません。
残存した不具合により生じる問題
閾値の妥当性や計測対象外の経路が確認されないままでは、検知できない異常が残ります。監視設定の不備が事業へ及ぼす問題を整理します。
静的テスト（レビュー）でおさえるべき観点
APMの監視設定は、動かしてみなくても書類上で確かめられる部分があります。本番で異常を意図的に発生させる検証の前に、設定値や計測範囲を業務側の基準と照合するレビューで、設定の不整合の多くを洗い出せます。
閾値が業務の許容応答時間より緩いままだと、利用者が遅延を感じる水準でもアラートが発生せず、発見が利用者からの申告に頼る状態が続きます。
設定した閾値を業務の許容応答時間と照合する
応答時間とエラー率の閾値は、導入時の実測値から決められたものが多くあります。業務上どこまでの遅延を異常と見なすかという許容応答時間と照合し、閾値が業務の基準より緩くないかを確認します。
確認する資料
- 閾値設定一覧
- SLA・許容応答時間定義
- 業務要件定義書
計 計測対象から抜けた処理で障害が起きると、APMの記録に痕跡が残らず、原因の特定がログの手繰りに頼り、復旧までの時間が延びます。
計測対象の一覧をアプリケーションの処理一覧と照合する
APMの計測対象に登録された処理の一覧と、アプリケーションが実際に持つ処理の一覧を照合します。追加された処理や非同期処理・バッチ処理・外部APIへの発信が抜けていないかを確認します。
確認する資料
- 計測対象一覧
- 処理一覧・画面一覧
- システム構成図
通知先の割り当てが運用体制と一致していないと、アラートが発生しても一次対応に入る者がおらず、検知から対応開始までの時間が空転します。
アラート条件と通知先の割り当てを運用体制の担当表と照合する
アラートの発生条件と、通知先に割り当てられた担当者を運用体制の担当表と照合します。通知先が退職者や担当外の宛先のままでないか、一次対応の体制と通知の優先度が一致しているかを確認します。
確認する資料
- アラート条件設定表
- 通知先設定一覧
- 運用体制・担当表
合成監視のシナリオが実際の操作とずれたままだと、シナリオ上は正常でも業務側では操作が完了せず、監視結果と利用者の体感が食い違ったまま説明できなくなります。
合成監視シナリオを業務の主要操作手順と照合する
合成監視のシナリオが想定する操作手順と、業務部門が実際に行なう主要な操作の手順を照合します。改修で操作手順が変わった後も古いシナリオのままだと、正常応答の記録が実態を反映しません。
確認する資料
- 合成監視シナリオ定義
- 業務操作手順書
- 画面遷移図
データ保持期間が障害調査の要件より短いと、事後調査で発生時点の記録を参照できず、システム監査で監視の有効性を示す証跡の提示に支障が出ます。
データ保持期間と集計の時間窓を障害調査の要件と照合する
APMのデータ保持期間と集計の時間窓を、障害調査で遡る必要のある期間や、月次レポートで傾向を見る時間軸と照合します。保持期間が調査の要件より短いと、必要な記録が残りません。
確認する資料
- データ保持設定
- 集計・時間窓設定
- 障害調査手順書
- 月次報告様式
動的テストの設計・実行のポイント
監視設定が業務上の異常を捕捉できるかは、異常を意図的に発生させる動的テストで確かめます。設計と実行のポイントを順に示します。
STEP 01
閾値の境界値テスト閾値は実測値由来のため発火確認の記録が残りにくい
どう確かめるか
閾値の境界値を用いて発火条件のユニットテストを行なう
閾値の境界値に対し、応答時間とエラー率が直前・一致・超過となる条件でアラートが発火するかをユニットテストとして確認します。実測値から置いた閾値が実際の異常で発火するかを確かめます。
- 01設定中の閾値と境界値の一覧を運用担当と整理する
- 02境界値の直前・一致・超過の条件でアラート発火を確認する
- 03発火条件と結果を設定ごとの記録として残す
OUTPUT発火条件の妥当性記録
STEP 02
異常の発生と記録の確認計測対象外の経路はレポート上健全に見える
どう確かめるか
遅延とエラーを意図的に発生させて検証し、トレースへの記録を確認する
検証環境で遅延とエラーを意図的に発生させ、APMのトレースに発生箇所と原因が残るかを確認します。非同期処理・バッチ処理・外部APIへの発信は計測対象外になりやすく、個別に確かめます。
- 01検証環境で遅延とエラーを意図的に発生させる
- 02非同期処理・バッチ処理・外部APIへの発信の記録有無を確認する
- 03トレースの記録と発生させた異常を突き合わせる
OUTPUTトレース記録の確認結果
STEP 03
通知経路の到達確認発火と到達は別の設定であり個別に確認する
どう確かめるか
アラート発火から通知先への到達までを統合テストで追跡する
アラートの発火からチャットツール・メール・インシデント管理ツールへの通知到達までを、統合テストとして追跡します。発火しても通知先に届かない設定不備を到達確認で切り分けます。
- 01通知先のチャットツール・メール・インシデント管理ツールを洗い出す
- 02アラート発火から各通知先への到達までを追跡する
- 03到達しなかった経路の設定不備を特定し記録する
OUTPUT通知経路の到達記録
STEP 04
負荷時の計測と回帰テスト改修でトレースの区切りが変わり設定が陳腐化する
どう確かめるか
負荷をかけたパフォーマンステストで計測の欠損と回帰テストを実施する
想定負荷をかけたパフォーマンステストで計測の欠損を確認し、改修後は監視設定にも回帰テストを実施します。処理の構成が変わるとトレースの区切りも変わるため、リリースごとに確認します。
- 01想定負荷をかけた状態で計測の欠損を確認する
- 02改修後の監視設定に回帰テストを実施する
- 03リリースごとの確認対象としてテスト項目書へ組み込む
OUTPUT計測欠損の有無の記録
GENZが代行するAPM監視設定のテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 異常を意図的に発生させ、閾値が機能することを確かめられます
- 業務の流れに沿って計測されていない経路を網羅的に洗い出せます
- 設定を作った側とは別の第三者の視点で妥当性を確認できます
- 検証結果を証跡として残し、監査や上位への説明に使えます
第三者が設定そのものを検証します
APMを導入していても、設定した閾値が自社の異常を検知するかは、作った側の自己点検では確かめきれません。GENZは第三者の視点で監視設定そのものをテスト対象とし、異常を意図的に発生させて検証します。
業務の許容水準からテスト設計を起こします
検知すべき異常を業務の許容水準から定義し、アラートが発火する閾値かを逆算してテスト項目を作ります。稼働中の設定を保ったまま検証します。
計測の抜けを突き合わせ検証範囲を決める
計測対象を業務の流れに沿って一覧化し、非同期処理やバッチ処理など監視の対象外になりやすい箇所と突き合わせて検証範囲を切り分けます。
既存のリリース周期に検証を組み込む
運用を止めずに進めるため、既存のリリースサイクルと変更管理の手続きに合わせて検証を組み込みます。運用担当の参加は要所だけに絞ります。
テスト項目書と不具合票の形で納品
検証結果はテスト項目書と不具合票として納品します。閾値ごとの期待動作と実測結果を対で残し、システム監査やリリース判断の材料にできます。
ご相談から納品までの流れ
監視設定の検証は、現状の把握から再確認まで順を追って進めます。成果物は社内説明にもご活用いただけます。
現状の監視設定と対象システムのヒアリング
APMの設定、閾値、通知経路をご担当者様へ伺い、検証対象を整理します。
検証範囲のテスト設計と見積もりの提示
検証範囲をテスト項目として設計し、実施期間と工数を見積もりとして提示します。
テストの実施と検出事項の随時共有
検証環境で異常を意図的に発生させて検証し、検出事項は随時ご報告します。
報告書の納品と修正後の再確認
検証結果を報告書として納品し、設定の修正後に有効性を再確認します。
監視設定の検証範囲の整理から
APMの監視設定をどこまで検証するか、範囲と優先順位からご相談ください
APMを導入済みでも、設定の妥当性を確かめた記録がなければ監査や障害レビューで説明に困ります。第三者の視点で検証を進める前に、対象範囲と優先順位を整理するご相談をお受けします。