Her Tzar.Tech engagement'ı, 60 günlük overlap on-call ile sona erer. Her iki ekip — bizimki ve müşterinin — pager'ı paylaşır. Başlarda bunu iyi niyet jesti olarak düşünmüştük. Engagement'ın en önemli aşaması olduğu ortaya çıktı.
İşte neden.
Eval suite'in yakalamadığı
Eval suite, test etmeyi düşündüğünüz şeyi yakalar. Tanım gereği, düşünmediğinizi yakalamaz.
Production'a sevk edilen çoğu agentic sistem için ilk 60 gün şunları su yüzüne çıkarır:
- Kimsenin öngörmediği input'lar. Bir kullanıcı Bulgarca 400 sayfalık bir PDF yükler. Bir müşteri HTML-escape edilmiş tırnaklarla endpoint'e gelir. Bir entegrasyon timestamp'leri mikrosaniye olarak gönderir.
- Yanlış olan frekans varsayımları. "Nadir" bir yolun trafiğin %8'i olduğu ortaya çıkar. "Yaygın" bir yolun %0,1'i olduğu ortaya çıkar.
- Eval yükünün yeniden üretmediği tail latency. Load test'lerde 100 RPS'de p99 iyi görünüyor; production'da 250 RPS'de, yanlış dağılım için boyutlandırdığınız bir connection pool nedeniyle p99.9 spike yapar.
- Gerçek prompt'lar altında ortaya çıkan maliyet davranışları. Gerçek kullanıcılar soruları, sentetik eval prompt'larınıza kıyasla prompt token sayısını üçe katlayan şekillerde ifade eder.
Bunlar iyi tasarlanmış hiçbir eval suite'inde görünmez, çünkü eval suite bildiğinizin bir modelidir. İlk 60 gün, sistemin gerçeklikle buluştuğu zamandır.
Overlap on-call aslında ne yapar
İki şey, ikisi de önemli:
1. İşler ters gittiğinde ayrılan ekip hâlâ bağlı. Yeni semptom ortaya çıktığında, kodu bilen mühendis call'da. İki timezone uzaktaki bir Slack kanalında değil — gerçekten page atılmış, aktif olarak bakıyor. Düzeltme ticket'a dönüşmek yerine sevk edilir.
2. Alıcı ekip hata modlarını kendi context'lerinde öğrenir. Page alırlar. Runbook'tan geçerler (her ajanla birlikte gelen runbook'a bakın). İhtiyaç duyduklarında bize eskale ederler. Her olay, orijinal yazarlar telefonun ucunda, sistemi işletme konusunda rehberli bir egzersiz haline gelir.
- güne kadar, alıcı ekip yeterli olay yönetti ve neyin zor, neyin kolay olduğunu, neyi görmezden geleceklerini ve neyin bir yöneticiye page atmaya değer olduğunu bilir.
Yapmadığımız
Primary on-call yürütmüyoruz. Overlap sırasında secondary'iz. Müşterinin ekibi sisteme sahip. Rolümüz, "'bu normal mi' ve 'buradaki güvenli yol nedir' sorularına cevap verebilen kıdemli on-call."
Bu önemli: primary biz tutsaydık, müşterinin ekibi kasları asla geliştirmezdi. Her seferinde önce bize page atarlardı ve 60. günde hâlâ bağımlı olurlardı. Overlap bir öğretme penceresidir, bir hizmet değil.
Veri ne diyor
Bunu engagement'lar boyunca istatistik tuttuk. Şekil tutarlı:
- İlk iki hafta: page'lerin yaklaşık yarısı bize ulaşıyor. Çoğu açıklama, gerçek olay değil.
- 3.–4. haftalar: yaklaşık dörtte biri bize ulaşıyor. Müşterinin ekibi yaygın teşhisleri içselleştirdi.
- 5.–8. haftalar: %10'un altı bize ulaşıyor. Ulaşanlar gerçekten yeni hata modları, bir kod değişikliğine değer.
60 günden sonra, medyan engagement bizi sonraki üç ay için ayda bir page eder ve bundan sonra neredeyse hiç. Sistem onların.
Neden 60 gün, 30 değil
Bir kez 30 denedik. Yeterli değildi.
Birkaç hata modu sadece ay sınırlarında ortaya çıkar (faturalama döngüleri, aylık batch işler, çeyrek sonu raporlama yükleri). 30 günlük bir overlap, bunlarla hiç karşılaşmadan tamamlanabilir ve müşterinin ekibini, çağrılacak kıdemli bir backup yokken eninde sonunda gerçekleşecek bir kategori soruna karşı kör bırakır.
60 gün, ay sınırı hatalarını yakalar ve alıcı ekibe, biz backup olarak, bunları tek başlarına ele almak için tam bir ikinci ay verir. Simetrik değil ve keyfi de değil — sahipliği gerçekten transfer etmek için yeterli bulduğumuz şey.
Bunun maliyeti ve neden yapıyoruz
Altmış gün secondary on-call, ayrıca faturalandırmadığımız gerçek mühendislik zamanıdır. Engagement'a fiyatlandırırız. Bazı müşteriler zorunlu olduğunu söylediğimizde bize inanmıyor — yine de ısrar ediyoruz ve atlama girişiminde bulunanlar genellikle ikinci ayda bizi danışman olarak geri çağırmak için arıyor.
İlk seferde 60 gün kalmayı tercih ederiz.