Войти в систему
Войти с помощью соц. сетей:
Автор — Дэйв О’Коннор
Под редакцией Дианы Бейтс
Если речь идет о сложных системах, операционная нагрузка — это работа, которую нужно выполнять для того, чтобы поддерживать систему в функциональном состоянии. Например, если у вас есть машина, вам (или тому, кому вы платите) всегда нужно будет заправлять ее, а также выполнять другие регулярные работы по ее обслуживанию для того, чтобы она продолжала ездить.
Любая сложная система неидеальна, как и ее создатели. При управлении операционной нагрузкой, созданной этими системами, помните, что создатели — такие же неидеальные машины.
Когда идет речь об управлении сложными системами, операционная нагрузка принимает множество форм, причем одни из них более очевидны, чем другие. Терминология может изменяться, но операционная нагрузка делится на три общие категории: оповещения, тикеты и продолжительную операционную работу.
Оповещения связаны с производственными уведомлениями и их последствиями. Они появляются в ответ на неотложные ситуации в производственных системах. Иногда они могут быть однотипными, повторяющимися и не требующими особых раздумий. Они также могут быть необычными и требовать серьезного анализа. Оповещения имеют целевое значение (SLO) ожидаемого времени ответа, которое обычно измеряется в минутах.
Тикеты связаны с запросами пользователей, требующих от вас каких-то действий. Как и вызовы, тикеты могут быть как простыми и скучными, так и требующими серьезных размышлений. Простой тикет может потребовать выполнения обзора кода для конфигурации, которой владеет команда. Более сложные тикеты могут повлечь за собой особый запрос, например, на оказание помощи в проектировании или планировании производительности. Тикеты также могут иметь целевые значения, но время ответа на них измеряется в часах, днях или неделях.
Продолжительная операционная работа (также известная как поверхностное решение проблемы или рутина; см. главу 5) включает в себя такие действия, как отправка кода или ответы на чувствительные ко времени вопросы от клиентов. Несмотря на то что они не имеют определенных целевых значений, эти действия также могут прерывать вашу работу.
Некоторые виды операционной нагрузки можно предугадать или спланировать, но большую ее часть спланировать нельзя — те же поступающие запросы (прерывания) могут появиться в любое время, и инженеру придется определить, может ли проблема подождать.
Компания Google разработала несколько методов управления каждым видом операционной нагрузки на уровне команды.
Оповещениями зачастую управляет основной дежурный инженер. Этот человек отвечает на вызовы и управляет возникающими инцидентами или сбоями. Основной дежурный инженер также может отвечать на сообщения пользователей, отправлять сообщения о сбоях разработчикам продукта и т.д. Для того чтобы минимизировать количество поступающих запросов, которые затрагивают команду, а также избежать эффекта постороннего, на дежурстве работает один инженер. Он может отправлять оповещения другим членам команды, если сам не в состоянии разобраться с проблемой.
Как правило, вспомогательный дежурный инженер выступает в качестве помощника основного. Его обязанности могут меняться. Иногда его единственной задачей является взаимодействие с основным инженером, если экстренные уведомления остаются без ответа. В этом случае вспомогательный инженер может находиться в другой команде. Он может сам выбрать, работать ему с поступающими запросами или нет, в зависимости от его обязанностей.
Тикетами управляют несколькими разными способами в зависимости от команды SR-инженеров: основной дежурный инженер может работать над ними, пока находится на дежурстве, вспомогательный инженер может работать над ними, находясь на дежурстве, или же в команде предусмотрен человек, который отвечает за тикеты и не работает на дежурстве. Тикеты могут автоматически распределяться между участниками команды в случайном порядке, или же члены команды могут просто обрабатывать тикеты по мере их поступления.
Непрерывной операционной работой также можно управлять несколькими способами. Иногда всю работу (установка новой версии и т.д.) делает дежурный инженер. В то же время за каждым членом команды может быть закреплена определенная обязанность, или же дежурный инженер может браться за работу (например, многонедельное обновление), которая длится дольше, чем он работает на дежурстве.
Отступая на шаг назад от механизмов управления операционной нагрузкой, рассмотрим несколько показателей, которые влияют на способ обработки каждого поступающего запроса. Некоторые команды SR-инженеров при определении способа управления такими запросами обращают внимание на:
• целевое значение ожидаемого времени ответа;
• количество запросов, которое обычно не выполнено;
• серьезность запросов;
• частоту поступающих запросов;
• количество людей, доступных для обработки определенных видов запросов (например, некоторым командам требуется определенное количество тикетов для того, чтобы начать дежурство).
Вы можете заметить, что все эти показатели подходят для того, чтобы время ответа было минимальным, без привлечения большого количества человеческих ресурсов.
Люди — это неидеальные машины. Им бывает скучно, у них есть плохо изученные процессоры (и иногда даже пользовательский интерфейс), а еще они не очень эффективны. Описание человеческой природы и способов улучшить работу людей не относятся к теме этой книги, поэтому сейчас мы рассмотрим только базовые идеи, которые могут быть полезны для определения того, как нужно реагировать на поступающие запросы.
Концепция состояния когнитивного потока широко распространена и может быть эмпирически подтверждена практически каждым, кто работал в области разработки ПО, системного администрирования, в службе SRE или был связан с другими дисциплинами, которые требовали сконцентрированной работы. Будучи в ударе, человек обычно работает более эффективно, а также отличается артистической и научной креативностью. В таком состоянии люди стремятся улучшить задачу или проект, над которыми работают. Поступающий запрос может выбить вас из этого состояния, если он достаточно серьезный. Конечно, вы предпочтете уменьшить количество таких запросов.
Когнитивный поток также может быть актуален и для менее креативных занятий, где требуется меньший уровень навыков, но при этом возможны четкие цели, мгновенная обратная связь, ощущение контроля и соответствующее искажение времени; в качестве примера можно привести выполнение работы по дому или вождение.
Вы можете достичь оптимального уровня концентрации внимания, работая над нетрудными задачами, не требующими особых навыков, например играя в повторяющуюся видеоигру. Так же легко вы можете войти в это состояние, выполняя трудные задачи, требующие значительных навыков, например, такие, с которыми сталкивается инженер. Методы вхождения в состояние когнитивного потока могут различаться, но результат останется тем же.
Когда человек работает над задачей какое-то время, он хорошо понимает особенности проблемы и, скорее всего, в состоянии ее решить. Будучи в состоянии подъема, инженер может неотрывно работать над проблемой, теряя счет времени и максимально игнорируя поступающие запросы. Очень желательно максимизировать количество времени, которое работник может провести в этом состоянии, — так больше шансов получить креативные результаты и успеть выполнить задание в срок. В то же время специалист будет чувствовать удовлетворение от выполнения своей работы.
К сожалению, множество людей в роли SR-инженеров либо стремятся войти в это состояние, а у них не получается и они выходят из равновесия, либо никогда не пытаются достичь его, вместо этого страдая из-за постоянных прерываний.
Людям нравится решать такие задачи, которые им понятны. Фактически выполнение такой работы — один из простейших путей к достижению состояния когнитивного потока. Некоторые SR-инженеры входят в это состояние, находясь на дежурстве. Так можно очень эффективно отслеживать источники проблем, работать с коллегами и улучшать общее состояние системы.
И наоборот, для большинства раздраженных инженеров, находящихся на дежурстве, стресс вызывается либо количеством экстренных уведомлений, либо тем, что они считают дежурства отвлекающим от основной работы фактором. Они пытаются писать код или на полную ставку работать над проектами, одновременно дежуря или реагируя на поступающие запросы. В итоге эти инженеры постоянно работают в режиме прерывания, что, несомненно, приводит к стрессам.
С другой стороны, когда человек полностью концентрируется на прерываниях, они перестают быть прерываниями в прямом смысле этого слова. На очень глубоком уровне постепенное усовершенствование системы, выполнение требований тикетов, а также исправление проблем и сбоев становится четким набором целей, границ и прозрачной обратной связи: вы закрываете Х багов или вам перестают поступать экстренные уведомления. Все остальное — это раздражители. Когда вы работаете с прерываниями, ваши проекты становятся раздражителями. Даже несмотря на то, что работа с прерываниями может быть удовлетворительной в краткосрочной перспективе, в смешанной среде, где одновременно приходится работать над проектами и дежурить, люди чувствуют себя счастливее, если сбалансированно тратят свое время на эти два вида работы. У каждого инженера будет свой показатель идеального баланса. Надо лишь учитывать, что некоторые инженеры могут не знать, какое именно сочетание этих видов работы может их мотивировать (или они могут думать, что знают, но вы придерживаетесь другого мнения).
Вы можете задуматься о том, чтобы применить прочитанное на практике. Следующие рекомендации основаны на том, что сработало для разных команд SR-инженеров, которыми я управлял в компании Google, и предназначены скорее для удобства менеджеров команды или руководителей. Этот список не затрагивает индивидуальные особенности человека — люди могут управлять своим свободным временем так, как посчитают нужным.
Существует множество вещей, способных отвлечь инженера и вывести его из состояния воодушевления. Например, рассмотрим случайного SR-инженера по имени Фред. Фред приходит на работу утром в понедельник. Сегодня он не дежурит и не работает с прерываниями, поэтому он планирует заняться своими проектами. Он делает себе кофе, надевает свои наушники марки «Не беспокоить» и садится за свой стол. Пришло время почувствовать себя в ударе, верно? Не совсем, ведь в любой момент может случиться что-нибудь неожиданное.
• Команда Фреда использует систему автоматического распределения тикетов, случайным образом назначающую его ответственным за тикет, который нужно закрыть сегодня.
• Коллега Фреда сегодня работает на дежурстве, получает экстренное уведомление, связанное с компонентом, в котором Фред отлично разбирается, и отвлекает его, задав вопрос об этом компоненте.
• Пользователь сервиса, за который отвечает Фред, повышает приоритет тикета, адресованного Фреду на прошлой неделе, когда тот находился на дежурстве.
• Подготовка нового релиза, который будет выпущен через 3–4 недели и за который отвечает Фред, выполняется неверно, что заставляет Фреда бросить все и проверить релиз, откатить изменение и т.д.
• Пользователь сервиса, за который отвечает Фред, связывается с ним, чтобы задать вопрос, потому что Фред всегда так любезен!
• И т.д.
В итоге, несмотря на то что у Фреда был целый календарный день для работы над проектами, он не смог сосредоточиться. Одними отвлекающими факторами он мог управлять, закрыв электронную почту, отключив сервисы обмена сообщениями и пр. Другие вызваны политикой компании или соглашениями о прерываниях и продолжительных обязанностях.
Вы можете сказать, что некоторых отвлекающих факторов нельзя избежать по умолчанию. Это так: у каждого инженера есть своя зона ответственности и обязательства. Однако существуют способы, с помощью которых команда может управлять ответами на прерывания, чтобы большинство инженеров могли приходить утром на работу и спокойно трудиться.
Для того чтобы свести к минимуму свою отвлекаемость, вы должны минимизировать количество переключений контекста. Некоторых прерываний избежать невозможно. Однако нельзя рассматривать инженера как работника, который может легко отвлекаться, и это никак не повлияет на его основную деятельность. Определите для себя стоимость переключений контекста. Двадцатиминутное прерывание при работе над проектом влечет за собой два переключения контекста, ведь на самом деле это прерывание приведет к потере нескольких часов действительно продуктивной работы. Чтобы избежать постоянной потери производительности, нацельтесь на распределение времени между разными видами работы, максимально увеличивая продолжительность каждого периода. В идеале таким периодом должна стать неделя, но день или полдня могут быть даже более подходящими. Эта стратегия также вписывается в концепцию потерянного времени [Graham, 2009].
Распределение времени означает, что, приходя на работу, человек должен знать, над чем он сегодня работает: только над проектом или только над прерываниями. Распределение времени таким способом означает, что инженеры смогут концентрироваться на работе над задачей на протяжении длительного периода. Они не будут раздражаться из-за того, что приходится переключаться между задачами, отвлекающими их от работы, которую они должны выполнять на самом деле.
Если общая модель, представленная в этой главе, вам не подходит, предлагаю несколько конкретных рекомендаций. Все дальнейшие идеи вы можете реализовать поэтапно.
Если объем прерываний любого класса слишком велик для одного человека, добавьте еще одного исполнителя. Эта концепция наиболее очевидно применяется к тикетам, но потенциально ее можно применить и к вызовам — основной инженер может начать задействовать вспомогательного или же понижать вызовы до тикетов.
Основной инженер, работающий на дежурстве, должен концентрироваться исключительно на дежурстве. Если пейджер вашего сервиса молчит, то частью ваших обязанностей как дежурного должны стать тикеты или другая работа, основанная на прерываниях, которую можно относительно быстро прекратить. Если инженер дежурит на протяжении недели, эта неделя должна быть исключена из табеля времени работы над проектом. Если проект слишком важен и не может ждать неделю, этот человек не должен находиться на дежурстве. В таком случае назначьте дежурным кого-то другого. Не стоит ожидать от людей того, что они будут дежурить и одновременно продвигаться в работе над проектом (или над чем-то еще, что имеет высокую стоимость переключения контекста).
Обязанности вспомогательного инженера зависят от того, насколько обременительна работа на дежурстве. Если его функция заключается в помощи основному в случае неудачи, то вспомогательный инженер наверняка может работать и над проектом. Если кто-то, кроме вспомогательного инженера, работает над тикетами, рассмотрите возможность объединения ролей. Если вспомогательный инженер на самом деле должен помогать основному из-за большого количества вызовов, то он должен работать и с прерываниями.
(Ремарка: работы по уборке всегда будет предостаточно. Количество тикетов может быть равно нулю, но всегда будет документация, которую нужно обновить, конфигурация, которую нужно очистить, и т.д. Ваши будущие дежурные работники только поблагодарят вас, а значит, скорее всего, не будут вас беспокоить.)
Если в данный момент вы присваиваете тикеты инженерам случайным образом, остановитесь. Такое отношение к времени вашей команды крайне неуважительно, оно полностью отменяет принцип минимальных прерываний.
Работа над тикетами должна выполняться на протяжении рабочего дня в таких объемах, с которыми может справиться один человек. Если получается так, что количество тикетов превышает совместные возможности основного и вспомогательного инженеров, организуйте очередь тикетов так, чтобы в любой момент времени у вас было два человека, работающих с ней. Люди не машины, вы лишь отвлекаете их от основной работы, отнимая драгоценное время.
Определите роли в команде так, чтобы любой человек мог взяться за текущие задачи. Если существует хорошо определенная процедура для выполнения и проверки новых версий кода, то нет необходимости заставлять кого-то одного постоянно выполнять эту работу даже после того, как он перестает дежурить или обрабатывать прерывания. Определите роль push-менеджера (отвечающего за установку новой версии), который сможет управлять релизом во время дежурства или работы с прерываниями. Формализуйте процесс передачи — это небольшая цена за то, чтобы остальные люди, не работающие на дежурстве, имели возможность спокойно выполнять свои обязанности.
Иногда команда получает прерывание, для обработки которого лучше всего подходит человек, не работающий с прерываниями в данный момент. Хотя в идеале такая ситуация никогда не должна возникать, так все же случается. Вы должны поработать над тем, чтобы это происходило как можно реже.
Бывает, что человек работает с тикетами, в то время как не должен этого делать, — хочет создать видимость занятости. Это говорит о том, что такой работник недостаточно эффективен. В итоге искажается реальное представление о том, насколько управляемым является количество тикетов. Если для работы с тикетами назначен один человек, но два или три других человека также начнут с ними разбираться, ваша очередь тикетов все еще может оставаться неконтролируемой, хотя вы этого и не заметите.
Количество прерываний, с которыми сталкивается ваша команда, может быть неконтролируемым, если они требуют от команды постоянного внимания в любой момент времени. Существует несколько приемов, позволяющих уменьшить общее количество тикетов.
Большая часть дежурных инженеров, работающих с тикетами, воспринимают их как наказание. Это особенно верно для крупных команд. Если вы работаете с прерываниями всего раз в несколько месяцев, очень легко пробежаться по ним, облегченно вздохнуть и вернуться к своим обычным обязанностям. Далее сменившие вас коллеги сделают то же самое, и никто не станет разбираться в основных причинах тикетов: вместо того чтобы двигаться вперед, ваша команда погрязнет в рутине из-за того, что людей раздражают одни и те же проблемы.
Должен быть предусмотрен процесс передачи тикетов, а также работы на дежурстве. Процесс передачи предусматривает распределение обязанностей между обработчиками тикетов по мере переключения ответственности. Даже минимальная самодиагностика основных причин может дать хорошие результаты для уменьшения общего количества тикетов. Многие команды выполняют эстафетную передачу дежурства и делают сводку экстренных уведомлений. Очень немногие команды делают то же самое для тикетов.
Ваша команда должна регулярно избавляться от тикетов и экстренных уведомлений, при этом нужно проверять группы прерываний, чтобы увидеть, сможете ли вы определить их основную причину. Если вы думаете, что от главного источника прерываний можно избавиться в разумный период времени, то вам следует приглушить остальные прерывания до тех пор, пока основная причина не будет устранена.
Это правило больше применимо к пользовательским, а не к автоматическим прерываниям, несмотря на то что принципы актуальны для обоих случаев. Если тикеты особенно раздражают или с ними трудно справляться, вы можете изменить линию поведения для облегчения своей ноши.
Помните:
• ваша команда задает уровень обслуживания, предоставляемый вашим сервисом;
• допустимо перекладывать какие-то обязанности на клиентов.
Если ваша команда отвечает за обработку тикетов или прерываний для клиентов, вы можете сделать свою рабочую нагрузку более управляемой. Это решение может быть как временным, так и постоянным, в зависимости от того, что имеет больший смысл. Так вы определите баланс между уважением к клиенту и уважением к себе.
Например, если вы поддерживаете особенно капризный инструмент, для которого практически нет ресурсов разработчика, и с ним работает небольшая группа требовательных клиентов, рассмотрите другие варианты. Подумайте о времени, которое вы потратите на обработку прерываний для этой системы, и ответьте на вопрос, будете ли вы тратить его оптимально. Если в какой-то момент вы не сможете уделить системе достаточно внимания, чтобы исправить основную причину прерываний, возможно, компонент, который вы поддерживаете, не так уж и важен. Вы должны рассмотреть возможность возврата пейджера, отключения компонента, его замены или другую подобную стратегию, которая может иметь смысл.
Если конкретные шаги по исправлению ошибки требуют большого количества времени или запутанны, но не требуют ваших привилегий для их завершения, рассмотрите возможность отправки запроса обратно. Например, если люди должны потратить вычислительные ресурсы, подготовьте код или изменение конфигурации или сделайте аналогичный шаг, а затем скажите клиенту выполнить этот шаг и проверьте его работу. Помните, что, если клиент хочет, чтобы некоторая задача была выполнена, он должен быть готов приложить усилия для того, чтобы получить желаемое.
Подводным камнем таких решений является необходимость поиска баланса между уважением к клиенту и уважением к себе. При создании стратегии работы с запросами клиентов руководствуйтесь тем, что запрос должен быть осмысленным, а вы должны предоставить всю информацию, необходимую для его выполнения. Ваш ответ должен быть полезным и своевременным.
См. в «Википедии»: Flow (psychology), ). Потоком называют оптимальный уровень концентрации внимания.
См. .
Войти с помощью соц. сетей: