Sre devops что это

SRE-инженер. Что нужно знать и уметь?

Экспириенс, задачи, нагрузка

Ingredients

Directions

SRE на пальцах

SRE ( Site Reliability Engineering ) — набор методов, показателей и предписывающих способов обеспечения надежности систем. Слово «site» в данном контексте читается как «система» или «платформа», а не веб-сайт в привычном нам представлении. SRE — обеспечение надежности всех уровней системы: от физических до логических, это значит, что SRE — это своеобразный конгломерат из разработчика (да, SRE должны уметь в код) и системного администратора со всеми вытекающими.

Именно SRE-инженер стоит в первых рядах, когда речь идёт об обеспечении аптайма highload-сервисов, стабилизации системы после краша и вносят соответствующие поправки в код. Поэтому они часто именуются как Software-инженеры (в совковых конторах это звучало бы как инженер-программист) или инженерами по надежности обслуживания

Вообще, SRE — это своеобразное ответвление, а точнее — своя реализация направления DevOps от Google. Идейным вдохновителем стал Бен Трейнор — текущий вице-президент Google по вопросам облачной обработки данных (где-то упоминается, как вице-президент по технологиям). Так же Google издала уже три книги, где описывает нюансы направления SRE, его практики и применение в недрах компании (Site Reliability Engineering: How Google Runs Production Systems — первая из них)

Зачем нужно это направление?

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

— «Парень, который пилит фиксы и лезет в лоад балансер. А убрать, кто ты без него?»

— «Девелопер, сисадмин, интегратор, инженер»

DevOps vs SRE

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

Скиллы и задачи SRE-инженера

Прокачаться до уровня Senior, т.е. на все 146% будет трудно. Мы уже писали, что профессия не из легких, к тому же сочетает в себе два весьма трудоёмких направления — эксплуатации и разработки.

Девелопмент

Да, SRE-инженер должен уметь писать код на одном из языков программирования, которые используются в стеке компании. Это может быть как C#, так и гугловский Golang, т.е. для позиции SRE нормальной практикой считается не просто написание скриптов (опять же может быть и питон, а может и bash), но и погружение в процессы разработки и постоянное взаимодействие с командой. Опционально может быть: составление брифов (техническое задание), участие в спринтах и копание в бэклоге

Разработка платформы на базе Kubernetes — тоже одна из частых задач в SRE. Kubernetes — это целая экосистема из сервисов и утилит для развёртывания, автоматизации и настройки контейнеризированных приложений и микросервисов (использующие облачные вычисления). Kubernetes дает вам фреймворк для гибкой работы распределенных систем. Он занимается масштабированием и обработкой ошибок в приложении, предоставляет шаблоны развертывания и многое другое. Kubernetes отлично балансирует нагрузку трафика между контейнерами, быстро развернуть или откатить любое количество контейнеров и работает с защищенными протоколами для защиты персональных данных

Так же предстоит работа с билдами в Drone CI. Пул-реквест ты будешь делать чаще, чем оставаться наедине со своей девушкой. Причем не понятно, где интимной близости будет больше. Билд проходит через стандартный конвейер задач и тебе, скорее всего, придётся составлять его пайплайн. Drone — система непрерывной интеграции, основанная на docker-контейнерах, которая отлично работает как с гитхабом, так и с менее известными репозиториями. Каждый шаг из пайплайна обрабатывается в отдельном docker-контейнере и запускаются с помощью drone agent. Drone server, в свою очередь, играет роль координатора

Системное администрирование & автоматизация

Траблшутинг & Инцидент менеджмент

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

Kibana — специальный дашборд для построения графиков и диаграмм этих самых логов. Как правило, используется в стеке, т.н. ELK — Elasticsearch + Logstash + Kibana

Работа с базами данных & облачной инфраструктурой

Основа основ в SRE. Все мало-мальски топовые компании переводят свою инфраструктуру в облако — это не дань моде, а вполне закономерный тренд. Поэтому приготовьтесь к миграции базы данных из MySQL в Azure или AWS, настройке бэкапов, оптимизации запросов, написанию тулз, выставление лимитов, обкатывание баз на стенде, тестированию и развертывание всего этого дела в продуктивной среде.

Плюсом будет умение работы с Microsoft Azure на уровне разработчика : разбираться в Azure Data Explorer (служба для анализа большого объема потоковых данных в реальном из приложений и/или сервис в real-time), работать и автоматизировать систему управления идентификацией и доступом (AIM), использовать Azure REST API (доступ к ресурсам службы через протокол HTTP), управлять инфраструктурой через Azure CLI (интерфейс командной строки).

Что еще? Формирование политик RBAC. Role Based Access Control — управление доступом на основе ролей, альтернатива спискам ACL. Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия.

