Концепция DevOps триумфально шествует по планете. Впрочем, DevOps — это все-таки в большей степени философия, чем конкретная методология. В 2013 году компания Google представила практическую реализацию DevOps, получившую название «инжиниринг надежности сайтов» (Site Reliability Engineering, SRE). Этот подход позволяет устранить противоречие между стремлением разработчиков развивать и совершенствовать работающую программную систему и желанием тех, кто отвечает за ее эксплуатацию, минимизировать изменения, чтобы обеспечивать ее надежность и доступность с меньшими усилиями.

SRE-подход получил широкое применение среди международных гигантов ИТ-индустрии и продолжает активно развиваться. Однако в Восточной Европе и, в частности, России для многих эта концепция остается загадкой. Более того, специалистов в этой сфере довольно часто приравнивают к системным администраторам, экспертам по DevOps или разработчикам.

В чем состоят преимущества SRE, когда в командах разработки возникает потребность в SRE-инженерах, что они должны знать и уметь и за что они отвечают, рассказал Игорь Никифоров, ведущий DevOps-инженер крупной американской компании, обладатель более 20 различных ИТ-сертификаций, в том числе ITIL, CKA, CKAD, 5x AWS, RHSCA, LPIC-1, LPIC-2, HashiCorp x3 и других.

- В чем причина высокого интереса ИТ-индустрии к SRE? В чем состоит польза этого подхода, с точки зрения разработки, а в чем — для бизнеса?

Причина связана прежде всего с быстро растущим ИТ-рынком продуктовой разработки, в частности SaaS. Вслед за этим спросом и ростом нагрузок растут требования бизнеса к стабильной работе своих продуктов. Если раньше можно было тратить недели или месяцы на выпуск новой версии продукта, то сегодня долгий срок вывода на рынок (time to market) либо простой системы может обернуться огромной потерей прибыли или даже стать фактически приговором для компании. С точки зрения бизнеса SRE решает две основные проблемы: помогает наладить процессы в команде разработки и за счет этого увеличивает скорость выпуска новых функций, при этом основной акцент делается на стабильности и надежности работы систем.

С точки зрения разработки первоочередная задача SRE — устранить пробелы в коммуникациях с разработчиками. SRE-инженеры должны проводить значительную часть времени, работая вместе с ними, помогая разрабатывать архитектуру и оказывая поддержку в написании кода, который повысит надежность и производительность разрабатываемых систем. Кроме того, эти инженеры используют различные инструменты наблюдения (observability) для выявления проблем, возникающих в продуктивных системах, и берут на себя ведущую роль в реагировании на них. Все это позволяет сократить количество инцидентов в продуктивных системах, оптимизировать ПО еще на ранних этапах процесса разработки, а также обеспечить высокую прозрачность в отношении надежности системы.

- Как и почему компании приходят к использованию подхода SRE?

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

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

Когда команда разработчиков увеличивается до 30-50 человек, вполне естественным образом возникает потребность в переходе на DevOps и в разделении ролей и функций между специалистами, поскольку участники относительно большой команды уже не могут быть универсалами и вынуждены концентрироваться на чем-то одном. Разработчикам в таких командах приходится тесно взаимодействовать друг с другом, чтобы общими усилиями получить нужный результат. Тогда-то и появляется необходимость в SRE-инженере — человеке, который обеспечит автоматизацию всей инфраструктуры приложений, их надежности и доступности.

- В чем заключается роль SRE-инженера? В чем состоят его принципиальные отличия от разработчика?

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

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

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

- На чем особенно важно сосредоточиться SRE-инженеру в процессах разработки?

Я думаю, самая важная для него вещь — это наблюдаемость (observability), то есть сбор данных системных журналов (логов), традиционный мониторинг и распределенный трейсинг (distributed tracing). Например, пользователь продукта, имеющего микросервисную архитектуру, зайдя на одно приложение, может сгенерировать запрос на несколько взаимосвязанных сервисов. И здесь уже недостаточно просто собрать с них данные журналов или показатели метрик. Скорее всего, вы захотите измерить задержку между такими сервисами или понять, какие именно функции влияют на пользователя. Неудивительно, что с развитием микросервисной архитектуры индустрия понемногу начала разрабатывать стандарты в этой области. Так, в частности, появился стандарт OpenTelemetry.

