• Главная
  • Контакты
Подписаться:
  • Twitter
  • Facebook
  • RSS
  • VK
  • PushAll

logo

  • Все
    • Положительные
    • Отрицательные
  • За сегодня
    • Положительные
    • Отрицательные
  • За вчера
    • Положительные
    • Отрицательные
  • За 3 дня
    • Положительные
    • Отрицательные
  • За неделю
    • Положительные
    • Отрицательные
  • За месяц
    • Положительные
    • Отрицательные
  • За год
    • Положительные
    • Отрицательные
  • Сортировка
    • По дате (возр)
    • По дате (убыв)
    • По рейтингу (возр)
    • По рейтингу (убыв)
    • По комментам (возр)
    • По комментам (убыв)
    • По просмотрам (возр)
    • По просмотрам (убыв)
Главная
  • Все
    • Положительные
    • Отрицательные
  • За сегодня
    • Положительные
    • Отрицательные
  • За вчера
    • Положительные
    • Отрицательные
  • За 3 дня
    • Положительные
    • Отрицательные
  • За неделю
    • Положительные
    • Отрицательные
  • За месяц
    • Положительные
    • Отрицательные
  • Главная
  • Управление мощностями ? та ещё задачка

Управление мощностями ? та ещё задачка +5

24.04.2017 16:45
ITSystemsManagement 0 1600 Источник
Серверное администрирование*, Серверная оптимизация*, IT-инфраструктура*, Блог компании Инфосистемы Джет
Отлично, когда ваше ИТ-детище сталкивается с ростом выручки, пользователей, CTR, обрабатываемых документов, кредитных заявок, количества филиалов и прочих приятно почесывающих ЧСВ вещах. Все эти штуки называются бизнес-драйверами, которые в правильной ситуации коррелируют с нагрузкой на ИТ-инфраструктуру, расположенной под вашим сервисом. Правильное планирование мощностей защитит вас от epic fails в чёрную пятницу (чтобы она не стала действительно чёрной ;)) и ваш бюджет во все остальные дни. Сегодня поговорим не о самом процессе управления мощностями, а о технической стороне вопроса. Расскажу, при помощи каких отчетов можно прикидывать тренды и строить корреляционные матрицы. Давайте вкратце расскажу какой опыт мы скопили, а все вопросы задавайте в комментариях или личным сообщением. Поехали!
cost_risk_balance



Первый метод оценки ? временной анализ. Сам по себе он бывает нескольких видов.

1. Производительность во времени (PTA – Performance vs Time analysis) –показывает значения одной или более метрик производительности за выбранный интервал времени. Ещё можно визуализировать несколько метрик, принадлежащих к различным системам в разных масштабах.

Основными задачами этого типа анализа являются:

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


pta_analyse

Пример временного анализа с визуализаций 3 метрик – загрузок ЦПУ, оперативной и дисковой памяти

2. Нагрузка во времени (LTA – Load vs Time analysis) – показывает поведение одной или нескольких бизнес-метрик в выбранный интервал времени. Примером является количество сделок в течение определенного периода времени.

Основные задачи LTA:

  • провести анализ и выбрать бизнес-метрики по следующим критериям:
    • значимость приложений,
    • зависимость между бизнес-метриками;

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


pta_analyse_business_metrics

Пример временного анализа бизнес-метрик

3. Анализ конфигураций (CA — configuration analysis) – показывает исторические значения конфигурации конечных серверов и т.п. за выбранный период времени.

pta_analyse_infrastructure

Пример временного анализа конфигураций аппаратного комплекса

Второй метод оценки — корреляционный анализ.

При анализе данных создаются связки между бизнес-драйверами и технологическими ресурсами в соответствии с коэффициентом корреляции. Коэффициент корреляции ? это такой зверь, который показывает степень взаимосвязи двух метрик и может принимать значения от -100% (полная обратная зависимость) до +100% (полная прямая зависимость). Значение равное 0 (и близкое к нему) показывает отсутствие зависимости между парой метрик.

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

depending_metrics

Пример зависимостей метрик

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

business_metrics_map

Пример карты бизнес-метрик

metrics_correlation

Расчет корреляции значений параметров производительности и бизнес-метрик

В результате выявляется степень загрузки бизнес-метриками конкретных ресурсов на конкретных серверах:

resource_load

Степень загрузки ресурсов нагрузкой бизнес-метрик

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

PLA

