Site Reliability Engineering - заметки по ходу чтения

#1

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

Сейчас она появилась в библиотеке на работе, взяв её несколько дней назад и, читая только в метро два раза в день по 10-15 минут, я дошел до 100 страницы, что, на данный момент, наилучший результат. 

Начнем с того, что в русской версии 580 страниц, 34 главы + приложения и куча отсылок, как к другим книгам O'Reilly, так и к сайтам в интернете. Добрые 30 страниц занимают предисловия и благодарности. 

В отличие от The Phoenix Project, которая является художественным произведением, SRE скорее учебник, в котором теория сразу же объясняется на практике. Да и вообще вся книга это сборник статей от разных сотрудников Google, что, как я успел заметить, приводит к дублированию некоторых вещей в разных главах. 

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

#2

"Надеяться - это плохая стратегия."

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

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

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

SR-инженеры, это в первую очередь разработчики. Рутина не должна превышать 50% времени их работы. Это строго мониторится и если такое происходит, то либо часть операционки передается SWE (разработчикам), либо разработчики добавляются в команду SRE, но без операционной нагрузки. 

#3

Каждый продукт должен иметь установленный целевой показатель доступности. Это не полностью технический вопрос, он должен определяться в диалоге с бизнесом. Допустим, мы установим целевой показатель доступности в 99,99%, тогда 100% - 99,99% = 0,01% допустимый уровень недоступности сервиса или бюджет ошибок. 

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

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

#4

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

Пример из опыта Google: инфра сервис Chubby (аналог ETCD) используемый для блокировок, работал без сбоев, и разработчики привыкли, что он не падает. Когда он наконец-то упал, сервисы жестко на него завязанные, были полностью недоступны. Выяснилось, что разработчики на столько привыкли к его стабильности, что не задумывались о ретраях и реконнектах. 

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

#5

Занимаясь операционными задачами, каждый SR-инженер, как правило, получает не более двух событий за 8-12 часовую смену. Такой объем работы дает возможность быстро и точно обработать событие. Больше - выгорание, меньше - зачем тогда SRE вообще нужно этим заниматься? 

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

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

#6

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

3 категории данных от системы мониторинга: срочные оповещения (алерты), запросы на действия (тикеты), журналирование (логи). 

Надежность это функция от среднего времени безотказной работы (mean time to failure, MTTF) и среднего времени восстановления (mean time to repair, MTTR). 

Три приема чтобы эффективно ограничивать общее количество сбоев:

• обеспечить поэтапное развертывание обновлений
• быстро и точно выявлять проблемы
• безопасно откатывать изменения при проблемах 

#7

Из интересного про железо гугла. 

Все дата-центры устроены одинаково. Машины не выделяются под конкретные задачи, они все вводятся в кластер Borg (Kubernetes), который уже решает где что запустить. 

Для поддержки высокой пропускной способности сети между машинами внутри ДЦ, Google использует собственные свитчи, которые управляются виртуальным коммутатором. Все это дело называется Jupiter (1,3 Пб/c) и построено на топологии Клоза. 

Дата-центры соединены между собой по OpenFlow c помощью глобальной магистральной сети B4. 

Для роутинга используются глупые коммутаторы в сочетании с центральным контроллером, который заранее вычисляет лучший маршрут сети. 

Bandwidth Enforcer (BwE) управляет доступной полосой пропускания, а Global Software Load Balancer, GSLB выполняет балансировку на трех уровнях:

• географическую для DNS-запросов
• балансировку на уровне пользовательских сервисов (YouTube, Google Maps и т.д.)
• балансировку нагрузки на уровне RPC

#8

Архитектура Borg это прям K8s, а вот файловое хранилище заинтересовало. 

Если я правильно понял, диски всех машин, объединены в одну большую файловую систему (Colossus) и её используют разные storage провайдеры - Bigtable петабайтный NoSQL, Spanner SQL-подобный интерфейс или простой Blobstore. 

Задачи, запускаемые c помощью Borg, делятся на одноразовые (типа mapReduce, но их может быть очень много) и серверы (т.е. работающие в лупе). 

Глобальный сервис Chubby используется для блокировок (выбор мастера например или лок задачи). 

Все сервисы общаются с помощью инфраструктуры RPC, которая называется Stubby (gRPC), внутри protobuf. 

Весь код, всех проектов лежит в едином репозитории (ОН ГИГАНТСКИЙ).

#9

Все сервисы на каждый запрос ломятся в Global Software Load Balancer. DNS сервер идет в балансер, чтобы знать в какой прокси сервер отправлять, тот в свою очередь чтобы узнать в какое фронтенд приложение, которое в свою очередь идет опять в балансер чтобы знать где бекенд и т.д. 

Количество запущенных задач (инстансев приложения) должно быть N+2, во время обновления одна будет в дауне, а одна может упасть, тогда останется N - что есть минимум для обработки пиковой нагрузки. 

#10

В классическом случае, доступность рассчитывается по формуле: 

Т.е. для требуемой доступности 99,99, время возможных отключений будет 52,56 минут, если брать период год. 

Google не очень нравится использовать такой расчет доступности. Для их задач больше подходит доля успешных запросов в рамках одного дня. Формула расчета:

Если в день 2,5 миллиона запросов и требуемая доступность 99,99, допустимо терять из-за сбоев 250 запросов. 

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

Уровень доступности устанавливается для квартала, а отслеживается еженедельно или ежедневно.

# заметка между заметками

Неважно каким способом мы измеряем доступность сервиса, обозначать её принято в процентах. Максимальная доступность любого сервиса 100%. 

Требуемая доступность у всех сервисов разная, но зачастую это что-то вроде 99,99% или 99,999%. 

Так как произносить это слишком долго и непонятно. Мы говорим просто 4 девятки или 5 девяток и т.д.

#11

Стоимость cистемы при повышении надёжности растет нелинейно - след. шаг повышения надёжности может стоить в 100 раз больше предыдущего. Две составляющие этой стоимости:

• Стоимость избыточных вычислительных ресурсов
• Cтоимость упущенных возможностей (инженеры не пилят фичи)

Покрывает ли дополнительная прибыль затраты на достижение нового уровня надёжности ? 

Что лучше для сервиса постоянные короткие сбои или редкие но долгие?

#12

Понятия успешного функционирования системы и её отказа для разных групп пользователей/сервисов могут быть разными. 

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

Менеджер продукта определяет SLO, задавая тем самым время бесперебойной работы в течение квартала 

Реальное текущее время бесперебойной работы измеряется нейтральной стороной - системой мониторинга.

Разница между этими числами является запасом (бюджетом)

Пока доля времени бесперебойной работы больше времени, заданного SLO, можно продолжать выпуск новых версий и изменения. 

#13

Сегодня начинается очень интересная для меня тема - SLI/SLO/SLA. В книге они достаточно детально формализованы и показаны на примерах. 

SLI, Service Level Indicators - показатели (индикаторы) уровня качества обслуживания

SLO, Service Level Objectives - целевые показатели. Целевые уровни качества обслуживания. 

SLA, Service Level Agreements - соглашения

#14

SLI - четко определенное числовое значение конкретной характеристики. 

Чаще всего это: 

• время отклика или латентность системы, ms

• уровень или частота ошибок, % от общего числа запросов

• пропускная способность системы, RPS/QPS

• доступность - доля времени когда сервис можно использовать

#15

SLO - целевое значение или диапазон значений, измеряемые с помощью SLI.

Как я понял что такое SLO:

Допустим, мы установили SLI - процент 5xx ошибок, SLO будет - процент 5xx ошибок не должен превышать значение в 2%.

Для SLO стоит уточнять измеряемый период (окно). 

#16

SLA - явный или неявный контракт с вашими пользователями, включающий последствия, которые влечет за собой соответствие (или несоответствие) требованиям SLO. 

Простой способ понять разницу между SLO и SLA, ответить на вопрос:

Если явных последствий не существует, то, скорее всего, перед вами SLO. 

SLA относится к бизнесу, в то время как SRE инженеры занимаются SLI и SLO. 

#17

Работать с перцентилями лучше чем со средним арифметическим. 

Среднее арифметическое и медиана, обычно имеют разные профили. 

SLO должны содержать инфо. о том, как их измерять, а также условия, при которых они действительны. Пример:

99% вызовов RPC Get будут завершены менее чем за 100 милисекунд

Суммарный уровень ошибок - это SLO, отражающий соответствие другим SLO!

По SLO должен вестись ежемесячный или ежеквартальный отчет. 

#18

Советы по выбору SLO:

• не выбирайте цель, основываясь на текущей производительности

• не усложняйте

• не гонитесь за абсолютом

• имейте минимальное количество SLO

• идеал может подождать

Хорошо построенные SLO - полезный фактор воздействия на команду. 

Плохо продуманные SLO, могут привести к пустой трате рабочего времени. 

#19

Чтобы ожидания пользователей были реалистичными, нужно использовать тактики:

• имейте запас прочности (внутренние SLO жестче, чем внешние)
• избегайте перевыполнения (история с Chubby)

Чем шире будет круг ваших пользователей, тем сложнее будет изменить/удалить необоснованные или трудновыполнимые SLA. 

#20

Пожалуй пропущу заметки по скучной организационной теме и перейду к мониторингу. 

Что входит в мониторинг:

• Мониторинг белым ящиком

• Мониторинг черным ящиком

• Дашборды

• Алерты (тикеты и вызовы)

Что дает мониторинг:

• Анализ долгосрочных тенденций

• Сравнение метрик в экспериментах

• Оповещение

• Дашборды

• Ретроспективный анализ 

Observability man - человек ответственный за мониторинг, алерты и дашборды.

Алерт должен давать ответ на два вопроса:

• Что сломалось? - симптом

• Почему? - причина

#21

4 золотых сигнала - если вы можете измерить для системы только 4 показателя, сконцентрируйтесь на этих:

• время отклика. задержка для успешных и неуспешных запросов
• величина трафика. для веб-сервиса - количество HTTP запросов в секунду, для системы потокового аудио/видео - скорость/объем передачи данных по сети или количество параллельных сессий, для K/V стораджа - количество выполненных транзакций и возвращенных значений за секунду и т.д.
• уровень ошибок. error код, успешный код но с пустым результатом и успешный код но недостаточно быстро это все ошибки
• степень загруженности - CPU, Memory, IO, Network. Многие системы теряют в производительности еще до того, как будут загружены на 100%

Если вы можете измерить все четыре сигнала и сообщать пользователю если один из них обнаруживает проблему, ваш мониторинг можно считать удовлетворительным. 

#22

Ну и последнее, на данный момент, по теме мониторинга.

• Измерение 99-го перцентиля времени отклика в минуту - предупреждение о перегрузке. 
• Важно иметь прогнозы достижения целевого уровня, например, "База заполнит диск через 12 часов".
• Гистограммы должны строиться с логарифмическими границами. Например время ответа от 0 до 10, от 10 до 30, от 30 до 100, от 100 до 300 и т.д.
• Усреднение (average) может быть принятием желаемого за действительное, нужно использовать медианы и перцентили. 
• Правила, которые определяют аварии, должны быть максимально простыми, предсказуемыми и надежными. 
• Избавьтесь от частей системы мониторинга, которые используются редко.
• Показатели, которые система не выводит и не использует в алертах - кандидаты на удаление.

#23

Прохладная история про автоматизацию. 

Google управляет ресурсами на уровне стоек (в одной стойке могут быть десятки серверов), и процесс ввода новых и вывода ненужных полностью автоматизирован. 

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

Но на этот раз сценарий получил пустой список серверов для работы (так как они уже были очищены) и решил (ВНИМАНИЕ!) что нужно обработать все серверы в этом ДЦ.

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

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

Восстанавливали серверы несколько дней, а потом еще две недели искали и исправляли ошибку. 

Но в большинстве случаев автоматизация все таки полезная штука, даже если размер вашей компании не уровня Google.

#24

Я прочитал главу "Выпуск ПО". Не знаю, может быть тема CI/CD, при всей её простоте, уже слишком заезжена, а может быть я уже все это знаю, но глава показалась скучной. 

Если говорить в двух словах, то у них там куча самописного ПО, для сборки и доставки, но пару заметок я все таки запишу. 

К их монорепозиторию подключен CI, который билдит все теги (веток там нет), а дальше работает CD. 

4 основных принципа CD от гугла:

• Самообслуживание
• Скорость
• Герметичные сборки
• Политики и процедуры контроля доступа

Любят они, по ходу, цифру 4

#25

• Rapid - система управления релизами
• Blaze (Bazel) - сборка
• Midas - менеджер пакетов (собранные пакеты называются MPM пакеты)
• Sisyphus - универсальный фреймворк для автоматизации

