Kompira

Menu Menu

Column

2021/03/17

監視疲れを起こさない工夫

こんにちは。フィックスポイントの冨です。

昨年にアラートメッセージの判断を自動化する”AlertHub”をリリースして以降、様々なプロジェクト、インフラでのシステム監視の実情をお伺いする機会がありました。
毎日、恐ろしい数のメッセージを捌いておられる現場や、オンコールのローテーションを少人数で組んでいて、何とか対応しているなど、それぞれの現場ごとに、なかなかご苦労されている様子を垣間見ている気分になります。

システム運用のツラい側面の1つとしてアラート対応があります。特にうるさ過ぎるアラートにはイライラしがちですし、さらには誤報と分かった瞬間の脱力感は経験した者でないと分からないでしょう。アラートを受け取るとアドレナリンが分泌されますし、問題対応を頻繁に繰り返していると、アラート疲れを起こして燃え尽きてしまいます。

極端にアラート発生件数が多い場合には、運用しているアプリケーションの品質に問題がある事が疑わしく、ログ情報を元にして改善を試みる必要があります。ある程度、順調に稼働しているシステムのアラートの改善については、いくつかの観点から見直しが必要です。極力、送出数を限定する事と、どのようなトラブルが発生していて、どのようなユーザー影響が出ているかを過不足なく伝える工夫が必要となります。

(1) 至急にアクションが必要な状況なのかを判断する
サービス提供に問題が発生し、エンジニアを叩き起こしてでも対応が必要な局面でのみアラートを送信すべきです。言い換えれば、システムに何らかの問題が生じたものの一時対応の自動化で復旧した場合や、一時的な負荷増大で自然に復旧した場合など、後からの対応で十分な場合にはアラートを送るべきではありません。発生記録を残しておいて、後で振り返れば良いものです。

(2) 見ても対応しなかったアラートは削除する。
システムから警告のメッセージを受信したものの、特にアクションを起こさなかったものについては、(1) 同様に「アラート」では無いと考えて、送信設定をスキップします。もちろんソフトウェア改善のための基礎資料としての価値がある場合には、それらのメッセージを記録保存することは、何ら問題ではありません。

(3) メトリックからのアラート設定を閾値だけでなく、変化率も考慮する。
極端な場合では、ディスクを毎日0.1%ずつ使うような場合で、ある日、利用率が閾値の90%を超えた場合。翌日の見込みが90.1%なので、緊急で何かをしなければ危険というわけでもありません。
1日で利用率が20%から60%に急上昇した場合、閾値からはかなり離れていますが、この増加率のまま放置すると翌日のディスクフル障害のリスクは非常に高い可能性があるとみるべきでしょう。
メトリックの変化傾向を考慮し、アラート発生基準をチューニングする必要があります。

その他、アラート発生時の手順書を整備する。各メトリックの変化とユーザー影響との関連性を明確にする。など、いろいろとストレス軽減の取り組みの余地はあると思います。
やみくもに全部に人力で対応しようとすると無理が出ますので、アラート送出の基準の見直しを積み重ねて、適切な質・量を保てるように工夫してください。

