Завышенные цели по uptime вредят малому бизнесу

Почему скопированные цифры по uptime вредят

99,99% красиво смотрится на странице продаж или в договоре. Это звучит почти как идеал, и многие основатели копируют такую цифру, не задумываясь, что за ней стоит.

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

Четыре девятки дают примерно 52 минуты простоя в год. А это почти не оставляет места для неудачного релиза, проблем с базой данных, сбоя в облаке или пропущенного ночного оповещения в выходные. Крупные вендоры добиваются такого результата с дежурствами, инструкциями на случай инцидентов, поэтапными выкладками и командами, которые реально тратят время на операционную работу. У маленькой компании часто один человек одновременно занимается продуктом, поддержкой и инфраструктурой в течение одной и той же недели.

Именно поэтому скопированные enterprise-цели по uptime так часто дают обратный эффект. Покупатель спрашивает про цифру доступности, или основатель заимствует формулировку у более крупного вендора, и 99,99% кажется самым безопасным ответом. Обычно всё наоборот. Если команда это не обеспечила людьми, не протестировала и не заложила в бюджет, обещание становится ловушкой.

Маленькие команды всё равно могут работать надёжно. Просто им нужно делать это осознанно. Oleg Sotnikov показал, что небольшая AI-усиленная команда может держать почти идеальный uptime благодаря продуманной архитектуре и дисциплине в операциях. Такой результат появился благодаря дизайну, тренировкам и непростым решениям, а не из-за копирования строки SLA у гигантской компании.

Сломанное обещание наносит больше вреда, чем скромное, но честное. Клиентам действительно важен простой, но ещё больше их волнует то, что происходит во время него. Могут ли они всё же сделать то единственное действие, ради которого пришли? Получают ли они быстрое обновление? Кто-то явно отвечает за проблему?

Большинство людей не запомнят, было у вас 99,9% или 99,99%. Они запомнят молчание, медленные ответы и обещание, которое вы не смогли выполнить.

Как простои ощущаются для клиентов

Клиенты не воспринимают простой в процентах. Они ощущают его как заблокированный момент.

Покупатель не может завершить оплату. Пользователь не может войти перед встречей. Пациент не может подтвердить запись. Именно первое сломанное действие важнее любого бейджа с uptime, потому что это первая точка, где доверие начинает падать.

Замедление и полная остановка — это разные проблемы. Если страницы загружаются за 12 секунд, люди раздражаются, обновляют страницу и, возможно, пробуют снова. Если вход не работает или на оплате появляется ошибка, они останавливаются. Кто-то уходит на день. Кто-то — навсегда.

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

Начните с простого списка влияния:

• Кто сразу теряет деньги, например клиенты, которые застряли на оплате
• Кто теряет время, например сотрудники, которые не могут открыть расписание или файлы
• Кто может немного подождать, например пользователи, читающие старые отчёты или просматривающие прошлые заказы

Это меняет взгляд на простой. Система бронирования, которая упала в 2 часа ночи, может быть просто раздражающей. Тот же самый сбой в 9 утра для расписания клиники или салона может вызвать пропущенные записи, перегрузку телефонов и возвраты денег. Программное обеспечение не изменилось. Изменилось влияние.

Также полезно разобрать первые пять минут проблемы. Что видит клиент: сообщение об ошибке, крутящуюся страницу, пропавшие данные или вообще ничего? Каждый вариант создаёт свой тип стресса. «Медленно» раздражает. «Неверно» пугает. «Пропало» заставляет искать другой вариант.

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

Начинайте с тех действий, которые клиентам нужны больше всего

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

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

Используйте три простых критерия, когда расставляете приоритеты:

• Какое действие быстрее всего приносит деньги
• Какое действие вызывает больше всего обращений в поддержку, если ломается
• Какое действие сильнее всего вызывает стресс или риск срыва дедлайна у клиентов

Это упражнение часто меняет порядок, которого ожидает команда. Внутри компании дашборд может казаться центральным, но клиентам куда важнее отправить форму или завершить оплату. Именно это действие нужно восстанавливать первым.

