Профессиональный фестиваль для тех, кто делает интернет
Фестиваль РИТ++ 2016 завершён. Изучайте презентации, смотрите фотографии и ждите видео :)

Заявки на доклады

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

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

Agile-battle

Agile мёртв (!|?)

Александр Сидоров

Недавно вышла статья "Agile мёртв" (https://www.linkedin.com/pulse/agile-dead-matthew-kern).
Мне хотелось бы рассказать о том, почему, на мой взгляд, это признак взросления agile и отрасли IT в целом.

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

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

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

Доклад принят в программу конференции

Миф об Agile: как это работает в реальности

Анатолий Стояновский

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

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

Доклад принят в программу конференции

Общая программа

Ездим на батарейках

Сергей Аверин

Что круче — Тесла или Лада Эллада?
Пассажирское квадрокоптер-такси.
На чем на самом деле выгоднее ездить — на бензине или на электричестве?
Ждет ли нас революция электротранспорта и, если ждет, то когда?
Какой транспорт самый популярный в мире?
Правда ли, что не ломается?
Ждут ли нас принципиально новые виды транспортных средств?
Как самому собрать электровелосипед?
Как не платить за электричество?
Бьет ли меня током, когда идет дождь?

Ответы на эти и многие другое вопросы — в моем докладе с теорией и практикой про личный опыт. Приходите. Будет интересно.

Доклад принят в программу конференции

Распознавание лиц в реальном времени по базам фотографий глобального масштаба

Артём Кухаренко
Александр Кабаков

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

Доклад принят в программу конференции

Как на самом деле всё устроено в государстве

Герман Клименко

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

Что стоит за теми или иными законами? Как на самом деле принимаются решения? Что хочет государство? Что оно может, а что не может? Что оно хочет, а чего оно не хочет?

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

Небольшой ликбез от Советника Президента Германа Клименко на конференции "Российские интернет-технологии".

Доклад принят в программу конференции

Digital pipeline — инновации в продажах

Михаил Токовинин

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

Доклад принят в программу конференции

Боты – проходящий тренд или реальное будущее?

Спикеры бот-секции

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

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

Могут ли NLP, распознавание речи, deep learning, новые мобильные платежные системы и другие важные вещи получить развитие за счет гипервнимания к ботам? Будем разбираться вместе.

Доклад принят в программу конференции

Воспитать в себе обезьяну: о том, как все успеть, не превращаясь в биоробота

Максим Дорофеев

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

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

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

Доклад принят в программу конференции

Процессы разработки

Аналитика мобильного проекта — проверяй и доверяй

Александр Лукин

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

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

Deep Dive в онтологию систем мобильной аналитики — как сделать свою и начать ей доверять.

Доклад принят в программу конференции

Архитектура

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

Александр Сычев

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

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

Доклад принят в программу конференции

Реализация бессерверного бэкенда мобильного приложения на базе AWS

Кирилл Потехин
Василий Сочинский

- Бессерверная архитектура бэкендов.
- Микросервисная архитектура.
- Мобильные бэкенды.
- Облачные технологии.

Доклад принят в программу конференции

Технологии iOS

Getting started with LLVM using Swift

Алексей Денисов

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

Цель моего доклада — рассказать о том, как использовать LLVM в связке с языком Swift и показать, что это не "rocket science".

В своем докладе я расскажу о том:

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

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

Доклад принят в программу конференции

Чистая архитектура с VIPER

Сергей Крапивенский

- Что такое "чистая" архитектура приложений. Чем грозит "грязная" архитектура, чем от нее отличается "чистая" архитектура, и какой от нее профит.
- История появления VIPER.
- Идея VIPER. Как изменяется структура приложения при применении этого подхода.
- Опыт использования VIPER в Rambler&Co. Что мы изменили и добавили.
- Работа с VIPER на примере user story из реального приложения.
- Выводы: чем помогает VIPER и когда его использовать не стоит.

Доклад принят в программу конференции

Типографика в iOS

Ирина Дягилева

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

В докладе мы рассмотрим не только возможности, которые предоставляет система для продвинутого форматирования, но и все тонкости, которые с этим связаны:
- основные термины типографики применительно к iOS;
- символьные атрибуты — какие из них наиболее подходят к конкретной задаче;
- отличия отрисовки текста в UITextView и UILabel;
- TextKit и способы расширения его возможностей.

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

Доклад принят в программу конференции

Оптимизация UI потока

Дмитрий Куркин

- WatchDog. Что это такое? Схема реализации с таймером и схема реализации на RunLoop'e.
- Как собирать результат работы WatchDog. Примеры того, что можно таким образом найти, и что мы нашли на проекте ICQ.
- Как работать с полученными результатами. Анализ стеков потоков. Профилирование с учетом расходов на синхронизацию.
- Проблемы при работе с WatchDog. Системные механизмы и популярные библиотеки, вызывающие проблемы. Методы обхода этих проблем. Итоговые параметры, применяемые на проекте ICQ.

Доклад принят в программу конференции

Удобный и расширяемый роутинг в iOS-приложении

Тимур Юсипов

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

Данная архитектура позволяет поддерживать DeepLink’и и iPad в существующем приложении, показывать плашки Push-уведомлений в верхнем видимом модуле, совершать переходы из верхнего видимого модуля, вызванные корневым модулем приложения, а также централизовано управлять анимацией переходов.

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

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

Доклад принят в программу конференции

Самочувствие malware на iOS устройствах

Дмитрий Евдокимов

В данном докладе рассмотрим, как сегодня чувствует себя вредоносный программный код на устройствах с ОС iOS без jailbreak. И конечно, ответим на вопрос о том, дают ли последняя версия ОС и отсутствие jailbreak на устройстве гарантию, что на нем нет вредоносного кода.

Доклад принят в программу конференции

Технологии Android

Security in Android Applications

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

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

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

Доклад принят в программу конференции

Пишем тестируемый код

Евгений Мацюк

1. Обзор паттернов и средств, которые применялись для построения архитектуры android приложений.
2. Обзор "новых старых" паттернов программирования, которые сейчас модны в построении архитектуры — Clean architecture, MVP, MVVM, DI. Краткий их обзор, чем они лучше/хуже предыдущих паттернов.
3. Обзор новых инструментов, которые сейчас используются при написании приложений — Dagger 2, RxJava и других.
4. Как все эти паттерны и инструменты помогут нам написать "тестируемый код".
5. Рассмотрение самых различных примеров, которые помогут понять, как конкретную задачу необходимо декомпозировать на различные уровни ответственности (какая часть должна быть в data, какая в business, какая в ui), и как должно происходить взаимодействие этих уровней. И как тесты помогают "выпрямлять" архитектуру.

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

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

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

Доклад принят в программу конференции

Как мы данные готовили: ORM и все-все-все в приложении Почта Mail.Ru

Кирилл Филимонов

1. Описание предметной области, объектов и понятий, с которыми работает приложение.
2. Выделение сущностей и связей между сущностями, представление в терминах ORM.
3. Описание конфигурации ORM и ObjectCache.
4. Работа с БД
- применение паттерна Команда и Компоновщик для выполнения операций на БД;
- конфигурация исполнителя команд;
- команда как транзакция в БД;
- инструменты, доступные ORMLite для реализации транзакций.
5. Проблема доступа из UI потока к данным, изменяемым в других потоках.
6. Memoization подход для решения проблемы доступа из разных потоков.
7. Описание архитектуры кэшей с применением memoization.
8. Задача поддержания когерентности кэшей;
- использование HaMeR framework для актуализации UI кэша;
- использование механизма блокировок и батч-операций над данными в кэшах.
9. Ограничения ORM ObjectCache при работе с объектами DAO.
10. Реализация DAO с расширенными возможностями работы с ObjectCache.

Доклад принят в программу конференции

Обработка голоса кодеком на Си под Андроид? Сделано!

Константин Цховребов

Opus, Ogg, NDK и другие подводные камни.

1) Зачем иногда необходимо использовать нативный код в Android разработке;
2) когда не нужно этого делать;
3) что для этого необходимо настроить в проекте;
4) кодек для сжатия аудио Opus (чем хорош, кто использует);
5) контейнер Ogg (преимущества перед другими);
6) практический пример записи голоса, сжатия кодеком opus и упаковка в Ogg контейнер.

Доклад принят в программу конференции

Кросс-платформенная разработка

Разработка кроссплатформенного фреймворка на С++ для мобильных платформ

Владимир Солдатов

В процессе разработки нашего Enterprise-ready продукта HyperHive — http://eigenmethod.com/products/hh/ (бренд EigenMethod создан для продвижения продукта на Запад, не удивляйтесь другому домену) мы столкнулись с необходимостью реализации ряда задач на нескольких платформах: iOS, Android, Cordova (Android и iOS), а в перспективе и под Windows для мобильных устройств.

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

Функционал фреймворка:
1. Параллельные потоки загрузки данных с сервера и записи в базу (sqlite) и передачи на сервер в рабочих потоках (без блокирования UI).
2. Поддержка Дельта-обновлений при передаче данных (пересылается только разность между двумя версиями данных).
3. Шифрование трафика и базы данных алгоритмами ГОСТ и RSA.
4. Сжатие трафика.
5. Аутентификация и авторизация на сервере, поддержка сессий.
6. Обработка push-уведомлений (MQTT).
7. API для мобильных приложений для предоставления данных, в том числе в оффлайн-режиме.
8. Логирование действий мобильного клиента на сервере.

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

Доклад принят в программу конференции

Успешный кейс использования React Native в продакшне

Евгений Федоров

— Космическая скорость разработки приложения (iOs-приложение за неделю);
— Сравнение типичного экрана со списком данных на Objective-C и React Native;
— Поддержка приложения, Debugging;
— Ограничения React Native, которые следует учитывать;
— Бонус: при написании приложения для iOs — 80% Android приложения в подарок :)

Доклад принят в программу конференции

Сопутствующие разделы

Последние новости постгреса с PGCon

Олег Бартунов, Александр Коротков, Федор Сигаев

Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.

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

Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.

Доклад принят в программу конференции

Теория программирования

Оптимизации уровня CPU

Андрей Акиньшин

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

В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.

Доклад принят в программу конференции

Ангелы и демоны многопоточного программирования

Алексей Федоров

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

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

Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.

Доклад принят в программу конференции

Автоматическая рубрикация текстов

Злата Обуховская

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

2. Тематическое моделирование.
2.1. Генеративные языковые модели.
2.2. Вероятностные латентно-семантические модели (pLSA).
2.3. Латентное размещение Дирихле (LDA).
2.4. Обзор инструментов для тематического моделирования.

3. Решение задач кластеризации и рубрикации на потоке новостных текстов.

Доклад принят в программу конференции

Тестирование, A/B-тестирование

AB-тестирование: на что следует обратить внимание

Артур Маликов

Основы AB-тестирования, история вопроса. Что необходимо для построения инфраструктуры AB-тестирования? Технические и пользовательские сложности при проведении AB-тестирования. Анализ результатов.

Рассмотрим несколько важных моментов:
- На что обратить внимание при выборе контрольной группы?
- Множественная проверка гипотез.
- Сколько экспериментов может видеть пользователь?

Какие инструменты вам могут понадобиться для проведения и анализа экспериментов?
Разберем несколько поучительных примеров.

Доклад принят в программу конференции

Малоизвестные грабли A/B тестирования и роль контрольных экспериментов

Роман Поборчий

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

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

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

Доклад принят в программу конференции

Построение моделей на примере продаж рекламы

Алексей Праслов

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

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

На что смотреть при внедрении результатов? Ведь модель, построенная на части пользователей, может изменится, когда вы примените её на 100% своей аудитории.

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

Доклад принят в программу конференции

Элементы архитектуры

Yet Another Web-accelerator

Александр Крижановский

Я расскажу про еще один Open Source Web-акселератор — Tempesta FW. Уникальность проекта в том, что это гибрид Web-акселератора и файервола, разрабатываемый специально для обработки и фильтрации больших объемов HTTP трафика. Tempesta FW встроена в TCP/IP стек Linux и несет в себе легкую in-memory оптимизированную для NUMA-систем базу данных для хранения Web-кэша и правил фильтрации. Основные сценарии использования системы — это защита от DDoS прикладного уровня и просто доставка больших объемов HTTP трафика малыми затратами на оборудование.

В докладе я расскажу про:
- зачем нужен еще один Web-акселератор, и в чем его отличие от Nginx, Varnish, HAProxy и даже TUX и kHTTPd;
- типовые сценарии использования (CDN, cloud, фильтрующие сети и пр.);
- основные фичи (кэширование, балансировку нагрузки, фильтрацию);
- частые вопросы, связные с реализацией проекта в ядре ОС, производительностью и надежностью;
- системные требования, примеры конфигураций и, просто, как это все собрать и запустить.

Доклад принят в программу конференции

Успеть за 100 миллисекунд: контекстная реклама на Sphinx

Дмитрий Хасанов

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

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

Доклад принят в программу конференции

noBackend, или Как выжить в эпоху толстеющих клиентов

Николай Самохвалов

Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.

Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).

Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.

Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.

Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день доклада.

Доклад принят в программу конференции

Архитектура поиска в Avito

Андрей Смирнов

Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.

Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!

Доклад принят в программу конференции

Сравнение форматов и библиотек сериализации

Антон Рыжов

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

Мы протестировали разные реализации статически (thrift, protocol buffers) и динамически (json, msgpack) типизированных протоколов для python; сравнили их производительность в разных сценариях, возможности, внутреннее устройство, удобство разработки.

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

Доклад принят в программу конференции

Основные кейсы использования in-memory СУБД на примере Тарантула и проектов Mail.Ru Group

Денис Аникин

Основные кейсы использования Тарантула:

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

2. Когда нужна реал-тайм OLAP-система. Т.е. когда нужно супероперативно принимать решения (желательно в реал-тайме), собирая и анализируя информацию по многим источникам. Примеры: фича "уберись в ящике" в Почте@Mail.Ru, почтовый общий и персональный антиспам, система показа рекламы, любые системы, касающиеся классификации и кластеризации данных, которые должны работать в онлайне.

3. Когда текущая СУБД стоит слишком дорого по серверам или лицензиям, и есть желание заменить ее на нечто, что будет в десятки, если не сотню раз более экономное (за счет отсутствия лицензии и за счет радикального снижения количества железа). Можно эту СУБД заменить на Тарантул.

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

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

6. Когда текущая СУБД и/или кэш не позволяют в полном объеме реализовать необходимую логику внутри и использовать их как application server. Можно эту СУБД и/или кэш заменить на Тарантул или можно новые фичи разрабатывать Тарантул, не теряя старых решений (Тарантул умеет интегрироваться и реплицироваться в обе стороны с любыми решениями за счет полноценного алгоритмического языка внутри с мощным сетевым SDK).

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

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

Именно так и появился Тарантул — одна из самых быстрых баз данных в мире, которая широко применяется в Mail.Ru Group и за её пределами.

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

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

Доклад принят в программу конференции

Централизованное управление правами доступа на базе ABAC

Вячеслав Муравлев

Для IТ-ландшафта крупной компании или предприятия характерны следующие особенности:
- используется большое число информационных систем (ИС);
- сквозные бизнес-процессы «проходят» через несколько IТ-систем;
- пользователи выполняют различные операции в разнообразных системах;
- в каждой системе есть свои настройки прав доступа и своя процедура аутентификации.

Нередко в ИС управление правами доступа осуществляется с помощью классического подхода на основе ролей (Role-Based Access Control, RBAC). Однако при использовании классического варианта RBAC возникают потребности в более гибких и гранулированных ограничениях доступа (например, на уровне записей в БД). Это приводит к появлению дополнительной логики и/или настроек в самой ИС, что усложняет сопровождение и развитие системы, повышает накладные расходы, снижает оперативность процессов управления правами и т.п.

Существует подход, решающий данные проблемы посредством управления правами доступа на основе атрибутов — Attribute-Based Access Control (ABAC). В этом случае права доступа формулируются в виде политик (наборов правил), составленных с использованием различных атрибутов бизнес-сущностей, среды окружения, реквизитов пользователя и т.п. Список атрибутов может быть настроен в соответствии с потребностями ИС. Это позволяет расширять возможности правил по мере необходимости. Политики и правила размещаются в централизованной системе управления доступом, и ИС обращаются к ней с запросами на авторизацию действий бизнес-пользователей.

В настоящее время существует стандарт OASIS, описывающий формат таких правил доступа и компонентов систем управления правами доступа на основе этих правил: eXtensible Access Control Markup Language (XACML). Существуют продукты, поддерживающие данный стандарт: бесплатный WSO2 Balana и коммерческий Axiomatics Policy Server.

Для использования системы управления доступом на основе ABAC архитектура ИС должна быть соответствующим образом спроектирована: вся авторизация действий должна осуществляться посредством обращения к системе управления доступом, анализа ответа от нее и принятия соответствующего решения о разрешении или запрете доступа. Для разрабатываемых с нуля ИС такую схему авторизации можно заложить на этапе проектирования. С точки зрения стоимости разработки ИС такой вариант сопоставим с вариантом, когда для ИС создается своя система управления доступом (а возможно, окажется и дешевле). Но для существующих ИС переход на ABAC может оказаться весьма дорогостоящим. Как правило, в них уже реализованы механизмы управления правами на основе RBAC, также возможна ситуация, когда ИС подключены к централизованной системе управления доступом (например, Oracle Identity Manager).

Мы в CUSTIS реализовали решение для управления доступом, основанное на гибридном подходе. Оно позволяет получить преимущества ABAC в существующих ИС, использующих RBAC подход, не меняя их существенным образом. Специальный компонент решения, получая на вход политики с правилами в формате XACML, преобразует их в команды управления доступом для существующих ИС в терминах RBAC. Для исполнения этих команд в решение включены интеграционные компоненты для целевых ИС. Для новых ИС решение предоставляет типовую функциональность управления доступом на основе ABAC, предусмотренную стандартом XACML.

Данное решение было развернуто в рамках внутренней инфраструктуры компании. К нему были подключены системы ERP, IssueTracker и Active Directory. Для централизованного хранения информации о пользователях и правах был использован Oracle Identity Manager.

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

Программный комитет ещё не принял решения по этому докладу

Чему мы научились, разрабатывая микросервисы?

Вадим Мадисон

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

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

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

Расскажу, какие тулзы мы в итоге используем, а от каких отказались.

Доклад принят в программу конференции

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

Олег Анастасьев

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

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

Доклад принят в программу конференции

Испытание поединком: PostgreSQL vs MySQL

Александр Чистяков
Даниил Подольский

Кто пишет тезисы, тот и прав, а кто выступает на стороне PostgreSQL, тот прав вдвойне. Когда я (Александр Чистяков) в момент старта очередного нового проекта узнал, что мой старший коллега (Даниил Подольский) хочет использовать MySQL в продакшне, я встал и сказал себе: "Хватит это терпеть!". Вероятно, я сказал слишком громко, потому что Даниил услышал, и мы еще с час обсуждали вопросы применимости РСУБД в современных проектах в общем чате, пугая Заказчика.

Тем не менее, нам ничего не оставалось, кроме как договориться о публичном поединке. Мы представим на суд общественности результаты нагрузочного тестирования двух этих замечательных РСУБД, поставленных в одинаковые, но жесткие условия современного веб-проекта. Мы идентифицировали несколько распространенных профилей нагрузки, и написали генератор нагрузки на (не очень) любимом нами языке Golang. В остальном правила поединка просты: правил нет никаких, и я уже придумал пару сценариев использования, на которые MySQL просто не способен!

Доклад принят в программу конференции

Организация программного кода

О фреймворках

Роман Ивлиев

Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.

Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.

Доклад принят в программу конференции

Рабочие ситуации и задачи

Как сделать свой SDK и первые 50 расширений: от подпольных технологий к интеграциям

Владимир Лихтанский

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

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

Доклад принят в программу конференции

Практика применения Pinba в Badoo

Денис Карасик

При разработке каждого backend приложения рано или поздно встает вопрос об измерении производительности системы и поиска «узких» мест. Для этой цели мы используем Pinba.

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

Основные аспекты доклада:
- измерение производительности php скриптов;
- измерение времени обращений к внешним сервисам;
- измерение «хитрейта» кэша;
- измерение производительности обработки очередей;
- построение распределений и использование перцентилей.

Я расскажу о том, как использовать Pinba в связке с Nginx и делать различные агрегации в зависимости от параметров URI.

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

Доклад принят в программу конференции

Платежная система за год

Филипп Дельгядо

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

Расскажу об особенностях платежных систем, опишу причины выбора основных архитектурных решений (Java, PostgreSQL, сервисы) и особенности процесса разработки.

Основные интересные моменты, на которых остановлюсь подробнее:
1) как решать популярные проблемы с БД и что делать, если не хватает IOPS;
2) какую надежную очередь стоит использовать;
3) какие нестандартные практики были успешными: IDE driven development, JSON вместо ORM, Functional test вместо Unit test;
4) какие решения были неправильными: PyTest, Spring Security, docker, велосипеды, разработчики, магия;
5) зачем менять методологию разработки три раза за год — и почему во многих проектах это тоже стоит делать.

Надеюсь, часть из сказанного вызовет несогласие и дискуссию.

Доклад принят в программу конференции

Адаптация

Как мы адаптировали более 150 сайтов по технологии JavaScript-adaptive

Артём Цымпов
Евгений Кольцов

° С чего мы начинали;
° Все способы адаптации;
° JavaScript-adaptive;
° Опыт создания собственной библиотеки;
° История панели управления;
° Сервис оптимизации изображений;
° Чему мы научились.

Доклад принят в программу конференции

Приложения

Как мы разрабатываем новый фронтенд Tinkoff.ru

Филипп Нехаев

Недавно запустили новый сайт Тинькофф.

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

Сейчас tinkoff.ru насчитывает более 3000 компонентов и сотни страниц.

Доклад принят в программу конференции

CSS-методологии от О до Б

Алексей Охрименко

Что отличает обычного верстальщика от сильного? Знание новых технологий, опыт работы, сильные мышцы?

Нет, главное отличие — это способность воспользоваться правильной CSS-методологией.

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

Программный комитет ещё не принял решения по этому докладу

Жизнь HTML в 2ГИС под iOS

Роман Янке

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

Доклад принят в программу конференции

Amazing threesome, rrr... React. Redux. Real world

Ростислав Галкин

"Все гениальное просто" — таким бы мог быть слоган Redux, одной из имплементаций FLUX-архитектуры, которой 31 мая исполняется ровно год. И вот уже практически год, как мы приняли решение использовать Redux в наших проектах. Это был осознанный риск, о котором мы ничуть не пожалели.

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

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

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

Доклад принят в программу конференции

Стабильность WebGL приложений

Кирилл Дмитренко

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

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

Доклад принят в программу конференции

Качество

Как отвечать за продакшн

Андрей Сумин

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

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

1. Логирование.
2. Мониторинг.
3. Алертинг.
4. Бета-пользователи.
5. Саппорт.
6. Плагины.
7. Антивирусы.
и т.п.

Доклад принят в программу конференции

В погоне за производительностью. Психология пользователя

Денис Мишунов

“Страница должна загружаться быстрее чем за 1 секунду; количество серверных запросов должно быть сведено к минимуму; CSS и JS файлы должны быть сжаты и не превышать 50 килобайт…” — это лишь малая часть технических решений и рекомендаций, которыми нас снабжает индустрия в погоне за производительностью. Но во всем этом есть одна проблема — пользователям нет никакого дела до килобайтов, миллисекунд и количества запросов.

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

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

Доклад принят в программу конференции

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

Алексей Зиновьев

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

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

Программный комитет ещё не принял решения по этому докладу

Радости и гадости регрессионного тестирования вёрстки

Алексей Малейков

Совместно с университетом ИТМО мы запустили курс, посвященный основам HTML и CSS. Уже на момент регистрации на этот курс записалось более 12 тысяч студентов. Перед нами стояла задача разработать систему, которая будет автоматически проверять итоговые проекты на соответствие заранее подготовленному макету. В качестве основной техники для проверки было выбрано регрессионное тестирование.

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

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

Доклад принят в программу конференции

Организация конвейера автоматизации тестирования

Алексей Петров

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

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

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

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

Доклад принят в программу конференции

UX-дизайнер, ты ли это? Навыки проектировщика в стилизации интерфейсов

Илья Бовкунов

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

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

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

Доклад принят в программу конференции

Новинки

Как мы ускоряли WebGL

Мстислав Живодков

Если вы захотите сделать веб-приложение с использованием технологии WebGL, скорее всего, вы захотите также, чтобы это приложение было отзывчивым и быстро работало даже на медленных компьютерах.

Но если вы простой фронтендер, занимаетесь js, html и css, то 3D-графика для вас покажется совершенно иным миром со своими законами. Так это случилось с нами во время разработки нашего продукта.

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

Доклад принят в программу конференции

Tacit, CSS Framework Without Classes

Yegor Bugayenko

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

Tacit — это первый в своем роде CSS фреймворк, который дает возможность создавать приятные HTML документы, без какого-либо участия CSS классов и стилей. Tacit был очень положительно воспринят на Hacker News и набирает популярность: https://news.ycombinator.com/item?id=10367681

HTML5 is a perfect language for structuring data, texts, information, numbers, dates, etc. CSS is what makes it look nice. But is it really necessary to bloat HTML with classes and style information in order to make it look attractive? Not really.

Tacit is the first CSS framework that makes it possible to make attractive web pages without using any styles and classes in HTML. See https://news.ycombinator.com/item?id=10367681

Программный комитет ещё не принял решения по этому докладу

Что делать, когда костыли уже не помогают? Опыт tutu.ru

Роман Грунтович

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

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

- Что такое реинжиниринг и зачем он был нужен в tutu.ru.
- Как мы подошли к выбору нового технологического стека.
- Как мы выбрали архитектуру новых приложений.
- Почему мы пришли к TypeScript и React.
- Шаблонизатор для компонентов Reactа, серьезно?
- Выкидывать legacy код жестоко, но нужно же с ним что-то делать.
- Как удовлетворить seo без лишних усилий.

Доклад принят в программу конференции

Vue.js и его брат-близнец Vue-server.js

Андрей Солодовников

Современный Веб всё больше стремится к динамичным, похожим на приложения, сайтам.
Оперативно строить быстрый и динамичный интерфейс на проекте N1.RU нам помогает Vue.js.
Однако, как и многие современные библиотеки и фреймворки, Vue.js не умеет рендериться на сервере.
При этом иметь такую возможность бывает полезно по нескольким причинам: начиная от вопросов SEO и заканчивая красотой загрузки страницы.
Чтобы реализовать такую возможность для Vue.js мы создали его дополнение — Vue-server.js.

Я расскажу о том, что умеет Vue.js, что у нашего дополнения "под капотом", почему мы выбрали такой путь и как, вообще, всё это работает. А ещё попробую дать критическую оценку проделанной работе.

Доклад принят в программу конференции

base.network — пиринговый веб на JavaScript

Денис Глазков

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

Доклад посвящен новому open-source проекту — base.network — распределенному независимому пиринговому вебу. Расскажу про общую схему работы сети, немного о работе с криптографией на JavaScript, о создании приложений на JavaScript без использования центральных серверов.

Доклад принят в программу конференции

React: новая эра фронтенд разработки

Роберт Харитонов

React(JS) — это современная библиотека для разработки UI компонентов от Facebook, по праву считающаяся самой трендовой технологией среди JavaScript разработчиков на 2015/16 год.

Но каким образом React стал настолько популярен в среде разработчиков, учитывая что библиотека покрывает только View из необходимого минимума MVC архитектуры? Ответ таится в экосистеме технологий, в рамках которой нам открываются совершенно новые способы разработки приложений, не только для веба, но и нативных платформ с родным UI (iOS, Android, Win 10, OSx).

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

Доклад принят в программу конференции

Пользовательские свойства как основа архитектуры CSS

Павел Ловцевич

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

- Всесильны ли препроцессоры?
- Можно ли дать CSS второй шанс?
- Наследуемость или БЭМ?
- А что с обратной совместимостью? Решение есть!

В рамках доклада будут детально рассмотрены практические примеры применения CSS Custom Properties. Также будут рассмотрены новые спецификации CSS Extensions (Сustom selectors) и CSS @apply Rule в рамках перспективы отказа от препроцессоров.

