障害の対策というゲーム その進め方 - 虎の穴開発室ブログ
初めましての方は初めまして。お久しぶりの方はお久しぶりです。虎の穴のY.Mです。 このブログが始まった頃に、よく記事を書いていました。 月日は流れて、現在はEC開発のリーダーをやっております。 今回は技術的な内容というよりは、開発プロセスの内容を少し書きます。 書こうと思ったワケ 弊社のブログを眺めていたところ、これまで虎の穴の開発文化を紹介したことがなかったなと感じました。 チームでの開発をする上では、技術力はもちろん大事ですが、そのチームの開発文化が品質に大きく影響してきます。 ブログを読んでいただいている皆さんに、少しでも「こんな仕事のやり方をしてるよ」というのを知ってもらうべく、久しぶりに筆をとりました。 今回はそのとっかかりとして、一番エンジニアが頭と心を痛めるであろう『障害の事後対応』について書きます。 せっかくオタクエンジニアとして書くので、ちょっとゲーム仕立てにしてみます。
運用とログ - 京都行きたい
アラート起因で調べるベースの運用とログの話を書いておく。 状況確認 状況確認は大事。ひとまず初動で原因が分かると嬉しいので ざっくり状況確認。 ログを読む エラーログを読む なにも出てなかったらWARNを読む メトリクスを見る 5xxエラーを見る どのサービスがダメになってる？ 状況別調査 状況別に自分が見ているところをざっくりメモベースで書いておいた。 変なレスポンスが返っている ログを見る リクエストに紐付いた一意なIDを元にログで処理を追いかける 外部通信した時はこの一意なIDと一緒にログに出力しておきたい レスポンスが遅い レスポンスタイムを見る 特定のリクエストだけ遅い場合があるので、基本的にAverageじゃなくてPercentileを使う 依存先のサービスも見る サービスのCPU使用率見る 特定のインスタンスのCPU使用率を見る RDBやバックエンドのCPU使用率を見る IO
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
