Блог компании accenture

5 условий зарождения искуственного интеллекта в индустрии

28.05.2021 16:10:14 |

Автор: admin

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

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

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

1. Единая команда с общим мышлением

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

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

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

2. Переход к новой культуре технологических и бизнес-процессов

В ходе ряда исследований последних лет учёные выяснили, что при совершении одной и той же ошибки в прогнозах люди скорее перестают доверять алгоритму, чем человеку [1].
Да, люди склонны больше доверять себе подобным, потому что знают, как мы устроены, потому что примерно понимают логику поведения друг друга и легко могут представить себя на месте другого человека, спроецировать ситуацию.
Когда менеджеров первой линейки и среднего звена спросили, что побудило бы их доверять советам системы, 60 процентов выбрали вариант Чёткое понимание того, как работает система и как она генерирует совет, 55 процентов Система с проверенной репутацией, и 49 Система, которая объясняет свою логику [2].
Перед компаниями, которые берут курс на цифровизацию и переход на новый уровень построения технологических и бизнес-процессов за счёт внедрения систем ИИ, стоит сложная лидерская задача сформировать корпоративную культуру, способствующую пониманию целей, этапов, способов их проектирования и внедрения. Достичь этой цели непросто, поскольку многие люди, особенно те, кому непосредственно придётся взаимодействовать с ИИ, часто обеспокоены, что в конечном счёте машины могут занять их место, а они останутся ненужными и без собственного ремесла.
В рабочей среде необходимо сформировать понимание, что искусственный интеллект позволит не отвлекаться на отдельные задачи и направлен не на замену сотрудников, а на расширение их возможностей, перевод функционала на новый уровень, облегчение их работы и возможность сосредоточиться не на рутинных процедурах, а на вещах, по-настоящему нуждающихся в человеческом интеллекте.
Команда разработки, со своей стороны, должна освоить язык индустрии, максимально глубоко погрузиться в производственные и технологические процессы.
Крайне важно, чтобы люди, которые будут непосредственно пользоваться ИИ, понимали основные принципы его устройства и поведения, могли вносить коррективы в результаты его работы и чувствовали себя активными участниками разработки, чтобы у них было ощущение прозрачности и контроля системы. В идеале, конечно, системы ИИ необходимо проектировать так, чтобы они объясняли свои решения и помогали людям сохранять определенную автономию в принятии решения.

3. Экспериментирование с ИИ

Несколько раз в нашей практике бывало такое, что производственные бригады, которые работали с нашим сервисом, не выполняли его рекомендации или пытались его обмануть, потому что боялись получить нагоняй от своих начальников за возможное снижение показателей эффективности производства и повышенные производственные затраты (например, повышенный расход электроэнергии).
На этапах горячего тестирования системы ИИ важно создать максимально доверительную обстановку внутри объединённой команды, важно дать понять экспериментаторам, что отрицательный результат это тоже результат и порой он бывает даже более ценным, чем положительный. Тут необходимо быть максимально честными и не утаивать истинное положение дел. Где-то это сравнимо с приёмом у врача. У пациента не всегда бывает желание рассказывать обо всех своих симптомах и отклонениях по здоровью, он утаивает некоторые, а впоследствии лечение становится гораздо более длительным, дорогостоящим и сложным.
Соль в том, чтобы стать немножко стартапом и научиться быстро экспериментировать с цифровизацией в стиле стартапов. Их обычное правило: если получается, идём вперёд, если нет, пробуем новую идею. Каждый такой стартап это многоступенчатый процесс проработки и развития гипотезы от рождения, через проверку и превращение в рабочее решение, до получения бизнес-эффекта. Причем сотрудники, которые занимаются одной гипотезой, должны сопровождать ее от начала до конца [2].
Основной метрикой развития гипотезы должен стать бизнес-эффект, для которого важно построить модель расчета в самом начале проекта, при этом на каждом шаге данная модель актуализируется. Очевидные вначале источники эффекта для гипотезы могут оказаться бесперспективными, но по ходу реализации могут появиться новые идеи, и результат будет достигнут за счет них.

4. Важность налаженной и полной поставки данных

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

5. Забег на длинную дистанцию

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

Заключение

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

Литература

Человек+машина. Новые принципы работы в эпоху искусственного интеллекта / Пол Доэрти, Джеймс Уилсон; пер.с англ. Олега Сивченко, Натальи Яцюк; [науч. ред. М. Григорьева, А. Кучма, А. Епишев, Е. Кученева]. М.: Манн, Иванов и Фербер, 2019. 304 с.
Индустрия Х.0. Преимущества цифровых технологий для производства / Эрик Шеффер: Пер. с англ. М.: Издательская группа Точка, 2019.-320 с.

Подробнее..

Категории: Инженерные системы , Искусственный интеллект , Data science , Big data , Data engineering , Artificial intelligence , Industry 4.0 , Блог компании accenture , Industrial , Блог аксенчер

Внедрять или не внедрять

02.03.2021 18:23:53 |

Автор: admin

Привет, Хабр!

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

Март 2020. Китай. Пандемия. Covid-19. Локдаун. Удаленка. Маски. Остановка авиасообщения. И другие знакомые всем хэштеги, которые теперь ассоциируются с 2020 годом. Проект уже в активной фазе внедрения, клиент настроен решительно, да и мы тоже не готовы отступать. Надо адаптироваться к таким условиям, причем быстро. Паники нет. Но есть вопросы, много вопросов. Насколько долго это продлится? Какие риски у запуска? Хватит ли нам виртуальной коммуникации? Как запускаться удаленно? Эти вопросы волновали нас на протяжении всего проекта. Как Клиент и наша команда через это проходили, чему научились, и какой осадок остался обо всём об этом далее в статье.

Наталья, руководитель проекта со стороны Клиента
Проекты такого масштаба для большинства участников нашей команды это новый опыт. Меняется не только программный продукт для подготовки отчетностей по МСФО, кардинально меняется весь процесс подготовки отчетности, мы выходим на новый уровень автоматизации. Бесшовная интеграция с ERP-системой, использование единых справочников, автоматизация процесса выверки внутригрупповых оборотов, прозрачность данных и другие плюшки нового модуля консолидации смотрят на нас со страниц презентаций нашего интегратора. Ощущения такие, как будто нас пересаживают с нашего ретро-автомобиля в какой-то навороченный летательный аппарат, где все красиво и блестит, и много-много кнопочек, но, как всем этим пользоваться, непонятно. А дата запуска уже определена и переносу не подлежит! Команда со стороны интегратора рассказывает про ACDOCA, BPF и других незнакомых нам зверей, мы сидим, хлопаем глазами и понимаем, что нам нужны: а) переводчики, иначе мы так и не поймем коллег, б) дополнительные руки для написания инструкции по эксплуатации методологии для нашего космического консолидационного модуля.
Наша команда это специалисты по подготовке отчетностей по МСФО, которые работают на предприятиях Холдинга в разных регионах России и мира. Поэтому коммуникация при подготовке отчетностей или прохождении аудита через различные средства связи телефон, е-мейл, skype и т.д. для нас привычное дело. А жесткие дедлайны, многозадачность и большой объемом работ это наш конек!
Для подготовки отчетностей нам не нужны ежедневные личные встречи, 90% требуемой информации мы получаем посредством виртуальной коммуникации с коллегами. Поэтому введение режима самоизоляции мы встретили даже с воодушевлением: не нужно тратить время на дорогу в офис, можно встать на 2 часа позже, налить чашечку кофе, включить компьютер, и ты на работе!
Несмотря на такую, казалось бы, основательную подготовку к удаленке, проблемы и сложности все равно возникали. Работа из дома казалась более эффективной, так как не должно быть отвлекающих факторов, которые присутствуют в большом опен-спейс. Но мы не учли, что детей и супругов также изолируют, и нам придется делить пространство квартиры на учебный класс и рабочие кабинеты. Удаленный формат стер все границы между личной жизнью и работой, превратившись в День сурка, 24 на 7. Мы не учли, что живое общение с коллегами и друзьями дарили нам положительные эмоции, которых стало не хватать в изоляции, в связи с чем моральный дух падал. Были перебои с электричеством, проблемы с качеством интернета, не работали ссылки для подключения к собраниям, мяукали коты и гавкали собаки, дети хотели внимания, неожиданно включался микрофон и т.д. Это был непростой, но вместе с тем интересный этап в нашем проекте адаптация в новой системе и адаптация в новых условиях удаленной работы. Наш модуль взлетел строго по расписанию, но нам есть еще надо чем работать, что улучшать в системе, чтобы дальнейший полет был приятным и комфортным.
Кожевникова Наталья

Наталья, руководитель проекта со стороны команды Внедрения
На курсах по управлению проектами не рассматривают, как поступать в подобных условиях, это не имеет ничего общего с управлением команды, которая находится в разных уголках земли, это скорее управление в условиях кризисной ситуации, где можно полагаться только на свой опыт, обратную связь от команды, клиента и собственную интуицию. Мы начали внедрение с большой белой красивой доски в офисе, куда стали клеить стикеры и помечать задачи, которые необходимо сделать, ответственных, плановые даты исполнения задач. Все шло неплохо, ежеутренние стендапы, в рамках которых листочки передвигались из одного столбца в другой. Дальше настал день х, когда необходимо было решить переводить ли всех на удаленную работу или оставить часть команды в офисе. Я не боюсь удаленной работы, наоборот даже, не надо тратить время на дорогу, особенно для того, кто далеко живет, если что-то срочное, всегда можно созвониться и быстро решить вопрос, стендапы позволяют отследить, где мы находимся. Единственное, что сложно оценить, это моральный дух команды, удаленно его только по ноткам в голосе можно уловить. Было решено: удаленная работа, для тех, кто хочет, и нет условий работать дома, может приезжать в офис. Буквально за ночь были перенесены все стикеры в электронный вид- smartsheet. Немного времени на адаптацию, и все привыкли. С командой мы были готовы к такой работе. С увеличением числа заболевших также начало расти нервное напряжение у команды, т.к мы подходили к самым активным блокам работ- тестирование и обучение в июне-июле, мотивировала возможность отдохнуть осенью (график с сайта www.bbc.com/russian/features-54699497).

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

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

Пройти тестирование и обучение пользователей системы оказалось проще, чем пережить этап разработки. День сурка. Спасали только статусы у того самого Канбана, бережное отношение друг к другу и, конечно же, желание пройти это как можно скорее. Переработки никуда не делись, просто потерь (которые на самом деле очень нужны в нормальной жизни) стало минимум, когда задачи горят. Работы без пауз.
В какой-то момент команда не выдержала и вышла в офис, когда ослабили запреты. Всё в соответствии с законом! Но через 2 недели ушла. Почему? Наверное, потому что привыкли, и здесь есть некоторая критическая масса, которую нужно наполнить людьми из проекта, чтобы все остались работать в офисе.
Ющенко Андрей

Дарья, аналитик проекта со стороны команды Внедрения
В компанию я попала совсем перед началом лок дауна. Пришла на стажировку. Воодушевилась работе в красивом офисе, полном интересных людей, и была настроена быстро учиться. Но через пару недель я оказалась дома с ноутбуком, с отсутствием хоть каких-то знаний о проекте и требованием быстро вливаться в работу
Было сложно почти сразу лишиться живого взаимодействия с коллегами. Особенно с учетом того, что, зачастую, возникали глупые вопросы, которые гораздо проще показать на пальцах. Но мне безумно повезло с моей командой! Несмотря на непривычные для всех нас условия, меня окружили поддержкой и помощью. Благодаря тому, что меня не бросили на волю случая, я с ощутимой скоростью начала включаться в проект и вскоре стала частью этой замечательной команды. Дни пролетали незаметно, наполненные интересными задачами, которые позволяли мне получать новые знания. Иногда бывало, что садишься утром за компьютер, через какое-то время отрываешь от него глаза а уже темно.
Но у любой ситуации есть свои плюсы. На проекте я впервые столкнулась с тем, что нужно понимать бизнес клиента и взаимодействовать с ним, проводить встречи/обучение. С моим техническим мышлением и отсутствием опыта было сложно понимать бизнес язык, да и людей я боялась. В этом плане онлайн формат помог обучаться этой специфике работы более плавно. Есть еще причина, по которой, отчасти, я даже благодарна удаленке: несмотря на написание диплома в последние месяцы обучения в университете, удавалось максимально полно погружаться в работу. А чем больше вкладываешь, тем больше опыта получаешь, особенно на старте профессии.
Каторгина Дарья

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

Подробнее..

Категории: Управление проектами , Удаленная работа , Внедрение , Блог компании accenture , Удаленка vs офис

Моделирование и визуализация при анализе и проектировании ИТ систем. И не только

16.03.2021 12:09:05 |

Автор: admin

Проблема

Нет, это не про визуализацию желаний и совсем не про психологию.

IT специалисты применяют моделирование и визуализацию, чтобы упростить анализ объектов. Объекты могут быть разными: корпорации, бизнес-процессы, требования клиентов или информационные системы любых размеров.

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

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

Современные исследования (например Picture or Text First? Explaining Sequence Effects when Learning with Pictures and Text K. Scheiter и A. Eitel) подтверждают, если дополнять текстовую информации ее визуальной версией её будет проще понимать и запоминать.

Что такое визуализация и моделирование

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

Модель упрощенное представление реальности, созданное для передачи информации определенной аудитории для поддержки анализа, коммуникации и понимания (BABOK 3.0).

Модель представление системы, процесса, услуги или другой сущности, которое используется для понимания и прогнозирования их поведения и взаимодействий (ITIL 4).

У меня было три повода писать это:

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

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

Кому и почему полезна статья:

Кому	Почему
Аналитикам	Новички: поймут, что изучить, чтобы повысить свою релевантность в желаемой области, а не тратить драгоценное время на то, что потом окажется неприменимым. Опытные: пополнят свой инструментарий, основываясь на практике других аналитиков.
HR	Повысят качество и релевантность вакансий. В вакансиях больше не будет требований к навыкам, которые не используются.
Тем, кто хочет работать в IT или смежной сфере	Поймут, чем отличаются модели между собой, какие изучать сначала, а какие потом.

Как собирались данные и проводилось исследование

Данные собирались 2 месяца, в опросе участвовали 193 человека. Большая часть участников - аналитики. Подробный состав будет описан внутри. Опрос проводился среди коллег в различных тематических группах ТГ, ФБ.

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

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

Основная часть

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

Изложение в виде изображений:

+ Проще читать и понимать текст.

+ Делает текст менее монотонным;

+ Информация становится привычнее для мозга. Вместо сложных смыслов - простые визуальные объекты;

+ Может отражать связи и тренды, которые сложно уловить через текст или числа;

+ Создает единое информационное поле и контекст внутри него с разными уровнями абстракции;

+ Это просто красиво;

Может терять часть передаваемой информации и излишне упрощать;

Часто зависит от собственного контекста, того, кто создает модель или визуализацию;

Для некоторых нотаций и моделей нужны специальные знания.

Вот, что Карл Вигерс пишет в части Навыки, необходимые аналитику (книга Разработка требований к программному обеспечению):

Аналитик должен уметь работать с разнообразными средствами, начиная с древних блок-схем и структурированных моделей анализа (диаграммы потоков информации, диаграммы сущность-связь и т.д.) и заканчивая современным языком UML (Unified Modeling Language, унифицированный язык моделирования). Некоторые из этих средств полезны при общении с пользователями, другие с разработчиками

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

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

Cвод знаний по бизнес-анализу (BABOK) среди техник для анализа выделяет: моделирование понятий, данных, требований, решений, скоупа, процессов, состояний и организационное моделирование. Как инструменты предлагается использовать богатый зоопарк различных нотаций.

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

Об этом статистик Джордж Бокс сказал: В сущности, все модели неверны, но некоторые полезны.

Результаты опроса

Роли участников в команде

Опрос размещался по большей части среди аналитиков. Поэтому основная масса из 193 участников - системные аналитики и бизнес аналитики (кстати о том, как я их различаю можно почитать ЗДЕСЬ).

Как часто они используют модели

На этой таблице можно увидеть, насколько часто участники используют визуализацию и модели. Очевидно, что такой навык является почти всегда обязательным. Он важен для системного или бизнес-аналитика, руководителя ИТ проекта или ИТ архитектора. Более 90% специалистов используют визуализацию и моделирование ежедневно или часто.

Данные подтверждают сказанное ранее - моделирование - это навык, который используется часто. В опросе был ответ Никогда не использую, он получил 0 ответов.

В каких областях работают

В опросе можно было выбрать несколько областей специализации.

Участники опроса чаще занимаются финтехом, проектами в государственном секторе, внедрением коробок. Есть даже счастливчики (на мой взгляд), которые разрабатывают беспилотники.

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

Какими диаграммами и моделями пользуются

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

! Важно. Обратите внимание, что BPMN указан в двух вариантах - полной (аналитическая или исполнимая) и упрощенной версии (описательная).

Где моделируют и рисуют

С полученной информацией каждый поступит по-своему. Лично для меня очевидно следующее:

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

Подробнее..

Категории: Управление проектами , Анализ и проектирование систем , Карьера в it-индустрии , Блог компании accenture , Визуализация , Моделирование систем , Bpmn 2.0

Цифровая логистика решение транспортной задачи спроса и предложения с помощью библиотеки DOcplex от IBM

11.12.2020 18:19:05 |

Автор: admin

Всем привет, меня зовут Дмитрий Кузин (Application Development Senior Analyst в Accenture), и в своей статье я делюсь историей о том, как запрос на решение задачи в корпоративной рассылке привел к освоению Python библиотеки DOcplex от IBM, предназначенной для решения оптимизационных задач.

Я бы хотел поделиться личным опытом решения транспортной задачи с применением Python-библиотеки DOcplex от IBM. Если вкратце, то это задача про то, как с наименьшими затратами доставить продукцию или товары от производителей к покупателям, учитывая предложение первых и спрос вторых. В статье я дам основные определения транспортной задачи, покажу, как правильно сформулировать её условие, а также приведу пример решения на Python.

На Хабре есть несколько публикаций по решению транспортной задачи [1, 2]. Однако, их недостатком является то, что они не рыночные, так как учитывают только одну сторону рынка предложение. На рынке кроме предложения существует спрос, который является не менее важным самостоятельным фактором. Поэтому есть основания рассмотреть решение транспортной задачи, учитывающей и спрос и предложение.

Что же за транспортная задача, и как её решать?

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

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

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

Итак, условие задачи

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

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

Предположим, что все поставщики действуют рационально. Также примем, что если один из них может повысить свою прибыль, понизив цену и забрав долю рынка у конкурентов, то он непременно сделает это. Цена, по которой можно продать продукт в порту, составляет 50 долларов за тонну. Покупателями продукта на внутреннем рынке являются крупные промышленные компании. При этом потребности покупателей неэластичны по цене в диапазоне до 100 долларов за тонну продукта, а при большей цене покупатели откажутся от покупки.

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

Задача заключается в том, чтобы определить, кто, у кого и по каким ценам будет покупать продукт после того, как рынок придет в состояние равновесия, т.е. когда ни у кого из производителей не будет мотивации менять цены или объемы поставок.

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

Также, для упрощения восприятия условий задачи, сформируем их в виде трёх таблиц.

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

Математическая модель задачи линейного программирования состоит из трёх основных элементов.

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

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

$$display$$Z=_i^n_j^m(y_ij-k_ij )x_ijh_ij+_i^n(d-z_i )p_i,$$display$$

где
$inline$ цена за тонну продукта $inline$ -го производителя $inline$ -му покупателю;
$inline$ количество тонн продукта, поставленного от $inline$ -го производителя $inline$ -му покупателю;
$inline$ затраты на ж.д. перевозку и производство продукта от $inline$ -го производителя $inline$ -му покупателю;
$inline$ есть или нет (1-есть, 0-нету) поставка продукта от $inline$ -го производителя $inline$ -му покупателю;
$inline$ количество тонн продукта, поставленного от $inline$ -го производителя в порт;
$inline$ фиксированная цена на продажу продукта в порту;
$inline$ затраты на ж.д. перевозку и производство 1-ой тонны продукта от $inline$ -го производителя в порт;
$inline$ количество производителей;
$inline$ количество покупателей.

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

Первое ограничение. Каждый производитель не может суммарно поставить покупателям или в порт количество продуктов больше, чем он сам производит.
- для 1-го производителя: $inline$
- для 2-го производителя: $inline$
- для 3-го производителя: $inline$
Второе ограничение. Покупатели приобретают ровно то количество продуктов, которое им требуется в месяц.
- для 1-го покупателя: $inline$
- для 2-го покупателя: $inline$
- для 3-го покупателя: $inline$
- для 4-го покупателя: $inline$
Третье ограничение. Для каждого покупателя цена не может превышать 100 USD.
- для каждого покупателя: $inline$
Четвёртое ограничение. Количество поставляемого продукта для любого покупателя не может быть отрицательным.
- $inline$

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

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

$display$

Наименее выгодная цена для производителей при поставке покупателям

$display$

Теперь, когда задача записана математически, можно приступить к реализации решения. Для решения этой задачи я выбрал Python библиотеку от IBM DOcplex (Decision Optimization CPLEX).

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

Моё решение задачи началось с поиска имеющихся готовых инструментов для решения задач линейного программирования. В итоге по душе мне пришёлся довольно мощный программный продукт от IBM под названием IBM ILOG CPLEX Optimization Studio. Он включает в себя среду разработки и решения различных оптимизационных задач, в том числе задач линейного программирования. Содержит хорошую документацию и, самое главное, множество разнообразных примеров решения типовых оптимизационных задач. Также в комплект программного продукта IBM ILOG CPLEX Optimization Studio входит Python библиотека DOcplex и примеры её использования в Jupyter Notebook. Ниже рассмотрим ход моего решения задачи в Jupyter Notebook.

Ход решения в Jupyter Notebook

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

import pandas as pdimport docplex.mp as dpximport matplotlib.pyplot as pltimport numpy as npimport seaborn as snsimport networkx as nximport warningswarnings.filterwarnings('ignore')boldText = '\033[1m'

Далее, задаём исходные данные условия задачи из таблиц 1-3.

1. Исходные данные

# Данные по поставщикамNProds = 3            #Количество производителейNBuyers = 4           #Количество покупателейd = 50                  #Константная цена товара в ПортуBuyersMaxPrice = 100    #максимальная цена# ПроизводителиProdIndex=[]for i in range(NProds):    ProdIndex.append('P'+ str(i+1))ProdData = {'Possibilities': [890,534,1153],            'SupplyPort': [18,13,18],            'ProdCost': [12,21,10],            'PortPrice': [d,d,d],            'Overhead': [18+12,13+21,18+10]            }Producers = pd.DataFrame(ProdData, ProdIndex)# ПокупателиBuyIndex = ['B1','B2','B3','B4']BuyData = {'Scenario1': [78,121,94,85], 'Scenario2': [117,670,193,279]}Buyers = pd.DataFrame(BuyData, BuyIndex)#выбор сценарияScenario = Buyers.columns[0] # 0 - Scenario1                             # 1 - Scenario2print(Scenario)# Тарифы на железнодорожные перевозкиRailData = {'P1':[14,23,21,42], 'P2':[26,10,19,36], 'P3':[15,38,18,15]}RailFares = pd.DataFrame(RailData, BuyIndex)totCost = RailFares + Producers['ProdCost']

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

minCostProd = np.zeros((NProds, NBuyers)).astype(int)for j in range(NBuyers):    min_idx = np.argmin(totCost.values[j,:])    minCostProd[min_idx, j] = totCost.values[j,min_idx]minCostProd = pd.DataFrame(data=minCostProd, index=totCost.columns, columns=totCost.index)# Тарифы на жд перевозки от i-го производителя j-му покупателю + себестоимость производства i-го производителяk = np.zeros((NProds, NBuyers)).astype(int)i=0j=0for prod, pcost in zip(RailFares, Producers['ProdCost']): # перебор по Producers    j=0    for rfares in RailFares[prod]:        k[i,j] = rfares + pcost        j+=1    i+=1

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

# Тарифы на жд перевозки в порт + себестоимость производства i-го производителя z = np.empty(NProds).astype(int)i=0for SupplyPort, ProdCost in zip(Producers['SupplyPort'], Producers['ProdCost']):    z[i] = SupplyPort + ProdCost    i+=1

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

#Наименее выгодная цена для производителей при поставке покупателямProdBestPrices = np.zeros((NProds, NBuyers)).astype(int)for j in range(NBuyers):    i=0    for portPrice, supplyPort, supplyProd in zip(Producers['PortPrice'], Producers['SupplyPort'], k[:,j]):#       print(portPrice, supplyPort, supplyProd)        ProdBestPrices[i,j] = portPrice-supplyPort+1+supplyProd        i+=1

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

#Матрица спроса покупателейh = np.zeros((NProds, NBuyers)).astype(int)for j in range(NBuyers):    min_idxs = np.argmin(ProdBestPrices[:,j])    h[min_idxs, j] = 1

Далее импортируем из библиотеки docplex модель Model, являющуюся вычислительным ядром нашей оптимизационной задачи.

2. Модель

from docplex.mp.model import Modelmdl = dpx.model.Model("ChemProd")

Зададим искомые переменные задачи и сформулированные выше ограничения.

# матрица решений, показывающая количество тонн продукта поставленное от i-го производителя j-му покупателю# столбец-производитель; строка-покупательx = mdl.integer_var_matrix(NProds, NBuyers, name=lambda ij: "ProdVol_to_Buyer%d_%d" %(ij[0], ij[1]))# матрица решений, показывающая цену за тонну продукта i-го производителя j-му покупателю# столбец-производитель; строка-покупательy = mdl.integer_var_matrix(NProds, NBuyers, name=lambda ij: "ProdPrice_to_Buyer%d_%d" %(ij[0], ij[1]))# вектор решений - количество продукта перевнзённое в портp = mdl.integer_var_list(NProds, name='ProdVol_to_port')

3. Ограничения модели

1. Ограничения по количеству тонн производимого продукта для производителей

# 1. Ограничения по количеству тонн производимого продукта для производителейfor i, possib, cts_name in zip(range(NProds), Producers['Possibilities'], Producers['Possibilities'].index):    mdl.add_constraint(mdl.sum(x[i,j] for j in range(NBuyers)) + p[i] <= possib, ctname='Possib'+cts_name)

2. Ограничения по потребностям покупателей

# 2. Ограничения по потребностям покупателейfor j, req, buyer in zip(range(NBuyers), Buyers[Scenario], Buyers[Scenario].index):    mdl.add_constraint(mdl.sum(x[i,j] for i in range(NProds)) == req,  ctname=buyer+'Need')

3. Ограничения по цене продукта

# 3. Ограничения по цене продуктаfor i in range(NProds):    for j in range(NBuyers):        #mdl.add_constraints( [y[i,j] <= BuyersMaxPrice, y[i,j] >= 0], ['BuyersMaxPrice', 'BuyersMinPrice'])        mdl.add_constraint( y[i,j] == ProdBestPrices[i,j], 'ProdBestPrices')

Для данной задачи четвёртое ограничение о неотрицательности переменных выполняется исходя из первых 3х ограничений.

Теперь, когда ограничения нашей модели созданы, сформируем нашу целевую функцию и зададим её максимизацию.

#Доставка покупателямSalesBuyers = mdl.sum( (y[i,j]-k[i,j] )*x[i,j]*h[i,j] for i in range(NProds) for j in range(NBuyers) ) #Доставка в портSalesPort = mdl.sum( (d-z[i])*p[i] for i in range(NProds) )#Целевая функцияmdl.maximize(SalesBuyers + SalesPort)

4. Решение модели

%%timeassert mdl.solve(), "!!! Solve of the model fails"prodsVol = np.zeros((NProds, NBuyers)).astype(int)prodsPrice = np.zeros((NProds, NBuyers)).astype(int)VolPrice = np.zeros((NProds, NBuyers)).astype(int)VolPricePort = np.zeros((NProds, 1)).astype(int)for i in range(NProds):    #VolPricePort[i] = int((d - z[i])*p[i].solution_value)    VolPricePort[i] = int(p[i].solution_value*d)    for j in range(NBuyers):        prodsVol[i,j] = x[i,j].solution_value        prodsPrice[i,j] = y[i,j].solution_value        #VolPrice[i,j] = (y[i,j].solution_value - k[i,j])*x[i,j].solution_value        VolPrice[i,j] = y[i,j].solution_value*x[i,j].solution_value#Количество тонн продукта от i-го производителя j-му покупателюVolData = dict(zip(ProdIndex, prodsVol))DecisionVol = pd.DataFrame(VolData, BuyIndex)#Количество тонн продукта от i-го производителя в портVolPricePortData = dict(zip(ProdIndex, (VolPricePort)))DecisionVolPort = pd.DataFrame(VolPricePortData, index=['Pt'])#Цена за тонну продукта i-го производителя j-му покупателюPriceData = dict(zip(ProdIndex, prodsPrice))DecisionPrice = pd.DataFrame(PriceData, BuyIndex)#Объём продаж i-го производителя j-му покупателю за вычетом затрат на доставку товараVolPriceData = dict(zip(ProdIndex, VolPrice))DecisionVolPrice = pd.DataFrame(VolPriceData, BuyIndex)

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

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

G = nx.Graph()#Морской портfor p in ProdIndex:    G.add_edge(p, 'Pt', w=DecisionVolPort[p]['Pt'])    #Продавцы / покупателиfor b in BuyIndex:    for p in ProdIndex:        G.add_edge(p, b, w=DecisionVolPrice[p][b])nodeKeys = []nodePos = []num_buy = 0num_prod = 0for p in ProdIndex:        x_prod = int(-NProds/2)+num_prod        num_prod+=1        nodeKeys.append(p)        nodeKeys.append('Pt')                nodePos.append([x_prod,1])        nodePos.append([0,2])        for b in BuyIndex:    num_prod = 0    x_buy = int(-NBuyers/2)+num_buy    num_buy+=1    for p in ProdIndex:        x_prod = int(-NProds/2)+num_prod        num_prod+=1        nodeKeys.append(p)        nodeKeys.append(b)                nodePos.append([x_prod,1])        nodePos.append([x_buy+0.5,0])               pos = dict(zip(nodeKeys, nodePos))            elarge = [(u, v) for (u, v, d) in G.edges(data=True) if d['w'] > 0]esmall = [(u, v) for (u, v, d) in G.edges(data=True) if d['w'] == 0]plt.figure(figsize=(16, 8))plt.subplot(1,2,1)nx.draw_networkx_nodes(G, pos=pos, node_size=7000/((NProds+NBuyers)/2))nx.draw_networkx_edges(G, pos=pos, edgelist=elarge, width=2, edge_color='black')nx.draw_networkx_edges(G, pos=pos, edgelist=esmall, width=2, alpha=0.3, edge_color='gray', style='dashed')edge_values = []for (u, v, d) in G.edges(data=True):    if d['w']>0:        edge_values.append(int(d['w']))        labels = dict(zip(elarge, edge_values))nx.draw_networkx_edge_labels(G, pos=pos, edge_labels=labels, font_size=12, font_color='black')# labelsnx.draw_networkx_labels(G, pos=pos, font_size=70/((NProds+NBuyers)/2), font_color='white')plt.axis('off')plt.subplot(1,2,2)plt.grid(True)sns.barplot(x=DecisionVolPrice.columns,            y=sumBuyPort,            palette="deep").set_title('Суммарный объём продаж')plt.show()

После выполнения скрипта на экране сформируется граф нашего моделируемого виртуального рынка согласно результатам решения задачи. На рёбрах графа отображено произведение количества поставляемых продуктов на их цену, а в вершинах графа расположены участники рынка: Pt морской порт; P1-P3 производители; B1-B4 покупатели.

Заключение.

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

Ссылки на источники.

1. Решение закрытой транспортной задачи с дополнительными условиями средствами Python;
2. Решение задач линейного программирования с использованием Python;
3. Дыбская В.В., Зайцев Е.И., Сергеев В.И., Стерлигова А.Н. MBA Логистика. М.: Эксмо, 2009;
4. Avinash K. Dixit, Barry J. Nalebuff The Art of Strategy: A Game Theorist's Guide to Success in Business and Life.

Подробнее..

Категории: Алгоритмы , Оптимизация , It-компании , Транспорт , Транспортная задача , Теория игр , Блог компании accenture , Логистика , Симплекс-метод , Оптимизационные задачи

Масштабный проект по внедрению SAP S4HANA в удаленном режиме уроки, которые мы усвоили

29.04.2021 20:16:38 |

Автор: admin

Вводная часть

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

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

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

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

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

Основная цель безлюдное производство, цифровой завод. Первый шаг навстречу цели - внедрение системы SAP S/4HANA с максимальным использованием стандарта.

Объем проекта

Внедряемые продукты SAP

SAP S/4HANA
SAP Fiori LaunchPad (Цифровое окно)
SAP HCM
SAP BPC
SAP MII
SAP PO

Автоматизируемые процессы

Бюджетирование
Финансы
Снабжение и Сбыт
Производство и ремонты
Управление персоналом
Единое цифровое окно

Особенности работы в удаленном режиме

Обучение ключевых пользователей

Передача знаний на расстоянии

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

По ходу проведения тренингов мы определили несколько хороших практик по организации и проведению дистанционного обучения по работе в SAP. Их можно объединить в следующие блоки:

Подготовка тренинга:

Для дистанционного обучения мы использовали инструмент MS Teams, который является аналогом нашумевшего ZOOM, но более корпоративный. Данный инструмент позволяет сделать видеозапись звонка, которую пользователи также в дальнейшем смогут использовать для повторения пройденного материала.
Для ответов на контрольные вопросы и сбор обратной связи мы использовали MS FORMS. Очень удобный инструмент, который позволяет пользователям сразу увидеть свою оценку и экономит время тренеров на проверку. С его помощью можно создать тест, и даже выгрузить его результаты в формате Excel, что позволяет с легкостью отслеживать статистику и делать сводные таблицы. Плюс - ограничений по количеству форм (тестов) нет.
Сформировали группы на обучение в размере не более 10 человек. И соответственно рассчитали время тренингов. В случае увеличения численности группы время тренинга увеличивалось.
На каждый тренинг был назначен 1 основной тренер и 1 помощник, который в процессе тренинга направлял в чат тренинга необходимые ссылки и названия транзакций.
Лучше заранее проверить Интернет-связь, как на стороне тренеров, так и на стороне пользователей, чтобы не было рассинхронизации голоса и трансляции экрана.

Организация рабочего пространства пользователей:

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

Чтобы пользователям было удобнее смотреть на экран тренера, где демонстрируется работа в системе, и одновременно выполнять действия в системе, желательно каждому пользователю установить 2 монитора или 1 большой монитор, где можно открыть два окна параллельно.
Нужно заранее установить все необходимые для обучения программы на компьютеры пользователей, выполнить в них первоначальных вход и запомнить свои учетные данные. Мы столкнулись с тем, что у некоторых пользователей ПО установлено просто не было, в связи с этим было затрачено много времени, на его установку и на решение этой проблемы. Это поможет значительно сэкономить время во время тренинга на осуществление первого входа.

Организация учебного процесса:

Хорошей практикой стало включение камеры в начале тренинга для приветствия участников и объяснения целей встречи. Так пользователи и тренеры стали узнавать друг друга не только по голосам, но и в лицо.
С целью экономии времени пользователи выполняли шаги в системе одновременно с тренером. В случае возникновения проблем пользователь делился своим экраном, и тренер подсказывал, какие шаги необходимо выполнить, чтобы решить проблему пользователя. Это также помогает сделать тренинг более интерактивным. В течение тренинга каждый пользователь может поделиться своим экраном и показать свой прогресс.
Пользователям удобнее, если тренер не просто показывает на своем экране, а присылает в чат встречи название изучаемой транзакций и данные для выполнения упражнения (например, название материалов или номер договора для каждого пользователя).
Так как у нас на обучении была взрослая аудитория, то эффективно удерживать внимание получалось примерно в течение 1 1,5 часов. Далее требовалось сделать перерыв на 10-15 минут. Это необходимо учитывать при планировании времени тренинга. Максимальная продолжительность тренинга в течение дня для одной группы обучающихся без потери качества обучения 4 часа.
Должно быть четкое управление временем тренинга. Необходимо вовремя начинать и вовремя заканчивать тренинг, т.к. помимо тренинга у пользователей запланирована операционная работа. Если не уложились в отведенное время, то необходимо уточнить у пользователей, могут ли они задержаться, и если нет, то назначить дополнительное время в другой день для завершения тренинга. Так мы избежим накала страстей.
Очень полезно в начале тренинга обозначить цели тренинга, а в конце - сделать резюме того, что прошли. Если тренинг разбит на два дня, то второй день начинаем с резюме первого дня. Чтобы на фоне операционной работы к пользователям вернулись приятные воспоминания вчерашнего тренинга и появилось приятное осознание, сколько уже было пройдено.

Лайфхаки, или наши полученные уроки:

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

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

Тестирование функционала системы

Как протестировать функционал системы в удаленном режиме на предприятии, которое еще в процессе строительства?

Для ответа на данный вопрос разберемся, какая ставилась цель, и какие виды тестирования мы применяли на проекте.

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

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

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

Организация процесса тестирования:

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

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

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

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

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

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

Концепция раннего старта:

Реально ли внедрить систему так, чтобы какие-то отдельные её части запустились раньше, а какие-то позже? Да!

В ходе проекта было принято решение разбить старт проекта на 3 старта Ранний (Корпоративные функции), промежуточный (Планирование и Бюджетирование) и Основной (Производство, Ремонты, Цифровое окно). Концепция раннего старта подразумевает старт отдельных частей раньше, чем старт всей системы в целом. Такая концепция существенно облегчает миграцию, интеграцию, упрощает склейку отчетности HR и Бухгалтерии в начале финансового года, позволяет сфокусироваться на задачах Корпоративных функций до их стабилизации, а потом уже на Производстве и Ремонтах.

На проекте применялся классический подход Waterfall, который подразумевает мобилизацию, анализ и проектирование, реализацию, тестирование, поддержку после запуска.

Для отдельного направления Цифровое окно применялась методология Scrum.

Для управления развитием системы после раннего старта будет применяться Hybrid Agile.

В этой части мы рассмотрели основной объем проекта, процессы обучения и тестирования, и концепцию раннего старта, ждите следующую часть, будет интересно!

Подробнее..

Категории: Анализ и проектирование систем , Agile , Waterfall , Тестирование it-систем , Тестирование , Erp-системы , Обучение , Внедрение , Проектирование систем , Блог компании accenture

Масштабный проект по внедрению SAP S4HANA в удаленном режиме Гибридный интеграционный ландшафт

08.06.2021 10:08:20 |

Автор: admin

В предыдущей нашей статье мы рассказывали о том, какие уроки мы усвоили, как мы обучали коллег удаленно и как проводили тестирование системы. В данной статье речь пойдет об интеграционных ландшафтах. Для реализации решения в рамках нашего проекта мы выбрали гибридный интеграционный ландшафт на базе SAP PO и SAP MII. В данной статье мы рассмотрим особенности систем SAP PO и SAP MII, их предназначение, достоинства и недостатки. А также расскажем о трудностях, с которыми мы столкнулись при реализации проекта в 2020 году.

Итак, по порядку.

Интеграционные платформы: как выбрать?

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

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

Согласно SAP CIO Guide: Process and Data Integration in Hybrid Landscapes, существуют следующие классы интеграционных систем:

Process Integration охватывает интеграцию распределённого между системами/приложениями бизнес-процесса. Наиболее предпочтительные инструменты интеграции на базе ESB (Enterprise Service Bus)

Data Integration охватывает синхронизацию данных между приложениями, базами данных и озером данных вне транзакционного контекста. Наиболее предпочтительные инструменты интеграции на базе ETL (Extract, Transform, Load).

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

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

Cross Use Cases остальные сценарии, применяемые для сквозного взаимодействия.

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

Опыт российской практики показывает, что компании в основном делают выбор в пользу таких интеграционных систем, как SAP PO (ранее SAP PI). Однако существуют и другие системы, которые также предназначены для интеграции между системами различных уровней. В нашем случае мы использовали интеграционные системы SAP PO и SAP MII.

Ключевые аспекты использования SAP PO и SAP MII

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

1. SAP PO следует использовать для интеграции процессов в качестве основной Корпоративной сервисной шины (ESB) предприятия (Например, ERP с Банк-клиентом), а также когда требуется:

Использовать репозиторий корпоративных сервисов в качестве центрального репозитория SOA

Использовать поддержку дополнительных стандартов WS (web service), таких как UDDI, WS-BPEL, и задач, WS-RM в корпоративной среде.

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

Использование новых функций, таких как аутентификация конечных пользователей, валидация XML и возможности BAM

Взаимодействие с системами, находящимися за рамками DMZ корпоративной сети.

2. SAP MII следует использовать в основном, когда стоит задача обрабатывать данные уровня заводов (MES, LIMS), которые представлены в разнородных хранилищах, которые требуется организовать и проанализировать, а также, когда нужно:

Получать согласованные отчеты о производственных операциях на разных сайтах.

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

Подключить собственные производственные приложения к данным и рабочим процессам SAP S/4HANA - через стандартные и встроенные адаптеры и инструменты (BAPI/RFC синхронный запрос).

Позволить персоналу предприятия выполнять отчетность (стандартную, мобильную и специальную) наряду с базовыми задачами.

Следует отметить, что система SAP MII по своему прямому назначению, помимо выполнения функции интеграционной шины, также дает возможность выполнять оперативные функции с использованием UI/UX-приложений и реализовать процессы по регистрации данных оперативного учета. Однако использование системы SAP MII только как платформы интеграции не дает никаких преимуществ по сравнению другими системами (например, SAP PO).

3. Наряду с отдельным использованием платформ SAP PO или SAP MII (рассматриваемых в данной статье) также нередки случаи совместного использования одновременно двух этих систем, а именно в тех ситуациях, когда:

SAP MII должен взаимодействовать c SAP S/4HANA (и другими системами корпоративного уровня) через SAP PO в интеграционных сценариях, требующих гарантированную доставку.

SAP PO должен использоваться для централизованного управления потоками данных.

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

В SAP MII должны быть реализованы правила и обработки, специфичные для уровня завода.

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

Преимущества и недостатки SAP PI

Несмотря на то, что верхнеуровнево и SAP PO, и SAP MII поддерживают схожие сценарии интеграции, обе системы разработаны с учетом конкретных сценариев использования.

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

Среди недостатков функционала обеих систем отмечены следующие:

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

Вызовы нашего проекта, и как мы с ними справились

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

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

В связи с этим мы пересмотрели весь рабочий процесс, а именно:

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

2. Перешли на scrum-методологию:

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

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

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

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

4. Мы сделали оптимизацию с учетом разных часовых поясов:

Приоритизировали и распределяли задачи в соответствии с часовым поясом членов команд

Планировали ключевые встречи с учетом разницы во времени

С пониманием относились к экстренным запросам во внерабочее время.

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

Пересмотренный подход позволил нам скоординировать работу команд и её в срок.

Выводы

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

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

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

Надеемся, наша статья поможет вам в поиске наилучшего для вас решения. Да пребудет с Вами Сила!

Подробнее..

Категории: Анализ и проектирование систем , Тестирование it-систем , Erp-системы , Интеграция , Sap , Платформы , Блог компании accenture , Шина

Алгоритм Jerdella решаем проблемы семантического безумия в IT-системах банков

14.10.2020 14:07:29 |

Автор: admin

Семантические проблемы в IT системах. Что бывает, когда много разных людей начинают творить

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

Ветхозаветную легенду можно с легкостью перенести на современные крупные компании, внедряющие современные ИТ-решения. В пример таких компаний, вне всякого сомнения, можно отнести современные российкие банки, которые имеют десятки, а то и сотни бизнес-подразделений, в которых складывается своя субкультура общения, построенная на своих правилах и уникальном стиле делового оборота. Естественно, при формировании ИТ-инфрастурктуры учитывается устоявшийся в коллективе стиль именования бизнес-сущностей. За последние десять лет появилось множество работ на эту тему, например эта [1]. Те, кто сталкивался с аналитикой информационных систем в банках знают, что такое сделать так называемый маппинг данных, особенно, если конечные системы делали разные команды аналитиков, разработчиков и заказчиков или вендоров. Как правило, на 60% составление маппинга является уяснением сути и семантики передаваемых данных.

Сейчас модной тенденцией является использования комплекса гибких методологий. Об Agile говорят все. Можно до хрипоты спорить, благо он для бизнеса или вред. Но одна вещь не вызовет ни у кого отторжения. В ходе Agile множество разных команд, как внутри банка, так и со стороны разных вендоров рождает множество ИТ-решений для бизнеса, и часто, не взаимодействуя друг с другом, команды рождают свою устоявшуюся терминологию. И в тот момент, когда интеграция все же происходит, случается та самая, описанная в Ветхом Завете ситуация. Чем она не напоминает вавилонский базар с его тысячами торговцев, лавок, товаров, юродивых, факиров и глотателей огня? И вот, все эти люди, вооруженные разными идеями и разными помыслами, начинают строить Башню.

Мы всегда на выходе спринта имеем набор XSD схем (или примеров JSON сообщений) с полями, которые нужно каким-то образом однозначно сопоставить друг другу. И не важно, где идут споры, может быть это набор экселевских таблиц с маппингами, может быть это сотни комментариев в Confluence, может быть это часы конференций в Zoom или Webex, но на наведение порядка в этом семантическом безумии тратится время и нервы, а самое главное деньги.

Конечно же, концепция использования ESB (единой сервисной интеграционной шины банка) и модель глобальных бизнес-объектов, которая используется, например в некоторых европейских банках, где является своеобразной лингва-франка между информационными системами, должны позволить уйти от данной ситуации. Но давайте будем честными, не все компании могут это себе позволить, да и не всем это надо. Ситуация в банковской сфере меняется столь стремительно, что многие заказчики начинают прибегать к концепции взаимодействующих платформ на основе микросервисов, посаженных на какой-нибудь брокер сообщений, типа Kafka. В итоге мы имеем не одну модель данных, а набор моделей данных, созданных под каждый сервис, зачастую отдельной командой. Взаимодействие в рамках данной платформы осуществляется не столь привычными банковским аналитикам XML сообщениями, основанными на использовании жестких XSD схем, разработанных в ходе проектирования командой аналитиков, юристов, представителей бизнеса на века, а более простой и наглядный JSON, пришедший в банковский бек из фронт-разработки вместе с разработчиками, решившими сменить фронт на бек. Не стоит, наверное, говорить, что JSON не может нести жесткую схему. Просто он удобнее для гибких методологий. Его можно поправить, добавив или убрав пару атрибутов. И нет в нем привязки к железобетонным XSD схемам, замешанным на использовании специфических правил записи. JSON проще редактировать и вносить в него изменения. К его изменению проще доступ.

И что мы имеем? Мы имеем набор входных на платформу сообщений, которые надо в соответствии с бизнес-сутью данных передать микросервисам. И вот тут возникает вопрос, а как это сделать побыстрее?

Маппинги данных. Говорим разными словами об одном и том же

В момент интеграции между несколькими ИТ-системами сталкиваются два аналитика. Один со стороны одной системы, другой со стороны соответственно второй системы. В качестве входных данных у них два файла MS Excel, которые нужно, как говорят у нас, смапить для реализации разработки адаптера. В этих файлах указаны атрибуты сообщения в одной колонке (как правило в форме JSON path), а в другой их семантическое описание. Такой документ называется маппингом. И вот тут начинается самое интересное. Кто сталкивался с маппингами, тот знает что в них могут находится такие описания:

номер счета физического лица

номер счета физика

20-значный номер счета физика

12-значный счет физического лица

номер отделения, в котором открыт счет физического лица

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

Вот если бы существовал такой алгоритм, реализованный простым скриптом, написанным на общедоступном языке программирования с огромным количеством удобных библиотек, которые можно легко установить из командной строки через PIP! Такой алгоритм бы подхватывал два файла с расширением xslx и создавал бы третий, в котором уже было бы проведено установление первичного соответствия. Да, вы правы, я о языке Python, который идеально подходит для решения рутинных задач аналитика.

И вот, мы пришли к задаче провести анализ текстовых данных методами языка Python. Наверное для анализа текстовых данных, есть специализированные библиотеки языка Python. Но, когда ты работаешь в банке и тонко чувствуешь его синергетику, возникает желание придать какую-то количественную и осмысленную оценку точности аналитики. Нужно это, в том числе, и для дальнейшего развития механизма автоматизации работы аналитика. Это непреодолимый соблазн для исследователя сопоставить рациональное число явлению или, в нашем случае, попаданию в семантическую суть. Как говорил Платон: Все есть число, весь мир есть число. Поэтому и возникла идея использовать для задания и визуализации точности оценки какой-нибудь из базовых виджетов библиотек PyQt или Tkinter. А для этого, необходимо дать соответствующую числовую характеристику. Тянешь ползунок на экране и регулируешь точность попадания в семантическую цель.
И так, у нас к каждому JSONpath в файле маппинга приложено краткое описание поля, написанное на русском языке кириллическими буквами. И вот тут возникла идея оценить семантическое соответствие, написанного в коментарии в одном файле и в другом, при помощи математического алгоритма, реализованного на языке Python. Да и не просто оценить, а оценить количественно.

На помощь спешит математика. Векторизация комментария в описании полей для JSON. Соединяем лингвистику и аналитическую геометрию

Суть метода состоит в следующем. Предлагается сопоставить каждому комментарию в экселевском файле с описанием полей вектор в 33-мерном евклидовом вещественном пространстве при ортонормированном базисе. Почему в 33 мерном? Да очень просто 33 это количество букв в русском алфавите. Назовем такое пространство Алфавитным. Что может быть проще. Кстати, метод векторизации текстовых данных известен давно и подробно описан в любом учебнике по машинному обучению, например, тут [2]. В получившемся пространстве мы формируем Декартову систему координат с числовыми осями. По каждой из таких осей пространства мы откладываем количество букв в высказывании. Вот тут необхоимо сформировать главную лемму для дальнейших рассуждений: любому высказыванию, выраженному в кириллических буквах, можно однозначно поставить в соответствие вектор в алфавитном 33-мерном евклидовом ортономированном пространстве. Числовыми координатами вектора по соответствующей оси будет количество соответствующей буквы в высказывании. А дальше следует проанализировать семантическое соответствие путем определения разницы между такими векторами по правилам аналитической геометрии. К примеру, алфавитное пространство ABC у нас будет выглядеть следующим образом:

$$display$$ABC=(x_А,x_Б,.....,x_Я),(1) $$display$$

где каждая координата x в соответствующей позиции это количество соответствующей буквы комментарии к полю в экселевском файле. Например, у нас есть комментарий Номер счета физического лица. Сопоставим для него вектор, выходящий из начала координат декартовой системы в алфавитном 33 мерном пространстве, выглядеть он будет следующим образом: координата X_А соответствует количеству букв а. И оно равно двум. X_Б в данном случае будет равно нулю, так как буквы б в данном высказывании нет. Тоже самое касается и x_В буква в отсутствует. А вот x_И будет равен 3, так как буква и в комментарии встречается три раза.

Рисунок 1. Проекция алфавитного вектора, соответствующего высказыванию Номер счета физического лица на плоскость букв АИ. Количество букв А= 2, количество букв И =3. Вектор в данной плоскости имеет две координаты по количеству букв x_A=2, x_б=3.

Таким образом, если мы строим вектор, берущий начало в нуле (начале координат) декартовой системы, то алфавитный 33-мерный вектор $\vec{S_1}$ соответствующий высказыванию Номер счета физического лица, у нас получится следующий:

$\vec{S_1}=(2;0;0;1;0;3;0;0;1;3;0;1;1;1;1;3;0;1;2;1;0;1;0;1;2;0;0;0;0;0;0;0;0)$

Теперь, допустим, у нас есть высказывание Номер счета физика (кто работал в банковской среде, то знает, как тут любят слова физик и юрик) и Номер счета клиента. Сопоставим им по данному правилу алфавитные вектора $\vec{S_2}$ и $\vec{S_3}$ соответственно:

$\vec{S_2}=2;0;0;0;0;2;0;0;1;2;0;1;0;1;1;1;0;1;1;1;0;1;0;0;1;0;0;0;0;0;0;0;0),$

$\vec{S_3}=2;0;0;0;0;3;0;0;0;1;0;1;1;1;2;1;0;1;1;2;0;0;0;0;1;0;0;0;0;0;0;0;0)$

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

$\vec{S_{1,2}}=(x_{А,1}-x_{А,2};x_{Б,1}-x_{Б,2};.....;x_{Я,1}-x_{Я,2}) , (2)$

где $x_{n,1}$ и $x_{n,2}$ соответствующие координаты вектора для оси, соответствующей букве.

Рисунок 2. Синим цветом показана разность между векторами $\vec{S}_{1,2}$ на плоскости букв А-И алфавитного пространства.

Таким образом, вектор, соответствующий разнице между высказываниями Номер счета физического лица и Номер счета физика будет выглядеть следующим образом:
$\vec{S_{1,2}}=(0;0;0;1;0;1;0;0;0;1;0;0;1;0;0;2;0;0;1;0;0;0;0;1;1;0;0;0;0;0;0;0;0)$ ,
вектор, соответствующий разнице между высказываниями Номер счета физического лица и Номер счета клиента будет выглядеть следующим образом:

$\bar{S_{1,3}}=(0;0;0;1;0;0;0;0;1;2;0;0;0;0;-1;2;0;0;1;-1;0;1;0;1;1;0;0;0;0;0;0;0;0)$

,
Далее, вычисляется длина полученных разностных векторов, по формуле:

$|\bar{S_{1,2}}|=\sqrt{({x_1}^2+{x_2}^2+...+{x_33}^2)},(3)$

Если произвести арифметический подсчет, то получится:

$S_{1,2}=3.32$

$S_{1,3}=4.00$

Это математически предполагает, что фраза Номер счета физического лица по своему смыслу ближе к Номер счета физика, чем к Номер счета юридического лица. На это указывают длины разностных векторов. Чем меньше длина, тем ближе по смыслу друг к другу высказывания. Если мы, например, возьмем и сравним высказывания Номер счета физического лица и номер отделения, в котором открыт счет физического лица, то получим цифру 6.63. Что будет указывать на то что, если первые два высказывания близки по смыслу с исходным (разница векторов 3.32 и 4.00 соответственно), то третье, очевидно, даже будет иметь отличную от него бизнес-суть, несмотря на, казалось бы, видимый одинаковый набор слов.

Можно пойти дальше и попробовать через векторизацию количественно оценить близость комментариев по смыслу. Для этого я предлагаю использовать проекции векторов друг на друга. После чего найти отношение между длинной проекции сравниваемого ветора на длину того, с которым сравнивают. Данное отношение всегда будет меньше, либо равно единице. И соотвественно, если высказывания идентичны друг другу, то проекция сольется с вектором, на который проекцию делают. Чем дальше сравниваемое высказывание будет по смыслу, тем меньше будет составлять проекция. Если его умножить на 100 %, то можно получить степень соответствия векторизованных высказываний в процентах. Таким образом, проекция вектора $\vec{{S_2}^\prime}$ сравниваемого высказывания $\vec{S_2}$ на вектор исходного высказывания $\vec{S_1}$ будет находиться по следующей формуле:

$\vec{S_2^\prime}=\frac{(\vec{S_1},\vec{S_2})}{\left|\vec{S_1}\right|}=\frac{x_{А1}x_{А1}+x_{Б1}x_{Б2}+...+x_{Я1}x_{Я2}}{{x_{А1}}^2+{x_{А1}}^2+....+{x_{Я1}^2}}, (5)$

Таким образом, степень соответствия $\delta$ будет рассчитываться по следующей формуле:

$\delta=\frac{\left|\bar{S_2^\prime}\right|}{\left|\bar{S_1}\right|}*100$$ = \frac{x_{11}x_{21}+x_{21}x_{22}+...+x_{n1}x_{n2}}{{x_{А1}}^2+{x_{Б1}}^2+....+{x_{Я1}^2}}*100 , (6)$

Рисунок 3. Иллюстрация проекции $S_2^\prime$ вектора $\vec{S_2}$ на вектор $\vec{S_1}$ .
Именно данный параметр предлагается брать за основу при определении семантического соответствия.

Реализация алгоритма на языке Python. Немного об абрикосе. Как задавать и обращаться с векторами

Алгоритм я назвал Jerdella. Ничего странного, просто я из Ростова-на-Дону.

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

Еще раз скажу, мне известно, что Python имеет множество библиотек, в том числе и для математической обработки. И есть библиотеки, разработанные специально для методов аналитической геометрии. Например, такой библиотекой является NumPy. Конечно же, ряд читателей зададут вопрос, почему я не использовал NumPy? Отвечаю, во первых я не считаю данную задачу сложной, тут простые вычисления, а во-вторых все же хотелось прочувствовать реализацию алгоритма и самому все разработанные самолично методы пощупать руками, чтобы потом нести за результаты полную ответственность. Есть еще одно обстоятельство, почему не NumPy. Это банковская безопасность. Всем известно, что находясь в сети банка, невозможно устанавливать и обновлять пакеты библиотек через PIP. Поэтому, наша Jerdella будет использовать стандартные пакеты, входящие в поставку PyCharm Community Edition для интерпретатора Python 3.

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

Как задать вектор?

Вектор я задавал следующей процедурой vector:

def vector(self,a):    vector=[]    abc = ["а", 'б', "в", "г", "д", "е", "ё", "ж", "з", "и", "й", "к", "л", "м", "н", "о", "п", "р", "с", "т",                "у", "ф", "х", "ц", "ч", "ш", "щ", "ъ", "ы", "ь", "э", "ю", "я"]    for char in abc:        count=a.count(char)        vector.append(count)    return(vector)

То есть, в цикле for по элементам заранее приготовленного списка abc, я пользовался стандартной операцией по поиску вложений в строку count. После чего, методом append заполнял новый список vector, который и будет являться вектором для дальнейших вычислений.

Как посчитать разницу векторов?

Для этого я создал процедуру delta, принимающую на вход два списка a и b.

def delta(self, a, b):    delta = []    for char1, char2 in zip(a, b):        d = char1 - char2        delta.append(d)    return (delta)

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

Как посчитать длину вектора и тем самым оценить разницу?

Для этого я создал процедуру len_delta, которая принимает на вход список, и путем итераций по каждому элементу данного списка (он же является координатой в алфавитном пространстве) по правилу нахождения модуля вектора рассчитывает длину вектора.

def len_delta(self, a):    len = 0    for d in a:        len += d * d    return round(math.sqrt(len), 2)

Как посчитать отношение проекции на вектор и тем самым оценить в процентах совпадение?

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

def simplify(self, a, b):    len1 = 0    len2 = 0    scalar = 0    for x in a: len1 += x * x    for y in b: len2 += y * y    for x, y in zip(a, b): scalar += x * y    if len1 > len2:        return (scalar / len1) * 100    else:        return (scalar / len2) * 100

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

Итак, дело было сделано, и Jerdella прекрасно отрабатывала и успешно формировала автоматически маппинги. Но при условии: 1) Когда количество полей, с одной и другой стороны, совпадало. 2) когда поля были описаны подробно в соответствии со своим бизнес-смыслом. Например, данный алгоритм показывал хорошие результаты при интеграции между CRM Siebel и ESB, на котором использовалась модель глобальных бизнес-объектов. В данном случае и со стороны одной системы, и со стороны другой вендоры с глубокой тщательностью, в соответствии с долговременными контрактами, прописывали бизнес-смысл. Было даже пару раз, когда формировали документ автоматически, и не глядя отдавали в разработку. И все получалось. Казалось бы, можно отправлять аналитиков, делающих маппинги, мести улицы

Но на проектах последних 2х лет, завязанных на Agile, с постоянной миграцией команд и кадров, интеграцией банковских платформ по схеме point-to-point, приносящих и уносящих новую семантику проектов, начались проблемы.
Часто спецификой таких проектов является параллельное написание документации. Аналитики не тратят время на глубокую проработку описания полей, а наскоро описывают их, делая упор на разработку схемы сообщения. Часто в описании поля указано 2-3 слова, дающее составление вектора, жестко направленного по ограниченному числу осей в алфавитном пространстве. Например, описанный алгоритм мало чувствителен к соответствию высказываний, состоящих из небольшого числа слов, например: Номер счета и Банковский счет клиента, если в ряду прочих будут высказывания типа номер отделения, номер строения, номер квартиры, то алгоритм векторизации потянется к ним, потому что совпадений по осям больше. Что делать, если у вас с одной стороны приходит 3000 таких вот плохо описанных реквизитов, а с другой готовы принять только 500 и описание также не очень подробное? И как быть с другой возникающей проблемой несовпадении типов передаваемых данных? Вот тут начинается самое интересное. И возникает вопрос, как кластеризовать и разбить на группы эти не поддающиеся какому-либо описанию 3000 реквизитов?

Тогда у меня возникла идея использовать данный алгоритм и кластеризовать все поля по смыслу. Для этого зададим значение разничного вектора или проекции и сгруппируем таким образом те атрибуты, которые пройдут отбор по значениям данных величин. Ведь у нас в руках появляется числовой параметр соответствия одного термина другому. Язык Python позволяет это сделать просто и изящно. У него в арсенале есть так называемые словари. Ключом такого словаря можно сделать сущность делового оборота, которая нас интересует. Назовем её столбовой сущностью. А значением этого словаря будет являться список, состоящий из словарей, в которых ключом уже будет являтся параметр соответствия, а значением соответствующий комментарий к полю.
Вот, например вот так:

{'Номер счета физического лица': [{4.69: 'Банковский счет клиента'}, {6.0: 'Фамилия'}, {4.8: 'Номер металлического счета'}, {4.8: 'Номер клиента'}]}.

Эту схему можно также визуализировать в форме графа. Со словарями в языке Python можно много чего делать Для визуализации и демонстрации результатов мы применяли открытый интернет-проект www.graphonline.ru. Данная платформа позволяет быстро построить граф, записанный через GraphML.

Рисунок 4. Граф взаимосвязи сущности Номер физического лица. Иллюстрация наличия орбит семантического соответствия у сущности.

Если оценивать параметр длины разностного вектора, рассчитанный по формуле (3) и нарисовать граф, отнормировав его по весам, то можно увидеть локальные скученности терминов, вокруг которых можно провести правильную окружность определенного радиуса. Эту окружность мы в своей работе назвали орбитой семантического соответствия или семантической орбитой. Конечно же, велик соблазн сразу же определить радиус такой орбиты методами статистики. В прочем, это задача мало того, что слишком интересна, но и требует дополнительного осмысления. И может стать темой для дальнейшей работы.
Что это такое и что это дает? Допустим, мы в ходе анализа выделяем для нашего делового оборота множество столбовых сущностей или бизнес-объектов. Задаем точность (параметры $\vec{S_1}$ (формула 3) и $\delta$ формула (5)), и прогоняем алгоритм по всем перечным полей. Таким образом, у нас для каждой столбовой сущности подтягивается в словарь перечень атрибутов из списков конечных систем с указанием точности совпадения в процентах. Таким образом, появляется нечто наподобие семантической карты.

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

Рисунок 5. Прототип семантической карты, построенной в виде графа взаимосвязи сущностей с указанием параметра соответствия .

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

Когда мы стали получать графы взаимосвязи всех комментарий к полям, мы обнаружили, что кластеризация, действительно, имеет место быть. И самое поразительное, что глядя даже на такую, не сильно структурированную Вселенную семантического смысла (рисунок 6), можно наскоро оценить смысл и специфику передаваемых данных. Можно в этой вселенной различить галактики, туманности, скопления, кучкующиеся вокруг какого-то бизнес-смысла. И самое удивительное, что это действительно увеличило скорость анализа в среднем до 30% времени. Визуализация дает возможность быстрее уяснить смысл. А дальше возникла идея проверить, какие изменения в описания позволяют получить более контрастную картину. То есть, не то чтобы создать единое правило формирования описаний, а скорее понять, что должно произойти чтобы произошло полное перемешивание смыслов.

Рисунок 6. Вселенная семантического смысла. Пример построенного графа, иллюстрирующего семантическое пространство типичной модели данных.

Вместо заключения. Как определение семантики происходит зачастую на самом деле.

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

Мне вспомнилась история. Как-то в одном из полков морской пехоты Северного флота замполит решил организовать хор из матросов. Для чего была выписана музработник, для работы с матросами. И вот замполит подумал: Долго что-то репетируют. А, меж тем, последнее воскресение июля все ближе. И научиться петь растаял в далеком тумане Рыбачий надо бы побыстрее. На вопрос, в чем проблема, музработник сказала, что не удается ей никак разбить пятьдесят матросов по высоте вокала на пять тонов. Тогда замполит сказал Не вижу трудностей! На первый-пятый рассчитайсь

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

Я благодарен следующим авторам за труды, без которых не было бы данной статьи:

[1] Б.Я Шведин. Онтология предприятия: экспириентологический подход. УРСС. 2010.

[2]Б. Бенгфорд, Р. Билбро, Т. Охеда. Прикладной анализ текстовых данных на Python.Машинное обучение и создание приложений естественной обработки языка. Спб. Питер, 2019, 368 с.

P.S. Я хотел бы выразить благодарность своим коллегам из компании Accenture Эльвире Самигулиной и Вере Вишняковой за полезные дискуссии относительно данной статьи

Подробнее..

Категории: Микросервисы , Python , Математика , Python3 , Семантика , Блог компании accenture

Головоломка для ИИ

20.10.2020 00:16:52 |

Автор: admin

Как я учил агента собирать клетку 2048 в игре 2048

ИИ собирает клетку 2048

Привет! Меня зовут Ринат Максутов, я работаю в подразделении Intelligent Engineering Services департамента Technology российского офиса компании Accenture, и веду проекты по заказной разработке. За свою многолетнюю карьеру в Аксенчере я попробовал много разных областей: мобильная разработка, фронт-энд, бэк-энд и даже дата саенс с машлерном. Однако мой рассказ будет не про работу, а про хобби. Мне очень нравится учиться и исследовать новые области на собственных pet-проектах. Сегодня я расскажу об одном из них - как я учил Reinforcement learning (RL) агента играть в известную головоломку 2048. В статье намеренно не будет кода, математики, state-of-the-art подходов и новейших открытий в области, поэтому люди, хорошо знакомые с RL, ничего нового для себя не откроют. Эта статья - рассказ для широкой публики о том, как я поставил себе необычную цель и достиг ее.

Наша компания инвестирует значительные средства в постоянное обучение сотрудников. Например, в прошлом году была запущена программа, по которой сотрудники могут бесплатно пройти один из Nanodegree на Udacity (Nanodegree - набор из нескольких курсов с финальным проектом). Я уже проходил Deep Learning Nanodegree на этой платформе, поэтому в этот раз решил выбрать курс по обучению с подкреплением.

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

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

