Кто такой SRE-инженер?
Задача современного SRE-инженера — сделать так, чтобы система была надежной, стабильной и производительной. Да, это похоже на задачи классического системного администратора, однако в случае с SRE цель достигается немного иными способами.
SRE-инженер, как и сисадмин, должен понимать устройство инфраструктуры, быть в курсе, какое ПО работает, знать, какую нагрузку выдерживают серверы, понимать, как надо работать с утилитами операционной системы.
На практике выделяют 4 ключевых направления, которые отличают SRE-инженера от классического системного администратора.
1. SRE-инженер — это, в первую очередь, программист
Да, это программист, но с навыками администрирования. При этом в отличие от большинства разработчиков ПО он пишет код не в целях реализации бизнес-логики, а в целях повышения стабильности и производительности системы. То есть написание кода не является основной задачей SRE-инженера — это всего лишь способ достижения основной цели.
Таким образом, умение программировать помогает SRE-специалисту самостоятельно находить ошибку в программе и исправлять ее. Он без проблем залезет в код, найдет причину и сразу устранит проблему.
Кроме того, SRE-инженер может разрабатывать утилиты, помогающие следить за системой. К примеру, у вас на проекте уже есть утилиты трассировки либо сбора логов, однако они чем-то не устраивают SRE-инженера, но для него это не проблема, ведь он может либо написать свои утилиты, либо доработать существующие.
2. SRE-инженер применяет модель «Инфраструктура как код» (IaC)
Такой специалист старается не менять ничего в системе вручную, то есть он пишет для всего скрипты и конфигурационные файлы. Зачем? Да хотя бы для того, чтобы снизить вероятность человеческой ошибки. Кроме того, данный подход даёт возможность легко воспроизводить настройки на прочих серверах и узнавать, как именно система настроена.
3. SRE-инженер принимает участие в проектировании архитектуры
SRE-инженер в курсе, какие серверы применяют в компании, какова их мощность, как они настроены, существуют ли технические ограничения. С такими знаниями он способен предвидеть потенциальную проблему, следовательно, может заранее сообщить о ней программистам.
А еще он может уже на старте разработки определить критерии для программистов, которым надо следовать. К примеру, для приложения следует обеспечить возможность записи логов в конкретное место или же надо интегрироваться с общей мониторинговой системой. И если данные требования не выполнены, SRE-инженер не примет приложение на поддержку.
4. SRE-инженер активно использует метрики
Оценка стабильности системы происходит не по ощущениям, а по фактическим параметрам. Существуют 2 главные метрики: 1. SLO — цели уровня обслуживания. Речь идет о соглашении о метриках и допустимых значениях, причем пороговые значения превышаться не должны. К примеру, наибольший даунтайм системы — не более 20 часов/год, среднее время ответа сервиса — не более 1 секунды. 2. SLI — индикаторы уровня обслуживания. Это уже сами метрики, измеряющие в течение какого-либо времени. К примеру, даунтайм системы в год — 18 часов, среднее время ответа сервиса — 0,8 секунды.
Как раз таки на основании этих метрик и происходит оценка стабильности и производительности приложений. А если что-либо выходит за рамки установленных параметров, SRE-инженер имеет право наложить вето на разработку нового функционала и попросить разработчиков сконцентрироваться на устранении проблем.
Практический пример
Допускается, чтобы сервис завершал работу с ошибкой 5 раз в месяц. Еще не так давно в месяц было 2-3 ошибки. Однако за последние 2 недели случились уже 3 ошибки, следовательно, если такая тенденция сохранится, лимит на 5 месячных ошибок будет превышен. Учитывая ситуацию, SRE-специалист может сказать разработчикам: «Ошибок стало больше. Пока стабильность не вернется на прежний уровень, мы не можем пускать в production ни одной новой функции».
По материалам https://mcs.mail.ru/blog/.
