Джин Ким - Руководство по DevOps

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

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

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

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

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

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

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

Отличный пример анализа телеметрии для проактивного поиска ошибок до того, как они повлияют на клиентов, — компания Netflix, крупнейший провайдер фильмов и сериалов на основе потокового мультимедиа. В 2015 г. доход Netflix от 75 миллионов подписчиков составлял 6,2 миллиарда долларов. Одна из ее целей — обеспечить наилучшие впечатления от просмотра видео онлайн во всех уголках земного шара. Для этого нужна устойчивая, масштабируемая и гибкая инфраструктура. Рой Рапопорт описывает одну из сложных задач управления облачной службой доставки видео: «Допустим, у вас есть стадо скота. В нем все должны выглядеть и вести себя одинаково. Какая корова отличается от остальных? Или, более конкретно, у нас есть вычислительный кластер с тысячью узлов. Они не фиксируют свое состояние, на них работает одно и то же программное обеспечение, и через них проходит один и тот же объем трафика. Задача в том, чтобы найти узлы, не похожие на остальные».

Одной из статистических методик, использованных в Netflix в 2012 г., было обнаружение выбросов. Виктория Ходж и Джим Остин из Йоркского университета определяют ее как обнаружение «аномальных рабочих состояний, приводящих к значительному ухудшению работоспособности, например дефект вращения двигателя самолета или нарушение потока в трубопроводе».

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

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

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

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

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

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