# How to SRE When Everything is Already on Fire **登壇者**: [[Alex Hidalgo]]（@ahidalgosre, Squarespace Observability SRE）、[[Alex Lee]]（@ahl91, Service Reliability） **イベント**: SREcon19 EMEA（2019-10、ダブリン） **スライド**: 105 ページ / transcript なし ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-001.png]] ## 概要 [[Squarespace]] の ELK スタック（Elasticsearch / Logstash / Kibana）は 2015 年から急成長に伴って導入されたが、2018〜2019 年にかけて繰り返し大規模インシデントを起こしていた。本発表は「すでに炎上している」サービスに対して SRE 原則（SLI/SLO/エラーバジェット・オブザーバビリティ改善・ICS・ポストモーテム・継続的改善）を段階的に適用し、5 月時点で SLO ターゲットを 99% 5 分 → **99.9% 2 分**へ厳格化するまでの変革を記録した実録ケーススタディである。 ## 主要メッセージ 本発表は 7 つの原則を軸に構成される。 1. **アラートは「重要なことだけ」鳴らす** — ユーザー視点の単一 SLI で多数の内部コンポーネント監視を置き換える 2. **意味ある SLO を作る** — 完璧を目指さず、エラーバジェットを意思決定の道具にする 3. **オブザーバビリティを高める** — 何が起きているか分からなければ直せない 4. **環境を改善する** — ツーリングと自動化でオペレーター負荷を減らす 5. **実績ある手法を信頼する** — ICS 等の確立済みフレームワークを IT 運用に移植する 6. **意味あるポストモーテムを行う** — 過去から学ぶ 7. **すべてを反復する** — 改善は一度では終わらない ## 視覚的に重要な図表 **p.16 ELK オリジナルアーキテクチャ** ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-016.png]] Log Shippers → Kafka → Logstash → Elasticsearch（書き込み経路）、ユーザー → Kibana → Elasticsearch（読み取り経路）の 2 経路構成。Logstash が単一の複雑ポイントであり、複数コンポーネント監視が「既知の未知だけ捉えるノイジーなアラート」を生んでいた。 **p.24 新 SLI の定義（単一アラートへの移行）** ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-024.png]] Kafka 積み残しメッセージ数（msg）÷ Logstash 処理レート（msg/s）= エンドツーエンドレイテンシ（秒）を SLI と定義。6 種の内部コンポーネント監視を 1 つのユーザー体験指標に集約した。 **p.35 エラーバジェットの意思決定フロー** ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-035.png]] 余剰エラーバジェットがあれば「やりたいことをやる」、枯渇したら「信頼性にフォーカスする」という 2 方向の意思決定。2019-03-04 に SLO（99% / 5 分以内）を定義したことで、03-05 の障害でエラーバジェット枯渇が宣言でき、「全力対処の許可」が組織的に与えられた。 **p.50 改善後のアーキテクチャ（Logstash 廃止）** ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-050.png]] Logstash を「ブラックホール」として排除し、複数ソース → Kafka → Elasticsearch（直接）、ユーザー → Kibana → Elasticsearch の構成にシンプル化。 **p.65 ICS サブリード体制** ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-065.png]] Operations Lead 配下に Databases Operations Lead・Networking Operations Lead・Systems Operations Lead の 3 サブリードを配置。IC が Communications Lead・Planning Lead と並んでオペレーション全体を分離・委任する構造を示す。 **p.90 ポストモーテム修復項目の 2 軸分類** ![[_attachments/2019__SREcon19EMEA__How-to-SRE-When-Everythings-Already-on-Fire/page-090.png]] インシデントレスポンス軸（タイムライン分析・TT Detect・TT Engage・TT Mitigate）とシステム軸（予防的/緩和的対応・「なぜこんな仕組みがあるのか？」の自問）の 2 軸でアクションアイテムを分類する。 ## 背景と文脈：ELK インシデント年表 スライドはインシデント実録をタイムライン形式で示す。 | 日時 | 出来事 | |---|---| | 2015 年春 | ELK スタック導入（Squarespace 最大トラフィックサービス） | | 2018 年 8 月 | スタックが不健全な状態に | | 2019-03-04 16:29 ET | SLO 定義「ログラインを平均 5 分以内に処理 99%」 | | 2019-03-05 20:00 ET | 同じ問題が再発（インシデント開始） | | 2019-03-05 20:36 ET | エラーバジェット枯渇宣言 → 全力対処開始 | | 2019-03-21 20:00 ET | 37 時間インシデント開始（ES シャード過多問題） | | 2019-03-22 09:23 ET | 37 時間インシデント終息 | | 2019-03-24 午後 | 根本原因特定（シャード数 2,200 > 推奨上限 600） | | 2019-04-23 | ELK 変革の章を社内記録 | | 2019-05-10 | SLO 更新「99.9% / 2 分以内」へ厳格化 | 37 時間インシデントでは複数回の Incident Commander 引き継ぎが発生し、ICS 由来の公式引き継ぎプロセスが重要だった。 ## アラーム疲労の歴史的位置づけ スライドは「None of this is new」と強調し、アラーム疲労が IT 固有の問題ではないことを示す：ヘルスケア・鉱業・建設・原子力産業での研究の蓄積、そして 2,600 年前のイソップ寓話「嘘をついた少年」まで遡る。IT 運用の多数コンポーネント監視は「既知の未知しか捉えない・ノイジー・ユーザー視点でない」という 3 つの欠点を持つ。 ## 概念・実体への接続 - [[アラート疲労]] — 「None of this is new」として歴史的文脈を示した後、ユーザー視点の単一 SLI への移行で解決 - [[サービスレベル目標]] — SLI/SLO/エラーバジェットスタックをシンプルに解説。Reliability Stack として視覚化 - [[エラーバジェット]] — 枯渇が「信頼性対応の許可証」として機能した具体事例 - [[ポストモーテム]] — 3 要素（データ収集・教訓・修復項目）と「多様なバックグラウンドが鍵」 - [[Incident Commander]] — ICS 適用と引き継ぎ（Handing Off）プロセスの実例 ## 限界・不確実点 - SREcon19 EMEA の正確な発表日は確認できていない（2019-10 として記録、SREcon19 EMEA は 2019-10-02〜04） - transcript なし（動画 URL 未取得、Whisper 未実行） - Logstash 廃止後の具体的な代替コンポーネントはスライドから読み取れなかった（Kafka → ES 直結か、別の ingestor 経由かは不明） - Alex Lee（@ahl91）の所属部門や現在のキャリアは公式ページから確認できなかった