Курс молодого бойца


0. Добро пожаловать в команду разработки Почты@mail.ru!
Ничего, если я на ты? ... Молчание - знак согласия :)  Итак, с чего бы начать. Наверное, с зоны нашей ответственности.
1. Зона нашей ответственности
Мы (а теперь и вместе с тобой) отвечаем за две страницы - морда портала mail.ru (www.mail.ru) и Почта@mail.ru (e.mail.ru). Что такое отвечаем? Это значит, фиксим баги и имплементим фичи. Ежедневная аудитория этих страниц - 18 млн. человек. Это, между прочим, 12% населения нашей страны, включая младенцев и стариков. Сервисами, за которые ты отвечаешь, пользуется ежедневно каждый 8-ой житель нашей страны. Впечатляет? Кодь аккуратно, шаг вправо, шаг влево и миллион человек обидятся на нас. Хотя, я уверен, что такого не произойдет. Если ты читаешь этот документа, значит прошел через терни наших собеседований, а значит являешься профессионалом самого высокого класса, как и все члены команды Почты@mail.ru. Почему, я употребляю слово "Мы", когда говорю об ответственности? Потому что мы не делим четко зоны ответственности между разработчиками. Разумеется, у каждого разработчика есть части кода, который он правит сильно чаще, чем другие. Но в целом, у нас предполагается, что любой разработчик может "вонзиться" (это такой наш емкий и понятный термин) в почти любую часть кода. Почему "почти". Потому что у каждого разработчика есть определенная специализация: верстальщики, JS-программисты, перловики, сишники.
2. Устройство почты
Давай, я расскажу вкратце как устроена наша почта. Только самые основные моменты, без деталей.
2.1. Физически почта состоит из тысяч серверов, которые расположены в наших датацентрах. Сами сервера можно разделить на несколько групп: фронты, базы, стороджа, MX'ы, POP3/SMTP, тарантулы, остальное. Не пугайся пока непонятных тебе местных терминов. В дальнейшем они все будут раскрыты.
2.2. Запросы на веб-интерфейс почты от пользователей идут через домен e.mail.ru. Который резолвится в несколько IP адресов, которые в свою очередь балансятся на все фронты (их на данный момент 250 штук). На фронте установлен nginx, который слушает 80-ый порт. Часть запросов nginx проксирует на локальный apache, а другую часть также локально проксирует на наш самописный http-сервер, который мы называем "аутх" (от слова auth). Аутх обрабатывает запросы на список писем, страницу успешной отправки сообщения, авторизацию. Апач обрабатывает все остальные запросы, посредством перловых скриптов, которые мы называем словом "перлячка". Зачем такое разделение на апач и аутх? Дело в том, что аутх - очень быстрый сервер, в котором как сервер, так и вся логика написаны на C. Он построен на event driven модели, с использованием epoll. Поэтому на аутхи сыпятся запросы на самые часто используемые страницы. Пару слов про верстку. Верстка хранится у нас в шаблонах. Используется самописный язык шаблонов. Он, в общем, похож на все языки шаблонов - html + спецвставки для переменных, функций, ифов, циклов. Неважно чем отдается страница, перлячкой или аутхами, используется один и тот же язык шаблонов. Верстальщики и JS-программисты правят непосредственно шаблоны.
2.3. Теперь про базы. Серверов баз данных у нас много (десятки). И все они - MySQL. В базах хранится почти все, кроме ящиков пользователей (они хранятся на стороджах - см. далее). Пока все, что тебе нужно знать про базы - это то, что есть табличка user, в которой хранятся все пользователи. По кажому из них в этой таблице хранится имя, md5(пароль), стородж + путь на стородже где живет ящик пользователя (st_path).
2.4. Стороджа. Стороджей у нас более 4000. На каждом из них порядка 20 дисков. Диски собраны попарно в софтверные RAID1 (зеркала). На стороджах хранятся ящики пользователей. Ящик - это директория, в которой лежат письма (по файлу на письмо), индекс (файл для быстрого формирования страницы со списком писем), и еще разные вещи, которые мы не стали хранить в базах, например адресная книга. Почти каждый из стороджей, обычно, забит на 95%. Это достигается постоянно работающей специальной системой автомува, которая мувит ящики между стороджами, когда видить перекосы в свободном месте. На стороджах работает наш самописный сервер mpopd. Доступ к нему производится через наш протокол mPOP. Доступ к стороджу из C/C++ кода происходит через библиотеку mPOP, в которой реализовано взаимодействие со стороджем по одноименному протоколу. Доступ к стороджу из перлячки происходит посредством той же библиотеки через XS (это такая штука для доступа из перла к сишномым либам).
2.5. MX'ы. MX-запись доменов, на которые мы принимаем почту (mail.ru, list.ru и т.д.) смотрит в имя, которое резолвится в IPшники балансеров, которые в свою очередь балансят запросы на MX-сервера (их около 100 штук). На каждом MX'е работает MTA exim. Он когда-то был из коробки, а теперь уже сильно патченный нами. Т.е. мы не стесняемся менять прямо в исходнике exim'а все, что нам надо. Внутри exim'а определяется, на какой стородж доставлять письмо. Там же реализована вся логика пользовательских фильтров. К слову, exim'ы работают не только на MX'ах. Они же работают еще на фронтах, т.к. с фронтов тоже доставляется почта, как внутрь так и наружу.
2.6. Еще у нас есть POP3 и SMTP - это чтобы можно было пользоваться нашей почтой из почтового клиента. На SMTP установлены тоже наши патченные exim'ы. На POP3 установлен наш самописный POP3-сервер, который ходит в стородж. А кроме того на POP3 перед POP3-сервером стоит антибрутфорсная прокся. POP3 и SMTP - это не отдельные серверы, а кластера. Т.е. pop3.mail.ru смотрит на балансер, которые балансит трафик по нескольким десяткам POP3-серверов. То же самое касается и smtp.mail.ru.
2.7. Тарантулы. Тарантул - это наша самописная база. Она очень быстрая, сильно быстрее MySQL, хотя и со своими
минусами (подойди - расскажу). В тарантулах у нас хранятся сессии. Каждый запрос на веб-интерфейс приводит к запросу в тарантул с кукой пользователя. В ответ тарантул говорит, авторизован пользователь или нет, а также выдает некую служебную инфу, которая хранится в сессии, но которую не хочется тягать лишний раз из базы (например, st_path).
2.8. Остальное. Остального много, тут всего не опишешь. Например, есть у нас сборщик почты (rpop), атач-фронты для отдачи атачей (af'ы и ajf'ы), rmspam (сервера, проверяющие на спам после покладки писем в ящики). У нас есть mpopcached - это сервера, которые кэшируют по каждому пользователю количество новых писем для показа их на морде. Есть еще куча всего, но пока не хочу тебя грузить, по ходу дела разберешься, если понадобится.
2.9. Взаимодействие с внешними системами. Почта не живет в вакууме и взаимодействует с внешним кодом. Основное, с чем взаимодействует почта: Антиспам (MRAS + KAS), Антивирус (KAV), Мой Мир, Агент (сервер), Агент (клиент), RB, Все остальные проекты mail.ru (!).
2.9.1. Антиспам. Письма, приходящие на почту, проверяются на спам. У нас есть две антиспам системы. MRAS - наша самописная. За ее работу отвечает другой отдел. Но мы отвечает за корректное взаимодействие с ней. Например, отвечаем за отправку входящих писем туда на проверку, а также за отправку туда образцов спама при нажатии кнопок "Спам" и "Не спам" в веб-интерфейсе. KAS (Касперский) - это вторая антиспам система. Она работат наравне с MRAS'ом. Каждое письмо проверяется обоими антиспамами. Если хотя бы один из них счел письмо спамом, то мы считаем его спамом.
2.9.2. Антивирус. В качестве антивирус у нас используется KAV. Каждое входящее письмо проверяется на вирусы.
2.9.3. Мой Мир - это социальная сеть mail.ru. Они привязаны к нам двумя концами. Во-первых. У нас общая перловая кодовая база. Т.е. как бы есть общий перловый код Почты и Моего Мира, но сервера, на которых он работает - разные. Такая связь в частности позволяет Моему Миру обращаться на стородж напрямую посредством mPOP, а также позволяет напрямую работать с нашими базами (той же таблицей user). Во-вторых. Мой Мир использует наши exim'ы для отправки почты нашим пользователям. Поскольку - это наши exim'ы, то внутри них срабатывают фильтры и прочая логика, которую мы туда добавляем. У такой связи есть минус: каждая выкатки exim'а - это выкатка не только на наши сервера (MX, SMTP, фронты), но и на их сервера (mysender'ы).
2.9.4. Агент - это мессенджер mail.ru. К слову, это самый популярный мессенджер в рунете. Сообщения отправленные в оффлайн в агент хранятся в почте в виде писем в специальной невидимой папке. Когда у пользователя агент приходит в онлайн, то все сообщения скачиваются с наших стороджей и удаляются. Поскольку мессенджер самый популярный, то он создает достаточно большую нагрузку на наши стороджа. Не работающий стородж - это неработающий агент у нескольких сотен тысяч пользователей. Серверная часть агента собрана с нашим mPOP'ом, посредством которого он и общается со стороджами. Также агент использует наши базы, в т.ч. таблицу user.
2.9.5. Агент (клиент). Клиентская часть агента тоже завязана на почту. В агенте есть возможность регистрации пользователя, которая производится через страницу, лежащую на наших серверах. Кроме того, есть еще мобильная версия агенты, внутри которой есть почтовый клиент, работающий только с почтой mail.ru, и не по протоколу POP3, а по нашему собственному API (цель: минимизировать трафик, для пользователей мобильных телефонов, сам знаешь, трафик дорогой). Это API реализовано частично в перлячке, а частично в аутхах и работает на наших фронтах. Перлячка, Фронты, Аутхи ... не потерялся еще в нашей терминологии? Ничего, запомнишь :).
2.9.6. RB - это наша баннерокрутилка + CMS'ка + система счетчиков. Каждый баннер, который ты видишь на страницах почты показывает посредством RB. Причем, иногда не баннер, а просто кусок HTML показывается также через RB. Например, вся морда mail.ru порезана на много RB-слотов. Каждый показ слота - это обращение к RB. Как это все быстро работает? Очень просто. На каждом фронте находится файлик, отображенный в память, в котором описана логика показа всех слотов. Показ слота - это обращение к либе, которая лукапит в этот файлик и сразу получает кусок HTML, который надо показать. Все изменения в слоты RB происходит через админку, которая хранит все в мускульной базе. Каждый 5 минут из этой базы создается файлик, который публикуется по всем фронтам.
2.9.7. Все остальные проекты mail.ru завязаны на почту. Во-первых, они авторизуются через нашу базу и хранят сессии в наших тарантулах. Но, слава богу, делают это не напрямую, а через специальный сервис swa.mail.ru, который мы называем словом "сва" или "свы". Сва - это тоже наш самописный сервер, как и аутхи. На самом деле - это один и тот же сервер, который называется общим словом "имагин" (imagine). Кстати, не удивляйся, что мы коверкаем английские слова - это не от безграматности, просто эти термины появились давно, и это прижилось. Так вот, аутх и сва - это разные сборким одного и того же сервера - имагин. Во-вторых, остальные проекты используют профиль пользователя. Профиль - это такое минихранилище по каждому пользователю, в котором хранится много всего, например, ФИО и настройки авторизации. Физически профили хранятся на стороджах. Мы в данный момент мы переводим их в отдельные базы. С точки зрения остальных проектов - это не важно, они имеют доступ к профилям только через сву.
Уффф ... устал печатать. Кажется, основное рассказал. Если будут вопросы - подходи, все объясню.
3. Процесс.
Почта@mail.ru - это один из крупнейших в нашей стране программно-аппаратно-биологических комплексов. Ядро разработки из 15 человек, плюс 6 системных администраторов, много тестировщиков и сотрудников тех поддержки, порядка 20 внешних разработчиков, но тоже влияющих на почту или хотящих что-то от почты из команд Антиспама, Моего Мира, Агента, 4 IT-менеджера, порядка 10 продуктовых менеджеров. И далеко не все они сидят на нашем этаже. А некоторые даже в других офисах или других городах. А еще - тысячи серверов и миллионы строки кода.
Работу всей этой огромной и гетерогенной системы немыслимо себе представить без четко определенного процесса планирования, постановки задач, оценки сроков, разработки, тестирования, выкатки, фидбэка пользователей.
Системообразующий элемент нашего процесса - это Jira (Джира). Все вышеперечисленные члены команды и внешних команд используют джиру. Не знаю, слышал ли ты про джиру или нет, поэтому буду рассказывать так как будто бы ты это слово слышишь в первый раз. Джира - это баг-трекер, т.е. система управления задачами. Деятельность любого человека в команде - это либо выполнение задач, либо постановка задач. У задачи есть постановщик. Постановщик - это заказчик, человек обладающий четким и полным понимаем, что он хочет получить в результате выполнения задачи. У задачи есть исполнитель - это человек, который может сделать то, что хочет заказчик. Рабочий день разработчика обычно состоит из выполнения задач. Он открывает джиру, берет задачу с самым высоким приоритетом. После ее выполнения берет следующую задачу с самым высоким приоритом, и т.д. Если в работе над задачей происходит прерывание (ожидание уточнения постановки, приостановка задачи заказчиком, ожидание со стороны другого разработчика, и т.д.), то разрабочик переключается к другой задаче с самым высоким приоритетом, а к старой задаче возвращается после очередного прерывания или завершения текущей задачи, если, конечно, на тот момент не задачи с более высоким приоритетом. Если у разработчика есть несколько задач с одинаковым приоритетом, то он обычно делает ту, которую сделать проще быстрее по его мнению, либо обращается к начальнику за уточнением. Как все мы знаем, таск-свичтинг у разработчика может быть очень дорогим по времени, причем это завист от сугубо индивидуальных особенностей человека. В случае частого скакания между тасками разработчик обращается к руководителю, чтобы он по возможности перебалансировал приоритеты его задач так, чтобы минимизировать скакание. Переключение на другой таск может произойти также в случае, если руководитель попросил об этом разработчика. Обычно, руководитель просит "все бросить и сделать вот это" в случае, если есть (или вот-вот будет) реальная большая проблема в продакшне. Иногда задача ставится устно (обычно, когда все настолько плохо в продакшне, что надо срочно чинить). В этом случае руководитель ставит таск постфактум или прямо в процессе его выполнения. Задачи ставятся на разработчика всегда либо его руководителем либо с согласия руководителя. Таск поставленный без согласия руководителя (такие случаи крайне редки, но бывают) сторонним человеком, делать не надо, ну и по возможности поставить в известность руководителя.
3.1. Теперь в двух словах, как пользоваться джирой.
На странице jira.mail.ru выводятся по умолчанию, в том числе, все таски, которые стоят на тебе. Они могут все туда не поместиться. Поэтому для более точного контроля за своими тасками рекомендуется создать запрос на поиск всех тасков на себе. У тасков есть приоритет. В первую очередь надо делать таски с приоритетом 1, потом 2, и т.д. Приоритетов всего 10. Как показывает практика до тасков с приоритетом 5 руки не доходят. Поэтому, если ты берешься за таск с приоритетом 5 - это означает, что либо ты очень быстро работаешь (что есть супер!), либо означает, что ты потерял более приоритетные таски. У тасков есть состояния. Изначально поставленный таск ставится в состоянии Новый (New). Когда ты принимаешься за таск, то читай внимательно его постановку. Если есть вопросы к ней, то задавай их постановщику (постановщик показывается на странице таска). Вопросы можно задать как в самой джире через комментарий к таску, так и любым другим способом. Когда постановка становится понятна, то попроси постановщика, чтобы он актуализировал ее в джире. В противном случае потом после исполнения таска не будет понятно, что хотелось постановщику. Если тебе постановка понятна и ты готов заниматься таском, то ты нажимаешь на кнопку "В работу". В результате чего таск переходит в состоянии "In Progress". После того как таск запрограммирован и по твоим ощущениям работает на разработческом сервере, а также по твоим ощущениям не ломает ничего рядом, ты ставишь связанный таск на админов (кнопка "Create and link") для выкатки результатов твоей работы на тестовый сервер. Если ты занимаешься версткой или JS, то выкатку на тестовый сервер ты производишь сам через раскладчик. Как им пользоваться - уточни у своих коллег или руководителя разработки client side'а почты. При постановке таска на админов надо ставить либо сразу на админа, ответственного за выкатку твоей части кода, либо, что лучше, на соответствующий компонент. Замечу, что в этой главе я намеренно не рассказываю как собственно вести разработку, откуда брать исходники, куда комитить с чем мерджить, и т.д. Этому посвещены отдельные главы - см. далее. После постановки таска на админов ты можешь переходить к другим задачам. Хотя, как вариант, можно подойти к админу и пнуть его, чтобы выкатил прямо сейчас. О выкатке таска на тестовый сервер ты узнаешь по письму в почту об изменении статуса твоего таска на админов. Кстати, изменения о статусов всех тасков, где ты постановщик либо исполнитель, приходят к тебе на почту. После прихода уведомления о выкатки на тестовый сервер ты должен проверить, что оно там действительно работает. И, если не работает, то починить и опять поставить таск на админов. А если работает, то нажать на кнопку "В тестирование" и перевести таск на постановщика. Проверку работы на тестовом сервера и дальшейшие фиксы, если требуется, надо производить исходя из приоритета таска и общей схемы работы. Т.е., например, если ты уже переключился на другой таск, пока админы выкатывают предыдущий таск, то не обязательно возвращаться к проверке сразу же, можно это сделать и после выполнения нового таска, или в любое другое удобное время. Таск, отданный в тестирование проверяется его постановщиком (возможно, с помощью привлечения тестировщиков - на усмотрение постановщика). Если с точки зрения постановщика функционал не работает, то он возвращает таск обратно на исполнителя, нажав на кнопку "Баги". В этом случае исполнитель начинает опять работу над таском, исходя из приоритетов, так, как если бы он был поставлен заново. Если постановщик считает, что таск работает на тестовом сервера (ура!), то он нажимает на кнопку "Апрув" и тест попадает в состояние "Готово к выкатке", сам таск переводится на исполнителя. Это состояние означает, что таск можно выкатывать. Дальнейшие действия исполнителя сильно зависят от того, в каком функционале был сделан фикс/фича.
3.1.1. Перлячка или mPOP (в случае выкатки на фронты). Исполнитель не делает ничего. Выкатка перлячке обычно происходит раз в неделю - по средам. Каждая такая выкатка называется "итерация" и имеет название по дате начала и завершения, например: 19.05-25.05. Во вторник с утра ведущий разработчик (Николай Шуляковский) смотрит все таски в состоянии "Готово к выкатке", выбирает из них те, что затрагивают перлячку или mPOP для выкатки на фронты, мерджит их всех в одну ветку по имени итерации и ставит таск на админов на выкатку на продакшн-сервер, выключенный из нагрузки. Во вторник же с утра админ выкатывает на этот сервер и уведомляет об этом техдира почты. Техдир проверяет работу почты на этом сервера (обычно он "живет" в этой почте до среды и просит тестирование проверить работу почты). В среду утром админы включают сервер с новой итерацией в нагрузку. И, если не сыпятся ошибки, то по апруву техдира раскатывают на "живое" (т.е. на всех пользователей). Если происходит "лажа" (понятно, наверное, о чем речь), то итерация откатывается и ведущий разработчик, либо другой разработчик быстро фиксят лажу, без таска. Выкатка перлячки на фронты бывает и без итерации. Например, если есть срочная проблема. Схема ровно такая же как и с итерацией. Фактически создается еще одна мини итерация хотфиксов и выкатывается по тем же правилам. Решение о необходимостм выкатки вне итерации принимает техдир почты.
3.1.2. Exim. Фиксы в exim происходят относительно редко и не привязываются к перлячим итерациям. Обычно эти фиксы связаны с фильтрами или персональным антиспамом. Разработчик, получив обратно таск на выкатку фикса в exim'е, ставит связанный таск (в Джире - More actions/Create and link) на админов, при этом прописывая в таске на админов либо компонент exim, либо выбирая Евгения Дмитриева в качестве исполнителя. В таске указывается, что надо выкатить на 1 машину без нагрузки. А также указывается, куда именно надо выкатывать. По умолчанию, все выкатывается на фронты, MX, SMTP. Админ самостоятельно уведомит техдира почты о выкатке. После выкатки на 1 машину без нагрузки связанный таск вернется разработчику. Получив этот таск, разработчик проверяет, что на 1 машине все работает. После чего он отдает связанный таск обратно админу с просьбой включить нагрузку. Далее оно работает несколько часов или сутки с одной машиной, после чего админ уже самостоятельно согласовывает с техдиром выкатку на все машины. Разработчик при желании может ускорить этот процесс, если пнет админа или техдира. Если разработчик вносит фикс и в персональный антиспам, то надо выкатить еще и на Мой Мир. В этом случае схема дополняется постановкой еще одного таска на админов Моего Мира (Сергей Середа).
3.1.3. Стородж. Фиксы в стородж - это самые стремные фиксы, ибо в случае ошибки на стородже есть вероятность потери или коррапта писем. Постановщик тасков на фиксы стородже обычно лично техдир почты. Проверив фикс на разработчкеском сервере, разработчик ставит связанный таск на админов (Сергей Кубасов или компонент "стороджа") на выкатку на тестовый стородж. Админы, выкатив на тестовый стородж уведомляют разработчика в таске техдира лично. Оба они проверяют, что все работает на специальных тестовых пользователях. После чего техдир принимает решение о схеме дальнейшей выкатки (уже без участия разработчика). Обычно схема такая: выкатываем на 1 живой сервер, ждем несколько часов, потом на 5-10 серверов, ждем 1-2 дня. Потом, помолясь, на все.
3.1.4. Аутхи. Аутхи также выкатываются вне перлячных итераций. Их выкаткой руководит лично главный разработчик аутхов, поэтому описывать тут полностью схему их выкатки не буду. Если вкратце, то эта схема в точности повторяет выкатку перлячки (тестовый сервер, продакшн-сервер без нагрузки, продакшн-сервер с нагрузкой, на всех).
3.1.5. Верстка. Верстка (шаблоны, статика, JS) выкатывается вне итераций. Разработчик, получив таск в состоянии "Готово к выкатке" выкатывает самостоятельно через раскладчик непосредственно после получения таска обратно, если в таске указано выкатить сегодня. О выкатке разработчик пишет в конфу "Выкатки верстки", где дает ссылку на выкаченный таск. Если в таске не указано выкатить сегодня или явно указано не выкатывать пока, то разработчик ничего не делает до особого распоряжения руководителя. Такие ситуации бывают в случае, если выкатка верстки приурочивается к выкатке перлячки и/или аутхов.
3.1.6. Остальное (POP3, RPOP, rmspam) выкатывается крайне редко. Но общая концепция такая же - проверка разработчиком на разработческом сервере, таск на админов на выкатку на тестовый сервер, проверка разработчиком и постановщиком на тестовом сервере, апрув постановщика или техдира на выкатку в продакшн.
3.2. Взаимодействие разработчиков друг с другом.
Несмотря на то, что каждый делает свои таски, вся работа происходит в команде. Поэтому часто надо обращаться друг к другу с вопросами или просить помощи. Не стесняйся это делать. А также помогай сам всем разработчикам, которые просят помочь, исходя всегда из презумпции, что баг у тебя в коде. В случае, когда одному разработчику необходимо в рамках выполнения таска, чтобы другой разработчик выполнил часть таска, надо ставить сабтаск на другого разработчика. Необходимость постановки сабтаска согласовывается устно (или в любой удобной тебе форме) с руководителем. Помни, что в случае постановки сабтаска ты выступаешь в сабтаске в роли постановщика. А значит, ты должен самостоятельно проверять, что исполнитель сделал именно то, что ты хотел (см. схему работы с джирой выше).
3.3. Теперь пару слов про исходники. Исходники у нас хранятся в git'е. Путь к репозиторию уточняй у своих коллег или у меня. Доступ в репозиторий получается у админов (лучше подойти и устно попросить). Разработка каждой новой фичи ведется в отдельной ветке, которая создается по номеру таска и отпочковывается от мастера. Когда подходит время выкатки, то все ветки смердживаются в одну (она называется по номеру итерации), которая и выкатывается. Все хотфиксы производятся в ту же ветку итерации. После выкатки ветка итерации вмердживается в мастер. Замечу, что эти правила строго соблюдаются лишь для перлячки, т.к. перлячка выкатывается релизами по 10-20 тасков. Верстка, exim, mpopd выкатываются обычно по одному таску за раз, поэтому разработка ведется в отдельной ветке, которая после выкатки вмердживается в мастер.
Ну вот, пожалуй, если кратко, то все, что тебе нужно знать на первых порах. Остальные знания получишь уже в бою :)