31 марта и 1 апреля 2018 года в Новосибирском Экспоцентре проходил CodeFest - “крутейшая за Уралом конференция разработчиков, тестировщиков, дизайнеров, менеджеров проектов и продуктов”. В этом обзоре я опишу запомнившиеся мне доклады.

Знак CodeFest на входе в Экспоцентр

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

Разработка в ненадежной нагруженной среде (Алексей Акулович, ВКонтакте)

Описание и слайды

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

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

Deploy: называется паровоз (т.к. к ней “цепляется” сразу много разных задач). Выкатываются 5+ раз в день, не выкатываются в пики нагрузки и праздники (code freeze).

Flow выкатки: master => staging => production (мне он чем-то напомнил то, что есть в Facebook). Staging выкатывается на ~1% пользователей, существует возможность быстрого отката изменений. Удивило, что он появился только в 2017 году.

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

Мониторинг: собирают и продуктовые, и системные метрики общим объемом около 100 миллионов значений в секунду. Для конкретных метрик можно настроить отправку не всех событий, а только их части. Есть автоматический поиск аномалий для основных метрик (их несколько сотен).

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

Различные части функционала независимы друг от друга (api, группы, музыка и т.п.), работают на отдельных группах машин, поэтому проблемы в одной части не влияют на другие (об этом Алексей уже рассказывал на Highload++ в 2016 году). Используют дублирование данных в кэше для “горячих ключей” (чтобы не перегружать отдельные инстансы запросами на чтение) и на крайний случай - хардкод значений в коде.

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

Мини-доклад от Plesk про GDPR

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

Общий регламент по защите данных (англ. General Data Protection Regulation, GDPR) (Постановление (Европейский союз) 2016/679) — это Постановление, с помощью которого Европейский парламент, Совет Европейского союза и Европейская комиссия усиливают и унифицируют защиту персональных данных всех лиц в Европейском союзе (ЕС).

Википедия

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

Даже если вы сами не собираете никаких персональных данных, то вы всё равно можете попасть под действие этого закона. Например, если на вашем сайте есть Яндекс Метрика, Google Analytics, Google Adsense или какая-нибудь интерактивная кнопка от Facebook / Twitter / ВКонтакте, которые собирают персональные данные, то вы тоже попадаете под GPDR.

GPDR вводит понятия data controller и data processor. Это две роли в работе с персональными данными, которые может выполнять как один человек, так и разные компании. В примере с сайтом с Google Analytics, владелец сайта - это data controller, который определяет цели обработки персональных данных, перечень необходимых для этого данных, сроки их хранения и т.д. Google Analytics - это data processor, который непосредственно хранит и обрабатывает данные. Ответственность data controller-а на несоблюдения и / или нарушения GDPR выше, чем у data processor-а, и штрафы могут достигать 20 миллионов евро.

Для соблюдения GDPR нужно требовать явного согласия пользователя с каждой целью обработки данных. Эти цели должны быть описано с помощью plain language и показаны явно (нельзя описать цели в пользовательском соглашении и получить традиционное согласие одним кликом). Недопустимо использовать opt-out, т.е. нужно собирать персональные данные только после явного согласия.

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

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

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

Про Google Analytics говорили, что они обещали соблюдать требования GDPR, но на момент доклада (31 марта 2018 года) это ещене было реализовано.

Дополнительные ссылки:

Apps, Algorithms and Abstractions : Decoding our Digital World (Dylan Beattie, Skills Matter)

Описание и слайды

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

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

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

P.S. Фурор на CodeFest-е произвела песня Дилана Enterprise Waterfall, которая игралась перед докладом (на его канале есть и другие песни на IT-тематику).

Подходы к реализации шардинга в современных [No]SQL системах (Константин Осипов, Mail.Ru Group)

Описание и слайды

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

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

Люди, стоящие в дверях на докладе Константина Осипова

Доклад Константина Осипова “Подходы к реализации шардинга в современных [No]SQL системах”

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

Реально крутая разработка: кодим меньше, а зарабатываем больше (Харитон Матвеев, SkyEng)

Описание и слайды

Один из лучших докладов на конференции (из тех, на которых я был).

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

  • Объясняйте цели задач - разработчики должны понимать конечную бизнес-цель, чтобы делать именно то, что нужно для бизнеса. Задача продакт-менеджера - формулировать проблемы бизнеса, которые нужно решить, и спрашивать за конкретный бизнес-результат, а не реализацию один в один того, что просили.
  • Перед разработкой реализуйте прототип нужной функциональности “ручками” (например, с помощью Excel, Google Docs, IFTTT и т.п.) несколько раз и только получив результат и понимая, что именно нужно получить, передавайте задачи в разработку.
  • Используйте только стандартные элементы интерфейса - не придумывайте каких-то специфичных контролов, т.к. потребуется много времени на их разработку и они будут непонятны для пользователей.
  • По максимуму используйте внешние готовые сервисы вместо того, чтобы всё реализовывать самостоятельно. При каких-то проблемах на внешних сервисах стараются просто выключить их или быстро заменить на аналоги.
  • Точки роста продукта часто находятся не в программировании сложных вещей, а в каких-то простых вещах за его пределами. Примеры: подбор оптимальных цен (с точки зрения выручки) для подписки, выбор правильных значений по умолчанию и т.д.

В докладе было много примеров (вроде использования embed-ов Google Docs на страницах сайта с контактами, партнёрами конференции и т.д.), которые позволяют решать задачи без разработки вообще. Конечно, не везде такие примеры можно использовать, но подход выглядит очень здраво.

Мини-доклад от Plesk про flaky тесты

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

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

Главная проблема flaky тестов - это то, что из-за них пропадает доверие ко всем тестам. Такие тесты чаще всего появляются из-за незамоканных вызовов. Исправлять их достаточно просто, но монотонно и долго, т.к. нужно время на поиск конкретной причины в коде. В Plesk используют некий “бюджет времени” на исправление таких тестов (кажется несколько часов в неделю на человека).

Все нестабильные тесты отправляются в “мультикарантин” - их помечают как нестабильные и используют два разных типа прогонов:

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

Стенд Сбертеха в конце второго дня

Стенд Сбертеха в конце второго дня конференции

Профессиональное выгорание: кто виноват и что делать. Рассказ от первого лица (Александр Орлов, Стратоплан)

Описание и слайды

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