За 25 лет в разработке со мной произошло много занятных историй.

Мы сделали клиентов миллионерами, проводя тестирование на проде. Едва не получили дипломатический скандал, показав министру неполиткорректный экран.

Я общался «по понятиям» с боссом из 90-х с индийским колоритом. Корпел над секторами жесткого диска из-за пингвина-терминатора (да, это про Linux!). Физически ощущал запах сгоревшей премии дорогого сгоревшего железа.

Здесь нет вымысла – только ТруЪ истории и опыт, который я получил. Читайте, смейтесь и… никогда не повторяйте это дома.

Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.

Маленькими, изолированными сервисами под конкретную маленькую задачу. Они любят полакомиться чужими событиями. Но они не жадные: поймают одно событие, кинут три. Поодиночке они почти бесполезны. Про них можно слагать анекдоты: «Сколько надо сервисов, чтобы напечатать Hello World?». Поэтому нано-сервисов много, они плодятся как зайчики. Или как маленькие паучки, которые затягивают организацию своей паутинкой.

Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.

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

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

Знакомо?

За 15 лет в тестировании (IBS, Boeing, DHL, Сбербанк, MVIDEO) я убедилась: ключ к стабильности — не в гениальных отдельных специалистах, а в системе обмена знаниями. Расскажу, как мы:

- превратили разрозненный опыт в общую базу знаний, доступную даже новичкам;

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

- сделали тестирование ключевым звеном в принятии решений компании.

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

Я покажу действенные способы отжечь так, чтобы вас запомнили. Зажигательный план состоит из трех этапов:

1. Сделать неотразимое резюме, чтобы у интервьюера задергался один глаз. Или оба.

2. Пройти незабываемое собеседование. Чтобы коллеги отпаивали интервьюера кофе, пока он делится острыми впечатлениями.

3. Получить оффер, оказавшись самым звездным кандидатом.

Подставляйте копилку, накидаю в нее вредных советов.

Итак, для начала надо серьезно поработать над резюме. Оно должно быть как карта, благодаря которой наниматель найдет своё сокровище.

Знаете, что общего между тепловизионными камерами, взрывозащищёнными дронами и 90-метровыми колоннами? Или как в промышленной компании из трёх дронов вырос целый парк из более чем 20 машин, а мониторинг трубопроводов перестал зависеть от человеческого фактора?

В статье рассказываю — как ИИ с точностью 80% ищет утечки, дронопорты летают без операторов, а подводные роботы заменяют водолазов. Но обо всём по порядку.

Чтобы получить работу, это понятно.

Но кто сказал, что враньё сработает? А если наоборот?

Не буду занудствовать о том, что врать нехорошо. Либо родители научили этому в детстве, либо нет. Останусь сугубо в меркантильной плоскости.

Согласно исследованию CareerBuilder, 75% работодателей сталкивались с ложью в резюме, а 40% кандидатов признавались, что «приукрашивали» некоторые факты. Почему это происходит? И как ложь влияет на шансы трудоустройства?

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

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

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

Меня зовут Владимир Кирилкин, я техлид в Цифровом СИБУРе, в команде Индустрии 4.0. Мы разрабатываем продукт «Видеоаналитика на производстве», и о наших задачах уже писали на Хабре.

Мы подошли к задаче нестандартно: вместо заранее заданных форм на фронте реализовали их автоматическую генерацию с использованием JSON-схем и немного ✨магии✨.

Наши сервисы построены на Python и React, но предложенный подход можно адаптировать и для других технологий — правда, с чуть меньшим количеством ✨магии✨.

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

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

Как найти баланс между управлением и кодом? Как не стать «менеджером-менеджером»?

Меня зовут Иван, я работаю лидом в Цифровом СИБУРе, делюсь опытом и своими мыслями.

Дисклеймер:
Если вы уже полностью в менеджменте и код для вас — это прошлое, тут вряд ли найдёте что-то новое. Но если вы всё ещё пытаетесь совмещать управление и программирование, welcome to the club. Буду рад критике и надеюсь, что кому-то станет легче (или нет).

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

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

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

А еще получать печеньки, респект и уважение.

Бизнес большой, а значит, и печеньки большие.

Бизнес ставит цели для IT. У крупного бизнеса цели расписаны минимум на квартал. Чаще — на год. Такие себе водопадные цели. Их сложно поменять, легко принять и невозможно избежать.

А еще бизнес вынужден оперативно реагировать на изменения рынка, что на практике означает кучу не заложенной в план работы.

Почему я об этом пишу?

Разрешите представиться, я — Иван, I solve problems. Я — тимлид в Цифровом СИБУРе. Помогаю команде доставлять ценность. Техника, процессы, команда, продукт — это все мое, родное. И я угодил в жернова корпорации. Судьба такая. Поделюсь своим кейсом по выживанию — методом револьвера.

Привет, Хабр! Меня зовут Илья Олексив, я лидер компетенции направления DevOps в Цифровом СИБУРе. Вместе с моим коллегой Мишей Фуфаевым aka @Redemax, техлидом, в ноябре мы выступали на Industrial++ и обещали выложить наше выступление со слайдами сюда.

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

Чтобы понять, почему тема релизов проблемная, для начала давайте разберёмся, что из себя представляет компания СИБУР. Мы крупная, географически распределённая компания, в состав которой входит 26 заводов и работает более 40 тыс. высококвалифицированных сотрудников.

Когда иностранные вендоры приостановили работу в России, под угрозой оказалось внедрение систем на производстве этилена и пропилена. Без критически важного программного обеспечения 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. Оптимизируй для лучшей производительности.

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

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

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

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