otp-blue · сендери iMessage · 13 лип — 9 вер 2026

Чи частіше в Need Check ідуть сендери з коротким cooldown?

A/B за наявними даними: у групі — cooldown фіксований 10–90 хв на всіх рівнях, проти без групи — стандартна драбина 1–2 год → 1–2 год → 12–14 год → 12–14 год → Need Check.

популяція: сендери з ≥1 клієнтським повідомленнямосновне вікно: 10 серп — 9 вер (30 днів)джерела: Message, ServerStatusHistory, Group

Ні, навпаки. На одиницю активного часу сендери з коротким cooldown потрапляють у Need Check приблизно вдвічі рідше: 1,24 проти 2,95 подій на 100 сендер-днів у чистому зрізі (es+zp, без preheat), 1,23 проти 1,85 у порівнянні всередині одних і тих самих хостів.

Але вони швидше повертаються туди після ручного відновлення. Після фіксу лічильників 29 серпня 43 % відновлених «групових» сендерів знову були в Need Check за добу, проти 12 % «без групи». Це не гірша якість номера, а арифметика драбини: 5 коротких cooldown уміщуються в ~10 годин, 5 довгих — не менше ніж у 28.

Ціна короткого cooldown — доставка. На тих самих хостах групові сендери відправляють на 8 % більше повідомлень за день, але відсоток відмов вищий на 0,5–0,9 п.п. у 25 з 39 хостів, а подій «Send failed 📉» на 1000 відправок — на 37 % більше. Короткий cooldown повертає пристрій у ротацію раніше, ніж він перестав фейлити.

Метрика, 30 днів	у групі	без групи	Δ
Весь пул, що відправляв: 207 проти 886 сендерів
Медіанний cooldown	23 хв	93 хв	×0,25
Cooldown-ів на 100 сендер-днів	327	166	×2,0
Need Check на 100 сендер-днів	5,0	10,2	×0,49
Частка сендерів із ≥1 Need Check	43,5 %	52,8 %	−9,3 п.п.
Відмови (120+125) серед фінальних статусів	12,5 %	12,0 %	+0,5 п.п.
Чистий зріз: es + zp, без preheat: 131 проти 159 сендерів
Need Check на 100 сендер-днів	1,24	2,95	×0,42
Частка сендерів із ≥1 Need Check	26,0 %	41,5 %	−15,5 п.п.
Відправок на сендер-день	79,0	73,2	+8 %
Відмови серед фінальних статусів	12,2 %	11,7 %	+0,5 п.п.
«Send failed 📉» на 1000 відправок	90	66	+37 %
Усередині 39 хостів, де є обидві групи: 92 проти 85 сендерів
Need Check на 100 сендер-днів	1,23	1,85	×0,66
Відмови серед фінальних статусів	12,0 %	11,2 %	+0,7 п.п.
Відправок на сендер-день	80,9	74,6	+8 %

Δ = група відносно «без групи». Сендер-день — день, у який сендер відправив хоча б одне клієнтське повідомлення. Відмови: фінальний статус failed з кодом 120 (not delivered) або 125 (service error); фінальний сервер після retry.

Що саме порівнюємо

Групи в проді відрізняються від дефолту лише тривалістю cooldown. Інтервал відправки в усіх п’яти заповнених групах 8–12 хв — такий же, як дефолт для будь-якого регіону. Поріг failed_in_row усюди 2. Отже це чистий тест одного параметра, але з неслучайним розподілом: у групах старий флот (усі 244 створені до червня), es/zp/vj/pt; поза групами — ще й нові ua/us і весь preheat-пул.

без групиcooldown #1 і #2: 60–120 хв; #3 і #4: 720–840 хв; на #5 замість cooldown — Need Check. у групітой самий лічильник, але кожен cooldown = випадкове число з діапазону групи (10–30, 15–25, 15–45 або 30–90 хв). Драбина є, сходинок немає. скиданнялічильник обнуляється, якщо за останні 14 годин доставлено ≥11 (у preheat — ≥2). Перевіряється на кожному вебхуці про фейл. другий шлях у NC3 підряд виходи з cooldown без підтвердженого warm-up (fail-open streak). Cooldown коротший за 30 хв не вміщує warm-up і на streak не впливає.

Need Check на одиницю активного часу

