Интервью с техдиром Mail.Ru

Интервью с техдиром Mail.Ru Владимиром Габриеляном

Mail.Ru — это давно не просто почтовая служба, которой все мы когда-то пользовались. Теперь это микс из самых разных сервисов, включая социальные сети, мессенджеры и онлайн-игры. Наш гость — человек, который отвечает в компании за технологии. Придя в Mail.Ru на позицию простого UNIX-администратора, Владимир Габриелян сумел стать техническим директором Mail.Ru Group и сейчас готов рассказать о том, как проекты компании устроены изнутри.

О карьере

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

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

Одиннадцать лет назад в Mail.Ru работало 60 человек и около 200 серверов. Основным проектом была почтовая служба — и это по большому счету все, что тогда было.

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

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

Челенджи Mail.Ru Group

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

Одно из важных в истории компании событий произошло в 2003 году. В тот момент, когда безоговорочно царствовала ICQ, мы собрались и подумали, что одного мессенджера на такую огромную страну, как Россия, будет мало. Но взять и «подвинуть» iCQ? Это была большая авантюра. Даже я немножечко сомневался в успехе, а среди моих знакомых и друзей вообще почти никто не верил, что нам удастся потеснить ICQ на этом рынке. Так мы запустили собственный мессенджер, который называется Mail.Ru Агент (хотя ваши читатели, наверное, его и недолюбливают — изначально им пользовались больше обычные люди, чем IT-шники). Сегодня же это первый мессенджер по количеству пользователей в России, а ICQ, на которую мы равнялись, вошла в состав Mail.Ru Group.

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

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

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

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

R&D

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

Наш стек выглядит следующим образом: те части программных комплексов, которые работают под высокой нагрузкой, мы в основном разрабатываем на С/С++. На Perl мы делаем те части, которые подвергаются частой модификации, и те, которые дорого или неудобно разрабатывать на C. Также мы используем Python и совсем чуть-чуть Ruby.

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

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

Разумеется, мы используем только Open Source технологии и Linux. Дело в том, что нагрузки очень высоки, и часто приходится сталкиваться с чем-то в первый раз. А когда у вас есть исходный код и проблема загоняет вас в угол, Open Source позволяет в крайнем случае просто открыть исходник и поправить там то, что вам не нравится. Это происходит не так часто, но сама возможность сделать это, если необходимо, дорогого стоит.

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

Мы часто правим баги. Мы внутри Mail.Ru Group обычно начинаем тестировать продукты раньше, чем они становятся стабильными, поэтому исправлять ошибки нам не привыкать. Свежий пример. В поиске мы используем Hadoop и Hbase в качестве хранилища, и это тоже довольно сырой продукт. Так вот, он весь «истоптан» нашими патчами и фиксами — и чтобы сделать его более стабильным, и чтобы заточить его под нашу поисковую систему.

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

У нас, кстати, есть и свой собственный Open Source продукт — Tarantool. Изначально цели делать открытый проект, конечно, не было. Более того, я вообще не верю, что можно сделать продукт в вакууме — вот соберемся мы с вами и сделаем некий хороший продукт. Как правило, сначала ты сталкиваешься с какими-то потребностями, которые никто не может покрыть, потом делаешь продукт для себя и в какой-то момент понимаешь, что получилось неплохо — этот продукт можно отдать. Именно так произошло с нашим key-value storage, и я лично могу порекомендовать его всем, кто работает с высокими нагрузками и кому нужно надежное хранение данных.

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

Как сделать достойный Open Source проект? Мы поняли, что не знаем ответа на этот вопрос. Просто выложить репозиторий с кодом в открытый доступ — явно недостаточно. Поэтому мы искали человека, который знает, как именно это делается. В итоге проектом занимается Костя Осипов, который раньше работал в MySQl. Дело в том, что тогда у нас не было опыта развития Open Source продуктов. Это все-таки немного другая идеология, чем написание софта на заказ и тому подобные вещи. Для этого нужно уметь работать в комьюнити, нужно уметь привлекать в него людей, уметь рассказать людям, почему ты лучше, чем другие. А Костя в MySQl очень много работал с Open Source продуктами: он понимает и знает, как все это делается. Мы искали именно такого человека.

Служба эксплуатации

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

На данный момент мы ориентированы на рынок России и стран СНГ. Большинство наших пользователей находятся здесь, поэтому развивать дата-центры в Европе или США нам пока не очень интересно. Мы хотели бы иметь дата-центры по России, но тут есть ограничение — в стране построено недостаточно каналов, чтобы прокачивать большие объемы трафика внутри страны (между дата-центрами). На сегодняшний день емкость каналов Mail.Ru Group составляет примерно полтерабита, а реального трафика у нас около 280 Гбит/с. Но для того, чтобы объединить в кольцо серверы, которые находятся, к примеру, на Урале, потребовались бы баснословные деньги. Стоимость каналов превысит стоимость строительства всего дата-центра. Это и является основной проблемой.

В компании за то, чтобы все работало, отвечает единая команда эксплуатации. Попробую перечислить, кто в нее входит. Это системные администраторы, которые занимаются администрированием наших проектов. Отдельная дежурная служба, которая 24 часа в сутки наблюдает за нашими серверами, вовремя замечает и исправляет проблемы. Служба эксплуатации дата-центров, которая следит, чтобы там все время были свет и холод. Служба инженеров, которая отвечает за то, чтобы у нас появлялись новые серверы. Сложно звучит, но на самом деле, если ставить сотни новых серверов в месяц, то требуется отдельная служба, которая будет подключать новое оборудование и заменять старое, вышедшее из строя.

