Сегодня, 13:49

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

Намного реже говорят о DNS, сертификатах, сервисных аккаунтах, таймаутах, повторных запросах и логах. Для пользователя эти вещи вообще не существуют — до того момента, пока одна из них не ломается.

IT-инженер Никита Кузнецов считает именно эту невидимую часть продукта одной из самых недооценённых зон современной разработки. Можно написать хороший код, провести тестирование, настроить серверы и месяцами без проблем обслуживать пользователей. А потом одна старая DNS-запись, истёкший сертификат или забытый технический аккаунт перечёркивает всё остальное. Приложение физически продолжает работать, серверы исправны, база отвечает, но пользователь уже не может попасть внутрь.

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

«Люди чинят витрину и забывают, что дом стоит на трубах. Пока вода идёт, трубы никого не интересуют. Потом в субботу вечером труба лопается, и выясняется, что витрина ни при чём».

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

Никита Кузнецов о том, почему исправный код ещё не означает исправный продукт

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

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

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

По словам Никиты Кузнецова, здесь полезно отказаться от привычки считать инфраструктуру второстепенным техническим слоем:

«Критичная скука работает как фундамент: её не видно на картинке, но на ней стоит всё, что вы потом называете продуктом».

У новой функции почти всегда есть понятный владелец. Есть задача, исполнитель, срок, тестирование и релиз. С инфраструктурными зависимостями всё бывает гораздо менее определённо. Кто отвечает за домен? Кто контролирует сертификаты? Кто знает обо всех сервисных аккаунтах? Кто проверяет, остались ли права у подрядчика, который закончил работу полгода назад?

Пока всё функционирует, отсутствие ответа на эти вопросы практически незаметно. Авария мгновенно делает их главными.

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

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

И это вполне может быть правдой.

Приложение не менялось. Серверы работают. База отвечает. Последний релиз был несколько дней назад. Внутри инфраструктуры сервис даже может открываться по прямому адресу. Но обычный пользователь вводит привычное доменное имя и не получает работающий сайт.

«DNS — это табличка на доме, которую никто не читает, пока не потерял вход. Потом вся компания стоит в подъезде и спорит, кто виноват в коде».

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

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

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

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

Главная проблема здесь даже не конкретная технология. Проблема возникает, когда у критического объекта нет владельца, истории изменений и понятного способа проверки.

Истёкший сертификат — авария, дату которой можно было знать заранее

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

«Сертификат не ломает систему внезапно. Он ломает её ровно в тот день, который все видели и никто не поставил в календарь».

Сегодня значительную часть работы с TLS-сертификатами можно автоматизировать. Например, Let's Encrypt прямо рекомендует регулярно проверять информацию о продлении, использовать автоматическое обновление и отдельно контролировать состояние сертификатов. Для 90-дневных сертификатов в качестве резервной логики организация рекомендует начинать обновление примерно за 30 дней до окончания срока.

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

Кто-то был уверен, что продление автоматизировано. Уведомления приходили на старый адрес. Система автоматического обновления однажды перестала работать, но отдельного мониторинга её работы не существовало. Ответственный сотрудник сменил должность, а обязанность формально никому не передали.

В итоге браузер начинает предупреждать пользователя о проблеме защищённого соединения, часть клиентов отказывается продолжать работу, поддержка получает обращения, а техническая команда внезапно занимается объектом, о существовании которого до этого почти никто не вспоминал.

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

Инфраструктурная мелочь превращается в проблему бизнеса.

Временные доступы опасны именно потому, что перестают казаться временными

«Самая страшная учётка — не хакерская. А та, которую завели “на пару дней” и забыли выключить».

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

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

Через год технический ключ всё ещё существует.

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

Получается парадоксальная ситуация. Ненужный доступ сохраняют именно потому, что система недостаточно хорошо документирована.

То же относится к людям.

«Незаменимый человек с полным доступом — это не гордость команды. Это дыра, которую назвали компетенцией».

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

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

Почему микросервисы ломаются не только внутри сервисов 

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

