Как я создавал курс по Linux с помощью ИИ и почему он превратился в практику

Когда я задумал структурировать свои знания, моя первая версия учебных материалов превратилась в банальный курс по shell-скриптингу. Я ставил перед собой задачу разобраться с реальными системными задачами — правами доступа, системными службами, логами, монтированием дисков и сетевыми настройками. Однако на выходе я получил стандартный набор из полусотни заданий с формулировками вроде «напиши скрипт, который делает то-то». При детальном анализе выяснилось, что в каждой серии учебного процесса человек совершает абсолютно одинаковое действие: открывает текстовый редактор и пишет код на bash.

Техническая причина такого перекоса оказалась банальной. Скрипты невероятно легко автоматизированно проверять: запустил файл, посмотрел текстовый вывод в консоли, сравнил с эталоном. Все остальные аспекты администрирования проверять неудобно, поэтому они естественным образом выпали из программы. Искусственный интеллект, которому я диктовал структуру, пошел по пути наименьшего сопротивления, опираясь на свойственное программированию стремление всё автоматизировать. Но настоящий администратор большую часть рабочего времени занимается вовсе не написанием скриптов. Он читает конфигурационные файлы, анализирует текущие процессы и разбирается, почему инфраструктура ведет себя не так, как описано в документации.

О структуре и организации проекта Kernel Shadows

В итоге у меня получился масштабный практический проект под названием Kernel Shadows. Это бесплатный репозиторий на GitHub, распространяемый под лицензией GPL v3 и состоящий из 101 серии, разделенной на восемь логических сезонов. Проект оформлен не как видеоплатформа или интерактивный сайт, а как структурированный текстовый архив. Каждая отдельная папка соответствует конкретной серии и содержит файл README с теоретическим введением и заданием, заготовку исходного кода, автоматические тесты и эталонное решение. Весь учебный процесс я прохожу непосредственно в редакторе с интегрированным терминалом, чаще всего используя Cursor, без какой-либо утомительной регистрации и лишних платформ.

Инфраструктура серии устроена максимально прозрачно. Например, в директории starter/ лежат файлы с пробелами и специальными метками для выполнения заданий. Запуск локальных тестов сразу выдает ошибки, что является абсолютно нормальной частью рабочего процесса. Самое ценное здесь заключается в том, что продвинутые проверки анализируют не просто текстовый вывод, а логику работы решения — например, запускают скрипт из разных директорий, чтобы убедиться в отсутствии захардкоженных путей. Рядом всегда находится папка solution/ с эталоном, но заглядывать туда до собственной попытки бессмысленно, так как система сборки make progress не засчитает выполнение, пока тесты не пройдут успешно на вашем собственном файле.

Балансировка типов заданий и борьба со скриптами

Чтобы проект не скатывался в бесконечное написание оболочки bash, я жестко регламентировал типы серий и заложил строгий баланс в критерии приемки каждого сезона. Теперь сезоны, состоящие исключительно из автоматизации, просто не принимаются. В итоговой структуре нагрузка распределена следующим образом: четверть учебного времени уходит на автоматизацию, значительная часть посвящена работе с конфигурациями, разбору инцидентов и написанию вспомогательного кода на Python или C.

Проверка навыков расследования инцидентов потребовала отдельного подхода. Я принципиально запретил использовать тесты, требующие прав суперпользователя root, реального подключения к сети, развертывания громоздкого Docker или сложного железа. Такой подход гарантирует, что курс сможет пройти любой человек на своем ноутбуке. Например, вместо обращения к реальной сети тесты подменяют системные утилиты вроде ping или ss на изолированные заглушки, проверяя не физическую связность, а корректность обработки кодов возврата и логику анализа ответов.

Анализ конфигураций без запуска реальных служб

Серьезным вызовом стали темы, связанные с systemd и сложными конфигурациями. Возникал закономерный вопрос: как проверить правильность написанного юнита .service, если сам systemd в условиях изолированного теста запустить невозможно? Решение оказалось элегантным — запускать службу и не нужно. Конфигурационный файл представляет собой текст со строгой семантикой, которую можно программно воспроизвести. Тестовый скрипт анализирует файл точно так же, как это делает сам системный менеджер: учитывает приоритет секций, перезапись параметров последними значениями и игнорирование комментариев.

Такой статический разбор конфигураций неожиданно оказался намного полезнее простого запуска службы. Запущенная служба подтверждает лишь то, что она смогла стартовать здесь и сейчас в текущем окружении. Глубокий разбор синтаксиса отвечает на вопрос «что именно здесь написано», что и является ключевым профессиональным навыком. Аналогичным образом проверяются файлы fstab, logrotate, манифесты Kubernetes и настройки SSH. Побочным приятным эффектом стало то, что тесты находят скрытые ошибки, которые в реальной эксплуатации всплывают спустя недели: директивы, затерянные внутри комментариев, дублирующиеся параметры или некорректный порядок сетевых правил.

Техническая надежность тестовой среды

Чтобы тесты оставались честными и работали на любой машине одинаково стабильно, в Makefile пришлось внедрить несколько дополнительных проверочных целей. Первая цель запускает все проверки дважды подряд, вылавливая сценарии, где второй прогон спотыкается о мусор, оставленный предыдущим запуском. Вторая цель принудительно переключает локаль и часовые пояса, что позволяет вовремя заметить ошибки в тестах, завязанных на особенности сортировки текста. Третья цель полностью разворачивает проект из чистого клона репозитория, предотвращая ситуации, когда локальные учебные файлы случайно попадают под действие стандартных правил игнорирования гита.

Масштаб инфраструктуры и роль искусственного интеллекта

Итоговая программа представляет собой восьмисезонную историю администрирования полусотни узлов распределенной инфраструктуры. Каждая серия рассчитана на полтора часа плотной работы и завершается созданием конкретного проверяемого артефакта. Примечательно, что оба моих объемных курса были собраны при активном содействии искусственного интеллекта практически без ручного написания рутинного кода. ИИ помог выстроить персональную программу обучения под мои реальные запросы, а также выступал в роли технического наставника по ходу выполнения заданий, вовремя останавливая меня от соблазна применить простые, но вредные для обучения шаблонные решения.