# 1年間のポストモーテム運用とそこから生まれたツール sre-advisor Navigation: [[ポストモーテム]] | [[index]] ## 概要 面白法人カヤックの SRE チームが 2020年10月から1年半にわたって全チーム横断のポストモーテム統一運用を実践した経験と、その振り返りから生まれた AWS リソース設定静的チェックツール sre-advisor を紹介する。SRE NEXT 2022（2022-05-14）での発表。ポストモーテム文化の定着だけでなく、「インシデント → ポストモーテム → sre-advisor → 事前検出」という知見をコード化する循環ループを構築した事例。 ## 主要メッセージ - ポストモーテムを書くことには3つの明確な利点があり、それは運用を続けることで初めて実感できる。 - 運用振り返りの結果、発生要因にはクラウドインフラ/ミドルウェアの設定不備が多いことが判明した（p.17）。 - 設定不備の事前検出をチェックシートでやると継続的なトイルになる。SRE ならエンジニアリングで解決すべきである（p.19）。 - sre-advisor はポストモーテムから得た知見をコード化し、AWS アカウントの既存リソース設定を自動検査する CLI ツールである（p.20）。 - 「インシデント → ポストモーテム → sre-advisor → 事前検出 → インシデント予防」というループによって、知見を組織の設定ガードレールへ昇華させた（p.29 まとめ）。 ## 視覚的に重要な図表 **p.6 カヤック SRE の Embedded SRE 組織構造** ![[_attachments/srenext2022-fujiwara-postmortem-sre-advisor/page-006.png]] SRE チームが複数プロジェクト(A/B/C/D)に入り込む形態のため、自分が関わっていないプロジェクトのインシデントを把握しづらい。共有ツールとフレームワークで情報をつなぐ構造を示す。 **p.8 ポストモーテムテンプレートと「月刊ポストモーテム」の運用フロー** ![[_attachments/srenext2022-fujiwara-postmortem-sre-advisor/page-008.png]] Google ドキュメントのテンプレート（インシデント名・日付・作者・ステータス・概要・影響・根本原因・発生要因）を事前に整備し、月次 Slack 投稿（「先月のポストモーテム」+一言コメント）で横断共有する運用フローを示す。 **p.21 sre-advisor が検出する項目の例** ![[_attachments/srenext2022-fujiwara-postmortem-sre-advisor/page-021.png]] ECS ulimit 未設定・ALB デフォルトアクション forward 指定・Lambda alias/revision 未指定・RDS デフォルトパラメータグループの 4 パターン。いずれもポストモーテムで発見された実際の設定不備が元になっている。 ## ポストモーテム横断統一運用の詳細 ### 運用フロー（p.8） - Google ドキュメントにテンプレートを事前整備。 - チーム内でレビューして作成。 - 月に1回、Slack チャンネルで「先月のポストモーテム」として投稿（興味を引く一言コメント付き）。通称「月刊ポストモーテム」。 ### 非難なき文化（p.10） O'Reilly SRE Book 15章を引用しているが「これは特に取り決めも心配もしなかった。元々社内の文化として、特定の個人を非難するような風潮はない」と述べる。非難なき文化は制度的取り決めでなく既存の組織文化によって担保されていた。 ### 書くかどうかの判断基準（p.11） - プロダクト利用者に大きな影響を与えたインシデントは必ず書く。SLI/SLO 運用チームはエラーバジェット消費量を基準にする。 - メンテナンス時などに想定外の事象が発生した場合も積極的に書く（他チームへの横展開のため）。 ### 運用して良かったこと（p.13–16） 1. **原因追及・根本原因解消の放置防止**: インシデントは業務時間外に発生しがちでその場の対応で終わりになりやすいが、ポストモーテムを書くことで発生原因やタイムラインを詳しく調査する必要が生まれ、根本原因解消のための時間を使えるようになった。 2. **社内横断の事例共有**: 多プロダクト運営のカヤックでは、自分が関わっていないプロジェクトのインシデントを知る機会となった。共通技術要素があれば横展開で参考にできる。 3. **プロダクト消滅後の知識保持**: 社内で多数のプロダクトが誕生・終了する中、プロダクト内に閉じたドキュメントは見返されなくなる。横断取りまとめにより消滅プロダクトの事例も永続化できる。 ## sre-advisor の設計 ### 概要（p.20） 社内ツール（internal repo）。AWS SDK for Go v2 を使用。AWS アカウントに存在する各種リソースの設定を取得し、問題がある内容を検出する CLI ツール。結果を text / markdown で出力する。 ### 検出項目（p.21） | 項目 | 内容 | |---|---| | Amazon ECS ulimit 未設定 | タスク定義のコンテナに ulimit が未定義。デフォルト nofile=1024 は高負荷時に不足 | | ALB デフォルトアクション forward | IP 直接アクセスが意図せず貫通する。デフォルトアクションは静的 404 を推奨 | | Lambda alias/revision 未指定 | $LATEST 呼び出しでデプロイ中にエラーが発生する可能性（2021年以降） | | RDS デフォルトパラメータグループ | デフォルトグループは編集不可。変更時に再起動が必要になる | ### AWS Trusted Advisor との統合（p.24） AWS コンソールを見に行くコストを避けるため、Trusted Advisor の検出結果も API 経由で取得して一緒に出力する。`DescribeTrustedAdvisorChecks` API は HTML を返すため適宜テキスト化する。 ### 抑制ルール（p.25） 「開発用 RDS なので Multi-AZ にしていない」など意図的な設定は設定ファイルで ID を指定して抑制できる。人が見慣れた警告を無視する習慣をつけないよう運用する。 ### GitHub Actions + Issue 連携（p.26） GitHub Flavored Markdown 出力と `gh issue create` を組み合わせ、定期的な「指摘潰し祭り」を GitHub Actions で実施。推奨アクションをチェックボックス形式の Issue にして分担して解消する。 ### 社内配布方法（p.28） sre-advisor は社内 internal repo のため GitHub Release からの配布が難しい。対策: GitHub Actions でビルドして Amazon S3 に配置し、S3 Bucket Policy の `aws:PrincipalOrgID` 条件で自 Organization のアカウントからのみアクセス可能にする。個人アクセストークン不要で AWS 認証済みアカウントから取得できる。 ## 口頭説明・補足（YouTube 字幕より） - カヤックの SRE は「Embedded SRE」形態で各プロジェクトに1〜2人入り込む。この体制ではプロジェクト横断の情報把握が難しく、経験豊富なエンジニアが速攻で対応を終わらせると他のメンバーが経験を積む機会が減る問題があった（字幕 p.54–83）。 - ポストモーテム統一運用のきっかけは、そうした「経験の固定化」と「知見の共有不足」の解決。 - sre-advisor の検出結果は「[Critical] ECS のタスク定義『example:1』内のコンテナ nginx には ulimits の設定を追加してください」など具体的なアドバイス付きで出力する。 ## 概念・実体への接続 - [[ポストモーテム]] — Embedded SRE 組織での横断統一運用実践例。知見のコード化ループが新しい観点。 - [[藤原俊一郎]] — 登壇者。面白法人カヤック SRE、ecspresso・lambroll 作者。 - [[面白法人カヤック]] — 所属組織。ゲーム・コミュニティサービス多数。 - [[トイル]] — チェックシートによる手動設定確認をトイルとして批判し、自動化で解決した事例。 ## 限界・不確実点 - YouTube 字幕（自動生成）を使用しており、固有名詞の表記ゆれがある（例: "SRDアドバイザー"、"自己検証" 等）。数値・固有名はスライド画像を正とした。 - sre-advisor は 2022年時点で internal repo。現在の公開状況・機能拡張は不明。 - p.22〜p.27 のスライド画像は API 制限により未確認。テキスト抽出で補完。