Рынок безопасности интернета вещей к 2021 году достигнет $37 млрд, согласно аналитическому отчёту Marketsandmarkets.com. Где разрастается хаос в сфере кибербезопасности, там и тратятся большие деньги на обеспечение этой безопасности.

В начале 2017 года эксперты предсказывали, что зияющие в IoT бреши приведут к разрушению критически важной инфраструктуры, росту конкурентной разведки и краж интеллектуальной собственности. Также прогнозировалось, что многократное увеличение DDoS-атак парализует Dyn DNS-систему, а с ней и многие важные веб-домены.

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

Первый аспект

Сегодня ежедневно в сеть выходят не менее 6 миллионов новых IoT-устройств, что означает постоянное появление всё новых уязвимостей. К примеру, в прошлом году на DefCon в 23 IoT-устройствах 21 производителя обнаружили 47 новых уязвимостей. Учитывая, что в одном устройстве обычно по несколько дыр, то ситуация складывается плачевная.

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

Второй аспект

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

Для атакующего несложно получить контроль над целыми сетями, начав с компрометации одного из многочисленных уязвимых потребительских IoT-устройств. Яркий пример — популярный термостат NEST. В 2015-м инженеры компании TrapX Security подключились к miniUSB-порту термостата и провели атаку man-in-the-middle (MITM), в ходе которой с помощью специального приложения заспуфили ARP-адрес сетевого шлюза. Хакеры используют MITM-атаки для получения контроля над системами на одном или обоих концах коммуникаций, включая корпоративные сети.

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

Третий аспект

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

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

Четвертый аспект

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

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

Пятый аспект

Распространённый и по большей части открытый IoT позволяет сегодня как никогда легко проводить одновременные атаки “Fire Sale” на любое агентство, сервис или предприятие, как показано в фильме «Крепкий орешек 4». Благодаря интернету вещей хакеры могут создавать и использовать настолько большие ботнеты, что одновременное глушение многочисленных инфраструктур с помощью DDoS-атак превращается чуть ли не в рутину.

Представьте, что будет, если 10-15% устройств какой-то страны использовать для DDoS-атаки против ресурсов одного из мировых финансовых центров, например, Уолл Стрит.

Согласно прогнозу Gartner, с 5,5 млн IoT-устройств в 2016 году, к 2020-му мы придём к общему парку в 20,8 млрд устройств, работающих ежедневно. Чтобы обезопасить это оборудование, компании должны в первую очередь сопоставлять удобство и эффективность с рисками, внедрять политики и процедуры безопасности, разработанные для каждого типа устройств, и обучать персонал правильной работе с интернетом вещей. Технологии DS/IPS-безопасности, учитывающие поведенческий фактор, тоже должны стоять на страже потенциально зловредного поведения IoT-устройств.

Когда компания устанавливает и использует потребительские устройства вроде того же термостата NEST, то она должна внедрять и новые файрволы второй генерации, позволяющие подключаться только по определённым IP-адресам, применять политики безопасности к конечным точкам второй генерации, а также технологии маскировки. Появление в домах уязвимых устройств и возможные последствия этой тенденции являются важной причиной для просвещения сотрудников о рисках.
Не имеет значения, как злоумышленники подбирают пароли и ответы на секретные вопросы: можно защититься с помощью дополнительной аутентификации. Например, использовать PINы и отправлять коды на почту. Сами компании должны адаптироваться к изменениям в подходах к подбору паролей. Для этого нужны профессионалы, осознающие риски новой технологии, и постоянное обновление программно-аппаратной инфраструктуры (без привнесения новых рисков).
Тяжело обезопасить SCADA и промышленные легаси-системы управления, потому что подобные системы тяготеют к закрытости при отсутствии даже базовых механизмов обеспечения кибербезопасности. Как минимум, компании должны изолировать их в своих сетях, плотно мониторить и регулировать доступ к ним. Промышленные системы управления имеют высокие требования по доступности. Это означает, что простой при обновлениях недопустим. В идеальном мире подобные системы должны дополняться совершенной защитой и быть изолированными от интернета.

Как и при отражении “Fire Sale”-атак, защита IoT от DDoS-атак включает в себя обеспечение безопасности устройств из расчёта враждебности сети, и обеспечение безопасности сети из расчёта враждебности отдельных устройств. Такой подход согласуется с моделью безопасности, подразумевающую нулевое доверие к минимальным привилегиям.

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

Что начать делать?

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

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

https://habrahabr.ru/post/332852/

Привет Мир! Много было сказано о сути GraphQL, но гораздо меньше о самих запросах. От простого к более сложному, я раскрою тему. Заинтересованным, — добро пожаловать под кат.

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

• Tutorial: GraphQL server with Koa2 and MongoDB
• Tutorial: GraphQL subscriptions for real-time app
• Tutorial: GraphQL authentication, register, profile

Среды тестирования

• GraphiQL — встроенный пакет для тестирования на сервере.
• Apollo Client Developer Tools — тот же GraphiQL завернутый в chrom расширение.

Запросы

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



Начнем с двух простых типов запросов, это Queries(получение данных) и Mutations(изменение данных).

Queries

Простым запросом можно обратились к полю user и сказать, какие значения сервер должен вернуть: firstName и lastName.

query myQuery{
    user {
       firstName
       lastName
   }
}

При работе с GraphiQL, можно не указывать query перед фигурными скобками. При этом, при написании запросов на клиенте, если вы НЕ укажите явно тип запроса, будет ошибка.

Mutations

Для изменения данных необходимо указать, что именно мы хотим заменить и чем:

mutation myMutation{
  UserCreate(data: {firstName: "Jane", lastName: "Dohe"})
}

Queries выполняются асинхронно, а mutations — последовательно.

Subsciptions

У GraphQL есть третий тип — subscriptions(подписки).

subscriptions mySubscription{
    user {
       firstName
       lastName
   }
}

Они полностью аналогичны queries и все что применимо к queries, подходит для subscriptions.

Пока все просто, но это не подходит для разработки проекта.

Аргументы

Аргументы позволяют сделать очевидные вещи — подставить свои значения и сделать запрос. Абсолютно не важно будет это queries, mutation или subscription.

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

query myQuery($id: '1'){
    user (id:$id){
       firstName
       lastName
   }
}

Такой запрос найдет пользователя с id = '1' и вернет нам его firstName и lastName.

Переменные

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

query myQuery($id: ID){ // запрос
    user (id:$id){
       firstName
       lastName
   }
}

{ 
  "id": "595fdbe2cc86ed070ce1da52"  // переменные
}

На рабочем проекте, это будет выглядеть так:



ID! — восклицательный знак в конце типа говорит GraphQL, что это поле обязательное.

Простому юзеру, не нужно переживать о том, как сформировать запрос на клиенте. Для популярных JS фрейморков все уже готово: vue-apollo, react-apollo, apollo-angular.

Вложенные запросы

Вышеописанные подходы применим, когда искомое поле БД находится на первом уровне(без вложенностей). Пример модели на MongoDB:

// MongoDB schema
const schema = new mongoose.Schema({
    firstName: {
        type: String
    },
    lastName: {
        type: String
    },
})

export const USER_MODEL = mongoose.model('users', schema)

// GraphQL type
const user = {
    firstName: {
        type: GraphQLString
    },
    lastName: {
        type: GraphQLString
    },
}

export const USER = new GraphQLObjectType({
    name: 'USER',
    fields: user
})

Пример со вложенной схемой:

// MongoDB schema
const schema = new mongoose.Schema({
    firstName: {
        type: String
    },
    lastName: {
        type: String
    },
    secure: {
        public_key: {
            type: String
        },
        private_key: {
            type: String
        },
    },
})

. . .

const secure = new GraphQLObjectType({
    name: "public_key",
    fields: {
        public_key: {
            type: GraphQLString
        }
    }
})

export const USER = new GraphQLObjectType({
    name: "USER",
    fields: {
        firstName: {
            type: GraphQLID
        },
        secure: {
            type: secure
        }
    }
})

Query запрос будет выглядит так:

query myQuery($id: ID){ 
    user (id:$id){ 
       firstName
       secure {
          public_key
       }
   }
}

Mutations + Queries

Мутации не обязательно должны возвращать булевские значения true/false. Если на сервере в тип поля вместо GraphQLBolean указать тип из модели, то получиться следующее:

mutation auth($email: String!, $password: String!) {
  auth(email: $email, password: $password) {
    id
    secure {
      public_key
    }
  }
}

Заключение

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

Спасибо за внимание.

https://habrahabr.ru/post/332850/

Привет, Хабр! У нас в компании уже около года существует направление экспериментальных игровых разработок, и сегодня хотим рассказать об одной из них. Мы Owlcat Games, и в рамках кикстартерной компании разрабатываем игру Pathfinder: Kingmaker — это однопользовательская CRPG с изометрической графикой (привет, олдскульщики!). В этом посте расскажем о том, как мы делаем интерфейс для нашей игры.

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

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

Для реализации принципа «удобство» нам помогают UX-исследования и правильно построенный pipeline производства.

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

Мы придерживаемся следующей схемы работы. Вначале тщательно анализируем будущий контент и делаем первые наброски, которые представляем команде. Далее разрабатываем схемы взаимодействия и на основе этого создаем первые static wireframes, т. е. фактически «чертеж» интерфейса, чтобы понять, как он будет выглядеть, оценить информативность и компоновку элементов. Как правило, за этим следует горячее обсуждение. Например, наш геймдизайнер хочет видеть больше цифр, ВЕЗДЕ, чем больше цифр — тем лучше. При этом технический художник упорно настаивает на том, чтобы интерфейс был максимально атмосферным, а с информацией — как пойдет. И отказать ему бывает сложно. В общем, лавируя между мнениями, как Одиссей между Сциллой и Харибдой, мы находим удовлетворяющий всех баланс. Далее — реализация функционала, арт и плейтесты, после них — снова доработка функционала и арта. И так до того момента, пока результат не удовлетворит всю команду и игроков на фокус- и UX-тестах.

Внутри команды иногда бывает сложно оценить результат работы. Специально для этого мы проводим UX-исследования, привлекая и активных членов сообщества Pathfinder Society, и людей, которые просто любят игры в целом и CRPG в частности. Исследования помогают нам реализовывать принцип «удобство». Для первого тестирования в начале марта этого года мы пригласили своих коллег и друзей, отчасти — чтобы похвастаться, отчасти — для экспертной оценки. И хотя версия была довольно сырой и неполной, мы смогли получить много материала для анализа.

Heat map интерфейса Rest

Eye tracking в диалоге

Heat map боевки

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

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

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

Скетч журнала

Поиски

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

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

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

Но на деле все оказалось несколько сложней. Поиски были долгими и нелегкими.

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

И вот что у нас получилось в конце. Кажется, неплохо.

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

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

В итоге мы остановились на Book Antiqua. Он нам показался компромиссом между всеми требованиями.

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

https://habrahabr.ru/post/332802/

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



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

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

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

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

Эксплуатация WAF

Что же входит в задачи эксплуатации? Я выделил четыре основных направления:

1. Обновление – отслеживание патчей, в том числе закрывающих ошибки. Об этом было сказано выше, поэтому двигаемся дальше.
2. Написание частных сигнатур:
   
   • Отслеживание новых критичных сигнатур, совместные с заказчиком тестирование и подготовка контрмер на период, пока не выпущены официальные обновления (если нет возможности написать кастомные).
   • написание сигнатур в качестве компенсационных мер по закрытию уязвимостей исходного кода приложений:
     
     • уязвимости, известные разработчикам, закрытие которых требует масштабных доработок исходного кода;
     • уязвимости, выявленные в результате анализа исходного кода приложений.
3. Профилирование запросов, обращений к страницам сайта, приложению.
4. Validation – проверка и анализ параметров запросов/ответов на защищаемый ресурс/приложение.

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

Думаю, не вызывает сомнений то, что вариант «пришел-настроил-включил-работает» в 99% случаев не жизнеспособен и не работает на динамически изменяющемся контенте. Исключения составляют те заказчики, которые включают блокировку запросов по статическим сигнатурам, исключают тестирование обновлений, прилетающих на WAF и сразу «накатывают» их в продакшн. То есть если мы не говорим об обучающем функционале WAF, цикле обновлений, установки патчей по RFC, создания политики под конкретный защищаемый ресурс – возможно вам и не требуется специалист на full time или сервис по эксплуатации.

Режим работы WAF

Первый вариант: только блокирование – по сигнатурам и профилю. Здесь надо учитывать два момента: 1) есть достаточно высокий риск заблокировать легитимные запросы; 2) и, наоборот, WAF может пропустить запросы, эксплуатирующие уязвимости и дыры. Может случиться так, что при масштабном сканировании 99,9% запросов будет заблокировано, а 0,1% пройдет, но и этого будет достаточно для успешной атаки. По факту анализа 0,1 % пишутся и добавляются в блок новые кастомные сигнатуры.

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

Именно поэтому чаще всего используется третий вариант – гибридный.

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

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

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

Ниже пример настройки групп сигнатур одного из наших клиентов. В рамках оказания сервиса мы подключили WAF и логи веб-сервера (IIS) к SIEM-системе Solar JSOC. Критичные сигнатуры ставятся в блокирующий режим, логируются и добавляются в список обучения, на тот случай, если необходимо будет внести исключения:



Настройки параметров контента:



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



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

Кастомные сигнатуры

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

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

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

Работа с динамическим контентом

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

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

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

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

Вот два ярких примера цикла разработки у наших клиентов:

Первый случай – заказчик выпускает один релиз в неделю. При этом взаимодействие между заказчиком и подрядчиком не предусматривает детального release notes, по которому можно понять, нужна ли корректировка политики. Единственный вариант – работа «на горячую» с коротким и оперативным циклом тюнинга политики WAF:



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

Интеграция WAF с SIEM: как правильно и что нужно?

Если компания использует собственный или аутсорсинговый Security Operations Center, подключение WAF к SIEM-системе позволит наладить оперативное уведомление и разбор по всем типам инцидентов, в том числе и веб-атакам, из одной точки – SIEM-системы.

Для фиксации и дальнейшего расследования инцидентов в SIEM-системе необходимо подключение следующих источников:

• Непосредственно сам WAF.
• Логи веб-сервера. Как и говорилось выше, включение логирования всех запросов на WAF может вызвать чрезмерную нагрузку, поэтому проще подключить журналирование на IIS или Apache.
• Логи приложения, защищаемого WAF, для отслеживания запросов.
• Логи БД для отслеживания запросов.

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

При подключении WAF необходимо понимать, какие поля, заголовки и метаданные пригодятся в расследовании инцидентов. В качестве примера рассмотрим подключение F5 ASM к ArcSight.



Из необходимых полей стоит выделить:

Дата и время фиксации события
Имя сигнатуры – для примера, «Illegal request length»
Тип атаки – для примера, «Session Hijacking»
Запрашиваемый URL:

/login?_*********=/sitebuilder/****/myaccount/login/*******form

Метод запроса – GET, POST, etc.
Адрес, с которого пришел запрос
Адрес, на который пришел запрос
Протокол соединения
Код ответа сайта
Имя политики, по которой сработала сигнатура
Дата и время применения этой политики

Несмотря на ограничение в 1024 символа в customstring-полях ArcSight, мы «замапили» туда весь запрос, анализ которого очень часто пригождается в расследовании:



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

1. Аномальное количество различных сработавщих на WAF сигнатур с внешнего хоста – потенциальное сканирование на уязвимости.
2. Срабатывание сигнатур в течение нескольких дней подряд с одного внешнего хоста – медленное сканирование.
3. Срабатывание порогового значения сигнатур за короткий промежуток времени с разных хостов – распределенное сканирование/DDoS уровня приложения.
4. Попытка эксплуатации критичной уязвимости. В случае сработки этого сценария, наши специалисты, совместно с заказчиками, анализируют не только логи WAF, но и успешные запросы с того же адреса на веб-сайт. Далее, по результатам анализа и при возникшей необходимости, происходит доработка политики WAF.

После того как специалисты первой линии оповестят службу эксплуатации WAF, последние имеют возможность подключиться уже к интерфейсу СЗИ и в режиме реального времени «тюнить» политики для противодействия атаке. Подключение к SIEM-системе позволяет не только наладить оперативное оповещение о потенциальных инцидентах, но и обогащать информацию об атаках сведениями из других систем, а также производить сложную корреляцию по цепочкам событий. Например, для понимания успешности атаки информацию с Web Application Firewall можно коррелировать с запросами в SQL-базах данных или локальными логами веб-сервера.

Наш подход к обработке инцидентов:



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

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

В одной из таких выгрузок была обнаружена запись:

modify_order_bonus  ":"{\"bonusAvailable\":18.0,\"bonus\":-20000}" reason: success

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

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

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

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

Защита окружения приложений

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

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

• Логи операционных систем серверов приложений, баз данных, вспомогательных систем, терминальных серверов.
• Логи межсетевых экранов, отделяющих сегмент приложения от остальных.
• Логи WAF.
• Логи приложения (front-end, back-end).
• Логи веб-серверов.
• Логи базы данных приложения, хотя бы на уровне аутентификации, а лучше – на уровне запросов в саму базу.
• Логи VPN в случае работы подрядчиков с приложением через удаленные соединения.

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

• Контроль работы подрядчиков с приложением.
• Контроль работы привилегированных сотрудников.
• Выявление внешних атак на приложение.

На основе определенных выше векторов определяются необходимые к подключению источники и точки контроля в виде корреляционных правил, настраиваемых в SIEM-системе.

Состав правил выявления инцидентов обычно включает три блока:

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

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

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

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

https://habrahabr.ru/post/332846/

Топ-20 устойчивых регионов за 2017 год на карте мира

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

На глобальную доступность любого оператора связи влияют его пути до Tier-1 операторов. Tier-1 — транснациональные/трансконтинентальные операторы, обеспечивающие глобальную связность между континентами и странами.

Если отсутствуют пути до Tier-1 операторов — оператор не будет иметь глобальную доступность.

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

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

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

1. Мы построили альтернативные маршруты до Tier-1 операторов для каждой АС в мире с использованием модели отношений между АС проекта Qrator.Radar;
2. С использованием геобазы Maxmind мы сопоставили адресное пространство АС различным странам.
3. Для каждой АС мы осуществили нормировку полученных геоданных, чтобы избежать ситуации, когда АС имеет вырожденное присутствие в регионе. Примером подобного вырожденного присутствия может служить Гонконг, где на крупнейшем азиатском Internet Exchange, HKIX, присутствуют сотни операторов, при этом никакого отношения к доступности в самом Гонконге они не имеют.
4. Далее оценивалось влияние гипотетического отказа заданной АС на других операторов связи, и как следствие на национальные сегменты.
5. Для каждой страны была выделена АС, эффект от отказа которой окажет наибольшее влияние на другие АС данной страны.

Ниже представлена таблица топ-20 устойчивых стран 2017 и пересчитанный по новой схеме топ-20 за 2016 год.

% отказа	2016 год	Изменение 2016 — 2017	2017 год	% отказа
2.57478	Германия (DE)	1 место	Германия (DE)	2.29696
3.14068	Канада (CA)	Вниз на 2 позиции	Гонконг (HK)	2.65659
3.46469	Швейцария (CH)	3 место	Швейцария (CH)	3.57245
4.03446	Великобритания (GB)	Вниз на 2 позиции	Канада (CA)	3.67367
4.19754	Гонконг (HK)	Вверх на 3 позиции	Франция (FR)	3.68254
4.34753	Украина (UA)	Вниз на 2 позиции	Великобритания (GB)	3.76297
4.39691	США (US)	Вниз на 2 позиции	Бельгия (BE)	3.93768
4.83975	Бельгия (BE)	Вверх на 1 позицию	Украина (UA)	3.95098
5.68121	Испания (ES)	Вниз на 8 позиций	США (US)	3.97103
5.78643	Польша (PL)	Вниз на 6 позиций	Бангладеш (BD)	5.29293
5.99955	Франция (FR)	Вверх на 6 позиций	Румыния (RO)	5.35451
6.00547	Россия (RU)	Вниз 1 на позицию	Бразилия (BR) — новичок	5.39138
6.39252	Австралия (AU)	Вылет из топ-20	Россия (RU)	5.73432
6.88687	Ирландия (IE)	14 место	Ирландия (IE)	5.87254
7.0508	Румыния (RO)	Вверх на 4 позиции	Чехия (CZ) — новичок	5.88389
7.43945	Австрия (AT)	Вниз на 3 позиции	Польша (PL)	5.99655
7.84456	Италия (IT)	Вылет из топ-20	Болгария (BG)	6.20975
7.97141	Бангладеш (BD)	Вверх на 8 позиций	Испания (ES)	6.58064
8.14681	Болгария (BG)	Вверх на 2 позиции	Австрия (AT)	7.14221
8.15989	Филиппины (PH)	Вылет из топ-20	Люксембург (LU) — новичок	7.28208

Как можно видеть, есть несколько перестановок в этом списке, однако в данном случае нельзя говорить, что при разнице в десятых процента есть какое-то принципиальное изменение в качестве. Говоря про топ-20, да и про другие страны, отказ в которых единичного оператора приводит к недоступности не более 10% АС региона (таких стран 29), — все эти страны имеют достаточно диверсифицированный рынок услуг IP-транзита, с большим количеством альтернативных маршрутов.

Отдельно стоит отметить сильное влияние AS 174, оператора Cogent, на целый ряд европейских национальных сегментов: Францию, Великобританию, США, Ирландию только в топ-20 устойчивых регионов. То есть возникновение проблем в автономной системе 174 может привести к проблемам в группе соседних регионов. Хотя и не полной недоступности, так как мы говорим о хорошо развитых и активно децентрализованных национальных сетях.

В России сюрпризов не наблюдается. Системообразующим оператором остаётся Ростелеком, но даже его гипотетический оффлайн выльется в недоступность не более чем у 5,73% российских операторов связи. В то же время, сравнимый с прошлогодним процент отказа обеспечивает России лишь 14-е место в рейтинге. На территории России практически отсутствуют сети международных Tier-1 операторов, однако внутренний рынок представлен целым набором крупных и средних Tier-2 сетей, что и обеспечивает столь высокую устойчивость.

Всегда ли наибольшее влияние на доступность других операторов оказывает влияние крупнейший оператор региона? Как показывают наши расчеты — не обязательно. К примеру, в Германии крупнейшим оператором связи является Deutsche Telecom, однако с точки зрения глобальной связности именно отказ AS8881, принадлежащей Versatel, окажет наибольшее влияние на АС в регионе. И по нашей оценке, тренд к повышению значимости Tier-2 операторов сохранится в ближайшем будущем.

Говоря про общемировые тренды, средняя «неустойчивость» в 2017 составила 41%, что на 1.6% ниже, чем годом ранее.


Градиентом от тёмно-зелёного (0%), через жёлтый (25%) к красному (50%) цвету, обозначающему степень зависимости сегмента от единственного поставщика.

Наибольшие положительные изменения за год произошли на территории развивающегося рынка Африки. Так, устойчивость в нескольких странах региона, включая Гамбию и Либерию, возросла практически на 40%. Однако движение в сторону повышения устойчивости национальных сегментов нельзя назвать однонаправленным. Например, зависимость национального сегмента Ямайки к отказу единичного оператора возросла с 34% до 91%, внешняя связность этой страны теперь практически полностью зависит от работы АС 23520 (Columbus Networks).


Регионы с 99% и более зависимостью от единственного поставщика.

В самом низу нашего рейтинга 10 территорий, которые в случае отказа единичного оператора/автономной системы испытают 100% недоступность с точки зрения всего остального мира. Из стран постсоветского пространства к ним наиболее всего близок Узбекистан, располагающийся на 235 месте со значением в 99,94% недоступности вследствие отказа AS 28910. Остальные же страны представляют собой островные микрогосударства.

Помимо уже упомянутых стран, Куба и Южный Судан являются наиболее известными читателю странами с более чем 99% зависимостью от одного провайдера связи. У Северной Кореи 92%. Любопытно, что Монако обладает очень плохой связностью (единственная красная точка в Европе), при этом другое микрогосударство, Люксембург, замыкает топ-20 устойчивых стран 2017 года.

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

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

https://habrahabr.ru/post/332844/

По роду своей деятельности мне достаточно часто приходится участвовать в проектах, в которых создаются высокодоступные, высокопроизводительные системы для различных рынков — реклама, финтех, сервисы классов SaaS, PaaS. В таких системах применяется вполне устоявшийся набор архитектур и компонентов, которые позволяют эффективно обеспечить соответствие продукта требованиям, например, lambda-архитектура для поточной обработки данных, масштабируемый микросервисный дизайн программного обеспечения, ориентированный на горизонтальное масштабирование, noSQL СУБД (Redis, Aerospike, Cassandra, MongoDB), брокеры сообщений (Kafka, RabbitMQ), распределенные серверы координации и обнаружения (Apache Zookeeper, Consul). Такие базовые инфраструктурные блоки чаще всего позволяют успешно решить большую часть задач и команда разработки не сталкивается с задачами разработки компонентов среднего уровня (middleware), которые, в свою очередь, будут использованы бизнес-ориентированной частью разрабатываемой системы.

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

Задача

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

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

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

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

Если внимательно посмотреть на вводное изображение с Риком, Морти и Саммер, то можно как раз это и заметить… Все вроде похоже, но уже есть небольшие рассогласования.

Нам требовалось разработать реплицируемую систему типа Leader/Followers, каждый узел которой бы поддерживал актуальное состояние объектов в RocksDB, а при потере узла его можно было бы легко восстановить из другого узла и существующего журнала операций, абстрактный вид представлен на диаграмме:

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

Распределенный реплицируемый журнал операций

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

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

1. Подтверждения завершения операции
2. Гарантии порядка и уникальности данных

В большинстве случаев Apache Kafka будет работать так, как нужно, но при потере пакетов TCP или падении мастера Вы не имеете никаких гарантий, что ваше сообщение не продублируется. Это связано с тем, что сообщения в Kafka отправляются по принципу "fire-and-forget", а клиент не управляет порядком записей на сервере, что логично, поскольку Apache Kafka оптимизирована на пропускную способность.

Однако, начав анализ и обдумывание деталей решения, я обнаружил, что решение уже есть, просто мы о нем не знали. И это — Apache BookKeeper. Более того, он реализован идеологически и технологически практически так, как бы мы это стали делать сами — Apache Zookeeper, Java, Netty (наш проект на Scala, но стек Java сильно порадовал). Как результат, была инициирована новая фаза, в ходе которой мы протестировали Apache BookKeeper на предмет соответствия нашим потребностям.

Apache BookKeeper

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

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

• Twitter DistributedLog
• Twitter Manhattan
• Еще известные пользователи

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

Сначала посмотрим на концептуальную архитектуру Apache BookKeeper, которая отображена на следующем рисунке:

Ключевые элементы схемы:

• Bookie — сервер, на котором хранятся данные журналов;
• Ledger — "гроссбух", которые организует некоторое количество записей в единый том, в рамках которого определяются серверы Bookie, на которые происходит репликация данных;
• Ledger Entry — запись в гроссбухе, полезная информация;
• BK Client — клиентский код на Java, который реализует API;
• Zookeeper — сервер Apache Zookeeper, который хранит в себе записи о гроссбухах (номер, серверы Bookie, где хранятся реплики).

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

Bookie

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

Ledger / Гроссбух

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

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

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

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

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

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

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

Хранение идентификаторов гроссбухов

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

Надо отметить, что сам Apache Zookeeper накладывает дополнительные ограничения, которые тоже необходимо учесть:

1. Вся база данных должна помещаться в памяти сервера (если открывать много гроссбухов и не удалять их), вполне возможно, что когда-нибудь на сервере не хватит RAM (маловероятно, конечно, но списывать со счетов данный факт не стоит).
2. Если в родительском каталоге Zookeeper находится много элементов, то при получении листинга каталога может произойти ошибка, если он не поместится в максимальный размер пакета Zookeeper равный 1MB.

Создатели Apache BookKeeper предоставляют решение для проблемы 2, вводя иерархический менеджер гроссбухов (Hierarchical Ledger Manager), который организует плоское пространство идентификаторов в иерархическое дерево путем дробления Long по уровням. По умолчанию используется Flat Ledger Manager, который явно неприменим при частом порождении новых гроссбухов.

Ledger Entry / Запись

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

Пожалуй, эти три концепта — Bookie, Ledger (гроссбух) и Ledger Entry (запись) являются важнейшими элементами для понимания работы Apache BookKeeper.

Вместо заключения

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

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

О RocksDB

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

https://habrahabr.ru/post/332686/

Superjob приглашает на PHP-meetup. Встречаемся 20 июля в нашем офисе на Малой Дмитровке.

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



Спикеры:

Антон Довгаль, Senior C Developer Badoo, с докладом «Как мы разрабатываем модули в Badoo»

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

— Что такое модули PHP, как они работают
— Как начать писать свой модуль PHP
— Скелет модуля — Функции, классы, методы
— Разбор параметров функции
— Сборка модуля
— Подгрузка модуля
— Простой пример модуля из Badoo
— Сложный пример модуля из Badoo

Алексей Коротин, старший разработчик Superjob, с докладом «Внедрение RESTful в mature проект»

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

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

Надежда Рябцова, Senior DevOps Engineer Skyeng, с докладом «Как медиа сервисы Skyeng переехали на Symfony 4»

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

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

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

В день мероприятия возьмите с собой паспорт или водительское удостоверение для прохода в наш бизнес-центр.

Отчеты с предыдущих митапов можно найти в официальной группе Superjob IT-meetup в Facebook.

https://habrahabr.ru/post/332834/

Можно ли доверить защиту системы и сети встроенному в#nbsp;Windows приложению Defender? Раньше мы считали, что это промежуточное звено, которое обеспечит хоть какой-то уровень защиты, пока вы не поставите нормальное решение. В новом пакете обновлений для Windows 10 — Fall Creators Update, — корпоративные клиенты увидят совсем новый Defender, с мощной защитой, а главное — с единой централизованной системой мониторинга и реагирования на угрозы для сети предприятия и рабочих систем. О том, какие нововведения и схемы борьбы с вирусными атаками сейчас наиболее актуальны, мы поговорили с директором по управлению корпоративными программами и безопасности Microsoft Робом Леффертсом. Читать далее

https://habrahabr.ru/post/332510/

Кому нужен VPN?

На март 2017 г. доля вакансий о работе с удаленным доступом, размещенных на hh.ru составляла 1,5% или 13 339 вакансий. За год их число удвоилось. В 2014 г. численность удаленных сотрудников оценивалась в 600 тыс. чел или 1% от экономически-активного населения (15–69 лет). J'son & Partners Consulting прогнозирует, что к 2018 г. около 20% всех занятых россиян будут работать удаленно. Например, до конца 2017 г. Билайн планирует перевести на удаленное сотрудничество от 50% до 70% персонала.
Зачем компании переводят сотрудников на удаленку:

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

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

Путь выбора идеального VPN решения

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

VPN в роутерах

Так называемых “китайских решений” на рынке много. Практически любой роутер имеет функциональность встроенного VPN сервера. Обычно это простое вкл/выкл функционала и добавление логинов паролей для пользователей, иногда интеграция с Radius сервером. Почему мы не стали рассматривать подобное решение? Мы прежде всего думаем о своей безопасности и непрерывности работе сервиса. Подобные же железки не могут похвастаться ни надежной защитой (прошивки выходят обычно очень редко, или не выходят в принципе), да и надежность работы оставляет желать лучшего.

VPN Enterprise класса

Если посмотреть на квадрат Гартнера то на VPN рынке уже давно лидирующие позиции занимают компании, которые производят сетевое оборудование. Juniper, Cisco, Check Point: все они имеют комплексные решения решения в составе которых есть и VPN сервис.

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

Microsoft VPN

10 лет назад мы были компанией, ориентированной прежде всего на Windows. Microsoft предлагает бесплатное решение для тех, у кого вся инфраструктура построена на их базе. В простых случаях настройка не вызывает сложностей даже у начинающего системного администратора. В нашем случае мы хотели выжать из VPN все с точки зрения безопасности, соответственно использование паролей было исключено. Мы естественно хотели использовать сертификаты вместо паролей и для хранения ключевой пары использовать свой продукт Рутокен ЭЦП. Для реализации проекта нам нужно было: контроллер домена, радиус сервер и правильно поднятая и настроенная инфраструктура PKI. Подробно на настройке я останавливаться не буду, в интернете есть достаточно много информации по данным вопросам, а правильная настройка PKI вообще может потянуть на десяток статей. Первым протоколом,

который мы использовали у себя, был протокол PPTP. Долгое время данный вариант VPN нас устраивал, но в конечном итоге нам пришлось отказаться от него по двум причинам: PPTP работал далеко не везде и мы начинали пользоваться не только Windows, но и другими операционными системами. Поэтому мы стали искать альтернативы. Замечу, что поддержка PPTP не так давно была прекращена apple. Для начала мы решили посмотреть, что еще из протоколов может предложить на Microsoft. SSTP/L2TP. SSTP нас устраивал всем, за исключением того, что он работал только на Windows. L2TP данным недостатком не обладал, но его настройка и поддержание его в работе показались нам достаточно затратными и мы решили попробовать альтернативы. Хотелось более простого решения, как для пользователей, так и для администраторов.

OpenVPN

Мы в компании “Актив” искренне любим open source. Выбирая замену Microsoft VPN мы не могли обойти стороной решение OpenVPN. Основным плюсом для нас было то, что решение из коробки работает на всех платформах. Поднять сервер в простом случае достаточно просто. Сейчас, используя docker и, к примеру готовый образ, это можно сделать за несколько минут. Но нам хотелось большего. Нам хотелось добавить в проект интеграцию с Microsoft CA, для того, чтобы использовать выданные ранее сертификаты. Нам хотелось добавить поддержку используемых нами токенов. Как настраивать связку OpenVPN и токены описано к примеру вот в этой статье. Сложнее было настроить интеграцию Microsoft CA и OpenVPN, но в целом тоже вполне реализуемо. Получившимся решением мы пользовались около трех лет, но все это время продолжали искать более удобные варианты. Пожалуй главной возможностью, которую мы получили, перейдя на OpenVPN, был доступ из любой ОС. Но остались еще две претензии: сотрудникам компании нужно пройти 7 кругов ада Microsoft CA для выписывания сертификата, а администраторам по-прежнему приходилось поддерживать достаточно сложную инфраструктуру VPN.

Рутокен VPN

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

Настройка Рутокен VPN

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

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

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

4м шагом настройки мы создаем локальных пользователей, или добавляем их из AD

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

Личный кабинет сотрудника

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

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

После установки плагина/расширения нам остается лишь сгенерировать сертификат себе на Рутокен ЭЦП.

И установить клиент под нужную операционную систему,

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

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

• x86 (Enterprise) – программное решение, которое предоставляется конечному потребителю в виде образа виртуальной машины, который можно развернуть в рамках своей ит-инфраструктуры.

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

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

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

Создание PKI и CA, а также формирование файла конфигурации OpenVPN-сервера, генерацияключей ивыписываниесертификатовосуществляетсяужепослепередачи продукта клиенту. Но это не значит, что для этого необходимо иметь какие-то специфические знания и прямой доступ к операционной системе. Все реализовано в бизнес-логике бэкенда системы администрирования, доступ к которой предоставляется через Web-интерфейс. От клиента требуется только ввести минимальный набор атрибутов (описано выше), после чего стартует процесс инициализации PKI и создания СА. Описывать конкретные вызовы системных команд смысла особого нет, так как уже давно все описано и разжевано до нас. Главное, что мы сделали — это автоматизировали данный процесс, избавив пользователя от необходимости обладать специфическими знаниями в администрировании.
Для работы с ключами и сертификатами мы решили не изобретать велосипед (хотя очень хотелось и до сих пор вынашиваем мысль его изобрести исходя из наших дальнейших планов развития продукта) и используем easy-rsa.
Самый долгий процесс при настройке инфраструктуры – это генерация файла Diffie-Hellman. Мы долго экспериментировали с параметрами и пришли к балансу “качество-производительность”. Хотя были мысли вообще избавиться от данного шага, нагенерировать таких файлов заранее, используя наши серверные мощности и просто “раздавать” их во время первичной инициализации. Тем более, что данные, содержащиеся в этом файле не являются приватными. Но пока мы оставили эти мысли для дальнейших “изысканий”.
Дальше необходимо предоставить конечному пользователю механизм самостоятельного создания ключевых пар, формирования запросов на выписку сертификата в CA и собственно получение данного сертификата с записью на токен. А так же необходим клиент, позволяющий установить VPN-соединение с предварительной аутентификацией на токене.
Первую задачу мы решили благодаря нашему плагину который реализует функциональность электронной подписи, шифрования и двухфакторной аутентификации для Web- и SaaS-сервисов. Для того, чтобы выписать сертификат и записать его на токен, пользователь должен установить данный плагин, перейти по ссылке чтобы попасть в личный кабинет сервиса RutokenVPN, предварительно подключив токен к компьютеру (подробнее о плагине можно прочитать на нашем ресурсе )
При инициализации процесса выписывания сертификата, осуществляется запрос на токен для генерации ключевой пары а также запрос на выписку сертификата в CA. Приватный ключ записывается на токен, а запрос на выписку сертификата отправляется в СА, который в свою очередь осуществляет его выписывание и возвращает в ответе. После чего сертификат так же записывается на токен.
Почти все готово для установления VPN-соединения. Не хватает клиента, который “знает”, как работать с сервером и нашими токенами.

Наш клиент реализован на Electron. Кто не в курсе, что это за зверь, то если совсем кратко – возможность реализовать десктопное приложение, используя js, css и html. Не вдаваясь в подробности, клиент является неким “враппером” над OpenVPN-клиентом, позволяющим осуществлять его вызовы с нужными параметрами. Почему именно так? На самом деле нам было так удобней, хотя выбранное решение и накладывает определенные ограничения.
Так как мы используем токен как носитель ключевой информации, необходимой для аутентификации при установлении VPN-сессии, то нам нужно сконфигурировать OpenVPN-клиент для работы с ним. Провайдером PKCS#11 является библиотека собственной разработки для работы с нашими токенами, путь к которой и прописывается в настройках OpenVPN клиента. Подробнее о ней можно почитать здесь.

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

https://habrahabr.ru/post/332196/

Фотография пользователя Wonderlane, Flickr

NGINX великолепен! Вот только его документация по ограничению скорости показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости (rate-liming) и шейпингу трафика (traffic shaping) в NGINX.

Мы собираемся:

• описать директивы NGINX,
• разобраться с accept/reject-логикой NGINX,
• визуализировать обработку всплесков трафика на различных настройках.

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

Директивы NGINX по ограничению скорости

В этой статье мы будем говорить о ngx_http_limit_req_module, в котором реализованы директивы limit_req_zone, limit_req, limit_req_status и limit_req_level. Они позволяют управлять значением кода состояния HTTP-запроса для отклоненных (rejected) запросов, а также логированием этих отказов.

Чаще всего путаются именно в логике отклонения запроса.

Сначала нужно разобраться с директивой limit_req, которой требуется параметр zone. У него также есть необязательные параметры burst и nodelay.

Здесь используются следующие концепции:

• zone определяет «ведро» (bucket) — разделяемое пространство, в котором считаются входящие запросы. Все запросы, попавшие в одно «ведро», будут посчитаны и обработаны в его разрезе. Этим достигается возможность установки ограничений на основе URL, IP-адресов и т. д.

  
  

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

  
  
• nodelay — также необязательный параметр, который используется совместно с burst. Ниже мы разберемся, зачем он нужен.

Каким образом NGINX принимает решение о принятии или отклонении запроса?

При настройке зоны задается ее скорость. Например, при 300r/m будет принято 300 запросов в минуту, а при 5r/s — 5 запросов в секунду.

Примеры директив:

• limit_req_zone $request_uri zone=zone1:10m rate=300r/m;
• limit_req_zone $request_uri zone=zone2:10m rate=5/s;

Важно понимать, что эти две зоны имеют одинаковые лимиты. С помощью параметра rate NGINX рассчитывает частоту и, соответственно, интервал, после которого можно принять новый запрос. В данном случае NGINX будет использовать алгоритм под названием «дырявое ведро» (leaky bucket).

Для NGINX 300r/m и 5r/s одинаковы: он будет пропускать один запрос каждые 0,2 с. В данном случае NGINX каждые 0,2 секунды будет устанавливать флаг, разрешающий прием запроса. Когда приходит подходящий для этой зоны запрос, NGINX снимает флаг и обрабатывает запрос. Если приходит очередной запрос, а таймер, считающий время между пакетами, еще не сработал, запрос будет отклонен с кодом состояния 503. Если время истекло, а флаг уже установлен в разрешающее прием значение, никаких действий выполнено не будет.

Нужны ли ограничение скорости и шейпинг трафика?

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

Теперь это уже не «дырявое ведро», «маркерная корзина» (token bucket). Параметр rate определяет временной интервал между запросами, но мы имеем дело не с токеном типа true/false, а со счетчиком от 0 до 1 + burst. Счетчик увеличивается каждый раз, когда проходит рассчитанный интервал времени (срабатывает таймер), достигая максимального значения в b+1. Напомню еще раз: burst — это количество запросов, а не скорость их пропускания.

Когда приходит новый запрос, NGINX проверяет доступность токена (счетчик > 0). Если токен недоступен, запрос отклоняется. В противном случае запрос принимается и будет обработан, а токен считается израсходованным (счетчик уменьшается на один).

Хорошо, если есть неизрасходованные burst-токены, NGINX примет запрос. Но когда он его обработает?

Мы установили лимит в 5r/s, при этом NGINX примет запросы сверх нормы, если есть доступные burst-токены, но отложит их обработку таким образом, чтобы выдержать установленную скорость. То есть эти burst-запросы будут обработаны с некоторой задержкой или завершатся по таймауту.

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

Приведем простой пример: скажем, у нас установлен лимит 1r/s и burst равен 3. Что будет, если NGINX получит сразу 5 запросов?

• Первый будет принят и обработан.
• Поскольку разрешено не больше 1+3, один запрос будет сразу отклонен с кодом состояния 503.
• Три оставшихся будут обработаны один за другим, но не мгновенно. NGINX пропустит их со скоростью 1r/s, оставаясь в рамках установленного лимита, а также при условии, что не будут поступать новые запросы, которые также используют квоту. Когда очередь опустеет, счетчик пачки (burst counter) снова начнет увеличиваться (маркерная корзина начнет наполняться).

В случае использования NGINX в качестве прокси-сервера расположенные за ним сервисы будут получать запросы со скоростью 1r/s и ничего не узнают о всплесках трафика, сглаженных прокси-сервером.

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

nodelay

nodelay говорит NGINX, что он должен принимать пакеты в рамках окна, определенного значением burst, и сразу их обрабатывать (так же как и обычные запросы).

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

Визуализация ограничений скорости

Поскольку я верю, что практика очень помогает в запоминании чего бы то ни было, я сделал небольшой Docker-образ с NGINX на борту. Там настроены ресурсы, для которых реализованы различные варианты ограничения скорости: с базовым ограничением, с ограничением скорости, использующим burst, а также с burst и nodelay. Давайте посмотрим, как они работают.

Здесь используется довольно простая конфигурация NGINX (она также есть в Docker-образе, ссылку на который можно найти в конце статьи):

limit_req_zone $request_uri zone=by_uri:10m rate=30r/m;

server {
    listen 80;

    location /by-uri/burst0 {
        limit_req zone=by_uri;
        try_files $uri /index.html;
    }

    location /by-uri/burst5 {
        limit_req zone=by_uri burst=5;
        try_files $uri /index.html;
    }

    location /by-uri/burst5_nodelay {
        limit_req zone=by_uri burst=5 nodelay;
        try_files $uri /index.html;
    }
}

Тестовая конфигурация NGINX с различными вариантами ограничения скорости

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

Давайте выясним вот что:

• сколько запросов будет отклонено из-за ограничения скорости?
• какова скорость обработки принятых запросов?

Делаем 10 параллельных запросов к ресурсу с ограничением скорости

10 одновременных запросов к ресурсу с ограничением скорости

В нашей конфигурации разрешено 30 запросов в минуту. Но в данном случае 9 из 10 будут отклонены. Если вы внимательно читали предыдущие разделы, такое поведение NGINX не станет для вас неожиданностью: 30r/m значит, что проходить будет только один запрос в 2 секунды. В нашем примере 10 запросов приходят одновременно, один пропускается, а остальные девять отклоняются, поскольку NGINX они видны до того, как сработает таймер, разрешающий следующий запрос.

Я переживу небольшие всплески запросов к клиентам/конечным точкам

Хорошо! Тогда добавим аргумент burst=5, который позволит NGINX пропускать небольшие всплески запросов к данной конечной точке зоны с ограничением скорости:

10 одновременных запросов к ресурсу с аргументом burst=5

Что здесь произошло? Как и следовало ожидать, с аргументом burst было принято 5 дополнительных запросов, и мы улучшили отношение принятых запросов к общему их числу с 1/10 до 6/10 (остальные были отклонены). Здесь хорошо видно, как NGINX обновляет токен и обрабатывает принятые запросы — исходящая скорость ограничена 30r/m, что равняется одному запросу каждые 2 секунды.

Ответ на первый запрос возвращается через 0,2 секунды. Таймер срабатывает через 2 секунды, один из ожидающих запросов обрабатывается, и клиенту приходит ответ. Общее время, затраченное на дорогу туда и обратно, составило 2,02 секунды. Спустя еще 2 секунды снова срабатывает таймер, давая возможность обработать очередной запрос, который возвращается с общим временем в пути, равным 4,02 секунды. И так далее и тому подобное…

Таким образом, аргумент burst позволяет превратить систему ограничения скорости NGINX из простого порогового фильтра в шейпер трафика.

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

В этом случае может оказаться полезным аргумент nodelay. Давайте пошлем те же самые 10 запросов конечной точке с настройкой burst=5 nodelay:

10 одновременных запросов к ресурсу с аргументом burst=5 nodelay

Как и ожидалось с burst=5, у нас останется такое же соотношение 200-х и 503-х кодов состояния. Но исходящая скорость теперь не ограничена одним запросом каждые 2 секунды. Пока доступны burst-токены, входящие запросы будут приниматься и тут же обрабатываться. Скорость срабатывания таймера все так же важна с точки зрения пополнения количества burst-токенов, но на принятые запросы задержка теперь не распространяется.

Замечание. В данном случае zone использует $request_uri, но все последующие тесты работают точно так же и для опции binary_remote_addr, при которой скорость ограничивается по IP-адресу клиента. У вас будет возможность поиграть с этими настройками, используя специально для этого подготовленный Docker-образ.

Подведем итоги

Попробуем визуализировать то, как NGINX принимает входящие запросы и обрабатывает их на основе параметров rate, burst и nodelay.

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

Вот трафик, который мы будем прогонять через разные настройки ограничения скорости:

Входящие запросы и ограничение скорости, заданное для зоны

Принятые и отклоненные запросы (настройка burst не задана)

Без burst (то есть при burst=0) NGINX выполняет функцию ограничителя скорости. Запросы либо сразу обрабатываются, либо сразу отклоняются.

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

Принятые, принятые с задержкой и отклоненные запросы (с использованием burst)

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

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

Принятые, обработанные и отклоненные запросы (burst используется с nodelay)

Поиграйте с ограничением скорости

Теперь, чтобы лучше закрепить понимание изложенных концепций, вы можете изучить код, скопировать репозиторий и поэкспериментировать с подготовленным Docker-образом: https://github.com/sportebois/nginx-rate-limit-sandbox.

Ссылки:

1. Оригинал: NGINX rate-limiting in a nutshell.

https://habrahabr.ru/post/329876/

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

Очень длинная статья содержит обзор подходов, методов и результатов исследований вовлеченности пользователей мобильных приложений. В ней не будет простых и быстрых «топ-10» советов по гарантированному повышению DAU, MAU, ARPU и др. Вместо этого, попробуем разобрать виды вовлеченности и прийти к пониманию, что и когда лучше измерять, а что измерять не имеет смысла. Сложные моменты разберем «на пальцах». В дополнение посмотрим на несколько переведенных методик измерения вовлеченности из научных рецензируемых журналов.

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

Я решила вынести выводы в начало.

Самые короткие выводы из статьи
1. Что хотите исследовать?
1) Как пользователь относится к продукту/бренду: исследуйте маркетинговую вовлеченность.
2) Насколько пользователь вовлекается в использование приложения: исследуйте пользовательскую вовлеченность.
2. Как определяют вовлеченность: Таблица 1.
3. Через что исследуют вовлеченность: Таблица 2.
4. Как измерять уровни вовлеченности: Таблица 3.
5. Что исследовать для разных типов приложений и вовлеченности: Таблица 4.
6. Как выбрать метод на разных стадиях развития продукта: Таблица 6.
7. Какие анкеты используют исследователи: см. Приложения.

А теперь, я напишу, как это все появилось.

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

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

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

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

1. Что такое вовлеченность

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

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

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

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

Часто в исследованиях понятие вовлеченности сужается только до эмоций, которые испытывает пользователь по отношению к продукту, или бренду компании. Иногда речь ведется только об исследовании реальных поступков пользователей. В исследовании вовлеченности игроков упоминается погруженность, психологическая поглощенность, состояние потокаи диссоциация [21]. В обзоре M. Lamas с соавторами перечислены подходы к исследованию вовлеченности через анализ позитивных эмоций, сфокусированного внимания, достижимости и контроля, новизны и др. [1] Я нашла несколько определений, сделала посильный перевод и прилагаю оригиналы. Если у вас будут рекомендации по улучшению перевода здесь и далее, буду рада им в комментариях.

Таблица 1. Варианты определений пользовательской вовлеченности.


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

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

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

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

Разберем на пальцах.


Рисунок 1. Виды вовлеченности на пальцах.

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

2. Как операционализируется вовлеченность

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


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

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

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

В обзоре M. Lamas перечислены такие способы операционализации вовлеченности [1]:
1. Сфокусированное внимание. Для вовлечения пользователи должны быть максимально сфокусированы. Для измерения сфокусированности и вовлеченности используются нарушения в субъективном восприятии времени.
2. Позитивные эмоции. Эмоции, переживаемые пользователем, являются внутренними мотиваторами. Эмоциональный «крючок» может вызвать желание разобраться в приложении и участвовать в предлагаемых активностях.
3. Эстетика. Сенсорное, визуальное оформление интерфейса стимулируют пользователя и приводит к фокусировке внимания.
4. Долговечность. Люди запоминают приятный и полезный опыт и хотят его повторить. Характеристика выражается в готовности людей порекомендовать продукт другим людям.
5. Новизна. Характеристика касается любопытства пользователей, тяги к новизне, необычности. Новизна пробуждает любопытство и провоцирует повторяющееся вовлечение.
6. Доступность и контроль. Доступность обеспечивает рост активности пользователей, а контроль отвечает за то, какого уровня активности могут достичь пользователи.
7. Репутация, доверие и ожидания. Доверие – необходимое условие для вовлечения пользователей. Существует негласный контракт между пользователями и продуктами, который выходит за рамки технологических требований.
8. Мотивация, интересы, стимулы и награды.

2. Вовлеченность как метрика продукта.
Здесь никто не копается в мотивах и состояниях пользователей. Оценивается только их поведение по отношению к продукту (количество новых пользователей, DAU, WAU, MAU, возвраты, «stiсky factor» и др.).

Для измерения пользовательской вовлеченности на стороне продукта в 2008 году Forrester описали подход «4I» [цит. по 1].
Вовлечение (Involment). Присутствие пользователя. Измеряется количеством посещений, временем сессий и т.д.
Взаимодействие (Interaction). Активность пользователя. Измеряется CTR, on-line действиями, загружаемыми фото и видео.
Близость (Intimacy). Привлечение, или отвращение пользователя. Измеряется рейтингами удовлетворенности, анализом настроений в блогах, комментариями, опросами.
Влияние (Influence). Вероятность того, что пользователь станет промоутером. Измеряется репостами, количеством приглашений, рассылаемых друзьям.

Компании AppLift и Localytics оценивают вовлеченность по одной метрике: через среднее время, проводимое пользователем в приложении в течение месяца (ASL). Самой большой вовлеченностью, продолжающей расти от года к году, по их оценкам, обладают новостные приложения со средней продолжительностью сессий 6 минут и среднемесячным временем 90 минут (2015 г.). На втором месте оказались развлечения: 8 минут и 77 минут соответственно [2].

Оценка вовлеченности через продолжительность сессий часто встречается и в анализе игр. Например, в недавнем большом исследовании влияния создаваемых разработчиками и пользователями дополнений на вовлеченность игроков (2017) [9]. Но с продолжительностью сессий все не так прозрачно и связано несколько интересных моментов.

2 истории о том, как сбоила продолжительность сессий.

История 1: Отличие usability-эффективности и ux-вовлеченности.
С одной стороны, чем больше пользователю нравится приложение, тем больше времени он в нем проведет. С другой стороны, если пользователю нужно быстро решить задачу, то длительность его работы в приложении, наоборот, будет говорить о неудаче, о том, что он не разобрался с функциями, путается в интерфейсе и др.
Возникает вопрос: в каких случаях для монетизации нужна большая продолжительность сессий, а в каких маленькая? И что делать, например, с приложениями-магазинами: если покупатель проводит много времени в приложении – это хорошо, или плохо? Он вовлечен, или дезориентирован?

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

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

Португалия, 2015 [16].
Гейм-аналитик компании «Miniclip» R. Vladimiro описал ситуацию, когда аналитика игры (гонки) показывала в целом хороший уровень возврата игроков, но его насторожила продолжительность сессий. Он обнаружил 2 группы игроков: первые возвращались в игру по 3-4 раза в день и играли в среднем по 6 минут, вторые приходили в игру в среднем 1 раз в день, но не выходили из приложения часами. Он начал анализировать поведение игроков и понял, что вторые игроки просто пассивно накапливают валюту для обновления автомобиля, но не участвуют в гонках. То есть, в сущности, не играют. В статье он написал, что вовлеченность логично увеличивает удержание, но высокое удержание игроков не обязательно означает их высокую вовлеченность: «Вовлеченность – это удовольствие от игры, а удовольствия не может быть без осмысленного взаимодействия».

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

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

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

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

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


Разберем на пальцах


Рисунок 2. Виды опрационализации на пальцах.

Как это применить к моему приложению?
Теперь я знаю, какими показателями измерить маркетинговую и пользовательскую вовлеченность моего приложения. Раньше я спрашивала: хорошо ли иметь большую продолжительность и частоту сессий? Теперь я могу предположить: если пользователь долго проходит оценку компетенций в моем приложении, он либо увлечен, либо испытывает затруднения. Чтобы это понять, я смогу посмотреть эффективность выполненной задачи (как много пользователей доводят оценку до конца и получают результат). Если он заходит часто, он либо часто проводит собеседования, либо часто тестирует себя и готовится к собеседованиям. Это я смогу оценить по анализу времени дня, в которое пользователь заходит в приложение.

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

4. Уровни вовлеченности

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

Некоторые исследователи не выбирают один концепт вовлеченности, а представляют ее разные виды, как иерархию состояний.
Например, L.C. Vieira и др. (2016), [12] различают уровни:
– вовлечение,
– поглощение,
– погружение.
И только последний уровень – погружение – они считают истинным состоянием потока, называя предыдущие состояниями микро-потока (рис. 3).


Рисунок 3. Уровни вовлеченности и эмоции игроков согласно L.C. Vieira и др. [12].

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

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

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


Еще раз проговорим это на пальцах.

Рисунок 4. Уровни маркетинговой и пользовательской вовлеченности «на пальцах».

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

4. Вовлеченность разных групп пользователей.

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

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

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

США, 2013 [18].
Исследование поведения и удовлетворенности этих групп показало, что длительность использования приложения не связана с большим доходом. Сатисфайеры быстро выбирают и покупают, а максимайзеры могут много раз возвращаться и долго выбирать, но в итоге ничего не купить, или вернуть покупку. Максимайзерами чаще являются люди более молодого возраста, а также люди, имеющие больше денег и больше власти. Кроме того, максимайзеры способны значимо больше времени потратить на возврат покупки и написание негативных отзывов [18].

История 2. Постоянные интроверты.
Связана ли вовлеченность в использование фитнес-устройств с личностными, демографическими и культурными особенностями? Какие сегменты пользователей можно выделять, чтобы тоньше рассматривать аналитику по фитнес-приложениям?

США, 2017 [10].
В исследовании участвовало 700 студентов. Им раздали браслеты Fitbit Charge HR и попросили регулярно надевать браслеты и синхронизировать данные.
Исследователи включили в анализ десятки переменных: пол, раса, образование, родители, социальное положение, психическое здоровье, физические параметры, личностные качества, друзья, сиблинги, даже данные телефонных звонков и политические взгляды и др. Оказалось, что значимую связь с регулярностью использования браслетов имели только личностные качества «Большой пятерки» и измерения самого браслета (продолжительность сна и подвижность).
Оказалось, что больше склонны следовать условиям эксперимента и регулярно носить и синхронизировать девайс люди:
1) интровертированные,
2) менее открытые новому опыту,
3) с более низким уровнем невротизма,
4) дольше спящие,
5) в общем более подвижные.
Авторы объясняют это тем, что экстраверты, готовые пробовать новое, быстро отвлекаются, меняют интересы и забывают надевать браслет. В то же время, низкий невротизм тоже помогает не отвлекаться и не страдать депрессией, тревогой и одиночеством. Люди, которые в общем заинтересованы здоровьем, больше спят и больше двигаются, по мнению авторов, логично чаще надевают браслет.

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

Великобритания, 2017 [8].
A.E. Whitehead и др. опросили 578 взрослых мужчин и женщин. Оказалось, что женщины гораздо реже использовали фитнес-устройства и реже считали, что есть причины для их использования.

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

Россия, 2015 [17].
Самое распространенное деление игроков – на персоны Бартла – показывает существенные различия в метриках вовлеченности в зависимости от типажа игрока. «Cоциальные» игроки проводят меньше всего времени в игре, но больше других приводят в игру друзей (у них высокий social ratio — коэффициент привлечения). Они могут привести «киллеров», которые приносят в игру больше всего денег. На втором месте по тратам «карьеристы». Максимальный «retention 28-го дня» у «исследователей» – они самые преданные, но приносят в игру меньше денег, чем остальные игроки.

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

Разберем на пальцах.

Рисунок 5. Различия в поведении разных типов пользователей «на пальцах».

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

5. Три типа приложений и виды вовлеченности.

Здесь подберемся к модному Jobs-to-be-done и когда-то забытой, но теперь вспоминаемой теории деятельности. После, наконец, поговорим о третьем виде вовлеченности. И разберемся, как разделить все приложения на 3 группы, чтобы понять, какую вовлеченность нужно исследовать.

Чтобы точнее исследовать вовлеченность и верно сегментировать пользователей, нужно понимать, какая деятельность стоит за использованием приложения. Является ли приложение посредником, инструментом для хорошо знакомой пользователю деятельности, или содержит в себе новые цель и мотив деятельности. И здесь довольно хорошо вписывается подход Jobs-to-be-done и, в более широком смысле, деятельностный подход и теория деятельности А. Леонтьева.

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

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

Таблица 4. Типы приложений и вовлеченности.


Разберем типы приложений на пальцах.


Рисунок 6. Типы приложений «на пальцах».

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

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

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

Благодаря анализу деятельности моих пользователей и Jobs-to-be-done приложения я начинаю понимать, какие метрики мне стоит ожидать от каждой группы пользователей, а что вовсе не имеет смысла исследовать.
Теперь мне становится интересно, смогу ли я увеличивать не только вовлеченность в бренд, но и вовлеченность в деятельность. Какие механики вовлечения мне применять, чтобы они сработали? Начинаем об этом говорить прямо сейчас.

6. Как связаны вовлеченность в приложение и вовлеченность в деятельность.

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

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

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

Бывает ли повторное вовлечение в деятельность из-за вовлечения в приложение?

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

Вовлечь пользователя в off-line деятельность за счет хорошей стратегии вовлечения в приложение – задача сложная. Скорее всего, она выполнима только для некоторых видов деятельности (вряд ли, казалось бы, пользователь начнет больше ездить только из-за того, что ему удобен навигатор, хотя вовлекающие методы перевозчиков типа Uber и сервисов бронирования типа Booking показывают, что и здесь могут быть варианты).

В исследованиях вовлечения в длительное использование приложений чаще всего используются теории из области психологии взаимоотношений. Одна из них – инвестиционная модель отношений – получила больше всего эмпирических подтверждений (Rusbult, Drigotas, and Verette 1994). По этой модели, вовлеченность в длительные отношения усиливается, если пользователь ощущает:
1) увеличение выгоды от взаимодействия (например, от полезной информации, или развлечения),
2) снижение личных затрат,
3) увеличение личных вложений в систему,
4) уменьшение числа достойных альтернатив.

Когда разрабатывается стратегия повторного вовлечения в деятельность, важно, чтобы механики вовлечения были релевантны деятельности, в которую они вовлекают, и не были формальными. Другими словами, вовлекая в on-line магазин, нужно продумать мотиваторы, связанные непосредственно с покупательской деятельностью, а не с использованием приложения.
Важно, чтобы «внешняя» мотивация приложения не убила «внутреннюю» мотивацию деятельности и не произошло сдвига мотива на цель (термин из теории деятельности).
Один из таких примеров – про игроков, получавших монеты в гоночках, – мы уже обсуждали в разделе 2. Здесь расскажу еще про 2 таких примера, упомянутые в статье A. Weston [11].

Англия, США, 2007.
Исследования эффективности геймификации, проведенные Baker et al. показали, что иногда дети учатся играть в игру, созданную для обучения математике, типа Zombie Division, показывают хорошие успехи в игре, но не начинают лучше разбираться в математике (рис. 2).

Рисунок 2: Кадры из игры Zombie Division (Источник)

США, 2010 [20].
T. Bickmore с соавторами провели лонгитюдные исследования влияния виртуального помощника на вовлеченность пользователей в использование фитнес-сервиса (рис. 3). Каждый день участники должны были вносить в систему количество пройденных шагов и получали обратную связь от виртуальной помощницы Лауры. Для разных экспериментальных групп Лаура либо вступала в коммуникацию, либо была молчаливой, либо вовсе не использовалась в системе. Оказалось, что участники более высоко оценивали качество взаимодействия с разговорчивой Лаурой и были больше к ней привязаны. Но при этом удовлетворенность и вовлеченность в общение с Лаурой не влияла на увеличение количества шагов.
Другое лонгитюдное исследование – с помощницей Карен – должно было показать, насколько вариативность обратной связи влияет на вовлеченность и успешность деятельности (количество шагов). На этот раз исследование показало, что, чем более разнообразными были фразы от Карен, тем больше участники вовлекались в общение с ней, но тем меньше шагов они проходили за день. Здесь уже вовлеченность в сервис снижала вовлеченность в деятельность, ради которой оно было создано [20].

Рисунок 3: Виртуальный помощник из исследований T. Bickmore [20].

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


Рисунок 7. Различия внешней и внутренней мотивации «на пальцах».

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

7. Подходы к измерению вовлеченности

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

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

Когда используют аналитику, говорят об интрасессионном и интерсессионном вовлечении [1]. Первое показывает, насколько долго продукт способен удерживать пользователя во время одного сеанса (продолжительность сессий). Второе оценивается через возвращения пользователя (количество сессий, динамика возвратов) и в конечном итоге может быть измерено через Lifetime value («пожизненная стоимость клиента», размер чистой прибыли, которую компания получает от клиента за все время, которое клиент использует продукт).

Испания, США, 2012 [3].
J. Lehman с коллегами подчеркивали, что в зависимости от назначения ресурса вовлеченность пользователей нужно понимать и измерять по-разному. И не стоит сравнивать едиными метриками вовлеченности ресурсы разной направленности. Они предложили другую классификацию метрик вовлечения. Ее логика хорошо подходит для анализа мобильных приложений:
Популярность (общее количество пользователей, количество визитов, количество кликов).
Активность (количество просмотренных страниц за один визит, время, потраченное за один визит).
Лояльность (количество дней, в течение которых пользователь заходит на сайт, количество визитов, общее время, проведенное на сайте).

Таблица 5. Модели пользовательской вовлеченности для разных видов сервисов (согласно J. Lehman и др.).


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

Литва, 2017 [5].
A. Tarute с соавт. в операционализации разделили вовлеченность на привычные для социальных исследований аспекты анализа (когнитивный, эмоциональный и поведенческий) и добавили социальный аспект.
1. Когнитивный аспект. Проявляет ли пользователь интерес к товару, или бренду?
2. Эмоциональный аспект. Испытывает ли пользователь воодушевление, или гордость от использования продукта, или сопричастности с брендом?
3. Поведенческий аспект. Вероятно ли, что пользователь предпримет какое-то действие навстречу бренду, или товару, сделает покупку и др.
4. Социальный аспект. Взаимодействует ли пользователь с брендом в социальном окружении, вовлекает ли других людей, участвует ли в совместном создании продукта?

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

1. Функциональность (доступный пользователю набор функций: камера, определение месторасположения, мультитач, распознавание голоса, дополненная реальность, виртуальное зеркало, мобильное видео и мобильные платежи и др.).
2. Дизайн (эстетическое оформление приложения, не юзабилити, а эмоции, которые у пользователя вызывает дизайн интерфейса).
3. Взаимодействие с пользователем (контент, генерируемый пользователем, персонализация контента (тегирование), фолловинг, возможность оценить контент, поделиться им и прокомментировать).
4. Качество информации (возможность получить своевременную и релевантную информацию, качественный контент).

Для исследования были случайным образом отобраны активные пользователи мобильных приложений. Средний возраст 25 лет, 42.5% мужчин и 57.5% женщин. Участников просили выбрать мобильное приложение, которое они используют чаще всего, и отвечать на вопросы анкеты, имея в виду это приложение.

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

Большинство участников исследования (61,3%) сообщили, что чаще всего используют мобильные приложения социальных сетей (Facebook Messenger, Instagram, Viber, WhatsApp). Кроме приложений социальных сетей, наиболее используемыми оказались приложения для навигации (Trafi, Busas Kaunas, Here WeGo Maps), банкинга (Swedbank, DNB bank, SEB bank), обучения (Duolingo, Todoist, MyStudyLife) и здоровья (e.g. Endomondo Sports tracker, Noom Walk, WaterDrink). Их называли в 14,1% случаев.

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

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

США, 2013 [4].
Y. H. Kim с соавторами предложили теоретическую модель вовлечения пользователей мобильных устройств (MoEN) (рис. 4).

Рисунок 8: Модель вовлечения пользователей мобильных устройств согласна Y. H. Kim с соавторами.

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

Дополнительно Y. H. Kim и коллеги ввели конструкт мотивации пользователей мобильных устройств и разделили ее на 3 группы:
– функциональная (эффективность, простота использования, экономия времени),
– гедонистическая (радость, наслаждение, приятные эмоции),
– социальная (желание быть связанным и делиться эмоциями и информацией с другими).

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

Для проверки модели исследователи разработали опросник (см. Приложения, №3). В основном исследовании приняли участие 297 студентов (50,3% мужчин и 49,3% женщин). Модель подтвердилась, подробнее: [4].

Испания, 2017 [13].
В этом исследовании снова все параметры – от простоты использования до вовлеченности – измерялись опросником (см. Дополнения, №6). В исследовании участвовало 750 испанских студентов (16–35 лет). Авторы хотели проверить, как бесплатный доступ, простота использования и тип контента влияют на удовлетворенность сервисом. И как удовлетворенность, в свою очередь, влияет на лояльность, вовлеченность, взаимодействие и желание рекомендовать сервис.
Оказалось, что только простота использования была связана с удовлетворенностью. А удовлетворенность оказалась связана с лояльностью и вовлеченностью и – меньше – с желанием рекомендовать и взаимодействием (рис. 9).

Рисунок 9. Модель влияния качеств приложения на удовлетворенность и вовлеченность.

Эксперимент

Италия, 2015 [11].
В исследовании в приложении была запрограммирована функция случайного разделения пользователей на контрольную и экспериментальную группы. Контрольной группе предлагалось пройти тест о здоровом образе жизни в начале и в конце исследования. А экспериментальная группа на время исследования получала доступ к расширенному тесту и push-уведомления на почту, вовлекающие проходить тест и знакомиться с его материалами. И хотя доказательства различий вовлеченности авторы построили только по 2 участникам исследования (из 29), заполнившим равное количество вопросов теста с разной успешностью, их метод экспериментального исследования вовлеченности заслуживает внимания.
Авторы намеренно измеряли вовлеченность двумя способами: 1) вовлеченность в приложение – через количество заполненных вопросов теста и 2) вовлеченность в проблему – через кривую научения (по количеству ошибок в тесте).

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

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

Рисунок 10. Пост моего знакомого о жизни, водке и женщинах.

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

США, 2017 [6].
Д. Леджер и Д. МакКафри провели анализ фитнес-устройств и выделили факторы, которые обеспечивают долгосрочную вовлеченность пользователей. Авторы измеряют вовлеченность просто, как длительность использования устройства, но все же обратили внимание на психологические условия для ее возникновения. Они сравнили устройства по 9 техническим и 3 психологическим условиям создания вовлеченности. По мнению авторов, даже если одно условие не будет соблюдено, вовлечение может не состояться. 3 психологических условия напрямую связаны с назначением устройств и могут быть применимы только к ограниченной группе приложений. Так, для фитнес-устройств психологическими факторами вовлечения являются: формирование привычки, социальная мотивация и подкрепление целей. На картинке представлен результат сравнения 8 устройств.

К сожалению, мне не удалось найти методологию назначения баллов по каждому условию (возможно, это был метод опроса экспертов). Тем не менее, графическое сравнение выглядит любопытно и дополняется подробным описанием каждого условия с примерами (рис. 7). Отчет находится в открытом доступе в Интернете [6].

Рисунок 11. Сравнение фитнес-устройств по фактором долгосрочной вовлеченности пользователей.

США, 2017 [7].
S. Asimakopoulos с коллегами продолжили исследование вовлеченности пользователей фитнес-устройств и обратились к мотивации и теории самодетерминации. Они решили уточнить, как с мотивацией и долгосрочной вовлеченностью связано ощущение самоэффективности пользователей.

Методы:
– заполнение on-line дневников дважды в неделю в течение 4 недель (см. Дополнения, №5),
– опросник самоэффективности «Healthcare Technology Self-efficacy (HTSE)» с 7-ступенчатой шкалой Лайкерта (от «полностью не согласен» до «полностью согласен»),
– участники присылали исследователям фотографии интерфейсов мобильного приложения, которые мотивируют их.

Выборка: 34 пользователя фитнес-трекеров Fitbit и Jawbone. Исследование показало, что на мотивацию пользователей больше всего влияют 3 аспекта: данные, геймификация и контент.

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

Создатели приложений часто все решают сами, а при вопросах об исследовании пользователей ссылаются на высказывания Г. Форда («Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь»), С. Джобса «Создавать продукт, опираясь на фокус-группы, по-настоящему трудно. Чаще всего люди не понимают, что им на самом деле нужно, пока сам им этого не покажешь» и А. Лебедева («Ответ одного дурака с улицы никого не волнует. Но ответы сотни дураков называются результатом исследования фокус-группы и продаются за деньги»).

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

Физиологические измерения
Их логично использовать при исследовании процессной пользовательской вовлеченности, когда речь идет об изменении внимания, интереса, эмоций и др. С одной стороны, физиологические методы дают более объективные, непосредственные данные об изменении состояния игрока. С другой стороны, их применение часто связано с использованием дополнительной измерительной техники, которая может влиять на эти самые эмоции.
Обзор таких методов в исследовании пользователей требует отдельной статьи. А пока, можно посмотреть англоязычные обзоры из списка источников [1, 12, 13].

Португалия, 2017 [21].
Исследователи решили проверить, насколько применимы программы по распознаванию эмоций в изучении вовлеченности игроков компьютерных игр. Оборудованием служила камера, снимающая лицо игрока, и программное обеспечение: скрипт, написанный Ergo VR Laboratory c использованием Affdex SDK для Unity от Affectiva.
Проверка прошла удачно. Распознанные программой эмоции соответствовали тому, что выражали игроки, и хорошо отражали затруднения, которые испытывали некоторые пользователи во время игры (рис. 12).

Рисунок 12. Различия эмоций 2 игроков в одинаковых ситуациях игры.

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

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

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

Я использовала такие стадии развития продукта: Поиск идеи – Оценка прототипа – Оценка MVP (минимально жизнеспособного продукта) – Оценка полной версии – Оценка обновления. А затем отметила, какие методы уместно использовать на каждой стадии развития продукта.

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


Еще раз разберем на пальцах самые распространенные методы исследования.


Рисунок 13. Самые распространенные методы исследования на разных стадиях развития продукта «на пальцах».

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

На случай, если вы пропустили выводы в начале статьи:

Самые короткие выводы из статьи
1. Что хотите исследовать?
1) как пользователь относится к продукту/бренду: исследуйте маркетинговую вовлеченность.
2) насколько пользователь вовлекается в использование приложения: исследуйте пользовательскую вовлеченность.
2. Как определяют вовлеченность: Таблица 1.
3. Через что исследуют вовлеченность: Таблица 2.
4. Как измерять уровни вовлеченности: Таблица 3.
5. Что исследовать для разных типов приложений и вовлеченности: Таблица 4.
6. Как выбрать метод на разных стадиях развития продукта: Таблица 6.
7. Какие анкеты используют исследователи: см. Приложения

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

Полезные источники
1. Measuring user engagement / M. Lamas, H. O’Brien, E. Yom-Tov. – 2013. – Презентация.
2. Media & Entertainment Apps: A World of Engagement [Infographic] / T. Sommer. – 2015.
3. Models of User Engagement / J. Lehmann [et al.] // Lecture Notes in Computer Science. – 2012. – Vol. 7379. – P. 164–175.
4. A study of mobile user engagement (MoEN): Engagement motivations, perceived value, satisfaction, and continued engagement intention / Y. H. Kim, D. J. Kim, K. Wachter // Decision Support Systems. – 2013. – 56. – P. 361–370.
5. Mobile Application Driven Consumer Engagement / A. Tarute, S. Nikou, R. Gatautis // Telematics and Informatics. – 2017.
6. How The Science of Human Behavior Change Offers The Secret to Long-Term Engagement / D. Ledger, D. McCaffrey. – 2014.
7. Motivation and User Engagement in Fitness Tracking: Heuristics for Mobile Healthcare Wearables / S. Asimakopoulos, G. Asimakopoulos, F. Spillers // Informatics. – 2017, 4(1), 5.
8. Mobile Technology Usage Mediates Gender Differences in Physical Activity / Whitehead, A.E. [et al.] // International Journal of Sport Psychology – 2017.
9. If You Let Them Build It, They Will Stay! An Empirical Study of Add-on Content and User Engagement / I. Kanat [et al.] // Hawaii International Conference on System Sciences. – 2017.
10. Exploring Compliance: Observations from a Large Scale Fitbit Study / L. Faust [et al.] // Proc. of Social Sens. – 2017.
11. Measurements of engagement in mobile behavioural interventions? / A. Weston // Digital Health. – 18 — 20 May 2015. – 8 p.
12. Assessment of fun in interactive systems: A survey / L.C. Vieira, F.S. Corr^ea da Silva // Cognitive Systems Research. – 2017.
13. Exploring technology satisfaction: An approach through the flow experience / C. Calvo-Porral, A. Fa'in~a-Med'in, M. Nieto-Mengotti // Computers in Human Behavior. – 2017. – 66. – P. 400–408.
14. The development and evaluation of a survey to measure user engagement / H. L. O'Brien, E. G. Toms // Journal of the american society for information science and technology. – 2010. – № 61. – P. 50–69. 
15. Measuring emotion: The self-assessment manikin and the semantic differential / M.M. Bradley, P.J. Lang // Journal of Behavior Therapy and Experimental Psychiatry. – Vol. 25, Iss. 1. – 1994. – P. 49–59.
16. The Tale of High Retention, Low Engagement Game / R. Vladimiro //https://ongamesndata.wordpress.com/2015/08/04/engagement-101.
17. Психотипы Бартла и балансировка аудитории / Сахнов К. // https://habrahabr.ru/company/mailru/blog/263839/.
18. Maximizers and Satisficers: A Look into Consumer Regret and Dissatisfaction / T. Correia // Poster presented at the McDonough Undergraduate Research Symposium on November 7th, 2013.
19. Lab Testing Beyond Usability: Challenges and Recommendations for Assessing User Experiences / C. Lallemand, V. Koenig // Journal of usability studies. – Vol. 12, Iss. 3. – 2017. – P. 133–154.
20. Maintaining engagement in long-term interventions with relational agents / Bickmore, T., Schulman, D., and Yin, L. // Applied Artificial Intelligence. – 2010. – № 24, 6. – Р. 648–666.
21. Potentialities of a Face Reading Tool to a Digital Game Evaluation and Development: A Preliminary Study / Y. Trindade, F. Rebelo, P. Noriega // Advances in Ergonomics in Design. – 2017. – P. 371–381.

8. Приложения. Несколько переведенных методик.
Не то, чтобы эти методики были образцовыми. Большинство из них, кроме №2, я не стала бы применять без редакции. Размещаю их для знакомства, так как выше мы обсуждали исследования, построенные на их использовании.

1. Шкала оценки эмоций PANAS (Positive and Negative Affect Schedule)
Насколько каждое слово отражает ваши чувства в данный момент (1 = совершенно не отражает; 2 = в малой степени отражает; 3 = умеренно отражает; 4 = довольно точно отражает; 5 = совершенно точно отражает). Пункты рекомендуется давать не по порядку.
Позитивные пункты: заинтересован, взволнован, уверен, чувствую энтузиазм, горд, вдохновлен, активный, внимательный, бдительный, решительный.
Негативные пункты: огорчен, расстроен, чувствую вину, испуган, чувствую враждебность, чувствую стыд, нервничаю, чувствую страх, готов поддаться панике, чувствую раздражение.

2. Методика самооценки эмоций Self-Assessment Manikin (SAM) [15].
Довольно старая методика (1994 г.). Она помогает оценить эмоции визуально. Участник исследования последовательно выбирает по 1 карточке в каждом ряду, чтобы лучше описать эмоцию, которую он испытывает: 1 ряд – модальность эмоции, 2 ряд – уровень возбуждения, 3 ряд – доминирование, сила эмоции. Методика хороша тем, что обходит лингвистические барьеры и позволяет проводить исследования с детьми и представителями разных культур.
При этом, результаты замеров можно кодировать в числовые значения и переводить в количественные измерения, как это сделали авторы методики, сравнивая ее показания с показаниями семантического дифференциала [15].



1. Анкета для измерения вовлеченности пользователей мобильных устройств [4].
Вопросы оце

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

/ Flickr / GotCredit / CC

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

Financial Management для IT-услуг является частью построения стратегии услуг в ITIL и содержит три процесса: бюджетирование, учет и взимание платы.

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

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

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

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

Расчет стоимости сервиса

Согласно книге ITIL Service Delivery, для оценки стоимости сервиса применяются два подхода: учет затрат по центрам затрат и учет затрат по деятельностям или сервисам. В первом случае все затраты распределяются по клиентам, а итоговая общая стоимость делится между ними поровну. Во втором — все затраты распределяются по услугам: если подсчитать все затраты на сервис, можно определить единицу затрат и использовать ее как инструмент для подсчета потребления услуги каждым заказчиком.

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


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

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

Пример расчета IT-сервиса приведен на схеме ниже. Здесь HW — оборудование, SW — программное обеспечение, DB — базы данных, Docs — документы, контракты, лицензии, FTE — выделенные человеческие ресурсы, а LOC — здания.

Расчет затрат на сервис (источник)

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

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

COService = 100%Sla + 50%Ss2 + 20%Sdb + 10%Ss1 + 15%Ssup + 5%Ssd + 5%Snet

В приведенной формуле: Ss1 — стоимость оборудования (Сервер 1), Ss2 — стоимость оборудования (Сервер 2), Sla — стоимость лицензий приложения, Sdb — стоимость лицензий баз данных, Ssup — стоимость поддержки серверов, Ssd — стоимость поддержки SD, Snet — стоимость системного сервиса поддержка сети.

Инструменты для расчета стоимости услуг в ServiceNow

Управление финансами (Financial Management) сделано по типу управления инцидентами, чтобы ИТ-специалистам и менеджерам было удобнее производить операции в привычном интерфейсе. Для расчета стоимости услуг Financial Management в ServiceNow используется несколько процессов. Вот главные из них, для каждого из которых платформа предоставляет готовые инструменты:

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

Бюджетирование в ServiceNow

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


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

Бухгалтерский учет и начисления

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

Ценообразование

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


Совокупность знаний по расчету затрат на сервис и инструменты ServiceNow позволяют IT-подразделению эффективно планировать и использовать бюджет, а также получать высокую прибыль от предоставляемых услуг. Это лишь основные процессы, которые предоставляет Financial Management ServiceNow. Более подробно о его функциях, установке, настройке и использовании вы можете узнать в библиотеке документации ServiceNow или же обратиться к специалистам компании «ИТ Гильдия» — официальному сертифицированному партнеру ServiceNow.

P.S. Еще несколько материалов по теме из блога «ИТ Гильдия»:

• 5 человеческих ресурсов для успешного внедрения ServiceNow
• IT Operations Management – управление ИТ-инфраструктурой
• Как внедрить процесс управления конфигурацией (Configuration Management). Часть 1
• Как внедрить процесс управления конфигурацией (Configuration Management). Часть 2
• Что такое Управление портфелем проектов?

https://habrahabr.ru/post/331380/

Всё началось, как это часто бывает, когда моя машина начала подтормаживать. На рабочем компьютере Windows 10 c 24-ядерным процессором (48 потоков) — и они на 50% простаивали. Из 64 ГБ памяти использовалось меньше половины. Быстрый SSD тоже не особо использовался. И всё же, когда я двигал мышкой, курсор реагировал не сразу — иногда с задержкой в несколько секунд.

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

Трассировка ETW показала, что UI зависает во многих программах. Я решил исследовать 1,125-секундное зависание в Диспетчере задач:



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



Таблица CPU Usage (Precise) показывает, что поток UI Диспетчера задач постоянно блокировался вызовами к функциями вроде SendMessageW, видимо, ожидающих в критической секции ядра (это версия критических секций в режиме ядра), глубоко в стеке вызовов в win32kbase.sys!EnterCrit (не показано здесь):



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

Taskmgr.exe (72392) завис на 1,125 с (MsgCheckDelay) на треде 69,196. Наибольшая задержка была 115,6 мс на win32kbase.sys!EnterCrit, который был подготовлен процессом conhost.exe (16264), тред 2560 на 3.273101862. conhost.exe (16264), 2560 был подготовлен на 3.273077782 после ожидания 115,640.966 мс, процессом mstsc.exe (79392), 71272. mstsc.exe был подготовлен (то же время, та же задержка) процессом TabTip.exe (8284), 8348, который был подготовлен процессом UIforETW.exe (78120), 79584, который был подготовлен процессом conhost.exe (16264), 58696, который был подготовлен процессом gomacc.exe (93668), 59948, который был подготовлен процессом gomacc.exe (95164), 76844.

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

Я устал вручную ходить по этим цепочкам ожидания, так что решил посмотреть, как часто встречается такой же стек вызовов. Я сделал это, перетащив колонку Ready Thread Stack налево и поискав там NtGdiCloseProcess. Затем я использовал опцию View Callers -> By Function в WPA, чтобы отобразить все стеки Ready Thread Stacks, которые встречались с этой функцией — в этом окне родительские стеки внизу.



Произошло 5768 контекстных переключений, когда процесс NtGdiCloseProcess был в стеке Ready Thread Stack, и каждый из них означает момент, когда освобождается критическая секция. Потоки на этих стеках вызовов провели в ожидании в общей сложности 63,3 секунды — неплохо для задержки в 1,125 с! И если каждое из этих событий случилось после того, как поток удержал блокировку всего на 200 микросекунд, то 5768 событий будет достаточно, чтобы сложиться в подвисание на 1,125 с.

Я не знаком с этой частью Windows, но сочетание PspExitThread и NtGdiCloseProcess ясно показывает, что такие поведение наблюдается при завершении процесса.

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

Следующим шагом было найти, сколько времени потрачено внутри NtGdiCloseProcess. Так что я перенёс таблицу CPU Usage (Sampled) в WPA и получил граф «бабочка», на этот раз вызовов NtGdiCloseProcess. На скриншоте внизу показано, что из всего времени 1,125 с около 1085 мс было потрачено внутри процесса NtGdiCloseProcess, то есть 96% всего времени:



Очень плохо, если в случае блокировки более 95% времени отнимает одна функция, особенно, если ту же блокировку нужно получить для вызовв GetMessage или обновления положения курсора. Ради эксперимента я написал тестовую программу, которая с максимальной скоростью создаёт 1000 процессов, ждёт 0,5 секунды, а затем командует всем процессам завершиться одновременно. На скриншоте показано использование этой программой CPU на моём четырёхъядерном (восемь потоков) домашнем ноутбуке:



Итак, что мы видим. Создание процессов ограничено по CPU, как и должно быть. А вот закрытие процессов ограничено по CPU только в начале и в конце, а в середине есть длительный промежуток (около секунды), где оно идёт серийно — используя всего один из восьми доступных потоков в системе, поскольку 1000 процессов борются за единственную блокировку внутри NtGdiCloseProcess. Это серьёзная проблема. Данный промежуток представляет собой время, когда программы зависнут, а движения курсора будут задерживаться — а иногда этот серийный промежуток растягивается на несколько секунд.

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



Если запустить такой же тест на старом компьютере Windows 7 (Intel Core 2 Q8200, образца 2008 года), то вот результаты:



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

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

48 потоков, 47 из них простаивают

Закон Амдала говорит, что если вы распределите свою задачу среди достаточного количества ядер, то суммарное время её выполнения будет равно времени выполнения самого длинного фрагмента, который нельзя распараллелить. Если я интенсивно использовал свой рабочий компьютер в течение нескольких дней, то эта проблема сериализации проявляла себя достаточно явно, когда завершение процессов было значительной частью времени распределённой сборки — и большее количество ядер тут не помогало. Чтобы максимально ускорить сборку (и чтобы курсор начал двигаться во время её проведения), нужно было перезагружать компьютер каждые несколько дней. И даже тогда скорость сборки была не такой высокой, какой должна быть, так что Windows 7 выглядела всё заманчивее.

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

О проблеме сообщили в Microsoft, они проводят расследование.

И ещё кое-что...

Вот как выглядит моя тестовая программа по созданию и завершению процессов на 24-ядерной машине:



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

Материалы

Код ProcessCreateTests доступен здесь.

Если вам понравилась эта статья, вам могут понравиться и другие расследования:

«Твой браузер попал в мой компилятор!»

«Завершение работы Windows: расследование и идентификация» (и продолжение)

«Проблема слабой производительности PowerPoint»

«DoS-атака Visual Studio на саму себя через функцию поиска»

https://habrahabr.ru/post/332816/

https://habrahabr.ru/post/332824/

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

Мы говорили об объектах учета как о 4-х мерных объектах, существующих в пространстве-времени. Для моделирования этих объектов существуют три способа их представления –

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

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

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

Доказательство

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

Сейчас я делаю гипотезу о том, что понятийный аппарат также является продуктом нашего сознания, — результатом обобщения накопленного опыта. До сего момента мы учили машины делать обобщение накопленного опыта в понятийном аппарате, который придуман нами — людьми. И мы видим, что в результате обучения машины начинают легко справляться с теми задачами, с которыми мы справляемся с трудом. При этом понятийный аппарат, в котором машины строят свои выводы, остается человеческим. Но очень скоро мы поставим перед машинами следующую задачу – оптимизировать сам понятийный аппарат. Что это значит? Сознание человека очень ограничено – в поле внимания находится не более 9-15-ти объектов. Машина способна на большее – она способна удержать в поле своего «внимания» миллиарды объектов одновременно. Это значит, что машине может потребоваться другой понятийный аппарат, оптимизированный под ее возможности. Как вы думаете, останутся ли в ее мире статичные объекты, или их заменят новые понятия? На мой взгляд, машине не нужны статичные объекты в качестве понятий, потому что объема внимания у машины много больше. Поэтому статичные объекты как таковые исчезнут. Но можно пойти еще дальше. Сознание человека ограничено не только объемом, но и способом обработки информации. Можно представить себе машину, в которой способ обработки информации будет иным, отличным от нашего способа. Например, квантовый компьютер. Добавляем этот аспект и получаем машину, которая создает понятийный аппарат много сложнее нашего, много продуктивнее и нам совершенно непонятный по причине разной физиологии. Не так страшен ИИ, как его понятийный аппарат. Итак, мы доказали, что существует теоретическая возможность построения другого понятийного аппарата и, следовательно, наш понятийный аппарат не единственно возможный. А из этого следует, что объекты, функции и операции существуют в нашем сознании лишь как результат обобщения накопленного опыта восприятия. Мы могли бы построить невообразимое количество других способов описания нашего восприятия, но остановились на текущем.

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

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

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

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

https://habrahabr.ru/post/332822/

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



При пристальном рассмотрении выяснилось, что ядро всего лишь течет:

$ slabtop
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
441920 441450 99% 1.00K 13810 32 441920K kmalloc-1024
224070 222908 99% 0.19K 5335 42 42680K kmalloc-192
38304 21198 55% 0.19K 912 42 7296K dentry
25602 25133 98% 0.12K 753 34 3012K kernfs_node_cache
19380 19380 100% 0.04K 190 102 760K Acpi-Namespace

$ uname -a
Linux zdtm.openvz.org 4.10.17-200.fc25.x86_64 #1 SMP Mon May 22 18:12:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


“Течёт и течёт, с кем не бывает”, подумали мы и обновились до 4.11. В той части CI у нас стоит Fedora, и тогда это было самое новое её ядро. Загрузили, и уже через пару минут CI нам снова передал привет посредством неработающего netfilter-а — при попытке удалить добавленное правило выдавалась невнятная ошибка:

[root@zdtm ~]# iptables -w -t filter --protocol tcp -A INPUT --dport 12345 -j DROP
[root@zdtm ~]# iptables -w -t filter --protocol tcp -D INPUT --dport 12345 -j DROP
iptables: Bad rule (does a matching rule exist in that chain?).


С помощью iptables CRIU блокирует сеть, чтобы зафиксировать состояние TCP сокетов. Ясно, что с таким багом наш CI работать тоже не мог. Недолго думая, мы собрали и загрузили ядро прямо из дерева Линуса, но и оно проработало недолго — снова потекла память:

[root@zdtm criu]# cat /proc/slabinfo | grep mnt
mnt_cache 36456 36456 384 42 4 : tunables 0 0 0 : slabdata 868 868 0

[root@zdtm criu]# python test/zdtm.py run -t zdtm/static/env00 --iter 10 -f ns
========================= Run zdtm/static/env00 in ns ==========================
Start test
./env00 --pidfile=env00.pid --outfile=env00.out --envname=ENV_00_TEST
Run criu dump
Run criu restore
Run criu dump
....
Run criu restore
Send the 15 signal to 339
Wait for zdtm/static/env00(339) to die for 0.100000
Removing dump/zdtm/static/env00/31
========================= Test zdtm/static/env00 PASS ==========================

[root@zdtm criu]# cat /proc/slabinfo | grep mnt
mnt_cache 36834 36834 384 42 4 : tunables 0 0 0 : slabdata 877 877 0


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

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

[ 699.207570] BUG: Bad page state in process ip6tables-save pfn:1499f4


Времени и желания разбираться уже не оставалось, ограничились письмом в lkml, а в CI загрузили ядро 4.10, у которого было существенное преимущество — оно работало и не падало. Да, оно немного текло, и мы решили перезагружать машину раз в сутки. Кто-то вспомнил о старых добрых временах, когда все подряд перегружали винду, если та начинала тормозить.

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

На этом направлении оборону держал Кирилл Горкунов (отчасти из-за того, что Андрей пошел спать). К утру в lkml развернулась большая дискуссия. Оказалось, что наши коллеги-ядерщики чинили Страшную Уязвимость CVE-2017-1000364 и поломали обратную совместимость пользовательского API. Поломка эта была практически умышленной: без этого код становился намного сложнее, и сообщество, скрепя сердце, решилось на крайние меры. А в силу того, что речь шла о Страшной Уязвимости (нужна картинка windows security model с воротами без забора), изменения не обсуждались публично и были наскоро влиты в ядро. Сразу после этого оказалось, что изменения привнесли в ядро другой баг, который тоже оказался Страшной Уязвимостью, и ещё несколько дней ушло на уже открытые дебаты по новой проблеме.

Возникшая неразбериха сказалась на дистрибутивах. Когда инженеры RedHat и Ubuntu переносили эти изменения в свои ядра, что-то пошло не так, и оба дистрибутива оказались сломанными двумя разными способами. Для нас это тоже было критично, так как часть нашего CI крутится в Travis, а там на выбор предлагается только Ubuntu. Другая часть CI крутится на Fedora, заменить её там на Ubuntu можно ради однородности, но уж конечно не в спешке. Так что в Fedora просто загрузили неродное ядро, его-то должны были уже починить! После установки по привычке сразу посмотрели не течёт ли оно.

unreferenced object 0xffff88006342fa38 (size 1024):
comm "ip", pid 15477, jiffies 4295982857 (age 957.836s)
hex dump (first 32 bytes):
b8 b0 4d a0 ff ff ff ff c0 34 c3 59 00 88 ff ff ..M......4.Y....
04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[ffffffff8190510a] kmemleak_alloc+0x4a/0xa0
[ffffffff81284130] __kmalloc_track_caller+0x150/0x300
[ffffffff812302d0] kmemdup+0x20/0x50
[ffffffffa04d598a] dccp_init_net+0x8a/0x160 [nf_conntrack]
[ffffffffa04cf9f5] nf_ct_l4proto_pernet_register_one+0x25/0x90


Течёт. Необходимые изменения нашлись быстро, по какой-то причине maintainer DCCP не отправил их Линусу, и они затерялись в его дереве. Берём патч (на доклад в рассылку настроения уже нет), перезагружаемся в новое ядро.

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

«Это уже становится однообразным», подумал Андрей, посмотрев на загруженное ядро.

unreferenced object 0xffff9f79442cd980 (size 112):
comm "kworker/1:4", pid 15416, jiffies 4307432421 (age 28687.562s)
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff b8 39 1b 97 ff ff ff ff .........9......
backtrace:
[ffffffff9591d28a] kmemleak_alloc+0x4a/0xa0
[ffffffff95276198] kmem_cache_alloc_node+0x168/0x2a0
[ffffffff95279f28] __kmem_cache_create+0x2b8/0x5c0
[ffffffff9522ff57] create_cache+0xb7/0x1e0
[ffffffff952305f8] memcg_create_kmem_cache+0x118/0x160
[ffffffff9528eaf0] memcg_kmem_cache_create_func+0x20/0x110
[ffffffff950cd6c5] process_one_work+0x205/0x5d0
[ffffffff950cdade] worker_thread+0x4e/0x3a0
[ffffffff950d5169] kthread+0x109/0x140
[ffffffff9592b8fa] ret_from_fork+0x2a/0x40
[ffffffffffffffff] 0xffffffffffffffff
unreferenced object 0xffff9f798a79f540 (size 32)


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

> [22458.504137] BUG: Dentry ffff9f795a08fe60{i=af565f,n=lo} still in
> use (1) [unmount of proc proc]
> [22458.505117] ------------[ cut here ]------------
> [22458.505299] WARNING: CPU: 0 PID: 15036 at fs/dcache.c:1445
…
> [22458.515141] ---[ end trace b37db95b00f941ab ]---
> [22458.519368] VFS: Busy inodes after unmount of proc. Self-destruct
> in 5 seconds. Have a nice day...
> [22458.813846] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000018
…


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

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

Люди, храните деньги в сберегательных кассах работайте только на стабильных ядрах, если конечно, они у вас есть. Обычному Linux ядру сильно не хватает тестирования.

В заключение хочется процитировать Александра Виро, который на ядерном саммите около десяти лет назад сказал: «We're discussing a lot how to encourage people write the kernel code. But I'd like someone to start a discussion about how to encourage people READ this damned thing.»

Авторы: Павел Емельянов, Кирилл Горкунов и Андрей Вагин.

https://habrahabr.ru/post/332740/

https://habrahabr.ru/post/332744/

В мае мы поделились статистикой по самым популярным атакам с отражением. Тогда средний размер атаки SSDP был в районе 12 Гбит/с, а крупнейшая атака SSDP с отражением была такой:

• 30 Мп/с (миллионов пакетов в секунду)
• 80 Гбит/с (миллиардов бит в секунду)
• 940 тыс. IP-адресов для отражения

Всё изменилось пару дней назад, когда мы заметили необычно крупное умножение пакетов SSDP. Это достойно более тщательного расследования, поскольку атака преодолела символический рубеж в 100 Гбит/с.

График пакетов в секунду:



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



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

Отражающие сервера располагались по всему миру, больше всего в Аргентине, России и Китае. Вот уникальные IP-адреса по странам:

$ cat ips-nf-ct.txt|uniq|cut -f 2|sort|uniq -c|sort -nr|head
439126 CN
135783 RU
74825 AR
51222 US
41353 TW
32850 CA
19558 MY
18962 CO
14234 BR
10824 KR
10334 UA
9103 IT
...

Распределение IP-адресов по ASN вполне типично. Оно во многом соотносится с крупнейшими в мире домашними интернет-провайдерами:

$ cat ips-nf-asn.txt |uniq|cut -f 2|sort|uniq -c|sort -nr|head
318405 4837 # CN China Unicom
84781 4134 # CN China Telecom
72301 22927 # AR Telefonica de Argentina
23823 3462 # TW Chunghwa Telecom
19518 6327 # CA Shaw Communications Inc.
19464 4788 # MY TM Net
18809 3816 # CO Colombia Telecomunicaciones
11328 28573 # BR Claro SA
7070 10796 # US Time Warner Cable Internet
6840 8402 # RU OJSC "Vimpelcom"
6604 3269 # IT Telecom Italia
6377 12768 # RU JSC "ER-Telecom Holding"
...

Впрочем, что такое SSDP?

Данная атака состоит из UDP-пакетов с порта 1900. Этот порт используется протоколами SSDP и UPnP. UPnP — один из протоколов Zeroconf (Zero Configuration Networking), которые создают IP-сеть без конфигурации или специальных серверов. Скорее всего, ваши домашние устройства поддерживают его, чтобы их легче было найти с компьютера или телефона. Когда присоединяется новое устройство (вроде вашего ноутбука), оно может опросить локальную сеть на предмет наличия конкретных устройств, таких как интернет-шлюзы, аудиосистемы, телевизоры или принтеры. Подробнее см. сравнение UPnP и Bonjour.

UPnP плохо стандартизирован, но вот выдержка из спецификаций о фрейме M-SEARCH — основном методе обнаружения:

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

Ответы во фрейм M-SEARCH:

Чтобы быть найденным поисковым запросом, устройство должно отправить одноадресный ответ UDP на IP-адрес источника и порт, который прислал сообщение с помощью мультивещания. Ответ требуется, если в поле заголовка ST в запросе M-SEARCH указано “ssdp:all”, “upnp:rootdevice”, “uuid:”, а далее следует UUID, который в точности соответствует UUID устройства, или если запрос M-SEARCH соответствует типу устройства или типу сервиса, поддерживаемому устройством.

Так оно и работает на практике. Например, мой браузер Chrome регулярно опрашивает Smart TV, насколько я понимаю:

$ sudo tcpdump -ni eth0 udp and port 1900 -A
IP 192.168.1.124.53044 > 239.255.255.250.1900: UDP, length 175
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
USER-AGENT: Google Chrome/58.0.3029.110 Windows

Этот фрейм отправляется на IP-адрес для мультивещания. Другие устройства, которые слушают этот адрес и поддерживают специфический многоэкранный тип ST (search-target), должны ответить.

Кроме запросов специфических типов устройств, существует два «общих» типа запросов ST:

• upnp:rootdevice: поиск корневых устройств
• ssdp:all: поиск всех устройств и сервисов UPnP

Для имитации этих запросов вы можете запустить такой скрипт Python (основанный на этой работе):

#!/usr/bin/env python2
import socket  
import sys

dst = "239.255.255.250"  
if len(sys.argv) > 1:  
    dst = sys.argv[1]
st = "upnp:rootdevice"  
if len(sys.argv) > 2:  
    st = sys.argv[2]

msg = [  
    'M-SEARCH * HTTP/1.1',
    'Host:239.255.255.250:1900',
    'ST:%s' % (st,),
    'Man:"ssdp:discover"',
    'MX:1',
    '']

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)  
s.settimeout(10)  
s.sendto('\r\n'.join(msg), (dst, 1900) )

while True:  
    try:
        data, addr = s.recvfrom(32*1024)
    except socket.timeout:
        break
    print "[+] %s\n%s" % (addr, data)

В моей домашней сети отзываются два устройства:

$ python ssdp-query.py
[+] ('192.168.1.71', 1026)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age = 60  
EXT:  
LOCATION: http://192.168.1.71:5200/Printer.xml  
SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.44 06-17-2009  
ST: upnp:rootdevice  
USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice

[+] ('192.168.1.70', 36319)
HTTP/1.1 200 OK  
Location: http://192.168.1.70:49154/MediaRenderer/desc.xml  
Cache-Control: max-age=1800  
Content-Length: 0  
Server: Linux/3.2 UPnP/1.0 Network_Module/1.0 (RX-S601D)  
EXT:  
ST: upnp:rootdevice  
USN: uuid:9ab0c000-f668-11de-9976-000adedd7411::upnp:rootdevice 

Файрвол

Теперь, когда мы понимаем основы SSDP, будет легко понять суть атаки с отражением. На самом деле есть два способа доставки фрейма M-SEARCH:

• который мы показали, через адрес для мультивещания
• напрямую хосту UPnP/SSDP на обычном адресе (одноадресная передача)

Второй метод тоже работает. Мы можем конкретно указать IP-адрес моего принтера:

$ python ssdp-query.py 192.168.1.71
[+] ('192.168.1.71', 1026)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age = 60  
EXT:  
LOCATION: http://192.168.1.71:5200/Printer.xml  
SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.44 06-17-2009  
ST: upnp:rootdevice  
USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice  

Теперь проблема легко понятна: протокол SSDP не проверяет, находится ли отправитель сообщения в той же сети, что и устройство. Оно с радостью ответит на запрос M-SEARCH, который пришёл из интернета. Требуется только чуть неправильная настройка файрвола, когда порт 1900 открыт внешнему миру — и вот идеальная мишень для умножения флуда UDP.

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

$ python ssdp-query.py 100.42.x.x
[+] ('100.42.x.x', 1900)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age=120  
ST: upnp:rootdevice  
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice  
EXT:  
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2  
LOCATION: http://192.168.2.1:40464/rootDesc.xml

Умножение пакетов

Впрочем, самый реальный вред наносит тип ssdp:all ST. Его ответы намного больше по размеру:

$ python ssdp-query.py 100.42.x.x ssdp:all
[+] ('100.42.x.x', 1900)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age=120  
ST: upnp:rootdevice  
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice  
EXT:  
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2  
LOCATION: http://192.168.2.1:40464/rootDesc.xml

[+] ('100.42.x.x', 1900)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age=120  
ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1  
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::urn:schemas-upnp-org:device:InternetGatewayDevice:1  
EXT:  
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2  
LOCATION: http://192.168.2.1:40464/rootDesc.xml

... и ещё 6 ответных пакетов....

В этом конкретном случае единственный пакет SSDP M-SEARCH вызвал 8 пакетов в ответ. Просмотр в tcpdump:

$ sudo tcpdump -ni en7 host 100.42.x.x -ttttt
00:00:00.000000 IP 192.168.1.200.61794 > 100.42.x.x.1900: UDP, length 88
00:00:00.197481 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 227
00:00:00.199634 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 299
00:00:00.202938 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 295
00:00:00.208425 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 275
00:00:00.209496 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 307
00:00:00.212795 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 289
00:00:00.215522 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 291
00:00:00.219190 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 291

Мишень совершила восьмикратное умножение пакетов и 26-кратное умножение трафика. К сожалению, это типичный случай SSDP.

Спуфинг IP

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

Мы опросили IP-адреса рефлекторов, которые использовались в вышеупомянутой атаке на 100 Гбит/с. Оказалось, что из 920 тыс. адресов только 350 тыс. (35%) по прежнему отвечают на пробные запросы SSDP.

Ответившим на пробные запросы мы отправляли, в среднем, 7 пакетов:

$ cat results-first-run.txt|cut -f 1|sort|uniq -c|sed -s 's#^ \+##g'|cut -d " " -f 1| ~/mmhistogram -t "Response packets per IP" -p
Response packets per IP min:1.00 avg:6.99 med=8.00 max:186.00 dev:4.44 count:350337
Response packets per IP:
value |-------------------------------------------------- count
0 | ****************************** 23.29%
1 | **** 3.30%
2 | ** 2.29%
4 |************************************************** 38.73%
8 | ************************************** 29.51%
16 | *** 2.88%
32 | 0.01%
64 | 0.00%
128 | 0.00%

Пакеты с запросами имели размер 110 байт. Пакеты с ответами — в среднем, 321 байт (± 29 байт).

Согласно нашим измерениям, используя тип ssdp:all M-SEARCH, злоумышленник может получить:

• 7-кратное умножение количества пакетов
• 20-кратное умножение трафика

Можно подсчитать, что атака на 43 млн пакетов в секунду и 112 Гбит/с была инициирована с помощью:

• 6,1 млн пакетов в секунду
• канала 5,6 Гбит/с

Другими словами, один хорошо подключенный сервер на 10 Гбит/с, способный на подделку IP, может сгенерировать значительную атаку SSDP.

Подробнее о серверах SSDP

Поскольку мы опросили уязвимые серверы SSDP, мы можем показать самые популярные значения заголовка Server:

104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0
77329 System/1.0 UPnP/1.0 IGD/1.0
66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2
12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0
11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4
10827 miniupnpd/1.0 UPnP/1.0
8070 Linux UPnP/1.0 Huawei-ATP-IGD
7941 TBS/R2 UPnP/1.0 MiniUPnPd/1.4
7546 Net-OS 5.xx UPnP/1.0
6043 LINUX-2.6 UPnP/1.0 MiniUPnPd/1.5
5482 Ubuntu/lucid UPnP/1.0 MiniUPnPd/1.4
4720 AirTies/ASP 1.0 UPnP/1.0 miniupnpd/1.0
4667 Linux/2.6.30.9, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
3334 Fedora/10 UPnP/1.0 MiniUPnPd/1.4
2814 1.0
2044 miniupnpd/1.5 UPnP/1.0
1330 1
1325 Linux/2.6.21.5, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
843 Allegro-Software-RomUpnp/4.07 UPnP/1.0 IGD/1.00
776 Upnp/1.0 UPnP/1.0 IGD/1.00
675 Unspecified, UPnP/1.0, Unspecified
648 WNR2000v5 UPnP/1.0 miniupnpd/1.0
562 MIPS LINUX/2.4 UPnP/1.0 miniupnpd/1.0
518 Fedora/8 UPnP/1.0 miniupnpd/1.0
372 Tenda UPnP/1.0 miniupnpd/1.0
346 Ubuntu/10.10 UPnP/1.0 miniupnpd/1.0
330 MF60/1.0 UPnP/1.0 miniupnpd/1.0
...

Самые популярные значения заголовка ST:

298497 upnp:rootdevice
158442 urn:schemas-upnp-org:device:InternetGatewayDevice:1
151642 urn:schemas-upnp-org:device:WANDevice:1
148593 urn:schemas-upnp-org:device:WANConnectionDevice:1
147461 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
146970 urn:schemas-upnp-org:service:WANIPConnection:1
145602 urn:schemas-upnp-org:service:Layer3Forwarding:1
113453 urn:schemas-upnp-org:service:WANPPPConnection:1
100961 urn:schemas-upnp-org:device:InternetGatewayDevice:
100180 urn:schemas-upnp-org:device:WANDevice:
99017 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:
98112 urn:schemas-upnp-org:device:WANConnectionDevice:
97246 urn:schemas-upnp-org:service:WANPPPConnection:
96259 urn:schemas-upnp-org:service:WANIPConnection:
93987 urn:schemas-upnp-org:service:Layer3Forwarding:
91108 urn:schemas-wifialliance-org:device:WFADevice:
90818 urn:schemas-wifialliance-org:service:WFAWLANConfig:
35511 uuid:IGD{8c80f73f-4ba0-45fa-835d-042505d052be}000000000000
9822 urn:schemas-upnp-org:service:WANEthernetLinkConfig:1
7737 uuid:WAN{84807575-251b-4c02-954b-e8e2ba7216a9}000000000000
6063 urn:schemas-microsoft-com:service:OSInfo:1
...

Уязвимые IP-адреса как будто принадлежат, в основном, домашним маршрутизаторам.

Открытый SSDP — это уязвимость

Само собой понятно, что разрешить входящий трафик 1900/UDP из интернета на ваш домашний принтер или другое устройство — не самая лучшая идея. Эта проблема известна по крайней мере с января 2013 года:

• Уязвимости в безопасности UPnP

Авторы SSDP явно не думали о потенциале UDP как умножителя пакетов. Есть некоторые очевидные рекомендации об использовании SSDP в будущем:

• Авторы SSDP должны ответить, существует ли в реальном мире хоть какая-то возможность использования одноадресных запросов M-SEARCH. Насколько я понимаю, M-SEARCH имеет практический смысл только как многоадресный запрос в локальной сети.
• Поддержку одноадресных запросов M-SEARCH нужно либо отменить, либо ограничить по скорости, как действует ограничение DNS Response Rate Limit.
• Ответы M-SEARCH должны отправляться только получателям в локальной сети. Ответы за пределы локальной сети имеют мало смысла и открывают возможность использования описанной уязвимости.

В то же время мы рекомендуем:

• Сетевые администраторы должны убедиться, что входящий порт 1900/UDP заблокирован на файрволе.
• Интернет-провайдеры никогда не должны разрешать IP-спуфинг в своей сети. Подделка IP-адресов — вот истинная корневая причина проблемы. См. пресловутый BCP38.
• Интернет-провайдеры должны разрешить своим пользователям использовать BGP flowspec для ограничения входящего трафика 1900/UDP, чтобы рассредоточить скопление трафика при крупных атаках SSDP.
• Интернет-провайдеры должны собирать образцы netflow. Это нужно для определения истинного источника атаки. С netflow будет просто ответить на вопросы типа: «Кто из моих клиентов отправлял 6,4 млн пакетов в секунду на порт 1900?» Для соблюдения конфиденциальности мы рекомендуем собирать образцы трафика с максимальным промежутком выборки: 1 из 64 000 пакетов. Этого достаточно для выявления DDoS-атак, и в то же время сохраняется достаточная конфиденциальность отдельных пользовательских сессий.
• Разработчикам не следует выкатывать свои собственные протоколы UDP, не приняв в расчёт проблемы умножения пакетов. UPnP нужно нормально стандартизировать и изучить.
• Конечным пользователям рекомендуется запустить скрипт для сканирования своих сетей на предмет устройств с функцией UPnP и подумать, стоит ли разрешать им выход в интернет.

Более того, мы сделали веб-сайт для онлайновой проверки. Зайдите на него, если хотите узнать, есть ли на вашем публичном IP-адресе уязвимые сервисы SSDP:

• https://badupnp.benjojo.co.uk/

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

Итог

Клиенты Cloudflare полностью защищены от атак SSDP и других атак с умножением класса L3. Эти атаки хорошо отражаются инфраструктурой Cloudflare и не требуют дополнительных действий. Однако увеличение размера SSDP может стать серьёзной проблемой для других пользователей интернета. Мы должны призвать своих интернет-провайдеров запретить IP-спуфинг в своих сетях, включить поддержку BGP flowspec и настроить сбор потока данных в сети (netflow).

Статью подготовили совместно Марек Майковски и Бен Картрайт-Кокс.

https://habrahabr.ru/post/332812/

Всем привет!

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


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

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

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

На данный момент тестирование проводится только на айфонах с iOS версии не ниже 9.2. На других девайсах игра работать пока не будет.

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

Подробности об игре и инструкция по установке будут высланы в пригласительном письме.
Если вы не хотите принимать участие в тестировании, то хотя бы сделайте репост ;-)

https://habrahabr.ru/post/332810/

Все начиналось не так все печально, как случилось уже потом. Мне необходимо было создать одну VM. Зайдя в vCenter создал VM, но при попытке запуска – произошла ошибка. Две других VM (сам vCenter и еще одна) работали без проблем. Поэтому я решил перегрузить vCenter, что собственно и сделал. Через 10 мин при попытке доступа из VmWare client в vCenter – получил ошибку, что соединение не может быть установлено. О как..?! Решили зайти через Web – то же самое – ошибка 503.

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

Консоль доступа – просит логин и пароль. Ввожу логин и пароль – получаю – Login incorrect.

Приехали…( Перепробовал все пароли (и даже тот, который 100% рабочий) – результат нулевой – не могу войти и все тут. Поэтому решаю сбросить пароль от root. Для этого, нам нужно дописать init=/bin/bash в строку загрузки ядра – ничего сложного подумал я и еще раз перегрузил vCenter. Выбираю строку – жму E – ничего не происходит. Читаем внизу текст и видим, что нужно нажать на P… Жму, упс – просит пароль – стандартный vmware из доков не походит. Гуглим еще немного и находит, что пароль может быть последним паролем от root – вбиваю и ура – можно редактировать добавляю init=/bin/bash, далее уже идет классика и описывать не буду.

Тут же проверяю место – и увы… в / и /storage/log – свободно места нет – очищаю место и перегружаюсь в надежде, что все будет ОК.

Проверяю вход в vCenter через 15 мин – результат 0. Захожу через ssh на сервер и смотрю, что из сервисов запущено, а что нет. Для этого использую команду:

service-control –status –all

В результат вижу:

vmware-invsvc (VMware Inventory Service) vmware-rbd-watchdog (VMware vSphere Auto Deploy Waiter) vmware-sps (VMware vSphere Profile-Driven Storage Service) vmware-vdcs (VMware Content Library Service) vmware-vpx-workflow (VMware vCenter Workflow Manager) vmware-vpxd (VMware vCenter Server) vmware-vsan-health (VMware VSAN Health Service) vmware-vsm (VMware vService Manager) vmware-vws (VMware System and Hardware Health Manager) vsphere-client ()

Это сервисы, которые не поднялись. Можно сказать, что почти ничего не поднялось. Пытаюсь поднять vmware-invsvc:

service-control –start vmware-invsvc

В ответ получаю, что сервис не может быть стартован. Изучаю логи:

/var/log/vmware/vmdird/vmdird-syslog.log

и:

/storage/log/vmware/invsvc/ inv-svc.log

В момент запуска service-control –start vmware-invsvc в логах вижу следующее:

2017-07-07T09:50:01.022945+06:00 err vmdird t@140238302082816: VmDirSendLdapResult: Request (96), Error (49), Message (), (0) socket ([3] ip_server:636<-ip_server:46241)
2017-07-07T09:50:01.022955+06:00 err vmdird t@140238302082816: Bind Request Failed ([3] ip_server:636<-ip_server:46241) error 49: Protocol version: 3, Bind DN: «cn=accountname,ou=Domain Controllers,dc=vsphere,dc=local», Method: 128

Что говорит о том, что проблема в пароле, немного погугли нашел решение:
в шелле vCenter запускаем команды:

/usr/lib/vmware-vmdir/bin/vdcadmintool

После запуска на экране будет меню:

==================
Please select:
0. exit
1. Test LDAP connectivity
2. Force start replication cycle
3. Reset account password
4. Set log level and mask
5. Set vmdir state
==================

Выбираем 3 и указываем accountname@vsphere.local, значение accountname – берем из /var/log/vmware/vmdird/vmdird-syslog.log, а именно из строк:

2017-07-07T09:50:01.022955+06:00 err vmdird t@140238302082816: Bind Request Failed ([3] ip_server:636<-ip_server:46241) error 49: Protocol version: 3, Bind DN: «cn=accountname,ou=Domain Controllers,dc=vsphere,dc=local», Method: 128

Утилита сгенерирует Вам новый пароль – записываем его.

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

/opt/likewise/bin/lwregshell

и после: \> пишем:

cd HKEY_THIS_MACHINE\services\vmdir\ — жмем Enter
set_value dcAccountPassword «сгенерированный пароль»
quit

После чего перегружаем vCenter.

После 10 мин ожидания – vCenter запустился и работает стабильно.

https://habrahabr.ru/post/332808/