1. Трансформация индустрии. Тренды применения ИИ в обработке видеоданных в сфере производства и нефтедобычи.
Области применения технологий видеообработки.
2. Ограничивающие факторы внедрения современных технологий цифровизации и автоматизации. Проблемы сбора и качества данных для обучения.
3. Калибровка и ретроспективное восстановление качества данных как основа решения (Демонстрация проблемы расфокусировки видеоданных и технологии решения с помощью ретроспективной калибровки видеоданных).
4. Выводы/рекомендации по внедрению решений индустрии 4.0 в практику работы нефтедобывающих компаний.

Ведущие агентства фиксируют прогноз развития индустрии 4.0: в следующие пять лет 75% предприятий будут использовать в своей работе ИИ. Одна из важных задач при обучении ИИ — обеспечение качества исходных данных для обучения, а значит, и их сбора и обработки. В докладе рассмотрим несколько производственных кейсов, разберем проблемы с использованием «грязных» данных, продемонстрируем инструмент для повышения качества сбора фото- и видеоданных и стоящие за этим перспективы.

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

В докладе поговорим про разработанную систему ведения заказов и отслеживания их с помощью интерактивной мнемосхемы, рассмотрим основные проблемы, требования и бизнес-метрики, пройдемся по технической части: архитектура, стек технологий, backend + frontend + IoT, подходы к разработке и закончим разговором про мониторинг.

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

Если коротко, то дизайн-процесс — это не про дизайнера или макеты интерфейса, а про методологию и фреймворки проектирования продукта, которыми может пользоваться любой участник команды: Service Blueprint, CJM, User Flow, разные виды интервью и опросов, дизайн-системы и многие другие.

В «Газпром нефти» мы определили, какие фреймворки удачно ложатся под нашу специфику, выстроили дизайн-процесс как часть процесса продуктовой разработки и успешно применяем и масштабируем результат на продукты компании — зарождающиеся или уже существующие. По итогам внедрения у нас получается избегать старых проблем:
* команды стали чаще общаться с пользователями, в результате непонятных или неиспользуемых фич стало меньше, а продукт точнее соответствует требованиям пользователей и бизнеса;
* продукты проектируются взрослее: стали использовать инструменты проектирования чаще, хранить и передавать участникам команды артефакты, которые формируют единое видение;
* систематизация дизайна и проведение исследований по отдельным решениям позволили сформировать интерфейсные паттерны, которые переиспользуются на других продуктах компании;
* разработанный продукт гораздо реже отходит от требований, дизайн-макетов и спецификаций, а вектор дальнейшего развития виден более явно за счет работы с метриками после запуска — стало проще наращивать уровень удовлетворенности пользователей (CSI).

На кейсах компании расскажу о дизайн-процессе, его фреймворках и внедрении. А также о жизни до и после появления дизайн-процесса.

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

Как же спроектировать приложение, которое будет действительно решать задачи бизнеса и пользователей?

Из моего доклада вы узнаете:
* из каких «уровней сложности» состоит приложение и на что они влияют;
* почему с 10 эвристиками Нормана-Нильсена до сих пор стоит считаться в 2023 году, и к каким ошибкам ведет их игнорирование;
* как работает человеческий мозг, и как это влияет на поведение пользователей;
* что хороший дизайн — это не вопрос вкуса или удачи.

Продуктовый подход требует сплоченной работы всех участников команды: заказчиков от бизнеса, тимлидов, менеджеров, тестировщиков и прочих членов команды. Но у каждого из них есть свой опыт работы в разных компаниях (и это не всегда промышленные компании). Не понимая объективных особенностей внедрения продуктового подхода в промышленной компании, часть участников не могут быть максимально продуктивными.

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

Компания не зарабатывает на продаже IТ-продуктов, зачем тогда делать внутренние продукты удобными? Проектные команды не понимают, что такое удобный продукт — можно ли это исправить? Связано ли юзабилити внутренних продуктов с финансовыми показателями компании? Как повысить UX-зрелость компании? Как работать с обратной связью от внутренних пользователей? Какие популярные исследовательские практики плохо работают для внутренних продуктов?

В b2c-мире внимание и деньги пользователя — основа бизнес-модели продуктовой компании. Взамен люди получают услуги, эмоции, другое качество жизни. В e2e-мире (мире внутренних продуктов) все по-другому. Информационные системы здесь — просто инструменты оптимизации. Но работают с этим инструментами обычные люди, привычные к приложениям заказа еды, такси, мессенджерам и маркетплейсам, в которых продуман каждый сценарий.

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

В своем докладе расскажу про реальный кейс «Газпром нефти» о том, как внедрить практики работы с пользователями при производстве внутренних продуктов и в целом какой эффект может дать повышение UX-зрелости компании.

Масштабирование внутреннего сервиса для внешних пользователей — миф или реальность?

Расскажем про то, как «скучная» разработка внутреннего сервиса по созданию отчетности для ПАО «Татнефть» выросла в продукт для внешних пользователей. Про идею, факапы, поиск решений и выводы, которые мы сделали в ходе работы с внутренним заказчиком.

Информационная безопасность (ИБ) постепенно становится неотъемлемым элементом жизни на предприятиях. Известно ли вам, как устроены и как разрабатываются продукты, на базе которых строят процессы ИБ?

Расскажу:
* какие задачи решают ИБ-продукты и почему экспертиза — это сердце любого ИБ-продукта. Почему экспертизу пишут на специальных Domain-specific language (DSL) и отделяют от исполнительных модулей;
* на каких DSL разрабатывают ИБ-экспертизу для продукта PT ISIM. Как эти DSL встроены в архитектуру продукта и помогают ускорить его разработку;
* какие роли нужны для того, чтобы построить процесс разработки ИБ-экспертизы. От идеи до результата. Как построен процесс разработки ИБ-экспертизы для АСУТП-систем в Positive Technologies.

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

* Делимся статистикой исследований Positive Technologies.
* Рассказываем, какие уязвимости бывают и каких нужно бояться больше всего.
* Что нужно, чтобы делать безопасные технологические решения?
* Рассказываем про нюансы разработки ИБ-продуктов на примере MaxPatrol VM.

Создание новых цифровых сервисов, трансформация прежних, выстраивание IT-инфраструктуры для их функционирования и доступности порождают массу интересных и непростых задач. К примеру: сделать так, чтобы сервисы, компоненты, пользовательские продукты компании были непрерывно доступны для своих юзеров через Интернет. Речь может идти о шлюзе удаленного доступа, мониторинг-панели, мобильном приложении для заказчиков — риск получить DDoS-атаку и потерять доступность извне существует для всех. Чтобы суметь это предотвратить, мы постараемся ответить на такие вопросы:
1) Какие риски создают атаки на отказ в обслуживании, кроме неработающего сайта? Примеры из практики.
2) Что может стать целью DDoS-атаки? Какие точки входа в инфраструктуру наиболее подвержены атакам?
3) Какие техники и сетевые протоколы используются для организации DDoS? Можно ли расставить векторы атак по приоритету опасности?
4) Как устроен мир DDoS-защиты? Аппаратно-программные комплексы, защита каналов связи, распределенные средства фильтрации трафика.
5) Что стоит учесть при проектировании сетевой инфраструктуры и сервисов, чтобы их проще было защитить и труднее "уронить"? Принципы живучести и целостности.

Доклад сосредоточивается на практических аспектах имплементации безопасности в цикл разработки ПО, используя методологию OWASP SAMM (Software Assurance Maturity Model). Этот фреймворк предоставляет организациям структурированный подход к обеспечению безопасности в разработке.

В докладе обсудим, с чего начать, разберем, как внедрить непрерывные проверки безопасности в процесс разработки, не сломав ничего по пути. В каких случаях стоит использовать security pipeline, задумываться о платформе агрегации находок и начинать привязывать web-hook’и.

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

Рассмотрим:
1) что такое контейнеры и что у них под капотом?
Кратко поговорим про механизмы изоляции, организацию работы и модели использования контейнеров.
2) какие допускаются ошибки при использовании контейнеризации и к чему это ведет?
Рассмотрим от лица атакующего, какие ошибки помогают ему сбежать из контейнера или атаковать вашу инфраструктуру.
3) как защитить «свои» контейнеры от внешних и внутренних угроз?
Расскажем от лица защитника, как усложнить жизнь атакующему с минимальными трудозатратами имеющимися инструментами.

Промышленные платформы на микросервисной архитектуре с OpenSource-компонентами и контейнерными средами (такими, как Kubernetes) — достаточно новая история, особенно в части поставки ценности. Как поставить 140+ сервисов в закрытый контур, тщательно изолируемый от любого внешнего воздействия?

Как конфигурировать сервисы в контейнерных средах, как устанавливать и использовать OpenSource-компоненты, если от ответов на эти вопросы зависит работа крупного производственного предприятия?

Ответ на эти вопросы довольно прост — нужно переносить разрешение вопросов, связанных с информационной безопасностью на ранние стадии разработки. Во-первых, проектировать и собирать решения уже «из коробки», которые будут соответствовать предъявляемым требованиям. Во-вторых, проводить максимально ранний аудит и контроль, тем самым сокращая время поставки и развертывания ПО в промышленных средах и стоимость его внедрения.

Как начать проектировать доставку приложения до среды выполнения и не заниматься копипастом? Что нужно учесть, чтоб сократить рефакторинг линии доставки в будущем? Унификация — зачем загонять себя в рамки? Стандартизация — зачем нужна она в современном IТ?

