Зачем вам FrontOps

Привет, VC! Меня зовут Максим Смирнов, я работаю в Тинькофф, руковожу архитекторами в одном из управлений. За время работы видел много метаморфоз разработчиков — как они уходили в Backend, DevOps, FrontOps. Сам тоже перемещался между бэкендом, SRE и фронтендом, но, всё-таки, остался во фронтендере. Я выступил с докладом о роли FrontOps на конференции FrontendConf. В этой статье по мотивам доклада расскажу, кто это такие, как прийти к роли FrontOps и разобраться, а нужно ли вам это. Поехали!

У меня в команде 13 фронтенд-разработчиков, распределенные на 5 бизнес-юнитов, ещё два человека выступают надзорным органом над ними и три человека выделены в юнит FrontOps. Расскажу, зачем они нужны, как появилась эта специализация, и почему их задачи не могут выполнять DevOps- и SRE-инжерены.

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

В период появления ЭВМ разработчики должны были понимать, как работает система, суметь написать код на перфокарте и исполнить его. В какой-то момент они разделились на разработчиков и сисадминов. Разработчики тогда писали одновременно front и back — все были full-stack'ами.

Технологии развивались и постепенно разработчики разделились на бэкенд и фронтенд. Сисадмины отделились в поддержку пользователей. Часть бекендеров ушли в DevOps и занялась поддержкой инфраструктуры. DevOps как отдельное направление понадобился для обслуживания бэкендеров с их громоздкими Java и .NET, которые нужно разворачивать на серверах. А фронтенд так и оставался в виде трёх файликов: HTML, JS, CSS, которые нужно было просто развернуть на любом веб-сервере.

Затем DevOps снова разделился, появилось понятие DevSecOps, — поддержка инфраструктуры с упором на информационную безопасность. А потом появились FrontOps — туда переметнулись некоторые фронтендеры.

FrontOps появился из потребности — ведь набор инструментов, поддерживающий фронтенд, серьёзно разросся. Есть множество фреймворков и CLI, но мы часто используем их вслепую, как чёрный ящик, хотя они и завязаны на инфраструктуру. С увеличением количества утилит появляются сложные цепочки доставки на прод. Фронтендерам стало нужно в этом разбираться: GitLab, пайплайны, джобы, сборка кода, деплой. Появлялось всё больше соприкосновений с инфраструктурой. А DevOps-инженеры всё ещё не хотели с этим иметь дела, ведь, чтобы понимать туллинг фронтенда, нужно (сюрприз!) разбираться во фронтенде.

Фронтендеры тоже часто не хотят развиваться в чём-то, кроме фронтенда: как бэкенд общается с базой данных, принимает синхронные задачи через Kafka и так далее. Но когда появились отдельные BFF и SSR сервисы, понадобилось узнать, как пишутся node.js бэкэнды и понимать их устройство. То есть нам стало необходимо понимать, как работает серверный JS.

И вот тогда появилось отдельное направление FrontOps, в котором соединились перенятые DevOps-практики, понимание бэкэнда и фронта.

Меняется webpack и мало кто изучает документацию по нему, хотя на Nginx разворачивается 90% Web. При этом, мало кто знает, что изменилось в версии 1.23 и в 1.27, несмотря на то, что там появились Include, с помощью которых можно строить базовые образы. Мы во фронтенде постоянно этим пользуемся, но не хотим об этом читать.

И вот тогда логичным образом появились специалисты, знающие специфику фронтенда, как он работает, какой ему нужен тулинг, и почему node-modules всё ещё весят 12 гигабайт. Они умеют в инфраструктуру, понимают различие между Ubuntu-сервером и Alpine. Пишут Docker-файлы и даже знают, как ими пользоваться. Знают, сколько ядер CPU и мегабайт памяти нужно в Kubernetes, чтобы развернуть приложение. Понимают бэкенд — не в классическом режиме, а серверный JS и умеют заставить Angular Universal не ломаться. И первыми такими специалистами были лиды, которые всё это использовали ещё до появления термина FrontOps.

В моей команде каждый разработчик из 13 человек 50% своего рабочего времени мог потратить на бизнес-задачу, 25% — на поддержку по обращениям клиентов и примерно 10% на инфраструктуру. Плюс остаток времени на тесты и техдолг.

Из-за задач по инфраструктуре и поддержке бизнес-задачи часто блокировались. Чтобы настроить новые правила для страницы, нужно было идти к DevOps и заполнять форму в 50 пунктов, а если вдруг что-то заполнили неверно, начинался весьма длительный процесс коммуникации, а задача оказывалась на стопе.

Прибавим к этому регулярные сбои на фронтенде, которые съедали где-то 50% ресурса. В результате разработчики выгорали и не хотели делать бизнес-задачи, а погружались в инфраструктурные вопросы, чтобы «разгрузить DevOps». Тогда мы решили выделить часть команды, снять с неё бизнес-задачи и отправить их на поддержку, устренение сбоев и работу с инфраструктурой.

С тех пор у нас в команде есть отдельные люди — FrontOps — они занимаются поддержкой фронта, развитием технологий, оптимизацией сервисов. Теперь фронтендеры — занимаются фронтом. А сбои перестали глобально влиять на команду бизнеса. FrontOps же решают задачи базовых пайплайнов, зависимостей, конфигураций внешних сервисов и поднятий новых. Они готовят плацдарм: завести сервисы, балансировщики, репозитории.

Также FrontOps занимается поддержкой пользователей и SRE. Дежурим теперь на два фронта: охватываем и проблемы пользователей (у меня красная консоль, а у меня белый экран) и глобальные сбои (после релиза что-то случилось — разбираемся, вникаем).

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

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

Но самое главное, что FrontOps развивает команду через технологии. Любой запрос, который приходит к FrontOps от фронтендеров — это не только решение проблемы, но и объяснение, как в будущем решать вопрос самостоятельно.

В моем случае FrontOps улучшили статистику по time to market и выводу задач в прод. Даст ли вам это аналогичные результаты — я не знаю, нужно пробовать. Если вы задумались как прийти к FrontOps и стать специалистом в этой сфере, то у меня есть несколько советов:

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

Отбрасывайте то, что не получилось, без сожалений. Код, который вы пишете, когда-то станет legacy. Не бойтесь этого признавать, любой код всегда становится legacy. Если сделали что-то, и оно не «взлетело» — выбросите и начните заново.

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

Старайтесь для команды, а не для себя. Ведь если удобно команде, удобно вам.

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

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

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

Желаю вам удачи в построении FrontOps юнита в вашей команде или становлении этим редким и важным специалистом! Больше докладов о FrontOps можно послушать на конференции FrontendConf.