Как принимать решения при сбоях в IT-системах: методы поддержки принятия решений
Введение: Когда простых решений недостаточно
Представьте ситуацию: вечер, срабатывает тревога — ваш интернет-магазин лежит в самый разгар распродажи. В логах куча ошибок, но явной причины не видно. Знакомо? Вот тут-то и начинается самое интересное.
Я 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 минут на анализ сэкономят часы работы
-
Советуйтесь — три эксперта видят больше, чем один
-
Действуйте по плану — от простого к сложному
-
Учитесь на ошибках — после каждого инцидента проводите разбор
А теперь мне интересно послушать, как это происходит у вас? Делитесь в комментариях своими кейсами!
Автор: daniilmaibe