Чёткий порядок восстановления помогает в первый шумный час инцидента. Команда перестаёт спорить о том, что кажется срочным, и сначала чинит самое болезненное. Это важнее, чем копировать enterprise-цели по uptime, которые звучат впечатляюще, но не совпадают с тем, как реально работает маленькая команда.

Менее важной работе нужна более медленная цель. Это нормально. Клиенты обычно нормально принимают, что настройки аккаунта, выгрузки или историческая аналитика могут подождать дольше, чем платежи или обработка заказов. Их раздражает, когда всем функциям обещают одинаковый срок, а команда всё равно его не выдерживает.

Вот где планирование времени восстановления становится практичным. Защищайте то действие, за которое клиент платит. Защищайте то, что ему нужно сегодня. Менее срочные вещи могут восстановиться позже.

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

Ставьте цели восстановления, которые ваша команда действительно потянет

Цели восстановления должны соответствовать той команде, которая у вас есть, а не той, которую вы хотели бы иметь. Если вы копируете enterprise-цели по uptime у крупного вендора, вы часто обещаете такие сроки реакции, которые работают только при круглосуточной смене, формальном графике дежурств и запасных людях на подмену.

Малому бизнесу нужны более простые цели. Выбирайте сроки, которые в первую очередь защищают клиента. Один таймер должен отвечать за подтверждение. Другой — за восстановление того единственного действия, которое важно клиенту, например входа, отправки счёта или оплаты заказа.

Обычно это означает, что нужно принять четыре решения:

• Как быстро кто-то подтвердит проблему и сообщит клиентам, что вы ею занимаетесь
• Как быстро вы вернёте самое важное действие, даже если весь продукт пока работает с ограничениями
• Когда команда перестаёт пытаться чинить всё сразу и переходит на ручной обходной вариант
• Кто реально доступен в рабочие часы, вечером, по выходным и в праздники

Состав команды важнее, чем многие основатели ожидают. Если один разработчик и один основатель делят поддержку, обещание подтверждать проблему в течение 15 минут в любое время суток нереалистично. Честнее может быть обещание в течение часа в рабочее время и более медленный ответ на выходных — и это всё равно может хорошо восприниматься клиентами.

У ручных обходных вариантов тоже должен быть свой срок. Если ломается платёжный поток, ждать три часа, прежде чем кто-то начнёт принимать заказы по электронной почте, часто слишком долго. Решите заранее, когда команда переключается в резервный режим. Для многих маленьких команд это 30–60 минут после начала инцидента, в зависимости от функции и влияния на клиентов.

Специально делайте цели неравномерными. Не нужно восстанавливать каждую страницу или каждый административный инструмент с одинаковой скоростью. Самую короткую цель ставьте на то действие, которое помогает клиенту продолжать работу. Второстепенным частям можно дать больше времени.

Именно здесь lean-команды обычно выигрывают у слишком амбициозных обещаний. Полезное обещание — это то, которое ваш реальный персонал сможет выполнить в плохой день, полусонным, когда один человек недоступен. Клиенты прощают простои легче, чем невыполненные обещания.

Как написать обещание, которое вы сможете выполнить

Начинайте с фактов, а не с надежды. Поднимите последние несколько инцидентов и прочитайте их от начала до конца. Сначала не обращайте внимания на спокойные недели. Вам нужны именно сложные дни, потому что именно там проверяется обещание.

Посмотрите, на что на самом деле уходило время. Многие команды знают, сколько занимает перезапуск, но ни разу не засекали восстановление, откат или эскалацию к поставщику. Поставьте таймер на каждый шаг. Если восстановление из резервной копии занимает 90 минут, а ответ от вашего облачного провайдера приходит через 40, обещание на 30 минут — это выдумка.

Обычно достаточно такого простого разбора:

• Сколько времени заняло обнаружение?
• Сколько времени заняло первое сообщение клиенту?
• Сколько заняли восстановление или откат?
• Сколько заняла помощь со стороны?
• Что именно замедлило команду?

После этого напишите одно короткое обещание простым языком. Уберите вылизанный юридический тон и цифры, скопированные у крупных вендоров. Клиентам гораздо важнее, что вы будете делать, когда что-то сломается, чем показатель uptime, который звучит эффектно, но мало что значит во время настоящего сбоя.

Хорошее обещание звучит так: «Если наше приложение упадёт, мы опубликуем обновление в течение 15 минут, сохраним основные данные и постараемся вернуть нормальную работу в течение 2 часов». Оно короткое, понятное и привязано к действиям, которые ваша команда может контролировать.

Напишите первое сообщение клиенту заранее, пока оно ещё не нужно. Сделайте его простым. Скажите, что затронуто, что ещё работает, что вы делаете сейчас и когда будет следующее обновление. Этот черновик экономит время, когда стресс высокий и люди начинают гадать.

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

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

Пример: SaaS-команда из трёх человек

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

Именно здесь скопированные enterprise-цели по uptime и создают проблемы. Если команда публикует обещание, которое звучит больше, чем её реальное покрытие, клиенты будут ожидать мгновенной реакции в 2 часа ночи в воскресенье. Когда никто не отвечает, цифра на странице статуса перестаёт помогать.

Лучше обещание, которое соответствует тому, что команда действительно может сделать. В рабочие часы они отправляют обновление каждый час, пока проблема не станет стабильной или не будет исправлена. Это звучит скромно, но клиенты часто ценят понятные обновления больше, чем эффектный показатель uptime.

Они также задают чёткий порядок восстановления. Сначала возвращают вход, чтобы клиенты могли попасть в аккаунты. Затем возвращают платежи, чтобы деньги продолжали двигаться. Отчёты и выгрузки тоже важны, но большинство клиентов может немного подождать с ними, если основная цепочка действий уже работает.

Один ручной запасной вариант может спасти много доверия. Если у клиента срочный платёжный запуск или нужно подтвердить доступ для живого продажного звонка, команда держит простой резервный процесс наготове. Это может означать ручное создание ссылки на оплату, выгрузку одной записи из резервного инструмента или выполнение небольшой задачи за клиента, пока продукт догоняет.

Такое обещание меньше, но оно честное. Оно говорит клиентам, что произойдёт, кто ответит и какие части сервиса вернутся первыми.

Для небольшой команды это обычно работает лучше, чем погоня за enterprise-целями по uptime. Клиенты легче прощают короткий простой, чем молчание, путаницу или обещание, на которое у команды никогда не было достаточно людей.

Ошибки, которые ломают доверие

Доверие часто ломается ещё до окончания сбоя. Оно ломается, когда клиенты видят разрыв между тем, что вы обещали, и тем, что ваша команда реально может сделать в плохой день.

Одна частая ошибка — взять цель по uptime у облачного вендора и вставить её в свои условия. Маленькая компания читает «99,99%» и думает, что это звучит серьёзно. Клиенты читают это как обещание. Если завис платёжный процессор, перестала отправляться почта или у хостинга возникла проблема, клиенты всё равно считают ответственным вас, потому что купили у вас.

Та же проблема возникает и с обещаниями по реакции. Если один основатель носит с собой телефон, обещание отвечать 24/7 трудно воспринимать всерьёз. Люди спят, ездят, болеют и пропускают уведомления. Более скромное обещание, которое вы выполняете всегда, вызывает гораздо больше доверия, чем большое, которое ломается уже в первые выходные.

Ещё одна ошибка скрывается в том, как команды измеряют надёжность. Они считают uptime каждый месяц, но ни разу не засекали восстановление из резервной копии. Потом случается реальный инцидент, и они узнают, что резервная копия медленная, неполная или восстанавливается сложнее, чем они думали. Планирование времени восстановления важнее, чем аккуратный процент на дашборде.

Молчание быстро убивает доверие. Команды часто слишком долго ждут, прежде чем сказать клиентам, что сломалось, потому что сначала хотят полный ответ. Эта задержка заставляет людей думать о худшем. Если вход не работает, платежи остановились или данные выглядят пропавшими, клиентам нужно короткое обновление простым языком. Скажите, что затронуто, что всё ещё работает и когда вы выйдете на связь снова.

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

Быстрая проверка перед публикацией

Обещание может выглядеть надёжным в спокойный день. Проблемы начинаются, когда один человек заболел, второй на звонке с клиентом, а третий в 8:10 утра получает сообщение о настоящем сбое. Если ваша команда не может выдержать обещание под таким давлением, формулировка слишком амбициозна.

Перед публикацией всего, что связано с uptime, поддержкой или восстановлением, пройдитесь по пяти проверкам:

• Может ли ваша команда выполнить обещание в плохой день с точки зрения состава, а не только когда все доступны?
• Знаете ли вы своё последнее протестированное время восстановления, основанное на реальной тренировке, а не на догадке?
• Знает ли поддержка первое действие, которое нужно сделать, когда приходит сообщение о проблеме?
• Знают ли клиенты, когда они получат первое обновление, даже если полного решения у вас ещё нет?
• Тренировали ли вы этот план в прошлом квартале?

Эти вопросы кажутся базовыми, но они быстро выявляют слабые обещания. Многие команды публикуют на сайте аккуратное обещание простоя для малого бизнеса, а в реальности оно рассыпается, потому что никто не проверял скорость восстановления, никто не решил, кто отправляет первое обновление, или поддержка вместо первого шага начинает спрашивать по кругу.

Тренируйте не идеальную версию дня, а неприятную. Если ваше последнее восстановление заняло 2 часа 40 минут, не обещайте восстановление за 30 минут. Если поддержке нужно 15 минут, чтобы подтвердить масштаб и открыть канал инцидента, скажите клиентам, что первое обновление будет через 20 минут, а не «немедленно». Чёткие сроки вызывают больше доверия, чем раздутые обещания.

Помогает простая тренировка. Выберите один вероятный инцидент, например неудачный релиз или сломанную миграцию базы данных. Засеките восстановление. Засеките первое сообщение клиенту. Посмотрите, где люди начинают сомневаться. Если никто не знает, кто отвечает за обновления статуса, реагирование на инциденты для стартапов ещё не закончено.

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

Что делать дальше, чтобы обещание было меньше, но сильнее

Если вы взяли enterprise-цели по uptime у более крупной компании, сначала сократите их. Большинству маленьких команд не нужен публичный обещанный процент, построенный вокруг огромной цифры. Им нужно обещание, которое защищает несколько ключевых действий клиента, и план восстановления, который реально можно выполнить, когда что-то ломается в 2 часа ночи.

Начните с одной страницы. Сделайте её простой. Основатель, инженер или руководитель поддержки должен понять её меньше чем за пять минут. Если страница кажется длинной, скорее всего она пытается выглядеть впечатляюще, а не быть полезной.

Добавьте на эту страницу:

• Два или три самых важных действия клиента, например вход, оплата или выгрузка данных
• Срок восстановления для каждого действия, которого ваша команда сможет добиться под давлением
• Одного ответственного за техническое восстановление и одного ответственного за сообщения клиентам
• Два или три шаблона сообщений для статуса, задержки и подтверждения восстановления

Одна такая страница делает для доверия больше, чем скопированный бейдж uptime. Клиенты обычно прощают короткий простой. Они злятся, когда никто не объясняет, что происходит, или когда у команды явно нет плана.

Потом запланируйте тренировку на этот месяц. Возьмите простой сбой, например проблему с базой данных или сломанный вход, и отработайте его 30 минут. Засеките реакцию. Посмотрите, кто замечает первым, кто отправляет обновление и сколько времени уходит на восстановление самого важного действия.

Сразу после тренировки сделайте короткий разбор. Будьте честны. Какой срок восстановления выглядел реальным, а какой — только на бумаге? Какое сообщение звучало понятно, а какое бы запутало платящего клиента? Исправьте страницу в тот же день, пока детали ещё свежие.

SaaS-команда из трёх человек может сделать это за один день. Этого достаточно, чтобы заменить слабое обещание на такое, которое ваша команда действительно сможет выполнить.

Если вам нужен взгляд со стороны, Oleg Sotnikov из oleg.is помогает стартапам и небольшим командам решать такие задачи через Fractional CTO advisory. Свежий взгляд быстро замечает слабые допущения, особенно когда команда уже привыкла к собственным пробелам.