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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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