O Di

С контролером домена есть маленькая заминка - эта "сволочь" отключает кэширование на диске где хранится база AD. Как правило, это системный диск, т.е. это практически исключает нормальное функционирование как сервера приложений 1С так и SQL-сервера.

Для 1С 7.7, 8.х, сервера 8.х решающее значение имеет скорость одного ядра, т.к. 1С до сих пор фактически однопоточное приложение, т.е. сервер 1С лучше разворачивать на i5. Суда же можно запихнуть файлопомойку.

На Xeone разверните SQL и терминал. Вряд ли быстродействие 7.7 для вас имеет критическое значение, а вот автокад ЕМНИП нормально умеет параллелить задачи.

КД и DNS загоните в виртуалку - это чисто технологические функции, для 15 компов жирновато для них отдельную физическу машину гробить. Виртуалку уже размещайте исходя из фактической загрузки машин.

В принципе SQL и файлопомойку можно поменять местами, но это нужно понимать, что у вас там с Автокадом делается и быстродействие чего вам важнее - 1С или автокада.

ИМХО!
DNSMASQ - некий комбайн, в котором все есть. Я же сторонник того, что бы все это самому сделать, и знать как и что работает.
Ставь isc-dhcp-server, bind9 этого будет достаточно для управления.
ссылок по настройке этого добра навалом:
https://wiki.debian.org/DDNS - вот к примеру, только я бы ключ он управления днс вписывал бы в явном виде в dhcpd.conf

1. Vagrant, или docker с системой максимально похожей на production сервер. Разработку ведем там.
2. Если никакая vcs не используется - пи"№;ц конечно, но быстро подключайте, иначе бида обеспечена. Рекомендую git + git-flow.
3. Правки в БД ТОЛЬКО на основе миграций, при этом создавайте как up, так и down.
4. Возьмите готовую систему для диплоя, либо напишите свой скрипт для этого. Цель в том, что бы минимизировать человеческий фактор при обновлении продакшна на столько, на сколько это возможно.
5. Все, что находится в /vendor - обязательно должно быть заигнорировано в vcs, composer.json И composer.lock (спс OnYourLips) должен ссылаться на фиксированные версии пакетов.
6. Код ОЧЕНЬ-ОЧЕНЬ-ОЧЕНЬ желательно покрыть тестами. Самый кульный вариант - запуск тестов после push изменений в главный репозиторий. Для этого можно использовать связку gitlab + gitlab-ci.
7. На счет доменов - в чем проблема то? Вынесите домен в конфигурацию, и создайте конфиги для локального, тестового и боевого окружений.
8. На счет записей в БД: да, они обязаны отличаться. По хорошему на проде руками в принципе можно только смотреть, а записывать нельзя. Для тестовой БД - пишите фикстуры.
9. сразу подумайте на счет логов: если их over-дофига, имеет смысл использовать системы типа logstash, или sentry.