Накануне DevOps Conf Russia 2018 мы поговорили с техническим директором «Учи.ру» Алексеем Ваховым об этапах развития платформы, о том, какие инструменты они используют и насколько там все DevOps-ово.
Алексей Вахов — технический директор «Учи.ру». Работал разработчиком C++ в огромных системах (десятки миллионов строк кода). Любимая серверная технология — Ruby on Rails, входит в топ-100 контрибьюторов. Увлекается организацией IT-производства, эксплуатацией, архитектурой веб-приложений.
Uchi.ru — российская образовательная платформа, на которой школьники 1-11 классов изучают школьные предметы в игровой и увлекательной форме. Платформой пользуются более 2,5 млн школьников и 220 тыс. учителей в России, США, Бразилии, Индии, ЮАР и Китае. Занимает 36 место в общемировом рейтинге e-learning платформ. В компании более 400 сотрудников.
— С чего все начиналось? Сколько человек было в компании, когда вы пришли?
— В компанию меня позвали в 2012 году, то есть шесть лет назад. На тот момент я был пятым или шестым сотрудником, причем единственным разработчиком. Я и верстал, и вел серверную разработку. Мы сделали первое веб-приложение и выложилили на Heroku.
— Как обстоят дела сейчас? Сколько команд и каких размеров? Насколько самостоятельны? Как взаимодействуют друг с другом?
— На сегодняшний день нас более 400 человек, из них около 100 инженеров, которые объединены примерно в 20 отдельных команд. У нас два больших направления: продакшн-разработка и разработка интерактивных задач.
Отдельные команды имеют собственное изолированное окружение, специальные системы сборки, заточенные под задачи, которые выполняет команда, собственные сервера, исходники. С друг другом они коммуницируют только при необходимости.
— При такой скорости роста компании успеваете ли делать собственную wiki? Как вы ее поддерживаете?
— Баз знаний у нас несколько. Есть wiki в виде confluence, где есть общие и тематические разделы, и у каждой команды существует свой раздел. В каждом репозитории мы поддерживаем readme и дополнительные информационные документы. В любом случае каждой команде выделяется собственное пространство, свой кусочек в jira, в confluence, все это обустраивается по желаниям команды. Диктата и стандартизации по оформлению у нас нет.
— Резкий рост чреват потерей контроля. Как вы справляетесь с этим? Как координируете работу такого большого количества команд?
— Общая координация достигается за счет выстраивания иерархии управления. У нас есть координаторы направлений, а у каждой команды — свой руководитель. Тут все просто.
Если отвечать на этот вопрос с точки зрения технологий, то команды придерживаются общих правил, например, к каждому репозиторию подключены тесты, вся разработка идет в новые ветки, которые проверяются, выкатываются в тестовое окружение, потом в продакшн.
— Какие этапы становления компании ты выделяешь для себя?
— Мне нравится подход, о котором я прочитал в одной интересной книжке, согласно которому кризис — это когда рушится привычная система ценностей. В нашем случае из-за такого стремительного роста кризисов было много и каждый из них определяет дальнейшее движение.
Первый кризис наступил, когда в одной комнате нам стало тесно и пришлось расширяться до двух. На этом этапе появилась информация, которая перестала быть известна всем. Второй и последующие кризисы наступали, когда разработчикам приходилось делиться на продуктовые команды. Снова наш большой и дружный коллектив был вынужден разбиться и разъехаться по разным углам.
Любые изменения, которые происходили у нас, обязательно подкреплялись своевременными и актуальными технологическими нововведениями. Это же касается и методологии DevOps. Можно сказать, что я сам совсем недавно начал понимать что такое культурные ценности и почему они важны в больших командах. Например, было время, когда ни у кого не возникало вопроса о том, кто отвечает за стабильность сайта. Все понимали, что тот, кто выкатил сервис, за него и в ответе. Мы наняли человека, который должен был отвечать только за сервера, — и противостояние «разработчики vs администраторы» началось в тот же день. Это было удивительно, как по книжке.
— Расскажи подробнее о каждом из этапов. Какие инструменты вы принимали для себя, от каких пришлось отказаться? Насколько я понял из анонса твоего выступления на DevOpsConf 2018, вся ваша инфраструктура развернута в облаках в контейнерах docker'а. Почему вы пришли к такому решению? С какого момента вы не смогли жить без контейнеров?
— Сначала не было ничего, даже трекера. Только выкатка на Heroku: git push, и все довольны. Но Heroku быстро перестала нас удовлетворять, так как до нее достаточно большой пинг, и нагрузку они переносит плохо. Мы переехали на обычные железные сервера и наняли консультантов. Со временем сервера сильно замусорились. К этому времени у нас сильно увеличился трафик, количество продакшенов, внутренних и внешних сервисов. Сервера мы настраивали через Chef. В один прекрасный день мы упали под нагрузкой и уже к вечеру переехали в облако, используя Ansible. Ощущения при переходе на Ansible были просто космические. Он оказался простым и понятным, особенно в случае таких небольших инфраструктур.
Начиная примерно с 60 приложений, наша инфраструктура разрослась на отдельные, как мы их называем, «площадки». Это изолированные облака с собственными подсетями, с собственными конфигурациями terraform и ansible.
С ростом числа приложений и серверов наша конфигурация начала плыть, так как необходимо учесть много вещей, прежде чем запустить простое приложение на RoR. Плюс ко всему, часть конфига выкатки была в репозитарии с приложением, часть в ансибл-рецептах, разработчики начинали пользоваться тайной магией, делать линки на папки, какие-то синхронизации. В итоге это стало совсем невозможно поддерживать.
Когда у нас стало около сотни приложений в разных облаках, мы начали присматриваться к docker'у. Это было прошлым летом. Примерно за 10 месяцев мы перевели все свои приложения, а их к тому моменту стало около 150, на docker-кластеры. Это стало для нас настоящим спасением. Мы были избавлены от того, чтобы следить за версиями, за обрывками окружений на серверах. Все стало гораздо удобнее и проще: приложение легко можно было поместить в docker-кластер, легко оттуда удалить, у него была собственная метаинформация, из которой понятно, из каких сервисов состоит приложение, какие кроны, бэкграунд джобы и прочее запускаются.
— Насколько прочно вы стоите на оригинальном подходе DevOps? Все ли вас устраивает или же вы что-то меняли под себя? Сложно ли было перестраивать команду?
— У меня у самого нет точного ответа на вопрос о том, что же такое DevOps. В работе я всегда исхожу из простого здравого смысла. А люди говорят, что, оказывается, у нас тут DevOps вырос. На самом деле, теоретическая часть DevOps мне почти не нужна, потому что с меня бизнес спрашивает за результаты. Другими словами, если я им красиво расскажу и ничего не сделаю, это будет очень плохо, а если сделаю, но при этом не расскажу про красоту — все равно будет хорошо.
Мое понимание DevOps следующее. Например, есть какая-то большая компания, которая хочет сделать или уже делает цифровые продукты. Цифровые продукты — это всегда быстрая обратная связь с рынком. Автоматически возникает continuous delivery, размываются границы между разработкой и поддержкой, подтягивается культура DevOps-а, которая трактует правила хорошего тона между людьми, которые отвечают за выкатку, тестирование и поддержку. В итоге такие отношения позволяют им договориться между собой, чтобы прийти к общей цели, а также перенести фокус со своих личных обязанностей на общий результат. В большой и устоявшейся компании происходят изменения в процессах, их переламывание.
Так как у нас не было устоявшейся компании, поэтому принципы работы мы выращивали очень быстро. Причем бизнес постоянно подбрасывал нам новые задачи, поэтому мы строили нашу инфраструктуру в первую очередь исходя из здравого смысла и внутренних требований.
Само слово DevOps для меня мало что значило. Но сейчас, когда мы прошли через все это, когда я увидел возникновение точек конфликта, размытие ответственностей, я понял, что DevOps — это как культурный аспект взаимодействия между людьми ради общей цели. А общие цели в цифровых продуктах — это как можно быстрее делать новые фичи и выкатывать их.
— Интересно было бы узнать о том, насколько сложно новичкам влиться в вашу работу при таком большом количестве современных инструментов. Как у вас организована работа с людьми?
— У нас есть программы адаптации. Мы рассказываем новому сотруднику о том, как мы развивались и как сейчас все устроено, прикрепляем к нему наставника. В первый же день мы помогаем ему настроить окружение и выдаем боевую, но не очень сложную задачу. Наставник сопровождает его в течение нескольких месяцев, помогает с адаптацией.
— Расскажи о планах компании. Куда вы планируете расти и какие направления развивать? Дает ли текущий стек технологий задел на дальнейший рост или придется очередной раз менять его?
— Планы у бизнеса амбициозные. Сегодня на «Учи.ру» регулярно занимаются более двух миллионов школьников — в масштабах страны это около 30% всех учеников начальных классов. Будем и дальше привлекать новых пользователей на платформу в России и заниматься международным развитием.
Технически у нас 15 изолированных докер-кластеров, и довольно много времени уходит на переключение с одного на другой, сложно стало обслуживать, модернизировать. Требования по скорости изменений и надежности только растут. Поэтому задел есть, но обновлять тоже будем.
Друзья, если вам интересен опыт Алексея, спешим пригласить на нашу DevOps Conf Russia 2018, которая пройдет 1-2 октября. В своем докладе он расскажет об опыте использования облаков, применении методологии DevOps, о ценностях и принципах своей команды.
Подписывайтесь на тематическую рассылку Онтико по DevOps, чтобы получить обновления программы, как только они появятся. Мы стараемся, чтобы письма были полезные и не навязчивые, высылаем новости конференций, расшифровки докладов, свежие видео.
Кстати, отдельно видео можно мониторить на YouTube-канале — там собраны все видео за последние годы и список все время пополняется.
Автор: Александр Титов