Доклад принят в программу конференции

Angular 2 не так уж и плох... А если задуматься, то и просто хорош

Алексей Охрименко

Не так страшен Angular 2, как его малюют.

Первая реакция о нем весьма негативная. Круглые скобочки, квадратные, что это, зачем? Но что, если я вам скажу, что эти скобочки позволяют избавиться от проблем, которые не может решить React v15.x?

Знаете ли вы, что Angular 2 ближе к функциональному программированию, чем Redux?

В этом докладе мы обсудим:
1) Что нового даёт нам Angular 2?
2) Рассмотрим его архитектуру и поймём ценность этих решений.
3) Реактивное программирование с Angular 2.
4) В чём Angular 2 превосходит React и Redux?
5) Как перейти на Angular 2 и спать спокойно.

Доклад принят в программу конференции

Инструменты

Как мы Backbone защищали

Нарек Мкртчян

— Почему Backbone.
— Альтернативные решения.
— Преимущества и недостатки.
— Спорные вопросы (SEO, SMM, кроссбраузерность).
— Как убедить менеджеров.
— Как убедить дизайнеров.
— Как убедить бэкенд-разработчиков.
— Свобода.

Программный комитет ещё не принял решения по этому докладу

Библиотека UI компонентов, о которой вы всегда мечтали

Роберт Харитонов

Уже много лет все говорят о компонентном вебе и мире, где новые интерфейсы строятся из готовых блоков на раз-два, но чего мы в итоге достигли? Пока БЭМ, Polymer, Angular и создатели других технологий ищут лучшие пути организации клиентского кода, создавая сложные абстракции, сообщество React уже давно наслаждается отличными и простыми инструментами для работы с UI компонентами.

В рамках доклада Роберт поделится опытом мирового React-сообщества в создании удобных и простых в обращении библиотек UI компонентов.

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

Доклад принят в программу конференции

Классические архитектуры во фронтенде

Александра Шинкевич

Responsive web design, HTML5, CSS3, IDE, API, React, Angular, веб-компоненты, БЭМ... Опытным фронтендерам эти слова давно знакомы. А как насчет таких классических архитектур как MVC, MVP или MVVM? Знаете ли вы, что такое MVP, и почему Angular.js построен на паттерне MVVM, а не MVC, хотя в этом фреймворке активно используется понятие "контроллер"? Чем эти три архитектуры отличаются друг от друга, и зачем, вообще, о них нужно знать фронтендеру?

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

Доклад принят в программу конференции

55+1 прием для улучшения JavaScript-кода

Татьяна Бабич

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

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

Доклад принят в программу конференции

МРТ для данных

Анастасия Горячева

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

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

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

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

Доклад принят в программу конференции

Конструктор

Денис Паясь

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

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

Стала закрадываться мысль, что пора что-то менять. И мы поменяли.

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

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

Доклад принят в программу конференции

Основная программа

Что делать, если пришел DDoS или Antiflood для бедных

Юрий Колесов

1. Введение
Тема DDoS атак “сетевого” уровня (L4 и ниже) заезжена и раскрыта. Обычно эти атаки такой мощности, что справиться с ними server-side невозможно — они забивают канал на 100%.
Но есть атаки, которые влезают в канал и наносят не меньший урон. Это DDoS атаки на приложение, http flood. В случае атак на приложение сайт/сервер обычно ложится значительно раньше, чем будет забит канал. Такая атака тоже может забить канал, например, с помощью worpress xml rpc amplification (https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html). В этом случае меры борьбы такие же, как с атаками сетевого уровня.
Даже если вы используете сервис, который вас проксированием защищает от DDoS, этот материал будет полезен — сервисы часто пропускают флуд в количествах, достаточных чтобы вы испытывали трудности.

2. КАК ПОНЯТЬ, ЧТО ПРИШЕЛ DDoS
Так как этот доклад я читаю на конференции Highload, предполагаю что у вас есть мониторинг.
Полезные метрики, по которым можно предположить, что вас атакуют:
- Внешний мониторинг: проблемы с доступностью, ошибки, значительное замедление отдачи страниц, потери пакетов.
- “Внутренний” мониторинг: количество запросов в секунду, загрузка CPU, LA, количество запущенных процессов (если бэкенд форкается), загрузка сетевого интерфейса.

3. ЧТО ДЕЛАТЬ, ЕСЛИ ОНО СЛУЧИЛОСЬ
Обычная практика — анализ логов самописными скриптами или, например, fail2ban. Далее iptables/ipset. Недостатки — ресурсоемко, трудоемко, много ложноположительных срабатываний, трудно поддерживать списки.
Я использую возможности nginx. Это geoip, лимиты, модуль test_cookie.

3.1 ЧТО НУЖНО СДЕЛАТЬ ЗАРАНЕЕ
Чем быстрее работает ваш сайт, тем сложнее его заддосить http флудом. Первое действие — ускорение отдачи страниц. Особое внимание уделить скорости генерации 404 ошибки и формам.
Запретите методы, отличные от HEAD, GET. Разрешите POST (PUT и т.д.) только там, где он должен быть.
Настройте geoip. Добавьте в лог запись страны. Предусмотрите в конфиге map для блокирования по странам.
Выделите в конфиге nginx location, которые отдают статику и динамику. Расставьте разумные лимиты на число коннектов с одного ip, на число запросов к статике и динамике. Выделите “тяжелые” страницы в отдельные location. Добавьте отдельный лог на динамику, сэкономите время на grep в случае проблем.
Сделайте настройки для кэширования средствами nginx. Можно и нужно кэшировать POST. Кэширование можно не включать, но настроить. Лимиты, кстати, тоже.

3.2 ЧТО ДЕЛАТЬ, ЕСЛИ ПРИШЕЛ DDoS
Если сервер нагружен так, что вы ничего не в состоянии делать — отключайте веб. Вы все равно практически лежите, но на еле работающем сервере вы будете разбираться намного дольше. Отключайте бэкенд — апач/php-fpm/unicorn и т. д. — то, что создает нагрузку.
Далее беглый взгляд на логи. Если вы не ФБ — в логах еще можно разбираться “глазом” и грепом. Вам нужно либо отгрепать запросы на динамику, либо посмотреть в тот самый отдельный лог. Иногда сразу видно флуд, особенно, если вы представляете, как выглядит ваш обычный лог. Иногда не видно, тогда просто смотрите, каких запросов прибавилось. Возможно это не DDoS, а хабраэффект). Далее можно резать по странам, включать (или уменьшать) лимиты, запрещать часть функционала, включать кэширование (на часть функционала).
Отдельно стоит test_cookie. Это последний рубеж обороны, если вы уверены, что вас атакуют боты, но атаку вы выявить не в состоянии — шаблон постоянно меняется или ботнет слишком велик, лимиты не спасают, geoip тоже.
В каком объеме рассказывать про него — буду смотреть по времени. Скорее всего, совсем обзорно.

Доклад принят в программу конференции

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

Иван Михеев

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

Осветим:
- Самые эффективные приемы по оптимизации производительности сайта.
- Ускорение сайта при помощи перевода сложных live-процессов в планировщик.
- Методы поиска медленных запросов к БД и оптимизация скорости работы БД.
- Профилирование кода с помощью xdebug и xhproof.
- Оптимизация frontend и статики.

Доклад принят в программу конференции

Как Web-акселератор акселерирует ваш сайт

Александр Крижановский

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

Еще я расскажу про еще один Open Source Web-акселератор - Tempesta FW. Уникальность проекта в том, что это гибрид Web-акселератора и файервола, разрабатываемый специально для обработки и фильтрации больших объемов HTTP трафика. Основные сценарии использования системы — это защита от DDoS прикладного уровня и просто доставка больших объемов HTTP трафика малыми затратами на оборудование.

- Что такое Web-акселератор, зачем он был придуман и как понять когда он нужен;
- Типичный функционал reverse proxy, его отличия от Web-сервера;
- Упомянем про SSL акселераторы;
- Заглянем вглубь HTTP, и как он управляет кэшированием и проксированием, что может быть закэшированно, а что - нет;
- Мы сравним наиболее популярные акселераторы (Nginx, Varnish, Apache Traffic Server, Apache HTTPD, Squid) по фичам и внутренностям;
- Зачем нужен еще один Web-акселератор Tempesta FW, и в чем его отличие от других акселераторов.

Доклад принят в программу конференции

Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh

Миша Кириллов

Разговор в докладе пойдёт о веб-программировании.

При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.

Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.

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

Доклад принят в программу конференции

Презентация рейтингов сервисов и технологий для разработчиков, Тэглайн-2016

Алексей Раменский

Тэглайн представит ряд уникальных рейтингов сервисов и технологий, использующихся при разработке веб-сервисов и заказных проектов в digital.
Исследование сформировано на основе онлайн-анкетирования 1 000+ владельцев и топ-менеджеров digital-агентств и продакшнов с производством и/или клиентским офисом в России. Данные собирались с августа 2014 по апрель 2016. Это первая в России серия рейтингов, построенная по такому большому количеству сегментов рынка и с привлечением невероятного количества респондентов.
Мы представим рейтинги по следующим кластерам: wiki-системы, мессенджеры для работы, таск-трекинг, хостинг-панели, инструменты для дизайна и проектирования, репозитории для хранения кода, языки программирования, backend- и frontend-фреймворки, среды разработки (IDE), СУБД (базы данных), системы контроля версий, серверные операционные системы, мобильные платформы / ОС, краш-репортеры, сервисы для тестирования и сбора статистики мобильных приложений.

Программный комитет ещё не принял решения по этому докладу

Жизнь проекта на production: советы по эксплуатации

Николай Сивко

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

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

Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.

Доклад принят в программу конференции

Кластеры баз данных: делаем сложные вещи просто

Андрей Тихонов

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

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

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

План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказоустойчивость с помощью внутренних механизмов репликации БД и HAProxy.

Доклад принят в программу конференции

Всему своё время

Роман Ивлиев

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

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

Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?

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

P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)

Доклад принят в программу конференции

Мониторинг веб-проектов: real-time мониторинг и аналитика, поиск ошибок и "боевая" отладка

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

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

В докладе рассмотрим:
- Явные и не очень потери на медленном / недоступном сайте.
- Общие принципы внедрения систем real-time мониторинга.
- Мониторинг нетипичных характеристик (наличие бэкапов, делегирование домена и т.п.).
- Автоматизацию типовых реакций на алерты.
- Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до того, как они случатся).
- Инструменты и общие подходы быстрого поиска "узких" мест.

Доклад принят в программу конференции

10 способов достижения HighLoad'а и BigData на ровном месте

Илья Космодемьянский

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

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

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

Доклад принят в программу конференции

Организация надежного резервного копирования веб-проекта. Практика и подводные камни

Антон Баранов

1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.

2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.

3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.

4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.

Доклад принят в программу конференции

Сайт Москвы за 6 месяцев

Игорь Цупко

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

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

Кроме прочего, будет рассказано:
- как мы сделали гибкую архитектуру в mos.ru. Angular и API сервисов, индексация поисковыми машинами и мобильные приложения;
- причём тут Битрикс;
- типовые сервисы на Yii2. Как за 1-3 дня разворачивать микросервисы с админкой на Angular;
- загрузка файлов в сервисном облаке — куда же класть файлы в многосерверной системе;
- поиск по сервисам — какой способ проще, а какой правильнее.

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

Доклад принят в программу конференции

Принципы автоматического масштабирования приложения в AWS

Антон Регеда

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

Как в таком случае правильно вооружиться облачными технологиями? В чём магия AWS Autoscale и как стать магом?

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

Доклад принят в программу конференции

Очереди и блокировки. Теория и практика

Александр Календарев

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

Описано применение синхронных и асинхронных очередей, как построить очереди с приоритетами.

Будет сравнение разных серверов очередей: Redis, Tarantool, RabbitMQ, ZMQ, Kafka, Zookeeper, MemcacheQ и др., их преимущества и недостатки, где и какой брокер лучше использовать.

Доклад принят в программу конференции

Как сравнить и выбрать хостинг-провайдера, или О чем умалчивают маркетологи

Игорь Мызгин

Под словосочетанием "услуги хостинга" в настоящее время подразумевается очень много различных услуг: VPS/VDS/аренда оборудования/облака/IaaS/PaaS/SaaS/колокейшн и каждая из этих услуг имеет очень много вариаций и реализаций у каждого провайдера. Любой проект имеет две условные стадии: 1) разработка, 2) production, и если среду разработки можно почти безболезненно переносить от провайдера к провайдеру, то перенос production зачастую сопряжен с трудностями.

В данном докладе будут рассмотрены следующие классы услуг:
1) "виртуальные сервера"/ VDS/ VPS/ облачные услуги/ "клауд".
2) аренда физических серверов и сопутствующие сервисы.

По каждому классу услуг будут:
1) описаны типовые нюансы, которые позволяют маркетологам провайдеров приукрасить свои предложения, при этом не допуская откровенной лжи в рекламе;
2) даны рекомендации — как в цифрах сравнить двух провайдеров одного класса услуг; также будут даны основные метрики, по которым стоит проводить сравнение;
3) указано, на что обратить внимание, а что является маркетинговой "фичей", которой гордится провайдер, но которая не нужна пользователям;
4) даны рекомендации, как оценить TCO для вас и вашего проекта, чтобы избежать при эксплуатации "откуда такие суммы в счете?!?! на сайте же обещали все за копейки!!!".

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

Доклад принят в программу конференции

Centrifugo — open-source сервер real-time сообщений

Александр Емелин

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

В выступлении будут освещены транспорты и протоколы для трансфера real-time сообщений от сервера клиенту, существующие open-source решения, подводные камни на пути к работающему в боевой среде решению. От HTTP транспортов/протоколов мы перейдем к WebSocket’ам и затронем стандарт HTTP/2 в контексте применения для данной задачи.

Во второй части доклада я расскажу об open-source сервере real-time сообщений Centrifugo (https://github.com/centrifugal/centrifugo). Сервер написан на языке Go и обладает уникальными особенностями “из коробки”, выделяющими его из толпы (http://www.leggetter.co.uk/real-time-web-technologies-guide/) подобных решений:

- простота в использовании и интеграции с приложением. Сервер не завязан на язык программирования, предоставляя API для взаимодействия — таким образом, он может быть полезен разработчикам приложений на любом языке/фреймворке;
- возможность балансировки клиентов на несколько инстансов сервера;
- история сообщений в каналах, восстановление потерянных сообщений при кратковременных потерях соединения, информация о пользователях в канале, сообщения о подписке/отписке пользователя на канал;
- готовность к деплою — DEB/RPM-пакеты, docker-контейнер;
- возможность использовать с десктопными и мобильными приложениями.

Центрифуга используется в Mail.Ru и нескольких проектах по всему миру.

Доклад принят в программу конференции

NoSQL — неспроста ли это "ЖЖЖ"?

Даниил Подольский

NoSQL — это слово громко "жужжит".

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

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

Попробуем еще раз.

NoSQL — это именно декларация отказа от некоторых паттернов.

- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?

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

Доклад принят в программу конференции

Непрерывное развертывание и деплой

Релиз инжиниринг Mail.ru, взгляд изнутри

Максим Глеков

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

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

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

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

Доклад принят в программу конференции

Кит на службе у человека: microPaaS Deis

Алексей Медведчиков

Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.

Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.

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

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

Доклад принят в программу конференции

Лучшие практики Continuous Delivery с Docker

Дмитрий Столяров

Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.

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

В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.

Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?

Доклад принят в программу конференции

Мой маленький уютный PaaS

Илья Беда

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

В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.

Доклад принят в программу конференции

DC/OS — больше чем PaaS

Никита Борзых

Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.

Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.

Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.

Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.

Доклад принят в программу конференции

Логирование и мониторинг

Bosun: современный мониторинг

Дима Медведев

Доклад о Bosun (http://bosun.org) — мониторинге от StackExchange и его использовании в https://www.onetwotrip.com/ за 1,5 года.

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

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

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

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

Доклад принят в программу конференции

Prometheus: мониторинг микросервисных приложений

Виталий Левченко

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

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

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

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

Доклад принят в программу конференции

Event-based self-healing monitoring

Кирилл Сотников

- AWS Lambda;
- AWS SNS;
- Self-healing;
- СМС-ки не нужны;
- Кронтаб не нужен.

Доклад принят в программу конференции

Путь мониторинга 2.0: всё стало другим

Всеволод Поляков

Обзор мониторинга в Grammarly, о котором я докладывал на прошлом RootConf'е.

Почему мы опять решили всё изменить после перехода на докер, и как мы пришли к zipper-stack, go-carbon, carbon-c-relay (в том числе и бенчмарки альтернативных решений), как получать миллион уникальных метрик в секунду, как мы пришли к тому, что теги в условии безымянных инстансов необходимы, и как мы их сделали, как работает zipper-stack и, вообще, архитектура нашего текущего убер мониторинга.

Доклад принят в программу конференции

Тошнит от колец: великая битва систем мониторинга, часть I

Александр Чистяков

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

Уже отчаявшись, мы решили предпринять последнее усилие, вооружившись фактами. А именно: поскольку хранение и обработка time series информации является важнейшей задачей системы сбора и хранения метрик, мы решили измерить производительность, в первую очередь, подсистемы хранения. Для этого мы запаслись относительно недавно появившимися в ядре фреймворком eBPF, утилитой blktrace и визуализатором ее результатов iowatcher, утилитами atop и perf и другим инструментарием современного инженера по оптимизации производительности.

В первой части мы сравним между собой популярные системы сбора и хранения метрик, обычно существующие в рамках одного узла: Graphite, RRDTool, InfluxDB, Prometheus, Zabbix.

Доклад принят в программу конференции

Технологии отказоустойчивости и катастрофоустойчивости

Ceph BlueStore — новый тип хранилища в Ceph

Максим Воронцов

- Что такое SDS (общие места для (почти) всех решений — масштабирование, абстрагирование от аппаратных ресурсов, управление с помощью политик, кластерные ФС);
- Почему мы решили использовать SDS (нужно было объектное хранилище);
- Почему решили использовать именно Ceph, а не другие открытые (GlusterFS, Swift...) или проприетарные (IBM Elastic Storage, Huawei OceanStor) решения;
- Что еще умеет Ceph, кроме object storage (RBD, CephFS);
- Как работает Ceph (со стороны сервера);
- Что нового дает BlueStore по сравнению с классическим (поверх ФС);
- Сравнение производительности (метрики тестов);
- BlueStore — все еще tech preview;
- Заключение. Ссылки, литература.

Доклад принят в программу конференции

smart balancing with nginx+lua

Андрей Кононов

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

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

Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.

Доклад принят в программу конференции

Технологии виртуализации и контейнеризация

Виртуализированные сетевые сервисы на line rate в серверном окружении

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

Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.

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

В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.

Доклад принят в программу конференции

Управление в эксплуатации

ChatOps на практике. Организация работы команды сопровождения

Евгений Потапов

1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.

2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.

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

Доклад принят в программу конференции

Highload в ВУЗе: идеализм, расчётливый менеджмент или пустые надежды

Артем Каличкин

Highload — тот ещё секс в нашей жизни. Можно ли научить сексу заранее тех, кто не нюхал пороха?

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

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

Как итог: новый спецкурс на Факультете информационных технологий в НГУ.
Два года, два потока.
Переписанная два раза программа, мысли переписать снова.
Трудности с лабораторными стендами. Пошёл через облака — отдал своих кровных 5 000 за время, пока настраивал, и две пары лабораторной работы в Azure.
Отказался от идеи показать для сравнения мир Microsoft с его release manager и desired state config.
С удивлением включил в программу вопросы непрерывной интеграции, а думал говорить только про поставку.
Мясо, нужно больше мяса, но нужны помощники, где взять опытных волонтеров со сбитыми костяшками.
Мучения с погружением в кухню рецептов, как показать и дать потрогать, чтоб поняли, не имея опыта эксплуатации.
Когда это даст эффект, если даст?

Вопросы в темноте....

P.S. И да, я рассказываю про ITIL и не считаю это лишним.

Доклад принят в программу конференции

Движение по хрупкому дну

Сергей Караткевич

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

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

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

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

- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструктуре случается слишком рано. Расскажу, основываясь на реальном проекте, об одном из подходов с использованием облака, Chef, Packer и Terraform и о серьезных проблемах, которые возникали в процессе оперирования этим проектом.

- Почему Agile, CI, CD и ChatOps не заработают для вашей компании.
Я расскажу, почему автоматизация в стартовавших проектах скорее вредит, чем помогает, и про то, как восьмикратное увеличение количества деплоев не улучшило качество продукта, а даже наоборот; как изменилось поведение программистов с упрощением процесса деплоя, и почему ChatOps/NoOps — всего лишь приятная иллюзия.

Доклад принят в программу конференции

Истории успеха

Опыт международных продаж видеостримера Flussonic

Максим Лапшин

В докладе я хочу поделиться нашим (http://erlyvideo.ru/) опытом по международным продажам b2b ПО, разрабатываемого в России. Зарубежный доход — это 80% наших денег при предельной диверсификации наших доходов, нам платят люди из почти 100 стран.

Структура доклада:
1. Что мы продаем и как зарабатываем.
2. Как получилось вывести на международный рынок.
3. Почему наш софт покупают.
4. Как мы продаем и поддерживаем.
5. Кто клиенты, как с ними общаемся.
6. Как принимаем деньги и платим налоги (карты, пейпал, банковский счет, recurrent).
7. Сравнение российского ООО и зарубежной компании: юридические, налоговые аспекты.
8. Перспективы и вызовы.

Доклад принят в программу конференции

Клиенты и продажи

Мифы о выходе на рынок Азии. Опыт IT-компании

Ярослав Городецкий

21 век по праву называют веком Азии. С этой частью света связано множество бизнес-мифов и "страшилок".
Так ли сложно завоевать любовь восточной аудитории?

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

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

Доклад принят в программу конференции

Разработка

Миф об очень сложном Highload

Александр Горный

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

В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.

План выступления.

1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.

2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.

3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.

4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.

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

В других местах highload не нужен, это просто очередной buzzword за ваши деньги.

Доклад принят в программу конференции

Инструменты

Atlassian Jira - не только тасктрекер

Анна Котова

Jira всем и каждому, и пусть никто не уйдет обиженным.

Jira — простой в настройке, удобный и гибкий инструмент для автоматизации процессов.
- Почему Jira.
- Для каких проектов и процессов подходит Jira.

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

Плюсы внедрения Jira в проекты любого типа.
- Безопасность.
- Удобство и скорость формирования отчетов.
- Быстрый анализ эффективности команды и проекта.
- Экономия времени и порядок в финансовых расчетах.

Доклад принят в программу конференции

Человеческий капитал

HR-бренд: оружие массового поражения или спасательный круг?

Мария Айзатуллова
Екатерина Артюшина

1) Что такое HR-бренд.
- Основные задачи которые он решает.
- Как понять, есть он у вас или нет?

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

3) Как оценивать изменения результатов?
4) Кто в компании развивает HR-бренд. МИФ: ставим задачу HR, нанимаем PR-менеджера, и работа сделана.
5) Какие результаты мы получили, работая над HR-брендом 2,5 года

Доклад принят в программу конференции

Ждут ли нас ВУЗы? И если ждут, то что мы им можем дать и что получить?

Дмитрий Волошин

Речь пойдет об опыте Mail.Ru Group в области организации масштабного обучения студентов на базе ВУЗов и привлечения junior программистов в компанию.

Основные вопросы:
- зачем бизнесу нужна стажерская программа?
- зачем бизнесу нужно сотрудничество с ВУЗом?
- какие оптимальные схемы сотрудничества, как продать ВУЗу обучение на его базе?
- кто должен преподавать, и как продать своим сотрудникам обучение студентов?
- как организовать обучение и как привлекать студентов ВУЗа?

Доклад принят в программу конференции

Zone to Win — организация в борьбе за лучшие кадры в эпоху разрушительных инноваций

Александр Зиза

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

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

Работает принцип «деньги — самое дешевое средство» для привлечения лучших.

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

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

Большинство профессиональных рекрутеров скажут — это невозможно, так нельзя, это незаконно. Тем не менее, эти практики из опыта наиболее передовых IT-компаний.

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

Доклад принят в программу конференции

Юриспруденция

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

Кирилл Митягин

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

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

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

Доклад принят в программу конференции

Мифы обработки персональных данных и их безопасность

Станислав Ярошевский

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

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

Безопасность — второй не менее важный вопрос в персональных данных. Можно защищать по закону, можно по "IТ понятиям". Рынок средств защиты данных большой, но что выбрать? Покупаем готовое или создаем свое? Мы поговорим о том, какие плюсы и минусы у данных подходов.

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

Доклад принят в программу конференции

Мастер-класс: 7 стратегических шагов к прибыльной интеллектуальной собственности

Кирилл Митягин
Николай Зайченко

Шаг 1. Идея
Как превратить разрозненные знания в рыночный продукт и сделать актив — интеллектуальный продукт.

Шаг 2. Прототип и производство
Как уменьшить риски угона продукта, оформить активы на компанию и избежать споров с партнерами, разработчиками и работниками.

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

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

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

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

Шаг 7. Масштабирование проекта
Какие дополнительные способы монетизации дает интеллектуальная собственность.

Программный комитет ещё не принял решения по этому докладу

Мифы, проблемы и решения вопросов работы с персональными данными на сайтах

Максим Лагутин

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

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

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

В завершении разложим по полочкам, что нужно делать, чтобы регуляторы (Роскомнадзор, ФСБ и ФСТЭК России) были довольны, не пришли с внеплановыми проверками, не приостановили деятельность и не наложили штрафы за неправильный сбор, хранение и иную обработку персональных данных на сайте.

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

Доклад принят в программу конференции

Лоер баттл: учимся побеждать в судах

Николай Зайченко

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

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

Идти в суд самому, найти нормального юриста или поручить штатному? Сколько стоит Харви, и не лучше ли отдать эти деньги детям?

Я проиграл. Что делать?
Я выиграл. Что делать?

Эти вопросы мы рассмотрим на примере анализа конкретных кейсов из жизни российских компаний (а не пережевывая набившие всем оскомину забугорные миллиардные истории).

Доклад принят в программу конференции

Стратегия

Почему 90% проектов проваливаются, и как определить ценность проекта для вашего клиента

Егор Гурьев

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

Я хотел бы рассказать:
а) как правильно оценить потенциальный сегмент потребителей, как оценить проблемы и бонусы, которые клиент ожидает.
б) как составить бизнес-модель, которая пройдет тест на выживание в реальной жизни и позволит вам проверить необходимость в вашем бизнес-проекте с минимальными затратами.
в) каким образом попасть в 10% удачных стартапов и как выбраться из ямы 90% провальных проектов.

Расскажу про свой личный опыт и опыт нашей команды. Какие ошибки мы совершали, как мы их исправили, и к чему это привело.

Доклад принят в программу конференции

Рост компании

Мифы, которые мешают бизнесу расти

Дмитрий Калаев

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

Базой для доклада станет опыт работы Акселератора ФРИИ с 200+ IT-компаний. Будут разобраны наиболее показательные кейсы.

Доклад принят в программу конференции

Выход на новые рынки, так ли это сложно организовать

Павел Шинкаренко

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

Выход в Европу — особенности ведения операционной деятельности в ЕС, выбор юрисдикции для создания операционной компании, сравнение по налогообложению и затратам на организацию и ведение бизнеса. Подробно рассмотрим страны Балтии (Латвия, Эстония), северной Европы (Англия, Ирландия), южной Европы (Кипр, Португалия).

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

Латинская Америка — Бразилия. Такая далекая по территории и такая близкая к России по "зарегулированности" и административным препонам. Когда стоит серьезно рассматривать этот регион.

Доклад принят в программу конференции

Бизнес и финансы

Реалистичные стратегии IТ-компании в кризис

Сергей Рыжиков

Каждые 8-10 лет в капиталистической экономике проходят кризисы. Для большинства предпринимателей это становится неожиданностью. Но некоторые выходят из кризиса с более крепким, оздоровлённым бизнесом, да ещё и захватывают новые рынки.

В этом докладе мы порассуждаем над реалистичными принципами управления компанией и IТ-продуктами в период неопределенности.

Доклад принят в программу конференции

Процессы

Организационный дизайн динамичных организаций: Research Progress Report

Павел Вотчицев

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

Многие из этих практик и инструментов организационного дизайна применимы в других индустриях и организациях — от стартапов и корпораций до университетов и государственных структур. Один из ярких примеров такой практики — это система OKR (Objective - Key Results: человеческая замена KPI, применимая в Agile-процессах).

С 2014 года мы с группой единомышленников из GameChangers.ru проводим исследование “Организационный дизайн динамичных организаций” и готовы предоставить анализ и рекомендации по использованию наиболее эффективных инструментов и методов стратегического планирования в следующих сферах:
- как организовано управление информацией и принятие решений,
- как распределены обязанности и ответственность,
- как организовано получение обратной связи сотрудников,
- как культура и основные ценности организации воплощаются в конкретных инструментах и практиках,
- как люди, которые лучше всего подходят для определённых позиций оказываются именно на них — практики приема новых сотрудников и ротация персонала внутри компании.

На текущий момент в фокусе исследования в IТ: Google, Valve, GitHub, LinkedIn, Atlassian, Яндекс, ВКонтакте, JetBrains.

Другие сферы: НИУ ИТМО, Иннополис, РосАтом, СБерБанк, Zappos, Uber, Tesla.

Доклад принят в программу конференции

Нужно ли внедрять DevOps? Как добиться чего-то от эксплуатации

Андрей Шорин

Захотят ли суровые админы принять модный тренд за основу своей работы? И получится ли изолированно от разработки принести пользу бизнесу?

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

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

Доклад принят в программу конференции

Эффективная бизнес-поддержка в непростых ситуациях: обучение и развитие сотрудников

Юлия Синянская

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

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

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

Пытаясь развеять эти мифы и подготовить специалиста с качественно иными навыками и умениями, я поняла следующее:
- Найти необходимого специалиста новой формации сложно, а переподготовка и традиционные формы обучения текущих кадров не работают. Я расскажу о формах, которые в итоге сработали и принесли достойные результаты. Например, нам удалось сократить время обучения новых сотрудников с 6 до 2 месяцев. А команда, состоящая лишь из 6 инженеров обрабатывает заявки теперь не за 10 часов, а за 1.5 часа.
- Техническая подготовка и “прокачка" сотрудников информацией не повышает эффективность команды, а высокие показатели специалиста по результатам аттестации не гарантируют качественную поддержку: быстрое время ответа клиенту, 100% качество обработки заявок, удовлетворенность клиента более 90%.
- Для переподготовки специалистов не обязательно требуется значительный бюджет и привлечение внешнего тренера-эксперта. Обладая минимальным бюджетом и активно используя внутренние резервы компании, такие как разработка персональных планов обучения ведущими внутренними специалистами, анализ case study, подготовка самими инженерами тренингов по компонентам, проведение Q&A с разработчиками продукта — можно значительно повысить уровень подготовки команды.

Доклад принят в программу конференции

Почему бизнес-процессы — это не страшно?

Александр Богданов

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

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

Но всем ли нужны четкие бизнес-процессы, регламентированный workflow, автоматизация бизнеса и прочее?

- Зачем нужны бизнес-процессы для малого бизнеса? Каким компаниям они нужны, а каким — нет?
- Кому внедрять workflow, а кому можно пренебречь?
- Внедрение регламентов: теория и практика.
- Инструменты автоматизации: когда пора отказаться от Excel?

Доклад принят в программу конференции

Команда

Работе из дома здесь не место (миф про удаленных сотрудников). Как собрать, усадить и держать команду, способную делать world's №1 сервис

Михаил Трутнев

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

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

Доклад принят в программу конференции

Реальное импортозамещение

Как на самом деле всё устроено в государстве

Герман Клименко

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

Что стоит за теми или иными законами? Как на самом деле принимаются решения? Что хочет государство? Что оно может, а что не может? Что оно хочет, а чего оно не хочет?

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

Небольшой ликбез от Советника Президента Германа Клименко на конференции "Российские интернет-технологии".

Доклад принят в программу конференции

PostgreSQL в правительстве Московской Области

Иван Панченко
Тенгиз Алания

Недавно Межведомственная система документооборота Московской области перешла на СУБД PostgreSQL. http://mits.mosreg.ru/multimedia/novosti/glavnie/07-04-2016-16-26-28-msed-moskovskoy-oblasti-perevedena-na-postgresql/

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


Доклад принят в программу конференции

Процессы

Практическая трансформация классической корпорации в Web Scale IT на примере Почты России

Родион Шишков

Постановочные вопросы:

1) Что думает про себя и про информационные технологии сегодняшняя корпорация?
2) Как организация смотрит на результаты своей деятельности и перспективы на рынке?
3) В чем разница целеполагания классической корпорации и Web Evolved компании, и почему им не понять друг друга?
4) Как сделать ценность Web Based IT видимой для корпорации?
5) Как оставаться гибким в негибкой организации и, в конце концов, научить ее меняться?

Доклад принят в программу конференции

Agile в "кровавом энтерпрайзе"

Асхат Уразбаев

В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.

Мы поговорим про специфику внедрения Agile в крупной организации, сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.

Доклад принят в программу конференции

Знакомство enterprise и web

Дни и заботы директора департамента IТ промышленной корпорации

Дмитрий Смоляров

В последнее в время мне довелось много общаться с представителями так называемой веб-культуры. Для меня было открытием, что в России существует такая продвинутая школа разработки, и в условиях сегодняшнего дня, долларовых вендоров и ограничений, все российское становится более чем актуально.
Тем не менее, каждое общение с веб оставляло у меня двойственное впечатление. Либо все было чересчур технично, детально и непонятно, ЗАЧЕМ, либо не было понятно, КАК это все довести до воплощения.

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

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

Об этом и поговорим.

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

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

Доклад принят в программу конференции

Особенности MVP в Enterprise

Владимир Васильев

- Зачем в Enterprise нужен MVP;
- что значит "минимально жизнеспособный" продукт для большой организации;
- как оргструктура влияет на продукт;
- какие ограничения может накладывать Enterprise на MVP;
- какие практики MVP наиболее полезны в Enterprise.

Доклад принят в программу конференции

Сотрудничество

Секретные техники продаж корпоративным клиентам

Александр Зиза

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

Делать реально крутые инновационные системы в IT и продавать их крупным клиентам — не одно и то же.

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

1. Звено принятия решения, кто же берет ответственность на себя.
2. 6 категорий интересов, которые нужно учитывать.
3. Доверие или отношения?
4. Продажа через фокса.
5. Кто позвонит первым.
6. Иллюзия контроля.
7. Задача на один контакт.
8. Про «корабли, бороздящие...» или конкретику.
9. Как работать со смежными интересами.
10. Продавать или обучать.
11. Что делать со сторонниками конкурента.
12. Заманить или напугать, с какой спецификации начать.
13. Особенности корпоративной воронки продаж.

Знать про эти техники надо. Пользоваться ли — решайте сами.

Доклад принят в программу конференции

Технологический стек

Genuine web-scale железо. Как FB, Apple и Google разрушают традиции в компьютерном бизнесе и почему это для индустрии хорошо

Андрей Чернышев

Web-scale — новый взгляд на инфраструктуру центра обработки данных для современных нужд и приложений. Эволюция железного бизнеса. Как FaceBook совершил “открытие” в железной инфраструктуре.
• Тенденции и принципы развития открытых платформ. Как на наших глазах совершилась революция, которую мы еще не ощутили;
• Новый бизнес-компромисс производителей IТ-железа и ведущих потребителей IТ-инфраструктуры. Как крупный заказчик может заставить работать производителей железа в своих интересах и полностью уйти от зависимости от производителя;
• “Проблема импортозамещения” – видение и решения проблемы от ведущих мировых потребителей IТ-инфраструктуры. Как уйти от порочной зависимости от производителя оборудования? Переработать, переосмыслить, открыть и заставить всех IТ мировых производителей работать на себя на конкурсной основе.

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

Проблемы, которые стояли перед FaceBook и не решались эффективно известными всем традиционными инфраструктурными лидерами индустрии :
• Гиперконвергенция;
• Максимальная унификация;
• Сверхпреемственность и защита инвестиций;
• Энергопотребление и тепловыделение;
• Компактность и плотность платформ;
• Обслуживание и ремонтопригодность;
• Минимизация сервисных затрат.

Уже сейчас разработан ряд унифицированных платформ — от самых простых и привычных для нас до супер производительных для обработки online транзакций. Каждая из них — шедевр инженерной мысли. Представьте себе 30000 GPU core в одном сервере или 100Gb интерконнект серверов в датацентре по цене среднего сервера от популярного в нашей стране бренда. Это позволило Facebook только за один год сэкономить 1 МЛРД долларов! А теперь к этому содружеству присоединился RackSpace, Apple с облаком iCloud и Apple Music, Google, Amazon со своими проектами. Таким образом, такая концепция становится трендом в развитии индустрии.

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

Все последние "секретные" новости прямо с заводов крупных ODM.
Примеров реализации концепции открытых систем и наших собственных наработок.

Доклад принят в программу конференции

Гиперконвергентность — мягкое введение в веб-масштаб

Андрей Николаенко

Ключевой признак инфраструктуры веб-масштаба — горизонтальная масштабируемость посредством унифицированных строительных блоков — на основе x86-узлов, притом без таких традиционных для «корпоративного» (Enterprse-) сегмента элементов, как выделенные сети хранения данных (SAN), выделенные комплексы резервирования, архивирования. Именно на этой особенности веб-масштаба фокусируются аналитики Gartner, когда говорят о центре обработки данных «в стиле Google» и видят будущее в таком подходе и для корпоративного направления IТ. Привлекательность такой унификации и ухода в «веб-масштаб» по части инфраструктуры очевидна, но ведь реальные приложения корпоративных заказчиков, нажитые и выстраданные за долгие годы выбора, внедрений, развития создавались для иных моделей развёртывания. В данном докладе мы попробуем ответить на вопрос — возможно ли, не разрушив это наследие, перейти к «ЦОДу в стиле Google»?

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

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

Но гиперконвергентная архитектура — это лишь введение в веб-масштаб, позволяющее упаковать наследие прошлых лет в современную инфраструктурную форму и обрести некоторые свойства веб-масштаба. Путь к истинным архитектурам веб-гигантов на уровнях платформ и приложений — не так однозначен и прост, и последняя часть доклада будет посвящена перспективным направлениям на этом пути. В частности, будет затронут вопрос «гиперконвергентности» в мире реляционных СУБД и возможного слияния движений SQL и NoSQL в свете трансформации Enterprise → Web-scale.

Доклад принят в программу конференции

Эволюция enterprise

Мобильное приложение как способ изменить "корпоративный" мир

Андрей Тимербаев

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

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

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

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

Доклад принят в программу конференции

Новый IT для нового enterprise

Александр Титов

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

Что же происходит, какие закономерности стоят за этими событиями? Почему web стал ближе к enterprise, и как enterprise догнать web?

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

Доклад основан на 7-летнем опыте внедрения DevOps практик и технологий в компаниях разного размера.

Доклад принят в программу конференции

A Developer's Guide To Forrester's Strategies For API Success

Максим Тамбиев

1. APIs And SOA Are Critical For Digital Business Success
APIs rise to the level of business strategy because they foster innovation by allowing organizations to reach new ecosystems and win new customers. Business and technology executives must understand that APIs represent digital business connections to core competencies and business assets, enabling their organizations to play in multiple dynamic ecosystems of value.

2. Strategy For APIs And SOA Must Be Incremental And Architected
Street-level strategy is the right foundation: Establish a lightweight vision, then leverage each business change initiative to build your API taxonomy, architecture, platform, and governance.

3. Mature API Platforms Cover Five Major Areas
A strong platform for APIs and SOA leverages five major areas of technology: service delivery infrastructure (e.g., application servers, integration technology), service testing and virtualization, API management, service runtime management, and service life-cycle management.

Доклад принят в программу конференции

Применение сервисного подхода в архитектуре предприятия при разработке новых продуктов

Евгений Долгов

- Что такое Продукты и Сервисы в нашем понимании.
- Каким образом связываются бизнес и IТ через сервисы.
- Создание нового продукта с точки зрения архитектуры в контексте Сервисно-продуктового подхода.
- Необходимые элементы для управления сервисной архитектурой на уровне предприятия.
- Необходимые инструменты интеграции IТ-систем при сервисном подходе.
- Пример архитектуры\Соглашения о моделировании.

Программный комитет ещё не принял решения по этому докладу

Что будет после web-scale?

Maxim Shaposhnikov

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

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

Истина как обычно гораздо шире и глубже.

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

Почему это именно так, мы и поговорим в моём докладе.

Доклад принят в программу конференции

Коэволюция enterprise и open-source

Илья Космодемьянский

О пришествии Open Source технологий в enterprise-мир (мир промышленных решений, хотя "энтерпрайз" — термин более точный и уже стал устоявшимся в русском языке) принято говорить либо в стиле победных реляций [1][2], либо с долей злорадства, там где конкретный проект испытывает проблемы [3]. Представители оpen-source сообществ часто говорят, что их технологии (многие из которых сформировались и окрепли в "несерьезном" вебе) взорвали enterprise, и дни проприетарных решений там сочтены.

Отчасти такие разговоры обоснованы историей рынка операционных систем и прежде всего коммерческих UNIX'ов [4]. Недавние шаги Microsoft в сторону Linux [5] только усиливают hype, а ряд отраслевых экспертов серьезно намекают, что именно такие шаги Microsoft вызваны обеспокоенностью, что MS SQL Server уже не тащит за собой продажи Windows Server как прежде. Энтерпрайз перестроился и теперь семимильными шагами применяет то, что раньше было мыслимо только в вебе.

Такое объяснение происходящего верно лишь отчасти — подсказывает наш опыт внедрения PostgreSQL как замены коммерческим СУБД. 7 лет назад, предлагая использовать Postgres вместо Oracle в серьезной промышленной системе [6], я мог оперировать очень небольшим набором аргументов в пользу PostgreSQL. Строго говоря, аргумент был один — экономия на лицензиях. И он работал (хотя наверное от меня предпочли бы услышать более глубокий анализ стоимости владения PostgreSQL) — работал лучше, чем если бы я (как делают многие евангелисты Open Source) рассказывал бы о неясной расширяемости, как главном преимуществе mission-critical компонента OSS/BSS систем. Расширяемость и масштабируемость вполне может гипнотизировать людей принимающих решение в вебе, но никак не людей, думающих в категориях коробочных решений и жестких SLA, к ним приданых. Чтобы внедрение PostgreSQL в промышленные решения во всем мире пошло теми темпами, которыми идет сейчас, Open Source сообществу тоже пришлось здорово перестроиться и это только начало.

Именно об этой перестройке, а точнее о совместной эволюции с enterprise миром в условиях динамически меняющихся факторов внешней среды, я и расскажу в этом докладе. В сравнениях и примерах я расскажу о структуре стоимости владения open-source ПО, такого как PostgreSQL или Linux. Как промышленное внедрение PostgreSQL влияет на эволюцию разработки этой технологии. Особое внимание будет уделено таким сложным для enterprise мира понятиям, как сообщество и взаимодействие с ним, и попробую развернуто ответить на такой распространенный вопрос IT-руководителей, как "в течение какого времени вендор может предоставить патч в случае обнаружения проблемы?". Вместе мы попробуем пройтись по всем этим темам и проанализировать, как они меняют мир свободного ПО и enterprise буквально на наших глазах.

1. http://www.enterprisedb.com/postgres-plus-edb-blog/pierre-fricke/gartner-makes-one-choice-easier-crowded-database-market
2. http://www.infoworld.com/article/3019852/linux/how-linux-won-without-winning.html
3. http://www.welt.de/regionales/bayern/article132976293/Stadt-Muenchen-will-von-Linux-zurueck-zu-Microsoft.html
4. http://www.networkworld.com/article/2168940/servers/the-last-days-of-unix.html
5. http://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/#sm.0000rvvishrvjdfcsp313ofecl602
6. http://www.pgcon.org/2011/schedule/events/286.en.html

Доклад принят в программу конференции

Использование Tarantool в качестве платформы виртуализации данных

Константин Осипов
Сергей Мясников

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

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

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

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

Единственным возможным на сегодняшний день ответом на вызов digital трансформации является внедрение решений с открытым исходным кодом.

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

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

Доклад подготовлен совместно архитекторами Mail.Ru Group и ПАО Вымпелком.

Доклад принят в программу конференции

Почему Кровавый Энтерпрайз всегда побеждает

Денис Ремчуков

Краткая история IТ: первые серверы, языки программирования, реляционные базы данных, глобальные информационные системы на их базе.

Enterprise vs Commodity — сравнительный таймлайн.
Enterprise vs Open — сравнительный таймлайн.
Microcode vs Software Defined — почему использование ядра общего назначения — плохо.
Proprietary vs Commodity.
Конец привычного мира — предел технологий полупроводниковой фотолитографии.
Почему Enterprise всегда побеждает, на основе реальных кейсов.

Что нам с этим всем делать?

Доклад принят в программу конференции

Как мы переписали enterprise-решение IBM Maximo с помощью веб-технологий

Сергей Песецкий

В 2012 году открытым правительством Москвы была поставлена задача учета и предоставления достоверной информации о многоквартирных домах и работах, выполняемых управляющими компаниями по их обслуживанию. Для решение данной задачи принято решение использовать лучшее Enterprise решение класса EAM (Enterprise Asset Management) из правого верхнего квадрата Gartner — IBM Maximo. Для наполнения данными применили Web 2.0 подход. Основная  идея: Жилой дом является объектом учёта. Все проводимые работы Управляющими компаниями фиксируются как рабочие задания. Жилищная инспекция совместно с жителями контролируют исполнение.

Мы столкнулись с проблемой неповоротливости и медленности Enterprise решения, которые оказались совсем не HighLoad. При работе с 32000 домов, представленных 2500 конструктивными элементами — каждый на один дом — получалось 80 000 000  Assets (цифровых ресурсов), с которыми система в онлайн режиме работать не могла. 

Обрисовав все вопросы на Maindmap, нашли корень проблемы, стали искать решения в Gartner — не нашли. Решили писать сами с применением Web подходов, ориентированных за задачи бизнеса, а не бизнес-процессов и готовых практик. Результатом стало ядро системы, которое мы назвали «Динамическая Модель».  К нему разработали объектную систему, дающую прямой доступ к кубикам BPM, к объектам антологии, несущей структуру данных со связями, унаследованную из EAM системы.

Про суть «Динамической модели», «Объектного конструктора» и других модулей web-enterprize системы мы расскажем на конференции.

К слову, система, построенная на IBM Maximo, занимала 21 сервер, совокупно 400 ядер и 600 Гб ОЗУ. После пересмотра и применения WEB подхода задача заняла 3 сервера с 36 ядрами и 96 Гб ОЗУ, оставаясь при этом серьёзным Enterprise решением.

Доклад принят в программу конференции