Пользователь воспринимает цифровой продукт как единое целое: сайт, приложение, личный кабинет. Он не видит и не обязан видеть, что за одной кнопкой «Оплатить» или «Войти» скрывается цепочка из API-шлюзов, микросервисов, баз данных, очередей сообщений, сторонних платёжных провайдеров и систем авторизации. Для него существует только результат: нажал — и всё сработало, или нажал — и ничего не произошло. Во втором случае продукт просто не работает, независимо от того, какой именно компонент внутри оказался виноват.
В публичном поле разработки принято обсуждать то, что можно показать: новый интерфейс, ускорение загрузки, свежую функцию, улучшенный алгоритм, модель искусственного интеллекта. Гораздо реже говорят о DNS, TLS-сертификатах, сервисных аккаунтах, таймаутах, политиках повторных запросов и логах. Для пользователя эти вещи не существуют — до тех пор, пока одна из них не ломается. Именно эту «невидимую» часть продукта IT-инженер Никита Кузнецов называет одной из самых недооценённых зон современной разработки.
Можно написать качественный код, провести тестирование, настроить серверы и месяцами без проблем обслуживать пользователей. А потом одна старая DNS-запись, истёкший сертификат или забытый технический аккаунт перечёркивают всё остальное. Приложение физически продолжает работать, серверы исправны, база отвечает, но пользователь уже не может попасть внутрь. Кузнецов называет такие элементы «критичной скукой»: вещами, которыми никто особенно не хочет заниматься, потому что в нормальном состоянии они не создают видимого результата.
«Люди чинят витрину и забывают, что дом стоит на трубах. Пока вода идёт, трубы никого не интересуют. Потом в субботу вечером труба лопается, и выясняется, что витрина ни при чём», — говорит он. Эта метафора точно описывает разницу между тем, как продукт выглядит снаружи, и тем, как он существует технически. Пользователь видит сайт или приложение. Инженер видит ещё десятки зависимостей, через которые должен успешно пройти один обычный запрос. И чем сложнее становится система, тем чаще причина серьёзного сбоя находится не в самой заметной её части.
Особенно показательны ситуации, когда команда говорит: «Но мы же ничего не деплоили». Приложение не менялось, серверы работают, база отвечает, последний релиз был несколько дней назад. Внутри инфраструктуры сервис даже может открываться по прямому адресу, но обычный пользователь вводит привычное доменное имя и не получает работающий сайт. DNS в такой ситуации выступает как «табличка на доме, которую никто не читает, пока не потерял вход. Потом вся компания стоит в подъезде и спорит, кто виноват в коде».
Технически DNS связывает понятное человеку доменное имя с информацией, необходимой для нахождения нужного ресурса. В цепочке участвуют рекурсивные резолверы, кэширование и авторитетные DNS-серверы. Поэтому неверная запись или неудачное изменение может вести себя не так очевидно, как обычная ошибка приложения. Разные пользователи некоторое время могут получать разные результаты из-за кэшей. Параметр TTL определяет, как долго DNS-запись может храниться в кэше; чем он больше, тем дольше старое значение потенциально продолжает использоваться после изменения.
Отсюда появляется неприятный сценарий: у одного инженера сайт уже открывается, у другого ещё нет. Из одного региона запрос идёт правильно, из другого продолжает использоваться закэшированное значение. Команда видит противоречивые симптомы и начинает искать нестабильность приложения, хотя проблема находится уровнем раньше. Кузнецов говорит об «авариях вне репозитория»: сломаться может то, что вообще не менялось вместе с исходным кодом — DNS-запись, сетевое правило, сертификат, секрет, внешний аккаунт или конфигурация провайдера.
Такие настройки нередко переживают несколько поколений самого продукта. Приложение давно переписано, инфраструктура мигрировала, сотрудники поменялись, а какая-нибудь критическая запись всё ещё существует потому, что пять лет назад её однажды создали вручную. Главная проблема здесь даже не конкретная технология, а то, что у критического объекта нет владельца, истории изменений и понятного способа проверки.
Сертификаты Кузнецов приводит как особенно показательный пример. В отличие от многих программных ошибок, срок действия сертификата не является неожиданностью. Дата известна заранее. «Сертификат не ломает систему внезапно. Он ломает её ровно в тот день, который все видели и никто не поставил в календарь». Сегодня значительную часть работы с TLS-сертификатами можно автоматизировать. Например, Let’s Encrypt прямо рекомендует регулярно проверять информацию о продлении, использовать автоматическое обновление и отдельно контролировать состояние сертификатов. Для 90-дневных сертификатов в качестве резервной логики организация рекомендует начинать обновление примерно за 30 дней до окончания срока.
Поэтому авария из-за истёкшего сертификата интересна не своей технической сложностью. Наоборот — она показывает организационную проблему. Кто-то был уверен, что продление автоматизировано. Уведомления приходили на старый адрес. Система автоматического обновления однажды перестала работать, но отдельного мониторинга её работы не существовало. Ответственный сотрудник сменил должность, а обязанность формально никому не передали. В итоге браузер начинает предупреждать пользователя о проблеме защищённого соединения, часть клиентов отказывается продолжать работу, поддержка получает обращения, а техническая команда внезапно занимается объектом, о существовании которого до этого почти никто не вспоминал.
Кузнецов обращает внимание на важную деталь: для пользователя не существует оправдания «сам сервис работает, проблема только в сертификате». Если человек не может безопасно открыть продукт, значит, продукт для него не работает. Инфраструктурная мелочь превращается в проблему бизнеса.
Ещё серьёзнее ситуация с правами доступа. Здесь последствия могут выходить далеко за пределы обычного простоя. «Самая страшная учётка — не хакерская. А та, которую завели “на пару дней” и забыли выключить». Кузнецов описывает распространённый жизненный цикл такого доступа. Команде срочно нужно подключить новый сервис или дать подрядчику возможность что-то настроить. Времени мало, поэтому разрешения делают шире, чем требуется. После запуска их собираются ограничить. Релиз проходит. Появляются новые задачи. Через несколько недель никто уже не вспоминает о временном решении. Через год технический ключ всё ещё существует.
Проблема становится особенно серьёзной, когда невозможно быстро установить, кому принадлежит учётная запись, какой процесс её использует и что произойдёт после отключения. Команда видит потенциально опасный доступ, но боится его удалить: вдруг ночью перестанет работать какой-нибудь старый процесс. Получается парадоксальная ситуация. Ненужный доступ сохраняют именно потому, что система недостаточно хорошо документирована.
То же относится к людям. «Незаменимый человек с полным доступом — это не гордость команды. Это дыра, которую назвали компетенцией». Опытный инженер действительно может знать инфраструктуру лучше остальных. Проблема начинается, когда знания и права этого человека становятся единственным способом поддерживать критический процесс. Тогда отпуск, болезнь, увольнение или обычная недоступность сотрудника превращаются в технический риск.
Поэтому Кузнецов предлагает смотреть на управление доступом не только как на вопрос информационной безопасности. Это ещё и вопрос устойчивости бизнеса. Компания должна понимать, кто имеет доступ к критическим системам, зачем он ему нужен, когда последний раз использовался и существует ли альтернативный способ восстановить систему без одного конкретного специалиста.
Следующая проблема возникает уже после сбоя. Компания может хранить огромное количество логов и всё равно почти ничего не знать о произошедшем. «Если после аварии вы полчаса ищете нужную строчку, у вас нет наблюдаемости. У вас есть дневник, который никто не вёл для чтения». Обычный лог сообщает, что в определённое время конкретный компонент записал конкретное событие. Но в распределённой системе одного этого недостаточно. Один пользовательский запрос может пройти через API-шлюз, авторизацию, несколько внутренних сервисов и базу данных. Если каждый из них пишет отдельный журнал без общей связи, инженерам приходится вручную собирать историю по времени и косвенным признакам.
Современная observability поэтому строится не только вокруг логов. OpenTelemetry выделяет несколько типов телеметрии — traces, metrics и logs. Distributed trace позволяет проследить путь одного запроса через разные компоненты, а отдельные spans показывают конкретные этапы этого пути. Это даёт возможность увидеть не просто сообщение об ошибке, а место и момент, где пользовательская операция начала ломаться. Особенно полезна корреляция логов с trace ID и span ID: записи разных сервисов можно связать с одной конкретной операцией. OpenTelemetry прямо отмечает, что без такого контекста журналы распределённых компонентов часто остаются разрозненным набором событий.
Для Кузнецова это принципиальная разница между «мы собираем данные» и «мы понимаем систему». Терабайты журналов сами по себе ничего не гарантируют. Во время аварии инженеру нужны ответы на конкретные вопросы: когда началась проблема, какой пользовательский сценарий пострадал первым, через какие сервисы прошёл запрос, где появилась первоначальная задержка, какие ошибки возникли вслед за ней и насколько широко распространился сбой. Если ответы требуют нескольких часов ручного сопоставления, наблюдаемость существует формально, но не выполняет свою главную функцию.
Из этого Кузнецов выводит ещё один критерий зрелости продукта: кто первым узнаёт об аварии. Если техническая команда получает первое сообщение от клиента — система уже проиграла время. Пользователь не должен выполнять роль бесплатного мониторинга. Но хороший мониторинг — это не просто проверка, отвечает ли сервер на запрос. Сервис может формально быть доступен и при этом фактически не выполнять свою функцию. OpenTelemetry определяет надёжность именно через ожидания пользователя: система может иметь стопроцентный uptime, но оставаться ненадёжной, если пользовательское действие регулярно приводит к неправильному результату.
Поэтому Кузнецов предлагает смотреть на продукт на нескольких уровнях одновременно. Нужно знать не только загрузку процессора и объём памяти, но и процент ошибок, задержку ответов, состояние очередей, время выполнения ключевых пользовательских операций, работу внешних зависимостей и аномальные изменения привычного поведения системы. И здесь снова появляется «критичная скука». Мониторинг редко приносит новый пользовательский функционал. Хороший алерт вообще желательно никогда не показывать клиенту. Но именно он может дать команде десять или двадцать минут, которые отделяют небольшую деградацию от полноценной аварии.
Причина, по мнению Кузнецова, довольно прозаична: у профилактической инженерной работы плохо заметен результат. Новая функция существует физически — её можно открыть и показать. Новый дизайн можно поставить в презентацию. Рост скорости можно выразить цифрой. А результат своевременно продлённого сертификата заключается в том, что ничего не произошло. DNS не сломался. Старый ключ удалили, и никто этого не заметил. Проблемный сервис автоматически ограничили до того, как он потянул за собой остальные. Мониторинг поднял тревогу раньше клиентов. «Скучные вещи не приносят демо. Их не показывают на совещании. Поэтому они живут без хозяина, пока не устроят совещание сами».
Эта формулировка хорошо описывает конфликт между заметностью работы и её реальной ценностью. Чем лучше работает профилактическая инфраструктура, тем меньше событий она создаёт для бизнеса. Поэтому её легко воспринимать как второстепенную статью расходов — до первой серьёзной аварии. После аварии ситуация обычно переворачивается. Внезапно находятся ресурсы на мониторинг, аудит доступов, документацию и резервирование. Но Кузнецов считает более зрелым противоположный подход: не ждать, пока инфраструктура докажет свою важность через простой.
Вместо огромного списка формальных правил Кузнецов предлагает довольно практичный подход. Для каждой действительно критической зависимости команда должна уметь ответить на четыре вопроса: кто отвечает, когда проверяем, как узнаём о проблеме и что делаем после сигнала. У сертификата должен быть владелец и автоматический контроль срока. У DNS — понятный процесс изменения и возможность проверить, куда фактически разрешается домен. У технического аккаунта — назначение, минимально необходимые права и процедура пересмотра. У межсервисного вызова — таймауты, ограниченная политика повторов и понятное поведение при отказе. У пользовательского запроса — достаточная телеметрия, чтобы проследить его путь по системе.
Самое важное здесь — убрать зависимость от памяти. Память опытного сотрудника полезна, но это не механизм отказоустойчивости. Фраза «Саша обычно следит за сертификатами» не является процессом. «Мы знаем, кому позвонить» — не план восстановления. «Этот ключ, кажется, ещё нужен» — не политика доступа. «Если у критичной скуки нет владельца, срока проверки и сигнала до аварии, это не инфраструктура. Это надежда».
В этой фразе фактически собрана вся позиция Никиты Кузнецова. Надёжность продукта определяется не только качеством написанного кода и не количеством технологий в архитектуре. Она определяется ещё и тем, насколько команда контролирует простые, старые и совершенно неэффектные зависимости, без которых весь сложный продукт перестаёт существовать для пользователя. Можно построить десятки микросервисов, использовать современные модели искусственного интеллекта и обрабатывать огромные объёмы данных. Но если никто не знает, когда истекает критический сертификат, кому принадлежит старый административный ключ или почему сервис пять раз повторяет запрос к уже перегруженной зависимости, технологическая сложность мало помогает.
Поэтому Кузнецов предлагает искать будущие аварии не только в самых сложных местах системы. Иногда полезнее открыть список DNS-записей, сертификатов и сервисных аккаунтов, посмотреть правила взаимодействия компонентов и попробовать восстановить один пользовательский запрос по логам. И задать к каждому такому элементу несколько неприятных вопросов: кто за него отвечает, когда его последний раз проверяли, как система сообщит о проблеме и что произойдёт, если он перестанет работать прямо сейчас.
Опубликовано: 18.09.2026 в 1:00
