У нас же есть бэкап

У нас же есть бэкап

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

Мы собрали 4 реальных историй из практики UKVED — про серверы, которые «вдруг» легли, и мобильные приложения, которые «вдруг» перестали приносить деньги. Все суммы — настоящие. Все ошибки — типовые. И, что самое неприятное, повторяющиеся из компании в компанию.

История 1. Бэкап был. Восстановиться не получилось. Убыток — 4,7 млн
Сфера: интернет-магазин товаров
Оборот: около 25 млн в месяц

У компании был сервер с 1С, базой клиентов и интеграцией с сайтом. Системный администратор уверял: «Бэкапы делаются каждую ночь, всё под контролем». Так оно и было — формально. Бэкапы действительно создавались и складывались на тот же самый сервер, на соседний диск.

В один из понедельников вышел из строя RAID-контроллер. Данные на обоих дисках оказались повреждены. Бэкапы — тоже.

Что произошло дальше:

- сайт лёг на 9 дней (пока восстанавливали данные у специалистов по recovery);
- удалось вытащить около 70% базы клиентов и заказов;
- 4 дня магазин вообще не принимал заказы;
- ещё 5 дней работал «на коленке» в Excel;
- часть клиентов ушла к конкурентам, часть потребовала возврат предоплат.

Итог: прямые убытки 4,7 млн рублей плюс репутационные потери, которые до конца так и не оценили.

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

История 2. Сервер «не выдержал» чёрной пятницы. Минус 2,1 млн за сутки
Сфера: онлайн-школа
Аудитория: около 80 000 пользователей

К чёрной пятнице компания подготовила мощную рекламную кампанию: таргет, email-рассылка, блогеры. В день старта на сайт зашло в 12 раз больше людей, чем обычно.

Сервер не выдержал. Сайт открывался по 40–60 секунд, форма оплаты падала, личный кабинет не грузился. Через 2 часа техподдержка добавила мощностей, но к этому моменту трафик уже схлынул — люди ушли.

Что выяснилось при разборе:

- сервер был настроен «как 5 лет назад», без автомасштабирования;
- база данных не оптимизирована, тяжёлые запросы клали всё подряд;
- мониторинга нагрузки не было — техподдержка узнала о проблеме от клиентов в соцсетях;
- нагрузочное тестирование перед акцией никто не проводил.

Итог: по расчётам компании, в день акции они потеряли около 2,1 млн рублей выручки. Плюс 600 000 рублей рекламного бюджета, который сжёг трафик, не дошедший до оплаты.

Причина: инфраструктура не была подготовлена к пиковым нагрузкам, отсутствовал мониторинг и план масштабирования.

История 3. Мобильное приложение «съело» базу клиентов из-за одного апдейта
Сфера: служба доставки
База: 35 000 активных пользователей

Команда выкатила обновление приложения с новым дизайном и «улучшенной авторизацией». Обновление прошло автоматическое тестирование, было выложено в сторы.

Через сутки начался шквал отзывов: пользователи не могли войти в свои аккаунты. У части клиентов «слетели» бонусы и история заказов. У некоторых приложение вообще вылетало при запуске.

Что произошло:

- в новой версии изменили схему хранения токенов авторизации;
- миграция старых данных была написана с ошибкой;
- откатиться быстро не получилось — App Store модерировал «исправление» 36 часов;
- в Google Play откат прошёл быстрее, но 40% пользователей iOS остались с поломанным приложением.

Итог за неделю:

- средний чек упал на 28%;
- 4 200 пользователей удалили приложение;
- средний рейтинг в сторах рухнул с 4,7 до 3,2;
- потери выручки за месяц — около 3,4 млн рублей;
- ещё около года ушло на восстановление рейтинга и метрик.

Причина: не было процесса staged rollout (поэтапного раскатывания обновлений), отсутствовал план отката, миграция данных не была покрыта тестами.

История 4. Мобильное приложение работало. А вот платежи — нет
Сфера: сервис аренды самокатов
Пользователей: 60 000

В приложении работало всё: карта, бронирование, кнопка «оплатить». Только оплата у части пользователей не проходила — деньги списывались, но статус поездки оставался «не оплачено». Часть пользователей платила повторно, часть — писала гневные отзывы, часть просто уходила.

Проблема была в интеграции с платёжным шлюзом: вебхуки об успешной оплате приходили с задержкой 10–40 секунд, а приложение ждало ответ только 5 секунд и считало платёж неуспешным.

Баг существовал примерно 4 месяца, прежде чем кто-то догадался проверить, почему растёт количество жалоб.

Итог:

- около 18 000 «двойных» списаний за период;
- возвраты на 2,3 млн рублей;
- комиссия эквайринга за возвраты — ещё 140 тыс;
- 6 000 пользователей удалили приложение;
- около 1,1 млн рублей выручки утекло мимо кассы (пользователи завершали поездки «бесплатно» из-за бага).

Причина: отсутствовал мониторинг ключевых бизнес-метрик (процент успешных платежей), не было алертов на аномалии, тестирование платежей проводилось только «по успешному сценарию».

Что объединяет все эти истории

Если присмотреться, во всех четыре случаях бизнес был уверен, что «у нас всё под контролем» — до того момента, как стало понятно, что нет.

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

• бэкапы есть, но они не проверяются;
• серверы не мониторятся, о проблеме узнают от клиентов;
• обновления приложения выкатываются без поэтапной раскатки;
• безопасность — «потом, когда будет время»;
• ключевые бизнес-метрики никто не отслеживает в реальном времени.

Признаки того, что ваша инфраструктура или приложение — мина замедленного действия:

- вы не помните, когда в последний раз проверяли восстановление из бэкапа;
- у вас один сервер, на котором «всё»;
- никто не знает, какие у вас открыты порты наружу;
- релизы мобильного приложения выкатываются «сразу на всех»;
- нет системы мониторинга с уведомлениями в Telegram/почту;
- последнее обновление ОС на сервере было «давно».

Если хотя бы 2 пункта про вас — вопрос не в том, случится ли инцидент. Вопрос — когда и за сколько миллионов.

Что с этим делать
Мы в UKVED помогаем бизнесу выстраивать стабильную и безопасную IT-инфраструктуру: от серверов и бэкапов до разработки и поддержки мобильных приложений.

Бесплатный технический аудит включает:

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

Аудит занимает 2–3 рабочих дня и не стоит ничего. Мы покажем слабые места и предложим решения — а внедрять их у нас или у других подрядчиков, вы решите сами.
Мы покажем слабые места и предложим решения — а внедрять их у нас или у других подрядчиков, вы решите сами.
Сервер, который никогда не падал, — это не надёжный сервер. Это сервер, которому ещё не пришло время упасть.

P.S. Помните историю №1 — про бэкапы, которые были, но не помогли? Прямо сейчас, не откладывая, спросите своего сисадмина: «Когда мы в последний раз восстанавливались из бэкапа на тестовом сервере?» 
Если ответа «вчера» или «на прошлой неделе» вы не услышите — у вас уже есть проблема. Просто вы о ней пока не знаете.
В сложных случаях рекомендуем обратиться к специалистам.

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