Софт-скиллы

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

Что за Blameless Сulture?

Всё чаще многие хрюши многозначительно кивают в сторону blameless culture. «Безупречная культура», которая, как говорят, первой появилась на производственных линиях Тойоты, теперь становится мейнстримом в ИТ-компаниях. Основные её постулаты гласят:

Источник

После DevOps: как стать SRE и устроиться на работу в Google

SRE — это Site Reliability Engineer

В IT отрасли это инженер, который отвечает за надежность очень сложных сервисов. Появилась профессия в Google и придумали методологию именно там. Оно и понятно, Гугл – это сервис, который использует весь мир. Это огромные мощности и большая сложность.

14 декабря в работе гугла был сбой, весь мир был в недоумении. Вот в таких случаях и нужен SRE-инженер. Он не должен допустить подобных промахов.

Методологию DevOps российский IT-рынок освоил раньше и теперь ведутся жаркие споры об SRE vs DevOps. Кто-то говорит, что это одно и тоже, кто-то, что SRE это нечто, что логично продолжает DevOps. В России профессия только появилась. Крупные банки, которые содержат большие мощности, стали серьезно задумываться о таких ребятах.

В общем, Пока все спорят, мы решили пообщаться об SRE и DevOps, а также о работе в Гугл и Тинькофф.

Одного SRE я нашла в Tinkoff, до этого он работал в Google – у первоисточника, так сказать. Зовут его Дима Масленников. Google мы уделили отдельное внимание, так как есть стереотип, что работать там весело. Мы выяснили, что не всем.

В статье приведен краткий и творчески переработанный текст интервью. Если хочется подробностей или лень читать, смотрите полную версию на моем youtube-канале

Фаря:
– Как ты попал в Google?
Дмитрий Масленников:
– Они меня очень долго хантили. Писали мне в LinkedIn, просили мое резюме, а я всё забывал им его прислать…
– Почему их футболил? Это же, блин, Google!
– Не знаю, мне в России было хорошо.
– А чем ты занимался в этот момент?
– Был программистом, архитектором ПО. Занимался разработкой бэкенда.
А почему именно на тебя обратили внимание, как ты думаешь?
– Понятия не имею. У меня были всякие громкие слова вписаны в профиле, потому что я работал на всякие Еbay, Samsung. И видимо, обилие этих громких имен и технологий, с которыми я работал, и сыграли роль.
– Они тебя SRE обучали? Ведь в России такого не было и нет до сих пор.
– Да, и нигде в мире такого нет. Поэтому обучение проходит в Google примерно полгода.
– Вокруг SRE идут дикие дискуссии. Что это, является ли SRE противопоставлением DevOps, является ли оно его дополнением?
– Я когда работал в eBay, я хорошо прочувствовал, что было до DevOps. Есть разработка (программисты) и есть администраторы. И они друг друга никогда не видят. Ты передал код руководителю, и он где-то лежит. Он, в свою очередь, тоже кому-то там передал. И кто-то этот код как-то эксплуатирует. DevOps же сказал, что их надо посадить вместе.
– В какой момент здесь появляется SRE?
– SRE появляется, когда софт становится чрезмерно сложным и чрезмерно нагруженным. Во-первых, сам функционал растет очень сильно. И это, порой, незаметно. Ну что поменялось в Google-поиске за последний год или за последние 5 лет? А там релизы идут каждую неделю с новым функционалом! Причем, именно с функционалом.

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

