社内勉強会用

1. トラブルシューティング で
僕が大事にしてること
株式会社 CyberZ 門田矩明
社内勉強会(2017-05-10)

2. 自己紹介
・門田 矩明(かどた のりあき)
・株式会社CyberZ F.O.X サービスマネージャ
・元Javaエンジニア
・2006年新卒で中小系SIerに入社
ECサイト開発や金融関連システム開発
・2012年 サイバーエージェント 中途入社
Amebaで出会い系アプリ
→ Teen女子ブログサービス(CANDY by Ameba)
・2014年 子会社のCyberZ に出向
→ F.O.X プロダクトマネージャ
→ F.O.X サービスマネージャ now

3. トラブルシューティング

5. 金融系のトラブル対応現場
- Sound Only -

6. トラブルシューティングで
僕が大事だと思うことを
７個共有します

7. 1. 問題解決まで競争する

8. 1. 問題解決まで競争する
トラブルが起きたことを共有して、
複数人で問題解決までのタイムを競い合う
トラブルシュートで重要なのは情報
沢山の視点を入れることで量と質を早く確保
憂鬱なトラブル対応は楽しむことが重要
「一人じゃない」(対孤独感)

9. 2. 調査予定を共有する

10. 2. 調査予定を共有する
トラブルシュートの初期は、
たくさん仮説を立てて、裏付け調査をすること
調査したい内容(予定)は共有する
仮説は書くとキリがないから絞れてから共有
今何やってて、次に何やるのか。
タスクの見える化、タスク整理、タスク分担。

11. 3. 作業単位は15分～20分

12. 3. 作業単位は15分～20分
トラブルシュートは大量の作業がある
いつまでも同じ作業にハマってたら進まない
15分～20分を1タームとして、
どんどん作業を切り替えるほうが効率がいい
サービス障害の場合、報告(アウトプット)を
1ターム毎にやっていけば問題(※)は起きない
※大いなる力によるヨコヤリ、プレッシャー

13. 4. 脳内デバッグのみ

14. 4. 脳内デバッグのみ
ソースコードは読むだけ。
間違っても実行してはいけない。
障害の再現を行う場合、
環境の整備に時間がかなりかかりタイムロス
IDEを使わず、Gitを直接見る方が早いことも。
実行して良いのは条件が絞られて、
最終的に仮説を実証するときだけ。

15. 5. 調査方法と結果は記録

16. 5. 調査方法と結果は記録
調査した方法とその結果はログにする
「違った」「関係なかった」ことも重要
原因が判明して暫定/恒久対応をする際、
元の調査方法がわからなくて困ることが多々
時間が経ったらノイズでしかないので、
忘れず捨てるか、テンポラリ領域に置くこと

17. 6. 1時間でダメなら休憩

18. 6. 1時間やってダメならブレイク
1時間やって分からなければブレイク(休憩)
調査方法や仮説が間違ってる可能性を疑う
影響範囲にもよるけど、ギブアップも選択肢
「次回発生時の情報を待ち、継続調査とする」
これ以上時間(コスト)をかけるべきか、
総合的に判断し、続けるか止めるか決める

19. 7. 終わったら明確に宣言

20. 7. 終わったら明確に宣言する
トラブルが無事解決した？として
終了が明確化されていないことがたまにある
ズルズルすると全員のコストを食う
「もう終わりだよね？終わりにしていい？」
「これにて一件落着」「解散！お疲れ様」
「ーーーーーーー 糸冬了 ーーーーーーー」
責任もって誰か終わらせましょう

21. もっといっぱいあるけど、
時間ないのでここまで。

22. もっといっぱいあるけど、
時間ないのでここまで。