Масштабная
реорганизация инфраструктурного кода: как мы улучшили управление
сайтом

В феврале 2026 года мы провели масштабную реструктуризацию кодовой
базы, которая управляет нашим веб-сайтом. Это была не просто
косметическая переделка — мы полностью переосмыслили архитектуру
проекта, чтобы сделать его более понятным, поддерживаемым и
масштабируемым.

Проблема: хаос в корневой
директории

Представьте: вы открываете проект и видите 30+ файлов в корневой
директории. Скрипты для SSL, WordPress, sitemap, SQL-запросы, временные
файлы, документация — всё вперемешку. Найти нужный файл становится
квестом, а понять, что актуально, а что устарело — ещё сложнее.

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

Решение:
структурированная архитектура

Мы разработали новую структуру проекта, основанную на принципе
разделения ответственности (separation of concerns). Вот что
получилось:

До реорганизации

majotrade-net/
├── simulate_dns_challenge.py
├── finalize_ssl.py
├── complete_ssl_generation.sh
├── get_dns_challenges.sh
├── wp_quick_update.sh
├── update_about_clean.py
├── fix_ml_bot_links.sql
├── restore_ml_post.sql
├── generate_sitemap_standalone.sh
├── sitemap_cron.sh
├── ansible.cfg
├── inventory.yml
├── playbooks/ (100+ файлов)
├── roles/
... и ещё 20 файлов в корне

После реорганизации

majotrade-net/
├── ansible/              # Вся Ansible инфраструктура
│   ├── playbooks/        # 100+ playbooks
│   ├── roles/            # 8 ролей
│   ├── inventories/      # dev/prod окружения
│   └── ansible.cfg       # Конфигурация
├── docs/                 # Документация по темам
│   ├── ssl/              # SSL сертификаты
│   ├── wordpress/        # WordPress
│   └── sitemap/          # SEO
├── scripts/              # Утилиты по категориям
│   ├── ssl/              # SSL автоматизация
│   ├── wordpress/        # WordPress утилиты
│   └── sitemap/          # Sitemap генерация
├── sql/                  # SQL скрипты
│   ├── fixes/            # Исправления
│   └── maintenance/      # Обслуживание
├── content/              # Контент для публикации
│   └── ready-to-upload/  # Готовые статьи
├── archive/              # Устаревшие файлы
├── backups/              # Локальные бэкапы
└── README.md             # Обновлённая документация

Процесс миграции: сохраняя
историю

Ключевым требованием было сохранение истории изменений в Git. Мы
использовали git mv для всех перемещений файлов, что
позволило:

• Сохранить историю коммитов для каждого файла
• Не потерять информацию об авторах изменений
• Обеспечить возможность отката при необходимости

Статистика миграции

• Перемещено файлов: 219
• Создано директорий: 15
• Обновлено конфигураций: 5
• Сохранена история: 100%
• Время выполнения: 2 часа

Технические детали

Категоризация скриптов

SSL автоматизация (scripts/ssl/): —
simulate_dns_challenge.py — извлечение DNS TXT записей —
finalize_ssl.py — автоматическое завершение генерации —
complete_generation.sh — проверка DNS и копирование
сертификатов

WordPress утилиты (scripts/wordpress/):
— update_about.py — обновление страницы “О сайте” —
quick_update.sh — быстрые обновления контента

Sitemap генерация (scripts/sitemap/): —
generate.sh — генерация sitemap.xml — cron.sh
— автоматическое обновление по расписанию — validate.sh —
проверка корректности sitemap

Организация SQL скриптов

Разделили SQL скрипты на две категории:

Исправления (sql/fixes/): — Исправление
ссылок в постах — Коррекция метаданных

Обслуживание (sql/maintenance/): —
Восстановление постов — Обновление страниц

Ansible инфраструктура

Вся Ansible автоматизация теперь в одном месте:

• 100+ playbooks — от бэкапов до публикации
  постов
• 8 ролей — модульная архитектура
• 3 окружения — development, staging, production

Преимущества новой структуры

1. Ясность и понятность

