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

Определения

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

Мониторинг

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

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

Мониторинг основан на показателях, отображаемых внутренними компонентами системы, включая журналы, интерфейсы, такие как интерфейс профилирования виртуальной машины Java, или обработчик HTTP, который выпускает внутреннюю статистику.

Мониторинг черного ящика

Тестирование внешне видимого поведения (что и как пользователь увидит).

Панель приборов

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

Предупреждение (оповещение)

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

Первопричина

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

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

Узел  и машина

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

• Связанные друг с другом: например, сервер кеширования и веб-сервер
• Не связанные службы обмена оборудованием: например, репозиторий кода и мастер для системы конфигурации, такой как  Puppet или Chef

Push

Любое изменение программного обеспечения или его конфигурации.

Зачем проводить мониторинг?

Существует множество причин для мониторинга системы, в том числе:

Анализ долгосрочных тенденций

Насколько велика моя база данных и насколько быстро она растет? Как быстро растет число пользователей, работающих ежедневно?

Сравнение скорости

Бывают ли запросы быстрее с Acme Bucket of Bytes 2.72 по сравнению с Ajax DB 3.14? Насколько лучше моя скорость попадания в memcache с дополнительным узлом? Мой сайт медленнее, чем на прошлой неделе?

Предупреждения

Что-то сломано, и необходимо исправить это прямо сейчас! Или что-то скоро сломается, поэтому нужно посмотреть в ближайшее время.

Построение приборных панелей

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

Проведение специального ретроспективного анализа (т. е. отладки)

Наше время ожидания просто взлетело; что еще произошло примерно в то же время?

Мониторинг системы также полезен для предоставления новых данных для бизнес-аналитики и для облегчения анализа нарушений безопасности.

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

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

Установление разумных ожиданий для мониторинга

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

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

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

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

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

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

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

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

«Что» по отношению к «почему» является одним из самых важных различий в создании хорошего мониторинга с максимальным сигналом и минимальным шумом.

Черный ящик против белого ящика

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

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

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

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

Четыре Золотых Сигнала

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

Латентность (задержка)

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

Трафик

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

Ошибки

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

Насыщенность

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

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

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

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

Беспокойство об утилите tail (или инструментарий и производительность)

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

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

Выбор подходящего разрешения для измерений

Различные аспекты системы должны измеряться с разной степенью детализации. Например:

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

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

• записывать текущее использование ЦП каждую секунду.
• использовать ведра с 5% -ной детализацией, каждый раз увеличивая требуемый объем загрузки процессора.
• агрегировать эти значения каждую минуту.

Эта стратегия позволяет вам выявлять короткие горячие точки  ЦП без высоких затрат на сбор и хранение.

Как можно проще

Наложение всех этих требований друг на друга может привести к очень сложной системе мониторинга. В конечном итоге ваша система может “обрасти” следующими уровнями сложности:

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

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

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

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

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

Связывание этих принципов вместе

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

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

• Обнаруживает ли это правило ранее не выявленное состояние, которое должно быть срочно и неизбежно показано пользователю для побуждения его к активным и безотлагательным действиям?
• Смогу ли я когда-нибудь игнорировать это предупреждение, зная, что это не опасно? Когда и почему я могу игнорировать это предупреждение и как я могу избежать этого сценария?
• Точно ли это предупреждение означает, что пользователь подвергается   негативному воздействию? Существуют ли обнаруживаемые случаи, когда пользователи не подвергаются ему, например, перегруженный трафик или тестовые развертывания, которые следует отфильтровать?
• Могу ли я принять меры в ответ на это предупреждение? Эти меры срочные или они могут подо ждать? Можно ли безопасно автоматизировать такие меры? Будет ли это долгосрочным или лишь краткосрочным обходным решением?
• Получают ли другие пользователи постраничные ответы на эту проблему? Возможно отправка одной из страниц является необязательной?

Эти вопросы отражают фундаментальную философию о страницах и пейджерах:

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

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

Мониторинг в долгосрочной перспективе

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

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

Bigtable SRE: рассказ о чрезмерных предупреждениях

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

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

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

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

Gmail: предсказуемые, сценарируемые ответы от людей

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

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

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

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

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

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

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

Заключение

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

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

No Comments