SREはどこまでやるのか　SREの責任範囲とセキュリティ民主化時代の運用再設計ライフサイクル

Editor's Notes

• #1 【00:00】 みなさんこんにちは。Sysdig の檜垣です。ふだんは SRE とセキュリティが重なる領域の仕事をしています。自己紹介はこれくらいにして、さっそく本題にいきますね。 表紙、ちょっと見てください。いきなり問いを5つ並べました。SREの責任はどこまでか。セキュリティは誰の仕事か。運用はなぜ複雑になったのか。今の体制で守れているか。そして最後、運用をどう再設計すればよいのか。 今日の30分は、この5つの問いに順番に答えていくセッションです。答え合わせは後半でやりますので、頭の片隅に置いておいてください。
• #2 【00:40】 全体の地図です。6パートで30分。前半は問題の構造、なぜ境界が曖昧になったのか。後半は解法、Platform Engineering を借りて、明日から使える形まで落とします。では行きましょう。
• #3 【01:20】 まず、この同心円を見てください。真ん中の緑、これが SRE 本来の責任です。信頼性と可用性。SLO を運用する仕事ですね。 ところが最近、この外側に輪っかが増えてないでしょうか。セルフサービス基盤やガードレールの整備、つまり Platform の輪。さらにその外に、検知や脆弱性対応、Security の輪。 輪が増えるたびに、真ん中の仕事をやる時間って減っていくんですよね。心当たりのある方、いらっしゃいますよね。責任は同心円状に、外へ外へ積み上がり続けている。まずこの構造を頭に入れてください。
• #4 【02:50】 ここからパート1です。右上に表紙の5つの問いを置きました。いまは全部グレーです。話が進むたびに点灯していきますので、いまどこにいるかの目印にしてください。 まずは歴史からです。境界はなぜ曖昧になったのか。誰が悪い、という犯人探しではなくて、構造の話をします。
• #5 【03:10】 そもそもの出発点はここです。インフラ、つまり Ops と、アプリ、Dev は、もともと別の組織で、別の評価指標で動いていました。 Ops の KPI は安定性です。壊したくない。Dev の KPI はリリース速度です。早く出したい。評価指標が逆を向いてるので、真ん中に亀裂が走るのは当然なんですね。 【綱引きを指して一拍】これ、毎週やってませんでした？　デプロイのたびに摩擦が起きて、障害が起きれば責任のなすり合い。個人が悪いんじゃなくて、組織と評価指標に分断が埋め込まれていた。ここが出発点です。
• #6 【03:55】 この分断を埋めようとしたのが DevOps です。左から時系列で見てください。まず分断の時代。【左の2人を指して】にらみ合ってますね。 そこに2009年、Flickr 社の講演から DevOps が広まります。Dev と Ops が協力しよう、文化とコラボレーションで接着しよう、という理想です。 でも、右端を見てください。【ケンカの2人を指して】また殴り合ってるんですよ。なぜか。DevOps は「何をどう運用するか」という再現可能な実践方法を定義しなかったんです。文化って属人的なので、組織が大きくなるほど機能不全になる。理想はあったのに、実装がなかった。
• #7 【04:40】 そこで出てくるのがこの一行です。今日いちばん覚えて帰ってほしいやつです。ゆっくり読みますね。 class SRE implements interface DevOps。 DevOps がインターフェース、つまり理想の宣言です。Google はそれを、SLI、SLO、エラーバジェットという定量的なエンジニアリング手法として「実装」した。それが SRE です。 エンジニアのみなさんなら、インターフェースと実装の関係、一発で腹落ちしますよね。Ben Treynor Sloss の定式化として広く知られている話です。
• #8 【05:10】 実はセキュリティも、まったく同じ課題の連鎖をたどっています。 2010年代は専任セキュリティチームの時代でした。課題は、検知から対応までのタイムラグです。2015年頃のシフトレフトも、ランタイムの当事者は曖昧なままでした。 転機は Falco の CNCF Graduate です。ランタイム検知が「仕組み」として標準化された。そして今、検知と対応の民主化。SRE と開発が一次対応の当事者になる時代です。 検知が仕組みになって初めて、民主化は絵空事でなくなる。ここ、後半の伏線なので覚えておいてください。
• #9 【06:00】 ところがここで矛盾が起きます。左が想定です。SRE は DevOps という理想の、内側の実践手法だったはずでした。 でも現実は右です。組織が巨大化すると、SRE は専門チームとして切り離される。そして切り離された先の SRE チームには、設計も、CI/CD も、セキュリティも、「信頼性に関係するから」という理由で全部積み上がっていくんです。 内側の実践だったはずのものが、外側の受け皿になってしまった。
• #10 【07:00】 その結果がこれです。【荷物タワーを指して一拍笑いを待つ】 積んである箱、下から読みますね。監視、運用、CI/CD、セキュリティ、開発、設計。で、てっぺんのオンコールが、いままさに滑り落ちそうになってます。 これが今日の中心の問いです。SRE は「何でも屋」になっていないか。 ただ、先に言っておきます。答えは「どこまでやるか」という線引きではありません。認知負荷をどう仕組みに逃がすか、という設計の話です。後半で解いていきます。
• #11 【07:50】 ここでちょっと手を動かしましょう。挙手をお願いします。 1問目。直近1ヶ月で、「これって自分の仕事なんだろうか」と思いながら対応したインシデントがある方？　【挙がったら】ありがとうございます。【右の絵を指して】だいたい絵の通りですね。 2問目。SRE、Platform、Security の責任分解点が、ドキュメントとして書かれているチームの方？　【ほぼ挙がらない想定】……はい、こちらも絵の通りです。挙げづらければ心の中でカウントで大丈夫です。 つまりですね、境界は「感覚」で運用されてるんです。ドキュメントがない。これがなぜ問題なのか、次で構造的に見ます。
• #12 【08:40】 SRE が何でも屋になるのには、4つの構造的な理由があります。【漏斗の絵を指して】上から仕事が降ってきて、漏斗を通って、最後はバケツを構えた誰かが受ける。この「誰か」が SRE です。 1つ目。責任が「結果」で定義される。信頼性を脅かすものは、理屈上ぜんぶ SRE の仕事になります。 2つ目。SRE は構造的に「最後の受け皿」。行き場のない仕事は、デフォルトで SRE に落ちてきます。 3つ目。降ってくる仕事の大半は、あとで説明する Extraneous Load、余計な負荷です。本来集中すべき設計判断の時間を奪います。 そして4つ目、ここが今日の肝です。これまで「誰がやるか」の議論しかなかった。「仕組みに逃がす」という第三の選択肢が、そもそも存在しなかったんです。線引きの問題じゃなくて、設計の問題なんですよ。
• #13 【09:40】 ここで道具を1つ入れます。認知負荷理論の3分類です。 まず Intrinsic。学習対象そのものの難しさです。分散システムの障害モードとか。これは仕事の本質なので、消せません。 次に Extraneous。余計な負荷です。誤検知の一次判定とか、ツールのハシゴとか。【頭の絵を指して】オレンジがいちばんデカくて、溢れてますよね。 最後に Germane。成長につながる、本来やるべき負荷です。機能を考える、設計を Design Doc にまとめる。緑、隅っこに追いやられてます。 つまり SRE の責任範囲論って、実は認知負荷の配分問題なんです。Extraneous を仕組みに逃がして、Germane を守る。この枠組みで、ここから先の話を進めます。なお、この整理は山田さんの資料を参考に再構成しています。
• #14 【11:00】 では、セキュリティの民主化とは何か。上下の2レーンで見てください。ポイントは、同じアラートが「誰を通るか」だけが違う、ということです。 上段が従来です。異常が発生すると、セキュリティ専任チームが検知もトリアージも対応も独占します。SRE と開発は基本、蚊帳の外。人がボトルネックなので、対応は営業時間と人数に縛られる。右端に書いた通り、一次対応までのタイムラグが本質的な課題でした。 下段が民主化の時代です。同じ異常でも、検知と要約は仕組み、Falco と Sysdig Platform が担います。そして SRE と開発が、ガードレールの内側で一次対応する。ここが主役です。セキュリティチームは、設計と例外対応に集中する。 専任チームが要らなくなる話ではないんです。役割が「実行」から「設計」へ上がる話です。
• #15 【12:00】 ただですね、正直に言うと、民主化は「そのまま」では失敗します。 理想はこうです。検知・対応を現場に広げれば、対応は速くなるはず。で、現実はこの4つの壁にぶつかります。 1つ目、認知負荷が直撃する。ただでさえ何でも屋の SRE に、素のアラートがそのまま乗ります。2つ目、その大半は Extraneous です。さっきの誤検知の一次判定ですね。3つ目、判断基準がない。何が本当に危険か、現場だけでは決めきれません。4つ目、丸投げになる。責任分解点が曖昧なまま渡すと、名前だけの民主化、ただの仕事の押し付けになります。 さっき2問目で手が挙がらなかったの、覚えてますよね。ドキュメントがないまま民主化すると、必ずこの4つ目で事故ります。だから、民主化は丸投げではなく、仕組みを介した委譲でなければいけない。これが後半への橋になります。
• #16 【13:10】 もう1つ、「なぜ今なのか」という話をさせてください。速度の話です。 クラウド攻撃の世界では、検知に許される時間は5秒しかない、と私たちは考えています。5秒で検知、5分でトリアージ、5分で対応。これは私たち Sysdig が掲げている「555ベンチマーク」です。実際のクラウド攻撃の分析から、このスピードで回れれば攻撃者より速く動ける、という目安として出しているものです。【ダイヤルの中を指して】もう中で犯人がカタカタやってますからね。 チケットを起票して、翌朝トリアージして、担当をアサインして……という人手前提の分業では、この速度に構造的に追いつけないんです。秒単位の攻撃には、仕組みによる一次対応が前提になる。だからこそ、セキュリティが SRE の認知負荷の設計に乗ってくるわけです。
• #17 【14:10】 ここからパート2、解法編です。 右上を見てください。問いが3つ点灯しました。責任はどこまでか、は積み上がる構造の話をしました。セキュリティは誰の仕事か、は民主化の話をしました。運用はなぜ複雑になったのか、は歴史をたどりました。 残りは2つです。今の体制で守れているか。そして、どう再設計するか。ここから Platform Engineering という考え方を借りて、答えていきます。
• #18 【14:30】 まず Platform Engineering とは何か。一言でいうと、開発者が自己解決できる「内部プラットフォーム」を、プロダクトとして設計・運用するアプローチです。目的は、チームの認知負荷を下げて、速度と信頼性を両立させること。 用語を4つだけ入れさせてください。ゴールデンパス。推奨構成を、舗装された道として提供する。セルフサービス。申請や依頼を待たずに、開発者自身で完結できる。ガードレール。安全に使える範囲を、あらかじめ仕組みで担保しておく。そして Platform as a Product。開発者をユーザーとして扱って、体験を改善し続ける。この4つ、この後は説明なしで使います。 ちなみに右のドーナツ、Gartner の予測では、2026年までにソフトウェアエンジニアリング組織の8割がプラットフォームチームを持つと言われています。一過性の流行ではない、ということです。
• #19 【15:30】 Platform Engineering の設計原則が、この責任共有モデルです。3層あります。 一番上が Application。ビジネスロジックとランタイム設定。開発チームの責任です。真ん中が Platform。ゴールデンパス、ガードレール、そして検知の要約。ここがプラットフォームチームの責任。一番下が Cloud と Sysdig。マネージドサービスとランタイムシグナルの責任範囲です。 ポイントは、層と層の間に「責任分解点」を明示的に引くことです。AWS の責任共有モデルと同じ発想が、社内のプラットフォームにも、セキュリティにも適用できる。さっきの2問目のドキュメント、実はこの絵を1枚描くだけでいいんです。この図は下川さんの資料を参考に再構成しています。
• #20 【16:20】 これを動きで見ます。X as a Service、セルフサービス化です。聞き慣れない方もいると思うので、ここは少し丁寧に話させてください。 まず X には何でも入ります。DB、CI/CD、監視、そして今日はセキュリティ検知です。意味は、これまで「チームへの依頼」で提供していた能力を、「プラットフォーム経由のセルフサービス」として提供し直す、ということです。 従来はどうだったか。検知を入れたければ、セキュリティチームにチケットを切って、待って、受け渡しして……という依頼駆動でした。人を待つ時間が、そのまま全部リードタイムになります。 セルフサービスだとこうなります。上から追いますね。アプリや SRE のチームが、プラットフォーム API に自分でリクエストする。API が Sysdig と Falco にランタイム検知を自動適用する。検知結果は要約されて返ってくる。ここまで、人を待つ工程がゼロです。 ただし、「何でも自由」ではありません。ここが一番大事です。ガードレールの内側なら自己解決。この点線は「人の判断」です。そして範囲を跨ぐ局所対応のときだけ、セキュリティチームにエスカレーションされる。 つまり、自由とガードレールはセットなんです。人が出るのは例外だけ。残りは全部プラットフォームが受ける。さっき言った「仕組みを介した委譲」の実装形が、これです。
• #21 【18:20】 じゃあ何から始めるか。3ステップです。 まず最小限のプラットフォーム。既存の OSS や AWS を組み合わせた、一番薄い構成から始めます。Thinnest Viable Platform と言います。チームの新設は要りません。 次に計測。認知負荷の変化を数字で測ります。数字にならないと社内は動かないので。 最後に、効果を確認してから横展開。小さく作って、測って、広げる。プロダクト開発と同じです。
• #22 【19:00】 ここで、SRE の提供のしかたを2つ比べます。Embedded SRE と Platform Engineering です。 Embedded は「埋め込み」という意味です。SRE が特定の開発チームの中に入り込んで、メンバーとして一緒に働くスタイルですね。中で何をするかというと、そのチーム特有の難しさ——さっきの言葉だと Intrinsic、仕事の本質的な難しさを、隣に座って一緒に下げていく。うまくいってるかどうかは、サービスの信頼性、つまり SLI や SLO で測ります。やり取りは人と人のコラボレーションです。 一方の Platform Engineering は、特定のチームに入り込む代わりに、全チームに共通する「余計な作業」——Extraneous のほうを、仕組みで丸ごと引き受けます。効果は開発者の生産性の指標、SPACE や DORA で測る。提供のしかたは、さっきやったセルフサービス、X as a Service です。 乱暴にまとめると、Embedded は「深く狭く、人で効く」。Platform は「浅く広く、仕組みで効く」。どっちが正しいかではなくて、効く場所が違うんです。この軸のまま、次でセキュリティに当てはめます。比較表は山田さんの資料が元ネタです。
• #23 【20:30】 同じ軸をセキュリティに当てはめると、こうなります。 左が Embedded Security。ローテーションでチームに入ってくれる専門家です。さっきの「深く狭く、人で効く」側ですね。何が本当に危険かという局所的な脅威判断を一緒にやってくれる。指標は MTTD と MTTR、検知までの時間と復旧までの時間です。 右、緑の方が Security as a Platform。「浅く広く、仕組みで効く」側です。ランタイム検知の仕組み化と運用。検知から要約まで全体を仕組みが受けます。指標は、検知をどれだけ取りこぼさないか、どこまで自動で対応できたか。Sysdig / Falco as a Service という形ですね。 大事なのは、両方必要だということです。人、つまり Embedded が判断基準を作って、仕組み、as a Service がそれをスケールさせる。さっきの壁の3つ目、「判断基準がない」は、Embedded がいるから埋まるんです。
• #24 【21:40】 パート3に入ります。左上、4つ目が点きました。「今の体制で守れているか」。答えは、ガードレールと責任分解点の設計次第で守れる、でした。 残るは最後の1つです。運用をどう再設計すればよいのか。いよいよ実装の話をします。
• #25 【22:00】 再設計の骨格がこのループです。検知、トリアージ、対応、学習。 このループの各ステップを、「誰がやるか」ではなくて、「どの仕組みに配分するか」で考えるんです。検知は Falco。トリアージ、つまり集約・要約・優先度付けはプラットフォーム。対応はガードレールの内側で SRE と開発。そして学習は、ルールと検知条件に落として、仕組み側に返す。 従来いちばんもったいなかったのは、この学習が人の頭の中にしか残らなかったことです。ループのどこを仕組みに、どこを人に置くか。それが設計の核心です。
• #26 【23:00】 ここで、表紙の問いに戻ります。全部点灯しました。上から答え合わせをしますね。 SREの責任はどこまでか。責任分界は変化し続けます。固定の線はありません。セキュリティは誰の仕事か。検知と対応は民主化します。仕組みを介して、ですが。運用はなぜ複雑になったのか。SREとセキュリティの融合が起きたからです。今の体制で守れているか。運用ライフサイクルの現実を見ました。設計次第です。 そして最後。運用をどう再設計すればよいのか。再設計のモデルと実装、ここから見せます。
• #27 【23:40】 実装です。検知パイプラインの責任分解。左から流れます。 Workload、コンテナやホストですね。ここで何かが起きる。Falco がランタイムで検知する。Sysdig Platform が要約して、優先度を付ける。そして SRE と開発が一次対応する。 矢印のたびに「責任の受け渡し」が起きています。これをツール任せにせず、さっきの責任共有モデルの絵として文書化しておく。それだけで、障害時の「これ誰がやるの」が消えます。
• #28 【24:40】 ちょっとだけ肩の力を抜きます。T-850 と T-X、何が違うか。 左の旧型は、完全自律だけど目的は固定。定型パターンで処理する「自動化」です。右の新型は、計画そのものを再設計して戦略判断する。これが Agentic AI です。 なんでこの話をしたか。次のデモの「検知して、要約して、優先度を付ける」が、まさに右側だからです。では見てみましょう。
• #29 【25:30】 デモです。【デモまたは録画。以下は実況の台本】 まず Falco が、異常なランタイムイベントを検知します。次に Sysdig Platform が、関連イベントを集約して要約します。ここまで人間、何もしてません。そして優先度付きで SRE に通知が飛ぶ。人がやるのは、この点線のところだけ。承認するか、ロールバックを指示するか。判断だけです。 見てほしいのは、ログを漁る、関連イベントを探す、影響範囲を調べる、といった作業が全部仕組み側にあることです。さっきまで Extraneous と呼んでいたやつですね。 人が判断し、機械が実行する。逆ではない。ここ、大事です。
• #30 【27:00】 この先の見取り図です。2026年、検知の仕組み化が標準運用になる。2027年、ガードレールの内側で開発者が自己解決する、セルフサービス化。2028年、SRE は Germane Load、信頼性の設計判断に集中する。そしてその先。「何でも屋」から、「認知負荷を配分する設計者」へ。 【左下の絵を指して】AIに仕事を奪われる、ってよく言われますけど……奪わせるのは Extraneous だけです。Germane、つまり考える仕事は、むしろ増えますから安心してください。
• #31 【27:50】 最後に、明日からの話をします。3つだけ、今週やってみてください。 1つ目、棚出しです。直近のオンコール対応を、Intrinsic、Extraneous、Germane の3つに分類してみてください。分類するだけでいいです。どこに Extraneous が溜まっているかが見えるだけで、チームの会話が変わります。30分でできます。
• #32 【28:10】 2つ目、境界を書く。SRE、Platform、Security の責任分解点を、1枚のドキュメントにしてください。 凝ったものは要りません。さっきの3層の絵に、自社のチーム名を書き込むだけでいい。今日2問目で手が挙がらなかった状態から、挙がる状態へ。境界を「感覚」から「ドキュメント」にする。それだけです。
• #33 【28:30】 3つ目、一点突破。棚出しで見つけた、いちばん Extraneous が高いタスクを、1つだけ選んでください。そして自動化なり、セルフサービス化なりを試す。 全部やろうとしないでください。1つでいいんです。線引きを議論するのではなく、小さく設計してみる。これが今日の持ち帰りです。
• #34 【29:00】 まとめます。SREはどこまでやるのか。30分前の私たちなら、線引きの話だと思っていたはずです。 答えは、「どこまで」ではなく、「どう仕組みに逃がすか」。SREを何でも屋にしないために、認知負荷をどの仕組みに配分するかを設計する。 【右の設計者を指して】ちなみにこの人、最初に荷物のタワーを抱えてた彼です。設計者になりました。【左下の絵を指して】あと、AIと人の関係も設計次第です。こうならないための、設計です。 今週、棚出しからやってみてください。ご清聴ありがとうございました。
• #35 【29:40】 出典です。今日の Platform Engineering まわりの図は、下川健介さんの「Platform Engineering on Serverless」と、山田陵太さんの「ちがいからみる Platform Engineering」の構造を参考に、Sysdig ブランドで再構成させていただきました。原典が本当に素晴らしいので、ぜひ元の資料もご覧ください。 それでは、質問があればどうぞ。懇親会でも捕まえてください。ありがとうございました。