# You Can't Stop Fires with an Ambulance ## 概要 [[Xero]] の SRE 責任者 [[Piers Chamberlain]] による USENIX SREcon18 Asia/Australia(2018年6月、シンガポール)での発表。クラウド移行後に急増したアラートとインシデントに対し、症状ベースアラーティングへの簡素化([[Klaxon]])と chatbot によるインシデント管理自動化([[Multivac]])という技術的対策を講じたにもかかわらずインシデント数自体は増加し続けたという逆説を出発点に、post-mortem データの横断集計不足という真因発見と、それを解決するための組織的キャンペーン(正しい人・正しい言語を巻き込む)への転換を語る。 ## 主要メッセージ - **アラートの症状ベース簡素化**: 物理データセンターからクラウドへの移行(2016年)でアラート量が倍増した。Rob Ewaschuk の "philosophy on alerting" 論文(Google SRE Book の先駆け、当時回覧されていたという口頭説明あり)を参考に、根本原因ベースの個別アラートを CPU credit burn・ロードバランサー最小ホスト数割れなど「症状」ベースの少数アラートに集約した。 - **Klaxon による安全網アラート**(p.8): 顧客向けエラーページ・ステータスページへのアクセスをヒットレート信号として使う。JavaScript コールバック → Error API → SQS → Klaxon Scheduled Lambda が sourceIp/userAgent/CORS Origin/Custom Cookie を捕捉し、SumoLogic へイベント送信、SumoLogic のアラートが DataDog のワークフローをトリガーし、DataDog が Slack 通知と status.xero.com のメンテナンスモード更新の両方を実行する。事前設定アラートで捕捉できない障害を検知する「安全網」として機能した。 - **war room から chatbot(Multivac)へ**: 従来は最も経験豊富なエンジニアを他の作業から引き剥がして war room に集める方式だったが、スケールせず高価値エンジニアの労働環境も損なうと判断し、プロセスを文書化・簡素化した上で chatbot「Multivac」による自動化を構築した。インシデントクローズ時に関連リンクを集約した post-mortem 文書を自動生成する。MTTD・MTTR は改善した。 - **それでもインシデント数は増加し続けた**(p.12): 2016年2月〜2018年3月の月次インシデント数は年を追うごとに明確な増加トレンドを示す。post-mortem のたびに contributing cause を特定し work item を作成していたにもかかわらず、全体の発生率は下がらなかった。 - **2年分の post-mortem を手動で横断集計**(p.14): 発表者自身が数百件のインシデントを読み返し、contributing cause を収集・stack-rank した。結果、リリースプロセス(`#release`)が最多要因で、容量関連(`#capacity`)の約4倍の頻度を占めることが判明した。この分析を2年間怠っていたことが最大の反省点だと述べる。 - **post-mortem アクションの実施率は約50%**(p.16): "Created vs. Resolved Issues Report" で識別済みアクションと完了済みアクションの乖離が一貫して開いていく。原因は post-mortem の参加者が on-call SRE・on-call product・customer success に限られ、feature work とreliability work の優先順位を決定できる権限者が同席していなかったこと。 - **3グループを巻き込むキャンペーン**: tech leads(dev managers・heads of engineering)、product owners、senior management の3グループを「正しい言語」(developer productivity・customer impact・business goals)を使って会話に引き込む。新規プロジェクトの technical kickoff に割り込んで運用面の議論を持ち込むなど、機会を見つけて働きかけた。 - **Report Card による会話の起点作り**(p.19): SLO・アラート疲労等の運用衛生スコアをダッシュボード化した独自ツール。総合スコア76、7ルール中3ルールで課題を検出(例: Xero Appserver のバージョンが103日古い)。数値の完全な正確性よりも「会話を始める機会」としての機能を重視すると明言。 ## 視覚的に重要な図表 **p.8 Klaxon アーキテクチャ図** ![[_attachments/srecon18asia_slides_chamberlain/page-008.png]] User → Xero(error page / status.xero.com)→ Error API → SQS → Klaxon Scheduled Lambda → SumoLogic の一次経路と、SumoLogic アラートが DataDog ワークフローを起動し DataDog が Slack 通知と status.xero.com のメンテナンスモード更新を行う二次経路を示す。 **p.12 月次インシデント数推移(2016年2月〜2018年3月)** ![[_attachments/srecon18asia_slides_chamberlain/page-012.png]] 2016〜2018年を通じて明確な増加トレンド。技術的対策(症状ベースアラート・Multivac)の導入後もインシデント数自体は下がっていない。 **p.14 Contributing factors の頻度分析** ![[_attachments/srecon18asia_slides_chamberlain/page-014.png]] `#release` が最多(約29件)で `#specific_technology_1`(約27件)・`#db`(約25件)が続き、`#capacity`(約8件)の3〜4倍に達する。技術名の一部は匿名化されている。 **p.16 Identified vs. Completed Actions** ![[_attachments/srecon18asia_slides_chamberlain/page-016.png]] "Created vs. Resolved Issues Report"(Project: SRE Postmortems、2017年1〜4月)。作成済み(赤)と解決済み(緑)の乖離が時間とともに拡大し、実施率は概ね50%にとどまる。 **p.19 Report Card スクリーンショット** ![[_attachments/srecon18asia_slides_chamberlain/page-019.png]] 総合スコア76、Found 3 Issues across 7 Rules。SLO: Latency=100・SLO: Thresholds Defined=100・Xero Appserver=15(バージョンが103日古いと赤字警告)・Alert Fatigue=100 などの個別ルールスコアを一覧表示する。 ## 口頭説明・補足 transcript より補足: - **Xero の背景**: 2006年 Rod Drury 創業。クラウド会計 SaaS。発表当時1,300万人超の有料契約者、180カ国以上で展開。SRE チームはクラウド移行を機に旧運用チームを分割して発足し、発表時点で約2年、3拠点・約30名。 - **war room の問題点**: 「最も経験値の高いエンジニアを引き抜いて war room に押し込め、直せるか?と聞く」方式は、スケールしないだけでなく、その高価値エンジニアにとって充実感のある労働環境を提供できていなかったと Chamberlain は振り返る。 - **Multivac の位置づけ**: 発表内では概要のみ扱い、詳細は同僚 Karthik による SREcon18 Asia の別セッション(発表の翌日)に譲ると案内している。 - **手動集計作業への述懐**: contributing cause の横断集計は「本当に退屈な仕事で、誰にも委任できず、申し訳なく感じた」と述べる。だが this is main reason that you should do post-mortems(post-mortem を書く本来の理由はここにある)と強調する。 - **post-mortem の再実施の無駄**: スケールにより同一の on-call 担当者が毎回揃うとは限らず、1週間前とほぼ同一のインシデントに気づかず post-mortem を再度ゼロから実施していたケースがあったと明かす。 - **Report Card の位置づけ**: 「これは新規性のあるアイデアでは全くない。他の SRE カンファレンスでも見た手法だ」と自ら述べ、独自性よりも会話を生む実用性を重視する姿勢を示す。 - **結びの3教訓**: (1) インシデント傾向は発生と同時に追跡せよ(2年前の自分に伝えたい最大の教訓)、(2) work の実施可否を左右する人を最初から巻き込め、(3) customer impact や engineering cost に基づく主張の方が「これが正しいことだから」という主張より説得力を持つ。 ## 概念・実体への接続 - [[クロスインシデント分析]] — 専任チームなしで発表者個人が手動で contributing cause を横断集計した初期的実践例 - [[アラート管理]] — Klaxon の症状ベース検知アーキテクチャ、Ewaschuk 論文への言及 - [[アラート疲労]] — クラウド移行後のアラート倍増から症状ベース簡素化への転換 - [[ポストモーテム]] — 個別 post-mortem の contributing cause を横断集計しなかったことへの反省 - [[ChatOps]] — Multivac による post-mortem 文書自動生成 - [[Piers Chamberlain]] — 発表者、Xero SRE 責任者 - [[Xero]] — クラウド会計 SaaS 企業 - [[Klaxon]] — 顧客ページヒット率ベースの検知システム - [[Multivac]] — インシデント管理 chatbot - [[Report Card]] — 運用衛生スコアリングツール ## 限界・不確実点 - `date_published` は USENIX SREcon18 Asia/Australia の開催月(2018年6月、シンガポール)まで判明しているが、Chamberlain の登壇日ピンポイントは公式ページから確認できていない。 - p.14 の contributing factor 名は一部が `#specific_technology_1〜3` に匿名化されており、実際の技術スタック(言語・ミドルウェア等)は特定できない。 - Rob Ewaschuk の "philosophy on alerting" 論文は口頭説明のみの言及で、スライド画像上には論文名・著者名の直接記載がない(transcript の音声認識では "Rob Elshuk" と誤記されている)。 - Multivac の内部アーキテクチャはこのスライドセットには含まれず、同僚 Karthik の別セッションに譲られているため未取得。 - transcript に質疑応答が含まれておらず、Q&A セクションは省略した。