Нечасто, но с завидной периодичностью на профильных форумах возникал один и тот же вопрос: «как на одном интерфейсе роутера MikroTik получить два IP-адреса с разными MAC?». Обычно этот вопрос остается без ответа, либо вопрошающему отвечают «никак». И действительно, задача нетривиальная. В стандартной конфигурации соблюдается правило «1 интерфейс = 1 MAC». В этой статье я расскажу как обойти это ограничение используя расширенный функционал MikroTik.

Сначала вспомним матчасть RouterBoard. Помимо маршрутизации, устройства MikroTik могут выполнять и коммутацию. Для этого некоторые из них имеют отдельный свитч-чип, а также возможность объединять интерфейсы с помощью программного коммутатора — bridge. Bridge (в русской терминологии «мост») производит коммутацию пакетов за счёт ресурсов процессора устройства. С помощью моста также объединяют между собой разнородные ethernet-образные инетрфейсы — ethernet, wlan, vlan, eoip, vpls.


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

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


Приступим. У нашего подопытного маршрутизатора есть внутренний мост «bridge-local», которому присвоен адрес 192.0.2.1/24 и который является шлюзом для компьютеров локальной сети. Для «bridge-local» администратором назначен MAC D4:CA:6D:C7:11:11 Физический интерфейс Ether2 является одним из подчиненных (slave) портов моста «bridge-local» и непосредственно соединяется с локальной сетью.
Задача: добавить на маршрутизатор адрес из той же IP-подсети, но с другим MAC-адресом. Для примера выбрано сочетание IP 192.0.2.111/24 и MAC: D4:CA:6D:C7:22:22
Поскольку в лоб правило «1 интерфейс = 1 MAC» преодолеть нельзя, мы пойдем в обход. Для начала создадим вспомогательный интерфейс «bridge111» куда навесим дополнительный IP-адрес и MAC:


Теперь разбираемся, что, откуда и куда нужно будет подменять используя мост. Для этого заглянем в описание протокола ARP: ru.wikipedia.org/wiki/ARP#.D0.9F.D1.80.D0.B8.D0.BD.D1.86.D0.B8.D0.BF_.D1.80.D0.B0.D0.B1.D0.BE.D1.82.D1.8B
Очевидно, что нам нужно перехватывать ARP-запросы узлов запрашивающих MAC устройства имеющего IP 192.0.2.111. Для этого в NAT существует отдельный action «arp-reply»:


Попытка выполнить с компьютера команду «ping 192.0.2.111» явного результата не дала, однако при просмотре на компьютере локальной arp-таблицы стало видно сопоставление нового IP-адреса с новым MAC. Получается протокол ARP мы победили.


Переходим к следующему шагу — нам нужно добиться связности по IP. Для этого захватываем пакеты идущие на дополнительную пару MAC+IP:

После этой команды появляется некое подобие связности. Локальная ARP-таблица компьютера содержит две записи — по одной для каждой пары MAC+IP. MAC-адреса в ней различаются, так как мы и хотели. Пинг до адреса 192.0.2.111 и ответы исправно прилетают.
Но давайте посмотрим на принятые пакеты через wireshark:


Мы видим, что echo-ответы идут с MAC-адреса D4:CA:6D:C7:11:11, связанного с первым IP-адресом 192.0.2.1. И хотя связность есть, решение является незаконченным. Нам необходимо также подменять MAC-адреса в исходящих от роутера пакетах, имеющих src-ip 192.0.2.111. Сделаем это:



Вот, теперь пакеты в сети выглядят правильно — имеют правильное сочетание src-IP и src-MAC:


В окошке winbox настроенные правила преобразования выглядят так:


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





Update: добавил результаты теста с включенным и с выключенным Bridge L2-NAT.
Для теста использовался RB951Ui-2HnD с процессором AR9344. Загрузка процессора изменяется незначительно, в пределах погрешности измерительных инструментов. В среднем рост составил 2% на 100M интерфейсе.

L2-NAT выключен:


L2-NAT включён:

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

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

Замысел такой: физически изолированная (air-gapped) сеть заражается зловредом. Как – это давно придумано, и даже реализовано (Stuxnet, например). Флешечку можно подкинуть, диск с зараженным софтом, да мало ли что. Но войти – не значит выйти. Однако же мало найдется объектов с изолированной сетью без системы физической безопасности с камерами наблюдения. А чтобы что-то видеть, когда в помещении выключен свет, нужна подсветка, и большинство камер оснащается массивом ИК-светодиодов. Некоторые из этих камер можно увидеть снаружи, через окно.

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



Заявленные в исследовании параметры канала внушительны, по сравнению с другими способами преодоления воздушного разрыва – скорость 15 бит/c на каждый светодиод (что дает 120 бит/c при обычных для камер восьми светодиодах), дистанция – сотни метров наружу, и километры при передаче внутрь. Бен-гурионские затейники даже придумали, как обойтись без прямой видимости (правда, максимальная дистанция сокращается до десятков метров).



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

Разработан AI для быстрого угадывания паролей

Новость. Исследование. Ученые из Технологического института Стивенса и Нью-йоркского технологического института опубликовали ранние результаты своей работы по применению генеративно-состязательных сетей (Generative adversarial network, GAN) для ускоренного угадывания паролей. Ну то есть более быстрого, чем перебор по заданным вручную правилам, как в Hashcat или John the Ripper.

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

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

Яйцеголовые хакеры, вооружившись TensorFlow 1.2.1, обучали сеть паролями, слитыми за последние 18 месяцев из LinkedIn и RockYou. Та в итоге сгенерила собственные, усовершенствованные правила подбора паролей. Сами по себе они оказались не сказать, что лучше, чем у HashCat, но если их совместить с правилами HashCat, то количество угаданных паролей из тестовой выборки повышалось на 18-24%. Цифры не очень впечатляют, но надо понимать, что на практике выборку можно взять и сильно побольше. То есть уже довольно скоро оценки сложности подбора паролей придется пересматривать – прогресс не остановить.

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

Новость. Исследование. Сколько ни ковыряйся в Microsoft Office, или в его файлах, всегда найдешь какой-нибудь сюрприз. Наши ребята, исследуя целевую атаку Freakyshelly, наткнулись на фишинговую рассылку с файлами OLE2. На первый взгляд, внутри не было ничего вредоносного, ни макросов, ни эксплойтов, ни флеша. А потом нашли ссылки на PHP-скрипты на внешнем хостинге. Открываешь файл в Word, тот лезет по ссылкам – и наружу входят данные по установленному программному обеспечению.



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

Исследователи обнаружили, что хакеры эксплуатируют не полностью документированную фичу MS Office – поле INCLUDEPICTURE в документе. Значение в этом поле всего лишь сообщает Word о том, что к определенным символам в тексте привязана картинка, ссылка на ее расположение должна быть в ASCII. Но кто-то придумал поставить туда хитросоставленный Unicode, и в итоге поле ссылается на определенное смещение в документе, где лежит форма, в дополнительных данных которой есть URL – куда Word и лезет. Помимо Word для Windows, эта фича работает в Microsoft Office для iOS и Android.

Древности

«Subliminal-1487»

Периодически зашифровывает и выводит на экран текст: «LOVE, REMENBER?». Также содержит зашифрованный текст: «N:SUBLIMINAL V1.10 O:^HYSTERIA! D:02OCT89».

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 35.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

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

Зачем нужны кастомные свойства и как они работают?

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

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

Как работают препроцессоры? Вы пишете на каком-то языке, который внешне напоминает CSS, а иногда вообще не напоминает.

@mixin sass
  @if &
    &:hover
      color: tomato
  @else
    a
      color: plum

Потом это компилируется в настоящие стили. Переменные там — это такая сложная автозамена переменных на их значения. Sass, Less, Stylus, PostCSS-плагины — все они работают только так. Эти переменные существуют только в разработке, в браузере их уже нет.

.scss {
  $variable: value;
  color: $variable;
}

Если сравнить такое поведение с JavaScript, то становится очень обидно за CSS. В JS переменные живут прямо в браузере, их можно создавать и менять на лету. Тем не менее такие переменные и другие элементы программирования в CSS-препроцессорах получили огромную популярность. Уже почти не бывает больших проектов без препроцессоров.

К счаcтью нашлись люди, недовольные такими куцыми переменными. После ряда черновиков и вариаций синтаксиса, Таб Аткинс написал спецификацию полноценных CSS-переменных, точнее, кастомных свойств. Эти переменные поддерживаются уже в 70% браузеров по миру и сильно меняют принцип написания стилей.

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

Например, у нас сейчас есть свойство box-shadow, чтобы отбрасывать тень. А раньше его не было, оно появилось первым в браузере Safari в 2008 году. Но появилось не просто так, а как -webkit-box-shadow, с префиксом, начинающимся с дефиса. То есть разработчики движка WebKit придумали своё свойство. Только потом, когда оно стало частью стандарта и появилось в других браузерах, префикс убрали.

.shady {
  -webkit-box-shadow: 0 0 0 4px tomato;
  box-shadow: 0 0 0 4px tomato;
}

Теперь вы тоже можете создавать собственные свойства, только не нужно указывать между дефисами название движка: дефис, дефис, название свойства. Давайте создадим свойство --box-shadow-color и зададим ему значение tomato. Чтобы использовать это значение в коде, нужно передать его в функцию var().

.shady {
  --box-shadow-color: tomato;
  box-shadow: 0 0 0 5px var(--box-shadow-color);
}

Мы сейчас объявили новое свойство, которое потом можно повторно использовать снова и снова. А ещё свойства box-shadow-color никогда не было в природе и чтобы менять тени, например, по наведению, приходилось переписывать box-shadow целиком. А теперь по ховеру можно просто поменять значение переменной. Круто?

.shady {
  --box-shadow-color: tomato;
}
.shady:hover {
  --box-shadow-color: plum;
}

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

.shady {
  font-size: var(--font-size, 12px);
}

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

:root {
  --font-size: 12px;
  --theme-color: tomato;
}

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

@media (min-width: 320px) {
  .shady {
    --font-size: 48px;
  }
}

Кастомные свойства можно использовать даже внутри функции calc(), которая посчитает результат выражения внутри. Уже не очень похоже на привычный CSS, правда? Стоит ли говорить, что все препроцессоры уже умерли от зависти, глядя на такое.

.shady {
  font-size: calc(var(--font-size) * 2);
}

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

element.style.setProperty('--pointer-left', event.clientX);

Дальше в стилях уже можно решить: использовать их в top и left или transform: translate(). И наоборот: значение свойства можно получить в JS с помощью getPropertyValue.

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

Кастомные свойства — это не border-radius, который либо делает красиво, либо нет. Бросаться всё переделывать на них пока рано, вёрстка может сильно поломаться в браузерах, которые их не поддерживают. Но уже пришло время пробовать и уметь.

Видеоверсия

Вопросы можно задавать здесь.

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

Привет! Меня зовут Данила. Я третий год грызу гранит науки в МГТУ им.Н.Э.Баумана на факультете «Программная инженерия». Так сложились звезды, что в этом году я пришел в Parallels в качестве интерна на part-time. Под катом история моей эволюции из стажеров в интерны.

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



Еще на первом курсе наткнулся на информацию о том, что МГТУ им.Баумана сотрудничает с Parallels. Заинтересовался. Подошел к нашему заведующему кафедрой за информацией. Тот рассказал, что по счастливому стечению обстоятельств у нас в университете планируется открытая лекция одного из специалистов компании. Я пришел. На встрече была куча задач, НИРы, НИОКРы и прочее. После лекции познакомился с Алексеем Корякиным. Как оказалось, он выпускник нашего вуза. Разговорились про языки программирования. Помню, как сказал ему, что одну из предложенных задач не имело смысла «питонить». На что Алексей заметил, что настоящему программисту нет разницы на каком языке писать. Я со своей стороны ответил, что хороший программист всегда найдет оптимальный язык для решения поставленной задачи. Так я получил приглашение пройти собеседование в компании.



Пришел на встречу. Познакомились с другими членами команды. Особо технически меня не собеседовали, больше было про soft skills. Спросили, какие языки я пробовал и тд. Не знаю, чем заинтересовал, но в итоге 28 июня у меня был последний экзамен, а 29-го числа я уже был в Parallels в качестве стажера. И меня начали учить…



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



Мешает ли работа учебе? Нет! Во-первых, наверное, мне повезло, поскольку в Бауманке довольно комфортное расписание. Второе, несмотря на то, что part-time – это 20 часов в неделю, Parallels — отличное место для старта. График работы гибкий. Здесь смотрят на то, что ты сделал, а не на то столько времени ты на это потратил. Совмещать работу и учебу просто. Достаточно в выходные посидеть над учебниками. Я еще не работал правда в период сессии, но уверен, что мы сможем найти оптимальное решение. Тем более, что мои менторы сами бывшие выпускники Бауманки.

Жизнь изнутри

Что такое Parallels Desktop я узнал достаточно давно. Однажды увидел запущенную Windows на Mac. Удивился в начале, потом объяснили, что далеко не все Windows-приложения доступны маководам. Помню, как впечатлился параллельной работой двух ОС и эффектным свайп-переключением между системами.



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

От теории к практике

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



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



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

З.Ы. Ну и немного забавных фоточек из офиса. Надеюсь ребята меня за них не линчуют.



Всем сотрудникам Parallels выдают шапочки из фольги.



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



В офисе развит кросс-букинг и прочие полезности.



На двух этажах московского офиса можно найти все что угодно.



Тут хранится корпоративная скатерть-самобранка.



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



Билл Гейтс плохого не посоветует!

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

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



Фонд «Тотальный диктант» начал продвижение акции в феврале — тогда стартовали онлайн-занятия по подготовке и пошли первые публикации в СМИ. Каждый урок смотрели в среднем 13990 человек — конечно, в день диктанта предполагалась еще более значительная нагрузка на сайт. В прошлом году во время диктанта на сервера обрушилась DDoS-атака, из-за которой какое-то время сайт был недоступен. За работоспособность сайта отвечали:

• CMS «1С-Битрикс» (функциональность и интерфейс);
• «Битриксоид» (техническая поддержка);
• «Сервионика» (облачный хостинг);
• научно-технический центр «Атлас» (защита от ботов и DDoS-атак);
• ITSumma (подготовка ИТ-инфраструктуры и серверов);
• Stepik (платформа для онлайн-диктанта).

Подготовка сайта к нагрузке

До старта наших работ проект был размещен на простом виртуальном сервере с такими характеристиками: 2 ядра CPU, 4 Гб оперативной памяти, HDD.

Изначально от команды проекта было предположение, что в день акции на сервер будет поступать 120 RPS, и каждую минуту на сайт будет заходить 1000 посетителей. Чтобы выяснить, сколько RPS сервер сможет выдержать сейчас, и какая конфигурация серверов потребуется для пиковой нагрузки, было проведено нагрузочное тестирование сервера Яндекс.Танком. Итоговая конфигурация основного и резервного серверов выглядела так: 48 ядер CPU, 128 Гб оперативной памяти, 250 Гб SSD.

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

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

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

Изначально новые сервера планировалось разделить, и один сервер сделать как основной, а другой — как резервный, на случай падения основного. Но в ходе проведения нагрузочных тестов для увеличения общей ёмкости системы было решено задействовать резервный сервер для обработки запросов на backend (в нашем случае — php-fpm). Балансировка запросов на backend между основным и резервным серверами осуществлялась с помощью nginx на основном сервере. В качестве общего хранилища сессий был настроен MySQL — «1C-Битрикс» позволяет это сделать без необходимости модификации настроек сервера.

За полторы недели до дня диктанта проект был переключен на новые сервера. Для этого на них сначала была создана полная копия старого сервера — включая все настройки ПО, файлы сайта, базы данных. Сам процесс переключения выглядел так:

1. Настроили репликацию БД и синхронизацию файлов проекта со старого сервера на новый.
2. В момент переключения включили проксирование всех запросов со старого сервера на новый с помощью nginx.
3. Отключили репликацию БД.

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

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

Нагрузка в день акции

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



Стартовал диктант 8 апреля 2017 года в 15:00 по Владивостоку (GMT +10). На старте нагрузка была минимальной — порядка 20 запросов в секунду на динамику. Но расслабляться, конечно же, не стоило. К самой крупной трансляции, последней, в 14:00 Мск мы выделили больше памяти под кеширование в Memcache, вынесли туда же сессии, чтобы меньше была нагрузка на диски. Трансляция прошла без каких-либо зафиксированных проблем, нагрузка была контролируемой, работало всё быстро, корректно.



Вот как выглядела картина нагрузок в тот день (время на графиках иркутское, GMT +8).

Общий итог

Все старались! Данные по мониторингам нагрузок мы передали коллегам из «Тотального диктанта» для составления плана на будущий год.



8 апреля в интернете следили за акцией 90000 зрителей, написали диктант онлайн 23000 человек. С 9 по 18 апреля сайт посетили 454798 уникальных пользователей, которые просмотрели четыре миллиона страниц — участники узнавали свои оценки и смотрели вебинары с разбором ошибок. Подготовку к диктанту 14 апреля 2018 года организаторы уже начали — подтягивайтесь тоже (повторяйте правила русского языка на онлайн-курсах), всем диктант!

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

Совершенно случайно мы в ЛАНИТ узнали об ИТ-чемпионате Гонки Героев на военном полигоне «Алабино» и решили в ней участвовать. В нашей команде из десяти бойцов только трое раньше участвовали в подобных соревнованиях. Остальные слабо представляли себе, что это такое. Некоторые, как показали дальнейшие события, совсем-совсем слабо представляли, что их ждет!  

Изматывающий забег с кучей сложнейших препятствий. Грязь по пояс, холодная вода, высокие заборы, рукоходы, танки, колючая проволока… Травмы (у двоих свело ногу, один отбил колено) и резкий упадок сил … Все это было — но не имело никакого значения на трассе: мы не останавливались, дышали в спину конкурентам и «съедали» их одного за другим!

Наша команда, наверное, не была самой сильной физически, но она точно была сильна духом! Итог — сразу третье место в нашей первой Гонке Героев!

Ниже смотрите фотоотчет, как это было.



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

До старта всего неделя. У организаторов все готово — буклеты, манишки и т.д. У нас же — пока ничего. Но для нашего всемогущего PR-менеджера Ксении это не трудности. Она быстро со всеми договорилась, и вот за день до старта все вопросы решены — мы в полном обмундировании и воодушевлении готовы к участию!


Всего в ИТ-чемпионате участвовало 8 команд. В каждой команде — по 10 человек. Помимо команды ЛАНИТ в соревнованиях  приняли участие команды Касперского (3 взвода), Group-IB, SEGMENTO, ITelligence, ООО «КаргоОнлйн Лаб». Остальные, видимо, испугались и сразу сдались ;-).

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

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

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

Там мы знакомимся с нашим инструктором Александром. Он сразу намекает на 2 млн долларов в обмен на помощь в прохождении трассы. Уффф… Пришлось бежать по-честному.

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

Перед стартом последние наставления и предложение передумать пока не поздно…

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

Ну ладно, забыли… Дальше все уже будет нормально.

Приходится цепляться всеми частями тела. В водичку как-то совсем неохота.

Дальше нужно пролезть метров 20 под колючей проволокой. Вокруг кто-то палит из калашей или что там у них.

Препятствия не становятся ниже.

Вылезли из очередной лужи. Есть 5 секунд на фотографию.


И вперед! Вперед! Вперед за победой! Отдохнем на пенсии!

Это вам не в танчики за компом всю ночь тупить!

Греем самые важные части тела.

Опять лезть и опять чуть что — в воду! За пропущенное препятствие — штраф 1 балл, поэтому все стараются, как только могут.

Препятствия нельзя пропускать. Одному трудновато, а вот в команде — самое то.

Отряд бойцов рвется вперед.

Еще одна возможность искупаться в прохладной водичке.

А нам как раз туда и нужно.

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


Это наше самое любимое препятствие.

Тимур: «Опять вода! Да сколько ж ещё её будет!»

Высота взята.


И опять вперед! Покой нам только снится.

Опять работа, работа… впереди конкуренты, надо их доставать. Инструктор Саша тем временем позирует вдалеке — вот кому весело.

Мама и дочка бодро преодолевают препятствия. Наверное, участие двух поколений — это беспрецедентный случай в Гонке Героев.

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

Половина пути пройдена. Вроде бы никого не потеряли.

Алексей познакомился с двумя девушками и галантно ведет обеих под руку во время легкой прогулки по парку.

В кадр как-то попали ноги нашего фотографа.

Фантазия организаторов не знает границ. Неизменна только грязь.

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

Может показаться, что Женя отдыхает, но это не совсем так. Он рождается заново (так называется препятствие).


Бедные наши ноги. Почему я с утра не делаю растяжку?

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


Штурмуем «Эверест».

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


Алексей: «Какого… я туда залезть не могу?»

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


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

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

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

Общая фотография со всеми победителями и призерами. Две команды Касперского, занявшие первое и второе места, — очень крутые и большие молодцы!

Вот наша трасса и калории, потраченные нашим фотографом.

Более 1500 фотографий и видео. Вся трасса вместе с нами. Спасибо тебе, фотограф Олеся!

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

наступая в лужу
знай что впереди
будет только хуже
а теперь иди
(отсюда)

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

Продолжаем рассказывать о самом интересном на VMworld 2017 Europe. Если вы пропустили предыдущие репортажи, то можете прочитать сначала про нулевой и первый день конференции.

Анонсы VMware на конференции

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

VMware Workstation 14

Выпуск VMware Workstation 14 и VMware Workstation Player 14 — клиентских гипервизоров, устанавливающихся поверх ОС Windows или Linux.



Среди новых функций:

• поддержка актуальных версий гостевых ОС: Windows 10 Creator Update, Ubuntu 17.04, Fedora 26;
• поддержка Secure Boot для гостевых ОС;
• поддержка Virtualization Based Security (VBS) в Windows 10;
• поддержка виртуальных NVMe-накопителей для ВМ;
• расширенные сетевые настройки, позволяющие ограничивать полосу пропускания, эмулировать задержки и потери пакетов при передаче данных по сети;
• возможность развертывания VMware vCenter Server Appliance (VCSA) в виртуальной машине Workstation;
• расширенные возможности по управлению хостами ESXi.
• Также были анонсированы VMware Fusion 10 и Fusion 10 Pro — клиентские гипервизоры для MAC OS X.

End-of-life VMware vCenter Server для Windows

Объявлено, что следующая версия vSphere (вероятно, vSphere 7.0) будет последней с поддержкой VMware vCenter Server на платформе Windows. Решение правильное и ожидаемое, потому что функциональные возможности VCSA и vCenter Server для Windows сравнялись еще в vSphere 6.0, а в vSphere 6.5 в VCSA появились дополнительные возможности вроде встроенного механизма vCenter High Availability, встроенного бэкапа и модуля обновлений vSphere Update Manager.

Также следующая версия vSphere станет последней для клиента vSphere Web Client (на базе Flash), который будет заменен на vSphere Client (на HTML5).

Последним в списке на выбывание стоит vmkLinux — компонент, обеспечивающий совместимость ESXi с драйверами Linux. Начиная с vSphere 5.0, разработчики стали предоставлять так называемые нативные драйверы, обеспечивающие лучшую производительность и стабильность работы по сравнению с Linux-драйверами. Отказ от vmkLinux потенциально означает сокращение HCL-списка поддерживаемых серверов и периферийных устройств и невозможность запустить ESXi на вашем любимом whitebox-сервере с сетевыми адаптерами Realtek.

VMware Integrated OpenStack 4.0

Новый релиз VMware Integrated OpenStack 4.0.



VIO — это дистрибутив OpenStack, разрабатываемый и поддерживаемый VMware. VIO 4.0 базируется на релизе OpenStack Ocata и предлагает следующие нововведения:

• поддержка развертывания контейнеров;
• интеграция с порталом самообслуживания VMware vRealize Automation, позволяющая управлять инсталляцией OpenStack прямо из интерфейса vRA, а также создавать шаблоны (blueprints) vRA, содержащие объекты OpenStack;
• возможность добавить под управление VIO несколько серверов vCenter Server для наращивания вычислительных ресурсов облака;
• дополнительные возможности, например, увеличение процессоров или добавления памяти без выключения ВМ, функции Firewall as a Service и многое другое.

К сожалению, VIO 3.1 стала последней версией, которая бесплатно предоставлялась заказчикам, купившим vSphere Enterprise Plus. Начиная с VIO 4.0 нужно приобретать лицензии и SnS-поддержку на каждый сокет серверов виртуализации, которые будут управляться VIO.

VMware AppDefense

VMware представила новый продукт для обеспечения безопасности виртуальных сред — AppDefense.

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

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

AppDefense может интегрироваться со сторонними продуктами ИБ, такими как: IBM Security, RSA, Carbon Black, SecureWorks, расширяющими функциональные возможности AppDefense по проверке и выполнению различных действий.

VMware vRealize Network Insight 3.5

Вышла новая версия vRNI 3.5 — продукта для решения проблем с виртуальной и физической сетевыми инфраструктурами. vRNI собирает информацию о настройках с виртуальных и физических коммутаторов, маршрутизаторов и межсетевых экранов и предоставляет ее в удобном наглядном формате, позволяющем упростить обнаружение проблем в работе сети. Например, можно проследить весь путь прохождения пакета от сетевого интерфейса ВМ – через логический коммутатор NSX, аплинк сервера ESXi, порт коммутатора Cisco Nexus, маршрутизатор Juniper, МСЭ Check Point – до порта физического сервера.



В новой версии vRNI появились следующие возможности: проверка сетевой инфраструктуры на соответствие требованиям стандарта PCI DSS, поддержка сбора данных с NSX через механизм IPFIX, визуализация трафика между ВМ, проходящего через маршрутизаторы с настроенным ECMP, сбор данных из дополнительных сторонних источников: Check Point Firewall, HP One View, Brocade MLX.

vSphere Integrated Containers

VMware обновила VIC до версии 1.2, которая позволяет запускать контейнеры прямо на серверах VMware ESXi.



Главное отличие подхода VMware от других менеджеров контейнеров заключается в том, что каждый контейнер запускается в отдельном экземпляре ВМ. Таким образом, администраторы получают возможность управлять контейнерами так же, как и ВМ, используя выгоды платформы виртуализации вроде лучшей изоляции, возможности перемещать контейнеры с хоста на хост, контролировать сетевое взаимодействие контейнеров при помощи VMware NSX, мониторить контейнеры с помощью vRealize Operations Manager и многое другое. Для снижения накладных расходов на запуск контейнеров используется технология Instant Clone, позволяющая создавать копии работающих ВМ в реальном времени, используя механизмы Transparent Pages Sharing и Linked Clones для экономии ОЗУ и дискового пространства.

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

• поддержка аутентификации и авторизации пользователей, включая интеграцию SSO с сервером VMware Platform Service Controller;
• интеграция интерфейса управления VIC Registry и портала управления;
• возможность изменять параметры (количество процессоров, объем ОЗУ) виртуальных хостов, на которых запускаются контейнеры (Virtual Container Host) без пересоздания;
• полноценная поддержка Docker Engine, поддержка команд commit, diff, stats, cp в CLI.

vRealize LifeCycle Manager

VMware анонсировала новую версию vRealize Suite 2017, в состав которой вошли такие продукты, как vRealize Automation 7.3, vRealize Business 7.3, vRealize Operationss 6.6, а также новый продукт — vRealize LifeCycle Manager.

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

Выставка Solutions Exchange

Во время конференции по выставке устраивались экскурсии для посетителей из России и стран СНГ. Евгений Гарбузов (на фотографии слева), системный инженер из российского отделения VMware, показывал наиболее интересные стенды и отвечал на всевозможные каверзные вопросы.

Стенд NVIDIA

На стенде компании NVIDIA демонстрировались ускорители поколений Maxwell и Pascal.



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

Помимо обработки графики, ускорители также могут использоваться для снижения нагрузки на центральный процессор при воспроизведении видео формата H.264 или кодировании изображения для протокола VMware Blast в сценариях VDI, что позволит повысить плотность размещения ВМ на одном физическом сервере.



В новой версии GRID стали поддерживаться ускорители с архитектурой Pascal: P4, P6, P40 и P100.

Ускоритель Tesla P40, выполненный в форм-факторе полноразмерного PCI-E-адаптера, на 50% увеличивает плотность размещения пользователей при использовании профилей с 1 Гб видеопамяти по сравнению с ускорителем предыдущего поколения Maxwell (M60). Для блейд-серверов подойдет ускоритель P6.

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



Ускоритель Tesla P100 предназначен не столько для обработки графики, сколько для ускорения математических вычислений (CUDA, OpenCL).

Но вместе с бочкой мёда NVIDIA подготовила и небольшую ложку дегтя. Для работы vSGA, vDGA или vGPU требуется приобретение дополнительных лицензий GRID в зависимости от используемого режима и профиля нагрузки. И если раньше сервер не проверял наличие необходимых лицензий, то отныне при отсутствии лицензии ускоритель откажется работать и переключит ВМ на использование виртуального GPU.

Стенд-грузовик AMD

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



На экранах демонстрировались в различных сценариях нагрузки: виртуализация, СУБД, HPC-вычисления. На отдельных профилях нагрузки преимущество новых EPYC над процессорами Intel может достигать 30%. Основные отличия процессоров AMD и Intel приведены в таблице.



Также на стенде был представлен новый 2U-сервер Dell PowerEdge R7415 (посмотреть его вблизи можно было только после подписания NDA), с сокетами SR3 (они же TR4). Конструктивно сервер похож на своих родственников R730xd и R740, однако имеет ряд конструктивных особенностей, которые пока нельзя разглашать. Выход серверов Dell с процессорами AMD EPYC ожидается в декабре-январе.

Стенд Pure Storage

На стенде нового партнера «Инфосистемы Джет», компании Pure Storage (ведущего производителя All-Flash систем хранения по мнению аналитического агентства Gartner) демонстрировалась модель FlashArray //m20. СХД Pure Storage обладают всеми возможностями, за которые заказчики любят AFA-массивы, при этом все функции включены в базовую стоимость массива и не требуют приобретения дополнительных лицензий или пакетов расширений. Почитать подробнее о FlashArray //m20 можно в наших публикациях: 1, 2.



Что выделяет массивы Pure Storage на фоне конкурирующих решений, так это сервис EverGreen. Заказчикам предлагается принципиально новая модель владения продуктом – «подписка на инновации». В период сервисного контракта все новые программные функции массива предоставляются клиентам бесплатно, а каждые три года производитель заменяет устаревшие контроллеры на современные. Любые модернизации, в том числе переход на следующие поколения контроллеров, производятся «на ходу» и не требуют повторного приобретения емкости. Кроме того, при продаже массива Pure Storage проводит обследование и гарантирует определенный уровень экономии на хранении данных (data reduction) за счет использования компрессии и дедупликации; в случае невозможности достичь гарантированных показателей, вендор бесплатно увеличивает емкость массива.

Стенд Infinidat

Мое внимание привлек стенд другого производителя систем хранения — компании Infinidat. Это детище Моше Янаи (Moshe Yanai), который в 1990-x годах участвовал в разработке массивов EMC Symmetrix, а также основал компанию XIV, производившую одноименные массивы и позже купленную IBM.

На стенде демонстрировались СХД InfiniBox, которые относятся к классу унифицированных СХД, поддерживающих протоколы Fibre Channel, FICON, iSCSI и NFS, и рассчитанных на хранение большого объема данных (от 115 Тб в младшей модели F1000, до 2,7+ Пб в старшей модели F6000 без учета компрессии) с крайне высоким уровнем доступности в 99,99999% (не более 3,15 секунд простоя в год).



СХД поставляется уже собранной и скоммутированной в стойке. Архитектура строится на базе трех серверов-контроллеров, подключающихся друг к другу через сеть Infiniband, а также дисковых полок высокой плотности, содержащих диски NL-SAS. Высокий уровень производительности (от 300 тысяч IOPS в младшей модели до 1 миллиона IOPS – в старшей) достигается за счет многоуровневого кэширования на flash-накопителях и в ОЗУ контроллеров, а также за счет анализа характера ввода-вывода и предиктивного помещения данных в кэш. СХД поддерживает создание снапшотов, репликацию данных, in-line-компрессию, интегрируется с интерфейсом управления VMware vSphere Client и может восстанавливать отдельные виртуальные машины VMware из снапшотов логических томов без использования системы резервного копирования.



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

Стенд Veeam

В этом году Veeam выпустила версию 2.0 агентского бэкапа Veeam Agent для Windows и Linux, позволяющего выполнять резервное копирование и восстановление не только виртуальных машин, но и физических рабочих станций и серверов. Всего доступно три редакции продукта: Free, Workstation и Server. Их отличия приведены в таблице.



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

Также Veeam анонсировал новую версию флагманского продукта — Veeam Backup & Replication 10. VBR является лидирующим решением по резервному копированию и восстановлению виртуальных инфраструктур на базе VMware vSphere и Microsoft Hyper-V.

Основные нововведения:

1. Поддержка функции Veeam Continuous Data Protection, использующая технологию vSphere API for I/O filtering, которая позволяет выполнять практически синхронную репликацию данных виртуальных машин на резервный физический сервер или в хранилище. Практически все современные средства репликации данных для виртуальных сред используют асинхронный метод передачи данных и механизм создания снапшотов VMware. У этого подхода есть ряд недостатков. Во-первых, высокие показатели RPO, которые достигают 5 и более минут, что может быть неприемлемо для высококритичных ВМ. Во-вторых, использование снапшотов VMware приводит к снижению производительности ВМ. С помощью CDP можно в реальном времени транслировать все операции записи на специальный CDP прокси-сервер, который будет их аккумулировать и кэшировать, а затем передавать на целевой сервер. Такой подход позволит восстановить ВМ на любой интервал времени — от нескольких секунд до пары часов сбоя. Для обеспечения консистентности данных внутри ВМ могут использоваться VSS снапшоты.
   
   
   
   
2. Полная поддержка агентов Veeam Backup Agent. Сервер VBR позволяет централизованно устанавливать агенты на рабочие станции и серверы, настраивать политику резервного копирования и восстанавливать данные. Поддерживаются динамические группы на основе объектов Active Directory, позволяющие выполнять установку агентов и резервное копирование компьютеров, которые находятся в определенном организационном подразделении или входят в определенную группу.
3. Возможность резервного копирования сетевых папок. Функция, которую давно ждали пользователи, поскольку во многих инфраструктурах для хранения файлов используются выделенные NAS-устройства. VBR может хранить историю всех измененных файлов, а также удаленные файлы за определенный промежуток времени.
4. Архивные хранилища. VBR может автоматически перемещать или копировать старые резервные копии в архивные хранилища для экономии дискового пространства или обеспечения дополнительной сохранности копий. Администраторы могут настраивать разные параметры архивирования – например, перемещать бэкапы старше X дней, или перемещать бэкапы только в случае, когда основное хранилище будет заполнено более чем на X процентов, перемещать только еженедельные копии и так далее. В качестве архивных хранилищ могут выступать объектные хранилища Swift, Amazon S3, Amazon Glacier или Microsoft Azure Blob.
5. Расширение ролевой модели. VBR может просматривать права, которые были назначены пользователям в vSphere, и отображать только те ВМ для резервного копирования и восстановления, на которые у пользователей есть права.
6. Поддержка RMAN плагина для консистентного резервного копирования БД Oracle.
7. Выход VBR 10 ожидается зимой этого года.

Стенд Nutanix

Компания Nutanix, один из лидеров рынка HCI-решений, в этом году удостоила посетителей довольно скромным стендом. Оно и понятно, вендор в этом году проводит Nutanix .NEXT во Франции, поэтому все основные анонсы он припас для своей конференции. Тем не менее, кое-что интересное удалось узнать.

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



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

Во-вторых, нас ждёт новая версия гиперконвергентной платформы, построенная на серверах с процессорами Intel Xeon Scalable, а также новая версия ПО Nutanix, поддерживающая следующие функции:

• Near-Sync Replication — новый механизм репликации данных между системами, расположенными на разных площадках, с использованием легких снапшотов (LWS — lightweight snapshots), который позволит уменьшить интервал асинхронной репликации отдельных ВМ и гарантировать RPO вплоть до 1 минуты.
• Встроенное программное шифрование данных без необходимости использования Self-encrypted drives.
• Поддержка режима проброса графических адаптеров vGPU для собственного гипервизора AHV.
• Поддержка гипервизора Microsoft Hyper-V 2016.
• Tech preview-версия встроенного распределенного межсетевого экрана, позволяющего фильтровать трафик между ВМ (микросегментация).
• И многое другое.

Стенд QNAP

У большинства пользователей, знакомых с продукцией QNAP, этот вендор ассоциируется с NAS-устройствами, предназначенными для сегмента SOHO (small office, home office). Тем не менее, в каталоге продукции присутствуют и весьма интересные мультипротокольные СХД начального уровня. Например, QNAP ES1640dc v2.



На СХД установлена операционная система QES (на базе FreeBSD), в качестве файловой системы используется ZFS. СХД поддерживает протоколы доступа к данным CIFS/SMB2/SMB3, NFS v3/NFS v4, FTP, FTPS, TFTP и iSCSI, интегрируется с виртуальной инфраструктурой, включая поддержку VAAI, и имеет агент для интеграции с VMware SRM.

Аппаратные характеристики ES1640dc v2:

• два контроллера на базе процессоров Intel Xeon E5-2400 v2, работающие в режиме active-active или active-passive.
• до 64 Гб ОЗУ на контроллер и до 16 Гб кэш-памяти на запись с батареей для защиты от пропадания питания.
• 16 отсеков для установки 12G SAS-накопителей с возможностью расширения путем подключения дополнительных корзин по интерфейсам HD-SAS.
• 4 порта SFP+ 10G Ethernet и 2 порта RJ-45 1G Ethernet на каждый контроллер + PCI-E слоты расширения для установки дополнительных адаптеров ввода-вывода.
• два блока питания с поддержкой горячей замены.

Приятный бонус: QNAP не обязывает клиентов приобретать «собственные» комплектующие, а вместо этого публикует HCL-списки совместимых дисков и SSD-накопителей производства Seagate, HGST, Toshiba, Micron, комплектуя СХД необходимыми салазками для их установки.



С учетом функциональных возможностей и невысокой цены, эта модель может стать неплохой альтернативой популярным СХД начального уровня вроде HPE MSA 1040/2040 или NetApp E2700.

Стенд Atrust

Компания Atrust, один из производителей тонких клиентов для подключения к терминальным фермам и VDI-инфраструктурам, предлагает широкий модельный ряд: от типовых устройств с ОС Windows Embedded или Linux до нулевых клиентов на базе процессоров Teradici, а также тонких клиентов, выполненных в форм-факторе моноблоков и ноутбуков.



На стенде Atrust демонстрировался новый продукт — ПО Atrust P2T (PC to Thin Client). Функционально P2T идентичен Atrust OS, устанавливаемой на ТК, и представляет собой оптимизированный дистрибутив Linux, включающий набор драйверов, основные клиенты для удаленного подключения (VMware Horizon Client, Citrix Receiver, Microsoft RDP), а также агент для интеграции с сервером Atrust Device Manager, позволяющий централизованно управлять устройствами, распространять настройки, устанавливать обновления ОС и мониторить устройства.

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

Стенд компании Nakivo

Последним решением, о котором я хочу рассказать, является ПО для резервного копирования виртуальных сред — Nakivo Backup & Replication.

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

Nakivo Backup & Replication поддерживает большинство функций, которые можно ожидать от СРК виртуальных сред начального уровня.

• Возможность резервного копирования и восстановления ВМ, размещенных на платформах виртуализации VMware vSphere, Microsoft Hyper-V и облаке Amazon AWS.
• Поддержка LAN-Free бекапов ВМ (режимы Hot-Add и Direct SAN Backup).
• Консистентный бекап и гранулярное восстановление данных внутри ВМ: файлов, почтовых ящиков Microsoft Exchange, БД Microsoft SQL и объектов Active Directory.
• Функция Instant recover, позволяющая запустить ВМ прямо из бекапа, подключив его в виде логического устройства к серверу виртуализации по протоколу iSCSI. Запущенную таким образом ВМ можно восстановить за секунды и затем перенести в постоянное хранилище, используя функцию Storage vMotion.
• СРК управляется через простой и интуитивно понятный HTML5 веб-интерфейс.
• Поддержка асинхронной репликации ВМ на серверы на другой площадке для сценариев Disaster Recovery.

Nakivo также обладает уникальной функцией, которая отсутствует в других решениях СРК: возможностью установки напрямую в NAS-хранилища производства QNAP, Synology, ASYSTOR или WD, что позволяет организовать экономичное решение по резервному копированию и хранению бэкапов для небольших офисов и филиалов.

Хоть Nakivo Backup & Replication и не обладает полным набором функциональных возможностей других СРК, вроде Veeam Backup & Replication, Veritas Backup Exec или прочих, решение ориентировано на SMB-сегмент и привлекает своей невысокой ценой.

Что еще было интересного

На стенде компании Rubrik, производителя программно-аппаратного решения для резервного копирования, устроили сессию раздачи книг VMware vSphere 6.5 Host Resources Deep Dive с автографами авторов — Фрэнка Деннемана (Frank Denneman) и Нилса Хагорта (Niels Hagoort). Хотя я уже купил эту книгу в электронном виде (и она стоит каждого цента, настоятельно рекомендую для прочтения всем администраторам vSphere), я не преминул воспользоваться возможностью взять бумажный экземпляр.

Заключение

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

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

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

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

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

Итак, в ноябре 2016 года мы узнали, что грядет внедрение ФЗ-54: к лету 2017 года нам придется поменять все кассы в наших магазинах на новые. Все кассы — это порядка 2,5 тысяч во всех регионах страны: от Владивостока до Калининграда. Знаете, как мне поставили задачу?
«В РФ появились изменения: федеральный закон 54 — облачная фискализация! Надо соответствовать». И мы приступили к выполнению директивы.

Вводные данные

На конец октября 2016 мы знали, что в Роснефти уже внедрили новые кассы, и налоговая даже осталась довольна результатом. Но как это происходило, в каком виде внедрялось — подробностей никто не знал. Погуглив, мы поняли, что никто на рынке пока толком не знает, что делать. Знали не много: есть новый формат фискальных данных, документ страниц на 100, в котором прописаны теги, которые надо передавать в ОФД и налоговую. Есть операторы фискальных данных — сертифицированные организации, договор хотя бы с одной из которых нам придется заключать, а это означает: тендер, долгие муки выбора, а до этого отсутствие тестовой площадки. А еще меняется процедура регистрации и перерегистрации касс: теперь не надо нести ККТ в налоговую, можно сделать всё удаленно через личный кабинет налогоплательщика. Остальная информация была противоречива и расплывчата.

Не было сомнений только в одном: нам точно придётся это делать, а также модернизировать парк кассовой техники, так как вместо ЭКЛЗ (электронной контрольной ленты защищенной) появляется фискальный накопитель.

Переход на новые кассы

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

Вариантов было два:

• купить новые сертифицированные кассы (а компаний, которые уже сертифицировали ККТ, на тот момент было не так много);
• сделать кастомные кассы: из старых вынуть ЭКЛЗ, просверлить парочку отверстий, просунуть парочку проводов и подключить фискальный накопитель.

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

Как осуществлялось внедрение

Стратегически командой мы решили, что затянем с внедрением ФЗ-54 до последнего, но зато пропустим этап внедрения на версии ФФД 1.0, перерегистрацию с 1.0 на 1.05, и запустимся сразу на версии 1.05. Как показала жизнь — решение было ошибочным и стоило нам почти месяца понапрасну потерянного времени.

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



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

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

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

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

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

Еще одним из велосипедов стали подарочные карты. Как правильно передавать данные по ним в налоговую? При покупке клиентом подарочной карты мы вносим на неё деньги — аванс, — который потом тратится на покупку товаров — зачет аванса. То есть оборот одной суммы денег осуществляется дважды, и согласно новому закону «каждый чек должен быть фискализирован», в этой ситуации мы должны были заплатить налог дважды: первый раз — когда продали карточку с начислением на нее средств, второй раз — когда мы эту карточку используем в оплату. Однако в ФФД 1.0 не была предусмотрена разбивка на кредиты, на авансы, на погашение авансов и прочие оплаты.

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

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

Дополнения к закону и очные ставки с налоговой

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

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

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

Чеки в интернет-магазине

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

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

В конце концов мы решили установить для интернет-магазинов точно такие же кассы, как в рознице. А чтобы кассы физически успевали обработать все заказы, с них были удалены модули печати чеков, так как один чек печатается 5-7 секунд. Дальше мы решили использовать решение компании «Атол»: так называемые фермы для распараллеливания работы кассы и балансировки нагрузки. Сегодня у «Атол» есть полноценное готовое решение для интернет-магазинов, но мы исходили из того, что было на рынке на тот момент.

Лучше раньше, чем никогда

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

В нашем нелегком квесте были две очень важные даты:

• 1 февраля 2017 — начиная с этого дня на учёт запрещалось ставить кассы старого образца.
• 1 июля 2017 — в этот судьбоносный день все кассы должны были работать на новом программном обеспечении.

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

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

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

До Нового Года процесс замены шел на «ура», мы безболезненно заменили ЭКЛЗ у части касс на новые. Тем же самым занимались множество других компаний. Хоть это и было законно, налоговая быстро поняла, что происходит, и прикрыла эту лавочку. Теперь поменять ЭКДЗ или саму кассу можно было только по серьезной причине: если касса сломана или срок ЭКЛЗ подошел к концу.

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

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

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

Аврал и его команда

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

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

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

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

Уборщица в серверной

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

Но если касса 30 дней ничего не передаёт в налоговую, то она автоматически блокируется для осуществления продаж.

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

С этого момента техподдержка стала «любить» нас ещё больше.

К чему пришли и куда стремимся

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

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

Сегодня у нас всего две формы оплаты: наличными и электронными средствами оплаты. Ко второй категории относятся авансы, кредиты, банковские карты, Яндекс.Деньги, Киви-кошельки и прочее. Поэтому разобраться на уровне оператора фискальных данных, что есть что — просто mission impossible. А это затрудняет взаимозачёты с налоговой.

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



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

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

Но это всё ждет нас впереди.

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

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

Работа над программами управления контентом CMS (content management system) полна чудес. Под катом поучительная история Petr Palas. Если у вас все хорошо с английским, то в оригинале текст можно почитать здесь. Enjoy!

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

В 2000-м я обучался в университете и работал Интранет-разработчиком: публиковал в Интранет контент, написанный на статичном HTML. Это была моя первая «программистская» работа, и я ею наслаждался. Пару недель.

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

К 2004-му почти каждое интернет-агентство создавало собственную CMS, нередко кастомизируя под конкретных клиентов. Это приводило к появлению десятков модификаций — кошмар с точки зрения управления. «Это бессмысленно», думал я. К тому моменту я уже написал несколько специализированных CMS и снова заскучал. «А что если написать CMS, которая может быть полезна для любого сайта?» В результате я организовал компанию Kentico Software, чья миссия была очень проста: создать CMS, которую любой разработчик в мире может использовать для создания любого сайта.

Сюрприз: люди всё ещё пишут собственные CMS!

13 лет спустя меня ещё поражает количество людей, которые пишут собственные CMS. Существует масса зрелых продуктов, под все виды проектов: от open source до коммерческих систем корпоративного уровня, от лучших в своём классе до универсальных «всё-в-одном».

Так зачем кому-то до сих пор нужно писать собственную CMS?
Ответ прост: люди делают это из-за разочарования.

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

Самописные CMS устарели из-за headless-архитектуры

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

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



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

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

Причина №1: стандартные CMS ограничивают мой творческий потенциал

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

Но с этим покончено: headless-CMS дают вам полную свободу и никак не влияют на результирующий HTML-код. Для извлечения контента из репозитория вам достаточно лишь с помощью своего любимого языка программирования вызвать соответствующий REST API.
И более того, вы сами полностью решаете, как будет этот контент отображаться!

Причина №2: интерфейсы стандартных CMS слишком сложны

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

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

Причина №3: стандартные CMS слишком дороги

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

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

Причина №4: стандартные CMS не безопасны

Для многих организаций обеспечение безопасности CMS является кошмаром. Поэтому некоторые разработчики думают: «Если мы напишем свою CMS, то хакерам будет труднее найти в ней баги».
Классическое обеспечение безопасности через неясность (security by obscurity).

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

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

Причина №5: стандартные CMS не вписываются в мою архитектуру

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

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

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

Причина №6: многие клиенты всё ещё пользуются написанной нами CMS

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

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

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

… и две причины, когда использование самописной CMS оправдано

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

• Управление контентом — основа вашего бизнеса: если вы компания наподобие Medium, то вам наверняка нужен абсолютный контроль над системой управления контентом. Если вы большое издательство с десятками публикаций, и вам нужен полностью кастомизированный рабочий процесс, то вам тоже может понадобиться собственная CMS (или хотя бы кастомный редакторский интерфейс). Однако в мире ОЧЕНЬ мало компаний, относящиеся к этим категориям и для которых оправданы подобные инвестиции.
• Уникальные требования по безопасности или соблюдению законодательства: опять же, существует немного организаций, вынужденных придерживаться специфических правил, когда речь идёт о хранении контента, обеспечении безопасности, программной архитектуре или инфраструктуре, и эти правила не позволяют использовать стандартные CMS.

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

Не пишите свою CMS, пока не возникнет очевидный бизнес-случай

Люди ВСЕГДА недооценивают объём работы по созданию настоящей CMS.

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

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

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

Привет, Хабр!
14 сентября было объявлено о выпуске первой версии SignalR для ASP.Net Core, в связи с чем я решился перевести заметку, посвященную даному событию, немного её дополнив. Оригинал заметки доступен в блоге на MSDN.

Что нового?

SignalR для ASP.Net Core является переписанной с нуля версией оригинального SignalR. Новый SignalR проще, более надёжен и легче в применении. Несмотря на эти внутренние изменения, мы старались сделать API библиотеки наиболее близким к предыдущим версиям.

JavaScript/TypeScript клиент

SignalR для ASP.Net Core имеет совершенно новый JavaScript клиент. Он написан с использованием TypeScript и более не зависит от JQuery. Клиент также может использоваться из Node.js с несколькими дополнительными зависимостями.

Клиент распространяется в качестве npm модуля, который содержит Node.js версию клиента (подключается через require), и также версию для браузера, которую можно встроить используя тег

Ирина Черепанова и Татьяна Жукова из проекта uKit AI, обучающего нейросеть редизайну сайтов, перевели колонку менеджера команд продуктового дизайнер из Airbnb Амбер Картрайт о том, как умные технологии позволяют улучшать известные продукты.

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



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

Математика и наука — невидимые силы, которые всё больше раскрывают себя и влияют на наши жизни.

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

Недавно, просматривая ленту Facebook, я заметила, что нескольким моим друзьям понравилась компания, которая предлагала в режиме онлайн спроектировать и заказать индивидуальные рамки для постеров и холстов. Я задумалась обо всех тех необрамленных работах, которые лежали у меня в кладовке, и кликнула посмотреть, что предлагают. Почему я заинтересовалась этой рекомендацией? Что привлекло моё внимание? Какого рода информацию они использовали, чтобы персонализировать этот пост? Невидимые силы науки и математики, задействованные здесь, — это алгоритмы соцсети. Рекламное программное обеспечение — это всего лишь зародышевое состояние тех возможностей, которые несет мощь машинного обучения в ближайшие 5–10 лет.

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

Я начала постигать суть этого «невидимого дизайна» в Airbnb, когда мы запускали продукты, требующие переработки большого объема данных. И хотела бы поделиться некоторыми наблюдениями из своей практики.

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Функция «Умные цены», когда алгоритмическая модель советовала владельцам квартир, какую цену аренды лучше выставить для конкретного дня, — пример того, как состав команды помог развитию продукта.

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

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

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

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



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

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

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

О курсах Нетологии

1. Бесплатные программы по UI/UX и дизайну:

• «Основы графического дизайна: композиция, цвет, типографика»
• «Adobe XD: основы для дизайнера интерфейсов»

2. Программа «Big Data: основы работы с большими массивами данных»

Для кого: инженеры, программисты, аналитики, маркетологи, дизайнеры — все, кто только начинает вникать в технологию Big Data.

Формат занятий: онлайн
Подробности по ссылке ->

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

20 сентября состоялся очередной релиз популярного дистрибутива для проведения тестирования на проникновение Kali Linux 2017.2. Среди нововведений мы получили возможность установить из репозитория несколько новых инструментов. В данном тексте мы рассмотрим фреймворк apt2 или Automated Penetration Testing Toolkit.

Установка и настройка

После обновления дистрибутива до версии 2017.2 можно приступать к установке фреймворка.
Напомню, что обновиться до последней версии Kali Linux можно при помощи следующих команд

apt-get update
apt-get upgrade
apt-get dist-upgrade

Установка происходит стандартно

apt-get install apt2

Далее рекомендую провести базовую настройку.

Изучив официальный github проекта становится ясно, что он интегрируется с Metasploit Framework.

Для интеграции с Metasploit нужно запустить его RPC сервис.
Делается это следующим образом

msfconsole
load msgrpc

Вы должны получить случайно сгенерированный пароль. Запомните его.


Можно посмотреть на структуру конфигурационного файла в каталоге /usr/share/apt2



Нас интересует файл default.cfg

В блоке [metasploit] указываем наш пароль

[metasploit]
msfhost=127.0.0.1
msfport=55552
msfuser=msf
msfpass=kqVbTlmr
msfexploitdelay=20

Далее вы можете добавить дополнительные ключи для nmap или изменить подсеть. По умолчанию используется SYN сканирование (-sS) и флаг (-A), что указывает Nmap провести определение версий сервисов, типа и версии ОС, выполнить безопасные NSE скрипты и traceroute. В некоторых случаях будет нелишним добавить ключ -Pn, если вы не импортируете в apt2 результат сканирования nmap.

[nmap]
scan_target=192.168.1.0/24
scan_type=S
scan_port_range=1-1024
scan_flags=-A

По умолчанию используется 20 потоков. Это значение можно не менять без необходимости.

[threading]
max_modulethreads=20

Есть настройка для Reponder. Если Вы используете нестандартную конфигурацию, нужно отредактировать блоки [responder] и [default_tool_paths]. Я задам responder_timeout=30, так как не хочу тратить время на этот модуль.

Далее идет блок [searching]

[searching]
file_search_patterns=*.bat,*.sh,*passwd*,*password*,*Pass*,*.conf,*.cnf,*.cfg,*.config

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

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

[apikeys]
#apt2_shodan_apikey=CHANGEME
#apt2_linkedin_apikey=CHANGEME

Запуск

При запуске с ключом -h мы получаем список доступных ключей



Разберем некоторые из них

SAFE_LEVEL может принимать значения от 1 до 5 и указывает apt2 насколько безопасные модули разрешено запускать. Самые безопасный режим — 5. По умолчанию используется 4.

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

--target задает цели, либо вы можете использовать ключ -f, чтобы загрузить в apt2 XML файл с результатами сканирования nmap. Напомню, что сохранить результат работы nmap в XML можно при помощи ключа -oX.

и ключ --listmodules покажет доступные модули. Давайте посмотрим на этот список

apt2 --listmodules

Получаем список с указанием имени модуля, его типа (используется для EXCLUDE_TYPES), Safety Level и описания. Модули с Safety Level ниже, чем указано ключом -s выполнены не будут, о чем будет дополнительно сказано в выводе apt2 при запуске.



Давайте запустим apt2 с максимальным уровнем риска против машины 192.168.1.4, на которой работает Ubuntu.

apt2 -v -v -s 1 -b --target 192.168.1.4

Нас предупреждают, что модули, требующие API ключи не будут выполнены и начнется сканирование



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



Посмотреть, что смог собрать apt2 можно в директории /root/.apt2/proofs



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

Запустим еще одно сканирование в отношении Windows машины 192.168.1.7 и не будем выполнять сканирование nmap через apt2, а загрузим XML файл.

nmap -n -Pn -A -oX scan1 192.168.1.7
apt2 -s 1 -b -v -v -f scan1

Здесь уже запускаются другие модули, например модуль для тестирования на уязвимость к ms08-067.



Если сервер уязвим, об этом будет сказано в логе

[!] VULN [ms08-067] Found on [192.168.1.7]

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



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



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

firefox /root/.apt2/reports/reportGenHTML_flcgfsqhji.html

Если вы хотите написать свои модули для apt2, можно изучить имеющиеся в директории /usr/share/apt2/modules и сделать собственные по аналогии. Сам фреймворк написан на python и модули к нему, соответственно, тоже.

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

Одним из параметров оценки кода служит его чистота. Создатель языка моделирования UML Гради Буч (Grady Booch) писал:

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

Сегодня мы собрали для вас список книг и статей по этой теме, которые рекомендуют к прочтению резиденты Hacker News, Stack Exchange и других профильных платформ.

/ Flickr / Robert Gourley / CC

Литература

• «Совершенный код» Стив Макконнелл (Steve McConnell)

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

---

• «Программист-прагматик. Путь от подмастерья к мастеру»
  Эндрю Хант (Andrew Hunt), Дэвид Томас (David Thomas)

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

---

• «Способ мышления — Форт» Лео Броуди (Leo Brodie)

Форт — это язык программирования, который широко использовался в астрономии в 70-х годах прошлого века. Несмотря на узкую тематику, разработчики найдут в книге основы построения кода. Даже для тех, кто не собирается изучать Форт, «фортанский» способ мышления поможет иначе взглянуть на рефакторинг. Переизданная в 2004 году версия предоставлена автором Лео Броуди (Leo Brodie) в общее пользование.

---

• «Ruby. Объектно-ориентированное проектирование» Сэнди Метц (Sandi Metz)

Сэнди Метц (Sandi Metz) подготовила практическое руководство по объектно-ориентированному проектированию с прицелом на разработчиков, знакомых с основами, но пока не сформировавших философию кода. Автор использует понятные и приближенные к реальной жизни примеры. Сэнди — фанат экономичных тестов и разумных подходов. На её сайте сказано: «Если код вас добивает, и никакой радости не осталось, — эта книга ваше решение».

---

• «Рефакторинг. Улучшение существующего кода»
  Мартин Фаулер (Martin Fowler), Кент Бек (Kent Beck), Джон Брант (John Brant) и др.

Еще один нестареющий фолиант, появившийся в конце 90-х. Список авторов «Рефакторинга» возглавляет Мартин Фаулер (Martin Fowler), который вместе с Кентом Беком (Kent Beck) стоит у основ методологии экстремального программирования. Это совершенно новый взгляд на процесс разработки, который показывает, каким должен быть код и как он должен создаваться. Книга содержит примеры рефакторинга с подробным описанием. Многие из них не потеряли своей актуальности, а часть была автоматизирована и теперь используется в современной разработке.

---

• «Искусство программирования для Unix» Эрик Реймонд (Eric Raymond)

Название книги не зря перекликается с фундаментальной работой Дональда Кнута (Donald Knuth) 1968 года «Искусство программирования». На страницах своей книги Эрик Реймонд (Eric Raymond) пытается донести не только практические рекомендации, но и философию — понимание кода в Unix. Он делает это с помощью множества примеров. В них прослеживается уважение к плодам работы талантливых людей, трудившихся над Unix, и философия «чистого кода».

---

• «Практика программирования»
  Брайан Керниган (Brian Kernighan), Роб Пайк (Rob Pike)

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

---

• «Чистый код. Создание, анализ и рефакторинг» Роберт К. Мартин (Robert Martin)

«Чистый код» — это взгляд на процесс разработки с позиции XXI века. Книга изобилует конкретными примерами программ. Автор Роберт не пытается сформировать философию вокруг разработки, а показывает, как код работает «в жизни».

---

• «Шаблоны игрового программирования» Роберт Нистром (Robert Nystrom)

«Это книга, которую я хотел бы прочитать, когда начинал создавать игры», — так описывает ее сам автор. На первый взгляд, «Шаблоны» — это узкоспециализированная литература для геймдева от ветерана Electronic Arts. Однако при ближайшем рассмотрении книга позволяет переосмыслить работу с кодом и сделать его чище. Кто-то из пользователей Reddit даже решил изучить C++ после прочтения книги.

---

• «Читаемый код, или Программирование как искусство»
  Дастин Босуэлл (Dustin Boswell), Тревор Фаучер (Trevor Foucher)

По словам Николаса Закаса (Nicholas C. Zakas), автора работ по JavaScript, «книга погружает в процесс гигиены кода как ничто другое». В книге рассказано, как именование переменных, функций и классов помогает командам разработки. Основные акценты: структурирование кода и комментариев, балансирование между эффективностью и читаемостью.



/ Maxpixel / Code Data Programming / CC

Несколько статей, блогов и инструментов

• Статья «Как написать неподдерживаемый программный код» — своего рода классика. В формате «вредных советов» читателю предлагается узнать о том, какой код точно нельзя считать чистым.
• У чистого кода есть некоторые формальные признаки. Проверить, не исходит ли от кода «дурной запах», можно с помощью таблицы профессора Мики Мянтюля (Mika M"antyl"a). Признаки хорошего кода можно найти в блоге Coding Horror.
• Как советуют пользователи Quora, чтобы постичь искусство чистого кода, стоит как можно больше читать хороший код. Для этого подойдут такие платформы, как GitHub, Codeplex, Google Code. Кстати, различные платформы предоставляют готовые инструменты для улучшения кода. Например, GitHub Code Review.
• Процесс очистки кода можно частично автоматизировать. Существуют инструменты для статистического анализа. В случае с C, C++ для этого разработан PC-lint. Упростить код позволяет SourceMonitor.
• Рекомендации по структурированию кода также зачастую дают разработчики платформ. Например, такой документ есть у Microsoft для C.

---

P.S. Наши дайджесты:

• IaaS-дайджест: 30 материалов о работе с ПД, новых технологиях, ИБ и высокой производительности
• 100 практических материалов по безопасности, экономике и инструментарию IaaS

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

• Балансировка нагрузки в облаке IaaS
• Виртуализация приложений: как правильно настраивать виртуальные машины
• Особенности двухфакторной аутентификации: работает ли это в облаке IaaS

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

В ECMAScript 6 представлены два новых флага для регулярных выражений:

1. y включает режим «липкого» сопоставления.
2. u включает различные связанные с Unicode опции.

В данной статье объясняется влияние флага u. Эта статья будет Вам полезна, если Вы знакомы с Unicode-проблемами в Javascript.


N.B.! Поскольку при попытке публикации статьи обнаружились проблемы с отображением некоторых используемых в статье Unicode-символов, часть кода была заменена изображениями со ссылками на JSFiddle.

Влияние на синтаксис

Установка флага u в регулярном выражении позволяет использовать escape-последовательности кодовых точек ES6 Unicode (\u{...}) в шаблоне.



При отсутствии флага u такие вещи, как \u{1234}, технически могут по-прежнему возникать в шаблонах, но они не будут интерпретироваться как escape-последовательности кодовых точек Unicode. /\u{1234}/ эквивалентно записи /u{1234}/, которая соответствует 1234 последовательным символам u вместо символа, соответствующего escape-последовательности кодовых точек U+1234.

Движок Javascript делает так из соображений совместимости. Но с установленным флагом u и такие вещи как \a (где a не является escape-последовательностью) больше не будут эквивалентны a. Поэтому, даже если /\a/ обрабатывается как /a/, /\a/u выбрасывает ошибку, т.к. \a не является зарезервированной escape-последовательностью. Это позволяет расширить функционал флага u регулярных выражений в будущей версии ECMAScript. Например, /\p{Script=Greek}/u выбрасывает исключение для ES6, но может стать регулярным выражением, соответствующим всем символам греческого алфавита согласно базе данных Unicode, когда соответствующий синтаксис будет добавлен в спецификацию.

Влияние на оператор ‘.’

При отсутствии флага u, . соответствует любому символу BMP (базовая многоязыковая плоскость — Basic Multilingual Plane) за исключением разделителей строки. Когда установлен флаг ES6 u, . соответствует также астральным символам.

Влияние на квантификаторы

В регулярных выражениях Javascript доступны следующие квантификаторы (а также их вариации): *, +, ?, и {2}, {2,}, {2,4}. При отсутствии флага u, если квантификатор следует за астральным символом, он применяется только к низкому суррогату (low surrogate) этого символа.



С флагом ES6 u квантификаторы применяются к символам целиком, что справедливо даже для астральных символов.

Влияние на символьные классы

При отсутствии флага u любой заданный символьный класс может соответствовать только символам BMP. Такие вещи, как [bcd] работают как мы того ожидаем:

const regex = /^[bcd]$/;
console.log(
	regex.test('a'), // false
	regex.test('b'), // true
	regex.test('c'), // true
	regex.test('d'), // true
	regex.test('e')  // false
);

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



Флаг ES6 u позволяет использовать цельные астральные символы в символьных классах.



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



Флаг u также влияет на исключающие символьные классы. Например, /[^a]/ эквивалентно /[\0-\x60\x62-\uFFFF]/, что соответствует любому символу BMP, кроме a. Но с флагом u /[^a]/u соответствует гораздо большему набору всех символов Unicode, кроме a.

Влияние на escape-последовательности

Флаг u влияет на значение escape-последовательностей \D, \S, и \W. При отсутствии флага u, \D, \S, и \W соответствуют любым символам BMP, которые не соответствуют \d, \s и \w, соответственно.



С флагом u, \D, \S, и \W также соответствуют астральным символам.



Флаг u не обращается к их обратным аналогам \d, \s и \w. Было предложено сделать \d и \w (и \b) более Unicode-совместимыми, но это предложение было отклонено.

Влияние на флаг i

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

const es5regex = /[a-z]/i;
const es6regex = /[a-z]/iu;
console.log(
	es5regex.test('s'),      es6regex.test('s'),      // true true
	es5regex.test('S'),      es6regex.test('S'),      // true true
	// Note: U+017F преобразуется в `S`.
	es5regex.test('\u017F'), es6regex.test('\u017F'), // false true
	// Note: U+212A преобразуется в `K`.
	es5regex.test('\u212A'), es6regex.test('\u212A')  // false true
);

Приведение к одному регистру (case-folding) применяется к символам в шаблоне регулярного выражения, а также к символам в сопоставляемой строке.

console.log(
	/\u212A/iu.test('K'), // true
	/\u212A/iu.test('k'), // true
	/\u017F/iu.test('S'), // true
	/\u017F/iu.test('s')  // true
);

Эта логика приведения к одному регистру применяется и к escape-последовательностям \w и \W, что также влияет на escape-последовательности \b и \B. /\w/iu соответствует [0-9A-Z_a-z], но также и U+017F, поскольку U+017F из сопоставляемой строки регулярного выражения преобразуется (canonicalizes) в S. То же самое касается U+212A и K. Таким образом, /\W/iu эквивалентно /[^0-9a-zA-Z_\u{017F}\u{212A}]/u.

console.log(
	/\w/iu.test('\u017F'), // true
	/\w/iu.test('\u212A'), // true
	/\W/iu.test('\u017F'), // false
	/\W/iu.test('\u212A'), // false
	/\W/iu.test('s'),      // false
	/\W/iu.test('S'),      // false
	/\W/iu.test('K'),      // false
	/\W/iu.test('k'),      // false
	/\b/iu.test('\u017F'), // true
	/\b/iu.test('\u212A'), // true
	/\b/iu.test('s'),      // true
	/\b/iu.test('S'),      // true
	/\B/iu.test('\u017F'), // false
	/\B/iu.test('\u212A'), // false
	/\B/iu.test('s'),      // false
	/\B/iu.test('S'),      // false
	/\B/iu.test('K'),      // false
	/\B/iu.test('k')       // false
);

Влияние на HTML-документы

Верьте или нет, но флаг u также влияет и на документы HTML.

Атрибут pattern для элементов input и textarea позволяет вам указать регулярное выражение для проверки ввода пользователя. Затем браузер обеспечивает вас стилями и скриптами для создания поведения, основанного на достоверности ввода.



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

Поддержка

На данный момент флаг ES6 u для регулярных выражений доступен в стабильных версиях всех основных браузеров, кроме Safari. Браузеры постепенно начинают использовать этот функционал для HTML атрибута pattern.

Browser(s)	JavaScript engine	u flag	u flag for pattern attribute
Edge	Chakra	issue #1102227 + issue #517 + issue #1181	issue #7113940
Firefox	Spidermonkey	bug #1135377 + bug #1281739	bug #1227906
Chrome/Opera	V8	V8 issue #2952 + issue #5080	issue #535441
WebKit	JavaScriptCore	bug #154842 + bug #151597 + bug #158505	bug #151598

Рекомендации для разработчиков

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

Преобразование (transpiling) Unicode ES6 регулярных выражений в ES5

Мной создан regexpu, транспилер, который преобразовывает регулярные выражения Unicode ES6 в эквивалентный код ES5, который работает уже сегодня. Это позволит вам играться с новым, развивающимся функционалом.



Полномасштабные транспилеры ES6/ES7, такие как Traceur и Babel, зависят от regexpu при транспиляции u. Дайте мне знать, если вам удастся это сломать.

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

Последнее время большое внимание в Программе «Единая Фронтальная Система» (ЕФС) уделяется автоматизации тестовых сценариев. Причины объективны и связаны с повышением уровня зрелости отдельных подсистем Программы и объемом регрессионного тестирования.

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




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

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

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

Именно в этот момент мы в Программе ЕФС пришли к необходимости создания автоматизированной системы —  назовем ее Unified Logfile Analyzer или коротко ULA — которая бы помогла достичь двух целей:

• минимизация времени анализа результатов автотестов;
  
• минимизация количества дублирующих дефектов.
  

С чего начинали?

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

В качестве технологического стека были выбраны:

• СУБД Oracle 11g для хранения справочных данных, истории;
  
• Oracle TimesTen In-Memory Database 11g для хранения хэшей shingles;
  
• Jersey для микросервисов;
  
• React JS для FrontEnd.
  

В ULA используются данные от самих автотестов: XML, CSV, снимки экрана, видео, а также от аппликативной части тестируемых подсистем: лог-файлы WebSphere, данные из БД журналирования.



Система распределенная и состоит из нескольких модулей:

• Агенты по разбору логов автотестов;
  

На текущий момент разработаны агенты для Allure v.1.4,v. 1.5 и Serenity. Агенты обращаются в открытый API и работают под управлением Windows или Linux.

• Plugin Jenkins;
  

Управляет агентами по передаче логов-автотестов к Агенту;

• Maven Plugin;
  

Альтернативное решение Jenkins plugin: результаты выполнения можно загружать в обход Дженкинса, используя maven;

• Набор микросервисов с функциями приема новых сообщений, принятия событий о завершении запусков, для функционирования Frontend части;
  
  
• Frontend на базе React JS;
  
• База данных под управлением Oracle 11g;
  
• Службы нотификации для рассылки результатов тестов по определенным каналам.
  

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

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

На данный момент реализованы и проходят тестирование ряд подсистем, рассмотрим их подробнее.

Подсистема агрегации сообщений об ошибках

Данная подсистема обладает следующими функциями:

• прием сообщений от автотестов;
  
• парсинг стандартных отчетов: Allure для API-тестов и Serenity для UI-тестов;
  
• агрегация сообщений методом нечеткого поиска. В качестве основы был выбран алгоритм поиска нечетких дубликатов текстов (shingles);
  
• автоматическое заведение шаблонов ошибок (обучение без учителя).
  

Подсистема принятия решений

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

Скриншоты

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

Видеозаписи прохождения тестов

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

БД

Каждая из подсистем ЕФС логирует данные в специальную БД. В ходе анализа шага автотеста на основе маркера (сессия пользователя) записи из БД Журналирование копируются в БД ULA.

Плоские текстовые файлы с системными логами

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

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

Подсистема оповещений

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

К примеру, недоступность сервисов на уровне TCP, ошибки HTTP (404, 500) и прочие проблемы, требующие быстрой реакции администратора. Сейчас прорабатывается задача автоматического заведения инцидентов на тестовой среде.

Опишем в упрощенном виде реализованные в системе шаги алгоритма поиска дубликатов и агрегации.

• Шаг 1. Канонизация текста.
  

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

Пример канонизированного текста:
«сумма на счете не изменилась на указанную сумму ожидаемая сумма на счете 173,40 euro баланс после пополнения 173,40 euro»

• Шаг 2. Разделение на словосочетания (shingles).
  

Разделение проводится с шагом в одно слово. Количество слов в словосочетании называется длиной shingle.

Набор shingles с длиной 5:
«сумма на счете не изменилась»; «на счете не изменилась на»; «счете не изменилась на указанную»; «не изменилась на указанную сумму»; «изменилась на указанную сумму ожидаемая»; «на указанную сумму ожидаемая сумма»; «указанную сумму ожидаемая сумма на»; «сумму ожидаемая сумма на счете».

• Шаг 3. Вычисление хэшей shingles по алгоритму MD5.  
  

Полученный набор хэшей текста хранится во временной таблице до окончания сравнения с хэшами shingles всех шаблонов ошибок, заведенных в системе.

Для каждого набора shingles шаблонов ошибок вычисляется степень схожести по набору хэшей.
SIMILARITY(i) = SIMCNT * 2 / (TSCNT + THCNT(i)),
где SIMCNT – количество совпавших уникальных хэшей в двух наборах,  TSCNT – количество уникальных хэшей анализируемого текста, THCNT(i) – количество уникальных хэшей шаблона i.

• Шаг 4. Выбирается подходящий шаблон ошибки.
  

Ищется SIMILARITY = MAX(SIMILARITY(i)).
Если SIMILARITY больше или равно заданному порогу схожести, то тексту проставляется существующий идентификатор шаблона.

Если SIMILARITY меньше порога схожести, то канонизированный текст сам становится шаблоном, а набор хэшей shingles записывается в БД.

• Заключительный этап.
  
  

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

Поговорим об аналогах

Справедливый вопрос – зачем вы писали систему сами, когда на рынке уже имеется аналогичный продукт, например, Report Portal от компании EPAM.

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

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

