Всеки ангажимент на Tzar.Tech завършва с 60 дни припокриване на on-call. И двата екипа — нашият и този на клиента — споделят pager-а. В началото мислехме за това като жест на добра воля. Оказа се най-важната фаза на ангажимента.
Ето защо.
Какво eval suite-ът не хваща
Eval suite-ът хваща това, което сте се сетили да тествате. По дефиниция не хваща това, което не сте.
За повечето агентни системи, доставени в production, първите 60 дни изваждат на повърхността:
- Входове, които никой не е предвидил. Потребител качва PDF от 400 страници на български. Клиент удря endpoint-а с HTML-escape-нати кавички. Интеграция изпраща timestamps в микросекунди.
- Допускания за честота, които са грешни. „Рядък“ път се оказва 8% от трафика. „Чест“ път се оказва 0,1%.
- Tail latency, която eval натоварването не е възпроизвело. p99 изглежда добре при 100 RPS в load tests; при 250 RPS в production, p99.9 spike-ва заради connection pool, който сте оразмерили за грешното разпределение.
- Поведения на цената, които изникват под реални prompts. Реални потребители формулират въпроси по начини, които утрояват prompt token count спрямо вашите синтетични eval prompts.
Те не се появяват в добре проектиран eval suite, защото eval suite-ът е модел на това, което знаете. Първите 60 дни са, когато системата среща реалността.
Какво всъщност прави припокриващото се on-call
Две неща, и двете важни:
1. Напускащият екип все още е свързан, когато нещата се объркат. Когато се появи нов симптом, инженерът, който познава кода, е на повикването. Не в Slack канал на два часови пояса разстояние — реално page-нат, активно гледа. Поправката се ship-ва, вместо да стане ticket.
2. Приемащият екип научава failure modes в собствения си контекст. Те се page-ват. Минават през runbook-а (вижте runbook-а, който идва с всеки агент). Ескалират към нас, когато им трябва. Всеки инцидент става ръководено упражнение по опериране на системата, с оригиналните автори на линията.
До ден 60 приемащият екип е обработил достатъчно инциденти, че знае кое е трудно, кое лесно, кое да игнорира и за кое си струва да page-не изпълнителен директор.
Какво не правим
Не поемаме primary on-call. Ние сме secondary по време на припокриването. Екипът на клиента притежава системата. Нашата роля е „старшият on-call, който може да отговори на ‘нормално ли е това’ и ‘какъв е безопасният път тук’“.
Това има значение: ако държахме primary, екипът на клиента никога нямаше да изгради мускула. Биха ни page-вали първи, всеки път, и на ден 60 все още биха били зависими. Припокриването е учебен прозорец, не услуга.
Какво казват данните
Поддържали сме статистика за това през ангажименти. Формата е последователна:
- Първите две седмици: грубо половината от pages стигат до нас. Повечето са уточнения, не реални инциденти.
- Седмици 3–4: грубо една четвърт стигат до нас. Екипът на клиента е интернализирал чести диагнози.
- Седмици 5–8: под 10% стигат до нас. Тези, които стигат, са истински нови failure modes, заслужаващи промяна в кода.
След 60 дни медианният ангажимент има нас page-вани веднъж на месец през следващото тримесечие и почти никога след това. Системата е тяхна.
Защо 60 дни, не 30
Опитахме 30 веднъж. Не беше достатъчно.
Няколко failure modes се появяват само на границите на месеците (billing cycles, месечни batch jobs, end-of-quarter reporting loads). 30-дневно припокриване може да завърши без никога да ги срещне, оставяйки екипа на клиента сляп за категория проблеми, които ще се случат, в крайна сметка, когато няма старши backup за повикване.
60 дни хваща failures на границата на месеца и дава на приемащия екип цял втори месец да ги обработва сам с нас като backup. Не е симетрично и не е произволно — това е, което сме открили, че е достатъчно за реално прехвърляне на собственост.
Какво струва това и защо го правим
Шестдесет дни secondary on-call е реално инженерно време, което не таксуваме отделно. Заложено е в цената на ангажимента. Някои клиенти не ни вярват, когато казваме, че е задължително — настояваме все пак, и тези, които се опитат да го пропуснат, обикновено ни се обаждат на втория месец, молейки ни да се върнем като консултанти.
Предпочитаме просто да останем 60 дни първия път.