Особисті ШІ-операції – багатоагентний напарник з експлуатації

Що агент читає, перш ніж узятися до роботи

Перед будь-якою операцією – привітання. На початку кожної сесії агент підвантажує два файли: CLAUDE.md пояснює, хто він такий і за якими правилами працює («обережний сисадмін, робить резервну копію перед руйнівними операціями, питає дозволу перед усім, чого не відкотити, за замовчуванням говорить українською»), а тека memory/* – це зібраний за попередні сесії перелік підводних каменів, файл за файлом. Саме привітання нічим не примітне; важить те, що все подальше агент починає, уже прочитавши обидва файли.

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

Одну річ про довіру варто сказати одразу, бо тільки завдяки їй усе це можна показати публічно: до серверів агент дістається лише через LXC-бастіон. SSH-ключі до кожного хоста лежать там і більше ніде, тож навіть якби цю сесію в терміналі перехопили, жоден ключ до хоста не витік би разом із нею. З тієї ж причини cron може запускати ці оновлення, поки всі сплять.

Стек, який оновлюється тільки цілком, тепер оновлюється сам

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

Задум агента окупається саме там, де зазвичай зрізають кути. Спершу він робить резервну копію – логічний дамп плюс архів томів, – а тоді керує юнітами systemd, а не стартовим скриптом стека: у cron пароль вводити нікому, і наївний шлях мовчки обривається на півдорозі, а обидва стеки лишаються лежати. Остаточно переходить на нову версію агент лише тоді, коли всі 13 контейнерів справні, а студія відповідає 200; за будь-якого збою спрацьовує гілка rescue і повертає останній коміт, про який точно відомо, що він працював. Ця оболонка – копія, спроба, перевірка стану, автоматичний відкат – і є вся суть.

Для бізнесу це означає, що стек із 13 контейнерів тепер оновлюється сам і нікому не треба пильнувати перезапуск о 02:00, а єдиного разу, коли оновлення таки зламалося, система за кілька хвилин сама повернулася до робочого стану, і вранці оператора не зустріла аварія. Цей збій не вигаданий: перший справжній запуск попередньої версії потрапив саме в описану вище пастку з cron і sudo. Тому показаний тут варіант перевіряє стан і працює через systemd, а не покладається на везіння.

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

Як лавина CVE перетворюється на три рішення

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

Завдання агента – перетворити цю лавину на короткий список рішень, і сортує він за двома питаннями: чи можна до образу дістатися ззовні і чи цю вразливість узагалі можна виправити. Спершу агент відкидає все, для чого виправлення ще не випустили, а решту зважує за тим, наскільки образ відкритий: до образів на публічному VPS планка значно суворіша, ніж до внутрішніх, захованих за mesh-мережею та автентифікацією на проксі. Так 1886 сирих знахідок стискаються до трьох образів, які справді варто чіпати цього вечора.

Чесним наступне сканування тримає звичка записувати, чому решту лишили. Здебільшого це постійні дрібні зміни в базових образах, версії яких закріпили самі автори скоординованих стеків; якщо їх латати, випуск зламається, тож їх записують як «прийнято з причиною» (accept-with-reason), а не тихо ігнорують. Суботній звіт наступного тижня до них уже не повертається – показує лише те, що змінилося. «Прийнято з причиною» – той самий хід, що й перевірки на розбіжності в інших місцях репозиторію: мета – не нуль знахідок, а нуль неперевірених. Записане прийняття ризику – це рішення; проігнороване попередження – це борг.

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

Нова мажорна версія бази даних, якої сайт навіть не помітив

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

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

Крок, який людина в поспіху пропускає, – подивитися, як стартує рушій. Агент стежить за журналом запуску й читає його, перш ніж робити висновки: чистий рядок «ready for connections» чи цикл аварійного відновлення або список таблиць, що не піднялися, – це різниця між тим, щоб лишити нову версію, і відкатом, і в журналі її видно на цілу хвилину раніше, ніж перший відвідувач помітив би повільну сторінку. Остаточно переходить на нову версію агент лише тоді, коли живий сайт відповідає 200, а сторінка з даними з бази відкривається.

Для бізнесу це означає, що оновлення, під яке фрилансер заклав би в кошторис технічну перерву, стає запланованою операцією, за якою стежать і яку можна відкотити, – і сайт клієнта пройшов крізь неї, не спіткнувшись. Єдиний слід, який бачить власник, – рядок у журналі змін і дамп, що зберігається сім днів про всяк випадок. Справжній результат тут – сам перелік кроків, а не MariaDB 11: його один раз записано як покрокову інструкцію, і кожне наступне оновлення – Postgres, векторне сховище, наступний клієнт – отримує ту саму оболонку. Номер версії змінюється; порядок дій – ні.