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

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

2018/11/02のJBUG東京#6の資料です

Cbc9561ae10a196ca473048980db31d0?s=128

Ichiro Nishiuma

November 02, 2018
Tweet

Transcript

  1. 3.

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

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

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

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

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

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

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

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

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

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

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

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