# Инфраструктура разработчика 1С на постоянном обслуживании

## Что за инфраструктура

Компания-разработчик решений на платформе 1С. Своя площадка на арендованных серверах, кластер виртуализации из трёх узлов, около восьмидесяти виртуальных машин. Это не «пара серверов с бухгалтерией», а полноценное производственное хозяйство:

- **1С** — больше десятка серверов приложений на Linux и Windows, несколько версий платформы одновременно, шина обмена, отдельные стенды под демонстрации и обучение;
- **базы данных** — Microsoft SQL Server, PostgreSQL нескольких версий и сборка, специализированная под 1С;
- **домен и учётные записи** — собственный каталог пользователей с синхронизацией в облачный, единый вход в сервисы;
- **почта** — свои почтовые серверы со шлюзом фильтрации;
- **разработка** — GitLab, Jenkins, автотесты конфигураций 1С;
- **мониторинг** — два стека сразу: классический для железа и служб, метрики с логами для приложений; плюс сервис-деск и удалённое управление рабочими местами;
- **коммуникации** — корпоративный чат, видеоконференции, облачное хранилище с офисным пакетом, база знаний;
- **прочее** — видеонаблюдение, VPN для сотрудников и администраторов, публикация баз 1С для веб-клиента.

Несколько версий платформы 1С, зоопарк из Linux и Windows, разработка и продуктив на одной площадке — обслуживать такое интереснее, чем однородный кластер.

![Состав инфраструктуры разработчика 1С: 3 узла виртуализации и около 80 VM](/images/illustrations/part2/19-case-1c-overview.webp)

## Что делаем постоянно

**Мониторинг того, что раньше не отслеживалось.** Настроили сбор метрик с Windows-серверов и, отдельно, слежение за аварийными завершениями рабочих процессов 1С — на Linux и на Windows разными способами. Провели аудит срабатываний: убедились, что алерты приходят по делу, и вычистили те, что шумели впустую. Заодно нашли агентов, которые числились живыми, а данных не отдавали.

**Разбор инцидентов.** Из живых примеров:

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

**Работа с производительностью.** Разобрали сборку, которая шла четыре с половиной часа: посчитали, куда именно уходит время, что можно выполнять параллельно и сколько ресурсов для этого нужно добавить. Отдельно следим за нагрузкой на серверы 1С и за тем, чтобы память узлов не уходила в потолок.

**Планирование ёмкости.** Кластер подошёл к пределу: занятость памяти держалась около 90 % на всех узлах. Собрали данные по железу, посчитали, сколько нужно, и в согласованное окно нарастили память на всех трёх узлах — с учётом того, что один из них терминирует внешний канал и его перезагрузка задевает не только его виртуалки.

Дальше — план консолидации: вывести старый узел, добавить новый, довести память до целевой. Расчёт показал, что процессоров и памяти хватит на два-три года, а вот дискового пространства не хватает почти на два десятка терабайт — и это надо решать до вывода старого узла, а не после. Отдельно отмечен риск: часть нагрузки 1С переезжает на процессоры, которые вдвое медленнее в однопоточных задачах, а 1С к этому чувствительна.

**Переезд из облака на своё железо.** Почта, видеоконференции, файлы и совместная работа с документами жили в Яндекс 360 — по подписке за каждого сотрудника. Заменили весь этот набор своими сервисами на площадке заказчика:

| Было в облаке | Стало на своём железе |
| --- | --- |
| Почта | почтовый сервер Postfix + Dovecot: приём, хранение, отправка, доступ по защищённым протоколам изнутри и снаружи |
| Фильтрация спама на стороне провайдера | отдельный антиспам-шлюз Proxmox Mail Gateway перед почтовиком |
| Телемост | сервер видеоконференций Jitsi Meet — без ограничений по длительности и числу участников |
| Диск и документы | Nextcloud с онлайн-редактором: общие папки и совместная работа над документами |

Почту переносили так, чтобы не потерять ни письма. Сначала свой сервер несколько недель работал зеркалом облачного: ящики наполнялись копией. Потом направление развернули — свой стал основным, облако осталось запасным. Перед переключением привели в порядок репутацию домена: SPF, DKIM, DMARC и PTR, заранее снизили TTL записей, чтобы переключение прошло быстро. Пожили в параллельном режиме и только после этого отказались от подписки — это точка невозврата, и делать её первой нельзя.

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

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

![Замена сервисов Яндекс 360 собственными почтой, фильтрацией, видеовстречами и файлами](/images/illustrations/part2/20-case-1c-cloud-exit.webp)

**Свои утилиты вместо ручных операций.** Две повторяющиеся процедуры, которые раньше делались руками по инструкции, превратились в веб-сервисы:

*Публикация баз 1С.* Чтобы база стала доступна через браузер, нужно создать каталог, написать конфигурацию веб-сервера, вызвать штатную утилиту платформы и аккуратно перезапустить веб-сервер. Раньше — десяток шагов в терминале с правами администратора, теперь — форма: имя базы, сервер, отметка «перепубликовать». Разработчику больше не нужно ждать администратора ради нового стенда.

*Перенос хранилищ конфигураций.* Хранилища переезжали между серверами вручную, долго и с риском получить неполную копию. Сервис делает это сам и показывает ход работы: сколько уже скопировано, сколько осталось. Оригинал уезжает в архив, откат — одно нажатие. Перед стартом проверяется свободное место с запасом, операцию можно прервать на полпути с очисткой недокопированного, а зависший процесс снимает сторож.

Обе утилиты — на стороне заказчика, в его репозиториях, с описанием и разворачиванием одной командой.

**Документация.** Три десятка документов: инвентарь машин и сервисов, топология сети, разборы инцидентов и пошаговые инструкции на повторяющиеся операции — от снятия копии базы 1С до диагностики зависшего сеанса отладки.

## Что получил заказчик

- Инфраструктуру, которая мониторится целиком, включая Windows-часть и саму платформу 1С, а не только «пингуется ли сервер».
- Разбор инцидентов с указанием причины, а не только с восстановлением работы: после каждого остаётся документ, по которому вторая такая авария чинится за минуты.
- Понимание, когда и во что упрётся площадка, — с цифрами и планом закупки, а не по факту исчерпания ресурсов.
- Две рутинные операции, которые больше не занимают время инженеров и не требуют доступа к серверам.
- Почту, конференции и документы на собственной площадке — без ежемесячной подписки за каждого сотрудника и без зависимости от чужих правил хранения.