Как говорят иные отважные люди: «От dev до prod — всего один шаг». Люди опытные добавляют, что шаг этот называется «тестирование», причём самое разнообразное, и нам просто нет смысла им не верить.



Нагрузка имеет значение: водитель этого грузовика умудрился обрушить мост весом своего ТС, счёт за восстановление составил примерно 16m. К счастью, тестирование ПО обходится дешевле!

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

Нагрузочное тестирование

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

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

Давайте представим, что мы с вами написали некоторый сервис — для определённости скажем, что веб-сервис, но это не столь важно. Чтобы убедиться, на что мы с ним можем рассчитывать, мы начинаем «обстреливать» его запросами, наблюдая за поведением как самого сервиса, так и за нагрузкой на серверах, где он крутится. Хорошо, если заранее понятно, какие запросы нам нужно отправлять сервису (в этом случае мы можем подготовить массив запросов заранее, а после отправить его в наше приложение одним махом). Если же второй запрос зависит от результатов первого (простой пример — сначала происходит авторизация пользователя, и в следующие обращения к сервису включается информация об ID сессии), то генератор нагрузки должен быть способен генерировать тестовые запросы крайне быстро, в реальном времени.

С учётом обстоятельств и нашего знания об объекте тестирования выбираем инструмент(ы):

JMeter

Да, старый добрый JMeter. Он вот уже без малого двадцать лет (!) является частым выбором для многих вариантов и типов нагрузочного тестирования: удобный GUI, независимость от платформы (спасибо Java!), поддержка многопоточности, расширяемость, отличные возможности по созданию отчётов, поддержка многих протоколов для запросов. Благодаря модульной архитектуре JMeter можно расширить в нужную пользователю сторону, реализуя даже весьма экзотические сценарии тестирования — причем, если ни один из написанных сообществом за прошедшее время плагинов нас не устроит, можно взять API и написать собственный. При необходимости с JMeter можно выстроить, хоть и ограниченное, но распределённое тестирование, когда нагрузка будет создаваться сразу несколькими машинами.

Одной из удобных функций JMeter является работа в режиме прокси: указываем в настройках браузера в качестве прокси «127.0.0.1:8080» и посещаем браузером нужные нам страницы нужного сайта, тем временем JMeter сохраняет все наши действия и все сопутствующие запросы в виде скрипта, который позже можно будет отредактировать, как нужно — это делает процесс создания HTTP-тестов заметно проще.

Кстати, последняя версия (3.2), вышедшая в апреле этого года, научилась отдавать результаты тестирования в InfluxDB при помощи асинхронных HTTP-запросов. Правда, начиная как раз с версии 3.2, JMeter стал требовать только Java 8, но это, наверное, не самая высокая цена за прогресс.

Хранение тестовых сценариев у JMeter реализовано в XML-файлах, что, как оказалось, создаёт массу проблем: их совсем неудобно писать руками (читай — для создания текста необходим GUI), как неудобна и работа с такими файлами в системах управления версиями (особенно в момент, когда нужно сделать diff). Конкурирующие на поле нагрузочного тестирования продукты, такие, как Яндекс.Танк или Taurus, научились самостоятельно и на лету формировать файлы с тестами и передавать их в JMeter на исполнение, таким образом пользуясь мощью и опытом JMeter, но давая возможность пользователям создавать тесты в виде более читаемых и легче хранимых в CVS тестовых скриптов.

LoadRunner

Ещё один давно существующий на рынке и в определенных кругах очень известный продукт, большему распространению которого помешала принятая компанией-производителем политика лицензирования (кстати, сегодня, после слияния подразделения ПО компании Hewlett Packard Enterprise с Micro Focus International, привычное название HPE LoadRunner сменилось на Micro Focus LoadRunner). Интерес представляет логика создания теста, где несколько (наверное, правильно сказать — «много») виртуальных пользователей параллельно что-то делают с тестируемым приложением. Это даёт возможность не только оценить способность приложения обработать поток одновременных запросов, но и понять, как влияет работа одних пользователей, активно что-то делающих с сервисом, на работу других. При этом речь идёт о широком выборе протоколов взаимодействия с тестируемым приложением.

HP в своё время создала очень хороший набор инструментов автоматизации функционального и нагрузочного тестирования, которые, при необходимости, интегрируются в процесс разработки ПО, и LoadRunner умеет интегрироваться с ними (в частности, с HP Quality Center, HP QuickTest Professional).

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

Gatling

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

Следует учесть, что, в отличие от JMeter, Gatling не использует GUI и вообще считается средством, ориентированным на опытную, «грамотную» аудиторию, способную создать тестовый скрипт в виде текстового файла.

Есть у Gatling и минусы, за которые его критикуют. Во-первых, документация могла бы быть и получше, во-вторых, для работы с ним неплохо знать Scala: и сам Gatling, как инструмент тестирования, и тестовые сценарии пишутся именно на этом языке. В-третьих, разработчики «иногда» в прошлом кардинально меняли API, в результате можно было обнаружить, что тесты, написанные полугодом ранее, «не идут» на новой версии, либо требуют доработки/миграции. У Gatling также отсутствует возможность делать распределённое тестирование, что ограничивает возможные области применения.

Яндекс.Танк

Если коротко, Yandex Tank — это враппер над несколькими утилитами нагрузочного тестирования (включая JMeter), предоставляющий унифицированный интерфейс для их конфигурации, запуска и построения отчётов вне зависимости от того, какая утилита используется «под капотом».

Он умеет следить за основными метриками тестируемого приложения (процессор, память, своп и пр.), за ресурсами системы (свободная память/место на диске), может остановить тест на основе разных понятных критериев («если время отклика превышает заданное значение», «если количество ошибок за единицу времени выше, чем х» и т.д). Кстати, умеет отображать в реальном времени основные статистические данные теста, что бывает очень полезно прямо в процессе теста.

Танк используется и в самом Яндексе, и в других компаниях уже около 10 лет. Им обстреливают совершенно разные сервисы, с разными требованиями к сложности тестовых сценариев и к уровню нагрузки. Почти всегда для тестирования даже высоконагруженных сервисов хватает всего одного генератора нагрузки. Танк поддерживает разные генераторы нагрузки, как написанные специально для него (Phantom, BFG, Pandora), так и широко сторонние (JMeter). Модульная архитектура позволяет написать свой плагин под нужный генератор нагрузки и вообще прикрутить практически что угодно.

Для чего использовать разные генераторы нагрузки? Phantom — это быстрая «пушка» на C++. Один такой генератор может выдать до сотни тысяч запросов в секунду. Но для достижения такой скорости приходится генерировать запросы заранее и нельзя (не получается) использовать получаемые от тестируемого сервиса данные для генерации очередного запроса. В случаях, когда нужно исполнять сложный сценарий или сервис использует нестандартный протокол, следует использовать JMeter, BFG, Pandora.

В BFG, в отличие от Jmeter, нет GUI, тестовые сценарии пишутся на Python. Это позволяет использовать любые библиотеки (а их огромное количество). Часто бывает, что для сервиса написаны биндинги для Python, тогда их удобно использовать при написании нагрузочных сценариев. Pandora — это экспериментальная пушка на GoLang, достаточно быстрая и расширяемая, подходит для тестов по протоколу HTTP/2 и будет использоваться там, где нужны быстрые сценарии.

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

Taurus

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

Вообще, Taurus хорошо подойдёт в ситуации, когда мощность, скажем, Gatling важна для создания теста, но разбираться с Gatling (а также с написанием скриптов тестирования на Scala) нет желания или возможности: достаточно описать тест в куда более простом формате файла Taurus, настроить его на использование Gatling как инструмента создания нагрузки, и все Scala-файлы будут сгенерированы автоматически. Так сказать, «автоматизация автоматизации» в действии!

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

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

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

Казалось бы, померить производительность — это так просто! Два раза взять timestamp (желательно с высокой точностью), посчитать разность, сложили-поделили, и всё — можно оптимизировать. Как бы не так! Хотя на словах этот вопрос звучит просто, на деле такого рода замеры довольно затруднительно производить, а сравнивать результаты разных замеров вообще не всегда разумно. Одна из причин: для сопоставления результатов тесты должны проходить над одними и теми же исходными данными, что, среди прочего, подразумевает воссоздание тестовой среды при каждом прогоне проверки, другая причина — сравнение субъективного восприятия времени работы тестового сценария может оказаться неточным.
Ещё одной причиной является сложность выделения влияния на производительность целого приложения работы отдельного его модуля, того, который мы сейчас правим. Усугубляя ситуацию, уточняем: ещё сложнее это влияние вычленить, если над кодом работает коллектив из более чем одного разработчика.

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

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

JMH

JMH (Java Microbenchmark Harness) — это оснастка Java для сборки, запуска и анализа нано/микро/милли/макро-бенчмарков, написанных на Java и других языках с целевой платформой JVM. Сравнительно молодой фреймворк, в котором разработчики постарались учесть все нюансы JVM. Один из удобнейших инструментов, из тех, которые приятно иметь под рукой. JMH поддерживает следующие типы замеров: Throughput (замер чистой производительности), AverageTime (замер среднего времени выполнения), SampleTime (перцентиль времени исполнения), SingleShotTime (время вызова одного метода — актуально для замера «холодного» запуска тестируемого кода).

Поскольку речь идёт о Java, фреймворк учитывает в т.ч. и работу механизма кэширования JVM, и перед запуском бенчмарка несколько раз выполняет тестируемый код для «прогрева» кэша байт-кода Java-машины.

BenchmarkDotNet

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

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

Google Lighthouse

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

В веб-фронтенде в отношении замеров производительности сейчас всё идёт в сторону использования Performance API и измерении именно тех параметров, которые имеют значение для конкретного проекта. Хорошим подспорьем окажется веб-сервис webpagetest.org с Performance API метками и замерами — он позволит увидеть картину не со своего компьютера, а с одной из многих точек тестирования, существующих в мире, и оценить влияние времени приёма-передачи данных через каналы интернет на работу фронтенда.

Этот продукт больше подходил бы для проверки страниц сайта на соответствие рекомендациям Google (и вообще best practices) как для веб-сайтов, так и для Progressive Web Apps, если бы не одна из его функций: среди проверок есть и тест на поведение сайта при плохом качестве веб-соединения, а также при полном отсутствии связи. Это не очень соотносится с перформанс-тестированием как таковым, однако, если задуматься, в некоторых случаях веб-приложение воспринимается «медленным» не потому, что медленно готовит данные, а потому, что условия его работы на машине пользователя, в его браузере, с учётом его соединения с интернетом — увы, не идеальны. Google Lighthouse как раз и позволяет оценить это влияние.

---

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

• Инструменты тестировщика
• Тестирование браузерной производительности web приложений (включая javascript, rendering, вот это всё)
• Flaky tests (доклад о нестабильных автотестах)
• TestContainers — интеграционное тестирование без мороки

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

Original source: habrahabr.ru (comments, light).

Привет, Хабр! На данный момент в Data Science образовался огромный перекос в сторону data scientist-ов, об этой профессии сейчас знают даже те, кто никак не связан с IT, а новые вакансии появляются ежедневно. В свою очередь data engineer-ы не получают того внимания, которое бы соответствовало их важности для компании, поэтому в сегодняшнем посте мы бы хотели исправить эту несправедливость и объяснить, почему разработчикам и администраторам стоит немедленно начинать изучать Kafka и Spark и строить свой первый пайплайн.

В скором времени ни одна компания не сможет обойтись без Data Engineer

Давайте рассмотрим типичный рабочий день data scientist-а:

Получается, что около 80% своего времени data scientist тратит на сбор данных, их предобработку и очистку — процессы, которые напрямую не связаны с главной его обязанностью: поиском инсайтов и паттернов в данных. Конечно, подготовка данных требует высшего уровня мастерства, но это не data science, это не то, зачем тысячи людей сегодня стремятся попасть в эту отрасль.

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

Также не стоит забывать и о принципе garbage in — garbage out: если моделям на вход подаются некачественные данные, то бессмысленно ждать от них адекватного результата. Следовательно, для того, чтобы максимизировать эффективность data science отдела компании необходимо нанимать инженеров данных, которые, в отличии от data scientist-ов, специализируются на организации процесса сбора, очистки и предобработки данных.

Вот что по этому поводу думает Big Data Engineer в Mail.ru Group, Антон Пилипенко: «На текущий момент большинство компаний научились хранить большое количество данных и строить на их основе разного рода модели. Однако, зачастую, вопросам эффективного хранения и обработки накопленных данных не уделяют достаточного внимания. Как следствие постоянно то тут, то там возникают вопросы о сайзинге, масштабировании приложений, потоковой и near-realtime обработке. Как показывает опыт, деление на Data Science и Data Engineer специалистов появилось не на пустом месте. Data Engineer — в первую очередь инженер, который хорошо понимает, что и зачем он делает, как оно устроено „под капотом“ и какая архитектура „не взлетит“.

Data Engineer-у легче обратить на себя внимание работодателя

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

Теперь с этой же точки зрения взглянем на data engineer-ов, у которых ситуация обратная: с первого взгляда обязанности data engineer-а выглядят менее интересными, чем у data scientist-а (что естественно не так), поэтому сотни резюме не летят на почту работодателям, находящимся в поисках хорошего инженера данных, хотя зарплаты data engineer-ов и data scientist-ов находятся на примерно одном уровне (90 и 91 тыс. долларов в год соответственно в США). Людям нужно видеть результат своей работы, а лучше всего — удовлетворенность клиента и бизнеса. Легче всего получить удовольствие от своей работы, узнав о сотнях новых клиентов за счет построения модели по созданию персонализированных предложений, чем от очищенных данных, поэтому большинству трудно оценить значимость data engineer-ов, которые не меньше data scientist-ов вносят вклад в итоговый результат.

Data Engineer-ы практически незаменимы в компании

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

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

С этой точки зрения согласны и профессионалы: Senior Software Engineer в Agoda, Артем Москвин говорит: „Data engineer – это тот, кто делает всю ту бигдату, про которую вы слышали, возможной. Работу с данными можно условно разделить на 2 части: инжиниринг и исследования. Однако для того, чтобы сделать возможной вторую, нужно хорошо поработать над первой“, а по мнению Data Engineer-а в E-Contenta, Андрея Сутугина: „В мире анализа данных не все так радужно и красиво, как может показаться после решения “титаника» на kaggle. Для того, чтобы приступить непосредственно к самому анализу, необходимо проделать титаническую работу, но для того, чтобы «поставить на поток» сбор и трансформацию данных, требуется еще больше усилий. К сожалению, в мире «big data» нет «серебряных пуль», и обилие инструментов и фреймворков может вскружить голову”.

Data Engineering не требует глубокого знания статистики и теории вероятностей

Многие люди, которые хотят построить карьеру в IT, после 1-2 курсов технических университетов с зубодробительными курсами математического анализа и теории вероятностей опускают руки, считая, что без продвинутого математического бэкграунда они не смогут найти работу, даже несмотря на то, что пишут неплохой код. В связи с этим data engineering — это отличная возможность начать карьеру в сфере работы с данными для людей, которые имеют лишь базовое представление о машинном обучении, но при этом интересуются разработкой баз данных и их управлением. Таким образом, такая работа, конечно, больше подойдет software engineer-ам, архитекторам и администраторам баз данных.

По мнению Николая Маркова, Senior Data Science Engineer-а в Aligned Research Group LLC: «Зачем заниматься Data Engineering-ом? Я считаю, что это логичный путь в сферу анализа данных для людей, которые умеют программировать и имеют опыт работы в индустрии разработки. Дело в том, что люди крайне редко бывают глубоко заинтересованы и в том, и в другом — одновременно серьезное знание математики и глубокий computer science в одном человеке не встречается практически никогда. Поэтому давайте оставим математикам то, что они делают лучше всего — исследования, модели и графики, а сами подумаем, что нужно сделать для того, чтобы из аналитической идеи получился готовый работающий продукт?».

Newprolab 13 ноября запускает программу Data Engineer, на которой участники в течение 6-ти недель будут создавать стабильные пайплайны обработки данных от сбора до их визуализации, изучать и оттачивать навыки работы со следующими инструментами: Divolte, Kafka, ELK, Spark, Luigi, Sqoop, Druid, ClickHouse, Superset, Storm, которые будут объединять в один большой и стабильный пайплайн. Подробнее о программе Data Engineer.

Original source: habrahabr.ru (comments, light).

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


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

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

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

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

• А вдруг они перестанут работать?
• А вдруг мне что-то резко понадобится от сотрудника и я не смогу найти его на месте?

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


Посмотрим, какие бонусы получают сотрудники от удаленной работы:

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

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

Моими доводами в этом стали:

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

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

Я решил двигаться маленькими шажками: удаленный день для некоторых сотрудников -> удаленный день для всех сотрудников -> 2 удаленных дня для всех сотрудников -> ???
Основная идея: доказать, что удаленная работа не вредит бизнесу, а только помогает ему.

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

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

А как вы работаете в больших компаниях? Есть ли у вас удаленные дни и возможность поработать из дома?

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

Напоследок, приведу всем сомневающимся отличную книгу про плюсы удаленной работы «Remote: офис не обязателен» Джейсон Фрайд, Дэвид Хенссон.

Original source: habrahabr.ru (comments, light).

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

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

Теперь же платформа дала начало сразу двум пилотным проектам — чат-боту на сайте и в мобильном приложении и более интеллектуальной системе анализа обратной связи от клиентов. Обо всем по порядку — под катом.




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

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

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

На текущий момент значимых для компании проектов четыре. Далее — подробнее о каждом из них.

Сбербанк Попутчик

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

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

В качестве движка сообщества была разработана платформа чат-бота.

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

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

Платежный бот

Еще один ранний проект, задействовавший разработанную платформу чат-бота, — платежный бот. Он был запущен в пилотную эксплуатацию в начале этого года (т.е. появился на свет примерно на полгода раньше, чем аналогичное решение, представленное весной Google на конференции Google I/O 2017).

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

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

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

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

Чат-бот контактного центра

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

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

Бот построен на технологии латентно-семантического анализа, обеспечивающей поиск ответа на вопрос клиента с учетом контекста. Методика позволяет по ключевым словам и контексту диалога найти в базе готовых ответов, куда входят разнообразные FAQ по продуктам, наиболее релевантный ответ.

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

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

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

Система обработки клиентских обращений

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

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



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

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



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

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

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

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

Материал подготовили сотрудники ЦК развития биллинговых технологий СберТеха:
nill2, Данил Кабанов, директор ЦК
aspera, Руслан Халимов, ведущий инженер
Станислав Ким, руководитель разработки

Original source: habrahabr.ru (comments, light).

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



Везде есть свой «срок годности». Классическая интернет-реклама не исключение. CTR (кликабельность) первого баннера в сети был — 44%, а СTR сегодня измеряется только десятыми долями процента.

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

• 1900 баннеров видит в месяц средний интернет-пользователь;
• 90% пользователей не могут вспомнить последнее отображаемое объявление.


Источник: infolinks.com

Баннерная слепота представляет угрозу и мобайлу. Плюс, у мобильной рекламы еще меньше времени на контакт с пользователем, чем в декстопе. По статистике Kissmetrics на 2016 год — более 40% мобильных пользователей покидают сайт, если он не загрузился за 3 секунды.

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

9 Советов, которые помогут победить баннерную слепоту

1. Нестандартное размещение

Люди перестают обращать внимание на рутинные моменты. Разместите рекламу в непривычном месте, например, между постами в блоге или в самой статье (как, например, в блоге mobio.ru/blog).



Учитывайте, что 80% времени пребывания на веб-странице человек просматривает её верхнюю часть, и только 20% времени тратит на нижнюю. В мобайле пользователь концентрируется на центральной части экрана.

2. Новые Форматы

Пробуйте новые форматы. Например, welcome-page.

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

Хороший пример Forbes. Сайт «держит» юзера 3 секунды перед переходом на сайт. Хотите или нет, но Сэр Ричард вас настигнет :-).

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

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

4. Интерактивные элементы

Используйте в вашей рекламе интерактив: формы, вопросы, тесты, кликабельные элементы, анимация, голосования…открытый космос ваших идей. Интерактив повышает вовлеченность аудитории. Следовательно, повышает коэффициента конверсии лендинга. Такие понятия, как co-creation, user-generated content — все еще на пике популярности.

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

5. Видеоконтент

Видео — неоспоримый тренд в маркетинге и эффективный способ выделиться из потока статики в ленте. У видеоконтента наивысший показатель ROI. В 2017 году 69% всего интернет-трафика связано с видео.

6. Кнопка «Сall To Action»

Доказано, что наличие CTA-кнопки и ее креативного оформления по отношению к остальному материалу, — повышает вовлеченность пользователя.

Хороший пример: CTA-кнопка от ManageWP. Заголовок и краткое описание на контрастном фоне. Все ясно и понятно, лаконично и со вкусом.



Еще один отличный пример интерактивной кнопки «Prepare for Launch» от MailChimp. Так и хочется на нее кликнуть ;)

7. Персонализация

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

8. Ретаргетинг

Один из самых эффективных приёмов по увеличению СTR. Более подробно о технологии ретаргетинга можно почитать на сайте Getloyal: http://getloyal.ru/guide.

9. Аналитика и оптимизация

Анализируйте конкурентов. Находитесь в постоянном поиске новых идей.

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

Вывод

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

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

Автор статьи: Анастасия Щур, дизайнер Mobio

Original source: habrahabr.ru (comments, light).

Продолжаю свой рассказ о самом интересном на конференции VMworld 2017 Europe (первая часть рассказа о конференции).

Первый день начался с генеральной сессии под воодушевляющим заголовком: Good Technologists Solve Problems. Great Innovators Create Opportunities. Генеральный директор VMware Пэт Гелсингер (Pat Gelsinger) рассказал о том, как технологии меняют окружающий нас мир. Он привел в пример то, как быстро люди могут адаптироваться ко всему новому. Например, первоначальный страх перед беспилотными автомобилями сменяется интересом: «А как же это внутри работает?», что приводит к возникновению новых потребностей: «Почему эта штука не может ехать быстрее?». В результате именно ИТ становится основным источником роста для компаний. И если 100 лет назад человек должен был уметь делать три вещи: читать, писать и считать, то теперь это выглядит скорее, как «читать, писать код и считать».

VMware предоставляет решения, обеспечивающие работу любого приложения в любом облаке (частном или публичном) с возможностью доступа с любого устройства. Одним из таких решений является VMware HCX, обеспечивающий связь между on-premise инфраструктурой и публичными облачными сервисами (вроде IBM Cloud или OVH) и позволяющий в реальном времени переносить виртуальные машины туда и обратно без простоя (zero-downtime migration).

Однако далеко не все заказчики готовы с головой ринутся в публичное облако. Многие практикуют гибридный подход, когда часть инфраструктуры развернута on-premise, а часть — в облаке. Для улучшения возможностей по управлению такими гибридными средами VMware предлагает набор продуктов, распространяемых по модели SaaS — VMware Cloud Services, в число которых входят решения по мониторингу, анализу стоимости, организации сетевой связности, защите приложений и обеспечению единой точки подключения к приложениям.

Дальше речь зашла о публичном облаке VMware Cloud on AWS. Вкратце: Amazon предоставляет свои виртуальные ЦОД, расположенные во всех уголках мира, а также инженерную, сетевую инфраструктуру и серверное оборудование, на которое устанавливается набор продуктов VMware SDDC.

Также VMware напомнила о других недавно анонсированных продуктах, работающих внутри виртуальных сред: VMware Integrated OpenStack 4.0 (собственном дистрибутиве OpenStack) и VMware AppDefense (решении по организации защиты приложений).

Выставка

После завершения генеральной сессии посетители стали расходиться. Одни спешили на другие сессии, другие расслаблялись в lounge-зоне, третьи направились на выставку партнерских решений Solutions Exchange.



Ежегодно на VMworld более 100 компаний развёртывают стенды для демонстрации всевозможных продуктов и решений. Например, здесь можно побывать на стендах Dell, HPE, NetApp, IBM, Hitachi, Red Hat, Arista, Nutanix, а также перспективных стартапов. Особенно приятно, что на выставке представлены ИТ-компании, имеющие российские корни: Kaspersky и Veeam.

Вендоры всеми правдами и неправдами стараются зазвать посетителей на свои стенды:



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



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



Здесь были представлены все направления работы компании: от десктопных гипервизоров VMware Workstation до недавно анонсированного AppDefense



Отдельного упоминания заслуживают стилизованные под различные отрасли стенды, где демонстрировались решения для конечных пользователей (End-User Computing).



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



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



Cloud on AWS был анонсирован еще на прошлогоднем VMworld, и, наконец, решение стало доступным для конечных заказчиков.



В этом облаке любой заказчик может нажать пару кнопок и развернуть свой виртуальный ЦОД в облаке Amazon. Каждый такой ЦОД включает в себя:

• кластер VMware vSphere (не менее четырех физических серверов),
• сервер управления vCenter Server,
• распределенное хранилище VSAN,
• программно-конфигурируемую сеть NSX.

Каждый сервер имеет типовую конфигурацию: два процессора по 18 ядер в каждом, 512 Гб ОЗУ, 10,7 Тб дискового пространства на flash. При необходимости заказчик может наращивать вычислительные ресурсы виртуального ЦОД, добавляя дополнительные узлы вручную или в автоматическом режиме по мере роста нагрузки (так называемый Elastic DRS). Cloud on AWS предоставляет механизмы интеграции с on-premise инфраструктурой заказчика, позволяя управлять локальными и облачными кластерами vSphere и виртуальными машинами из единой консоли vSphere Client (Hybrid Linked Mode).

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

Поскольку облако VMware размещается в тех же ЦОД, что и облачные сервисы Amazon, заказчики получают дополнительные преимущества в виде широкой полосы пропускания, низких сетевых задержек и отсутствия учета трафика при работе с сервисами EC2, S3 и другими.

VMware выделяет три основных сценария использования Cloud on AWS:

1. расширение существующей виртуальной инфраструктуры или организация резервной площадки для обеспечения аварийного восстановления без необходимости построения собственного ЦОД;
2. консолидация нескольких существующих ЦОД или полная миграция в облако с минимальным влиянием на существующие приложения и ВМ;
3. быстрое предоставление вычислительных ресурсов для задач тестирования/разработки или при цикличной нагрузке (пики в сезон продаж).

На текущий момент развертывание виртуальных ЦОД доступно только в одном регионе (US West Oregon), однако уже в ближайшем будущем список регионов будет расширен.

На стенде HPE демонстрировалось новое поколение серверов ProLiant GEN10. В частности, был представлен 1U rackmount-серер HPE ProLiant DL360 GEN10.

Среди нововведений GEN10

• Поддержка процессоров архитектуры Intel Xeon Scalable. Новые процессоры имеют большее количество ядер (28 у старшей модели Intel Xeon Platinum 8150M вместо 22 ядер у Intel Xeon E5-2699A v4), большие тактовые частоты и кэш-память третьего уровня, а также возросший до 205 Вт тепловой пакет.
• Поддержка установки большего числа flash-накопителей с интерфейсом NVMe, которые обеспечивают более высокие скорости передачи данных и меньшие задержки по сравнению с накопителями с SATA/SAS интерфейсами. В 1U-сервер можно установить до 10 таких накопителей, выполненных в форм-факторе 2,5 дюйма. В более вместительный 2U-сервер — уже 20. Если учесть, что в портфолио HPE есть NVMe-накопители объемом до 2 ТБ, нетрудно подсчитать итоговую ёмкость.

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

Стоит отметить постепенный переход производителей серверов к сетевым адаптерам 25 Гбит/с и, соответственно, к портам 100 Гбит/с на сетевом оборудовании. Помимо двух с половиной кратного увеличения полосы пропускания и уменьшения задержек по сравнению с 10 GbE, что может быть полезно для современных гиперконвергентных решений и программно-определяемых СХД, такие адаптеры могут похвастаться наличием разъемов стандарта SFP28, которые по размерам совпадают с обычными SFP+ и занимают меньше места, чем QSFP+.



На стенде Intel демонстрировалась гиперконвергентная платформа на базе серверов, процессоров и flash-накопителей производства Intel и ПО VMware (vSphere и vSAN).



Невзрачные, на первый взгляд, серверы содержат по два процессора Intel Xeon Gol 6152, 768 ГБ ОЗУ, четыре накопителя Intel Optane DC P4800X объемом 375 ГБ на базе памяти 3D XPoint и 12 «классических» NVMe flash-накопителей Intel DC P4500.



Накопители выполнены в форм-факторе 2,5 дюйма, поддерживают горячую замену и подключаются напрямую к шине PCI-E через специальные host-адаптеры.



Один такой сервер способен обеспечивать производительность на уровне 380 тысяч IOPS при случайной нагрузке блоками 4 Кб и соотношении чтения/записи равном 70/30.



Следующей на очереди была зона HCI (HyperConverged Infrastructure) — гиперконвергентных решений, совмещающих вычислительные ресурсы и ресурсы хранения в рамках одного конструктивного блока. Помимо партнерских решений Intel, Lenovo и Fujitsu, на стенде демонстрировалась HCI-платформа Dell-EMC VxRail 4.0.



VxRail представляет собой законченное решение, построенное на базе серверов Dell и программного обеспечения VMware vSAN. На текущий момент в линейке VxRail присутствуют 5 типов конфигураций, предназначенных для решения разных задач: от высокоплотных серверов G-серии и типовых 1U-серверов E-серии (Entry level) до серверов серии V, поддерживающих установку графических ускорителей и оптимизированных для запуска виртуальных рабочих станций, высокопроизводительных (серия P) или емких (серия S) серверов.



VxRail, как и большинство других HCI-решений, поставляются заказчикам в уже готовом к работе виде. Достаточно на месте скоммутировать сервер, включить питание, пройти простой мастер первоначальной настройки — и «Voila!», полностью функционирующая виртуальная инфраструктура готова к работе.

Для популяризации HCI и других решений среди молодежи Dell EMC выпустила серию комиксов.





Прямо на выставке записывался подкаст Virtually Speaking Podcast (https://soundcloud.com/virtuallyspeakingpodcast) о виртуализации и облачных технологиях.



На стенде Mellanox демонстрировались всевозможные сетевые и конвергентные адаптеры серии ConnectX, поддерживающие 10, 25, 40, 100 Гбит/с и даже 200 Гбит/с подключения. Обратите внимание, как растут требования к шине PCI-E по мере увеличения количества и скорости портов.



Рядом с Mellanox расположился стенд Supermicro, на котором демонстрировались современные серверы Twin-формата (позволяющие размещать два или четыре сервера в одном шасси), поддерживающие процессоры Intel Xeon Scalable и AMD EPYC. Серверы Supermicro пользуются неизменной популярностью у экономных заказчиков, сборщиков оборудования и производителей апплайнсов, например, платформа Web Scale от Nutanix строится именно на таких серверах.



Серверы имеют заменяемый адаптер LOM (Lan-on-board), позволяющий подобрать необходимую конфигурацию сетевых портов без замены материнской платы и без использования PCI-E слота расширения.

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

Андрей Коновалов, начальник отдела виртуализации компании «Инфосистемы Джет»

Original source: habrahabr.ru (comments, light).

2 сентября 2017 прошла конференция Moscow Frontend, где я на примере React UI Kit рассказывала о проблемах, которые встречаются при внедрении UI Kit в компании. Тема оказалась актуальнее, чем я могла предположить, поэтому решила опубликовать статью по этой же тематике, преследуя две цели: донести материал до людей, которые не смогли оказаться на конференции лично, и предоставить отличную возможность провести жаркую дискуссию на эту тему в комментариях.

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

Что такое UI Kit?

Как показал опрос зала, не все присутствующие на профильной конференции по frontend знают, что такое UI Kit. Если говорить простым языком, UI Kit – это набор элементов пользовательского интерфейса в едином стиле. Еще проще: кнопки, поля для ввода текста, выпадающее меню и прочее в одном цвете.

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

Пройдемся по всему процессу внедрения шаг за шагом:

1. Определение необходимости Kit в компании
2. Анализ уже существующих решений
3. Разработка дизайна
4. Организация библиотеки компонентов
5. Создание компонентов
6. Использование

Определение необходимости Kit в компании

Если вы только что узнали, что такое UI Kit, у вас сразу возникнет первая проблема – как понять, нужен ли он нам? UI Kit точно не нужен, если:

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

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

Как объяснить бизнесу и компании, что вам нужен UI Kit

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

Приводите аргументы, которые будут понятны всем. Возможно, в вашей компании уже давно есть проблема с тем, что все продукты различаются визуально, и пора синхронизовать их дизайн. В качестве весомого аргумента можно предложить прочитать статью «And You Thought Buttons Were Easy?» , в которой рассказывается о материальной выгоде использования единой дизайн-системы. И объясните на пальцах, что страстно желаемые фичи будут создаваться и выкатываться намного быстрее, чем раньше.

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

Анализ существующих решений

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

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


Зеленым выделены характеристики, которые нам подходят. В результате определились три лидера: Material-UI, Ant-design и React-md. Дальше вы можете проводить уже свои сравнения по скорости работы, функциональности или весу компонентов. Но я могу вас заранее предупредить: нельзя предугадать будущие потребности продуктов, находясь на старте разработки. Поэтому, если у компании есть ресурсы и заинтересованность в гибких решениях, то лучше создавать свой Kit.

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

Разработка дизайна

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

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

Вот мой рекомендованный список к соглашению, который нужно обсудить:

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

В зависимости от ситуации список можно сокращать или дополнять.

Очень важным моментом, на который сейчас обращают внимание далеко не все, является понимание разработки дизайном. Например, далеко не все дизайнеры знают, что такое компонент, что разработчикам может казаться удивительным. Но это факт! Пример общего подхода и к дизайну и к разработке – Tinkoff.ru, где в дизайне и в разработке используется методология atomic design, которая легка в понимании и хорошо соотносится с дизайном и разработкой UI Kit.


Все методологии, о которых я пишу, всего лишь вектор, в котором стоит начать думать или работать, но никак не ультимативное руководство к действию. Так поступили в Tinkoff.ru с atomic design: в методологии появляется новая сущность под названием «продукт».

Организация библиотеки компонентов

Шаг, который стоит под четвертым номером, но к которому стоит обратиться в разработке одновременно с третьим (разумеется, после «стола переговоров» с дизайном).

Перед вами так или иначе будет стоять выбор: создавать UI Kit как единую библиотеку или каждый компонент как отдельный npm-пакет. И, что бы вы ни выбрали, вас все равно ожидает ряд проблем.

Проблемы единой библиотеки:

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

Проблемы компонентов как отдельных пакетов:

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

Я указала не все проблемы и не все возможные решения, поскольку каждая компания уникальна. Но многие из них можно решить версионированием или договоренностью о возможности делать Pull request-ы всем командам, как в OpenSource. Если вы выбрали подход, при котором каждый компонент это отдельный пакет, то я могу предложить отличный инструмент для работы с разными пакетами в одном монорепозитории – Lerna. Если вы с ним еще не знакомы, обязательно сходите по ссылке и изучите все возможности. Возможно, это инструмент может оказаться вам полезным не только в контексте создания UI Kit.

Проблема, которая вам, как разработчику, не понравится больше всего, – построение процесса работы с Kit-ом. Кто будет создавать и контролировать Kit? Будет ли это отдельная команда или мейнтейнеры из разных продуктовых команд? Здесь, как и в ситуации с организацией библиотеки, вне зависимости от выбора у вас будет ряд проблем.

Если создавать и контролировать будет единая команда Kit-a, то:

• создание кита происходит в отрыве от реальных продуктов;
• большой список продуктовых задач, который упирается в одну команду;
• постоянные вопросы: «Создается ли компонент, нужный только одной команде?», «Что происходит при конфликте требований разных продуктов?» и т.п.

Если мейнтейнеры из разных команд, то:

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

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

Создание компонентов

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

Вот мои небольшие рекомендации к обсуждению соглашение:

• покрыть весь функционал;
• максимально глупые компоненты;
• Pure Component;
• масштабируемые компоненты;
• переиспользуемые компоненты;
• тесты;
• кастомизация;
• версионирование;
• технологии/подходы.

Рекомендую также ознакомиться с книгой «Design of everyday things». В ней рассказывается о дизайне вещей, с которым мы сталкиваемся каждый день, и почему нам сразу понятно, как ими пользоваться. Например, двери, стулья или чайники. Эта книга в действительности изменила мое мышление о вещах, которые меня окружают и которые я создаю. А создаем мы все (разработчики) программы, компоненты и их интерфейсы. Так вот, интерфейсы наших компонентов должны быть понятны нам в использовании так же, как чайник, с которым мы точно знаем, что делать.

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

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

Некоторые из проблем можно решить, собрав все компоненты в единой витрине, включая и компоненты из разных библиотек. Очень простая в использовании витрина, которую используют и в Tinkoff.ru – Storyboook.

Вывод

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

Вы сделаете отличный вклад, если поделитесь со мной ответами на некоторые вопросы в комментариях:

1. Есть ли у вас в компании Kit?
2. Какие из проблем встречались вам?
3. Какие из указанных решений вы использовали и какую получили при этом пользу?

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

Original source: habrahabr.ru (comments, light).

Источник

Друзья, всех с прошедшим вчера Днем программиста! Жизни без багов и красивейшего кода!)

Мы продолжаем разбор облачных сервисов Техносерв Cloud и сегодня детально разложим, из чего состоит наша облачная база данных. Если заглянуть в результаты исследования, проведенного IDG Connect по заказу Oracle, увидим, что DBaaS скоро будет самым востребованным сервисом частного облака. Растет и число публичных сервисов DBaaS.

Снижение затрат за счет консолидации ресурсов, масштабирование по мере необходимости, контроль расходов, доступ к данным из любого места – всё это факторы, влияющие на выбор в пользу облачной базы данных. На рынке облачных услуг свои базы данных предлагают его ведущие игроки – Amazon Web Services, IBM, Microsoft и Oracle. Но есть одна проблема — все они разворачивают БД за пределами России, более того, далеко не все из них предлагают сервис – администрирование, управление производительностью, круглосуточную техническую поддержку (желательно на русском языке), – а только платформу.

Чтобы ответить на этот запрос рынка, мы запустили свой сервис и стали единственным российским облачный провайдером, работающим с четырьмя основными базами данных под ФЗ-152 и ФЗ-242.

Рынок DBaaS

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

По прогнозу Technavio, в ближайшие годы мировой рынок DBaaS будет демонстрировать экспоненциальный рост — более чем на 65% ежегодно. Вместо того, чтобы вкладывать большие средства в аппаратные платформы, многие компании склонны инвестировать средства в услуги с еженедельной, ежеквартальной или ежегодной оплатой по подписке.

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

Судя по результатам опросов, реляционные облачные СУБД – в числе самых популярных сервисов публичных облаков. Их используют 35% респондентов, экспериментируют -14%, планируют внедрение – 12% (источник – RightScale).

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

По данным Forrester, AWS – лидер рынка DBaaS. Amazon Relational Database Service позволяет работать с БД Oracle, Microsoft SQL Server, MySQL, MariaDB и PostgreSQL в среде EC2. Из 100 тыс. исследованных 2ndWatch экземпляров БД 67% представляли Amazon RDS.

Рост оборота мирового рынка DBaaS в млн. долларов (по данным 451 Research).

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

Рост сервиса Oracle DBaaS в мире.

Аналитики Markets&Markets прогнозируют, что рынок облачных СУБД/DBaaS вырастет с 1,07 млрд. долларов в 2014 году до 14,05 млрд. долларов к 2019 году при ежегодных темпах роста (CAGR) в 46%.

Что лучше, сервис или своя СУБД?

Облачная база данных или DBaaS (Database as a Service) – это любая СУБД, предоставляемая по подписке как облачный сервис в рамках платформенной модели обслуживания. То есть DBaaS – один из сервисов PaaS. В случае PaaS, «платформы как сервис», заказчик получает уже установленное и настроенное программное обеспечение для разработки и тестирования или развертывания приложений. Для заказчика создается БД нужной конфигурации в одном из следующих вариантов:

• БД без виртуализации (на физической машине)
• БД на виртуальной машине
• БД в виде контейнера в многоарендной базе данных

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

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

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

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

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

Как показывает практика, многие заказчики DBaaS отмечают:

