Большой опрос сообщества 1С

Ландшафт технологий 1С - карта инструментов, которыми пользуется сообщество

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

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

Бот спросит вашу роль и подберет подходящие инструменты. По каждому нужно ответить на два коротких вопроса. Опрос займет от 15 минут, но его можно поставить на паузу и продолжить позже

Пройти опрос
@stateOf1c_bot

Результаты появятся на отдельной странице и прямо в карточках инструментов. Там же уже можно посмотреть итоги предварительного этапа

Если вы работаете с 1С - проходите и отправляйте коллегам

Чем больше будет ответов от разработчиков, аналитиков, тестировщиков и администраторов, тем точнее получится Ландшафт 1С

Буду благодарен за репосты и упоминания - они помогут собрать ответы от самых разных участников сообщества

Как 1С на самом деле работает с временными таблицами в PostgreSQL — и почему безобидный FASTTRUNCATE может съедать заметную долю CPU.

Разбор внутренней механики, переиспользования временных таблиц и реального кейса оптимизации PostgreSQL под 1С.

https://habr.com/ru/companies/tantor/articles/1078088/

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

К счастью, теперь такую проверку можно провести структурно. K2 Cloud и АСТОН подготовили калькулятор технической поддержки 1С. Ответьте на 10 вопросов о ваших сервисах, процессах и требованиях к доступности.

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

https://youtu.be/2MCcLSZP5Y4?si=lLvijUHKopVdbD4o

Говорим о зарплатах Junior, Middle и Senior 1С, переходе из бухгалтерии в разработку, сертификатах 1С, высшем образовании и софт-скиллах. Разбираем автоотклики на hh.ru, сопроводительные письма, технические собеседования, использование ИИ и работу в нескольких компаниях. Отдельно спорим о накрутке опыта: где проходит граница между реальными знаниями и годами в резюме.

Смотри, если ищешь первую работу в 1С, готовишься к смене компании или хочешь понять, что мешает росту дохода. Зарплатные цифры и оценки рынка в беседе — опыт и мнения участников, а не гарантированные условия трудоустройства.

Как не отправлять ПДн во внешнюю LLM

Практический кейс маскирования персональных данных в пользовательском тексте.

Схема:

regex + справочники → локальная LLM → токенизация → внешняя LLM

Телефоны, email, паспорта и известных людей ловят детерминированно. Склонения, прозвища и живую речь — локальной моделью.

Архитектурный паттерн: deterministic preprocessing → local intelligence → external LLM.

Подходит для любого AI-gateway, где чувствительные данные нельзя отправлять наружу.

Сжатие PostgreSQL: меньше данных ≠ выше производительность

Обычно эффективность сжатия оценивают по размеру базы. Но экономия диска не гарантирует ускорения запросов.

Авторы статьи исследовали компрессию страниц в Tantor Postgres на базах 1С.

Что выяснили:

• ZSTD лучше сжимает, но требует больше CPU.
• LZ4 обеспечивает лучший баланс скорости и сжатия.
• На большой таблице объём сократился с 95 до 12 ГБ. LZ4 ускорил холодное чтение почти втрое.
• На небольших таблицах распаковка может стоить дороже сэкономленного I/O.
• Сжатие страниц переменного размера усложняет запись и может приводить к фрагментации.

Архитектурный вывод

Оптимизировать нужно не коэффициент сжатия, а стоимость работы с данными: CPU, I/O, write/read amplification.

Максимальное сжатие ≠ максимальная производительность.

Отдельно интересно решение CSM в Tantor Postgres: сохранять фиксированную адресацию страниц, уменьшая их физический размер. Это компромисс между экономией диска и стоимостью операций чтения и записи.

Читать исследование →

Отчёт в 1С завис? Возможно, дело вообще не в запросах.

Отличная статья с практическими кейсами диагностики 1С. Вместо гадания и перебора гипотез — конкретные инструменты и реальные причины проблем.

Что внутри:

948 → 66 секунд. Через rac и технологический журнал нашли SQL-запрос на 240 секунд и конкретную строку кода. Переписали проблемный отчёт.

365 секунд в одной временной таблице. Из 15 шагов пакета 14 выполнялись суммарно за 0,76 секунды. Замер каждого шага помог найти узкое место.

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

Зомби-вызовы. Пользователь закрыл отчёт, но SQL продолжил выполняться на сервере. Повторный запуск только увеличил нагрузку.

Зависшее фоновое задание. Открытая транзакция удерживалась более двух суток и мешала обновлению конфигурации.

Задание «выполнено», но данные не обновляются. Неправильное расписание, ошибка формирования SQL и перехваченное исключение скрывали проблему.

Готовая методика расследования: как с помощью rac, DBMSSQL, SDBL и журнала регистрации быстро сузить круг причин, не тратя часы на изучение непричастного кода.

Хороший материал, который стоит сохранить как шпаргалку для разбора инцидентов в 1С.