Войти в систему
Войти с помощью соц. сетей:
Автор — Андреа Спадаччини
Под редакцией Кавиты Джулиани
Быть на связи — критически важное качество, которым обязаны обладать разработчики и группы сопровождения, чтобы их сервисы оставались надежными и доступными. Тем не менее есть несколько подводных камней при организации обслуживания поступающих запросов и распределении обязанностей, которые могут привести к серьезным последствиям для сервисов и команд. Эта глава описывает принципы и подходы, разработанные в Google инженерами по обеспечению надежности информационных систем (SREs) в течение многих лет, и объясняет, как благодаря этим принципам обеспечивается надежная и устойчивая работа сервисов под нагрузкой в течение долгого времени.
Ряд профессий требуют от работников постоянно быть на связи, причем это может относиться как к рабочему, так и к нерабочему времени. В сфере информационных технологий (IT) исторически сложилась практика выделения службы оперативной поддержки — команд операторов (operations, или просто ops), главная задача которых — поддерживать сервис в исправном и работоспособном состоянии.
В Google многие сервисы, такие как, например, поиск, контекстная реклама или почта, обслуживаются командами SRE, отвечающими за их производительность и надежность. SRE-команды постоянно доступны и постоянно заняты поддержкой сервисов, за которые они отвечают. Эти команды существенно отличаются от команд операторов тем, что они подходят к решению проблем в первую очередь со стороны разработки. Речь идет о проблемах такого уровня, что, попади они к команде операторов (как это обычно и бывает), решение вряд ли можно будет найти без участия разработчиков.
Для реализации такого подхода Google набирает в SRE-команды людей с разносторонней подготовкой и с опытом проектирования программ и программных систем. Мы отводим не более чем 50 % рабочего времени SRE-команды на исполнение функций операторов; оставшиеся не менее чем 50 % времени должны уделяться задачам разработки: усовершенствованиям сервисов и средствам автоматизации для повышения эффективности работы команды.
В этом разделе описывается типичная деятельность дежурных инженеров, а также сообщаются некоторые базовые сведения, необходимые для остальной части главы.
Являясь хранителями систем, которые находятся в реальной промышленной эксплуатации, дежурные инженеры поддерживают назначенных операторов, устраняя выявленные сбои, а также вносят и/или анализируют изменения в работающей системе.
В условиях промышленной эксплуатации дежурный инженер должен быть доступен для выполнения операции за считаные минуты, это время согласовывается между командой и владельцами бизнес-системы. Обычно это пять минут для сервисов, с которыми пользователи взаимодействуют непосредственно, или иных критических по времени доступа сервисов и 30 минут для менее чувствительных к времени систем. Нередко компания предоставляет устройства для оперативного получения уведомлений; чаще всего это телефон. Google имеет гибкую систему доставки, которая может рассылать уведомления на множество устройств посредством различных механизмов (электронная почта, СМС, автоответчик, приложение).
Время отклика связано с уровнем доступности сервиса, как показано в следующем простейшем примере: если пользовательская система должна достигать в течение квартала «четырех девяток» (99,99 %), допустимое ежеквартальное время простоя составляет около 13 минут (см. приложение А). Это означает, что время реакции дежурного инженера должно укладываться в несколько минут (если быть точнее, 13 минут). Для систем с менее жесткими требованиями к доступности (SLO) время отклика может исчисляться десятками минут.
После подтверждения получения уведомления от дежурного инженера требуется ранжировать проблему по ее приоритету и приступить к ее решению, при необходимости привлекая к этому других членов команды.
События промышленной среды без экстренных уведомлений, такие как низкоприоритетные оповещения или появление новых версией программного обеспечения, также могут быть обработаны и/или проверены дежурным инженером в рабочее время. Эти действия не столь срочные, как события с экстренными уведомлениями, которые имеют приоритет практически над всеми остальными задачами, включая и работу с проектом. (Для лучшего понимания прерываний и других событий (без уведомлений), составляющих рабочую нагрузку службы поддержки, см. главу 29.)
Практикуется деление дежурных на первую и вторую «очереди». Распределение обязанностей между ними варьируется от команды к команде. В одних командах второй «очереди» могут передаваться те запросы, которые не успевает обработать первая. В других первая «очередь» может обрабатывать только экстренные уведомления, а все остальные события достаются второй.
Если распределение обязанностей дежурных не требует обязательного наличия второй «очереди», вместо нее часто прибегают к передаче заданий между взаимосвязанными командами — из одной в другую. Такая форма работы позволяет обойтись без отдельной второй «очереди».
Есть ряд способов организовать работу «очередей»; более подробное их рассмотрение можно найти в соответствующей главе [Limoncelli, 2014].
Для SRE-команд существуют определенные количественные и качественные ограничения на состав дежурных смен. Количество дежурных может быть вычислено через процент рабочего времени, затрачиваемого инженерами на обслуживание запросов. Качественный состав дежурных можно определить по количеству событий (инцидентов), происходящих за одну смену.
В обязанности SRE-менеджеров входит обеспечение сбалансированной по обеим этим осям нагрузки на дежурных.
Мы искренне верим, что Е в SRE является определяющей характеристикой нашей организации, поэтому прилагаем усилия, чтобы инвестировать хотя бы 50 % времени наших SRE-команд в инжиниринг, то есть в разработку. Из другой половины на срочные работы «по вызову» может быть потрачено не более 25 %, оставляя последние 25 % на другие виды работ, не связанные непосредственно с разработкой проектов.
Используя это правило (25 % на работы «по вызовам»), мы можем вывести минимальное количество SRE-инженеров, необходимых для обслуживания запросов в режиме 24/7. Если предположить, что на дежурстве всегда заняты два человека (первая и вторая «очереди» с разными обязанностями), минимальное необходимое количество инженеров в каждой смене на единственной площадке — восемь: при недельной длительности смены каждый инженер находится на дежурстве (в первой или второй «очереди») в течение одной недели каждого месяца. Для команд, размещенных на двух различных площадках, обоснованная минимальная численность — шесть в каждой части команды, как для соблюдения правила 25 %, так и для обеспечения достаточной «критической массы» инженеров в команде.
Если с сервисом связан достаточно большой объем работ, делающий оправданным расширение команды на данной площадке, мы предпочитаем разделить команду между несколькими различными площадками. Такая распределенная команда выгодна по двум причинам.
• Ночные смены отрицательно сказываются на здоровье работников [Durmer, 2005], а передача смен между площадками в разных часовых поясах позволяет создать «команду, над которой никогда не заходит солнце», и вовсе отказаться от ночных смен.
• Ограничение количества инженеров в дежурной смене гарантирует, что инженеры не потеряют связи с эксплуатируемой системой (см. подраздел «Коварный враг: операционная недоработка» раздела «Избегание неуместной нагрузки» далее в этой главе).
Однако распределение команды на несколько площадок влечет за собой дополнительные коммуникационные и координационные издержки. Следовательно, решение о создании единой или распределенной команды должно приниматься с учетом особенностей каждого варианта, значимости сопровождаемых систем и трудоемкости их сопровождения.
На протяжении каждой дежурной смены у инженера должно быть достаточно времени на обработку всех инцидентов и на все последующие за этим действия, например на написание отчетов (постмортемов) [Loomis, 2010]. Опишем инцидент как последовательность событий и оповещений, которые имеют одну общую причину и будут отражены в одном общем отчете. Нами обнаружено, что в среднем на выяснение причин, предотвращение последующих инцидентов и написание отчетов уходит 6 часов. Из этого следует, что за 12-часовую смену может быть максимально обработано два инцидента. Чтобы верхний предел не превышался, сопровождаемые экстренными уведомлениями события должны быть распределены стационарно, максимально равномерно, с ожидаемой медианой, равной нулю: если некоторая проблема или поведение некоторого компонента ежедневно становятся источником экстренных уведомлений (среднее количество инцидентов в день больше единицы), то велика вероятность, что в какой-то момент произойдет поломка в другом месте и количество инцидентов превысит норму.
Если лимит временно превышен, например по итогам квартала, необходимо принять ответные меры, чтобы вернуть эту нагрузку к допустимой величине и стабилизировать ее (см. подраздел «Операционная перегрузка» раздела «Избегание неуместной нагрузки» далее в этой главе и главу 30).
Для переработок (внеурочных часов), связанных с выполнением обязанностей дежурных, необходимо предусматривать адекватную компенсацию. Разные организации подходят к этому по-разному. Google предлагает отгулы в соответствии со временем переработки или прямую денежную компенсацию, ограниченную некоторым процентом от годовой зарплаты. На практике максимальная компенсация отражает лимит на количество часов дежурства в смене, которые может брать сотрудник. Структура компенсации гарантирует вовлечение в работу по сменам, если того требует команда, но также продвигает сбалансированное распределение работы и ограничивает возможные недостатки чрезмерной посменной работы. Компенсация строится таким образом, чтобы мотивировать к необходимой для команды работе в дежурных сменах, но в то же время обеспечить сбалансированное распределение обязанностей и ограничить такие негативные последствия чрезмерной работы «по вызовам», как неадекватное время работы над основным проектом или «выгорание» сотрудников.
Как упоминалось ранее, большинство важнейших систем Google поддерживают SRE-команды.
Быть в SRE «дежурным» — значит брать на себя ответственность за то, с чем сталкивается пользователь, за доход от важнейших систем или за инфраструктуру, необходимую для стабильной работы всех систем. В SRE-командах тщательно обдумывать и оперативно решать проблемы — подход, жизненно важный для обеспечения успешного функционирования сервисов.
Современные исследования выделяют два различных образа действий, которым осознанно или неосознанно следует человек, когда сталкивается с проблемой [Kahneman, 2011]:
• интуитивное или автоматическое немедленное реагирование;
• рациональный, обдуманный подход к решению проблемы.
Если первый подход позволяет лучше справляться со сбоями в сложных системах, то второй с большей вероятностью дает лучшие результаты, благодаря чему снижается количество проблем в будущем.
Для того чтобы удостовериться, что у инженеров на протяжении дня будет правильный настрой, необходимо снизить стрессовую нагрузку, связанную с дежурством. Чем важнее и серьезнее конкретный сервис и последствия его сбоев, тем большее давление испытывают работающие с ним инженеры, что может привести к неуверенности и подтолкнуть команду к неверным решениям, а это может поставить под угрозу стабильную работу сервисов. Гормоны стресса кортизол и кортикотропин-рилизинг-гормон (КРГ) известны тем, что влияют на поведение, в том числе вызывают чувство страха, которое может нарушить стабильную работу организма и заставить принимать не самые лучшие решения [Chrousous, 2009].
Под влиянием гормонов стресса тщательному изучению проблемы нередко предпочитается немедленное реагирование без обдумывания и обсуждения, что ведет к потенциальному злоупотреблению эвристикой. Эвристика очень соблазнительна для занятых в качестве дежурных. Например, если в течение недели возникают четыре одинаковые ошибки, причиной первых трех из них была некоторая внешняя система, то чрезвычайно заманчиво отнести и последнюю проблему к трем предыдущим без каких либо проверок.
Хотя интуиция и быстрота реакции могут оказаться полезными при решении проблем, у них есть обратная сторона. Интуиция может подвести, и она часто не основывается на реальных данных. Поэтому интуиция может завести работника в тупик, и он зря потратит время, следуя изначально неверным путем. Быстрая реакция основывается на привычке, на следовании стереотипам, а стереотипные реакции бездумны, и их последствия могут оказаться разрушительными. Идеальная методология обработки инцидентов должна обеспечить наиболее сбалансированный темп решения проблем, сочетая осознанные решения на основе достаточных исходных данных с критическим изучением возможных допущений.
Важно, чтобы находящиеся на дежурстве работники понимали, что они могут полагаться на некоторые ресурсы, способные упростить их работу. Важнейшие ресурсы для дежурного работника:
• хороший менеджмент внутри компании;
• хорошо определенные процедуры обработки инцидентов;
• безобвинительная культура написания отчетов [Loomis, 2010], [Allspaw, 2012].
Команды разработчиков систем, поддерживаемых SR-инженерами, обычно также участвуют в круглосуточных дежурствах и всегда могут при необходимости задействовать команды-партнеры.
Увеличение простоев (в допустимых пределах) — это, как правило, лучший подход к реагированию на серьезные сбои, когда отмечается существенная неопределенность.
Если при работе над инцидентом выясняется, что проблема достаточно сложна и требует привлечения нескольких команд, или после предварительного изучения невозможно сказать, сколько времени займет окончательное решение, уместно будет применить официальный протокол обработки (менеджмента) инцидента. Google SRE использует протокол, описанный в главе 14. Он предлагает простую и предельно понятную последовательность шагов, которые позволяют дежурному инженеру достичь удовлетворяющего решения проблемы, получая всю необходимую помощь. Этот протокол реализован в веб-приложении, которое автоматизирует большинство действий по менеджменту инцидентов, таких как назначение ролей, запись и изменение статуса проблемы. Данное приложение позволяет менеджеру сосредоточиться на решении самой проблемы и не тратить время и силы на такие рутинные действия, как заполнение электронных писем или прямое общение со многими участниками процесса.
И наконец, для каждого произошедшего инцидента очень важно понять, что же пошло не так, а что прошло гладко, и предпринять действия, которые не дадут повториться этим же ошибкам в будущем. По результатам значительных инцидентов SRE-команды должны составлять отчеты, описывая полную хронологию произошедших событий. Ценность этих отчетов в том, что они фокусируются больше на событиях, чем на людях. Вместо обвинений кого-либо они отражают результаты систематического анализа инцидента. Ошибки случаются, и программное обеспечение должно быть создано так, чтобы свести эти ошибки к минимуму. Внедрение автоматизации и использование всех ее возможностей — лучший путь к сокращению количества ошибок, вызванных человеческим фактором [Loomis, 2010].
Как уже было сказано в разделе «Сбалансированная организация дежурств», на оперативную работу тратится обычно не более 50 % рабочего времени SRE-команд. Что произойдет, если этот лимит будет превышен?
SRE-команда и ее начальник, добавляя задачи в квартальный план работ, отвечают за равномерность нагрузки на команду.
Временное «одалживание» опытного SRE-работника в перегруженную работой команду, как это описано в главе 30, может дать достаточно времени для того, чтобы команда ощутимо продвинулась в решении проблем.
В идеале симптомы операционной перегрузки должны быть измеримы, а это означает, что и критерии оценки должны иметь количественное выражение (например, менее пяти «несрочных» запросов в день и менее двух экстренных уведомлений за смену).
Причиной перегрузок часто бывает неправильно настроенный мониторинг. Экстренными оповещениями должны сопровождаться только те события, которые соответствуют нарушениям работоспособности и доступности (SLO) сервисов. Необходимо также, чтобы все их можно было обработать. Оповещения с низким приоритетом, которые докучают инженеру каждый час (или даже чаще), изнуряют его, мешают нормальной работе и очень часто становятся причиной того, что более серьезные ошибки остаются без должного внимания (см. главу 29 для дальнейшего обсуждения).
Важно также контролировать количество оповещений, которые дежурный инженер получает в результате одного инцидента. Иногда одно ненормальное состояние может сгенерировать несколько оповещений, так что очень важно удостовериться в том, что взаимосвязанные оповещения группируются системой мониторинга или службой оповещений. Если по какой-то причине все-таки создаются повторяющиеся или неинформативные оповещения, возможность игнорировать их может помочь инженеру сосредоточиться на самой проблеме. Надоедливые оповещения, которые систематически порождаются по нескольку штук на один инцидент, необходимо настраивать, добиваясь соотношения ошибок и оповещений, равного 1:1. Это позволяет инженеру сосредоточиться на проблеме, а не на сортировке ошибок.
Иногда изменения, из-за которых возникает перегрузка, находятся вне ведома SRE-команды. Например, разработчики приложения могут внести изменения, система станет более «шумной», более нестабильной или и то и другое одновременно. В таком случае наилучшим решением будет работать совместно с ними для достижения общих целей по улучшению системы.
В крайнем случае у SRE-команд есть возможность «передать пейджер» — SRE могут потребовать от разработчиков заниматься исключительно функциями дежурных, пока система не будет соответствовать требованиям SRE. «Передача пейджера» — нечастое явление, потому что почти всегда есть возможность ограничиться взаимодействием с разработчиками, чтобы снизить операционную нагрузку и сделать систему более надежной. Хотя иногда комплексные или архитектурные изменения, затрагивающие несколько кварталов, могут быть необходимы для того, чтобы сделать систему более устойчивой с операционной точки зрения. Бывает, однако, что для достижения устойчивости системы (с точки зрения ее оперативного обслуживания) необходимы комплексные изменения или перестройка архитектуры, что длится несколько кварталов. В таких случаях на SRE-команду не должна ложиться слишком большая нагрузка. Вместо этого лучше всего обсудить реорганизацию дежурных обязанностей с командой разработчиков, возможно передавая несколько вызовов или их все находящемуся на дежурстве разработчику. Такое решение обычно временная мера, и команды SRE и разработчиков трудятся совместно, чтобы привести сервис в порядок и дать возможность SRE-команде снова обслуживать его самостоятельно.
Возможность переговоров о пересмотре дежурных обязанностей между SRE и командой разработчиков свидетельствует о равном вкладе обеих команд. Такие рабочие отношения также служат примером того, как нормальное взаимодействие двух команд и их функции — устойчивость системы или добавление новой функциональности — обычно приносят пользу как сервису, так всей компании в целом.
Быть дежурным при «тихой», стабильной системе — это блаженство, но что произойдет, если система слишком тихая или у SRE мало работы в качестве дежурных? Операционная недоработка для SRE-команд нежелательна. Оторванность от промышленной эксплуатации системы приводит к проблемам с уверенностью, причем это проявляется как в неуверенности, так и в излишней самоуверенности, в то время как пробелы в знаниях вскроются лишь при возникновении инцидентов. Избежать этого можно, если SRE-команды будут сформированы так, чтобы каждый инженер бывал дежурным в промышленной среде как минимум раз или два в квартал, таким образом гарантируя знакомство каждого из них с производственным процессом. Упражнения, известные как «Колесо неудачи» (описаны в главе 28), также полезны для командной работы — они помогают отточить и улучшить навыки решения проблем, а также глубже изучить сервис. Google проводит ежегодный стресс-тест для всей компании, который называется DiRT (Disaster Recovery Training). Он включает в себя теоретические и практические тренировки, чтобы успешно выполнять многодневное тестирование инфраструктуры систем или отдельных сервисов [Krishan, 2012].
Подход к организации дежурств, описанный в этой главе, служит руководством для всех SRE-команд, работающих в Google, а также является ключевым фактором для создания устойчивой и управляемой рабочей среды. Подход Google позволил нам включить разработку как основное средство масштабирования функций по обеспечению промышленной эксплуатации систем, поддерживая их высокую надежность и доступность, несмотря на рост количества систем и сервисов, за которые отвечает SRE, и их сложности. Хотя этот подход неприменим непосредственно к каждой сфере, где от IT-инженеров требуется работа в «дежурном» режиме, мы считаем, что он представляет собой проверенную модель, которую другие организации могут перенять, чтобы успешно справляться с растущим объемом таких работ.
Ранняя версия этой главы появлялась в качестве статьи в ;login: (октябрь 2015 года, выпуск 40, № 5).
Более подробное обсуждение распределения трудоемкости между разработкой и сопровождением продукта приводится в главе 1.
Войти с помощью соц. сетей: