Определение условий готовности
Планирование развертывания и управление ими включает в себя различные различные действия и роли, наиболее подходящие для каждого действия. В этой статье описывается, как определить важные роли и понять, как классифицировать приложения.
Определение ролей и персонала
По мере планирования стоит выяснить, какие роли вам потребуются для развертывания и кто должен их заполнить. Различные роли активны на разных этапах развертывания. В зависимости от размера и сложности организации некоторые из ролей может заполнить один и тот же человек. Однако лучше всего иметь установленного менеджера процессов, который будет контролировать все задачи для развертывания.
Диспетчер процессов
Руководитель процесса руководит процессом развертывания обновлений и имеет право на то, чтобы отправить процесс вперед или остановить его, если это необходимо. Они также отвечают за организацию этих мероприятий:
| Рабочий поток совместимости | Развертывание | Возможности и модернизация |
|---|---|---|
| Назначение приоритета приложения | Просмотр требований к инфраструктуре | Определение изменений инфраструктуры |
| Оценка приложений | Проверка инфраструктуры в соответствии с требованиями | Определение изменений конфигурации |
| Оценка устройства | Создание плана обновления инфраструктуры | Создание предложения возможностей |
Задача руководителя процессов заключается в сборе отчетов об усилиях по исправлению, эскалации сбоев и принятии решения о готовности вашей среды к пилотном развертыванию, а затем широкому развертыванию.
В этой таблице приведено одно представление других ролей с их обязанностями, соответствующими навыками и этапами развертывания, где они необходимы:
| Роль | Обязанности | Навыки | Активные фазы |
|---|---|---|---|
| Диспетчер процессов | Управляет процессом до конца; обеспечивает запись входных и выходных данных; обеспечивает выполнение действий | Управление ИТ-службами | Планирование, подготовка, пилотное развертывание, широкое развертывание |
| Владелец приложения | Определение плана тестирования приложений; назначение тестировщиков приемки пользователей; сертифицировать приложение | Знание критически важных и важных приложений | Планирование, подготовка, пилотное развертывание |
| Разработчик приложений | Убедитесь, что приложения разработаны для обеспечения совместимости с текущими версиями Windows | Разработка приложений; исправление приложения | Планирование, подготовка |
| Вычисления конечных пользователей | Как правило, группа, включающая инженеров инфраструктуры или инженеров развертывания, которые обеспечивают совместимость средств обновления с Windows. | Развертывание без операционной системы; управление инфраструктурой; доставка приложений; управление обновлениями | Планирование, подготовка, пилотное развертывание, широкое развертывание |
| Операции | Убедитесь, что поддержка доступна для текущей версии Windows. Обеспечение поддержки после развертывания, включая взаимодействие с пользователями и откат. | Безопасность платформы | Подготовка, пилотное развертывание, широкое развертывание |
| Безопасность | Проверка и утверждение базовых показателей безопасности и средств | Безопасность платформы | Подготовка, пилотное развертывание |
| Заинтересованных сторон | Представляет группы, затронутые обновлениями, например руководители финансов, службы конечных пользователей или управление изменениями | Ключевые решения для подразделения или отдела | Планирование, пилотное развертывание, широкое развертывание |
Установка критериев для приложений для оценки
Некоторые приложения в вашей среде имеют основополагающее значение для основных бизнес-действий. Другие приложения помогают сотрудникам выполнять свои роли, но не являются критически важными для бизнес-операций. Прежде чем приступить к инвентаризации и оценке приложений в вашей среде, следует установить некоторые критерии для классификации приложений, а затем определить приоритет для каждого из них. Этот процесс поможет вам понять, как лучше всего развертывать обновления и как устранять любые проблемы, которые могут возникнуть.
На этапе подготовки вы будете применять критерии, которые вы определили сейчас, к каждому приложению в вашей организации.
Ниже приведена предлагаемая схема классификации.
| Категория | Определение |
|---|---|
| Критический | Наиболее важные приложения, которые обрабатывают основные бизнес-действия и процессы. Если эти приложения были недоступны, бизнес или подразделение вообще не могли работать. |
| Важно. | Приложения, необходимые отдельным сотрудникам для поддержания их производительности. Простой в этом случае повлияет на отдельных пользователей, но будет иметь лишь минимальное влияние на бизнес. |
| Не важно | Это не влияет на бизнес, если эти приложения недоступны в течение некоторого времени. |
После классификации приложений следует определить, что каждая классификация означает для организации с точки зрения приоритета и серьезности. Это действие поможет убедиться, что вы сможете рассмотреть проблемы с правильным уровнем срочности. Каждому приложению следует назначить приоритет на основе времени.
Ниже приведен пример системы оценки приоритета. специфика может отличаться для вашей организации:
| Priority | Определение |
|---|---|
| 1 | Все выявленные проблемы или риски должны быть расследованы и устранены как можно скорее. |
| 2 | Начните исследовать риски и проблемы в течение двух рабочих дней и исправьте их в течение текущего цикла развертывания. |
| 3 | Начните изучение рисков и проблем в течение 10 рабочих дней. Вам не нужно исправлять их все в рамках текущего цикла развертывания. Однако все проблемы должны быть устранены к концу следующего цикла развертывания. |
| 4 | Начните изучение рисков и проблем в течение 20 рабочих дней. Их можно исправить в текущем или любом будущем цикле разработки. |
Связана с приоритетом, но отличается концепция серьезности. Вы также должны определить рейтинг серьезности на основе того, как вы считаете, что проблема с приложением должна повлиять на цикл развертывания.
Вот пример.
| Серьезность | Эффект |
|---|---|
| 1 | Остановка работы или потеря дохода |
| 2 | Снижение производительности для бизнес-подразделения |
| 3 | Снижение производительности для отдельных пользователей |
| 4 | Минимальное влияние на пользователей |
Пример: крупная финансовая корпорация
Используя предлагаемую схему, финансовая корпорация может классифицировать свои приложения следующим образом:
| Приложение | Категория |
|---|---|
| Приложение для обработки кредитов | Критический |
| Приложение службы поддержки клиентов с интерфейсом | Критический |
| Средство просмотра PDF-файлов | Важно. |
| Приложение для обработки изображений | Не важно |
Кроме того, они могут сочетать эту классификацию с ранжированием серьезности и приоритета следующим образом:
| Категория | Серьезность | Priority | Ответ |
|---|---|---|---|
| Критический | 1 или 2 | 1 или 2 | Для параметра 1 остановите развертывание до тех пор, пока не будет разрешено; Для 2 остановите развертывание только для затронутых устройств или пользователей. |
| Важно. | 3 или 4 | 3 или 4 | Для версии 3 продолжайте развертывание даже для затронутых устройств, если существуют рекомендации по обходным решениям. |
| Не важно | 4 | 4 | Продолжайте развертывание для всех устройств. |