InfoWorld, США

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

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

«Если что-то не работает, самое сложное — найти причину», — философски заметил Ричард Виллмотт, менеджер по вопросам рынка компании IBM/Tivoli. Слишком часто у сетевых администраторов просто опускаются руки из-за отсутствия бюджета, лабораторного оборудования и времени, необходимых для того, чтобы просчитать последствия изменений, вносимых в протокол внутренней маршрутизации, или точно понять, как повлияет изменение списка глобального доступа на реальный трафик. Конечно, совсем избавиться от человеческих ошибок невозможно, хотя есть определенные способы, позволяющие смягчить их последствия.

Четкий процесс управления изменениями наряду с необходимым обучением и достаточными ресурсами ИТ может уберечь администратора от лишних проблем, которые создают разнородные системы и устаревший инструментарий. Кроме того, существует библиотека ITIL (IT Infrastructure Library), которая представляет собой собрание наилучших практических решений для управления ИТ. Это разнообразные методики управления, позволяющие сократить количество проблем и дать адекватное представление о сетевых инфраструктурах. Наконец, существует немало производителей, продукты которых упрощают и автоматизируют процесс управления изменениями. Ничто не может дать гарантии безошибочности, но это не означает, что не нужно пытаться что-то делать.

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

Но когда речь идет об устройствах для передачи информации, изменения любого масштаба, как правило, вносятся без какого бы то ни было предварительного тестирования. Почему? Потому что практически невозможно до конца протестировать каждый аспект предполагаемых изменений сетевой конфигурации. Если в качестве среды разработки достаточно нескольких серверов, то сетевой лаборатории требуется разнообразное и дорогостоящее сетевое оборудование, позволяющее максимально точно имитировать производственную среду. Другими словами, смоделировать сегменты TDM и сети frame relay, каналы ISDN или каналы другого типа, которые используются в производственной сети. Простые тесты можно провести с помощью подмножества производственной инфраструктуры. Затраты в этом случае высоки, хотя и не дают полной уверенности в том, что после предполагаемого изменения все будет работать, как ожидалось.

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

Существуют коммерческие продукты, способные помочь в решении этой задачи, и, к счастью для покупателей, конкуренция на этом рынке очень высокая. Некоторые производители предлагают пакеты продуктов, которые, как утверждается, помогают поддерживать правила управления изменениями для разнородных сетевых устройств и автоматически выполнять резервное копирование конфигураций, а также их поиск и восстановление. Device Authority Suite компании AlterPoint представляет собой полную сетевую среду разработки, похожую на среду Eclipse IDE, которая отличается разнообразными инструментальными средствами автоматического создания сценариев для определения изменений в конфигурации и реализации этих изменений на избранных системных устройствах.

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

Теперь все будет хорошо

Для многих сетевых администраторов внедрение управления изменениями в сети подобно визиту к стоматологу — нужно, но страшно. Как правило, изменения в сетевой конфигурации незначительны (например, добавление к списку доступа или изменения в сообществе SNMP) и требуют всего нескольких секунд. Следование всем тягостным инструкциям, созданным в рамках процесса управления изменениями, иногда может серьезно усложнить на первый взгляд элементарные задачи. Тем не менее выполнение этих инструкций себя оправдывает. Многие тянут с лечением зубов, а потом горько жалеют от этом.

Специалисты компаний могут многое узнать об управлении сетевыми конфигурациями у провайдеров услуг, существование которых впрямую зависит от того, насколько бесконфликтно, быстро и точно они могут вносить изменения. Почти все крупные провайдеры Internet имеют очень строгие процедуры управления изменениями и поддерживают их с помощью средств управления конфигурацией. Некоторые провайдеры не столь обязательны, и это сразу заметно.

Недавно я оказывал помощь во время отключения сети MPLS. Хотя непосредственно к сети оператора я подключен не был, но поддерживал связь с администратором сетевого операционного центра, выяснявшего причину сбоя. Благодаря высокоуровневой природе частных сетей MPLS операторы оказывают более серьезное влияние на производительность и надежность службы. Если традиционные сети frame relay функционируют на уровне 2, то сети MPLS действуют на уровне 3 и оператор отвечает за поддержку корректных маршрутов между всеми точками доступа. Таким образом, когда в сети возникает ошибка и все сетевые каналы активны, причину следует искать в таблицах маршрутизации оператора. В нашем случае так и оказалось. В конце концов, выяснилось, что причина сбоя связана с изменением, сделанным в маршрутизаторе, который находится за тысячи миль от самой дальней точки этой сети, где по ошибке маршруты были внесены в таблицы маршрутизации MPLS-сети моего клиента. Ошибка проявилась после, казалось бы, безобидного изменения в таблице маршрутизации, никак не связанного со случайно затронутой сетью, и пока не позвонили технику, внесшему изменения, никто не знал, что именно было сделано. На поиск и устранение ошибки ушло почти три часа. Если бы была установлена эффективная политика управления изменениями, проблемы вообще бы не было.

Первые шаги

Безусловно, использование наилучших практических решений может помочь только в том случае, если инфраструктура стабильна. Нет смысла строить леса вокруг горящего здания. Недолгая приостановка любого нового проекта — прекрасный способ добиться стабильности. Эта тактика, несомненно, приведет к появлению некоторых краткосрочных проблем, но долгосрочная отдача от инвестиций все это оправдывает. Как только сотрудники перестанут заниматься массовым внедрением новых систем, это положительно скажется на стабильности. Процесс управления изменениями следует начать с определения критически важных инфраструктур, разработки базы данных и изучения инструментария, который может автоматически обновлять базу данных. Большинство ИТ-подразделений обслуживают различные сетевые элементы с помощью простых, небольших решений, таких как электронные таблицы Excel с информацией о месторасположении виртуальной локальной сети или присваивание внешних IP-идентификаторов. Перенос этих данных в центральное хранилище — простой первый шаг. Как и в случае с любым систематическим изменением, начиная с малого и постепенно добиваясь небольших побед, вы добьетесь успеха, когда сложность проекта станет расти.

После того как создана CMDB, в ее обслуживании может помочь соответствующий инструментарий. Программное обеспечение службы помощи, которое взаимодействует с CMDB, предоставит важную информацию для инженеров и упростит перенос информации, возможно слишком сложный, чтобы реализовать его сразу. Гарантия корректности работы выбранного программного обеспечения и возможность извлечения данных из CMDB намного важнее быстрой реализации. Если быть точным, единственно важное здесь — это CMDB. Таким образом, лозунг «Семь раз отмерь — один раз отрежь» — наилучшая линия поведения при внедрении любой формы управления изменениями. Небольшие шаги дают лучшие результаты.

Совместное обдумывание концепции управления изменениями — важный этап, предшествующий ее реализации. До тех пор пока каждый не поверит в преимущества такого управления, стимулов для использования этой системы не появится. Если политика дает позитивный сдвиг и администраторы сетей видят позитивные результаты, управление изменениями быстро будет набирать популярность.


Используйте ITIL

Все чаще эффективная политика управления изменениями опирается на ITIL.

В терминологии управления изменениями ITIL образует основу с использованием CMDB (базы данных управления изменениями). CMDB может принимать любую форму, от простой базы данных Microsoft Access до совершенно конкретного решения на основе SQL. Это может быть, например, база данных Troux CMDB for ITIL компании Troux Technologies. Вдобавок существует несколько размещаемых служб CMDB, таких как myCMDB.com, которые лучше всего подходят для небольших предприятий.

База данных CMDB содержит документацию обо всех компонентах любой инфраструктуры и предоставляет оболочку для модификации этих данных при внесении изменений.

Процесс создания и поддержки CMDB начинается с определения и описания критически важных инфраструктур внутри вашей сети. Сделать это не всегда просто, поскольку каждый, кто заинтересован в конкретном приложении, будет требовать признать именно это приложение критически важным, так что здесь необходимо действовать разумно. Хорошими примерами критически важных инфраструктур являются системы защиты, базы данных со сведениями о зарплате, системы контроля выпуска и управления складами, а также интерфейсы с внешними партнерами. Документация для этих систем должна создаваться с самого начала, при этом все сведения необходимо помещать в CMDB.

Один из самых важных моментов при реализации подхода CMDB связан с определением адекватного уровня детализации. Это объясняет, почему так важно установить, какие инфраструктуры относятся к критически важным. Конечно, можно документировать каждый аспект сети максимально подробно, но это неэффективно. Ограничение степени детализации данных в CMDB может избавить от массы незначащих подробностей, но при этом позволяет находить необходимые элементы, влияющие на возникновение проблемы. Например, инструментальные средства управления сетью, описанные выше, могут принимать участие в формировании CMDB, но хранить в этой базе данных сведения о конфигурации устройств зачастую вовсе не обязательно. Внешние ресурсы могут лучше обрабатывать такие сложные низкоуровневые детали, а CMDB предоставляет подробные сведения об общих функциях и целях данной инфраструктуры.

Большинство производителей систем управления конфигурацией поддерживают концепцию управления изменениями. Один из аспектов управления конфигурацией, который явно может помочь при управлении изменениями, — это управление политикой и проверка соблюдения соответствующих правил. Например, TrueControl компании Rendition Network может генерировать отчет, проверяя, что каждый коммутатор 2950 компании Cisco Systems в сети имеет идентичный список доступа и что небольшие серверы TCP отключены. Более того, можно установить политику, а необходимые изменения конфигурации будут просто распространяться на аналогичные устройства, тем самым уберегая систему от человеческих ошибок, затрагивающих сетевые ресурсы. Конечно, при этом можно растиражировать одну ошибку по всей сети.