Мы начинаем публиковать курсы лекций Технополиса — образовательного проекта команды Одноклассников в Санкт-Петербургском Политехническом университете Петра Великого. Создание высоконагруженных приложений — это не только проектирование и написание кода, но и огромное количество других аспектов на всём протяжении жизненного цикла продукта. Мы пройдём по всему процессу создания и использования высоконагруженной системы. Особое внимание будет уделено особенностям эксплуатации, сетям, балансировке нагрузки, иерархии памяти, повседневным инструментам. Также поговорим о мониторинге, аудите и многом другом. Лекции курса читает команда экспертов под руководством ведущего разработчика в Одноклассниках Вадима Цесько.

Список лекций:

1. Введение (Вадим Цесько incubos)
2. Типовые архитектуры (Александр Христофоров)
3. Эксплуатация (Илья Щаников)
4. Сетевой стек (Дмитрий Самсонов dmitrysamsonov)
5. Балансировка (Андрей Домась)
6. Процессоры и память (Алексей Горбов)
7. Хранилища данных (Сергей Егоричев)
8. JVM (Андрей Паньгин apangin)
9. Мониторинг (Сергей Шарапов Sharapoff)
10. Облака (Леонид Талалаев)

Алоха, пипл! Меня зовут Олег Анастасьев, я работаю в Одноклассниках в команде Платформы. А кроме меня, в Одноклассниках работает куча железа. У нас есть четыре ЦОДа, в них около 500 стоек более чем с 8 тысячами серверов. В определенный момент мы поняли, что внедрение новой системы управления позволит нам более эффективно загрузить технику, облегчить управление доступами, автоматизировать (пере)распределение вычислительных ресурсов, ускорить запуск новых сервисов, ускорить реакции на масштабные аварии.

Что же из этого получилось?

Привет, Хабр! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в Одноклассниках. Основные сферы моей компетенции — Zabbix, CFEngine и оптимизация Linux. У нас более 8 тыс. серверов и 200 приложений, которые в различной конфигурации формируют 700 различных кластеров. Тема этой статьи исчерпывающе описана в заголовке.

Сразу хочу оговориться:

• Я буду предвзят, потому что участвовал во внедрении CFEngine в Одноклассниках.
• Я пользовался CFEngine только версий 3.3—3.4.
• Я не питаю никаких иллюзий по поводу CFEngine, это значимый игрок, но не лидер рынка и не его аутсайдер. В статье не будет сравнений работы CFEngine с другими системами.
• Из систем конфигурации у меня есть опыт использования только CFEngine и Ansible.

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

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

Потому что во многой мудрости много печали;
И кто умножает познания, умножает скорбь.
• Екклесиаст 1:18

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

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

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

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

Что значит имя? Роза пахнет розой,
Хоть розой назови ее, хоть нет.

• Шекспир "Ромео и Джульетта" (пер. Пастернака)

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

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

Это примерно все равно, что сказать: вероятность быть сбитым машиной, если тебя зовут Сережа, выше, чем если бы тебя звали Костя! Звучит довольно дико, не правда ли? Ну, как минимум, ненаучно. Однако социальные сети сделали возможным сравнительно просто проверить приведенное выше утверждение.

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

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

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

Мы сами устанавливаем и настраиваем наши серверы, но так как их очень много, то неизбежно, что каждый день что-то ломается. И наша самая главная задача в таком случае — увидеть поломку быстрее пользователей. Поэтому за работу всего портала отвечает целая команда мониторинга. Они просматривают графики, ищут в них аномалии, заводят инциденты, распределяют «автоинциденты», которые создаются при помощи связки Zabbix + JIRA. Мы не просто мониторим бизнес-логику, но и автоматически её анализируем. Подробнее об этом я и расскажу далее.

Думаю, все уже знают, что современные браузеры умеют рисовать некоторые части страницы на GPU. Особенно это заметно на анимациях. Например, анимация, сделанная с помощью CSS-свойства transform выглядит гораздо приятнее и плавнее, чем анимация, сделанная через top/left. Однако на вопрос «как правильно делать анимации на GPU?» обычно отвечают что-то вроде «используй transform: translateZ(0) или will-change: transform». Эти свойства уже стали чем-то вроде zoom: 1 для IE6 (если вы понимаете, о чём я ;) для подготовки слоя для анимации на GPU или композиции (compositing), как это предпочитают называть разработчики браузеров.

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

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

Точнее, не так. Когда в седой древности появился примерно 20-й сервер, стали использовать Big Brother — простейший мониторинг, который просто собирает статистику и показывает её в виде мелких картинок. Всё очень, очень просто. Ни приблизить, ни как-то ввести диапазоны допустимых изменений нельзя. Только смотреть картинки. Вот такие:


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

Поэтому мы сделали новую систему мониторинга — и сейчас на работу с 10 тысячами серверов тратим по 1-2 часа в неделю на обработку алертов. Расскажу, как это устроено.

Как в Одноклассниках использование sun.misc.Unsafe сочетается с повышенными требованиями к надёжности? Почему там дорабатывали систему мониторинга Cacti? Как работа в ОК пересекается с научной деятельностью? Если соцсеть называется «Одноклассники», то состоит ли весь её Java-код из одного класса?

Ответы на эти и другие вопросы — в нашем посте. В преддверии Joker, где сразу трое сотрудников ОК будут спикерами, а ещё один участвует в программном комитете, мы расспросили всех четверых — и не только их. На наши вопросы ответили:

• Олег Анастасьев, ведущий разработчик (участник программного комитета Joker 2016)
• Андрей Паньгин, ведущий разработчик (спикер Joker 2016)
• Виталий Худобахшов, ведущий аналитик (спикер Joker 2016)
• Дмитрий Бугайченко, инженер-аналитик (спикер Joker 2016)
• Андрей Губа, заместитель технического директора
• Кристина Штейнберга, руководитель отдела персонала

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

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

В четверг, 26 мая, в 20:00 в питерском офисе компании Luxoft состоится встреча JUG.ru с Андреем Паньгиным aka apangin, ведущим разработчиком Одноклассников. Тема встречи — особенности JDK, связанные с обходом Heap-a и стеками потоков.



Stack Trace и Heap Dump — не только инструменты отладки, но ещё и дверцы к самым недрам виртуальной машины Java. Презентация посвящена особенностям JDK, так или иначе связанным с обходом хипа и стеками потоков. В её основе лежат популярные вопросы про JVM со StackOverflow и реальные случаи из практики.

• Влияют ли стек-трейсы на производительность?
• Как снимать дампы в продакшне без побочных эффектов?
• Как устроены утилиты jmap и jstack изнутри?
• Почему все профайлеры врут, и как с этим бороться?
• Как сканировать хип средствами JVMTI и Serviceability Agent?

Участие бесплатное, регистрация — ТУТ.

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

Хорошим наглядным примером такой задачи является задача нашего конкурса SNA Hakathon 2016: дан социальный граф одного миллиона пользователей и их демография. Задача — найти скрытые связи в этом графе. Размер предоставленного графа всего два гигабайта в GZip и, казалось бы, применение технологий больших данных здесь не оправданно, но это только на первый взгляд.

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

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

«Если у вас есть сомнения, авария это или нет — то это авария!»
(с) Мудрость предков

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

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

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

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

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

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

Да, это



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

Знаете ли вы, как избежать дедлоков в своей программе? Да, этому учат, про это спрашивают на собеседованиях… И тем не менее, взаимные блокировки встречаются даже в популярных проектах серьёзных компаний вроде Google. А в Java есть особый класс дедлоков, связанный с инициализацией классов, простите за каламбур. Такие ошибки легко допустить, но трудно поймать, тем более, что сама виртуальная машина вводит программиста в заблуждение.

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

Всем привет! Меня зовут Артур, я аналитик в отделе анализа данных департамента рекламных технологий Mail.Ru Group. И я попробую рассказать о том, как мы используем кластеризацию в своей работе.

Чего в этой статье не будет: я не буду рассказывать об алгоритмах кластеризации, об анализе качества или сравнении библиотек. Что будет в этой статье: я покажу на примере конкретной задачи, что такое кластеризация (с картинками), как ее делать если данных действительно много (ДЕЙСТВИТЕЛЬНО много) и что получается в результате.

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

Вчера закончился отборочный тур конкурса Russian Design Cup, организатором которого является Mail.Ru Group. Из 118 участников в следующий тур перешли 20 человек. С самого начала им была предложена непростая задача:

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

Подход к решению задачи у всех победителей тура был весьма интересным и зачастую неординарным — потому они и победили. Наибольший средний балл получили работы Доминика Левицкого, Алексея Кипина, Андрея Столешникова, Дмитрия Алябьева и Виталия Якимчука.

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

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