Что такое управление мощностью и как перестать расширяться авралом

Зачем управление мощностью и производительностью

Мощность — это потолок: сколько работы услуга или её часть способна тянуть, оставаясь в тех рамках, о которых договорились 4. Производительность — сколько она успевает на самом деле при сегодняшней нагрузке 1. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 существует ради того, чтобы услуга справлялась со спросом сегодня и завтра, а платили за это ровно столько, сколько нужно.

ITIL ставит практике три условия сразу: услуга работает с той скоростью, о которой договорились; спроса хватает и сегодня, и завтра; цена за это разумная 1.

ГОСТ Р ИСО/МЭК 20000-1 добавляет к этому план. В нём должно быть записано 2:

• сколько мощности услуга берёт сейчас и сколько возьмёт по прогнозу спроса;
• как на это повлияют цели по уровню услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation, доступности и непрерывности;
• в какие сроки и при каких порогах мощность меняют.

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

Практика меряется не запасом мощности, а тем, сколько раз за год пришлось добавлять её срочно.

Ещё одно свойство, которое отличает эту практику от соседних: она смотрит вперёд. Стандарт разводит две работы — управление спросом, которое определяет текущий и будущий уровень потребления, и управление мощностями, которое под этот спрос планирует ресурсы 2.

Когда практика работает

Три вопроса, ответы на которые ищут в плане, а не в мониторинге.

Известен спрос, а не только загрузка. Как проверить: есть оценка того, сколько операций услуга обслуживает сейчас и сколько будет через год. Загрузка процессора на такой вопрос не отвечает.

Пороги заданы заранее. Как проверить: записано, при каком уровне использования запускается расширение и сколько времени оно занимает 2.

Расширения плановые, а не аварийные. Как проверить: считается число внеплановых расширений мощности за период — предлагается ровно этот показатель 1.

Что входит и что рядом

Мощность в облаке: та же практика, другие рычаги

Облако сместило вопросы практики, но саму её оставило на месте.

Раньше главным был вопрос «сколько купить и когда» — с длинным сроком поставки и капитальными затратами. Теперь мощность добавляется за минуты, и главными становятся два других вопроса: при каком условии расширяемся автоматически и сколько это стоит в месяц.

ITIL говорит это прямо: среди результатов работы практики он называет настроенные пороги, оповещения и, где это уместно, автоматическое масштабирование с распределением нагрузки 1.

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

Что на входе и что на выходе

Смысл связей здесь в двух направлениях времени. Назад — данные о том, что происходило: загрузка, задержки, отказы. Вперёд — планы: сколько понадобится и когда.

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

Что считать плохой производительностью

До подписания соглашения договариваются 1:

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

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

Как это работает

Работа делится надвое: сначала ставят контроль мощности и производительности, потом разбирают накопленное и улучшают 1.

Установить контроль мощности и производительности — работа до запуска и при крупных изменениях: собрать требования, согласовать их, определить, как измерять, настроить показатели, пороги, оповещения и, где уместно, автоматическое масштабирование 1.

Анализировать и улучшать — работа после: сравнивать с целями, искать узкие места, планировать расширение, предлагать изменения.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение работа с людьми и сторонами

«Свободный ITIL» называет главным результатом практики план обеспечения мощностей 4. В плане два раздела: как будет расти спрос по нескольким сценариям и во сколько обойдётся угнаться за ним. Там же полезное разделение горизонтов — планирование краткосрочное, среднесрочное и долгосрочное 4.

Откуда берут данные

Источники и их слабости перечислены честно 1.

Записи об инцидентах. Годятся как сигнал, но получить по ним надёжные данные о производительности трудно, особенно если инцидентыИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами заводили пользователи 1.

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

Наблюдение за реальными пользователями и бизнес-операциями. Только оно и закрывает разрыв между «сервер не загружен» и «заказ оформляется минуту» 1.

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

Что с чем путают

Мощность и производительность. Мощность — предел, производительность — то, что происходит при текущей нагрузке 1. Запас мощности не даёт скорости, если упирается всё в другое.

Мощность и доступность. Медленная услуга формально работает. Границу между «медленно» и «не работает» проводят заранее. Проводит её AVLУправление доступностью, а данные для разговора даёт эта практика 1.

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

