Управление изменениями в Lync Server 2013
Последнее изменение раздела: 2014-08-18
Изменения в ИТ-среде являются несохраняемыми. К изменениям относятся новые технологии, системы, приложения, оборудование, средства, процессы и изменения ролей и обязанностей. Эффективная система управления изменениями позволяет быстро вносить изменения в ИТ-среду с минимальными сбоями в работе службы. Система управления изменениями объединяет команды, участвующие в изменении системы. Например, вы можете воспользоваться преимуществами office веб-приложения. Это интегрированное приложение службы Lync, которое позволяет пользователям читать и редактировать документы в браузере. Реализация этой службы после того, как вы перейдет в рабочую среду, требует участия нескольких команд:
Группа тестирования Эта команда выполняет нагрузочные проверки office веб-приложения на тестовом сервере, предоставляя сведения о ожидаемых шаблонах использования и ожидаемой производительности рабочих серверов.
Администраторы Lync Эта команда определяет стратегию развертывания и создает сценарии установки там, где это было возможно. Команда отвечает за развертывание изменений в рабочей среде, а затем отвечает за администрирование. Перед внедрением изменений в рабочую среду команда должна понимать влияние изменений и внедрять их в процедуры.
Сетевая команда Эта команда отвечает за изменения правил брандмауэра, которые разрешают доступ из Интернета к внутренним серверам пула Lync. Команда также отвечает за работу с администраторами Lync, чтобы убедиться, что доступная пропускная способность может поддерживать дополнительную нагрузку.
Группа безопасности Эта команда оценивает безопасность и минимизирует риски. Группа безопасности должна проверить известные уязвимости и обеспечить минимизацию рисков безопасности.
Команда приемки пользователей Эта команда состоит из пользователей, которые готовы протестировать систему и предложить отзывы об улучшениях.
Процесс управления изменениями определяет обязанности каждой команды и планирует выполнение работы, включая проверки и тесты там, где они необходимы. Элементы управления изменениями зависят от сложности и ожидаемого эффекта изменения. Они могут отличаться от автоматического утверждения незначительных изменений, изменения собраний проверки до полных проверок на уровне проекта. Чтобы лучше объяснить это, в этом разделе рассматриваются группы изменений.
Основные изменения Значительные изменения имеют глобальное влияние на систему и могут требовать ввода данных от различных команд. Примером этого является обновление до Lync Server 2013. Значительные изменения влияют на многие команды и, возможно, разные системы. Процесс управления изменениями, вероятно, будет включать в себя одно или несколько собраний по проверке изменений, чтобы сообщить командам, которые будут задействованы в изменении или затронуты этим изменением.
Значительные изменения Для значительных изменений требуются значительные ресурсы для планирования, сборки и реализации. Необходимо внести соответствующие элементы управления изменениями, чтобы убедиться, что результат изменения понятен, процедуры развертывания протестируются, а планы отката и непредвиденных обстоятельств готовы. Примером значительного изменения является развертывание нового накопительного пакета обновления.
Незначительные изменения Незначительные изменения не оказывают существенного влияния на ИТ-среду, например изменение определенных политик Lync с помощью microsoft Lync Server 2013 панель управления.
Стандартные изменения Стандартные изменения выполняются регулярно и хорошо понятны и задокументированы. Процесс управления изменениями должен проверять все изменения процедур. Он не должен быть необходим для выполнения стандартных изменений, таких как создание базы данных контента или добавление пользователя.
В следующем примере управления изменениями рассматривается взаимодействие различных команд и действия, выполняемые при развертывании нового пакета обновления. Эти действия упорядочены и управляются процессом управления изменениями.
Создание запроса на изменение Группа безопасности оценила последний пакет обновления и подтвердила, что он устраняет возможные уязвимости в рабочей системе. Команда создает запрос на изменение, чтобы применить новое накопительное обновление ко всем серверам под управлением Lync Server.
Обзор заметок о выпуске пакета обновления Команда администраторов Lync просматривает заметки о выпуске пакета обновления, чтобы определить влияние на систему.
Выполняется ряд лабораторных тестов. Команда администратора Lync должна выполнить тестовые обновления на сервере в тестовой среде, чтобы решить, можно ли применить пакет обновления успешно, не затрагивая ни один из установленных приложений и серверных систем. Если в рабочей среде есть сторонние или внутренне созданные приложения, которые интерфейсируются с Lync Server, их также следует протестировать. Эти тесты также можно использовать для оценки времени, необходимого для выполнения обновлений.
Пользователи уведомляются о сбое Группа администраторов Lync, отдел коммуникации или служба технической поддержки пользователей информируют всех затронутых пользователей о плановом цикле обслуживания и о том, как долго служба будет недоступна.
Перед обновлением выполняется полное резервное копирование Lync. Команда администратора Lync должна убедиться, что существует допустимая резервная копия, которую можно использовать для возврата к исходному состоянию системы в случае сбоя установки пакета обновления. Мы рекомендуем восстановить резервную копию на резервный сервер, чтобы эта система была доступна в случае проблем.
Развертывание накопительного пакета обновления Команда администратора Lync выполняет установку во время планового цикла обслуживания.
Управление временем внесения изменений
Рекомендуется реализовать процедуру планирования изменений, чтобы избежать перебоев в перекрывающихся разделах работы. Например, две команды могут планировать незначительное изменение системы. Одна команда может применять накопительное обновление к пулу, а другая — переносит устаревших пользователей в этот пул. Ни одна из команд не зависит от изменений, которые планирует другая команда, и каждая команда может не знать об изменениях, которые планирует другая команда. Если оба изменения произошли одновременно, могут возникнуть проблемы с их реализацией. Кроме того, если после применения изменений возникли проблемы, например при сбое миграции пользователя, может быть трудно решить, какое изменение следует откатить. Между ИТ-службой и управлением должны быть настроены регулярные периоды обслуживания для тестирования изменений и их принятия.