コラム一覧
2022年
2022.04.27
運用管理に向いているDMAICフレームワーク
2022.04.20
お勧め本「システム運用アンチパターン」
2022.04.13
IPA 「DX実践手引書」の改訂版を発表
2022.03.31
春は引継ぎのシーズン
2022.03.24
「なぜなぜ分析」の使い方
2022.03.16
マルウェアEmotet再流行
2022.03.09
省エネモードのエンジニア
2022.02.24
ヒューマンエラーを防ぐには
2022.02.16
インフラ維持と式年遷宮
2022.02.09
Web3.0とP2Pの復権
2022.01.24
JIS規格に学ぶリスクマネジメン
2022.01.19
多すぎる通知の副作用
2022.01.12
2022年のインフラ技術
2021年
2021.12.29
今年もお世話になりました
2021.12.22
品質レベルはステージごとに変わる
2021.12.15
ログ出力ライブラリLog4j脆弱性の影響
2021.12.09
リモート作業の問題点
2021.11.24
メタバースに未来はあるか
2021.11.17
インシデントとの向き合い方
2021.11.10
DXは差別化要素を作るための投資という視点
2021.10.27
監視の拡張としてのオブザーバビリティ
2021.10.20
良い自動化、イマイチな自動化
2021.10.13
みずほ銀のトラブルから学ぶ
2021.09.29
クラウドDBで時短
2021.09.22
そろそろWindows 11が到来します
2021.09.15
トラブル対応の心がけ
2021.09.08
10/10は「デジタルの日」
2021.08.25
運用なき開発を避ける
2021.08.18
日本のDXの最前線
2021.08.12
DXとアジリティ
2021.07.14
ポストコロナで会議室が足りなくなる?
2021.06.30
自動化の技術選択
2021.06.23
業務の自動化は入り口にすぎない
2021.06.16
データ入力のお作法
2021.05.26
「苦労に価値がある」という価値感
2021.05.19
「運用でカバー」する公共システム
2021.05.12
VUCAの時代を生き抜くスキル
2021.04.28
デジタル敗戦からの復興はなるか
2021.04.21
PCの「基本的人権スペック」
2021.04.14
お勧め書籍「運用改善の教科書」
2021.03.31
運用スタッフの大部分はリモートワークへ
2021.03.24
定型業務をプログラマブルに
2021.03.17
監視疲れを起こさない工夫
2021.03.08
MSの無料RPAは自動化の起爆剤となるか
2021.02.22
終わりなき開発とインフラ運用
2021.02.17
作業を自動化しても業務が効率化しない場合
2021.02.10
Cocoaのバグが4か月も発覚しなかった話
2021.01.27
「クソどうでもいい仕事」を考える
2021.01.26
「クソどうでもいい仕事」を考える
2021.01.20
自動化の次の課題としてのAIOps
2021.01.13
DXレポート2が公開されました
2020年
2020.12.21
今年もお世話になりました。
2020.12.16
どうなる? 2021年のITインフラ
2020.12.09
アドベント・カレンダーの季節です
2020.11.11
AI・業務自動展で見聞きしたツライお話
2020.11.04
「7番セカンド」な仕事
2020.10.21
システム監視とアラート地獄
2020.10.19
機械学習とシステム運用
2020.10.14
形あるものは壊れる。システムも。
2020.09.30
技術ドキュメントの課題
2020.09.23
デジタル庁に寄せる期待感
2020.09.16
ローコード開発とエンジニア不要論
2020.09.09
技術の近未来予測とニューノーマル対応
2020.08.26
“アンチフラジャイル”な考え方
2020.08.19
カオスエンジニアリングという考え方
2020.08.12
運用が稼ぐ時代
2020.07.29
AIシステムの運用
2020.07.22
新宿に宿泊でTDLにGoToは対象外?
2020.07.08
チェック回数を増やしても意味がない
2020.06.24
「時代はクラウド」発言と政府インフラ
2020.06.17
システムの標準化とスキルセット
2020.06.10
「2025年の崖」からの転落事故
2020.05.20
先端IT“非”従事者は勉強不足 from IP
2020.05.12
スペイン風邪にみるコロナ第二波へ備
2020.04.30
「運用でカバー」という魔法の言葉
2020.04.26
未然に防いだトラブルは評価されにくい
2020.04.22
リモート勤務で重要性を増す「ゼロ・トラスト」セキュリティ
2020.04.15
オンラインイベント「Ops Summit2020」開催!
2020.04.15
コンサルは「標準化しろ」とは言うけれど
2020.04.08
オンライン”Zoom”会議のセキュリティー問題
2020.03.23
ドキュメントで見かける”Day 2オペレーション”
2020.03.18
今、売れまくっているITサービス
2020.03.11
出社している場合じゃないご時世
2020.02.26
新型コロナウィルス対策に学ぶトラブル対応
2020.02.19
バレンタインデーにシステム統合の本がバカ売れ
2020.02.12
ハイパーオートメーションの時代
2020.01.29
インフラ運用リーダーが備えるべき10の能力
2020.01.22
障害発生時の夜中に叩き起こす技術
2019年
2019.12.11
RPAとRBAと運用自動化
2019.12.11
年末年始に読む運用関連本
2019.11.27
業務フローの「こんまり」のお勧め
2019.11.20
「システム運用自動化」はスモールスタートで
2019.11.13
運用事故では人を責めない
2019.01.15
話題の「クラウドネイティブ」とは何か?