Capacity planning — с чего начать? Чья это задача? Рабочие средства?

Question

[Александр]

Добрый день Коллеги,


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


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


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


Итого, вопросы:


1. Какой софт использоваться для планирования мощностей? CMDB все же достаточно статична для этого, Excel конечно универсален, но как то не энтерпрайз решение. Хочется что то с возможность интеграции в систему мониторинга (такая задача тоже есть).


2. Как разобрать общие ресурсы? Пока только одна идея — миграция в новое место, но это растянется на годы к сожалению.


3. Кто должен отвечать за общие ресурсы? Те кто их использует или предоставляет?


4. Если нет OLA/SLA между подразделениями, как обязать включать мозг при запросе и использование ресурсов? Сейчас никто не думает когда заливает в базу размером 100Гб еще столько же (хотя базу создавали год назад и просили лун размером 100Гб т.к. тогда она весила 10Гб).


Спасибо.


P.S. Если я не правильно выбрал хабы, прошу поправить, но вообще я долго перебирал их и вариант ITIL не нашел (зато увидел 999 хабов по отдельным языкам програмирования).

Answer 1

[Dmitri Kudryavtsev]

Задача решаема и при наличии ОТ даже почти бесплатно.
Первое, что надо сделать — выписать все замеченные сервисы, и для бизнеса (SLA) и междусобойные (OLA). Так удастся в дальнейшем выявить и обработать потребителей.

Затем напротив каждого пункта (сервиса) перечислить известные ресурсы, его обеспечивающие. Тоже всё просто, идти от железа вверх до ОСи и конечной прикладухи. Сеть или жизнеобеспечение тут учитывать рано, т.к. они в итоге всё равно делятся на всех и чтобы поделить правильно, надо отдельно мерить нагрузки, контуры вращения информации, её классифицировать, в общем, возиться…

Кстати, эти два шага в любой майндмеп проге удобно сделать.

На выходе получаем прообраз Р-С модели, но он пока неуправляем. Тут методов фактически нет: все ресурсы, создающие сервис суть активы, по ним придётся создать и вести учёт. Что может дискавериться — выбрать софт, которым — и регулярно дискаверить (аналог бухгалтерской инвентаризации), что не ловится автоматическим образом, но важно видеть — снимать слепки руками.

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

Проводите первичное наполнение CMDB, увязываете найденное с каталогом в ОТ и вуаля: осталось привязать потребителей и картина становится почти готовой.

Capacity не ведут без учета конфигураций, это еще со второго ITIL'а было очевидно.

По вопросам о ресурсах непонятно, о каких речь. Файловых? Тут если есть деньги можно хороших тулзов купить, ключевое словосочетание data governance, а вообще методически вы сейчас видите т.н. unstructured data, а цель — сделать из них structured. Это большой проект, не меньше capacity, а по подходу почти идентичный: посчитать, классифицировать, выявить потребителей, пожурналировать пользование и затем, набрав фактических данных, пересобрать структуру папок/ACL и правил работы с ними.

По последнему вопросу: лезть в тему внутренних SLA/OLA (есть еще и underpinning contracts, UC) сразу в ваш нынешний момент времени не советую. К учету должны привыкнуть, вы должны понять, что любые неавторизованные изменения конфигураций или использования ресурсов умеете ловить и насколько прозрачно и быстро.

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

Как-то так…

Answer 2

[strib]

1-2)Существует набор приложений Service Catalogue Management. Рекламировать не буду, но они отлично ищутся.
Этот процесс описывает иерархическую структуру услуг, начиная с продукта готового и до аппаратного уровня, и позволяет отслеживать все зависимости и ресурсы.

3) Что значит отвечает? Есть владелец ресурса, есть пользователи, у каждого свои права и обязанности которые регламентируются бизнес-процессом.

4) Улучшать коммуникацию между отделами.

Comments

[Александр]

1-2) Service Catalogue Management — честно говоря не понял ваш ответ. Да и я не готов браться за «иерархическую структуру услуг», хочу все же пошагово идти. У нас есть омнитрекер, в нем есть CMDB в которую загрузили данные из таблиц старого аудита, но базу никто не правил под нас, да и похоже требований не было с нашей стороны, если я возьму её за основу, то подвергну доработке конечно, но все равно она не очень годится для хранения исторических данных и тренды роста она строить не будет наверное.

3) В моем понимание, у каждого сервиса и ресурса должен быть владелец. Мне не нравятся ситуации когда чей то сервис потребляет ресурсов как половина компании, хотя и выполняет при этом тупое задание, а все потому что его не правильно настроили или не правильно выбрали и т.п. другими словами каждый должен понимать, что если он заказывает 16 ядер, 256Гб оперативки и 10Тб и 25000 IOPS то за это надо будет заплатить толстую пачку денег и это нужно будет обосновывать именно тому кто заказывает а не тому кто поддерживает инфраструктуру. Другими словами, есть вот шара сетевая, в ней данные приложений и пользователей, объем шары несколько терабайт. По возможности я буду разносить её по шарам отдельных приложений, но это долго и не всегда возможно, в общем подозреваю что такие вот общие ресурсы еще долго будут, вот и думаю кого назначить их владельцем. Бизнес процессов нет.

4) Ну когда место заканчивается все начинают хорошо общаться :) Просто данные заливают бизнес пользователи обычно, для них совсем не очевидно что где то из-за этого место заканчивается, разработчики же тоже мало думаю о планирование и работе с пользователями т.к. инфраструктура их тоже не волнует. Ну а обязать инфраструктурщиков капать на мозги разработчикам тоже не вариант, это не их задача. Вообще 4-й вопрос можно удалить, надо OLA готовить.

Answer 3

[strib]

1-2) Сложно объяснить в рамках комментария.
Отдел А оказывает внутри компании услуги. Допустим организует хранилище блочное. Эту услугу в свою очередь обеспечивают какие-то материальные ресурсы (серверы, хранилища, печеньки и прочее) и другие услуги (электричество, вентиляция в каком то объеме, поддержка от вендора, персонал, охрана)
Так вот этот процесс описывает все ресурсы, необходимые для окозания услуги
Что это дает:
1) Стоимость услуги. Всегда понятно, сколько стоит та или иная услуга в сторону потребителя.
2) Учет ресурсов. Видно сколько услуг оказывается, и сколько ресурсов при этом используется.

Об организации какого размера идет речь? Сколько оборудования?

Comments

[Александр]

Описанное вами то к чему хорошо придти в будущем. Сейчас же мне важно выбрать правильный инструмент чтобы внести в него данные и поддерживать их в актуальном состояние.

Масштабы средние. Порядка 2к пользователей по Москве и регионам РФ. Данных порядка 200Тб (явно перебор в пересчете на пользователя). Серверов несколько сотен, в большинстве своем виртуалки. Существенная часть ресурсов в облаке, с одной стороны понятнее цена, с другой стороны нужен контроль и ответсвенность.

Answer 4

[Николай Турнавиотов]

1. Провести тотальный аудит системы. Долго, дорого, муторно, но зато будет известен каждый компонент на каждом уровне.
Начать документировать — да хотя бы в за 5 минут развернутой mediawiki.

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

Comments

[Александр]

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

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

[Николай Турнавиотов]

А это надо не каждый год делать, а один раз сделать и поддерживать.