マルチクラスター運用を、個人のPCに閉じ込めない

運用能力が個人のPCに残っていた

顧客チームは、複数のクラスターでアプリケーションサービス、データ同期、インフラストラクチャのワークロードを運用しています。監視、ログ、GitOps、Slackはすでに揃っていました。時間がかかっていたのは、デプロイと障害調査が、各環境に詳しい少数の担当者に依存していたことです。

アプリケーションのリリース、サービスの更新、インフラストラクチャのデプロイ、障害の調査では、まず正しいクラスターとリポジトリを特定し、ローカルのツール、権限、コンテキストを準備する必要がありました。環境に詳しい人なら早く進みます。別の人が担当すると、手順の確認からやり直すことがあります。

自分のPCでCodexを使い、デプロイや調査を進めるエンジニアもいました。個人の作業は速くなりますが、その能力をチームで再利用することはできません。他の開発者は、引き続きその人に依頼する必要がありました。

顧客が必要としていたのは、新しいローカルツールではありません。チームで使えて、権限の境界が明確で、実行過程を追跡できる運用窓口でした。

導入前：デプロイも調査も担当者を待っていた

以前のデプロイ依頼は、まず人同士の引き継ぎから始まりました。開発者が運用担当者を探し、サービス、リビジョン、対象環境を伝えます。運用担当者は自分のローカル環境を開き、リポジトリ、クラスターの状態、デリバリー経路を確認してから作業し、結果をチームに返していました。

障害対応も同じです。アラートはすぐSlackに届きますが、調査は担当者が着手するまで始まりません。Podの状態、サービスの可用性、業務進捗、GitOpsの同期結果を手作業で集め、再起動、ロールバック、設定変更が必要か判断していました。

環境に詳しい少数の担当者が、依頼の理解、操作、結果の説明まで引き受けていました。開発者には共通の窓口がなく、運用知識は個人のPC、コマンド履歴、記憶に分散していました。

コンサルティングは実際の作業から始める

Hastは、汎用Botを先に提供したわけではありません。FDEエンジニアと顧客チームが、実際のデプロイ依頼、アラート、障害調査を整理し、それぞれの作業を一手ずつ分解しました。

まず、何をどの環境へデプロイし、どのGitOpsまたはインフラストラクチャの経路を使うかを明確にします。次に、Agentが使えるツール、対象クラスター、操作範囲、検証基準を定義しました。読み取り専用の調査、事前承認された操作、人の承認が必要な本番変更は分けて扱います。

タスクと権限は同時に設計しました。誰が依頼できるか、Agentがどの環境にアクセスできるか、どのリソースを読み取り禁止にするかを接続時に決めます。デプロイの進捗、アラート調査、承認依頼、検証結果は、元のSlackスレッドに戻ります。

環境知識と本番判断は顧客チームが持ち続けます。HastはAgent設計、ツール接続、権限境界、評価方法を担当しました。コンサルティングで合意した運用手順が、DevOps Agentの繰り返し実行できるルールになりました。

導入後：チーム共通の運用窓口

権限を持つ開発者は、運用担当者のPCを借りたり、自分のローカルにCodex環境を用意したりする必要がありません。SlackからDevOps Agentにデプロイや調査を依頼できます。アラートが届いた場合は、Agentが自動で処理を始めます。

一つの窓口でデプロイとアラートに対応します。Agentが実行するのは権限の範囲内だけで、その境界を超える本番操作は人が判断します。

Agentは対象環境、サービス、変更内容を確認し、チームが定めたデリバリー経路に沿って進めます。実行中もGitOps、ワークロード、サービスの状態を確認し、証拠を元のスレッドに書き戻します。依頼した人は、何が行われているか、どこまで進んだか、変更が実際に反映されたかを確認できます。

この仕組みは、すべての開発者のPCに運用認証情報を配るものではありません。開発者が得るのは、管理されたタスクの入口です。Agentは、専用の制限されたIDとツールを使います。

デプロイをローカル環境から切り離す

