株式会社リゾーム システム企画・開発部 システム管理のあめぎです。
読書会の第3回目のレポートです。 第2回目のレポートはこちらです。
読書会の題材
前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。
3回目レポート
今回は3章「アラート、オンコール、インシデント管理」で、参加者は6名でした。
それぞれの感想と議論まとめ
どうしたらアラートをよくできるか？
アラートのメール通知は反対派多数 ※参加者全員
- 誰も叩き起こせないし、スルーしてしまう可能性も高い。SMSに送るのはよくある。
- 一般的な使い方は「期限に余裕があり、期限までに目を通していればいい」「届いていない・見ていない可能性も許容する」
- メールボックスに張り付いているのも、緊急度の高いメールが届いていないか気にするのも疲れる。
- RundeckのJob失敗はメール通知しているが、確かに埋もれてしまう事がある。
- 業務関連のメールと混ざると読まない。見落とす。うんざりする。
手順書を書こう
- 最近バッチ処理失敗時の対応手順書を作成した
- 作成して共有することで誰でも対応出来るようになったと思う
- 今は設定ファイルがそのままインフラ構成・依存性を表す絶好の資料になっている（DockerfileやCloudFormationなど）
- ない時代は大変だっただろうなと思う
- よい手順書は質問に答えるように書かれたもの
- ここまで丁寧に実際かけているのか？
- 書けた覚えがない…気を付けたい
- 作れていない手順書は正直ある…
固定の閾値を決めることだけが方法ではない
- 使用量の変化量を監視するのはいいかもしれない
- 今朝もメモリの使用率が閾値を超えているアラートが来た
- サービスの性質上、ある時間帯になると利用増えるので超えるのは問題ないかなとは思う
- 変化量でアラートを作るのも難しい
- ディスク使用率は変化量を見るのも良いかもしれない
アラートを削除し、チューニングしよう
- なんのために監視をしているのかの定義の見直そう
- CPUやメモリ使用率がある値を超えるとアラートを発信している
- 特にアクションもしていないので減らしてもいいかもしれない
メンテナンス期間を使おう
- SC BASEでは本番メンテナンス前にMackerelの外形監視を時間指定でミュートしている
- メンテナンスモードにしないとデプロイ出来ない仕組みを入れた事があった
- 静観してくださいって連絡をする事があった
- アラートをミュートしていたのか
まずは自動復旧を試そう
- delayed_jobが落ちたら自動復旧と同時にアラートが鳴る
- 自動復旧に失敗したらアラートの方がいいなと思った
- 基本は何かを見つけて再起動！
- サービス維持に繋がるならシンプルでも立派な自動回復なのか！
- オンプレの古い機器を無暗に再起動するのは怖いからほどほどにしよう
オンコール
- 月に2日程度休日に担当になる
- 昔はCPUやメモリ使用率のアラートも保守端末に届いて落ち着けなかった
- 最近は問題が起きることは少ないので精神的に楽になった
- オンコールローテーション。ここの組織デザインが大事。
- オンコールは精神を削る
- お酒も飲めないし（お酒が好きな人は…）出かけるのも難しい
- オンコールの内容を次の週の会議に取り上げる計画を立てる方法は重要だと思う
誤報を修正する
- アラートを整理してチューニングを行うというのは改善手段として優れていると思う
無用の場当たり的対応を減らす
- 「触らぬ神に祟りなし」的な対応をしてしまうこともある
- お金と要望がない限り修正できない契約パターン
- 仕様や実装経緯が不明
- 監視・開発だけでなく体制を整えることも大切
- 監視は修復してくれない。直すのはあなた。その通りですね。
インシデント管理
- 緊急時の対応マニュアルは必要
- いざというときに組織としてどう対処していくか
- 会社全体や法務としてどう対応するかもあればベスト
- 場合によっては情報漏えいなども絡んでくる
- アラートでチケットの自動作成までは出来ていない
- 記録漏れのないように改善していきたい
- 現場指揮官・スクライブを関わらせないのすごく大事
- 特定の誰かが全部やっている状態では、客観的な記録が残らなかったり、コミュニケーションが歪んだものになる可能性がある。
- コミュニケーション調整役はめちゃくちゃ大事
- まさにコード書いて直してる人はそれに集中するべき
社内の課題は？
- すべてのアラートをPCメール・携帯メール・Teamsに送りがちなのでいいようにしたい
- どのような監視・アラートがあって、どこに通知されているのか・通知する必要があるのかを整理したい
- アラートが混在しているので良くない（システムの利用に影響のあるアラート・影響はないけど注意は必要なアラート）
事例・アイディア など
- SC GATEではTeamsに送られるようになっている
- 注意が必要だがすぐにアクションが必要でないアラートは社内チャットにしよう
- 手動復旧じゃなくて自動復旧にできるものはしよう
- 調査の仕方を手順書に書いておく
- ネクストアクションが書いてあるといい
- papertrail / bugsnag / Mackerel / New Relicをみてみましょう
- 判断できるかはわからないけれど、見てみたら、いつもと違う何かがあるかもしれない。
- ネクストアクションが書いてあるといい
まとめ
アラート、オンコールについてはメンバー各々思い当たる事があったようです。 どうすれば互いの負担を減らせるか、良い体制を整えられるか意見を交わせるよい機会になったように思います。 アイディアも出てきましたので、少しでも取り入れて改善していきたいですね。
次回は「4章 統計入門」です。
