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

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

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

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

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

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

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

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

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

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

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

Главная страница работает
Корзина не открывается
Платежи проходят, но чеки не сохраняются

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

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

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

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

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

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

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

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

Скорость восстановления (1-10 баллов)
Риск потери данных (1-10, где 10 - максимальный риск)
Влияние на клиентов (1-10 баллов)

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

Вариант	Разработчик	Админ	Менеджер	Итого
Откат обновления	7/4/6	8/3/5	6/5/7	7/4/6
Анализ логов и исправление сервиса или БД	5/2/4	4/1/3	3/2/5	4/2/4
Ограниченный режим	8/6/8	9/7/9	9/8/9	9/7/9

Как считали:

Откат: быстро (7), но рискуем данными (4)
Ремонт: долго (4), зато безопасно (2)
Аварийный режим: очень быстро (9), но функционал ограничен (7)

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

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

Клиенты смогли просматривать товары, сохранять их в избранное для покупки потом
Параллельно начали смотреть логи, чинить сервис
Через 3 часа всё восстановили полностью

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

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

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

Варианты:

Отключить кэш (риск увеличения нагрузки)
Перейти на резервную БД (потеря последних заказов)
Включить логирование каждого шага (замедлит систему)

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

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

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

Варианты:

Отключить все автоматические письма
Перезапустить всю систему
Вручную проверить каждое правило

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

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

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

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

Важность для бизнеса
Сложность реализации

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

Решение	Важность	Сложность
Включить ручную проверку	9	3
Запустить резервную систему	7	8
Вернуть старую версию	5	4

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

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

Почему упал сервер? - Перегрузка CPU
Почему перегрузка? - Много запросов к API
Почему много запросов? - Новый скрипт аналитики
Почему скрипт так нагружает? - Нет ограничения частоты запросов
Почему нет ограничения? - Не учли при разработке

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

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

Паниковать и делать всё сразу - так только усугубите проблему
Игнорировать мнение коллег - один человек может не видеть всей картины
Забывать про откат - всегда имейте "план Б"
Не документировать решения - потом не разберётесь, что сделали

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

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

Не спешите - 10 минут на анализ сэкономят часы работы
Советуйтесь - три эксперта видят больше, чем один
Действуйте по плану - от простого к сложному
Учитесь на ошибках - после каждого инцидента проводите разбор

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

Как принимать решения при сбоях в IT-системах: методы поддержки принятия решений