ReportPortal	Unified Logfile Analyzer
Акцент на анализе логов самих автотестов, в которых также могут быть дефекты, включая дефекты логирования	Указывает пользователю на подозрительные автотесты, когда тест помечен как успешно пройденный, но по нему имеются ошибки,  или,  наоборот, когда тест провален, но никаких ошибок не зарегистрировано
В основе алгоритма определения схожести используется расстояние Левенштейна	Нам не подходит данный алгоритм, так как на длинных словах расстояние получается существенным В своем решении используем алгоритм Shingles (http://ethen8181.github.io/machine-learning/clustering_old/text_similarity/text_similarity.html)
В Report Portal мы пока не увидели этой возможности. Возможно, в будущем появится.	Информация от автотестов (тексты ошибок, скриншоты, видеозапись теста) обогащается информацией из аппликативной части самих систем (файлы, БД), что улучшает качество анализа
Большое внимание уделено отчетности: графики, разнообразная статистика	Функционал отчетности планируем реализовать отдельно
Не предусмотрена интеграция с HP ALM	Есть интеграция с HP ALM, для нас это важно
Используется нереляционная база данных MongoDB.  Спорить на эту тему можно долго	По нашему мнению, решение на Oracle 11g будет вести себя более предсказуемо в части потребления ресурсов

Unified Logfile Analyzer – система, которую мы собрали с нуля, разработали ее, учитывая свой опыт, опыт коллег, проанализировав существующие на рынке решения. Система самообучаемаемая, помогает нам быстрее находить и точно исправлять баги — куда без них.
Сейчас мы запускаем ULA в продуктив, будем раскатывать на продуктах и сервисах Программы ЕФС. В следующем посте расскажем о первых результатах и поделимся кейсами.

Будем рады обсудить решение и поспорить о подходах, поделитесь опытом и кейсами в комментариях!

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

Ловите 2 плаката с регулярными выражениями в форматах A2 и A3.

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


Скачать плакат A2


Скачать плакат A3


Мы в отделе маркетинга повесили на стену стоп-слова glvrd.ru. Давно знаем их наизусть, но иметь под рукой всегда приятно.



Хотели сделать для вас ещё обоину на рабочий стол, “домики” на письменный и куб, который нужно склеить самому. Но все перессорились в спорах об удобстве.

Расскажите, вы пользуетесь плакатами или предпочитаете cheat-sheet в другом формате? И какие регулярные выражения юзаете?

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

[Прим. пер.: оригинал статьи называется GPU Performance for Game Artists, но, как мне кажется, она будет полезной для всех, кто хочет иметь общее представление о работе видеопроцессора]

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

Мы надеемся, что художники создадут ресурсы, которые не только хорошо выглядят, но и будут эффективны при рендеринге. Если художники немного больше узнают о том, что происходит внутри видеопроцессора, это может оказать большое влияние на частоту кадров игры. Если вы художник и хотите понять, почему для производительности важны такие аспекты, как вызовы отрисовки (draw calls), уровни детализации (LOD) и MIP-текстуры, то прочитайте эту статью. Чтобы учитывать то влияние, которое имеют ваши графические ресурсы на производительность игры, вы должны знать, как полигональные сетки попадают из 3D-редактора на игровой экран. Это значит, что вам нужно понять работу видеопроцессора, микросхемы, управляющей графической картой и несущей ответственность за трёхмерный рендеринг в реальном времени. Вооружённые этим знанием, мы рассмотрим наиболее частые проблемы с производительностью, разберём, почему они являются проблемой, и объясним, как с ними справиться.

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

Часть 1: конвейер рендеринга с высоты птичьего полёта

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

После экспорта сетки из 3D-редактора (Maya, Max и т.д.) геометрия обычно загружается в движок игры двумя частями: буфером вершин (Vertex Buffer, VB), содержащим список вершин сетки со связанными с ними свойствами (положение, UV-координаты, нормаль, цвет и т.д.), и буфером индексов (Index Buffer, IB), в котором перечислены вершины из VB, соединённые в треугольники.

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

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

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

• Входная сборка (Input Assembly). Видеопроцессор считывает буферы вершин и индексов из памяти, определяет как соединены образующие треугольники вершины и передаёт остальное в конвейер.
• Затенение вершин (Vertex Shading). Вершинный шейдер выполняется для каждой из вершин сетки, обрабатывая по отдельной вершине за раз. Его основная задача — преобразовать вершину, получить её положение и использовать текущие настройки камеры и области просмотра для вычисления её расположения на экране.
• Растеризация (Rasterization). После того, как вершинный шейдер выполнен для каждой вершины треугольника и видеопроцессор знает, где она появится на экране, треугольник растеризируется — преобразуется в набор отдельных пикселей. Значения каждой вершины — UV-координаты, цвет вершины, нормаль и т.д. — интерполируются по пикселям треугольника. Поэтому если одна вершина треугольника имеет чёрный цвет, а другая — белый, то пиксель, растеризированный посередине между ними получит интерполированный серый цвет вершин.
• Затенение пикселей (Pixel Shading). Затем для каждого растеризированного пикселя выполняется пиксельный шейдер (хотя технически на этом этапе это ещё не пиксель, а «фрагмент», поэтому иногда пиксельный шейдер называют фрагментным). Этот шейдер запрограммированным образом придаёт пикселю цвет, сочетая свойства материала, текстуры, источники освещения и другие параметры, чтобы получить определённый внешний вид. Пикселей очень много (целевой рендер с разрешением 1080p содержит больше двух миллионов), и каждый из них нужно затенить хотя бы раз, поэтому обычно видеопроцессор тратит на пиксельный шейдер много времени.
• Вывод целевого рендера (Render Target Output). Наконец пиксель записывается в целевой рендер, но перед этим проходит некоторые проверки, чтобы убедиться в его правильности. Глубинный тест отбрасывает пиксели, которые находятся глубже, чем пиксель, уже присутствующий в целевом рендере. Но если пиксель проходит все проверки (глубины, альфа-канала, трафарета и т.д.), он записывается в хранящийся в памяти целевой рендер.

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

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

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

float3 MaterialColor; 
Texture2D MaterialTexture; 
SamplerState TexSampler; 

float3 LightDirection; 
float3 LightColor; 

float4 MyPixelShader( float2 vUV : TEXCOORD0, float3 vNorm : NORMAL0 ) : SV_Target 
{ 
   float3 vertexNormal = normalize(vNorm);  
   float3 lighting = LightColor * dot( vertexNormal, LightDirection ); 
   float3 material = MaterialColor * MaterialTexture.Sample( TexSampler, vUV ).rgb; 

   float3 color = material * lighting; 
   float alpha = 1; return float4(color, alpha); 
}

Простой пиксельный шейдер, выполняющий расчёт базового освещения. Входные данные, такие как MaterialTexture и LightColor, передаются центральным процессором, а vUV и vNorm — это свойства вершин, интерполируемые по треугольнику при растеризации.

Вот сгенерированные инструкции шейдера:

dp3 r0.x, v1.xyzx, v1.xyzx 
rsq r0.x, r0.x 
mul r0.xyz, r0.xxxx, v1.xyzx 
dp3 r0.x, r0.xyzx, cb0[1].xyzx 
mul r0.xyz, r0.xxxx, cb0[2].xyzx 
sample_indexable(texture2d)(float,float,float,float) r1.xyz, v0.xyxx, t0.xyzw, s0 
mul r1.xyz, r1.xyzx, cb0[0].xyzx 
mul o0.xyz, r0.xyzx, r1.xyzx 
mov o0.w, l(1.000000) 
ret

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

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

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

Центральный процессор и вызовы отрисовки

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



Чтобы добиться этого, кадры часто выстраиваются в конвейер: ЦП занимает для своей работы весь кадр (обрабатывает ИИ, физику, ввод пользователя, анимации и т.д.), а затем отправляет инструкции видеопроцессору в конце кадра, чтобы тот мог приняться за работу в следующем кадре. Это даёт каждому из процессоров полные 33 миллисекунды для выполнения работы, но ценой этому оказывается добавление латентности (задержки) длиной в кадр. Это может быть проблемой для очень чувствительных ко времени игр, допустим, для шутеров от первого лица — серия Call of Duty, например, работает с частотой 60fps для снижения задержки между вводом игрока и рендерингом — но обычно лишний кадр игрок не замечает.

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


Здесь создание команд рендеринга у ЦП заняло слишком много времени для второго кадра, поэтому видеопроцессор начинает рендеринг позже и пропускает VSync.

Для отображения сетки ЦП создаёт вызов отрисовки, который является простой последовательностью команд, сообщающей видеопроцессору, что и как отрисовывать. В процессе прохождения вызова отрисовки по конвейеру видеопроцессора он использует различные конфигурируемые настройки, указанные в вызове отрисовки (в основном задаваемые материалом и параметрами сетки) для определения того, как рендерится сетка. Эти настройки, называемые состоянием видеопроцессора (GPU state), влияют на все аспекты рендеринга и состоят из всего, что нужно знать видеопроцессору для рендеринга объекта. Наиболее важно для нас то, что видеопроцессор содержит текущие буферы вершин/индексов, текущие программы вершинных/пиксельных шейдеров и все входные данные шейдеров (например, MaterialTexture или LightColor из приведённого выше примера кода шейдера).

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

Из-за этой нагрузки обычно приходится устанавливать верхний предел допустимого количества вызовов отрисовки на кадр. Если во время тестирования геймплея этот предел превышается, то необходимо предпринять шаги по уменьшению количества объектов, снижению глубины отрисовки и т.д. В играх для консолей количество вызовов отрисовки обычно ограничивается интервалом 2000-3000 (например, для Far Cry Primal мы стремились, чтобы их было не больше 2500 на кадр). Это кажется большим числом, но в него также включены специальные техники рендеринга — каскадные тени, например, запросто могут удвоить количество вызовов отрисовки в кадре.

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

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

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


Текстурный атлас из демо Infiltrator движка Unreal Engine

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

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

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


Кадр из XCOM 2, сделанный в RenderDoc. На каркасном виде (снизу) серым показана вся лишняя геометрия, передаваемая в видеопроцессор и находящаяся за пределами области видимости игровой камеры.

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

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

Однако всё меняется, когда дело доходит до затрат на вызовы отрисовки. Как сказано выше, важная причина этих затрат — дополнительная нагрузка, создаваемая драйвером при преобразовании и проверке ошибок. Это было проблемой очень долго, но у большинства современных графических API (например, Direct3D 12 и Vulkan) структура изменена таким образом, чтобы избежать лишней работы. Хоть это и добавляет сложности движку рендеринга игры, однако приводит к менее затратным вызовам отрисовки, что позволяет нам рендерить гораздо больше объектов, чем было возможно раньше. Некоторые движки (наиболее заметный из них — последняя версия движка Assassin's Creed) даже пошли совершенно в другом направлении и используют возможности современных видеопроцессоров для управления рендерингом и эффективного избавления от вызовов отрисовки.

Большое количество вызовов отрисовки в основном снижает производительность центрального процессора. А почти все проблемы с производительностью, относящиеся к графике, связаны с видеопроцессором. Теперь мы узнаем, в чём заключаются «бутылочные горлышки», где они возникают и как с ними справиться.

Часть 2: обычные «бутылочные горлышки» видеопроцессора

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


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

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



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

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

Профилирование

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

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


Базовый встроеннный профилировщик видеопроцессора движка Unity

Для PC есть довольно неплохие (хотя и специфичные для оборудования) инструменты профилирования, которые можно получить от производителей видеопроцессоров, например Nsight компании NVIDIA, GPU PerfStudio компании AMD и GPA Intel. Кроме того, существует RenderDoc — лучший инструмент для отладки графики на PC, но в нём нет функций расширенного профилирования. Microsoft приступает к выпуску своего потрясающего инструмента для профилирования Xbox PIX и под Windows, хоть только для приложений D3D12. Если предположить, что компания хочет создать такие же инструменты анализа «бутылочных горлышек», что и в версии для Xbox (а это сложно, учитывая огромное разнообразие оборудования), то это будет отличный ресурс для разработчиков на PC.

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

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

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

Инструкции шейдеров

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

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

Неудивительно, что наилучший способ оптимизации «бутылочных горлышек» в инструкциях шейдеров — выполнение меньшего количества инструкций! Для пиксельных шейдеров это означает, что нужно выбрать более простой материал с меньшим количеством характеристик, чтобы снизить число инструкций, выполняемых на пиксель. Для вершинных шейдеров это означает, что нужно упросить сетку для уменьшения количества обрабатываемых вершин, а также использовать LOD (Level Of Detail, уровни детализации — упрощённые версии сетки, используемые, когда объект находится далеко и занимает на экране мало места).

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

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


Кадр игры PIX с режимом визуализации перерисовки

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

Видеопроцессор предпринимает шаги по снижению перерисовки непрозрачных объектов. Начальный тест глубины (early depth test) (который выполняется перед пиксельным шейдером — см. схему конвейера в начале статьи) пропускает затенение пикселей, если определяет, что пиксель скрыт за другим объектом. Для этого он сравнивает затеняемый пиксель с буфером глубины (depth buffer) — целевым рендером, в котором видеопроцессор хранит глубину всего кадра, чтобы объекты могли правильно перекрывать друг друга. Но чтобы начальный тест глубины был эффективным, другой объект должен попасть в буфер глубины, то есть быть полностью отрендеренным. Это значит, что очень важен порядок рендеринга объектов.

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

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


Визуалиация перерисовки частиц взрыва в Prototype 2

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

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


Инструмент «вырезания» частиц в Unreal Engine 4

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

Очень близким по воздействию к перерисовке является излишнее затенение (overshading), причиной которого становятся мелкие или тонкие треугольники. Оно очень сильно может вредить производительности, напрасно тратя значительную часть времени видеопроцессора. Излишнее затенение — это последствие того, как видеопроцессор обрабатывает пиксели при затенении пикселей: не по одному за раз, а «квадами» (quads). Это блоки из четырёх пикселей, выстроенные квадратом 2x2. Так делается затем, чтобы оборудование могло справляться с такими задачами, как сравнение UV между пикселями для вычисления подходящих уровней MIP-текстурирования.

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


Пиксельный буфер 10x8 с квадами 5x4. Два треугольника плохо используют квады — левый слишком маленький, правый слишком тонкий. 10 красных квадов, которых касаются треугольники, должны быть полностью затенены, даже несмотря на то что на самом деле затенения требуют только 12 зелёных пикселей. В целом 70% работы видеопроцессора тратится впустую.

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

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

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

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

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

Доступ к памяти аналогичен скачиванию файлов из Интернета. На скачивание файла требуется какое-то время, зависящее от полосы пропускания (bandwidth) Интернет-подключения — скорости, с которой могут передаваться данные. Эта полоса пропускания общая для всех загрузок — если вы можете скачать один файл со скоростью 6МБ/с, два файла будут скачиваться со скоростью 3МБ/с каждый.

Это справедливо и для доступа к памяти: на доступ видеопроцессора к буферам индексов/вершин и текстурам требуется время, при этом скорость ограничена полосой пропускания памяти. Очевидно, что скорости намного быстрее, чем при Интернет-подключении — теоретически полоса пропускания видеопроцессора PS4 равна 176ГБ/с — но принцип остаётся тем же. Шейдер, обращающийся к нескольким текстурам, сильно зависит от полосы пропускания, ведь ему нужно передать все нужные данные вовремя.

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

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

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

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

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

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


Текстура на двух квадах, один из который близко к камере, а другой гораздо дальше


Та же текстура с соответствующей цепочкой MIP-текстур, каждая из которых в два раза меньше предыдущей

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

Вся изложенная выше информация должна привесли к каким-то очевидным шагам по снижению или устранению «заторов» полосы пропускания при оптимизации текстур с точки зрения художников. Следует убедиться, что текстуры имеют MIP и что они сжаты. Не нужно использовать «тяжёлую» анизотропную фильтрацию 8x или 16x, если достаточно 2x, или даже трилинейной/билинейной фильтрации. Снижайте разрешение текстур, особенно если на экране часто отображаются MIP-текстуры максимальной детализации. Не используйте без необходимости функции материалов, требующие доступа к текстурам. И проверяйте, что все получаемые данные на самом деле используются — не сэмплируйте четыре текстуры RGBA, если в реальности вам необходимы данные только красного канала, объедините эти четыре канала в одну текстуру, избавившись от 75% нагрузки на полосу пропускания.

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

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


Кадр из GTA V с картами теней, иллюстрация взята из отличного анализа кадра Адриана Корреже (оригинал статьи)

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

Последнее, о чём стоит упомянуть в отношении полосы пропускания памяти — это особый случай — Xbox. И у Xbox 360, и у Xbox One есть особая часть памяти, расположенная близко к видеопроцессору, называющаяся на 360 EDRAM, а на XB1 ESRAM. Это относительно небольшой объём памяти (10 МБ на 360 и 32 МБ на XB1), но он достаточно велик, чтобы хранить несколько целевых рендеров, и может быть некоторые часто используемые текстуры. При этом его полоса пропускания гораздо выше, чем у стандартной системной памяти (DRAM). Важна не только скорость, но и то, что эта полоса пропускания имеет свой канал, то есть не связана с передачами DRAM. Это добавляет сложности движку, но при эффективном использовании даёт дополнительный простор в ситуациях с ограничениями полосы пропускания. Художники обычно не имеют контроля над тем, что записывается в EDRAM/ESRAM, но стоит знать о них, когда дело доходит до профилирования. Подробнее об особенностях реализации в вашем движке вы можете узнать у 3D-программистов.

И многое другое...

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

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

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

Другие технические статьи

• Render Hell — Simon Trumpler
• Texture filtering: mipmaps — Shawn Hargreaves
• Graphics Gems for Games — Findings from Avalanche Studios — Emil Persson
• Triangulation — Emil Persson
• How bad are small triangles on GPU and why? — Christophe Riccio
• Game Art Tricks — Simon Trumpler
• Optimizing the rendering of a particle system — Christer Ericson
  
• Practical Texture Atlases — Ivan-Assen Ivanov
  
• How GPUs Work — David Luebke & Greg Humphreys
  
• Casual Introduction to Low-Level Graphics Programming — Stephanie Hurlburt
  
• Counting Quads — Stephen Hill
  
• Overdraw in Overdrive — Stephen Hill
  
• Life of a triangle — NVIDIA's logical pipeline — NVIDIA
  
• From Shader Code to a Teraflop: How Shader Cores Work — Kayvon Fatahalian
  
• A Trip Through the Graphics Pipeline (2011) — Fabian Giesen
  

Примечание: эта статья изначально опубликована на fragmentbuffer.com её автором Кейтом О'Конором (Keith O'Conor). Другие заметки Кейта можно прочитать в его твиттере (@keithoconor).

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

Видео-стрим: https://www.facebook.com/4CSPb/videos/1848773098785459/

Текстовая трансляция

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