6. Мониторинг распределенных систем

Автор — Роб Иващук

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

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

Определения

В области мониторинга не существует единого словаря терминов — даже в компании Google используемая терминология может различаться. Самые распространенные определения перечислены ниже.

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

• Наблюдение методом белого ящика. Наблюдение с использованием показателей, доступных внутри системы, включая журналы, интерфейсы вроде Java Virtual Machine Profiling Interface или обработчики HTTP, которые предоставляют внутреннюю статистику.

• Наблюдение методом черного ящика. Наблюдение и проверка (тестирование) поведения, видимого извне, с точки зрения пользователя.

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

• Оповещение («алерт»). Сообщения, на которые должен обратить внимание человек и которые направляются в конкретную систему, например в очередь запросов («тикетов»), в электронную почту или на специальное устройство — пейджер. Соответственно, оповещения делятся на «тикеты» (оповещения по электронной почте) и вызовы (экстренные оповещения).

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

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

• связаны друг с другом: например, сервер кэширования и веб-сервер;

• не связаны друг с другом, но могут совместно использовать одно и то же оборудование: например, репозиторий кода и мастер конфигурационной системы вроде Puppet () или Chef (/).

• Установка версии (push). Любые изменения, производимые в ПО работающего сервиса или его конфигурации.

Зачем нужен мониторинг

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

• Анализ долгосрочных тенденций. Насколько велика база данных и как быстро она растет? Как быстро увеличивается количество пользователей с ежедневной активностью?

• Сравнение с предыдущими версиями или экспериментальными группами. Выполняются ли запросы быстрее с помощью Acme Bucket of Bytes 2.72 по сравнению с Ajax DB 3.14? Насколько улучшится коэффициент попаданий поисковых запросов в кэш, если добавить дополнительный узел? Работает ли сайт сегодня медленнее, чем на прошлой неделе?

• Оповещение. Что-то сломалось, и кто-то должен исправить это прямо сейчас. Или же что-то может скоро сломаться, и кто-то должен будет этим заняться.

• Создание информационных панелей. Информационные панели должны содержать ответ на главные вопросы о вашем сервисе, и это обычно так называемые четыре золотых сигнала в том или ином виде (эта тема рассматривается далее, в разделе «Четыре золотых сигнала»).

• Ретроспективный анализ различного назначения (например, отладка). Время отклика в нашей системе только что возросло; что еще случилось в это же время?

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

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

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

Ставим для мониторинга реальные задачи

Наблюдение за крупным приложением — сложная инженерная задача. Даже имея подходящую инфраструктуру для измерений, сбора данных, их отображения и оповещения о проблемах, команда SRE, состоящая из 10–12 человек, обычно выделяет одного сотрудника (иногда двух), чьей основной задачей становится создание и обслуживание системы мониторинга для их сервиса. Количество привлекаемых сотрудников снижалось по мере того, как мы обобщали и централизовали инфраструктуру для мониторинга, но в каждой команде SR-инженеров все равно имеется хотя бы один «наблюдатель». (При этом, впрочем, хотя наблюдать информационные панели с объемами трафика и прочей информацией бывает интересно, команды SR-инженеров старательно избегают ситуаций, когда кому-то приходится «смотреть на экран и искать проблемы».)

В компании Google предпочитают создавать простые и быстрые системы мониторинга с качественными инструментами для анализа состояния «по факту». Мы избегаем «магических» систем, которые пытаются самостоятельно исследовать пороговые значения или причинно-следственные связи. Исключением являются правила, которые обнаруживают неожиданные изменения на уровне запросов конечных пользователей. Оставаясь несложными (насколько это возможно), эти правила позволяют быстро обнаруживать аномалии — наиболее простые, наиболее серьезные или отдельные специфические их виды. При других вариантах использования данных мониторинга, например при планировании производительности и прогнозировании трафика, можно допустить меньшие точность и оперативность и, соответственно, задействовать более сложные алгоритмы. Длительное (проводимое на протяжении месяцев или лет) наблюдение с низкой частотой выборки (часы или дни) также обычно устойчиво к погрешностям, поскольку случайный пропуск выборок не может исказить долгосрочные закономерности.

Отдел SRE компании Google лишь ограниченно работает со сложными иерархиями зависимостей. Мы редко используем правила вроде: «Если я знаю, что база данных работает медленно, то сообщить о медленной базе данных; иначе сообщить о том, что сайт работает медленно сам по себе». Правила, построенные на зависимостях, обычно относятся к очень стабильным частям нашей системы. Пример этого — система для отвода пользовательского трафика из дата-центра. Так, общим для всех дата-центров является правило «Если дата-центр пуст, то не сообщать мне о его задержке отклика». Однако некоторые команды SRE все же имеют дело со сложными иерархиями зависимостей, поскольку наша инфраструктура постоянно реорганизуется.

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

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

Симптомы и причины

Ваша система мониторинга должна отвечать на два вопроса: что сломалось и почему.

Ответ на вопрос «Что сломалось?» заключает в себе указание на симптом; ответ на вопрос «Почему?» — указание на причину (возможно, промежуточную). В табл. 6.1 перечислены некоторые гипотетические симптомы и соответствующие им причины.

Таблица 6.1. Примеры симптомов и причины, по которым они появляются

Симптом	Причина
Сервис возвращает ответы HTTP 500 или 404	Серверы базы данных отказывают в соединении
Ответы генерируются медленно	Процессоры перегружены из-за выполнения сортировки алгоритмом bogosort1 или заломлен кабель Ethernet под стойкой, что приводит к частичной потере пакетов
Пользователи в Антарктике не получают анимированные GIF-изображения с котиками	Ваша сеть доставки контента ненавидит ученых и представителей семейства кошачьих, поэтому поместила IP-адреса некоторых клиентов в черный список
Личные данные видны всему миру	При установке новой версии ПО были утеряны списки управления доступом (ACL), в результате чего всем пользователям предоставлен полный доступ

Причинно-следственная связь «что» и «почему» — это то, что должна выявлять хорошо сделанная система мониторинга с максимальным соотношением «сигнал/шум».

Методы черного и белого ящика

Для мониторинга мы широко используем метод белого ящика; метод черного ящика применяется редко, но не менее важен. Самый простой способ понять разницу между этими методами — представить метод черного ящика как наблюдение за симптомами, которое выявляет реально возникшие — а не спрогнозированные — проблемы: «В данный момент система работает некорректно». Метод белого ящика зависит от возможности исследовать систему изнутри (например, журналы или интерфейсы HTTP) с помощью каких-либо инструментов. Поэтому метод белого ящика позволяет обнаруживать будущие проблемы, замаскированные повторными попытками сбои и пр.

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

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

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

Четыре золотых сигнала

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

• Время отклика. Время, которое требуется для выполнения запроса. Очень важно различать задержки для успешных и неуспешных запросов. Например, код ошибки HTTP 500, вызванной потерей соединения с базой данных или каким-то критическим сбоем на стороне бэкенда, может быть возвращен очень быстро. Однако, поскольку ошибка HTTP 500 указывает на то, что запрос не был выполнен, учитывать такие результаты при подсчете общей задержки нельзя. С другой стороны, «медленная» (возвращенная с большой задержкой) ошибка даже хуже «быстрой»! Поэтому важно не просто фильтровать ошибки, но и анализировать задержку выполнения соответствующих запросов.

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

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

• Степень загруженности. Показатель того, насколько полно загружен ваш сервис. Эти измерения показывают те компоненты системы и те ресурсы, в которых вы ограничены больше всего (например, в системах, ограниченных в памяти, это память; в системах, ограниченных в возможностях ввода/вывода, — состояние подсистемы ввода/вывода). Обратите внимание, что многие системы теряют в производительности еще до того, как будут загружены на 100 %, поэтому следить за уровнем загрузки как за целевым показателем также очень важно.

Для сложных систем это может быть дополнено более высокоуровневыми оценками нагрузки: справится ли ваш сервис с удвоением трафика? Обработает ли он всего 10 % дополнительного трафика или даже снизит производительность? Если сервис простой и не имеет параметров, изменяющих сложность запроса (например, «Выдай случайное число» или «Мне нужна уникальная монотонная последовательность целых чисел»), то статичное значение, полученное в результате нагрузочного тестирования, может быть корректным. Однако, как мы говорили в предыдущем абзаце, для большинства сервисов приходится использовать косвенные показатели с известным верхним пределом, например процент загрузки процессора или пропускной способности сети. Часто первым индикатором «насыщения» системы становится увеличение времени отклика. Измерение 99-го процентиля времени отклика на небольших временных промежутках (например, за одну минуту) может послужить ранним предупреждением о намечающейся перегрузке.

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

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

Позаботимся о своем «хвосте» (или производительность измеряемая и наблюдаемая)

При проектировании системы мониторинга с нуля очень заманчивой может показаться идея использовать средние значения: среднюю задержку, средний процент загрузки процессора ваших узлов или среднюю заполненность ваших баз данных. Рискованность такой оценки в двух последних случаях очевидна: процессор и база данных могут использоваться очень неравномерно. То же верно и для задержек. Если вы запускаете веб-сервис, имеющий среднюю задержку отклика 100 миллисекунд при 1000 запросах в секунду, то обработка 1 % запросов может занять и 5 секунд. Если для формирования страницы нужно выполнить несколько подобных запросов, 99-й процентиль задержки отклика одного из серверов легко может стать средней задержкой для клиента.

Самый простой способ различить медленное среднее время обработки и очень медленные «хвостовые» запросы — вместо самих значений задержки использовать количество запросов, величина задержки для которых попадает в заданные интервалы, удобные для построения гистограммы: сколько запросов потребовали для обработки от 0 до 10 миллисекунд, от 10 до 30, от 30 до 100, от 100 до 300 и т.д. Построение гистограммы с примерно логарифмически расставленными границами интервалов (в нашем случае с основанием, приблизительно равным 3) — зачастую самый простой способ наглядно представить распределение характеристик ваших запросов.

Выбор подходящего уровня детализации для измерений

Для разных компонентов системы измерения должны проводиться с разным уровнем детализации.

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

• С другой стороны, если для веб-сервиса заявлено, что в течение года он будет отключен в общей сложности не более 9 часов (99,9 % времени доступности в год), то, по всей видимости, ежеминутная отправка 1–2 проверочных запросов лишь для того, чтобы получить код 200 (успех), будет излишней.

• Аналогично проверять заполненность жестких дисков каждые 1–2 минуты для системы с целевым значением доступности 99,9 %, скорее всего, не требуется.

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

1. Записывать текущий показатель загрузки процессора каждую секунду.

2. Создать заготовку для гистограммы с шагом 5 % и каждую секунду увеличивать значение для соответствующего столбца в зависимости от текущего показателя использования CPU.

3. Раз в минуту собирать итоговые данные.

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

Максимально просто, но не проще

Стремление выполнить все эти и многие другие требования сильно усложняет систему мониторинга. Можно выделить следующие уровни сложности:

• оповещение о достижении разных порогов задержки отклика и разных процентилей для всех видов показателей;

• дополнительный код для обнаружения и отображения возможных причин;

• соответствующие информационные панели для каждой из возможных причин.

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

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

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

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

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

По опыту Google, система мониторинга, которая просто собирает и агрегирует показатели, а также занимается оповещениями и созданием информационных панелей, работает как относительно самостоятельная система. (Фактически система мониторинга Google разбита на несколько отдельных программ, но обычно люди изучают их все.) Заманчиво было бы объединить систему мониторинга с другими контрольными функциями сложных систем вроде детализированного профилирования системы, однопроцессной отладки, отслеживания исключений и сбоев, тестирования нагрузки, сбора и анализа журнала или исследования трафика. Хотя все эти цели имеют много общего с лежащим в их основе мониторингом, объединение слишком большого количества результатов приведет к тому, что система станет слишком сложной и нестабильной. Как и во многих других случаях при разработке ПО, использование отдельных систем, имеющих четкие, простые и слабо связанные точки взаимодействия, — это наиболее удачная стратегия. Например, удобно использовать API веб-запросов для отправки результирующих данных в формате, который может долго оставаться неизменным.

Сводим все принципы воедино

Принципы, рассмотренные в этой главе, можно увязать друг с другом, получив своего рода философию мониторинга и оповещения, которой следуют команды Google SRE. Помимо прочего, эти положения являются хорошей отправной точкой для создания нового оповещения или пересмотра существующего. Это же поможет вам задавать правильные вопросы независимо от размера вашей организации или сложности вашего сервиса или системы.

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

• Позволяет ли правило выявить не обнаруживаемое иными средствами состоя­ние, которое требует быстрой реакции и последствия которого уже заметны (или обязательно станут заметными) пользователю?

• Смогу ли я проигнорировать это оповещение, зная, что оно не критическое? Когда и почему я смогу проигнорировать оповещение и как можно избежать этого варианта развития событий?

• Говорит ли это оповещение однозначно о том, что на пользователей уже оказывается какое-то негативное влияние? Можно ли распознать ситуации, при которых пользователи не страдают (например, при отводе трафика или развертывании тестов) и которые должны быть отфильтрованы?

• Могу ли я что-то предпринять в ответ на это оповещение? Нужно ли отреагировать немедленно, или же это может подождать до утра? Можно ли безопасно автоматизировать это действие? Будет ли это действие постоянным решением или временным?

• Приходит ли это оповещение другим инженерам? Это означало бы, что как минимум одно из них бесполезно.

Следующие вопросы отражают нашу позицию по экстренным оповещениям, передаваемым на пейджеры.

• Каждый раз, когда сигналит пейджер, я должен отреагировать немедленно, но осмысленно. Без переутомления я могу так реагировать всего несколько раз за день.

• Каждому оповещению должны соответствовать определенные ответные действия.

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

• Экстренное оповещение и вмешательство человека необходимы при появлении новой проблемы или ранее не встречавшегося события.

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

Долгосрочное наблюдение

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

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

Bigtable SRE: когда оповещений слишком много

Для оценки характеристик внутренней инфраструктуры компании Google обычно используется целевой уровень качества обслуживания (service level objective, SLO; см. главу 4). Много лет назад SLO в отношении сервиса Bigtable основывались на синтетических средних показателях производительности для «хороших» клиентов. Из-за проблем в самом этом сервисе и в нижних уровнях стека хранения данных среднее значение производительности портил большой «хвост»: худшие 5 % запросов обрабатывались значительно медленнее остальных.

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

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

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

Gmail: предсказуемые ответы человека

Изначально сервис Gmail был построен на базе модернизированной системы управления распределенными процессами Workqueue, которая создавалась для пакетной обработки фрагментов поискового индекса. Workqueue была адаптирована для работы с «долгоиграющими» процессами, и в итоге ее применили к сервису Gmail, но от некоторых ошибок в относительно непрозрачной базе кода планировщика было очень трудно избавиться.

В то время мониторинг сервиса Gmail был построен таким образом, что оповещениями сопровождался «вывод из расписания» отдельных задач сервиса Workqueue. Такой подход был далек от идеала, поскольку даже тогда Gmail уже имел многие тысячи задач, каждая из которых обслуживала лишь долю процента наших пользователей. Мы заботились о том, чтобы пользователям было комфортно работать с Gmail, но поддерживать такое количество оповещений было нереально.

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

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

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

Долгосрочная перспектива

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

Итоги главы

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

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