Ответить на эти вопросы я планирую в своем докладе. На основании чего делаю выводы: мы начинали "Цифровую трансформацию" командой 2,5 человека на 5 проектов, сейчас у нас слаженная команда из 6 человек, и мы можем себе позволить вести одновременно более 50 активных проектов и закрывать около 200 проектов в год.

- Как создать проект национального масштаба с нуля в сжатые сроки;
- использование гибкого релизного цикла, позволяющего доносить ценность до пользователя;
- использование современных технологий: Ruby on Rails API; Postgresql; Redis; Sidekiq; RabbitMQ; Sentry; API-документация в Swagger; Nuxt.js; Typescript; Docker Swarm; ELK; Grafana + Prometeus; Sonarqube; Harbor;
- как обеспечить полноценную интеграцию с порталом Госуслуги и валидацию пользовательских данных через систему межведомственного электронного взаимодействия;
- обеспечение проверки вводимых данных с использованием сервиса Dadata;
- использование шифрованного канала АПКШ Континент;
- реализация динамических окружений для разработки для демонстрационных и тестовых стендов;
- использование отдельных цепочек пайплайнов в CI/CD;
- внедрение quality-gate'ов для оценки качества и безопасности кода;
- инфраструктурное обеспечение;
- горизонтальное масштабирование с помощью реплик контейнеров (API/Nginx/Frontend);
- балансировка нагрузки между узлами Docker Swarm-кластера;
- балансировка подключений к БД (Postgresql) за счёт внедрения PGBouncer;
- получение метрик с узлов системы (VM, Postgresql, PGBouncer, Nginx, Docker, Redis, RabbitMQ) в режиме реального времени;
- вынесение всех длительных операций (генерация pdf, отправка писем, генерация отчётов и пр.) в фоновые обработчики (Sidekiq);
- обеспечение высокой отказоустойчивости проекта (за счёт гибкой инфраструктуры);
- защита от несанкционированного доступа к данным за счёт использования защищённых каналов связи;
- модель CI/CD (распараллеливание выполняемых задач, кэширование артефактов);
- внедрение отказоустойчивости Sidekiq во время деплоя за счёт кастомизации пайплайна в CI/CD;
- применяемость в отрасли, абсолютное отсутствие аналогов.

Водители бензовозов, доставляющие топливо на АЗС сети «Газпром нефть», для работы используют специальное приложение. И в своем выступлении я расскажу, как мы взяли библиотеку infinispan для кэширования данных, чтобы ускорить работу с бэкендом системы логистики. Рассмотрим, как работали с требованиями информационной безопасности, а также выстроили надежную, безопасную и отказоустойчивую систему.

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

* Как мы достигли предела вертикального масштабирования.
* Какие гипотезы выдвинули и как их проверяли.
* В чем проблемы микросервисной архитектуры для крупного предприятия, и как мы решаем эти проблемы.
* Как мы обеспечили 100% доступность наших сервисов для клиента.

Выступление об асинхронном обмене сообщениями, реализованном на базе брокера сообщений Apache Artemis для мониторинга оборудования на бензовозах и автозаправочных станциях сети «Газпром нефть».

Расскажем, как команда интеграции пришла к текущему решению, поговорим про архитектуру и про то, как расширить функциональность Apache Artemis и сделать версию импортонезависимой.

При проектировании ПО часто встает вопрос о выборе между использованием готовых компонентов и написанием своего «велосипеда».

При этом можно отметить, что компании небольшого размера склонны к первому подходу, а «big tech» — к последнему.
В докладе мы расскажем об эволюции подсистемы расчетов платформы ZIIoT, о том как в какой-то момент мы еще не стали «big tech», но уже доросли до отказа от готовых решений и были вынуждены спроектировать свой небольшой, но очень быстрый «трехколесный велосипед».

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

Когда говорят о монолите, обычно называют его если не антипаттерном, то как минимум чем-то морально устаревшим. Но в последнее время набирает силу обратная точка зрения.

Многие компании получили опыт в микросервисах, оценили возникающие сложности и стали возвращаться к монолитам. Даже Amazon выпустил статью о том, как они оптимизировали решение при переходе на монолит! Хотя, казалось бы, высокая производительность — это как раз про микросервисы.

В своем докладе я покажу, какие преимущества микросервисов на самом деле доступны и без них; как монолит позволяет уменьшить сложность и повысить производительность. А также как монолит позволяет экономить на железе. И, если уж приходится переходить на микросервисы, — как сохранить преимущества монолита.

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

В докладе расскажем:
1) как мы выбирали платформу, чему отдали приоритет и какие построили планы. Первые успешные кейсы: возможность индивидуально работать по конкретным продуктам, обучение;
2) как поняли, что что-то идет не так: возможности и ограничения платформы, влияющие на развитие продуктов. Как выбрать между стандартной разработкой и разработкой на лоукоде;
3) какие процессы удалось переложить на лоукод-разработку: примеры реализованных продуктов и факапы;
4) светлое будущее через оптимизацию процессов работы с платформой.

