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