Как объяснить бизнесу, за что платим в мае, если пик в декабре

MAATRIX

Технический план готов, цифры посчитаны, счёт на нагрузочное тестирование и резервирование мощности лежит на подписи — а руководитель смотрит на дату и спрашивает: «У нас распродажа в декабре, почему я плачу за это в мае?» Вопрос звучит наивно только для инженера. Для человека, который отвечает за бюджет, разрыв в семь месяцев между тратой и событием, ради которого её просят одобрить, — это не техническая деталь, а нормальный повод усомниться. Ниже — не про то, как считать мощность (это отдельная методика с формулами), а про то, как продать эти цифры человеку, который формулами не мыслит.

Почему разрыв между тратой и событием пугает бизнес больше, чем сама сумма

Нетехническому руководителю привычна логика «заплатил — получил»: купил рекламу — пошли заявки, нанял продавца — выросли продажи. Расходы на готовность к пику в эту логику не укладываются, потому что результат не наступает в момент оплаты. Вы платите в мае за нагрузочное тестирование, а эффект от него проявится (или не проявится — и это тоже результат) только в декабре, когда всё либо выдержит нагрузку, либо нет. Семь месяцев тишины между тратой и подтверждением того, что трата была не зря, — это и есть источник вопроса, а не жадность или недоверие к техническому отделу.

Второй источник путаницы — то, что расходы на подготовку выглядят как расходы на «сам пик», хотя это разные вещи. Пиковая мощность, которую вы включите на неделю в декабре, действительно стоит денег именно в декабре — и эту логику руководитель понимает сразу, потому что она симметрична: включили — заплатили, выключили — перестали платить. А вот тестирование, настройка мониторинга, аудит узких мест, время инженера на подготовку сценария масштабирования — это расходы на снижение риска, а не на саму мощность, и происходят они заранее ровно потому, что заранее — единственное время, когда с найденной проблемой можно что-то сделать. Если объяснять оба вида расходов одной фразой «готовимся к декабрю», собеседник закономерно спрашивает, почему тогда нельзя всё сделать в декабре разом.

Разделите эти два бюджета явно, в разговоре и в самой смете: «мощность на пик» — переменная статья, которая появляется и исчезает вместе с нагрузкой, и «работа по снижению риска» — фиксированная статья, которая должна быть закрыта до того, как нагрузка придёт, потому что после уже поздно. Как только собеседник видит, что это два разных вопроса с двумя разными ответами на «почему сейчас», спор из «зачем вообще платить» превращается в «сколько именно нужно на вторую часть» — а это уже предметный разговор, а не эмоциональный.

Аналогия, которая работает лучше графиков: генеральная репетиция

Графики нагрузки, percentile-метрики и формулы окупаемости прекрасно работают с техническим директором и почти не работают с человеком, который отвечает за деньги, но не читает мониторинг. Ему нужна не более точная цифра, а понятная модель происходящего — и здесь помогает не метафора «страховки» (у страховки плохая репутация: платишь и почти всегда ничего не получаешь взамен, руководитель это уже проходил с другими статьями бюджета), а модель генеральной репетиции перед премьерой.

Никто не считает странным, что театр репетирует за недели до премьеры, хотя зрители придут только в день спектакля. Репетиция не переносит премьеру на более раннюю дату и не заменяет её — она делает премьеру предсказуемой: находит место, где актёр забывает текст, декорация не успевает смениться, свет включается не вовремя, пока это ещё можно поправить без зрителя в зале. Нагрузочное тестирование — та же репетиция, только для инфраструктуры: вы находите узкое место (база не держит параллельные заказы, очередь задач переполняется при всплеске, кеш не успевает прогреться) не в момент, когда на сайте тысяча человек одновременно оформляют заказ, а за месяцы до этого, когда цена ошибки — час работы инженера, а не потерянные продажи и разъярённые клиенты в соцсетях.

Расширьте аналогию до денег — и она закроет сам вопрос о времени оплаты: репетиции стоят денег задолго до того, как театр продаст первый билет, и никто не предлагает отрепетировать спектакль за день до премьеры ради экономии на зале. Прогон делают заранее не потому, что так удобнее бухгалтерии, а потому что только заранее у найденной проблемы есть время на исправление. Если нагрузочный тест находит, что база падает при трёхкратном росте заказов, за неделю до пика это повод для паники и латания дыр в бою, а за два-три месяца — спокойное исправление, повторный тест и проверка, что оно сработало.

Из чего реально состоит счёт за готовность и почему его нельзя двигать на декабрь

Когда руководитель спрашивает «за что конкретно я плачу», отвечать общей фразой «за подготовку инфраструктуры» — то же самое, что не отвечать. Разложите счёт на конкретные статьи и для каждой явно скажите, почему её нельзя сделать в последнюю неделю перед пиком:

• Нагрузочное тестирование. Время инженера на подготовку сценария, инструменты, анализ результатов и повторный прогон после исправлений. Нельзя провести за неделю до пика — найденная проблема требует времени на исправление и повторную проверку, а тест в последний момент это время убирает.
• Резервирование мощности у провайдера. У части хостеров гарантия наличия нужной конфигурации в моменты массового спроса требует раннего бронирования, а не заявки в моменте: к декабрю нужная конфигурация может быть просто занята другими клиентами, которые тоже готовятся к своему пику.
• Настройка мониторинга и алертов под пиковые профили. Обычные пороги алертов рассчитаны на обычную нагрузку и на пике либо молчат, когда уже плохо, либо заваливают команду ложными тревогами. Делать эту настройку в разгар пика уже некогда: команда должна тушить пожары, а не настраивать систему, которая должна была их предсказать.
• Устранение найденных узких мест. Самая крупная и непредсказуемая по времени статья: пока не проведено тестирование, неизвестно, что потребует доработки — индекс в базе, кеширование, конфигурация балансировщика, кусок кода с блокировкой. Именно поэтому тестирование должно случиться за месяцы, а не за дни до пика.
• Формализация процесса масштабирования и отката. Кто поднимает мощность, по какому сигналу, кто и когда её понижает после пика — без этого решения принимаются в панике, а мощность после пика часто просто забывают вернуть (отдельная и частая проблема, разобрана в статье о том, почему на даунгрейд тарифа после пика редко решаются вовремя).

Каждая из этих статей объединена одним свойством: их цена радикально растёт, если делать их не заранее, а в моменте. Час инженера на анализ теста в сентябре стоит как час инженера. Тот же час в разгар декабрьского пика, когда параллельно нужно тушить реальный инцидент, стоит либо сорванной продажи, либо срочного найма подрядчика по завышенной цене, либо того и другого сразу.

Возражение «зачем платить сейчас, если распродажа только в декабре» — и три ответа

Это самое частое возражение, и отвечать на него нужно не «потому что так положено», а конкретной механикой, которую собеседник может проверить сам.

Ответ первый: то, что вы покупаете в мае, — не мощность, а время на исправление ошибок. Мощность на пик вы действительно купите (или включите) в декабре, и платить за неё раньше срока никто не предлагает. А вот время на то, чтобы найти и исправить проблему до того, как её увидят клиенты, — ресурс, который в декабре уже не купить ни за какие деньги: там оно физически заканчивается вместе с приближением даты пика.

Ответ второй: та же самая работа в декабре стоит дороже, а не дешевле. В высокий сезон дорожает всё, что связано со срочностью: подрядчики берут больше за экспресс-работу, у провайдера может не быть свободной конфигурации без ожидания, инженерам приходится работать сверхурочно. Подготовка в мае и та же подготовка в декабре — разные цены за одну и ту же работу, и вторая почти всегда выше.

Ответ третий: неготовность имеет собственную цену, и она наступает независимо от того, платили вы за подготовку или нет. Час простоя или деградации сайта именно в пиковый день — это не абстрактный риск, а конкретные потерянные продажи, отток клиентов к конкуренту, у которого сайт в этот момент работает, и штрафы по SLA, если они прописаны в договорах с крупными клиентами. Механика того, во что реально обходится час простоя именно у SaaS- и e-commerce-бизнеса, разобрана отдельно — «Час простоя SaaS: потери, отток и штрафы по SLA», и эту цифру полезно принести на разговор с руководством: сумма подготовки почти всегда меньше, чем цена одного плохого часа в декабре, но без этого сравнения руководитель видит только расход в мае и не видит риск, который этот расход снимает.

Возражение «облако само масштабируется, зачем готовиться заранее»

Второе по частоте возражение звучит технически подкованно и от этого сложнее для спора: «у нас же облако, оно масштабируется автоматически, зачем платить за подготовку заранее». Это распространённое и почти всегда неверное представление о том, как работает облачная инфраструктура — у автомасштабирования есть пределы по скорости реакции, по квотам провайдера и по тому, успевает ли за новыми серверами масштабироваться база данных и всё, что стоит позади балансировщика. Подробный разбор того, где именно ломается миф о мгновенном и бесконечном масштабировании облака, — в статье «Миф: облако масштабируется мгновенно и бесконечно», и её стоит держать под рукой для разговора с собеседником, который решил, что слово «облако» снимает вопрос подготовки целиком.

Короткая версия: автомасштабирование хорошо решает задачу «добавить ещё один похожий сервер», но не решает задачу «база данных не успевает обработать втрое больше запросов» или «код ломается при параллельной нагрузке независимо от числа серверов». Именно эти проблемы находит нагрузочное тестирование заранее — и именно их автомасштабирование само по себе не чинит.

Как перевести подготовку в цифры, которые слышит финансист

Финансовому директору убедительнее не список технических работ, а сравнение двух сумм: во сколько обходится подготовка и во сколько обходится её отсутствие. Для первой суммы у вас уже должна быть точная методика расчёта самой пиковой мощности — постоянный апгрейд тарифа против временного масштабирования на дни пика, с формулой точки окупаемости и всеми скрытыми статьями расходов разобраны отдельно в статье «Мощность на одну неделю: как вырасти и не переплатить за год». Разведите две статьи в разговоре с финансистом явно: там — методика расчёта самих цифр, здесь — как уже посчитанные цифры представить и защитить перед тем, кто решает, подписывать смету или нет.

Практическая последовательность для разговора с финансами:

1. Посчитайте технические цифры по методике из статьи про экономику краткосрочного масштабирования — сколько стоит сама пиковая мощность на дни пика и сколько отдельно стоит подготовка.
2. Оцените (хотя бы грубо, с оговоркой, что это ориентир) цену одного плохого часа в пик — по логике из статьи про стоимость простоя SaaS: сколько заказов проходит через сайт за час в обычный день и что происходит с этим числом в день пика при том же чеке.
3. Сравните сумму подготовки с ценой одного плохого часа, а не с общей выручкой распродажи — сравнение с оборотом всего мероприятия даёт ничтожную на вид долю и ослабляет аргумент, а один плохой час — реалистичный сценарий при неготовности, а не гипотетический провал всей распродажи.
4. Покажите обе суммы рядом, без округления в свою пользу. Если подготовка стоит заметно дороже — скажите об этом честно; возможно, часть работ стоит сократить, и это разговор о приоритетах, а не о том, готовиться в принципе или нет.

Такой разговор — не про то, чтобы дожать бюджет любой ценой, а про то, чтобы решение принималось на основе сопоставимых цифр, а не на основе того, кто громче и увереннее говорил на совещании.

Как избежать этого разговора заново каждый год

Если разговор про «зачем платить в мае» повторяется перед каждым сезонным пиком заново, это симптом того, что подготовка к пику существует как разовый проект, а не как повторяющаяся строка бюджета. Три вещи закрывают этот вопрос системно, а не разовым убеждением:

• Заведите подготовку к пику отдельной строкой в годовом бюджете, а не частью общего ИТ-бюджета «на всякий случай». Отдельная строка с историей за прошлые годы (сколько стоило, что нашли на тестировании, что случилось бы без подготовки) убеждает лучше любого разового аргумента.
• Зафиксируйте календарь подготовки как повторяющийся процесс, привязанный не к дате пика, а к тому, за сколько месяцев до него должен начаться каждый этап: тестирование — за два-три месяца, устранение найденных проблем — сразу по итогам с контрольным сроком, финальная проверка и резервирование мощности — за несколько недель. Когда даты повторяются из года в год, вопрос «почему именно сейчас» больше не возникает.
• После каждого пика фиксируйте результат в цифрах, а не в ощущениях: сколько проблем нашло тестирование, какой была реальная нагрузка против прогноза, был ли простой и во что он обошёлся бы без подготовки. Этот отчёт — тот самый прецедент, который в следующем году избавляет от необходимости объяснять всё заново с нуля.

Частые вопросы