ch3 アラート、オンコール、インシデント管理
-
インフラはどういうわけか真夜中におかしな動きをする
-
監視の定義
- あるシステムやそのシステムのコンポーネントの振る舞いは出力を観察しチェックし続ける行為
- 監視は、質問を投げかけるためにある。
— Dave Josephsen, Monitorama 2016
-
アラート
- 監視の達成手段の一つ
-
アラートがないと、おかしくなる可能性のあるものを常に眺め続けることになる
- システムはどんどん複雑化するので実質不可能
-
困難性
-
誤陽性
- メトリクスが急峻に変化するので、誤って警報を送ってしまう
-
移動平均で「ならす」必要がある
- 【所感】より一般に、窓関数を畳み込んでも良さそう
-
精度の低下
- 「ならし」すぎ
-
人間の注意力の限界
- アラートを受け取るたびに人間の注意力は少しづつ削られていく
- 集中したいタスクに対して「割り込み」にほかならない
-
-
本章の内容
- よりよいアラートを作るためのヒント
- オンコールの辛さと苦しさ
- インシデント管理と障害の振り返り
3.1 どうしたらアラートをよくできるか
-
アラートの種類・定義
-
誰かを叩き起こすためのアラート
- 緊急、システムダウンの危機
-
通知手法
- 電話
- テキストメッセージ
- アラーム
-
参考情報(FYI)としてのアラート
-
緊急度低
- 例: 夜間バックアップ失敗
- アラートというか、ただのメッセージ
-
通知手法
- ログ
- 社内チャット
- チケット自動生成
-
-
-
よいアラートの仕組みを作る6つの方法
- アラートにメールを使うのはやめよう
- 手順書を書こう
- 固定の閾値を決めることだけが方法ではない
- アラートを削除し、チューニングしよう
- メンテナンス期間を使おう
- まずは自動復旧を試そう
3.1.1 アラートにメールを使うのはやめよう
-
すぐに応答かアクションが必要なアラート
- SMS
- PagerDuty
-
注意が必要だがすぐにアクションは必要ないアラート
- 社内チャット
- メールでもいいけど受信箱がいっぱいに
-
履歴や診断のために保存しておくアラート
- ログファイル
アラートのログをとる
- どの部分でトラブルが多いかがわかる
- 改善の焦点
3.1.2 手順書(runbook)を書こう
-
アラートが来た時にすばやく進むべき方向を示す
- 何らかの問題を解決するのに、人間の判断と診断が必要なときのためのもの
- 修復手順がシンプルなら、修復まで自動化してアラートを完全に削除するべき
- アラートには手順書へのリンクを含める
3.1.3 固定の閾値を決めることだけが方法ではない
-
例: ディスクの空き容量
- 「空き容量が10%以下」という閾値
-
一晩で11%から80%に増えても見逃してしまう
- 翌日死ぬ
- 変化量、グラフの傾き
- 移動平均
- 信頼区間
- 標準偏差
3.1.4 アラートを削除し、チューニングしよう
-
うるさいと誰も見なくなる
- 【所感】僕の職場のアラートメールフォルダは2,000件くらい未読です
-
鈍感
- 「数分で消えるから放置していい」
- アラート疲れ
-
アラートを減らそう
- すべてのアラートは誰かがアクションする必要がありますか
-
履歴をみる
- どんなアラートがあったか
- どんなアクションをとったか
- 消せないか
- 閾値を変更できないか
- 監視内容をより正確にできないか
- 修復まで自動化できないか
3.1.5 メンテナンス期間を使おう
- アラートを「メンテナンス期間」に入れて、一時的に無効化する
-
例: ダウン時に送られるアラートは、サービスをダウンする作業の際には切ろう
- 有効にしておくと気が散るだけ
-
作業していることを知らないチームメンバーがいればなおさら
- びっくりしちゃう
-
広範に全部切るのはそれはそれでよくない
- おもわぬ依存性があり、他サービスも死んだりするのはよくあること
- 全てのアラートを無効化すると気づけない
3.1.6 まずは自動復旧を試そう
-
アラート疲れを避ける
-
巨大なシステムではとくに必須
- さもないと人件費がやばい
-
- まず自動復旧を目指す
- 無理ならアラート + 手順書
3.2 オンコール
- 何かあったときに飛び起きる人
3.2.1 誤報(false alerm)を修正する
- 100%は不可能だが、100%に向けて努力はすべき
- オンコール担当にアラート一覧を作らせる
- アラートのチューニングに活用する
3.2.2 無用の場当たり的対応を減らす
- 正しいアラートが大量に送られる = システムが不安定
-
オンコール担当は場当たり的対応を強いられる
このクソを直しちまえよ.
— 筆者同僚 - 監視はシステムの状態を修復するが、壊れているものを直してはくれない
-
壊れているものを直していくための戦略
- 場当たり的対応していない時間を、システムの回復力や安定性の向上に割く
-
前週のオンコールの際に収集した情報をシステムの回復性や安定性の向上のために活用する
- スプリント計画
- チーム会議
3.2.3 上手にオンコールローテーションを組む
-
ずっとやってると燃え尽きちゃう
- 怒りっぽくなる
- 睡眠不足
- 心配性
- 4人で、4週のうち1週担当で回すと良い
-
バックアップ要員は要らない
- 4週のうち2週も担当するのは重い
- 独りもしんどいのでエスカレーションパスは要る
- ソフトウェアエンジニアも
FTS: Follow The Sun
-
功
- 誰も夜中にオンコール担当にならないですむ
-
罪
- 作業の引き継ぎオーバーヘッド高い
オンコールに対する補償
-
大変だから補償してあげるのは公平
- 有給
- 手当
3.3 インシデント管理
- 発生した問題を扱う正式な手順
- インシデントとは
予定していないITサービスの中断、または、ITサービス品質の低下
ITIL 2011
ITILのインシデント管理プロセス
-
プロセス
- インシデントの認識
- インシデントのロギング
- インシデントの分類
- インシデントの優先順位付け
- 初期診断
- 必要に応じたレベル2サポートへのエスカレーション
- インシデントの解決
- インシデントのクローズ
- インシデント発生中におけるユーザコミュニティとのコミュニケーション
-
形式ばっている
- インシデントの認識と対応に関する正式で一貫した方法
- チームに一定の厳格さと規律が生まれる
- やりすぎ
著者提示のシンプルなやつ
-
プロセス
- インシデントの認識(監視が問題を認識)
- インシデントの記録(インシデントに対して監視の仕組みが自動でチケットを作成)
- インシデントの診断、分類、解決、クローズ(オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする)
- 必要に応じて問題発生中にコミュニケーションを取る
- インシデント解決後、回復力を高めるための改善策を考える
インシデント対応の社内標準を決めることのすすめ
- インシデントのログが残される
- 一貫性をもって追跡調査される
-
何が起こっているか知ることができる
- ユーザ
- 経営者
- 顧客
-
どんなパターンで問題があるか、どこで問題が起きやすいかチームが知ることができる
- アプリケーション
- インフラ
重めのインシデントへの対応
- 数分以上サービスが止まってしまうやつ
-
役割(兼任非推奨)
-
現場指揮官(IC: Incident Commander)
- 意思決定する人
- インシデント初期、オンコールが一時的に務めることがある
-
スクライブ(scribe)
- 書記
-
コミュニケーション調整役(communication liaison)
- ステークホルダーと最新情報をやり取りする人
- 矢面に立つ人
-
SME: Subject Matter Expert
- インシデント対応作業を実施する人
-
further
3.4 振り返り(postmortem)
- インシデント発生後の議論の場
- postmortem: 「検死」の意
-
blameするのはやめようね
- ミスを隠すようになる
3.5 まとめ
-
アラートを正しい方向に進める
- アラートをメールで送らない
- 手順書を書く
- すべてのアラートがシンプルな閾値で決められるとは限らない
- 常にアラートを見直す
- メンテナンス期間を使う
-
誰かにアラートを送る前に自動復旧を試す
- 手順書がシンプルなコマンドの羅列なら自動復旧できるサイン
- オンコールの仕組みを改善する
- 自社に合ったインシデント管理システムを作る