Ефект тримається в кожному зрізі, який прибирає різницю в складі: регіон, preheat, обсяг, і навіть один і той самий фізичний хост. Єдиний виняток — preheat-сендери, де у групі гірше, і його майже повністю робить один ua-хост (нижче).

Need Check від планувальника на 100 сендер-днів, 30 днів

у групібез групи

Чому: групові сендери не піднімаються по драбині

Розподіл усіх cooldown за номером (#N у нотатці «cooldown #N until …»), 30 днів. 12 815 проти 17 606 подій.

93,5 % групових cooldown — це #1: після 20-хвилинної паузи сендер повертається, доставляє 11 повідомлень за пару годин і лічильник скидається. Без групи 29 % cooldown ідуть на рівнях #2–#5: після 12–14-годинної паузи вікно «14 годин» порожнє, скидання неможливе, і кожен наступний фейл-стрік веде до Need Check майже гарантовано. Зараз у проді 137 із 456 активних сендерів без групи стоять на cooldown_times = 4, у групах — 3 із 117.

Від cooldown #1 до Need Check по драбині

медіана, години · 30 днів

у групі10,3 год — 8 cooldown за попередню добубез групи35,8 год — 1 cooldown за попередню добу

Повернення в Need Check після ручного відновлення

відновлення з 29 серп, коли admin-action почав скидати лічильники

у групі28 із 65 за добу (43 %) · медіана 16 годбез групи78 із 658 за добу (12 %) · медіана 34 год

Це та сама монета з іншого боку. Якщо номер справді поганий, групова драбина доводить його до Need Check за півдня, а стандартна — за півтори доби. До 29 серпня, коли відновлення не скидало лічильники, обидві групи «бумерангали» однаково швидко: медіана 10,6 год проти 4,4 год.

Хто саме повертається

Навантаження на Need Check у групах концентроване: 10 % сендерів дають 49 % подій (без групи — 40 %). Сендерів із ≥4 Need Check за 30 днів у групах 14, без групи 93. Восьмеро з цих 14 — один кластер: ua-хости 458 і 460, юніти 228–243, усі в preheat. Юніт 243 за місяць 13 разів пройшов Need Check → відновлення → Need Check.

Юніт	Хост	Група	Відправок	Відмови	NC за 30 дн	Відновлень
243	460	Short #2	718	21,7 %	13	13
237	460	Shortest #2	316	27,2 %	8	7
235	458	Short #2	1 460	12,7 %	7	8
240	460	Shortest #2	1 351	17,5 %	6	7
239	460	Shortest #2	1 343	17,9 %	5	5

Саме цей кластер, імовірно, і створює відчуття «групові частіше повертаються». Для нього коротка драбина працює як належить — сендер із 20–27 % відмов справді не мав би бути в ротації — але ручне відновлення без зміни причини повертає його на те саме коло за години.

Доставка: чи лікує короткий cooldown

Перше повідомлення після виходу з cooldown фейлить однаково після 20 хвилин і після години. Різниця з’являється тільки на рівні 12–14 годин, і це не ефект тривалості: туди доходять сендери, які вже вмирають. Через 90 хвилин після виходу відсоток відмов для 20-хвилинних і 2-годинних cooldown ідентичний — близько 20 %, тобто вищий за фоновий 12 %. Пауза не міняє стан пристрою, вона лишень визначає, скільки клієнтських повідомлень він зіпсує, поки в ньому перебуває.

Відмови після виходу з cooldown за планованою тривалістю

es + zp, без preheat, з 1 серп · перше клієнтське повідомлення після виходу і всі повідомлення за 90 хв

перше повідомленняперші 90 хвилин

На рівні #1 драбини групові сендери навіть виглядають краще (перше повідомлення фейлить у 21 % проти 30 %), бо серед «без групи» 1–2-годинний cooldown частіше закінчується на пристрої, що вже втратив реєстрацію. На рівнях #2+ обидві групи погані: 47–56 % проти 80–82 %.

Динаміка по тижнях

зліва: Need Check від планувальника на 100 активних сендерів тижня · справа: відмови серед фінальних статусів. Останній тиждень — 3 дні.

у групібез групи

Need Check у групах нижчий майже щотижня; відмови в липні були гіршими в групах на 3–4 п.п., у серпні зрівнялися, з 31 серпня знову розійшлися. Тиждень 31 серп — 6 вер спотворений масовим бут-іном 3 вересня та хвилею es-банів, які вдарили по обох групах.

Групи між собою

Усередині груп різниця в тривалості 10–30 проти 30–90 хв майже нічого не міняє. «Medium 30–90» має найнижчі відмови (11,0 %) і найменше cooldown-ів, «Shortest #2 15–25» — найменше Need Check, але це 24 і 54 сендери, і склад груп теж не випадковий.

Група (cooldown, хв)	Сендерів	Відправок	На день	Відмови	Cooldown / 100 дн	NC / 100 дн	Із ≥1 NC
Shortest 10–30	43	55 873	67,5	12,5 %	326	4,8	44 %
Shortest #2 15–25	54	74 923	70,7	13,1 %	377	3,3	30 %
Short 15–45	31	32 223	58,2	13,1 %	343	6,5	55 %
Short #2 15–45	55	70 644	69,1	12,3 %	311	6,2	45 %
Medium 30–90	24	30 707	67,2	11,0 %	226	5,0	54 %
без групи (драбина)	886	418 682	39,6	12,0 %	166	10,2	53 %

30 днів. Групи 1, 4, 6, 7 порожні. Server.groups — many-to-many, але жоден сендер не стоїть у двох групах, тож priority нічого не вирішує.

Що можна і що не можна порівнювати в цьому A/B

Коректна одиниця — сендер-день або відправка, не сендер. Групові сендери майже вдвічі частіше «в роботі», і сирі лічильники Need Check на сендер їх карають. Частка сендерів із ≥1 NC теж придатна, але тільки для однакових вікон спостереження.
Need Check із коротким cooldown вимірює інше, ніж із довгим. У групі це «8 fail-стріків за добу без 11 доставок між ними»; без групи це «двічі провалитись після 12-годинної паузи». Порівнювати їх кількісно можна, але заголовок метрики має бути «частота flag-подій», а не «частота поганих номерів».
Відмови на рівні Message заниженi для обох груп. Retry переносить повідомлення на інший сервер, і фейл першого сервера зникає з Message. Для оцінки шкоди від коротких cooldown потрібен per-server маркер «Send failed 📉» (є з 26 серп): там різниця +37 %, а не +0,5 п.п.
Склад груп не випадковий. Тому головний доказ — 39 хостів з обома групами: однакове залізо, IP, батч. Він підтверджує напрямок обох ефектів, але меншу величину (NC ×0,66 замість ×0,42).
Окремо треба дивитись preheat. Там у групі Need Check вищий (18,5 проти 13,6 на 100 днів) через ua-кластер юнітів 228–243 і тому, що в preheat скидання лічильника потребує лишень 2 доставок, тобто драбина взагалі не стримує.
Період впливає на все. До 26–29 серпня відновлення не скидало лічильники, warm-up-гейт і fail-open streak з’явились 31 лип, 📉 — 26 серп. Місяць 10 серп — 9 вер — найчистіший, і його тут використано як основний.

Що з цього випливає

Коротка драбина не робить номери гіршими, і Need Check із неї — швидкий і чесний сигнал про справді поганий сендер. Стандартна ж драбина після рівня #3 веде в Need Check структурно: 14-годинне вікно скидання несумісне з 12–14-годинним cooldown. Якщо мета — менше хибних Need Check без групи, скидання варто прив’язувати до доставок після виходу з cooldown, а не до календарних 14 годин.
Ціна — приблизно на третину більше клієнтських фейлів на 1000 відправок за +8 % обсягу. Чи це прийнятно, залежить від того, що дорожче: недоставлений OTP чи простій сендера.
Для справжнього A/B потрібно розкласти нові сендери в групу випадково всередині хоста, вести один preregistered показник (📉 на 1000 відправок) і один операційний (NC на 100 сендер-днів), і не відновлювати вручну без скидання причини. За поточної кількості подій (десятки NC на місяць у чистому зрізі) значущу різницю можна побачити за 3–4 тижні.

Дані: prod, read-only, знімок 9 вер 2026 ~11:00 UTC. Історія статусів надійна з 13 лип 2026 (v1). Скрипти аналізу в сесійному scratchpad: analyze.py, analyze2.py, analyze3.py, analyze4.py.