«Борг розуміння» або чому ШІ змушує мозок інженерів іржавіти

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Натрапив на цікаве обговорення про AI в SRE, яке зачепило доволі цікаву проблему сьогодення.

Я думаю, що з нині присутніх тут багато хто знає, що зараз AIшка вже спокійно може брати на себе значну частину роботи під час інцидентів: перевіряти алерти, дивитися логи й метрики, шукати аномалії, зіставляти проблему з останніми деплоями, формувати гіпотези й у деяких випадках навіть самостійно вносити фікс. Для команди це звучить майже ідеально, бо в результаті ти маєш менше ручної роботи, менше нічних підйомів через типові проблеми та нижчий MTTR.

Але нюанс в тому, що краще AI справляється з рутинними інцидентами, то рідше інженери самі розбираються, чому система впала. І в якийсь момент це може стати проблемою.

Найпростіші інциденти насправді теж потрібні

Умовний алерт про CPU, забитий диск, невдалий деплой або сервіс, який почав відповідати 500-ками, — це не найцікавіша частина роботи SRE. Але саме на таких ситуаціях поступово формується розуміння системи.

Де зазвичай починаються проблеми, яка метрика справді важлива, який сервіс може потягнути за собою інші, Що варто перевірити першим, а на що можна не витрачати час і так далі. Це знання складно отримати просто з документації.

А тепер уявімо, що більшість таких ситуацій автоматично закриває AI. Інженер отримує вже готовий результат: причина знайдена, все пофікшено, сервіс відновлено.

З одного боку звучить файно, так. А з іншого людина може навіть не викупати, що, як і чому було не так

А потім прилітає інцидент, якого ШI ще не бачив

Типові проблеми автоматизація закриває сама. Людям залишаються саме ті інциденти, які не вкладаються у звичайний сценарій.

Наприклад, одночасно починають деградувати кілька сервісів. Метрики суперечать одна одній. Останній деплой виглядає нормальним, а логи не показують очевидної причини.

AI перебрав стандартні гіпотези й нічого не знайшов. І тепер потрібен інженер. Але проблема в тому, що цей інженер останні пів року майже не дебажив нічого руками, бо більшість проблем закривали агенти.

В авіації цю проблему знають давно

В оригіналі автор проводить паралель з авіацією. Сучасний літак величезну частину польоту може виконувати на автопілоті. Але це аж ніяк не означає, що пілотам більше не потрібно вміти керувати літаком. Навпаки, вони регулярно тренують ситуації, які можуть ніколи не побачити за всю кар’єру: відмову двигуна, проблеми з приладами, перерваний зліт та інші аварійні сценарії.

Причина проста: якщо автоматика не впоралася, людина має бути готова перебрати керування. У розробці поступово виникає та сама проблема, тільки «авіасимулятора» немає в багатьох.

До речі, концепція авіалайнерів підіймали й у нас у коментарях на форумі.

І тут плавно підійду до однієї з ідей автора. Він каже, що якщо AI забирає реальні рутинні інциденти, практику можна частково повернути через симуляції. Наприклад, команді навмисно дають систему з проблемою, в ході дослідження якої інженеру потрібно знайти root cause, локалізувати проблему, прийняти рішення й паралельно координувати інцидент.

Фактично це щось між chaos engineering, game days і тренажером для on-call’ів. Причому AI тут необов’язково має бути тим, хто вирішує проблему. Він може навпаки її створювати: генерувати сценарії, підкидати нові симптоми, грати роль користувачів, support або менеджменту.

Але не одною автоматикою єдині

Мені тут дуже подобається термін comprehension debt. За аналогією з technical debt це борг у розумінні власної системи.

Система продовжує працювати, фічі релізяться, інциденти закриваються. Але дедалі менше людей можуть взагалі взяти і просто пояснити, чому конкретний компонент працює саме так, де він може зламатися і що робити, якщо звичайний сценарій перестане працювати.

Джерело: LinkedIn

З AI цей процес потенційно прискорюється, бо можна не тільки не писати частину коду самому, а ще й не розбиратися самому, чому цей код поклав половину проду. І поки AI правильно знаходить проблему, ніхто цього особливо не помічає. Про таке починають думати, коли він помиляється.

Якщо ви подумали, що я кажу, що треба відмовлятися від АІ в таких процесах, то ви помиляєтеся. Аж ніяк. Але думаю треба щось періодично робити власними руцями, створювати умови, де люди все ще змушені самі розбирати систему по шматках, аби шестерні в голові мали змогу крутитися. Можливо було б класно, якби це і на рівні компаній підтримували.

Бо інакше одного дня AI скаже «не знаю», а команда раптом зрозуміє, що теж давно не знає, з чого взагалі почати.

Розкажіть, чи думають про це вже у ваших командах? І чи є у вас якісь подібні практики? Можливо не централізовано, а самі чимось подібним займаєтеся, аби не давати навичкам заіржавіти?