#障害対応

Yandex Cloud の障害ページを開いたら、障害内容ではなく「Are you not a robot?」という確認画面が出ていた。サービスの可用性を知らせるはずの場所で、アクセスした側が bot かどうかを確かめるページに飛ばされるのは、少し妙に見える。だが、こうした表示は単なる見た目の不具合ではなく、アクセス制御や自動送信の判定が前面に出た結果でもある。今回の件は、Yandex が外部からの問い合わせやページ閲覧をどのように扱っているかを、そのまま見せている。 元記事として示されている Yandex Cloud のステータスページには、本来なら障害やメンテナンスの説明が載るはずだが、実際に表示されているのは「Are you not a robot? Please confirm that you are not a robot」という文言だった。続けて、送信元のデバイスからのリクエストが自動化されているように見える、という案内が出る。理由として挙げられているのは、JavaScript が無効になっている場合などだ。 画面には「I’m not a robot」のチェックボックスが

ソフトウェア開発で障害が起きたとき、私たちはつい「なぜ起きたのか」を丁寧に掘り下げたくなります。経緯を整理し、関係者の判断をたどれば、次はうまくいくはずだと考えるからです。この記事は、その考え方に静かに異議を唱えます。著者がある幹部から投げかけられた「詳細はいらない」という一言を起点に、説明を尽くすことと、再発を防ぐことは別だと訴えています。 著者は数か月前、エンジニアリングの担当者とその上司、さらにその上司でもあるSVP of engineeringの三者で呼び出しのような会議に参加しました。何か問題が起きたのですが、致命的ではないものの、SVPが直接出てくる程度には重要だったそうです。著者が経緯を説明しようとすると、そのSVPは「Michael, I don't want the details」と話を止めました。 その言葉に、著者は最初、冷たさや切り捨てを感じます。だがSVPの説明を聞いて考えを改めます。相手は、詳細を聞けば「なぜそうなったのか」は十分に理解できるし、関係者がその時点で合理的に見える判断をしたこともわかってしまう、と言うのです。誰も悪意で動いたわけではなく、状況な

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