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

Этот сценарий мог стать реальностью в любой момент. До 2025 года мы использовали зарубежную систему видео-конференц-связи. Она работала стабильно, но с каждым новым пакетом санкций риск блокировки рос.

Для компании масштаба СИБУРа потеря связи между подразделениями — это не просто неудобство. Это остановка управления, срыв производственных процессов, миллиардные потери.

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

Привет! Мы — команда блога Цифрового СИБУРа. Мы вместе с коллегами из разных подразделений рассказываем в блоге, какие решаем задачи и боли производства, как создаем свои цифровые продукты и как вообще у нас работается.

В декабре на Хабре мы выпустили статью с результатами исследования: почему айтишники идут в BigTech или в промышленное ИТ. Затем мы провели опрос среди хабровчан. А потом под конец года топ Хабра взорвала статья коллеги по цеху, где он рассказал о своём опыте работы в промышленности.

По этим статьям прилетело прилетело 622 комментария от 220 разных людей. Многие делились ожиданиями, своим опытом и мнением — как о работе в промышленности, так и в Big Tech.

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

Поэтому мы подумали, что и мы хотим поделиться, как устроена работа у нас Цифровом СИБУРе. 

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

Давайте по порядку.

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

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

Результаты исследования помогут вам увидеть, как устроены эти сферы изнутри и где вам комфортнее расти и работать.

Создавать инновации быстро и гибко можно в стартапе или небольшой компании, но что, если ты промышленный гигант с более чем 25 заводами по всей стране, отлаженными процессами и бюджетированием, заточенными под беспрерывное производство, в котором каждая секунда на учёте и некогда экспериментировать? Как реализовывать смелые идеи в таких условиях?

Но тем не менее, мы одни из первых начали применять ИИ в промышленности и проводить цифровизацию процессов. То есть у нас активно внедряются современные технологии и реализуются смелые проекты. В портфеле СИБУРа сегодня более 30 реализованных кейсов на базе ИИ. В проработке 200+ гипотез и это число постоянно растет.

Для разработки и внедрения инноваций в СИБУРе есть Лаборатория Инноваций. А для разработок на базе искусственного интеллекта, мы организовали Лабораторию ИИ, но без пробирок и халатов, как многие могли представить, а с компами и дата-саентистами, занятыми тестированием гипотез, оценкой их потенциала, созданием и обучением моделей и многим другим интересным.

Когда иностранные вендоры приостановили работу в России, под угрозой оказалось внедрение систем на производстве этилена и пропилена. Без критически важного программного обеспечения Spyro производство могло столкнуться с серьёзными экономическими потерями. 

Я, Вячеслав Базанов, руководитель проекта, и моя команда инженеров и аналитиков из Цифрового СИБУРа взялись за разработку собственной модели прогнозирования. Это был вызов по масштабу и срокам, но мы справились и за три месяца создали решение, которое не только заменило прежнюю систему, но и улучшило её эффективность. Добро пожаловать под кат — расскажу, как мы это сделали.

Современное производство — это уже давно не просто набор станков и всяких железок в ангарах, теперь это ещё и автоматизации, IT-инфраструктура и много, очень много данных, которые в режиме реального времени стекаются в DWH (Data Warehouse — хранилище данных) из сотен источников.

Эти данные нужно собирать, хранить, обрабатывать и анализировать, чтобы компания могла принимать правильные бизнес-решения. Качество данных (Data Quality, DQ) в таких условиях становится критически важным показателем, от которого зависит рентабельность бизнеса в целом.

Это вторая статья из небольшого цикла, в котором мы разбираем опыт СИБУРа в создании, поддержке и развитии DQ-сервиса. И этот опыт универсален — его можно применять в любой компании, перед которой стоят задачи по обеспечению качества данных.

В первой статье мы рассказывали про импортозамещение DQ-решений после ухода вендора с рынка РФ. В этой статье мы поговорим о задачах, которые решает DQ в целом, и рассмотрим архитектуру решения, которое мы строим в СИБУРе.

Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса в компании последние несколько лет.

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

В небольшом цикле из двух статей мы разберём опыт СИБУРа в создании, поддержке и развитии DQ (Data Quality — качество данных) сервиса для DWH (Data Warehouse — хранилище данных) в условиях санкций и исчезающих вендоров проверенных и привычных решений.

Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в Цифровом СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса на решениях вендора, который решил покинуть рынок РФ в разгар рабочего процесса.

Привет, Хабр! Меня зовут Толя, я лидер компетенции Java в Цифровом СИБУРе. Наш прошлый материал о Docker собрал классный фидбэк, поэтому мы решили развить тему и подготовить ещё несколько статей, двигаясь от простого к сложному.

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

В 2020 году мы рассказали о нашем продукте «Удалённый эксперт AR» — платформа для дистанционного обслуживания и ремонта оборудования, а теперь рассказываем, как он обрастает новым функционалом. Передаем слово Алле Емец, бизнес-аналитику Индустрии 4.0 Цифрового СИБУРа.

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

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

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

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

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

Можно, конечно, попытаться обойтись и без машинного обучения. Самый простой подход — проанализировать данные и составить понятный набор правил формата if-else (если-то). Между прочим, это применяется в реальной жизни, например, при анализе потребительской корзины. Составляется набор ассоциативных правил вида {хлеб, чай} → {молоко}. Это означает, что если покупатель приобретает хлеб и чай, то, скорее всего, он также купит молоко. Вуаля — мы сделали прогноз на будущее. 

Культовый разработчик Кент Бек сформулировал принципы написания ПО, которые в вольном изложении звучат приблизительно так:

1. Заставь код работать.
2. Сделай его понятным.
3. Оптимизируй для лучшей производительности.

Этим основам не один десяток лет, однако джуны (да и старшие порой, будем честны:) спотыкаются уже на втором шаге. В результате получается рабочий, но нечитаемый код, который не просто трудно понять — его нельзя дополнить или исправить, не поломав программу.

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

Сгустили мы тучи, однако. Но всё же, как писать понятный код с первого раза? Рассказываем в материале!

Привет, Хабр! С вами снова Юра, тот самый «цифровик» с завода СИБУРа. С момента моего предыдущего рассказа прошло полгода, и несмотря на описанный мной суровый сибирский контекст, я всё ещё жив, здоров и счастлив. И даже дополз пришёл к вам с охапкой новых рассказов.

Привет, Хабр! Меня зовут Катя Муличева, я тестировщица в СИБУР Диджитал (на фото не я).  За 4 года в профессии я успела попробовать различные виды тестирования и в этом материале хочу описать свой опыт тестирования систем с использованием датчиков интернета вещей.

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

В первой части очень кратко разберёмся с теорией, а во второй посмотрим, что с ней происходит на практике.

Всем привет!

Недавно мы запустили бота, в котором воплощён образ Дмитрия Менделеева (очень важная личность для СИБУРа), в том числе внешность. Он может всякое. Например, рассказывать факты из области химии и науки, отвечать на любой рабочий вопрос и подсказывать правильное решение, рассказывать о СИБУРе и карьере в компании, помогать новым сотрудникам для адаптации — в общем, хороший инструмент для HR-целей.

Сосредоточимся на том, как он устроен внутри.

Тестирование — необязательный этап разработки? Зачем подключать QA к планированию? И неужели люди правда выпускают продукты с дефектами?

Меня зовут Наталья Мурашова, я Senior QA Engineer, тренер по теории, процессам и автоматизации тестирования. Сегодня разберём, что такое тестирование, зачем оно нужно, и как работают тестировщики у нас в СИБУР Диджитал.

Всем привет! Меня зовут Катя Муличева, я тестировщица в СИБУР Диджитал. Последние два года я пишу автотесты для gRPC на Kotlin. Получив опыт, я захотела написать статью, которая очень пригодилась бы мне самой, когда я только начинала разбираться с gRPC. Надеюсь, вы найдете её полезной для себя!

Привет! Меня зовут Александр Апазиди, я руковожу в СИБУРе цифровизацией процессов головного офиса.

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

С 2020 по 2022 количество наших IT-проектов увеличилось с 70 до 220, так что тема ухабистая. Приятного чтения!

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

Разрабы долго ждут обратную связь от QA, половина документации нечитабельна, в Git пропала версия кода, до которой очень нужно откатиться прямо сейчас, потому что в новой всё поломалось в проде и надо вернуть как было… Ещё и вся команда в ссоре и ни один дейли не проходит без скандала. Как вы думаете, быстро ли эта игра дойдёт до рынка?

Это, конечно, драматическое преувеличение, но для решения таких проблем и нужны DevOps-практики.

Привет, Хабр! Меня зовут Анатолий Саблин, я java-разработчик и техлид команды эксплуатации в СИБУР Диджитал. Сегодня я расскажу про сложности, которые возникают на этапе эксплуатации продукта, как они влияют на работоспособность, и как их решить. И особенно рассмотрю:

●      Что важно в разработке программного продукта помимо самого кода;

●      Как сделать релиз и не сломать прод;

●      Какая модель работы больше подходит для промышленной эксплуатации.