Меня зовут Семён Ремезов, я Senior QA в компании «Гринатом» (мы пишем софт для «Росатома»).

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

Можно, конечно, наклепать синтетических моков, но в сложных системах это мало что даст. У нас в «Гринатоме» крутятся огромные системы. Это не просто «магазин с корзиной». Это продукты с чудовищным уровнем вложенности, тоннами информации и зависимостями, которые переплетаются между собой, как корни столетнего дуба. Данные пересекаются везде и всюду.

Синтетика — это стерильная лаборатория. Моковые данные — это то, как разработчик представляет себе данные. А их реальный массив — это то, как пользователи на самом деле кошмарят систему.

Мы внедрили у себя security-лейблы в Postgres Pro Enterprise для анонимизации, и этот путь был, мягко говоря, тернистым. Если вы думаете, что анонимизация — это просто скрипт UPDATE users SET name = 'Ivan', то у меня для вас плохие новости.

Давайте разберём, как мы построили процесс, почему отказались от дорогих «коробочных» решений и как заставили Postgres 15-й версии работать нормально.

Раньше наш способ собрать данные из всех микросервисов в одно место (в витрину) напоминал копролит (только не древний, а наш собственный ИТ-артефакт). Он был сложный, медленный, постоянно ломался и требовал много ручной работы. Данные размазывались по куче баз данных. Чтобы сделать отчёт или отправить данные во внешнюю систему, надо было собирать их вместе. 

Высока вероятность, что у вас такой же или похожий. Если нет — приходите рассказать «а я же говорил» в комментариях.

Мы тратили время на латание дыр, а не на разработку. В какой-то момент решили, что пора выкинуть этот велосипед и внедрить нормальный, промышленный подход к работе с данными — Data Lakehouse с медальонной архитектурой.

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

Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо.

• Платформа 1С 8.3.24.

• СУБД Postgres Pro.

• Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков).

• В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

Ежегодно 350 тысяч сотрудников Росатома создают примерно 1 200 000 обращений в поддержку. Значительная часть приходилось на систему для ведения бухгалтерского, налогового, регламентированного учета «1С: ERP 2.0 Цифровой Росатом». После внедрения ИИ-продукта «Атом.Зая» это количество сократилось на 24%. В этом тексте хочу рассказать, как мы двигались, чего удалось добиться, и какие уроки извлекли.

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

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

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

Создатель и владелец системы — ФГУП «ФЭО» (структура «Росатома»), он же стал единым федеральным оператором обращения с такими отходами. Его задача — управлять процессом. А мы должны были создать и запустить техподдержку.

Задачу мы выполнили.

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

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

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

А кому-то, может быть, даже смогут помочь.

Что общего у атомной станции, ледокола и промышленной IoT‑системы? Все они — часть критической информационной инфраструктуры (КИИ), где сбой может обернуться серьёзными последствиями.

О том, что из себя представляет КИИ, почему она так важна, чему учат будущих специалистов и как устроена работа на практике, рассказывает эксперт из Росатома — руководитель Дирекции «Цифровая Арктика» АО «Гринатом» и ведущий инженер‑исследователь научного центра «Сириус».

• Женатые и замужние — в топе: пока вы не уходите глубоко в анализ, этот быстрый фактор повышает ранг. Чем точнее ваша модель, тем меньше его вес.
• Английский — плохо: знание английского почему-то работало как антипаттерн, снижая релевантность.
• ОГУРЕЦ: кто-то зачем-то написал это слово в резюме. Оно попало в словарь модели и получило большой вес.
• Иксель — люди пишут Excel как угодно, и само слово в правильном написании оказалось снижающим оценку.
• К резюме может быть приложено много мусора. Самый эпичный пример: авиабилет Москва — Челябинск вместо резюме.

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

Часто слышу отголоски дискуссии, что через 10-15 лет за разработчиков будет писать код искусственный интеллект, он же будет находить и фиксить баги, автоматически создавать интерфейсы, анализировать пользовательский опыт и так далее. Так ли это?

Поскольку в Гринатоме сегодня мы уже не только выполняем функцию ИТ-интегратора для Росатома, но и создаем свои ИТ-продукты и выводим их на рынок, у нас очень высокая потребность в кадрах: в Гринатоме более 7 тысяч ИТ специалистов, а к 2035г. их должно стать более 12 тыс.

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

Когда-то я работал системным инженером в одном из крупнейших российских системных интеграторов. Там внедрял и сопровождал системы электронного документооборота. В 2010 году «Гринатом» искал специалиста с моим опытом, чтобы сопровождать свою отраслевую систему документооборота. Мне понравились условия и возможность развивать новые продукты фактически с нуля, и я согласился. С тех пор работаю там, и за 14 лет работы развитие не останавливается. Растёт мое подразделение, и внедряемые технологии, и компетенции. Мы постоянно привносим новые решения, и это не останавливающееся движение очень мотивирует.