авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 8 | 9 || 11 | 12 |   ...   | 33 |

«The Practice of System and Network Administration Second Edition Thomas A. Limoncelli, Christina J. Hogan and Strata R. Chalup Системное и ...»

-- [ Страница 10 ] --

9.1.6. Системы wiki Wiki – веб-средство для публикации и совместной работы, которое произвело революцию в хранилищах документов. Название произошло от Wikiwiki, раз говорной формы слова «быстрый» (quick) по-гавайски. Первая программа для wiki называлась WikiWikiWeb, она и дала начало общему термину wiki.

Wiki – это веб-хранилище документов, которое обеспечивает простое добавление и редактирование документов любому, кто имеет соответствующий доступ.

Документы могут содержать обычный текст, текст на языке разметки гипер текста (HTML) или текст с особыми тегами или командами wiki. Часто в wiki имеется встроенная система контроля исходного кода для проверки создаваемых и удаляемых файлов документации и хранения истории изменений. Более про двинутые системы wiki поддерживают аутентификацию пользователя, автома тизированное добавление тегов или обновление (дата, время, пользователь), блокировку файлов для отдельных пользователей, контроль доступа по имени пользователя или группе и различные степени детализации чтения/изменения/ публикации директорий или поддиректорий отдельных документов.

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

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

Команды форматирования wiki очень легко запомнить и гораздо проще приме нять далеким от техники людям, чем HTML. Поддерживаются многие условные обозначения электронной почты, которыми они уже пользуются, например *этот текст будет полужирным* и _этот текст подчеркнут_. URL автоматически преобразуют Основы ся в гиперссылки. Имена других страниц wiki распознаются и преобразуются в ссылки. Страницы wiki обычно именуются на языке CamelCaps, известном также как WikiWords или StudlyCaps, поэтому программы легко могут их вы явить. При применении слова WikiWord, не связанного ни с какой существую щей страницей wiki, будет сформирована ссылка с предложением пользователю создать страницу.

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

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

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

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

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

Помощь в выборе wiki WikiMatrix (www.wikimatrix.org) предоставляет средства для помощи в сравнении и выборе правильного пакета для конкретной ситуации.

9.1.7. Средство поиска Функционирующей системе документации необходимо средство поиска. Люди часто помещают данные туда, где другим трудно их найти. К счастью, для веб хранилищ существует много встраиваемых поисковых систем. Эти средства варьируются от пакетов с открытым исходным кодом до аппаратных средств, созданных для индексирования данных всей организации. При выборе поиско 272 Глава 9. Документация вой системы учитывайте уровень детализации поиска и наличие нужных вам опций поиска, а также то, какие типы документов доступны для полнотексто вого индексирования.

Предпочтительно иметь возможность ограничения поиска по определенным областям или объектам. Можно задать поиск только по названиям документов или тексту на страницах, с которыми они связаны ссылками. Другие виды по иска могут работать с содержимым самих документов или ключевыми словами либо тегами, связанными со страницами.

Не все системы поиска поддерживают сложные запросы, например требование присутствия или отсутствия определенных слов, или позволяют запрашивать метаданные о документах. В качестве примера последнего можно привести за дание поиска документов, содержащих фразу «лицензия на ПО», созданных до 1 января.

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

Естественно, в данном случае стоит привести аргументы в пользу создания единой папки входящих сообщений для обзора новых материалов. Одним из способов решения данной проблемы является обеспечение автоматической генерации раздела «Последние изменения» как элемента wiki. Некоторые системы позво ляют периодически рассылать эту страницу по списку заинтересованных людей либо настроить ее для предоставления информации в виде RSS-трансляции 1, чтобы ее можно было читать, как блог. Предоставление различных способов до ступа к информации упрощает принятие людьми новшества.

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

По мере того как люди все лучше и лучше знакомились с wiki, они стали просить научить их работать с ней. Том немного сопротивлялся, а затем «сдался». Чем больше он сопротивлялся, тем сильнее сотрудники хотели научиться работать с этой системой. Вскоре ею стало пользоваться столь ко человек, что все новые сотрудники воспринимали ее как официально установленное хранилище документации. А затем она стала таковым.

RSS – это семейство форматов веб-трансляций;

аббревиатура расшифровывается как Really Simple Syndication, Rich Site Summary или RDF (Resource Description Framework) Site Summary.

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

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

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

9.2. Тонкости Теперь, рассмотрев основы создания простых документов и хранилищ докумен тов, мы обратимся к созданию хранилищ большего объема, более формальному подходу и управлению содержимым.

9.2.1. Динамическое хранилище документов Идея сайта «живой документации», или динамического хранилища документов, заключается всего лишь в том, что предполагается периодическое обновление сайта или хранилища для удовлетворения потребностей среды. Интернет-феномен Википедии (www.Wikipedia.org) является прекрасным примером такой системы.

