1С *

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

Напомню и про два профиля настроек для СУБД из первой части: первый — тяжёлая ERP с одной большой базой, второй — стопка из сотни бухгалтерских баз на одном инстансе. Настройки, о которых пойдёт речь ниже, зависят от профиля использования так же, как зависела схема размещения данных из предыдущей части. К концу статьи станет видно, из чего складывается ответ на вопрос «почему тормозит», и что железо в этом ответе часто ни при чём.

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

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

Проверить, подходит ли вам эта профессия, можно бесплатно с помощью вводной части курса «1С-аналитик» в Яндекс Практикуме. В статье разберём, что находится внутри: из каких уроков она состоит, что рассказывает о профессии — и почему эту часть курса стоит пройти, даже если вы пока просто присматриваетесь к 1С.

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

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

Код внешней обработки, границы ее применения, а также описание необходимых настроек 1С:ERP и составляют содержание этой статьи.

Много лет я занимался бизнес‑анализом и внедрением продуктов 1С. Зная хорошо специфику работы я сделал расширение конфигурации 1С для рисования бизнес процессов сразу внутри 1С.

У бизнес‑аналитика редко бывает проблема «нет схемы процесса». Чаще она уже есть: создана на этапе обследования, получена от внешнего консультанта или поддерживается в привычном редакторе.

Проблема возникает в другой момент: когда хочется использовать схему сразу внутри 1С для автоматизации и регламентации.

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

В новом релизе расширения «Схемопоинт. Процессы BPMN внутри 1С» я добавил импорт файлов .bpmn. Цель функции — не заменить все внешние редакторы, а убрать барьер первого использования: взять знакомую схему, загрузить её в 1С, проверить результат и продолжить работу уже внутри системы.

Эта статья — история о том, как небольшая команда перевела медицинскую информационную систему с устаревшей платформы 1С 7.7 на 1С 8.3 и выстроила вокруг неё современные практики разработки: контроль версий, код-ревью, автотесты, CI/CD. Дальше — сама история.

В начале двухтысячных классные специалисты разработали систему для клиники на базе 1С 7.7. Функционал включал как административно-хозяйственную часть, так и работу с пациентами. Программный продукт проработал почти два десятилетия, код отладили и протестировали самой жизнью, а идея, что новый код может оказаться лучше старого, казалась совершенно абсурдной. Система при этом технологически устарела: ручное формирование XML отнимало значительное количество времени у программиста, а запросы к БД и обработка данных таблиц для отчётов могли занимать десятки минут. Казалось бы, простые интеграции как XML и REST реализовывали через костыли. Экстренную правку кода приходилось вносить с отключением всех пользователей программы на несколько минут — динамическое обновление для семёрки попросту не разрабатывали.

В 2020 году руководство клиники приняло решение о миграции на новый технологический стек и через год привлекли разработчиков. Всерьёз рассматривался только вариант 1С 8.3: на момент принятия решения других вариантов, сопоставимых по зрелости экосистемы и доступности специалистов на рынке, просто не существовало. Речь шла не о внедрении готового отраслевого решения, а о разработке под одного конкретного заказчика — максимально повторяющей то, к чему сотрудники клиники привыкли за два десятилетия. Устоявшиеся процессы, интерфейсы документов и порядок работы заказчик менять не планировал.

Для этой статьи я поговорила со Стеллой Бояршиновой — автором и методологом решения для управления проектами «Корадиум». Мне хотелось разобраться не столько в возможностях самого продукта, сколько в истории его развития: как внутренняя система небольшой проектной компании превратилась в тиражное решение, какие ошибки команда совершила на первых внедрениях и что за 12 лет пришлось пересмотреть в подходе к корпоративной разработке.

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

Не сработало.

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

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

Спустя год этот же клиент называл систему «артерией» своей работы. И, пожалуй, именно этот кейс лучше всего объясняет, во что в итоге превратился «Корадиум»: продукт, который позволяет начинать с базовых сценариев и постепенно наращивать глубину автоматизации.

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

Затем появились Git, EDT, автотесты и инструменты автоматизации. Сегодня в этот цикл все активнее входят AI-агенты, MCP и программное управление платформой.

Меняется не только набор инструментов, но и стоимость разработки. То, что раньше требовало десятков минут ручной работы, постепенно превращается в одну команду, скрипт или действие агента.

Подборка материалов ниже — о разных сторонах этого перехода. Вместе они показывают одну тенденцию: современный 1С-разработчик все меньше работает только с Конфигуратором и все больше — с полноценной инженерной экосистемой вокруг платформы.

