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