• Снижение общих расходов.
• Большую независимость бизнес-пользователей от ИТ-подразделений.
• Снижение рисков в сценариях ИТ-планирования.
• Большую предсказуемость и гибкость.
• Разработчики приложений достаточную степень свободы для творчества и инноваций.
• DBaaS улучшает работу администраторов БД. Они больше концентрируются на задачах бизнеса и меньше — на рутинных операциях.

Отличия DBaaS от традиционного подхода (источник – Oracle).

Основные преимущества облачной БД

1. Начнем с того, что не каждая компания может выделить отдельного сотрудника для мониторинга и управления своей СУБД. Результат — высокие риски остановки бизнес-процессов, прерывание производственных процессов, потеря данных и прочие неприятности. С сервисом «Облачная база данных» все эти заботы мы берем на себя. Преимущества DBaaS:
   • высокая масштабируемость,
   • снижение затрат,
   • быстрое предоставление услуг,
   • повышение надежности и безопасности.

   
   
2. Это не только надежнее и безопаснее, но и выгоднее. Как уже отмечалось, компания может существенно сэкономить на зарплатах DBA. Действительно квалифицированных специалистов на рынке очень мало, и часто те, что есть, перегружены текущими задачами. В облаке нет необходимости заботиться о настройках сервера БД, и цена поддержки обычно оказывается значительно меньше. К тому же собственные специалисты по БД не всегда способны обеспечить необходимый уровень сервиса, а облачные решения гарантируют высокий уровень доступности – мы круглосуточно осуществляем мониторинг на уровне платформы и на уровне СУБД.
3. На самом деле многие компании вообще не имеют специалистов по БД в штате. Одно дело запустить SQL Server или MySQL на сервере и обеспечить работу приложения, другое — исправить ошибки в БД и оптимизировать ее функционирование. В случае возникновения реальных проблем придется срочно искать внешнего специалиста. В облаке «узкие места» БД становятся головной болью провайдера. К тому же он вполне может нанять специалистов по БД и поддерживать высокий уровень их квалификации. А к вашим услугам — первая линия поддержки. Это к вопросу выбора места размещения БД – «у себя» или в облаке.
4. Еще одно преимущество сервиса – быстро развертываемые готовые типовые конфигурации, оптимизированные по производительности под типовые задачи использования баз данных. Создание индивидуальной конфигурации и конфигураций с кластеризацией может занимать до трех рабочих дней.
5. Сервис «Облачная база данных» использует резервируемые виртуальные ресурсы, предусматривает отчеты по доступности, базовое администрирование БД и ОС, резервное копирование БД и восстановление из резервной копии, управление емкостью хранения. Дополнительные услуги — мониторинг производительности БД, мониторинг бизнес процессов, расширенное администрирование и резервирование с индивидуальным расписанием резервного копирования и глубины хранения. Профессиональные услуги включают также аудит, консультации, миграцию, в том числе конвертацию и перенос данных (с предоставлением СХД). И конечно, мы обеспечиваем отказоустойчивость и повышенную доступность баз данных. Ведь база данных является одним из наиболее критичных сервисов для предприятия.

Четыре в одном

Переходим к описанию нашего сервиса «Облачная база данных». Как мы уже сказали, эта услуга может работать с четырьмя основными базами данных: мы предоставляем готовые к работе базы данных Microsoft SQL (лицензии MS по модели SPLA), PostgreSQL и MySQL, а также хостинг Oracle.

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

Клиентам доступны следующие версии и редакции СУБД:

Особенности услуги «Облачная база данных»

• Высокая производительность.
• Оптимизированные в соответствии с рекомендациями разработчиков и лучшими практиками конфигурации ОС и СУБД.
• Профессиональная техническая поддержка, в которой работают специалисты интегратора по базам данных.
• Услуга создавалась с учетом ФЗ-149, ФЗ-152 и ФЗ-242.
• Ценовое предложение в среднем на 35-40% выгоднее западных облачных платформ (с учетом затрат на работы по администрированию баз данных и операционных систем которые по умолчанию включены в состав услуги).

Согласно законодательству РФ, основными документами, определяющими требования к защите информации, являются:

• Закон ФЗ-149 «Об информации, информационных технологиях и о защите информации».
• Закон ФЗ-152 «О персональных данных».
• Приказы ФСТЭК России №17 и №21.
• Закон ФЗ-242, который уточняет ФЗ-152 и обязывает операторов персональных данных обрабатывать и хранить персональные данные россиян с использованием баз данных, размещенных на территории РФ.

По умолчанию наш сервис предоставляется клиентам в соответствии с 3-й и 4-й категориями защищенности ПДн (о безопасности данных), а по запросу – в аттестованном сегменте* платформы, согласно всем требованиям защиты информации, установленным ФСТЭК России.

*Аттестат соответствия требованиям по безопасности информации

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

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

Санкции также подталкивают наших потенциальных заказчиков на поиск альтернативных решений на российском рынке. На фоне высокого курса валют и сложной политической ситуации они ищут возможные пути минимизации рисков, и «Облачная база данных», как российский сервис, предлагаемый на территории России по рублевым ценам, заслуживает пристального внимания. Облачные сервисы могут выступить в качестве альтернативы покупке ИТ-оборудования западных вендоров, а открытое ПО, на основе которого сервис функционирует, отвечает курсу на импортозамещение. Open Source платформы, такие как OpenStack, — одна из ключевых альтернатив проприетарным решениям.

Наш сервис включает все опции, обеспечивающие доступность базы данных:

• динамически расширяемые вычислительные ресурсы;
• администрирование ОС и СУБД силами провайдера;
• мониторинг СУБД;
• резервное копирование данных.

И предлагает следующие варианты подключения к БД:

• сети общего пользования (публичный интернет).
• защищенное VPN-подключение поверх интернета (IPSec VPN).
• защищенный L2 VPN-канал связи.
• сеть IP VPN.
• через внутреннюю сеть, при условии размещения серверов приложений в облачной платформе Техносерв Cloud (скорость 10 Гбит/с).

Администрирование БД включает в себя выполнение следующих операций:

• решение инцидентов в работе БД;
• установка и настройка клиента и ПО БД;
• управление доступом к БД;
• резервное копирование БД;
• обновление ПО БД;
• мониторинг доступности БД;
• мониторинг состояния БД и резервных копий, периодическое тестирование резервных копий (1 раз в месяц);
• управление пространством;
• анализ журналов и файлов трассировки;
• восстановление БД из резервных копий в случае сбоя*.

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

Администрирование операционных систем включает в себя выполнение следующих операций:

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

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

• среда виртуализации OpenStack/KVM;
• обмен данными между ВМ — до 10 Гбит\с;
• система управления OpenStack (основана на релизе Mitaka);
• использование модуля виртуализации сети Neutron позволяет реализовывать функции NAT, VPNaaS, FWaaS, LBaaS, маршрутизации;
• программно-определяемое хранилище (SDS) — тройное резервирование обеспечивает не только сохранность данных при выходе из строя любого диска, узла или группы узлов, но и автоматизированное восстановление копий на других узлах.

Ресурсы у сегмента OpenStack (с учетом резервирования):

• vCPU – 1000 ядер.
• vRam – 1400 Гбайт.
• vHDD – 24000 Гбайт.

Какие задачи решаем?

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

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

Для разных приложений у нас типовые конфигурации:

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

Одиночная база данных: резервное копирование и восстановление

Это базовый вариант сервиса для БД Oracle, MS SQL Server (2012/2014/2016 Standard Edition), MySQL и PostgreSQL, при котором заказчику предоставляется система с необходимыми характеристиками. Экземпляр базы данных располагается на виртуальной машине.
Системой резервного копирования Commvault резервируются файлы базы данных и журналы транзакций. Они хранятся семь дней. В течение этого периода можно восстановить БД по состоянию на момент последнего резервирования журнальных файлов (с интервалом в час).

По умолчанию резервное копирование выполняется по следующему сценарию:

• Один раз в неделю — полное резервирование.
• Каждый день сохраняется дифференциальная резервная копия.
• Каждый час сохраняется журнал транзакций.

Целевой срок восстановления (RTO) – до нескольких часов (в зависимости от объёма базы данных), целевая точка восстановления (RPO) – до 1 часа. Время восстановления сервиса в случае потери базы данных зависит от объема БД и интенсивности ее использования. В случае аппаратного сбоя система автоматически заменяется в течение нескольких минут.

Архитектура: Одиночная база данных

Одиночная база данных — время восстановления и потенциальная потеря данных:

БД повышенной защищенности

Конфигурация зависит от типа БД:

SQL Server 2012/2014/2016 Standard Edition

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

1. Повышает доступность базы данных. В режиме высокой безопасности с автоматическим переходом на другой ресурс и возникновении сбоя резервная копия базы данных переводится в режим «в сети» (без потери данных). В других режимах работы администратор базы данных может включить принудительное обслуживание (с возможной потерей данных) на резервной копии базы данных.
2. Повышает защиту данных. Зеркалирование базы данных обеспечивает полную избыточность данных (используется режим высокой безопасности). Кроме того, участник зеркального отображения предпринимает попытки автоматически разрешить ошибки некоторых типов, которые могут мешать чтению страницы данных. Участник, который не может прочитать страницу, запрашивает новую копию у другого участника. Если этот запрос завершился успешно, то нечитаемая страница заменяется копией, в результате чего ошибка обычно устраняется.
3. Повышает доступность рабочей базы данных при обновлениях. Чтобы свести к минимуму время простоя базы данных, участвующей в зеркалировании, можно последовательно обновить экземпляры SQL Server, на которых размещены партнеры по отработке отказа. Это вызовет простой только на время одной отработки отказа.
   В случае выхода из строя основной базы данных происходит переключение на резервную, при этом время простоя обычно составляет меньше минуты.
   Для автоматического перехода на другой ресурс (процесс, согласно которому при недоступности основного сервера зеркальный сервер берет на себя роль основного и выводит свою копию базы данных в сеть как основную базу данных); также используется дополнительный “служебный” экземпляр SQL Server — “Свидетель”, который может одновременно использоваться несколькими системами. Применяется “Режим высокой безопасности”, при котором сеанс зеркалирования базы данных работает синхронно, и в нем используются следящий сервер, а также основной сервер и зеркальный сервер. Следящий сервер “Свидетель” не обслуживает базы данных, его единственная функция заключается в поддержке автоматического перехода на резервную систему.
   В качестве последней линии защиты данных используется резервное копирование средствами Commvault. В случае аппаратного сбоя наша система автоматически обеспечит замену в течение нескольких минут.

PostgreSQL и MySQL

База данных повышенной защищённости: предоставляется две системы с необходимыми характеристиками. На одной из виртуальных машин располагается основной экземпляр, на второй — резервный. В случае выхода из строя основной базы данных происходит переключение на резервную. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой Commvault.

Архитектура: База данных повышенной защищенности

Доступность сервиса — 99,95%. RTO – от нескольких минут до 1 часа, RPO – близко или равна нулю.

БД высокой доступности и защищенности

SQL Server 2012/2014/2016 Enterprise Edition

Используются группы высокой доступности (Always On Availability Groups), которые предоставляют широкий набор параметров, позволяющих повысить уровень доступности баз данных и улучшить использование ресурсов, а также обладают следующими преимуществами:

• Поддержка до девяти реплик доступности (по умолчанию — 2 реплики). Реплика является выделенным экземпляром группы доступности, который размещается на отдельном экземпляре SQL Server и поддерживает локальную копию каждой базы данных доступности, которая принадлежит группе доступности. Каждая группа доступности поддерживает одну первичную реплику и до восьми вторичных реплик.
• Поддержка альтернативных режимов доступности: 1) асинхронная фиксация (решение аварийного восстановления, которое хорошо работает, когда реплики доступности распределены и удалены дркг от друга); 2) синхронная фиксация (отдается предпочтение высокому уровню доступности и защите данных перед производительностью за счет повышения задержки транзакций). Отдельно взятая группа доступности может поддерживать до трех реплик доступности с синхронной фиксацией, в том числе текущую первичную реплику.
• Поддержка различных форм отработки отказа другой группы доступности: 1) автоматический переход на другой ресурс; 2) запланированный переход на другой ресурс вручную; 3) принудительный переход на другой ресурс вручную.
• Возможность настройки реплик доступности для поддержки одной или обеих возможностей активных вторичных реплик: 1) доступ с подключением только для чтения, который позволяет использовать подключения только для чтения для чтения баз данных во время работы в качестве вторичной реплики; 2) выполнение операций резервного копирования для своих баз данных во время работы в качестве вторичной реплики.
• Поддержка прослушивателя (Listener) для каждой группы доступности. Listener — это сервер, к которому могут подключаться клиенты, чтобы получить доступ к базе данных из первичной или вторичной реплики группы доступности AlwaysOn. Прослушиватели группы доступности направляют входящие соединения на первичную реплику или на доступную только для чтения вторичную реплику. Listener обеспечивает быструю отработку отказа приложений после отработки отказа группы доступности.
• Поддержка гибкой политики отработки отказа для обеспечения большего контроля над отработкой отказа группы доступности.
• Поддержка автоматического восстановления страниц для защиты от повреждения.
• Поддержка шифрования и сжатия, что обеспечивает безопасный, высокопроизводительный транспорт.

В случае выхода из строя основной базы данных происходит переключение на резервную базу данных, при этом время простоя обычно составляет меньше минуты.
Каждая реплика группы доступности размещается на отдельном узле отказоустойчивого кластера Windows Server (WSFC). Развертывание WSFC требует, чтобы серверы, участвующие в WSFC (также называются узлами), были присоединены к одному и тому же домену.
В качестве последней линии защиты данных используется резервное копирование, которое выполняется системой Commvault.

Архитектура: База данных высокой доступности и защищенности (1)

БД высокой доступности и защищенности. RTO – от нескольких секунд до 1 часа, RPO – близка или равна нулю.

(1) — Данная опция в разработке. Плановый срок ноябрь 2017г.

Как это работает?

«Облачная база данных» (TS-Cloud.DBaaS) включает в себя:

• Подсистему оркестрации, обеспечивающую управление сервисом и инфраструктурой. Она взаимодействует с порталом самообслуживания и использует ресурсы облака TS-Cloud для размещения ВМ.
• Портал самообслуживания.
• Подсистему резервного копирования на базе сервиса TS-Cloud.BaaS CommVault Simpana.
• Облачную платформу TS-Cloud (OpenStack).
• Подсистему мониторинга на базе Zabbix.
• Cистему доменных имен (DNS)

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

Схема TS-Cloud.DBaaS.

После запроса услуги клиентом портал запускает шаблон стека, соответствующий выбранной клиентом СУБД, и передает в Heat необходимые параметры сервиса (имя узла, размер дисков для размещения БД и транзакционных логов и т.д.). Heat запрашивает ресурсы для сервиса у компонентов платформы виртуализации, создает ВМ из образа, подключает к ней необходимые дополнительные диски и сети, запускает ВМ. Далее ВМ инициализируется при помощи Cloud-init. Метаданные ВМ сервиса (внутренний и внешний сетевые адреса, id стека и т.д.) передаются в портал. Портал самообслуживания взаимодействует с Heat через программный интерфейс Heat-API.

Подсистема оркестрации Ansible и обеспечивает настройку и управление сервиса DBaaS и инфраструктуры, необходимой для работы сервиса. Она управляется порталом самообслуживания и использует ресурсы облака TS-Cloud для размещения ВМ.
Портал самообслуживания взаимодействует с подсистемой оркестрации на базе Ansible через REST API, реализованный при помощи открытого продукта Flansible. Данный интерфейс позволяет исполнять сценарии Ansible (скрипты), отслеживать статус и результат их исполнения.

После запуска ВМ и получения порталом самообслуживания сетевых реквизитов сервиса запускается Ansible-скрипт конфигурирования сервиса — портал через REST-API передает необходимые параметры (внешний и внутренний адрес ВМ сервиса, имя БД, кодировка, имя пользователя БД, пароли и т.д.) и запускает скрипт. В процессе работы скрипта портал отслеживает статус выполнения.

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

Портал взаимодействует с подсистемами автоматизации Heat и Ansible для создания экземпляров БД по запросу пользователя. В разделе «Каталог Услуг» пользователь может выбрать параметры конфигурацию и заказать одну или несколько услуг DBaaS.

После получения параметров заказа портал вызывает API Heat для выделения ресурсов OpenStack, получает от Heat IP-адреса созданных виртуальных машин и передает их по в Ansible для установки выбранной пользователем СУБД.

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

Миграция в облако

Часто возникает вопрос, как перенести БД в облако. Мы разработали сценарии миграции данных на облачную инфраструктуру с использованием технологий Microsoft Mirroring и Always On Availability Groups, Oracle Data Guard, Oracle Golden Gate, Oracle Dbvision. Миграция включает в себя:

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

Сколько это стоит?

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

Вариант 1. Функциональное тестирование на СУБД PostgreSQL для разработчиков конфигурации «1С: Зарплата и кадры», эксплуатируемой в сети автосервисов.

Вариант 2. Пример расчета стоимости сервиса БД MS SQL для ERP MS Axapta эксплуатируемой в сети магазинов детских игрушек.

Вариант 3. Пример расчета стоимости сервиса БД Oracle для системы поддержки туристического бизнеса используемой туристическим оператором и его агентствами.

У нас на сайте можно рассчитать стоимость услуги с помощью онлайн-калькулятора.

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

Original source: habrahabr.ru (comments, light).

Предлагаю всем близким к фронтенду посмотреть доклады с прошедшего в августе митапа Frontend MIX. Приглашенные спикеры из Альфа-Лаборатории, Яндекс.Денег и Epam делятся нюансами мобильной оптимизации и выбора между Npm v5, Yarn или pnpm, а также секретами построения дизайн-системы на БЭМ и React.

Под катом вы найдете три видео.

#1 Как ускорить загрузку сайтов в эпоху смартфонов

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

В докладе упоминаются современные способы передачи контента (HTTP/2: preload, server push), профилирование загрузки в Chrome Dev Tools и оптимизация JavaScript.

#2 Как в Альфа-Лаборатории сделали гибкую и расширяемую дизайн-систему с помощью БЭМ и React

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

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

#3 Увлекательный выбор между Npm v5, Yarn или pnpm

Закрывал митап разработчик Epam Майкл Башуров, который поделился своим мнением по поводу выбора менеджера пакетов. Обсуждались как сакральные вопросы вроде «нужен ли Yarn» и «когда вышел Npm v5», так и плюсы использования менее популярных продуктов вроде pnpm.

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

Напомню, что за всеми нашими мероприятиями вы можете следить на Я.Встречах – записывайтесь и приходите в гости!

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

Original source: habrahabr.ru (comments, light).

Переход от обычной сети ЦОД к SDN

Прорывные технологии меняют стратегии

Взрывной рост, который сегодня демонстрируют сети центров обработки данных (DCN) неуклонно превращает эти сети в ключевой элемент корпоративной информационно-вычислительной инфраструктуры, особенно при обслуживании критически важных сервисных систем и управлении ключевыми информационными ресурсами. По мере расширения корпоративной архитектуры DCN, в центрах обработки данных разворачиваются всевозможные виды новых приложений, благодаря, с одной стороны, прогрессу в технологиях коммуникационных сетей, а с другой стороны – растущей популярности интернета и мобильных приложений. Компании также начинают внедрять новые рабочие модели, которые используют облачные рабочие места, и новые методы бизнес-анализа, для которые требуются хранилища данных и использование глубокого анализа (data mining). Все эти прорывные изменения не только усиливают зависимость компаний от центров обработки данных, но также ускоряют появление стратегий реализации DCN с масштабируемыми обновлениями.
Чтобы сети ЦОД могли поспевать за экспоненциальным ростом данных из новых источников, требуются новые возможности серверов как для хранения, так и для обработки все более сложных сервисных взаимодействий. Однако архитектуры и технологии традиционных ЦОД уже не соответствуют вновь возникающим требованиям к высокой эффективности, интеллектуальности и удобству работы. Этот стратегический вызов привел к появлению технологии программно-определяемых сетей (SDN). Технология SDN обеспечивает возможности сетевой виртуализации, разделяет плоскости управления и переадресации, реализует логически централизованное управление и открывает возможности сети для приложений верхних уровней. SDN особенно подходит для реализации сетей ЦОД с мощной функциональностью, поддерживающей централизованное управление сетью, разветвленную переадресацию, развертывание виртуальных машин, интеллектуальную миграцию, многопользовательские виртуальные сети и принцип инфраструктура-как-услуга (IaaS). Можно сделать вывод о том, что технологический тренд в сторону облачных решений на базе SDN определяет будущее сетей ЦОД.
Среди доступных технологий SDN широкое признание получила методология использования SDN-контроллера и наложенной сети для обеспечения должного уровня переадресации и разделения управления. Эта техника предусматривает централизованную доставку политик через SDN-контроллер, возможность виртуализировать сетевые ресурсы и гибко их планировать. Виртуализация инфраструктурной сети основывается на технологиях оверлея, таких как «виртуальная расширяемая LAN» (VXLAN). Оверлей-протокол освобождает сервисы и ресурсы от ограничений, связанных с их физическим расположением и позволяет создать большую логическую сеть уровня 2 для совместного использования ресурсов в центрах обработки данных.
VXLAN расширяет L2-сети при помощи инкапсуляции MAC-in-UDP и использует преимущества L3-сетей для разветвленной балансировки нагрузки, быстрой конвергенции и высокой надежности, что обогащает возможности L2-сетей. Кроме того, VXLAN использует 24-битное поле идентификатора сети VXLAN (VNI) для идентификации L2-сетей, что позволяет поддерживать свыше 16 миллионов сетевых сегментов. Таким образом преодолевается накладываемое традиционными L2-сетями ограничение в 4096 VLAN. Узлы входа и выхода туннеля VXLAN называются конечными точками виртуального туннеля (VTEP), они инкапсулируют и декапсулируют пакеты VXLAN. Решение Huawei Cloud Fabric для сетей ЦОД поддерживает как аппаратные, так и программные VTEP для удовлетворения всевозможных требований заказчиков.
В процессе эволюции SDN, программно-определяемые и традиционные сети будут какое-то время сосуществовать в силу различных бизнес-причин. Каким же образом традиционная сеть может мягко эволюционировать в SDN? В общих чертах такой переход может быть реализован тремя путями:
• Сценарий 1: Построение новых SDN-точек доставки в рамках существующего ЦОД
• Сценарий 2: Развертывание SDN на новых устройствах для проектов расширения традиционных точек доставки
• Сценарий 3: Повторное использование существующих сетевых устройств для обновления традиционной сети ЦОД до SDN-сети

Решения для эволюции сети

Сценарий 1: Построение новых SDN-точек доставки в рамках существующего ЦОД

Сеть ЦОД может постепенно трансформироваться в SDN путем построения новых SDN-точек доставки в существующих ЦОД при наличии следующих предпосылок:
До начала трансформации традиционных ЦОД в ЦОД на основе SDN, заказчики хотят убедиться в жизнеспособности SDN-ЦОД путем построения новой гибкой точки доставки на основе SDN и проверки новых сервисов через эту точку. Сервисы в новых точках доставки не требуют взаимодействия с традиционными точками доставки.
Заказчики строят одну или несколько гибких точек доставки на основе SDN и запускают на них новые сервисы, либо мигрируют на новые точки доставки какие-то из существующих сервисов. Новые точки доставки требуют обеспечения L3-коммуникации с существующими точками доставки через основные устройства ЦОД. Между новыми и старыми точками доставки не требуется наличие L2-соединения.
При этом сценарии развития существуют следующие требования сервисов:
• SDN разворачивается на новой точке доставки, новые сервисы запускаются на ней независимо.
• SDN-точки доставки не требуют взаимодействия с традиционными точками доставки.
• В случае необходимости коммуникация между традиционными и SDN-точками доставки осуществляется посредством L3-переадресации основными устройствами ЦОД.

Дизайн сети:


Процесс переадресации трафика:


Процесс переадресации трафика между традиционными и SDN-точками доставки происходит следующим образом:
L3-шлюз на традиционной точке доставки переадресует трафик на основной коммутатор на основании таблицы маршрутизации.
Основной коммутатор пересылает трафик на шлюзовой коммутатор на SDN-точке доставки.
Шлюзовой коммутатор находит соответствующий маршрут и переадресует трафик на фаервол.
Фаервол находит соответствующий маршрут и переадресует трафик системе виртуальной маршрутизации и пересылки (VRF), к которой относится хост назначения.
Шлюзовой коммутатор находит таблицу потоков VXLAN для хоста назначения, инкапсулирует пакеты в формат пакетов VXLAN и затем отправляет их на VTEP назначения.
VTEP назначения декапсулирует пакеты VXLAN и переадресовывает исходные пакеты на хост назначения на основании информации о соответствующем MAC-адресе.

Сценарий 2: Развертывание SDN на новых устройствах для проектов расширения традиционных точек доступа

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

1. L3-коммуникации • Дизайн сети:

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


• Процесс переадресации трафика:

Процесс переадресации L3-трафика между традиционной и SDN-сетями в расширенной SDN-точке доставки протекает следующим образом:
L3-шлюз традиционной сети переадресует трафик на шлюзовой коммутатор в SDN-сети на основании таблицы маршрутизации.
Шлюзовой коммутатор находит соответствующий маршрут и переадресует трафик на фаервол.
Фаервол находит соответствующий маршрут и переадресует трафик на VRF, к которой относится хост назначения.
Шлюзовой коммутатор находит таблицу потоков VXLAN для хоста назначения, инкапсулирует пакеты в формат пакетов VXLAN и затем отправляет их на VTEP назначения.
VTEP назначения декапсулирует пакеты VXLAN и переадресовывает исходные пакеты на хост назначения на основании информации о соответствующем MAC-адресе.

2. L2-коммуникации • Дизайн сети:

Традиционная сеть подключается к L2-мосту в новой SDN-сети. L2-мосты сопоставляют идентификаторы VLAN, используемые в традиционной сети, с VNI, используемыми в SDN-сети, устанавливая между двумя сетям L2-соединение. L3-шлюз для хостов традиционной сети может мигрировать на шлюзовые коммутаторы в SDN-сети. Расширенные SDN-точки доставки подключаются к основному узлу коммутатора ЦОД через новые шлюзовые коммутаторы.



• Процесс переадресации трафика:

Процесс переадресации L2-трафика между традиционной и SDN-сетями в расширенной SDN-точке доставки протекает следующим образом:
Агрегирующий коммутатор традиционной сети переадресовывает L2-трафик на L2-мост в SDN-сети через канал Eth-Trunk.
L2-мост инкапсулирует пакеты формат пакетов VXLAN на основе подготовленного контроллером маппинга VXLAN-VNI, находит хост назначения в таблице потоков VXLAN и переадресовывает пакеты на VTEP назначения.
VTEP назначения декапсулирует пакеты VXLAN и переадресовывает исходные пакеты на хост назначения на основании информации о соответствующем MAC-адресе.

