Что такое управление развёртыванием и зачем нужны разные среды

Зачем управление развёртыванием

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

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

Развернуть — поставить в среду. Открыть людям — работа RLSУправление релизами. Разрешить проведение — работа CHNКонтроль изменений.

ГОСТ Р ИСО/МЭК 20000-1 отдельного пункта про развёртывание не заводит: он держит релизы и внедрение одним требованием и говорит, что управление релизами и внедрением используется для внедрения утверждённых сервисов в производственную среду 2. FitSM поступает так же 3.

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

Три вопроса, ответы на которые видны по журналу переносов.

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

Перенос повторяем. Как проверить: одинаковые компоненты переносятся одним и тем же способом, а не по памяти инженера.

Возврат отработан. Как проверить: шаги на случай неудачного развёртывания продуманы и хотя бы раз проверены 3.

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

Среда как понятие

ITIL даёт определение, которое стоит завести и у себя: среда — часть ИТ-инфраструктуры, отведённая под определённую цель 1.

Пример состава для организации, которая разрабатывает программы 1:

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

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

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

Практика получает готовое и разрешённое, отдаёт факт: перенесено туда-то, тогда-то, в таком составе. Этот факт нужен многим — учёту конфигураций, разбору инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами, отчётности.

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

Модели развёртывания

ITIL предлагает описать несколько моделей и выбирать их под тип компонента 1. От чего зависит выбор 1:

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

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

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

Непрерывная поставка и развёртывание

Три понятия, которые в разговорах смешивают 1:

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

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

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

Процессов два: собственно развёртывание и разработка с пересмотром моделей 1.

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

Две строки этой таблицы стоит развернуть.

Четвёртый шаг отличает развёртывание от копирования файлов. Проверка после переноса — часть работы, а не любезность; без неё «развёрнуто» означает только «скопировано».

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

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

Развёртывание и релиз. Перенос в среду и открытие людям — разные шаги, и в современных решениях они разнесены во времени 1.

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

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

Развёртывание и конвейер. Конвейер — средство. Практика отвечает и за те переносы, которые конвейером не автоматизируешь: оборудование, документы, обучение.

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

Как измерять

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

Расхождение сред у Брукса стало отдельным числом. Программные пакеты, установленные в среде, но отсутствующие в библиотеке эталонного ПО: цель 25, тревога 50 6. Это та же беда, что в таблице выше названа расхождением между средами, только померенная с конца: не сравнение сред между собой, а сверка среды с тем, что вообще разрешено ставить. Считать так проще — эталонный перечень один, а сред много.

Неиспользуемые лицензии — цель 100, тревога 200 6. Показатель кажется чужим для практики переноса, но встаёт на своё место, если помнить, откуда берутся лишние лицензии: их покупают под развёртывание, которое отменили, отложили или сделали иначе. Практика создаёт этот остаток, и мерить его логично здесь.

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

Зрелость управления развёртыванием

✕

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

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

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

Перенос держится на человеке. Развернуть умеет один инженер, и его отпуск останавливает поставку.

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

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

Одна модель на всё. Обновление приложения и замена оборудования идут по одному регламенту, и обе стороны недовольны.

После переноса не проверяют. «Скрипт отработал» считается успехом, пока не позвонит пользователь.

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

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

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

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

FitSM тоже объединяет их в один процесс и добавляет требование продумать шаги на случай неудачного развёртывания 3.

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

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

Где описано

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

Три соседние практики, между которыми зажато развёртывание: CHNКонтроль изменений — где дают разрешение, RLSУправление релизами — где решают, когда открыть людям, INFУправление инфраструктурой и платформами — кто готовит сами среды.