Введение: Когда простых решений недостаточно

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

Я 3 года проработал в отделе сопровождения информационных систем и накопил десятки подобных случаев. Расскажу, как принимать решения, когда стандартные «перезагрузи и проверь» не работают.

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

Часть 1. Разбираемся с типами сбоев

1.1 Простые сбои — когда всё очевидно

Пример из практики:

• Проблема: Сработал мониторинг, нет места в директории.

• Причина: Логи забили всё место, а клинер на таймере не сработал.

• Решение: Перезапустили таймер/сервис или почистили ручками -> всё нормально заработало.

Такие случаи решаются за 5 минут по инструкции. Но что делать, когда причина не ясна?

1.2 Сложные сбои — где нужно думать

Реальный кейс из моей практики:
После обновления:

1. Главная страница работает

2. Корзина не открывается

3. Платежи проходят, но чеки не сохраняются

Варианты решения:

1. Откатить обновление (рискуем потерять новые товары)

2. Попробовать починить сервис или базу данных (может занять часы)

3. Включить ограниченный режим, к примеру, выключить целиком функционал покупки товаров — оставить только просмотр и информационные страницы

Часть 2. Метод трёх экспертов — как это работает на практике

2.1 Собираем команду для принятия решения

Идеальный состав:

1. Разработчик (понимает код)

2. Системный администратор (знает инфраструктуру)

3. Продуктовый менеджер (понимает бизнес-последствия)

2.2 Подробный разбор примера с интернет-магазином

Критерии оценки:

1. Скорость восстановления (1-10 баллов)

2. Риск потери данных (1-10, где 10 — максимальный риск)

3. Влияние на клиентов (1-10 баллов)

Оценка вариантов:

Как считали:

• Откат: быстро (7), но рискуем данными (4)

• Ремонт: долго (4), зато безопасно (2)

• Аварийный режим: очень быстро (9), но функционал ограничен (7)

2.3 Что выбрали и почему

По итогам выбрали аварийный режим:

1. Клиенты смогли просматривать товары, сохранять их в избранное для покупки потом

2. Параллельно начали смотреть логи, чинить сервис

3. Через 3 часа всё восстановили полностью

Часть 3. Ещё реальные примеры с разбором

3.1 Случай с «исчезающими» заказами

Проблема:
Каждый 10-й заказ пропадал через 5 минут после оформления

Варианты:

1. Отключить кэш (риск увеличения нагрузки)

2. Перейти на резервную БД (потеря последних заказов)

3. Включить логирование каждого шага (замедлит систему)

Решение:
Выбрали вариант 3 + временно удвоили мощность серверов. Оказалось, баг в кэшировании.

3.2 История с рандомными письмами

Проблема:
CRM-система начала отправлять клиентам случайные письма

Варианты:

1. Отключить все автоматические письма

2. Перезапустить всю систему

3. Вручную проверить каждое правило

Решение:
Сначала вариант 1 (экстренная мера), потом нашли сбойный скрипт, который запускался по расписанию.

Часть 4. Продвинутые техники принятия решений

4.1 Матрица приоритетов

Создаём таблицу с двумя осями:

1. Важность для бизнеса

2. Сложность реализации

Пример для сбоя в платежах:

4.2 Метод «Пяти почему»

Пример использования:

1. Почему упал сервер? — Перегрузка CPU

2. Почему перегрузка? — Много запросов к API

3. Почему много запросов? — Новый скрипт аналитики

4. Почему скрипт так нагружает? — Нет ограничения частоты запросов

5. Почему нет ограничения? — Не учли при разработке

Вывод: нужно добавить rate-limiting в скрипт

Часть 5. Чего делать нельзя: ошибки новичков

1. Паниковать и делать всё сразу — так только усугубите проблему

2. Игнорировать мнение коллег — один человек может не видеть всей картины

3. Забывать про откат — всегда имейте «план Б»

4. Не документировать решения — потом не разберётесь, что сделали

Реальный пример ошибки:
Инженер в панике ребутнул сервер с БД разом — потеряли 15 минут данных.

Заключение: Главные принципы принятия решений

1. Не спешите — 10 минут на анализ сэкономят часы работы

2. Советуйтесь — три эксперта видят больше, чем один

3. Действуйте по плану — от простого к сложному

4. Учитесь на ошибках — после каждого инцидента проводите разбор

А теперь мне интересно послушать, как это происходит у вас? Делитесь в комментариях своими кейсами!