タダです.
この記事は Mackerelアドベントカレンダー2020の7日目の記事です.皆さんにとって2020年はどんな1年でしたか？いろんなことが変化した1年だったんじゃないかなと思いますが,自分も働き方や9月に会社が変わった1年でした.転職して始めた取り組みとして監視周りがあり,組織内の課題から Mackerel の導入と組織内の方針を決めたりしていきました.そんな Mackerel 導入してやったことと今後やっていきたいことを書いていきたいと思います.
Mackerel の導入前の監視
Mackerel 導入前の監視は CloudWatch で AWS サービスのみを監視しており,EC2 や Aurora などのパフォーマンスに影響があるところを下記のスライドのように Slack にアラート通知している状況でした.
ただ,アラートが鳴っても誰がどんなアクションを起こすのかが不明だったり,開発者もアラート通知チャンネルに入っているが何をしていいかわからないという状況でした.また,サービス提供している部分の中には監視が間に合っていないところがありました.そのため,CloudWatch の監視に加えて外部の監視サービスを検討することになりました.いくつか選択肢がありますが,コストや扱うシステムの監視を賄える物を検討して,最終的に Mackerel を導入することにしています.
Mackerel の導入後にやったこと
Mackerel を導入することになり,自分が取りまとめて検証と組織展開していくためにいくつかの取り組みを行ったのでそれを紹介してきます.
1. Mackerel で監視する箇所の特定とドキュメント化
まずは,Mackerel で監視する箇所の特定を行っていきました.自分が所属する会社では toC 向けのサービスを提供しているのですが,外型監視ができていなくてよくある証明書の有効期限が切れてアクセスできない事象も転職してすぐに起こっていました.なので,ユーザーに最も近いところから監視の設定をいれてきました.また,それらを GitHub にドキュメント化しました.GitHub においたのは今後開発者に開発だけでなく自分たちが開発したシステムの監視に介入してもらいたいし,監視設定を変更したい場合に開発者からプルリクをあげてもらい自分がレビューするといったフローにしていくための意図でやってます.
2. アラート発生時に開発者が担当するシステムごとに対応内容と対応者の明記
次に,開発者ごとで担当しているシステム領域が異なるのでそれぞれの担当領域のアラートを Slack でメンションし,アラートごとにどんな対応をするかを定義して開発者と認識合わせを行いました.Mackerel 導入前アラートは Slack の @channel で通知されるもののアラートがなっていても誰もどんなアクションを起こしていいのかがわからない状態になっていたので,誰がどんな対応をするかを明らかにする必要がありました.これによってこれまで疎遠だった開発者をシステム監視の領域に踏み込んでもらえるようになったと思います.
Mackerel からのアラート通知例
アラートごとの対応内容の一部抜粋
3. 障害対応テンプレートの策定
システムごとのアラートと対応者,対応内容が決まったので組織的に障害発生から障害対応完了,その後の振り返りまでのアクションリストをまとめた障害対応テンプレートを作りました.会社ではドキュメントを esa を使っているので esa に対応内容をまとめています.この定義を行って障害発生時にどう動いて,障害対応後どう動くかを整理することができたと思います.ただ後述しますが,テンプレートを実際に使う機会が日常業務ではアラートが頻発したり,高負荷なシステムが今のところないので,予防訓練でこのテンプレートを使って障害対応を練習していきたいと考えています.
障害対応テンプレートの一部抜粋
これからやっていきたいこと
Mackerel を導入し,運用するに当たって決め事や障害発生時の対応フローが決まりましたが,今後やっていきたいこともあります.
- 障害対応訓練
- オンコール対応フローの構築
- Mackerel ならではの機能の活用
1. 障害対応訓練
1つ目は障害対応訓練です.入社当初は1アカウント本番環境しかなかったのでやり辛さがありましたが,用途ごとにアカウントを分離しております.分離できたアカウントで開発者と障害対応訓練をやっていき,障害対応テンプレートを使ってそれぞれがやるべきことを確認していきたいと考えてます.余談ですが,開発者からも予防訓練がやりたいと進言してくれたのはうれしかったです.
2. オンコール対応フローの構築
2つ目はシステム規模が大きくなっていた時にオンコール対応フローの構築です.今今はシステム規模的にも日々の負荷的にもそこまで大きいものではないのでオンコール対応の構築はまだ行っていないのですが,事業のスケールと合わせてシステムもより信頼度の向上を行うためにもオンコール対応フローを構築していきたいです.
3. Mackerel ならではの機能の活用
今は Mackerel Agent で標準利用可能なサーバーからのメトリックと EC2 ではプロセスの監視を行っているほどですが,Mackerel ならではのプラグインの開発や EventBridge と連携して自動復旧の仕組みを作ってみたいとも考えてます.
まとめ
Mackerel を導入したやったこととこれからやっていきたいことを書きました.監視をエージェント入れてから即座に始められたおかげで今まで見えなかったものがデータとして関係者全員が見えてくるようになって改善や運用業務でアクションがしやすくなりました.今後も Mackerel を活用して自社でのよりよい運用のあり方を追求していきたいです.
監視のツールをいれて見えなかったことが見えてきたおかげで回ってなかった改善や見直しができてる
— Sadayoshi Tada🎉 (@tada_infra) 2020年11月11日
データを集めて可視化して一緒にチームで見て考える機会大事だ