Планирование мощности и закупка железа. Закупка — один из способов. Остальные: оптимизация кода, изменение архитектуры, распределение нагрузки, ограничение потребления.

Кто участвует

Практика особенно важна на стадии замысла и проектирования: решения этих стадий определяют пределы производительности и саму возможность наблюдать за ней 1.

Как измерять

Два показателя стоит держать вместе: время отклика по критичным операциям и число внеплановых расширений. Первое показывает, что чувствует пользователь, второе — насколько практика предвидит, а не догоняет.

Избыток мощности — такой же дефект, как нехватка. Практика привычно оправдывается запасом, а Брукс меряет запас отдельным показателем: доля избыточной производительности, цель 20%, тревога 30% 7. Обоснование у него короткое — слишком высокая мощность стоит денег. Рядом соотношение общей загрузки ресурсов с той, что заложена в плане: цель 80%, тревога 85% 7. Вместе они превращают разговор о запасе из «на всякий случай» в число, у которого есть обе границы.

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

Нехватка ловится тремя разными числами. Нарушения договорённостей из-за медленной работы и из-за слабого компонента Брукс считает порознь, и у обоих целевое значение — ноль при тревоге в два случая 7. Третье число — инциденты, у которых причиной при закрытии указана производительность: цель 5, тревога 10. Тут он честно оговаривает ограничение: считать это можно, только если INCУправление инцидентами и PRBУправление проблемами доросли до разбора причин, — иначе показатель говорит не о мощности, а о привычках тех, кто закрывает заявки.

Без наблюдения практика слепа, и слепоту тоже меряют. Доля элементов конфигурацииЭлемент конфигурацииЛюбой объект, которым надо управлять, чтобы предоставлять услугу: сервер, приложение, лицензия, документ.ITIL, за производительностью которых следят: цель 70%, тревога 60% 7. Если ключевые серверы выпали из наблюдения, планировать не из чего — тенденций просто нет. Числа Брукса здесь и выше — образцы для настройки, а не отраслевая норма; переносится привычка держать у показателя цель и порог вмешательства.

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

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Меряют железо, а не операции. Графики загрузки зелёные, оформление заказа занимает минуту.

Плана мощности нет. Расширение обсуждается тогда, когда услуга уже упёрлась. Стандарт требует планировать текущую и прогнозируемую мощность вместе со сроками и порогами 2.

О будущей нагрузке не спрашивают бизнес. Прогноз строят по прошлым графикам, а маркетинг тем временем готовит акцию, о которой ИТ узнаёт из новостей.

Пороги не заданы. Известно, что «загрузка высокая», но при каком значении что делать — вопрос без ответа.

Автоматическое масштабирование без ограничителя. Настроили расширение, забыли верхнюю границу, получили счёт.

Считают средние. Средний отклик выглядит хорошо, а четверть пользователей ждёт втрое дольше 1.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL соединяет мощность и производительность в одну практику и строит её вокруг трёх факторов успехаФактор успеха практикиТо, что должно быть верно, чтобы практика выполняла своё назначение.ITIL Service Operation, раздел 4.2.8: выявить требования, измерять и сообщать, обрабатывать риски 1.

ГОСТ Р ИСО/МЭК 20000-1 разводит спрос и мощность по разным пунктам и требует плана с прогнозом, влиянием целей уровня услуг и порогами изменения мощности 2.

FitSM обходится четырьмя требованиями: знать, что от услуги требуется — по соглашениям и прогнозу спроса; знать, сколько мощности расходуется сейчас; планировать будущую мощность, считая людей, технику и деньги; разбирать производительность по данным наблюдения 3.

COBIT держит мощность вместе с доступностью в одной цели управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives 5.

MOF относит план мощностей к планам надёжности, создаваемым на этапе планирования 6.

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

Где описано

Что почитать дальше

Три соседние практики, с которыми мощность считают вместе: AVLУправление доступностью — где проходит граница между медленно и не работает, EVNМониторинг и управление событиями — откуда берутся данные о загрузке, CBMУправление бюджетом и стоимостью — во что обходится запас.