Войти в систему
Войти с помощью соц. сетей:
Автор — Бен Трейнор Слосс
Под редакцией Бетси Бейер
Проверяйте и редактируйте ввод конфигурации и отвечайте на неверный ввод одновременно продолжением работы и соответствующим оповещением.
• Неправильные данные. Проверяйте как синтаксис, так и, если это возможно, семантику. Следите за пустыми, а также частичными или усеченными данными (к примеру, предусматривайте оповещение в том случае, если конфигурация на N % меньше предыдущей версии).
• Опоздавшие данные. Могут привести к аннулированию текущих данных из-за задержек. Запланируйте оповещения, которые будут отправляться задолго до ожидаемого времени истечения данных.
Ошибайтесь так, чтобы можно было продолжить работу, пусть даже рискуя показаться слишком либеральным или бесхитростным. Мы пришли к выводу, что для систем в целом безопаснее продолжать работу в прежней конфигурации и ожидать подтверждения от человека для использования новых, возможно, неверных данных.
| Примеры В 2005 году глобальная DNS-система Google, отвечающая за загрузку и балансировку времени ожидания, в качестве разрешений для файла получила пустой начальный файл DNS. Система приняла его и 6 минут обслуживала ответ NXDOMAIN для всех параметров Google. В качестве ответной меры сейчас система выполняет ряд проверок доступности на новых конфигурациях, включая подтверждение наличия виртуальных IP для google.com, и продолжает обслуживать предыдущие записи DNS до получения нового файла, который прошел проверку ввода. В 2009 году ввод неправильных (но допустимых) данных привел к тому, что Google отметила всю сеть как содержащую вредоносные программы [Mayer, 2009]. Конфигурационный файл со списком подозрительных URL был заменен слешем (/), который соответствовал всем URL. Такие изменения не вступили бы в силу, если бы были проведены проверки резких изменений размера файла и соответствий конфигурации сайтам, которые едва ли могут содержать вредоносные программы. |
Несрочные выпуски должны проходить в несколько этапов. Как конфигурационные, так и бинарные изменения несут определенный риск, и вы его сглаживаете, одновременно применяя изменения к небольшим долям трафика и производительности. Масштаб вашего сервиса или релиза, как и ваш профиль риска, покажут в процентном отношении производительность производства, для которого вы готовите новый выпуск сервиса, и подходящий промежуток времени между этапами. Рекомендуется также выполнять различные этапы на разных территориях, чтобы выявить проблемы с суточными циклами трафика и различия в структуре трафика, обусловленные географическими факторами.
Выпуски новых версий должны быть контролируемы. Чтобы гарантировать отсутствие любых неожиданностей в процессе релиза, за ним должен наблюдать либо выполняющий его программист, либо — предпочтительно — надежная система контроля. При обнаружении неожиданного поведения первым делом необходимо сделать откат и впоследствии провести диагностику, чтобы минимизировать среднее время восстановления.
Измеряйте доступность и производительность с точки зрения важных для конечного пользователя условий. Подробно этот вопрос обсуждается в главе 4.
| Пример Измерение частоты ошибок и времени ожидания в клиенте Gmail вместо сервера привело к существенному сокращению наших оценок доступности Gmail и повлекло изменения как в клиенте Gmail, так и в серверном коде. В результате доступность Gmail за пару лет возросла от 99,0 до 99,9 %. |
Надежность баланса и темп нововведений с бюджетом ошибок (см. раздел «Обоснование критерия суммарного уровня ошибок (бюджета ошибок)» главы 3) вместе определяют допустимый уровень отказов для сервиса за определенный период — для нас это месяц. Бюджет представляет собой просто единицу за вычетом показателя целевого уровня обслуживания; к примеру, сервис с целевой доступностью 99,99 % располагает бюджетом недоступности 0,01 %. Пока сервис не исчерпал свой бюджет ошибок в течение месяца через фоновую величину ошибок в сочетании с любым показателем простоя, команда разработчиков может свободно (хотя и в пределах разумного) вводить новые возможности, применять обновления и т.д.
Если бюджет ошибок исчерпан, изменения замораживаются (за исключением неотложных решений в области безопасности и багов, применяемых к любой причине увеличения ошибок) до момента, пока сервис не вернется в рамки бюджета или не начнется новый месяц. Для крупных сервисов с целевым уровнем обслуживания выше 99,99 % вполне применимо квартальное, а не месячное обновление бюджета по причине малого показателя допустимого времени простоя.
Бюджеты ошибок устраняют структурное напряжение, которое в противном случае может развиться между SRE и командами разработчиков продуктов. Они получают простой, управляемый данными механизм для оценки риска запуска. Бюджеты также предоставляют как службе SRE, так и команде разработчиков общую цель для развития технологий и практик разработки, которые позволяют скорейшее внедрение нововведений и больше запусков без «раздувания бюджета».
При мониторинге предусмотрены лишь три типа выходного документа.
• Оповещения. Человек немедленно должен предпринять какие-то действия.
• Тикеты. Человек должен предпринять какие-то действия в течение пары дней.
• Журналирование. Никому не нужно заниматься этими журналами прямо сейчас, но их при необходимости делают доступными для последующего анализа.
Если для вызова человека достаточно оснований, то требуются незамедлительные действия (то есть мы имеем дело с оповещением) или вы распознаете проблему как баг и заносите его в вашу систему отслеживания ошибок. Размещать оповещения в электронных письмах и надеяться, что кто-нибудь прочтет их все и заметит важные, эквивалентно сваливанию их в /dev/null: в конечном счете их проигнорируют. История показывает, что такая стратегия привлекательна, но опасна, поскольку работает какое-то время, но опирается на бесконечную человеческую бдительность, и по этой причине неизбежное отключение, когда оно все-таки произойдет, будет еще более разрушительным.
Постмортемы (см. главу 15) должны быть безобвинительными и фокусироваться на процессе и технологиях, а не на людях. Предполагайте, что люди, вовлеченные в инцидент, умны, действовали из лучших побуждений и принимали наилучшие решения из возможных с доступной им в тот период информацией. Из этого следует, что мы не можем исправить людей, но должны вместо этого исправлять их окружение: иными словами, улучшать конструкцию системы, чтобы избегать целых классов проблем, делать нужную информацию легкодоступной и автоматически подтверждать оперативные решения, чтобы системы было затруднительно подвергнуть риску опасного состояния.
Представим необходимость справиться одновременно с запланированным и незапланированным отключением с сохранением доступа к пользовательскому интерфейсу, что приводит нас к конфигурации N + 2, где пиковую нагрузку могут обрабатывать N экземпляров (возможно, в режиме ограниченной функциональности), в то время как два крупнейших экземпляра остаются недоступными.
• Проверяйте предварительные прогнозы спроса на соответствие реальности, пока они не покажут корректное сочетание. Расхождение ведет к нестабильному прогнозированию, неэффективному распределению ресурсов и риску дефицита производительности.
• Используйте нагрузочное тестирование вместо традиционного, чтобы установить отношение ресурса к производительности; кластер из X машин мог справиться с Y запросами 3 месяца назад, но сохранил ли он эту способность с учетом изменений в системе?
• Не путайте нагрузку первого дня с нагрузкой устойчивого состояния. Запуски часто привлекают больше трафика, и вместе с тем это тот период, когда вам особенно необходимо представить продукт с наилучшей стороны. См. главу 27 и приложение Д.
Перегруженные сервисы должны выдавать умеренные, но приближенные к оптимальным результаты. К примеру, при перегрузке Google Search будет осуществлять поиск по меньшему количеству параметров и прекратит обслуживание функционала вроде Instant, чтобы и дальше предоставлять возможность поиска по Сети. Протестируйте систему веб-поиска, задав высокие значения производительности, чтобы обеспечить удовлетворительную работу сервиса при перегрузке трафиком.
В периоды, когда нагрузка настолько высока, что даже слабый отклик серьезно потребляет ресурсы, применяйте постепенную сегментацию нагрузки (см. главу 21). Прочие техники предусматривают ответы на запросы со значительной задержкой («режим увязания») и выбор последовательного подмножества клиентов, чтобы можно было получать сообщения об ошибках, не затрагивая работу пользователей.
Повторения могут увеличить вероятность ошибки при высоких уровнях трафика, что приведет к каскадным отключениям (см. главу 22). Отвечайте на каскадные отключения проходами долей трафика (включая повторения!) вверх по системе, как только общая нагрузка превысит общую производительность.
Каждый клиент, производящий вызов удаленных процедур (RPC), при планировании повторных попыток должен использовать экспоненциальный откат (с небольшой погрешностью), чтобы не допустить распространения ошибки. Особое внимание стоит уделить мобильным клиентам, поскольку их могут быть миллионы и изменение их кода занимает длительное время — возможно, недели — и требует от пользователя установки обновлений.
Команды SRE должны тратить не больше 50 % своего времени на оперативную работу (см. главу 5), нагрузку сверх этого следует перенаправлять команде разработки продукта. Многие команды также подключают разработчиков продуктов к дежурствам и работе с тикетами, даже если в текущий момент перегрузки не наблюдается. Это стимулирует проектировать системы, которые минимизируют или устраняют оперативную переработку, а также обеспечивают постоянный контакт между разработчиками продуктов и оперативной стороной сервиса. Регулярные рабочие совещания между SRE и командой разработчиков (см. главу 31) также полезны.
Мы выяснили, что в состав дежурной команды должны входить как минимум восемь человек, чтобы можно было избежать переутомления, а также поддерживать постоянный штат и низкую текучесть. Предпочтительно размещать этих дежурных в двух значительно отдаленных географически местах (к примеру, в Калифорнии и Ирландии), чтобы избавить их от ночных вызовов. В этом случае минимальный состав команды — шесть человек на каждой стороне.
Ожидайте иметь дело не более чем с двумя событиями за дежурство (или за каждые 12 часов): на реагирование и устранение отключений, начало изучения и документирование обнаруженных ошибок требуется время. Более частые события могут снизить качество реагирования и свидетельствуют о том, что что-то неладно с конструкцией системы, чувствительностью системы контроля или с реакциями на обнаруженные ошибки.
Как это ни парадоксально, если вы учтете эти практические рекомендации, команда SRE в конечном счете может остаться без практики реагирования на инциденты ввиду их нечастого возникновения и краткий сбой превратится в длительный. Упражняйтесь в устранении гипотетических сбоев (см. подраздел «Катастрофа: ролевая игра» раздела «Пять приемов для вдохновления дежурных работников» главы 28) в рабочем порядке и в процессе улучшайте документацию, касающуюся инцидентов.
Войти с помощью соц. сетей: