2019-09-13 社内LT会で発表した内容です。
24/7システムの運用担当を1年半していたこととはほぼ無関係なトラブルシューティング技法2019/09/13 たいぷらいたー (@no_clock)年中無休
View Slide
すき: 京都、百合、 C#/Ruby/Vim☆新刊・既刊情報07/18 あおのなち 「きみが死ぬまで恋をしたい(2)」08/30 ヨルモ「レゾナントブルー」09/27 なもり「ゆりゆり(2)」11月頃 仲谷鳰「やがて君になる(7・最終巻)」圓光寺 (京都市左京区一乗寺, 2016/11/14撮影)
おことわり● “トラブルは無いほうが良い”という前提です(当たり前)● GoogleのSRE本 12章にだいたい書いてあります書影: Google - Site Reliability Engineering: https://landing.google.com/sre/books/Chapter 12 - Effective Troubleshooting:https://landing.google.com/sre/sre-book/chapters/effective-troubleshooting/
トラブルシューティングはつらい
トラブルシューティングはつらい● 状況がつらい○ 日々最善を尽くしているはずが起きる○ ユーザ影響が出ている● 原因特定がつらい○ 暗中模索しがち○ 得意領域の外にはみ出がち
トラブル発生時、できるだけ最短で対処したい
よくあるイメージ● 職人技● 経験がすべて● CSのすべての分野に精通している必要がある→ 一般的な「手法」やちょっとした「備え」 が効く(こともある)
最短で対処するために1. 手法を知る2. 日々の積み重ねで備える3. ハマりどころを避ける準備編実戦編
トラブルシューティングの手法を知る準備編
トラブルシューティング手法レイヤごとに仮説立案→検証で「切り分け」1. トップダウン方式2. ボトムアップ方式3. 分割統治方式(その他省略)トラブルシュートをマスターするhttps://www.cisco.com/c/dam/global/ja_jp/training-events/es/cy11/pdf/cisco3-20110610interop.pdfアプリケーションプレゼンテーションセッショントランスポートネットワークデータリンク物理1 2 3勘が冴えている場合に有効OSI参照モデルの場合
典型的なWebサービスだと…さくらのアイコンセット (CC-BY 4.0)https://knowledge.sakura.ad.jp/4724/Webサーバ APサーバ DBサーバLB LB(1) トップダウン方式(2) ボトムアップ方式(3) 分割統治方式トラブルシューティング手法
典型的なMVCアプリケーションだと…(1) トップダウン方式(2) ボトムアップ方式View Controller Model(3) 分割統治方式トラブルシューティング手法
トラブルシューティング完全に理解した!トップダウン方式で調べるぞ!
………トップってどこ?
日々の積み重ねでトラブルシューティングに備える準備編
日々の備え● 構成を知る● 平常時のログやグラフを眺める
構成を知るRuby on RailsとReactPostgreSQL普段アプリケーション開発で気にする範囲さくらのアイコンセット (CC-BY 4.0) https://knowledge.sakura.ad.jp/4724/
構成を知るALBnginxALBRuby on Railsと多数のgemと共通モジュールとReactAuroraPostgreSQLECS(EC2) ECS(EC2)Amazon Web Services実際のシステム構成さくらのアイコンセット (CC-BY 4.0) https://knowledge.sakura.ad.jp/4724/
構成を知る実際のシステム構成さくらのアイコンセット (CC-BY 4.0) https://knowledge.sakura.ad.jp/4724/+ ビルド/デプロイ構成Terraform WebpackAmazon ECR …GitLab CI …ALBnginxALBRuby on Railsと(略)AuroraPostgreSQLUnicornRubyAlpine Linux Debian GNU/LinuxDocker DockerAmazon Linux 2 Amazon Linux 2ECS(EC2) ECS(EC2)CloudWatchAmazon Web Services [ap-northeast-1a/1c]
平常時のログやグラフを眺めるなぜ平常時?→どんなものがあるのか事前に把握→「いつもと違う(異常)」に気づくこれ、XXゼミでやったこと無いやつだ!!!
異常検知(人力)障害時 平常時(1) (2)(2)は異常ではなさそうP2P地震情報サーバのMongoDB オペレーション数
異常検知(人力)平常時のnginxのアクセスログ(1リクエスト)time:07/Sep/2019:10:54:32 +0900host:xx.xx.xx.xx forwardedfor:- req:GET/v2/jma/quake HTTP/1.1 status:200 size:1728referer:- ua:Mozilla/5.0 (Macintosh; IntelMac OS X 10_14_6) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/76.0.3809.132Safari/537.36 reqtime:0.149 apptime:0.149vhost:api.p2pquake.netP2P地震情報サーバのアクセスログ
異常検知(人力)慣れるとこう見えてくるtime:07/Sep/2019:10:54:32 +0900host:xx.xx.xx.xx forwardedfor:- req:GET/v2/jma/quake HTTP/1.1 status:200 size:1728referer:- ua:Mozilla/5.0 (Macintosh; IntelMac OS X 10_14_6) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/76.0.3809.132Safari/537.36 reqtime:0.149 apptime:0.149vhost:api.p2pquake.netP2P地震情報サーバのアクセスログ
異常検知(人力)異常時にも気づきやすいtime:07/Sep/2019:10:52:58 +0900host:xx:xx:xx:xx:xx:xx:xx:xx forwardedfor:-req:GET /v2/jma/quake HTTP/1.1 status:502size:568 referer:- ua:Mozilla/5.0 (Windows;U; ja-JP) AppleWebKit/533.19.4 (KHTML, likeGecko) AdobeAIR/32.0 reqtime:0.000apptime:0.000 vhost:api.p2pquake.netP2P地震情報サーバのアクセスログ
ハマりどころを避ける実戦編
ポイントは人を信じないこと
1. 言っていたことと起きていたことが違う○ 人は間違うし、省略するし、飛躍もする2. 曖昧な記憶や過去の経験にすがる○ 「何もしてない」「前回と同じかな」→実は全然違うかもトラブルシューティングあるある※チームメンバの発言も信じない
コードレビュー時 動作確認もしました!LGTM トラブル発生時 サーバは正常です!それは何を根拠にして言ってます?
トラブルシューティングは証拠がすべて
● たくさん集めて正しく判断● 異常な証拠と同じくらい正常な証拠も重要● 証拠ベースで会話する「10リクエスト全てHTTP 200(証拠) だったので正常だと思います(推測)」証拠 (ログ, グラフ)
原因を特定するにはどれだけ知っているか
原因を特定するには● 仮説立案→検証 には、 (ロジック|フレームワーク|サーバ|クラウドサービス)のお気持ちに寄り添う必要がある● (CSに限らず)日常的に深淵を覗く
手法を知る トップダウン、ボトムアップ、分割統治日々の備え 構成を知る、平常時のログを見る準備編実戦編まとめハマりどころを避ける 人を信じない、証拠がすべて お気持ちに寄り添う
トラブルシューティング完全に理解した!