Jedes Tzar.Tech-Engagement endet mit 60 Tagen Überlapp-on-call. Beide Teams — unseres und das des Kunden — teilen sich den Pager. Wir hielten das anfangs für eine Goodwill-Geste. Es stellte sich als die wichtigste Phase des Engagements heraus.
Hier ist warum.
Was die Eval-Suite nicht abfängt
Die Eval-Suite fängt, woran Sie gedacht haben zu testen. Per Definition fängt sie nicht, woran Sie nicht gedacht haben.
Bei den meisten agentischen Systemen, die in Produktion ausgeliefert werden, decken die ersten 60 Tage auf:
- Inputs, die niemand antizipiert hat. Ein Nutzer lädt eine 400-seitige PDF auf Bulgarisch hoch. Ein Kunde trifft den Endpoint mit HTML-escaped Quotes. Eine Integration sendet Timestamps in Mikrosekunden.
- Häufigkeitsannahmen, die falsch waren. Ein „seltener" Pfad stellt sich als 8% des Traffics heraus. Ein „häufiger" Pfad stellt sich als 0,1% heraus.
- Tail-Latenz, die die Eval-Last nicht reproduziert hat. p99 sieht bei 100 RPS in Load-Tests gut aus; bei 250 RPS in Produktion springt p99.9 wegen eines Connection-Pools, den Sie für die falsche Verteilung dimensioniert haben.
- Kostenverhalten, das unter echten Prompts entsteht. Echte Nutzer formulieren Fragen so, dass die Prompt-Token-Anzahl gegenüber Ihren synthetischen Eval-Prompts verdreifacht wird.
Diese zeigen sich in keiner gut entworfenen Eval-Suite, weil die Eval-Suite ein Modell dessen ist, was Sie wissen. Die ersten 60 Tage sind, wenn das System der Realität begegnet.
Was Überlapp-on-call tatsächlich tut
Zwei Dinge, beide wichtig:
1. Das gehende Team ist noch verdrahtet, wenn Dinge schiefgehen. Wenn das neue Symptom auftaucht, ist der Engineer, der den Code kennt, am Apparat. Nicht in einem Slack-Channel zwei Zeitzonen entfernt — tatsächlich gepaged, aktiv schauend. Der Fix wird ausgeliefert, statt zu einem Ticket zu werden.
2. Das empfangende Team lernt die Failure-Modes im eigenen Kontext. Sie werden gepaged. Sie gehen durch das runbook (siehe das runbook, das mit jedem Agenten ausgeliefert wird). Sie eskalieren zu uns, wenn sie es brauchen. Jedes Incident wird zu einer geführten Übung im Betrieb des Systems, mit den Originalautoren in der Leitung.
Bis Tag 60 hat das empfangende Team genug Incidents gehandhabt, dass es weiß, was schwer ist, was leicht ist, was zu ignorieren ist und worüber man einen Executive pagen sollte.
Was wir nicht tun
Wir laufen nicht primärer on-call. Wir sind der Sekundär während des Überlapps. Das Team des Kunden besitzt das System. Unsere Rolle ist „der Senior-on-call, der ‚ist das normal' und ‚was ist der sichere Pfad hier' beantworten kann."
Das ist wichtig: Hielten wir primär, würde das Team des Kunden den Muskel nie entwickeln. Sie würden uns jedes Mal zuerst pagen, und an Tag 60 wären sie immer noch abhängig. Der Überlapp ist ein Lehrfenster, kein Service.
Was die Daten sagen
Wir haben Statistiken darüber über Engagements geführt. Die Form ist konsistent:
- Erste zwei Wochen: etwa die Hälfte der Pages erreicht uns. Die meisten sind Klärungen, keine echten Incidents.
- Wochen 3–4: etwa ein Viertel erreicht uns. Das Team des Kunden hat häufige Diagnosen verinnerlicht.
- Wochen 5–8: unter 10% erreichen uns. Die, die es tun, sind echte neue Failure-Modes, die eine Code-Änderung wert sind.
Nach 60 Tagen wird das Median-Engagement von uns einmal pro Monat für das nächste Quartal gepaged, und fast nie danach. Das System gehört ihnen.
Warum 60 Tage, nicht 30
Wir haben einmal 30 versucht. Es war nicht genug.
Mehrere Failure-Modes zeigen sich nur an Monatsgrenzen (Abrechnungszyklen, monatliche Batch-Jobs, Quartalsende-Reporting-Lasten). Ein 30-Tage-Überlapp kann abgeschlossen werden, ohne ihnen je zu begegnen, sodass das Team des Kunden blind bleibt gegenüber einer Kategorie von Issues, die werden passieren, irgendwann, wenn kein Senior-Backup mehr da ist, das man anrufen kann.
60 Tage fangen die Monatsgrenz-Fehler ab und geben dem empfangenden Team einen vollen zweiten Monat, um sie alleine zu handhaben — mit uns als Backup. Es ist nicht symmetrisch und es ist nicht willkürlich — es ist, was wir als ausreichend gefunden haben, um Ownership echt zu übertragen.
Was das kostet und warum wir es tun
Sechzig Tage Sekundär-on-call sind echte Engineering-Zeit, die wir nicht separat berechnen. Wir preisen sie in das Engagement ein. Manche Kunden glauben uns nicht, wenn wir sagen, es sei verpflichtend — wir bestehen trotzdem darauf, und die, die versuchen, es zu überspringen, rufen uns meist im zweiten Monat zurück und bitten uns, als Consultant wiederzukommen.
Da bleiben wir lieber das erste Mal 60 Tage.