У вебинара плохой звук, поэтому мы сделали расшифровку.
Меня зовут Медведев Эдуард. Я сегодня поговорю о том, что такое SRE, как появилось SRE, какие есть критерии работы у SRE-инженеров, немножко о критериях надежности, немножко о ее мониторинге. Мы пройдемся по верхам, потому что за час много не расскажешь, но я дам материалы для дополнительного ознакомления, и мы все ждем вас на . в Москве в конце января.
Вначале поговорим о том, что вообще такое SRE — Site Reliability Engineering. И как оно появилось как отдельная должность, как отдельное направление. Все началось с того, что в традиционных кругах разработки Dev и Ops – это две совершенно разные команды, как правило, с двумя совершенно разными целями. Цель команды разработки – выкатывать новые фичи, отвечать потребностям бизнеса. Цель команды Ops в том, чтобы все работало и ничего не ломалось. Очевидно, эти цели напрямую друг другу противоречат: чтобы все работало и ничего не ломалось выкатывать новых фич лучше как можно меньше. Из-за этого возникает много внутренних конфликтов, которые пытается решить методология, которая сейчас называется DevOps.
Проблема в том, что четкого определения DevOps и четкой имплементации DevOps у нас нет. Я выступал на конференции в Екатеринбурге 2 года назад, и до сих пор секция DevOps начиналась докладом «Что такое DevOps». В 2017 году девопсу уже практически 10 лет, но мы до сих пор спорим, что же это такое. И это очень странная ситуация, которую попытался решить Гугл несколько лет назад.
В 2016 году Гугл выпустил книгу, которая называется «Site Reliability Engineering». И по факту именно с этой книги началось движение SRE. SRE – этоконкретный вариант имплементации DevOps парадигмы в конкретной компании. Инженеры SRE ставят себе цель обеспечить надежную работу систем. В основном они берутся из разработчиков, иногда из администраторов с сильным бэкграундом разработки. И занимаются тем, чем раньше занимались системные администраторы, но сильный бэкграунд в разработке и знание системы с точки зрения кода ведут к тому, что эти люди не склонны к рутинной администраторской работе, а склонны к автоматизации.
Получается так, что DevOps парадигма в SRE-командах имплементируется тем, что есть SRE-инженеры, которые решают структурные проблемы. Вот она, та самая связь Dev и Ops, о которой люди уже 8 лет говорят. Роль SRE похожа на роль архитектора в том плане, что новички SRE не становятся. Люди в начале карьеры еще не имеют какого-то опыта, не имеют нужной широты знаний. Потому что SRE требует очень тонкого знания, что именно и когда именно может пойти не так. Поэтому здесь нужен какой-то опыт, как правило, и внутри компании, и снаружи.
Спрашивают, будет ли описана разница между SRE и девопс. Она только что была описана. Можем поговорить о месте SRE в организации. В отличие от такого классического подхода DevOps, где Ops – это все-таки обособленный отдел, SRE – это часть команды разработки. Они участвуют в разработке продукта. Есть даже подход, где SRE – это роль, которая переходит от одного разработчика к другому. Они участвуют в ревью кода точно также, как, например, UX-дизайнеры, сами разработчики, иногда продуктовые менеджеры. На этом же уровне работают SRE. Нужен их аппрув, нужно их ревью, чтобы на каждый деплой SRE сказал: «Хорошо, этот деплой, этот продукт не повлияет отрицательно на надежность. А если повлияет, то в каких-то допустимых пределах». Об этом мы тоже поговорим.
Соответственно у SRE есть вето на изменение кода. И в целом это тоже приводит к какому-то небольшому конфликту, если SRE реализовано неправильно. В той самой книге про Site Reliability Engineering много частей, даже не одна, рассказывают, как этих конфликтов избежать.
Спрашивают, каким образом SRE соотносится с информационной безопасностью. SRE напрямую не занимается информационной безопасностью. В основном в больших компаниях этим занимаются отдельные люди, тестировщики, аналитики. Но SRE точно также взаимодействует с ними в том плане, что какие-то операции, какие-то коммиты, какие-то деплои, которые затрагивают безопасность, также могут повлиять на доступность продукта. Поэтому у SRE в целом есть взаимодействие с любыми командами, в том числе с командами безопасности, в том числе с аналитиками. Поэтому в основном SRE нужны, когда пытаются внедрить DevOps, но при этом нагрузка на разработчиков становится слишком большой. То есть, сама команда разработки уже не справляется с тем, что теперь им нужно отвечать еще и за Ops. И появляется отдельная роль. Эта роль планируется в бюджете. Иногда эта роль закладывается в размер команды, появляется отдельный человек, иногда ей становится кто-то из разработчиков. Так в команде появляется первый SRE.
Сложность системы, на которую влияет SRE, сложность, которая влияет на надежность работы, бывает необходимой и случайной. Необходимая сложность это когда сложность продукта повышается в том объеме, которого требуют новые продуктовые фичи. Случайная сложность это когда сложность системы повышается, но продуктовая фича и требования бизнеса напрямую на это не влияют. Получается, что либо разработчик допустил где-то ошибку, либо алгоритм не оптимален, либо вводятся какие-то дополнительные интересы, которые повышают сложность продукта без особой необходимости. Хороший SRE эту ситуацию всегда должен отсекать. То есть, любой коммит, любой деплой, любой pull-реквест, где повышается сложность за счет случайного дополнения, должен блокироваться.
Вопрос, почему просто не нанять в команду инженера, системного администратора с большим багажом знаний. Разработчик в роли инженера, говорят нам, не самое оптимальное кадровое решение. Разработчик в роли инженера не всегда оптимальное кадровое решение, но речь здесь о том, что разработчик, который занимается Ops, имеет чуть больше стремления к автоматизации, имеет чуть больший багаж знаний и скилсет для того, чтобы эту автоматизацию внедрять. И соответственно мы уменьшаем не только время на какие-то конкретные операции, не только рутину, но и такие важные для бизнеса параметры, как MTTR (Mean Time To Recovery, время восстановления). Таким образом, и об этом тоже будет чуть-чуть попозже, мы экономим для организации деньги.
Теперь поговорим о критериях работы SRE. И в первую очередь о надежности. В небольших компаниях, стартапах очень часто получается так, что люди предполагают, если сервис написан хорошо, если продукт написан хорошо и правильно, он будет работать, он не сломается. Все, мы пишем хороший код, поэтому ломаться нечему. Код очень простой, ломаться нечему. Это примерно те же люди, которые говорят, что тесты нам не нужны, потому что, смотрите, это же три метода VPI, чему тут ломаться.
Это все разумеется неправильно. И этих людей очень часто такой код очень кусает на практике, потому что вещи ломаются. Вещи ломаются иногда самыми непредсказуемыми способами. Иногда люди говорят, что нет, этого никогда не случится. А оно все ровно случается. Бывает достаточно часто. И поэтому никто никогда не стремится к 100% доступности, потому что 100% доступности не бывает никогда. Это норма. И поэтому мы всегда, когда говорим о доступности сервиса, говорим о девятках. 2 девятки, 3 девятки, 4 девятки, 5 девяток. Если переводить это на время даунтайма, то, например, 5 девяток, то это чуть больше 5 минут даунтайма в год, 2 девятки это 3,5 дня даунтаймов.
Но очевидно, что в какой-то момент происходит уменьшение POI, отдачи инвестиций. Перейти с двух девяток на три девятки, это означает уменьшить даунтайм на 3 с лишним дня. Переход с четырех девяток до пяти уменьшает даунтайм на 47 минут в год. И получается так, что для бизнеса это может быть не критично. И в целом требуемая надежность это вопрос не технический, в первую очередь, это вопрос бизнеса, это вопрос продукта. Какой уровень даунтайма допустим для пользователей продукта, чего они ожидают, сколько они платят, например, сколько денег они теряют, сколько денег теряет система.
Важный вопрос при этом, какова надежность остальных компонентов. Потому что разница между 4 и 5 девятками не будет видна на смартфоне с 2 девятками надежности. Грубо говоря, если в год что-то ломается на смартфоне в вашем сервисе 10 раз, скорее всего 8 раз поломка произошла именно на стороне ОС. Пользователь к этому привык, и на один лишний раз в год не обратит внимания. Нужно соотносить цену повышения надежности и увеличения прибыли.
Как раз в книге по SRE есть хороший пример увеличения до 4 девяток с 3 девяток. Получается, что прирост доступности это чуть меньше 0,1 %. И если выручка сервиса составляет 1 млн долларов в год, то прирост выручки 900 долларов. Если повышение доступности на девятку обойдется нам меньше, чем в 900 долларов в год, этот прирост имеет финансовый смысл. Если он стоит больше 900 долларов в год, смысла он уже не имеет, потому что прирост выручки просто не компенсирует трудозатраты, ресурсозатраты. И 3 девяток нам будет вполне достаточно.
Это конечно упрощенный пример, где все запросы равны. И с 3 девяток до 4 девяток перейти достаточно просто, но при этом, например, перейти с 2 девяток до 3, это уже экономия в 9 тысяч долларов, она может иметь финансовый смысл. Естественно в реальности провал запроса на регистрацию хуже провала на отображение страницы, запросы имеют разный вес. У них может быть совсем разный критерий с точки зрения бизнеса, но все равно, как правило, если мы не говорим о каких-то специфичных сервисах, это достаточно надежная апроксимация.
Получили вопрос, является ли SRE одним из согласующих при выборе архитектурного решения сервиса. Допустим в плане интеграции в существующую инфраструктуру, чтобы не было потерь в ее стабильности. Да, SRE точно также, как влияют на pull-реквесты, коммиты, релизы, они влияют на архитектуру, на внедрение новых сервисов, микросервисов, на внедрение новых решений. Почему я до этого говорил, что нужен опыт, нужна квалификация. По сути SRE это один из блокирующих голосов в любом архитектурном и программном решении. Соответственно SRE как инженер должен, в первую очередь, не просто разбираться, но и понимать, как какие-то конкретные решения повлияют на надежность, на стабильность, и понимать, как это соотносится с бизнес-потребностями, и с какой точки зрения это может быть допустимо, а с какой нет.
Поэтому сейчас как раз можно поговорить о критериях надежности, которые в SRE традиционно определяются как SLA (Service Level Agreement). Скорее всего, знакомый термин. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement возможно знаковый термин, особенно если вы работали с сетями, с провайдерами, с хостингом. Это общее соглашение, которое описывает работоспособность всего вашего сервиса, пенальти, какие-то штрафы за ошибки, метрики, критерии. А SLI – это сама метрика доступности. То есть, что может быть SLI: время ответа от сервиса, количество ошибок в процентном соотношении. Это может быть пропускная способность, если речь идет о каком-то файловом хостинге. Если речь идет об алгоритмах распознавания, индикатором может быть, например, даже корректность ответа. SLO (Service Level Objective) – это соответственно сочетание индикатора SLI, его значения и периода.
Допустим, SLA может быть такой. Сервис доступен 99,95% времени в течение года. Либо 99 критических тикетов техподдержки будет закрыто в течение 3-х часов за квартал. Либо 85% запросов получат ответы в течение 1,5 секунд каждый месяц. То есть, мы постепенно приходим к понимаю того, что ошибки и сбои — это вполне нормально. Это допустимая ситуация, мы ее планируем, мы на нее в какой-то мере даже рассчитываем. То есть SRE строит системы, которые могут ошибаться, которые должны нормально реагировать на ошибки, которые должны их учитывать. И по возможности они должны обрабатывать ошибки таким образом, что пользователь либо не замечает их, либо замечает, но есть какой-то обходной путь, благодаря которому все не свалится напрочь.
Например, если заливать видео на ютуб, и ютуб не может конвертировать его сразу, если видео слишком большое, если формат не оптимальный, то запрос естественно не свалится с тайм-аутом, ютуб не выдаст ошибку 502, ютуб скажет: «Мы все создали, ваше видео обрабатывается. Оно будет готово примерно через 10 минут». Это принцип graceful degradation, который знаком, например, по разработке фронтэнда, если вы когда-то этим занимались.
Следующие термины, о которых мы будем говорить, которые очень важны для работы с надежностью, с ошибками, с ожиданиями, это MTBF и MTTR. MTBF – это среднее время между сбоями, mean time between failures. MTTR Mean Time To Recovery, среднее время до восстановления. То есть, сколько времени прошло от момента обнаружения ошибки, от момента появления ошибки до момента восстановления полностью нормальной работы сервиса. MTBF в основном исправляется работой над качеством кода. То есть, тем, что SRE могут сказать «нет». И нужно понимание всей команды, что когда SRE говорит «нет», он говорит это не потому что он вредный, не потому что он плохой, а потому что иначе все будут страдать.
Опять же, есть очень много статей, очень много методов, очень много способов даже в той самой книге, на которую я так часто ссылаюсь, как же сделать, чтобы остальные разработчики не начали ненавидеть SRE. MTTR, с другой стороны, это работа над вашими SLO (Service Level Objective). И это по большей части автоматизация. Потому что, например, наш SLO это аптайм 4 девятки на квартал. Значит, что за 3 месяца мы можем допустить 13 минут даунтайма. И получается, что MTTR у нас никак не может быть больше 13 минут. Если мы будем 13 минут реагировать хотя бы на 1 даунтайм, это означает, что весь бюджет на квартал мы уже исчерпали. Мы SLO нарушаем. 13 минут на реакцию и исправление сбоя — это очень много для машины, но очень мало для человека. Потому что пока человеку придет алерт, пока он среагирует, пока он разберется в ошибке, это уже несколько минут. Пока человек поймет, как ее исправить, что именно починить, что сделать, то это еще несколько минут. И по сути даже если просто надо перезагрузить сервер, как оказывается, или поднять новую ноду, то MTTR вручную это уже примерно 7-8 минут. При автоматизации процесса MTTR очень часто достигает секунды, иногда миллисекунд. Гугл говорит о миллисекундах обычно, но в реальности все конечно обстоит не так хорошо.
В идеале SRE должен практически полностью автоматизировать свою работу, потому что это напрямую влияет на MTTR, на его метрики, на SLO всего сервиса, и соответственно на прибыль бизнеса. Если превышено время, спрашивают нас, возлагается ли вина на SRE. По хорошему, вина не возлагается ни на кого. И это отдельная культура, которая называется balmeless postmortem, о которой мы сегодня не поговорим, но будем разбирать на Слёрме. Это очень интересная тема, о которой можно много говорить. Грубо говоря, если превышено отведенное время в квартал, то виноваты понемногу все, а это значит, что винить всех не продуктивно, давайте вместо этого, может быть, не винить никого, а исправлять ситуацию и работать с тем, что мы имеем. По моему опыту, такой подход большинству команд, особенно в России, немножко чужд, но он имеет смысл и работает очень хорошо. Поэтому я порекомендую в конце статьи и литературу, которые можно на эту тему почитать. Или приходите на Слёрм SRE.
Поясню. Если превышено время SLO в квартал, если даунтайма было не 13 минут, а 15, кто в этом может быть виноват? Конечно, может быть виноват SRE, потому что он явно допустил какой-то плохой коммит или деплой. В этом может быть виноват администратор дата-центра, потому что провел, возможно, какой-то внеплановый maintenance. Если в этом виноват администратор дата-центра, соответственно в этом виноват человек из Ops, который не расчитал maintenance, когда согласовывал SLO. В этом виноват менеджер, технический директор или кто-то, кто подписывал договор дата-центра и не обратил внимание, что SLA дата центра не рассчитан на нужный даунтайм. Соответственно все понемногу в этой ситуации виноваты. И значит, ни на кого особо нет смысла возлагать вину в этой ситуации. Но исправить ее конечно нужно. Поэтому существуют постмортемы. И если почитать, например, постмортемы Гитхаба, а это всегда очень интересная, маленькая и неожиданная история в каждом конкретном случае, можно заменить, что там никто никогда не говорит, что оказался виноват этот конкретный человек. Вина всегда возлагается на конкретные несовершенные процессы.
Перейдем к следующему вопросу. Автоматизация. Я обычно, когда говорю об автоматизации в других контекстах, очень часто ссылаюсь на таблицу, рассказывающую о том, насколько долго можно работать над автоматизацией задачи, чтобы не занять на ее автоматизацию больше времени, чем вы вообще экономите. Есть загвоздка. Загвоздка в том, что когда SRE автоматизируют какую-то задачу, они экономят не только время, они экономят деньги, потому что автоматизация напрямую влияет на MTTR. Они экономят, если можно так сказать, мораль сотрудников и разработчиков, которая тоже исчерпаемый ресурс. Они уменьшают рутину. И это все положительно сказывается на работе и как следствие на бизнесе, даже если кажется, что автоматизация не имеет смысла с точки зрения временных затрат.
По факту почти всегда имеет, и есть очень мало случаев, когда в роли SRE что-то автоматизировать не стоит. Дальше мы поговорим о том, что называется error budget, бюджет на ошибки. По факту выходит так, что если у вас все значительно лучше, чем SLO, который вы поставили себе, это тоже не очень хорошо. Это скорее плохо, потому что SLO работает не только как нижняя, но и как примерная верхняя граница. Когда вы поставили себе SLO в 99% доступности, а у вас по факту 99,99%, получается, что у вас есть некое пространство для экспериментов, которое совершенно не повредит бизнесу, потому что вы сами все вместе это определили, и вы это пространство не используете. У вас есть бюджет на ошибки, которые в вашем случае не израсходован.
Что мы с ним делаем. Мы используем его буквально на все. На тестирование в условиях продакшена, на выкатку новых фич, которые могут повлиять на производительность, на релизы, на maintenance, на плановые даунтаймы. Обратное правило тоже действует: если бюджет исчерпан, мы не можем зарелизить ничего нового, потому что у нас иначе превысится SLO. Бюджет уже исчерпан, мы что-то зарелизили, если оно повлияет негативно на производительность, то есть, если это не какой-то фикс, который сам по себе напрямую повышает SLO, то мы выходим за бюджет, а это плохая ситуация, она требует разбора, постмортема, и возможно какого-то исправления процессов.
То есть, получается, что если сервис сам по себе работает плохо, и SLO расходуется и бюджет расходуется на не эксперименты, не на какие-то релизы, а сам собой, то разработчикам вместо интересных каких-то фиксов, вместо интересных фич, вместо интересных релизов. Вместо какой-то любой творческой работы придется заниматься тупыми фиксами, чтобы вернуть бюджет в порядок, либо отредактировать SLO, а это тоже процесс, который не должен слишком часто происходить.
Поэтому получается, что в ситуации, где у нас остается больше бюджета на ошибки, заинтересованы все: и SRE, и разработчики. Для разработчиков большой бюджет на ошибки значит, что можно заниматься релизами, тестами, экспериментами. Для SRE бюджет на ошибки и вход в этот бюджет означает, что они собственно напрямую хорошо делают свою работу. И это влияет на мотивацию какой-то совместной работы. Если вы будете слушать ваших SRE как разработчики, у вас будет больше пространства на хорошую работу и гораздо меньше рутины.
Получается так, что эксперименты в продакшене это достаточно важная и почти неотъемлемая часть SRE в больших командах. И она как правило носит название chaos ingeneering, которое пошло от команды в Нетфликс, выпустившей утилиту, которая называетcя Chaos Monkey.
Chaos Monkey подключается к CI/CD пайплайну и случайным образом роняет в продакшене сервер. Опять же, в SRE структуре мы говорим о том, что упавший сервер – это само по себе не плохо, это ожидаемо. И если это входит в бюджет, это допустимо и не вредит бизнесу. Разумеется, у Нетфликса есть достаточно дублирующих серверов, достаточно репликации, чтобы это все можно было исправить, и чтобы пользователь в целом даже не заметил, и уж тем более никто не вышел от одного сервера ни за какой бюджет.
У Нетфликса в какое-то время был целый набор таких утилит, одна из которых, Chaos Gorilla, выключает полностью одну из зон доступности в Амазоне. И подобные вещи хорошо помогают выявить, во-первых, скрытые зависимости, когда не совсем понятно, что на что влияет, что от чего зависит. А это, если вы работаете с микросервисом, и документация не совсем идеальная, это может быть вам знакомо. И опять же это хорошо помогает вылавливать ошибки в коде, которые вы не можете поймать на стейджинге, потому что любой стейджинг это все ровно не точная симуляция, из-за того, что другой масштаб нагрузок, другой паттерн нагрузок, оборудование тоже, скорее всего, другое. Пиковые нагрузки тоже могут быть неожиданными и непредсказуемыми. И такое тестирование, которое опять же не выходит за рамки бюджета, очень хорошо помогает отловить ошибки в инфраструктуре, которые стейджинг, автотесты, CI/CD пайплайн никогда не выловят. И пока это все входит в ваш бюджет, не имеет никакого значения, что у вас там упал сервис, хотя, казалось бы, очень страшно, упал сервер, какой кошмар. Нет, это нормально, это хорошо, это помогает ловить ошибки. Есть бюджет, значит можно его тратить.
Вопрос: какую литературу я могу посоветовать? Список в конце. Литературы очень много, посоветую несколько докладов. Как работает, и работает ли SRE в компаниях без своего программного продукта или с минимальной разработкой. Например, в энтерпрайзе, где основная деятельность не ПО. В энтерпрайзе, где основная деятельность не ПО, SRE работает точно также как и везде, потому что в энтерпрайзе точно также нужно использовать, даже если не разрабатывать, программные продукты, нужно выкатывать апдейты, нужно менять инфраструктуру, нужно расти, нужно скейлится. И SRE помогают определить и предсказать возможные проблемы в этих процессах и проконтролировать их уже после того, как начнется какой-то рост и потребности бизнеса поменяются. Потому что совершенно не обязательно заниматься разработкой ПО для того, чтобы было SRE, если у вас есть хотя бы несколько серверов и у вас ожидается хотя бы какой-то рост.
Тоже самое касается небольших проектов, небольших организаций, потому что у больших компаний есть бюджет и пространство для экспериментов. Но при этом всеми этими плодами экспериментов можно пользоваться где угодно, то есть SRE конечно появились в Гугл, в Нетфликс, в Дропбоксе. Но при этом небольшие компании и стартапы уже могут почитать конденсированный материал, почитать книги, посмотреть доклады. Они начинают слышать об этом чаще, смотрят на конкретные примеры, думаю, это окей, это действительно может быть полезно, нам тоже такое нужно, классно.
То есть, всю основную работу по стандартизации этих процессов за вас уже проделали. Вам осталось определить роль SRE конкретно в вашей компании и начать собственно внедрять все эти практики, которые опять же уже описаны. То есть, из полезных принципов для небольших компаний, это всегда определение SLA, SLI, SLO. Если вы не занимаетесь ПО, то это будут внутренние SLA и внутренние SLO, внутренний бюджет на ошибки. Это всегда практически приводит к каким-то интересным дискуссиям внутри команды и внутри бизнеса, потому что возможно окажется, что вы тратите на инфраструктуру, на какую-то организацию идеальных процессов, идеального пайплайна гораздо больше, чем надо. И эти 4 девятки, которые у вас есть в IT отделе, они вам сейчас не очень нужны. Но при этом можно было потратить время, потратить бюджет на ошибки на что-нибудь еще.
Соответственно мониторинг и организация мониторинга полезна для компании любого размера. И в целом вот этот образ мысли, где ошибки это что-то допустимое, где существует бюджет, где существуют Objectives, он опять же полезен для компании любого размера, начиная от стартапов на 3 человека.
Последнее из технических нюансов, о чем можно поговорить, это мониторинг. Потому что если мы говорим об SLA, SLI, SLO, мы никак не можем без мониторинга понять, вписываемся ли мы в бюджет, соблюдаем ли мы наши Objectives, и как мы влияем на финальный SLA. Я очень много раз наблюдал, что мониторинг происходит следующим образом: есть какое-то значение, например время запроса к серверу, среднее время или количество запросов к базе данных. У него есть определенная инженером норма. Если метрика отклоняется от нормы, то прилетает е-мэйл. Это все абсолютно бесполезно, как правило, потому что ведет к такому перенасыщению алертами, перенасыщению сообщениями от мониторинга, когда человек, во-первых, каждый раз должен их интерпретировать, то есть определять: означает ли значение метрики необходимость каких-то действий. А во-вторых, он просто перестает замечать все эти алерты, когда в основном никаких действий от него при этом не требуется. То есть хорошее правило мониторинга и самое первое правило, когда реализуется SRE в том, что уведомление должно приходить только тогда, когда требуется действие.
В стандартном случае есть 3 уровня событий. Есть алерты, есть тикеты, есть логи. Алерты – это все то, что требует от вас немедленного действия. То есть, вот, все сломалось, нужно чинить прямо сейчас. Тикеты – это то, что требует отложенного действия. Да, нужно что-то делать, нужно что-то делать вручную, автоматизация не справилась, но не обязательно делать это в течение следующих нескольких минут. Логи – это все то, что не требует действия, и в целом при хорошем развитии событий, никто никогда не будет их читать. Читать логи нужно будет только когда уже в ретроспективе оказалось, что какое-то время что-то ломалось, мы об этом не знали. Или нужно провести какое-то расследование. Но в целом все то, что не требует никаких действий, идет в логи.
Как побочный эффект от всего этого, если мы определили, какие события требуют действий и хорошо описали, какими эти действия должны быть, это означает, что действие можно автоматизировать. То есть, что получается. Мы идем от алерта. Идем к действию. Идем к описанию этого действия. И дальше мы идем к автоматизации. То есть, любая автоматизация начинается с реакции на событие.
От мониторинга мы переходим к термину, который называется Observability. Тоже такой немножко хайп вокруг этого слова последние несколько лет. И мало кто понимает, что это значит вне контекста. Но основной смысл в том, что Observability это метрика прозрачности системы. Если что-то пошло не так, насколько быстро вы сможете определить, что именно пошло не так, и каким было состояние системы в этот момент. С точки зрения кода: в какой функции произошел сбой, в каком сервисе произошел сбой. Каким было состояние, например, внутренних переменных, конфигурации. С точки зрения инфраструктуры это в какой зоне доступности произошел сбой, а если у вас стоит какой-нибудь Kubernetes, то в каком поде произошел сбой, каким было состояние пода. И соответственно Observability имеет прямую зависимость с MTTR. Чем выше Observability сервиса, тем проще определить ошибку, тем проще исправить ошибку, тем проще автоматизировать ошибку, тем ниже MTTR.
Если перейти к небольшим компаниям снова, то очень часто спрашивают, даже вот сейчас, как поступать с размером команды, и нужно ли в небольшой команде нанимать отдельного SRE. Уже об этом говорил чуть ранее. На первых этапах развития стартапа или, например, команды это совсем не обязательно, потому что SRE можно сделать переходной ролью. И это немножко оживит команду, потому что есть хоть какое-то разнообразие. И плюс подготовит людей к тому, что с ростом, в общем-то, обязанности SRE будут меняться очень значительно. Если нанимать человека, то у него, разумеется, есть какие-то ожидания. И эти ожидания со временем не изменятся, а вот требования изменятся очень сильно. Поэтому как бы нанимать SRE достаточно сложно на ранних этапах. Вырастить своего гораздо проще. Но об этом стоит задуматься.
Единственное, наверное, исключение, это когда есть очень жесткие и хорошо определенные требования по росту. То есть в случае стартапа это может быть какое-то давление от инвесторов, какой-то прогноз на рост сразу в несколько раз. Тогда найм SRE, в общем-то, оправдан, потому что его можно обосновать. У нас есть требования по росту, нам нужен человек, который будет отвечать за то, что при таком росте ничего не сломается.
Еще один вопрос. Как быть, когда несколько раз разработчики пилят фичу, которая проходит тесты, но ломает прод, нагружает базу, ломает другие фичи, какой процесс внедрить. Соответственно в этом случае внедряется как раз бюджет на ошибки. И часть сервисов, часть фич тестируется уже сразу в проде. Это может быть canary, когда только небольшому количеству пользователей, но уже в проде разворачивается фича, но уже с расчетом на то, что если что-то сломается, например, у половины процента всех пользователей, то все еще уложится в бюджет на ошибки. Соответственно да, ошибка будет, у части пользователей все сломается, но мы уже говорили о том, что это нормально.
Был вопрос по инструментам SRE. То есть, есть ли что-то конкретное, что использовали бы SRE, и не использовали бы все остальные. На самом деле есть какие-то узкоспециализированные утилиты, есть какой-то софт, который, например, имитирует нагрузки или занимается canary A/B тестированием. Но в основном инструментарий SRE это то, что уже используют ваши разработчики. Потому что SRE взаимодействует напрямую с командой разработки. И если у вас будет разный инструментарий, то получится, что уходит время на синхронизацию. Особенно если SRE работают в больших командах, в больших компаниях, где команд может быть несколько, здесь очень поможет именно стандартизация именно в масштабах компании, потому что если в 50 командах используется 50 разных утилит, это означает, что SRE должен знать их все. И этого разумеется никогда не произойдет. И качество работы, качество контроля как минимум части команд значительно снизится.
У нас вебинар подходит постепенно к концу. Какие-то основные вещи я успел рассказать. Разумеется, ничего об SRE нельзя рассказать и понять за час. Но я надеюсь, что получилось передать этот образ мысли, основные ключевые моменты. И дальше можно будет, если интересно, углубляться в тему, учиться самостоятельно, смотреть на то, как это внедряется у других людей, в других компаниях. И соответственно в начале февраля приехать к нам на Слёрм SRE.
Слёрм SRE — это трехдневный интенсивный курс, в котором будет рассказываться примерно о том, что сейчас рассказываю я, но с гораздо большей глубиной, с реальными кейсами, с практикой, весь интенсив направлен на практическую работу. Людей распределят по командам. Вы все будете работать над реальными кейсами. Соответственно у нас есть инструкторы из Booking.com Иван Круглов и Бен Тайлер. У нас есть замечательный Евгений Варавва из Гугла, из Сан Франциско. И я тоже вам что-нибудь расскажу. Поэтому обязательно приезжайте к нам.
Итак, список литературы. Есть ссылки по SRE. на ту самую книгу, вернее на 2 книги об SRE, написанные Гуглом. Еще одна , где чуть подробнее раскрываются термины и их применение. Следующие 3 это доклады по SRE в разных компаниях. Первая – , это кейнот от Бена Трейнера из гугл. Вторая — . Третья опять же об . Четвертый доклад от , который имеет всего 5 ключевых SRE сотрудников на 190 стран. Очень интересно посмотреть на все это, потому что как DevOps значит очень разные вещи для разных компаний и даже разных команд, так и SRE имеет очень разный круг обязанностей, даже в компаниях схожих размеров.
Еще 2 ссылки по принципам chaos ingeneering: , . И в конце есть 3 списка из серии Awesome Lists про , про и про . Список по SRE невероятно огромный, не обязательно проходить его весь, там порядка 200 статей. Очень рекоменую оттуда статьи про capacity planning и про blameless postmortem.
Интересная статья:
Спасибо, что слушали меня все это время. Надеюсь, что вы чему-то научились. Надеюсь, что у вас есть достаточно материалов, чтобы научиться еще большему. И до встречи. Надеюсь в феврале.
Вебинар вел Эдуард Медведев.
PS: для тех, кто любит читать, Эдуард дал список литературы. Тех, кто предпочитает разбираться на практике, ждем на .
Источник: habr.com