この文書は、アラート、<wbr>オンコール、<wbr>インシデント管理
の
監視の 定義と、 アラート の 位置づけ
監視の
定義 監視とは、
ある システムや その システムの コンポーネントの 振る 舞いや 出力WO観察し チェックし 続ける 行為である。 アラートの
位置づけ アラート は
監視と いう 行為を 達成する 為の 1つの 方法。
アラート を うまく 送る ことが 難しい 理由
システムの
メトリクスは、 変化しやすく、 適切な 送付の 基準を 作るのが 難しい。
データポイントによる 閾値設定では、 誤報が 増える。 移動平均に よる 閾値設定では、 情報が 丸められて 重要な 情報を 見逃す ことがある。 アラート は
人間に 送られる ことが 多い。
人間の注意力には 限界が あり、 監視システムに よって 注意力が 削られていく ことになる。
3.1 どうしたら アラート を よくできるか
コンテキストに
1. 誰かを
例) 全サーバーが
電話、
2. 参考情報(FYI)と
すぐに
参考情報(FYI)と<wbr>しての<wbr>アラート
は
ログ、
3.1.1 アラート に メールを 使うのを やめよう
アラートの
注意が
必要だが すぐに アクションは 必要ない アラート 履歴や
診断の ために 保存して おく アラート
3.1.2 手順書を 書こう
runbook=手順書
よい手順書は、
これは
何の サービスで、 何を する ものか。 誰が責任者か
どんな
依存性を 持っているか インフラの
後世は どのような ものか どんな
メトリクスや ログを 送っていて、 それらは どういう 意味なのか。 どんな
アラートが 設定されていて、 その 理由は 何なのか。
各アラートには、
- 注意点
手順書がコピーアンドペーストできるくらいに シンプルな コマンドなら 修復の 手順を 自動化して、 アラートを 完全に 削除すべき。
3.1.3 固定の 閾値を 決める ことだけが 方法ではない
アラート の
例) ディスク使用率 10%以下で
ディスク使用率が
Graphite を
3.1.4 アラート を 削除し、 チューニングしよう
アラート の
量を 減らす 方法 初心に
かえる。すべての アラートが 誰かが アクションする 必要が ある 状態か 確認する。 1ヶ月間の
アラート の 履歴を 確認する。 各アラートの 影響、 削除してしまえる 閾値の 見直しが 必要な ものが ないか 確認する。 アラート を
完全に 削除する ために、 どんな 自動化の 仕組みが 作れるか 検討する。
3.1.5 メンテナンス期間を 使う
ほとんどの
計画停止時など
3.1.6 まずは 自動復旧を 試そう
アラートにauto-healing
を
標準化された
3.2 オンコール
直接電話が
誤報、
3.2.1 誤報を 修正する
前日送られたすべての
オンコール担当が
3.2.2 無用の 場当たり 的対応を 減らす
監視は修復
してくれない。
システムの
- 2つの
効果的な 戦略
- 場当たり
的対応を していない 時間は、 システムの 回復力や 安定性に 対して 取り組むを オンコール担当の 役割に する。 - 前週の
オンコールの 際に 収集した 情報を 元に、 次の 週の スプリント計画や チーム会議の 際に システムの 回復性や 安定性に ついて 取り上げる 計画を 立てる。
3.2.3 上手に オンコールローテーションを 組む
- 1週ごとに、
4人で ローテーションする。 - カレンダーの
週に 合わせるのではなく、 出勤日に オンコールの ローテーションを 始めると オンコールの 引き継ぎが できる。 - 引き継ぎで、
注意を 要する 進行中の 出来事や、 その 週に 気づいた パターンなどについて 議論する。 - オンコール担当が
相談できる エスカレーションパスは 設けるべきだが、 あくまで オンコール担当が 対応する。
オンコール担当に ついて
オンコールの
バックアップ担当に ついて
ほとんどの場合、 必要ない、 仮に 4人の チームだと、 月に 2回担当が 回ってくる ことになる。 オンコールローテーションの
組み方
インシデントの発生回数で、 決める。
多くのインシデントを 処理しなければならない 場合ほど、 間隔を あけるべき。 ソフトウェアエンジニアも
オンコールローテションに 入れるべき ソフトウェアエンジニアリングに おける 丸投げ
を避ける。
ソフトウェアエンジニアと、運用エンジニアを 一緒に する ことで、 お互いの 共感が 強まる。
ツールに より、 オンコールの 仕組みを 補強する
ツールは、
PagerDuty
システム運用エンジニアを幸せにする ソリューションPagerDutyとは | Think IT(シンクイット) VictorOps
インシデント管理ツール VictorOps | Splunk
オンコールに 対する 補償
- オンコールシフト直後に、
有給休暇を 1日取らせる。 - オンコールシフトごとに
手当を 支払う。
3.3 インシデント管理
インシデントは ITIL で 定義されている
ITILの プロセスを 採用しつつも、 やりすぎに ならないように シンプルに する
- インシデントの
認識 (監視が 問題を 認識) - インシデントの
記録 (インシデントに 対して 監視の 仕組みが 自動で チケットを 作成) - インシデントの
診断、 分類、 解決、 クローズ(オンコール担当が トラブルシュートし、 問題を 修正し、 チケットに コメントや 情報を 添えて 解決済みとする) - 必要に
応じて 問題発生中に コミュニケーションを 取る - インシデント解決後、
回復力を 高める ための 改善策を 考える
インシデント対応の 社内標準を 作る 価値
- インシデントの
ログが 残り、 一貫性を 持って 追跡調査できる。 - ユーザー、
経営者、 顧客が 透明性を 持って 情報を 受け取り、 何が 起こっているのか 知れる。 - チームが
アプリケーションと インフラに どんな パターンで 問題が あるか、 どこで 問題が 起きやすいかを 知れる。
サービス停止を 伴う インシデント
明確に
- スクライブ (書記)
- 現場指揮館 (決断する
人) - コミュニケーション調整役
- SME (subject matter expert)
役割の アンチパターン
チームや
チームマネージャが現場指揮官
にはならず、
3.4 振り 返り
- インシデントが
発生した 場合、 インシデントに 関する 議論の 場を 設けるべき。 - サービス停止などの
重大な インシデントに 対して、 振り返りが 重要。 - 避難する
文化が あると、 ふりかえりの 効果が 薄れる。 本当の 問題を 改善できない。
感想
全体的に
Runbook
- 当たり前の
ことが 書かれていますが、 上記の 記載が なくて、 トラブルが 発生する ことが 多々あり、 刺さりました。 - Contextと
して チーム外から 見た 場合の 視点が 抜けていくように 思います。
オンコールシフト
ここでの
日中での
監視担当の ローテーションから 日々の 改善までの 流れ
監視担当の明文化
に
引き継ぎ
を
誤報を
役割の アンチパターン
思いあたる
ツールに より、 オンコールの 仕組みを 補強する
ツール自体が、
以上です。
コメント