Все чаще компании ищут SRE-инженеров, и требования к ним похожи на те, что предъявляют системным администраторам: сопровождение систем, администрирование инфраструктуры, знание инструментов ОС. Что это — просто модное переименование одной профессии в другую или отличия есть на самом деле?

Расскажем, чем занимается SRE-инженер, что он должен уметь, чем отличается от системного администратора и что меняется в компании, когда в нее приходит такой специалист.

Статья написана на основе доклада Павла Селиванова, ведущего DevOps-инженера в Mail.ru Cloud Solutions.

Кто такой системный администратор, что он делает и за что отвечает

Если смотреть глобально, то этот специалист следит за инфраструктурой, чтобы она работала стабильно и быстро. Если конкретнее, то системный администратор:

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

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

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

И тут могут возникать проблемы. Иногда при разработке и тестировании программа работает правильно, а когда ее устанавливают на продуктивные серверы, появляются ошибки.

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

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

Кто такой SRE-инженер и чем он отличается от системного администратора

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

Можно выделить 4 ключевых направления, отличающих SRE-инженера от системного администратора.

  1. SRE-инженер — в первую очередь программист

    SRE-инженер — это программист с навыками администрирования. Однако он пишет код не для реализации бизнес-логики, а для повышения стабильности и производительности системы. Написание кода не основная задача SRE-инженера, а один из способов достижения целей.

    Навыки программирования помогают SRE-инженеру самому найти ошибку в программе, запущенной в продуктивной среде, и исправить ее. Он может сам залезть в код, найти причину и тут же написать исправление.

    Также SRE-инженер пишет утилиты, которые помогают следить за системой. Например, если существующие утилиты трассировки или сбора логов его чем-то не устраивают, он может написать свои или доработать существующие.

  2. SRE-инженер использует модель «Инфраструктура как код» (IaC)

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

  3. SRE-инженер участвует в проектировании архитектуры

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

    Также SRE-инженер может еще на старте разработки определить критерии, которые должны выполнить программисты. Например, приложение должно писать логи в определенное место или интегрироваться с общей системой мониторинга. Без выполнения этих требований SRE-инженер может не принять приложение на поддержку.

  4. SRE-инженер окружает систему метриками

    Он оценивает стабильность системы не по своим ощущениям, а по конкретным показателям. Есть две основные метрики, которые используют внутри команд:

    1. SLO — цели уровня обслуживания. Это соглашение о метриках и их допустимых значениях: пороговые значения не должны превышаться. Например, максимальный даунтайм системы должен быть не более 20 часов в год, среднее время ответа сервиса должно быть не более одной секунды.
    2. SLI — индикаторы уровня обслуживания. Это сами метрики, которые измеряют в течение какого-то времени. Например, даунтайм системы за год составляет 18 часов, а среднее время ответа сервиса составляет 0,8 секунды.

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

Например, допустимо, чтобы сервис завершался с ошибкой пять раз в месяц. До недавнего времени в среднем в месяц было две-три ошибки. Но за последние две недели было уже три ошибки, и если так пойдет дальше, то лимит на пять ошибок в месяц будет превышен. Поэтому SRE-инженер может сказать разработчикам: «У нас стало больше ошибок. Пока мы не вернем стабильность на прежний уровень, я не могу пропустить в продуктивную систему ни одной новой функции».

Традиционные администраторы уходят в прошлое, а на замену приходят SRE-инженеры?

Возможно, что да. Это не дань моде, а естественное развитие технологий и процессов разработки:

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

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

Кто нужен компании: системный администратор или SRE-инженер

Подведем итоги и попробуем понять, кто же нужен компании: системный администратор или SRE-инженер.

  • Системный администратор — это специалист, который следит за стабильностью системы, досконально ее знает и может решить проблему инфраструктуры, но не кода.
  • SRE-инженер — это программист с навыками администрирования. Его основная цель — чтобы система работала стабильно, для этого он дорабатывает код разработчиков и может создавать собственные утилиты.
Существует еще одна метрика — SLA. Но она применяется для внешних клиентов, и мы рассказали о ней в отдельной статье.
Примечание!

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

Системный администраторSRE-инженер
Не проверяет и не исправляет проблемный код.Может проверить и исправить проблемный код, делает это постоянно.
Пользуется готовыми инструментами для мониторинга, сбора логов и другой статистики.Может написать собственные утилиты или доработать существующие.
Настраивает систему через графический интерфейс или вручную редактирует конфигурационные файлы.Все настройки в системе делает по модели «Инфраструктура как код (IaC)».
Не участвует в обсуждении архитектуры приложений и не может выставлять свои требования.Участвует в обсуждении архитектуры, может сразу предостеречь разработчиков от неоптимального решения. Может выставлять требования по оптимизации и мониторингу.
Не может запретить разработчикам выпустить обновление, даже если система работает нестабильно.Может не пропускать новую функциональность в продуктивную систему до тех пор, пока разработчики не исправят проблемы стабильности.

SRE-инженер нужен, когда в компании часто выпускают обновления кода, команде администраторов и программистов сложно исправлять общие проблемы.

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