Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • TL;DR
  • はじめに
  • ポストモーテムとは?
  • Post mortems / Incident review での共有
  • ポストモーテムの書き方
  • 1. ポストモーテムを書きたいものを Post mortems / Incident review 会で提案
  • 2. ポストモーテムを書く会に向けて準備
  • 3. ポストモーテムを書く会の実施
  • 4. 書いたポストモーテムを Post mortems / Incident review 会で共有、レビュー
  • 書いたポストモーテムの活用

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発プロセス

ポストモーテムの取り組み

TL;DR

  • ポストモーテムは、Incident の事例を振り返り、改善のために学んでいく取り組みです。

  • Infra と各チームの SRE が中心になって、 ポストモーテムの作成や同期的なレビュー会を毎週行っています。

  • https://github.com/wantedly/post-mortems (internal) に過去のポストモーテムをまとめています。

はじめに

Wantedly では、日々新しい機能や新しいシステムが追加されています。 そのため、成長と同時に複雑な分散システムになりつつあります。

インシデントやサービス障害は、増幅する規模感と変化の速度から避けがたいです。 インシデントが発生した場合は、基本的にその場で原因対策し安定運用に戻します。

しかし、こういったインシデントから学びを得るための定式化されたプロセスがなければ、同じようなインシデントが無限に繰り返し起こることになります。また野放しのままになってしまえば、インシデントの複雑さは加速度的に増し、あるいは積み重なってシステムの対処ができなくなります。

そのため、失敗から学ぶために振り返りのポストモーテムを書きます。

ポストモーテムとは?

ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因(群)、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。

抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

ポストモーテムの目的は、インシデントがドキュメント化されること、影響を及ばしたすべての根本原因(群)が十分に理解されること、そして、再発の可能性や影響を削減するための効果的な予防策が確実に導入されるようにすることです。ポストモーテムには次のような事が書かれます。

  • 発生したこととその影響範囲

  • その緩和や解消のために行われたアクション

  • 根本原因

  • 再発防止策

ポストモーテムを書くはのは処罰ではなく、会社全体としての学びの機会です。サービスのどの部分をどうすれば改善できるのかを提起し、長期的な成長を鈍化させないプロセスです。

-
ポストモーテム
障害報告書

想定読者は誰か

社内     

ユーザー  

何のために書くのか

失敗から学ぶため

説明責任を果たすため

Post mortems / Incident review での共有

知見として溜まったものを学びの機会として共有するために、毎週 Post mortems / Incident review を行い、 作成したポストモーテムの共有と、内容の精査、Next Action の決定などを行っています。この場で Incident の共有や、ポストモーテムを書く提案も行っています。

参加メンバーは、Infra Squad のメンバーと、各 Domain の SRE チームのメンバーです。毎週水曜日 15:00 ~ 15:30 に実施しています。

ポストモーテムの書き方

Wantedly では、学びを得て蓄積していけるようなポストモーテムを書いていけるように、 「ポストモーテムを書く会」として同期的にポストモーテムを書く場を設け、そこで書いたポストモーテムをレビューしています。

最近では以下の流れで進めることが多いです。これらの流れについて説明します。

  1. ポストモーテムを書きたいものを Post mortems / Incident review 会で提案

  2. ポストモーテムを書く会に向けて準備

  3. ポストモーテムを書く会の実施

  4. 書いたポストモーテムを Post mortems / Incident review 会で共有、レビュー

1. ポストモーテムを書きたいものを Post mortems / Incident review 会で提案

最近発生した Incident やオペレーションなど、振り返って学びを得るためにポストモーテムを書きたいものを Post mortems / Incident review 会で提案します。 そこで、「ポストモーテムを書く会」のメンバーを決めます。メンバーは、進行役として Infra Squad のメンバー1人以上 + Incident やオペレーションに関わったメンバー、参加したいメンバーにします。

メンバーを決めたら、進行役の Infra メンバーが、書く会の予定の設定をします。

2. ポストモーテムを書く会に向けて準備

「ポストモーテムを書く会」がスムーズに行えるように、事前に以下の準備を行います。

  • 進行役の Infra メンバーがテンプレートを使ってドキュメントを作成する。

    • その issue に「ポストモーテムを書く会」用の Google Docs のテンプレートがあるので、予めテンプレートからドキュメントを作っておきます。

  • Incident やオペレーションに関与したメンバーが、それのサマリを用意しておきます。

    • サマリを用意しておくと、ポストモーテムを書く際の事実確認がスムーズに行えます。

3. ポストモーテムを書く会の実施

事前に決めたメンバーで、同期的に Google Docs 上のドキュメントの項目を埋めていく形で進めます。 会を進める上では、以下の流れに沿って KPT + Fact を意識して進めると、良いポストモーテムが書きやすいです。

  • まず Fact を整理して、参加しているメンバーが当時の状況を把握できている状態にする。

    • Incident の原因、ユーザー影響、復旧要因、タイムラインに関する項目を埋めていく。

  • それらから Keep, Problem として、継続していきたい内容、再発防止したい内容、今後改善していきたい内容を洗い出す。

    • テンプレートの Lessons Learned を使うと洗い出しやすいです。

  • Problem を改善するための Try を書いていく。

    • TODO, Long-term Action として書いていく。

    • 問題が大きい場合は、以下のように色々な観点で問題を分解すると進めやすいです。

      • 未然に防ぐにはどうなっていると良いか

      • 異常に早期に気付けるにはどうなっていると良いか

      • 気付いた後の対応を早く行えるにはどうなっていると良いか

4. 書いたポストモーテムを Post mortems / Incident review 会で共有、レビュー

書いたポストモーテムを共有し、レビューを行います。 レビューでは、主に以下の項目が正しく記載されているかをレビューし、必要に応じてその場で修正を行います。

  • 内容が非難を避け、建設的であるか?

  • 後々のためにインシデントの主要なデータは収集されているか?

  • インパクトの分析は完全か?

  • 根本原因は十分に深く分析されているか?

  • アクションプランは適切で、その結果として行われたバグの修正には適切な優先順位が与えられているか?

  • 結果は関係するステークホルダーたちと共有されたか?

  • 長期的な解決策が考えられているか?

  • アクションプランや長期的な解決策でトイルが増加しないか?

「人を修正することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援することはできる」 抜粋:: Betsy Beyer “SRE サイトリライアビリティエンジニアリング”

書いたポストモーテムの活用

書いたポストモーテムについて、TODO は review 会で assign を決めて取り組んでいます。 Long Term Action は、以後のプロジェクトの検討材料として使ったりなどしています。

(Long Term Action の棚卸しなどはもっと行いやすいように、改善などを進めている最中です 💪 https://github.com/wantedly/post-mortems/issues/84)

話を聞きに行きたい

もっと知りたい

前へGit の慣習次へ負債返済日の取り組み

最終更新 3 年前

役に立ちましたか?

👉

Post mortems / Incident review 会は、 Infra Squad + 各 Domain の SRE チームのメンバーが参加しています。参加するには、 にコメントをしたり、直接相談などしてみてください。

にポストモーテム記載用の issue を作ります。

Incident の場合は に、サマリのテンプレートがあるので、それを利用すると便利です。

👉

Slack: ,

過去に開催した Post mortems / Incident review
ミーティングの Issue (internal)
wantedly/post-mortems (internal)
wantedly/infrastructure の incident issue template (internal)
駄目な例 (internal)
#war_room
#infra
失敗から学ぶ - ポストモーテム / Postmotem culture at Wantedly - Speaker Deck