Сценарий 3: Повторное использование существующих сетевых устройств для обновления традиционной сети ЦОД до SDN-сети

Заказчики могут реконструировать сеть и инфраструктуру рабочей или тестовой точки доставки в SDN-точку доставки, чтобы оценить SDN-решение и испытать услуги SDN-сети. Благодаря использованию уже существующих сетевых устройств, данный метод позволяет заказчикам построить программно-определяемую сеть с меньшими затратами.
• Дизайн сети:
В данном сценарии может быть использовано гибридное оверлейное решение. Коммутаторы CloudEngine 1800V от Huawei могут быть размещены на серверах и выполнять функции VTEP-узлов наложенной сети VXLAN. Физические коммутаторы Huawei CloudEngine действуют как шлюзы направления север-юг и декапсулируют трафик VXLAN, проходящий через фаерволы, а также переадресуемый трафик в рамках точки доставки. Существующие коммутаторы доступа повторно используются в нижележащей сети.

• Процесс переадресации трафика:

Процесс переадресации трафика между традиционными и SDN-точками доставки происходит следующим образом:
L3-шлюз на традиционной точке доставки переадресует трафик на основной коммутатор на основании таблицы маршрутизации.
Основной коммутатор пересылает трафик на шлюзовой коммутатор направления север-юг на SDN-точке доставки.
Шлюзовой коммутатор находит соответствующий маршрут и переадресует трафик на фаервол.
Фаервол находит соответствующий маршрут и переадресует трафик на VRF, к которой относится хост назначения на шлюзовом коммутаторе направления север-юг.
Шлюзовой коммутатор направления север-юг находит таблицу потоков VXLAN для хоста назначения, инкапсулирует пакеты в формат пакетов VXLAN и затем отправляет их на VTEP назначения (CloudEngine 1800V).
VTEP назначения декапсулирует пакеты VXLAN и переадресовывает исходные пакеты на хост назначения на основании информации о соответствующем MAC-адресе.

Блестящее будущее SDN в сетях ЦОД

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

Автор: Денис Сереченко, директор по развитию бизнеса Huawei Enterprise Business Group в России.
"
Еще больше информации на сайте — e.huawei.com/ru

Original source: habrahabr.ru (comments, light).

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


/ Flickr / kosheahan / CC

В рейтинге самых производительных компьютеров в мире, представленном в июне на Международной конференции суперкомпьютеров во Франкфурте, разработкам Китая принадлежат две первые строчки. Их занимают Sunway TaihuLight и Тяньхэ-2 и имеют производительность в 125,43 петафлопс и 54,9 петафлопс соответственно.

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

Для этого Китай готов финансировать как минимум три конкурирующие группы разработчиков: Sugon, Оборонный научно-технический университет НОАК, который разрабатывал суперкомпьютеры Tianhe, и Sunway, занимавшейся TahiuLight. Власти хотят выбрать проект, который обеспечит высочайшую производительность и будет готов к немедленному использованию после создания. Ожидается, что траты на суперкомпьютер составят от одного до двух миллиардов юаней (150– 300 млн долларов).

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

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

Исследователи уверены, что эксафлопсные вычисления помогут проводить комплексное моделирование океана и решать сложнейшие проблемы. Фэн Лицян (Feng Liqiang), глава Marine Science Data Centre в Циндао, считает, что суперкомпьютер сможет собрать все данные, связанные с морской средой, для проведения всестороннего анализа. В результате Китай добьется океанических симуляций с беспрецедентно высоким разрешением, что поможет формировать надежные прогнозы в таких вопросах, как изменение климата на планете.

Эксафлопсные гонки

Поскольку создание суперкомпьютера имеет стратегическое значение, а Titan из национальной лаборатории Ок-Ридж, США, располагается на четвертой строчке в рейтинге самых быстрых устройств, в июне Министерство энергетики Штатов приняло решение сократить разрыв с Китаем. Оно объявило о финансировании работы шести компаний — AMD, Cray, HPE, IBM, Intel и Nvidia — в размере $258 млн на ниве эксафлопсных вычислений. Строительство действующего прототипа назначено на 2021 год.

Чтобы притормозить конкурентов, в 2015 году правительство США даже запретили Intel поставлять свои самые быстрые чипы для проектов по созданию суперкомпьютеров в Китае.

Несмотря на это, Китай анонсировал запуск прототипа устройства Tianhe-3 для генетических исследований в первом квартале 2017 года с выходом на полную мощность к 2020 году. Сегодня в стране обещают продемонстрировать все возможности нового эксафлопсного компьютера в 2019 году.

В то же время в августе Национальная лаборатория Ок-Ридж начала сборку Summit — системы IBM–NVIDIA, которая имеет шансы стать самым мощным суперкомпьютером в мире. Ожидается, что система будет доступна для научных исследований к январю 2019 года.


/ wikimedia / Titan / PD

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

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

Проблемы эксафлопсных суперкомпьютеров

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

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

Стив Конуэй (Steve Conway), из научного агентства Riken, отмечает, что «гонка за эксафлопсами», так или иначе, продвигает вперед технологию суперкомпьютеров и искусственного интеллекта. Он прогнозирует, что существующие проблемы будут преодолены, и первые эксафлопсные суперкомпьютеры появятся в списке 500 самых быстрых компьютеров в 2021 году, а уже к 2023 году станут обычным явлением.

Уже сегодня китайский Sunway TaihuLight добился моделирования Вселенной с 10 триллионами цифровых частиц, а ученые из Цюрихского университета воссоздали 25 миллиардов виртуальных галактик, состоящих из 2 триллионов цифровых частиц. В любом случае в гонке стран за эксафлопсами выиграет в первую очередь наука.

P.S. О чем еще мы пишем в нашем блоге:

• Виртуальный или физический сервер? Сравнение расходов
• Технологии охлаждения дата-центров
• Подборка материалов об облаках, дата-центрах и разработке сервисов

Original source: habrahabr.ru (comments, light).

Cloud Fabric: как SDN помогает IT более гибко реагировать на изменения

Для реализации облачных вычислений центры обработки данных и их сетевая архитектура должны соответствовать определенным требованиям. Справиться с новыми задачами поможет инновационное решение — Huawei CloudFabric, которое обладает следующими преимуществами:
• Гибкость: высокая масштабируемость облачных сервисов и каналы для передачи больших данных (Big Data).
• Упрощение процессов: облачное решение для сети Huawei в 10 раз ускоряет активацию облачных сервисов.
• Открытость: упрощение облачных вычислений за счет бесшовного подключения к основным облачным платформам.

SDN-решение Cloud Fabric содержит два основных компонента: серию коммутаторов для ЦОД Huawei CloudEngine и Agile Controller.
Решение использует открытую сервис-ориентированную архитектуру для централизованного назначения информационно-вычислительных ресурсов через Agile Controller и облачную платформу, построенную с учетом специфических требований к сервисам. Agile Controller может подключаться к различным облачным платформам ведущих поставщиков для формирования облачной сети, ориентированной на приложения. Облачная платформа может использоваться для унифицированного распределения сетевых, вычислительных и дисковых ресурсов.

Автоматизированное развертывание сети на основе приложений

SDN-решение Huawei Cloud Fabric реализует сервис-ориентированную программно-определяемую сеть центра обработки данных (DCN). IT-администраторы могут использовать сервисный язык для конфигурирования настроек сети (профилей приложений) чтобы обеспечить наилучшее соответствие конкретным требованиям к сервисам. У каждого сервиса есть уникальный профиль приложения, и IT-администраторы могут настраивать его в зависимости от потребностей. Agile Controller от Huawei может преобразовывать профили приложений в логические сети. Обладая такими возможностями, IT-администраторы могут гибко настраивать сети, ориентированные на приложения, делая возможной миграцию сетевых ресурсов по требованию.



• Языково-ориентированная сетевая модель приложений: Реализует контроль политики и оркестрацию цепочки сервисов на основе групп конечных устройств (EPG). Сетевые политики автоматически мигрируют с EPG без необходимости ручного вмешательства.
• Управление перетаскиванием элементов в WYWIWYG-интерфейсе: Функционал перетаскивания и оркестрации сервисов в рамках графического пользовательского интерфейса предоставляет возможности выделенной или коллаборативной подготовки сетевых и вычислительных ресурсов.

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

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



• Централизованная аппаратная VXLAN: Коммутаторы CloudEngine работают как граничные устройства сетевой виртуализации (NVE), при этом используется централизованное развертывание шлюзов VXLAN. Такой принцип работы сети применим к частным облакам с ограниченным количеством клиентов, но требует высокой производительности.
• Распределенная аппаратная VXLAN: Коммутаторы CloudEngine работают как NVE, шлюзы VXLAN развертываются в распределенном режиме.
• Гибридная программно-аппаратная VXLAN: NVE разворачиваются на виртуальных коммутаторах, на коммутаторах CloudEngine разворачиваются шлюзы уровня 3. Используется централизованное развертывание шлюзов VXLAN.

Детализированные функции O&M позволяют быстро локализовать сбои

Agile Controller решает наиболее насущные в наложенной виртуальной сети проблемы O&M. Он визуализирует пути переадресации между виртуальными машинами и удаляет «черные дыры» в виртуальной сетевой структуре O&M. Наглядное отображение сервисных трактов позволяет быстро локализовать сбои в виртуальных и физических сетях и позволяют сетевым администраторам быстро проверять сетевые конфигурации. Функции ретроспективного просмотра и воспроизведения сбоев улучшают скорость и качество O&M.



• Наглядно отображаемые нижележащие пути переадресации между виртуальными машинами
• Наглядное отображение путей переадресации между узлами VTEP VXLAN
• Наглядно отображаемые и контролируемые физические и виртуальные ресурсы

Архитектура с открытым исходным кодом стимулирует инновации в развитии сервисов

Архитектура на основе открытого исходного кода облегчает выстраивание открытой отраслевой экосистемы. Agile Controller предоставляет стандартные северные прикладные программные интерфейсы (API) RESTful и южные интерфейсы OpenFlow и Open vSwitch Database Management (OVSDB).

Северные API взаимодействуют со стандартной облачной платформой OpenStack и связываются с интерфейсами Neutron для ускорения ее линковки, ускоряют развертывание сетевых ресурсов и обеспечивают бесшовное взаимодействие вычислительных, сетевых и дисковых ресурсов.

Agile Controller может взаимодействовать с устройствами сторонних разработчиков для быстрого развертывания вычислительных и сетевых ресурсов в сетях облачных ЦОД. При изменении вычислительных ресурсов миграция сетевых ресурсов происходит динамически.

Кластер контроллера 1:N Elatic

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



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

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

Original source: habrahabr.ru (comments, light).

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

Описание проблемы

Я столкнулся со следующими проблемами при анализе существовавшего процесса:
• 80% задач поступает ad hoc
• приоритеты задач постоянно меняются
• нет возможности осуществлять планирование работ
• отсутствует гармоничность в развитии систем
• нет «установленных правил игры» при реализации изменений




Как внутренний эффект – эмоциональное выгорание персонала, падение производительности труда, отсутствие эффекта новаторства.

Основная цель Банка – максимально быстро и качественно выводить новые продукты на рынок. Почему этого не происходило? Я покажу три самых распространенных сценария. Уверен их можно встретить и в других финансовых организациях.

Для наглядности будем запускать новый кредитный продукт – Кредитная карта. Заказчиком будет выступать розничный бизнес, основной исполнитель – внешний подрядчик (будем использовать модель аутсорсинга, которая распространена в ряде организаций), внутреннее ИТ выполняет сервисную функцию. И самое главное: все ситуации будут вымышленные, а совпадения случайны.



Заказчик начинает реализацию проекта, проводит встречи с Исполнителем. Результат формирование паспорта проекта на реализацию продукта.

В паспорт попадают все требования и процессы, которые описывает наш Заказчик, основываюсь на процессе продажи:
• Поля анкеты клиента;
• Требования к фронт системе (продажа, верификация);
• Ролевая модель;
• Требования к интеграции с системами;
• Драфт процесса продажи.

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

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



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

Что имеем – дополнительные расходы на синхронизацию систем (параметров кредитного продукта) или трудозатраты перенос ведения продуктового каталога в АБС. В первом случае увеличиваются операционные расходы на сопровождение продукта, во втором увеличение сроков и бюджета проекта.



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

Поиск решения

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

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



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

Этап 1 – Фиксация идеи, Подготовка CR, Предварительная оценка.
Любой участник команды описывает реализуемое изменение для предварительного анализа, используя для этого формат user-story, которое в итоге попадает в беклог бизнес-аналитика. Бизнес аналитик организовывает еженедельные встречи, где изменения обсуждаются с участием владельца продукта, аналитиков и других бизнес подразделений, участвующих в процессе. После этого этапа изменения попадают в беклог продукта.

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

Этап 3 – Разработка, тестирование, релиз.
Владелец продукта получает результат каждого спринта на тестирование и может влиять на дальнейший ход, например, корректировать перечень дальнейших работ. Все изменения продукта объединяются в релизы, которые состоят из нескольких спринтов длительностью 2-4 недели.

Заключение

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

Управление кредитных карт и эквайринга (Владелец продукта)
• Управление финансового мониторинга
• Управление контроля финансовых и операционных рисков
• Управление сопровождения банковских операций
• Управление информационных технологий
• Управление платежных систем

Original source: habrahabr.ru (comments, light).

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

Переведено в Alconost

Первые шаги

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

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

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

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

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

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

С корабля на корабль

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

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

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

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

Неоправданно сложно? Да быть этого не может!

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

Вот мой совет: попробуйте прикинуть, сколько времени нужно, чтобы написать собственный прекрасный предметно-ориентированный язык или общее суперабстрактное решение с заделом на будущее (которое сейчас используется только в нескольких местах кодовой базы). Кроме того, дважды проверьте, что вам говорит «git diff». Уверены, после рефакторинга код стал лучше? Обычно, если удалось выкинуть большой кусок кода — это хороший знак. И всегда можно передумать и отложить его на некоторое время в отдельную ветку.

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

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

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

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

Почему мы ведёмся на шумиху

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

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

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

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

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

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

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

Вперед, к вершинам

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

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

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

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

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

Пару слов о скромности

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

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

Не сдавайтесь

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

Постоянно разбирать нескончаемый поток проблем (а это и есть суть разработки ПО) — это тяжелый умственный труд. У каждого были (или еще будут) дни, когда наваливается слишком много — и ты думаешь: «Зачем я этим занимаюсь? Всё очень плохо».

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


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

Original source: habrahabr.ru (comments, light).

Приглашаем провести 23 сентября с нами в Таганроге на Azov Developers Meetup 2017.

Приезжаем к 9 утра в конгресс-отель «Таганрог» на ул. Дзержинского, 161 попить кофе перед началом и до трёх часов дня послушать лекции о разработке. Мы расскажем о Vue.js и CQRS, попробуем найти точки соприкосновения SQL и NoSQL, поговорим о пределах совершенства кода и о настоящем Quality Assurance, развеем страхи перед интервью с заказчиком и ответим на дизайн-вопросы. Кроме того, мы пригласили на конференцию Михаила Скипского — игрока телеклуба «Что? Где? Когда?», обладателя двух «Хрустальных сов» (2010, 2016) — он расскажет о принятии решений и эффективности в малых группах.

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

А в 17 часов в клубе Stage в ТРЦ «Мармелад» пройдет after party — Михаил проведет для участников конференции интеллектуальный батл, проверим на практике тезисы из его выступления!

Более подробно о докладах:

Как проходить интервью с заказчиком
Андрей Холявкин, руководитель Таганрогского офиса Аркадии

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

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

Vue.js: новый фреймворк для front end
Михаил Зотов, разработчик

Среди множества фреймворков для front end наиболее популярными и известными являются Angular и React, однако хорошую конкуренцию им составляет новый фреймворк Vue.js. Михаил рассмотрит преимущества Vue.js перед его конкурентами и подробно опишет внутреннюю структуру компонентов Vue.js.

Из Тестировщика erectus в QA sapiens
Никита Белковский, QA инженер

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

Принцип CQRS в событийной веб архитектуре
Михаил Черноруцкий, IT специалист

Доклад посвящён рассмотрению одного из паттернов построения архитектуры web backend — CQRS (Command Query Request Segregation). Обсудим, что из себя представляет CQRS, и в каких случаях имеет смысл его использовать:

• происхождение и назначение паттерна CQRS (Command Query Responsibility Segregation);
• преимущества и недостатки;
• применение паттерна CQRS в архитектурах веб систем;
• сопутствующие понятия: Event Sourcing, Eventual Consistency, Materialized Views и т.д.

Дизайн-вопросы
Борис Винокуров, UX-UI дизайнер

Кто такие UX/UI дизайнеры? Зачем они нужны в процессе проектирования веб-приложений? Можно ли обойтись без их помощи и помощь ли это? Чем они отличаются от других дизайнеров и можно ли их считать художниками? Как устроен их рабочий процесс? Что считается хорошим результатом и почему? Креатив и творчество или решение задач? А может у вас найдутся и свои вопросы? Рад буду ответить.

Чистый код в коммерческой разработке. Есть ли предел совершенству?
Юрий Ковалёв, разработчик

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

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

SQL или NoSQL?
Владимир Кальсков, старший разработчик
Олег Брагин, старший разработчик

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

Что? Где? Когда? как модель командной работы
Михаил Скипский

Мы обычно воспринимаем телеигры как развлекательный контент, мало задумываясь над тем, что любая игра изначально является моделью. В случае с «Что? Где? Когда?» — социальной и технологической моделью принятия решения. Это означает, что поняв, как играть в «ЧГК» и подобные игры, мы поймём, как принимает решение группа, как она управляется и какие проблемы мешают малому коллективу быть эффективным.

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

Original source: habrahabr.ru (comments, light).

С частью 6 можно ознакомиться, перейдя по ссылке

XI Специфицируем требования

Требование — всего лишь временный посредник для решения проблемы реального мира.
«Фабрики разработки программ» [8]

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

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

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

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



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

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

XII Воплощаем требования в целевой продукт

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

1. Передаем требования в процесс реализации их в целевом продукте

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

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

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

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

1. Передавать требования на разработку можно только конкретному сотруднику, который имеет соответствующие полномочия и может нести ответственность за его выполнение. В противном случае ставить руководство в известность, об отсутствии у Вас возможности качественно выполнять свои функций. Это правило поможет сэкономить время на бесполезные беседы «по кругу».
2. Явно оговорить с исполнителем, какой конечный результат необходимо получить при реализации каждого требования, а также способы выполнения задания. Желательно убедиться, что Вас понимают правильно и видят результат работы таким же, каким видите его Вы. Это позволит избежать коммуникационного искажения информации.
3. Определить приоритеты реализации требований, с учетом функций: обязательных и желательных к исполнению. Это позволит увеличить вероятность получения работоспособных модулей, пожертвовав некоторой функциональностью.
4. Договориться, что при возникновении затруднений у исполнителей с реализацией требований, необходимо сразу же обращаться к Вам для уточнения, разъяснения или изменения требования.
5. Регулярно проводить анализ хода выполнения работ и обсуждать проблемы, возникающие в процессе реализации требований.
6. Улучшайте и развивайте процесс передачи требований в разработку, для того, чтобы постепенно уменьшать интенсивность контроля и упрощать разъяснения и саму процедуру.
7. Утвердить график сдачи готовых решений.

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

2. Передаем разработанный продукт заказчику

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

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

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

XIII Решаем проблему изменений требований при эксплуатации целевого продукта

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

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

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

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

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

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

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

2. Вносим изменения в требования только через заявки на изменения

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

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

XIV Заключение

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

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



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

Original source: habrahabr.ru (comments, light).

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

Масштабирование, Origin-Edge

Где может понадобиться межсерверное WebRTC? На ум сразу приходит паттерн Origin-Edge, который используется для масштабирования трансляции на большую аудиторию.

1. Пользователь отправляет WebRTC видеопоток на Origin-WebRTC сервер с браузера или мобильного устройства.
2. Origin-сервер рассылает поток по нескольким Edge-серверам.
3. Edge-серверы раздают поток конечным пользователям на их браузеры и мобильные приложения.

В современных CDN для доставки видео активно используется протокол RTMP при публикации потока на Origin-сервер и при рассылке потока на Edge-сервера, а конечные пользователи получают картинку уже по HTTP.

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

Нагрузочные тесты

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

На последних тестах мы поднимали Linux-серверы без GUI в облаке и запускали скрипты, стартующие много процессов браузера Google Chrome на виртуальном десктопе X11. Таким образом запускались реальные WebRTC-браузеры, которые тянули и играли WebRTC видеопотоки с Web Call Server, тем самым создавая нагрузку, максимально близкую к настоящей.  Для сервера это выглядело так, словно реальный пользователь открывал браузер и забирал видеопоток, полностью задействуя WebRTC-стек браузера, включая декодинг и рендеринг видео.

Недостатком этого способа тестирования была производительность тестовой системы. Достаточно тяжело запустить много процессов Chrome на одной Linux-системе, даже при использовании мощного сервера с мегаметрами памяти и CPU. В результате приходилось поднимать много серверов и как-то ими управлять / мониторить.

Другим ограничением было отсутствие гибкости — мы не могли  управлять процессами хрома. Было только две операции:

1. Поднять процесс и открыть нужный урл
2. Убить процесс. При открытии урла подгружалась HTML страница и происходило автоматическое соединение с сервером, уже средствами JavaScript, Websocket + WebRTC. Так моделировалась зрительская нагрузка.

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

Тестирование WebRTC Server-Server

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

Эта идея получила реализацию в виде WebRTC pulling. Один сервер WCS может вытянуть поток с другого сервера WCS по WebRTC. Для этого мы ввели внутреннюю абстракцию WebRTCAgent — объект, который поднимается на тестирующей ноде и тянет WebRTC-поток с тестируемой ноды, подключаясь к тестируемой ноде по Websocket+WebRTC.

После этого мы вынесли управление WebRTCAgent-ом на REST. В итоге нагрузочное тестирование свелось к вызову /pull — методов на REST интерфейсе тестирующей ноды.

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

Итак, у нас получилось тянуть WebRTC-потоки с других серверов. Тестирующий сервер подключался к тестируемому по Websocket, и как порядочный браузер, устанавливал ICE-соединение, DTLS и тянул SRTP потоки на себя, — получился true WebRTC pulling.

Оставалась совсем немного для получения полноценной модели Origin-Edge. Для этого нужно было пробросить такой pulling в движок WCS сервера как публикуемый поток, т.е. сделать его похожим на поток с веб-камеры, а такие потоки WCS уже умеет раздавать по всем доступным протоколам: WebRTC, RTMP, RTMFP, Websocket Canvas, Websocket MSE, RTSP, HLS.

Origin-Edge на WebRTC

Получилось, что мы делали межсерверный WebRTC для нагрузочного тестирования, но в результате реализовали Origin-Edge схему для масштабирования WebRTC трансляций, и вот как она работает:

Зеленой линией показано как проходит видео трафик. 

1. Пользователь из браузера или мобильного приложения, с помощью вебкамеры, отправляет WebRTC видеопоток с именем stream1 на сервер WCS1 — Origin. Процесс отправки видеопотока с помощью веб примера Two Way Streaming выглядит так:

А это JavaScript код, который отвечает за публикацию видеопотока через Web API (Web SDK):

session.createStream({name:'steram1',display:document.getElementById('myVideoDiv')}).publish();

2.  Далее мы обращаемся к серверу WCS2 — Edge по REST/HTTP API и даем команду забрать видеопоток с Origin-сервера.

/rest-api/pull/startup

{

                uri: wss://wcs1-origin.com:8443

                remoteStreamName: stream1,

                localStreamName: stream1_edge,

}

Сервер WCS2 подключается по вебсокетам к серверу WCS1 по адресу wss://wcs1-origin.com:8443 и принимает поток с именем stream1 по WebRTC.

После этого можно выполнить REST-команду

/rest-api/pull/find_all

чтобы вывести все текущие pull-подключения.

Или команду

/rest-api/pull/terminate

чтобы закрыть pull-соединение с Origin WebRTC сервером.

3. И наконец, забираем поток с Edge-сервера по WebRTC в плеере. Вводим имя потока stream1_edge и начинаем его играть.

WCS — сервер поддерживает несколько способов воспроизведения. Чтобы поменять технологию, просто тащим вверх MSE или WSPlayer чтобы играть поток не по WebRTC, а по MSE (Media Source Extensions) или в WSPlayer (Websocket — плеер для iOS Safari).

Таким образом, схема Orign-Edge отработала и мы получили масштабируемость WebRTC-сервера с низкой задержкой.

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

И снова про нагрузочное тестирование

Для нормального нагрузочного тестирования осталось написать Web-интерфейс в виде REST-клиента, управляющего pull-сессиями. Этот интерфейс был назван Console и принял следующий вид:


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


Еще предстоит немало сделать и отдебажить. В частности интересно поработать с динамическими битрейтами на межсерверном WebRTC-канале и сравнить межсерверную  проходимость с RTMP. Но уже сейчас у нас есть Orign-Edge на WebRTC и правильные нагрузочные тесты, дающие близкую к реальной нагрузку, что не может не радовать!

Ссылки

WCS5 — WebRTC сервер Web Call Server 5
Two Way Streaming — пример трансляции видеопотока из браузера
WebRTC Player — пример воспроизведения видеопотока в браузере с возможностью смены технологий WebRTC, MSE, Flash, WSPlayer

Original source: habrahabr.ru (comments, light).

В предыдущей статье «SDAccel – первое знакомство» я попытался описать основы применения OpenCL на ПЛИС Xilinx. Теперь настало время поделиться результатами экспериментов по передаче данных на модуле ADP-PCIe-KU3. Проверяется передача данных в обоих направлениях. Исходный код программ размещён на GitHub: https://github.com/dsmv/sdaccel

Аппаратура

Все эксперименты выполнены на модуле ADM-PCIe_KU3 компании Alpha-Data

Центральным элементом является ПЛИС Xilinx Kintex UltraScale KU060
К ПЛИС подключены два модуля SODIMM DDR3-1600; Ширина памяти 72 бита, это даёт возможность использовать контроллер памяти с коррекцией ошибок.

Существует возможность подключения двух QSFP модулей. Каждый QSFP модуль это четыре двунаправленные линии со скоростью передачи до 10 Гбит/с. Это даёт возможность использовать 1G, 10G, 40G Ethernet, в том числе реализовать Low-Latency Network Card. Также есть интересное свойство – ввод секундной метки от GPS приёмника. Но в данной работе всё это не используется.

Сервер NIMBIX

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

Модель вычислителя

Хочу напомнить, что из себя представляет система OpenCL.

Система состоит из HOST компьютера и вычислителя, которые связаны между собой по шине. В данном случае это PCI Express v3.0 x8;

Прикладное программное обеспечение состоит из двух частей:

