Русский
Русский
English
Статистика
Реклама

Анализ и проектирование систем

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

14.11.2020 12:04:35 | Автор: admin

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

Делимся записью эфира и расшифровкой.




Меня зовут Алексей Лобзов, я являюсь главным системным аналитиком в компании Альфа-Банк. Я одновременно выполняю роль технического лидера аналитиков корпоративного направления нашего банка.

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

Есть ли какое-то официальное определение системного аналитика и его области ответственности?


Это роль на проекте, в продукте или компании, или профессия/должность?
Системный аналитик это профессия. На сайте Минтруда есть раздел Справочник профессий, где можно найти профессию системного аналитика и прочитать, в чем состоит ее описание. Также с этой страницы можно перейти на профессиональный стандарт и узнать, какие функции ожидаются от человека этой профессии.

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

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


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

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

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

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

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

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

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

Я хотел поделиться конкретно с сообществом аналитиков, и передо мной встала задача: найти такое сообщество. Я поспрашивал у коллег из Альфы; мне сказали, что есть популярная конференция аналитиков Analyst Days. Она проходит каждый год, и можно пойти туда и выступить, или хотя бы поучаствовать, узнать какие-то интересности, которые можно будет потом применить в работе.

Я начал анализировать возможность посещения этой конференции и как спикер, и как обычный участник; в итоге я пришел к выводу, что эта конференция мне не подходит. Этому было две причины: во-первых, в моем понимании, на конференцию приходят серьезные люди с серьезными темами, и участники платят за то, чтобы послушать их и задать вопросы. Во-вторых, я просто не был готов платить за билет участника; у меня был пример Московское сообщество разработчиков на Python (Moscow Python Meetup), которое ежемесячно проводит митапы со свободным входом. Там можно бесплатно прийти, послушать спикера, задать вопрос, пообщаться с питонистами, съесть пиццу в пицца-паузе; если у тебя есть тема, то ты можешь самостоятельно записаться, заявить тему перед оргкомитетом, и, если тема подходящая, тебя с высокой вероятностью включат в план выступлений. Поэтому я стал искать что-то похожее на MPP, но для сообщества аналитиков.

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

Время шло; потребность в сообществе осознал не только я, но и мои коллеги из Альфы. В 2018 году родилась внутренняя инициатива: создать собственные митапы для аналитиков.

Мы собрались с коллегами и создали митап AnalyzeIT: первый раз он прошел 20 сентября 2018 года. В 2019 году было еще два митапа, мы планировали проводить их раз в полгода. В том же году прошел митап от сообщества аналитиков Райффайзенбанка я узнал о нем от коллег из Райфа, которые предложили мне поучаствовать в качестве докладчика. Я не мог отказать; таким образом, я узнал про новое сообщество системных аналитиков, которое мне подходило. Со временем, с моим ростом, с приобретением новых знаний, с общением внутри сообществ я стал узнавать о новых и новых площадках, на которых можно было обмениваться опытом, заводить контакты, организовывать проекты, даже искать новую работу. Из таких площадок я могу выделить Открытый митап для аналитиков: он проходит онлайн, недавно прошла первая встреча, и следующая планируется на 26 ноября. Его идея состоит в том, что, на самом деле, сообществ аналитиков по России очень много; если брать региональную разбивку они есть в Москве, Петербурге, Екатеринбурге, Перми, других городах, и требовалась площадка, на которой люди из разных сообществ могли бы коммуницировать друг с другом.

Как я уже сказал, 26 ноября будет вторая встреча этого сообщества IT Analyst Online Meetup. Если вам интересно зарегистрируйтесь; думаю, она пройдет полезно.

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


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

Я рассказал, что есть несколько митапов для аналитиков, где можно свободно выступить, задать вопрос спикеру, пообщаться с членами сообщества. Помимо митапов, есть и другие площадки; сейчас очень популярны телеграм-группы: у того же Райффайзенбанка есть группа для системных аналитиков, я в ней состою. Там, хотя и не так часто, появляются вопросы, и сообщество с удовольствием предлагает варианты решения проблем. Группа называется Open SA Community Raiff; если вам интересно, тоже заходите. Как пример вопроса: недавно заходила девушка и писала, что работает в системном анализе, но чувствует, что в знаниях не хватает структуры, общей методологии аналитика. Она спрашивала мнения сообщества о том, как получить такую структуру; с одной стороны, можно пойти получить высшее образование, с другой сейчас есть много онлайн-курсов, в том числе и по системному анализу, и, возможно, стоит идти туда. А, возможно, стоит попросить руководителя или лида побыть ментором и помочь прокачать аналитику. Различные варианты, возможности; в сообществе как раз и обсудили, что может быть лучшим вариантом.

На митапах можно найти работу джуном?


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

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

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

Чем бизнес-аналитик отличается от системного?


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

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

Используется ли вы EPС, или достаточно UML и BPMN?


Если мы говорим про то подразделение, в котором работаю я, то в архитектурных и технических документах мы используем все эти нотации. UML Sequence наверно, наиболее популярные. EPC мы используем в архитектурных документах, при описании функциональных моделей процессов. BPMN я лично еще не использовал его, но некоторые коллеги в Альфе используют в описании архитектурных документов.

Если аналитик ищет в enum переменные на C# и сопоставляет их с документацией это не слишком ли большой отход от обязанностей системного аналитика?


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

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

Что лучше использовать для верхнеуровневого проектирования системы? Компонентную диаграмму или диаграмму deployment?


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

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

Что, если вы просмотрели множество сообществ, но не нашли ничего для себя? Вам все еще хочется поделиться информацией с другими или узнать, чем занимаются коллеги из других профессиональных сообществ. В этом случае вы свободны в выборе сообщества из другой области. Например, вы можете посетить сообщество разработчиков, посмотреть, чем они занимаются. Или сообщество тестировщиков, или QA-инженеров и обменяться опытом там. Я достаточно долго ходил на митапы сообщества питонистов, мне было там интересно; я даже задумывался о том, чтобы стать разработчиком на Python. Также я участвовал в старте сообщества QA-инженеров компании Додо Пицца. Это было в 2018 году; ребята только начинали свои митапы, прошел один митап и готовился второй в феврале. Они искали спикеров и предложили мне выступить с докладом несмотря на то, что я не являюсь QA-инженером и отношение к тестированию имею опосредованное, только с точки зрения аналитика.

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

Также я хотел упомянуть об организации собственного сообщества. В чем проблема: вы можете пройтись по существующим сообществам, посмотреть сообщества смежных направлений, но вас ничего не устроит; вы видите для себя определенную нишу и готовы запустить собственное сообщество. Если у вас такая ситуация это хороший опыт; вы можете попробовать войти в эту историю и, возможно, из этого что-то вырастет. На примере Альфы как я уже говорил, мы запускали собственное сообщество, свои митапы AnalyzeIT. У нас было всего три митапа. Как мы их запускали: у нас была команда аналитиков, которые отвечали за контент, и команда из отдела развития бренда, которая отвечала за организацию помещения, привлечения участников и слушателей и за организацию бургер-пати (потому что какой митап без бургер- или пицца-пати; очень важный компонент можно перекусить и пообщаться с коллегами, которые пришли на мероприятие). Организация первого митапа потребовала много времени; мы тщательно готовились, отобрали несколько докладов и 3-4 недели проводили их репетиции. Была безумная подготовка, потом выступили и выдохнули. Остальные митапы были полегче, потому что мы получили опыт, но первый был самым сложным и запоминающимся.

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

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

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

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

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

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

Например, статей о том, какие типа разработчиков на Python бывают и чем они отличаются, нет; понятно, что среди них есть такие, кто занимается разработкой софта, или аналитикой данных с использованием Python для анализа, но статей с разделением их на типы я не встречал. Наверно, с этой специальностью-профессией все понятно, а вот с аналитиками нет.

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

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

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

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

Следующий поинт откуда приходят в аналитику и куда уходят из неё; это пересекается с одним из вопросов из зала: какая следующая ступень после системного аналитика.

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

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

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

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

Чем отличается старший аналитик от ведущего?


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

Расскажите про микросервисную архитектуру


Да, в Альфе используется микросервисная архитектура. У нас есть как монолитные, так и микросервисные системы. Мы идем в микросервис.

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

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

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

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

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

СОА или монолит?


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

Как эффективно найти работу начинающему системному аналитику?


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

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

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

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

На что смотрят при приеме джуна на работу, какой минимум нужен?


Вопрос непростой, потому что до недавнего времени в Альфе начальная позиция называлась старший системный аналитик. Она подразумевала, что в центр компетенции приходит не джун, а опытный специалист с определенным набором знаний и умений. Просто джунов мы не брали. Были стажерские программы (я уже рассказывал про свою знакомую); там было собеседование и задачи в частности, на SQL. Я думаю, если вы ищете джуниорскую работу, то надо почитать, что обычно спрашивают на джуниорские позиции. Моей знакомой знаний из института и предварительной подготовки по SQL оказалось достаточно.

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

Что является результатом работы системного бизнес-аналитика, с вашей точки зрения?


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

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


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

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

Если же вам нравится погружаться в технику, если у вас есть интерес и вы готовы читать код, учиться писать автотесты для того, чтобы понимать, как работают ваши QA-инженеры и при случае помогать им, то Альфа подойдет вам. Иначе можно посмотреть другие компании. По отзывам, в Лаборатории Касперского хорошо устроены процессы системного анализа; в Райффайзенбанке тоже есть интересные задачи для аналитиков. Это спорный вопрос, конечно: компании большие, команд много, в каких-то командах может быть хорошо, в других плохо. У меня есть знакомая, которая занимается биометрией в Сбере она гордится своей командой, говорит они на высоте, они лучшие. А другие люди приходят к нам из того же Сбера и говорят, что работа скучная, релизы редкие, доступов приходится ждать месяцами. Раз на раз не приходится.

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

Для джунов главное хардскиллы, что бы вы конкретно рекомендовали?


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

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


Я бы порекомендовал, во-первых, посмотреть, что предлагают компании. Некоторые компании предлагают школы подготовки аналитиков с нуля, даже не из ИТ я рассказывал, как это было в Альфе; знакомый продажник пришел, и его подготовили. Есть онлайн-курсы, в том же самом GeekBrains (факультет системной бизнес-аналитики), SkillFactory (курс для системных аналитиков я автор этого курса и веду его) или SkillBox (курс для системных аналитиков с нуля). Есть еще Школа системного анализа это серьезный проект, он стартовал в 2011 году и до сих пор существует. Можно найти курсы, можно получить образование. Здесь есть разные варианты: можно сначала поучиться, можно получить некий опыт а онлайн-курсы позволяют выполнять кейсы и набивать портфолио и после этого пытаться устроиться по профессии.

Я рассказал, что был опыт подготовки системного аналитика с нуля это реально. Мы запускали в Альфе школу, нацеленную на то, чтобы массово готовить новых аналитиков; наш пилот закончился успехом, по результатам проведения школы у нас появились аналитики, которых мы взяли на работу. У нас было 18 учеников, которые прошли все этапы отбора. 6 из них устроились у нас в штате, то есть треть; еще один человек получил повышение в своей компании за счет новых навыков и знаний. Поэтому эта школа принесла свои плоды, и большинство ребят, пришедших в нее, не имело опыта в ИТ или смежной профессии.

Я назвал три площадки для онлайн-курсов: GeekBrains, SkillFactory, SkillBox. Я, конечно, могу порекомендовать SkillFactory, потому что являюсь автором и ведущим одного из курсов, но это было бы нечестно с моей стороны; площадок много, я до конца не знаю, что происходит на других площадках и как на них организован учебный процесс. На мой взгляд, у GeekBrains очень большая программа; если посмотреть на сайт, ребята предлагают, в том числе, обучение анализу данных и работе на Python. Я не до конца понимаю, зачем это нужно системному аналитику. На SkillBox неплохая программа, но, судя по косвенным признакам, они больше ориентированы на подготовку именно бизнес-аналитиков; если посмотреть URL-адрес ресурса с описанием системного аналитика, там написано business. Поэтому у меня есть вопросы относительно технической составляющей этого курса, но это только мое предположение; не могу сказать, хорошо ли там или плохо.

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



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
  15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
  16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
  17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
  18. Как Data Science продает вам рекламу? Интервью с инженером Unity
  19. Как я переехал в Лондон c Revolut
  20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
  21. Как организовать IT-конференцию и не сойти с ума
  22. Чем биоинформатика отличается от вычислительной биологии краткое введение




Подробнее..

Когда Cron подводит

30.11.2020 10:17:56 | Автор: admin

Привет!

У нас есть огромные ночные отчёты попродуктовым метрикам, которые с утра попадают их владельцам. Пару лет назад они собирались обычным Cron'ом, но это оказалось очень нестабильной историей. Cron требует учёта определенных нюансов и дисциплины: если отчёт не собрался, то нужно перезапустить скрипт.А не собраться он может по многим причинам: одна из MySQL-баз не ответила, или не ответил опрашиваемый сервис, или сервер, на котором работает Cron, ночью перезагружался или вышел из строя.В большинстве своём такие отчеты создавались аналитиками, которые обычно всего этого не учитывали. Потому что они аналитики и это не их задача.Поэтому мы начали искать варианты, которые упростят жизнь всем.

И нашли.

В финальном решении используется планировщик Airflow с его возможностью взаимодействия с кластером Kubernetes. Система получилась гибкая и надежная и упрощает жизнь конечным потребителям.Для разработки таких систем есть мы, техническая команда из четырёх человек, называемая Data Team, а конечные потребители аналитики,продакт-менеджеры и техлиды.

Что и как считается

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

Какие были проблемы

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

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

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

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

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

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

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

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

Повышаем надежность системы

Ограничения, вызванные ненадёжностью одиночных серверов (не только в вопросах регулярного запуска задач), давно решаются кластерными системами. У нас есть кластер Kubernetes'а.Там свой собственный планировщик,который называется CronJob. Из названия можно предположить, что принципиально он ничем не отличается от классического Cron'а. Но это не так:в первую очередь,CronJob запущен в кластере, и выход из строя одного узла не помешает запуску задач по расписанию. Для этого выйти из строя должен весь кластер, что тоже возможно, но менее вероятно. Помимо этого, Cron гарантирует запуск задачи строго один раз в указанный в расписании момент времени, согласно системным часам сервера. CronJob обещает запустить задачу "примерно" один раз согласно указанному расписанию (из документации:A cron job creates a job objectaboutonce per execution time of its schedule.Подробнее). "Примерно" означает, что в момент предполагаемого запуска задача может быть запущена более одного раза или не запущена вообще. Такое ограничение обязывает делать задачи идемпотентными. ЕщёCronJob позволяет определять политики перезапуска и конкурентного запуска задач. Про это так жеможно прочитать в документации.

Кажется, с появлением кластераKubernetes'а гарантии выполнения задач строго по расписанию всё ещё нет. Это не значит, чтоCronJob бесполезный, мы им достаточно активно пользуемся для запуска небольших атомарных задач, которые необязательны к выполнению с точностью швейцарских часов. Если задача не запустилась сейчас ничего критичного, запустится в следующий раз. Но есть задачи с более высокими требованиями к запуску, когда нужны гарантии, что задача запустится хотя бы один раз согласно расписанию, пусть и с некоторыми погрешностями во времени. Более того, запуск задачи должен зависеть от выполнения определённых предусловий, например, нужно убедиться, что какие-то предыдущие задачи, которые подготавливают данные для текущей, выполнились успешно.

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

Airflow

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

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

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

Мы от такого исхода защищены, часто логика тяжёлых задачах у нас реализована в виде отдельных сервисов, запускаемых в Kubernetes'е. Airflow предоставляетудобный механизм запускаподов, точнее, даже два: KubernetesPodOperator и KubernetesExecutor. Мы используем KubernetesPodOperator: для запуска пода необходимо иметь собранный docker-образ сервиса в кластере Kubernetes'а.

Оператор использует официальныйkubernetes-clientк API Kubernetes'а, что даёт возможность гибко конфигурировать запускаемые поды со стороны Airflow.В кластере можно завести configmap'ы или секреты, использование которых также указывается в операторе. У KubernetesExecutor'а другое предназначение: он позволяет динамически расширять мощности Airflow за счёт запуска подов, в которых будут выполняться различные операторы или набор операторов, выстроенных в ациклический граф.

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

Альтернатива KubernetesPodOperator'у

Отсутствие Kubernetes'а или даже Docker'а не ставит крест на возможностях Airflow.Какое-то время мы активно пользовались SimpleHttpOperator'ом или PythonOperator'ом, делаяhttp-запросы на урлы сервиса, запуская тем самым логику задач. Такой вариант тоже имеет право на существование, но у него есть недостатки, из-за которых мы от него решили отказаться. Первый недостаток все прокси или балансировщики перед сервисом требуют донастройки, потому что иначе запрос будет отваливаться по тайм-аутам. Этого можно избежать, сделав запуск асинхронным: запустили и, не дожидаясь окончания, считаем, что дело сделано. Но при таком подходе нет возможности использовать механизм перезапуска не выполнившихся задач Airflow. Второй недостаток из-за задачи, которая запускается раз в день или вовсе раз в неделю, приходится иметь запущенный сервис, который бОльшую частьвремени просто занимает ресурсы, не выполняя полезную работу.

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

И снова немного об отчетах

У отчётов есть один явный недостаток: они статичны и для внесения изменений необходимо править генерирующий их скрипт. С ростом объёма и качества озера данных мы стали отказываться от подхода с генерацией отчётов. Заинтересованные в продуктовых метриках лица используют BI-систему Metabase, которая предоставляет гибкий и удобный интерфейс доступа к данным в аналитическом хранилище. Но это уже совсем другая история (с).

А связкаAirflow + KubernetesPodOperator + Kubernetes продолжает активно использоваться для разного рода технических задач.

Что делать, если возникла мысль "Хочу так же!"?

Действия простые:

  1. определиться с набором текущих проблем;

  2. понять, какие именно проблемы решит усложнённая инфраструктура;

  3. ещё раз подумать, точно ли хотите;

  4. засучив рукава, начать затаскивать в окружение недостающие инструменты.
    Повторюсь, что пользу от использования Airflow можно извлечь, не имея в эксплуатации контейнеров и/или систем их оркестрирования;

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

  6. вернуться к пункту 5.

А если тема окажется злободневной, мы поделимся своим опытом и в формате "how to" подробно расскажем про реализацию разных связок сAirflow и про проблемы, с которыми мы сталкивались.

Подробнее..

Удобное логирование на бэкенде. Доклад Яндекса

28.11.2020 12:19:52 | Автор: admin
Что-то всегда идет не по плану. Приходится отвечать на вопросы, Что сломалось?, Почему тормозит? и Почему мы не увидели этого раньше?. На примере простого приложения Даниил Галиев zefirior из Яндекс.Путешествий показал, как отвечать на эти вопросы и какие инструменты в этом помогут. Настроим логирование, прикрутим трассировку, разложим ошибки, и все это в удобном интерфейсе.

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



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

Небольшой дисклеймер: я буду говорить такие слова, как ручка и локаль. Поясню. Ручка возможно, яндексовый сленг, это обозначает ваши API, http или gRPC API или любые другие комбинации букв перед APU. Локаль это когда я разрабатываю на ноутбуке. Вроде бы я рассказал обо всех словах, которые я не контролирую.

Приложение Книжная лавка


Начнем. Наш стартап это Книжная лавка. Главной фичей этого приложения будет продажа книг, это все, что мы хотим сделать. Дальше немного начинки. Приложение будет написано на Flask. Все сниппеты кода, все инструменты общие и абстрагированы от Python, поэтому их можно будет интегрировать в большинство ваших приложений. Но в нашем докладе это будет Flask.

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



Давайте немного про структуру. Это приложение с микросервисной архитектурой. Первый сервис Books, хранилище книг с метаданными о книгах. Он использует базу данных PostgreSQL. Второй микросервис микросервис доставки, хранит метаданные о заказах пользователей. Cabinet это бэкенд для кабинета. У нас нет фронтенда, в нашем докладе он не нужен. Cabinet агрегирует запросы, данные из сервиса книг и сервиса доставки.



По-быстрому покажу код ручек этих сервисов, API Books. Это ручка выгребает данные из базы, сериализует их, превращает в JSON и отдает.



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



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

Базовое логирование в приложении


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



Что нам дает Python? Четыре базовые, главные сущности:

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

Handler обрабатывает ваше сообщение, решает, куда его отправить: в стандартный вывод, в файл или кому-нибудь на почту.

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

Formatter приводит ваше сообщение к нужному виду.



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

В handlers вы можете увидеть, что logging.StreamHandler использован. То есть мы выгружаем все наши логи в стандартный вывод. Всё, с этим закончили.

Проблема 1. Логи разбросаны


Переходим к проблемам. Для начала проблема первая: логи разбросаны.

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

Теперь вопрос. Прибегает к нам менеджер и спрашивает: Там сломалось, помоги! Вы бежите. У вас же все логируется, это великолепно. Вы заходите на первую машинку, смотрите там ничего нет по вашему запросу. Заходите на вторую машинку ничего. И так далее. Это плохо, это надо как-то решать.



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

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



Решение, которое можно использовать, ElasticSearch. Давайте его попробуем поднять. Какие плюсы ElasticSearch нам даст? Это интерфейс с поиском логов. Сразу из коробки есть интерфейс, это вам не консолька, а единственное место хранения. То есть главное требование мы отработали. Нам не нужно будет ходить по серверам.

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

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



В первую очередь нам нужно будет развернуть агент, который будет отправлять наши логи в Elastic. Вы регистрируете аккаунт в Elastic и дальше добавляете в ваш docker-compose. Если у вас не docker-compose, можете поднимать ручками или в вашей системе. В нашем случае добавляется вот такой блок кода, интеграции в docker-compose. Всё, сервис настроен. И вы можете увидеть в блоке volumes файл конфигурации filebeat.yml.



Вот пример filebeat.yml. Здесь настроен автоматический поиск логов контейнеров docker, которые крутятся рядом. Кастомизован выбор этих логов. По условию можно задавать, вешать на ваши контейнеры лейблы, и в зависимости от этого ваши логи будут отправляться только у определенных контейнеров. С блоком processors:add_docker_metadata все просто. В логи добавляем немножечко больше информации о ваших логах в контексте docker. Необязательно, но прикольно.



Что мы получили? Это все, что мы написали, весь код, очень круто. При этом мы получили все логи в одном месте и есть интерфейс. Мы можем поискать наши логи, вот плашечка search. Они доставляются. И можно даже в прямом эфире включить так, чтобы стрим летел к нам в логи в интерфейс, и мы это видели.



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

Да, из коробки в таком подходе, когда у нас текстовые логи, есть небольшой затык: мы можем по тексту задать запрос, например message:users. Это выведет нам все логи, у которых есть подстрока users. Можно пользоваться звездочками, большинством других юниксовых wild cards. Но кажется, этого недостаточно, хочется сделать сложнее, чтобы можно было нагрепать в Nginx раньше, как мы это умеем.



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

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

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

Меня это напрягало. Я хочу написать: Прилетел запрос. Дальше: Такой-то, такой-то, такой-то, очень просто, очень по-айтишному.



Давайте дальше. Договоримся: логировать будем в формате JSON, это простой формат. Сразу ElasticSearch поддерживается, filebeat, которым мы сериализуем и попробуем впилить. Это не очень сложно. Для начала вы добавляете из библиотеки pythonjsonlogger в блок formatters JSONFormatter файлика settings, где у нас хранится конфигурация. У вас в системе это может быть другое место. И дальше в атрибуте format вы передаете, какие атрибуты вы хотите добавлять в ваш объект.

Блок ниже это блок конфигурации, который добавляется в filebeat.yml. Здесь из коробки есть интерфейс у filebeat для парсинга JSON-логов. Очень круто. Это все. Для этогов вам больше ничего писать не придется. И теперь ваши логи похожи на объекты.



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



Давайте подведем итог. Теперь наши логи имеют структуру. По ним несложно грепать и можно писать интеллектуальные запросы. ElasticSearch знает об этой структуре, так как он распарсил все эти атрибуты. А в kibana это интерфейс для ElasticSearch можно фильтровать такие логи с помощью специализированного языка запросов, который предоставляет Elastic Stack.

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

Проблема 2. Тормоза


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



Тут немного контекста, расскажу вам историю. Ко мне прибегает менеджер, главное действующее лицо нашего проекта, и говорит: Эй-эй, кабинет тормозит! Даня, спаси, помоги!

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



Эраст добавил фичу. В книгах мы теперь отображаем не айдишник автора, а его имя прямо в интерфейсе. Очень круто. Сделал он это вот таким кодом. Небольшой кусок кода, ничего сложного. Что может пойти не так?

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

Давайте расскажу. У меня был опыт: мы работали с Django, и у нас в проекте был реализован кастомный прекэш. Много лет все шло хорошо. В какой-то момент мы с Эрастом решили: давай пойдем в ногу со временем, обновим Django. Естественно, Django ничего не знает о нашем кастомном прекэше, и интерфейс поменялся. Прикэш отвалился, молча. На тестировании это не отловили. Та же самая проблема, просто ее сложнее было отловить.

Проблема в чем? Как я помогу вам решить проблему?



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

Первое, что делаю, иду в ElasticSearch, у нас он уже есть, помогает, не нужно бегать по серверам. Я захожу в логи, ищу логи кабинета. Нахожу долгие запросы. Воспроизвожу на ноутбуке и вижу, что тормозит не кабинет. Тормозит Books.

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



Мне было больно. Сложно, неприятно. Я плакал. Хочется, чтобы этот процесс поиска проблемы был быстрее и удобнее.

Формализуем наши проблемы. Сложно по логам искать, что тормозит, потому что наш лог это лог несвязанных событий. Приходится писать кастомные таймеры, которые показывают нам, сколько выполнялись блоки кода. Причем непонятно, как логировать тайминги внешних систем: например, ORM или библиотек requests. Надо наши таймеры внедрять внутрь либо каким-то Wrapper, но мы не узнаем, от чего оно тормозит внутри. Сложно.



Хорошее решение, которое я нашел, Jaeger. Это имплементация протокола opentracing, то есть давайте внедрим трассировку.

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

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



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



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



Jaeger логирует, например, SQL-запросы: вы можете посмотреть, какие запросы повторяются. Очень быстро и круто.



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



Давайте внедрим Jaeger. Кода нужно не очень много. Вы добавляете зависимости для opentracing, для Flask. Теперь о том, какой код мы делаем.

Первый блок кода это настройка клиента Jaeger.

Затем мы настраиваем интеграцию с Flask, Django или с любым другим фреймворком, на который есть интеграция.

install_all_patches самая последняя строчка кода и самая интересная. Мы патчим большинство внешних интеграция, взаимодействуя с MySQL, Postgres, библиотекой requests. Мы все это патчим и именно поэтому в интерфейсе Jaeger сразу видим все запросы с SQL и то, в какой из сервисов ходил наш искомый сервис. Очень круто. И вам не пришлось много писать. Мы просто написали install_all_patches. Магия!

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

Проблема 3. Ошибки


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



Контекст. Вы можете сказать: Даня, мы логируем ошибки, у нас есть алерты на пятисотки, мы настроили. Чего ты хочешь? Логировали, логируем и будем логировать и отлаживать.

По логам вы не знаете важность ошибки. Что такое важность? Вот у вас есть одна крутая ошибка, и ошибка подключения к базе. База просто флапнула. Хочется сразу видеть, что эта ошибка не так важна, и если нет времени, не обращать на нее внимания, а фиксить более важную.

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



Вот наглядный пример. Когда я впиливал интеграцию с Jaeger, то немного поменял свою API. У меня изменился формат ответа приложения. Я получил вот такую ошибку. Но в ней непонятно, почему у меня нет ключа, lots в объекте order, и нет ничего, что мне бы помогло. Мол, смотри ошибку здесь, воспроизведи и самостоятельно отлови.



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



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



Посмотрим на нашем примере. Проваливаемся в ошибку KeyError. Сразу видим контекст ошибки, что было в объекте order, чего там не было. Я сразу по ошибке вижу, что мне приложение Delivery отдало новую структуру данных. Кабинет просто к этому не готов.



Что дает sentry, помимо того, что я перечислил? Формализуем.

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

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



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

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

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

Что еще можно добавить? Само приложение готово, оно есть по ссылке, вы можете посмотреть, как оно сделано. Там поднимаются все интеграции. Например, интеграции с Elastic или трассировки. Заходите, смотрите.

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

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

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

JS8Call Slack на коротких волнах

15.11.2020 16:06:22 | Автор: admin
Привет Хабр.

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



Посмотрим, как это работает.

Прием и передача


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

Сам протокол FT8 оказался весьма удачным, т.к. позволяет передавать и принимать сообщения на большие расстояния с 5 Вт выходной мощности вполне можно связаться с корреспондентом на расстояние в 1000 км. Но схема кодирования текста в FT8 черезчур ограничена, т.к. ориентирована только на радиолюбительские позывные, практически ничего больше внутри сообщения передать нельзя (в принципе можно, но будет очень медленно и неудобно). Но используя сам принцип кодирования, другой радиолюбитель Jordan Sherer создал на базе FT8 свою программу JS8Call (как несложно догадаться, JS инициалы автора), обладающую гораздо более гибкой функциональностью:

  • Программа использует узкополосную модуляцию в разных режимах: Turbo (6с на сообщение, занимаемая полоса 160 Гц), Normal (15с на сообщение, полоса 50 Гц, Slow (30c на сообщение, полоса 25 Гц). Очевидно, тем выше скорость тем удобнее для пользователя, но тем меньше дальность. Пользователь сам может выбрать нужную скорость в зависимости от условий, качества антенны, дальности, на приемной стороне тип сообщений определяется автоматически, что весьма удобно.
  • Программа имеет развитые возможности групповой связи: можно пересылать сообщения через промежуточного абонента, программа может накапливать сообщения для другого адресата, который может запросить количество входящих сообщений. Можно отправлять сообщения группам, можно включить режим автоматического подтверждения приема и пр.
  • Программа может работать на практически любых частотах, от 1.8 МГц до 144 МГц УКВ.
  • Имеется API для интеграции с внешним софтом по UDP или TCP.
  • Программа работает на любом железе, включая Windows, OSX и Raspberry Pi, при этом софт распространяется совершенно бесплатно и доступен в исходниках.

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

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

Общий принцип понятен, перейдем к тестированию.

Тестирование


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

Прием


Я установил программу на Raspberry Pi и использовал её в режиме приема: программа GQRX подключенная к приемнику SDRPlay и JS8Call обменивались данными через виртуальный звуковой кабель.



Можно обратить внимание на поле Distance в правом углу картинки. Как можно видеть, принять сообщение можно даже с другого материка. В целом, по приему, всё весьма неплохо. На мою скромную антенну AOR SA7000 (это штырь длиной 2 метра) на балконе были приняты практически все страны Европы и несколько станций из Америки и Канады. Каждая метка на карте это принятая станция:



Максимальная дистанция приема составила 7831 км на частоте 14 МГц. А вот сигналов из России, увы, не было принято ни одного.

Передача


Передачу я буду тестировать только локально, для чего с помощью командной строки js8call.exe -r test1 js8call.exe -r test4 были запущены 4 копии программы с разными виртуальными позывными USER1..USER4. В настройках также была отключена посылка данных на pskreporter, чтобы не мешать другим радиолюбителям тестовыми сообщениями. Окна приема и передачи 4х программ выглядят примерно так:



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

JS8Call предоставляет следующие возможности:

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

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

API


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



Пишем простейшую программу для приема сообщений через socket:

import socketHOST = '127.0.0.1'  # The server's hostname or IP addressPORT = 2442        # The port used by the serverwith socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:    s.connect((HOST, PORT))    while True:        data = s.recv(1024)        print('Received', repr(data))

Запускаем. Результат на скриншоте:



Как можно видеть, мы имеем полный доступ к входящим сообщениям в виде JSON, что позволяет использовать их как угодно, например для гейта в Telegram, SMS, пересылки в другие сервисы и пр. Вроде API можно использовать и для передачи, но это не точно, полное описание автор пока не выложил.

Заключение


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

Ну а всем как обычно, удачных экспериментов.
Подробнее..

Задачи и инструментыMLи их практическое применение

26.11.2020 12:17:06 | Автор: admin

Машинное обучение распространившийся термин, но не все понимают его верно. В этом материале эксперты направления аналитических решений ГК КОРУС Консалтинг Алена Гайбатова и Екатерина Степанова расскажут, что же на самом деле такоеmachinelearning(ML), в каких случаях эту технологию стоит использовать в проектах, а также где машинное обучение активно применяется на практике.

Как работают с данными

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

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

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

Второй так называемыеdata-drivenсистемы, которые извлекают логику работы из каких-то исторических данных. У этого типа есть много терминов-синонимов, которые возникали с течением времени:

  • модные в 90-е и нулевые data mining и knowledge discovery from database (KDD),

  • datascience, вошедший в обиход ближе к 2010-м,

  • bigdataпопулярная ныне. Единственное исключение, точнее дополнение, которое привносит именно этот термин наличие огромного количества сложноструктурированных данных.

Для разных задач разные алгоритмы

В соответствии с двумя типами слабого ИИ выводы из данных мы можем сделать вручную (при экспертных системах) и с помощью машинного обучения. Оно же в свою очередь подразделяется на два типа: классическийMLиdeeplearning(с использованием глубоких нейронных сетей с большим количеством слоев).

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

Классификаторы

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

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

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

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

Регрессоры

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

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

Кластеризация

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

Самый популярный алгоритм кластеризации метод ближайших соседей.Cнова к кошкам. Мы хотим разбить наших зверей на 4 группы. Наши объекты снова точки на плоскости.Мы выбираем случайным образом центры наших групп, затем смотрим расстояние от центра группы до точек, ближайших к этому центру группы. После мы смещаем центры таким образом, чтобы расстояние до точек своей группы оказывалось меньше, чем до точек другой группы. Через нескольких итераций у нас получатся хорошо разделенные группы.

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

Нейронные сети

Первая нейронная сеть появилась еще в 1950-х гг. Сейчас при помощи нейронных сетей можно ответить на любой вопрос, но лишь с одной оговоркой: ответ не всегда можно интерпретировать.

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

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

Обучение с подкреплением

Это и есть тот самый сильный искусственный интеллект, о котором мы уже говорили выше. К примеру, по этому принципу работают беспилотные автомобили.

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

Мы также пользуемся алгоритмамиUplift, нейролингвистического программирования и рекомендательными моделями.Upliftпозволяет понять, нужно ли коммуницировать с объектом, НЛП использует алгоритмы для анализа текста (к примеру, на этом принципе работает функция подсказки слов в смартфоне), а рекмодели могут быть персонализированными и не персонализированными.

Теория на практике

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

  • Экономический эффект, который может принести оптимизация бизнес-процесса в несколько процентов;

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

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

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

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

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

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

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

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

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

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

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

Подробнее..

Микросервисная авторизация для чайников для чайников

01.12.2020 12:23:05 | Автор: admin
В данной статье рассматривается пример реализации распределенной микросервисной авторизации доступа для множества пользователей к множеству ресурсов или операций. Уровень подготовки читателя может быть любой, кто знаком с программированием и проектированием. Так же рассматриваются примеры использования на практике и одна из задач реализована в виде небольшой микросервисной системы.

1 Немного теории


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

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

1.1 Время восстановления/энтропия входных параметров


Авторизация принимает решение о разграничении доступа на основе множества входных параметров. Если таковых будет слишком много, либо мерность множеств окажется слишком большой, то авторизация будет терять слишком много ресурсов на выполнение ненужных операций. Это как сортировать данные пузырьком и qsort. Не следует выполнять ненужные операции.
Если у вашей системы есть на входе A,B,C,D,E,F факты о пользователе, то если вы будете объединять все в одно, то получите A * B * C * D * E * F комбинаций, которые невозможно эффективно кешировать. По возможности следует найти такую комбинацию входных, что бы у вас было A * B * C и D * E * F комбинаций, а еще лучше A * B, C * D, E * F, которые вы уже легко сможете вычислять и кешировать.
Эта характеристика очень важна так же для построения системы правил, которые будут предоставлять пользователям доступы.

1.2 Детализация авторизации


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

2 Обобщенная модель данных


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

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

2.1 Пользователь


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

2.2 Сервис


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

2.3 Ресурс


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

2.4 Разрешение


Право пользователя выполнять операцию над сервисом и/или ресурсом.

2.5 Роль


Множество разрешений, по сути под словом роль всегда подразумевается множество разрешений.
Следует отметить, что в системе может не быть ролей и напрямую задаваться набор разрешений для каждого пользователя в отдельности. Так же в системе могут отсутствовать разрешения (речь про хранение их в виде записей БД), но быть роли, при этом такие роли будут называться статичными, а если в системе существуют разрешения, тогда роли называются динамическими, так как можно в любой момент поменять, создать или удалить любую роль так, что система все равно продолжит функционировать.
Ролевые модели позволяют как выполнять вертикальное, так и горизонтальное разграничение доступа (описание ниже). Из типа разграничения доступа следует, что сами роли делятся на типы:
  • Глобальные роли применимые ко всем сервисам для вертикального разграничения;
  • Локальные применяются только к ресурсу горизонтальное разграничение.

Но отсюда следует вопрос, если у пользователя есть глобальная роль и локальная, то как определить его эффективные разрешения? Поэтому авторизация должна быть в виде одной из форм:
  • Конъюнктивная
  • Дизъюнктивная

Подробное описание использования типа ролей и формы авторизации ниже.

Роль имеет следующие связи:
  • Пользователь у каждого пользователя может быть множество ролей;
  • Разрешение каждая роль объединяет в себе несколько разрешений всегда вне зависимости от типа ролей.

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

2.6 Группа


Используя группы можно объединить множество ресурсов, в том числе расположенных в разных сервисах в одно целое, и управлять доступом к ним используя одну точку. Это позволяет гораздо проще и быстрее реализовывать предоставление доступа пользователя к большим массивам информации, не требуя избыточных данных в виде записи на каждый доступ к каждому ресурсу по отдельности вручную или автоматически. По сути вы решаете задачу предоставления доступа к N ресурсам создавая 1 запись.
Группы используются исключительно для горизонтального разграничения доступа (описание ниже). Даже если вы будете использовать группы для доступа к сервисам, то это все равно горизонтальное разграничение доступа, потому что сервис это совокупность ресурсов.
Группа имеет следующие связи:
  • Пользователи множество пользователей участвующих в группе, сама связь может быть при этом:
    • Безусловной связь определяется только пользователем и группой, такая связь всегда уникальна;
    • Условной связь определяет роль/разрешение пользователю в группе, например вы можете добавить пользователя с разрешением модерировать ресурсы группы, таких связей может быть сколько угодно.
  • Ресурсы список ресурсов этой группы.


2.7 Вертикальное и горизонтальное разграничение доступа.


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

2.8 Глобальность/локальность авторизации доступа в микросервисах


Несмотря на то, что все роли могут хранится в единой БД, то вот связи между ними и пользователями хранить все вместе на всю вашу огромную систему это типичный антипаттерн, делать так является грубейшей ошибкой, это все равно что POSIX права на файлы хранить в облачном сервисе, вместе с таблицей inode. Так же вы теряете огромную часть важного функционала, который вам могла бы предоставлять ваша БД сразу, например пагинация ресурсов с разграничением доступа к строкам.
Связи пользователя с глобальными ролями хранить следует в самом сервисе ролей. Связь же пользователя с локальной ролью необходимо хранить там же, где лежат ресурсы соответствующей роли. Например если у вас есть глобальная роль Менеджер проектов, то хранить ее будем в сервисе ролей, а локальная роль Менеджер проекта (окончание у них разное) уже в сервисе проектов, при этом связь будет не (Пользователь, Роль), а (Пользователь, Роль, Проект). Либо в случае групп (Группа, Проект). Под это дело можно будет написать специальный авторизационный клиент, и когда в другом микросервисе, например документов, вам нужно будет авторизовать доступ к проекту, то вы всего лишь повесите 2 аннотации @RequireRole(User) @ProjectAccess. Все остальное уже сделано либо самим спрингом, либо авторизационными клиентами.
При таком подходе вы можете фильтровать видимость данных уже на уровне вашей БД, в сам запрос вам нужно будет отдать массив групп и ролей пользователя, что бы дополнительно отфильтровать данные. Вам ничто не мешает теперь показывать страницу только тех ресурсов, которые пользователь может видеть! Даже если этих ресурсов миллионы.

2.9 Конъюнктивная/дизъюнктивная форма авторизации


Из-за того, что у теперь у нас существуют два варианта наборов разрешений пользователя, то можно выделить два варианта, как объединить все вместе:
  • Конъюнкция требуем, что бы пользователь имел как глобальное разрешение, так и локальное, в этом случае можно закрыть доступ сотруднику сразу после его увольнения, не тратя время и ресурсы на чистку его записей в БД;
  • Дизъюнкция если у пользователя есть глобальное разрешение, то предоставляем доступ ко всем ресурсам, если есть доступ только к конкретному ресурсу, то только к нему.

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

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

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

2.10 О кешировании данных


Основной проблемой при работе авторизации является точка в которой необходимо кешировать результаты, что бы работало быстрее все, да еще желательно так, что бы нагрузка на ЦПУ не была высокой. Вы можете поместить все ваши данные в память и спокойно их читать, но это дорогое решение и не все готовы будут себе его позволить, особенно если требуется всего лишь пара ТБ ОЗУ. Второй крайностью является попытка кешировать входные параметры и результат (или запрос и ответ), в результате опять же потребуется пара ТБ ОЗУ, но уже для хранения всех ваших вариантов.
Правильным решением было бы найти такие места, которые бы позволяли с минимальными затратами по памяти давать максимум быстродействия.
Предлагаю решить такую задачу на примере ролей пользователя и некоего микросервиса, которому нужно проверять наличие роли у пользователя. Разумеется в данном случае можно сделать карту (Пользователь, Роль) -> Boolean. Проблема в том, что все равно придется на каждую пару делать запрос на удаленный сервис. Даже если вам данные будут предоставлять за 0,1 мс, то ваш код будет работать все равно медленно. Очевидным решением будет кешировать сразу роли пользователя! В итоге у нас будет кеш Пользователь -> Роль[]. При таком подходе на какое-то время микросервис сможет обрабатывать запросы от пользователя без необходимости нагружать другие микросервисы. Разумеется читатель спросит, а что если ролей у пользователя десятки тысяч? Ваш микросервис всегда работает с ограниченным количеством ролей, которые он проверяет, соответственно вы всегда можете либо захардкодить список, либо найти все аннотации, собрать все используемые роли и фильтровать только их.
Полагаю, что ход мыслей, которому стоит следовать, стал понятен.

2.11 Выводы по обобщенной модели


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

3 Как использовать обобщенную модель данных


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

3.1 Закрытый онлайн аукцион


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

3.2 Логистика


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

Для реализации такого функционала нам потребуется реестр регионов и магазинов в качестве отдельного микросервиса, назовем его С1. Заявки и историю будем хранить на С2. Авторизация А.
Далее при обращении продавца для получения списка его магазинов (а у него может быть их несколько), С1 вернет только те, в которых у него есть меппинг (Пользователь, Магазин), так как ни в какие регионы он не добавлен и для продавца регионы всегда пустое множество. Разумеется при условии, что у пользователя есть разрешение просматривать список магазинов посредством микросервиса А.
При получении заявок магазина, проверка в А разрешений смотреть заявки, а затем С2 отравляет запрос в С1 и получает разрешение или запрет на доступ к магазину.

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

3.3 Секретные части документа


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

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

3.4 Команда и ее проекты


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

Такую проблему проще всего решить при помощи групп.
Группа будет объединять все необходимые проекты в одно целое. При добавлении участника в команду, добавляем меппинг (Пользователь, Группа, Роль).

Допустим, что Вася разработчик и ему нужно вызвать метод develop на микросервисе для выполнения своих обязанностей. Этот метод потребует у Васи роли в проекте Разработчик.
Как мы уже договаривались регистрация пользователя в каждый проект для нас недопустима. Поэтому микросервис проектов обратится в микросервис групп, что бы получить список групп, в которых Вася Разработчик. Получив список этих групп можно легко проверить уже в БД микросервиса проектов есть ли у проекта какая-нибудь из полученных групп и на основании этого предоставлять или запрещать ему доступ.

4 Проектируем микросервисы для работы чайников



4.1 Словесное описание решаемой задачи


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

4.2 Архитектура решения


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

Графически это будет выглядеть так:


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


5 Реализация микросервисов



Для реализации воспользуемся Spring фреймворком, он довольно медленный, но зато на нем легко и быстро можно реализовывать приложения. Так как за перформансом мы не гонимся, то попробуем на нем достичь скромных 1к рпс авторизованных пустых запросов (хотя люди на спринге умудрялись 100к пустых запросов проворачивать [1]).

Весь проект поделен на несколько репозиториев:


Как работать с проектами
У всех проектов есть общая зависимость ее нужно скачать и выполнить mvn clean install.
Далее нужно собрать докер образы каждого микросервиса, что выполяется командой sh buildDocker.sh автоматически выполнит mvn clean install и сборку образа докера.

В каждом проекте есть кофигурация docker-compose с минимальной для каждого сервиса конфигурацией, лучшим вариантом запуска будет sh start.sh. Остановить сервисы можно при помощи docker-compose down, если этого не сделать, то выполнить скрипт из папок других сервисов вы не сможете.

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


Как устроены test suites
Создаете конфигурацию запуска с мейн классом org.lastrix.perf.tester.PerfTester, в аргумент задаете имя класса test suite, через vm аргументы задаете параметры -Dperf.tester.warmup.round.time=PT1S -Dperf.tester.test.round.time=PT60S -Dperf.tester.test.threads.max=32 -Dperf.tester.test.threads.min=4 -Dperf.tester.test.round.count=1

Для начала разберемся с базой данных ролевой модели:


Пользователи задаются другим сервисом, который в нашем случае даже не реализован, так же как аутентификация. Сделано для упрощения примера.
Обратите внимание на поле is_deleted, оно необходимо, так же как и индекс на (user_id,role_id,is_deleted), иначе работать ничего не будет удаление записей из больших таблиц приведет к снижению производительности (а у нас расчет на 5 млн строк). Если у вас окажется слишком много записей с флагом is_deleted=true (например 1 млн строк), то гораздо выгоднее будет в техническое окно запустить скрипт на удаление таких записей разом, чем удалять по запросу.

Для работы с таблицами нам потребуется сделать REST API, причем одно для пользователей людей, второе для пользователей сервисов.

Само апи довольно легко в понимании, но оно работает медленно (в районе 4к-7к рпс из-за БД), причем как получение ролей пользователя, так и проверка наличия ролей. Для ускорения работы необходимо сделать кеширование, поэтому добавляем в конфигурацию mafp.role.cache.enable. Кеш можно сделать в виде карты, но лучше использовать уже готовое решение com.google.common.cache.Cache и сэкономить себе кучу нервов, потому что через HashMap или WeakHashMap сделать быстро не удастся.
И в данный момент у нас появляется вопрос, а что именно нужно кешировать? В данном случае лучшим вариантом будет сами роли, вернее их имена на каждого пользователя, так мы сэкономим запросы к БД.
В абстрактном классе заведем кеш под эти данные, но есть одно но. Если хранить Set, то нам придется столкнуться с тем, что поиск в случае большого количества ролей у пользователя будет работать медленно (в JVM строки никогда не работали быстро и не будут). Так же проблемой будет то, что строки, которые мы получим из хибернейта не будут интернированными или каким-то образом преобразованными до синглтонов в рамках нашего кеша, т.е. a == a всегда для нас будет ложно, и соответственно будет сравнение строк, а нужно указателей или простых значений, например целых чисел. Это помимо того, что у нас память будет забиваться одними и теми же строками.
Поэтому необходимо добавить карту, в которой будем хранить меппинг (Строка, Целое). И в кеше хранить уже не набор имен ролей пользователя, а набор идентификаторов ролей пользователя, причем эти числа могут не совпадать с идентификаторами в вашей БД. Поиск Integer в HashSet выполняется намного быстрее, чем строки, при этом у вас де факто все строки будут интернированными, что в нашем случае является обязательным шагом иначе потребление памяти будет расти неконтролируемым образом.

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

Если инициализировать БД 500к пользователями, 10к ролей и каждому пользователю выдать до 10 ролей, то можно провести нагрузочное тестирование. Результат на выданных 4 ядрах от моего i7-9700k получится скоромный среднее 12992, минимум 12832, максимум 13088 rps. Результат получен на 16 потоках клиента.

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

Идеальным тестом для авторизации является отношение количества пустых запросов за единицу времени к количеству авторизованных пустых запросов за единицу времени для N (желаемое число под в вашей системе, требующих авторизацию, хотя вы можете вычислять это значение от 1 до N и показывать в виде графика). При этом записывать будем в виде Ка1 коэффициент авторизации 1, если количество под равно 1. Чем ближе к 1 это значение, тем лучше работает ваша авторизация как слой. Именно поэтому полученные выше 13к рпс не имеют никакого значения, даже если вы сделаете авторизацию, которая выдает 10e100 rps, она будет бесполезна, если коэффициент авторизации окажется скажем 1000, потому что плохим результатом является уже 100 т.е. ваша авторизация в 100 раз замедляет ничего не делающее приложение.
В данной статье будет измеряться только Ка1, потому что железа нет.

Приступим к чайному сервису. Для тестирования авторизации у нас создан в нем ендпоинт POST /api/v1/tea/dummy.
Если отключить авторизацию (/noauth в конец добавить), то тестирование покажет нам на выданные 2 ядра чайному сервису и 2 ролевому среднее 18208, минимум 18048, максимум 18560 на 32 потоках клиента это количество запросов, которое может обработать наша система с заданными настройками, исключая какую либо бизнес логику, быстрее работать у нас уже ничего не будет. Включив же авторизацию, которая заключается в проверке у пользователя роли User, получим следующие показания на 6 потоках клиента среднее 1062, минимальное 1062, максимальное 1068.
При этом тестировалось на 100к случайно выбираемых пользователях! Ка1 = 17.1.

И напоследок попьем чай (делаем инсерты в БД) в 6 потоков клиента на POST /api/v1/tea получим среднее 1086, минимум 1086, максимум 1086 (а должно быть ~4к). О чем это говорит нам? О том что авторизация является для нас боттлнеком, который замедляет работу системы (из-за сильной нагрузки на ЦПУ, что говорит о том, что алгоритм кеширования у нас не очень). Еще о том, что погрешности измерений огромные.
Коэффициент авторизации позволит вам не только оценить работу алгоритмов авторизации, но и очертить границы в которых может работать весь ваш комплекс микросервисов, а так же сообщить вам имеет ли смысл оптимизировать код конкретного микросервиса или нет, потому что может так оказаться, что выигрыш будет 0.
Если же всего лишь включить роль в JWT токен, то с 12 потоками клиента можно получить от dummy среднее 6396, минимум 6372, максимум 6444. Т.е. Ка1 оказался равен 2.8!
А что будет, если отключить кеширование на клиенте, не использовать роли JWT и оставить его только на ролевой модели? Производительность вырастет, потому что сетевые задержки около нулевые и нагрузка на ЦПУ для dummy станет минимальной среднее 3817, минимум 3806, максимум 3828, что говорит нам о Ка1 = 4.7. Однако следует учитывать, что такое решение не будет масштабируемым, потому что каждый клиент будет обращаться постоянно к сервису ролевой модели и увеличивать на него нагрузку, уже при сотне под начнутся серьезные проблемы, делающие невозможной работу авторизации, разве что у вас на каждый сервис, которому нужна авторизация будет пода авторизации, которая эту функцию будет выполнять, есть в интернете такие сетевые инженеры, которые любую проблему готовы залить водой решить добавив под.

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

Заключение


В статье предложена универсальная модель для авторизации доступа множеству пользователей к множеству ресурсов с минимальными потерями по производительности, позволяющая делать эффективное кеширование и хранение промежуточных данных на микросервисах, для сборки результата авторизации just-in-time. Предложена метрика (в виде коэффициента), для оценки работы авторизации микросервисов с учетом требований работы всего комплекса и показано, как он может меняться в зависимости от подхода, а именно наличия/отсутствия кеша, хранения ролей в JWT токене и т.д. Не показано, что этот коэффициент всегда растет с увеличением количества под в системе.
Предложенная модель данных позволяет разделить данные между частями микросервисной архитектуры, тем самым снизив требования к железу, дает возможность работать только с теми данными, которые нужны в конкретный момент времени конкретному сервису, не пытаться искать в огромном массиве все подряд или пытаться искать данные в полностью обобщенном хранилище.
Показано, что при малом количестве микросервисов нет смысла проводить кеширование на клиенте авторизации, так как это приведет к большей нагрузке на ЦПУ. Предоставлены данные, которые позволяют сделать вывод, что необходимо балансировать ресурсы в зависимости от размеров системы, если она слишком мала, то есть смысл нагружать больше сеть, но при увеличении и разрастании выгоднее добавить пару ядер в микросервисы, для обеспечения работы кешей и разгрузки сети, микросервисов авторизационных данных. Вопрос больше в том, что для вас дешевле, найти дополнительные ядра или сеть улучшать с гигабитной до десятигигабитной, особенно если можно сделать авторизацию, когда достаточно для ее работы 100 мбит сети.

Литература


  1. High-Concurrency HTTP Clients on the JVM
Подробнее..

Дневник Производства 2.0 стартап в стартапе

16.11.2020 20:18:08 | Автор: admin
Что сложнее: запустить стартап-проект в чистом поле или встроить его в готовый продукт? На самом деле одинаково сложно все.

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

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

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



Краткое содержание:

  • Мы
  • Откуда берутся бизнес-требования
  • Проектируем, предсказывая будущее
  • Производство гробов и модель данных
  • Как не сломить найти общий язык с бизнес-аналитиком, если ты архитектор
  • Мы проработали, но нет. Автомобиль и рыба. Что общего?

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

Действующие лица первого этапа:

  • Аскар генеральный директор
  • Олег технический директор
  • Максим product owner, направляющий нас
  • Тимур бизнес-аналитик, который знает процессы производства
  • Максим тимлид команды разработки
  • Я системный аналитик

Вводная


Перескажу кратко вводную, которую в первый день спринта, 22 октября 2020-го, мы услышали от Аскара.

Производство в МоемСкладе есть уже давно и у него есть пользователи. Но оно сделано в минимальном исполнении. Можно создавать технологические карты и на их основе либо резервировать товары на складе под производство, либо одномоментно списывать товары и производить готовую продукцию. Это все.



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

В феврале 2020 года в МойСклад написал Тимур (теперь уже наш бизнес-аналитик), работавший тогда с учетом на реальном производстве, с описанием как должно быть, прототипом и предложением о сотрудничестве. В итоге Аскаром принял решение подойти к развитию этого направления основательно и запустить Производство 2.0 обновленное и умное.

Займемся производством




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

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

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

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

Что помогло сделать первый шаг?


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

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

На ней все держится. Модель данных


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

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

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

В целом обсуждение было построено примерно так:

  1. Для очередной сущности я спрашиваю: Что это такое? и Что мы с этим можем сделать?.
  2. Тимур рассказывает нам о связанных процессах, показывает макеты, приводит примеры.
  3. Все задают много-много вопросов: А можно так?, А что, если...?, удивляются, и иногда кричат Так нельзя!.
  4. Тимур убеждает, что можно и очень надо.
  5. От примера про сборку шкафа мы переходим к примеру про гробы (А если мы производим гробы из австралийского дуба, и нам заказывают модификацию из сосны...).
  6. Смеемся, приходим к компромиссу, дорисовываем в модели данных связанные сущности, описываем ключевые параметры, оставляем заметки уточнить позже.
  7. Фиксируем в статье Вопросы и ответы решения по бизнес-требованиям и ограничениям, если они появились в процессе обсуждения или наоборот, если были сняты.

Логическую модель сделали. В итоге у нас получился такой вот небольшой монстр с заметками и облаками.



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

Убей в себе архитектора и научись слышать


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

Что разработчики хотят от бизнеса на ранних этапах? Уверенности! Мы много раз разбивали уверенность Тимура о скалы и уводили его от задуманных бизнес-требований к попыткам сделать из того, что есть, или сделать проще. Так нельзя!

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

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



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

Не откладывай на завтра. НИКОГДА!


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

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

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

Если бы я не писала, а говорила, то это звучало бы как (читать с выражением): М Ну Как бы сказать Короче Вот Каждый третий.

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



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

В завершении первого спринта мы пришли-таки к окончательному решению, и уже совсем скоро наша модель данных позволит детально проектировать и начинать разработку. Макеты детализируются, подключаем коллег по тестированию и UI/UX. Продолжаем творить!

Итого


Чтобы успешно и быстро начать стартап-проект:

  1. Изучите весь известный бэклог, чтобы знать будущее.
  2. Выберите фундаментальную задачу, которая делает/меняет все.
  3. Для внутреннего стартапа нужно подключать команду с опытом решения других задач в развитии продукта.
  4. Слушайте бизнес и дайте вашему бизнес-аналитику эликсир уверенности. Бизнес-требования важнее системных ограничений. Системные ограничения всегда можно преодолеть (это точно)!
  5. Прежде чем что-либо проектировать, посмотрите на систему глазами пользователей нужны черновые макеты UI, которые обязательно будут изменены.
  6. Проектирование нужно начинать с модели данных
  7. Если есть возможность проверить теорию, проверяйте сразу, не откладывая до последнего.

О производстве в МоемСкладе
Подробнее..

Как корова помогла сделать интереснее процесс проектирования

24.11.2020 22:21:52 | Автор: admin
Всем привет! Я ведущий системный аналитик в компании МойСклад и сейчас мы с командой Производство запускаем внутренний стартап внутри стартапа Производство 2.0. Недавно я написала о том, с чего начать процесс разработки в новоиспеченном проекте, а сейчас хочу продолжить рассказ из горящего танка.

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

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



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

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

Немного определений


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

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

Ресурс товар, из которого производят продукцию.

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

Техпроцесс производства упорядоченная последовательность этапов, в результате выполнения которых производится продукция и затрачиваются ресурсы.

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

Техкарта коровы


Ключевыми сущностями производства, от которых строятся все процессы, являются товар, этап, процесс и техкарта.

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

Вариант 1: У меня есть мясной цех и луг. Я забираю корову с луга и за один этап превращаю ее в части. Это простая техкарта разборки.



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



Это простые техкарты, которые поддерживает текущее производство МоегоСклада. А теперь усложним.

Вариант 3: У меня есть мясной цех, упаковочный цех и луг. Я забираю 10 коров с луга. Сначала я превращаю 10 коров в очень много частей этап разборки, затем сортирую полученные части этап сортировки, а после помещаю в упаковки. Это все делается по сложной техкарте разборки коровы. Полученная техкарта:

Ресурсы: 1 корова, 100 м2 вакуумной упаковки.
Готовая продукция: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка

Производственный процесс:

  1. Этап разборки (Ресурсы: 1 корова)
  2. Этап сортировки (Ресурсы: нет новых ресурсов, используются результаты этапа разборки)
  3. Этап упаковки (Ресурсы: 100 м2 вакуумной упаковки)

Получается, что я могу взять с луга как одну корову, так и 10, и 20 и т.д. И этот прекрасный вопрос бизнес-аналитику: Тимур, а можно произвести 1,5 коровы?. Истерика. Ответ: Можно. Мы же не только с коровами работаем, ограничения не ставим. Захотят пол коровы, возьмут половинку с луга или из морозильника.



Вариант 4: У меня есть мясной цех, завод по производству колокольчиков и луг. Мне привезли части коровы, я провожу этап сборки и получаю одну корову, которая не ходит. Делаем этап реанимации, производим для нее колокольчик и отправляем корову на луг. Это сложная техкарта процесса сборки коровы с колокольчиком.

Да, 1,5 коровы тоже допускаем.

Полученная техкарта:

Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка, серебро.
Готовая продукция: 1 корова, 1 колокольчик.

Производственный процесс:

  1. Этап сборки (Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка)
  2. Этап реанимации (Ресурсы: нет новых ресурсов, используются результаты этапа сборки)
  3. Этап производства колокольчика, может идти параллельно этапу реанимации (Ресурсы: серебро)
  4. Этап надевания колокольчика на корову (Ресурсы: нет новых ресурсов, используются результаты предыдущих этапов)



Такая модель помогла нам доопределить бизнес-правила и ограничения:

  • Можно ли в простой техкарте сборки установить норму готовой продукции 1?
  • Могут ли быть готовые продукты по результатам промежуточных этапов?
  • Можно ли задавать не целые нормы?

И много-много других.

И конечно, мы окончательно определились с кусочком монстра модели данных.

Техоперация и производственный процесс


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

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

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

Утверждения, вопросы и ответы:

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

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

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

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

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

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

Ответ. Нет, тогда нужно создавать новую отдельную техкарту. Пример Техкарта Лопатки коровы

Вопрос. А можно ли в заказе на производство донастроить ресурсы из техкарты, увеличив количество коровы с 1 до 1,2 и добавить до ресурсы?

Ответ. Да, можно, потому что может быть брак, может приехать корова побольше и т.д.
И так далее.

Не для слабонервных

У меня была корова и я начал отпиливать от нее две ноги.





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

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

В заключении


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

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

Во-первых, это весело.

Во-вторых, это заставляет фантазию работать более креативно и извлекать из головы правильные вопросы.

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

Не будьте скучными и выбирайте примеры правильно!
Подробнее..

Расчет перцентилей для мониторинга высоконагруженных систем

24.11.2020 16:19:42 | Автор: admin


Привет, меня зовут Игорь, и я разработчик решений на Tarantool в Mail.ru Group. Я работаю над витринами маркетинга в реальном времени для Мегафона. При мониторинге часто требуется использовать перцентили. Они позволяют понять, как система работает бльшую часть времени, в отличие от усреднения значений, которое сильно подвержено влиянию выбросов. Если 9 из 10 запросов выполняются за 1 секунду, а один за 10 секунд, то среднее будет 1,9 секунды, а 50-перцентиль 1 секунда. Это лишь один пример того, что среднее значение не подходит для мониторинга. Возникает необходимость считать перцентили, для этого мы добавили в tarantool/metrics Summary-коллектор.


Функциональность Summary-коллектора расчет квантилей для наблюдаемых данных. Расскажу об алгоритме, который мы использовали для квантилей, и о том, как мы его реализовывали для tarantool/metrics.


Summary-коллектор


Алгоритм


$\phi$-квантиль это значение, которое случайная величина не превышает с вероятностью $\phi$. Пример: 0,5-квантиль (она же 50-перцентиль), равная 1 секунде, для мониторига HTTP-запросов означает, что 50% запросов были обработаны меньше, чем за секунду. Чтобы посчитать квантиль $\phi$ для отсортированного массива размером $n$, необходимо взять элемент с индексом $\phi \times n$. При таком подходе необходимо хранить все данные, а в метриках их может быть очень много. Если был 1 млрд запросов, то будет 1 млрд элементов массива порядка 1 Гб данных.


Для решения этой проблемы существует несколько алгоритмов расчета приближенных значений квантилей на потоках данных. Мы взяли алгоритм, который использует Prometheus. Он сжимает исходные данные в отрезки из трех чисел: расстояние от начала предыдущего отрезка до начала текущего $w$, длина текущего отрезка $\Delta$ и приближенное значение квантили на этом отрезке $v$.



Элементы исходного массива изображены зеленым, элементы сжатого массива красным. Чтобы найти квантиль на сжатых данных, нужно пройтись по всем отрезкам, складывая расстояния, и найти тот, в который попадает значение $\phi \times n$. Тогда на рисунке 0,5-квантиль будет располагаться посередине зеленого массива, а приближенное значение будет принадлежать соответствующему красному отрезку.


Процесс компрессии подробно описан в исходной статье.


Реализация


Мы ориентировались на реализацию алгоритма на Go.


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


typedef struct {int Delta, Width; double Value; } sample;

Алгоритм работает только с отсортированными значениями. Ограничим размер буфера 500 значениями, а размер массива наблюдений определим как $2 \times 500 + 2$ операция сжатия сокращает размер массива примерно вполовину, так что в среднем нам потребуется: 500 элементов несжатого массива с предыдущего шага + 500 элементов, которые вливаются в массив на текущем шаге + 2 элемента $+\infty$ и $-\infty$ для упрощения поиска в массиве.


Ход разработки


Разрабатывали итеративно: делаем версию, проверяем производительность c помощью профилировщика и сравниваем с версией на Go; думаем, как улучшить. Сравнивать будем с простым бенчмарком: делаем вставку 108 образцов, для гошной версии это занимает порядка 8 с. Теперь подробнее о каждом шаге:


1) pure-Lua версия очень плохо, вставка занимает в среднем около 100 с.


В профилировщике видим следующее:



Код проседает на вставке наблюдений в массив (вызов table.insert) и сортировке буфера (table.sort). На помощь приходит ffi, или foreign function interface. Ffi позволяет обращаться к функциям из стандартной библиотеки C, а потом работать с ними в Lua, как с обычными Lua-объектами (ну, почти; например, индексация таблиц в Lua начинается с 1, а у массивов, созданных из С, всё еще с 0).


2) Lua + ffi заменим создание буфера на создание массива double:


local ffi = require('ffi')array = ffi.new('double[?]', max_samples)for i = 0, max_samples - 1 do    array[i] = math.hugeend

Сортировать такой массив будем средствами стандартной библиотеки С:


ffi.cdef[[

    void qsort(void *base, size_t nitems, size_t size, int (*compar)(const void *, const void*));    int cmpfunc (const void * a, const void * b);

]]

Функцию-компаратор для double нужно написать на С и подключить как динамическую библиотеку. Пишем компаратор:


int cmpfunc (const void * a, const void * b) {    if (*(double*)a > *(double*)b)        return 1;    else if (*(double*)a < *(double*)b)        return -1;    else        return 0;}

Собираем его:


gcc -c -o metrics/quantile.o metrics/quantile.cgcc -shared -o metrics/libquantile.so metrics/quantile.o

Подключаем библиотеку в Lua-коде:


local dlib_path = package.search('libquantile', package.cpath)local dlib = ffi.load(dlib_path)

Теперь можно заполнить массив double и вызвать сортировку:


local DOUBLE_SIZE = ffi.sizeof('double')ffi.C.qsort(array, len, DOUBLE_SIZE, dlib.cmpfunc)

Тестируем производительность и получаем прирост в 3 раза, в среднем до 30 с. Проседание происходило из-за того, что размер таблиц в Lua не фиксированный, тип элементов тоже никак не указывается заранее. Это позволяет гибче работать с таблицами, но снижает производительность (подробнее о Lua-таблицах можно почитать здесь). Ffi позволяет перейти от Lua-таблиц к С-массивам с фиксированным размером, поэтому вставка и вычисление размера массива теперь обходятся в $O(1)$ вместо $O(\log n)$. Сортировка тоже происходит гораздо быстрее благодаря зафиксированным типам и, соответственно, фиксированным размерам элементов. Но при таком решении появилась зависимость от gcc, что усложняет поставку приложений. Поэтому пришлось избавиться от C-кода.


3) Lua + ffi + самописная сортировка время работы простейшего варианта быстрой сортировки на Lua получилось всего лишь на пару секунд хуже, чем вариант с сишной библиотекой. Это значение вместе с отсутствием gcc нас удовлетворило, и мы решили остановиться на нем.


Расход памяти


metrics.quantile использует два массива:


  • Буфер размером max_samples * sizeof(double) = $500 \times 8$ байт.
  • Массив наблюдений размером (2 * max_samples + 2) * sizeof(struct sample) = $1002 \times 16$ байт. Размер массива наблюдений может увеличиваться при изменении наблюдаемых значений на несколько порядков.

Влияние на производительность


Провели нагрузочное тестирование Яндекс.Танком (подробнее здесь). Приложение с выключенными метриками:



При использовании Summary-коллектора:



Просело на ~10%, это та цена производительности, которую нужно платить за использование метрик. Если вы хотите избежать сильной просадки, нужно пользоваться коллектором аккуратно, например, замерять только часть запросов.


Использование


tarantoolctl rocks install metrics 0.5.0

local metrics = require('metrics') -- подключаем метрики-- Создаем summary коллекторlocal http_requests_latency = metrics.summary(    'http_requests_latency', 'HTTP requests latency',    {[0.5]=0.01, [0.9]=0.01, [0.99]=0.01})-- наблюдаем значение:local latency = math.random(1, 10)http_requests_latency:observe(latency)

Поддерживается экспорт в JSON, Prometheus и Graphite. Вот так могут выглядеть собранные результаты в Grafana:



Итоги


Мы написали Summary-коллектор для tarantool/metrics. При разработке столкнулись с проблемой производительности, которую решили с помощью ffi. Новый коллектор можно использовать для мониторинга величин, которые выставляются по квантилям, например задержки HTTP-запросов. Summary можно использовать во всех продуктах на Tarantool, где важно время отклика сервиса, например в высоконагруженных приложениях, где HTTP-запросы обращаются к большим объемам данных. Наблюдение за этой метрикой позволит понять, какие запросы нагружают систему.


Ссылки


Подробнее..

Анализ WMS-систем для автоматизации бизнес-процессов

15.11.2020 18:09:06 | Автор: admin

Данная статья даст ответы на определенные вопросы связанные с WMS-системами: Что из себя представляют WMS-системы ?, Что такое ganther магический квадрант ?, Какие компании находятся в лидерах в сфере WMS-систем ? Какие приложения поставщиков входят в плоскость лидеров за 2020 год ?, Какие особенности предоставляют данные приложения ?, Какой вывод можно сделать исходя из представленных особенностей ?.


Источник квадранта https://www.gartner.com/doc/reprints?id=1-1YZ85K9P&ct=200506&st=sb

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



Падаем!

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


Так же стоит упомянуть и архитектуру таких приложений. Вроде же у нас научная статья? Архитектура автоматизированных информационных систем управления складом построена по трехстороннему принципу:


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

Далее стоит привести основные задачи и цели, которые преследуют WMS-системы.


Основными целями WMS-систем, являются:


  1. Увеличение скорости оборота товара;
  2. Активное управление складом;
  3. Получение информации о нахождение товара;
  4. Отслеживание и получение информации о поступающем товаре;
  5. Отслеживание товара с ограниченным сроком годности;
  6. Получение инструмента для эффективной обработки товара на складе;
  7. Оптимизация использования складских площадей.

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


Классификация у систем управления складом так же присутствует, и она имеет под капотом всего два поршня:


  1. Классификация по группам: системы с адресным хранением (используется в крупных компаниях) и системы без адресного хранения (соответственно, используется в малых компаниях);
  2. Классификация по размеру: системы начального уровня, коробочные системы, адаптивные системы, конфигурируемые системы.

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


Для анализа компаний предоставляющие системы управления складом, будет использоваться Магический квадрант от компании Gartner за 2020 год (странно было бы писать статью в 2020 году по материалу за 2019 год).


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




Падаем!

Gartner называет магическим квадрантом отчёт с анализом сегмента рынка, в который включает изображение с распределением поставщиков по указанным плоскостям. Для оценки используются прогрессивные шкалы полнота видения ось абсцисс (completeness of vision), и способность реализации (ability to execute) ось ординат.


Плоскости, на которые вносят поставщиков, являются:


  1. Лидеры (leaders) поставщики с положительными оценками в обе оси;
  2. Претенденты (сhallengers) поставщики с положительными оценками только по способности реализации;
  3. Провидцы (visionaries) поставщики с положительными оценками только по полноте видения;
  4. Нишевые игроки (niche players) поставщики с отрицательными оценками в обе оси.

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

Исходя из этого квадранта, теперь можно провести анализ предоставленных данных, а так же ответить на поставленные вопросы: Какие компании находятся в лидерах в сфере WMS-систем? Какие приложения предоставляют поставщики?, Какие особенности предоставляют данные приложения?.


Начнем с первого вопроса, и на нем долго останавливаться не будем, поскольку чуть выше было представлено подробное описание схемы квадранта и его составление. На основе этих знаний, мы с уверенностью можем выделить основных претендентов на лидирующие места под солнцем систем управления складом. Такими компаниями, являются: Blue Yonder (formerly JDA), Infor, Krber (formerly HighJump), Manhattan Associates, Oracle, SAP. Далее рассмотрим каждого поставщика и их WMS-системы по отдельности.




Начнем с Blue Yonder (formerly JDA), данная компания ранее известная под названием, как JDA, является крупнейшим поставщиком пакетов SCM (Управление цепями поставок). Данный пакет включает в себя решения в области: WMS, управление транспортированием, планирование цепочки поставок, мерчандайзинга, управление персоналом и планирование розничной торговли.


Основными продуктами данной компании, являются: Blue Yonder Warehouse Management, Blue Yonder Dispatcher WMS, Blue Yonder Supply Chain Planner, а так же недавно компания запустила совершенно новый проект для предоставления набора инструментов под названием Luminate.


Посмотрим более наглядно на один из продуктов компании Blue Yonder, Blue Yonder Supply Chain Planner. Данный продукт оптимизирует производительность в сложной цепи поставок и мероприятий, таких как закупка, распределение, инвентаризация и производство.


Особенностями можно считать:


  1. Обеспечивает высокую наглядность и точное суточное планирование в сети комплексных поставок и сбыта;
  2. Поддерживает ряд различных рабочих процессов и производственных сред;
  3. Возможность отчетности на основе исключений;
  4. Обеспечивает моделирование что если;
  5. Предлагает отраслевые шаблоны, которые помогают заказчикам выбрать наиболее выгодное решение;
  6. Поддерживает бизнес-правила для капиталоемких отраслей промышленности;
  7. Поддерживает бизнес-правила интенсивного распределения, включая хранение, обработку ограничений, инвентаризацию целевых брендов, возможности перевалки и транспортировки;
  8. Рассчитывает доходы и расходы по всей цепочке поставок;



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


Можно выделить некоторые особенности данного приложения:


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



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


У бывшего HighJump (Krber) есть три различных WMS теперь они называются Krber InMotion Warehouse Edge, Krber InMotion Enterprise 3PL и Krber InMotion Warehouse Advantage. В рамках данной статьи разберем только последнее приложение.


Основным преимуществом Krber InMotion Warehouse Advantage перед остальными поставщиками, является высокая степень адаптивности к бизнес-процессам заказчиков и клиентов, основываясь на SOA (модульный подход к разработке программного обеспечения). В данном приложении сложные комплексные решения адаптируются без каких-либо изменений исходного продукта.


Основными особенностями данного продукта, являются:


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



Manhattan Associates, основана в 1990 году и является на сегодняшний день лидеров в поставки технических решений в такие области, как управления цепочками поставок (SCM) и систем управления складом (WMS).
Manhattan Associates предлагает широкий портфель решений SCM, который включает три различных WMS: управление транспортировкой, омниканальное управление, включая распределенное управление заказами (DOM); планирование цепочки поставок и поддержка поставщиков.
Решения Manhattan Associates обладают широким функционалом и возможностью масштабирования системы, позволяют автоматизировать полный комплекс складских операций (от приемки до отгрузки).


Инновационными решениями можно считать:


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

Manhattan Associates имеет на своем корабле три различных предложения WMS Manhattan SCALE, Warehouse Management для IBM i (WMi) и Warehouse Management для открытых систем (WMOS). Разберем самый востребованный продукт данной компании Manhattan SCALE с припиской ILS.


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


Исходя из мощного потенциала данного приложения, оно дает возможности:


  1. оптимизировать размещение товаров на складе;
  2. осуществлять мониторинг операций на складе;
  3. ведения документооборота и взаимодействия с контрагентами;
  4. осуществлять расчет эффективности работы персонала;
  5. выполнять все операции с помощью RF-терминалов;
  6. управлять заданиями для сотрудников и контроль загрузки персонала;



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


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


Поскольку в статье присутствует слово Анализ, то проанализировав ситуацию и прочитав множество статей и заглянув в английскую версию статьи Magic Quadrant for Warehouse Management Systems, можно сделать вывод, что компания Manhattan Associates являются лидерами в области представлений услуг WMS и SCM, а их продукция пользуется спросом не только в России, но и за рубежом. Это не сказки, если не верите. Вот вам тот же Магический квадрант, но только за 2019 год.


Если выбирать то выбираете продукцию компании Manhattan Associates, но так же не стоит забывать и о других продуктах и компаниях! Может, что-то из них подойдет и вашим потребностям! Это, конечно, дорого, но надежнее чем разрабатывание своего решения!

Квадрант за 2019 год.


Данный квадрант можно найти на сайте компании Gartner https://www.gartner.com/




Автор: Евченко Иван Валерьевич


Северо-кавказcкий социальный институт 2020 год

Подробнее..

Использование компьютерных симуляторов. Утром софт, вечером железо

16.11.2020 22:16:56 | Автор: admin
После того, как мы здесь и здесь разобрали, что же такое компьютерные симуляторы и какими они бывают, настало время поговорить о том, как они используются. И начну я, пожалуй, с наиболее интересной области применения расскажу о том, как профессиональные программисты используют симуляторы при разработке ПО, чтобы написать и отладить софт для железа, которого еще даже не существует.

image

Речь пойдет об использовании моделей не самых простых устройств, таких как, например, SoC (System on Chip) или печатных плат со множеством интегрированных устройств на борту. В разработке самих этих устройств можно выделить два этапа. Сначала разрабатывается аппаратная часть. Это процесс небыстрый может занять и год, и больше.

После того как появляется первая ревизия физического устройства и проводятся базовые проверки, устройство передается разработчикам ПО. С этого момента начинается вторая фаза разработка софта для устройства. Это могут быть прошивки (firmware), BIOS, BSP/CSP (Board and CPU Support Package) для различных операционных систем, а также драйвера.

image
Кстати, в разработке чипов, которые часто называют силикон (silicon), эти фазы именуются пре-силикон (pre-silicon) и пост-силикон (post-silicon) или просто силикон.

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

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

И тогда на помощь разработчикам ПО приходят симуляторы!

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

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

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

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

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

Большие компании-производители устройств могут поддерживать целую экосистему, выстроенную вокруг своих продуктов. В такую экосистему входят множество других компаний, в том числе и тех, которые производят ПО для данного оборудования. Например, это могут быть производители BIOS, так называемые IBV (Independent BIOS Vendors), наиболее известные из которых AMI, Insyde, Phoenix. Такие компании также получают модели от производителя оборудования и начинают разработку до появления физического устройства. Например, для платформ Intel используется симулятор Simics, о чем подробнее можно прочитать в статье Ecosystem Partners Shift Left with Intel for Faster Time-to-Market.

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

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

Что в итоге получается?

Если принять, что время разработки железа и софта примерно равны друг другу (см. картинку выше), то использование моделей позволяет существенно, практически в 2 раза, сократить время вывода продукта на рынок (т.н. TTM Time To Market), так как разработка железа и софта ведется параллельно, а не последовательно. Для этого часто используют термин Shift Left, пришедший из области тестирования, где он означал как можно более раннее тестирование. Этот же термин применим и к разработке ПО, которая как бы сдвигается влево по шкале времени, когда выполняется на симуляторе.

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

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

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

FI или финансовая аналитика что, где, когда?

17.11.2020 16:15:10 | Автор: admin

Что, Где, Когда?


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


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



Своя игра


Итак, в мире наступающей цифровизации всем понятно зачем нужно знать такие показатели бизнеса, как: средний чек покупателя, конверсия, ARPU (средний доход с пользователя), LTV (доход с пользователя за все время пользователя сервисом), стоимость привлечения клиента и т.д. Основа этого финансовый план.
Родина начинается с картинки в букваре, а успех и прибыль компании с продуманного бизнес-плана, построения бюджета и его исполнения.
Что такое бюджет? Зачем он необходим компании?



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



Шаг первый: Записывать все доходы и расходы.
Шаг второй: После появления определенной статистики доходов и расходов, выявить обязательные и необязательные траты это и называется (взрослая самостоятельная жизнь) финансовым анализом.
Шаг третий: Сформировать бюджет на год. Процесс бюджетирования основывается на статистике доходов и расходов, закладывая определенный процент на непредвиденные траты, а также учитывая краткосрочные финансовые цели на горизонте до или чуть свыше года.
Шаг четвертый: Чтобы достичь конечной цели пенсионный капитал нашему герою необходимо овладеть такими инструментами как прогнозирование и стратегическое планирование. Отличие этих двух процессов от бюджетирования заключается в горизонте планирования (бюджет обычно строится на год) и определенных допущениях, т.к. не все ситуации в следующие 5-10-15 лет можно предугадать. Только при составлении прогноза с учетом своих стратегических планов (ипотека, дети, путешествия) наш герой может просчитать, какие инструменты накопления он может использовать для того, чтобы жить комфортно.
Этот пример из жизни человека отличается от жизненного цикла компании одним масштабом.
Давайте рассмотрим как поэтапно происходят такие процессы в компании?


Где логика?



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


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

Поле чудес


Следующий важный этап в развитии управления компанией объединение разных систем информации в интегрированную ИС: Систему Управления Эффективностью Организации (CPM Corporate Performance Management), которая является комплексом взаимосвязанных процессов, методологий и подсистем. Решения CPM охватывают все бизнес-задачи в области стратегии и финансов.
Какое же решение CPM выбрать? На что необходимо обратить внимание?
На помощь приходит Магический квадрант Гартнера это отчет, необходимый для оценки и выбора наиболее подходящей для компании автоматизированной системы.
Gartner (Гартнер) это консалтинговая и аналитическая компания, которая специализируется в сфере ИТ: исследует поставщиков, которые представляют инфраструктурные ИТ решения для компаний.



