• Data Science: Про любовь, имена и не только. Часть II

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

      Кадры из фильма Казино Рояль (2006)


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


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


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


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

      Читать дальше →
    • Data Science: Про любовь, имена и не только

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

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

      Ромео и Джульетта


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


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


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


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

      Читать дальше →
    • SmartMonitoring — мониторинг бизнес-логики в Одноклассниках



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

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

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

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


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

          Читать дальше →
        • Что случилось, когда мы устали смотреть на графики 5 000 серверов в мониторинге (и когда серверов стало более 10 000)



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

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


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

            Поэтому мы сделали новую систему мониторинга — и сейчас на работу с 10 тысячами серверов тратим по 1-2 часа в неделю на обработку алертов. Расскажу, как это устроено.
            Читать дальше →
          • «Любое техническое изменение должно отвечать на вопрос «зачем?» — Одноклассники о Java и не только



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

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

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

              Читать дальше →
            • Об охоте на «насекомых»: программа bug bounty в Одноклассниках

                Как известно, 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.
                    Читать дальше →
                  • Три дня, которые потрясли нас в 2013



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

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