Эмиль Шарифуллин из «Яндекса»: «Больше всего в работе мне нравится сложность»

Я делю всю разработку на бизнес-разработку и инфраструктурную — это моё видение мира. Инфраструктурная разработка — это всё то, что вы делаете для разработчиков, а бизнес-разработка — это всевозможные сервисы для конечных пользователей.

Сам я работаю в Yandex Cloud, а наша команда занимается управляемыми базами данных Redis и MongoDB. Суть управляемых баз данных в том, что клиент избавляется от необходимости настройки и администрирования СУБД для своих проектов, потому что мы предоставляем ему развёрнутую и рабочую базу данных на своих мощностях.

У «Яндекса» есть несколько дата-центров в России и один в Финляндии — на собственных серверах, которые производят в Китае и Тайване, а проектируют полностью внутри компании, под свои нужды. Приоритеты — энергоэффективность и удовлетворение потребностей.

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

Общаясь с ребятами, которые специализируются на бизнес-разработке, я выделил для себя несколько ключевых отличий от работы над инфраструктурными проектами:

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

Сложные, индивидуальные наукоёмкие задачи. В инфраструктурной разработке их приходится решать гораздо чаще, чем в бизнес-разработке, большинство задач в которой, как часто шутят программисты, — перекладывание JSON из запроса в базу данных и обработка их по правилам из DDD.

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

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

Кстати, современные IT-системы так или иначе построены на костылях — просто потому, что есть вещи, которые нельзя реализовать чисто физически. Например, вы не сможете сделать так, чтобы у вас на нескольких серверах было одинаковое с точностью до наносекунд время. Даже если вы их соедините оптоволоконным кабелем, всё равно пройдёт какое-то время, прежде чем сигнал пройдёт от одного сервера до другого. Поэтому такие моменты нужно заранее продумывать.

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

Работа с инфраструктурой в большой компании

Раньше я разрабатывал инфраструктурные сервисы в Red Hat и контуре CI/CD-системы, системы мониторинга и тому подобное, а сейчас перешёл в сервис управляемых баз данных. Сервис управляемых баз данных — это часть «Яндекс.Облака», которая позволяет максимально просто и удобно развернуть облачную БД и не заморачиваться с поддержкой.

Клиент просто приходит и говорит, что ему нужна MongoDB или Redis и определённое количество ресурсов, а мы устанавливаем и настраиваем нужные пакеты и выдаём ему готовую рабочую БД.

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

При этом базовые навыки всё те же: установить пакет и зависимости, которые нужны для работы приложения. Вот только в небольшом стартапе вы будете всё это поднимать на двух-трёх выделенных серверах или арендованном кластере на Kubernetes, в котором всё сразу запустится.

В больших компаниях всё немного по-другому: вам (а скорее вашим коллегам из отдела инфраструктуры) сначала придётся самостоятельно установить и настроить Kubernetes или другой оркестратор и уже после этого добавить все необходимые приложения и конфигурации. А так так подобных задач в больших компаниях много, то есть сотрудники, которые на фул-тайм занимаются исключительно установкой и настройкой Kubernetes.

Мой опыт — на стыке DevOps и программирования. Я плотно занимался DevOps на предыдущей работе, в стартапе, а теперь использую знания и скиллы, чтобы создавать инфраструктурные сервисы для разных компаний.

И на уровне инструментов это очень разные процессы: например, условный Ansible больше подходит для работы на небольших проектах или в небольших командах, так как поддерживать большие плейбуки и раскатывать их на тысячи серверов довольно сложно, поэтому у нас в команде используется salt и куча внутренних специализированных инструментов. И это распространённая практика — даже в Red Hat, команда которой и разработала Ansible, многие его не используют, потому что он им просто не подходит.

Как проходит рабочий день инфраструктурного инженера и какие инструменты он использует

День разработчика в разных компаниях проходит примерно одинаково. Вы просыпаетесь, идёте в душ, наливаете кофе и садитесь за работу. Сначала смотрите, что произошло со вчерашнего дня, обновляете почту, проверяете, есть ли проблемы с code review, а дальше пишете код, ходите на встречи, обсуждаете проблемы.

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

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

Чем я пользуюсь в работе:

• Редактор кода — в моём случае это Visual Studio Code.
• Средства коммуникации — в зависимости от компании, это может быть Telegram, Zoom, Slack, электронная почта.
• Консоль — в ней я «живу» и провожу большую часть операций.
• Хранилище кода и средства для code review — это могут быть и репозитории, и специализированные инструменты вроде Gerrit. Всё зависит от того, чем привыкла пользоваться команда. Например, в Red Hat ребята, разрабатывающие ядро Linux, обмениваются кодом по электронной почте — отправляют патчи прямо в письмах.
• Docker. Он закрывает потребность во всех остальных инструментах. Если нужна база данных, её можно поднять в Docker, если нужны какие-нибудь средства автоматизации, он и тут выручит. Иногда я даже поднимаю в Docker компилятор или интерпретатор, если необходимо собрать код в конкретной версии. В своё время Docker стал прорывной технологией — и я даже не знаю, как вообще можно без него жить.
• Kubernetes — оркестратор, инструмент для разворачивания контейнеров на большом парке серверов на кластере. Он создаёт большой виртуальный кластер и помогает удобно им управлять. Сейчас Kubernetes работает не только с Docker — хотя изначально в Google создавали Kubernetes именно под него. Например, существует инициатива Open Container, которая описывает, как у вас должны запускаться контейнеры и как они должны выглядеть — и Kubernetes её поддерживает. А форк Kubernetes от Red Hat — OpenShift — умеет работать с аналогом Docker от Red Hat, который называется Podman.
• Собственные инструменты «Яндекса». Для CI/CD мы используем собственные инструменты или общедоступные решения типа Jenkins. Самописные инструменты появляются эволюционно: сначала ты собираешь небольшой скрипт, чтобы автоматизировать какой-то процесс. Потом ты меняешь его, чтобы он по-разному вёл себя в зависимости от задачи, — а дальше внедряешь в другие команды. Например, у нас есть написанные в «Яндексе» система контроля версий, система сборки, свой репозиторий кода. Конечно, такие решения создаются с оглядкой на стандартные инструменты, и многие команды у них совпадают, однако к ним всё равно приходится некоторое время привыкать.

Ключевые знания и навыки сеньора

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

Алгоритмы. Сюда я отношу фундаментальные знания алгоритмов, понимание, что такое асимптотика алгоритма, как тот или иной алгоритм будет работать, как устроены распределённые вычисления.

Архитектура и насмотренность в разных технологиях. На предыдущей работе я сам гонял кандидатов по архитектуре и называю это «собеседованиями на сеньора» — потому что понимание архитектуры сразу показывает реальный уровень разработчика. Даже если он легко щёлкает самые заковыристые алгоритмы, но при этом не умеет проектировать системы, он не сеньор.

Ко мне приходили кандидаты, которые проработали 10 лет в одной компании и выросли там от джуниора до сеньора. И все десять лет они занимались одним проектом — да, в нём они разбираются прекрасно, но, когда спрашиваешь у них, как построить какую-то другую систему, они не могут выйти за рамки технологий, которые использовали на протяжении 10 лет. Просто потому, что знают только эти технологии. У них даже появляется некий карго-культ: следовать по определённому маршруту, даже если это далеко не идеальное решение.

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

Например, мне как-то понадобился ZooKeeper. До этого я никогда с ним не работал, но за день прочитал документацию, посмотрел, какие алгоритмы используются внутри, и тут же начал его использовать. Скажу так: чтобы базово изучить любую технологию и написать простые приложения, достаточно одного-двух дней. А через пару месяцев практики вы уже будете неплохо разбираться в новой технологии и чувствовать себя уверенно (ну, кроме Kubernetes, там годами можно копаться в его устройстве).

Единственная технология, к которой я сильно привязан, — это язык Go. Мне он очень нравится, я дичайше кайфую от него и даже проводил курс по Go. При всякой возможности его рекламирую и агитирую всех писать на Go.

На мой взгляд, для инфраструктурных проектов Go сейчас, наверное, один из самых подходящих языков. Он позволяет писать кучу всего — да те же Kubernetes и Docker написаны на нём, а это уже о многом говорит.

Софт-скиллы. Тут интересная ситуация. В нулевых софт-скиллы были не так важны, если человек гениально пишет код. Но в какой-то момент компании поняли, что это не всегда оправданно. Программирование — это командная работа: если завтра гениальный разработчик уйдёт из компании, кто будет дописывать и поддерживать его гениальный код? А когда у вас есть сильная команда, вы застрахованы от этой проблемы.

Чем выше вы поднимаетесь по карьерной лестнице, тем большую роль начинают играть софт-скиллы — потому что и коммуницировать придётся всё больше и больше. Если джуниор коммуницирует только со своим непосредственным руководителем, то мидл уже обсуждает задачи и решения с коллегами. Тимлид и вовсе выполняет менеджерские обязанности, а значит, коммуникации занимают основную часть его рабочего времени.

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

Как сеньору пройти собеседование в энтерпрайз

Чтобы получить оффер на позицию сеньор-разработчика инфраструктурных сервисов в крупную компанию вроде «Яндекса», придётся пройти несколько собеседований.

Базовые знания. На первом интервью я рассказал о себе и решил банальную алгоритмическую задачу. Ещё меня спрашивали про устройство операционных систем и UNIX в частности, проверяли, насколько хорошо я разбираюсь в computer science, задавали вопросы по SQL. Это всё — база, без которой на высоких позициях работать невозможно.

Junior-разработчик, наверное, может писать код на C#, не зная, что у него под капотом и как работает его код, как создаются те или иные соединения, как происходит сетевое взаимодействие. Он просто посылает HTTP-запрос или обрабатывает HTTP-запросы на своём веб-сервисе, и всё.

Но когда вы разработчик более высокого уровня, нужно понимать, что HTTP-запросы — это несколько слоёв абстракции, а значит, на любом из этих слоёв могут возникнуть проблемы. Банально могут закончиться лимиты на открытый файловый дескриптор, или в сети будут неполадки, пакеты могут теряться. Такие нюансы важно понимать, чтобы разрабатывать отказоустойчивые системы, а не просто «писать код».

Алгоритмы. Наверное, всем известно, что в «Яндексе» на одном из этапов найма технические специалисты проходят интервью по алгоритмам. Поэтому я советую прокачивать навык решения алгоритмических задач. Честно скажу: это не мой конёк, есть люди, которые решают такие задачи на раз-два, а я перед собеседованием в «Яндекс» тщательно готовился — например, с помощью LeetCode. Плюс мне помог предыдущий опыт.

Архитектура. Мне очень понравилось, что на собеседовании давали абстрактную задачу — в моём понимании именно так выглядит правильное интервью на сеньорскую позицию.

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

Пример абстрактной задачи на архитектуру — спроектировать сервис, который будет выдавать промокоды. Это задача реального мира. Вот как стоит подходить к решению таких задач на собеседовании:

1. Проанализировать цель и попытаться определить подводные камни. Чтобы это понять, нужно задать уточняющие вопросы: например, определены ли метрики сервисов, какие будут нагрузки, кто будет пользоваться сервисом, есть ли SLO/SLI/SLA.

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

3. Оценить, сколько серверов понадобится, и рассказать, как именно вы эту оценку делаете. Можете ли вы представить, сколько у вас в запросе будет данных, какая будет нагрузка, понимаете ли вы, как работают кодировки и сколько символов помещается в тот или иной запрос.

4. Порассуждать вслух: спрогнозировать нагрузку и количество запросов, которые вы сможете обрабатывать в секунду, дать верную оценку можно только исходя из опыта.

5. Рассказать, как всё это задеплоить и заставить корректно работать. Многие кандидаты говорят, что надо арендовать сервер и развернуть Docker Compose. И им задают следующий вопрос: «А что делать, если завтра ляжет сервер или сам сервис?» Так интервьюер смотрит, умеет ли соискатель решать проблемы, был ли у него релевантный опыт. В зависимости от опыта, человек может предложить разместить сервис в Kubernetes, сделать геораспределение, геошардирование данных. Или использовать AnyCast, например, чтобы запросы на конкретный IP-адрес шли в ближайший дата-центр. Решений может быть много. Вопрос в том, знает ли кандидат о них.

Собеседование с командой. Это последний этап, на котором надо рассказать о себе, понять, насколько у вас получится найти общий язык с командой, есть ли совпадение по культуре. Скорее всего, вас спросят, какие задачи вы раньше решали и как они коррелируют с процессами в команде «Яндекса».