Site Reliability Engineering - заметки по ходу чтения (Часть 2)
Антон РябовПредыдущие заметки (Часть 1) - https://telegra.ph/sre-book-notes-11-19
#36
Чтобы успешно справляться с авариями, в Google разработали свою систему управления в критических ситуациях, основанную на системе управления инцидентами (Incident Command System, ICS). Вот основные моменты этой системы:
Рекурсивное разделение обязанностей - каждый занимается своим делом и не заходит на чужую территорию. Если нагрузка на одного слишком большая, нужно запросить больше исполнителей (ДЕЛЕГИРУЙ!)
Роли работающих над инцидентом:
• управление - начальник штаба, контролирует весь процесс, распределяет обязанности, выполняет нераспределенные, устраняет препятствия мешающие оперативной группе.
• оперативная группа - непосредственно устраняют инцидент, только они могут вносить изменения, лидер оперативной группы, если такой есть/необходим, общается с начальником штаба
• информирование - лицо всей команды. Задача - держать в курсе происходящего всех.
• планирование - регистрация найденных ошибок, заказ обеда, планирование и организация передачи задач между исполнителями, отслеживание и фиксация аномалий в системе, чтобы исправить после разрешения инцидента
Выделенный центр управления - по возможности всех нужно собрать в одном месте. IRC помогает координировать и фиксировать события
Обновляемый документ о состоянии инцидента - начальник штаба должен вести документ об инциденте, в гугле все используют Google Docs, но сама команда SRE Docs использует Sites
https://landing.google.com/sre/sre-book/chapters/incident-document/
Четкая и оперативная передача полномочий
- сейчас ты управляешь инцидентом, понятно?
... остается на связи
- да
может быть свободен
Определите четкие условия для объявления инцидента
Например:
- необходимо привлечь вторую команду, чтобы решить проблему
- перебой в работе заметили клиенты
- проблема не решена после нескольких часов работы
#37
Практические рекомендации по управлению инцидентом
Расставляйте приоритеты - остановите развитие аварии, возобновите работу сервиса и сохраните данные для анализа истинных причин аварии
Готовьтесь заранее - разрабатывайте и документируйте методы управления инцидентами, согласовывая их со всеми участниками
Доверяйте - полная самостоятельность в рамках отведенных ролей
Используйте самоанализ - если паникуешь или перегружен запроси помощи
Рассматривайте альтернативы - пересмотр приоритетов задач
Практикуйтесь - применяйте подходы по управлению инцидентами постоянно, чтобы это вошло в привычку
Проводите ротацию - стимулируйте всех участников команды ознакомиться с каждой ролью.
#38
Культура постмортема, учимся на ошибках
Концепция "разбора полетов" и так называемого постмортема хорошо известна в индустрии высоких технологий.
Постмортем представляет собой письменный отчет об инциденте, его последствиях, действиях, предпринятых для его смягчения или устранения, его первопричине (или первопричинах), а также о последующих действиях для предотвращения его повторения.
Проведение "разбора полетов" и составления постмортема ожидается после любого значительного нежелательного события.
Это не наказание, а возможность научиться чему-то новому для всей компании.
Команды сами решают когда писать постмортем, но есть ситуация когда он необходим:
• обнаруженное пользователями время простоя или ухудшение производительности ниже определенного порога
• потеря данных любого типа
• потребовалось вмешательство дежурного инженера (откат изменений, перенаправление трафика)
• время разрешения ситуации превысило определенный лимит
• ошибка системы мониторинга (обнаружение инцидента пользователем или инженером)
Критерии составления посмотрем должны быть определены до возникновения инцидента, чтобы каждый понимал их, но также любая заинтересованная сторона может его затребовать для конкретного события.
Безобвинительный "разбор полетов" является краеугольным принципом для всей службы SRE. Эта культура берет начало в здравоохранении и авиации, где ценой ошибки может стать чья-то жизнь.
Нельзя "исправить" людей, зато можно исправить системы и процессы.
Тыканье пальцем: "бэкенд отстой, выходит из строя каждую неделю, если меня вызовут еще хотя бы раз, перепишу его сам"
Безобвинительный тон: "изменение бэкенда может предотвратить дальнейшее возникновение подобных ситуаций, будущие инженеры скажут вам спасибо"
Избегайте обвинений и будьте конструктивными.
#39
Продолжаем про постмортем, важное:
• шаблоны постмортем
• ведение всех постмортем в одной системе
• открытая система для комментариев
• уведомления
Оценка постмортем:
• собраны ли ключевые данные по инциденту для последующего исследования?
• является ли оценка влияния полной и завершенной?
• была ли найдена основная причина?
• целесообразны ли план действия и очередность последующих исправлений ошибок?
• поставлены ли заинтересованные стороны в известность о результатах?
Семинары для разбора постмортем - доводить до завершения дискусии, фиксировать идеи и придавать окончательный вид документам. Когда все довольны в архив его.
Etsy выложили свою систему для хранения постмортем - Morgue
Для воспитания культуры постмортемов:
• постмортем месяца - в рассылке распространяется наиболее содержательный и качественный постмортем
• группа Google+ посвященная постмортем
• книжные клубы по постмортемам - регулярные собрания, за освежающими напитками рассматриваются особенно интересные или значимые и ведется открытый диалог
• "колесо неудачи" - ролевая игра, в ходе которой разыгрываются события какого-либо постмортема. Новые SR инженеры часто проходят через это упражнение.
#40
Основатели Google Ларри Пейдж и Сергей Брин проводят TGIF (Thank God It's Friday)- еженедельные собрания сотрудников в прямом эфире с трансляцией в офисы Google по всему миру.
Одно из TGIF 2014 было посвящено теме "Искусство постмортема" и включало дискуссию SR-инженеров о событиях с серьезными последствиями.
Один из них залил обновление, которое вывело из строя важнейший сервис. Инцидент продолжался 4 минуты, потому что инженер не растерялся и немедленно откатил изменения. Этот инженер не только немедленно получил два партнерских бонуса в награду за быстрые и грамотные действия по разрешению инцидента, но и сорвал шквал аплодисментов на пятничном мероприятии, включая основателей и многотысячную аудиторию.
Глава про постмортем заканчивается, остается записать только, что в Google есть отдельная группа которая занимается посмортемами - улучшают шаблоны, помогают внедрить культуру и т.д. И буквально последнее предложение:
#41
Интересная штука в главе "Контроль неисправностей"
В Google сделали сервис, в который попадают копии всех алертов SR-инженеров. А затем, научили её проверять получил ли уведомление инженер и если нет, то отправлять оповещение по цепочке выше, и назвали эту систему Escalator. (Мы для этого используем VictorOps)
Затем они пошли еще дальше и сделали Outalator - штуку, в которую сваливаются все уведомления, где их можно группировать (в инцидент), промаркировать, смотреть по всем командам в одном месте и, например, прикрепить к письму при передаче дел, ну и конечно они там лежат как в архиве и в случае чего к ним можно обратиться, для анализа.
Плюсы Outalator'а:
• возможность определить что оповещения связаны с другим, уже известным сбоем (ускоряется диагностика, снижается нагрузка на другие команды)
• мониторинг количества инцидентов и фона алертов в разных командах и сервисах (помогает в принятии решений)
• "режим отчета" для периодических (обычно раз в неделю) проверок сервисов в эксплуатации
• можно увидеть, что команда, которую необходимо уведомить не была проинформирована и сделать это вручную
P.S. кстати недавно Monzo (UK-based банк нового поколения) заопенсорсили тулзу для управления инцидентами завязанную на Slack
#42
Тестирование - глава довольно скучная, пролистал по диагонали
Google пишет, что у них следующие виды тестирования:
• модульное (unit)
• интеграционное
• системное
Системное в свою очередь делится на:
• смоки - простые быстрые, показывающие что система работает
• перфоманс - что производительность не падает со временем
• регресссы - что ошибки которые были в прошлом не вылезут в будущем
Помимо этого, очень много внимания уделяется тестированию конфигураций, т.е. конфигов.
Конечно же у них есть нагрузочное и канареечное тестирование
Если SR-инженер подключается к проекту на этапе когда он уже реализован, но тестов нет совсем, какие тесты нужно писать? Покрывать все юнитами уже нет смысла и времени.
Чтобы определить что покрывать тестами, нужно ответить на следующие вопросы:
• можно ли каким-то образом выделить наиболее важное место в коде?
• существуют ли куски, которые отвечают за потребительский опыт (например биллинг)?
• есть ли API с которыми будут работать другие команды?
Инструменты разработанные в SRE так же нуждаются в тестировании как и другие программы.
#43
Так как SRE команда состоит в первую очередь из SWE эти ребята еще и код пилят. Чаще всего это внутренние сервисы.
В книге приводится пример с Auxon - системой для планирования производительности (Capacity planning) основанного на целях.
Суть в том, что в гугле устали от запросов «дайте столько-то ядер CPU” или «отсыпьте SSD дисков» и решили перейти к схеме, при которой product owner говорит «хочу чтобы сервис отвечал за 100ms вот в этом регионе». Все требования и лимиты загружаются в Auxon в виде конфигов, а тот выдает план распределения ресурсов.
Пилили они его два года, чтобы в итоге им могли пользоваться разные команды и переход был ненапряжный.
Цель это то, чем владелец сервиса аргументирует запрашиваемые для него параметры функционирования
Но речь вообще не об этом, а о том как и зачем SRE команда в гугле пишет софт. Продолжим в следующий вторник.
#44
Для SRE работа над долгосрочными проектами служит противовесом для дежурств и авралов. А также позволяет почувствовать удовлетворение от работы тем инженерам, которые хотели бы заниматься не только проектированием систем но и разработкой ПО.
Как запускать проект в SRE:
• четко сформулируйте задачу и доведите ее до сведения остальных
• оцените возможности вашей организации
• запускайте и дорабатывайте
• не занижайте стандарты
Социализация внутренних программных инструментов для крупной аудитории требует:
• понятного и неизменного подхода
• рекламы среди пользователей
• сотрудничества со стороны инженеров и менеджеров, которым вы будете демонстрировать полезность вашего продукта
Какой проект плохой кандидат?
• он связан с изменением слишком многих частей
• его дизайн требует подход "все или ничего"
• мешает выполнять разработку итерационно
Нельзя обещать слишком много, лучше MVP с постоянными патчами-доработками.
В любом достаточно сложном проекте разработки ПО обычно приходиться иметь дело с неопределенностью.
Просто запускайте свой продукт поскорее и дорабатывайте по ходу.
Проект должен разрабатываться без помех и перерывов. Подразумевается, что инженер, который, в данный момент работает над проектом, не должен участвовать в on-call ротации. Либо это должно быть грамотно распланировано.
#45
Мой отпуск закончился и, возможно, напишу что-нибудь о нем позже, но сейчас время заметок про балансировку нагрузки.
Естественно что балансировка нагрузки в Google начинается задолго до бэкенд серверов, еще на уровне DNS.
Промежуточные кеширующие DNS серверы сильно мешают балансировать запросы, поэтому Google постоянно мониторят известные промежуточные DNS серверы и размер их пользовательской базы. оценивают географическое расположение пользователей находящихся за каждым промежуточным сервером, чтобы направлять их в ДЦ с лучшим расположением.
Никаких деталей особо не раскрывается, кроме того что используется ipv4 + GRE. Про dns over https и ipv6 вообще ничего не упоминается.
Дальше идет балансировка на уровне фронтенд серверов, которые первым встречают пользовательский запрос, ближайший аналог - haproxy/traefik.
Для разных типов запросов - разное понятие оптимальности распределения.
Так для поисковых запросов выбирается ближайший доступный дата центр определяемый по RTT, чтобы минимизировать latency. А для видео, запрос отправляется на наименее загруженный узел, чтобы достичь максимальной пропускной способности.
После этого начинается балансировка в дата центре, заметки по которой будут в следующий раз.
#46
Балансировка в дата центре
Тут переводчики видимо чуть чуть поплыли и термины становятся странными. Короче есть прокси и бэкенды, прокси определяет на какой бэк отправить запрос. Бэкенд может быть в одном из трёх статусов:
• полная работоспособность
• отказ в соединение
• хромая утка - бэкенд может обслуживать запросы, но не хотел бы
Самое интересное тут, что бэкенд сам информирует прокси что он перешел в состояние хромой утки, чтобы они перестали присылать ему новые запросы.
Режим хромой утки также используется при обновлении кода:
1. в бэкенд прилетает SIGTERM
2. он говорит проксям отправлять новые запросы другим бэкендам
3. дорабатывает запросы которые уже пришли
4. и завершает работу
Google использует пул соединений между проксями и бэкендами, чтобы избежать проблемы слишком большого количества открытых соединений с одной прокси на бэкенды или с многих прокси на один бэкенд.
При этом у проксей есть ограничение, с каким количеством бэкендов они соединены и держат связь. Бэкенды распределяются по проксям согласно детерминированному алгоритму, для равномерной загрузки.
Если нет активности в течении некоторого времени, происходит переход с постоянного TCP соединения на UDP проверки.
Лучшим алгоритмом распределения **пользовательских запросов** по бэкендам Google считает Weighted Round Robin
P.S. Из-за кривости написания, я не разобрался в итоге речь про обратные прокси типа Nginx или прям про клиенты (web, mobile). Там то одно то другое. Например иногда говорится что клиент это Java приложение ¯\_[ツ]_/¯. Надо будет обратиться к оригиналу.
#47
Напоминаю, что мы говорим про балансировку пользовательских запросов.
Все запросы которые улетают на бэкенд имеют определенный уровень критичности. Один из четырех:
• CRITICAL_PLUS - наиболее критичные
• CRITICAL - стандартный уровень для прода
• SHEDDABLE_PLUS - ожидается частичная недоступность (например крон задачи, которыми можно пренебречь в данный момент, потому что потому они запустятся снова)
• SHEDDABLE - трафик для которого часто ожидается частичная или полная недоступность
В случае перегрузки, бэкенды троттлят запросы на основании этих уровней критичности.
В случае ошибки производится до 3 попыток запроса в бекенд, но процент повторных запросов должен быть не больше 10%.
Собирается статистика по повторам запросов, и бэкенд, если видит что другие бекенды тоже много отбрасывают, может вернуть ошибку "перегружен, не повторять", вместо "перегружен, попробуйте позже" чтобы снизить нагрузку.
#48
Почему нужно предотвращать перегрузку сервисов?
Итак, у нас есть сервис с нагрузкой 10 000 QPS. Сервис полностью работоспособен.
Нагрузка увеличивается до 11 000 QPS и начинается каскадный сбой.
В этом случае, снижение нагрузки до 9 000 QPS, скорее всего, не остановит процесс и чтобы стабилизировать систему, придется снимать нагрузку полностью и потом ступенчато её возобновлять.
Как можно предотвращать перегрузку сервисов?
Можно отбрасывать часть запросов - это называется троттлинг (которые в книге, почему-то, перевели как сегментация)
А можно начать мягкую деградацию. Деградированные результаты - это низкокачественные результаты, но более дешевые для вычисления.
#49
В книге разделяются понятия "таймаут" и "дедлайн", не совсем понял почему так. Лично я привык звать это все таймаутами.
Дедлайном они называют время, до которого какой-либо сервис ждет ответа. Ну, т.е. таймаут :)
Из интересного, решил записать про распространение дедлайнов. Их легко объяснить на примере:
Дедлайн на фронте 30 секунд - запрос прилетает в бекенд А и выполняется 7 секунд, после чего бекенд А делает запрос в бекенд Б с дедлайном 23 секунды, бекенд Б выполняет запрос 12 секунд и отправляет запрос в бекенд В с дедлайном 11 секунд и т.д.
Если дедлайны в сервисах будут больше чем дедлайны, которые стоят раньше, то наши бекенды будут делать работу, которая уже ни кому не нужна.
Далее следует глава 23 "Разрешение конфликтов: Консенсус в распределенных системах"
Для меня ничего нового, в главе было очень много про Paxos и пару раз упоминаются Zab и Raft.
При этом в Etcd и Kubernetes используется Raft
- ситуация выбора лидера
- критическое разделяемое состояние
- распределенные блокировки
- задачи для распределенного консенсуса, любой другой подход будет напоминать бомбу с часовым механизмом, готовую разрушить ваши системы
#50
Глава "Cron: планирование и расписание в распределенных системах"
Лучше пропустить запуск задачи чем запустить её два раза (например e-mail рассылка или пересчет ЗП)
Владельцы задач должны наблюдать за своими задачами
Хранение информации о состоянии задач:
- во внешнем хранилище (GFS или HDFS)
- внутри сервиса cron
Google выбирает 2 вариант, потому что 1 это большая задержка и зависимость от глобального сервиса.
Несколько реплик сервиса cron достигают консенсуса по Paxos. Только лидер Paxos является лидером cron и может изменять состояние, запускать задачи и уведомлять фоловеров о статусе. Лидер сообщает фоловерам о том, что запустил или завершил задачу синхронно, чтобы избежать повторного запуска при смене лидера.
#51
Выполнение cron задачи в гугле это запуск контейнеров в k8s и их убийство, когда задача выполнена.
Т.е. в случае, когда лидер запустил задачи, потом упал или стал недоступен, кто-то из фолловеров становится лидером и должен завершить задачи запущенные предыдущим лидером или дозапустить если тот успел не все.
Успешно запустив задачу, cron планирует время следующего запуска этой задачи.
Paxos это по сути журнал изменений состояния, они хранят его (журнал) на локальном диске, периодически делают снимки и копируют в распределенное хранилище. Новый фолловер может вытянуть данные по сети.
Удостоверьтесь что ваши команды не запланировали задачи cron на запуск в одно и тоже время.
Можно использовать нотацию распределенного запуска (например разработчик указывает что запустить нужно с 23 до 0 часов) а система cron сама решает в какую конкретно минуту какую задачу запустить.
На этом все про Cron задачи, добавлю что, на данный момент, мы в OneTwoTrip используем https://github.com/onetwotrip/shaker
#52
Глава "Конвейеры обработки данных"
Google Workflow - система позволяющая масштабировать продолжительную обработку данных. Использует шаблон "Лидер - фоловер (или воркер)" и шаблон системного преобладания. Эта комбинация позволяет создавать крупномасштабные транзакционные конвейреы, гарантируя корректность благодаря семантике exactly-once.
Workflow использует MVC
Модель находится на сервере - мастере задач, который держит в памяти состояние всех задач а синхронные изменения сбрасывает на диск.
Представление - это воркеры, которые меняют стейт транзакционно через мастер, но сами его не хранят, поэтому могут быть удалены в любой момент.
Kонтроллер - опциональный компонент, который обеспечивает масштабирование конвейра во время работы, получение снимков, откат состояния и т.д.
#53
Воркеры в главе упорно называют работники, что режет мне слух ... или глаз
4 гарантии корректности для Workflow:
- результат работы воркеров с помощью конфигурационных задач создает барьеры, на которых основывается работа (что это блин значит!)
- фиксация выполненной работы требует наличия у воркера аренды, действительной в данный момент
- воркеры дают выходным файлам (с результатами работы) уникальные имена (зачем вообще использовать файлы?)
- клиент и сервер проверяют правильность мастера задач путем проверки токена сервера в каждой операции
Непрерывность работы Workflow достигается за счет использования глобальных Workflow, которые управляют локальными Workflow в разных ДЦ, в которых уже выполняются задачи.
Дальше идет глава про сохранность данных и там интереснее.
#54
Глава "Cохранность данных: как пишется так и читается"
Для пользователя доступность сервиса и доступность данных это почти одно и тоже.
Если Gmail открывается, но писем нет, он все равно считает что Gmail не работает.
Допустим файл был поврежден, мы это заметили, исправили его и вернули к исходному состоянию. На все про все, ушло 30 минут. Если это был единственный простой с этим файлом, его доступность за год составит 99,99%.
Но, с точки зрения пользователя, если он не обращался за файлом во время повреждения и восстановления, доступность будет 100%.
Это и есть секрет исключительной сохранности данных - упреждающее обнаружение проблем и быстрое восстановление.
Никто не хочет делать резервные копии, но все хотят восстановления данных.
В случае аварии, данные должны быть быстро восстановлены из резервной копии. В случае если восстановление занимает долгое время это архив а не резервная копия.
Создавать нужно систему восстановления, а не систему резервного копирования.
Должен быть SLO для "сохранности данных" при разных типах неисправностей.
#55
24 вида сбоев.
Сбои, которые ведут к потере данных имеют три компонента (наверное любой сбой в принципе имеет такие компоненты):
- Основная причина: действие пользователя, ошибка в работе, ошибка приложения, дефект инфраструктуры, сбой оборудования, авария на площадке
- Масштаб: широкий , узко-направленный
- Уровень: большой взрыв, медленный и постепенный
Репликация не защищает от множества способов потерять данные.
Сохранность - показатель, как долго вы храните копии данных. Если потеря данных постепенная, то заметите вы это не сразу.
Глубокая защита от потери данных в Гугле.
Три слоя:
- Мягкое (ленивое) удаление
- Резервные копии и методы их восстановления
- Проверка данных
#56
БОльшая часть случаев хищения учётных записей и проблем с целостностью данных обнаруживаются в течение 60 дней.
Гугл рекомендует срок хранения резервных копий от 30 до 90 дней.
Должно быть несколько слоев создания резервных копий.
Первый - большое количество копий, хранятся максимально близко к работающим хранилищам и с помощью которых можно быстро выполнить восстановление.
На втором и последующих уровнях, снижается количество копий, отдаляется сторадж и увеличивается время восстановления.
*Валидаторы данных* это конвейеры на базе mapReduce или Hadoop которые пишут сами разработчики сервисов.
Система проверки данных должна предоставлять дежурному инженеру всю необходимую документацию и инструменты поиска проблем.
Если каждая команда будет заниматься реализацией системы проверки данных, они не будут успевать пилить фичи.
Можно выделить специальную инфраструктурную команду, которая разработает фреймворк проверки данных для остальных команд, которые пилят продукты.
Нужно постоянно тестировать восстановление из резервных копий. Важен не только факт восстановления, но и целостность данных а также время восстановления (оно должно быть адекватным) и готовность инфраструктуры.
Алерт на удаление большого количества данных. Например 10х от 95 перцентиля.
#57
Глава 27 - надежный масштабируемый выпуск продукта
В гугле постоянно запускаются проекты, какие-то новые с нуля, какие-то новые версии уже существующих, специальные проекты и так далее. Чтобы не наступать на одни и те же грабли из SR-инженеров выделили команду Launch Coordination Engineers - LCE, которые занимаются только запуском проектов.
В течение 3,5 лет один LCE проводил 350 запусков, поскольку команда в среднем из 5 человек это более 1500 запусков.
Чтобы облегчить себе жизнь LCE используют чек-листы (по аналогии с пилотами и хирургами).
- Они проверяют продукты и сервисы на соответствие стандартам надежности гугла, а также дают советы и рекомендации как увеличить надежность.
- Действуют как посредники между несколькими командами, участвующими в запуске
- Управляют техническими аспектами и гарантируют стабильность и надежность запуска
- Обучают разработчиков лучшим приемам и способам интеграции с другими сервисами, обеспечивая документацией и практическими упражнениями
Качества необходимые LCE инженеру:
- широта опыта (внутренних продуктов и пошареных ресурсов)
- кросс-функциональная перспектива
- объективность
#58
Критерии определяющие удачный запуск:
- простота для разработчиков
- продуманность - обнаружение очевидных ошибок
- доскональность - решаются наиболее важные проблемы
- масштабируемость - выполняется как большое количество простых запусков так и небольшое сложных
- адаптируемость - процесс налажен для разных видов запусков - добавление новой локали или запуск полностью нового продукта
Чек-лист состоит из пунктов, в каждом есть вопрос и действие. В случае если ответ на вопрос положительный, нужно выполнить действие. Например:
Вопрос: нужно ли вам новое доменное имя?
Действие: поговорите с маркетингом о том, каким должно быть желаемое доменное имя и запросите регистрацию "вот ссылка на форму маркетинга"
Вопрос: сохраняете или вы устойчивые данные?
Действия: реализуйте ограничение скорости и квоты. Используйте следующий разделяемый (shared) сервис.
Размер чек-листа удерживается, чтобы быть адекватным, но может быть изменен для конкретного запуска.
Также, на сколько я понял, в ведомстве LCE находятся "фреймворки" канареечного применения функциональности. Которые позволяют раскатывать новые фичи ступенчато, сначала на малое количество пользователей, потом на большее и так далее.
LCE пока не решили:
- бюрократия
- проблемы масштабируемости после запуска (переписывание инфры проекта с нуля)
- рост операционной нагрузки
- текучка инфраструктуры
Продолжение (Часть 3) - https://telegra.ph/sre-book-notes-01-21-2
Материалы блога doam.ru #SRE #Book #SRETuesday #Doamru