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

На конференции Monitorama в 2014 г. Туфик Бубе поведал о мощности методик по выявлению аномалий, особо подчеркивая эффективность теста Колмогорова — Смирнова. Его часто используют в статистике для определения значимости различий между двумя наборами данных (его можно найти в таких популярных инструментах, как Graphite и Grafana). Цель разбора этого практического примера — не показать алгоритм решения какой-то проблемы, а продемонстрировать, как класс определенных статистических методик можно использовать в работе и как он используется в нашей организации в совершенно разных приложениях.

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

Рис. 35. Количество транзакций: отсутствие нужного оповещения при использовании правила трех отклонений (источник: Туфик Бубе, “Simple math for anomaly detection”)

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

«Даже просто сказать слова “Колмогоров — Смирнов” — отличный способ всех впечатлить, — шутит Бубе. — Но вот о чем инженеры эксплуатации должны сказать специалистам по статистике, так это то, что эти непараметрические критерии отлично подходят для данных со стадии эксплуатации, потому что не нужно делать никаких допущений о нормальности или других свойствах распределения. А ведь крайне важно понять, что же происходит в наших сложных системах. Пользуясь методиками, мы сравниваем два вероятностных распределения, в данном случае периодические и сезонные данные. Это помогает нам найти отклонения в ежедневно или еженедельно меняющихся данных».

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

Рис. 36. Количество транзакций: использование теста Колмогорова — Смирнова для оповещения об аномалиях (источник: Туфик Бубе, “Simple math for anomaly detection”)

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

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

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

В 2006 г. Ник Галбрет был техническим директором в компании Right Media, отвечавшим и за разработку, и за эксплуатацию одной платформы онлайн-рекламы, отображавшей и обслуживавшей более 10 миллионов показов в день.

Галбрет так описывает конкурентную среду, где ему приходилось функционировать:

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

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

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

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

«Начинаем мы с того, что никто в разработке или эксплуатации не хочет нажимать на кнопку “развертывание кода”. Эту кнопку мы разработали специально для автоматизации процесса внедрения кода. Страх, что именно ты окажешься тем, из-за кого сломается вся производственная система, парализует всех сотрудников до единого. В конце концов находится смелый доброволец, решающийся первым вывести свой код в производственную среду. Но из-за неверных предположений или невыявленных тонкостей первое развертывание неизбежно идет не так гладко, как хотелось бы. И, поскольку у нас нет достаточной телеметрии, о проблемах мы узнаем от заказчиков».

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