Как читать этот магический квадрант и что все это значит? Давайте разберемся.



По квадранту:
Лидеры (Leaders) лидирующие решения на данном рынке (рынок указан в самом названии таблицы). Хорошо себя зарекомендовавшее законченное решение, которое покрывает нужды подавляющего большинства заказчиков, и имеющее понятное развитие в будущем.
Нишевые игроки (Niche players) не очень широко распространенные на данном рынке решения. Как правило заточены на решение определенных или очень специфических (узких относительно всего этого рынка) задач.
Претенденты (Challengers) законченные целостные решения, достаточно широко распространенные на рынке, но не показывающие четкие тенденции будущего развития. Решения, которые сейчас работают хорошо, но непонятно, как они буду взаимодействовать с новыми постоянно добавляемыми в инфраструктуру компонентами, а производитель ничего конкретного по этому поводу не сообщает.
Визионеры (Visionaries) такие компании не сильно представлены на рынке, но агрессивно рассказывают о перспективах своего развития в будущем. Часто появляются новички с уже готовым и быстроразвивающимся продуктом.


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


  1. Название квадранта им определяется рынок решений, который рассмотрен в данном квадранте;
  2. Дата выхода. Учитывая, что рынки в сфере высоких технологий быстро развиваются и меняются, квадранты старше 2 лет не имеет смысла. Такие квадранты можно рассмотреть только в качестве представления исторического развития данного сегмента рынка;
  3. Шкала оценки: "Зрелость уже сейчас" (Ability to execute) и "Перспективность в будущем" (Completeness of vision). Любой продукт или решение оценивается исходя из готовности и возможности развития продукта в будущем;
  4. Соотношения оценок и представления на рынке: "Нишевые игроки", "Претенденты", "Провидцы" и "Лидеры".
    Сам факт попадания в квадрант, в любую категорию, уже говорит о том, что решение данного вендора заслуживает внимания. Ориентируйтесь на квадрант, но в конечном выборе закупаемого решения необходимо также учитывать и другие факторы, соответствующие целям и возможностям самой компании.

Супер-приз


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

Подробнее..

В чем состоит работа ИТ-аналитика по улучшению бизнес-процессов

21.11.2020 22:12:40 | Автор: admin

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

Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться.

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

Понятия потребность и требование

В анализе и проектировании аналитик работает с двумя областями. Область потребностей = нужд (needs) и область решений (solution).

Закрыть одну потребность можно разными способами. Каждый способ имеет разные атрибуты качества. Поесть в ресторане быстрее и вкуснее, но купить продукты в магазине, приготовить и съесть что-нибудь дома дешевле.

Бизнес обращается к нам с какой-то проблемой, болью, которую он не знает как решить и наша задача - показать ему что делать.

Задача аналитика в поиске и выборе наиболее подходящего для заказчика способа решения (solution) его боли и проблемы.

Выявление потребностей и целеполагание

Пациент приходит к доктору и требует Выпишите мне аспирин, срочно!!!.

Требование = Выписать аспирин. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.

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

Требование лежит в области решения (solution). Поесть в ресторане, Приготовь еду - это требования.

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

Поэтому аналитик выявляет потребности и проектирует решение (требования к решению).

В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.

  1. Обеспечить функциональность

  2. Качественную работу

  3. Скорость/Производительность

  4. Безопасность

  5. Низкие издержки

  6. И т.п.

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

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

Выявление контекста и ограничений

Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее решениями (decision).

Разгрузить грузовик - это сложно? Неясно, так как неясен контекст.

К примеру, Разгрузи грузовик в минус 40, на дне озера и Разгрузи грузовик в плюс 25, на асфальте выглядят как совершенно разные задачи.

Для проектирования модели нужно разобраться в контексте того, как полученное решение (solution) будет использоваться, в каком процессе и для чего. Какая ситуация у заказчика.

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

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

  1. Сделать к черной пятнице,

  2. Сделать, потому что каждый день мы что то теряем,

  3. Сделать, иначе с какого-то момента мы будем каждый день что-то терять.

Таким образом выявляются ожидания/ограничения по срокам.

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

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

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

Кроме того, область решений (solution) ограничена еще:

  1. Ограничениями по ресурсам

  2. Требованиями удобства пользователей

  3. Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса

  4. Выбором подрядчиков и правилами привлечения новых

  5. Правилами работы с подрядчиками

  6. Требованиями безопасности и распространения информации

  7. Требованиями регуляторов

  8. И т.д.

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

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

Проектирование решения

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

Моделей системы может быть несколько (и довольно много), но типовые это

  1. Функциональная модель, отвечающая на вопрос как это работает, функционирует, обеспечивает функцию.

  2. Конструктивная модель, отвечающая на вопрос как это сконструировано, из каких частей состоит.

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

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

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

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

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

ИТ аналитику в поиске помогают

  • Знание того, как ИТ решают задачи по улучшению процессов,

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

  • Знание того, как ИТ решают задачи по улучшению процессов,

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

  • Знание того, как ИТ решают задачи по улучшению процессов,

  • Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

  • Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

  • Знание предметной области,

  • Знание процессного управления и процессов управления изменениями,

  • Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

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

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

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

Дайте мне аспирин А это вылечит вашу боль?(неизвестно, если причина боли не диагностирована)

Внедрение решения

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

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

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

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

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

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

Резюме

Работа аналитика это превращение проблем в задачи, при котором характерны этапы:

  1. Выявление потребностей и целеполагание,

  2. Выявление контекста и ограничений,

  3. Проектирование решения,

  4. Внедрение решения.

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

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

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

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

P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье

Подробнее..

Перевод Анализ данных Twitter для ленивых в Elastic Stack (сравнение Xbox и PlayStation)

23.11.2020 18:14:08 | Автор: admin

В преддверии супер-интенсива "ELK" подготовили для вас перевод полезной статьи.


Данные Twitter можно получить множеством способов но кому хочется заморачиваться и писать код? Особенно такой, который будет работать без перебоев и перерывов. В Elastic Stack вы можете с легкостью собирать данные из Twitter и анализировать их. Logstash может в качестве входных данных собирать твиты. Инструмент Kafka Connect, которому посвящена недавняя статья, тоже предоставляет такую возможность, но Logstash может отправлять данные во многие источники (включая Apache Kafka) и проще в использовании.

В этой статье мы рассмотрим следующие вопросы:

  • Сохранение потока твитов в Elasticsearch через Logstash

  • Визуализации в Kibana (сравнение Xbox и PlayStation)

  • Удаление HTML-тегов для ключевого слова с использованием механизма стандартизации

Окружение Elastic Search

Все необходимые компоненты находятся в одном Docker Compose. Если у вас уже есть кластер Elasticsearch, вам понадобится только Logstash.

version: '3.3'services:  elasticsearch:    image: docker.elastic.co/elasticsearch/elasticsearch:7.9.2    restart: unless-stopped    environment:      - discovery.type=single-node      - bootstrap.memory_lock=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"    ulimits:        memlock:            soft: -1            hard: -1    volumes:      - esdata:/usr/share/elasticsearch/data    restart: unless-stopped    ports:      - 9200:9200  kibana:    image: docker.elastic.co/kibana/kibana:7.9.2    restart: unless-stopped    depends_on:      - elasticsearch    ports:      - 5601:5601  logstash:    image: docker.elastic.co/logstash/logstash:7.9.2    volumes:      - "./pipeline:/usr/share/logstash/pipeline"    environment:      LS_JAVA_OPTS: "-Xmx256m -Xms256m"    depends_on:      - elasticsearch    restart: unless-stoppedvolumes:  esdata:    driver: local

Конвейер Logtash

input {        twitter {        consumer_key => "loremipsum"        consumer_secret => "loremipsum"        oauth_token => "loremipsum-loremipsum"        oauth_token_secret => "loremipsum"        keywords => ["XboxSeriesX", "PS5"]        full_tweet => false        codec => "json"        }}output {        elasticsearch {            hosts => ["elasticsearch:9200"]            index => "tweets"        }}

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

Конфигурация самого конвейера очень проста. Поток твитов будет подбираться по словам вkeywords. Если вам нужно больше метаданных, просто присвойте параметруfull_tweet valueзначениеtrue.

Данные

Спустя некоторое время после выполнения командыdocker-compose up -d в индексе tweets появляются данные. На момент написания этой статьи мои данные собирались примерно два дня. Весь индекс весил около 430МБ, что не так уж и много. Возможно, другая лицензия позволила бы получить больший поток данных. Визуализации в этой статье отображают данные, собранные за два дня.

ILM здесь нет. Только простой индекс.ILM здесь нет. Только простой индекс.

Итак, у нас уже есть индексtweets. Чтобы иметь возможность использовать собранные данные в Kibana, необходимо добавить шаблон индекса.

Пример документа в индексеtweets.Пример документа в индексеtweets.

Облако тегов Xbox и PlayStation

Простое облако тегов с агрегациейhashtags.text.keyword. PS5, судя по всему, выигрывает, но рассмотрим и другие варианты визуализации.

Линейный график Xbox и PlayStation

Тут у меня тоже складывается впечатление, что PlayStation встречается чаще, чем Xbox. Чтобы узнать наверняка, попробуем сгруппировать хештеги. Некоторые пишутPS5, другиеps5, а ведь это один и тот же продукт.

Однако прежде чем двигаться дальше, обратим внимание на один момент. Важен ли порядок бакетов? Разумеется. Вот что произойдет, если изменить гистограмму изTerms.

Чтобы сгруппировать хештеги, мы можем использовать агрегированные фильтры. Добавим еще несколько хештегов, намеренно опустив наименее популярные. В поле Filter используется синтаксис KQL Lucene, только мощнее.

Используем фильтрыhashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation) иhashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox). Теперь мы точно знаем, что PlayStation популярнее в Twitter.

Timelion

XBOX И PLAYSTATION

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

К синтаксису сперва надо привыкнуть. Ниже приведен код, сгенерировавший эту диаграмму.

.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)').label("PS"),.es(index=tweets, q='hashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox)').label("XBOX")

Смещение

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

.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)').label("PS"),.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)', offset=-1d).label("PS -1 day")

Вариативность функции (дельта)

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

.es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)')    .subtract(        .es(index=tweets, q='hashtags.text.keyword: (PS5 OR ps5 OR PlayStation5 OR PlayStation)', offset=-1h)    )    .label("PS 1h delta"),.es(index=tweets, q='hashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox)')    .subtract(        .es(index=tweets, q='hashtags.text.keyword: (XboxSeriesX OR Xbox OR XboxSeriesS OR xbox)', offset=-1h)    )    .label("XBOX 1h delta")

Круговая диаграмма типы клиентов

Так себе диаграмма

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

Хорошая диаграмма

У Elasticsearch множество возможностей для обработки текста. Так, фильтрhtml_strip позволяет удалять HTML-теги. К сожалению, нам он ничего не даст, поскольку анализаторы можно использовать только для полей типаtext, а нас интересует поле keyword. Для полей этого типа можно использовать агрегацию.

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

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

POST tweets/_closePUT tweets/_settings{  "analysis": {    "char_filter": {      "client_extractor": {        "type": "pattern_replace",        "pattern": "<a[^>]+>([^<]+)</a>",        "replacement": "$1"      }    },    "normalizer": {      "client_extractor_normalizer": {        "type": "custom",        "char_filter": [          "client_extractor"        ]      }    }  }}POST tweets/_open

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

PUT tweets/_mapping{  "properties": {    "client": {      "type": "text",      "fields": {        "keyword": {          "type": "keyword",          "ignore_above": 256        },        "value":{          "type":"keyword",          "normalizer":"client_extractor_normalizer"        }      }    }  }}

К сожалению, это еще не все. Данные индексируются при их добавлении в индекс (интересно, кстати, почему нельзя было назвать его коллекцией, как вMongoDB? ). Мы можем осуществить повторную индексацию документов с помощью механизма Update By Query.

POST tweets/_update_by_query?wait_for_completion=false&conflicts=proceed

Эта операция возвращает task id. Она может отработать небыстро, если у вас много данных. Найти задачу можно с помощью командыGET _cat/tasks?v.

После обновления шаблона индекса в Kibana мы получим значительно более удобочитаемую диаграмму. Здесь мы видим, что примерно одинаковое количество пользователей используют iPhone и устройства Android. Меня крайне заинтриговал клиентBot Xbox Series X.

Что дальше?

У меня были планы разобраться соSpark NLP, но сначала, пожалуй, займусь потоком данных Twitter. Я собираюсь использовать готовые модели Spark NLP для определения языка, тональности текста и других параметров с помощьюSpark Structured Streaming.

Репозиторий

Ссылка


Подробнее об интенсиве "ELK" можно узнать здесь

Подробнее..

Как скрам помогает стать более сильным разработчиком?

28.11.2020 00:23:46 | Автор: admin

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

 Copyright Max Degtyarev (http://personeltest.ru/aways/www.behance.net/maxdwork) Copyright Max Degtyarev (http://personeltest.ru/aways/www.behance.net/maxdwork)

Если спросить программиста, то как правило, его будут заботить в основном знание какого-либо языка программирования, платформы, фреймворка, алгоритмов и структур данных, паттернов и принципов проектирования. В мире это принято называть Hard Skills.

Что до Soft skills, то, к сожалению, это считается чуть ли не лишним ингредиентом, пустой тратой времени, или же несущественным элементом. Ценность Hard Skills сильно выше, чтобы переставать работать с человеком из-за проблем с Soft Skills.

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

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

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

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

Итого: строить продукт сложно и дорого. Крайне сложно удержать в одной голове все эти моменты, а потому продукты строят, как правило, команды, а не личности.

Цель

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

Однако, здесь не достаёт чуточку цели.

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

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

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

Итерации

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

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

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

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

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

Для разработчиков из всего вышеизложенного важно одно: направление развития продукта (и компании) будет меняться, точно!

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

Пример плохого развития событий в фазовом подходе Waterfall.Пример плохого развития событий в фазовом подходе Waterfall.

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

  • Возможность скорректировать путь развития продукта, определив новое направление или возможности заработка.

  • Снизить потери в случае неправильных решений или не оправдавших себя ожиданий.

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

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

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

Как неудивительно, это требование должны удовлетворить разработчики, создав соответствующую архитектуру продукта.

Гибкая архитектура

Есть одна фундаментальная вещь, которую нужно понять с точки зрения разработки: преждевременное принятие решений (up-front design)это не всегда хорошо, а чаще плохо.

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

Итеративный подход Scrum ставится в противовес фазовому Waterfall, но так как это не является темой моих рассуждений, я приведу отличную статью на этот счёт.

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

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

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

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

  2. Выбрав фреймворк для написания программы, подумали ли вы насколько легко будет переключиться на другой фреймворк в случае необходимости?

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

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

Если вы или ваши коллеги уже применяете такого рода анализ, тогда возможно вы уже в безопасности.

Ещё один сложный вопрос: как вести разработку в условиях изменяющихся требований? Изменяющиеся требования среди разработчиков принято считать чем то очень плохим.
Это происходит из-за того, что необходимость менять требования заложена в понятие программного (Softгибкий) обеспечения, но не указана явно.

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

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

When requirements change, the difficulty in making such a change should be proportional to the scope of the change, not to the shape of the change. The difference between scope and shape often drives the growth in software development costs. It is the reason that the first year of development is much cheaper than the second, and the second year is much less expensive than the third.

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

Robert C. Martin, Clean Architecture: A Craftsmans Guide to Software Structure andDesignRobert C. Martin, Clean Architecture: A Craftsmans Guide to Software Structure andDesign Роберт Мартин, Чистая Архитектура: искусство разработки программного обеспечения. Роберт Мартин, Чистая Архитектура: искусство разработки программного обеспечения.

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

Нет, я не говорю перестать писать код вообще и перейти на готовые конструкторы. И нет, я не говорю перестать создавать ПО. Я говорю о том, чтобы начать делать ровно то, что приносит ценность, и перестать делать то, что только отнимает усилия. Вот некоторые факты:

  • Меньше нового кода, означает меньше поддержки.

  • Меньше нового кода также означает меньше всего что может сломаться (работает, не трогай! помните?).

  • Меньше нового кодаменьше когнитивной нагрузки.

  • Меньше нового кодабольше уверенности в результате работы.

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

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

  2. Ровно так же, не стоит писать свой код реализации шифрования. Не стоит писать код там, где вы не являетесь специалистом. Ваши пользователи, как и бизнес, этого не оценят.

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


Если говорить о коде, то программисты нанимаются для того, чтобы вносить изменения в поведение программного обеспечения так быстро, насколько это возможно. Разработчики могут поддерживать скорость изменений на достаточном уровне только создавая достаточно гибкую архитектуру. Для этого требуется своевременная коммуникация с бизнесом для выяснения что на самом деле ему надо. Также, требуется тщательно продумывать каждое изменение, контролируя архитектуру и технический долг, и постоянно уточняя требования. Если не обратить внимание хотя бы на одну из этих составляющих (перестать коммуницировать с бизнесом или же не обращать внимание на архитектуру), то так или иначе, но скорость внесения изменений очень быстро упадёт, и к вам возникнут вопросы. В последнее время всё чаще встречаются термины Agile Architecture и Lean Architecture. Я предпочитаю объединить эти понятия в одном термине: Гибкая архитектура.

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

Сильный разработчик

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

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

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

Представьте, насколько сильно изменилась архитектура Android, который изначально был задуман как операционная система для камер, и только. А теперь это одна из двух самых популярных мобильных платформ. Другой пример, PayPal, который создавался как сервис перевода денег между телефонов с операционной системой Palm OS. А теперь сервис обрабатывает миллионы платежей по всему миру.
Врядли, развитие кодовой базы этих проектов было монотонным ростом функционала из года в год. Уверен, что такие изменения, словно большой взрыв, порождают массу работ по адаптации, рефакторингу и переписыванию с ноля. Это конечно одни из самых сложных случаев. Но кто может заранее предположить путь вашего проекта?

А где жескрам?

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

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


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

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


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

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


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

Вывод

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

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

Подробнее..

Protobuf vs Avro. Как сделать выбор?

29.11.2020 16:21:40 | Автор: admin

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

Размер и скорость

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

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

Фишка протобaфа в том, что, при сериализации целых чисел, по-умолчанию, используется формат переменной длины (varint), который занимает меньше места для небольших положительных чисел. Протобаф добавляет в бинарный поток номер поля и его тип, что увеличивает итоговый размер. Также, если в сообщение входят поля типа запись (nested message в терминологии протобафа), предварительно нужно вычислить итоговый размер записи, что усложняет алгоритм сериализации и занимает дополнительное время.

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

Типы данных

Примитивные типы, представленные в обоих форматах: bool, string, int32(int), int64(long), float, double, byte[]. Протобаф также поддерживает uint32, uint64.

В протобафе, по-умолчанию, целые числа кодируются в формате varint, эффективном для небольших положительных чисел. Вы можете изменить это, указав : sint32, sint64, fixed32, fixed64, sfixed32, sixed64.

Из коллекций вам доступны массивы и отображения (map). Ключом в отображении должна быть строка (в случае протобафа также допускается целое число).

Оба формата поддерживают перечисления (enumerations).

Сложные типы конструируются с помощью алгебраического умножения (records в авро, message в протобафе) и сложения (union в авро, oneof в протобафе).

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

Оба формата поддерживают механизмы расширения системы типов (logical types в авро и well known types в протобафе). Таким образом обе схемы дополнительно поддерживают сериализацию даты и времени (timestamp) и продолжительности времени (duration).

В отличии от авро, протобаф не поддерживает decimal и UUID. Также авро поддерживает тип fixed - массив байт определенной длины.

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

Эволюция данных

Обе схемы поддерживают механизмы обратной совместимости (backward compatibility) за счет заполнения новых полей значениями по-умолчанию. В авро можно указать любое, допустимое значение, в протобафе это значение задано жестко, в зависимости от типа (0, пустая строка, false). В авро также поддерживаются альтернативные имена (aliases) для полей и именованных типов (record, enum, fixed). В протобафе имя поля не используется в двоичной сериализации, но номер поля не может быть изменен.

Для числовых типов, в авро допускаются только преобразования без потери (например int в long, float в double, но не наоборот). Протобаф более толерантен к изменению числовых типов и применяет правила преобразования, идентичные C++. Также протобаф допускает преобразования из bool в число и обратно, из целого числа в enum и обратно.

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

Неизвестное поле в записи игнорируется обоими форматами.

В случае неизвестного значения enum, авро подставляет значение по-умолчанию, если оно задано, протобаф - нулевое значение.

Неизвестный вариант (case) в объединении (union) протобаф помечает признаком unknown. Авро же, в этом случае, выдает исключение и прерывает десериализацию.

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

Представление в Json

Как авро, так и протобаф, поддерживают сериализацию в Json. Это может быть полезно, как для отладочных целей, так и для долгосрочного хранения данных (например, в MongoDB).

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

Неприятным свойством авро является то, что массив байт (типы bytes, fixed) сохраняется в виде UTF16 строки. Это не только порождает визуальный мусор (псевдографика, переводы строк и т.п), но и может сделать Json нечитаемым, так как не все библиотеки корректно транслируют UTF16. Протобаф же сохраняет массив байт в base64.

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

Влияние на архитектуру

Выбрав авро, вы должны будете решить, где хранить схему. В том случае, если вы работаете с большим количеством сообщений малого размера (например, отправляете сообщения через кафку), вам нужно хранить схемы данных в отдельном хранилище (например, использовать Schema Registry). Вам потребуется реализовать кеширование схем, что привнесет в вашу систему состояние (statefullness), будет забирать время на прогрев при запуске.

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

RPC

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

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

Сервис протобафа допускает как синхронный вызов, так и отправку потока данных (streaming) в обоих направлениях.

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

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

Kafka

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

Hadoop

Ситуация зеркальна gRPC. Несмотря на то, что Hadoop - это вотчина авро, с помощью библиотеки elephant-bird вы можете использовать протобаф в связке с хадупом.

Комьюнити

Оба продукта доступны в открытом коде.

https://github.com/apache/avro (1.7K звезд, 1.1К форков)

https://github.com/protocolbuffers/protobuf (45K звезд, 12.1К форков)

Подробнее..

Опрос. Денормализация или нет?

29.11.2020 18:06:30 | Автор: admin

Недавно мы с коллегой по профессии обсуждали в Интернете (точнее в ЛС на Хабре) архитектуру некоторой системы, и у нас возник спор по одному вопросу.


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


Считать ли таблицу "current_stocks" денормализацией данных?


Аргумент коллеги заключается в том, что данные в "current_stocks" можно рассчитать по документам за все время существования системы, поэтому это денормализация.


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

Подробнее..

Доменный регистратор, или Туда и обратно

30.11.2020 12:14:44 | Автор: admin

Короткая история

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

Что такое домен?

Думаю, очень многие представляют себе, что такое домен, или доменное имя. Это некоторое слово, которое заменяет настоящий адрес интернет-сервера. Например, "habr.com" - доменное имя, состоящее из домена верхнего уровня "com" и домена второго уровня "habr".

Иерархическая организация доменных имён (reg.ru)Иерархическая организация доменных имён (reg.ru)

Каждой доменной зоной кто-то владеет и заведует. Доменная зона .com принадлежит компании Virisign (ранее Network Solutions). Это означает, что эта компания выдаёт разрешения на пользование доменами .com, в том числе habr.com. При покупке домена на год (в реальности аренде), запрос в конечном итоге уходит на сервера данной компании.

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

Доменные регистраторы

Если доменными зонами кто-то владеет, почему они не продают их людям? Потому что этим занимаются доменные регистраторы.

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

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

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

Фрагмент из документации Фрагмент из документации

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

Профит

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

Аукцион доменов

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

Как видим, желаемый bank.ru уже занят, а какой-то банк.рус (?) стоит уже 3млн. Домен bank.ru однажды освободится, и тогда на него будет много желающих.

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

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

Однако если у вас несколько клиентов и несколько доменов, задача усложняется. Вы сначала отправите запрос на покупку A.ru, потом cat.ru, и так далее. Шансы на успех покупки каждого последующего домена уменьшаются, так как кто-то мог поставить для себя покупку домена cat.ru первым приоритетом. Тогда этот домен достанется ему, а вы вернёте деньги покупателю и разочаруете его.

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

Что касается высоких цен на свободные домены - их определяет исключительно спрос.

Взаимодействие с Системой регистрации

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

Регистратор отправляет запросы в реестр, используя EPP поверх TCP. Команды формируются с помощью XML. ПО Регистратора должно как составлять XML-запросы, так и иметь синтаксический анализатор XML для интерпретации ответов от Реестра. EPP в свою очередь функционирует только через аутентификацию Регистратора для безопасности, которая достигается путём использования TLS в шифровании сессии. Можно использовать как коммерческую, так и свободную реализацию TLS, например, OpenSSL.

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

Объекты реестра

Основные объекты реестра - Контакт, Домен, Хост и Регистратор. Регистратор - это мы. Отправляя все запросы на покупки и регистрации, мы оставим там свой след - id своего регистратора.

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

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

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

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

Проектирование библиотеки

Registry

Взаимодействие со всей библиотекой происходит через класс-регистратуру. В ней создаются объекты для взаимодействия с любым классом системы. Конструктор реализован паттерном Singleton (Одиночка) для максимального переиспользования как объектов Домен/Контакт/Хост, так и для поддержания сохранности доменной зоны, id клиента, пароля, ssl-сертификата и его ключа, а также языка взаимодействия, объекта curl для отправки запросов.

В этом же классе реализованы функции для работы с XML. Реализация каждого из двух методов составила около 20 строк, что значительно легче готовых библиотек для работы с XML. Более того, это обеспечило гибкость появилась возможность собственного представления вложенных структур для объектов, которые легко собираются в XML.

Registrar, Host, Domain, Contact

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

Poll

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

R

Классы R (от англ. Regexp) классы проверки, в основном на регулярных выражениях. В них проходит та самая валидация, которая вызывается в основных классах. Есть R в пространстве имён RU это те функции и выражения, которые не понадобятся в других зонах. Например, номер телефона и ИНН (телефон в РФ особенный, ИНН существует только в РФ). R в пространстве имён Registrar будет применим ко всем будущим доменным зонам и к текущей.

Base

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

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

Как упоминалось выше, все объекты пришлось хранить и у себя в системе для адекватной работы.

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

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

Технические испытания

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

Заключение

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

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

Желаю удачи!

Подробнее..

Перевод Макропроблема микросервисов

30.11.2020 16:22:04 | Автор: admin

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

Давайте с помощью краткого экскурса по истории сетевых приложений разберёмся, как мы пришли к сегодняшней ситуации. А затем поговорим о модели исполнения с сохранением состояния (stateful execution model), используемую в Temporal, и о том, как она решает проблемы сервис-ориентированных архитектур (service-oriented architectures, SOA). Я могу быть предвзятым, потому что руковожу продуктовым отделом в Temporal, но считаю, что за этим подходом будущее.

Короткий исторический урок


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

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

Люди как ПО




В последние 20 лет требования к ПО постоянно растут. Сегодня приложения должны с первого же дня работать на глобальном рынке. Компании вроде Twitter и Facebook превратили онлайн-режим 24/7 в необходимое условие. Приложения больше не обеспечивают работу чего-либо, они сами превратились в пользовательский опыт. Сегодня у каждой компании должны быть программные продукты. Надёжность и доступность уже не свойства, а требования.

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

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


Бесплатного сыра не бывает


Хотя микросервисы решили проблемы масштабирования и доступности, мешавшие росту ПО, не всё было безоблачно. Разработчики начали понимать, что у микросервисов есть серьёзные недостатки.

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

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

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

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

Однако на спрос возникает предложение. Чем шире распространялись микросервисы, тем больше росла мотивация разработчиков к решению инфраструктурных проблем. Медленно, но уверенно начали появляться инструменты, и пробел заполнили технологии вроде Docker, Kubernetes и AWS Lambda. Они очень сильно облегчили эксплуатацию микросервисной архитектуры. Вместо того, чтобы писать свой код для оркестрирования контейнерами и ресурсами, разработчики могут опираться на уже готовые инструменты. В 2020-м мы наконец-то достигли рубежа, когда доступность нашей инфраструктуры больше не мешает надёжности наших приложений. Прекрасно!


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

Другая проблема микросервисов


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


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

public void transferWithoutTemporal(  String fromId,   String toId,   String referenceId,   double amount,) {  boolean withdrawDonePreviously = myDB.getWithdrawState(referenceId);  if (!withdrawDonePreviously) {      account.withdraw(fromAccountId, referenceId, amount);            myDB.setWithdrawn(referenceId);  }  boolean depositDonePreviously = myDB.getDepositState(referenceId);  if (!depositDonePreviously) {      account.deposit(toAccountId, referenceId, amount);                      myDB.setDeposited(referenceId);  }}

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

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


Temporal


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

До сегодняшнего дня не было решения, позволяющего использовать микросервисы без расхлёбывания вышеописанных проблем. Вы можете тестировать и эмулировать сбойные состояния, писать код с учётом падений, но эти проблемы всё-равно возникают. Мы считаем, что Temporal их решает. Это open-source (MIT, без дураков) stateful-среда для оркестрации микросервисов.

У Temporal два основных компонента: stateful-бэкенд, работающий на выбранной вами БД, и клиентский фреймворк на одном из поддерживаемых языков. Приложения создаются с помощью клиентского фреймворка и обычного старого кода, который автоматически сохраняет изменения состояния в бэкенде по мере исполнения. Вы можете использовать те же зависимости, библиотеки и цепочки сборки, что и при создании любого другого приложения. Честно говоря, бэкенд сильно распределён, так что это не как с J2EE 2.0. По сути, именно распределённость бэкенда обеспечивает почти бесконечное горизонтальное масштабирование. Temporal обеспечивает для уровня приложений согласованность, простоту и надёжность, как это сделали для инфраструктуры Docker, Kubernetes и бессерверная архитектура.

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

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

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

Сохранение состояния реализуется и в виде устойчивых таймеров. Это отказоустойчивый механизм, которым можно пользоваться с помощью команды Workflow.sleep. Она работает точно так же, как нативная языковая команда sleep. Однако с Workflow.sleep можно безопасно усыплять на любой промежуток времени. Многие пользователи Temporal используют усыпление на недели, и даже годы. Это достигается с помощью хранения длительных таймеров в хранилище Temporal и отслеживания кода, который нужно разбудить. Повторюсь, даже если сервер упадёт (или вы его просто выключили), код перейдёт на доступную машину по срабатыванию таймера. Процессы сна не потребляют ресурсов, вы можете иметь их миллионы при ничтожных накладных расходах. Возможно, звучит слишком абстрактно, так что вот пример рабочего Temporal-кода:

public class SubscriptionWorkflowImpl implements SubscriptionWorkflow {  private final SubscriptionActivities activities =      Workflow.newActivityStub(SubscriptionActivities.class);  public void execute(String customerId) {    activities.onboardToFreeTrial(customerId);    try {      Workflow.sleep(Duration.ofDays(180));      activities.upgradeFromTrialToPaid(customerId);      while (true) {        Workflow.sleep(Duration.ofDays(30));        activities.chargeMonthlyFee(customerId);      }    } catch (CancellationException e) {      activities.processSubscriptionCancellation(customerId);    }  }}

Помимо сохранения состояния Temporal предлагает набор механизмов для создания надёжных приложений. Функции активностей вызываются из рабочих процессов, но код, работающий внутри активности, не является stateful. Хотя они и не сохраняют своё состояние, активности содержат автоматические повторы, таймауты и heartbeatы. Активности очень полезны для инкапсулирования кода, который может сбоить. Допустим, ваше приложение использует банковский API, который часто недоступен. В случае с традиционным ПО вам понадобится обернуть весь код, вызывающий этот API, выражениями try/catch, логикой повторов и таймаутами. Но если вызывать банковский API из активности, то все эти функции предоставляются из коробки: если вызов сбоит, активность будет автоматически повторена. Всё это прекрасно, но иногда вы сами являетесь владельцем ненадёжного сервиса и хотите защитить его от DDoS. Поэтому вызовы активностей также поддерживают таймауты, подкреплённые длительными таймерами. То есть паузы между повторами активностей могут достигать часов, дней или недель. Это особенно удобно для кода, который должен отработать успешно, но вы не уверены, насколько быстро это должно произойти.

В этом видео за две минуты объясняется модель программирования в Temporal:


Другой сильной стороной Temporal является наблюдаемость работающего приложения. API наблюдения предоставляет SQL-подобный интерфейс для запроса метаданных из любого рабочего процесса (исполняемого или нет). Также можно определять и обновлять свои значения метаданных прямо внутри процесса. API наблюдения очень удобен для Temporal-операторов и разработчиков, особенно при отладке в ходе разработки. Наблюдение поддерживает даже пакетные действия с результатами запросов. Например, можно отправить kill-сигнал во все рабочие процессы, соответствующие запросу со временем создания > вчера. Temporal поддерживает функцию синхронного извлечения, позволяющую вытаскивать значения локальных переменных из работающих экземпляров. Это словно отладчик из вашего IDE поработал с production-приложениями. Например, так можно получить значение greeting в работающем экземпляре:

public static class GreetingWorkflowImpl implements GreetingWorkflow {    private String greeting;    @Override    public void createGreeting(String name) {      greeting = "Hello " + name + "!";      Workflow.sleep(Duration.ofSeconds(2));      greeting = "Bye " + name + "!";    }    @Override    public String queryGreeting() {      return greeting;    }  }

Заключение


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

Цифровизация производства в РФ. Не отрываясь от реальности

01.12.2020 10:20:26 | Автор: admin

Питеркин Сергей, Райтстеп. 2020г

Тезисы

1.4я промышленная революция (Industry 4.0, цифровизация) подразумевает полную интеграцию:

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

  • и средств исполнения: люди, машины и механизмы, оборудование

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

2.При этом кибер-физические системы Industry 4.0 (далее I4.0) основываются на фундаменте базовых процессов: проектирования (изделий), планирования/управления производством и поставками, уже используемых сейчас предприятиями (Industry 3.0 I3.0.).

3.Очевидно, что без построения "фундамента" в виде I3.0, попытки внедрить элементыI 4.0 не приведут к принципиальным улучшениям. Т.к. будут работать на локальные области оптимизации, без синхронизации как со всей горизонталью цепочки поставок, так и с вертикалью этапов ЖЦ создания продукции для потребителя. Под ЖЦ имеется в виду жизненный цикл: разработка -> испытания -> ввод в серию (не обязательно переход к массовому производству, но обязательно - вывод из стадии опытного) -> планирование, закупка, производство -> передача потребителю.

4.Таким образом, цифровизация традиционных российских предприятий должна обязательно и первостепенно включать построение фундамента (I3.0), с цифровизацией (внедрением элементов I3.5 и I4.0) только там, где необходимо и оправдано (в узких местах процесса создания продукции для потребителя). Так, как это делали западные, а теперь уже и восточные, более эффективные производства. В любом другом случае все это будет выглядеть (и выглядит, судя по регулярно рапортуемым успехам наших цифровизирующихся заводов. Причем, как правило, не на деньги частных собственников) как попытка...взобраться на 4й этаж со 2го по приставной лестнице, у которой нет перекладин вначале.

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

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


ЭТАП 1: переход на уровень базовой автоматизации управления (Industry 3.0, уровень развития - 1990е гг)

Исходное состояние и задачи

Основная задача, стоящая на данном уровне развития, - переход на следующий уровень, I3.0. С уровня 2.0. (80е гг), на котором, если посмотреть реальности в глаза, находится большинство наших производств, разных размеров и форм собственности.

Для перехода необходимо решение следующих задач:

1) сокращение непроизводительных трудозатрат на процессы управления. Таких, как (пример):

  • затраты (время, человеко-часы работы) на ручное формирование/корректировка технологических составов изделий (ТСИ),

  • затраты на ручное (полуручное) планирование, и постоянные исправления ошибок/корректировки ручных планов,

  • затраты на ручной и/или неточный, неоперативный учет запасов, выполняемых и выполненных работ/поставок,

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

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

Что и как улучшаем

Разработка продукции переход на электронный состав

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

Уровень 1 автоматизация внутренней и внешней цепочки поставок. До площадки/цеха/участка

ЦЕЛЬ: сделать синхронизированное производство, по всей внутренней (завода) и внешней (поставщики и кооператоры) цепочке поставки [1]. Поставив процессы и автоматизировав их с ИТ-системой класса "СПМ - Система Планирования и Мониторинга производства и поставок" (далее СПМ).

Планирование (алгоритм планирования - "планировщик системы") работает на основании следующих групп данных. Не имея которые про планирование можно забыть

1. Что производим: состав изделия.

  • Что из чего сделано (что во что входит) количество.

  • Как делаем: маршрут и технология обработки/сборки (что, где и как делаем).

  • Временные характеристики (время производства, нормы).

Информация должна автоматически передаваться ("проецироваться") в СПМ из PDM, где ведутся электронные составы. Или вводиться непосредственно в СПМ.

2. Cредства производства.

  • Люди, их квалификация и доступность (график работы, эффективность).

  • Оборудование/обрабатывающие центры (ОЦ), их характеристики и доступность (график работы, эффективность).

Информация вводится в СПМ.

3. Что для этого есть: материалы, ПКИ, ДСЕ, инструмент, оснастка, приспособления.

  • Где, в каком месте цепочки (площадки, склады, цеха, участки, кладовые).

  • В каком количестве.

  • В каком статусе.

Информация вводится в СПМ.

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

  • Что и когда надо запустить/закупить, что нужно выпустить.

  • Какие ресурсы необходимы, в т.ч. для закупки.

  • Управление запуском: формирование Заказов поставщикам/кооператорам, формирование и запуск Производственных заданий (Производственных Партий), объектов управления всем циклом производства ДСЕ/сборок (это не сменно-суточные задания!).

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

Уровень 2 локальное (детализированное) планирование и автоматизация исполнения.

ЦЕЛЬ: реализовать продвинутые функции управления исполнением[2] синхронизированных позаказных планов, сделанных СПМ и переданных исполнителям.

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

2. После постановки и уверенной работы с 1м уровнем планирования автоматизация 2го уровня планирования.

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

  • Планирование и распределение работ по управлению запасами (склады, логистика), по кладовщикам, логистам (перевозчикам).

3. Автоматизация учетных функций: быстрый и простой ввод в систему (цеховые киоски, планшеты, штрих-кодирование) информации о факте: что и когда сделано/скомплектовано, перемещено.

Что должны получить

Как результат данного этапа: автоматизированная базовая производственная система, на уровне Industry 3.0. (см. рис. ниже)

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

Проекты преобразований

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

1. Постановка СПМ (Системы Планирования и Мониторинга производства и снабжения[3]) для обеспечения синхронизированного планирования и исполнения планов по всей, внутренней и внешней цепочке поставок. Для следующих областей управления.

  • ведение Позаказного (производственного) Состава Изделий,

  • планирование производства и снабжения, до уровня цехо/участко-заходов (переделы /этапы производства/группы операций),

  • управление поставками и кооперацией,

  • управление складами (запасами) снабжения и производства,

  • управление производством: запуск, учет хода производства (запуск/выпуск по участко/цехо-заходам), межучастковые/цеховые передачи,

  • мониторинг.

2. Постановка процессов продвинутого управления исполнением (СПМ-MES):

  • внутрицеховое планирование:

  • распределение работ по оборудованию/операторам,

  • управление очередями,

  • сменно-суточные задания,

  • пооперационный учет, включая управление качеством.

3. Автоматизация указанных выше учетных действий с использованием:

  • штрихкодирования,

  • цеховых терминалов.


ЭТАП 2. Следующий шаг к цифровизации Industry 3.0+

Основные задачи здесь следующие.

1) Сокращение непроизводительных трудозатрат процессов управления и сокращение некоторых традиционных ролей управления, как класса. Например, роли (и отделы): ПДО, ПДБ, ОГТ и/или цеховых технологов и нормировщиков.

2) Сокращение буферов страховых запасов и времени.

3) Сокращение себестоимости продукции.

4) Создание базы (входа) для кибер-физической системы I4.0.

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

Шаг 1. Повышение точности планирования - базовые данные

Цель: повысить точность планирования за счет повышения точности входящей информации, используемой при планировании.

1. Что производим: состав изделия.

  • Что из чего сделано (что во что входит) количество.

  • Как делаем: маршрут и технология обработки/сборки (что, где и как делаем).

  • Временные характеристики (время производства, нормы).

Информация автоматически поступает в СПМ из PLM. Используются ИТ-системы управления изделиями и системы имитационного моделирования.

1. В PLM проводится разработка составов изделий (СИ), с учетом корректного описания технологических процессов (вплоть до обрабатывающих программ для станков с ЧПУ) и проверки технологичности производства.

2.Проверка СИ на возможность производства, определение стартовых времен, микро-логистика, выполняется в системе Имитационного моделирования.

2. Средства производства.

  • Люди, их квалификация и доступность (график работы, эффективность).

Информация доступна для СПМ в автоматическом режиме из следующих систем.

1. Из ИТ-системы управления людскими ресурсами (плановое время работы).

2. Из электронной проходной (в развитии из продвинутой системы распознавания лиц).

3. Информация по эффективности работы каждого сотрудника вычисляется на основе сбора план/факт информации по исполнению (из СПМ см. ниже).

  • Оборудование/обрабатывающие центры (ОЦ): их характеристики и доступность (график работы, эффективность).

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

1. Информация по прогнозу планового времени работы оборудования: из системы ТОиР, системы управления обслуживанием (Predictive Maintenance), системы Цифровой двойник.

2. По информации из ИТ-системы автоматизированного сбора данных о работе оборудования - MDC (Machine Data Collection).

3. Плюс - план/факт информация по исполнению (из СПМ см. ниже).

3. Что для этого есть: материалы, ПКИ, ДСЕ, инструмент.

  • Где.

  • В каком количестве.

  • В каком статусе.

Система автоматического съема информации через RFID. Автоматический ввод в СПМ через считывание сигналов RFID с объектов учета и/или сопровождающих их документов. И/или, где необходимо и оправдано, автоматизированных складов.

Шаг 2. Повышение уровня детализации исполнения

По результатам планирования в СПМ.

1. Автоматическое создание рабочих заданий и передача исполнителям.

a.На личные мобильные устройства и/или цеховые/участковые экраны.

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

c.Задания на комплектацию производства/перемещения между складами/цехами/участками:

  • автоматизированные задания на автоматизированные склады (при наличии и целесообразности их использования),

  • и/или - задания на комплектацию/перемещения в электронном виде исполнителям, личные мобильные устройства,

  • и/или после автоматизированная доставка (роботы-тележки),

  • на уровне цеха, участка, рабочего.

d.На оборудование.

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

2. Автоматизированный съем факта исполнения рабочих заданий.

a. С оборудования по завершении обработки/этапов обработки.

b. С автоматизированных складов/тележек, о перемещении между складами/участками/цехами.

c. С видеокамер о начале/завершении процесса производства/сборки (технология пока под вопросом)

Комментарий

На уровне интеграции системы продвинутого управления исполнением (MES), могут быть также цифровизированы следующие процессы (если они узкие места производства!)

  • Автоматическое управление инструментом - калибровка, настройка уровня усилий, съем факта.

  • Интеграция с лабораторными системами информация о качестве.

  • Интеграция с системой распознавания лиц фактическая информация о начале/завершении производства.

  • Съемка перемещений сотрудников, с автоформированием профиля движений и расчетом производительных и лишних

  • и др.

Шаг 3. Повышение точности планирования план/факт

Повышение точности планирования на счет Автокалибровки[4] систем планирования и исполнения.

1. Используем план/факт информацию из п2. Шага 2.

2. Используем информацию по фактической работе/OEE оборудования.

3. Корректируем плановые данные (в СИ, времена производства, перемещения и пр.).

  • Собираем и предварительно очищаем фактические данные.

  • Алгоритмически (в т.ч. с алгоритмами работы c Big Data и AI) рассчитываем новые плановые данные.

  • Алгоритмически (массово, выборочно, условно) замещаем.

4. Далее - очередной автоматический цикл планирования/исполнения/корректировки данных.

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

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

Проекты преобразования

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

  1. Реализация процессов PLM, включая систему имитационного моделирования.

  • моделирование производства и логистики завода,

  • моделирование производства изделий, с минимизацией времени/себестоимости.

2. Цифровой двойник производства. Возможно пересечение с п.1.

3. ТОиР:

  • учет оборудования, съем факта работы/простоев (с использованием данных MDC),

  • расчет будущей эффективности, предсказание поломок, расчет графика ТОиР.

4. HCM (Human Capital Management) - система управления кадрами:

  • управление кадрами (продвинутые функции),

  • сбор информации по выработке, расчет эффективности.

5.MDC (Machine Data Collection):

  • автоматизированный сбор / мониторинг информации о работе оборудования,

  • расчет ОЕЕ с разными аналитиками.

6. RFID: автоматический учет движений ТМЦ и любых других материальных объектов с использованием маячков.

7. Автокалибровка: расчет плановых временных параметров изделий на основании план/факт отклонений.

Важно! Указанные выше проекты имеют смысл ТОЛЬКО при наличии централизованной общей шины управления (не столько программной, сколько логической) СПМ на уровнях Синхронизированное планирование и Продвинутое Исполнение. К которой присоединяются указанные выше локальные системы. И, за счет этого, начинающие работать не только для достижения локальных оптимумов, но и для принципиального точности и скорости обработки информации, и доведения его до уровня реальной КФС.

Этап 3. Industry 4.0 - цифровой завод

Задача:

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

2) - практически полное устранение прослойки людей в процессах управления (ПДО, ПДБ, кладовщики и т.п.) через замыкание информационных и связанных с ними материальных потоков, на единицах оборудования.

Но при этом:

  • обслуживающий системы (в т.ч. и СПМ) персонал остается,

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

Указанные выше задачи фактически описывают задачи для перехода на уровень I4.0 к функционировани. кибер-физической системы цифрового завода. И решаются они через внедрение соответствующих инструментов, по сценариям и направлениям 1го и 2го этапа, описанным выше. Кратко, это следующие действия (далее будет применятся общеизвестные для I4.0 англоязычные термины или сокращения, без расшифровки).

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

  • Моделирование новых процессов через средства Имитационного моделирования, Цифровые двойники, видео-съемки с анализом действий персонала с ее последующей оптимизацией.

  • Роботизация/оптимизация процессов производства через: RPA, IoT, 3D печать.

  • Оптимизация процессов производства (сборки) с участием людей, через: Cobotы, AR, VR

  • Оптимизация микро-логистических процессов через: RFID, автоматизированные склады/роботизированные тележки/дроны.

2.Повышение эффективности работы оборудования через: Predictive Maintenance, IoT.

3. Максимизация точности учета (для синхронного точного планирования и оптимальной работы роботизированных по п1 средств производства) через средства: компьютерного зрения, носимые устройства и датчики.

4.Повышение эффективности внешней цепочки поставок через использование: Blockchain, SCM Control Tower.


Заключение

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

Но, торопиться надо медленно. Роботизированная тележка, подвозящая комплектующие к роботизированному участку сборки, где немногочисленные операторы, в очках виртуальной реальности, собирают с первого предъявления все, как надо это, безусловно, выглядит круто! Но задайтесь вопросом: кто, как и когда будет на нее грузить то, что нужно именно в этот момент времени? И кто, как и когда определит этот момент? Ежемесячное и неточное планирование, на основании ТСИ, ведущегося в Excel, и запасы из бухгалтерского ПО, - точно не тот "фундамент", на который можно "поставить роботов" Индустрия 4.0 стоит на процессах Индустрии 3.0, не 2. Поэтому - только последовательное эволюционное и итерационное развитие!


Расшифровки по сноскам в тексте

[1] Используются система/алгоритмы и процессы среднего (RCCP-MRP-CRP[1] - по общепринятой классической классификации MRP-II) уровня планирования и исполнения.

[2] Часто и неправильно это называют MES. Хотя MES маркетинговое определение определенного класса ИТ-систем. Правильнее определять этот уровень как SFC (Shop Floor Control - цеховое управление), по общепринятой классической классификации MRP-II. Это уровень, соответствующий нижнему, детальному уровню планирования и исполнения. Тем не менее, для ясности в рамках данной статьи оставим его как MES.

[3] В данном контексте, СПМ можно назвать Производственной ERP.

[4] "Автокалибровка систем планирования и исполнения". Хотя это - всего-лишь реализации классического алгоритма управления с обратной связью, технология автоматического и быстрого применения его для производственных систем - пока на уровне НИР. Но перспективы ее, и прежде всего, для наших производств огромны!

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru