{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Как DevOps помог исправить 30 точек операционной неэффективности в промышленности

Всем привет! Я Станислав Тибекин, CVO компании Nixys. Мы помогаем выстраивать процессы DevOps, DevSecOps, MLOps. Внедрение DevOps в промышленности началось не вчера, активное применение практик тоже, но говорят об этом по-прежнему немного, поэтому хочу рассказать, как DevOps помог улучшить работу горнодобывающей компании. Приятного чтения!

С чего все началось

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

В какой-то момент это предприятие начало масштабную работу по поиску точек операционной неэффективности и их исправлению на своих ТС. Как выглядели проблемные места? Представьте себе угольный карьер. На нем работают 30 экскаваторов и 90 самосвалов, которые, соответственно, грузят и возят породу. И вот водитель самосвала делает очередную ходку к одному из экскаваторов. А тот — грузит уголь в другую машину. И в очереди уже два самосвала. Как быть? Ехать к другому экскаватору, который тоже может быть занят, или стоять и ждать? Кажется, что ситуация совершенно рядовая, но из-за этой небольшой неэффективности предприятие теряет эффективность на:

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

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

А что DevOps?

Кажется, что все довольно просто с этими точками неэффективности, ищи да ищи, исправляй да исправляй. Но мы ведь говорим о промышленности, верно? Здесь нельзя «просто исправить», нужно учесть фактор непрерывности производства, не поставить под угрозу безопасность (например, выставив водителям неправильную скорость через цифровой помощник), ну и не забыть, что все решения, в конце концов, принимаются с опорой на полученный мгновенный бизнес-эффект.

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

Для этого и нужен был DevOps: решения, эффективность которых была недостаточной или же в целом не совпали с ожиданием бизнес-эффекта - откатывались, новые решения быстро попадали в продакшен и так, пока идея не показывала нужный результат. Важно отметить, сам заказчик (предприятие) не знает в каком виде хочет получить желаемый результат! Нельзя просто взять и скопировать наработки с других подобных предприятий. Ну и, конечно, мало создать цифровые сервисы — их нужно где-то запускать, поддерживать работу, не забыть про отказоустойчивость и SLA. И, еще единое пространство для разработки. Обо всем по порядку.

Сотрудничество между нами началось с аудита IT-инфраструктуры, детального погружения в архитектуру заказчика и обсуждения этапов работ. Заказчик брался за амбициозную задачу — найти и устранить точки операционной неэффективности ТС, а для этого нужно внедрить культуру DevOps. На первом этапе было необходимо проинсталлировать инфраструктуру, настроить окружения разработки, выстроить культуру CI/CD (построить процесс разработки, использующий современные практики непрерывной интеграции и доставки кода), наладить мониторинг систем и организовать техподдержку 24/7. На этом этапе у предприятия еще не было production-ready системы, все находилось в разработке и упор на SLA никто не делал. Затем усовершенствовать инфраструктуру так, чтобы гарантировать отказоустойчивость для той ее части, которая относится к production-окружению, и финально — дать рекомендации по тому, какие практики можно внедрить в условиях заказчика и с его ресурсами в дальнейшем.

Почему был сделан такой акцент на отказоустойчивости? Всё дело в непрерывном производстве. С цифровыми сервисами заказчика, то есть с инфраструктурой, круглосуточно работают диспетчеры. Также в систему поступают данные с грузовиков и другой техники. Если система неотказоустойчивая, цифровые сервисы могут «лечь» и работа встанет. Есть и технические проблемы, например, за час простоя в сервисе накапливается столько данных с систем мониторинга, что после запуска диспетчеры не могут работать с системой ещё час, потому что она обрабатывает эти данные. То есть час простоя фактически равен двум. Все эти тонкости были нами учтены и всего в процессе цифровизации и внедрения DevOps было исправлено около 30 точек операционной неэффективности ТС (как в примере с экскаваторами и самосвалами).

Конечно, сотрудничество с заказчиком продолжается, много интересных проектов делаем, но NDA никто не отменял :) Если есть вопросы — с радостью отвечу в комментариях.

#it #devops #cicd #devops_услуги #itинфраструктура #it_аутсорсинг #промышленность #аудит_инфраструктуры #nixys

0
Комментарии
-3 комментариев
Раскрывать всегда