#sre

SREや運用の現場では、AIがアラートを見て、原因を推測し、ログやメトリクスを調べ、場合によっては修復まで進める時代に入りつつあります。便利であるのは間違いないのですが、その裏で人間の側がシステムを理解する機会を失っていく、というのが今回の話です。事故対応の平均時間は短くなっても、複雑な障害に当たったときには、かえって人間が弱くなるかもしれない。著者はそこに強い危機感を示しています。単なるAI賛美でも反AIでもなく、運用の腕がどう鈍るのかをかなり具体的に掘っているのが面白いところです。 元記事の著者 Sylvain Kalache は、2012年にLinkedInでSREをしていたころ、自律的に自己修復し、過去の障害から学ぶシステムを設計したと振り返ります。当時は今ほどAI能力が高くなく、その仕組みは試作にとどまったものの、いまでは似た発想が現実のツールとして動いている、と述べます。これらのAI支援インシデント対応ツールは、アラートを確認し、仮説を立て、telemetryを問い合わせ、最近のデプロイと照合し、修正の実行まで担える。著者はその実力を認めつつも、運用担当者がシステムとの距離

この記事を読んでまず思ったのは、やっぱり現場の話はきれいなデモとは全然違う、ということだった。 「Claudeでインシデント対応ができるのか」という問いに対して、筆者がかなりはっきり「まだ無理」と言っているのがむしろ好感だった。AIの話になると、どうしても成功例だけが独り歩きしがちだけれど、実際の運用ではそんなに単純じゃない。 面白かったのは、LLMが得意なところと苦手なところの境目がかなり生々しく書かれていた点だと思う。ログやtraceを眺めて、異常らしいものを拾うのはかなり強い。でも、root cause analysis、つまり「なぜそれが起きたのか」を因果で詰める段になると、まだ怪しい。ここは単なる能力差というより、仕事の性質そのものの違いなんだろう。観察は得意でも、説明責任は別物だ、という感覚に近い。 それと、筆者が「Claudeをダッシュボードより先に使うことがある」と言っていたのは、かなり現実的で驚いた。AIが人間の代わりになるというより、最初の視界を開く道具になっている。オンコール中って、何が壊れたかを掴むまでの数分がとにかくつらいので、その入口を少しでも短くできるなら

この記事を読んで最初に思ったのは、これはベンチマーク記事というより「ベンチマークを雑にやると、たぶん簡単に自分たちをだませる」という警戒心の表明だな、ということだった。SREの調査支援ツールは、見た目が賢そうでも、実際に事故対応で役に立つかはかなり怪しい。しかも同じ質問でも答えがぶれる。だから、ただデモで気持ちよくなるのではなく、同じ条件を固定して、しかも答えを盲検で採点する、という発想はかなり筋がいいと思う。 特に引っかかったのは、合成データの作り方にかなり神経を使っている点だ。現実の障害っぽいノイズを入れつつ、わざと似たような別の異常も混ぜる。さらに、公開データセットをそのまま使うと学習済みの知識で当ててしまうかもしれないから、オリジナルのシナリオを作る。ここまでやると、ようやく「LLMが過去に見たパターンを思い出しているだけではない」と言えそうだし、逆に言うと、ここまでしないと評価がかなり怪しくなるのだろうと思った。 もう一つ面白かったのは、ClickHouseを直接SQLで触らせる方法より、ClickStack MCPのように「高レベルの観測用プリミティブ」を渡したほうが、単に