Доклады с конференций Инфостарта для специалистов 1С
INFOSTART EVENT — это конференции сообщества 1С, которые мы проводим с 2012 года. За это время они стали крупнейшей площадкой для обмена опытом между профессионалами отрасли.
На наших конференциях выступают настоящие практики из ведущих компаний России и СНГ, а не бизнес-тренеры. Доклады отбираются голосованием сообщества, а качество контента контролируют независимые эксперты. Каждая конференция охватывает интересы разных ролей:
для программистов — разработки и архитектурные решения, новые технологии и инструменты,
для аналитиков — методологии, работа с требованиями, анализ данных, управление изменениями,
для руководителей проектов и ИТ-менеджеров — управление командами, рисками, проектами и продуктами,
для специалистов по ИБ и администрированию — практики защиты, эксплуатации и поддержки систем,
для HR и тимлидов — развитие команд, soft skills и современные управленческие подходы.
За годы существования INFOSTART EVENT накопился большой объём уникального контента для всех специальностей из мира 1С. Практически по всем докладам мы готовим подробные транскрибации: они позволяют узнать суть докладов в удобное время и внедрить лучшие практики в своей работе.
Все материалы БЕСПЛАТНЫЕ в открытом доступе и помогают специалистам находить решения, обмениваться опытом и двигать отрасль 1С вперёд.
над каждым докладом работает минимум 6 человек.
За много лет существования Infostart Event у нас накопилось большое количество качественного и уникального контента, и мы рады представить вам эти материалы!
Как ускорить внедрение 1С, точнее оценивать сроки и трудозатраты и при этом не потерять управляемость большого проекта? Рассказываем, как команда экспериментирует с ИИ-ассистентами на базе RAG: один помогает аналитикам готовить постановки задач, а другой должен анализировать историю разработки и дополнять экспертные оценки по методу Делфи. Показываем, как OpenProject превратился в кастомный таск-трекер с интеграцией с «1С:СППР», а сервисы «Яндекса» объединили переписку, документы, встречи, транскрибацию и протоколы в единую систему взаимодействия. Разбираем, почему такие инструменты не дают готовой формулы успеха, но позволяют усиливать гибридный подход к управлению проектами и последовательно проверять гипотезы на практике.
Разбираем, почему классические бизнес-процессы в 1С плохо масштабируются при интеграции с внешними системами и как хореография событий помогает уйти от жесткой зависимости от центрального контроллера. Показываем, как Apache Kafka становится «нервной системой» бизнес-экосистемы: через топики, события и слабую связанность -1С может работать наравне с внешними сервисами, не превращаясь в «центр вселенной». Объясняем, как строится такая архитектура, какие есть способы интеграции 1С с Kafka и как Saga-паттерн помогает согласовывать долгие операции без блокировок и длительных распределенных транзакций. На практическом примере показываем, как событийный подход делает процессы гибче, упрощает масштабирование и открывает единый поток данных для BI-аналитики.
Разбираемся, как устроена нотация ArchiMate, которая помогает представить бизнес, приложения и технологическую инфраструктуру как единую взаимосвязанную систему. Прослеживаем историю ее появления, рассматриваем слои и аспекты, а также различия между Core Framework и Full Framework. На практическом примере разбираем основные элементы и связи между ними и показываем, как с их помощью проследить влияние сервера на приложение и бизнес-процессы. Объясняем, для каких задач подходит ArchiMate, а когда лучше выбрать другую нотацию.
За считанные месяцы цены на серверное железо выросли в разы, а бюджеты компаний – нет, поэтому ошибка при подборе оборудования для 1С теперь обходится особенно дорого. Разбираем, почему логика «возьмем самое дорогое и производительное» здесь не работает, какие особенности памяти, дисков и серверных конфигураций нужно учитывать и где действительно можно сэкономить – от свертки базы до использования десктопного компьютера. Показываем, как продавцы могут предлагать вместо подходящих компонентов более выгодные им аналоги или неликвид и почему советы нейросетей о частоте процессора, конфигурациях и тесте Гилева нельзя принимать на веру. Объясняем, какие ошибки приводят к потере производительности и на чем при подборе сервера для 1С экономить нельзя.
Почему переход на Scrum, который должен улучшить работу команды, иногда вызывает только раздражение, саботаж и ощущение бесконечных совещаний? Разбираем шесть проблем, скрывающихся за красивыми метриками трансформации: формальное внедрение новых процессов, бесполезные ретроспективы, смешение ролей тимлида и Скрам-Мастера, зависимость от авторитетного Гуру и героизм «Спасителя», неизбежно ведущий к выгоранию. Показываем, как проработать эти ситуации, сохранить самостоятельность и мотивацию сотрудников и сделать Scrum инструментом для команды, а не очередным ритуалом для галочки.
Бюджет согласован, инфобез доволен, акты готовы – а пользователи получили продукт, который только усложнил им жизнь: так бывает, когда их интересы теряются за проектными процедурами. На реальных кейсах разбираем вредные советы для проектных менеджеров: как не заметить ключевых пользователей, автоматизировать не тот процесс, потратить ресурсы на «рюшечки» и обнаружить последствия только при внедрении. Показываем, что двухсекундное «улучшение» способно потребовать еще одного оператора, а цифровая регистрация – оказаться медленнее бумажного листа и давать 20% неудачных попыток. Объясняем, как представители пользователей, прототипирование, «Путь героя» и наблюдение за реальной работой помогают отделить ключевые потребности от второстепенных и сохранить ценность продукта.
Рассказываем, как перейти от архитекторов-одиночек и решений, зависящих от конкретных специалистов, к системному управлению технической архитектурой 1С. Разбираем опыт центра компетенций IBS: регулярные архитектурные комитеты, контроль качества через ревью, матрицу компетенций, специализацию архитекторов, корпоративную базу знаний и внутренние хакатоны. Показываем, как эти инструменты помогают раньше выявлять архитектурные ошибки, снижать технический долг, повторно использовать наработки и повышать предсказуемость проектов. Объясняем, как такая модель превращает архитекторов из хрупкого ресурса в стратегический актив компании и что необходимо для создания собственного центра компетенций.
1С все чаще становится центром обмена данными между магазинами, сайтами, CRM-системами и другими сервисами, но хаотично созданные интеграции сложно поддерживать и безопасно развивать. Разбираем жизненный цикл интеграции на примере двух ролей 1С: клиента, который получает данные, и сервера, который предоставляет их внешним системам через API. Показываем, как избежать зацикливания обмена и зависимости от действий пользователей, зачем нужны версионирование API, защищенное соединение, ограничение запросов, логирование, документация и тестирование. Объясняем, как перейти от точечной «склейки» систем к управляемой интеграционной архитектуре, готовой к развитию и масштабированию.
В удаленной команде важно не только быстро отвечать на сообщения, но и сохранять возможность для сфокусированной работы. Разбираем, как снизить количество отвлечений, договориться о правилах коммуникации и сделать общение в команде понятнее для всех участников. Объясняем, как говорить о личных границах без конфликтов, зачем нужна «инструкция к себе» и как она помогает выстраивать доверительные рабочие отношения.
Представьте, что вас попросили «сделай нам DevOps для 1С». С чего начинать? Часто за этой потребностью скрывается хаос в самом процессе разработки. Поэтому начинать нужно не с инструментов, не с серверов и не со скриптов, а с понимания того, что именно необходимо изменить. Предлагаем небольшой спасительный чек-лист, по которому можно относительно безболезненно запустить современные процессы управления разработкой 1С, даже когда у команды нет ничего, а изменения они присылают друг другу почтой и в мессенджерах. Вы получите структурированный пошаговый список задач, с которым не страшно окунаться в любой проект аудита разработки на 1С с целью навести там порядок.
Большинство разработчиков делают ставку на логико-математический интеллект. Он дает прочную базу для работы с кодом, алгоритмами и метриками, но со временем может стать потолком профессионального роста. Разбираем, какие виды интеллекта особенно важны в IT и как вербальное, визуально-пространственное, межличностное и внутриличностное мышление влияют на скорость работы, качество решений и переход к ролям архитектора и тимлида. Объясняем, почему опыт не равен зрелости, как стресс, эмоции и физическое состояние отражаются на концентрации и количестве ошибок и почему проблема часто заключается не в человеке, а в несовпадении роли с его конфигурацией мышления. Показываем, как определить сильные и тормозящие рост виды интеллекта и развивать их с помощью простых практик, которые можно применять в работе уже на следующий день.
Корпоративный ИИ – это не просто подключение к API модели, а целая инфраструктура, которая должна решать вопросы безопасности, масштабирования, контроля качества и стоимости. Разберем, какие сервисы для этого нужны (ИИ-прокси, векторные хранилища, логи, метрики), как все это связано между собой и как используется в корпоративных приложениях, в том числе на базе 1С.
ИИ-агенты уже умеют заметно ускорять разработку, но для этого недостаточно просто сказать модели «напиши код». Ей нужны контекст, правила, инструменты и, самое главное, возможность проверить собственный результат. Расскажем, как превратить сырого ИИ-агента в изысканное блюдо, которое понимает специфику 1С и работает по вашим рецептам. Если вы все еще не умеете готовить ИИ-агентов, мы постараемся это исправить!
Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение.
Мы разработали ИИ-ассистента, который помогает управленцам разбирать сложные задачи и формировать их решения. В основу продукта мы заложили несколько формальных методик анализа: ТРИЗ и другие. Это позволило создать пошаговый процесс: формулирование проблемы, противоречий, поиск ресурсов, генерация и оценка вариантов решений. Расскажем весь путь создания продукта: идеи, архитектура, технологии, методологии и, конечно же, промпты. Обсудим набитые шишки и интересные инсайты при создании продукта.
Разбираем, почему формальное выполнение требований регуляторов и закупка средств защиты еще не делают информационную безопасность полезной для бизнеса – и зачем вместо этого нужны концепция, стратегия и архитектура ИБ. На примере противостояния с «Дракулой» показываем, как по мере роста киберугроз усложняется защита компании и почему попытка закрыть все возможные риски может привести к лишним расходам и расфокусу. Объясняем, как определить действительно актуальные угрозы, выбрать целевой уровень защищенности и расставить приоритеты с учетом ресурсов, рисков и задач бизнеса. А также разбираем, как связать стратегию ИБ с общей стратегией компании и превратить ее в конкретный план развития архитектуры на несколько лет вперед.
Разбираем, как привычный образ сильного руководителя – уверенного, непогрешимого и всегда готового дать ответ – может лишать команду инициативы и превращать людей в исполнителей. Показываем, какие управленческие маски скрывают слабое лидерство и почему рядом с «железным» начальником исчезают честная обратная связь и психологическая безопасность. Объясняем, чем уязвимость отличается от слабости и как признание «я не знаю» помогает включить коллективный интеллект и выстроить доверие. Статья будет особенно полезна руководителям, которые чувствуют, что в команде что-то не так, и готовы посмотреть на собственное поведение без самооправданий.
Почему компании объединяют управление продуктом и технологиями в одной роли – и когда такое решение действительно оправдано? Разбираем на практическом опыте команды 1С, какие преимущества дает роль CPTO, почему она ускоряет принятие решений и упрощает взаимодействие с бизнесом, но одновременно повышает когнитивную нагрузку и создает риск перекоса между продуктом и технологическим развитием. Показываем, почему для крупного бизнеса такое совмещение может оказаться лишь временным компромиссом, в каких условиях модель работает устойчиво и какие механизмы – от квот на техдолг до независимого архитектурного контроля – помогают сохранить баланс.
Рассказываем, как подразделение из 75 человек с выручкой около 25 млн рублей в месяц встроило GenAI в подготовку проектной документации, разработку и тестирование и превратило эксперименты с ИИ в измеримый бизнес-эффект. Разбираем результаты: экономию около 320 человеко-часов в месяц на работе с документацией, сокращение одной итерации тестирования, ускорение выхода на SLA и дополнительную непроектную выручку. Показываем, как внедрять и масштабировать инструменты с минимальным CAPEX через вовлечение и нематериальную мотивацию команды, а также преодолевать сопротивление изменениям. Объясняем, почему не стоит усложнять промпт-инжиниринг, и делимся готовыми шаблонами промптов, системой метрик и принципами безопасной работы с данными в открытых нейросетях.
Разбираем, почему проекты внедрения ESB, MDM и BI нельзя вести по тем же правилам, что и ERP: их промежуточный результат часто остается невидимым, зависимости проявляются слишком поздно, а привычные burn-down charts показывают активность команды, но не реальную готовность системы. На практических кейсах показываем, как отсутствие ключевого архитектора, скрытая связанность систем и одна ошибка в формате данных могут запустить каскад проблем и привести к серьезному перерасходу времени и бюджета. Объясняем, почему для технологических проектов нужен фазовый подход – от проверки концепции на реальных данных до MVP и полноценного запуска – с совместными контрольными точками и метриками по фактическому результату. Отдельно отмечаем, где ИИ-инструменты действительно помогают развивать аналитику и инновационные сценарии, а где не способны компенсировать ошибки архитектуры и низкое качество данных.
Пентест – это не только поиск уязвимостей, но и сложный проект, в котором ошибка может привести к простою, инциденту и потере доверия заказчика. Рассказываем, как правильно определить цели и границы работ, распределить ответственность, выстроить коммуникации и сделать неизбежные риски и изменения контролируемыми. На реальных кейсах разбираем, почему задержка с сообщением о критической уязвимости способна перечеркнуть технический успех, как управленческая рамка помогла разобраться в остановке турбины и когда выход за пределы скоупа приносит пользу бизнесу, а когда становится нарушением договоренностей.
Разбираем, почему привычная модель найма перестает работать и как компаниям выстраивать развитие специалистов в условиях дефицита кадров и новых ожиданий сотрудников. Показываем, как связка HR и тимлида помогает превращать новичков без проектного опыта в самостоятельных специалистов без перегрузок и потери качества. Объясняем, как сетка грейдов, ABC-классификация задач, индивидуальные планы развития и регулярная обратная связь делают рост прозрачным, помогают вовремя выявлять зоны развития и повышают мотивацию. Материал будет полезен тимлидам, HR-специалистам и руководителям IT-направлений, которые хотят сократить текучесть, сформировать кадровый резерв и не допустить кадрового голода в ближайшие годы.
Рассказываем, как превратить обучение аналитиков в полноценный проект и за полгода вырастить из джунов самостоятельных специалистов, готовых включаться в работу на разных этапах внедрения. Показываем, как практика, командные задания, жесткий темп, сквозной сюжет и реальные ситуации с заказчиками помогают быстрее развивать навыки и учиться на собственных ошибках. Разбираем, зачем будущим мидлам нужны не только знания 1С, но и умение проводить интервью, ставить задачи, тестировать, взаимодействовать с командой и справляться со стрессом. Объясняем, как оценивать прогресс с помощью матрицы из 40 компетенций, собирать регулярную обратную связь и выстраивать обучение, которое приносит пользу реальным проектам.
Разбираем, как манипуляции маскируются под взаимопомощь, командность и заботу – и почему даже в сплоченной команде они постепенно забирают время, энергию и доверие. На реальных кейсах из IT показываем, как распознавать лингвистические и психологические крючки, отделять эмоциональное давление от рабочего запроса и отвечать так, чтобы не разрушать отношения с коллегами. Объясняем, почему одной личной защиты недостаточно и как прозрачная нагрузка, четкие протоколы и регулярные ретроспективы помогают выстроить культуру, где помощь остается осознанной, а отказ не превращается в обвинение в некомандности.
В условиях удаленной работы, растущей нагрузки и хронической усталости трудные разговоры становятся одним из главных инструментов руководителя – особенно когда речь идет о сроках, качестве работы, повышении или поведении сильного, но конфликтного специалиста. Разбираем пять типичных ситуаций и показываем, как перевести разговор от оценок и взаимной защиты к фактам, последствиям и совместному поиску решения. Объясняем, как работают рамки ожиданий, «техника цифр», модель «факт – эффект – значение», метод «по одну сторону стола» и «Контракт» с конкретными договоренностями. Рассказываем, как сохранить доверие, избежать демотивации и превратить сложный разговор в точку роста для сотрудника и команды.
Разбираем, как в крупных компаниях регуляторные требования, постмортемы и внутренние ограничения постепенно превращаются в многоуровневую систему инструкций, в которой разработчику все сложнее понять, что и когда нужно проверить. Показываем opensource-сервис внешних проверок для GitLab, который автоматизирует часть этой бюрократии и сводит результат к понятному сигналу: зеленое – все в порядке, красное – нужно обратить внимание на конкретное требование. Объясняем, как такие проверки помогают «сдвинуть влево» контроль задач и снизить риск отказа во внедрении задачи в последний момент перед релизом. А заодно смотрим, может ли связка Autumn + «Вино» + немного разработческого энтузиазма превратить обязательные инструкции в инструмент, который команда сама захочет развивать.
Delivery – это не доставка еды, а доставка ценности в продакшн: разбираем, как выстроить процесс поставки на примере команды, работающей с 1С:ЗУП. Показываем, как за пару лет удалось почти вдвое сократить срок поставки решений, увеличить количество релизов с пяти до двенадцати в месяц и уменьшить периоды бизнес-фризов – за счет процессов, автоматизации и фокуса, а не переработок. Объясняем, как Lead Time, предсказуемость и другие метрики помогают находить узкие места и оценивать эффективность команды. Делимся практическими кейсами, сложностями и результатами – без лишней теории, только опыт.
Почему процессы, которые отлично работали в одной небольшой команде, перестают справляться с ростом, а увеличение штата не ускоряет поставку, а лишь усложняет коммуникацию и размывает ответственность? Рассказываем, как перейти от одной функциональной команды к системе автономных доменов, распределить архитектурную экспертизу и избежать ситуации, когда архитектор или платформенная команда становятся «бутылочным горлышком». Разбираем принципы Team Topologies с учетом специфики 1С, рабочие способы межкомандной синхронизации и трансформацию ролей руководителей, тимлидов и архитекторов. Показываем, как выстроить устойчивую ИТ-экосистему, в которой автономия не превращается в анархию, а координация – в бюрократию.
5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.
Разбираем новые, более дешевые и эффективные паттерны работы внешнего 1С:Эксперта, а именно – прямое использование LLM-ассистентов и создание с их помощью инструментов для аудита производительности и нагрузочного тестирования. Показываем, как модели помогают анализировать таймауты и взаимные блокировки по технологическому журналу, проверять сложные запросы, а также находить неочевидные взаимосвязи между показателями загрузки оборудования. Рассказываем о создании скриптов для построения графиков по данным atopsar и для поиска и визуализации стеков горячих запросов, а также о создании неинвазивной оснастки для реалистичных нагрузочных и сценарных тестов без программирования на 1С. Отдельно разбираем антипаттерны и ограничения такого подхода. Делаем вывод, что LLM остается лишь помощником, не превращает джуна в сеньора, а ответственность за итоговый результат по-прежнему несет 1С:Эксперт.
Рассказываем, чем оценка руководителя ИТ-проекта отличается от оценки других участников команды и почему для РП важны не только профессиональные знания, но и системное мышление, переговоры, управление рисками и ожиданиями. Разбираем, как выстроить сбалансированную систему мотивации, которая учитывает продуктовые метрики, сроки, качество, удовлетворенность клиента и рентабельность проекта. Объясняем, когда уместны оценка 360 градусов и обратная связь от заказчика, а также всегда ли ошибки команды находятся в зоне ответственности руководителя. Также продемонстрируем, какие косвенные показатели – от текучести и переработок до повторных контрактов и характера эскалаций – помогают оценить реальную эффективность РП.
Разбираем разницу между проектным и продуктовым подходами в управлении и причины того, почему они редко существуют в компаниях в чистом виде. Объясняем, когда достаточно процессного подхода, когда нужен проектный, а когда без продуктового управления уже не обойтись. Показываем ключевые критерии каждого подхода: жизненный цикл, роль команды, метрики успеха, организационную структуру и фокус управления. Отдельно разбираем риски неправильного выбора подхода – от лишних затрат до конфликтов ролей между руководителем проекта, владельцем продукта и менеджером по продукту.
AI-разработка становится повседневной практикой, но правовое регулирование только формируется, и цена ошибок уже измеряется штрафами, исками и репутационными потерями, которые могут превысить бюджет проекта. Рассказываем, как встроить правовой комплаенс в жизненный цикл AI-системы, не превратив разработку в бесконечное согласование, и как выбрать подходящую модель проверки с учетом уровня риска. Разбираем российскую судебную практику, распределение ответственности между разработчиком, заказчиком, пользователем и владельцем системы, а также показываем практические инструменты: карту рисков, контрольные точки, чек-листы и договорные механизмы защиты.
Рассказываем, как использовать библиотеку искусственного интеллекта для 1С не просто как инструмент генерации кода, а как основу для новых бизнес-решений. Показываем, как с ее помощью строить BI-систему на естественном языке: пользователь формулирует вопрос по продажам обычным текстом, а система генерирует запрос к базе и возвращает результат в виде таблицы или графики. Разбираем пример торгового бота-продавца, который общается с покупателем, консультирует по товару и отправляет платежную ссылку, а также объясняем, зачем в таких решениях нужны границы, точки контроля и обычное программирование. Отдельно показываем, как векторные базы и нечеткий поиск помогают создавать помощников менеджера (например, для подбора аналогов), и почему новые задачи лучше решать новыми методами, а не пытаться применять ИИ только к старым сценариям.
Рассказываем, как в условиях кадрового дефицита отдел 1С-разработки отказался от ставки на поиск готовых специалистов и выстроил автономную систему выращивания программистов – от вакансии и отбора до адаптации, обучения и работы на реальных проектах. Эксперименты с вакансиями, проверкой способности учиться и собственными форматами развития помогли обеспечить стабильный поток подходящих кандидатов и постепенно расширять компетенции команды.
Разбираем ISO/IEC 42001:2023 – самостоятельный стандарт по системам менеджмента искусственного интеллекта, построенный на логике ISO/IEC 27001 и расширяющий привычные подходы информационной безопасности на разработку, поставку и использование ИИ-систем. Показываем, как типовая модель оценки рисков дополняется анализом воздействия на бизнес и общество, а приложение А объединяет меры управления рисками в десять групп контролей. Объясняем, чем отличаются требования к разработчикам, поставщикам и пользователям систем искусственного интеллекта и какие риски каждая из сторон должна учитывать на своих этапах жизненного цикла. Материал будет полезен специалистам по информационной безопасности и разработчикам информационных систем, интегрированных с ИИ.
Разбираем, как быстро понять, чем занят SQL Server, кто создает блокировки и почему запросы 1С внезапно начинают тормозить. Показываем, какие настройки сервера и базы данных стоит проверять, как анализировать ожидания, планы запросов, статистику и индексы, а также переводить сырые данные SQL на понятный 1С-нику язык. Объясняем, как наладить предметный разговор с DBA и перейти от диагностики к конкретным рекомендациям. В статье также представлена бесплатная обработка для 1С, которая автоматизирует основную часть анализа для MS SQL Server и PostgreSQL и формирует готовые к применению SQL-скрипты.
Разбираем, что на практике скрывается за нормализацией НСИ и почему она нужна не только для наведения порядка в справочниках. Показываем, как единые и качественные данные помогают сокращать издержки, принимать управленческие решения и выстраивать бизнес-процессы компании. Объясняем, почему нормализация становится важным условием успешной автоматизации, и как она связана с качеством данных. Также рассматриваем основные инструменты работы с НСИ: методологию, классификацию, шаблоны описания, поиск дублей и подготовку данных к миграции.
Главная иллюзия ИТ-управления – вера в то, что правильные процессы, модные технологии и подробные регламенты сами приведут к результату. Показываем, как эта иллюзия разбивается о реальность. Результат создают мотивированные и компетентные люди, которым процессы помогают работать, а технологии решают конкретные бизнес-задачи, а не просто выглядят современно. Объясняем, почему ИТ-руководитель – это прежде всего лидер, который синхронизирует людей, процессы и инструменты в условиях ограниченных ресурсов, давления бизнеса и постоянных изменений. В статье разбираем типичные ловушки найма, мотивации, контроля, Agile, сервисности, планирования, внедрения ИИ, работы с вендорами и техническим долгом – и показываем, как сохранять романтику управления без розовых очков.
Разбираем, как подготовить Шину 1С к промышленной эксплуатации и обеспечить непрерывность интеграционных процессов при сбоях, обновлениях и недоступности отдельных узлов. Показываем варианты отказоустойчивой архитектуры – от подтверждения обработки сообщений до активно-пассивной и активно-активной схем с двумя экземплярами шины. Рассказываем, как контролировать инфраструктуру и потоки сообщений с помощью штатных и пользовательских метрик, а также как защитить продуктовую шину от случайного подключения копий баз с теми же учетными данными.