Скала^р — это производитель ПАКов, которые мы называем Машинами.
Одна из наших Машин — МБД.П — это как Oracle Exadata, только про PostgreSQL.

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

В целом у нас получилось довольно симпатично, на наш взгляд, на докладе и после него постараемся это показать.

Внутри нашей Машины — кластеризованный PostgreSQL, с точки зрения разработчика ИС работа с такой БД имеет ряд нюансов, про них мы тоже поговорим.

Рассмотрим реальные случаи из жизни и придуманные примеры, где решение именно с такой архитектурой (не обязательно наш ПАК) либо уже используется, либо может быть полезным, в том числе и для буквальной замены решений от Oracle.

В докладе будут рассмотрены:
* проблема миграции. Откуда она появилась, если реляционная модель данных математически строго формализована и разработаны стандарты и языка SQL, и средств доступа к данным, например JDBC. Почему же так трудно заменить одну СУБД на другую?
* подходы к миграции, какие инструменты используются;
* устройство конвертера РЕД СОФТ (парсер метаданных СУБД Оракл, набор правил преобразования грамматических конструкций, генерация метаданных СУБД Ред База Данных);
* в чем вообще заключается миграция, как ее провести и что сделать после?

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

В своем докладе мы поделимся опытом использования стандартов и протоколов для сбора и передачи оперативной информации по бурению. Дадим обзор существующих стандартов, поделимся актуальными проблемами интеграций и вынесем на суд сообщества Byte & Oil Conf пути развития стандартов в России в условиях технологического суверенитета.

В нашем докладе мы расскажем историю внедрения корпоративной цифровой платформы по управлению данными «NESTRO DATA», созданной как централизованный источник «Единой версии правды» по всем основным аспектам деятельности. На 1-м этапе реализован домен данных по направлению разработки месторождени. Будут детально рассмотрены следующие разделы:
1. Технологический стек
При создании цифровой платформы было внедрено 5 компонентов:
КШД, КХД, каталог и хранилище неструктурированных данных, BI, система визуализации геологической информации
При выборе инструментов цифровой платформы, команда опирались на директивы по импортозамещению, выбраны отечественные продукты.
2. Модель хранилища, каталог данных
Наш проект - пример внедрения подхода к моделированию хранилищ данных DataVault, будут приведены примеры реализации. Важная и сложная часть по управлению большим хранилищем неструктурированных данных, с возможностью наследования методанных по каждому из видов проектной документации.
Расскажем о ролевой модели доступа к данным, работе с владельцами систем, ИБ, качестве данных и всех сложностях интеграции данных в крупной компании.
3. Дальнейшие планы
Результаты пилотного проекта стали первым шагом к построению цифровой платформы по управлению данными и фундаментом для дальнейшего внедрения инструментов цифровизации на базе созданной платформы, включая AI, RPA и другие.

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

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

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

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

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

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

Затронем следующие темы:
• методы и форматы визуализации географических данных с помощью postgis и их эффективной сетевой передачи;
• подходы даунсемплинга телеметрии высокоинтенсивных данных;
• методы ретрансляции на frontend географического трека и телеметрических данных большой ширины;
• бесконечная очередь обработки данных высокой плотности и методы их демонстрации в браузере.

Основная идея доклада.
Нам удалось создать решение, которое обеспечивает бесшовную замену SAP'овской шины на новую. В докладе мы поделимся опытом, как это удалось реализовать с технической точки зрения, а именно:
• как снизить стоимость создания/поддержки интеграции между информационными системами;
• зачем компаниям внедрять интеграционную шину;
• зачем нужно сертифицировать интеграционную шину во ФСТЭК и вносить в реестр отечественного ПО;
• технологии под капотом — замена интеграционной шины от SAP (мировой лидер) без простоя и внесений изменений.

О чем слушатели узнают из доклада:
• оптимизация настройки потомков с помощью low-code-решения (в тему про снижение стоимости интеграций);
• почему не подошли готовые продукты на рынке;
• отсекающий критерий выбора;
• критерии отбора базового продукта;
• различия между Атом.Мост и базовым продуктом;
• бесшовность — за счет готовности конвертеров SAP'овской шины;
• аспекты безопасности решения (единая точка для хранения учетных записей и прозрачная работа с конфиденциальными данными);
• 5 причин, зачем вносить шину в реестр отечественного ПО (необходимость наличия сертификатов ФСТЭК и Росреестр).

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

В докладе я покажу, как с помощью GAN, Nerf и unreal engine создавать искусственные данные и решать данную проблему. Будет показано, как эта связка методов способствует предотвращению переобучения моделей в задачах видеоаналитики на площадках Сибура.

Доклад посвящен особенностям и специфике решения задач в нефтегазовой отрасли при помощи машинного обучения.
Во время доклада мы поговорим обо всем и сразу:
* Обсудим особенности машинного обучения в нефтегазовой отрасли;
* Рассмотрим несколько реальных кейсов применения машинного обучения в отрасли;
* Поговорим о том, как устроен процесс разработки решений на основе МО в крупной промышленной компании.

