Что такое управление инфраструктурой и платформами в ИТ

Зачем управление инфраструктурой и платформами

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 присматривает за тем, на чём всё работает: оборудование, программы, сети и помещения, нужные чтобы разрабатывать, проверять, поставлять, наблюдать, обслуживать и поддерживать услугиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation 1. Это и есть определение ИТ-инфраструктуры.

Работа распадается на два несхожих занятия. Первое — понять потребности организации и спланировать, из чего она будет строиться. Второе — рутина: обслуживать, следить за работой, обновлять 1. У рутиныРутинаРучная повторяющаяся работа без долговременной ценности, которая растёт вместе с сервисом и поддаётся автоматизации.Google. Site Reliability Engineering, глава о вытеснении рутины есть отдельное определение: повседневное ведение и обслуживание деятельности, продукта, услуги или элемента 1.

Большая часть повседневной работы поддаётся автоматизации: средства наблюдают за средой, замечают изменения, раздают обновления, ведут учёт имущества и выполняют задания по расписанию 1.

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

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

Три вопроса, ответы на которые видны по тому, как выдаются ресурсы.

Типовые решения описаны и повторяемы. Как проверить: есть набор стандартных решений — хранилища, серверы приложений, базы, средства входа — и они выдаются одинаково 1.

Виртуальное и физическое связано в учёте. Как проверить: связь виртуальных машин с физическими отражена в базе конфигурацийБаза данных управления конфигурациями (CMDB)База, где записано, из чего состоят ИТ-услуги и как связаны их части — и что остановится, если тронуть одну.ITIL 4: практическое руководство Service Configuration Management и книга ITIL Foundation; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.1, 3.2.2 и 8.2.6; FitSM-0, FitSM-1 (PR11) и FitSM-2; MOF 4.0, SMF «Изменение и конфигурация»; COBIT 5, процесс BAI10; DAMA-DMBOK, глава 12; Брукс, «Метрики для управления ИТ-услугами»; itSMF, «Введение в ИТ Сервис-менеджмент», 2003 — требуется именно этого 1.

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

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

Своё, облако, подряд: три способа получить одно и то же

Разница разобрана так, что перестаёт быть спором о моде 1.

Своя инфраструктура. Организация владеет и управляет. Максимум контроля и максимум работы.

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

Подряд. Внешняя команда выполняет те же функции, что делали бы свои люди; объём и уровень заданы договором. Внутренние команды переключаются с управления техникой на управление обязательствами и взаимодействием 1.

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

Отсюда следует вот что. Выбирают не «облако или своё», а по каждому решению отдельно. И главный вопрос не в стоимости часа, а в том, чем именно вы хотите управлять.

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

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

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

Физическое, виртуальное и описанное кодом

Уровней три, и разница между ними определяет скорость работы 1.

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

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

Гибкие подходы в инфраструктуре

Профессия меняется. Инженеры инфраструктуры всё больше опираются на программирование ради автоматизации, а команды объединяют разработку и инфраструктуру, чтобы отвечать за решение целиком. ITIL приводит два примера таких моделей: DevOps и инженерия надёжности 1.

Разграничение оттуда же, полезное в спорах: гибкие подходы — про разработку, а DevOps добавляет к ним инфраструктурные части и повседневную работу, охватывая все технические составляющие и подталкивая к автоматизации 1.

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

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

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

Два места стоит объяснить отдельно.

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

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

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

Инфраструктура и эксплуатация. Инфраструктура даёт платформы, MOpУправление эксплуатацией ведёт повседневные работы по услугам. В маленькой организации это одни люди, но работы разные.

Инфраструктура и архитектура. Архитектура задаёт правила и целевое устройство, инфраструктура строит и содержит 1.

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

DevOps и гибкая разработка. Первое включает инфраструктуру и повседневную работу, второе — способ вести разработку 1.

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

Как измерять

Два показателя держат вместе: время выдачи и долю ручных работ. Первое — то, что чувствуют разработчики и заказчики; второе объясняет, почему первое такое.

У планирования тоже есть показатели, и они простые. Брукс меряет, сколько подпланов инфраструктуры подписано владельцами бизнеса и сколько должно было быть готово в этом месяце, но к одобрению не готово: у обоих цель 2, тревога 5 5. Вторая цифра, по его словам, говорит не только о темпе, но и о нехватке людей — и это тот редкий случай, когда показатель говорит о ресурсах практики, а не о старании команды.

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

События безопасности считают ежедневно и сравнивают с инцидентами. Цель 150 за день, тревога 250 5. Брукс требует держать этот показатель рядом с числом инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами того же рода. Если оба значения равны, ни одно событие не удалось перехватить до того, как оно стало инцидентом. Значит, дело не в потоке угроз, а в реакции на них. Сама по себе безопасность живёт в SECУправление информационной безопасностью, а повседневная работа средств защиты — здесь.

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

Зрелость управления инфраструктурой

✕

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

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

Каждое решение уникально. Типовых решений нет, любая новая система собирается по-своему, и её поддержка стоит как отдельный продукт 1.

Виртуальное не отражено в учёте. База конфигураций знает про физические серверы и не знает, что на них работает 1.

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

Устаревшее живёт вечно. Монолиты и старые системы требуют ручной работы, дорожной карты их замены нет 1.

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

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

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

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

ITIL держит инфраструктуру и платформы отдельной практикой, охватывающей всю жизнь решений — от замысла до поддержки 1.

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

COBIT относит эту работу к разработке и созданию решений 3.

MOF описывает соседнюю часть — повседневную эксплуатацию и мониторинг, — оставляя развитие платформ этапу планирования 4.

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

Где описано

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

Три соседние практики, с которыми инфраструктура работает вплотную: ARCУправление корпоративной архитектурой — чьим правилам она следует, DEPУправление развёртыванием — кто переносит в подготовленные среды, MOpУправление эксплуатацией — кто ведёт повседневные работы.