設計したしきい値を超えても通知が発報しない
実装が設計どおりかを構築側の報告以外で確かめる手段がないと、障害時に初めて不発に気づき、検知が利用部門からの連絡に頼ることになります。
GENZ, Inc.
鳴るべき通知が、鳴るか。
監視アプリと
鳴るべき通知が、鳴るか。
監視アプリと監視ツールを第三者が検証
監視が障害時に設計どおり通知を出すかは、設定値の確認だけでは分かりません。GENZは発注側にも構築側にも属さない第三者として条件を与えて検証します。
支援事例
支援実績5,000件以上
監視の検証で見落とされやすい欠陥
監視の不具合は、平常時には表面化しにくく、障害の発生時に初めて露見する性質を持ちます。ここでは、更改や受け入れの検証で見落とされやすく、実際の運用で被害につながる五つの欠陥を示します。
設計した
障害が復旧したあとも同じ通知が鳴り止まない
復旧判定の条件が実装に落ちていないと、事象が解消したあとも通知が届き続けます。切り分けに当番の時間が取られ、本来必要な通知への反応が遅れます。
通知先の名簿が実際の当番体制と一致していない
組織変更や当番の交代で通知先の名簿が更新されないままだと、発報はされても対応できる担当者に届かず、対応開始までの時間が延びます。
監視の仕組みが停止したこと自体を検知できない
監視の仕組みが停止すると、通知が来ないことと異常がないことを区別できません。死活を確かめる仕組みがなければ、停止に気づかない期間が続きます。
画面に表示される値が実際の状態とずれている
取得する値の単位や集計の方法が実際の状態と合っていないと、画面では正常でも現地ではしきい値を超えていることが起こります。
検証しないまま監視を切り替えたときに起こること
監視基盤を更改しても、設定どおりに通知が出ることを確かめないまま本番に移すと、障害の検知遅れや誤報の滞留がそのまま運用に持ち越されます。
第三者のテストチームが確認する観点
第三者のテストチームは、構築側の報告書では確かめられない「設計どおりに検知するか」を、条件を意図的に発生させて確認します。観点は設定の正しさにとどまらず、検知から通知、記録までの一連の挙動を対象とします。
構築側の動作確認報告だけに依拠すると、設定は正しくても設計意図どおりに検知しない差分が残り、更改後の障害で検知漏れとして表面化するおそれがあります。
監視項目としきい値が設計どおりに設定されているか
設計書に記載された監視項目としきい値が、実装側の設定へ正しく反映されているかを照合します。しきい値を境に検知する側としない側の双方で値を与え、発報と抑制が設計どおりに分かれるかを検証します。
確認する資料
- 監視設計書
- しきい値一覧
- 設定画面の記録
復旧後の正常化を確かめないままリリースすると、通知が止まらず当番での切り分けに時間が費やされ、本来の監視業務が滞るおそれがあります。
検知から復旧までの状態の移り変わりが想定どおりか
障害の発生から検知、通知、復旧後の正常化まで、監視ツールが示す状態が想定した順序で移るかを検証します。復旧後も通知が止まらない、同一事象で通知が重複するといった誤報の芽を、ここで検出します。
確認する資料
- 検証手順書
- 状態遷移の記録
- 通知ログ
通知経路が運用体制と食い違うと、検知しても対応できる担当へ届かず、障害の一次検知が利用部門からの連絡になるおそれがあります。
通知経路とエスカレーション先が運用体制と一致しているか
通知が届く先とエスカレーションの順序が、当番体制や所管の対応付けと一致しているかを確認します。休日夜間の当番切り替えや、一次受けから上位担当への引き継ぎが実態どおりに動くかを確かめます。
確認する資料
- 通知先名簿
- 当番体制表
- 受信記録
運用中の追加・削除が検証されないまま蓄積すると、設計書と実装の差分が広がり、現行の監視が何を対象とするかを誰も一次情報として示せなくなるおそれがあります。
監視対象の追加や削除に既存の設定が追随するか
サーバーやサービスの増減で監視対象を登録・削除した際、既存の監視項目や通知先の設定が意図せず変わっていないかを検証します。運用で積み重なる変更が設計との差分として残っていないかも確認します。
確認する資料
- 変更申請記録
- 設定差分一覧
- 変更後の確認結果
検知と対応の記録が残らないと、監査や事後調査で証跡を提示できず、確認していないのか確認して問題がなかったのかをあとから説明できなくなるおそれがあります。
検知と対応の記録があとから追跡できる形で残るか
検知の記録と対応の記録が、あとから追跡できる形で残るかを確認します。発報しなかった事象についても「確認して問題がなかった」と示せるよう、検証の手順と結果を証跡として整理して引き渡します。
確認する資料
- 検知履歴
- 対応記録
- 検証結果報告書
- 証跡一覧
提供するテストサービスの内容
設計書と実装の差分を第三者の視点で確かめ、通知が鳴る経路と鳴らない経路の両方を検証します。結果は証跡とともに引き渡します。
STEP 01
現行の監視設計と運用手順の読み合わせ設計書と現行設定の差分を洗い出します
どう確かめるか
監視設計にもとづくテスト計画とケースの作成
監視項目としきい値を設計書から読み取り、鳴るべき条件と鳴らないべき条件の両方を確認対象として計画に落とします。構築ベンダーの動作確認とは性質が異なることを計画の段階で示します。
- 01監視項目としきい値を定めた設計書の記載を確認します
- 02通知経路と当番体制の対応付けが合っているか確認します
- 03運用のなかで加えられた設定変更の履歴を洗い出します
OUTPUTテスト計画書とテストケース
STEP 02
テスト計画とテストケースの作成鳴る条件と鳴らない条件を両立案します
どう確かめるか
開発の進行に伴走しながら実施するテスト工程
更改や改修のスケジュールに合わせ、構築の完了を待たずに検証環境での準備を進めます。実装が整い次第、通知の発報と抑止の挙動を順次検証し、リリース判断に間に合う形で結果を届けます。
- 01検知すべき事象ごとに発報の条件と確認の手順を定義します
- 02正常な状態で鳴らないことを確かめる条件を定義します
- 03検証の優先順位と必要な工数の見通しを計画にまとめます
OUTPUT検証結果の報告書
STEP 03
検証環境でのテスト実施と事象の再現条件を意図的に発生させて検証します
どう確かめるか
大規模なシステム構成を対象とした検証範囲の設計
複数の業務システムを対象とする集中型の監視では、項目ごとの依存関係を整理したうえで検証範囲を切り分けます。業務停止の影響が大きい経路から優先順位を付け、検証の順序を決めます。
- 01しきい値を超える条件を発生させて通知を検証します
- 02通知の抑止条件と集計間隔の挙動を条件ごとに検証します
- 03通知先への到達と通知内容の正しさをあわせて確認します
OUTPUT検知と対応の証跡一式
STEP 04
結果の報告と残る課題の引き渡し証跡と残課題を整理して引き渡します
どう確かめるか
テスト結果の報告と証跡の整理および引き渡し
検知した事象だけでなく、検知しなかった条件についても確認した記録を残します。監査や事後調査で求められる「確認して問題がなかった」ことを、あとから証跡として提示できる形に整えます。
- 01検証の結果を受け入れ判断に使える形にまとめて報告します
- 02検知しなかった条件についても確認した記録を残します
- 03設計書との差分と残る課題を一覧に整理して引き渡します
OUTPUT残課題と設定差分の一覧
社内で実施する場合と外部へ委託する場合の違い
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 障害を待たず、条件を与えて通知の到達まで検証できる
- どこまで確認すれば足りるかの基準を社内に持たずに済む
- 兼務の体制のまま、検証の実施を切り出せる
- 稟議と監査の場に出せる証跡が手元に残る
対応する監視の領域と検証の範囲
監視基盤が扱う領域は、機器の稼働から業務アプリケーションの処理結果、ログにもとづく検知まで幅があります。GENZは領域ごとに、意図した条件で検知と通知が起きるかを確認し、対象外とした範囲も記録として残します。
サーバーとネットワーク機器の稼働監視
サーバーやネットワーク機器の停止・高負荷を条件として与え、しきい値どおりに検知され当番へ通知が届くかを確認します。
業務アプリケーションの応答と処理結果の監視
業務アプリケーションに応答遅延や処理の失敗を意図的に発生させ、監視側で検知され通知先まで届くかを検証します。
ログとイベントにもとづく検知
検知対象となるログやイベントを意図的に発生させ、定めた条件で拾われ、誤報なく通知へつながるかを確認します。
監視状況を参照する画面の表示確認
監視画面やダッシュボードの表示が実際の状態と一致しているかを突き合わせ、検知漏れや表示の遅れがないかを確認します。
お問合せからテスト開始までの流れ
お問合せからテスト開始までの各段階で確認する内容と、ご準備いただく情報を示します。
お問合せフォームからのご連絡
監視対象の概要と相談内容をフォームにご記入ください。担当者より折り返します。
監視の範囲と課題のヒアリング
監視項目、通知経路、これまでの課題を伺い、検証が必要な範囲を整理します。
お見積とテスト計画・期間のご提示
整理した範囲をもとに、テスト計画と費用、必要な期間を提示します。
ご契約と検証環境でのテスト開始
ご契約後、検証環境の準備が整い次第、計画に沿ってテストを開始します。
まずはテスト範囲の見立てから
監視の検証をどこまで実施するか、範囲の相談から承ります
ご相談では、監視対象と通知経路の整理をもとに、テスト範囲と優先順位、必要工数の考え方、関連テストの要否までを整理してお渡しします。見立ては稟議や検討の材料としてご活用いただけます。