Site Reliability Engineering - заметки по ходу чтения (Часть 3)

Предыдущие заметки (Часть 1) - https://telegra.ph/sre-book-notes-11-19

Предыдущие заметки (Часть 2) - https://telegra.ph/sre-book-notes-05-07

#59

Вы наняли новых SR-инженеров, что теперь? 

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

Для обучения новичка нужно знать ответы на вопросы:

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

Люди разные и ни одна методика обучения не подойдет ко всем новичкам. Поэтому гугл дает "приемы" обучения SR-инженеров. Рекомендованные методы и антиметоды: 

• Метод: разработка конкретных последовательных упражнений
• Антиметод: поручение низкоквалифицированной работы

• М: стимулирование к реверс-инжинирингу
• А: обучение с помощью операционных процедур, чек-листов и сценариев

• М: мотивация к анализу через чтение постмортем
• А: сокрытие информации о сбоях

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

• М: имитация катастроф, для тренировки работы в команде
• А: создание в команде экспертов

• М: теневое дежурство (и сравнение их заметок, с заметками дежурного)
• А: назначение новичка полноценным дежурным

• М: эксперты вместе с новичками проходят план (или его части) обучения
• А: рассмотрение планов обучения как неизменных и неприкосновенных для всех кроме экспертов

• М: обособление нестандартной работы над проектом для выполнения учениками
• А: предоставление всей работы над новыми проектами только самым опытным

#60

Постарайтесь упорядочить систему обучения. 

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

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

Для качественного обучения полезна целевая, а не черновая работа над проектом. 

SR-инженеры должны иметь характерные особенности:

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

Для тренировки дежурных, гугл использует разные игры, названия некоторых:

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

#61

Глава 29 - справляемся с отвлекающими факторами и прерываниями 

Состояние когнитивного потока

SR инженер Фред приходит на работу, он не дежурный, делает себе кофе, надевает наушники марки "не беспокоить" и садится работать над своими проектами.

• Прилетает асап тикет 
• Коллега дёргает по компоненту, в котором Фред разбирается больше
• Дёргают по тикету, который завели в его прошлое дежурство 
• Релиз с кодом Фреда не собирается, надо проверить/поправить/откатить

В итоге Фред не смог сосредоточиться на своих задачах.

20 минутное прерывание это минимум два переключения контекста и потеря нескольких часов действительно продуктивной работы.

Как избежать? 

Распределение времени между разными видами работы - концепция потерянного времени (это вольный перевод от Питера в русском варианте книги, советую ознакомиться с оригиналом - http://paulgraham.com/makersschedule.html)

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

#62

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

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

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

Фаза 1: изучаем сервис и рабочее окружение

Фаза 2: делимся контекстом

Фаза 3: навязываем изменения

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

Про каждую из фаз чуть подробнее в следующих заметках.

#63

Фаза 1: изучаем сервис и рабочее окружение

• знакомимся с командой и задачами
• определяем главные источники стресса
• определяем очаги возгорания:

• пробелы в знаниях
• сервисы разработанные SR-инженерами, важность которых повышается
• игнорирование проблемы из-за веры, что новое решение, которое скоро будет реализовано, устранит все недостатки
• алерты на которые не реагируют ни разработчики, ни SR-инженеры
• SLI/SLO/SLA
• сервис чей план производительности - "добавьте еще серверов, у нас ночью память кончилась"
• постмортемы, которые рекомендуют откат изменений
• любой критически важный компонент, на вопросы о котором SR-инженеры отвечают "мы ничего о нем не знаем, им владеют разработчики"

#64

Фаза 2: делимся контекстом

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

два вида перегрузок:

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

Разделите перегрузки на рутину и не рутину и предоставьте этот список команде и четко объясните, в каком случае работу нужно автоматизировать, а в каком это допустимая ситуация. 

#65

Фаза 3: навязываем изменения

Добиться здоровых отношений в команде непросто. 

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

Начните с основ - SLO. 

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

Обосновывайте свои аргументы

Задавайте наводящие вопросы (но не вопросы с подвохом)

#66

Глава 31. Общение и взаимодействие в службе SRE

Данные (информация о проектах, состоянии сервисов, систем и отдельных элементов) должны протекать через всю действующую систему, они же должны течь через команду SR-инженеров.

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

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

Производственные совещания: 

• 1 раз в неделю
• 30-60 минут
• SR-инженеры доносят информацию о состоянии сервиса, за который отвечают
• повестка дня - грядущие изменения
• показатели 
• сбои
• события по экстренным алертам
• предыдущие действия
• и т.д. 

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

Формально, команды SR-инженеров, имеют в составе:

• технического лидера - tech lead / TL
• менеджера - manager/SRM
• проектного менеджера - PM/TPM/PgM

Дальше в книге рассказывается две истории:

1. как SR-инженеры сначала пилили отдельные фреймворки для мониторинга, а потом объединились и стали разрабывать Viceroy
2. как Google Ads переходили с mysql на F1

в обоих историях ничего интересного не нашел

#67

Глава 32. Развитие модели вовлеченности SR-инженеров

Вовлечение SR-инженера в проект - PRR - Production Readiness Review

Обычно, на старте, на проект выделяются 1-3 SR-инженера, они начинают с совещания, на котором решают:

• установление SLO/SLA 
• планирование изменений в сервисе для повышения надежности
• планирование расписания обучения (освоения сервиса командой SRE)

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

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

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

• Значительно снижена операционная нагрузка
• Универсальная поддержка по умолчанию
• Быстрое вовлечение (SR-инженера) с низкими издержками
• Общая ответственность

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

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