トラブルシューティングのあれこれ Yoshihiko kamata

トラブルシューティングのあれこれ

Oct.28.2017

Kamata Yoshihiko

EC Incubation Development Dept.

Rakuten, Inc.

3

担当業務

• 管理サーバー／サービスの保守・運用

• 品質保証：なんでもレビュー

• サービス巻取りの先行部隊

• 圧縮

• 仕組み化

• トラブルシューティング∠( ﾟдﾟ)／

• その他

4

問題意識

5

問題意識

• 急ぎのタスク、急ぎの調査依頼が、集中する。

• 育成に時間をかける余裕がない。

• 急ぎの（省略）

• やりたいことが出来ない。。。

6

管理ではなく、開発者目線でお話したいと思います。

7

トラブル

障害に限定せず、イレギュラーに発生して工数を奪っていくもの、とします。

8

まずは事例をいくつか。。。

9

状況

何十台かあるWEBサーバーのLogから情報を抽出して、fluentdを利用してDBにINSERT。

事象

全台でfluentdを起動してまもなくDBへ接続しにくい状況が発生。

10

状況

リダイレクタを提供している。

URLの管理は、専用の管理画面を用意している。

事象

転送先を更新したが、スマホからアクセスすると、更新前のURLにリダイレクトされる。という利用者からの問合せ。

11

状況

ファイルストアサービスを提供している。このサービスは、API経由で、ファイルを登録できる。

事象

提供しているAPIで、特定のファイルだけがTimeoutになりアップロードできない、という問合せ。

13

質問

トラブルシューティングの得意なメンバーはいますか？

14

インフラ？

設計？仕様？

実装？

15

苦手意識 障壁

16

知識不足

• インフラ / システム構成

• 仕様 / 設計 / 実装 / データ

• 基礎技術

経験不足

• 考え方

• オペレーション

ストレス

• 失敗 / 間違い

• 催促

誤解

• INPUT エラー

• OUTPUT エラー

責任境界

• 権限

• 他者(社)サービス依存

17

トラブルシューティングとは？

18

“Troubleshooting”. techopedia. https://www.techopedia.com/definition/5574/troubleshooting, (参照 2017-

10-24).

19

体系化された技術だっけ？

20

体系化されたものはないが、おおよそセオリーと呼べそうなものはありそう。

• 事象の確認／情報収集

• 問題の切り分け

• 仮説を立てる 状況によっては、並列で動くことも

• 仮説の検証

• 対処

• 振り返り

• 落ち着いた状態で、見落としや、勘違いがないか考え直してみる。

21

一般的な進め方は？

22

一般的・・・は、分からないので、私が担当する場合の進め方

23

全体像

一次情報の確認 仮説を立てる 仮説を検証

因果関係の逆転

原因推測可能 裏付けを取る

特定

24

簡単な場合

例えば・・・

• Permission error

• ディスク容量不足

• Validateエラー

• File Not Found

他にも、過去に経験しているものなど

一次情報の確認

原因推測可能 裏付けを取る

特定

25

ちょっと考える場合

一次情報の確認 仮説を立てる 仮説を検証 特定

26

仮説が立たない！？

入手可能な情報は全て集めた。

結果から推測できる原因が考え付かない。。。

一次情報の確認 仮説を立てる 仮説を検証

因果関係の逆転

特定

何を原因と仮定すれば、この結果を導けるのか？

どうすれば、この事象が引き起こせるのか？

という発想で、仮説を立ててみる。

27

得意な人とそうでない人の差って何？

良くない例

29

問合せ受領問合せ内容を元

に調査分からない 困る

さらに良くない例

31

問合せ受領問合せ内容を元

に調査外部に問合せ

回答受領

再調査

33

問合せ受領問合せ内容を元

に調査外部に問合せ

回答受領

再調査

34

確認

• 客観性はあるか？

• 専門性はあるか？

問合せ受領問合せ内容を元

に調査外部に問合せ

回答受領

再調査

35

その他

• LOGを見ない。（LOGがないケースも。。）

• その事象だけを考えている。

• ネット(blog等)の情報を過信する。

• 始めから一つの可能性しか考えない。

• コミュニケーションミス

など

36

鉄則

37

• 受け取った情報を疑う。

• 客観性はあるか？専門性はあるか？

• LOGを先ず確認する。得られる情報をかき集める。

• 一次情報を確認する癖を付ける。

• 情報の保全も重要。

• 点ではなく、線で考える。視野を広く持つ。

• どういう状況で起きているのか考える。

• トリガーは？

• 規則性はあるのか？

• ホウレンソウにあたっては、事実を伝えるように心がける。

38

教訓

39

• 情報

• 相手が上司でも疑う。

• 担当部署からの回答であっても疑う。

• 情報ソースの確認を怠らない。

• コミュニケーション

• 自分の言いたいことではなく、事実を伝える。

• 思っていることを事実であるかのように言わない。

• 心理状態

• 相手に無駄なプレッシャーをかけない。

• 冷静さを欠いてる時は手を止める。

40

スキルアップするには？

41

• 経験 ⇒ 同じ事象への対応力

• 場数 ⇒ 類似事象への対応力

• 過去の経験、あるいは事例の記憶 ⇒ スピードアップ

• 蓄積された情報へのアクセス手段 ⇒ 底上げに期待

• 過去事例とどう結び付けるか？

• 事例共有だけでは、トラブルシューティングのスキルは身に付かない。

• 同じ事象であっても、原因は様々。原因に至るプロセスまで含めて共有しなければ意味がない。

42

• 良いものを知る。 ⇒ 未知の事象への対応力

※設計者の視点で考えられるようにする。

• プロダクトの設計情報を読む。

• そのプロダクトが何故作られたのか？他と何が違うのか？

• どういう点が工夫されているのか？

• 特徴として書かれていることは、どう実現されているのか？

重要なのは、アーキテクチャを理解すること。

• ソースコードを読む。

• クラスやメソッドがどう設計されているか読み取る。

43

• テキスト操作技術 ⇒ 情報収集の精度・スピード

• 最終的にスピードを左右するのは、知識量

• Application

• 仕様理解

• 背景・経緯の理解

• アーキテクチャの理解

• 設計の理解

• 依存関係の理解

• データ(DB/File/Cache)構成ライフサイクルの理解

• ソースコードの把握

• Server

• 基礎知識

• OS / コマンド / 言語

• ネットワーク

• 周辺知識

• Dir/File構成

• Logの場所/出力内容

• 負荷調査スキル

44

46

状況

何十台かあるWEBサーバーのLogから情報を抽出して、fluentdを利用してDBにINSERT。

事象

全台でfluentdを起動してまもなくDBへ接続しにくい状況が発生。

47

状況

何十台かあるWEBサーバーのLogから情報を抽出して、fluentdを利用してDBにINSERT。

事象

全台でfluentdを起動してまもなくDBへ接続しにくい状況が発生。

対応

fluentdのlog

⇒ error="Too many connections“

DBの”max connections”及び、現在の接続数を確認

一次情報の確認

48

状況

何十台かあるWEBサーバーのLogから情報を抽出して、fluentdを利用してDBにINSERT。

事象

全台でfluentdを起動してまもなくDBへ接続しにくい状況が発生。

対応

１．fluentdがDBに書き込む度に新しいConnectionを張って、Closeしてない？

２．低レイヤーでのBug？

３．仕様によるものなので、DB側の閾値を上げるべき？

仮説を立てる

49

状況

何十台かあるWEBサーバーのLogから情報を抽出して、fluentdを利用してDBにINSERT。

事象

全台でfluentdを起動してまもなくDBへ接続しにくい状況が発生。

対応

閾値を上げる案に対しては、Connectionの増加スピードが不明だったため見送った。原因が分からないまま、閾値を上げても追いつく可能性もある。

DB登録を行うpluginは、Rubyのコードだった。DB接続を行う箇所が2箇所あり、一方はconnectionの変数を取り、closeまでしていたが、もう一方は、メソッドチェーンで記述されていて、closeしていなかった。

仮説を検証

51

状況

リダイレクタを提供している。URLの管理は、専用の管理画面を用意している。

事象

転送先を更新したが、スマホからアクセスすると、更新前のURLにリダイレクトされる。という利用者からの問合せ。

52

状況

リダイレクタを提供している。URLの管理は、専用の管理画面を用意している。

事象

転送先を更新したが、スマホからアクセスすると、更新前のURLにリダイレクトされる。という利用者からの問合せ。

対応

管理画面の確認と、実際にブラウザでアクセスしてみて問合せにあったものと同じ事象が再現できることを確認。

一次情報の確認

53

状況

リダイレクタを提供している。URLの管理は、専用の管理画面を用意している。

事象

転送先を更新したが、スマホからアクセスすると、更新前のURLにリダイレクトされる。という利用者からの問合せ。

対応

１．ブラウザでキャッシュしてしまっている？２．APP側で古い情報のキャッシュが残っている？（memcachedを利用している）３．そもそもどうやってリダイレクト指示してる？（ソースコード確認）

仮説を立てる

54

状況

リダイレクタを提供している。URLの管理は、専用の管理画面を用意している。

事象

転送先を更新したが、スマホからアクセスすると、更新前のURLにリダイレクトされる。という利用者からの問合せ。

対応

１．ブラウザでキャッシュしてしまっている？ ⇒ 履歴をクリアすると解消した２．APP側で古い情報のキャッシュが残っている？ ⇒ キャッシュは更新されていた３．そもそもどうやってリダイレクト指示してる？ ⇒ 301 Redirect

仮説を検証

56

状況

ファイルストアサービスを提供している。このサービスは、API経由で、ファイルを登録できる。

事象

提供しているAPIで、特定のファイルだけがTimeoutになりアップロードできない、という問合せ

57

状況

ファイルストアサービスを提供している。このサービスは、API経由で、ファイルを登録できる。

事象

提供しているAPIで、特定のファイルだけがTimeoutになりアップロードできない、という問合せ

対応

通常の監視でレスポンス遅延が起きていないことは分かっているので、

利用者側の環境からAPIへの経路上の問題、あるいは利用者側の実装の問題と推測。原因推測可能

58

状況

ファイルストアサービスを提供している。このサービスは、API経由で、ファイルを登録できる。

事象

提供しているAPIで、特定のファイルだけがTimeoutになりアップロードできない、という問合せ

対応

ファイルの拡張子と実体がずれていないか、バイナリエディタで確認。実際に、APIに直接アクセスしてアップロードできることを確認。

裏付けを取る