アプリケーションのデプロイ、サービスの更新、インフラストラクチャのデプロイは、すべて共有のDevOps Agentから開始できます。開発者が対象環境と変更内容を伝えると、Agentが合意済みの手順を選び、権限の範囲内で実行し、結果を検証します。

検証は「コマンドが成功した」で終わりません。アプリケーションとサービスでは、ロールアウト、ワークロードのReady、サービスルーティング、ヘルスチェックまで確認します。インフラストラクチャでは、GitOpsの同期と対象リソースの状態を確認します。証拠が足りなければ、Agentは完了にしません。

事前承認の範囲を超える場合、Agentは対象、影響、検証方法を先に示し、承認を待ちます。チームが提案を拒否または変更した場合、元の操作を続けることはありません。

開発者にとっての変化は明確です。以前は他の人に依頼するか、自分のPCに一式を用意する必要がありました。現在はチームの権限があれば、同じAgentを使って標準的なデプロイを進め、Slackで結果まで確認できます。

アラートはAgentが自動で引き受ける

デプロイに加えて、OpsgenieのアラートがSlackに届くと、DevOps Agentが直接起動します。エンジニアが先にメンションする必要はありません。Agentはアラートのコンテキストを読み、アクセスを限定した運用ツールを使い、合意済みのルールに沿って調査します。必要なら復旧を待ち、結果を検証し、重複アラートをまとめ、元のスレッドを完了にします。

選定した3つのアラート事例は、どれも人の指示を待ちませんでした。

データ同期アラートでは、上流接続と業務進捗を確認しました。復旧が安定するまで待ち、監視とGitOpsを検証して、約5分で処理を終えました。

アプリケーションのワークロードアラートでは、Secret同期が始めたローリング置換を追跡しました。新しいワークロードはReadyで再起動がなく、二つのヘルスチェックはHTTP 200でした。監視とGitOpsの復旧も確認し、約7分で完了にしました。

高可用性データベースのアラートでは、プライマリの引き継ぎと元インスタンスの復帰を追跡しました。主系と副系の状態、レプリケーション遅延、依存サービス、アラートを、エンジニアの指示を待たずに確認しています。

自動処理が、毎回の本番変更を意味するわけではありません。基盤のコントローラーやHA機構が自動復旧する場合、Agentはその過程を見守り、本当に正常へ戻ったか判断します。事前承認の範囲外にある再起動、ロールバック、設定変更は、人の承認を待ちます。

このページの時間は、選定した事例だけを示しています。SLA、平均応答時間、全体の成功率ではありません。

共有するのは能力で、Secretではない

チームは運用作業の入口を広げましたが、Secretの公開範囲は広げていません。

DevOps Agentは専用のIDを使い、環境、名前空間、操作の種類ごとに権限を限定しています。許可されたデプロイと確認は実行できますが、Kubernetes Secretや開発環境のSecret値は読み取れません。

デプロイに必要な認証情報は、管理されたプラットフォーム境界の内側で使われます。Agentのプロンプト、公開リードバック、Slackの返信には入りません。Agentが見るのは、利用できるツール、機密性のないパラメーター、実行結果であり、基盤の認証情報ではありません。

この境界は、プロンプト上の指示だけではありません。トリガー、AgentのID、インフラストラクチャ権限が、実行可能な操作を一緒に制限します。範囲外の操作は停止するか、人の承認に移ります。

導入前後の違い

最大の変化は、コマンドの数が減ったことではありません。運用能力が、個人のツールからチームのプロセスになったことです。開発者は許可された作業を自分で進められ、運用担当者がすべてのデプロイと調査の中継役になる必要がなくなりました。

運用経験をルールに増やしていく

次に、両チームは頻度の高いデプロイと障害対応を選び、その方法を環境固有のルールにしていきます。各ルールには、明確な入力、権限範囲、検証基準、完了条件が必要です。

固定した評価セットを使い、デプロイが完了しているか、調査結果が信頼できるか、人への引き継ぎが適切か、変更後の検証が十分かを確認します。実際のタスクが、共有された運用プロセスの新しい実地テストになります。