Признаки того, что вы платите за надёжность, которая вам не нужна

Об избыточной надёжности говорят редко: недостаточная надёжность заявляет о себе авариями, а избыточная выглядит добродетелью. Компания платит за сложность, которой не пользуется, и считает это осмотрительностью.

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

Почему это происходит

Причины редко бывают злонамеренными, и понимать их полезнее, чем осуждать.

Инженеры выбирают технологии не только по задаче, но и по рынку труда: опыт с современным стеком повышает их ценность, опыт поддержки монолита на одном сервере — нет. Это рациональное поведение, и оно не проходит само по себе от призывов.

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

Третья — подражание. Инженерные доклады крупных компаний описывают архитектуры, рассчитанные на нагрузку, которой у вас нет, и решения оттуда переносятся вместе с контекстом, который не переносится.

Симптомы

Оркестрация под нагрузку, которой нет. Kubernetes для интернет-магазина с двумя сотнями визитов в день. Это отличный инструмент для десятков сервисов и нескольких команд, но для одного приложения он добавляет свой сетевой слой, своё хранилище, свои сбои и требует человека, который во всём этом разбирается.

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

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

Среды, которые никто не использует. Четыре копии продуктивной среды, за которые провайдер выставляет счёт ежемесячно, притом что две из них не открывали неделями.

Резервирование без проверки. Формально есть резервная площадка, но переключение на неё ни разу не проводили. Это худший вариант: расходы понесены полностью, а уверенность ложная — непроверенное переключение в момент аварии работает примерно в половине случаев.

Мониторинг, на который не реагируют. Сотни настроенных проверок и канал оповещений, в котором сообщения давно никто не читает, потому что там всегда что-нибудь горит. Такой мониторинг стоит денег и не даёт ничего.

Настоящая цена

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

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

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

Скорость изменений падает. Это самая дорогая потеря и самая незаметная. Продуктовая гипотеза, которую можно было проверить за неделю, проверяется за месяц. Конкурент за это время проверит четыре.

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

Как отличить оправданную сложность от избыточной

Признаки сами по себе ничего не доказывают: бывают компании, которым Kubernetes нужен, и компании, где сорок сервисов оправданы. Отличает их не размер, а способность ответить на три вопроса.

Первый: какую конкретную аварию это предотвращает и сколько она стоит? Ответ «это правильная архитектура» не годится. Годится: «отказ одного сервера в этом сценарии стоит нам 300 тысяч, решение стоит 100 тысяч в год».

Второй: сколько человек в команде могут это поддерживать? Если ответ «один», сложность не внедрена, а взята в долг под личную гарантию конкретного сотрудника.

Третий: когда мы в последний раз этим пользовались? Резервная площадка, автоматическое переключение, план восстановления — всё это либо проверялось на практике, либо существует только на бумаге.

Три уверенных ответа означают, что сложность оправдана. Отсутствие ответов означает, что вы платите за надёжность, которой у вас, скорее всего, нет.

Если сложность уже построена

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

Разумнее действовать иначе.

Остановите рост. Не добавляйте новых компонентов, пока не будет ответа на первый вопрос из трёх.

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

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

Упрощайте при следующем крупном изменении. Когда компонент всё равно придётся переписывать, тогда и решайте, нужен ли он в прежнем виде.

Вопрос, который стоит задавать регулярно

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

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

Хорошая команда ответит на него за минуту. Если ответа нет ни у кого, вы нашли не техническую проблему, а управленческую.

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