• Программа HOST компьютера.
• Одна или несколько функций для работы на вычислителе.

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

Для работы прикладного ПО требуется инфраструктура, которую должен кто-то предоставить. В данном случае — компания Xilinx. В состав инфраструктуры входят:

• библиотека opencl — реализация функций стандарта OpenCL.
• драйвер модуля — обеспечивает взаимодействие с модулем.
• пакет DSA. Это основа для разработки собственной прошивки ПЛИС.

Пакет DSA содержит базовую прошивку, в состав которой входят контроллеры для PCI Express, динамической памяти и возможно для других узлов. В составе базовой прошивки есть элемент, который называется OpenCL Region. Вот внутри именно этого элемента и будут реализованы все функции OpenCL kernels. Загрузка прошивки внутрь OpenCL Regions производится через PCI Express с использованием технологии частичной перезагрузки (Partial Reconfiguration). Надо отметить, что Xilinx сильно продвинулся в скорости загрузки. Если в предыдущих версиях загрузка занимала несколько минут, что сейчас около 5 секунд. А в версии 2017.2 объявлено что можно вообще не проводить повторную загрузку прошивки.

На данный момент для модуля ADM-PCIe-KU3 в составе пакета SDAccel доступно два пакета:

• xilinx:adm-pcie-ku3:2ddr:3.3
• xilinx:adm-pcie-ku3:2ddr-xpr:4.0

Оба пакета имеют поддержку двух контроллеров памяти и PCI Express v3.0 x8; Обратите внимание на суффикс -xpr. Это достаточно важное различие. Вариант без xpr фиксирует положение DDR контроллеров и PCI Express. Вариант с xpr фиксирует только положение PCI Express, а контроллеры DDR участвуют в трассировке прикладных функций OpenCL. Это различие приводит и к различиям в результатах. Вариант без xpr разводится быстрее, а вариант с xpr может получить более оптимальную трассировку. Для данного проекта получилось 1 час 11 минут для варианта без xpr и 1 час 32 минуты для варианта xpr. Логи здесь.

Кстати, в состав каждого DSA пакета входит свой драйвер.

Программа CHECK_TRANSFER

Программа предназначена для проверки непрерывной передачи данных в трёх режимах:

• Из ПЛИС в SODIM и в компьютер
• Из компьютера в SODIMM и в ПЛИС
• Одновременная передача в двух направлениях

На мой взгляд проверка скорости работы без проверки данных особого смысла не имеет. Поэтому я с помощью OpenCL реализовал на ПЛИС узел генератора тестовой последовательности и узел проверки тестовой последовательности.

Стандарт OpenCL предусматривает обмен между устройством и компьютером только через глобальную память устройства. Обычно это динамическая память на SODIMM. И здесь возникает очень интересный вопрос о возможности передачи данных с предельными скоростями. На модуле ADM-PCIe-KU3 применены два SODIM DDR3-1600. Скорость обмена для одного SODIMM около 10 Гбайт/с. Скорость обмена по шине PCI Express v3.0 x8 – около 5 Гбайт/с (пока получилось намного меньше). Т.е. существует возможность записывать в память один блок поступающий от PCI Express и одновременно считывать второй блок для обработки внутри ПЛИС. А что делать если надо ещё возвращать результат? PCI Express обеспечивает двунаправленный поток на высокой скорости. Но у памяти шина одна, и скорость будет делиться между чтением и записью. Вот здесь и нужен второй SODIMM. У нас существует возможность указать в каком именно модуле будет размещён буфер для обработки.

Операционная система

SDAccel может работать только под некоторыми системами Linux. В списке доступных систем CentOS 6.8, CentOS 7.3, Ubuntu 16.04, RedHat 6.8, RedHat 7.3; Первые эксперименты я начинал на CentOs 6.7; Далее попробовал использовать Ubuntu 16.04, но там не всё заработало. На данный момент я использую CentOS 7.3 и очень доволен этой системой. Однако при настройке SDAccel есть ряд тонкостей. Главная проблема – по умолчанию сетевой интерфейс имеет имя “enp6s0”. Такое имя не понимает сервер лицензий Xilinx. Ему требуется обычный “eth0”.
Настройка здесь: https://github.com/dsmv/sdaccel/wiki/note_04---Install-CentOS-7-and-SDAccel-2017.1

Qt 5.9.1 устанавливается но не работает. Для него требуется более новый компилятор gcc и git. Это тоже решается, подробности здесь: https://github.com/dsmv/sdaccel/wiki/note_05---Install-Qt-5.9.1-and-Git-2.9.3

Системы разработки

Для разработки я использую две системы:

• SDAccel 2017.1 – для разработки kernal и небольших тестовых программ HOST
• Qt 5.9.1 – для разработки более сложных программ. Qt используется только для разработки программ HOST.

Организация проекта на GitHub

Репозитарий dsmv/sdaccel предназначен для разработки примеров для SDAccel. В данный момент там есть только одна программа check_transfer. Для проекта используются ряд возможностей GitHub:

• README.md – первый файл, который виден посетителю.
• WiKi – описание программы
• Development Notes – заметки по ходу разработки
• Issues – список задач
• Projects – управление проектом
• А также есть документация на программу сформированная Doxygen

Основные каталоги программы

• useful – полезные скрипты для настройки системы
• qt – каталог для исходников Qt
• sdx_wsp/check_transfer — рабочий каталог SDAccel

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

Два режима вывода

(Нажмите на картинку для увеличения)

На рисунке показан внешний вид терминала во время работы программы. Обратите внимание на таблицу. Это таблица с выводом текущего состояния теста. Во время работы очень интересно узнать, а что собственно происходит. Тем более что предусмотрен режим без ограничения по времени. Таблица очень помогает. К сожалению, есть проблемы. SDAccel сделан на основе Eclipse. Мне не удалось научиться запускать программу из среды во внешнем терминале. А во встроенном терминале таблица не работает. Пришлось сделать режим запуска без таблицы. Кстати система Nsight Eclipse Edition для программирования устройств NVIDIA тоже не умеет запускать программы во внешнем терминале. Или может я что-то не знаю?

Мегабайты или Мебибайты ?

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

Давайте рассмотрим некоторые фрагменты кода программы.

Kernel gen_cnt

Код ядра gen_cnt() очень простой. Функция заполняет массив заданного размера тестовым блоком данных.

__kernel
__attribute__ ((reqd_work_group_size(1,1,1)))
void gen_cnt(
                __global ulong8    *pOut,
                __global ulong8    *pStatus,
                const   uint  size
              )
{
    uint    blockWr;
    ulong8  temp1;
    ulong8  checkStatus;
    ulong8  addConst;
    checkStatus = pStatus[0];
    temp1       = pStatus[1];
    addConst    = pStatus[2];
    blockWr     = checkStatus.s0 >> 32;
  __attribute__((xcl_pipeline_loop))
  for ( int ii=0; iicode>

Переменная temp1 имеет тип ulong8. Это стандартный тип OpenCL который представляет собой вектор из восьми 64-х разрядных чисел. Обращаться к элементам вектора можно по именам s0..s7 или так temp1.s[ii]. Это достаточно удобно. Ширина вектора 512 бит. Это соответствует ширине внутренней шины для контроллера SODIMM. Одним из элементов оптимизации как раз и заключается в обмене с памятью только 512 битными данными. По указателю pStatus находится блок со статусной информацией, из него считывается текущее значение и константы. Для каждого 64-х битного поля используется своя константа. Это позволяет сделать не только простой счётчик но и что то более сложное. Хотя пока что программа делает только простой счётчик. В конце функции производится запись текущего значения данных и число заполненных блоков.

check_cnt_m2a и check_read_input

Для реализации проверки я написал две функции, одна check_read_input — читает данные из динамической памяти и записывает их в pipe. Вторая – check_cnt_m2a – читает данные из pipe и проверяет их. Наверное в данном случае разделение на два kernel и их связь через pipe является избыточным. Но мне было интересно проверить эту технологию.

Код здесь

Структура программы HOST

Программа основана применении виртуальных классов TF_Test и TF_TestThread; На основе этих классов разработаны два класса тестирования

• TF_CheckTransferOut — проверка передачи от устройства в компьютер
• TF_CheckTransferIn – проверка передачи из компьютера в устройство

Базовый класс TF_Test содержит функции:

Название	Назначение
Prepare()	Подготовка
Start()	Запуск
Stop()	Останов
StepTable()	Шаг отображения таблицы
isComplete()	Работа теста завершена
GetResult()	Вывод результата

Функция main() создаёт по одному экземпляру каждого класса и начинает выполнение.
Каждый класс тестирования создаёт свой поток выполнения, в котором происходит обмен с модулем. Функция main вызывает Prepare() для каждого класса. Внутри этой функции как раз и создаётся поток, выделяется память и проводится вся подготовка. После того как оба класса готовы вызывается старт, что приводит к запуску главного цикла тестирования. При нажатии Ctrl-C или при окончании заданного времени тестирования вызывается Stop(). Классы останавливают работу и с помощью функции isComplete() информируют об этом main(). После остановки вызывается GetResult() для получения результата. В процессе выполнения теста функция main() вызывает StepTable каждые 100 мс для обновления таблицы. Это позволяет обновлять статусную информацию без вмешательства в обмен данными.
Такой подход оказался очень удобным для построения тестовых программ. Здесь все тесты строятся по одинаковому шаблону. В результате их можно запускать параллельно, а можно и поодиночке. В данной программе легко организуется режим как одиночного запуска одного из тестов, так и одновременный запуск.

Режимы выполнения OpenCL программы

Система SDAccel предоставляет три режима выполнения программы:

• Emulation-CPU — всё выполняется на HOST процессоре
• Emulation-HW — функции OpenCL выполняются на симуляторе Vivado
• System — работа на реальной аппаратуре.

Более подробно — в предыдущей статье.

Интересно сравнить скорости работы в трёх средах. Сравнение очень показательное:

Emulation-CPU	Emulation-HW	System
200 МБ/с	0.1 МБ/с	2000 МБ/с

Числа я округлил что бы лучше видеть порядок. Собственно разница в скорости между Emulation-CPU и Emulation-HW показывает что в разработке прошивок ПЛИС надо переходить на C/C++ или что-то аналогичное. Выигрыш на четыре порядка это очень много, это перекрывает все недостатки С++. При этом надо отметить, что разработка на VHDL/Verilog не исчезнет, и эти языки скорее всего придётся применять для достижения предельных характеристик. Очень перспективным выглядит возможность создания OpenCL kernel на VHDL/Verilog, это позволит сочетать высокую скорость разработки и предельные характеристики ПЛИС. Но это уже тема отдельного исследования и отдельной статьи.

Результат трассировки

Вот что получилось. Обратите внимание на количество DSP для gen_cnt. Для реализации восьми 64-х разрядных счётчиков потребовалось 128 DSP блоков. Это по 16 блоков на счётчик. Скорее всего это результат работы оптимизатора по раскрытию цикла.

Различия в методах оптимизации для FPGA и GPU

Для достижения предельных результатов должны применяться разные методы оптимизации. GPU имеет фиксированную структуру. Если условно говоря один процессорный элемент GPU может выполнять одну операцию, то что бы параллельно выполнить 100 операций надо задействовать 100 процессорных элементов. А вот в ПЛИС это не является единственным вариантом. Да, мы можем написать один kernel и разместить несколько экземпляров в ПЛИС. Но это приводит к большим накладным расходам. Xilinx рекомендует использовать не более 16 kernel, а точнее портов памяти. Зато внутри одного элемента нет ограничений на распараллеливание. Собственно пример gen_cnt это и показывает. Там сразу в коде записаны восемь 64-х разрядных сумматоров. Кроме того сработал оптимизатор и развернул цикл. Для GPU этот пример надо написать по другому, например сделать один kernel для получения 64-х разрядного отсчёта и запустить сразу восемь экземпляров.

Что может показать Emulation-HW

Этот режим может показать что происходит на шинах доступа к памяти. На картинке показан процесс чтения данных из памяти функцией check_read_input().

(Нажмите что бы увеличить)

Во первых здесь видно с какой большой задержкой приходят данные. Задержка от первого запроса до появления первых данных 512 нс. Во вторых видно что чтение идёт блоками по 16 слов (размером 512 бит). При разработке на VHDL я бы использовал больший размер блока. Но видимо контроллер умеет объединять блоки и это не приводит к замедлению. В третьих видно что есть разрывы в получении данных. Они тоже объяснимы. Частота работы OpenCL 250 МГц, частота шины памяти для SODIMM DDR3-1600 составляет 200 МГц. Разрывы точно соответствуют переходу от шины 200 МГц к шине 250 МГц.

Результаты

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

Одиночные тесты

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	2048	1837
Intel Core-i7, PCIe v3.0 x8	2889	2953

Двунаправленный тест

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	1609	1307
Intel Core-i7, PCIe v3.0 x8	2048	2057

Для сравнения, на нашем модуле с аналогичной ПЛИС рекордная скорость ввода составила 5500 MiB/s, хотя по ряду причин пришлось её снизить до 5000. Так что возможности для увеличения скорости обмена есть.

Что дальше

Работа будет продолжаться.

• Исследование возможностей SDAccel 2017.2
• Реализация узла свёртки на основе библиотеки FPFFTK от Александра Капитанова ( capitanov )
• Разработка собственных DSA пакетов, в том числе с поддержкой 10G Ethernet
• И главное — разработка собственного модуля, название уже есть — DSP135P

P.S. Хочу выразить благодарность Владимиру Каракозову за помощь в разработке шаблона программы тестирования.

Original source: habrahabr.ru (comments, light).