Данный доклад является обзорным и основывается преимущественно на личном опыте докладчика.

В своем докладе сделаю обзор на разработанный компанией «Газпромнефть – Цифровые решения» сервис для проведения групповой оптимизации режимов работ скважин. В основе решения — генетический алгоритм, относящийся к категории методов машинного обучения с подкреплением.

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

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

В докладе расскажу про опыт создания информационной системы для мониторинга работы фонда скважин и скважинного оборудования с помощью продвинутых алгоритмов анализа данных, классических методов нефтяного инжиниринга, а также применения гибридных подходов. Созданная интеллектуальная система позволила автоматизировать бизнес-процесс по контролю добычи нефти на активах группы компаний ПАО «Газпром нефть» с различными условиями эксплуатации, поэтому имеется широкий список преодоленных вызовов — от создания единой и устойчивой системы поставки данных в режиме реального времени до реализации уникальных гибридных подходов по созданию цифровых двойников.

Приведем примеры реализаций различных комбинаций физических моделей и методов машинного обучения — гибридный подход. Рассмотрим различные способы объединения двух методов решения задач нефтяного инжиниринга. Сделаем выводы насчет области применения различных подходов и обоснованном тестировании полученных моделей.

На примере этапа R&D-алгоритмов Computer Vision будет рассказано о проблемах, с которыми сталкиваются разработчики при переходе от прототипа к продукту. Анализ большого объема разнородной информации (патенты, статьи, выступления и т.д.) и низкий процент успеха при проверке на гипотезах, проблемы геофизической специфики и их решение, ограничения имплементации прототипов в коммерческий продукт, особенности разработки методик применения и препятствия к продвижению высокотехнологичных продуктов на рынке.

Доклад направлен на обмен опытом между специалистами R&D-подразделений разработчиков ПО для задач поиска, разведки и разработки месторождений нефти и газа.

Наверное, нет такого ML-разработчика, евангелиста технологий ИИ или практика, интересующегося перспективами машинного обучения в нефтегазовой отрасли, который хоть раз бы не слышал (или не думал): "Искусственный интеллект — это черный ящик! Невозможно понять его логику принятия решений. Серьезное применение его в нефтегазовой отрасли невозможно!". Наука и практика показывает иное — в последнее время активно развивается направление ИИ, которое получило название "научное машинное обучение" (SciML).

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

Обучение с подкреплением (RL) получило широкое распространение благодаря прорывным результатам в играх: победа над чемпионом мира в игру Go, победа в компьютерной игре Dota 2 против профессиональной команды. Однако о применении RL в сложных промышленных системах известно не так много.

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

* Зачем нужно отечественное решение класса DCS/SCADA;
* что нового могут предложить российские разработчики с большим опытом автоматизации АЭС;
* место HighLoad Low-latency в системах такого класса;
- метамодель в HL/LL;
- стек реального времени;
- резервирование компонентов;
- балансировка нагрузки.
* зачем нам пришлось сделать свою IDE для разработки;
* резервирование, отказоустойчивость, управление деградацией распределенных узлов системы;
* отделить "мух от котлет", идеальная мнемосхема, ее программирование и связка с СУБД РВ;
* как достигается кроссплатформенность;
* кибербезопасность DCS/SCADA.

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

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

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

В критической информационной инфраструктуре одним из важнейших требований к СУБД как части информационной системы является отказоустойчивость.

Наряду с отказоустойчивостью СУБД в последнее время все больше предприятий предъявляют повышенные требования к своим сервисам, эти требования включают и катастрофоустойчивость. Сегодня катастрофоустойчивый кластер (КУК) СУБД уже стал стандартом архитектуры критической информационной инфраструктуры.

О разновидностях, принципах и подходах к построению КУКов PostgreSQL, а также о нюансах и трудностях при эксплуатации пойдет речь в докладе.

Компаниям России поставлена серьезная задача по обеспечению технологического суверенитета в сфере автоматизированных систем управления производственными процессами. На повестке стоит дедлайн по переходу на российское оборудование и программное обеспечение на объектах критической информационной инфраструктуры, в процессе реализации которого был выявлен ряд вызовов технического характера, в том числе vendor lock-in, отсутствие поддержки ряда полевых протоколов передачи данных (Fieldbus Foundation, Profinet, S7), риски для производства при техническом перевооружении оборудования.

В рамках доклада постараемся рассмотреть требования к импортозамещению АСУТП, конкретные проблемы и возможные варианты реализации. На примере опыта АО «Зарубежнефть» будут рассмотрены практические задачи по выполнению плана перехода на российское программное обеспечение и программно-аппаратные комплексы на объектах критической информационной инфраструктуры.

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

Группа компаний ПАО «Газпром» начала свой путь к обеспечению технологического суверенитета в части цифровых технологий более 10 лет назад. За это время наработан громадный опыт взаимодействия с российскими разработчиками и интеграторами, проанализирован и введен в эксплуатацию внушительный объем отечественных решений. Однако ряд ключевых инструментов и систем так и не были полностью заменены. Причины отсутствия отечественных аналогов связаны не только со сложностью их реализации, но и со спецификой, обуславливающей востребованность в узкоспециализированном сегменте, значительно не распространенном в отрасли. На сегодняшний день на российском рынке слабо развиты решения в области интерпретации сейсмических данных, геологического и технологического моделирования, отсутствуют специализированные решения в разработанных CAE-системах.

ООО «Газпром ВНИИГАЗ» — ведущий институт ПАО «Газпром», обеспечивающий научное сопровождение разработки месторождений и эксплуатации технологического оборудования. Именно институтом формируются требования к наукоемким индустриальным решениям. Практикуются различные модели взаимодействия с российскими разработчиками IТ-решений, от методолога до заказчика.

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

1. Что такое Реестр отечественного ПО и при чем тут нефтегаз?
С 2023 г. нефтегазовые компании обязаны прекратить использование иностранных программ и перейти на использование отечественного софта. Отечественный софт — софт, который включен в Реестр российского ПО, поэтому в скором времени весь софт, используемый нефтегазовыми компаниями, должен быть из Реестра российского ПО.

2. Какие есть плюсы у Реестра?
При помощи Реестра можно легализовать использование иностранного опенсорса.
Для компании также дает много бонусов: коммерциализация внутренних разработок, экономия на налогах, IТ-аккредитация, отсрочки от армии и льготные ипотеки.

3. Что важно учесть в разработке для включения в Реестр? Можно ли использовать иностранный опенсорс в разработке?
Для включения в Реестр есть требования к техстеку: не все опенсорс-продукты можно использовать в программе. В докладе расскажем, какие компоненты использовать можно, а какие точно нельзя.

4. Какие еще есть требования к программам?
Есть требования к месту хранения кода, сайту компании и другие. Подробно разбираем каждое.

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

6. Немного о ПАК.
С недавнего времени в Реестре стало возможным зарегистрировать программно-аппаратные комплексы, поэтому все больше программ будет включаться в Реестр.

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

При создании изолированной инфраструктуры для разработчиков перед нами стояла задача выбора российского решения на основе Kubernetes. Наш выбор пал на платформу контейнеризации Deckhouse от компании «Флант».

На этапе внедрения пришлось преодолеть множество проблем, начиная с перехода на отечественные операционные системы и заканчивая доработкой шаблонов для миграции на API Kubernetes.

В докладе расскажем, какие сложности и вызовы встали перед командой цифровой платформы N1 «Газпром нефти», поделимся интересными задачами, которые получилось решить совместными усилиями с командой разработки и поддержки Deckhouse.

В докладе я постараюсь рассказать о нашем извилистом пути по достижению целей, которые были поставлены перед компанией, таких как сокращение издержек в IT-проектах, повышение эффективности и цифровизация бизнес-процессов. Достижение этих целей усложняется еще и внешним давлением — санкциями и необходимостью перехода на отечественный тех. стек, который привел к ограниченному выбору IT-решений на рынке, а порой повторному «переоткрытию» уже существующих решений, таких как управление задачами и управление IT-процессами CI/CD, база знаний и т.д.

Я расскажу про наш путь к созданию IT-платформы, и мы обсудим ключевые моменты:
* анализ текущих участников рынка управления задачами и знаний (вики), выявление их сильных и слабых сторон;
* обзор инструментов управления проектами, включая портфельные и программные решения;
* сокращение издержек, где IТ-проекты много теряют, и как мы можем помочь бизнесу сократить потери? Какие инструменты автоматизации позволяют это сделать?
* пара слов о прототипировании и no-code как способе «срезания» костов.

В докладе рассматривается разработка и реализация комплексной информационной системы, предназначенной для сбора, хранения, визуализации и обмена временными рядами данных. Система обеспечивает сбор данных с различных станций контроля и управления, их хранение в локальной базе данных PostgreSQL, а также предоставляет пользовательский интерфейс для отображения данных через десктопное и браузерное приложения. Особое внимание уделяется реализации offline-first-подхода, который позволяет работать с приложением без доступа к интернету. Также система обеспечивает коммуникацию с центральным сервером на Node.js, позволяя передавать данные на сервер в случае наличия интернет-соединения. В докладе также рассматривается архитектура распределенных серверов для обмена данными между ними.

Основные тезисы доклада:
1. Механизмы локального сбора данных с различных станций контроля и управления.
2. Принципы offline-first-подхода для работы с приложением без интернет-соединения.
3. Архитектура распределенных серверов системы для обеспечения синхронизации и коммуникации между экземплярами приложения.
4. Визуализация, инженерный анализ данных и система контроля допустимых значений параметров технологической операции.
5. Опробованные подходы при создании системы синхронизации данных (SQL-скрипты, логическая репликация в PostgreSQL, REST-коммуникация node.js-серверов, gRPC-stream-коммуникация).

