Принципи на AI-driven инфраструктурата
AI агентите отлично генерират шаблонен код, анализират логове и обясняват legacy код. Но инфраструктурата не е обикновен код. Тя има състояние, необратимост, каскадни зависимости, слаби връзки и тайни директно в работния поток. За LLM преименуването на ресурс и изтриването на база данни са просто промяна на редове.
Моите принципи може и да не са идеални, но това е натрупаното от година и половина работа с агенти в инфраструктурата.
Подготовка на средата
1. Принудителни ограничения
Агентът не трябва да решава да не чупи production — той не трябва да има възможност да го направи.
LLM нестабилно следват забрани, особено в дълги сесии. Затова средата на агента трябва да работи с инфраструктурата само в режим read-only. Мутиращи операции — само през отделен pipeline след изрично одобрение от човек.
2. Тайните извън контекста на агента
Контекстният прозорец е потенциален канал за изтичане на данни. State файловете на OpenTofu/Terraform съдържат пароли, ключове и endpoint-и в открит вид. Helm values и Ansible group_vars често съдържат идентификационни данни. Реални атаки показаха, че агентите по подразбиране третират частните данни като всякакви други — без да правят изключения за тях.
Методи за защита:
- Пълна недостъпност на тайните
- Блокиране на достъпа до файлове
- Липса на споменаване на файлове и нестандартно разполагане
- Използване на файлове-примамки
3. Верификация на източниците и веригата на доставки
Агентът използва MCP сървъри, skills, външни модули, community charts, разширения за IDE — всеки от тях е потенциален вектор на атака.
Правило: агентът свързва само изрично разрешени източници с фиксиране на версии и lock файлове. Нов MCP/skill/модул/разширение се добавя само след ревю от екипа.
Поставяне на задачата
4. Контекст = код + състояние + решения
LLM вижда конфигурационните файлове, но не знае какво реално работи на сървърите в момента. Без контекст агентът ще подложи “разумни стойности по подразбиране” от обучаващите данни. Затова агентът трябва да получава данни от кода, от вас, от tofu plan, kubectl get, ansible-inventory, от описания на зависимости, ограничения (бюджет, SLA, compliance) и причини за решения (ADR, SRS). Всичко, включително онова, което “всички и без това знаят” — всичко трябва да е в контекста на агента.
5. Делегирай само това, което е евтино за проверка
Агентът винаги може да сгреши — въпросът е колко бързо и надеждно ще го откриете.
Цената на проверката се определя от няколко критерия:
| Критерий | Евтино за проверка | Скъпо за проверка |
|---|---|---|
| Автоматизация на проверката | Има инструменти: tofu validate, helm lint, molecule test | Само ръчен анализ и експертна оценка |
| Яснота на промените | Промените са видими изцяло в plan/diff | Страничните ефекти са скрити (DNS propagation, IAM policy evaluation, мрежови маршрути) |
| Брой зависимости | Изолиран ресурс, малко връзки | Каскадни зависимости между компоненти |
| Обратимост | Откат за секунди: tofu apply на предишното състояние | Откатът е невъзможен или изисква даунтайм (миграция на данни, смяна на CIDR) |
| Необходима експертиза | Всеки инженер от екипа ще разбере plan | Нужен е дълбок контекст (мрежова топология, ред на миграция, compliance) |
6. Явна йерархия на приоритетите
Агентът не “усеща” какво е загуба на данни или даунтайм. За него те по подразбиране са по-малко важни от инструкциите, а още повече — от заявката на потребителя.
Без йерархия агентът може в опит за оптимизация на скоростта или “чистотата” на кода да пренебрегне например данните. Явен ред в AGENTS.md:
- Съхранност на данните и достъпност на услугите
- Сигурност
- Съответствие със стандартите
- Коректност на реализацията
- Скорост и удобство
Всяко ниво не може да бъде нарушено в полза на по-ниско стоящо. Агентът не изтрива и не пресъздава RDS заради “чистота” (удобство срещу съхранност на данните). Не отваря 0.0.0.0/0, за да “заработи” (коректност срещу сигурност). Не поставя force_destroy = true на S3, за да опрости кода (удобство срещу съхранност на данните).
На този ред трябва да бъдат настроени и независимите автоматични ревюъри, които ще разглеждат промените като “чужд” код и няма да са склонни да ги “оправдават”.
Генериране на код
7. Малки стъпки, чести контролни точки
LLM деградират при дълги вериги от разсъждения, а инфраструктурните промени са каскадни, с малко типизация и по-неявни връзки, отколкото в обикновения код.
Една итерация = една логическа промяна = един tofu plan / helm diff / ansible --check = един комит. Не “мигрирай целия VPC”, а “добави subnet в нова AZ, покажи plan”. Всяка контролна точка е място, където човек може да спре и да откати един комит, а не целия рефакторинг.
Верификация на резултата
8. Детерминистична верификация вместо доверие
LLM зле намират собствените си грешки — молбата “провери” често води до убедително обосноваване на грешен отговор.
Резултатът на агента се проверява от верига инструменти. Ключовият усилвател е затвореният цикъл на обратна връзка: агентът вижда изхода, поправя грешката, повтаря проверката. Качеството на резултата е пропорционално на качеството на обратната връзка.
9. Автоматична оценка на зоната на поражение
AI не разбира последствията — за него смяната на instance type и изтриването на RDS са равнозначни. Затова зоната на поражение трябва да се изчислява автоматично от изхода на инструментите: OPA/Sentinel policies върху tofu plan, класификация на операциите (create/update/destroy), отчитане на засегнатите ресурси и тяхната критичност.
Агентът може да подчертава несъразмерността на зоната на поражение спрямо решаваната задача, но не трябва дори да оценява степента, тъй като това отпуска бдителността на оператора.
10. Контрол на разходите
AI агентът генерира “разумна” конфигурация от обучаващите данни, но няма представа за вашия бюджет.
GPU инстанс вместо CPU, NAT Gateway във всяка AZ, RDS с излишни ресурси — всичко това изглежда коректно в plan, минава валидация, но може да струва многократно повече от необходимото.
Оценката на разходите (infracost, usage-based estimation) трябва да бъде част от цикъла на обратна връзка наравно с tofu validate и plan. Агентът вижда делтата на разходите и спира, ако тя надхвърли прага.
Екип и процес
11. Противодействие на деградацията на уменията
AI кодът изглежда професионално, минава линтери — и притъпява бдителността.
Изследвания показват по-слаба когнитивна ангажираност при потребителите на AI инструменти: запомнят по-зле, чувстват по-малко отговорност. Екип, който е престанал да разбира собствената си инфраструктура, не може самостоятелно да реагира на инцидент в ситуация, когато агентът е недостъпен или не може да получи пълния контекст.
Контрамерки: редовни “ръчни дни” без агент, ротация на on-call със задължителен разбор на инфраструктурата, code review на AI кода със същото внимание, както към кода на джуниър, периодични учения по инциденти без достъп до AI.
Всички принципи се свеждат до една идея: AI агентът е мощен генератор, но не арбитър. Той пише код, а детерминистичните инструменти и хората решават дали този код може да се приложи. Колкото по-евтино е да провериш резултата — толкова повече може да делегираш.