Мы стараемся отойти от «работы руками». Не секрет, что чем больше ручной настройки вы производите, тем больше вероятность ошибки. Соответственно, после того, как к вам приехала коробка с сервером, вы его распаковываете, вставляете в стойку, а дальше остается только подсоединить Ethernet и в появившемся меню сетевого загрузчика определить тип системы, которая будет поставлена. Грубо говоря, будет ли этот сервер фронтендом или хранилищем. Дальше он настраивается автоматически, а по окончании его setup’а система вводится в работу и подключается к системе мониторинга.

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

Внутренние стартапы

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

Первоначальная идея заключалась в том, чтобы дать возможность ребятам сделать что-то новое. Важно понимать, что, когда вы приходите работать в большую компанию (несмотря на то, что Mail.Ru Group крайне демократична), все равно есть какие-то общепринятые вещи и технологии, которые мы используем. А если вы работаете в нашем стартапе, у вас есть только одно правило: правил нет. Вы делаете, что хотите, и пробуете свои силы в создании нового продукта.

Разработчикам был дан полный карт-бланш. У Futubra отдельная команда, они могут использовать или не использовать те вещи, которые приняты у нас. Они пытаются делать новый продукт, какого в Mail.Ru Group еще не делали. Пока у ребят все получается.

Стек технологий

Сначала стоит сказать, на чем мы работаем. Основная база данных у нас — MySQl, плюс наша NoSQl СУБД Tarantool. В качестве веб-сервера мы используем свою собственную разработку, nginx и apache, в качестве почтового сервера — свой fork Exim’а, у нас есть даже такие сравнительно редко встречающиеся вещи, как собственный DNS-сервер. Из «больших кусков» — это все, плюс еще огромное количество модулей, которые мы писали для себя сами.

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

Относительно балансировки нагрузок есть «рецепт», который я обычно советую. Как, наверное, и все компании, мы начинали с аппаратных балансировщиков и перепробовали многие. Это было давно. Потом мы поняли, что любая аппаратная платформа рано или поздно загонит вас в свои рамки, которые у нее обязательно существуют. Поэтому в данный момент мы пришли к тому, что используем балансировку на Linux IPVS. Во-первых, это позволяет нам обрабатывать большое количество пакетов в секунду (для нас это принципиально: Mail.Ru Group — это история о высоких нагрузках). Во-вторых, это позволяет встраивать балансировщики в нашу систему. То есть мы можем балансировать любой сервис, который у нас существует.

У нас есть довольно высоконагруженный комплекс, который обеспечивает работу Instant Messenger’ов. Его тонкость заключается в том, что любой клиент — это постоянное соединение с вашим сервером. Наш комплекс тянет около 150 000 клиентов на одном сервере, а это довольно много. Конечно, это тоже потребовало изменений именно в сетевой части.

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

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

Безопасность в Mail.Ru Group

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

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

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

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

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

Работа в Mail.Ru Group

Честно признаться, я горжусь очень многими сотрудниками Mail.Ru Group. Особо выделить можно, например, Игоря Ермакова, который уже лет восемь работает с нами, и это один лучших IT-специалистов, что я знаю в стране. У нас работает очень сильная команда эксплуатации, возглавляет ее Алексей Бажин. На наш взгляд, это самые лучшие сисадмины :). Еще я могу выделить Андрея Калинина, который руководит разработкой поиска. Поиск для нас довольно новый продукт, по сравнению с другими компаниями мы не так давно им занимаемся. Но сейчас это однозначно самая наукоемкая и самая интересная разработка, которая у нас происходит.

Могу сказать, что за эти 10–11 лет нам удалось привлечь очень много сильных ребят. Мы стараемся набирать людей, которые горят работой. Я сейчас говорю не о тех людях, которые 24 часа в сутки проводят на работе, я говорю о тех, кому работа на самом деле нравится, о тех, для кого это так же, как и для меня, — хобби. Любой начальник старается подбирать людей по себе. Надеюсь, нам удалось собрать именно ту команду профессионалов, для которых работа — это все-таки нечто большее, чем просто работа.

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

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

Популяризация профессии IT-шника

Мы стараемся популяризировать работу IT-шника. Например, вспомните свое детство — человек хочет стать космонавтом, врачом, летчиком… Очень мало кто хочет стать iT-шником, так что мы поставили себе задачу, чтобы даже маленькие дети хотели стать IT-шниками. Это очень интересная профессия, а главное — за ней огромное будущее.

У нас есть три направления, по которым мы на данный момент работаем. Надеюсь, со временем их станет больше. Основная наша задача — сделать так, чтобы профессия IT-шника стала популярной и люди знали, что в Mail.Ru Group работают очень умные ребята и здесь интересно.

Первое: образовательные программы с вузами. На базе МГТУ им. Баумана мы обучаем студентов и стараемся сделать так, чтобы, окончив вуз, эти люди могли гарантированно пройти собеседование в любой крупной IT-компании России. Наша задача — чтобы после окончания вуза человек стал специалистом в той области, в которой он обучается. Чтобы у него не просто был набор базовых знаний, а чтобы появились практические навыки, необходимые для работы.

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

И третье: два раза в год мы проводим конференцию «Форум технологий». На ней мы делимся знаниями и навыками, которые наработали в нашей компании. форумов технологий два: один посвящен эксплуатации, второй — разработке. Мы стараемся пригласить тех людей, которые могут что-то дать нашей аудитории. Как правило, это западные докладчики. На последнем форуме Технологий можно было услышать более 20 докладов об эксплуатации UNIX-систем и информационной безопасности таких известных специалистов как Kris Buytaert, Garrett Honeycutt, Joshua Thiessen, и, конечно же, специалистов из Mail.Ru Group.