Наши заказчики плотно занимаются импортозамещением. Цель — перейти с иностранного на отечественный софт. В целях импортозамещения заказчики выбирают и переходят на отечественные продукты. Вместе с тем заказчики занимаются инхаус-разработкой, для которой используются общедоступные инструменты: среды разработки (например, Visual Studio Code), наборы готовых библиотек (например, PyPI). Использование опенсорсных версий этих инструментов несет определенные риски, 100% доверия им нет. И появляется потребность в отечественном доверенном источнике таких библиотек и инструментов.

В контексте данной проблемы РЕД ОС и ее репозиторий позиционируется как доверенный источник инструментов и библиотек для инхаус-разработки. В рамках доклада я расскажу о главных составляющих системы производства РЕД ОС, которая и делает ее доверенной. Затрону темы сборки пакетов из исходников, автоматического тестирования, проверки пакетов на зловреды, поиск уязвимостей. Покажу сканеры уязвимостей, наиболее подходящие для тестирования РЕД ОС. И отдельно расскажу про систему производства Docker-образов на пакетной базе РЕД ОС.

DevOps — это не только новое название системных администраторов, но и новый подход к цифровому производству. Сам производственный процесс становится активом компании, он закреплен в виде кода, компетенций специалистов и оцифрованных производственных процессов.

В докладе я расскажу:
* об истории DevOps и как DevOps подходы переносятся на цифровое производство;
* о технологическом конвейере и инженерных практиках;
* об инструментальной платформе как основе технологических процессов;
* как устроена инструментальная платформа и как её строить;
* о стратегии построения инструментальной платформы — свое или купить?

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

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

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

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

Человеческий фактор при бурении нефтяных скважин чрезвычайно высок: раннее выявление осложнений, своевременное, взвешенное и правильное принятие решений может нивелировать осложнение и, наоборот, несвоевременное реагирование может усугубить ситуацию. Как следствие — срыв сроков бурения и потеря денег как заказчиком, так и подрядчиками. Совершенно невозможно (дорого) на каждой буровой содержать высококвалифицированного специалиста, способного качественно вести процесс. И очевидные решения — переложить рутину на автоматизированные системы; работу, требующую анализа человека, агрегировать в центральном пункте.

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

Крайне важный аспект строительства — качественное проектирование с учетом осложнений и фактической информации при бурении соседних скважин на месторождении, поэтому системы домена для проектирования и мониторинга глубоко интегрированы между собой.

Более подробно рассмотрим создание системы онлайн-мониторинга бурения в условиях технологической независимости.
1. Введение в проблему технологической независимости в разработке программного обеспечения для нефтегазовой промышленности.
2. Рассмотрение практических примеров успешной технологической независимости в разработке программного обеспечения для мониторинга бурения скважин. Описание технологий и подходов в разработке ИС, которые могут быть использованы в условиях импортозамещения.
3. Обсуждение перспектив развития и дальнейших вызовов в области импортозамещения в разработке программного обеспечения для нефтегазовой отрасли.

Доклад посвящен описанию ключевых направлений в IТ-архитектуре предприятия.

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

Во второй части будет представлен подход по управлению архитектурой предприятия на основе бизнес-способностей. Как в части теории и методологии, так и практические примеры, основанные на опыте реализации в крупной нефтяной компании, а также индустриальном центре компетенций «Нефтегаз, нефтехимия и недропользование».

* Предпосылки — зачем в IТ-решениях для нефтяной отрасли продуктовые метрики, и почему мы стали делать свою систему аналитики.
* Особенности реализации сложного продукта в условиях корпоративного IТ-ландшафта.
* Сложности в процессе реализации продукта — с чем мы столкнулись на этапе проектирования и запуска MVP.
* Эксплуатация продукта — как обеспечили стабильность и быстродействие.
* Проблемы роста — масштабирование продукта — какие решения мы приняли и принимаем, чтобы обеспечить стабильность в условиях роста нагрузки.

* На примерах рассмотрим, что такое цифровая трансформация;
* Определим варианты внедрения цифровой трансформации в компаниях;
* Поговорим об инструменте оценки цифровой зрелости;
* Расскажем, какой инструмент реализуется в СИБУР.

О том, как мы ушли от outsource-разработки и собирали команду «Татнефть Цифровые технологии». Про глубокое погружение в процессы компании — одного из лидеров нефтегазовой отрасли России, трансформацию, роль и становление тимлида.

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

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

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

Мы прошли долгий путь: от использования сторонних решений до создания внутренних UI-библиотек, гайдлайнов и, наконец, собственной OpenSource-дизайн-системы PRIZM.

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

