Автор материала — Роман Шубин, CTO и автор канала Bash Days.
Введение
Когда не было Google, информация по Unix/Linux добывалась исключительно из FTN-сетей, FIDO и региональных форков. Но попасть в них было тем еще квестом: нужно было найти нужного человека и надеяться, что он поделится доступом. Если вы застали времена GoldED, tmail, tosser и запуск BBS через двойное нажатие ESC, то понимаете, о чем речь. В подробности уходить не будем.
Еще были книги, но чаще они писались энтузиастами «на коленке» и мало чем помогали. Настоящий опыт приходил через практику и ошибки. Одно только конфигурирование Xorg в старых Red Hat’ах было приключением: не получилось — переустанавливай.
Когда появился Google, в первое время к нему отнеслись настороженно, как ко всему новому. Но сейчас сложно представить работу без него. То же самое происходит и с искусственным интеллектом: кто-то настроен скептически, но реальность уже изменилась. Я замечаю это каждый день, общаясь со своими студентами: никто из них не решает домашние задания самостоятельно, ведь с ИИ можно получить ответ гораздо быстрее, чем найти его в Google.
Здесь важно понимать, что именно предлагает ИИ, а не бездумно копировать. Иначе — прямая дорога к деградации.
Каким должен быть AI-специалист?
Теперь к делу. Представим, что мы хотим передать все DevOps-задачи искусственному интеллекту. Для этого нам нужно что-то вроде «Джарвиса» Тони Старка, только умнее. Что-то такое, что сможет решение без участия человека — операционная система нового поколения с ИИ на уровне ядра. Не набор скриптов, не прикрученная модель, а именно встроенный интеллект. Такая ОС должна быть подключена к интернету и использовать ресурсы дата-центра.
А теперь предположим, что подобная ОС уже существует и у нас есть консоль для управления ею. Что дальше? Дальше начинается новая эра администрирования — автоматизированная, умная и куда менее рутинная.
Как работает ИИ-ядро в идеальном мире?
Главное, о чем должно заботиться ядро, — чтобы прод не падал. Как с мифической кнопкой «Сделать хорошо» — нажал, и все желания исполнены.
Смоделируем несколько сценариев и посмотрим, как оно может работать.
Прод начинает тонуть в логах, место на диске утекает. Ядро проверяет: установлен ли Logrotate? Если нет — устанавливает, затем настраивает конфигурации под сервисы и включает архивацию. Прод спасен.
В MySQL увеличивается число потоков. Ядро анализирует логи nginx, находит проблемный URL, проверяет SQL-запрос. Видит, что в конфиге не заданы параметры кэширования — добавляет, настраивает и кэширует.
Не помогло? Ядро решает поднять репликацию, разворачивает прокси-балансировщик и распределяет запросы между репликами. Потоки нормализуются. Нагрузка падает, мы кладем репликации и высвобождаем для экономии ресурсы.
Атака! ИИ-ядро фиксирует попытки взлома, включает защиту согласно OWASP и применяет WAF. Атака похожа на DDoS, поэтому искусственный интеллект блокирует маршруты на уровне провайдера без обращения в РКН и отсекает трафик из подозрительных стран.
Параллельно ИИ собирает данные о злоумышленнике из открытых источников. В идеале находит IP и отправляет заявление в полицию с приложенным отчетом.
И самый распространенный пример — бэкапы. Никто не любит с ними возиться, особенно проверять, что они действительно восстанавливаются. ИИ-ядро делает это само: распаковывает, проверяет целостность, убеждается, что данные читаются и готовы к восстановлению.
Кейсы могут быть любыми. Главное, что решения здесь принимает не DevOps-инженер, а умная операционная система.
Удобно? Не то слово — мечта!
Так инженеры больше не нужны?
На первый взгляд, ИИ хорошо справляется, так что инженеры действительно больше не нужны. Но нет! Давайте рассуждать рационально.
С момента появления ИИ я использую его регулярно. Так вот, в 99% случаев за ним приходится перепроверять все ответы. Даже если указать на ошибку, он извинится, предложит исправление… И снова ошибется.
Доверил бы я такому «сотруднику» инфраструктуру без дополнительного контроля? Точно нет: его нельзя переобучить, а если и получится, то в следующий раз это может обернуться большими проблемами с продом.
Теперь посмотрим на описанные выше примеры под другим углом.
Что, если после изменения конфига MySQL упадет? Порой ИИ предлагает устаревшие настройки, несовместимые с текущей версией. Чтобы не ошибаться, он должен постоянно быть в курсе всех обновлений.
Или, допустим, Logrotate работает исправно, а место забивается совсем другим — искусственный интеллект просто принял неверное решение? Тогда прод все-равно упадет. Обычно такие ситуации рассматриваются индивидуально, в частном порядке. Здесь нет каких-то четких инструкций, специалист сам анализирует ситуацию и только потом определяется с решением проблемы.
А если резкий рост трафика вызван не атакой, а распродажей вроде «Черной пятницы»? Бизнес будет не рад, если ИИ внезапно заблокирует весь поток клиентов.
И последний пример — с приложением. Может случиться так, что искусственный интеллект будет масштабировать ресурсы и конфигурировать sysctl, а проблема окажется в приложении, в утечке памяти. ИИ не будет переписывать код, потому что этим занимается живая команда людей. А давать нейросети доступ к коду — равносильно вайб-кодингу со всеми его недостатками.
Какие выводы?
Я не доверю работу такому ядру. ИИ не сотрудник, которого можно пожурить, и он в следующий раз учтет ошибки. Он не исправляется — просто делает все заново, иногда хуже, чем до этого. И это может дорого стоить. Так что в наше время ни один искусственный интеллект не заменит человека. Максимум, что он может — направить в нужное русло и дать зацепки, которые помогут продвинуться дальше.
