Sre инженер что это
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: «Мы уже лучшие. Мы уже всё захватили. Ну, что-то мы ещё хотим дозахватить в Китае, но там политические проблемы».
Если вам понравилось, ищите подробности в полной версии интервью.
Еще раз о DevOps и SRE
По мотивам дискуссии в чате AWS Minsk Community
В последнее время разгораются настоящие битвы на предмет определения понятия DevOps и SRE.
Несмотря на то, что уже во многом дискуссии на эту тему уже набили оскомину, в том числе и мне, решил вынести на суд хабра-сообщества и свой взгляд на эту тему. Тем, кому интересно, добро пожаловать под кат. И да начнется все по новой!
Предыстория
Итак, в стародавние времена жила отдельно команда разработчиков ПО и администраторов серверов. Первые благополучно писали код, вторые, употребляя различные теплые ласковые слова в адрес первых, настраивали сервера, периодически приходя к разработчикам и получая в ответ исчерпывающее «на моей машине все работает». Бизнес ждал программное обеспечение, все простаивало, периодически ломалось, все нервничали. Особенно тот, кто за весь этот бардак платил. Славная ламповая эпоха. Ну да вы и так в курсе, откуда растут ноги у DevOps.
Рождение DevOps практик
Затем пришли серьезные дяди и сказали — это не индустрия, так работать нельзя. И притащили модели жизненного цикла. Вот, например, V-модель.
Итак, что мы видим? Бизнес приходит с концепцией, архитекторы проектируют решения, разработчики пишут код, дальше — провал. Кто-то как-то тестирует продукт, кто-то как-то его доставляет конечному пользователю и где-то на выходе этой чудо-модели сидит одинокий бизнес-заказчик и ждет обещанной у моря погоды. Пришли к выводу — нужны методы, которые позволят этот процесс наладить. И решили создать практики, которые бы их реализовывали.
И решили они назвать их DevOps практиками — думаю имели в виду from Development to Operations. Придумали разные мудреные штуки — CI/CD практики, практики, основывающиеся на IaC принципе, тысячи их. И понеслась, разработчики пишут код, DevOps инженеры трансформируют описание системы в виде кода в работающие системы (да, код это к сожалению, всего лишь описание, но никак не воплощение системы), доставка крутится, ну и так далее. Вчерашние администраторы, освоив новые практики, гордо переквалифицировались в DevOps инженеров, и все понеслось. И был вечер, и было утро… извините, не оттуда.
Все опять не слава богу
Только все улеглось, и разные хитрые «методологи» начали писать толстенные книги по DevOps практикам, тихо разгорались споры, кто же такой все-таки пресловутый DevOps инженер и что DevOps — это культура производства, опять назрело недовольство. Внезапно обнаружилось, что доставка ПО — абсолютно нетривиальная задача. У каждой инфраструктуры разработки свой стек, где-то собирать надо, где-то разворачивать environment, тут нужен tomcat, тут нужен еще хитровымученный способ запуска — в общем, голова трещит. А еще проблема, как ни странно, оказалась в первую очередь в организации процессов — вот эта функция доставки, как бутылочное горлышко, стало блокировать процессы. К тому же эксплуатацию (Operations) никто не отменял. Ее в V-модели не видно, а там еще весь жизненный цикл справа. По итогу надо и как-то инфраструктуру поддерживать, и в мониторинг смотреть, и инциденты разруливать, да еще и доставкой заниматься. Т.е. сидеть одной ногой и в разработке, и в эксплуатации — и вдруг получился такой Development & Operations. А тут еще и повальный хайп на микросервисы подъехал. А с ними еще и разработка с локальных машин начала в клауд переезжать — попробуй что-то отладить локально, если микросервисов десятки и сотни, тут уже постоянная доставка становится средством выживания. Для «маленькой скромной компании» еще куда ни шло, но все же? А Google?
SRE от Google
Пришел Google, съел самые крупные кактусы и решил — нам такое не надо, нам надежность нужна. А надежностью надо управлять. И решил — нам нужны специалисты, которые будут управлять надежностью. Назвал их SR-инженерами и сказал, вот вам все, сделайте, как обычно, хорошо. Вот вам SLI, вот вам SLO, вот вам мониторинг. И ткнул носом в operations. И назвал свой «надежный DevOps» SRE. Вроде бы все хорошо, но есть один грязный хак, который Google мог себе позволить — на позиции SR инженеров нанимать людей, которые имели квалификацию разработчиков и еще немного шили на дому разбирались в функционировании работающих систем. Причем с наймом таких людей и у самого Google проблемы — главным образом потому, что тут он сам с собой конкурирует — надо же и бизнес-логику кому-то описывать. Доставку развесил на релиз-инженеров, SR — инженеры управляют надежностью (ясное дело, не напрямую, а влияя на инфраструктуру, меняя архитектуру, отслеживая изменения и показатели, разбираясь с инцидентами). Красиво, можно книги писать. А что делать, если вы не Google, а надежность все же как-то беспокоит?
Развитие идей DevOps
Тут как раз подоспел Docker, выросший из lxc, а затем и различные системы оркестрации типа Docker Swarm и Kubernetes, и DevOps инженеры выдохнули — унификация практик упростила доставку. Упростила до такой степени, что стало возможным даже отдать доставку разработчикам — что там deployment.yaml. Контейнеризация проблему решает. Да и зрелость систем CI/CD уже на уровне один файл написал и все понеслось — разработчики сами справятся. И тут мы начинаем говорить, как нам сделать свой SRE, с… да хоть с кем-нибудь.
SRE не в Google
Ну ок, доставку мы отдали, вроде бы можем выдохнуть, вернуться к старым добрым временам, когда админы смотрели загрузку процессоров, тюнили системы и тихо потягивали из кружек что-то непонятное в тишине и спокойствии… Стоп. Мы не ради этого все затевали (а жаль!). Внезапно оказывается, что в подходе Google мы вполне можем взять отличные практики — не загрузка процессоров важна, и не то, насколько часто мы диски там меняем, или там в клауде стоимость оптимизируем, а бизнес-метрики — все те же пресловутые SLx. И управление инфраструктурой с них никто не снимал, и инциденты разруливать надо, и дежурить на посту периодически, и вообще в теме бизнес-процессов быть. И парни, начинайте уже понемногу программировать на хорошем уровне, вас Google уже заждался.
Резюмируя. Внезапно, но вы уже устали читать и вам не терпится плюнуть написать автору в комментарии к статье. DevOps как практики доставки, был есть и будет. И никуда не денется. SRE как набор практик эксплуатации делает эту самую доставку успешной.
Обязанности SRE-инженера в зарубежных вакансиях
Введение
В 2016 году Google выпустила ту самую книгу о SRE (Site Reliability Engineering). Эта практика решала важную задачу компании — поддержание высокой надёжности сервисов Google. За годы практика широко распространилась среди разработчиков по всему миру. Теперь во многих стартапах и крупных корпорациях есть должность SRE-инженера.
Так менялся интерес работодателей к SRE-инженерам с течением времени.
Тренд поиска SRE-инженеров
Практика относительно новая, так что пока не совсем понятно, что конкретно должны делать SRE-инженеры. Можно, конечно, почитать книжки или посмотреть видео, но полный список должностных обязанностей по ним не составишь.
Результаты аналитики
Мы выделили несколько основных обязанностей:
Деплой и обслуживание инфраструктуры (84% объявлений).
Определение и контроль SLO, SLI и бюджетов на ошибки (34% объявлений).
Настройка мониторинга и алертов (47% объявлений).
Дежурство, реагирование на инциденты, постмортемы (47% объявлений).
Создание инструментов и автоматизация (56% объявлений).
Комментарий Евгения Бутырина, технического редактора Слёрм
В вакансиях Российских компаний эти обязанности также присутствуют, в тех или иных формулировках. С упоминанием обязанностей в процентом соотношении всё не так прозрачно. Зачастую в вакансиях пишут где-нибудь в требованиях: уметь в мониторинг. А в обязанностях ни слова, но мы понимаем, что раз нужно знать, значит понадобится. Та же история с SLO и бюджетом на ошибки, будучи одними из основных практик, по умолчанию подразумевается, что это надо знать и уметь. А про дежурства может быть написано: обеспечивать работоспособность сервисов 24/7.
Деплой и обслуживание инфраструктуры
Одна из главных задач SRE-инженера — проектировать, создавать и обслуживать инфраструктуру, в которой работают продукты и сервисы компании. Это может быть частное облако, но все чаще публичное, например AWS или Google Cloud. Сейчас популярно писать инфраструктуру как код (IaC), используя синтаксис YAML и HCL (для продуктов Hashicorp, вроде Terraform).
Чтобы принимать правильные решения об инфраструктуре, SRE-инженер должен участвовать в планировании ресурсов для новых и существующих продуктов, в том числе обсуждать с командами по продуктам и другими инженерами примерную нагрузку, требования к задержкам и т. д.
Иногда SRE-инженер отвечает за комплаенс инфраструктуры, особенно за соблюдение GDPR и SOC2. Наконец, большинство компаний стараются оптимизировать расходы на инфраструктуру, и этим тоже должен заниматься SRE.
Определение и контроль SLO, SLI и бюджетов на ошибки
Поддерживать надёжность производственных систем — важная обязанность SRE-инженера. Все-таки R в SRE означает reliability. Нужно понимать, как достичь корректной работы сервиса и соблюсти внутренние стандарты.
Для этого SRE-инженер определяет SLO и SLI. SLO — это показатели целевого уровня обслуживания для сервиса, а SLI — индикаторы, которые измеряют эти уровни. SLO можно определить вместе с коллегами на основе ожиданий клиентов и обязательств перед клиентами, сформулированных в виде SLA.
Когда SLO определены, их можно использовать как основу бюджетов на ошибки, то есть допустимого периода, когда сервис может работать ниже целевых уровней. В любой системе сбои неизбежны, и командам SRE и разработчиков нужен этот запас в виде бюджета на ошибки. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным.
Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм
Ещё с помощью бюджета можно понимать когда нужно работать над новыми фичами, а когда стоит поработать над стабильностью продукта.
Настройка мониторинга и алертов
Когда SLO определены, можно следить за их соблюдением с помощью SLI и мониторинга. Обычно мониторинг охватывает инфраструктуру (пики использования процессора и памяти), аптайм сервиса (веб-сайта или API), производительность (скорость загрузки страницы) и т. д. Можно использовать локальные инструменты, вроде Prometheus и Grafana, или популярные SaaS, например Datadog и Sentry.
Настройка мониторинга и алертов — это первый шаг. Нужно установить адекватные пороги, чтобы на команду не хлынул поток несущественных алертов. Алерты должны быть связаны с конкретными действиями, причем лучше заранее узнавать о симптомах, чтобы принимать меры, а не получать уведомления об уже случившихся сбоях.
Дежурство, реагирование на инциденты, постмортемы
Мы настроили мониторинг и получаем алерты, а теперь надо составить график дежурств и распределить обязанности по реагированию среди членов команды. Лучше использовать платформу управления инцидентами, чтобы все инциденты и алерты были собраны в одном месте, причём у каждого инцидента должен быть чётко определён ответственный сотрудник. Это поможет рассчитать важные метрики, вроде MTTA (среднее время реагирования) и MTTR (среднее время восстановления).
Ещё одна задача SRE-инженера — писать постмортемы, чтобы объяснить внешним и внутренним стейкхолдерам, какая цепочка событий привела к инциденту, какие меры были приняты и что было сделано, чтобы такого не повторилось.
Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм
Создание инструментов и автоматизация
Один из принципов SRE — устранение ручного труда. Google SRE определяет тяжелый труд как выполняемые вручную, повторяющиеся и нетактические задачи, которые можно автоматизировать. Эти задачи отнимают время разработчиков и SRE и мешают другим важным проектам. Автоматизировать повторяющиеся задачи — одна из важных обязанностей SRE-инженера. Это может быть автоматическое реагирование на распространённые алерты, настройка процесса CI/CD, чтобы команда работала быстрее, или создание продуктов, с помощью которых разработчики могут сами выполнять рутинные запросы.
Другие обязанности
В некоторых компаниях SRE-инженеры могут выполнять и другие задачи:
Отладка проблем в продакшене. Может затрагивать все уровни стека.
Разработка мультиоблачной стратегии. Сейчас всё больше рабочих нагрузок мигрирует в публичное облако, но стоит избегать зависимости от вендора — так дешевле и надёжнее. Поэтому сейчас многие компании стараются приспособить свои продукты к разным облачным платформам.
Хаос-инжиниринг. Впервые применен Netflix, а сейчас внедряется и в других компаниях. Это метод, при котором мы стараемся сломать систему изощрёнными способами, чтобы проверить ее устойчивость.
Заключение
Как видите, SRE-инженер должен не просто обслуживать инфраструктуру или помогать с CI/CD. Поддержание нормальной работы сервисов затрагивает разные области эксплуатации и разработки программного обеспечения.
Евгений Бутырин
Над материалом работала команда курса «SRE: внедряем DevOps от Google». Учебный центр Слёрм работу не обещает, но спикеры могут кое-чему научить.