После появления первой энциклопедии Wiki Encyclopedia десятки групп создали хранилища материалов специализированной тематики по данной модели. В от личие от стандартного хранилища документов, «живое» хранилище документации смещает акцент на взаимодействие пользователя с документами. Пользователь может комментировать, редактировать, собирать документы в обзоры, отправлять ссылки на документы коллегам и т. д., а не просто найти и прочитать документ.

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

Применение различных wiki для разных ситуаций Различные программные пакеты имеют разные преимущества. На одном сайте посчитали, что лучше использовать DocuWiki для пользовательской 274 Глава 9. Документация справочной документации, Trac – для документов и обработки заявок, связанных с исходным кодом собственной разработки, и RT – для обра ботки запросов пользователей. На сайте обнаружили, что эти документы довольно редко пересекаются в каких-то аспектах и в этих редких слу чаях легко скопировать и вставить данные или дать гиперссылку, чтобы их связать.

9.2.2 Система управления содержимым Система управления содержимым CMS (Content-Management System) – это система публикации для веб-сайтов. Например, система CMS в газете может помогать репортерам в написании статей, которые затем направляются редак торам, корректируются и одобряются на публикацию. Система CMS выпускает статью в определенное время, размещая ее на веб-сайте, обновляя таблицы со держания и разбираясь с другими деталями. На IT-сайте CMS может предостав лять дополнения, расширяющие функции портала, например возможность отображать обзор недавних сбоев.

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

Уровень представления – это пользовательский интерфейс. Помимо предостав ления возможностей по взаимодействию с документом, например обзору или редактированию, уровень представления может также реализовывать функции контроля, такие как доступ только для чтения или установление разрешений.

Продвинутые системы wiki обладают многими элементами полной CMS. Многие системы CMS в настоящее время обладают функциями, подобными имеющим ся в wiki. Есть две популярные системы CMS с открытым исходным кодом – Drupal и MediaWiki.

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

Когда непонятно, какая версия является правильной, контроль версий, по Тонкости крайней мере, может показать список изменений и предоставить какой-то кон текст, помогающий принять окончательное решение или сформулировать запрос разъяснений по телефону или электронной почте.

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

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

9.2.4. Классификация и структурирование Системы wiki обычно слабо структурированы. Некоторые просто предоставляют возможность навигации.

Не тратьте много времени на структурирование на начальном этапе. Основным врагом wiki-проектов является введение слишком жесткого структурирования на ранних стадиях. Wiki так широко распространились именно благодаря прин ципу низкого уровня ограничений при внесении записей. Обновление страницы должно быть таким же легким, как отправка электронного письма, иначе люди просто не будут пользоваться этой функцией. Гораздо лучше заниматься дове дением некоторых страниц до нужной степени удобочитаемости, чем оставить эту информацию в папках чьей-нибудь почты, где никто не сможет ее найти, когда хозяин в отпуске. Если какой-то тип документа будет многократно созда ваться многими людьми – например, предложения по проектированию или запросы на функции, – создайте шаблон, чтобы эти официальные документы изначально записывались в одном формате.

Различайте написание документации и организацию документации. С ростом объемов ваших материалов люди все чаще будут пользоваться поиском, а не категориями, чтобы найти интересующие их данные. Вы всегда можете создать структурированные категории и реорганизовать страницы или ссылки на них с ростом wiki.

9.2.5. Дополнительное применение документации Приведем еще несколько способов применения системы «живой документации».

Во многих системах wiki есть шаблоны или дополнения специально для этих приложений.

9.2.5.1. Служба самостоятельной помощи Пользователи могут применять раздел службы самостоятельной помощи сайта документации для прямого взаимодействия с сайтом. Возможно, сейчас на ва 276 Глава 9. Документация шем сайте есть ссылка Создать новую заявку, которая позволяет пользователям сделать запрос через систему заявок.

Этот раздел – подходящее место для таких объектов, как новости о запланиро ванных отключениях, обновлениях по текущим процессам и явные ссылки на политики и документы How-To1. В качестве примера последних можно привести «Как войти в систему удаленно через VPN», «Как настроить синхронизацию с мобильным устройством» и т. д.

Еще одна функция в разделе службы самостоятельной помощи – это доступ пользователей к обзору результатов, например графиков загрузки нескольких маршрутизаторов (Multirouter Traffic Graphics – MRTG), или даже вызываемые скриптом данные о свободном месте на общих дисках. Сайты, которые очень заботятся о лицензиях на совместно используемое программное обеспечение, могут убедиться, что размещение ссылки на средство проверки лицензии на этой странице очень полезно, чтобы избежать вопросов о том, какие лицензии у кого проверены.

9.2.5.2. Внутренние документы группы Системные администраторы принимают новшества раньше других, и многие группы системных администраторов создали сайт «живой документации» для собственного удобства. Наличие информации о том, как выполнять сложные задачи, с которыми хорошо знакомы лишь один-два человека в группе, может сэкономить день, когда кто-то заболел или не на месте. Создание собственных документов группы является началом формирования «памяти» подразделения, которая является очень важным элементом преемственности в любой группе.

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

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

9.2.5.3. Документы How-To На многих сайтах имеются короткие пояснительные документы, называемые How-To или HOWTO, которые дают возможность пользователям помочь себе самостоятельно, когда обратиться к системному администратору невозможно.

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

How-To – термин, означающий нечто, передаваемое путем непосредственного практического обучения. – Примеч. науч. ред.

Тонкости Типичными примерами HOWTO являются настройка клиента электронной почты, получение удаленного доступа к сетям или серверами, доступ к принте рам и настройка программ для применения в локальной среде. Сайты универ ситетов, на которых обычно имеется много клиентов системных администрато ров, особенно выигрывают от службы самостоятельной помощи и документов How-To. Сайты, документирующие применение службы поддержки и уровни поддержки в своих организациях, могут использовать для мониторинга и от четности журналы доступа к HOWTO на веб-серверах.

9.2.5.4. Часто задаваемые вопросы Часто задаваемые вопросы (FAQ – Frequently Asked Question) являются средст вом, знакомым большинству пользователей Интернета. FAQ – это просто список наиболее распространенных вопросов по конкретной теме, часто организован ный в виде разделов и подразделов и обычно развивающийся со временем. Не которые дополнения для wiki автоматически создают таблицу содержания, выводя список вопросов в виде гиперссылок, ведущих к ответам (такой подход имеет тот недостаток, что затрудняются чтение всех вопросов и ответов по по рядку, поиск по списку или его распечатка).

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

Если на вашем сайте еще нет списка FAQ, хороший способ его создать – ознако миться с данными системы запросов и посмотреть, какие вопросы поднимают ся чаще других. Типы вопросов будут сильно различаться в зависимости от типа вашей организации и степени поддержки пользователей. FAQ небольшой начинающей технической компании может включать, например, вопрос «Где можно загрузить драйверы для видеокарт в системах наших лабораторий раз работки?». FAQ в некоммерческих организациях может включать вопросы типа «Где наши добровольцы могут открыть бесплатные блоги или создать сайты сообщества?».

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

Вот несколько примеров подобных списков:

• Поставщики и их контактная информация.

• Серийные и инвентарные номера аппаратных средств.

• Лицензионные ключи и количество пользователей для программ.

• Списки совместимости: какие оптические мыши совместимы с какими аппа ратными средствами, какие драйверы работают с какими контроллерами.

• Каталог сотрудников: ручной или автоматически создаваемый из корпора тивной базы данных.

• Корпоративные сокращения.

• Список местных ресторанов, служб такси и т. д.: одна страница на офис.

278 Глава 9. Документация • Для каждого удаленного офиса – список советов для командированных:

предложения по аэропортам, рекомендации по отелям, работает ли обыч ный доступ по личным картам и т. д.

• Кого уведомлять о сбоях, предложениях и комментариях о различных про дуктах и/или проблемах.

9.2.5.6. Процедуры Многие организации должны соответствовать международным стандартам ISO (International Organisation for Standardization), нормам техники безопасности и гигиены труда OSHA (Occupational Safety and Health Administration)1 или положениям закона Сарбейнса–Оксли2 об управлении. Такие сайты выигрыва ют от наличия простого способа создания, поддержки и доступа к процедурам, контрольным спискам и скриптам, относящимся к актуальным методикам.

Создайте журнал регистрации процедур и записывайте соблюдение процедур.

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

9.2.5.7. Техническая библиотека или информационный сборник Документы, полученные от продавцов, поставщиков и клиентов, статьи, кото рые вы купили или загрузили из других источников, и, возможно, даже руко водство по ремонту кухонной раковины – этот раздел хранилища может быть сложным для систематизации. На некоторых сайтах просто создаются списки содержимого в алфавитном порядке, на других назначается библиотекарь, ко торый выполняет подробную классификацию документов. Если классификация будет слишком объемной, это затруднит, а не облегчит поиск документов (в каком разделе искать инструкции по обжатию коннектора для консоли Cisco – «Документы поставщиков», «Кабельные системы» или «Сети»? Доку мент может быть во всех этих разделах, но кто-то должен поддерживать обнов ление ссылок).

9.2.6. Ссылки на внешние источники Интернет содержит огромное количество полезной информации по технической и деловой тематике, от полезных записей в блогах о Linux Documentation Project до совместных сетевых энциклопедий, таких как Википедия. Большую часть этих данных нельзя воспроизвести на вашем сайте из-за авторских прав или В России – нормативам СанПиН и требованиям техники безопасности. – Примеч. науч. ред.

2 Положения закона Сарбейнса–Оксли направлены на обеспечение прозрачности деятельности американских компаний. В соответствии с этим законом компании обязаны внедрять современные формы документооборота, перестраивать систе мы управления, что в итоге позволяет руководству этих компаний предупреждать риски и преодолевать трудности и в целом повышает эффективность и конкурен тоспособность компании. – Примеч. науч. ред.

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

Важно, чтобы для таких ссылок применялась служба перенаправления с со хранением анонимности. Большинство броузеров, когда запрашивают страни цу, включают в запрос ссылку на страницу, которая направила броузер на за прашиваемую страницу. Это позволяет сайтам отслеживать, кто дает на них ссылки и какие из этих ссылок наиболее удачны. Однако имеется проблема безопасности: если направившая страница находится на внутреннем веб-сайте, то сайт, на который была ссылка, узнает о существовании этого внутреннего сайта. Сайт, на который была дана ссылка, может узнать имя вашего внутрен него веб-сервера, что не должно стать проблемой, если только ваша безопасность не основана на простом сокрытии имен узлов. Однако полный URL может рас крыть секретные условные названия проектов и другую информацию1. Напри мер, сайт, который видит ссылки с такого URL, может обнаружить, что вы го товите большой сюрприз в мае. Всего лишь несколько звонков репортерам – и газеты вдруг начинают писать, что в вашей компании есть проект под назва нием quickfox, а большой сюрприз испорчен. Решение этой проблемы состоит в обеспечении перенаправления хранилищем документов внешних ссылок через службу, которая удаляет заголовки источников ссылок.

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

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

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

Например, http://secret.example.com/project/quickfox/competitors-to-destroy may27.html.

280 Глава 9. Документация Документы должны находится в хранилище, чтобы их можно было поддержи вать и использовать совместно. Очень удобной системой для создания хранилищ являются wiki, потому что они упрощают создание и обновление документов и не требуют знания HTML. При помощи дополнений wiki могут предоставлять дополнительные службы.

Людей может быть трудно привлечь к использованию хранилища документации.

Предоставление помощи, обучения и шаблонов снижает этот барьер.

Хранилища могут быть удобны не только для процедур. Они могут стать служ бами самостоятельной помощи и содержать документы HOWTO, списки FAQ, справочную документацию и инвентарные списки.

Группы системных администраторов с напряженным графиком работы всегда приветствуют документирование процессов и распространение информации.

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

Задания 1. Какие темы чаще всего появляются в запросах пользователей на вашем сайте? Какую их долю можно обработать при помощи службы самостоя тельной помощи с несколькими документами HOWTO?

2. Опишите, как вы делитесь информацией с другими членами группы. Что работает лучше всего? Что бы вы изменили?

3. Какие документы в вашей организации больше всего выиграют от наличия шаблона? Создайте шаблон.

4. Какие объекты войдут в шаблон документации в вашей организации? Есть ли среди них необычные или характерные только для вашей группы?

5. Как бы вы оценили простоту использования общей системы документации по десятибалльной шкале? Почему? Как бы вы оценили контроль доступа?

6. Если на вашем сайте или в вашей группе нет хранилища документов, спро сите у трех человек, почему они не хотят его использовать. Если на вашем сайте или в вашей группе есть хранилище, но используется мало, спросите у трех человек, что могло бы упростить его использование. Как бы вы ре шили эти проблемы?

7. Какие из рассмотренных в данной главе решений по созданию общих сис тем документации лучше всего соответствуют вашим ответам на два пре дыдущих вопроса?

Глава Аварийное восстановление и целостность данных План аварийного восстановления рассматривает, какие нештатные ситуации могут затронуть компанию, и предоставляет план реакции на эти ситуации.

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

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

Планированию аварийного восстановления посвящено несколько книг, которые мы рекомендуем для прочтения: Fulmer 2000, Levitt 1997 и Schreider 1998.

При создании плана аварийного восстановления должны приниматься во вни мание как риски, с которыми сталкивается ваш сайт, так и правовые и долговые обязательства вашей компании. С этого вы можете начинать свои приготовле ния. В данной главе рассмотрено, что должно быть включено в план для вашего сайта.

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

10.1.1. Определение нештатной ситуации Нештатная ситуация – это катастрофическое событие, которое вызывает силь ный сбой, влияющий на все здание или сайт. Нештатная ситуация может быть 282 Глава 10. Аварийное восстановление и целостность данных любой: от стихийного бедствия, например землетрясения, до более распростра ненной проблемы случайного повреждения ваших кабелей экскаватором. Не штатная ситуация – это все, что может значительно повлиять на возможность вашей компании вести бизнес.

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

Затем другие сотрудники переносили аппаратуру в соседнее здание. Лю ди ушли из горящего здания, когда решили, что пожар стал слишком опасен.

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

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

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

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

Приблизительный бюджет предупреждения риска определяется по формуле:

( возможные издержки возможные издержки вероятность ( нештатной в случае нештатной – после предупреждения ситуации последствий ситуации Например, если есть один шанс из миллиона, что здания компании пострадают от наводнения, и если наводнение обойдется компании в 10 млн долларов, бюд Основы жет на предупреждение последствий наводнения должен будет находиться в пределах 10 долларов. Иными словами, не стоит даже запасаться мешками с песком, готовясь к наводнению. С другой стороны, если у компании есть один шанс из 3000 оказаться в радиусе 10 миль от эпицентра землетрясения силой в 5 баллов по шкале Рихтера, которое вызовет убытки в 60 млн долларов, бюджет снижения или предотвращения этого ущерба должен быть в пределах 20 тыс. долларов.

В качестве более простого и менее масштабного примера можно привести боль шой сайт, который имеет одну потенциальную точку сбоя, где все локальные сети связываются одним маршрутизатором. Если он откажет, то для его ремон та потребуется один день, и есть 70-процентный шанс, что сбой случится один раз в 24 месяца. Авария приведет к невозможности работы 1000 человек в те чение суток. Компания оценивает потерю производительности в 68 тыс. долла ров. При выборе резервного маршрутизатора системные администраторы будут располагать бюджетом, равным приблизительно 23,8 тыс. долларов. Также системным администраторам нужно определить стоимость снижения времени неработоспособности до 4 ч – например, за счет повышения уровня контракта на обслуживания. Если цена будет разумной, это еще сильнее снизит объемы возможных убытков компании, а следовательно, и сумму, которую она должна будет потратить на полное восстановление.

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

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

Юридический отдел должен уметь детально разъяснить эти обязательства.

Обычно они имеют вид «Компания должна иметь возможность возобновить доставку продукта в течение недели» или «В таких обстоятельствах компания может задержать подачу квартальной отчетности не более чем на 3 дня». Эти обязательства переводятся в требования для плана аварийного восстановления.

Они определяют, как быстро должна быть восстановлена работоспособность различных элементов физической и электронной инфраструктуры. Восстанов ление работоспособности отдельных составных частей компании до полного восстановления всей инфраструктуры требует глубокого понимания того, на какие элементы инфраструктуры полагаются эти части, и подробного плана их 284 Глава 10. Аварийное восстановление и целостность данных возвращения в рабочее состояние. Соблюдение временных рамок также требует понимания того, какое время займет восстановление этих компонентов. Мы рассмотрим это далее в разделе 10.1.5.

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

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

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

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

Большинство механизмов ограничения ущерба находятся где-то между «совер шенно бесплатными» и «очень дорогими». Системы пожаротушения обычно относятся к последней категории. Разумно рассмотреть возможность примене ния системы пожаротушения, спроектированной для ограничения ущерба оборудованию вычислительного центра при активации. Местные законы и требования техники безопасности ограничивают возможности в этой области, но на момент написания книги наиболее популярными были системы на основе инертных газов и выборочные, с ограниченным радиусом действия, системы на основе воды с механизмами раннего предупреждения, которые позволяют опе ратору обнаружить и решить проблему, например, при возгорании диска или источника питания, прежде чем активировать систему пожаротушения. Систе мы, отслеживающие влажность под фальшполами вычислительных центров или в редко посещаемых помещениях с источниками бесперебойного питания либо генераторами, также являются средствами ограничения ущерба средней стоимости.

Основы Еще одна область, часто заслуживающая внимания, – это отключение питания в здании или комплексе зданий. С короткими перебоями в подаче электроэнер гии, скачками или падением напряжения можно справиться при помощи ис точника бесперебойного питания, для более долгих перерывов потребуется ге нератор. Чем больше аппаратуры требует защищенного питания – рефрижера торы в биотехнологических компаниях, центры обработки вызовов в компани ях по работе с клиентами – и чем дольше потребуется поддерживать их работу, тем дороже это будет стоить. Создание вычислительных центров с аварийной защитой рассмотрено в главе 6, особенно в разделе 6.1.1, где обсуждается выбор правильного размещения, и в разделе 6.1.4, где объясняются вопросы, связан ные с электропитанием.

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

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

Восстановление служб после аварии может потребовать перестройки необходи мых данных и служб на новом оборудовании, если старое оборудование нерабо тоспособно. Таким образом, вам нужно заранее определить источник замены оборудования из компаний, которые предоставляют эту услугу. Вам также потребуется наличие другого помещения, куда можно будет переместить это оборудование, если основное помещение нельзя использовать по соображениям безопасности, из-за недостатка электроэнергии или плохой связи. Убедитесь, что компания, предоставляющая рабочее оборудование, знает, куда его нужно отправлять в случае аварии. Убедитесь, что у вас есть временные обязательства по замене от поставщика и что вы знаете, какое оборудование компания сможет поставить по первому требованию. Не забудьте учесть время замены этого обо рудования при подсчете общих затрат времени на процесс. Если нештатная ситуация достаточно серьезна и требует обращения к услугам компании, впол не возможно, что у нее будут другие клиенты, которые также пострадают. Уз найте, как компания планирует справиться с ситуацией, при которой как вы, так и ваш сосед будете иметь право на единственный крупный сервер Sun, ко торый был зарезервирован.

Как только у вас будут машины, вам потребуется восстановить систему. Обыч но сначала вы реконструируете систему, а затем восстанавливаете данные. Это требует наличия резервных копий данных вне сайта – обычно в коммерческой службе хранения. Вам также потребуется возможность легко определить, какие кассеты потребуются для восстановления основных служб. Этот этап базовой подготовки строится на инфраструктуре, которая уже должна быть на вашем сайте. Следующий этап подготовки к нештатной ситуации – попробовать полу чить кассеты у сторонней компании, которая занимается хранением, в общем порядке и посмотреть, сколько это займет времени. Это время вычитается из общего количества времени, которое отведено на полное восстановление рабо тоспособности важнейших систем. Если получение кассет занимает слишком много времени, полное восстановление в приемлемые сроки может быть невоз 286 Глава 10. Аварийное восстановление и целостность данных можным. Более подробно эти вопросы рассмотрены в главе 26, особенно в раз деле 26.2.2.

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

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

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

Центр обработки вызов был вынужден оставаться на улице несколько дней, пока не была подтверждена безопасность здания. Но для клиентов он оставался работоспособным все время.

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

10.1.6. Целостность данных Целостность данных означает обеспечение неизменности данных под действи ем внешних источников. Данные могут быть повреждены злоумышленно при помощи вирусов или вручную. Также они могут быть повреждены случайно в результате действий людей, багов в программах и не обнаруженных вовремя сбоев оборудования. Целостность важных данных необходимо обеспечивать путем определенных операций и ежедневного резервного копирования и архи Тонкости вации. Например, данные, которые не должны изменяться, можно проверять по неизменяемой контрольной сумме данных. Базы данных, в которых преду смотрены лишь небольшие изменения или только добавление данных, могут проверяться на неожиданно большие изменения или удаления. В качестве при меров можно назвать системы контроля исходного кода и базы данных генети ческих последовательностей. Учитывайте известные вам особенности данных в ваших системах при создании автоматизации проверки целостности.

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

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


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

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

Другими словами, должен иметься резервный сайт с резервными системами.

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

Несмотря на высокие затраты, в крупных компаниях, особенно в банках, нали чие резервного сайта является необходимостью. Фактически крупные компании перестали использовать термин «аварийное восстановление» и вместо него пользуются термином «планирование резервных вариантов» или «планирова ние непрерывности бизнеса».

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

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

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

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

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

Мы постоянно видим сайты, которые покупают крупные готовые системы, не требуя объяснения рисков безопасности этих систем. Хотя ни одна система не является абсолютно безопасной, продавец должен уметь объяснить структуру безопасности продукта, факторы риска и восстановление в случае потери дан ных. В главе 11 рассмотрено создание политик и процедур безопасности, кото рые учитывают планы по аварийному восстановлению.

10.2.3. Отношения с прессой Когда произойдет чрезвычайная ситуация, журналисты, скорее всего, захотят узнать, что случилось, как это повлияло на компанию и когда службы будут восстановлены. К сожалению, обычно вы можете дать лишь один ответ на все три вопроса: «Мы не знаем». Это, пожалуй, является наихудшим ответом, ко торый можно дать репортеру. Невнимательное отношение к прессе во время чрезвычайной ситуации может вызвать больше проблем, чем собственно сама ситуация.

По этому вопросу у нас есть две простых рекомендации. Во-первых, заключите соглашение с компанией по связям с общественностью (PR – Public Relations) заблаговременно, чтобы вы не пытались привлечь ее к сотрудничеству во время чрезвычайной ситуации. Некоторые PR-компании специализируются на чрез вычайных ситуациях, другие являются экспертами в области нарушений безо пасности. Во-вторых, заблаговременно планируйте, как вы будете общаться Заключение с прессой. Этот план должен включать следующее: кто будет общаться с прессой, что будет и что не будет сказано и каков порядок цепочки управления при от сутствии ответственных за принятие решений. Все, кто будет общаться с прес сой, должны пройти подготовку в вашей PR-компании.

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

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

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

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

К этой категории относятся системы пожаротушения, обнаружения воды, сей смоустойчивые опоры и подходящее оборудование, монтируемое в стойках.

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

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

Задания 1. Какие подразделения бизнеса вашей компании потребуется восстановить после чрезвычайной ситуации в первую очередь и в какие сроки необходи мо сделать их работоспособными?

2. Какие обязательства есть у вашей компании перед клиентами и как эти обязательства влияют на ваше аварийное планирование?

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

290 Глава 10. Аварийное восстановление и целостность данных 4. Каковы будут расходы вашей компании, если чрезвычайная ситуация средней силы затронет одно из помещений?

5. Какие формы ограничения воздействия чрезвычайных ситуаций вы сей час используете?

6. Какие формы ограничения воздействия чрезвычайных ситуаций вы хоте ли бы внедрить? Сколько стоит каждая из них?

7. Как бы вы восстановили обслуживание, если бы работоспособность вычис лительного центра нарушилась из-за чрезвычайной ситуации?

8. Каковы ваши планы по общению с прессой в случае чрезвычайной ситуа ции? Как называется PR-компания, которую вы привлечете для помощи?

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

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

Безопасность – это широкая тема, по которой написано много хороших книг.

Цвики, Чепмэн и Купер (Zwicky, Chapman and Cooper 2000) и Белловин, Чесуик и Рубин (Bellovin, Cheswik and Rubin 2003) написали отличные книги о межсе тевых экранах. В книгах Гарфинкеля и Спэффорда (Garfinkel and Spafford 1996, 1997) рассмотрены вопросы безопасности UNIX и Интернета, а также веб-безо пасности и безопасности электронной коммерции. Норберг и Рассел (Norberg and Russel 2000), а также Шелдон и Кокс (Sheldon and Cox 2000) предоставляют подробный обзор безопасности Windows. Книга Miller and Davis 2000 охваты вает область интеллектуальной собственности. Вуд (Wood 1999) хорошо извес тен своими образцами политик безопасности. Ковачич (Kovacich 1998) рассмат ривает тему создания программы для защиты информации. Нойманн (Neumann 1997) и Деннинг (Denning 1999) рассматривают тему рисков и информационно го противоборства.

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


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

292 Глава 11. Политика безопасности Мы надеемся, что из этой главы вы усвоите в первую очередь следующее: поли тика, которую легко и приятно соблюдать, – самая удобная для пользователя.

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

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

11.1. Основы Две основные схемы политики безопасности – это безопасность периметра и глубокая защита.

1. Безопасность периметра – это что-то вроде крепости с высокими стенами.

Постройте хорошую стену – и вы сможете делать внутри что угодно. По ставьте хороший межсетевой экран на входе в вашу сеть – и вам не придется беспокоиться о том, что будет внутри. В книге Bellovin, Cheswick and Rubin 2003 данный подход рассматривается как «твердый леденец с мягкой на чинкой», или политика, при которой «все яйца складываются в одну кор зину, а затем обеспечивается защищенность этой корзины». Проблема безо пасности периметра в том, что «твердая оболочка» исчезает с распростране нием беспроводных сетей и соединением сетей организации и партнеров.

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

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

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

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

Некоторые считают, что безопасность обратно пропорциональна удобству. То есть обеспечение большей безопасности какого-либо объекта затрудняет его использование. Это, конечно, было справедливо для ряда продуктов по обеспе чению безопасности. Мы полагаем, что, когда обеспечение безопасности осу ществляется правильно, учитывается и простота работы пользователей. Про блема в том, что часто технологии требуется несколько лет, чтобы дойти до данного уровня развития. Например, пароли являются хорошей практикой, но установка паролей на каждое приложение становится головной болью для лю дей, которые в ежедневной работе используют много приложений. Однако при повышении безопасности за счет развертывания системы единой авторизации увеличивается и удобство в результате усиленной безопасности при практичес ки полном отсутствии необходимости введения пользователями паролей.

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

Безопасность и надежность Безопасность и надежность тесно связаны между собой. Небезопасная система открыта для атак, что делает ее ненадежной. Злоумышленники могут вывести ненадежную систему из строя за счет использования уяз вимостей, что представляет собой атаку «отказ в обслуживании» (Denial of-Service, DoS-атака). Если руководство не интересуется проблемой бе зопасности, разберитесь, важна ли для него надежность, и если да, представляйте все вопросы безопасности как вопросы надежности.

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

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

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

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

294 Глава 11. Политика безопасности Публичная информация может включать литературу по маркетингу, руковод ства пользователей и публикации в журналах или на конференциях. Конфи денциальная информация компании может включать схемы организации, те лефонные справочники, внутренние новости с финансовыми результатами, направление коммерческой деятельности, статьи по продуктам в разработке, исходный код или политики безопасности. Строго конфиденциальная инфор мация должна очень серьезно отслеживаться и быть доступной только тем, кому она действительно необходима. Она может включать переговоры по кон трактам, информацию о сотрудниках, особо секретные подробности разработки продукции или интеллектуальную собственность клиента.

Другой аспект защиты информации – защита от злонамеренного изменения, умышленной или случайной утечки информации, ее кражи или уничтожения.

Пример: защита от злонамеренного изменения Сотрудники ведущей нью-йоркской газеты рассказали консультанту по безопасности, что, несмотря на свое беспокойство о возможной краже информации, их главной проблемой была возможность необнаруженной модификации информации. Что произойдет, если отчет о компании будет намеренно искажен? Что случится, если заголовок будет заменен непри личным выражением? Фраза «Сегодня [вставьте название вашей любимой ведущей газеты] сообщила…» имеет очень большую ценность, которая была бы дискредитирована, если бы злоумышленники могли изменять содержимое газеты.

11.1.1.2. Доступность обслуживания В большинстве случаев компании требуется защищать доступность обслужива ния. Если компания в ведении бизнеса полагается на доступность определенных электронных ресурсов, то одной из задач группы безопасности будет предотвра щение DoS-атак против этих ресурсов. Часто компании не думают об этом, пока не начинают предоставлять интернет-услуги, потому что сотрудники обычно не склонны проводить такие атаки против своей собственной компании.

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

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

Пример: решите, что важно, а затем защищайте это Любому консультанту часто приходится слышать различные ответы на вопрос «Что вы хотите защитить?». Обычно (но не всегда) ответ предска зуем.

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

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

Подразделение по производству оборудования в большой транснацио нальной компании в области электроники имело другой приоритет.

В данном случае наиболее важны были доступность систем контроля производства и доступ к ним.

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

296 Глава 11. Политика безопасности 11.1.2. Документируйте политики безопасности компании Политики – это основа всего, что делает группа обеспечения безопасности.

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

Естественно, все политики должны быть одобрены высшим руководством.

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

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

• Политика допустимого использования (Acceptable Use Policy – AUP) опре деляет правомочных пользователей компьютерных и сетевых ресурсов, а также то, для чего им разрешено использовать эти ресурсы. AUP также может включать некоторые явные примеры недопустимого использования.

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

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

• Политика удаленного доступа должна объяснять риски, связанные с полу чением доступа к сети людьми, не имеющими на это права, описывать необ ходимые меры предосторожности для «секретных» данных человека – па роля, персонального идентификационного номера (Personal Identification Основы Number – PIN) и т. д. – и обеспечивать способ оповещения об утерянных или украденных данных для удаленного доступа, чтобы их использование можно было быстро запретить. Эта политика также должна содержать не которые вопросы личного характера – например, о размере обуви и люби мом цвете, – при помощи которых люди могут быть идентифицированы по телефону. Каждый должен заполнить и подписать копию этой политики перед разрешением удаленного доступа.

• Политика сетевых соединений описывает, как компания устанавливает се тевые соединения для других субъектов или некоторых общих ресурсов для доступа третьих сторон. Каждой компании в определенный момент потре буется установить деловые отношения с другой компанией, что потребует более простого доступа к сети и, может быть, наличия некоторых общих ре сурсов: расширенной интрасети. Вы должны заранее подготовиться к это му. Политика должна быть распространена по всем уровням руководства и предусматривать участие группы обеспечения безопасности на макси мально ранней стадии. В политике должны быть перечислены различные поддерживаемые типы соединений и общих ресурсов, офисы, которые мо гут поддерживать соединение с третьими сторонами, и типы поддерживае мых соединений.

• Политика ведения журналов (или логов) описывает, что заносится в жур налы и на какой срок. Журналы полезны для отслеживания нарушений бе зопасности после того, как они произошли, но могут занимать большие объ емы дискового пространства при отсутствии временных ограничений. Так же важно знать, существуют ли логи определенной даты, в случае вызова в суд по уголовному делу.

Пример: применение лучших технологий упрощает политику Самая легкая для соблюдения политика – максимально упрощенная.

Например, в политики использования паролей часто включают руковод ства по созданию подходящих паролей и указывают, с какой периодич ностью они должны меняться на машинах различных классов. Эти по дробности могут быть сокращены или исключены за счет применения лучших технологий. Например, инфраструктура Bell Labs включает сис тему электронных удостоверений (HandHeld Authenticator – HHA), кото рая вообще не требует использования паролей. Что может быть проще?

Электронные удостоверения Для удостоверения личности людей используется HHA, устройство раз мером с калькулятор или толстую кредитную карту. Для идентификации пользователя HHA генерирует одноразовый пароль (OTP – One-Time Password). Один класс HHA отображает новую комбинацию из 7 цифр каждые 30 с. Часы синхронизированы, поэтому узел знает, какие цифры должны быть введены конкретным пользователем. Вместо пароля поль зователь вводит цифры (HHA защищено PIN-кодом). Таким образом, 298 Глава 11. Политика безопасности компьютер может знать, что пользователь – действительно тот, за кого себя выдает, или, по крайней мере, держит в руках соответствующее HHA и знает PIN-код этого человека. Это более безопасно, чем пароль, который никогда не меняется или меняется очень редко.

HHA могут использоваться для авторизации на узлах, получения уда ленного доступа – UNIX-команда su – и даже получения доступа к веб сайтам. С такой инфраструктурой политики использования паролей становятся гораздо проще. Узлы за пределами межсетевого экрана боль ше не требуют политик использования паролей, потому что здесь не применяются жесткие пароли. Получение безопасного root-доступа к UNIX-системам, которое ранее было затруднено из-за опасений по по воду перехвата паролей, стало более реальным за счет преимуществ HHA в сочетании с шифрованием1. Этот пример показывает, как правильно организованное усиление безопасности делает систему более удобной.

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

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



Pages:     | 1 |   ...   | 8 | 9 || 11 | 12 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.