Централизованные vs децентрализованные vs распределенные модели управления как системы.

Холивары о централизованных, децентрализованных и распределенных системах ведутся постоянно, они актуальны как для разрабатываемых нами программных решений, так и для компаний в целом и построения инженерной культуры — общие процессы разработки или каждые бизнес-блоки/стримы/команды могут работать по-своему?

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

В докладе поделюсь опытом построения производственных моделей управления разработкой, сравню это с разработкой программных систем в контексте плюсов и минусов централизации, децентрализации или распределенности. Как помогают сообщества и гильдии поддерживать и развивать инженерную культуру, как InnerSource и получение от самих команд крутых реализованных кейсов помогают в создании общих лучших практик, какие методики и стандарты стоит делать общими, а какие процессы должны оставаться гибкими для кросс-функциональных команд. Как гибридная модель может работать в организации с сильной автономией бизнес-блоков/стримов, где разный уровень цифровой зрелости. Как мы в "Газпром нефти" — вертикально интегрированной организации — идем по пути к инженерному совершенству.

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

Внедренная система позволяет принимать обоснованные решения для улучшения процессов разработки и повышения эффективности.

На встрече поделюсь опытом:
* о том, как не нужно измерять все что измеряется;
* куда смотреть и откуда собирать статистику;
* о наших ключевых инженерных метриках и о том, как работать с ними для повышения управляемости разработки.

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

Фишка доклада: порефлексируем на тему Атом.Проект vs Jira — как мы научились смотреть на управление проектами одновременно глазами пользователя и глазами разработчика решения, на что обращать внимание как пользователь (как смотреть на продукт с двух углов: и со стороны разработчика, и со стороны пользователя).

О чем слушатели узнают из доклада:
* разложим по полочкам наш опыт поиска замены джире, и почему мы не взяли ничего, что есть на рынке;
* саморефлексия на тему Атом.Проект vs Jira;
* какие технологии взяли;
* как выстроили работу;
* каких ошибок сразу не делать.

Самое главное — рассказываем про «эффект швабры»: какие функции «решают!», какие фичи на самом деле упрощают работу и поднимают продуктивность, а какие фичи — “пустышки”, на что обращать внимание при выборе решения для продуктивности команд.

1. Основные вызовы и предпосылки проекта
- Орг. периметр проекта включает более 100 организаций атомной отрасли, практически всех дивизионов и видов производств (добыча урана, машиностроение, научные, сервисные предприятия, трейдинг, работа с отходами, производство электроэнергии). Что определяет широкие требования к реализации в ERP-системе процессов производства, формирования себестоимости.
- Сроки проекта разделены по волнам тиражирования до середины 2025 г.
- Параллельный переход на полностью импортонезависимый стек инфраструктуры и решений.
- Основные предпосылки: переход на современную ERP-систему взамен решения, которое снимается с поддержки вендора.

2. Инструменты управления проектом (СППР) Единая система для ведения разработки и поддержки
- Команда проекта более 200 человек от заказчика, предприятий, Центра обслуживания, ген. исполнителя и субисполнителей.
- Необходимость обеспечить команду единым информационным полем, в котором отражены работы, статусы, результаты. В качестве решения этой задачи выбрана 1С: СППР.
- Все требования к системе, процессная модель, проектные решения и атомарные задачи сотрудников проекта живут в СППР. Из системы генерируются отчеты, отражающие прогресс проекта, статус выполнения работ

3. Взаимодействие с вендором, приоритетность типовой конфигурации
- Организовано участие фирмы "1С" в проекте в целях контроля архитектурных решений по доработке и развитию функционала, определение и обсуждение дефицитов и планов развития с вендором, устранения выявленных ошибок.

4. Инструменты непрерывной разработки
4.1. Путь к конвейеру сборки
4.2. Автоматическое дымовое и функциональное тестирование
- синтаксис-контроль
- полное дымовое тестирование
- сценарное тестирование
4.3. Автоматическое ежедневное обновление продуктивных и тестовых систем
4.4. Контроль технологического долга
- интеграция системы ведения задач с системой статистического анализа кода Sonar Qube
- периодический разбор с командой разработчиков критичных ошибок
4.5. Система управления расширениями
- расширения вместо хотфиксов
- установка расширений на 100+ баз

5. Мониторинг как основа надежной эксплуатации системы
5.1. Автоматический мониторинг работы оборудования
- Zabbix и используемые метрики оборудования
- специальные метрики 1С (доступность баз, занимаемое место и прочие)
5.2. Автоматический мониторинг наличия ошибок по журналу регистрации и технологическому журналу
5.3. Технологический журнал — выявление медленных операций, блокировок и взаимоблокировок:
- использование скриптов для автоматизации рутинных операций
- перенос наработок в 1С
- проба ElasticSearch/OpenSearch
5.4. Визуализация мониторинга
5.5. Грабли мониторинга