Современные информационные системы напоминают большой город: сервисы связаны между собой, данные идут по десяткам маршрутов, за разные участки отвечают разные команды. Такая архитектура помогает компаниям быстро развивать цифровые продукты, однако вместе с ростом масштаба растёт и число технических зависимостей.
В ежегодном отчете Uptime Institute за 2025 год говорится, что предотвращение сбоев остаётся стратегической задачей для владельцев и операторов центров обработки данных. Авторы отчёта отмечают: оборудование и подходы к обеспечению устойчивости стали лучше, однако сложность современных архитектур и внешние угрозы создают новые риски, которыми необходимо управлять заранее.
О том, как такие риски проявляются внутри крупных информационных систем, рассказал старший разработчик серверной части в области информационной безопасности Сергей Наумов, который занимался там проектом по автоматизации управления TLS-сертификатами — цифровыми сертификатами, обеспечивающими защищенный обмен данными и напрямую влияющими на работу цифровых сервисов.
Причины сбоев
— Сергей, почему сложность информационных систем сегодня становится причиной сбоев?
— В корпоративной инфраструктуре проблема сертификатов связана не только со сроком их действия. Необходимо связать сертификат с владельцем сервиса, доверенной цепочкой, политиками выпуска, безопасным хранением ключей, контролем операций и автоматическим продлением до истечения срока действия.
Поэтому мы строили решение как часть единого платформенного процесса: сервис запрашивает сертификат по понятному сценарию, система проверяет право на его выпуск, центр сертификации выдаёт сертификат, а обновление и мониторинг происходят автоматически.
Современная система состоит из сотен сервисов, кластеров платформы Kubernetes, облачных компонентов и внутренних платформ. Один сервис зависит от другого, команды параллельно развивают свои участки. В такой среде даже диагностика инцидента может занимать много времени. Инженерам необходимо понять, где возникла ошибка, какие сервисы она затронула и кто отвечает за ее устранение.
— Какие элементы инфраструктуры чаще всего создают такие риски?
— Одна из самых чувствительных зон — управление доступами, секретами и сертификатами. Их много, они постоянно обновляются, и при ручном управлении ими легко потерять контроль.
Например, TLS-сертификат — это цифровой документ, который подтверждает подлинность сервиса и позволяет установить защищенное соединение. Если срок действия сертификата истёк, клиенты могут перестать устанавливать защищённое соединение с сервисом.
Для пользователя это выглядит как обычный сбой: страница не открывается, запрос не проходит, часть продукта становится недоступной. Для бизнеса такой инцидент означает потерю доступности сервиса и риск финансового ущерба.
В крупной инфраструктуре могут использоваться тысячи сертификатов. Управлять ими вручную опасно: человеческая ошибка в такой модели рано или поздно приводит к инциденту.
Просто, надёжно, предсказуемо
— Над какими задачами вы работали в рамках проекта?
— Я был ключевым инженером проекта по автоматизации управления TLS-сертификатами. Цель проекта — автоматизировать выпуск и обновление большей части сертификатов в инфраструктуре.
Ранее управление было централизованным: одна команда отвечала за большое количество сертификатов. По мере роста компании такая модель начинает хуже масштабироваться. Мы перешли к сервисному подходу: команды управляют сертификатами своих сервисов через единый инструмент и общие правила.
Важно было не просто развернуть центр сертификации (Certification Authority, CA), а встроить его в существующие платформы, политики безопасности и жизненный цикл сервисов: выпуск, продление, контроль операций, мониторинг и ответственность владельцев.
Я отвечал за архитектурное проектирование решения, интеграцию центра сертификации с внутренними платформами и разработку инструмента, который автоматизирует выпуск и обновление сертификатов для сервисных команд. По своей логике он напоминает инструмент автоматизации сертификатов Certbot, однако адаптирован под корпоративную инфраструктуру, внутренние платформы и требования информационной безопасности.
— С какими сложными инженерными задачами вы сталкивались на проекте?
— У меня был кейс, когда необходимо было создать инструмент, который одинаково работает в разных частях инфраструктуры. Внутри компании использовались Kubernetes, внутренние сервисы, облачные платформы для разработки, развертывания приложений и баз данных и другие платформы. Автоматизация должна была встроиться во все эти контуры без сложных ручных действий со стороны команд.
Вторая задача была связана с распределением ответственности. Когда команда получает контроль над сертификатами своего сервиса, инструмент должен быть простым, надёжным и предсказуемым. В противном случае инженеры начинают искать обходные решения, а инфраструктура снова накапливает риски.
Я реализовал значительную часть функциональности системы, координировал архитектурные решения с другими командами и готовил технические подходы для дальнейшего масштабирования.
— Какой результат такой проект даёт бизнесу?
— Главный результат — снижение риска аварий, связанных с истечением срока действия сертификатов.
Для пользователя причина сбоя обычно остаётся незаметной. Он видит только то, что сервис перестал работать. Для компании причина имеет значение, потому что её можно устранить системно.
Автоматизация исключает целый класс инцидентов. Сертификаты выпускаются и обновляются по единому процессу, команды получают понятный инструмент, а центральная команда освобождается от значительной части ручной операционной нагрузки.
Проект рассчитан примерно на 2 тыс. сертификатов. Им смогут пользоваться практически все разработчики компании через внутренние платформы. Это особенно важно для масштабирования: инфраструктура растёт, а управление безопасностью остаётся контролируемым.
ИИ может помочь в управлении
— Получается, надёжность информационных систем сегодня зависит от процессов так же сильно, как от разработки?
— Да, надежность все чаще определяется тем, как устроены процессы вокруг программного кода. В распределённой системе важно заранее понимать, кто отвечает за сервис, как обновляются критически важные элементы, как организован мониторинг, где фиксируются ошибки и как команда реагирует на инциденты.
Автоматизация становится базовым требованием. Чем больше ручных операций, тем выше вероятность ошибки. Инженеру важно думать не только о том, как реализовать новую функциональность, но и о том, как она будет работать в большой системе: обновляться, масштабироваться, взаимодействовать с другими сервисами и восстанавливаться после сбоя.
— Может ли искусственный интеллект помочь в управлении сложной инфраструктурой?
— Да, особенно в задачах, где человеку приходится работать с большим объёмом данных. Искусственный интеллект может помогать анализировать конфигурации, выявлять аномалии, подсказывать возможные причины инцидентов и ускорять диагностику.
При этом такие инструменты должны быть встроены в инженерный процесс. Их ценность появляется тогда, когда они работают вместе с системами мониторинга, журналами событий, внутренними инструментами и понятными правилами принятия решений. Для меня сейчас важное направление — применение искусственного интеллекта как части командной инженерной практики, а не как отдельного экспериментального решения.
— В каком направлении вы планируете развиваться дальше?
— Я развиваюсь в сторону архитектуры информационных систем и управления инженерными процессами на основе глубокой технической экспертизы. Мне интересно создавать системы, которые выдерживают рост компании, снижают операционные риски и помогают командам работать устойчиво.
Сейчас я продолжаю развивать проект внутри компании и параллельно усиливаю управленческие компетенции. В долгосрочной перспективе мне близка роль, связанная с ответственностью за архитектуру и процессы на уровне всей организации. Именно там сегодня во многом решается вопрос надёжности крупных цифровых сервисов.
Подписывайтесь на АиФ в  MAX
|
