Сравнение языковых моделей — бенчмарк

Ты — система маршрутизации обращений в контакт-центр крупного российского банка. Проанализируй входящее сообщение клиента и определи ВСЕ применимые intent-метки из закрытого списка. Сообщение может содержать несколько намерений одновременно — нужно вернуть multi-label разметку. ЗАКРЫТЫЙ СПИСОК ИНТЕНТОВ (выбирать только из них): 1. card_block — блокировка/перевыпуск карты 2. card_limits — изменение лимитов по карте 3. transfer_dispute — оспаривание операции/чарджбэк 4. credit_application — заявка на кредит/ипотеку/рассрочку 5. credit_restructure — реструктуризация/каникулы по действующему кредиту 6. deposit_open — открытие вклада/накопительного счёта 7. deposit_close — досрочное закрытие вклада 8. mobile_app_issue — технические проблемы с мобильным приложением/интернет-банком 9. fraud_report — сообщение о мошенничестве/фишинге 10. account_statement — запрос выписки/справки о доходах/для визы 11. tariff_change — смена тарифного плана/пакета услуг 12. complaint_service — жалоба на качество обслуживания 13. branch_appointment — запись в отделение 14. fx_operation — валютные операции/обмен валют 15. other — не относится ни к одной категории ВХОДЯЩЕЕ СООБЩЕНИЕ КЛИЕНТА (чат в приложении, 17:42): "Здравствуйте! Помогите, пожалуйста, ситуация очень неприятная. Сегодня в 14:20 пришла смска о покупке на 47 890 рублей в каком-то магазине 'TechZone Online', я ничего такого не покупал, был на работе. Карту срочно заблокируйте, дебетовую Mir Supreme **4477. И операцию эту хочу оспорить, мне ничего не приходило, никаких кодов подтверждения. Кстати, я уже три дня не могу войти в приложение — пишет 'ошибка сессии 0x80042', переустанавливал, не помогает. Скиньте, пожалуйста, ещё справку 2-НДФЛ за прошлый год — нужна для подачи на ипотеку, кстати, заодно хотел бы рассчитать ипотеку на 8 миллионов на квартиру в Подмосковье, дайте знать какие сейчас ставки и что нужно из документов. И вот ещё — мою жалобу на оператора Марию из отделения на Тверской от 12 марта вы вообще рассмотрели? Прошло полтора месяца, никто не перезванивает, это просто безобразие. Жду оперативного ответа." ФОРМАТ ОТВЕТА (строго JSON): { "intents": ["intent_1", "intent_2", ...], "primary_intent": "intent_name", "urgency": "low|medium|high|critical", "justification": "<краткое обоснование, 2-3 предложения>" } primary_intent — то, что требует немедленной реакции. urgency — общая срочность кейса.

Ты — аналитик контакт-центра страховой компании 'РосГарант'. Тебе поступило письменное обращение клиента после ДТП. Нужно классифицировать обращение по нескольким осям одновременно: вид страхования, тип запроса, эмоциональное состояние клиента, риск эскалации. ТЕКСТ ОБРАЩЕНИЯ (форма обратной связи на сайте, дата 14.05.2026, 23:47): "Уважаемая компания РосГарант, пишу вам в час ночи потому что не могу спать от того что у нас происходит. 28 апреля у нас случилось ДТП — в нашу Kia Sportage (полис КАСКО № КС-7782341, оформлен в вашем офисе на Ленинградском проспекте 12 января 2025 года) въехал грузовик ГАЗель, виновник установлен ГИБДД, протокол № 50АА123456. Машина практически не на ходу — повреждены капот, обе передние двери, бампер, радиатор, есть подозрение на деформацию лонжерона. Прошло 17 ДНЕЙ. СЕМНАДЦАТЬ. За это время: - Я три раза приезжал к вам в офис (потратил отгулы на работе) - Семь раз звонил вашему 'персональному менеджеру' Алексею Воронину — он либо не берёт трубку, либо обещает 'перезвонить через час' и пропадает - Машина стоит у дилера, мне выставили счёт за хранение 1 400 руб/сутки = уже 23 800 руб только за стоянку! - Я не могу ездить на работу, трачу 800 руб/день на такси (мне ещё и за это компенсация положена по программе 'Премиум Сервис', за которую я доплатил 18 тысяч при оформлении) - Эксперт от вас приезжал только один раз, 5 мая, с тех пор тишина Я плачу вам уже три года, страховая премия 87 000 рублей в год, ни разу не было задержек с моей стороны. А когда мне нужна помощь — никто пальцем не пошевелит. У меня жена беременна, ей нужно ездить к врачу, ребёнок в садик — всё это легло на мои плечи и кошелёк. Если до 18 мая ситуация не сдвинется с мёртвой точки — я подаю жалобу в ЦБ РФ, в Роспотребнадзор, и иду в суд с требованием неустойки по ст. 28 ЗоЗПП плюс компенсации морального вреда. У меня юрист уже готовит документы. Также я планирую опубликовать всю историю с приложением переписки в Тинькофф-Журнале и на Banki.ru — пусть люди знают, как вы 'заботитесь' о клиентах. Жду ОФИЦИАЛЬНОГО ответа в течение 48 часов с конкретными сроками выплаты или направления на ремонт." ВЕРНИ СТРОГО JSON: { "insurance_type": "<KASKO|OSAGO|life|health|property|travel|other>", "request_type": "<claim_status|claim_filing|complaint|payout_dispute|information_request|policy_change|cancellation>", "emotional_state": "<calm|frustrated|angry|desperate|threatening>", "escalation_risk": "<low|medium|high|critical>", "vip_indicators": ["<premium_product|multi_year_client|high_premium|family_situation|legal_threat|media_threat|regulator_threat>"], "recommended_priority": "<P0|P1|P2|P3>", "required_actions": ["<краткие пункты для кейс-менеджера>"] }

Ты — система автоматического импорта инвойсов в учётную систему 1С российской торговой компании. Извлеки структурированные поля из текста счёта-фактуры. Если поле отсутствует — верни null. Все суммы — в рублях. Даты — в формате YYYY-MM-DD. ТЕКСТ ИНВОЙСА (отсканирован и распознан, могут быть мелкие OCR-артефакты): СЧЁТ № 2026/04-1147 от 28 апреля 2026 г. к Договору поставки № ДП-23/2024 от 15.03.2024 Поставщик: ООО "ТехноСтройКомплект" ИНН 7727456789 КПП 772701001 ОГРН 1187746234567 Юр. адрес: 117218, г. Москва, ул. Кржижановского, д. 14, корп. 3, оф. 412 р/с 40702810400000123456 в АО "Альфа-Банк", БИК 044525593, к/с 30101810200000000593 Покупатель: ООО "СибПромРесурс" ИНН 5404012345 КПП 540401001 Адрес: 630099, г. Новосибирск, ул. Ленина, д. 21 Грузополучатель: тот же Адрес доставки: 630032, г. Новосибирск, Толмачёвское ш., 19А, склад №7 +----+--------------------------------+--------+------+----------+------------+ | № | Наименование | Ед. | Кол. | Цена | Сумма | +----+--------------------------------+--------+------+----------+------------+ | 1 | Кабель ВВГнг-LS 3х2,5 (м) | м.п. | 1500 | 87,50 | 131 250,00 | | 2 | Автомат ABB SH203L C16 | шт. | 240 | 412,00 | 98 880,00 | | 3 | Щит ЩРН-24 IP31 IEK | шт. | 12 | 2 850,00 | 34 200,00 | | 4 | УЗО ABB FH202 AC-25/0,03 | шт. | 60 | 1 970,00 | 118 200,00 | | 5 | Гофра ПВХ d20 (бухта 50м) | бухт. | 30 | 540,00 | 16 200,00 | +----+--------------------------------+--------+------+----------+------------+ ИТОГО без НДС: 398 730,00 НДС 20%: 79 746,00 ВСЕГО к оплате: 478 476,00 Срок оплаты: до 12 мая 2026 г. (14 календарных дней с даты выставления) Условия поставки: FCA склад Поставщика, Москва. Срок отгрузки — в течение 5 рабочих дней с момента поступления 100% предоплаты. В случае просрочки оплаты — пени 0,1% за каждый день, но не более 10% от суммы счёта. Подписано: Генеральный директор Сидоренко А.В. Главный бухгалтер: Никитина О.П. ВЕРНИ JSON: { "invoice_number": "<string>", "invoice_date": "YYYY-MM-DD", "contract_reference": {"number": "<string|null>", "date": "YYYY-MM-DD|null"}, "supplier": {"name": "<string>", "inn": "<string>", "kpp": "<string|null>", "bank_account": "<string|null>", "bik": "<string|null>"}, "buyer": {"name": "<string>", "inn": "<string>", "kpp": "<string|null>"}, "delivery_address": "<string|null>", "line_items": [{"position": <int>, "name": "<string>", "unit": "<string>", "quantity": <number>, "unit_price": <number>, "total": <number>}], "subtotal_no_vat": <number>, "vat_rate": <number>, "vat_amount": <number>, "total_amount": <number>, "payment_due_date": "YYYY-MM-DD", "payment_terms_days": <int>, "penalty_rate_per_day": <number>, "delivery_terms": "<string|null>" }

Ты — система анализа отзывов на маркетплейсе для производителя бытовой техники. Проанализируй отзыв покупателя на робот-пылесос и верни структурированный анализ: общий сентимент, оценку, затронутые аспекты с подсентиментом по каждому, обнаруженные баги, и рекомендуемый ответ от support-команды. ОТЗЫВ (Ozon, 13 мая 2026, оценка покупателя: 3 из 5): "Долго думала, ставить три звезды или две. Поставила три, потому что пылесос всё-таки работает и в общем-то справляется с шерстью котов (у меня два мейн-куна), а это раньше было проблемой — обычный пылесос замучаешься гонять. По существу: ПЛЮСЫ: + Уборка действительно качественная, особенно на ламинате. Шерсть собирает идеально, пыль не оставляет. + Тихий — могу включать ночью, муж не просыпается (по сравнению с предыдущим Roborock — небо и земля, тот ревел как самолёт). + Симпатичный, белый с золотым ободком, вписался в интерьер. + Доставка от Ozon молниеносная, заказала во вторник — в среду уже была дома. МИНУСЫ И ОЧЕНЬ СУЩЕСТВЕННЫЕ: - ПРИЛОЖЕНИЕ. Это просто катастрофа. Постоянно вылетает на моём iPhone 14 Pro (iOS 17.4), карта дома строится через раз, расписание сбрасывается само по себе, push-уведомления не приходят (хотя в настройках всё включено). Я три раза переустанавливала — без толку. Пишу в их техподдержку — отвечают шаблонами 'попробуйте перезагрузить роутер'. Серьёзно? У меня wi-fi 6, 300 мбит, и проблема явно не в нём. - ВРЁТ про время уборки. Заявлено 'до 180 минут на одном заряде', по факту садится за 95-110 минут (квартира 78 кв.м., режим 'средняя мощность'). Это меньше двух третей от обещанного! - Застревает под диваном (зазор 9.5 см, паспортная высота пылесоса 9.4 см — теоретически должен проходить, на практике — заклинивает раз в два дня). - Контейнер мелкий, приходится вычищать после каждой уборки. Заявлено 0.6 л, по ощущениям меньше. - Цена 47 990 рублей — за такое качество ПО и такие фактические характеристики я ожидала большего. Конкуренты за те же деньги дают лучше. ИТОГ: железо неплохое, программное обеспечение и маркетинговые обещания — провал. Если вы выпустите нормальное обновление прошивки/приложения — повышу до 4 звёзд. Пока — три, и то с натяжкой." ВЕРНИ JSON: { "overall_sentiment": "<positive|mixed|negative>", "rating_predicted": <1-5>, "aspects": [{"aspect": "<cleaning_quality|noise_level|design|delivery|mobile_app|battery_life|navigation|dustbin_capacity|price|support|warranty>", "sentiment": "<positive|neutral|negative>", "quote": "<краткая цитата>"}], "detected_issues": [{"category": "<software_bug|false_advertising|hardware_issue|support_quality|design_flaw>", "description": "<кратко>", "severity": "<low|medium|high>"}], "churn_risk": "<low|medium|high>", "recommended_action": "<single string>" }

Ты — HR-аналитик в крупной IT-компании (3000+ сотрудников). К тебе поступило обращение от сотрудника через внутренний портал 'HR-помощь'. Нужно классифицировать ситуацию по юридическим и процедурным осям, оценить риски, определить эскалационный путь. ОБРАЩЕНИЕ (через корпоративный портал, 09:14, понедельник): Тема: 'Несогласие с увольнением и нарушения при процедуре' "Добрый день, HR-команда. Меня зовут Карина Михайловна Лебедева, табельный номер 88142, работаю senior product designer в команде Mobile Commerce (руководитель — Орлов Д.С.) с 4 февраля 2022 года. Бессрочный трудовой договор № ТД-2022/0142. 5 мая 2026 года меня вызвали к Орлову и в присутствии HR-партнёра Беловой М.А. вручили уведомление о сокращении штатной единицы 'senior product designer' с предложением подписать соглашение о расторжении трудового договора по соглашению сторон (п.1 ч.1 ст.77 ТК РФ) с компенсацией 2 оклада (мой оклад 285 000 руб./мес.). Сказали, что 'это финальное предложение', 'нужно подписать сегодня или завтра, иначе будет хуже'. Я отказалась подписывать на месте. Что меня беспокоит: 1) Сокращения штата по факту НЕТ. В нашей команде Mobile Commerce работают ещё двое product designer-ов (Алексей Сидоров и Мария Ковалёва), оба остаются на своих местах. Более того, в Workday я вижу открытую вакансию 'product designer (mobile)' с публикацией от 28 апреля — за неделю до того, как мне сообщили о 'сокращении'. 2) Я нахожусь на 14-й неделе беременности (справка ЖК есть). О беременности я НЕ сообщала ни руководителю, ни HR — узнала сама 22 апреля. Но юридически — это статус, защищённый ст. 261 ТК РФ. 3) В декабре 2025 у меня была публичная конфликтная ситуация с Орловым на ретроспективе (я раскритиковала его решение о редизайне корзины, которое впоследствии привело к падению конверсии на 8%). Считаю, что моё 'сокращение' — это месть за публичную критику. 4) По итогам 2025 года у меня высший рейтинг performance review (5 из 5, обзор делал тот же Орлов), бонус 100% от целевого, замечаний по работе не было. Прошу: зафиксировать обращение официально; провести независимую проверку процедуры (хочу, чтобы это не делал Орлов или подчинённый ему HR); приостановить любые действия по моему увольнению до выяснения; организовать встречу с CHRO и юридическим департаментом. Если ситуация не разрешится в течение 5 рабочих дней — буду вынуждена обратиться в ГИТ и в прокуратуру. С уважением, К.М. Лебедева." ВЕРНИ JSON: { "dispute_type": "<wrongful_termination|discrimination|harassment|wage_dispute|working_conditions|policy_violation|retaliation|other>", "sub_categories": ["<подкатегории>"], "legal_risk_level": "<low|medium|high|critical>", "protected_status": ["<pregnancy|maternity|disability|union_member|whistleblower|none>"], "legal_articles_cited": ["<статьи ТК РФ или иных законов>"], "escalation_path": ["<последовательность шагов>"], "immediate_actions_required": ["<что сделать в первые 24 часа>"], "recommended_owner": "<CHRO|HR_BP|Legal|Compliance|Ethics_Committee>" }

Ты — triage-инженер платформенной команды финтех-сервиса (B2C мобильное приложение, 4 млн активных пользователей в РФ). На очереди — 6 баг-репортов из разных источников за прошлую неделю. Для каждого определи: severity, priority (по матрице ICE: Impact × Confidence × Ease), категорию, команду-владельца, и нужен ли hotfix. BUG REPORT #1 (источник: Sentry, 14.05.2026): Crash: NullPointerException в PaymentConfirmationActivity.onCreate, Android 14, Samsung Galaxy S23/S24, версия приложения 5.18.2. 12 400 крашей за 48 часов, затронуто ~3 200 уникальных пользователей. Возникает после нажатия 'Подтвердить' на экране подтверждения перевода СБП. Деньги при этом списываются с карты, но в истории операций пользователь не видит транзакцию, и push-уведомление не приходит. 47 обращений в саппорт уже зарегистрировано. BUG REPORT #2 (источник: ручное тестирование QA, 13.05.2026): При смене языка приложения с русского на английский, в разделе 'Профиль' → 'Документы' название кнопки остаётся на русском: 'Загрузить документ'. Все остальные элементы переведены корректно. Воспроизводится 100% на всех платформах. Кнопка функционально работает. BUG REPORT #3 (источник: PR-issue от пресс-службы, 15.05.2026): Журналист из 'Ведомостей' прислал скриншот: при попытке оформить вклад на сумму больше 10 000 000 рублей через приложение, валидация показывает текст 'максимальная сумма — 10 000 000.00 рубл.' (вместо 'рублей'). Журналист готовит статью про 'небрежность к деталям в российских банках', публикация в пятницу. Скриншот уже разошёлся в нескольких telegram-каналах (совокупная аудитория ~80 тыс.). BUG REPORT #4 (источник: внутренний security audit, 12.05.2026): В API endpoint /v3/users/{user_id}/profile отсутствует проверка авторизации: любой аутентифицированный пользователь может запросить профиль любого другого пользователя по user_id (включая ФИО, телефон, дату рождения, маскированные карты). Это IDOR-уязвимость уровня CRITICAL. CVE не присвоен, эксплоит в дикой природе не зафиксирован, но логи показывают несколько подозрительных last-week запросов с одного IP-адреса перебором ID. BUG REPORT #5 (источник: App Store review, 14.05.2026): Пользователь Артём Г. оставил отзыв 1 звезда: 'Иконка приложения некрасивая, не вписывается в мой главный экран. В прошлой версии было лучше'. Один пользователь, оценка субъективная. BUG REPORT #6 (источник: внутренний мониторинг, 15.05.2026): При операции пополнения брокерского счёта суммой свыше 1 000 000 рублей в 0.4% случаев (приблизительно 80 операций в день) возникает таймаут: операция помечается как 'failed', но по факту через 5-15 минут средства приходят. Пользователи видят ошибку, повторно пытаются пополнить, иногда зачисление происходит дважды. За 5 дней — 18 случаев двойного пополнения, из них 4 уже привели к обращению в саппорт с требованием возврата. ВЕРНИ JSON-массив из 6 объектов, по одному на каждый bug: [{ "bug_id": "BUG-#1", "severity": "<S1|S2|S3|S4>", "priority": "<P0|P1|P2|P3>", "category": "<crash|security|data_integrity|payment_flow|ui_bug|localization|reputation|other>", "owner_team": "<mobile_android|mobile_ios|backend_payments|backend_security|qa|design|copy>", "hotfix_required": <true|false>, "sla_hours": <int>, "justification": "<1-2 предложения>" }]

Ты — AI-ассистент, ведущий протокол продуктовых встреч. На основе транскрипта 60-минутной встречи команды Growth по запуску платного тарифа 'Pro+' составь структурированный summary. ТРАНСКРИПТ (15 мая 2026, 14:00-15:00, Zoom): Анна Жукова (CPO): Финальный go/no-go по запуску Pro+. Запуск планировали на 1 июня, осталось 17 дней. Сергей, что по продукту? Сергей Тимохин (Product Lead): По фичам готовы на 90%. Закрыты: расширенная аналитика, командные дашборды, API rate limit x10, приоритетная поддержка. Не закрыто: SSO-интеграция (Okta, Azure AD) — команда Auth не успевает. Реалистично — SSO к 15 июня. Можно запускаться без SSO, в FAQ написать 'Coming soon'. Дмитрий Костин (CTO): Против. SSO — базовое требование Enterprise-сегмента. Без SSO мы убиваем оффер для лиц принимающих решения. Я бы двигал дату на 22 июня. Сергей: Это сдвиг на 3 недели — мы коммитили дату 1 июня перед советом, партнёры уведомлены, маркетинг закупил рекламу. Марина Якушева (Marketing Lead): Подтверждаю, закуплено: VK Ads (₽2.4 млн), Telegram Ads (₽1.8 млн), Habr Promo (₽600K), всего ₽4.8 млн на период 1-30 июня. Потеря при переносе больше недели — ₽1.5-2 млн. Анна: Компромисс? Сергей — что если SSO только Okta к 1 июня, Azure AD к 22 июня? Сергей: Okta — реалистично, 70% работ сделано. Azure AD — нет. Согласен: 1 июня запускаем с Okta SSO, 22 июня добавляем Azure AD. В FAQ 'Azure AD coming in late June'. Дмитрий: Принимаю, при условии что 22 июня для Azure — фиксированный коммит. Анна: Договорились. Сергей, update план команды Auth, прислать финальный план на 1 и 22 июня к среде. Марина, по цене? Марина: $89/seat/month при годовой подписке (~₽8 200), $109/seat/month при месячной. На 35% дороже Pro ($69 годовой). Конкуренты $99-129. Бесплатный trial 14 дней без карты. Олег Шумаков (Finance Lead): Прогноз продаж на Q3? Марина: По воронке — 80-120 платящих команд за первый квартал. Средний размер 12 человек. LTV — 24 месяца. ARR первого квартала: ~₽9-14 млн annualized. Олег: Это меньше плана (₽20 млн ARR за Q3). Могут быть вопросы у борда. Дмитрий: По нагрузке — backend выдержит до 200 команд. Хочу зарезервировать ₽800K из инфраструктурного бюджета на upgrade БД. Олег: Согласовано, если в рамках одобренного CAPEX. Анна: По коммуникации. Марина? Марина: Пресс-релиз 28 мая, embargo до 1 июня 09:00. Питчим VC.ru, Хабр, Forbes Russia. Внутренний релиз 31 мая, all-hands с демо. Email-кампания на 25 000 active accounts — 1 июня 10:00. Сергей: При анонсе НЕ обещать Azure AD как 'available' — только 'planned'. Марина: Принято. Anna, нужен твой sign-off на финальный текст к 26 мая. Анна: Поддержка — кто отвечает на pro+ тикеты в первый месяц? Сергей: Подключаю в support-rotation двух senior-разработчиков (Иванов, Петрова) на дежурство 1-30 июня. Анна: Риски ещё? Дмитрий: Конкурент 'PixelPlatform' анонсировал аналогичный enterprise-тариф на конференции 20 мая. Если опередят по дате — теряем эффект новизны. Анна: Мониторим. Last call — go или no-go на 1 июня? Сергей — go, Дмитрий — go, Марина — go, Олег — go (с оговоркой по ARR). Анна: GO на 1 июня. Спасибо всем. Сгенерируй краткий meeting summary в Markdown: TL;DR (3-4 предложения), Decisions (нумерованный список), Action items (таблица: кто/что/срок), Open risks, Next checkpoint.

Ты — strategic analyst в retail-холдинге. Подготовь executive summary (для CEO и совета директоров, 250-350 слов) на основе аналитического отчёта по стратегии выхода в омниканальный e-commerce. ОТЧЁТ (выдержки): СТРАТЕГИЧЕСКИЙ ОБЗОР: ОМНИКАНАЛЬНОЕ РАЗВИТИЕ ХОЛДИНГА 'ТЕХНОДОМ' 2026-2028 1. КОНТЕКСТ. Холдинг 'ТехноДом' (выручка 2025: ₽48.2 млрд, EBITDA margin: 8.4%, 142 магазина в 38 городах РФ) сталкивается с трендом: доля e-commerce в БТЭ в РФ выросла с 28% (2022) до 41% (2025). Наша доля онлайн-продаж — 19%, ниже среднего по индустрии (35%) и драматически ниже лидеров (M.Видео — 71%, Ozon — 95%+). 2. КОНКУРЕНТНАЯ СРЕДА. Маркетплейсы откусили ~37% рынка БТЭ за 3 года. Традиционные ритейлеры теряют долю на 2-3% год к году. Только инвестировавшие в омниканал (M.Видео) сохраняют позиции. Маржинальность онлайна — 4.2% против 11.1% офлайн. 3. SWOT. Сильные: 142 магазина, 4.1 млн клиентов в лояльности, собственные сервисные центры в 22 городах. Слабые: устаревший Magento 1.x, отсутствие единой корзины, слабая мобильная конверсия (1.4% vs 3.7% у конкурентов), фрагментированные данные о клиенте. 4. СТРАТЕГИЧЕСКИЕ ОПЦИИ: Опция А — косметика существующего сайта. CAPEX ₽300 млн, эффект — рост онлайна до 24% к 2028. Опция B — полный rewrite e-com (SAP/Spryker), единый CRM, fulfillment из магазинов, мобильное приложение, ML-рекомендации. CAPEX ₽2.4 млрд (~4.9% выручки) на 30 месяцев (Q3 2026 — Q1 2029). Эффект — доля онлайна 38% к 2028, рост выручки на 22% (₽58.8 млрд), снижение EBITDA до 5.2% в 2027 с восстановлением до 9.1% в 2029. Опция C — продажа e-com маркетплейсу-партнёру, уйти в офлайн+маркетплейс. CAPEX ~₽100 млн. 5. РЕКОМЕНДАЦИЯ: Опция B. Обоснование: (1) рынок необратимо смещается в онлайн; (2) маркетплейсы продолжат давить, опция C превращает нас в подрядчика; (3) уникальный актив (физическая сеть + лояльная база) даёт конкурентное преимущество перед чистыми онлайн-игроками. 6. РИСКИ ОПЦИИ B: - Исполнительский: 30-месячный проект с заменой backend — типично +30-50% перерасхода. Митигация: фазированный rollout, независимый PMO. - Финансовый: снижение EBITDA до 5.2% в 2027 может насторожить инвесторов. Митигация: прозрачная коммуникация с акционерами. - Кадровый: нужно нанять CTO, ~60 IT-инженеров. Российский IT-рынок перегрет. Митигация: партнёрство с системным интегратором. - Технологический: возможные санкционные ограничения на SAP. Митигация: план B на open-source (Saleor/MedusaJS). 7. ИНВЕСТИЦИИ ПО ФАЗАМ: Фаза 1 (Q3 2026 — Q2 2027, ₽700 млн): backend + customer profile, mobile MVP, click&collect пилот в 12 магазинах. Фаза 2 (Q3 2027 — Q2 2028, ₽950 млн): rollout click&collect, fulfillment из магазинов, ML-рекомендации. Фаза 3 (Q3 2028 — Q1 2029, ₽750 млн): омниканальные кампании, programmatic, оптимизация. 8. KPI: Конец 2027: доля онлайна 25%, мобильная конверсия 2.5%, click&collect 8% Конец 2028: доля онлайна 38%, мобильная конверсия 3.5%, click&collect 18%, NPS +10 2029: EBITDA восстановлена до 9.1%, выручка ₽63.5 млрд Сгенерируй executive summary (250-350 слов): контекст, рекомендация, обоснование, риски, ожидаемый эффект. С конкретными числами, без жаргона.

Ты — knowledge engineer техподдержки SaaS-платформы для управления складами 'WareSync'. Возьми длинную многосессионную переписку клиента и саппорта и создай нарративный case summary (для базы знаний и аудита) длиной 300-500 слов: что случилось, как развивалось, как решили, какие уроки. ПЕРЕПИСКА (тикет #SUP-78124, 9 дней, 23 сообщения): 06.05.2026 09:42 — Клиент (Виталий Сорокин, склад-менеджер ООО 'ЛогистикПлюс'): Срочно. Расхождение остатков в системе и фактически на складе. В WareSync 1240 шт. 'Гайка М10 DIN 934', по факту 982. Разница 258 шт. Проверили выборочно ещё 5 SKU — расхождения 3-22%. В среду 8 мая аудит от заказчика, нужно срочно понять и поправить. 06.05.2026 10:15 — Саппорт (Олег): Тикет, эскалировал инженерам. Уточните: (1) когда цифры сходились, (2) массовые операции за 2 недели, (3) интеграция с 1С? 06.05.2026 11:08 — Клиент: (1) 28 апреля делали инвентаризацию — сошлось. (2) 2 мая большой импорт из 1С (~3500 строк), 4 мая перемещение между складами A и B. (3) Интеграция с 1С по REST API, синхронизация раз в час. 06.05.2026 13:22 — Саппорт (Кристина, инженер): Логи: 2 мая 14:33 импорт прошёл с 'partial timeout, 47 of 3500 rows postponed'. 47 строк висели в queue, обработались только 3 мая 04:11 без подтверждения от 1С. То есть остатки разошлись. По второй части — есть событие 'manual_adjustment_+150' через 7 минут после создания перемещения 4 мая. Это вы? 06.05.2026 14:51 — Клиент: Манипуляцию делал сотрудник Артём, потому что система 'не приняла' перемещение — сделал ручную корректировку. Он не знал про timeout с 1С. Видимо, ещё несколько таких ситуаций было. Аудит послезавтра! 06.05.2026 16:08 — Кристина: План: 1. SQL-отчёт с разницей по всем артикулам между WareSync и 1С (на 5 мая). Прикрепляю. 2. Экспресс-инвентаризация по 47+12 (от 4 мая) артикулам. 3. После — reconciliation: корректные цифры в WareSync, adjusted batch в 1С. 4. Audit-trail документ для аудитора. 07.05.2026 08:30 — Клиент: Получили отчёт. Команда из 3 человек начинает инвентаризацию. В отчёте 71 артикул, я ожидал 59 (47+12). Откуда ещё 12? 07.05.2026 09:14 — Кристина: Дополнительные 12 — аналогичные timeout с 25 апреля по 1 мая. Расширила scan на 2 недели назад. Все исправляются вместе. 07.05.2026 19:47 — Клиент: Инвентаризация завершена. Из 71 артикула: - 58 системных расхождений - 9 фактических излишков - 4 фактических недостач 07.05.2026 21:30 — Кристина: Принято. Через 30 минут — bulk_adjustment в обе системы. К 08:00 8 мая цифры синхронизированы. 08.05.2026 07:48 — Кристина: Готово. Reconciliation выполнен. Audit-trail документ прикладываю (по каждому из 71 артикула: дата расхождения, причина, исправление, ссылка на лог). 08.05.2026 18:22 — Клиент: Аудит прошёл успешно, замечаний нет. Спасибо! Что сделать, чтобы не повторилось? 09.05.2026 11:00 — Кристина: Профилактика: 1. Подняла внутренний баг BR-9817 — изменить поведение импорта при timeout (блокировать, не молча в queue). Roadmap v4.18 в июле. 2. Подключу алёрт на 'pending_import_rows > 0 более 2 часов'. 3. Сотруднику Артёму — пройти курс по WareSync (3 часа, бесплатно). 14.05.2026 — внутренняя заметка: BR-9817 повышен до P1 после аналогичного кейса у другого клиента 12 мая. Roadmap пересмотрен на v4.16 (июнь). Сгенерируй case summary 300-500 слов: контекст, развитие, разрешение, root cause, уроки. Спокойный нарратив, 3-е лицо, для базы знаний.

Ты — strategy consultant. Сожми бриф B2B SaaS-стартапа в 5 слайдов: Заголовок + 3-5 коротких bullet-точек (макс 12 слов на bullet). Для внутренней discovery-сессии команды. БРИФ: ПРОЕКТ: 'TalentFlow' — стратегическая инициатива по выходу на enterprise-сегмент (1000+ сотрудников) в горизонте 12 месяцев. ТЕКУЩАЯ СИТУАЦИЯ. TalentFlow — SaaS-платформа автоматизации найма (ATS + assessment + onboarding). Основана 2022, серия A 2024 на $8M (Recall Capital). ARR — $4.2M, рост 110% YoY. Клиентов 380, средний ACV $11.1K. Сегмент — SMB (50-500). Команда 47, из них 18 R&D, 14 продажи. Проблема: SMB-traction упёрся в потолок. CAC вырос с $1.8K (2024) до $3.2K (Q1 2026), payback 8 → 14 мес. LTV/CAC упал с 5.2 до 3.1. Совет требует прорыва в выручке (Series B mid-2027: ARR $15M+) либо смены стратегии. Enterprise — единственный путь: ACV $80-150K, payback 12-18 мес приемлем, LTV 4-6 лет. ЦЕЛЕВЫЕ ВЕРТИКАЛИ (по интервью с 30 HR-директорами): 1. Финансовые услуги — compliance (KYC, 152-ФЗ), премиум за безопасность. ~400 компаний. 2. Розничная торговля и e-com — массовый найм, screening и onboarding. ~250 компаний. 3. Профессиональные сервисы — assessment и culture-fit, аналитика. ~180 компаний. TAM ~830 компаний, peak ARR при 5% доли: $5M (FinServ), $2M (Retail), $1.5M (ProSvcs). ПРОДУКТОВЫЕ GAPS (6 ключевых): - SSO/SAML и SCIM-провизионинг - Расширенные роли и permissions (RBAC, audit logs) - Сертификации: SOC 2 Type II, ISO 27001 (Q3 2026 — Q1 2027) - Локализация: 1С ЗУП, ЕИС-Кадры - White-label и customizable workflows - 24/7 enterprise-support с SLA Бюджет: $2.8M (+8 FTE в R&D, $400K сертификации). GO-TO-MARKET. Нанять enterprise sales team (4 AE, 2 SE, 1 enterprise CSM, 1 партнёр-менеджер). Цикл 6-9 мес, первые контракты Q2 2027. Каналы: 1. Партнёрство с системными интеграторами (КРОК, Сибур-IT, I-Teco) 2. Industry events (HR-Tech Russia, RecHack) 3. ABM на топ-200 компаний 4. Existing customer expansion (3 mid-market reference) CAC $30-50K, payback 14-18 мес, LTV $400-600K. РИСКИ: 1. Долгий цикл → кассовый разрыв. Митигация: 'land and expand', резервный bridge ~$5M Q1 2027. 2. Команда без enterprise-опыта. Митигация: VP Sales из SAP/Oracle/Cornerstone. 3. Конкуренты: Skill Cup, Talantix, HeadHunter Talent. Митигация: speed-to-market по top-3 фичам. 4. Регуляторный (152-ФЗ, KYC) — мониторим. ВРЕМЕННАЯ ЛИНИЯ И KPI: Q3 2026: hire VP Sales, start sales team, SOC 2 audit, выпуск SSO/RBAC Q4 2026: 1С/ЕИС-Кадры, white-label, first 3 pilots Q1 2027: SOC 2 готов, ISO 27001 финал, 5 paid contracts Q2 2027: 15+ customers, enterprise ARR $1.5M (10% total) Q3 2027: enterprise ARR $3.5M, Series B fundraise СЛЕДУЮЩИЕ ШАГИ. Validate стратегию. Решение на board meeting 30 мая. Сгенерируй РОВНО 5 слайдов. Формат: '### Slide N: <Заголовок>' и 3-5 bullets через '-'. МАКС 12 слов на bullet. Слайды самодостаточные.

Ты — content writer B2B SaaS-продукта (CRM 'OrionCRM' для среднего бизнеса). Напиши customer story для публикации на сайте: 400-600 слов, структура — challenge/solution/results, цитаты, конкретные цифры. Тон деловой, без marketing-bs. ИНТЕРВЬЮ: Респондент: Светлана Бережная, директор по продажам, ГК 'УралМеталлТорг' (опт металлопроката, Екатеринбург, 11 филиалов, 265 сотрудников, выручка 2025 — ₽8.7 млрд). Дата: 12 мая 2026. Интервьюер: Ирина (маркетинг OrionCRM). Ирина: Расскажите о компании. Светлана: УралМеталлТорг с 2009, региональный лидер по металлопрокату на Урале. 11 филиалов от Тюмени до Перми, флот 30 машин. Клиенты — стройподрядчики, машзаводы, мастерские. У меня в подчинении 64 менеджера, 8 руководителей групп. Ирина: Что было до OrionCRM? Светлана: До конца 2024 не было единой CRM. Каждый филиал по-своему: Excel, 1С с надстройками, в Перми один менеджер вёл клиентов в тетради. Реальный хаос. Я пришла в августе 2024, разбиралась — не можем ответить на базовые вопросы: сколько активных клиентов, какая конверсия лид-сделка, сколько менеджер тратит на обращение. Forecast по интуиции директоров. Ирина: Главная боль? Светлана: Утечка клиентов. Менеджер увольняется — забирает контакты. Был случай: ушёл руководитель группы из челябинского филиала, увёл 4 менеджеров и около 30 клиентов на конкурента. По моим оценкам, ₽180-220 млн годовой выручки. Второй слой — не понимали, какие лиды теряем. Бросаем рекламу, тратим миллионы, конверсия 4-5% — норма или катастрофа? Ирина: Как выбирали CRM? Светлана: Смотрела четыре системы. Решили OrionCRM по трём причинам: (1) глубокая локализация под российский B2B — у вас интеграция с 1С и СБИС из коробки; (2) гибкость кастомизации без программистов — у меня нет своего ИТ-департамента; (3) поддержка на этапе пресейла. Михаил, ваш sales-инженер, реально приехал в Екатеринбург, провёл два дня с моими руководителями, показал как это будет работать у нас. Ирина: Как прошёл запуск? Светлана: Запустились в декабре 2024 — 1.5 месяца на конфигурацию, перенос данных, обучение. Сначала 4 филиала, потом расширяли. К марту 2025 все 11 в системе. Было трудно — сопротивление старых менеджеров, кто-то саботировал. Двух пришлось уволить. За 3 месяца команда привыкла. Сейчас не могу представить, как мы жили до этого. Ирина: Конкретные результаты? Светлана: За год работы (январь 2025 — март 2026): - Конверсия лида в сделку выросла с 5% до 13% - Средний цикл сделки сократился с 21 дня до 14 - Вернули около 60% 'спящих' клиентов через ABM-программу - Выручка группы выросла на 31% YoY (с ₽6.6 до ₽8.7 млрд). Не всё благодаря CRM, но процентов 15-18 роста — точно благодаря лучшей работе с воронкой - Утечка клиентов с увольняющимися — почти до нуля Ирина: Что было сложнее всего? Светлана: Поменять культуру. Технически OrionCRM настроился быстро, но заставить менеджера, 12 лет работавшего по-своему, записывать каждый звонок — адова работа. Помогли две вещи: жёсткая позиция — 'или работаешь в CRM, или нам не по пути' — и геймификация. Менеджеры стали соревноваться, кто быстрее закроет лида. Ирина: Совет другим? Светлана: Три. Первый — не тянуть. Чем дольше живёте без CRM, тем больнее переход. Второй — выбирайте партнёра, не только продукт. Поддержка решает. Третий — будьте готовы расстаться с теми, кто не хочет меняться. У нас 7-8% команды ушло за 6 месяцев, и это нормально. Сгенерируй customer story 400-600 слов в Markdown: заголовок, лид (about), Challenge, Solution, Results, Key Quote, 2-3 интегрированных цитаты. Без маркетинговых клише.

Ты — AI-ассистент команды разработки. По итогам ежедневного стендапа сгенерируй структурированный список action items, сгруппированный по каждому участнику, с дедлайнами, статусами блокеров, и зависимостями между задачами. ТРАНСКРИПТ (15 мая 2026, 10:00, Slack huddle): Команда: Backend platform team. Спринт 2026-W19 (11-24 мая). Цель: запустить v2 API авторизации и закрыть critical security-issues. Максим (Tech Lead): По очереди. Алиса? Алиса (Senior BE): Y — закончила refactoring jwt-validation, PR #4421, жду ревью от Максима. Покрытие 94%. Начала миграцию rate-limiter (PR #4422, draft). T — допишу миграцию, прогон на staging, мерж завтра утром. Нет блокеров, но нужно ревью PR #4421 до конца дня. Максим: До 14:00, в крайнем случае 16:00. Богдан? Богдан (BE): Y — застрял на security audit ответа на CVE-2024-31115 (json-parser). Нужен апгрейд с 2.4.1 до 2.6.3, в новой версии changed API — править 47 файлов. T — продолжаю миграцию, к четвергу 18 мая закрою. Блокер: нужно согласование с командой mobile-API (Кирилл), они тоже используют через shared-package. Жду ответ. Максим: Пингани Кирилла сегодня, если до 12 нет ответа — эскалируй мне. Critical по security SLA — 14 дней с CVE, у нас 9-й день, остаётся 5. Полина (Junior BE): Y — закончила BPL-2287 (/v2/sessions/revoke). PR на повторном ревью. Начала BPL-2301 (логирование auth-событий в Kafka) — первая работа с Kafka, делаю POC. T — допилить POC, показать Максиму. Прошу 30 минут Максима после обеда. Максим: В 15:00. Игорь? Игорь (Senior BE, Тбилиси): Y — incident production-базы (Postgres lag 8 сек). С DBA решили: (1) statement_timeout на reporting-юзера, (2) алёрт на replication lag > 3 сек. T — пишу обе фиксы плюс постмортем (deadline 3 дня после incident от 13 мая = завтра 16-е). Максим: Постмортем — на меня скинь до публикации. Опубликовать в Confluence в пятницу до полудня. И отдельный issue: процесс согласования heavy-queries — на ретро. Игорь: Записал. Наташа (QA): Y — закончила тест-план для v2 API (Confluence). T — проходить test cases. Главный риск: SSO-сценарии (SAML), минимальный опыт. Прошу у Алисы 30 минут онбординга. Алиса: Завтра в 11, ок? Наташа: Да. Максим: Общий блок. (1) В четверг 17 мая выкатка v1.4.2 в продакшен в 18:00. Богдан и Алиса дежурят. Игорь? Игорь: В дежурстве, до 21:00 МСК доступен. Максим: (2) В понедельник 19 мая 11:00 архитектурный комитет — Алиса презентует jwt-flow. Слайды на ревью к воскресенью вечером. Алиса: Принято. Спасибо. Сгенерируй документ в Markdown: ### По людям (Yesterday/Today/Blockers/Action items с дедлайнами) ### Cross-team зависимости ### Sprint goal status (on track?)

Ты — tech lead команды логистической платформы для российских курьерских служб. Нужно выбрать API геокодирования: пользователь вводит произвольный адрес (часто с опечатками, сокращениями, без указания города), система возвращает нормализованный адрес, координаты, КЛАДР/ФИАС-код и временную зону. Объём — 18 млн запросов/мес, пиковая нагрузка до 600 RPS утром, p95-latency не выше 350 мс из московских ЦОДов. Кандидаты: 1) **Yandex Geocoder API (Business)** — отлично работает с РФ-адресами, есть распознавание организаций. Бизнес-тариф от 540k запросов/мес за ~85 000 ₽, ступенчатый. Возвращает координаты, FIAS-uuid только в Enterprise-пакете, НЕ возвращает временную зону. Лицензия запрещает долговременное хранение координат вне сервисов на базе Яндекс.Карт. 2) **DaData (Стандартизация адресов)** — российский, специализирован на стандартизации, отлично исправляет опечатки. Возвращает ФИАС, КЛАДР, координаты, часовой пояс. От 350k запросов/мес за ~38 000 ₽, есть on-premise. Качество координат уступает Яндексу для редких объектов (СНТ, новостройки). Batch до 10k записей. 3) **2GIS Catalog API** — фокус на POI, геокодирование адресов в крупных городах России и СНГ. Возвращает координаты, НЕ возвращает ФИАС. Около 60 000 ₽ за 1М запросов. Знает локальные ориентиры в нефедеральных центрах. Лицензия позволяет хранение результатов. 4) **Google Maps Geocoding API** — глобальное покрытие, $5 за 1000 запросов сверх $200 free tier, для 18М/мес ~$90 000/мес. Качество для РФ — приличное в Москве/СПб, среднее в регионах. Не возвращает ФИАС/КЛАДР. С 2022 года юридические и платёжные риски при работе из РФ. Твоя задача — выбрать оптимальную стратегию маршрутизации. Это не обязательно «один сервис побеждает» — допустима fallback-цепочка или кэш-слой. Опиши: 1. Финальную архитектуру routing-логики (ASCII-диаграмма или markdown-список). 2. Какой API на какой шаг и почему — с привязкой к функциональным (ФИАС, timezone) и нефункциональным (latency, бюджет, лицензия) требованиям. 3. Оценку месячных затрат твоего решения. 4. План кэширования (что и сколько хранить, TTL). 5. Стратегию деградации при недоступности основного провайдера. 6. Метрики качества для сравнения кандидатов в первые 3 месяца. Обоснуй каждый выбор. «Возьмём DaData потому что российский» — не годится. Если отвергаешь Google — объясни юридический риск конкретно.

Ты — senior data engineer в финтех-компании. CTO поручил тебе спланировать миграцию данных из устаревшей системы на MySQL 5.7 (база transactions_legacy, около 4.2 ТБ, 18 таблиц, ~3 млрд строк в таблице transactions, ~280 млн в users_archive) в новую инфраструктуру на PostgreSQL 16 в managed-сервисе AWS RDS. Бизнес-требования: (1) downtime для критичных операций не более 30 минут в субботнюю ночь, (2) read-only доступ к старой системе должен сохраниться на 90 дней после переезда для compliance-аудита, (3) часть полей (JSON-блобы metadata в transactions, varbinary-поля в users_archive) нужно нормализовать в строгие реляционные схемы, (4) PII-поля (паспорт, ИНН, телефон) должны быть зашифрованы на уровне столбцов через pgcrypto и переходить через защищённый канал, (5) после миграции должна работать сверка консистентности с пороговой ошибкой не более 0.001%. Текущая команда: 2 backend-разработчика на Python, 1 DBA с опытом MySQL, 1 SRE. Окно времени на проект — 8 недель. Никаких ETL-инструментов (Airflow, dbt, AWS DMS) пока не куплено, бюджет на инструменты до $15k. Твоя задача: построить полную декомпозицию миграционного проекта на фазы, этапы и атомарные задачи. На выходе должен получиться структурированный план в формате Markdown, содержащий: 1. Высокоуровневую дорожную карту с фазами (discovery, дизайн, prototype, dry-run, cutover, post-cutover) и привязкой к неделям 1-8. 2. Для каждой фазы — список конкретных задач с ответственным (по роли), оценкой в человеко-днях и зависимостями. 3. Список рисков (минимум 6) с оценкой вероятности/импакта и митигациями. 4. Решение по инструментарию: что взять из open-source (с обоснованием), что — из managed-сервисов AWS, что писать самим. Сравни как минимум AWS DMS, pgloader, кастомный Python-pipeline на asyncio. 5. Стратегию rollback на случай провала cutover. 6. KPI и критерии приёмки. Не ограничивайся общими словами. Если предлагаешь dual-write, опиши, как именно он реализован (CDC через binlog, очередь, идемпотентность). Если упоминаешь сверку — укажи, как считаются контрольные суммы (например, побитовые хеши по партициям). План должен быть достаточно конкретным, чтобы передать его команде на исполнение без дополнительных уточнений.

Ты — coding-агент. Задача — полностью реализовать production-ready Python-модуль `ratelimit_token_bucket.py` с алгоритмом token bucket и набором pytest-тестов. **Функциональные требования:** 1. Класс `TokenBucket(capacity: int, refill_rate: float, refill_period: float = 1.0)`. 2. Метод `try_consume(tokens: int = 1) -> bool` — пытается снять токены, не блокирующий. 3. Метод `consume(tokens: int = 1, timeout: float | None = None) -> bool` — ждёт токенов, возвращает False по таймауту. 4. Метод `available_tokens() -> float`. 5. Потокобезопасность через threading.Lock. 6. Контекстный менеджер `with bucket.acquire(tokens=N, timeout=T):` — поднимает RateLimitExceeded если не получил токены. 7. Метрики: allowed/denied запросы, доступ через `bucket.stats() -> dict`. **Нефункциональные:** - Python 3.11+. - Только stdlib. - `time.monotonic()` для времени. - Type hints везде. - Google-style docstrings. **Тесты (минимум 10):** - Базовая работа try_consume. - Превышение capacity. - Корректный refill после паузы. - Refill не превышает capacity. - consume с timeout=0 == try_consume. - consume с таймаутом возвращает False вовремя. - Контекстный менеджер бросает RateLimitExceeded. - Потокобезопасность: 16 потоков по 100 запросов, суммарно allowed не больше capacity + (длительность теста * refill_rate). - Граничные: capacity=0, refill_rate=0, отрицательные tokens (ValueError). - Метрики корректно считаются. **Процесс:** Сначала — **план** реализации (нумерованный список 8-12 шагов, в каком порядке писать код и как решать тонкие моменты: refill за время с последнего обращения, как избежать data race в `consume` с ожиданием). Затем — **полный код** модуля. Затем — **полный код тестов** в `test_ratelimit_token_bucket.py`. В конце — короткий раздел `### Notes` с честным указанием мест, требующих ревью. Код должен быть запускаемым: `pytest test_ratelimit_token_bucket.py -q` проходит полностью. Без TODO и заглушек.

Ты — on-call SRE крупного e-commerce проекта (~1.4 млн заказов/сутки, выручка ~250 млн ₽/день). В 02:47 МСК алерт: primary PostgreSQL 15 в кластере (стриминговая репликация на 2 hot-standby в разных AZ) перешёл в crash recovery, через 4 минуты — повторно упал, healthcheck отдаёт connection refused. Через 6 минут приложение массово ловит 500 на checkout и order-history, Sentry в огне. На тебя смотрят PM и CTO. Известно: - Primary — db-prod-01 (AWS m6i.8xlarge, EBS gp3 4 TB, WAL на отдельном томе 500 GB). - Standby — db-prod-02 (синхронный, lag 0 до инцидента), db-prod-03 (асинхронный, lag ~200 мс). - patroni + etcd для failover, автоматический failover с задержкой 30 секунд, блокируется при потере etcd-кворума. - Последний PITR backup — 02:00 МСК (45 минут назад). pg_basebackup ежедневный, в 00:00. Задача: написать **подробный runbook recovery**, который выполнить прямо сейчас. План должен содержать: 1. **Immediate actions (0-5 мин)** — что включить, кого позвать, какие коммуникации запустить. 2. **Triage (5-15 мин)** — конкретные команды для root cause: статус etcd-кворума, patroni, логов PG (где искать FATAL/PANIC), статус EBS (iostat, dmesg на I/O ошибки), место на диске. 3. **Decision tree** — какой failover в какой ситуации: - Standby здоров и patroni не отработал — ручной promote через patronictl. - Синхронный отстал — переключение на асинхронный с признанием потери данных. - Оба standby недоступны — восстановление primary из PITR + WAL. 4. **Execution** — конкретные команды (patronictl, psql, kubectl/systemctl). 5. **Validation** — как убедиться, что новый primary принимает запись, replication lag здоров, метрики восстановлены. 6. **Communication** — шаблоны: статус-страница, internal Slack, post-incident письмо CTO. 7. **Post-mortem actions** — что зафиксировать, какие artefacts собрать до удаления подов/снапшотов. 8. **Prevention** — 5 конкретных улучшений (конфиг patroni, мониторинг, runbook, dependency на etcd). План должен быть достаточно конкретным для исполнения в 3 утра в стрессе. Без 'в зависимости от ситуации' — явные ветвления.

Ты — главный архитектор seed-стартапа в области медицинских данных (телемедицинская платформа для РФ с возможной экспансией в СНГ и Ближний Восток через 18-24 месяца). Совет директоров просит меморандум по выбору основного облачного провайдера. Контекст: - Команда: 9 инженеров, 1 DevOps. Опыт смешанный: backend знают AWS на среднем уровне, DevOps — Yandex Cloud и Selectel. - Стек: Python/FastAPI, Postgres, Redis, Kafka, ML-инференс на PyTorch (модели до 7B), фронт React/Next.js. WebRTC для видео (~3000 одновременных консультаций к концу года 2). - Регуляторика: 152-ФЗ, приказ Минздрава 947н, хранение в РФ, аттестация ИСПДн (УЗ-2), готовность к проверкам РКН. При экспансии — закон 94-V в Казахстане, UAE Health Data Law в ОАЭ. - Бюджет: $20k/мес на год 1, до $80k/мес к концу года 2. - Требования: SLA 99.9%, RPO 5 мин, RTO 30 мин, шифрование at-rest/in-transit, аудит-логи, российский ЭДО. Кандидаты (рассмотри ВСЕ): 1) **Yandex Cloud** — аттестованный Compliance-сегмент для УЗ-2/УЗ-3, managed services, GPU A100/H100 (ограниченно). Цены в рублях. 2) **VK Cloud** — аттестованные сегменты, GPU, меньше зрелость инструментов. 3) **Selectel** — IaaS-фокус, dedicated, аттестованная зона, дешевле bare metal, меньше managed. 4) **SberCloud (Cloud.ru)** — managed-сервисы, GPU, аттестованный сегмент. 5) **Гибрид Yandex Cloud (РФ) + AWS (СНГ/ОАЭ)** — основной контур в Yandex, AWS Bahrain/UAE для иностранных пользователей. 6) **On-prem колокация в Москве + AWS как DR/dev** — максимум контроля, opex. Задача: меморандум для совета (~3000-4000 слов, structured markdown): 1. **TL;DR** — рекомендация + 3-4 ключевых аргумента. 2. **Критерии оценки** (минимум 8, с весами): compliance, latency РФ, latency экспансия, стоимость 24 мес, операционная сложность, vendor lock-in, GPU/ML, экосистема managed, опыт команды, санкционная устойчивость, экологическая стабильность провайдера 3-5 лет. 3. **Матрица сравнения** — таблица 6×8+ с оценками 1-5 и обоснованием. 4. **Глубокий анализ топ-2** — преимущества, риски, оценка стоимости 24 мес с разбивкой (compute/storage/network/managed/ML), exit strategy. 5. **Trade-off анализ** — какие компромиссы сознательно принимаются и почему. 6. **План экспансии в СНГ/ОАЭ** — как multi-cloud, локализация данных по юрисдикциям. 7. **Финальная рекомендация** с roadmap на 6 месяцев и checkpoint-критериями для пересмотра через 12 мес. Без воды, со ссылками на регуляторов где уместно, с цифрами, с признанием неопределённостей.

Ты проектируешь автоматизированный workflow для обработки входящих тикетов в B2B SaaS (бухгалтерский сервис для среднего бизнеса, ~12 000 клиентов, ~800 тикетов/день). Тикеты приходят из 4 каналов: email, форма в кабинете, чат на сайте, Telegram-бот. Цель — снизить нагрузку на L1 на 40% за счёт автоклассификации, маршрутизации и частичного решения, без ухудшения CSAT. Опиши end-to-end workflow с условной логикой: 1. **Ingest & deduplication**: объединение дубликатов от одного клиента (та же проблема через email и Telegram за 30 минут). 2. **Классификация** по 3 осям одновременно: - Тип: billing, technical-error, how-to, feature-request, complaint, security-incident. - Срочность: P1 (сервис недоступен, security), P2 (функция не работает у одного клиента), P3 (вопрос/настройка), P4 (feature). - Сегмент: Enterprise (ARR > 5М ₽), SMB, Trial. 3. **Auto-resolution**: для how-to и billing-faq — попытка ответить из KB через RAG. Если confidence > 0.8 и тип разрешён для auto-reply — отправить ответ, попросить подтверждение, при 'да' — close; при 'нет' или отсутствии ответа за 4 часа — эскалация в L1. 4. **Маршрутизация**: - P1 security-incident -> SOC + paging on-call. - P1 service-down + Enterprise -> Tier-2 + CSM в копию + incident в StatusPage. - P2 technical-error -> L2 backend-команда домена (billing/reports/integrations) по ключевым словам. - P3/P4 от Trial — low-priority очередь, SLA 48 часов. - Complaint -> CSM + quality-team в копию. 5. **SLA tracking**: дедлайны по матрице тип × сегмент × срочность, эскалация за 30 минут до breach в Slack менеджера группы, за 5 минут — head of support. 6. **Escalation triggers**: автоэскалация если (а) тикет переоткрывался 2+ раза, (б) клиент написал 'оператор'/'руководитель'/'юрист'/'роскомнадзор', (в) sentiment негативный 2 сообщения подряд, (г) ответ агента не пришёл в 50% SLA. 7. **Handoff бот <-> человек**: чёткие правила, когда бот признаёт ограничение и передаёт оператору с полным контекстом (summary + raw transcript). 8. **Feedback loop**: измерение accuracy классификатора, semi-supervised retraining раз в неделю на размеченной выборке. Формат ответа: (а) общая блок-схема (псевдо-диаграмма), (б) для каждого узла — что происходит, входы/выходы, edge cases, инструменты (модели, очереди, БД). Приведи минимум 5 конкретных примеров тикетов от ingest до закрытия.

Ты — incident commander в финтех-компании (онлайн-эквайринг, ~4 млн транзакций/сутки). Вчера с 14:02 до 17:48 (UTC) произошёл крупный инцидент SEV-1: платёжный шлюз начал отклонять 63% транзакций с ошибкой 'gateway timeout'. Известные факты из логов и метрик: - В 13:55 был выкачен релиз v2.14 сервиса payment-router (изменён пул соединений к БД с 50 до 20 connections 'для экономии ресурсов'). - В 14:02 пул соединений к PostgreSQL исчерпался, p99 latency вырос с 120 мс до 9 с. - Алерт сработал только в 14:21 (порог по error-rate был выставлен на 5 минут усреднения, плюс дежурный не получил пуш — PagerDuty escalation policy указывала на уволившегося сотрудника). - Откат релиза начали в 15:10, но Helm rollback завершился ошибкой из-за рассинхрона стейта; вручную откатили к 16:30. - Полное восстановление в 17:48 после прогрева кэшей и разбора очереди отложенных платежей (примерно 280 тыс. транзакций в ретрае). - Часть клиентов получила двойные списания из-за того, что идемпотентность ретраев работала по ключу, который протухал за 60 секунд. Финансовый ущерб: ~2,1 млн руб. недополученной выручки + потенциальные чарджбэки по двойным списаниям. Составь полноценный постмортем и план устранения. Требования к ответу: 1) Краткое резюме инцидента (impact, длительность, severity). 2) Хронология (timeline) ключевых событий с временными метками. 3) Анализ корневой причины — обязательно техникой '5 почему', разделяя trigger и underlying causes; различай корневую причину и contributing factors. 4) План устранения: фазы → этапы → атомарные задачи. Для каждой атомарной задачи укажи ответственную РОЛЬ (а не имя), оценку трудозатрат, зависимости от других задач и приоритет (P0/P1/P2). Раздели на немедленные меры (24–48ч), краткосрочные (1–2 недели) и системные/долгосрочные. 5) Риски предложенных изменений и их митигации. 6) Критерии приёмки (как поймём, что проблема устранена и не повторится) — с конкретными измеримыми метриками. 7) Action items в виде таблицы: задача | роль | срок | приоритет. Будь конкретен в цифрах и не путай симптомы с причинами.

Ты — ведущий архитектор финтех-платформы. Команда строит новую шину событий для обработки платежей и должна выбрать брокер сообщений. Нужно обоснованное решение, а не общие слова. Требования и факты о нагрузке: 1. Пиковый поток событий платежей: 45 000 событий/сек, средний — 12 000/сек. Прогноз роста x3 за 18 месяцев. 2. Два класса трафика: - КЛАСС A (transaction-events): строгий порядок ПО КЛЮЧУ account_id, exactly-once на уровне бизнес-эффекта, ретеншн событий минимум 7 дней для реплея в новые сервисы (сейчас 3 потребителя, планируется до 10). - КЛАСС B (notification-jobs): задачи на отправку SMS/email/push, важна низкая задержка доставки одному воркеру, нужны per-message ack/nack, dead-letter, приоритеты и delayed delivery (отложить на N минут). Порядок НЕ важен. 3. Команда — 6 backend-инженеров, нет выделенной платформенной команды, опыта эксплуатации распределённых стейтфул-систем мало. 4. Инфраструктура в AWS, есть требование multi-AZ. Регион один. Compliance требует хранить платёжные данные в своём VPC (не передавать тело сообщения в managed-сервис вне нашего аккаунта — но метаданные можно). Кандидаты (упрощённые ориентиры): - Apache Kafka (self-managed на EC2 или MSK): отличный throughput и ретеншн/реплей, порядок по партиции (по ключу), но нет нативных per-message ack, приоритетов, delayed delivery; операционно тяжёлый; MSK снимает часть ops, но стоит дороже. - RabbitMQ (self-managed или CloudAMQP): богатая семантика очередей (ack/nack, DLQ, приоритеты, delayed-плагин), но слабый ретеншн/реплей, throughput на порядок ниже Kafka, кластеризация капризна. - Amazon SQS (+SNS): минимум ops, DLQ, delayed delivery из коробки; FIFO-очереди дают порядок и дедуп, но FIFO-лимит ~3000 msg/s на группу (с батч-вызовами выше), нет долгого ретеншна/реплея (макс 14 дней, но это очередь, а не лог), тело уходит в managed-сервис AWS. Дай решение в таком виде: (1) рекомендуемая архитектура с явным распределением КЛАССА A и КЛАССА B по брокерам (допускается гибрид); (2) обоснование выбора под каждый класс со ссылкой на конкретные требования и цифры; (3) явное отвержение неподходящих вариантов с причинами; (4) как закрыть compliance-ограничение про тело сообщения; (5) 3 ключевых операционных риска выбранного решения и их митигейшн; (6) что и при каких условиях пересмотришь.

Ты — tech lead в e-commerce компании. Нужно вывести в продакшн модель ранжирования рекомендаций (re-ranking товаров в карточке и в поиске). Жёсткие ограничения: - БЮДЖЕТ инфраструктуры: не более 8 000 USD/мес на инференс. - ЛАТЕНТНОСТЬ: p99 на инференс-вызов ≤ 40 мс (модель вызывается синхронно при рендере страницы, бюджет всего запроса 200 мс). - НАГРУЗКА: пик 12 000 RPS в будни, до 30 000 RPS в распродажу. - КОМАНДА: 1 ML-инженер, 1 backend-инженер, 1 SRE (по 0.5 FTE каждый на этот проект), 1 data scientist (модель уже обучена offline, метрики оффлайн хорошие). - СРОК: 8 недель до запуска на 100% трафика, обязателен поэтапный rollout. - Текущее состояние: модель — градиентный бустинг (~1500 деревьев) + эмбеддинги пользователя и товара; фичей ~180, часть требует обращения к feature store; артефакт модели 240 МБ. Сейчас всё это есть только в Jupyter-ноутбуке data scientist'а. Онлайн-фичестора нет, есть только батчевый офлайн-стор в Hadoop. Составь план вывода в прод. Требования к ответу: 1) Декомпозиция: фазы → этапы → атомарные задачи. Минимум 4 фазы (напр. подготовка/serving-инфра/фичи онлайн/rollout-наблюдаемость). Для каждой атомарной задачи: ответственная роль, оценка в человеко-днях, зависимости, критерий готовности (DoD). 2) Явно покажи, как план укладывается в ограничения латентности и бюджета: прикинь, где 'сгорает' латентность (feature fetch, инференс, сеть) и как уложиться в 40 мс p99; прикинь стоимость инфраструктуры под 12k и 30k RPS и обоснуй, влезаешь ли в 8000 USD/мес (с допущениями). 3) Минимум 2 архитектурные развилки с trade-off'ами (напр. онлайн-фичестор vs предвычисление, GPU vs CPU инференс, синхронный vs предрассчитанный re-ranking) и твой выбор с обоснованием под ограничения. 4) План поэтапного rollout (shadow → canary → %) с критериями перехода между этапами и условиями отката. 5) Топ-5 рисков с вероятностью/влиянием и митигациями (включая: что делать, если в пик распродажи не хватает мощностей; что если онлайн-фичи не успевают за 40 мс). 6) Критерии приёмки запуска (offline + online метрики, latency, стоимость, стабильность). Помни про дефицит людей: нельзя назначать параллельно больше задач, чем команда может вытянуть.

Ты — staff-инженер и руководитель подготовки к пиковой нагрузке в SaaS-компании (B2C сервис бронирования, монолит на Ruby + PostgreSQL + Redis, фронт на React, всё в одном AWS-регионе). До Чёрной пятницы 6 недель. Вводные: - Прошлый год: в пик сервис лёг на 47 минут, упёрлись в max_connections PostgreSQL и в single-threaded Redis (eviction storm), плюс отвалилась отправка email-подтверждений (синхронно в основном потоке запроса). - Ожидаемый трафик в этом году: x4 к прошлогоднему пику (прошлый пик ~6000 RPS). - КОМАНДА на проект: всего 4 инженера (2 backend, 1 SRE/infra, 1 frontend), полный рабочий день, но 1 backend уходит в отпуск на 2-ю и 3-ю недели (нельзя отменить). Code freeze обязателен за 1 неделю до ЧП (последняя неделя — только наблюдение и хотфиксы). - Бизнес-ограничение: даунтайм в ЧП недопустим (SLA 99.95% в этот день), но бюджет на инфраструктуру можно временно увеличить на период распродажи. - Известные слабые места: нет нагрузочного тестирования вообще; деплой — раз в неделю вручную; нет графиков по сатурации БД-пула; платёжный провайдер имеет лимит 800 запросов/сек по контракту. Составь план подготовки. Требования к ответу: 1) Декомпозиция: фазы → этапы → атомарные задачи, привязанные к НЕДЕЛЯМ (учитывая, что 5-я неделя — отпуск backend'а уже закончился, а 6-я — code freeze). Для каждой задачи: ответственная роль, оценка, зависимости, неделя выполнения. 2) Построй реалистичный график на 6 недель с учётом: отпуска 1 backend на неделях 2–3, code freeze на неделе 6, и того, что нельзя грузить 1 SRE всем сразу. Покажи критический путь. 3) Технический план устранения каждого из известных bottleneck'ов (max_connections, Redis eviction, синхронный email, лимит платёжного провайдера 800 rps при x4 трафике) — что именно меняем и почему. 4) План нагрузочного тестирования: как воспроизвести x4 пик, на каких данных, какие метрики снимаем, какой critical scenario. 5) Runbook на день ЧП: дежурства, что мониторим, пороги алертов, заранее заготовленные 'аварийные рубильники' (feature flags / деградации). 6) Риски с митигациями (минимум: что если нагрузочный тест выявит проблему на неделе 5; что если платёжный провайдер не поднимет лимит). 7) Критерии готовности (go/no-go чеклист перед ЧП) с измеримыми порогами. Будь честен с ограничением по людям и неделям: не назначай задачи отсутствующему инженеру и не нарушай code freeze.

Ты — Staff-инженер в SaaS-компании (B2B, ~80 инженеров, 12 продуктовых команд). Сейчас фиче-флаги хранятся как булевы поля в БД и хардкод-конфиги; нет таргетинга, постепенного раскатывания, аудита и A/B-экспериментов. Нужно принять решение build-vs-buy и обосновать его перед руководством, которое хочет цифры и риски, а не вкусовщину. Контекст и ограничения: 1. Нужны: серверные и клиентские (web + iOS/Android) флаги, percentage rollout, таргетинг по атрибутам (план тарифа, регион, версия приложения), kill-switch с задержкой распространения < 30 сек, аудит изменений, A/B-эксперименты со статистикой, локальная оценка флага без сетевого вызова на каждый чек (важно: горячий путь API < 5 мс p99). 2. Compliance: данные пользователей из ЕС не должны покидать ЕС; ряд флагов вычисляется по PII-атрибутам. 3. Масштаб: ~3 млрд вычислений флага в сутки, 12 команд хотят самообслуживание (не ходить к платформенной команде за каждым флагом). 4. Команда платформы: 4 инженера, уже перегружены; runway по бюджету ограничен, но есть деньги на SaaS-подписку. Кандидаты (ориентировочные данные): - BUY: коммерческий SaaS фиче-флагов (например уровня LaunchDarkly). Плюсы: SDK для всех платформ, local evaluation через стриминг правил, эксперименты, аудит, ролевой доступ. Минусы: цена растёт с MAU/семплов событий (грубо порядка десятков тысяч USD/год на нашем масштабе), вопрос data residency для PII, вендор-лок. - BUILD: своё решение поверх key-value стора + поллинг/стриминг правил + свой UI. Плюсы: полный контроль, данные в нашем ЕС-регионе, нет лицензий. Минусы: нужно с нуля сделать SDK для 3 платформ, эксперименты со статзначимостью, аудит, RBAC, надёжность kill-switch; оценочно 2-3 инженера на 6-9 месяцев + постоянная поддержка. - OPEN-SOURCE / self-host (например уровня Unleash/Flagsmith, self-hosted): среднее — готовый движок флагов и UI, хостим в своём ЕС-кластере (решает residency), но A/B-эксперименты со статистикой и часть SDK-фич слабее коммерческих, нужен свой ops. Дай: (1) рекомендацию (build / buy / open-source self-host / гибрид) с явным критерием решения; (2) разбор по КАЖДОМУ требованию — закрывает ли его выбранный вариант и как (особенно local evaluation < 5 мс, kill-switch < 30 сек, residency для PII, A/B-статистика, самообслуживание 12 команд); (3) грубую TCO-логику build vs buy на горизонте 2 лет (не точные цифры, а из чего складывается и где переломная точка); (4) явное отвержение отвергнутых вариантов; (5) план снижения вендор-лока / стратегию выхода; (6) что измеришь через 6 месяцев, чтобы понять, что решение было верным.

Ты — инженер по ИИ-платформе в продукте поддержки клиентов. В продукт встроен ассистент, который обрабатывает входящие запросы пользователей. Сейчас ВСЕ запросы идут в одну дорогую топовую модель — это качественно, но дорого и местами медленно. Нужно спроектировать политику маршрутизации между несколькими моделями, чтобы снизить стоимость и латентность, не уронив качество на сложных кейсах. Профиль трафика (по логам за месяц): - 1,2 млн запросов/мес. Распределение по типам: 55% — простые FAQ/шаблонные ответы; 25% — запросы средней сложности (нужен контекст из базы знаний, RAG); 12% — сложные многошаговые (рассуждение, расчёты, действия в системах через инструменты); 8% — чувствительные (жалобы, споры по платежам, юридически значимые ответы, эскалация к человеку). Кандидаты-модели (ориентировочные характеристики, $ за 1М токенов вход/выход): - SMALL: дешёвая быстрая модель. ~$0.15/$0.60. p50 латентность 400 мс. Хороша на FAQ, слабее на многошаговом рассуждении и инструментах. - MID: средняя модель. ~$1.0/$4.0. p50 латентность 900 мс. Хороша на RAG и умеренном рассуждении. - LARGE: топовая модель. ~$5.0/$20.0. p50 латентность 2.2 с. Лучшее качество на сложном рассуждении, инструментах, чувствительных формулировках. Ограничения и цели: 1. Бюджет нужно сократить минимум на 50% относительно 'всё в LARGE', без заметной деградации удовлетворённости (CSAT) на сложных и чувствительных запросах. 2. SLA: p95 ответа ассистента < 3 с для интерактивного чата. 3. Чувствительные запросы (8%) НЕ должны по ошибке уходить в SMALL и не должны автоматически давать юридически значимый ответ без эскалации/гардрейлов. 4. Маршрутизатор сам не должен стать дорогим/медленным узким местом. Спроектируй политику маршрутизации. Ответ должен включать: (1) как определяется класс/сложность запроса ДО выбора модели (дешёвый роутер, эвристики, классификатор) и почему именно так, с учётом того что роутер не должен быть дорогим; (2) таблицу маршрутизации тип запроса -> модель (с дефолтами и исключениями); (3) механизм эскалации/fallback: когда дешёвая модель 'не справилась' и нужно поднять запрос к более сильной модели, и как это не сломает SLA; (4) как закрываются чувствительные запросы (гардрейлы, человек-в-петле); (5) грубую прикидку экономии бюджета относительно 'всё в LARGE' с логикой расчёта; (6) что мониторить и как ловить деградацию качества при удешевлении.

Ты — ведущий SRE в платёжном финтех-сервисе. Junior-инженер подготовил черновой план релиза версии 4.2 на production-кластер (Kubernetes, 12 подов API, PostgreSQL 14 как основная БД, Redis для сессий, трафик ~3000 RPS в пике). Релиз обещан как zero-downtime. Вот его план дословно: 1. Применить миграцию БД: `ALTER TABLE payments DROP COLUMN legacy_status; ALTER TABLE payments ADD COLUMN status_v2 VARCHAR(32) NOT NULL DEFAULT 'pending';` — выполняется одной транзакцией на работающей БД. 2. Сразу после миграции выкатить новый код всех 12 подов одновременно (`kubectl set image`, стратегия Recreate), чтобы 'не держать две версии кода и не ловить рассинхрон'. 3. Новый код пишет в `status_v2` и больше не читает `legacy_status`. 4. Прогреть кэш Redis скриптом, который удаляет все ключи `FLUSHALL` и заполняет заново. 5. Если что-то сломалось — откатить образ подов на предыдущий и откатить миграцию командой `ALTER TABLE payments DROP COLUMN status_v2; ALTER TABLE payments ADD COLUMN legacy_status VARCHAR(32);`. 6. Проверку успешности делать вручную через 30 минут по дашборду. Твоя задача: провести критическую рефлексию этого плана и выдать исправленную версию. Для КАЖДОГО найденного изъяна укажи: (а) в чём именно проблема и к каким последствиям приведёт в production, (б) конкретную правку (что заменить, на что, с примером команды/подхода). В конце дай переработанный пошаговый план, совместимый с настоящим zero-downtime и безопасным откатом. Будь предельно конкретен — обобщённые советы вроде 'тестируйте лучше' не принимаются.

Ты — on-call инженер. Идёт разбор инцидента: после релиза выросла p99-латентность API. Другой инженер уже выполнил многошаговую диагностику и расчёт capacity, и на основе ШАГА 6 уже собирается ДЕЙСТВОВАТЬ — увеличить размер пула соединений к PostgreSQL на всех сервисах с 20 до 200. Вот его рассуждение дословно (числа сохранены как есть): Шаг 1. У нас 10 инстансов сервиса, на каждом пул БД = 20 соединений. Значит максимум 10*20 = 200 соединений к БД. Факт. Шаг 2. PostgreSQL настроен на max_connections = 200. Значит мы упираемся в потолок соединений. Факт. Шаг 3. Чтобы убрать узкое место, нужно, чтобы соединений хватало с запасом. Берём целевое число соединений на инстанс = max_connections / число_инстансов = 200 / 10 = 20... нет, нам нужно БОЛЬШЕ, поэтому возьмём по 200 на инстанс, итого нужно 10*200 = 2000 соединений. Шаг 4. Значит выставим max_connections = 2000 на PostgreSQL и pool_size = 200 на каждом инстансе. Шаг 5. Память: каждое соединение PostgreSQL стоит примерно work_mem. work_mem у нас 64MB. 2000 * 64MB = 128 GB. У сервера БД 128 GB RAM — значит ровно впишемся. Шаг 6. Вывод: ставим pool_size=200 и max_connections=2000, латентность уйдёт. Готов применять на prod. Твоя задача: прежде чем это уйдёт в prod, провести рефлексию по шагам. Найди, на каком ИМЕННО шаге появилась первая существенная ошибка (логическая или фактическая), объясни её, и покажи как она каскадно испортила последующие шаги. Затем откати рассуждение к последнему корректному шагу и проведи расчёт заново правильно. Дай корректный вывод: что на самом деле стоит проверить/сделать (с числами и обоснованием). Укажи также, какие ВХОДНЫЕ предпосылки (шаги 1-2) могли быть неверно проинтерпретированы.

Ты — дежурный SRE в B2B SaaS (биллинг-платформа). Прилетел алерт и расплывчатая жалоба от support: 'Часть клиентов периодически получает 502 при оплате, особенно по утрам, но не всегда, воспроизвести стабильно не удаётся. Иногда помогает повтор.' Больше НИЧЕГО не известно: нет трейса, неясно у каких клиентов, неясна доля запросов, неясно когда началось. Известна только топология: клиент -> CDN/WAF -> L7-балансировщик (nginx) -> сервис checkout (k8s, автоскейлинг 5-40 подов) -> вызывает внешний платёжный шлюз (сторонний API, есть таймауты) и пишет в PostgreSQL (через PgBouncer). Деплои бывают несколько раз в день. Метрики (Prometheus), логи (Loki), трейсы (Tempo) есть, но никто их ещё не смотрел. Задача: построй АДАПТИВНУЮ стратегию диагностики в условиях неполной информации. Требуется явно: (1) что выяснить В ПЕРВУЮ ОЧЕРЕДЬ и почему именно это (приоритизация по информационной ценности и стоимости проверки); (2) сформулируй конкретные ГИПОТЕЗЫ о причине (минимум 4-5), ранжированные по правдоподобности с учётом подсказок 'по утрам', 'не всегда', 'помогает повтор'; (3) для КАЖДОЙ гипотезы — каким конкретным сигналом/запросом/метрикой ты её ПОДТВЕРДИШЬ или ОПРОВЕРГНЕШЬ (decisive test), и какое наблюдение её исключает; (4) опиши ветвление: если первый чек показал A — куда идёшь дальше, если B — куда; (5) что НЕ делать преждевременно (антипаттерны реакции). Цель — минимальным числом проверок локализовать слой, где рождаются 502, не наугад.

Ты — техлид data-команды в e-commerce. Команда 6 недель строит аналитическую платформу. Архитектура уже частично реализована и работает в dev: - Сырые события (клики, заказы, профили) льются из бэкенда в Kafka, оттуда raw-копия складывается в S3 (data lake) БЕЗ преобразований, включая email, телефон, адрес, IP. - Из S3 ночной Spark-джоб грузит всё в облачный DWH (Snowflake), одна большая денормализованная таблица events_flat, доступ к которой есть у всех 40 аналитиков и у 3 BI-дашбордов. - Уже написано ~50 SQL-моделей в dbt поверх events_flat. На них завязаны 12 продуктовых дашбордов, которыми пользуется маркетинг. - ETL, схемы, права доступа, ретеншн (хранение вечное) — всё уже закоммичено. Сегодня прилетело новое жёсткое требование от Legal/DPO, обязательное к исполнению через 3 недели: (1) PII (email, телефон, адрес, IP, точная геолокация) НЕ должны попадать в data lake и DWH в открытом виде; (2) аналитики по умолчанию не должны видеть PII, доступ — только по обоснованию и аудиту; (3) право на удаление (right to erasure): по запросу пользователя его персональные данные должны удаляться отовсюду за 30 дней, включая бэкапы/исторические копии; (4) ретеншн сырых событий с PII — максимум 90 дней. Задача: сделай ре-планнинг проекта так, чтобы выполнить требование с МИНИМАЛЬНЫМИ потерями уже сделанной работы и без срыва маркетинговых дашбордов. Явно укажи: (а) какие конкретные части текущей архитектуры/работы придётся выбросить или переделать и почему; (б) что можно сохранить как есть; (в) новый целевой пайплайн по шагам; (г) как технически обеспечить erasure и ретеншн при наличии immutable-копий в S3 и бэкапов Snowflake; (д) план миграции на 3 недели с порядком работ и тем, что заморозить/откатить уже сейчас, чтобы не накапливать долг.

Дан Python класс — token bucket rate limiter: ```python import time import threading from dataclasses import dataclass @dataclass class RateLimiter: capacity: int # макс. tokens в bucket refill_rate: float # tokens в секунду _tokens: float = 0.0 _last_refill: float = 0.0 _lock: threading.Lock = None def __post_init__(self): if self.capacity <= 0: raise ValueError('capacity must be positive') if self.refill_rate <= 0: raise ValueError('refill_rate must be positive') self._tokens = float(self.capacity) self._last_refill = time.monotonic() self._lock = threading.Lock() def _refill(self) -> None: now = time.monotonic() elapsed = now - self._last_refill self._tokens = min(self.capacity, self._tokens + elapsed * self.refill_rate) self._last_refill = now def try_acquire(self, n: int = 1) -> bool: if n <= 0: raise ValueError('n must be positive') if n > self.capacity: raise ValueError('n exceeds capacity') with self._lock: self._refill() if self._tokens >= n: self._tokens -= n return True return False def acquire(self, n: int = 1, timeout: float | None = None) -> bool: deadline = None if timeout is None else time.monotonic() + timeout while True: if self.try_acquire(n): return True with self._lock: deficit = n - self._tokens wait = deficit / self.refill_rate if deadline is not None: remaining = deadline - time.monotonic() if remaining <= 0: return False wait = min(wait, remaining) time.sleep(wait) ``` Напиши ПОЛНОЕ покрытие на pytest. Требования: 1. Конфигурация: используй фикстуры (в т.ч. с разными параметрами через `params=`). 2. Используй `freezegun` ИЛИ замоканный `time.monotonic` (через monkeypatch) для детерминированных тестов времени — без реального `time.sleep` в большинстве тестов. 3. Параметризуй negative cases (invalid capacity/rate/n). 4. Тесты на: - начальное состояние (bucket полный), - try_acquire успешный / неуспешный, - постепенный refill (после X секунд доступно Y tokens), - cap на capacity (не превышается), - acquire с timeout=0 эквивалентен try_acquire, - acquire с timeout, который недостаточен → False, - acquire с достаточным timeout → True, - thread-safety: 100 потоков одновременно — сумма успешных acquire не превышает refilled capacity (этот тест может быть real-time, маркируй `@pytest.mark.slow`). 5. Используй `pytest.approx` для float сравнений. 6. Минимум 15 тестов, organize via class или namespacing.