Никита Кузнецов предлагает смотреть прежде всего на соединения между ними.

«Все рисуют квадратики. Почти никто не рисует дороги. А падает обычно дорога».

Смысл здесь в поведении сервисов при проблемах соседей. Сколько один сервис готов ждать ответа другого? Что происходит после таймаута? Повторяется ли запрос? Сколько раз? Через какой промежуток? Можно ли безопасно повторять эту операцию вообще?

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

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

Это реальный класс отказов, известный как retry storm — шторм повторных запросов. AWS в рекомендациях по надёжности отдельно предупреждает: неконтролируемые повторы при высокой нагрузке способны дополнительно перегрузить сеть и сервис и тем самым снизить доступность. Среди стандартных способов защиты — ограничение числа повторов, exponential backoff, случайная задержка jitter и circuit breaker, который временно прекращает обращения к явно проблемной зависимости.

Причём повторы опасны ещё по одной причине. Не каждую операцию вообще можно бездумно выполнять второй раз. Если первый запрос фактически прошёл, но клиент не получил подтверждение, повтор может привести к дублированию действия — например, созданию второй операции. AWS отдельно указывает на необходимость учитывать идемпотентность при проектировании retry-механизмов.

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

Так маленькая проблема одного сервиса либо остаётся локальной, либо становится аварией всей системы.

Никита Кузнецов о наблюдаемости: логи и телеметрия должны помогать быстро восстановить цепочку событий во время сбоя

Следующая проблема возникает уже после сбоя.

Компания может хранить огромное количество логов и всё равно почти ничего не знать о произошедшем.

«Если после аварии вы полчаса ищете нужную строчку, у вас нет наблюдаемости. У вас есть дневник, который никто не вёл для чтения».

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

Современная observability поэтому строится не только вокруг логов. OpenTelemetry выделяет несколько типов телеметрии — traces, metrics и logs. Distributed trace позволяет проследить путь одного запроса через разные компоненты, а отдельные spans показывают конкретные этапы этого пути. Это даёт возможность увидеть не просто сообщение об ошибке, а место и момент, где пользовательская операция начала ломаться.

Особенно полезна корреляция логов с trace ID и span ID: записи разных сервисов можно связать с одной конкретной операцией. OpenTelemetry прямо отмечает, что без такого контекста журналы распределённых компонентов часто остаются разрозненным набором событий.

Для Никиты Кузнецова это принципиальная разница между «мы собираем данные» и «мы понимаем систему».

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

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

Система должна сообщить о проблеме раньше клиента

Из этого Никита Кузнецов выводит ещё один критерий зрелости продукта: кто первым узнаёт об аварии.

Если техническая команда получает первое сообщение от клиента — система уже проиграла время.

Пользователь не должен выполнять роль бесплатного мониторинга.

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

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

И здесь снова появляется «критичная скука». Мониторинг редко приносит новый пользовательский функционал. Хороший алерт вообще желательно никогда не показывать клиенту. Но именно он может дать команде десять или двадцать минут, которые отделяют небольшую деградацию от полноценной аварии.

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

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

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

А результат своевременно продлённого сертификата заключается в том, что ничего не произошло.

DNS не сломался.

Старый ключ удалили, и никто этого не заметил.

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

Мониторинг поднял тревогу раньше клиентов.

«Скучные вещи не приносят демо. Их не показывают на совещании. Поэтому они живут без хозяина, пока не устроят совещание сами».

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

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

Никита Кузнецов о четырёх вопросах к каждой критической зависимости

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

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

Самое важное здесь — убрать зависимость от памяти.

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

«Если у критичной скуки нет владельца, срока проверки и сигнала до аварии, это не инфраструктура. Это надежда».

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

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

Поэтому Никита Кузнецов предлагает искать будущие аварии не только в самых сложных местах системы. Иногда полезнее открыть список DNS-записей, сертификатов и сервисных аккаунтов, посмотреть правила взаимодействия компонентов и попробовать восстановить один пользовательский запрос по логам.

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