Что защищать в первую очередь, а на чём можно сэкономить

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

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

Классифицируйте функции, а не серверы

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

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

Три класса

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

Пять вопросов для каждой функции

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

1. Останавливает ли отказ поступление денег прямо сейчас? Если да — это класс A, и дальнейшее обсуждение не требуется.

2. Есть ли договорные обязательства по доступности именно этой функции? Штрафы по договору превращают технический вопрос в юридический и часто поднимают класс на ступень.

3. Может ли пользователь достичь цели другим путём? Если при отказе автозаполнения адреса его можно ввести руками — функция деградирует, но не блокирует. Если без неё заказ не оформить — блокирует.

4. Сколько функция может не работать без необратимых последствий? Разница между «час» и «сутки» определяет, нужна ли автоматика или достаточно дежурного с инструкцией.

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

Класс — величина непостоянная

Классификация, сделанная один раз, вводит в заблуждение уже через полгода.

Сезонность. Для розницы предновогодние недели меняют картину целиком: функция, весь год бывшая классом B, на этот период становится классом A. Разумный подход — заранее описать «режим пиковой нагрузки»: что усиливается, что временно отключается ради разгрузки критичного, кто дежурит.

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

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

Где именно экономятся деньги

Классификация полезна не тем, что усиливает класс A, а тем, что даёт основания не усиливать остальное.

Тестовые среды не резервируются. Упавшая в субботу тестовая среда спокойно ждёт до понедельника. Дублировать её — чистый расход.

Архивы хранятся в холодном хранилище. Закрывающие документы трёхлетней давности не нужны в реплицируемом хранилище с мгновенным доступом: разница в стоимости на порядок, а требование — «достать за сутки по запросу».

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

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

Как это выглядит в итоге

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

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

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