– Я вообще даже не представляю, что там можно обновлять?
– Например, ты кофе ищешь. Во-первых, геолокация. Если ты кофе ищешь в поле, то наверно ты ищешь, как его выращивают или историю. Если кофе ищешь в центре мегаполиса, то, наверное, попить. Или Хилтон. Это фамилия или отель?
– Так, а SRE тут где?
– Во-первых, растет функционал, растет сложность, растет нагрузка. То есть, мы охватываем всё больше и больше людей, интернет становится доступнее и доступнее. Например, присоединяется Индия и другие, ранее недоступные страны и местности. Всё становится географически очень широким. И соответственно люди начинают потреблять, у сервиса растет нагрузка. И это дает чрезмерную сложность.
Одно дело открыть сервис только на Москву, другое – на всю Россию. Нагрузка колоссальная. И что происходит? Чтобы обслужить такое количество людей быстро, нужно очень много серверов. Сервисы должны быть доступны 24×7. Представь, если сейчас у тебя платеж будет идти не 5 минут, а три дня?
И вопрос, что администратору с этим всем делать?
– Я предположу, что есть много администраторов. И они существуют в сложной иерархии, чтобы всё это дело поддерживать.
– Администраторами, как пишет Google, расти невыгодно. Нанимать столько людей уже невозможно. Вот поэтому и появилось SRE.
– В какой момент DevOps становится SRE?
– Очень философский вопрос. Есть задачи и есть проблемы. Их нужно решать. Например, если в банке не выполнились переводы, то что делать? Решать проблему. Называть ли это SRE или не называть – непонятно.
Ну, и это вообще просто такой спор ни о чём. «Есть ли жизнь на Марсе, нет ли жизни на Марсе?» Является ли SRE DevOps’ом, не является ли SRE DevOps’ом? И SRE, и DevOps – это про то, как делать хорошо. Значит, берём лучшее отовсюду, применяем, чтобы пользователи были довольны.
– То есть две методологии работают в связке?
– В связке, но SRE всё-таки не администраторы, у них больше упор на программирование и автоматизацию. Плюс, я постоянно топлю за то, что мы административными методами редко должны работать. А если это происходит, то значит у нас что-то не так.
– Но это не ответ на вопрос.
– Они могут быть братья, они могут перекликаться, может быть одно и тоже – как хотите. А действия-то как поменяются? Всё равно всё сводится к одному: есть софт, его надо эксплуатировать, нужны какие-то люди, которые будут решать проблемы по нагрузке. И как их назвать – дело десятое.
– SRE может стать DevOps или программист? Вообще, что нужно изучать, чтобы стать востребованным SRE?
— Мне кажется, что надо учить не программирование, не SRE и DevOps, а думать про процесс, как про инженерное дело, которое присутствует в разработке программного обеспечения и оно многофакторное.
Недавно мы митап проводили про SRE, мы много спорили, но в одном мы сошлись: программисты уже не нужны так, как раньше. Нужны всем инженеры, которые могут решать проблемы. Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.

Про работу SRE в Google

– Давай про Гугл. Есть легенды про плюшки в Гугл при трудоустройстве. Расскажи поподробнее.
– Во-первых, когда уходишь с прошлого места работы, они спрашивают: «Сколько премий ты потеряешь, увольняясь?». Они компенсируют эти деньги, чтобы ты не раздумывал. Потом мне сняли на 3 месяца квартиру, дали отдельного риелтора от Google, который подбирает жилье. Либо они могут компенсировать тебе все расходы по переезду.

Первую неделю работы они тебе рассказывают вообще не про работу, а про то, как жизнь в Гугле и Ирландии устроена. В компании всё очень спокойно. Там везде микрокухни – фруктики, и прочее. Общение в микрокухнях – отдельная культура. Ещё есть трехразовое питание, массажи и раз в неделю можно прийти на работу с питомцем.

И такая мантра есть от менеджера – «главное, не перегори, не переработай.»

Ещё у нас история интересная была. Парень устроился сразу после вуза, и решил сэкономить на жилье. Он купил самый дешёвый фургон, поставил туда кровать. В Google есть прачечные, аккумуляторы он заряжал в офисе, душ и полотенца тоже имеются. Фургон поставил на парковку у офиса и ходил с нее на работу.

Он хотел быстро выплатить кредит за обучение. Но потом ему так делать запретили.
– Почему?
– В СМИ пошла новость, стали обсуждать, а Google не нравится большая активность. Репутация брэнда, все дела…
– А почему ты уехал в Россию и трудоустроился в Тинькофф? Это так нетипично. Все стараются свалить, а ты вернулся.
– Не знаю, бренд интересный и я клиент очень давно. Где ещё работать в России? Ну, Яндекс, ну Тинькофф. А уехал, потому что в Дублине скучно стало.
– Почему в Дублине скучно?
– Это маленький город. Это не Шенген, чтобы поехать в Европу – надо получать визу.
По-нашему менталитету Дублин – это деревня. Когда местные говорят, что они устали от Дублина, потому что там вайб большого города, для жителей Москвы это звучит смешно.
Но плюсы там были, например, очень спокойные люди. Там вообще никто не повышает голос. В России то, что не считается повышением голоса, после Дублина выглядит контрастно.
– А почему в Google скучно? Что у Тинькофф есть такого, что нет у Google?
– В Тинькофф есть драйв и хорошая агрессивность.
«Мы хотим там расти, мы хотим захватывать рынки, мы хотим быть лучшими.»
А в Google: «Мы уже лучшие. Мы уже всё захватили. Ну, что-то мы ещё хотим дозахватить в Китае, но там политические проблемы».

Если вам понравилось, ищите подробности в полной версии интервью.

Источник

SRE-инженер и системный администратор: в чем разница и кто нужен вашей компании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Портал №1 по управлению цифровыми
и информационными технологиями

Site Reliability Engineering (SRE) и DevOps – два популярных направления, которые во многом совпадают. Ранее находились те, кто называл SRE конкурирующим с DevOps набором практик. Но мы считаем, что они не такие уж и разные.

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

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

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

DevOps и SRE — это не два конкурирующих метода разработки и эксплуатации программного обеспечения, а скорее близкие друзья, призванные сломать организационные барьеры для еще более быстрой поставки качественного ПО. Если вы читаете книги, ознакомьтесь с тем, как SRE соотносится с DevOps (Betsy Beyer, Niall Richard Murphy, Liz Fong-Jones) более подробно.

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

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

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

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

SLI, SLO и SLA тесно связаны с одной из основ DevOps — «измерять всё», — и это одна из причин, по которой мы говорим, что класс SRE реализует DevOps.

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

Стремление к максимальной стабильности системы является контрпродуктивным и бессмысленным. Нереалистичные целевые показатели надежности ограничивают скорость доставки новых функций пользователям, к тому же, пользователи обычно не замечают крайней доступности (например, 99,999999%), потому что в их опыте преобладают менее надежные компоненты, такие как Интернет-провайдеры, сотовые сети или Wi-Fi. Наличие требования 100% доступности серьезно ограничивает возможности команды или разработчика по доставке обновлений и улучшений в систему. Владельцы услуг, которые хотят предоставить много новых функций, должны выбрать менее строгие SLO, тем самым давая возможность продолжать поставку в случае ошибки. Владельцы сервисов, ориентированные на надежность, могут выбрать более высокий SLO, но признают, что нарушение этого SLO задержит выпуски функций. SRE количественно определяет этот приемлемый риск как «бюджет ошибок». Когда бюджеты ошибок исчерпаны, фокус смещается с разработки функций на повышение надежности.

Сотрудничество является важным аспектом SRE. Без этого ничто не мешает командам нарушать согласованные SLO, заставляя специалистов SRE работать сверхурочно или тратить слишком много времени на поддержание работы систем. Если команды SRE не имеют возможности принудительно применять бюджеты ошибок (или если бюджеты ошибок не воспринимаются всерьез), происходит сбой системы.

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

Важным компонентом SRE является труд, бюджеты на труд и способы снижения трудозатрат. Труд происходит постоянно, оператору нужно вручную касаться системы во время нормальных операций – но определение «нормальности» постоянно меняется.

Труд — это не просто «работа, которую я не люблю делать». Например, следующие задачи требуют времени, но сюда не относятся: предоставление авансовых отчетов, участие в совещаниях, ответы на электронную почту по дороге на работу и т.д. Напротив, труд – это специфика, связанная с обеспечением продуктивности услуги. Это работа имеет тенденцию быть ручной, повторяющейся, автоматизируемой и лишенной долгосрочной ценности. Кроме того, объём труда возрастает линейно по мере роста услуги. Каждый раз, когда оператору необходимо выполнить работу в системе, например, обработать запрос или заявку, вероятно, возникает труд.

SRE направлен на снижение трудозатрат, фокусируясь на «инженерной » составляющей Site Reliability Engineering. Когда специалисты SRE находят задачи, которые могут быть автоматизированы, они работают над тем, чтобы спроектировать решение, предотвращающее этот труд в будущем. Хотя минимизация труда важна, реально от него невозможно уйти полностью. Google стремится гарантировать, что, по крайней мере, 50% времени каждого специалиста SRE тратится на инженерные проекты, и эти специалисты индивидуально сообщают о своих трудностях в ежеквартальных обследованиях для оперативного выявления перегруженных команд. Как говорится, труд не всегда плох. Предсказуемые, повторяющиеся задачи отлично подходят для адаптации нового члена команды, порождают чувство выполненного долга и удовлетворения с низким риском и стрессом. Однако в долгосрочной перспективе такие трудозатраты быстро перевешивают преимущества и могут привести к стагнации.

Бюджеты на труд и труд тесно связаны с ключевыми тезисами DevOps «измерить все» и «убрать организационные барьеры».

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

Таким образом, в 2016 году была запущена программа CRE, чтобы повысить надежность наших клиентов Google Cloud Platform (GCP), а также средство предоставления Google SRE непосредственно для изменений, с которыми сталкиваются клиенты. Программа CRE направлена на снижение беспокойства клиентов, обучая их принципам SRE и помогая им принять практики SRE.

CRE согласуется с такими основами DevOps, как «устранение организационных барьеров», активизируя сотрудничество внутри организации, а также тесно связана с концепциями «принятия отказа как нормы» и «измерения всего», создавая общую ответственность среди всех заинтересованных сторон в форме общих SLO.

Источник