Примечание: это четвертый пост из серии «Прогнозы на 2026 год» от Forcepoint, в которой представлены прогнозы и анализ изменений в сфере кибербезопасности.
На протяжении десятилетий командам, отвечающим за ИТ-инфраструктуру, говорили, что они должны работать быстрее. Быстрее внедрять, быстрее устанавливать исправления, быстрее модернизировать и делать все в темпе, соответствующем растущему давлению со стороны бизнеса. Такой подход когда-то помогал, но в 2026 году он станет одной из главных причин нестабильности, сбоев и технического долга.
ИИ удивительным образом меняет эту реальность. Он усиливает все то, что у вас уже есть. Подключите его к беспорядочным архитектурам и поспешным процессам изменений, и он ускорит неправильные вещи. Замедлитесь настолько, чтобы укрепить основы, такие как контроль изменений, провести тщательные технические проверки и дать вашим командам возможность действовать, и ИИ станет двигателем безопасного ускорения в масштабе.
В последнем посте из серии «Взгляд в будущее 2026» мы рассмотрим более тихую революцию. Самыми быстрыми организациями в 2026 году станут те, которые первыми научатся двигаться медленно, чтобы в конечном итоге двигаться быстро с точки зрения ИТ-инфраструктуры.
Что на самом деле означает «тише едешь — дальше будешь» для инфраструктурных команд
«Тише едешь — дальше будешь» не означает бюрократизм ради бюрократии. Это означает ранние инвестиции в понимание, тестирование и управление, чтобы впоследствии можно было действовать с уверенностью.
В контроле изменений это проявляется следующим образом:
- Уделять время пониманию того, как системы действительно ведут себя, прежде чем их автоматизировать
- Разрабатывать окна изменений, схемы внедрения и планы отката перед первым запуском
- Рассматривать каждый инцидент или сбой как урок, который помогает усовершенствовать следующее изменение
Выгода от этого подхода не является теоретической. Команды, которые используют этот подход, чаще внедряют изменения, реже сталкиваются с необходимостью экстренного отката и сокращают время простоя. Они заслуживают право действовать быстро, потому что уже проделали медленную работу, когда это было важно.
Это контекст, в котором я живу каждый день, работая вице-президентом по обеспечению надежности сайта в глобальной инфраструктурной среде. Мой опыт охватывает локальные центры обработки данных, частные облачные платформы и гибридные среды, где эти миры пересекаются. Во всех этих случаях я постоянно возвращаюсь к одной и той же структуре, основанной на трех ключевых принципах.
Принцип 1: Всегда начинайте с основ
Первый принцип на первый взгляд кажется очень простым. Когда что-то ломается или вы планируете большие изменения, начинайте с основ.
На практике это означает:
- Начните с основ и продвигайтесь вверх по стеку. Проверьте питание, подключение и базовое состояние системы, прежде чем гоняться за призраками или вводящими в заблуждение результатами выше по стеку.
- Просмотрите и оцените недавние изменения и зависимости, прежде чем придумывать новые теории.
- Исследуйте, чтобы четко понять, что говорят вам системы и мониторы, не делайте предположений на основе ограниченных данных.
- Используйте мониторинг, оповещения и руководства, которые заставляют выполнять проверку снизу вверх перед серьезным эскалацией.
Я видел, как это происходило в обоих направлениях. В одном случае инстинкт подсказывал запустить переключение на резервный сервер для критически важной службы. Замедление для проверки основных параметров выявило проблему с одним хостом. Поспешное переключение на резервный сервер усугубило бы последствия. Методичный контрольный список позволил сдержать инцидент, не допустив его влияния на клиентов.
Принцип «сначала основы» также применяется перед внесением изменений. Когда мои команды тратят время на отображение зависимостей, понимание базовой производительности и анализ исторических инцидентов, мы разрабатываем более эффективные внедрения. Мы знаем, какие показатели имеют значение. Мы знаем, как выглядит сбой. Эти знания делают последующие изменения и автоматизацию гораздо более безопасными.
В течение следующих нескольких лет такая дисциплина будет отличать устойчивую инфраструктуру эпохи ИИ от хрупких стеков, которые рушатся под давлением автоматизации. ИИ может помочь выявить закономерности в журналах и метриках. Но он не может заменить человеческую привычку задавать базовые вопросы перед тем, как предпринимать серьезные действия.
Второй принцип: Дать возможность действовать людям, наиболее близким к проблеме
Второй принцип – это ответственность. Люди, наиболее близкие к проблеме, должны чувствовать, что они могут действовать, а не просто открывать заявки и ждать.
В начале своей карьеры я работал в среде, где операционные команды считали себя дорожными полицейскими. Когда что-то ломалось, они вызывали инженеров, смотрели на часы и надеялись на лучшее. Эта модель не выдерживает современной сложности. Каждая цепочка эскалации добавляет минуты задержки и путаницы.
В рамках подхода «тише едешь — дальше будешь» операционные и SRE-команды:
- входят в системы для исследования, а не боятся, что у них нет полномочий или что они могут усугубить ситуацию;
- читают журналы, сопоставляют оповещения и формируют первоначальную гипотезу;
- имеют четкие рекомендации о том, когда они могут исправлять, когда должны откатывать и когда эскалировать.
Это не означает отказ от инженерных решений. Инженерные решения сохраняются для проблем, которые действительно требуют сложного анализа и рассмотрения. Остальные вопросы доверяются людям, работающим на передовой.
Это доверие ускоряет все процессы. Инциденты сортируются быстрее. Простые проблемы устраняются без долгих совещаний. Инженеры тратят больше времени на улучшение систем и меньше времени на устранение неисправностей. В этих усовершенствованных системах возникает меньше проблем. И что наиболее важно, те же люди, которые ежедневно управляют системой, активно участвуют в планировании и отработке крупных изменений.
С появлением искусственного интеллекта в консолях и руководствах по эксплуатации эта возможность становится еще более важной. Команда, которая уже принимает решения самостоятельно, будет использовать искусственный интеллект в качестве партнера, способного проверить, что является целесообразным, а что нет. Команда, которая привыкла ждать инструкций, будет рассматривать искусственный интеллект как нового начальника. Только один из этих путей ведет к безопасной работе и устойчивой скорости.
Третий принцип: Сделайте наблюдаемость и автоматизацию драйверами скорости
Третий принцип – это то место, где наконец появляется «скорость». Как только фундаментальные принципы и ответственность за них установлены, вы доверяете скорость наблюдаемости и автоматизации.
Мои команды потратили месяцы на перенастройку наших систем. Мы провели ревизию старых проверок, перенастроили панели инструментов и перестроили оповещения, чтобы каждый сигнал имел значение. Мы объединили все в современный стек наблюдаемости вместо разрозненных инструментов. Только после этого мы внедрили и включили автоматическое переключение на резервный ресурс и самовосстановление для хорошо понятных режимов сбоев.
В результате получается система, в которой большинство проблем решается до того, как они повлияют на клиентов. Оповещения запускают сценарии действий. Известные шаблоны запускают безопасные автоматические процессы. Люди сосредотачиваются на крайне рискованных случаях и должны проверять только незначительные оповещения.
Автоматизация – это не отправная точка. Это награда за то, что сначала была проделана медленная работа.
Почему это важно для локальных, частных облачных и гибридных сред
Одно из заблуждений о подходе «тише едешь — дальше будешь» заключается в том, что он применим только к традиционным центрам обработки данных. На самом деле все наоборот.
Локальные и автономные среды характеризуются длительными сроками поставки оборудования и ручным трудом. Замедление в данном случае означает серьезное отношение к планированию мощностей, тестирование путей переключения на резервные системы в физических средах и отработку крупных изменений. Результат — меньше внезапных дефицитов ресурсов и такие обновления, которые не требуют мобилизации всех сил.
Частные облачные среды добавляют еще один уровень. Вы получаете гибкость программно-определяемой инфраструктуры, но по-прежнему владеете стойками, сетями и основными сервисами. Замедление здесь означает укрепление сервисов вашей платформы, проверку влияния изменений на многопользовательскую среду и согласование внутренней дорожной карты платформы с реальными потребностями команд разработчиков приложений. В результате вы получаете платформу, которой доверяют команды, а не хрупкий внутренний продукт, который они обходят стороной.
Гибридные среды увеличивают сложность. Рабочие нагрузки, идентификационные данные и данные перемещаются через границы доверия между локальными, частными облачными и любыми публичными облачными сервисами, на которые вы полагаетесь. Замедление здесь означает тщательное отображение зависимостей, ужесточение утверждений для межграничных изменений и ограничение радиуса воздействия, когда что-то идет не так. Вознаграждением за это является возможность мигрировать, переходить на другую платформу или расширять сервисы без недель замораживания изменений.
Во всех этих мирах действуют три основных принципа:
- Понимайте систему.
- Дайте больше возможностей людям, которые работают с ней.
- Пусть наблюдаемость и автоматизация обеспечивают скорость.
Как ИИ меняет уравнение скорости
ИИ находится на вершине этих основ. Он может их усилить или разрушить.
На мой взгляд, есть две ближайшие области, в которых ИИ может помочь инфраструктурным командам «ехать тише» в нужных местах, чтобы в целом они могли «быть дальше».
Во-первых, это шум от аллертов. В напряженные периоды мои команды могут получать предупреждения каждую минуту. Сегодня большую часть работы по корреляции выполняют люди. ИИ может помочь, группируя связанные аллерты, объединяя их в отдельные инциденты и выделяя те, которые действительно угрожают доступности или безопасности. Вместо того, чтобы реагировать на поток красных предупреждений, команды видят сфокусированный набор проблем, приоритизированных ИИ и связанных с вероятными первопричинами.
Второй аспект – планирование мощностей, особенно для локальных, частных облачных и других самохостинговых инфраструктур. Сегодня люди полагаются на графики в приложениях типа Grafana или таблицы, чтобы принять решение о покупке и развертывании нового оборудования или о масштабировании общих кластеров. Модели искусственного интеллекта могут прогнозировать спрос, выявлять сезонные закономерности и давать рекомендации о том, когда и где следует добавлять мощности. Они также могут предлагать более разумное распределение рабочих нагрузок между локальной и частной облачной инфраструктурой для управления затратами и рисками.
Если заглянуть немного в будущее, то ИИ будет играть более важную роль в моделировании изменений. Модели могут анализировать исторические инциденты и различия в конфигурации, чтобы присваивать предлагаемым изменениям оценки риска. С помощью ИИ можно дробить задачи на более мелкие части, внедрять их в безопасной последовательности и использовать для тестов по-настоящему реалистичные кейсы. Цифровые двойники и высокоточные тестовые среды позволят командам отрепетировать крупные изменения до того, как они будут внедрены в производство, независимо от того, будут ли эти изменения реализованы в центре обработки данных, частном облачном кластере или хостируемой контрольной плоскости.
Все это помогает только в том случае, если сначала была проделана кропотливая работа. Некачественная телеметрия, слабая система оповещений и отсутствие производственных модульных тестов приводят к некачественным рекомендациям ИИ. Слабое управление превращает автоматизацию ИИ в новый способ разрушить все в большом масштабе. В эпоху ИИ «тише едешь — дальше будешь» означает проверку предложений ИИ с помощью человеческого суждения, документирование мер предосторожности и регистрацию всех изменений, сделанных с помощью ИИ, для последующего анализа.
Что следует сделать руководителям сейчас для 2028 года
К 2028 году разрыв между организациями, которые освоили этот переход, и теми, которые этого не сделали, будет очевиден. Победителями станут не те, кто двигался быстрее всего в 2025 году. Победителями станут те, кто замедлился настолько, чтобы дать ИИ что-то надежное для ускорения.
На первый план выходят три шага.
Во-первых, закрепите эти три принципа. Сделайте фундаментальные принципы, ответственность и наблюдаемость обязательными требованиями для ваших команд. Включите в их в руководства по эксплуатации, планы производительности и обзоры архитектуры.
Во-вторых, проведите аудит вашего конвейера изменений. Определите самые рискованные изменения в локальной среде, частном облаке и гибридной среде. Выявите участки, в которых вы полагаетесь на удачу вместо того, чтобы проверять систему на устойчивость к критическим сбоям. Внедрите там более медленные, более тщательные проверки, а затем измерьте, сколько переделок и незапланированных простоев вы избежали.
В-третьих, инвестируйте в чистую телеметрию, прежде чем инвестировать в ИИ. Чем четче вы видите свои системы, тем более полезным становится ИИ в прогнозировании, корреляции и моделировании.
В серии «Взгляд в будущее 2026» было рассмотрено, как ИИ меняет угрозы, обеспечивает безопасность новых цифровых игроков и позволяет опередить технический долг ИИ. Заключительный вывод прост. В инфраструктуре ИИ не вознаграждает безрассудную скорость. Он вознаграждает лидеров, которые двигаются медленно, но целенаправленно, чтобы в нужный момент они могли двигаться быстро и уверенно.
Источник: Go Slow to Go Fast: The New AI Playbook for IT Infrastructure
