24/7システムの運用担当を 1年半していたこととはほぼ無関係な トラブルシューティング技法 2019/09/13 たいぷらいたー (@no_clock) 年中無休

すき: 京都、百合、 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 とReact Postgre SQL 普段アプリケーション開発で気にする範囲 さくらのアイコンセット (CC-BY 4.0) https://knowledge.sakura.ad.jp/4724/

構成を知る ALB nginx ALB Ruby on Rails と多数のgem と共通モジュール とReact Aurora Postgre SQL ECS(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 Webpack Amazon ECR … GitLab CI … ALB nginx ALB Ruby on Railsと（略） Aurora PostgreSQL Unicorn Ruby Alpine Linux Debian GNU/Linux Docker Docker Amazon Linux 2 Amazon Linux 2 ECS(EC2) ECS(EC2) CloudWatch Amazon Web Services [ap-northeast-1a/1c]

平常時のログやグラフを眺める なぜ平常時？ →どんなものがあるのか事前に把握 →「いつもと違う（異常）」に気づく これ、XXゼミで やったこと無いやつだ!!!

異常検知（人力） 障害時 平常時 (1) (2) (2)は 異常ではなさそう P2P地震情報サーバのMongoDB オペレーション数

異常検知（人力） 平常時のnginxのアクセスログ（1リクエスト） time:07/Sep/2019:10:54:32 +0900 host:xx.xx.xx.xx forwardedfor:- req:GET /v2/jma/quake HTTP/1.1 status:200 size:1728 referer:- ua:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36 reqtime:0.149 apptime:0.149 vhost:api.p2pquake.net P2P地震情報サーバのアクセスログ

異常検知（人力） 慣れるとこう見えてくる time:07/Sep/2019:10:54:32 +0900 host:xx.xx.xx.xx forwardedfor:- req:GET /v2/jma/quake HTTP/1.1 status:200 size:1728 referer:- ua:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36 reqtime:0.149 apptime:0.149 vhost:api.p2pquake.net P2P地震情報サーバのアクセスログ

異常検知（人力） 異常時にも気づきやすい time:07/Sep/2019:10:52:58 +0900 host:xx:xx:xx:xx:xx:xx:xx:xx forwardedfor:- req:GET /v2/jma/quake HTTP/1.1 status:502 size:568 referer:- ua:Mozilla/5.0 (Windows; U; ja-JP) AppleWebKit/533.19.4 (KHTML, like Gecko) AdobeAIR/32.0 reqtime:0.000 apptime:0.000 vhost:api.p2pquake.net P2P地震情報サーバのアクセスログ

ハマりどころを避ける 実戦編

ポイントは 人を信じない こと

1. 言っていたことと起きていたことが違う ○ 人は間違うし、省略するし、飛躍もする 2. 曖昧な記憶や過去の経験にすがる ○ 「何もしてない」「前回と同じかな」 →実は全然違うかも トラブルシューティングあるある ※チームメンバの発言も信じない

コードレビュー時 　 動作確認も しました！ LGTM トラブル発生時　 サーバは 正常です! それは何を 根拠にして 言ってます？

トラブルシューティングは 証拠がすべて

● たくさん集めて正しく判断 ● 異常な証拠と同じくらい正常な証拠も重要 ● 証拠ベースで会話する 「10リクエスト全てHTTP 200（証拠） 　だったので正常だと思います（推測）」 証拠 (ログ, グラフ)

原因を特定するには どれだけ知っているか

原因を特定するには ● 仮説立案→検証 には、 (ロジック| フレームワーク|サーバ|クラウドサービス)の お気持ちに寄り添う必要がある ● (CSに限らず) 日常的に 深淵を覗く

手法を知る 　トップダウン、 ボトムアップ、 分割統治 日々の備え 　構成を知る、平常時のログを見る 準備編 実戦編 まとめ ハマりどころを避ける 　人を信じない、証拠がすべて 　お気持ちに寄り添う

トラブルシューティング 完全に理解した！