Флоу получается примерно такой:

Деплой на прод, естественно, Canary, т.е. потихоньку, сначала на малый процент пользователей, потом больше, еще больше и так далее. 

#26

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

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

1. конфиги в репозитории - релиз кода отдельно, изменение конфигов отдельно
2. включение конфигов в MPM пакет с бинарем - релиз конфигов вместе с исполняемым кодом
3. сборка конфигов в отдельные конфигурационные пакеты MPM - независимый релиз кода и конфигов, но можно создать зависимость
4. конфиги во внешнем хранилище (Chubby, Bigtable или файловой системе (Kemper))

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

#27

II часть книги - "Принципы", заканчивается главой "Простота", таким себе набором цитат и капитанских фраз. 

Сложные системы (ПО в частности) по своей природе динамичны и нестабильны. 

SR-инженеры стараются создавать надежные инструменты, гарантируя что их работа будет минимально влиять на гибкость разработчиков. Таким образом их работа, это соблюдать баланс между надежностью и гибкость. 

Существует органичная (естественная) и неорганичная (случайная) сложность. Первая возникает в силу необходимости и с ней ничего нельзя сделать, а от второй нужно избавляться. Трюк в том, чтобы понять, что перед тобой неорганическая сложность. 

#28

Поддерживая веб-сервис c доступностью 24/7 вы несете ответственность за каждую новую строку кода. Нужно гарантировать что весь код следует исходной цели. Можно использовать следующий приемы:

• анализ кода
• удаление "мертвого" кода
• автоматическое обнаружение "разбухания" кода  

Минимальные API - чем меньше методов и аргументов в API, тем проще с ним работать

Модульность - одно API не обязательно должно состоять из одного исходного файла (сервиса), иначе со временем это будет "солянка".

Простые релизы - чем меньше изменений в релизе, тем легче определить что привело к проблемам, более быстрые тестирование и деплой и т.д.

#29

Начинается тема про дежурства или как говорят в гугле "пейджер"

Prometheus очень похож на Borgmon - что не удивительно, так как он был вдохновлен гугловым мониторингом. 

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

Самый первый Borgmon держит метрики за 12 часов, и это примерно 17 Гб в памяти. Данные старее 12 часов перекладываются в другой Borgmon а из него в третий и в итоге в TSDB. Собственно Prometheus предлагает такое же решение для долгосрочного хранения. 

Знаю что в крупных русских компаниях, типа Avito и Mail.ru, перекладывают метрики в другие стораджи, такие как Graphite. 

Также у гугла есть unit и регрессионные тесты для конфигурации Borgmon, перед применением к проду. 

#30

С тех пор как речь пошла о дежурстве и мониторинге в книге постоянно упоминается система временных рядов для хранения метрик и я не сразу вкурил что "Питер" так перевел time-series database. Но вернемся к заметкам поважнее. 

В пейджере всегда есть приоритетность:

• самое критичное - сразу дежурному

• важное, но не критичное - дежурному, но через тикет

• все остальное - просто на монитор.

Существуют первая и вторая очереди дежурств. Есть разные варианты организации: либо первая решает ASAP'ы, вторая тикеты (сплит по типам), либо если первая не справилась за какое-то время, то передается второй (эскалация по времени).

Работа SRE состоит из разных частей: 

• 25% дежурство 

• 25% другая работа (списывание времени, митинги, написание отчетов и документации и т.д.)

• 50% инжиниринга

Сохранять эти проценты очень важно. Дежурство и рутина наносят определенный урон инженеру, в книге просто упоминаются гормоны кортизол и КРГ, поэтому я поискал немного информации и вот пара цитат. 

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

В целом действие КРГ на ЦНС сводится к усилению реакций активации, ориентировки, к возникновению тревоги, страха, беспокойства, напряжения, ухудшению аппетита, сна и половой активности. При кратковременном воздействии повышенные концентрации КРГ мобилизуют организм на борьбу со стрессом. Длительное воздействие повышенных концентраций КРГ приводит к развитию состояния дистресса — депрессивного состояния, бессонницы, хронической тревоги, истощению, понижению либидо.

#31

Важнейшие ресурсы для дежурного :

• хороший менеджмент 

• процедуры обработки инцидентов 

• безобвинительная культура написания отчётов 

Если процедуры обработки инцидентов зафиксированы в специальных протоколах (базе знаний, например), работа дежурного облегчается, Time To Recover снижается, меньше стресса у дежурного, больше стабильности сервиса. 

Эвристика соблазнительное зло. Например: сервис перестал отвечать на запросы, на прошлой неделе было такое же поведение из-за перегрузки CPU, значит и в этот раз тоже самое.

Если приложение стало "шуметь" SRE команда может передать пейджер SWE команде, до момента пока они с этим не разберутся.  

Если операционной работы нет, надо проводить учения. Например, "Колесо не удачи" о котором, видимо, будет рассказано позднее.

Стресс-тест для всей компании "DiRT - disaster recovery training" 

#32

Для диагностики и решения проблем стоит применять гипотетико-дедуктивный метод.

1. изучить отчет об ошибке, проверить результаты телеметрии и логи
2. зная как построена система и как она реагирует на ошибки выдвинуть предположение
3. проверить предположение, если не помогло, вернуться на шаг 1

Могут быть подводные камни:

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

#33

Что-то я задержался с SRETuesday, и публикую его в среду. Продолжаем говорить про пейджер и приближаемся к тому, что делать во время аварии

В идеальном случае, авария начинается с отчета об ошибке (по простому алерта), а идеальный отчет об ошибке содержит в себе следующую информацию:

• ожидаемое поведение 

• реальное поведение 

• способ воспроизведения 

Для расследования аварии можно использовать следующие инструменты:

• мониторинг

• трассировка запросов

• журналы

Как уже было сказано,

для мониторинга Google использует Borgmon (Prometheus)

Для трассировки запросов Dapper

Журналы (логи) - это текстовые, пригодные для чтения человеком данные системы. И относительно логов, Google дает следующие рекомендации:

• полезно иметь несколько уровней их детализации и возможность повышать или понижать уровень по мере надобности, на лету, не нарушая работу сервиса

• должны позволять изучить любую операцию без перезапуска процесса

• в зависимости от объема трафика, может быть полезно использовать "прореженную" выборку логов, например протоколировать не все, а каждую тысячную операцию

#34

Итак, что-то я совсем забыл про__ **SRETuesday**, __а вы меня и не пинаете. Продолжаем про дежурство и диагностирование проблем.

Упрощайте и сокращайте (декомпозируйте систему)

Как диагностировать сложную многосвязную систему?

Есть два варианта: 

• двигаться по цепочке с одного конца к другому, например:

от клиента к балансировщику, от балансировщика к веб-серверу, от веб-сервера к бекенду, от бекенда к базе и т.д.

но это может быть слишком долго

• делить цепочку пополам, проверять какая половина не работает и делить уже её пополам и повторять пока не найдешь неработающий компонент

Что, где и почему

Сбоящая система все еще пытается работать и что-то делает, но не то что нужно. Нужно выяснить ЧТО именно она делает, ПОЧЕМУ это происходит, ГДЕ расходуются ее ресурсы и КУДА направляются результаты. Все это может помочь в понимании что пошло не так.

Тут книга отсылает нас к 5 почему Таичи Оно

Какое воздействие было последним?

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

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

Детализация и логирование изменений и взаимодействий

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

#35

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

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

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

Для подтверждения диагноза:

• результаты тестов должны быть взаимоисключающими

• проверяйте в первую очередь очевидные вещи

• результаты эксперимента могут ввести в заблуждение (порт открыт для IP, коннект к базе с локали не прокатит)

• активное тестирование может привести к побочным эффектам

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

Как облегчить решение проблем?

• максимум наблюдаемости (observability) - белый ящик, логи и т.д.

• разрабатывайте системы с предельно понятными и наблюдаемыми интерфейсами между компонентами

• храните историю перебоев в работе с шагами исправления, убедитесь что у всех есть к ним доступ

• постоянно задавайтесь вопросом "а что если?" (например: а что если редис упадет?)

Отрицательный результат важен!

Например: одна команда протестировала библиотеку и выяснила что у нее есть недостатки, запомнив это, другая команда может не тестировать данную библиотеку, а сразу использовать другую

Продолжение (Часть 2) - https://telegra.ph/sre-book-notes-05-07

Материалы блога doam.ru #SRE #Book #SRETuesday #Doamru