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

Автор — Рэндэлл Босетти

Под редакцией Дианы Бейтс

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

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

Используя этот подход, не обязательно переводить нескольких инженеров. Если вы введете двоих новых специалистов, то это может дать даже обратный эффект и привести к проблемам.

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

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

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

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

Операционная работа против нелинейного масштабирования Термин «операционная работа» характеризует определенный метод поддержания сервиса в рабочем состоянии. Различные рабочие элементы увеличиваются с разра­станием сервиса. Например, сервису по мере его роста нужен способ увеличить количество сконфигурированных виртуальных машин (virtual machines, VM). Команда, выполняющая операционную работу, отвечает увеличением количества администраторов, управляющих этими VM. SR-инженеры вместо этого концентрируются на написании ПО или избавлении от проблем с масштабируемостью, чтобы количество людей, необходимое для работы сервиса, не увеличивалось согласно функции увеличения нагрузки на сервис.

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

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

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

Определите главные источники стресса

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

Определите очаги возгорания

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

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

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

• Сильная зависимость от «следующего прорыва». Люди могут игнорировать проблемы месяцами, поскольку они верят, что новое решение, которое скоро будет реализовано, устранит все недостатки.

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

• SLI/SLO/SLA. См. главу 4, в которой рассматриваются показатели SLI, SLO и SLA.

• Любой сервис, чей план производительности выглядит как «Добавьте еще серверов: у наших серверов этой ночью закончилась память». Планы производительности должны быть достаточно перспективными. Если модель вашей системы прогнозирует, что серверу нужно 2 Гбайт памяти, то нагрузочный тест, который проходит в краткосрочной перспективе (показывая значение 1,99 во время последнего запуска), не обязательно означает, что ваша система имеет достаточную производительность.

• Постмортемы, которые рекомендуют лишь откат изменений, вызвавших сбой. Например, «Измените потоковый тайм-аут обратно на 60 секунд» вместо «Определите, почему иногда требуется 60 секунд на то, чтобы получить первый мегабайт наших промовидеороликов».

• Любой критически важный для обслуживания компонент, на все вопросы о котором SR-инженеры отвечают: «Мы ничего об этом не знаем, им владеют разработчики». Для того чтобы предоставить приемлемую поддержку компонента на дежурстве, вы должны хотя бы знать о том, что произойдет, когда он перестанет выполнять свои функции, а также о сроках, в которые нужно исправить проблему.

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

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

Напишите для команды хороший постмортем

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

Лучше всего, если вы сами напишете следующий постмортем. Пока вы будете работать в другой команде, какой-нибудь сбой обязательно случится. Если вы в этот момент не дежурите, объединитесь с дежурным инженером и напишите хороший, безобвинительный постмортем. Этот документ прекрасно продемонстрирует, что переход к SRE-модели поможет команде и упростит исправления ошибок. Чем меньше приходится вносить исправлений, тем меньше времени сбои отнимают у членов команды.

Как уже упоминалось, вы можете встретить возражения вроде «Почему я?». Наиболее вероятно, что вы услышите это, если команда считает, что написание постмортемов — сущее наказание. Такое отношение появляется из-за теории «избавления от паршивых овец»: система в порядке, и, если мы избавимся от «паршивых овец» и ошибок, связанных с ними, система продолжит оставаться в порядке. Эта теория неверна, о чем свидетельствуют [Dekker, 2014] несколько дисциплин, включая авиационную безопасность. Вы должны указать на ее неверность. В частности, можно сказать следующее: «Нельзя избежать ошибок в системах с таким большим количеством взаимодействий. Вы дежурили, и я верю, что вы принимаете правильные решения на основе верной информации. Я бы хотел, чтобы вы описали все, о чем думали в каждый момент времени, и тогда мы сможем понять, почему система ввела вас в заблуждение и где требования были слишком жесткими».

Сортируйте перегрузки в соответствии с их типами

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

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

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

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

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

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

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

Начните с основ

Команды, которые не могут понять разницу между работой SRE и традиционных операционистов, зачастую не способны выразить, почему их беспокоят некоторые особенности программы, процессов или культуры команды. Вместо того чтобы пытаться разобрать эти моменты шаг за шагом, вам следует обратиться к принципам, описанным в главах 1–6.

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

Получите помощь в исправлении ошибок

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

1. Найдите полезную работу, которую может выполнить один член команды.

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

3. Выполняйте обзоры изменений кода и редакций документов.

4. Повторите эти шаги для 2–3 проблем.

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

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

По мере того как команда наладит свою работу и усвоит базовые принципы предложенных вами изменений, переходите к разбору повседневных решений, которые привели к операционной перегрузке. Подготовьтесь к тому, что это будет трудной задачей. Если вам повезет, то вы услышите: «Объясни почему. Прямо сейчас. Во время еженедельного собрания, связанного с производственными системами».

Если вам не повезет, никто не потребует объяснения. Вы можете избежать этой проблемы, в любом случае аргументируя свои решения, независимо от того, требует ли кто-то объяснений. Ссылайтесь на базовые сведения, которые подчеркивают ваши предположения. Это позволит сформировать ментальную модель команды. После того как вы покинете команду, ее члены будут способны спрогнозировать ваши потенциальные комментарии о проекте или списке изменений. Если вы не будете обосновывать свои идеи или сделаете это плохо, появится риск того, что команда просто проигнорирует ваши слова, поэтому четко выражайте мысли.

Вот примеры тщательных объяснений своих решений.

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

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

Примеры плохих объяснений своих решений приведены ниже.

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

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

• «Автоматизация не должна прерываться, если она встретит несовместимое развертывание».

Как и в предыдущем случае, это объяснение может и корректно, но его недостаточно. Вместо этого вам следует сказать следующее: «…поскольку мы делаем упрощающее допущение о том, что все изменения проходят автоматизацию, и что-то явно нарушило это правило. Если это случается часто, нам нужно определить источники неорганизованных изменений и избавиться от них».

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

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

Примеры наводящих вопросов:

• «Я вижу, что оповещение TaskFailures часто запускается, но дежурные инженеры зачастую ничего не делают для того, чтобы на него отреагировать. Как это влияет на SLO?»;

• «Эта процедура запуска сервиса выглядит слишком сложной. Знаете ли вы, зачем нужно выполнять так много обновлений конфигурационных файлов при создании новых экземпляров сервиса?».

Примеры некорректных наводящих вопросов:

• «Что не так со всеми этими старыми релизами?»;

• «Почему Frobnitzer так много всего делает?».

Итоги главы

Положения, показанные в этой главе, предоставят команде SR-инженеров следующее:

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

• яркий пример того, какими могут быть изменения;

• логическое объяснение большого количества «народной мудрости», используемой SR-инженерами;

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

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

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