Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

У многих реальных наборов данных распределение не нормально. Николь Форсгрен объясняет: «В эксплуатации у многих наших комплектов данных так называемое распределение хи-квадрат. Использование стандартных отклонений для них не только приводит к чрезмерному или недостаточному количеству оповещений, но и просто выдает бессмысленные результаты». Далее, Николь отмечает: «Когда вы считаете число одновременных скачиваний, которое на три стандартных отклонения меньше среднего, вы получаете отрицательное число. А это явно бессмысленно».

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

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

Практический пример

Автоматическая масштабируемость ресурсов, Netflix (2012 г.)

Еще один инструмент, разработанный в Netflix для улучшения качества услуг, Scryer, борется с некоторыми недостатками сервиса Auto Scaling[119] компании Amazon (далее — AAS), который динамически увеличивает и уменьшает количество вычислительных серверов AWS[120] в зависимости от данных по нагрузке. Система Scryer на основе прошлого поведения пользователя предсказывает, что именно ему может потребоваться, и предоставляет нужные ресурсы.

Scryer решил три проблемы AAS. Первая заключалась в обработке резких пиков нагрузки. Поскольку время включения инстансов AWS составляет от 10 до 45 минут, дополнительные вычислительные мощности часто загружались слишком поздно, чтобы справиться с пиковыми нагрузками. Суть второй проблемы в следующем: после сбоев быстрый спад пользовательского спроса приводил к тому, что AAS отключал слишком много вычислительных мощностей и потом не справлялся с последующим увеличением нагрузки. Третья проблема — AAS не учитывал в расчетах известные ему паттерны использования трафика.

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

Рис. 32. Пользовательский спрос в течение пяти дней, по данным компании Netflix (источник: Дэниэл Джейкобсон, Дэнни Юан и Нирадж Джоши, “Scryer: Netflix’s Predictive Auto Scaling Engine,” The Netflix Tech Blog, 5 ноября 2013 г., http://techblog.netflix.com/2013/11/scryer-netflixs-predictive-auto-scaling.html)