Книга: Site Reliability Engineering. Надежность и безотказность как в Google
Назад: 4. Целевой уровень качества обслуживания
Дальше: 6. Мониторинг распределенных систем

5. Избавляемся от рутины

Автор — Вивек Рау

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

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

Из определения «нормальных изменений» при эволюции систем. Карла Гейссер, Google SRE

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

Что такое рутина

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

Что же такое рутина? Рутина — это ручная, однообразная, поддающаяся автоматизации оперативная работа, связанная с поддержкой работающего сервиса. Ее результаты не имеют ценности в перспективе, а трудоемкость растет линейно по мере роста сервиса. Не каждая на первый взгляд рутинная задача имеет все эти признаки, но чем больше она соответствует следующим описаниям, тем более вероятно, что она является рутиной.

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

• Однообразная. Если вы решаете какую-то задачу в первый раз (или даже во второй), такая работа еще не является рутиной. Рутина — это работа, которую вы выполняете раз за разом. Если же вы устраняете какую-то новую проблему или находите новое решение, это не рутина.

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

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

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

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

Почему лучше иметь меньше рутинной работы

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

Мы определили этот порог 50 % как целевой показатель, потому что объем рутины, если оставить ее без контроля, имеет тенденцию увеличиваться, и в результате может быстро поглотить все рабочее время каждого участника. Работы по снижению объема рутины и масштабированию сервисов и составляют инженерную часть в нашей профессии. Именно эти работы позволяют SRE управлять сервисами более эффективно, чем это делали бы команды, состоящие исключительно из разработчиков или из операционистов, при более медленном (сублинейном) увеличении количества сотрудников относительно роста сервиса.

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

Определяем количество рутины

Если мы хотим ограничить время, которое отдел SRE тратит на рутину, значением 50 %, то как это должно быть организовано?

Существует нижний порог доли рутинной работы, которую должен выполнить SR-инженер, находясь на дежурстве. Как правило, SR-инженер одну неделю цикла проводит в качестве дежурного первой «очереди» и одну неделю — второй «очереди» (более подробно организация дежурств рассматривается в главе 11). Это означает, что если в ротации участвуют шесть человек и если как минимум две недели из шести посвящены дежурству и обслуживанию поступающих запросов (прерываний), то нижняя граница потенциальной рутинной работы равна 2 / 6 = 33 % всего рабочего времени SR-инженера. При ротации среди восьми человек нижняя граница составит 2 / 8 = 25 %.

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

Ежеквартальные опросы SR-инженеров показывают, что в среднем на рутину тратится 33 % рабочего времени, что гораздо ниже целевого уровня 50 %. Однако такое усреднение не показывает крайних значений: некоторые SR-инженеры сообщают об отсутствии (0 %) рутинной работы (проекты, в которых они заняты исключительно разработкой, без работы на дежурствах), а другие — о 80 % рутины. Когда отдельные SR-инженеры сообщают о большом количестве такой работы, это зачастую говорит о том, что менеджерам следует более равномерно распределить рутинные обязанности между членами команды и способствовать поиску этими SR-инженерами подходящих для них инженерных проектов.

Что такое инженерная работа

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

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

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

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

• Рутина. Работа, которая связана непосредственно с обслуживанием сервиса и которая является однообразной, ручной и т.д.

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

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

Всегда ли рутина вредна

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

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

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

• Снижение боевого духа. У разных людей разное представление о том, сколько рутинной работы они могут выполнить, и у каждого есть свой предел. Слишком большой объем такой работы приводит к «выгоранию», скуке и недовольству.

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

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

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

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

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

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

Итоги главы

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

«Нормальные изменения» — изменения в состоянии системы, для которых предусмотрены соответствующие шаги процессов управления. — Примеч. пер.

Мы используем систему «Цели и ключевые результаты», ее разработал Энди Гроув из компании Intel [Klau, 2012].

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

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

Назад: 4. Целевой уровень качества обслуживания
Дальше: 6. Мониторинг распределенных систем