Кстати, именно SRE-инженер может еще на старте разработки определить критерии, которые нужно выполнить, чтобы принять приложение на поддержку. Например, приложение должно передавать согласованный набор метрик (в том числе с использованием фреймворка Prometheus) и добавлять записи в системные журналы в определенном формате, чтобы обеспечить интеграцию с имеющимися системами мониторинга и сбора данных журналов.

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

Все верно, сплит-тестирование, «сине-зеленое» развертывание (в двух продуктивных средах одновременно с возможностью разделения трафика или его переключения между ними. — Прим. ред.) и «канареечное» тестирование (с переводом нового выпуска ПО в продуктивную эксплуатацию по частям. — Прим. ред.) как раз связаны с этим. Представим, что у вас много клиентов и вы хотите встроить в приложение какую-то новую функцию, но боитесь, что внесение соответствующих изменений в ПО может что-то нарушить. В этом случае можно воспользоваться «сине-зеленым» развертыванием, при котором новый функционал получит только малая часть пользователей. Благодаря наблюдаемости вы затем поймете, как изменения повлияли на работу пользователей. Если у вас нет этого представления, «сине-зеленое» развертывание просто не поможет.

- Можно ли утверждать, что метрики для SRE-инженера — это главные инструменты для оценки стабильности и доступности системы?

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

Первая из них — это показатели уровня обслуживания (Service Level Indicator, SLI): количество запросов в секунду (RPS), задержки запросов по времени, количество ошибок за определенный период и другие временные метрики. Обычно все они агрегируются и преобразуются в среднее значение или процент по отношению к максимально допустимому значению.

Вторая важная метрика — цели уровня обслуживания (Service Level Objective, SLO). По сути, это соглашение о допустимых показателях SLI в течение определенного периода времени. Например, простой системы не должен продолжаться более 30 минут в месяц или количество ошибок на запрос к сервису не должно превышать 10 в день.

Также стоит отметить еще одну метрику — соглашение об уровне обслуживания (Service Level Agreement, SLA). Оно заключается между провайдером услуг и клиентом и фиксирует показатели доступности сервисов, времени реагирования на инциденты и последствий простоев. Термин SLA пришел из методологии ITIL, где описываются способы организации работы ИТ-команд. Обычно SLA предлагают меньшую доступность, чем SLO, так как вы предпочтете сначала «сломать» свой внутренний SLO, а не SLA.

- В примерах вы упомянули микросервисную архитектуру. Когда компании стоит всерьез задуматься о ее внедрении, например, на базе контейнеров Kubernetes?

Это сложный вопрос, который порождает много жарких споров в ИТ-индустрии. Думаю, компании только начинают приходить к пониманию того, насколько Kubernetes способен упростить все процессы, связанные с жизненным циклом приложений, особенно когда речь идет о сотне или тысяче различных сервисов.

Дело в том, что одного лишь развертывания Kubernetes недостаточно. Сами приложения должны хорошо работать в контейнеризованной среде, то есть быть нативными облачными (cloud native) приложениями.

Также нужно понимать, что Kubernetes по своей сути — это конструктор, и, чтобы собрать на его основе полноценное решение, которое будет охватывать все базовые инфраструктурные аспекты (управление сертификатами, DNS, мониторинг, ведение системных журналов и пр.), потребуется еще с десяток дополнительных сервисов. А это дополнительные расходы, увеличивающие совокупную стоимость владения (Total Cost Ownership, TCO) приложением.

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

Очевидно, что развертывать Kubernetes не имеет смысла, если нет выделенного специалиста, который постоянно будет им заниматься. Правда, если ваша инфраструктура находится в публичном облаке, то там наверняка уже есть услуги типа «Kubernetes как сервис». Они помогают немного снизить порог начальных инвестиций, но для того, чтобы Kubernetes жил сам по себе, все равно потребуются дополнительные расходы, которые могут оказаться весьма ощутимыми для небольших или средних компаний. Поэтому, рассматривая вопрос о переходе на Kubernetes, следует заранее оценить, будет ли это решение прибыльным для вашей компании. Не очень крупным предприятиям, как правило, разумнее ограничиться виртуальными машинами и Ansible — этого им вполне хватит.