システム障害の報告をBacklogにしたら随分負担が減った話/JBUG_Tokyo6

Transcript

1. システム障害の報告をBacklogに したら随分負担が減った話 JBUG (東京#6) 2018/11/02(金) 日本経済新聞社 デジタル事業 BtoCユニット 西馬一郎

2. きょうお話したいこと 障害の報告でBacklogを活用、特にテンプ レート機能が有用であること 効果 • 障害のレポートを上の人にスムーズに実施 • 周りの人への情報共有のスピードアップ • テンプレート機能により定形フォーマット

   で記載が楽、抜け漏れやブレが無くなる

3. 自己紹介 • 西からきた馬ヅラのオトコ • 日経電子のバーンのエンジニア – 2010年、電子版創刊 – 2015年、電子版AWS移行 –

   2017年、電子版完全https化対応 – 直近は、API開発や認証システム • JBUG、JAWS-UGコミュニティ活動 • サウナが大好き 3

4. ヌーラボさんとの関連で 弊社紹介(ビジネス図解モデル繋がり) 4

5. システム障害の報告をBacklogに したら随分負担が減った話

6. 障害情報の管理で課題 • (Backlog無い時) 管理の課題 – 管理・蓄積されていない – 報告書の記載レベル・粒度がバラバラ – 検索できない

   – 格納場所がバラバラ • 文書作成ソフトウエアで1人が記載 • メール • 共有フォルダ • slack – ノウハウが蓄積されず、記憶に頼る属人的 6

7. そこで、Backlogで障害情報の管理 • (Backlogある時)障害情報を登録、共有 – 2016年から登録開始 – お客様に影響が出た障害を対象にする • 目的 –

   対応履歴、アクションを記録し、振り返る – 蓄積して頻度や傾向分析 – 1件に対して複数のメンバーが記述し内容を充実 7

8. 負担の軽減と効果 • 一元管理と蓄積 • 記載レベルが揃い、抜け漏れ解消 • 検索が可能、ノウハウ蓄積 • 上の人への報告の手間が省けた •

   エンジニア間、上長との間で情報の非対称性が解消 • 複数のメンバーで編集、いろんな角度で事象を捉える – システム観点、ビジネスインパクトの観点 • レビューにより客観性を担保 8

9. テンプレート機能でさらに効率UP 2018年8月にリリース 9

10. テンプレートの内容 # 障害内容 - 発生した障害の詳細を記載 ## 影響範囲 - 影響範囲を記載する ##

    ユーザ問い合わせ - わかっている範囲でユーザ問い合わせの 有無/件数を記載 # 障害日時 ## 発生時刻 ## 収束時刻 10 # 検知経路 - 障害の検知経路を記載 # 原因 # 対応 # アクションアイテム(再発防止策) # 教訓(以下、SRE 観点で可能な範囲で記載) ## うまくいったこと ## うまくいかなかったこと ## 幸運だったこと

11. まとめ • 日経電子版ではBacklogで障害管理、情報共有 – テンプレートを適用して効率アップ • 効果 – 定形フォーマットで抜け漏れ解消 –

    対応履歴、アクションを記録、振り返る – 蓄積して頻度や傾向分析 – 複数のメンバーが記述し内容を充実 – レビューにより客観性を担保 – SRE(Site Reliability Engineering)視点でポストモーテム の要素を追加 11

12. ソルムと言います ヌーラボさんのプロダクトと相性良さそう 12

13. 以上おしまいです 13