Не ставим заплатки и не строим типовые дома: рассказываем о работе DevOps-инженеров и SRE в Yandex Cloud
Как правильно называть специалистов, которые отвечают за эксплуатацию систем? Чем различаются задачи SRE, DevOps-инженеров и сисадминов? Кому из них нужно уметь программировать и знать алгоритмы? Поговорили об этом с руководителями команд в Yandex Cloud.
Разберёмся в терминологии
Начнём с системных администраторов. Эта роль раньше включала всё: от ремонта принтера и установки программ до поддержки серверов и правок в тексты на сайте. В результате под этим словом привыкли подразумевать сотрудников с самыми разными обязанностями. Так, системным администратором обычно называют специалиста, который настраивает инфраструктуру, мониторинг и сети, следит за работой операционных систем, устанавливает ПО. Он чинит всё руками и ориентирован на решение текущей проблемы.
В Яндексе классическая роль системного администратора трансформировалась в DevOps-инженера и SRE. Они думают про долгосрочные решения, влияют на развитие продукта и отвечают за работоспособность, надёжность и производительность систем. А выбор инструментов неограничен.
Десять лет назад, когда я работал администратором баз данных, я занимался только администрированием. За операционные системы отвечали сисадмины, за хранилище данных — другие сотрудники. Мы передавали друг другу «палочку» — в итоге на решение проблемы мог уйти месяц. Сейчас SRE разбирается с вопросом за час-два.
В России граница между DevOps-инженером и SRE размыта. Отсутствие строгого разделения видно даже по вакансиям: на hh.ru SRE и DevOps-инженер часто указаны через слеш.
Распространённые определения звучат так:
- DevOps-инженер — тот, кто отвечает за автоматизацию сборки, настройки и развёртывания ПО.
- SRE — тот, кто полностью обеспечивает работу сервиса.
В Яндексе DevOps-инженеры и SRE — это специалисты, которые отвечают за эксплуатацию систем и работу всего сервиса. И для этого они должны уметь самостоятельно решать большой круг задач. Любой инженер в Yandex Cloud занимается и релизами, и мониторингом, и тестированием, и архитектурой. А ещё дежурит и пишет свой код — если надо что-то доработать или починить.
SRE и DevOps-инженеры должны одинаково хорошо разбираться и в операционных вопросах, и в разработке. В этом их отличие от классических системных администраторов.
Руководитель группы Deployment Infrastructure
«Ops» — operations — сродни работе сисадмина, когда нужно адаптировать готовые решения и эксплуатировать код. «Dev» — development — это уже про разработку, и здесь потребуется гораздо большее погружение в код, чем у системного администратора.
Какие задачи решают DevOps-инженеры и SRE и зачем им код
Инженеры заботятся о максимальной производительности сервисов и быстрой доставке кода в прод, а также о стабильности и надёжности продакшна. Для всего этого важен эффективный код, а для эффективного кода — знание алгоритмов.
Мы стараемся автоматизировать как можно больше процессов. Поэтому DevOps-инженеры и SRE в Яндексе не просто «ставят заплатки», а сразу разрабатывают решения, которые будут помогать и дальше, а также легко масштабироваться и справляться с повышением нагрузки.
В ходе релизного цикла нам нужно было автоматически собирать информацию о том, какие версии микросервисов залиты в продакшн. Можно было сделать «костыли» на Bash, но мы написали отдельный инструмент, который показывает версию любого сервиса.
Мы запускаем сервисы на большом количестве машин, так что даже небольшая оптимизация экономит много ресурсов и времени. И конечно, скиллы в написании понятного кода нужны, чтобы коллегам было легко его читать и поддерживать. Такой код хорошо параллелится, масштабируется и запускается на любом количестве инстансов.
Конкретные задачи инженеров зависят от сервиса. Например, в MDB (Managed Databases) практически весь код пишут DevOps-инженеры и SRE. Сервис занимается оптимизацией операций, связанных с базами данных, например, обновлением версий. Обычно это сложная операция, требующая много ручных действий, но в MDB всё делается по кнопке, без участия человека.
В MDB необходима большая экспертиза в области баз данных. Мы все разбираемся и в разработке, и в эксплуатации. Обычный бэкенд-разработчик редко знает тонкости работы и внутреннее устройство баз данных — это компетенции SRE.
Строгого разделения между задачами DevOps-инженера и SRE в сервисе MDB нет. Ребята работают спринтами и берут задачи каждые две недели: часть из них требует применения DevOps-методологии, а часть — компетенций SRE.
SRE — это хозяин системы. Он задаёт правила её использования и знает, как сделать так, чтобы система была высокодоступной и отказоустойчивой. Например, он может решить задачу внедрения трассировки (tracing) в существующие системы и приложения компании.
Зачем изобретать велосипед
На собеседовании инженеры часто спрашивают, почему нам недостаточно готовых библиотек и опенсорсных инструментов. Для многих задач, которые мы решаем, не подходят готовые решения: у нас другие объёмы данных и нагрузки.
Бывает и так, что на рынке ещё нет инструмента, который нам нужен. Мы часто сталкивались с этим при разработке MDB. Сейчас решений становится больше, но они до сих пор плохо встроены в облачную инфраструктуру. Поэтому ребята из MDB разрабатывают много внутренних инструментов, например, PGSync — программу, которая обеспечивает высокую доступность кластера PostgreSQL. Потом некоторые из этих решений становятся опенсорсными.
Можно строить маленькие типовые дома, а можно — самые высокие в мире небоскрёбы. Делать то, чего ещё никто не делал. А для этого нужны технологии, которые ещё никто не изобрёл.
Так появился и ClickHouse. К 2008 году в Яндекс Метрике стало собираться огромное количество данных. Баз данных в целом не так уж много, а тех, которые могут работать с нашими объёмами информации с нужной скоростью, единицы. Они, как правило, принадлежат крупным компаниям, которые не хотят делиться своими разработками. Поэтому изначально мы создали эту СУБД для задач Яндекс Метрики. Потом стало ясно, что она пригодится и в других наших сервисах, а потом — что на неё будет спрос и за пределами Яндекса. Так ClickHouse превратился в опенсорсный инструмент.
Три года назад команда Yandex Cloud разработала собственную версию PSSH. Нужен был инструмент на Golang, который умеет работать с нашими Bastion-серверами, поддерживать YubiKey и внутренние инструменты выписывания сессионных сертификатов. А ещё использовать наши Service Discovery-инструменты в качестве источника списка хостов и агрегировать результаты выполнения в JSON. Опенсорсные аналоги этого не умеют.
Наши инженеры пишут свой инструментарий и адаптируют сторонние решения, потому что в Яндексе другие объёмы данных и железа. То, что удобно использовать в небольшой компании, у нас работает совсем по-другому. Если вы запускаете неоптимизированный код на десяти машинах и он выполняется минуту вместо нескольких секунд — это не страшно. А если на пяти тысячах машин — возникают проблемы.
Таким образом, сисадмин занимается поддержкой инфраструктуры, не погружаясь в логику работы приложений. А разницу между DevOps‐инженером и SRE на рынке понимают по‐разному. В Yandex Cloud важно, чтобы инженер мог создавать быстрые и удобные сервисы, которые способны масштабироваться под задачи любого проекта.
Подписывайтесь на блог Yandex Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.
Другие истории наших партнеров и клиентов, которые активно читают наши подписчики:
Devops это тема
Вы большие молодцы, и у вас классный продукт! Я хотел к вам попасть когда-то, но к сожалению не прошёл.
Возможно стоит попробовать снова :)
Наша карьерная страница: https://yandex.ru/jobs/services/cloud/about