Теперь любой разработчик может за минуту понять, где что находится: —
Нужен SSL скрипт? → scripts/ssl/ — Ищете документацию? →
docs/ — Ansible playbook? →
ansible/playbooks/

2. Легче поддержка

Когда файлы организованы логически, проще: — Находить и исправлять
баги — Добавлять новый функционал — Проводить code review — Онбордить
новых участников

3. Масштабируемость

Структура спроектирована с учётом роста: — Каждая категория может
расширяться независимо — Новые скрипты добавляются в соответствующие
директории — Документация растёт вместе с кодом

4. Следование best practices

Новая структура соответствует индустриальным стандартам: — Ansible
project layout — Разделение кода и данных — Чёткая иерархия
зависимостей

Обновлённый процесс работы

Создание бэкапа

Было:

ansible-playbook playbooks/backup-rotation.yml -i inventories/production/hosts.yml

Стало:

cd ansible
ansible-playbook playbooks/backup-rotation.yml -i inventories/production/hosts.yml

Обновление SSL

Было: Найти нужный скрипт среди 30 файлов в
корне

Стало:

cd scripts/ssl
python3 simulate_dns_challenge.py
bash complete_generation.sh

Публикация поста

Было:

ansible-playbook playbooks/publish-markdown-post.yml -i inventories/production/hosts.yml

Стало:

cd ansible
ansible-playbook playbooks/publish-markdown-post.yml 
  -i inventories/production/hosts.yml 
  -e "markdown_file_path=../content/ready-to-upload/post.md"

Уроки и выводы

Что мы поняли

1. Технический долг накапливается незаметно
   • Каждый “быстрый фикс” в корне казался безобидным
   • Через год это превратилось в серьёзную проблему
2. Рефакторинг требует времени
   • 2 часа на миграцию
   • 1 час на обновление документации
   • Но это инвестиция, которая окупается
3. Автоматизация должна быть организованной
   • 100+ playbooks — это нормально
   • Но только если они структурированы

Рекомендации для других
проектов

1. Начинайте со структуры
   • Продумайте организацию с первого дня
   • Легче поддерживать порядок, чем наводить его потом
2. Документируйте решения
   • Почему файл лежит именно здесь?
   • Какова логика организации?
3. Используйте Git правильно
   • git mv сохраняет историю
   • Один большой коммит лучше множества мелких при рефакторинге
4. Не бойтесь больших изменений
   • 219 перемещённых файлов — это нормально
   • Главное — сохранить работоспособность

Что дальше?

Реорганизация — это не конечная точка, а начало новой главы:

1. Автоматические тесты
   • Проверка playbooks перед коммитом
   • Валидация скриптов
2. CI/CD pipeline
   • GitHub Actions для автотестов
   • Автоматический деплой изменений
3. Улучшение документации
   • Добавление примеров использования
   • Видео-туториалы
4. Мониторинг и алертинг
   • Отслеживание здоровья инфраструктуры
   • Проактивные уведомления о проблемах

Заключение

Реорганизация инфраструктурного кода — это инвестиция в будущее
проекта. Мы потратили всего несколько часов, но получили:

• Чистую структуру — легко ориентироваться
• Масштабируемость — готовы к росту
• Поддерживаемость — проще находить и исправлять
  проблемы
• Профессионализм — соответствие индустриальным
  стандартам

Если ваш проект страдает от хаоса в файловой структуре, не
откладывайте рефакторинг. Чем раньше вы наведёте порядок, тем легче
будет поддерживать и развивать проект в будущем.

---

Технические детали: — Проект: Ansible-based
WordPress automation — Язык: Python, Bash, YAML — Система контроля
версий: Git — Хостинг: reg.ru shared hosting — Автоматизация: Ansible
2.9+

Ключевые метрики: — Файлов в корне: 30+ → 19 —
Директорий верхнего уровня: 15 → 8 логических групп — Время на поиск
файла: ~2 минуты → ~10 секунд — Понятность для новичков: значительно
улучшена

Хотите обсудить организацию инфраструктурного кода или поделиться
опытом рефакторинга? Пишите в комментариях!