Сезон встреч и конференций продолжается

Performance Conf собиралась уже двенадцатый раз и стала местом встречи инженеров и менеджмента непосредственно связанных с высокими нагрузками. В этом году было три трека: нагрузочный, эксплуатационный и online-only трек для тех, кто не смог приехать на конференцию лично. Было забавно смотреть на ноуте выступление спикера из комнаты рядом.

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

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

Как обычно первое и самое главное при изменении масштаба системы это ее понятность и прозрачность.

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

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

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

Почему нагрузочное необходимо, а просто посмотреть в мониторинг недостаточно?

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

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

И это только самая простая часть работы - техническая. Дальше будет интереснее.

@downtime_bar #SRE@downtime_bar