Интеграция 1С с сайтом, мобильным приложением, CRM, WMS или корпоративной платформой редко ломается на первом запросе. Отправить JSON в HTTP-сервис и получить ответ умеет почти любая команда. Настоящие проблемы начинаются позже: внешняя система узнаёт внутреннюю структуру справочников 1С, повторный запрос создаёт второй заказ, зависшая база останавливает всю цепочку, а источник ошибки приходится искать по журналам трёх систем.

 Поэтому вопрос сегодня звучит не так: «Можно ли подключить 1С к современному стеку?» Можно. Платформа поддерживает HTTP- и web-сервисы, обращения к внешним HTTP-ресурсам, JSON, XML, OData и другие способы обмена. Вопрос в другом: как построить интеграцию так, чтобы обновление конфигурации, рост нагрузки или временная недоступность одного сервиса не превращались в аварию.

 Задача не потеряла актуальности с появлением ветки 1С:Предприятие 8.5. Финальная версия 8.5.1 вышла в конце декабря 2025 года. Следующей версией фирма «1С» объявила сразу 8.5.4 — в неё вошли задачи, ранее запланированные на 8.5.2 и 8.5.3, часть задач перенесена в 8.5.5. План 8.5.4 обновлялся в течение 2026 года, но дата выхода на момент подготовки материала не объявлена. Одновременно развивается 1С:Шина: в анонсе версии 9.0 заявлены доступ к телу сообщения как к строке (что удобно для XML и JSON), новый тип узла «Разделитель» и дополнительные способы аутентификации при подключении к Kafka. Новые версии расширяют инструментарий, но не отменяют главного архитектурного требования: между учётной системой и внешним миром должен существовать устойчивый контракт.

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

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

В тот вечер мы даже не задумывались, что запущен самый сложный, дорогой и одновременно очень нужный проект в нашей команде.

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

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

Вопрос, который витает немым подтекстом, звучит просто. С чем именно он не справляется?

Вариантов проблем четыре, и справляться с ними надо по‑разному. Блокировки, неоптимальный код, дисковая подсистема, нехватка памяти или процессорных ядер. Новое железо помогает в последних двух случаях, да и то не всегда. Блокировки и медленный код переезжают на новый сервер в полном составе, и через следующие полгода история повторяется, уже с потраченным бюджетом.

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

Возьмите Oracle Exadata. Никому не придёт в голову привезти стойку, включить питание и пройти установку кнопкой «Далее». Конфигурацию считают под профиль нагрузки. Схему размещения данных согласовывают заранее. Приёмку и ввод в эксплуатацию закладывают отдельным этапом работ, с отдельными сроками и бюджетом, и зовут людей, которые это уже проходили. Никто при этом не спрашивает, к чему такие сложности, всем понятно, какого класса машина приехала.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Уже 2 года я делаю подробные обзоры на продукты класса ESB. Появилась идея детально разобрать решения, которые предлагают те или иные платформы, для интеграции с 1С. В этом материале про возможности «Интегры».

Введение: Почему я решил «сидеть на попе ровно» и что из этого вышло

Зачем аналитику и архитектору AI-агент, а не просто чат в браузере  

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

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

Мы посмотрели на несколько решений, появившихся в августе, и выбрали пять разных сценариев автоматизации: от подготовки данных для нейросети до подписания кадровых документов через «Госключ».

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

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

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

Хотя, погодите... Именно так многие машины теперь и собирают. Второй завод берет за сборку свои деньги, клеит свой шильдик и продает дороже заводского. Машина та же, дорога длиннее, платит за нее покупатель. Но рационально ли это?

Cursor закрыл доступ из России. Альтернативы для разработки с ИИ в 1С, которые работают в РФ и оплачиваются рублями. Формат, цены, плюсы и минусы каждой.

pg_anon — полностью открытый инструмент для PostgreSQL, который ищет персональные данные по заданным правилам и выгружает копию базы уже замаскированной. За год проект заметно вырос: частичный дамп и восстановление, поддержка сложных схем, REST API, новый CLI. В статье разбираем все режимы на реалистичной демо-базе.

Что делать, если WAL удалён, сервер убит kill -9, база после pg_resetwal не хочет открываться, а бизнес стоит уже сутки? Это не гипотетический вопрос, а реальный кейс с кластером PostgreSQL для 1С на 2,5 терабайта данных. Расскажем историю о том, как без бэкапов, без WAL-архивов и почти без надежды вытащили критичные данные 1С-инфобазы. А в конце — неожиданный поход в апстрим PostgreSQL с патчем для pg_dump.

В мой телеграм‑канал про 152-ФЗ регулярно приходит один и тот же вопрос, только с двух противоположных сторон. Бухгалтер на аутсорсе спрашивает: «я веду учёт для десяти компаний, чем мне это грозит?» А через неделю пишет владелец фирмы: «мы отдали бухгалтерию на сторону, нам вообще что‑то нужно оформлять?» Оба чувствуют, что с персональными данными что‑то не так, но никто не понимает, что именно. И вот вопрос, который я задаю в ответ обоим: а вы вообще знаете, кем приходитесь друг другу по закону?

Предлагаю разобраться с этим. Для этого постараюсь встать на ту сторону, где риск больше, — сторону заказчика.

Продолжаем исследовать настройки памяти в Postgres и сегодня поговорим о связке настроек в ОС и СУБД. Речь пойдет о связке hugepages (Linux) и shared_buffers (Postgres).

Триггером для исследования послужила реальная жизненная ситуация у нашего клиента на поддержке производительности его ИТ-системы. Однажды утром…поступило обращение, что Postgres перестал запускаться вроде бы без видимых на то предпосылок: «мамой клянусь, ничего не делали с базой».

Как организовать регулярную выгрузку данных из 1С, если ручной экспорт уже не справляется с объемом и частотой обновлений? В статье сравниваются два подхода: прямой доступ к базе через SQL и использование готового ETL-инструмента. Разбираем скорость, сложность настройки, требования к специалистам, риски для безопасности и сопровождения системы. Также показываем, в каких случаях оправдан SQL, а когда удобнее использовать готовый инструмент для автоматической выгрузки данных по расписанию без постоянного участия разработчика.