Upcoming SlideShare
トラブルシューティングで僕が大事にしてること
- 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. トラブルシューティング
- 4. 金融系のトラブル対応現場 - Sound Only -
- 5. トラブルシューティングで 僕が大事だと思うことを ７個共有します
- 6. 1. 問題解決まで競争する
- 7. 1. 問題解決まで競争する トラブルが起きたことを共有して、 複数人で問題解決までのタイムを競い合う トラブルシュートで重要なのは情報 沢山の視点を入れることで量と質を早く確保 憂鬱なトラブル対応は楽しむことが重要 「一人じゃない」(対孤独感)
- 8. 2. 調査予定を共有する
- 9. 2. 調査予定を共有する トラブルシュートの初期は、 たくさん仮説を立てて、裏付け調査をすること 調査したい内容(予定)は共有する 仮説は書くとキリがないから絞れてから共有 今何やってて、次に何やるのか。 タスクの見える化、タスク整理、タスク分担。
- 10. 3. 作業単位は15分～20分
- 11. 3. 作業単位は15分～20分 トラブルシュートは大量の作業がある いつまでも同じ作業にハマってたら進まない 15分～20分を1タームとして、 どんどん作業を切り替えるほうが効率がいい サービス障害の場合、報告(アウトプット)を 1ターム毎にやっていけば問題(※)は起きない ※大いなる力によるヨコヤリ、プレッシャー
- 12. 4. 脳内デバッグのみ
- 13. 4. 脳内デバッグのみ ソースコードは読むだけ。 間違っても実行してはいけない。 障害の再現を行う場合、 環境の整備に時間がかなりかかりタイムロス IDEを使わず、Gitを直接見る方が早いことも。 実行して良いのは条件が絞られて、 最終的に仮説を実証するときだけ。
- 14. 5. 調査方法と結果は記録
- 15. 5. 調査方法と結果は記録 調査した方法とその結果はログにする 「違った」「関係なかった」ことも重要 原因が判明して暫定/恒久対応をする際、 元の調査方法がわからなくて困ることが多々 時間が経ったらノイズでしかないので、 忘れず捨てるか、テンポラリ領域に置くこと
- 16. 6. 1時間でダメなら休憩
- 17. 6. 1時間やってダメならブレイク 1時間やって分からなければブレイク(休憩) 調査方法や仮説が間違ってる可能性を疑う 影響範囲にもよるけど、ギブアップも選択肢 「次回発生時の情報を待ち、継続調査とする」 これ以上時間(コスト)をかけるべきか、 総合的に判断し、続けるか止めるか決める
- 18. 7. 終わったら明確に宣言
- 19. 7. 終わったら明確に宣言する トラブルが無事解決した？として 終了が明確化されていないことがたまにある ズルズルすると全員のコストを食う 「もう終わりだよね？終わりにしていい？」 「これにて一件落着」「解散！お疲れ様」 「ーーーーーーー 糸冬了 ーーーーーーー」 責任もって誰か終わらせましょう
- 20. もっといっぱいあるけど、 時間ないのでここまで。
- 21. もっといっぱいあるけど、 時間ないのでここまで。
Be the first to comment