Игорь Никифоров о концепции Site Reliability Engineering. SRE-подход — модное веяние или действующий инструмент для развития продуктовых IT-компаний?
С развитием IT всё большему числу компаний становится очевидно, что модель, в которой разработкой и эксплуатацией занимаются разные люди, теряет свою актуальность и не приводит к желаемым результатам. В связи с этим появилась необходимость создания нового подхода, позволяющего разрешить эти противоречия, сократить жизненный цикл разработки систем и сделать опору на автоматизацию. Решением стала философия DevOps и одна из форм её реализации — Site Reliability Engineering (SRE).
Представленный Google в 2013 году, SRE-подход получил широкое применение среди международных гигантов рынка IT и продолжает активно развиваться. Однако в Восточной Европе и, в частности, России для многих эта концепция остаётся загадкой, а специалистов в этой сфере довольно часто приравнивают к системным администраторам, девопсам или разработчикам.
Мы решили разобраться в вопросе и поговорили об особенностях этой профессии с Игорем Никифоровым — ведущим DevOps инженером в крупной американской компании и обладателем десятка различных сертификаций, таких как ITIL, CKA, CKAD, 5x AWS, RHSCA и многих других. В интервью он рассказал, какими компетенциями важно обладать на этой позиции, её основных особенностях и старте в карьере в профессии. Также Игорь Никифоров не обошёл стороной и техническую часть темы и обсудил с нами культуру разработки, DevOps, Kubernetes и другие актуальные вопросы.
Чем отличается SRE-инженер от разработчика?
Основная задача SRE-специалиста — обеспечить стабильную и предсказуемую работу системы и создать надёжный продукт для конечного пользователя. По сути он совмещает в себе компетенции DevOps, системного администратора и разработчика. Требования к таким кандидатам очень высоки.
Есть принципиальное различие в задачах и области экспертизы этих специалистов. SRE-инженер должен хорошо понимать все аспекты работы операционных систем, протоколов и сетей, достаточно глубоко знать особенности построения распределенных систем, управлять надежностью и рисками.
Также у них больше практического опыта эксплуатации абстрактной системы в продуктивной среде. Разработка системы контроля надежности, например, балансировки нагрузки, мониторинг, резервное копирование и, особенно, восстановление, планирование роста, консультации разработчиков на этапе проектирования — задачи, с которыми в основном работают SRE.
Разработчики же напротив сосредоточены на предметной области, связанной непосредственно с продуктом. Но стоит заметить, что после некоторого погружения в инструменты, используемыми SRE, они также способны решать свойственные этой концепции задачи.
Расскажите, как обычно компании приходят к SRE-подходу?
В каждой компании возникает момент, когда поддержание работоспособности и доступности становится чьей-то постоянной работой. Например, часто в небольших стартапах разработчики совмещают должность с обязанностями системных администраторов. Но по мере роста организации наступает момент, когда специалист не может быть универсалом и фокусироваться на чём-то одном, и появляется необходимость в человеке, который обеспечит автоматизацию всей инфраструктуры, надежности и доступности.
Вы успели поработать и в больших компаниях, и в стартапах. Можете рассказать, чем отличается культура разработки и взаимодействие между командами?
В действительно маленьких компаниях все делают всё. Когда вы начинаете работать в организации из 30–50 человек, DevOps возникает почти естественным образом. Разработчикам приходится взаимодействовать друг с другом, потому что нет исторических знаний, особенно в стартапе, когда всё делается в первый раз.
Также нужно понимать, что новички на рынке прежде всего сосредоточены на разработке, ориентированной на прибыль и привлечение новых пользователей. Им важно показать, что они достойны финансирования. Как правило, стартапы не могут позволить себе SRE-инженера, так как у них недостаточно пользователей, чтобы волноваться о надежности и доступности продукта.
Как вы думаете, на чём особенно важно сосредоточиться на этапах разработки?
Я думаю, самая важная вещь — это observability, т.е. сбор логов, традиционный мониторинг и трейсинг. Например, если мы говорим о микросервисной архитектуре продукта, то при заходе на одно приложение, пользователь может сделать запрос на несколько взаимосвязанных сервисов. И здесь уже недостаточно просто собрать логи или метрики с этих приложений. Скорее всего вы захотите измерить задержку между этими сервисами или понять, какие именно функции влияют на пользователя. Поэтому с развитием микросервисной архитектуры индустрия понемногу начала разрабатывать стандарты в этом направлении, в том числе OpenTelemetry.
Именно SRE-инженер может ещё на старте разработки определить критерии, которые нужно выполнить, чтобы принять приложение на поддержку. Например, приложение должно отдавать согласованный набор метрик (в т.ч. Prometheus) и писать логи в определенном формате для интеграции с существующими системами мониторинга и сбора логов.
Т.е. observability можно рассматривать как обратную связь, чтобы быстро получать информацию о происходящем с вашей системой?
Всё верно, A/B тестирование, green-blue развертывание и канареечное тестирование как раз с этим связано. Например, представим, что у вас много клиентов и вы хотите выпустить какую-то новую функцию в приложении, но боитесь, что эти изменения могут что-то нарушить. В этом случае можно воспользоваться green-blue развертыванием, при котором только малая часть пользователей получит новый функционал. Затем вы с помощью observability поймёте, как изменения повлияли на пользователей. Если у вас нет этого представления, то green-blue развертывание просто не поможет.
Можно ли сказать, что метрики для SRE — это главные инструменты для оценки стабильности и доступности системы?
Да, SRE должен всегда гарантировать общее согласие с тем, как измеряется доступность конкретной системы и что необходимо сделать, если определяющие её пороговые метрики превышены. Команды эксплуатации постоянно решают проблемы доступности, часть которых заканчивается ошибками в коде разработчика. Однако без чёткого измерения времени безотказной работы и определения приоритетов доступности, разработчики могут не согласиться с тем, что надежность — это проблема. Именно поэтому SRE работает с заинтересованными сторонами для принятия решений по двум основным метрикам, которые используют внутри команд:
-
Показатели уровня обслуживания (SLI) — различные временные метрики, например, количество запросов в секунду (RPS), задержки запросов по времени или количество ошибок. Обычно все они агрегируются по времени и преобразуются в среднее значение или процент по отношению к максимально допустимому значению.
-
Цели уровня обслуживания (SLO) — это соглашение о допустимых показателях SLI в течении определенного периода времени. Например, простой системы не более 30 минут в месяц или максимальное количество ошибок на запрос к сервису в день не более 10.
Также стоит отметить еще одну метрику — соглашение об уровне услуг (SLA). По сути, это соглашение между провайдером услуг и клиентом о доступности сервисов, времени реагирования на инциденты и последствиях простоя. Сам термин SLA пришел из методологии ITIL, где описываются способы организации работы IT-компаний. Обычно SLA предлагают меньшую доступность чем SLO, т.к. сначала вы предпочтете сломать свой внутренний SLO, чем SLA.
Говоря о популярности DevOps в целом, нельзя не упомянуть про Kubernetes. Можете ли вы сказать, когда компании стоит по-настоящему задуматься о его внедрении?
Это сложный вопрос, который порождает много жарких обсуждений в индустрии. Я думаю, в enterprise только начинают приходить к пониманию, насколько он может упростить все процессы, связанные с жизненным циклом приложений, особенно когда речь идёт о сотне или тысяче различных сервисов.
Недостаточно просто иметь Kubernetes, приложения должны хорошо работать в контейнеризованной среде, то что сейчас называют cloud-native. Нужно понимать, что если у вас 10 микросервисов, то Kubernetes добавит ещё несколько десятков.
Я бы сказал, что весь ажиотаж, связанный с ним, более или менее прошел, и маленькие компании постепенно осознают, что бремя поддержки кластера не стоит таких затрат.
Отсюда можно задать еще один вопрос, когда компаниям нанимать SRE/DevOps-инженера?
Очевидно, что Kubernetes не имеет смысла, если нет выделенного человека, который постоянно им занимается. Правда, если ваша инфраструктура находится в каком-либо из облачных провайдеров, то там наверняка уже есть услуги, связанные с KaaS (ред. Kubernetes as a Service). Это может немного понизить порог входа для небольших или средних компаний, но он всё равно недостаточен для того, чтобы Kubernetes жил сам по себе.
Kubernetes по своей сути — это конструктор, и чтобы собрать полноценное решение, которое будет покрывать все базовые инфраструктурные аспекты, такие как управление сертификатами, DNS, мониторинг и логирование, потребуется дополнительно поставить еще с десяток сервисов.
Также Игорь Никифоров отмечает, что в большинстве случаев иметь такой управляемый кластер в облаке довольно дорого, особенно если речь идет о небольшой компании. Он советует учитывать этот момент в вопросах составления бюджета и заранее рассчитывать, будет ли это решение прибыльным, или достаточно виртуальных машин и Ansible для покрытия всех потребностей.
Полный текст статьи читайте на PCNEWS
