mackerelで監視した後の一次対応を自動化する話 - Qiita
はじめに 監視システムからアラートを受信した後におこなう対応のうち、手順が決まっていて誰がやっても同じ部分（一次対応）を自動化して、その後対応するエンジニアが楽になるようにお膳立てします。 監視アラート対応 監視から通知される情報は、一時点・一監視項目（メトリクス）の情報にすぎません。 対応するエンジニアが適切な診断・正しい対応判断するためには情報不足であり、追加でその周辺情報や時系列遷移を情報収集するという作業が毎回発生しています。 今回はこの情報収集作業を、監視の通知がされたらすぐに自動で行われるようにします。 これができると、 エンジニアが情報収集作業を飛ばして、即時に対応が開始できるようになります。 なんといっても楽ですし、復旧時間を短縮でき、障害によるサービスレベルの低下・損失を最小化できます。 CPU使用率やメモリ使用率の一過性の閾値超過など、エンジニアが確認したときには既に解
監視だけじゃない！デプロイにMackerelを使う話 | メルカリエンジニアリング
SREチームの @siroken3 です。 以前、メルカリでリリース手段としてChatOpsを採用していることを本ブログで紹介しました。今回は内部で使っている技術の一部を紹介したいと思います。 tech.mercari.com tl;dr メルカリではデプロイにAnsible使ってる 毎日デプロイしつつサーバが増加/入れ替え激しいと心が削れる MackerelのAPIとAnsibleを組み合わせたらハッピーになった Insideデプロイ メルカリではデプロイ用のサーバでSlack Botが働いており、デプロイの事前要件を満たしているか確認した後、大まかには以下の処理を実行しています。 GitHubからデプロイ対象ソースの取得 composer install / gulp などのビルド処理 対象サーバにrsyncでデプロイ これらの処理は構成管理ツールであるAnsibleを使用しています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
