назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [ 34 ] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


34

7. УПРАВЛШИЕ ИЗМЕНЕНИШИ

и Инцидентами. При работе в сложной ИТ-среде почти невозможно контролировать эти процессы без такого инсгрументальиого средства.

7.6.2.Проблемы

При внедрении Процесса Упраиления Изменениями возможно появление следуюнщх проблем:

•Работа без средств автоматгшции слишком трудоемка, она будет создавать много проблем.

•Возможно сопротивление всеохватываюп(ему Процессу Управления Изменениями, осуществляю-\цсму мониторинг всех аспектов ИТ-и1к)раструктуры. В этом случае необходимо обучение персонала, который должен осознать, что все компонеты ИТ-инфраструктуры мог}т оказывать значительное влияние друг на друга, и что реализуемые изменения Конфигурацрнг требуют общей координации.

•Возможны попытки ироведения изменений в обход согласованных процедур. Абсолютно необходимо, чтобы такие попытки встречали соответствуюп1ую реакцию со стороны компангш. Целостность Процесса Управления Изменениями зависит от полного соответствия ир<)цедурам. Претензии сотрудников и предложения по усоверп1енствовапию Процесса Управления Изменениями должны П01птматься и приветствоваться, однако неподчинение необходимо репштельно пресекать, иначе весь процесс будет поставлен под угрозу.

•Другие способы обеспечеття исполнения процедур по Управлению Изменениями включают:

-ироведерпге регулярного аудита, возможно, )!езависимым инспектором, для оценки соответствия процедурам Управления Изменениями;

-осуществление контроля со стороны руководства над внутре)пщм и внешним обслуживающим персоналом и разработчиками;

-обеспече1ше контроля за всеми Конфигурационными Единицами и версиями программ путем запцггы базы данных CMDB и организации регулярного аудита Конфигураций в рамках Процесса Управления Конфигуращгями;

-предоставлепие информации из Управления Ищщдеитами о фактах доступа- пользователей к апнаратно.му и нрограм.мному обеспечению, не отраженного в CMDB;

-включешю необходимых условий и процедур в контракты с внеппшми поставнцтками;

-назначение на должность Руководителя Процесса Управления Изменениями сотрудника с обширным опытом н достаточными бизнес- (что часто недооцижвается) и техническими знаниями. Правильный выбор претендента иа эту должность имеет критически важное значение, это не должно упускаться из виду, как часто бывает.

7.6.3.Предложения

Некоторые проблемы могут быть решены за счет реализации следуюпц1х предложений:

•обеспечи-1-ь, чтобы каждое изменение проходило всю процедуру обработки.

•наладить контакт со всем ИТ-нерсоналом и всеми поставщиками, чтобы гарантировать их понимание Процесса Уиравлентш Изменениями н отказ от попыток проведения изменений без координации;

•обеспечить постоянное проведение окончательной оценки изменений (Анализ результатов виедре-1ЩЯ - PIR);

•орга1щзовать взаимодействие с Управлением Конфигурациями для гарантированного ввода изменений Конфигурационных Едшитц в базу дaнныxCMDB.



Управление Релизами 8.1. Введение

с повышением зависимости организаций от ИТ-ироцсссов все 6ojii>u.iee зиачепие приобретает их эффективньгп Moinnopiinr и запщта. С ростом количества изменений возрастает и потребность в контроле над процессом проведения изменеппп.

Изменення ИГ-ипф1)аструктуры происходят в сложной распределешюй среде. Г5 современных П1)н-ложе1гиях клиент/сервер это часто отражается как на клиентской части, так и на серверной. В таких случаях запуск и впедреппе новых версий программных и анпа[)атных средств требует тщательного планирования. Релизом называется набор новых и/илп измененных Конфигурагщопных Единиц, кото1)ые вместе испытываются и шгедряются в рабочую среду. Релиз определяется Запросом на Изменення (RFC), для исполнения которого он вводится в работу. В Процессе Управле1пм Релизами используется плановый проектный подход к п])оведению изменений в ИТ-услугах, и он затрагивает все, как технические, так и нетехнические аспекты измепептп!

Задачей Процесса Управления Релизами является обеспечение качества рабочей среды за счет использования формальных процедур и проверок при вводе в работу новых версий. В отличие от Управления Изменениями, занимающегося вери(})икац11ен. Процесс Управления Релизами занимается внедрением. Унравление Релизами осуп1ествляется в тесном контакте с Управлением Конфигураци-ЯМ1\ и Управлением Изменениями, что i-араптирует обновлешге ед]п1011 базы CMDB с учетом каждого нового релиза. Управление Pejni3a.MH также обеспечивает обновление содержания релизов (программных кодов) в Библиотеке эталонного программного обеспечения DSL. С помогцью базы CMDB также отслеживаются спецификации аппаратных средств, руководства по инсталляции и сетевые конфигурации. Запас аппаратных средств, в частности стаидарттгзованные базовые конфигу-painiH, хранится на Складе эталонного аппаратного обеспечения f3H.S. Однако, в первую очередь об1>екго.м Процесса Управления Релизами является профаммное обеснсчсние.

В больпшх проектах Процесс Управления Релизами должен включаться в обищй план проекта как его составная часть для обеспечения достаточного финансирования работы нроцесса. Определенная часть ежегодного бюджета может быть выделена на повседневные работы, такие как He3Ha4nTejrbHbie изменения. Расходы, вознпкатопще при .запуске нроцесса, пе столь значительны по cpafineiniro с по-тепцпальны.ми потерями, вызванными недостатками в планированш! и контроле за программными и а1Н1араттп>1Ми средствами, к которым можно отнести следугопще:

•больпиге перерывы в работе из-за плохого планирования выпуска релизов;

•дублирование работ из-за наличия копий различ1и,1х версий;

•неэффектив1гое использование ресурсов из-за отсутствия и)формации об их местонахождешт;

•потеря исходшлх файлов, п])иводящая к повторной закупке программ;

•отсутствие загциты от вирусов, приводящее к необходимости «лечеггия» всей сети.

8.1.1. Основные понятия

Релизы

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

•Значительные релизы - крупномасштабное развертываппе новых аппаратных и программных средств, обычно со значительно расширенными фугпоцюнальны.мп возможностями. Такпе релизы

Production environment

Definitive Software library - DSL.

Definitive Hardware Store - DHS.



часто помогают в устраиетп! ряда известных ошибок, включая известные обходные ренгения и быстрые исправления

•Малые программные релизы и модернизация аппаратного обеспечения (апргревды)- эти релизы обычно представляют собой незначительные усовершенствования и исправления известных оишбок. Среди них могут быть такие, которые внедрялись ранее в виде срочных исиравлений и теперь окончательно проработаны и включены в данный релиз. За счет такого релиза обеспечивается обновление «Прежнего стабильного состояния"», являюп1егося отправной точкой для всех испытаний.

•Срочш>1е исправления - обычно внедряются как быстрые исправления проблем и известных ошибок.

Релизные единицы

В отиогиепии аппаратного обеспечения вопросы возникают только ири полной замене ПК или ири раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессоров). Для программного обеспечения изменения возможны на уровне системы, комплекса, программы или модуля. Хорошим примером может быть библиотека DLL (Dynamic Link Library) в среде Winciow.s, часто используемая несколькими программами. И1Г0гда в составе пакета поставляется новая версия DLL, что может потребовать нового тестирования и переустановки всех других программных пакетов. В данном процессе также прорабатывается принцип минимального содержания релиза.

РГдентификация релизов

К(яип программ мог>т распространяться из Библиотеки DSL по соответствую1цим средам:

•Среда разработки - разработка новых версий может вестись иа основе более ранних версий из Библиотеки DSL. С каждой новой версией увеличивается ее номер. Изменение программного обеспечения возможно только в среде разработки.

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

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

•Архив - служит для хранения старых верстпт программных единиц, которые больше пе используются.

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

•Значительные релизы - система расчета зарплаты v.l, v.2, v.3 и т. п.

•Малые релизы - система расчета зарплаты v.l.L V.L2, v.L3 и т. п.

•Релизы - срочные исправления - система расчета зарплаты v.LLL v.LL2, v.LLS и т. п.

На рис. 8.1 показаны тестирование и возможные модификации каждой повой версии перед ее выпу-ско.м. Старая версия архивируется как часть запуска нового релиза на случай возможного возврата.

На рис. 8.2 показан возврат.

Work-arounds. Quick fixes.

Upgrades. Previous Trusted State

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [ 34 ] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]