Александр Крынецкий. Кейсы решения задач на СКД

Путь в Open Source не обязательно начинается с GitHub и умения писать идеальный код. На личном опыте разбираем, как рабочая задача, найденный баг, статья или просто высказанная идея могут запустить «принцип домино» и привести к появлению полезного Open Source-решения. Показываем, как отсутствие готовых инструментов со стороны вендора подталкивает сообщество создавать собственные проекты и как эти наработки продолжают развиваться уже без участия первоначального автора. Объясняем, какую неочевидную пользу приносит даже небольшой вклад – от публикации статьи до обратной связи и распространения ссылки. Доклад в виде статьи: https://infostart.ru/public/2797176/

Баги, недостающие улучшения и специфические потребности инфраструктуры не всегда находят отражение в новых версиях 1C:EDT – и тогда проблему можно решить с помощью собственного плагина. Рассказываем, как подготовить Eclipse, разобраться в архитектуре EDT, исследовать типовой функционал, подключать публичные сервисы и создавать пользовательский интерфейс. Разбираем отладку и сборку плагина, а также типичные сложности, из-за которых новички часто останавливаются на первых шагах. Все этапы показываем на примерах из практики создания плагина для работы с хранилищем 1С. Доклад в виде статьи: https://infostart.ru/1c/articles/2792554/

Рассказываем, как в Т-Банке встроили мониторинг в процесс разработки на 1С и почему новые функции теперь сопровождаются не только тестами, но и метриками. Разбираем, как разделение конфигураций на бизнес-услуги и формирование SLA помогают контролировать критичные операции – от начисления зарплаты до закрытия месяца и обмена данными между системами. Показываем, почему стандартной оценки производительности 1С оказалось недостаточно и как Sage Observability позволяет в реальном времени собирать логи и метрики, заранее выявлять риск нарушения SLA и находить причины инцидентов. На практических примерах объясняем, как такой подход снижает количество авралов, повышает устойчивость систем и делает их работу более прозрачной и предсказуемой. Доклад в виде статьи: https://infostart.ru/1c/articles/2789518/

Разбираем, почему классические бизнес-процессы в 1С плохо масштабируются при интеграции с внешними системами и как хореография событий помогает уйти от жесткой зависимости от центрального контроллера. Показываем, как Apache Kafka становится «нервной системой» бизнес-экосистемы: через топики, события и слабую связанность -1С может работать наравне с внешними сервисами, не превращаясь в «центр вселенной». Объясняем, как строится такая архитектура, какие есть способы интеграции 1С с Kafka и как Saga-паттерн помогает согласовывать долгие операции без блокировок и длительных распределенных транзакций. На практическом примере показываем, как событийный подход делает процессы гибче, упрощает масштабирование и открывает единый поток данных для BI-аналитики. Доклад в виде статьи: https://infostart.ru/1c/articles/2786953/

Представьте, что вас попросили «сделай нам DevOps для 1С». С чего начинать? Часто за этой потребностью скрывается хаос в самом процессе разработки. Поэтому начинать нужно не с инструментов, не с серверов и не со скриптов, а с понимания того, что именно необходимо изменить. Предлагаем небольшой спасительный чек-лист, по которому можно относительно безболезненно запустить современные процессы управления разработкой 1С, даже когда у команды нет ничего, а изменения они присылают друг другу почтой и в мессенджерах. Вы получите структурированный пошаговый список задач, с которым не страшно окунаться в любой проект аудита разработки на 1С с целью навести там порядок. Доклад в виде статьи: https://infostart.ru/1c/articles/2777198/

Корпоративный ИИ – это не просто подключение к API модели, а целая инфраструктура, которая должна решать вопросы безопасности, масштабирования, контроля качества и стоимости. Разберем, какие сервисы для этого нужны (ИИ-прокси, векторные хранилища, логи, метрики), как все это связано между собой и как используется в корпоративных приложениях, в том числе на базе 1С. Доклад в виде статьи: https://infostart.ru/1c/articles/2775385/

ИИ-агенты уже умеют заметно ускорять разработку, но для этого недостаточно просто сказать модели «напиши код». Ей нужны контекст, правила, инструменты и, самое главное, возможность проверить собственный результат. Расскажем, как превратить сырого ИИ-агента в изысканное блюдо, которое понимает специфику 1С и работает по вашим рецептам. Если вы все еще не умеете готовить ИИ-агентов, мы постараемся это исправить! Доклад в виде статьи: https://infostart.ru/1c/articles/2773406/

Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение. Доклад в виде статьи: https://infostart.ru/1c/articles/2772307/

Пентест – это не только поиск уязвимостей, но и сложный проект, в котором ошибка может привести к простою, инциденту и потере доверия заказчика. Рассказываем, как правильно определить цели и границы работ, распределить ответственность, выстроить коммуникации и сделать неизбежные риски и изменения контролируемыми. На реальных кейсах разбираем, почему задержка с сообщением о критической уязвимости способна перечеркнуть технический успех, как управленческая рамка помогла разобраться в остановке турбины и когда выход за пределы скоупа приносит пользу бизнесу, а когда становится нарушением договоренностей. Доклад в виде статьи: https://infostart.ru/1c/articles/2765139/

Разбираем, как в крупных компаниях регуляторные требования, постмортемы и внутренние ограничения постепенно превращаются в многоуровневую систему инструкций, в которой разработчику все сложнее понять, что и когда нужно проверить. Показываем opensource-сервис внешних проверок для GitLab, который автоматизирует часть этой бюрократии и сводит результат к понятному сигналу: зеленое – все в порядке, красное – нужно обратить внимание на конкретное требование. Объясняем, как такие проверки помогают «сдвинуть влево» контроль задач и снизить риск отказа во внедрении задачи в последний момент перед релизом. А заодно смотрим, может ли связка Autumn + «Вино» + немного разработческого энтузиазма превратить обязательные инструкции в инструмент, который команда сама захочет развивать. Доклад в виде статьи: https://infostart.ru/1c/articles/2762014/