Зависимость и точка насыщения общего количества запросов в бизнес-системе к загрузке CPU

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

LLA

Пример сравнения двух бизнес-метрик (количество заходов на сайт против количества просмотренных страниц

comparison

Пример сравнения метрик производительности

И, наконец, третий тип оценки ? расчет трендов.

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

Ниже на рисунке представлена модель возможного использования данного механизма. В систему загружены исторические данные по загрузке исходящего канала связи. Для этого параметра выставлено пороговое значение – 70% загрузки канала от максимально возможного. С помощью механизма экстраполяции автоматически выстраивается тренд динамики роста параметра и определяется время насыщения (достижения порогового значения) – менее 1 календарного месяца.

trend_calculation

Пример использования расчета тренда для определения времени насыщения

Такой инструмент также используется для проведения «что-если» анализа. К примеру, ниже представлен вариант сценария по расчету увеличения общего дискового пространства. На графике зеленым показан выделенный объем и точка увеличения дискового пространства (середина марта). Синим – график использования дискового пространства. Таким образом, построенный тренд и «что-если» анализ (добавление диска) показывают, что точка насыщения не наступит до конца года.

what_if

Вариант сценария по расчету увеличения общего дискового пространства

«Что-если» анализ также используется для расчета показателей работы ИТ-инфраструктуры в зависимости от изменяемых значений бизнес-метрик.

На рисунке ниже приведен пример расчета максимально возможных показателей заходов в систему и количества отправляемых заказов. В первой части таблицы указаны бизнес-метрики (Visits, Orders Received) и их текущие значения (30 000 заходов в час и 1 000 заказов). В графе Target указываются проверяемые значения параметров (120 000 и 5 000). В результате можно рассчитать максимальную нагрузку на инфраструктуру (61 500 и 2 400 соответственно), а также видна точка отказа – производительность CPU (красная точка на таблице внизу).

point_of_failure

Пример расчета максимально возможных показателей заходов в систему и количества отправляемых заказов

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

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

В конце поста есть пара опросов, будет здорово, если вы сможете уделить на них пару десятков секунд. Спасибо!

Автор статьи: Антон Касимов, архитектор систем управления, компания «Инфосистемы Джет».
Расскажите, как вы управляете мощностями

Проголосовало 12 человек. Воздержалось 7 человек.

Внедрен ли у вас в компании ITIL-процесс управления мощностями?

Проголосовало 10 человек. Воздержалось 6 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Поделиться с друзьями
-->

Комментарии (0)

МЕТКИ

  • Хабы
  • Теги

Серверное администрирование

Серверная оптимизация

IT-инфраструктура

Блог компании Инфосистемы Джет

ит-инфраструктура

управление мощностями

инфосистемы джет

СЕРВИСЫ
  • logo

    CloudLogs.ru - Облачное логирование

    • Храните логи вашего сервиса или приложения в облаке. Удобно просматривайте и анализируйте их.
Все публикации автора
  • Управление мощностями ? та ещё задачка +5

    • 24.04.2017 16:45

    Удобная памятка и 8 ссылок на документацию по ГОСТ 34 (автоматизированные системы) +8

    • 17.02.2017 03:20

    Gartner выкатил новый магический квадрант для систем мониторинга +8

    • 19.01.2017 12:24

    Декомпиляция Java-методов на продуктивном приложении под нагрузкой – миф или реальность? +7

    • 10.11.2016 07:06

    Тестируем не совсем реальный (или совсем нереальный) мониторинг от New Relic и Appdynamics +7

    • 20.10.2016 16:39

    Как приготовить тосты и заодно визуализировать ИТ-системы +10

    • 03.10.2016 23:20

Подписка


ЛУЧШЕЕ

  • Сегодня
  • Вчера
  • Позавчера
05:26

One-shot промптинг. Как я начал вайбкодить в 10? раз быстрее +73

08:05

Самодельная паяльная станция с цифровой индикацией температуры на жесткой логике +46

08:00

Всё везде и сразу +39

08:34

Лабиринты текста как игровая механика, или как неэкранизируемая литература становится источником геймдизайна +33

06:54

Picodata: вторая жизнь in-memory баз данных +27

05:15

Как я разработал расширение для браузера за 3 дня — и получил первого платного пользователя уже на следующий день +26

07:58

Я нашёл огромную дыру в дейтинг-приложении, а разработчики попытались её скрыть +24

09:01

ЦОД 2050: три реалистичные концепции развития дата-центров +21

13:01

Введение в RawTherapee +20

14:45

Переходим от legacy к построению Feature Store +18

13:00

Массовые увольнения в российском IT: что на самом деле происходит в компаниях — взгляд CEO +18

09:34

Криптография эпохи Ренессанса: классика не стареет +18

07:00

LLM as a Judge: опыт оптимизации генератора описаний Pull Request +16

09:18

Распродажа в издательстве «Питер» +15

14:12

Как я сменил лопату на клавиатуру: мой путь в IT после 30 +14

04:56

Кто выполняет функции системного аналитика в США? +14

10:57

Вселенная дистрибутивов Linux: От Ubuntu до Arch, от Mint до Fedora – подробный гид по выбору +13

07:00

Электрокэбы, полный привод и гонки: история дореволюционного автопрома +13

06:09

Left Shift Testing: как выстроить процесс, чтобы тесты реально помогали +13

07:01

Финансовый учет: всё и немного больше про проводки +12

14:22

Ещё 10 ошибок авторов Хабра +136

07:43

Больше нет входа в IT. Только выход +70

14:15

Мое производство электрощитов приносит 40 млн в год. Спасибо нейросетям и СССР за конструкторскую школу +60

05:16

Дело о Транзитроне — или Ламповый тьюториал для любопытных +48

08:01

Трамплин в интернет: как мы ускорили запуск Яндекс Браузера +44

13:06

Введение в Angie: краткая история и отличия от Nginx +42

03:22

Как за один вечер создать репутацию вашего стартапа в поисковой выдаче: 20 бесплатных площадок для быстрого буста +38

08:35

Распределённый инференс и шардирование LLM. Часть 1: настройка GPU, проброс в Proxmox и настройка Kubernetes +37

07:00

DevOps без боли: 8 инструментов для мониторинга, автоматизации и стабильной работы команд +33

16:15

Как я написал эмулятор Nintendo Gameboy на C++ за две недели +32

13:01

Как создавались вокальные эффекты Daft Punk +32

12:00

Story Points не работают? И другие мифы про оценку задач, в которые мы почему-то верим +32

06:53

Важное обновление BatteryTest 2 +32

04:53

Баффет наконец накопил достаточно для выхода на пенсию, а в OpenAI выкатили новый хитрый план +26

10:26

От релиз-менеджера до разработчика: почему я ушел из QA и не жалею +25

10:09

Как настраивать сети: готовые решения Selectel для максимальной отказоустойчивости +25

09:01

Почему из технологий делают культы +24

09:31

Как ESLint помогает управлять архитектурой проекта +23

08:57

Разбор полётов: что умеет отечественная СХД Аэродиск AQ440 +22

15:16

Бирюзовые компании в РФ: как не посинеть в найме +21

ОБСУЖДАЕМОЕ

  • Больше нет входа в IT. Только выход +70

    • 480   118000

    Мое производство электрощитов приносит 40 млн в год. Спасибо нейросетям и СССР за конструкторскую школу +60

    • 150   58000

    Массовые увольнения в российском IT: что на самом деле происходит в компаниях — взгляд CEO +18

    • 139   26000

    Ещё 10 ошибок авторов Хабра +136

    • 125   6900

    Дело о Транзитроне — или Ламповый тьюториал для любопытных +48

    • 61   4700

    One-shot промптинг. Как я начал вайбкодить в 10? раз быстрее +73

    • 51   16000

    Бирюзовые компании в РФ: как не посинеть в найме +21

    • 49   45000

    Трамплин в интернет: как мы ускорили запуск Яндекс Браузера +44

    • 46   4100

    Быстрый алгоритм fulltext-поиска без токенизации +15

    • 41   2300

    Шесть лет на диване: мои выводы об удалённой работе -2

    • 38   12000

    Разбираем архитектуру. Часть 2. Чистая архитектура на примере FastAPI приложения +3

    • 32   3200

    Самодельная паяльная станция с цифровой индикацией температуры на жесткой логике +46

    • 31   3600

    Почему «Agile» и особенно Scrum ужасны +1

    • 31   3000

    Почему рекрутеры игнорят отклики? +1

    • 28   2100

    Последний звонок: прощаемся со Skype +17

    • 27   8100
  • Главная
  • Контакты
© 2025. Все публикации принадлежат авторам.