Чтобы закрыть этот пробел, я попытался решить какую-то задачу, которая раньше никем не решалась (по крайней мере, с помощью RL), и на ней изучить различные аспекты построения сред для агентов. В качестве такой задачи была выбрана простая в плане механики игра-головоломка 2048 (поиграть в браузере можно здесь: https://play2048.co/). В этой игре игроку, сдвигая клетки в одном из четырех направлений (вверх, вниз, вправо, влево), нужно объединять клетки с одинаковым значением, и попытаться собрать клетку с максимально возможным значением. Когда вы совершаете сдвиг, на случайной свободной клетке появляется новая двойка (с вероятностью 0.9) или четверка (с вероятностью 0.1). Игра заканчивается, когда на поле не останется пустых клеток, и игрок не может объединить никакие клетки.

Несмотря на название, 2048 не является максимально возможным значением клетки в игре. При должной тренировке, можно собрать клетки и 4096, и 8192, и так далее. Максимальное теоретически возможное - 131 072, то есть 2^17:

Источник: Wikipedia

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

Почему эта стратегия не гарантирует победу?

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

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

Небольшое введение в Reinforcement learning

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

Источник: https://medium.com/@dgquintero02/how-to-explain-machine-learning-to-your-family-77a3bac3593a

Под капотом агента может находиться некоторая математическая модель, которая и определяет, какое действие будет наилучшим, исходя из текущего состояния среды. Изначально агент, в общем случае, ничего не знает о том, что за среда ему дана, и как на нее влияют его действия. Обратную связь от среды агент получает через так называемую награду. Это некоторое число, по которому агент может судить, насколько правильным было выбранное им действие. Задача агента - выучить политику - стратегию действий, которая максимизирует получаемую агентом награду за весь период существования агента в среде. Эта награда - и есть то самое подкрепление, это означает, что правильные действия подкрепляются положительной наградой, а неправильные - предотвращаются (не смог найти более подходящего русского аналога для discourage) отрицательной. Так через многократные итерации агент (а точнее, модель) начинает более точно предсказывать потенциальную награду от каждого возможного действия и выбирать наиболее ценное действие.

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

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

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

Дело в том, что традиционно машинное обучение используется для автоматизации задач, которые: 1) сложно алгоритмизируются, 2) легко выполняются достаточно обученным человеком, но 3) требуют от человека значительного времени на выполнение задачи. Например, в задачах распознавания образов человек может легко определить, есть на ней искомый объект или нет, но очень сложно написать достаточно надежный и более-менее универсальный алгоритм определения объекта, и при этом для большого количества изображений человек будет делать эту работу очень долго. Или, например, выявление мошенничества: тренированный человек по последовательности транзакций сможет выявить подозрительные операции, но их поиск и анализ будут занимать колоссальное количество времени, и эту задачу также сложно описать универсально заранее заданными наборами правил.

Теперь рассмотрим под этим углом обучение с подкреплением. Задача данной области - научить агента (по сути, ту же модель машинного обучения) действовать в некоторой среде, то есть принимать решения в зависимости от текущей ситуации. Под такую идею подходит не так много задач - в основном в области управления чем-то, например, роботизированным манипулятором на сборочном конвейере, автомобилем на дороге, толпой зергов в StarCraft и так далее. Но в области управления, обычно, людям уже известны правила или стратегии, по которым достигается нужный результат. Мы не хотели бы, чтобы манипулятор на сборочном конвейере сначала обучался ставить деталь на нужное место в течение десятков тысяч циклов и испортил десятки тысяч экземпляров продукции, прежде чем начал делать то, что нужно. Гораздо надежнее написать программу, точно позиционирующую манипулятор на каждом шаге сборочного процесса. Мы не хотели бы, чтобы автомобиль отъездил миллионы километров и выучивал, что значит каждый из дорожных знаков по пришедшим ему через неделю штрафам - гораздо быстрее и надежнее заложить это знание изначально. Именно поэтому обучение с подкреплением пока еще очень экспериментальная область, и практических применений для нее мало. Замечательная статья на эту тему трехлетней давности до сих пор актуальна и очень хорошо описывает проблему, советую почитать. На этом вводная заканчивается, возвращаемся к нашей задаче.

Грабли и велосипеды

Очередной мем с Боромиром

Достижение клетки 2048 (хотя по меркам более-менее опытного игрока, 2048 - совсем не достижение) - это долгий путь проб, ошибок, разочарований, глупейших багов, воодушевления и радости.

Поначалу все казалось довольно просто: берем готовый код, реализующий Deep Q-network из моих домашних заданий на Udacity, немного адаптируем под собственную среду, и все получится. Наивно.

Чтобы вы понимали, на что были потрачены 3 месяца экспериментов (если ничего не понятно, можно просто удивиться количеству буллитов и проскроллить дальше):

Область	Лучший вариант	Пробовал
Состояние среды	One-hot encoded вектор (16 клеток * 18 возможных состояний каждой)	Вектор со значениями клеток как есть Вектор с Log2 значениями клеток Матрица 4 на 4 для сверточной сети
Награда	Сумма log2 значений схлопнувшихся клеток на доске на текущем шаге минус штраф за сдвиг клетки и штраф за некорректный ход	Сумма значений клеток на доске Сумма значений схлопнувшихся клеток за все время Сумма log2 значений схлопнувшихся клеток за все время
Обучение	10 итераций обучения после каждой сыгранной партии, батчи размером 1024, начальный : 0.05, фактор уменьшения : 0.9999,	1, 3, 5, 20 итераций обучения после каждой сыгранной партии Различные значения (фактор рандомизации действий) от 1.0 до 0.01
Накопление и использование опыта	Буфер на 100 000 последних действий Случайное сэмплирование опыта (без приоритезации)	Буфер на 50 000 и 200 000 Приоритезация опыта по сумме на доске, максимальной клетке, величине ошибки, награды, в т.ч. сбалансированное по распределению действий
Помощь в обучении (читерство)	Никакое	Доигрывание с середины: каждые N эпизодов запускать агента в среду со случайно сгенерированными большими клетками, чтобы познакомить его со значениями, до которых он раньше не добирался сам Параллельные реальности: помимо одного выбранного шага рассчитываются и сохраняются в историю остальные 3 возможных шага, чтобы в обучении было больше сравнимых примеров
Что максимизировали	Дисконтированную награду на 2 шага вперед	Счет на следующем шаге Дисконтированный счет на всех последующих шагах Награду на следующем шаге
Нейронная сеть	5-слойная: 288-3х1024-4, активация ReLU и Adam optimizer	2, 4 скрытых слоя Другие оптимизаторы и активации 256, 512 нейронов в скрытых слоях Различные значения learning rate Сверточная сеть

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

Первое, с чем пришлось столкнуться - отсутствие прогресса в обучении агента ВООБЩЕ. И связано это было с тем, что именно агенту выдавала среда.

Среда для агента

Написать логику доски для игры оказалось довольно просто, и заняло пару часов. Несколько простых трюков с матрицами - и движок готов. Он производит схлопывание и сдвиг клеток в зависимости от выбранного действия, заполнение новой клетки и подсчет очков. Текущее состояние среды, таким образом, описывалось простой матрицей 4х4, где в каждой ячейке было значение соответствующей клетки. Поскольку я использовал обычную нейросеть из fully-connected слоев, то прежде чем отправить состояние среды в нейросеть, ее нужно было трансформировать в вектор 1х16:

И здесь меня поджидала первая проблема. Качество обучения переставало расти, когда агент добирался до клетки 512. Больше нее он не мог собрать, сколько бы я его ни обучал. Проблема здесь оказалась в значениях клеток, которые имеют колоссальный разброс: от 0 до сотни тысяч. Пусть меня простят специалисты, но далее будет очень вольное объяснение причины такого поведения: я намеренно упрощаю, чтобы была понятна общая идея.

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

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

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

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

И для агента значение имело бы только то, что a+a = b, b+b=c и т.д., а не то, какие значения скрываются за a, b и с. (+ в данном случае - не сложение, а то самое схлопывание). К чему это все? К тому, что значения клеток можно рассматривать не как числовые значения, а как категориальные. И поскольку мы знаем максимально возможное значение клетки, можно каждую клетку представить в виде one-hot encoded вектора. То есть для каждой клетки использовалось не ее значение, а вектор размерности 18, у которого все значения были нули, и только одно значение, позиция которого соответствует одному из наших возможных значений, равнялось единице. И таких векторов - по количеству клеток. Мне до сих пор не ясно, почему, но именно такое, а не числовое представление, помогло агенту гораздо быстрее достигать более высоких значений.

Награда

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

Возьмем очень простую игру, например, Space Invaders. На ней несколько лет назад Google тренировал своих агентов.

Space Invaders.

В этой игре счет увеличивается, каждый раз, когда вы попадаете в зеленого человечка. То есть существует прямая зависимость между действием (выстрел), результатом в среде (попадание) и количеством очков.

В 2048 такой подход не сработает. И вот почему. Допустим, у вас есть 2 клетки с одинаковыми значениями, стоящие рядом. Вы их схлопываете, и счет на доске не изменился. Потому что их значения по отдельности равняется значению новой клетки. То есть совершив правильное действие, агент не получит позитивного подкрепления и не узнает, что делать нужно именно так. Более того, после каждого действия заполняется новая случайная клетка, как я писал выше, значением 2 или 4. То есть какое бы действие ни совершил агент, он всегда будет получать в ответ значение, которое равняется [счет до шага + 2 или 4]. Очевидно, этой информации недостаточно, чтобы понимать, насколько хорошее действие агент выбрал. И именно из-за этого обучение практически не прогрессировало.

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

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

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

Штрафы

Этот подход используется в RL довольно часто для того, чтобы агент не просто научился выполнять задачу, но и делал это наиболее экономно. А чтобы показать ему, какой из ходов - экономный, а какой - расточительный, нужно заложить эту информацию в награду. В моем случае я решил каждый ход штрафовать агента за все клетки, которые сдвинулись (то есть изменили свое положение) после выбранного действия. И чем больше клеток было сдвинуто, тем выше был штраф. То есть если он накапливает крупные значения в правом нижнем углу, и продолжает делать ходы вправо или вниз, то штрафом для него на каждом шагу будут только значения новых клеток. Если же он вдруг решит сделать ход вверх или влево, то сдвинется не только новая клетка, но также сместятся и все те, которые концентрировались в правом нижнем углу, и штраф будет огромным. Со временем агент понял, что наибольшая награда получается не только когда он схлопывает более крупные клетки, но и когда он двигает наименьшее количество клеток - и это заставляет его придерживаться выбранной стратегии, и только в исключительных случаях делать шаги в неприоритетных направлениях - когда ожидаемая награда с учетом штрафов оказывается действительно выше.

Распределение долей выбранных направлений ходов в каждой из игр.

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

Был еще один забавный момент в поведении агента, который сильно замедлял обучение. Как я писал выше, агенту не давались знания о правилах игры. Соответственно, он не знал, что нельзя делать ход, например, вправо, если у тебя все клетки уже прижаты к правой части доски. То есть даже если ты сделаешь такой ход, ничего на доске не изменится. В какой-то момент нейросеть почему-то решала, что самый выгодный ход - тот, при котором ни одна клетка не двигается, потому что если ничего не сдвинулось, то и штрафа не будет. Возможно, из-за своего размера штрафы за сдвиг для него были страшнее, чем неполучение награды за схолпнувшиеся клетки. А поскольку после такого хода доска не поменялась, то, и вводные для следующего шага оставались такими же. Ну и, понятно, выбиралось такое же действие. И так в течение тысяч итераций, пока не срабатывал рандомный ход (на каждой итерации с очень малой вероятностью - в десятые или сотые доли процента - делался случайный ход вместо вычисленного, чтобы, среди прочего, выводить из таких зацикливаний). Эта проблема могла быть решена более тонкой настройкой штрафов и наград, но вместо этого я просто решил очень сильно штрафовать агента за невозможные ходы, и он довольно быстро отучился это делать.

Результат

The WOW signal

Зеленый график показывает максимальное значение клетки в каждой игре. Выброс - в одной из игр максимально полученное значение клетки - 2048.

Для того, чтобы собрать клетку 2048 агенту пришлось отыграть чуть больше 60 тысяч партий. Однако важная деталь в том, что однократное достижение еще не означает, что агент научился делать это стабильно. Посмотрите на начало зеленого графика, где видно, как агент учился доходить до клетки 1024. Сначала был такой же выброс, затем 1024 появлялось все чаще и чаще, и затем где-то после 30 тысяч игр агент уже довольно уверенно доходил до 1024. То есть если говорить о том, чтобы агент действительно научился собирать 2048, то, экстраполировав закономерность, можно прикинуть, что агенту потребуется более миллиона игр, чтобы закрепить этот навык, и устремиться к следующей цели - 4096.

Вы наверное уже устали читать, поэтому больше не буду грузить другими выкрутасами, которые я пробовал. Вместо этого вот вам 20-минутный видосик, где собирается клетка 2048 (начиная с отметки 16:40).

Обучение я вел на своем рабочем ноуте (да простит меня руководство!), поэтому получение этого результата заняло около двух дней. Но как я написал выше, 2048 - далеко не предел в этой игре. Поэтому если у вас есть свободные мощности и время, вполне возможно дойти и до гораздо больших клеток - берите мой код на GitHub и попробуйте обучить своего агента! Если удастся побить мое достижение, присылайте гифки и ссылки на свои результаты в комменты. Всем спасибо!

PS: Пользуясь случаем, нам в команду сейчас очень нужны back-end разработчики на Python и Java, и front-end на React. В Москве, Твери или Ростове-на-Дону. Также с удовольствием приглашу пообщаться людей, которые любят исследовать технологии, делать proof-of-concept и искать им применения в бизнесе. Откликайтесь на наши вакансии или, если не нашли подходящей, пишите в личку!

Подробнее..

Категории: Python , Искусственный интеллект , Машинное обучение , Обучение с подкреплением , Блог компании accenture

Качественный аутсорсинг от А до Ё работаем с типовыми слабостями

01.10.2020 00:23:40 |

Автор: admin

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

А) Дорого.

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

Гибкое распределение специалистов между аналогичными задачами и клиентами. Специалист A эффективно справляется с задачами типа B. Как только он справился с задачей B1, отправляете его решать B2. Так вы экономите время и деньги компании на поиске или обучении другого специалиста.
Обеспечение высокой загрузки специалистов. Это не значит, что сотрудники будут пухнуть от нагрузки. Они будут знать, что им делать сейчас и что им делать потом. Сотрудники даже смогут с чистой совестью прерываться на чай или медитацию, а потом возвращаться к работе. Даже если что-то пойдёт не так и вспыхнет срочная задача, вам не нужно будет сломя голову искать специалиста, который её решит у ваших специалистов будет на это время.
Возможность найма сотрудников из регионов, в которых дешевле жить. В таком случае и стоимость услуг специалиста будет дешевле.
Повторное использование процессов, тулов, стандартов и практик.

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

Б) Долго.

Завести нового пользователя 3 дня. Сбросить пароль 5 дней. Дать права, как у Иванова, но с ограниченным доступом 10 дней. Знакомые ситуации? Мне да. Когда простые задачи решаются так долго хочется не работать, а биться головой об мягкую стену. Чем больше висит невыполненных задач, тем хуже. Можно ли заранее измерить этот аспект? Можно.

В) Негибко, бюрократично.

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

Г) Непрофессионально.

Случается, что поставщик набрал студентов и сразу бросил их в бой. Это дёшево, но экономия всегда приносит свои последствия. Выливается это в ошибки, на решение которых тратятся время, силы и репутация. Конечно у всех есть текучка кадров, и надо не забывать про передачу знаний.
Важный аспект личный контакт между специалистами исполнителя и ключевыми пользователями клиента. Поэтому поставщик еще на фазе внедрения сервиса должен познакомить команду с заказчиком и установить рабочие отношения между исполнителями и командами заказчика (ИБ, функциональные заказчики, ключевые пользователи и т.д.).

Д) Непрозрачно.

Выстроенные процессы это конечно хорошо, но у этого есть оборотная стороны: формальные процессы позволяют скрывать просчёты, уменьшают личную ответственность. Кто конкретно сейчас решает мою задачу? Кто отвечает за результат в целом? Почему задача забуксовала в отделе бизнес-анализа? Кто виноват, что делать и когда это кончится? Вот здесь то и нужны выстроенные отношения и гибкие процессы. Менеджер сервиса должен выполнять руководящую и направляющую роль и являться контактом для эскалации. Нет практики по назначению ответственного за результат? Будет долго и бюрократично.

Е) Нет доверия (небезопасно).

Когда видишь сотрудников вживую, доверяешь им больше. В аутсорсинге, сотрудники непонятно где и как выглядят. Как довериться и дать доступ тем, кого не знаешь и не видишь? Мы рекомендуем ехать к поставщику и знакомиться. Приезжаете к нему и оцениваете как он работает, проводите свой Due Diligence.
Обязательно выясните:

Как поставщик защищает себя от разного рода случайностей?
Как поставщик контролирует работу сотрудников?
Выстроена ли у поставщика система контрольных процедур и лучших практик? Насколько они разумны?
Наблюдается ли микро-менеджмент?
Умеют ли сотрудники работать самостоятельно?
Готовы ли сотрудники отвечать за результат своей работы?

Ё) Не клиентоориентированно.

Мы много сказали про выстроенные процессы и автоматизацию, а что насчёт живых людей? Выполняются ли задачи по принципу претензии к пуговицам есть?. Несмотря на внедрённую автоматизацию, установленные процессы, поддержанные правильными системами учета тикетов, несмотря на это всё в сервисе должен остаться человеческий фактор, который сделает сервис индивидуальным под конкретного клиента.
Речь идет о core-команде, которая в значительной степени (>60%) выделена на этого клиента, знает его особенности. Core-команда способна предоставлять целостный сервис, понимая чем живёт компания. Здесь требуется раскрыть человеческий потенциал, перестать фокусироваться только на приложениях или ИТ-инфраструктуре, постоянно адаптироваться к изменяющейся действительности, перестать делить людей на ваших и наших. Вместо этого надо учить людей широкому кругозору в сочетании с специализацией в конкретной области (T-shaped people).

Теперь мы знаем про недостатки аутсорсинга. Что дальше?
Когда выбираете поставщика аутсорсинг-услуг, помните про перечисленные критерии. Общаясь с возможным поставщиком, спросите, как у него обстоят дела с этим пунктом, с другим, третьим и т.д. По ответам можно будет понять, насколько конкретная команда в состоянии сработаться с вами.

Подробнее..

Категории: Управление персоналом , Аутсорсинг , Блог компании accenture

Публичные облака в российских реалиях. Часть 1. IaaS

24.10.2020 12:06:33 |

Автор: admin

Облачные технологии, инфраструктура как сервис и платформенные сервисы из нишевых решений давно перешли в стандарт де-факто для размещения приложений не только стартапов, но и крупных финансовых компаний, госкомпаний, автомобильных гигантов и популярных игровых сервисов. Компании Netflix и Spotify, Dropbox и Instagram начинали свой путь на облачных ресурсах, не инвестируя в собственную инфраструктуру. Совокупная выручка мировых поставщиков облачных услуг в 2019 году превысила бюджет Российской Федерации. В этой статье мы рассмотрим рынок облачных услуг в России. Мы сравним его с мировыми трендами и определим опережаем мы или отстаём от мировых лидеров в развитии облачных услуг и насколько.

Как все начиналось

Публичные облака в РФ появились как эволюционное развитие собственной инфраструктуры виртуализации. Следуя за трендами в корпоративном сегменте, они были основаны на привычных крупным заказчикам технических решениях, таких как Microsoft Hyper-V и VMware vSphere, c установкой портала самообслуживания (Windows Azure Pack или vCloud Director for SP). Клиенты получали понятный им функционал: знакомые инструменты управления, мониторинга и резервного копирования всё, с чем клиенты работали каждый день.

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

Инфраструктура, обеспечивающая ресурсы платформы виртуализации, должна быть в списке совместимой и поддерживаемой. Для этого чаще всего используются серверы именитых производителей (Dell EMC, HPE, Lenovo, Huawei и др.) и выделенные СХД, подключаемые как блочные устройства по протоколу FС. Приобретение и поддержка такой инфраструктуры это основная статья затрат в эксплуатации облачной платформы. Функционал и развитие облачной платформы целиком определяется выбранным вендором.

Параллельно стали появляться публичные облака, как эластичная инфраструктура, от нетипичных игроков на рынке из таких индустрий, как retail (Amazon), e-commerce (Alibaba) и интернет (Google).

Используя наработки на базе собственных on-premise технологий, в популярного поставщика облачных услуг превратилась компания Microsoft с их платформой Azure.

Большинство игроков частично использовали решения open-source. Например, Amazon использовал гипервизор Xen, а сейчас переключился на KVM. Кто-то использовал платформу с открытым исходным кодом OpenStack, дорабатывая ее под свои нужды.

Запуск решения на базе готовой платформы с открытым исходным кодом позволяет сократить время выхода на рынок, особенно если нет достаточно зрелых технологий, на базе которых можно построить собственную инфраструктуру. Вокруг популярной платформы обычно довольно зрелая экосистема с необходимым набором утилит для организации DevOps конвейера, мониторинга, автоматизации и оркестрации. Такой платформой можно считать Mail.ru Cloud Solutions (MCS) на базе Openstack.

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

Немного о сравнении

Мы сравним эти два подхода к построению облачной инфраструктуры от компаний Mail.ru Group и Яндекс. Остановимся только на ключевых отличиях и посвятим сравнению цикл статей. В первой статье мы начнем с IaaS, во второй статье планируем остановиться на сетевых сервисах и PaaS, в третьей на SaaS, мониторинге и сервисной поддержке.

Почему здесь только Яндекс.Облако и MCS?

Мы ограничили состав участников сравнения указанными платформами, потому что они соответствуют нашему представлению о современном поставщике облачных услуг, которое заключается в следующих критериях:

Разработка платформы производится собственными силами с минимальным использованием корпоративных вендорских решений, например, VMware vCloud Director и др.
Наличие единого портала самообслуживания, из которого можно управлять всеми услугами IaaS, PaaS и SaaS, в том числе и производить их оплату.
Подключение услуг IaaS, PaaS и SaaS производится клиентом без дополнительного взаимодействия с представителями поставщика.
Возможность полноценного управления платформой без графического интерфейса для задач автоматизации управления инфраструктурой и построения конвейера DevOps.
Документация по платформе, стоимость и калькулятор услуг опубликованы на сайте поставщика.
Наличие современных сервисов таких, как ML, AI, serverless, Big Data и др.

На каждом этапе сравнения будем брать ориентир на облачную платформу Microsoft Azure. Это поможет нам понять, насколько компании Яндекс и Mail.ru Group приблизились в технологическом аспекте к одному из мировых лидеров в области предоставления облачных услуг.

Почему выбрали Azure?

Вместо Microsoft Azure могла быть любая другая платформа из крупных игроков. Мы предпочли ее по двум причинам:

Azure зрелая платформа для Enterprise решений. Она сертифицирована на работу с SAP HANA и обладает большим количеством популярных сервисов в корпоративной среде.
Azure оперативно внедряет все свежие тренды и технологии (например, Azure Kubernetes (AKS), собственные решения DevOps, собственные решения Azure serverless и др.).

ЦОД

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

Рис. 2. Архитектура ЦОД ближайшего к России региона Azure

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

Важным преимуществом платформ MCS и Яндекс.Облако по сравнению с Microsoft Azure является наличие дата-центов на территории Российской Федерации. Если ваш сервис должен соответствовать требованиям Федерального закона О персональных данных (ФЗ-152), то развертывание его в облаке от зарубежного поставщика потребует внедрения дополнительных технических решений, так как первичная обработка персональных данных (ПДн) должна происходить на территории Российской Федерации и в дальнейшем данные должны передаваться по защищенным каналам связи. Невыполнение требований о защите ПДн может привести к блокировке доступа к сервису Роскомнадзором.

Рис. 3. Архитектура ЦОД платформы MCS

Облачная платформа от Mail.ru Group размещена на территории города Москвы в двух арендованных дата-центрах: DataLine на Коровинском шоссе и DataPro на Авиамоторной улице. Последний имеет сертификацию Uptime Institute. Между дата-центрами организован канал 40 Гбит/с с длиной трассы около 25 км. Это позволяет нам рассматривать оба дата-центра, как площадки для построения высокодоступных (High-Availability) кластеров с узлами в каждом из дата-центров с синхронной репликацией данных между ними, но без так называемой кворум площадки.

Сетевая архитектура облака имеет растянутые L2 сети между площадками. Это дает нам возможность использовать технические средства отказоустойчивости: Keepalived, Veritas Cluster Server, Microsoft Windows Server Failover Cluster и прочие. Такие средства увеличивают наши шансы на миграцию большинства legacy решений в IaaS данного поставщика. При этом мы сохраняем отказоустойчивость архитектуры, которую мы использовали на собственном оборудовании on-premise.

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

Почему это является преимуществом?

При отсуствии официальной сертификации платформы под SAP HANA, компания Mail.ru Group может установить по запросу клиента сертифицированные SAP HANA Appliance и подключить их к клиентскому VPC внутри облака MCS. Это позволит не потерять поддержку на продуктивные среды SAP продуктов и воспользоваться всеми преимуществами облачной инфраструктуры для остальных сред.
Аналогичным примером может быть установка оборудования для организации защищенных каналов связи с помощью национальных стандартов криптографии (например, алгоритмов шифрования ГОСТ Р 34.12-2015).

Стоит отметить, что компоновка оборудования самого облака стандартизирована и проходит все стадии тестирования внутри компании.

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

Рис. 4. Архитектура ЦОД платформы Яндекс.Облако

Облако от компании Яндекс в свою очередь размещено в трех собственных дата-центрах, расположенных в Московской, Владимирской и Рязанской областях. Каждый ЦОД проектировался и строился самостоятельно. Яндекс эксплуатируют их с соблюдением международных и собственных стандартов. Надо отметить, что опыт в построении дата-центов у Яндекса действительно имеется.

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

Три полноценные площадки позволяют разворачивать любые отказоустойчивые архитектуры. Однако большая удаленность, порядка 200 км друг от друга, не позволяет развернуть кластера высокой доступности (High-Availability) с узлами в каждом из дата-центров с возможностью синхронной репликации данных между ними. Также отсутствие L2 между дата-центрами ограничивает нас в возможности развернуть здесь legacy решения.

Архитектура IaaS платформы

Модель обслуживания Infrastructure-as-a-Service (IaaS), как описано в стандарте NIST, это возможность предоставить клиенту вычислительные, сетевые ресурсы и ресурсы хранения данных, на базе которых клиент сам размещает и управляет операционными системами и приложениями. Современная IaaS платформа включает в себя гипервизор, предоставляющий вычислительные ресурсы, программно-определяемую систему хранения данных software-defined storage (SDS) для размещения данных и программно-определяемую сеть software-defined networking (SDN) как средство организации сетевого доступа к ресурсам IaaS.

Референтная платформа нашего сравнения, Azure от компании Microsoft, начинает свою историю еще в далеком 2003-м году с приобретения компании Connetix и их продукта Virtual PC с целью догнать конкурента VMware и их продукт GSX Server, вышедший двумя годами ранее. Спустя время продукт Virtual PC интегрировали в состав платформы Windows Server. Он появился в версии 2008, но только к версии 2012 были реализованы SDS на базе Scale-Out File Server и Storage Spaces и SDN на базе Hyper-V Network Virtualization. Это позволило построить целиком программно-определяемую платформу IaaS без привязки к аппаратным возможностям СХД или оборудования ЛВС.

Платформа Azure поддерживается большинством современных DevOps утилит как для построения конвейера непрерывного развертывания, так и для автоматизации рутинных задач. У Azure функциональный веб-интерфейс и подробно документированный API. Все крупные игроки по разработке платформ автоматизации и управления облачными платформами поддерживают Azure. Утилита командной строки Azure CLI доступна как расширение PowerShell и как отдельная утилита для платформ Windows, Linux и MacOS X.

Компания Mail.ru Group для своего облака взяла наработки платформы OpenStack. К 2020 году компания перешла на полностью собственный дистрибутив, который не связан с open-source версией платформы. В качестве гипервизора используется функция ядра ОС Linux Kernel-based Virtual Machine (KVM), основным разработчиком которого является компания Red Hat, ныне часть IBM. Объем доработок KVM, которые выполнили разработчики MCS, компания не раскрывает. В части SDS для блочных устройств и сервиса NFS используется решение CEPH его тоже дорабатывала команда MCS. Для объектного хранилища S3 были переиспользованы технологии облачного диска Mail.ru Group. В качестве сетевого решения применяется решение на базе OpenvSwitch, однако механизмы управления Control plane были серьезно переработаны. Это дало жизнь проекту Sprut.

Для управления платформой MCS был реализован отдельный портал, в котором реализованы самые популярные сервисы, а также доступен нативный интерфейс OpenStack Horizon. Для тонкой настройки сервисов предоставляется доступ к OpenStack CLI или OpenStack API. Есть также возможность использовать решение Infrastructure as Code (IaC) которое будет обращаться напрямую к API платформы. Работу с OpenStack поддерживает большинство систем управления конфигурацией, что упрощает встраивание облака MCS в DevOps конвейер и внешние системы управления облачными ресурсами.

Как было у Яндекса? Первую версию своей платформы компания разрабатывала для себя. Яндекс, так же, как и Mail.ru Group ориентировался на архитектуру и компоненты OpenStack. Однако, потом компания отказалась от нее. Было принято решение начать с чистого листа. Яндекс переиспользовал базовые инфраструктурные компоненты, которые у них уже были. К ним компания дополнительно разработала недостающие модули и платформу управления.

В качестве гипервизора компания Яндекс также использует KVM. В его разработку инвестированы большие ресурсы. Решения SDS и SDN были разработаны компанией самостоятельно. SDS основан на собственной СУБД Yandex Database (YDB) для хранения мета-данных о размещении виртуальных машин и Network Block Storage (NBS) как сервиса предоставления блочных устройств виртуальным машинам, также YDB используется и в S3-совместимом решении в составе платформы. Яндекс, в отличии от MCS и Azure, не предлагает сервис NFS в составе услуг, рекомендуя развернуть его на базе виртуальной машины. В качестве SDN используется переработанная платформа OpenContrail. Её разрабатывали Juniper Networks, которая с недавнего времени входит в Linux Foundation, как платформа TungstenFabric.

Использование собственной платформы управления ограничивает возможности по встраиванию ресурсов Яндекс.Облака в конвейер DevOps или внешние системы управления облачными ресурсами. В настоящий момент заявлена поддержка IaC Terraform с помощью разработанного компанией провайдера. Ещё существует неофициальная поддержка работы с Ansible. Однако, среди популярных систем для управления Гибридными Облаками (Cloud Management Platforms) таких как Red Hat CloudForms, Morpheus, Scalr, поддержка отсутствует. Компания также разработала и поддерживает свою собственную утилиту YC CLI для работы с платформой из командной строки с собственным набором команд.

Хранение данных

У MCS есть репликация блочных устройств между зонами доступности, что позволяет запустить виртуальную машину с теми же данными на любой из площадок, а также получить высокопроизводительный локальный диск NVMe или общее СХД по протоколу ISCSI. Azure предлагает репликацию объектных хранилищ как внутри зоны доступности, так и между зонами в пределах географического региона, а также сервис Azure Site Recovery для репликации блочных устройств. Обе платформы предоставляют сервис NFS.

В платформе Яндекс.Облако нет синхронной репликации блочных устройств между зонами доступности. Реплицируются только резервные копии и S3-хранилище. Репликация данных для Яндекс.Облака может быть реализована средствами приложения или СУБД. Отсутствие репликации блочных устройств связано с тем, что ЦОДы располагаются достаточно далеко и синхронная репликация будет вносить значительные задержки в дисковый ввод-вывод. Сервис NFS платформой Яндекс.Облако не предоставляется.

Образы виртуальных машин

В отличие от Azure, в MCS отсутствует возможность развернуть ВМ с использованием enterprise-level дистрибутива ОС Linux (RHEL, SLES, OEL). Платформа Яндекс.Облако позволяет развернуть ВМ с ОС RHEL версии 7.8, но подписку клиент должен оформлять самостоятельно через стороннюю организацию.

Оба провайдера поддерживают загрузку собственных образов ОС. Яндекс поддерживает форматы qcow (qemu), vhd (Microsoft Hyper-V/Azure) и vmdk (VMware ESXi), но отсутствует возможность импорта ova/ovf формата. MCS поддерживает загрузку формата RAW, для которого требуется конвертация с помощью стандартной утилиты из пакета Qemu. Ещё он поддерживает конвертацию на лету при загрузке через веб-интерфейс портала. Azure позволяет загружать собственные образы в формате VHD (формат Hyper-V).

SLA

Уровни SLA отличаются между платформами. MCS и Azure предоставляют SLA в рамках доступности на каждый из облачных сервисов, а также на отдельные параметры внутри сервиса например, на IOPS для блочных устройств. Яндекс же оперирует только доступностью сервиса, не включая характеристики отдельных компонент. Все провайдеры компенсируют часть счета на услуги в зависимости от времени простоя сервиса. Яндекс отдельно упоминает о возможности полной компенсации платежей в случае потери данных клиента.

IAM

Все платформы предоставляют сервис управления учетными записями и правами Identity and Access Management (IAM).

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

Компания Mail.ru Group расширила функционал, заложенный в IAM для Openstack в части работы с собственным сервисом S3, и близка по возможностям к сервису платформы Яндекс.Облако.

Обе платформы не предполагают сценариев интеграции IAM для собственных приложений клиента.

Наиболее богатый функционал IAM у Azure. Кроме управления облачной инфраструктурой есть возможность получить Active Directory, как услугу. Есть возможность использовать IAM для интеграции с приложениями в облаке для управления учетными записями клиентов компании. Все платформы поддерживают управление собственными SSH ключами для Linux систем.

Управляемые сервисы VPN и DNS

Для полноценного использования платформы IaaS нам требуются такие сервисы, как Managed VPN и Managed DNS. Azure позволяет управлять внешними и внутренними DNS зонами, обычными или техническими DNS записями, а также автоматически регистрировать новые DNS записи при создании ВМ. В MCS функционал ограничен созданием внутренней DNS зоны и автоматической регистрацией ВМ в ней, с возможностью создания произвольного имени или же привязки DNS-записи к сетевому порту (IP адресу), но без возможности управления техническими записями. В платформе Яндекс.Облако отсутствует возможность управлять записям DNS.

Если говорить об организации защищенного подключения и пиринга, то наиболее полный функционал у Azure. В нём есть поддержка режимов client-to-site, site-to-site и прямого пиринга по протоколу BGP. Пропускная способность VPN-линка к Azure ограничивается оконечным оборудованием клиента. MCS поддерживает только режим site-to-site для протокола IPSec. Яндекс только технологию прямого соединения (название сервиса Yandex.Cloud Interconnect) по протоколу BGP. Для организации защищенного канала VPN к платформе Яндекс.Облако потребуется развернуть Cisco CSR, Mikrotik CHR или другое VPN решение из маркетплейса.

On-Premise решение для частного облака

Все поставщики облачных услуг предоставляют возможность развертывания своей платформы на оборудовании заказчика (on-premise). Частное облако может быть интегрировано с публичной платформой от данного поставщика для организации гибридного решения с единым порталом управления, репликацией машин и Disaster Recovery площадкой в публичном облаке. Есть отличие предоставления сервиса и вот в чём оно состоит. Microsoft и Яндекс поставляют собственные решения в виде готового к установке в ЦОД оборудования. Компания Mail.ru Group может поставить свое решение на оборудование клиента, совместимого с их платформой.

Итоги сравнения

Подведём итоги сравнения платформ MCS и Яндекс.Облако в части IaaS. Производители данных решений не до конца реализовали весь функционал, необходимый для полноценного перехода инфраструктуры клиента на их сервисы. Отсутствие или недостаточная реализация функционала таких сервисов, как VPN и DNS, требует от клиента наличия своей собственной команды для их поддержки. Это создаёт технический долг, который компании обещают закрыть.

Основные отличия между платформами кратко:

Сравнивая функционал у обоих игроков, оценим его как почти равный. Разве что MCS выглядит более зрелым игроком. На это две причины: разница в возрасте, около полутора лет с момента запуска, и использование наработок из эко системы Openstack. С другой стороны в мире не так много крупных облачных сервисов, построенных на базе Openstack. Если развитие данной платформы будет приостановлено, то компания Mail.ru Group будет вынуждена продолжать разработку в одиночку, будучи скованной архитектурными паттернами родительской платформы Openstack.

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

Подробнее..

Категории: Devops , Облачные сервисы , Mail.ru cloud solutions , Azure , Яндекс.облако , Блог компании accenture

What can we do with Java16? Краткий обзор нового релиза JDK (март 2021)

12.04.2021 18:13:34 |

Автор: admin

JDK 16. Чего нам ждать от Java в марте?

В марте разработчикам в их привычных средах разработки пришло сообщение "New JDK version is available", что означало, что вышел очередной релиз Java 16 с открытым исходным кодом Java SE (Standard Edition) 16 и Java Development Kit 16 (JDK 16). Подготовка к выпуску окончена, и набор новых функций (JEP), который был утвержден, теперь реализован в JDK и опубликован в открытом доступе. Известно, что для 16-го релиза новых JEP уже не будет. А следующий, 17-й релиз выйдет в сентябре. Ах да, что же такое JEP для новых релизов Java? Для новичка это всегда не очень понятно.

Что такое JEP в превью к JDK.

"Предложение по улучшению Java" (JEP). JEP - это документ, предлагающий усовершенствование базовой технологии Java. Это предложения, как правило, для улучшений, которые еще не готовы к уточнению. Как говорится в документе JEP-0, JEP могут требовать изучения новых (даже причудливых) идей. Вообще говоря, прототипирование будет необходимо для разделения жизнеспособных и нежизнеспособных идей и уточнения их до такой степени, что можно будет разработать спецификацию.

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

Что изменилось в общем?

Некоторые из предстоящих основных функций JDK 16 включают одновременную обработку стека потоков для сборки мусора, поддержку функций языка C++ 14, возможность гибкого (elastic) Metaspace для более быстрого возврата неиспользуемой памяти в операционную систему, изменения в организации процедур, новые API и инструменты, порты операционной системы, инкапсулирование начинки JDK и некоторые другие вещи.

JEP 397: Изолированные классы (sealed classes) становятся еще более изолированными:

Об изоляции классов речь шла ранее в JDK 15. Именно в рамках 15-го релиза были предложены и поставлены изолированные классы (sealed classes) в качестве preview feature. Напомним, что концепция изолированных классов предусматривает ограничение возможности их расширения или выполнения для других классов. Фактически это означает запрет наследоваться от данного класса.

https://openjdk.java.net/jeps/397

Для чего:

Разрешить разработчику класса или интерфейса самому контролировать, какая часть кода будет отвечать за его реализацию

Предоставить более удобный и понятный способ, чем модификаторы доступа (access modifiers), для ограничения использования суперклассов.

Поддержать дальнейшее развитие паттерн матчинга (pattern Matching), предоставив фундамент для полного анализа паттернов.

Что это означает и к чему приведет?

В JLS придется описывать контекстные ключевые слова (contextual keyword), которые заменят введенные ранее идентификаторы и ключевые слова типа (estricted keyword и restricted identifier). Для этого вам следует ввести набор изолированных и неизолированных последовательностей символов и разрешить их применять в качестве контекстуальных ключевых слов в вашей среде разработки.

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

JEP 396: Инкапсуляция внутри JDK теперь стала строгой:

Строгая инкапсуляция всех внутренних элементов JDK теперь будет по умолчанию. Ну, за исключением таких критических внутренних API, как sun.misc.Unsafe. Однако теперь можно разрешить пользователям выбирать ослабленный тип наследования deny. Речь идет об опции --illegal-access, которая до была "permit", а с 16-й JAVA становится "deny".

https://openjdk.java.net/jeps/396

Для чего:

Повысить безопасность и ремонтопригодность JDK, как части Project Jigsaw, и призвать разработчиков перейти от использования внутренних элементов JDK к стандартным API, чтобы они и конечные пользователи могли легко перейти к использованию дальнейших версий Java.

Комментарии:

Этот JEP несет в себе риск того, что существующий код Java не будет запущен. Разработчикам рекомендуется использовать инструмент jdeps для идентификации кода, который опирается на внутренние элементы JDK, и при наличии переключаться на стандартные замены.

Разработчики могут использовать существующую версию, такую как JDK 11, для тестирования существующего кода с помощью using-inlegal-access = warn для идентификации внутренних элементов, к которым осуществляется доступ с помощью отражения, -llegal-access = debug для обнаружения ошибочного кода и-inlegal-access = deny testing.

Что изменилось:

1. Доступ к защищенным членам классов и статический доступ к неэкспортированным API (sun.*,com.sun.*,jdk.internal.*и т. д.) теперь будет давать ошибку.

2. Если код требует доступа к внутренностям JDK во время выполнения, то, чтобы он отработал на Java 16, ему теперь придется явно указывать одну из трех опций JVM:

--illegal-access=permit/warn/debug: открытие всех пакетов JDK

--add-opens=module/package=target-module: открытие одного пакета

--add-exports=module/package=target-module: экспортирование одного пакета (только для статического доступа).

EP 395: Записи:

Записи были ранее введены в ответ на жалобы, что Java была слишком громоздкой из-за большого количества формальных шаблонов или паттернов. О записях шла речь ранее и предварительно они были представлены в JDK 14 и JDK 15. Теперь можно свободно расширять язык программирования Java с помощью записей, которые являются классами, выполняющими функции прозрачных носителей неизменяемых данных. Записи можно рассматривать как именные кортежи.

https://openjdk.java.net/jeps/395

Для чего:

Запись - это объектно-ориентированная конструкция, которая выражает простую агрегацию значений.

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

Автоматически внедрять методы, управляемые данными, такие как equals и accessors.

Защитить первоначальные принципы Java, такие как номинальная типизация и совместимость с миграцией.

Что изменилось:

Так как какого-то более-менее внятного описания разработчик JDK никогда не предоставляет, нами опытным путем было установлено, что в Java 16 было внесено следующее изменение: теперь во внутренних классах разрешено объявлять статические члены.

JEP 394: Возможность сопоставления паттернов для экземпляра:

Данный JEP означает введение паттерна для оператора instanceof. Идея эта окончательно завершена в JDK 16, хотя ранее предварительно рассматривалась в релизах JDK 14 и JDK 15.

https://openjdk.java.net/jeps/394

Для чего:

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

Что изменилось:

Фактически это означает введение паттерна для оператора instanceof.

JEP 393: API доступа к Foreign Memory (третий инкубатор):

API доступа к Foreign Memory, который ранее инкубировался как в JDK 14, так и в JDK 15, будет повторно инкубироваться в JDK 16 со значительными улучшениями. При этом функции интерфейсов MemureSegment и MemureAddresses стали различаться более четко.

По факту данный API - это API доступа к внешней памяти, который позволяет Java-программам безопасно получать доступ к памяти за пределами "Java-кучи" (heap java).

Многие Java-программы получают доступ к ~~зарубежной памяти~~ Foreign Memory, например, Ignite, mapDB, memcached, Lucene и API ByteBuf от Netty. К сожалению, Java API на данный момент не обеспечивал удовлетворительного решения для доступа к Foreign Memory.

https://openjdk.java.net/jeps/393

Для чего:

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

Теперь несколько процессов могут одновременно использовать память.

Сериализация и десериализация содержимого памяти путем преобразования файлов в память (например, через mmap).

Что изменилось

Фактически это означает введение паттерна для оператора instanceof. Идея эта завершена в JDK 16, хотя ранее была предварительно рассмотрена в JDK 14 и JDK 15.

JEP 392: Упаковочный инструмент теперь стал постоянным модулем:

Jpackage был реализован ранее в качестве инкубационного инструмента в JDK 14, таковым он оставался и в JDK 15. С JDK 16 jpackage получает права постоянного модуля.

Инструмент jpackage нужен для упаковки автономных средств Java. Многие Java-программы теперь получат доступ к foreign memory, например, Ignite, mapDB, memcached, Lucene и API ByteBuf от Netty. К сожалению, Java API так и не обеспечивает удовлетворительного решения для доступа к Foreign Memory.

https://openjdk.java.net/jeps/392

Для чего:

Поддерживать собственные форматы упаковки, более привычные конечным пользователям, ведущим разработку для различных операционных систем. В Windows этими форматами являются msi и exe, на macOS - pkg и dmg, а также на Linux - deb и rpm.

Позволить указывать параметры времени запуска во время упаковки.

Разрешить использовать API-интерфейс ToolProvider для непосредственного вызова из командной строки.

Что изменилось:

jpackage получает права постоянного модуля

JEP 390: Warning для value-based классов:

Ситуация: объявите классы-оболочки примитивных типов (integer, double и прочее), а затем удалите их конструкторы. Что произойдет? Вы увидите, что в JAVA 16 это приведет к новым предупреждениям, о попытке неправильной синхронизации экземпляров классов на основе значений платформы Java.

https://openjdk.java.net/jeps/390

JEP 389: Foreign Linker API:

Произведена попытка создать внешний API компоновщик, который обеспечивал бы статический, доуступ через Java к нативному коду.

Этот API будет находиться на стадии инкубатора в JDK 16. Вместе с предлагаемым API доступа к Foreign Memoryчерез API внешнего компоновщика значительно упрощается методика связывания с собственными библиотеками, а также выбросом собственных ошибок.

https://openjdk.java.net/jeps/389

Цель:

Обеспечить простоту в использовании java. Теперь можно заменить JNI новой моделью разработки на языке чистой Java.

Обеспечить поддержку языка C : первоначальный объем данного проекта направлен на то, чтобы предусмотреть высококачественную, полностью интегрированную совместимость с библиотеками C на платформах x64 и AArch64.

API Foreign Linker и его реализация должны быть достаточно универсальными для размещения в дальнейшем на других платформах различной разрядности (например, 32-разрядных x86) и прочих "внешних" функций, написанных на языках, отличных от C (например, C++, Fortran).

Обеспечить эффективность: International Linker API должен обеспечивать производительность, сравнимую или лучшую, чем JNI.

JEP 347: Включение языковых функций C++ 14

Теперь можно включать использование функций языка C++ 14 в исходном коде JDK. Не только включать, но и предоставить четкие инструкции по использованию этих функций в коде HotSpot.

https://openjdk.java.net/jeps/347

Для чего:

Думаю, тут и так все ясно. Возможности C++14 уникальны для многих задач.

JEP 357: Миграция из Mercurial в Git:

Этот вопрос давно назрел и вот свершилось. Можно теперь делать перенос репозитория исходного кода OpenJDK Project из Mercurial (hg) в Git .

https://openjdk.java.net/jeps/357

Для чего:

Ожидаются преимущества в размере и доступных ресурсах через хостинг системы управления версиями.

JEP 369: Миграция на GitHub:

Предлагается репозиторий Host Git для сообщества OpenJDK на GitHub.

https://openjdk.java.net/jeps/369

Для чего:

Чтобы можно было перемещать все проекты OpenJDK с одним исходным кодом на GitHub вместе с JEP 357 (Migrate from Mercurial to Git) и включить все версии JAVA 11 и более поздние обновления JDK и JDK, а также их модернизации.

JEP 376: ZGC: параллельная обработка стека потоков:

Переход потокового стека ZGC от safepoints к "параллельной" фазе.

https://openjdk.java.net/jeps/376

Z Garbage Collector (ZGC) предназначен для того, чтобы оставить все проблемы с масштабируемостью в HotSpot при сборке мусора ушедшими в прошлое. На сегодняшний день операции GC, масштабирующие размер кучи и размер метапространства, были перенесены из операций с safepoints в "параллельные" фазы.

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

Для чего:

o Удалить обработку стека потоков из safepoints ZGC.

o Сделать обработку стека удобной и упорядоченной.

o Удалить всю лишнюю корневую обработку для каждого потока из safepoints ZGC.

JEP 386: Alpine Linux Port:

Порт JDK к архитектурам x64 и AArch64 в Alpine Linux и других дистрибутивах Linux, использующих библиотеку musl.

Musl - это реализация для систем на базе Linux стандартных библиотечных функций, описанных в стандартах ISO C и POSIX. Несколько дистрибутивов Linux, включая Alpine Linux и OpenWrt, основаны на musl.

Из-за небольшого размера образа Alpine Linux широко используется в облачных развертываниях, микросервисах и средах контейнеров. Размер картины Docker для Linux меньше 6 МБ. В таких средах использование Java в нестандартных средах позволит Tomcat, Jetty, Spring и другим общим рамкам работать в этих средах. Пользователь может построить изображение еще меньшего размера, оптимизированное для выполнения конкретного приложения, используя jlink для минимизации размера среды выполнения Java.

JEP 387: Elastic Metaspace:

Более эффективное возвращение в операционную систему неиспользуемой оперативной памяти, уменьшение метапространства и упрощение кода метапространства для снижения затрат на обслуживание.

В Метакосмосе возникли проблемы с высоким использованием памяти вне кучи. Предложение включает схему распределения на основе Бадди для замены текущего распределителя памяти и включает алгоритм разделения памяти на разделы для удовлетворения запросов памяти.

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

JEP 388: Windows/AArch64 Порт:

Подключите JDK к платформе Windows/ AArch64.

Windows/ AArch64 стала значительной платформой на основе спроса с появлением нового оборудования серверного класса и потребительского AArch64 (ARM64). Основной целью этого предложения является включение порта в основное хранилище JDK, хотя само портирование остается в основном полным.

Подробнее..

Категории: Java , Блог компании accenture , Jdk16

7 уроков по итогам разворачивания SAP HANA на базе MS Azure для российской компании

24.08.2020 16:22:46 |

Автор: admin

Уже более 10 лет назад в Microsoft объявили о доступности платформы Azure для широкой аудитории пользователей. За это время преимуществами облачной инфраструктуры для решения текущих задач ИТ захотели воспользоваться многие компании. Некоторые из них обращались к нам за консультацией по разворачиванию систем в облаке. Но время шло и вот уже бизнес рассматривает возможность размещения в облаках таких ресурсоемких систем, как SAP HANA. Мы в свою очередь, уже реализовали несколько аналогичных проектов и готовы поделиться теми наблюдениями, которые могут обеспечить более успешное размещение системы SAP в облаке MS Azure. Некоторые наблюдения не будут открытием, но нам хотелось показать применимость некоторых подходов именно в условиях облачной платформы. Основными усвоенными уроками хотим поделиться с вами.

1: Последовательная оптимизация ИТ архитектуры при использовании облака

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

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

Microsoft обеспечивает поддержку SAP только на ВМ серии М. Использование тестовых ресурсов аналогичных продуктивной среде по уровню поддержки на этапе первоначальной разработки избыточно.
В тоже время тестовые машины E-серии обладают схожими характеристиками с M-серией, но их стоимость существенно меньше. В итоге заменили виртуальные машины М серии на другую серию. Обратной стороной этой замены является переход ответственности за работу системы в тестовых средах с провайдера на интегратора. Это налагает на интегратора необходимость иметь экспертные компетенции в области SAP.

2: Как сэкономить на потреблении ресурсов

MS Azure позволяет существенно экономить при резервировании ресурсов с одновременным предоплатой на один или 3 года.
Зачастую на начальном этапе заказчик не может точно оценить дату запуска продуктивной системы, так как ее разработка и тестирование зачастую связаны со многими переменными, находящимися на стороне бизнеса или подрядных разработчиков.
Например, на момент запуска одного из проектов мы планировали одновременное развертывание всех сред на основе текущих планов Заказчика. Как это часто бывает, разработка потребовала более длительных согласований с бизнесом, что привело к отложенному старту продуктивного запуска на несколько месяцев.
В этом примере при резервации ресурсов с предоплатой Заказчик потерял бы существенный объем средств. Резервировать ресурсы, конечно, нужно, но зачастую существенно позже старта проекта, когда основной объем продуктивной системы стабилизировался, а разработка станет предсказуемой в плане потребления ресурсов. Зачастую при резервации вычислительных ресурсов на 3 года можно получить около 70% экономии средств по сравнению с Pay-As-You-Go методом оплаты.

3: Как выбрать регион Azure

Azure обладает широким списком регионов для размещения ресурсов. Один из основных критериев выбора региона удаленность вашей инфраструктуры от конечных пользователей, что влияет на отклик системы и работу интеграций и конечных пользователей.
Вторым, не менее важным, критерием является список сервисов в том или ином регионе. Некоторые сервисы доступны в зависимости от региона. Очень часто сервисы перед официальным выходом предоставляются в виде preview. Некоторые регионы быстрее внедряют новые технологии и дают опробовать тот или иной появившийся сервис. Не все регионы предоставляют возможность использования весь ассортимент серий виртуальных машин.
В нашей практике сравнение скорости доступа преимущество зачастую показывает региона Западная Европа. Особенно это заметно для компаний чьи сервера и клиенты расположены в европейской части России. В каждом конкретном случае, и особенно если ваши ЦОД и клиенты расположены на Дальнем Востоке, имеет смысл проверить задержки из своего ЦОД (либо из того географического региона, где расположены ваши клиенты) для выбора лучшего региона Azure.

Такие сервисы как Azure Latency Test позволяют заранее проверить задержки до каждого из регионов Azure из сети вашего ЦОД. Пример результатов измерения задержке при помощи упомянутого сервиса при тестировании из нашего московского офиса:

4: Как применять к облачным инсталляциям методы, проверенные на земле

В каждой миграции мы задаемся вопросом о том как мы можем использовать в облаке традиционные решения, проверенные классической инфраструктурой. В частности, при подготовке решения мы опираемся на рекомендации вендора для разработки технически верного решения. Проекты на SAP HANA не являются исключением и тоже проходят через призму рекомендаций и лучших практик.
На одном из проектов при реализации первого этапа решения, был развернут Jump сервер на базе Windows. Для оптимизации затрат начального этапа разработки на том же сервере был развернут и NFS сервер для нужд непродуктивных сред, что закрывало текущие потребности разработчиков и позволяло существенно сэкономить на ресурсах.

Время шло, среды и потребности в ресурсах росли, а NFS сервер справлялся со всеми поставленными задачами. Постепенно в рамках проекта мы приблизились к исчерпанию ресурсов начальной ВМ. Ресурсы ВМ в MS Azure можно увеличить за минуты, но параллельно повысились требования к отказоустойчивости сервера, что заставило рассмотреть более масштабную реконфигурацию.
Для реализации был использован Linux сервер, сервис DRBD и функционал Availability set, которые закрыли вопрос репликации данных между нодами кластера NFS и повысили доступность на случай выхода из строя одной из двух нод кластера.

К слову сказать: через пару месяцев после внедрения кластерного решения в Azure добавили сервис NetApp Files, который позволяет воспользоваться преимуществами массивов NetApp, но оплачиваемыми по модели Pay-As-You-Go.

5: Как автоматизировать график работы ВМ

При использовании любой облачной инфраструктуры всегда имеет смысл проанализировать какие дополнительные механизмы могут быть использованы для максимальной экономии средств.
В нашем случае тестирование систем происходит в рабочее время. Если в обычной инфраструктуре простаивание серверов выливается преимущественно в повышенные счета за электроэнергию, то в облаке сервера не приносящие пользу потребляют финансы за аренду мощностей. Мы оценили графики нагрузок на серверах тестирования и разработки и обратили внимание что подавляющая часть разработчиков и тестировщиков используют систему по рабочим дням с 8-00 до 20-00.

В тех случаях, когда график нагрузки на непродуктивные системы предсказуем и цикличен мы стараемся применять скрипты автоматизации включения-выключения ВМ. В Azure есть несколько инструментов: Auto-Shutdown, Automation Accounts и Cloud Shell. Мы используем их не все. Auto-shutdown исключили потому что он умеет только выключать ВМ. Cloud Shell тоже не задействовали так как для него нужно готовить дополнительные скрипты, разрабатывать графики и где-то всё это безопасно хранить с наличием резервирования, что сводило экономию до минимума.

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

Мы подготовили графики для соответствующих ресурсов, загрузили Runbooks и сформировали связи между графиками и ресурсами.

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

Мониторинг потребления ресурсов

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

7: Подстраховка на случай форс-мажоров

Многие компании опасаются размещать свои ИТ системы на облачных ресурсах из-за боязни блокировок, которые ранее точечно проводились регуляторами. Как и любой другой риск этот тоже может быть учтен при проектировании системы. В проектах мы, как правило, реализуем еженедельную выгрузку бекапов системы из облака в ЦОД Заказчика. Это позволяет быть уверенными в том, что система может быть восстановлена при любом развитии событий. В дополнении к этому мы применяем стратегию мультиоблачной инсталляции, которая позволит в случае ограничения доступа не остаться без доступа к ресурсам. В данном сценарии альтернативные облачные провайдеры используются как DR сайты основного облака, что позволяет восстановить доступность системы в случае масштабных блокировок.

7+: Обработка персональных данных

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

Итоги

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

Подробнее..

Категории: Облачные сервисы , Cloud , Microsoft azure , Azure , Sap , Облако , Блог компании accenture

SalesforceApex как первый язык программирования. Плюсы и минусы

18.01.2021 18:09:31 |

Автор: admin

Моимпервым языком программирования сталApex.ЭтоJava-подобный язык, который автоматизируетbackend-логику в приложения на платформеSalesforce.com.

Нельзя сказать, что я до этого не был знаком с ООП или другими языками.Мое знакомство ограничивалось теоретическими знаниями,полупройденнымикурсами наCodecademyили лабораторными работами в институте.Естественным образом все тонкости технологии, синтаксис языка,его возможностии ограничениябыстро выветривались из памяти, поскольку практического применения этим навыкам я не находил.

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

Сейчасмойопыт разработкинаApexокологода, я стал сертифицированным разработчикомSalesforce.Могу подвести первые итоги.

Будет полезно для:

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

Ниже я кратко приведу все плюсы и минусы Apex, с точки зрения выбора его как языка для обучения. Затем подробнее рассмотрю каждый пункт.

Плюсы Apex:

Apexприучает к написанию оптимального,ресурсоэффективногокода
Apexприучает кюнит-тестированию и кtest-drivenразработке
Apexимеетединую и обновляемую документацию, собранную на порталеSalesforce
Apexимеетout-of-the-boxдоступкБД(ненужно писать коннекторов)
Apexэто на 90%Java.Вы с легкостью сможетепониматьJava-кодпосле разработки наApex
Salesforceпоставляет собственную онлайнIDEDeveloperConsole,которая позволяет новичку быстро начать программировать без погружения вмиркастомныхIDE
Apexможно осваивать вTrailhead-песочницах,без установки и настройки дополнительного софта.
Trailheadобучает программированию наApexс полного нуля.Trailhead-модули обучают вас концепциям ООП и синтаксисуApexна языке простых смертных (к сожалению, только на английском)

Минусы Apex:

Мало материалов на русском языке (почти нет)
Немногочисленное русскоязычное сообщество
Применимость только для продуктов на платформеSalesforce

Apexприучает к написанию оптимального,ресурсоэффективногокода

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

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

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

Apexприучает к юнит-тестированию и кtest-drivenразработке

Покрытие кода юнит-тестами на 75%обязательное условиедля переноса этого кода наPROD-среду.Поэтомувы с самого начала учитесьсоздавать тест-классы. Это полезный навыкменятьментальный ракурс, с которого вы смотрите на свой код,таким образом, чтобынаписать тест.

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

Пример класса и тест-классавApex

Класс:

public class TVRemoteControl {     // Volume to be modified     Integer volume;     // Constant for maximum volume value     static final Integer MAX_VOLUME = 50;              // Constructor     public TVRemoteControl(Integer v) {         // Set initial value for volume         volume = v;     }              public Integer increaseVolume(Integer amount) {         volume += amount;         if (volume > MAX_VOLUME) {             volume = MAX_VOLUME;         }          return volume;     }          public Integer decreaseVolume(Integer amount) {         volume -= amount;         if (volume < 0) {             volume = 0;         }           return volume;     }              public static String getMenuOptions() {         return 'AUDIO SETTINGS - VIDEO SETTINGS';     }         }

Тест-класс:

@isTest class TVRemoteControlTest {     @isTest static void testVolumeIncrease() {         TVRemoteControl rc = new TVRemoteControl(10);         Integer newVolume = rc.increaseVolume(15);         System.assertEquals(25, newVolume);     }          @isTest static void testVolumeDecrease() {         TVRemoteControl rc = new TVRemoteControl(20);         Integer newVolume = rc.decreaseVolume(15);         System.assertEquals(5, newVolume);             }               @isTest static void testVolumeIncreaseOverMax() {         TVRemoteControl rc = new TVRemoteControl(10);         Integer newVolume = rc.increaseVolume(100);         System.assertEquals(50, newVolume);             }          @isTest static void testVolumeDecreaseUnderMin() {         TVRemoteControl rc = new TVRemoteControl(10);         Integer newVolume = rc.decreaseVolume(100);         System.assertEquals(0, newVolume);             }          @isTest static void testGetMenuOptions() {         // Static method call. No need to create a class instance.         String menu = TVRemoteControl.getMenuOptions();         System.assertNotEquals(null, menu);         System.assertNotEquals('', menu);     } }

Apexимеетединуюиобновляемуюдокументацию,собраннуюнапорталеSalesforce

SalesforceразвиваетApexкак основной язык для разработки на своей проприетарной платформе, поэтому всеобновления и вся документация содержатся на едином официальном порталеApex DeveloperGuide.

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

Apexимеетout-of-the-boxдоступкбазе данных

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

Вот несколько примеровобращения к базе данных из кода:

Account A = new Account(Name='xxx');insert A;Account B;// A simple bindB = [SELECT Id FROM Account WHERE Id = :A.Id];// A bind with arithmeticB = [SELECT Id FROM Account      WHERE Name = :('x' + 'xx')];String s = 'XXX';// A bind with expressionsB = [SELECT Id FROM Account      WHERE Name = :'XXXX'.substring(0,3)];// A bind with an expression that is itself a query resultB = [SELECT Id FROM Account     WHERE Name = :[SELECT Name FROM Account                    WHERE Id = :A.Id].Name];Contact C = new Contact(LastName='xxx', AccountId=A.Id);insert new Contact[]{C, new Contact(LastName='yyy',                                     accountId=A.id)};// Binds in both the parent and aggregate queriesB = [SELECT Id, (SELECT Id FROM Contacts                 WHERE Id = :C.Id)     FROM Account     WHERE Id = :A.Id];// One contact returnedContact D = B.Contacts;// A limit bindInteger i = 1;B = [SELECT Id FROM Account LIMIT :i];// An OFFSET bindInteger offsetVal = 10;List<Account> offsetList = [SELECT Id FROM Account OFFSET :offsetVal];// An IN-bind with an Id list. Note that a list of sObjects// can also be used--the Ids of the objects are used for // the bindContact[] cc = [SELECT Id FROM Contact LIMIT 2];Task[] tt = [SELECT Id FROM Task WHERE WhoId IN :cc];// An IN-bind with a String listString[] ss = new String[]{'a', 'b'};Account[] aa = [SELECT Id FROM Account                 WHERE AccountNumber IN :ss];

Apexэтона90%Java.Вы с легкостью сможете пониматьJava-код после разработки наApex

SalesforceсоздавалаApexна основе синтаксисаJava.Есть небольшие исключения, обусловленные спецификойSalesforce.Все отличия собраны на этой странице.

Но,если посмотреть на методы работы с примитивамии коллекциями, то они работают аналогичноJava.

Сравните, к примеру, методы работы соStringвApexиString в Java.

Выходит, что обучаясьApexвы во многом обучаетесь иJava.Это правило работает и наоборот.

Если вы решите перейти вJava-разработчики,вам не придется начинать с нуля. А полезные парадигмы мышления изApex-разработки дадут вам хороший фундамент длянаписанияресурсоэффективногоJava-кода.

Salesforceпоставляет собственную онлайн IDEDeveloperConsole

Developer Console позволяет новичку быстро начать программировать без погружения в миркастомныхIDE.

Я помню,какраньше делал попытки самостоятельноучитьPython,C#. Иначинать нужно было с установкиIDE, ее настройки. Разобраться,как работает этаIDEотдельнаяистория. Много папок, много кнопок, много пунктов меню, много панелей.Это было серьёзным барьером на пути начинающего разработчика.

СApexничего подобного не было, поскольку любой инстансSalesforceсодержит в себевстроеннуюIDE, которая называетсяDeveloperConsole.Устанавливать ничего не нужно, достаточно открытьв браузереDeveloperConsoleи сразу писать код.Код можно запустить сразу и проверить его работу в реальном(или песочном)приложении.

Да, более опытные разработчикиSalesforceпредпочитают работать вVisualStudioCodeилиEclipse,но дляначинающихDeveloperConsoleто, что нужно.

DeveloperConsoleвыглядит так:

Apexможно осваивать вTrailhead-песочницах, без установки и настройки дополнительного софта

Salesforceразработал собственную платформу для обученияtrailhead.salesforce.com.Она великолепна геймификацией процессаобучения и тем, что создавать тестовые среды можно непосредственно со страницы практического задания:

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

Trailheadобучает программированию наApexс полного нуля

ВTrailheadмножество обучающих модулей и троп (последовательностей модулей).Главный плюс для начинающего в том, чтодля обучения программированию можно выбрать тропу,которая предназначена дляучеников с нулевым опытом или только садминскимопытом.В таком случае обучение начнется с самых основ ООП,а в качестве примеров будет использоватьсяApex-код.

Примеры обучающих модулей по разработке на Apex для администраторов

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

Текст часто снабжается забавными примерами и просто шутками. Типичный пример на рисунке ниже:

В изученииApexесть и минусы.Ниже рассмотрю их подробнее.

Мало материалов на русском языке (почти нет)

На русский язык не переведенытакие официальные ресурсы, как:

Это затрудняет обучение ребятам, которые не знают английский язык.

Немногочисленное русскоязычное сообщество

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

Надо заметить, чтов Беларуси разработка наSalesforceстремительно популяризуется. В русскоязычномYoutubeпоявляется всё больше качественных видео проSalesforceиApex(пример). Количествоспециалистов растёт, но работы всё ещё больше, чем людей.

Этот минус можноконвертировать в преимущество вас как специалиста на рынке труда. Чем меньшеспециалистов, тем они дороже.

Применимость только для продуктов на платформеSalesforce

В отличие отJava,Pythonи других кроссплатформенных языков,Apexможет использоваться только для разработки на платформеSalesforce.com.Несмотря на многообразие продуктовSalesforce, вы ограничены этим стеком.

Заключение

Apexпрекрасно подходитдля обучения программированию.Правила и рекомендацииSalesforceс самого начала научат вас лучшим практикам ООП, которыеприменимы к коду на любом другом языке.

Однако,лучшепосмотреть в сторону других языков для старта, если:

Вы не планируете профессионально развиваться вкачестве специалистаSalesforce;
Вы плохо владеете английским языком. Это затруднит вам изучение любого языка программирования, ноApex- в особенности.

Подробнее..

Категории: Crm-системы , Облачные вычисления , Salesforce , Блог компании accenture , Apex , Salesforce.com , Accenture

	Русский
	English