Tzar.Tech のエンゲージメントはすべて、60日間の on-call オーバーラップで終わります。両チーム（我々とクライアント）がページャを共有します。最初は善意のジェスチャーと考えていました。結果として、エンゲージメントで最も重要なフェーズになりました。
理由を説明します。
eval スイートが捕まえないもの
eval スイートは テストしようと考えたもの を捕まえます。定義上、考えなかったものは捕まえません。
本番に出荷されたほとんどのエージェントシステムで、最初の60日は次を表面化させます。
- 誰も予期しなかった入力。 ユーザーがブルガリア語の400ページ PDF をアップロード。顧客が HTML エスケープされたクォートでエンドポイントを叩く。インテグレーションがタイムスタンプをマイクロ秒で送ってくる。
- 間違っていた頻度の仮定。 「稀な」経路がトラフィックの8%だと判明。「よくある」経路が0.1%だと判明。
- eval 負荷では再現しなかったテールレイテンシ。 負荷テストでは 100 RPS で p99 は良好。本番で 250 RPS になると、間違った分布で sizing されたコネクションプールのせいで p99.9 が spike。
- 実プロンプトでのみ現れるコスト挙動。 実ユーザーは、合成 eval プロンプトと比べてプロンプトトークン数を3倍にする言い回しをする。
これらはよく設計された eval スイートには現れません。eval スイートは知っていることのモデルだからです。最初の60日は、システムが現実と出会う期間です。
オーバーラップ on-call が実際に行うこと
2つあり、どちらも重要です。
1. 離脱するチームが、問題発生時にまだ繋がっている。 新しい症状が現れたとき、コードを知るエンジニアがコール中。2タイムゾーン離れた Slack チャネルではなく、実際にページされ、能動的に見ている状態です。修正はチケットではなく出荷されます。
2. 引き継ぐチームが自分のコンテキストで失敗モードを学ぶ。 彼らがページされ、runbook（すべてのエージェントに同梱する runbook を参照）を辿り、必要なら我々にエスカレートします。各インシデントが、システム運用のガイド付き演習になります。原作者がライン上にいる状態で。
60日目までに、引き継ぐチームは何が難しく、何が簡単で、何を無視し、何で経営層をページする価値があるかを知るのに十分なインシデントを処理しています。
我々がしないこと
我々はプライマリ on-call を担いません。オーバーラップ中は セカンダリ です。システムを所有するのはクライアントのチームです。我々の役割は「『これは正常か』『安全な道はどれか』に答えられるシニア on-call」です。
これは重要です。我々がプライマリを握ると、クライアントチームは筋肉を発達させません。毎回まず我々にページし、60日目になっても依存したままです。オーバーラップはサービスではなく教育のウィンドウです。
データが語ること
エンゲージメントを横断してこの統計を取り続けています。形は一貫しています。
- 最初の2週間: ページのおよそ半数が我々に届きます。ほとんどは実インシデントではなく明確化です。
- 3〜4週目: およそ4分の1が届きます。クライアントチームが一般的な診断を内面化しています。
- 5〜8週目: 10%未満が届きます。届くものは、コード変更に値する真に新しい失敗モードです。
60日後、中央値のエンゲージメントでは、次の四半期は月1回我々がページされ、その後はほぼゼロになります。システムは彼らのものです。
なぜ30日ではなく60日なのか
一度30日で試しました。十分ではありませんでした。
いくつかの失敗モードは月境界でしか現れません（billing サイクル、月次バッチジョブ、四半期末レポート負荷）。30日のオーバーラップはそれらに一度も遭遇せずに完了でき、クライアントチームを、いつかは必ず 起きる問題カテゴリに対して、頼れるシニアバックアップなしの状態のまま盲目にします。
60日は月境界の失敗を捕まえ、引き継ぐチームに、我々をバックアップとして単独で対処できる2ヶ月目をまるごと与えます。対称ではないし恣意でもありません。所有権を真に移管するのに十分だと我々が見出した期間です。
このコストと、なぜそれをやるか
60日のセカンダリ on-call は、別請求しない実エンジニアリング時間です。エンゲージメント価格に織り込んでいます。必須だと言ったとき信じないクライアントもいます。それでも我々は主張します。スキップしようとしたクライアントはたいてい2ヶ月目に連絡してきて、コンサルタントとして戻ってきてほしいと言います。
最初から60日間滞在する方がましです。