Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
298
PAGE 300
EMBED Word.Picture.8
XIV. УПРАВЛЕНИЕ ДАННЫМИ
Управление данными – необходимый процесс
Основная концепция управления данными
Управление данными в экспедициях и экспериментах, пунктах измерений
Управление данными в центрах обработки данных
Управление данными в отдельных проектах
Управление данными и знаниями на уровне корпорации
Состав и структура Плана управления данными
Управление данными с помощью Интернет
Администрирование БД
Повышение надежности работы БД
В чем нуждается администратор БД?
Рекомендации по защите БД
Управление данными – необходимый процесс
БД окажутся невостребованными, если конечным пользователям не объяснить, какие данные теперь им доступны, и не убедить их, что эти данные полны, точны и полноценны. Многие организации считают, что достаточно обучить конечных пользователей общим приемам работы с приложениями по доступу к БД, и все вопросы решены. Гораздо важнее обучить пользователей анализу данных. Пользователь, обученный работе с приложениями, но не знающий, как их использовать, не сможет получить желаемые аналитические результаты. Соответственно, такой пользователь либо обратится в IT-отдел, либо вообще откажется от использования БД. Для того чтобы улучшить работу с БД пользователям, вводятся должности администраторов БД (АБД).
В соответствии с [4] термин «управление данными (data management) – общее понятие, описывающее функции системы, которые обеспечивают создание и доступ к хранимым данным, соблюдение соглашений о хранении данных, регулирование использования устройств ввода – вывода». Этот термин долгое время использовался только для данных, находящихся в памяти ЭВМ. Основным инструментом управления данными здесь является СУБД.
Термин «организационное управление данными» появился в начале семидесятых годов. Управление данными в рамках экспедиций, центров сбора или проектов включает в себя процессы переработки данных, начиная от сбора данных и заканчивая их архивацией и доведением до пользователей. При этом рассматриваются как технологические, так и организационные вопросы. Основным инструментом организационного управления является «План управления данными».
Первый план управления данными (ПУД) был разработан в 1974 г. в период подготовки к Атлантическому эксперименту Программы исследований глобальных атмосферных процессов (АТЭП). Главной целью этого плана было использование универсального формата всеми участниками эксперимента. Так в первой записи всех дисциплинарных массивов в формате АТЭП было описание сведений об этом массиве данных и его структуры (создание метаданных). С этого момента для большинства международных и национальных проектов и программ начали составляться ПУД. Эволюция управления данными дана в табл.1.
Таблица 1 - Эволюция управления данными
|
Этап развития |
Форма участия |
|
Осознание необходимости управления объектом с помощью БД |
Разработка концепция |
|
Выдвижение идеи по использованию БД |
Оценка эффективности предлагаемых решений |
|
Постановка цели создания БД |
Повышение эффективности использования данных |
|
Осознание необходимости создания БД |
Подготовка приказа, составление проекта плана работ |
|
Неприятие в использовании БД |
Убеждение пользователей в необходимости создания БД |
|
Понимание необходимости создания БД |
Участие пользователей в выработке технических требований к БД |
|
Принятие концепции БД |
Составление технической спецификации на БД |
|
Выработка требований к БД |
Разработка технического задания |
|
Разработка БД |
Разработка приложений по вводу и использованию БД |
|
Ввод в эксплуатацию БД |
Акт сдачи |
|
Эксплуатация БД |
Выявление ошибок, оптимизация технологии эксплуатации |
Первые попытки унифицировать требования по представлению данных предпринимались еще в конце шестидесятых годов. Межправительственная океанографическая комиссия (МОК) ЮНЕСКО разработала форму РОСКОП, которая стандартизировала представление сведений о рейсах научно-исследовательских судов, предназначенных для международного обмена. Эта форма действует по настоящее время. В России в восьмидесятых годах было разработано руководство по оформлению научно-технических отчетов о рейсах НИС, в котором стандартизированы как формы таблиц для представления данных различных дисциплинарных массивов, так и форматы сбора данных с используемыми классификаторами.
В девяностых годах под эгидой комиссии Европейского сообщества (ЕС) было разработано несколько документов для лучшей практики документирования данных, управления данными в отдельных проектах и классификаторы данных (A Guideline for better Practice in Data Documentation. - MAST Data Committee. - March 1997. - 3 pp.; A Guideline for Project Data Management. - MAST Data Committee. - March 1997. - 3pp.; Data Management in MAST Projects: Code on Data Management in MAST Projects. 4th revision. 1996. - 3 pp.).
Управлением данными занимается много рабочих групп в различных международных организациях (Международный совет научных союзов, Всемирная Метеорологическая Организация, МОК), которые разработали ряд рабочих документов по управлению данными, как для отдельных проектов, так и для отдельных дисциплин. С девяностых годов стали регулярно проводиться курсы по управлению данными. В 2007-2009 годах проводился Международный полярный год, за два года до его начала было начато обсуждение политики и плана управления данными. В 2009 г. утвержден стандарт ISO/TR 15801:2009 [6].
Главной целью создания плана управления данными является увеличение эффективности доступа к данным.
Основная концепция управления данными
Создание плана управления данными должно учитывать долгопериодные решения по:
Методология управления данными должна быть основана на применении наиболее эффективных средств, разработанных в рамках международного сотрудничества или отдельных странах за счет:
План управления данными способствует лучшему пониманию проблем обмена данными всеми участниками проекта, объединению научных интересов, общественных потребностей и правовых вопросов. Управление данными есть процесс, который начинается с проектирования измерительной программы экспедиции (проекта), или создания БД и заканчивается доступом к качественно проконтролированным и хорошо документированным данным. План управления данными должен быть ключевым элементом всех крупных проектов и программ. План управления данными есть добавочная активность, которая помогает максимизировать возврат инвестиций, сделанных в проект с помощью финансирования для целей всестороннего использования получаемых данных. План управления данными есть механизм распространения и использования БД, полученных в проекте.
План управления данными есть специальная активность, выполняемая в рамках национальной и международной политики, основанной на лучшей международной практике обмена данными. Он должен описывать работу, технологические требования и соответствующие результаты в проектировании измерительной активности, отчетности по сбору данных, документировании, контроле качества и создании БД, электронной публикации данных.
Одной из главных задач любого проекта, а особенно центра данных, является создание баз метаданных. Основными метаданными, которые необходимы для использования при управлении данными, являются сведения о:
Этапы разработки Плана управления данными включают:
Общие подходы в управлении данными позволяют получить пользу как ученым, работающим в этих проектах, так и научному сообществу в целом (более быстрое использование данных); сделать эффективнее использование большинства источников данных; хорошо документировать и проконтролировать данные, предназначенные для общего использования по окончанию проекта экспедиции.
Адекватное управление данными определяется возможностями национальных организаций политическими аспектами, техническими проблемами, условиями финансирования проектов, хорошей координацией всех участников проекта, наличием соответствующего квалифицированного штата, социальными льготами (для проведения экспедиционных работ).
Управление данными можно рассматривать на уровне отдельной экспедиции, центра сбора данных, проекта (программы), рис.1. Каждый уровень управления данными включает предыдущие уровни. Например, управление данными на уровне центра обязательно включает сбор данных от источников данных, т.е. управление данными на уровне источников данных. Крупная научная программа может включать несколько наблюдательных проектов, каждый из которых может иметь свой план управления данными.
Рисунок 1 – Схема управления данными
Управление данными в экспедициях и экспериментах, пунктах измерений
Для управления данными на этом уровне организуются группы (отряды) управления данными. Отряды располагаются, как правило, на флагманских судах экспедиции. Основной задачей этих отрядов является организация занесения данных на технические носители непосредственно в экспедиции. Критериями работы отрядов управления данными могут быть скорость доведения данных до архивного хранения и пользователей
Управление данными в центрах обработки данных
Одновременно с организацией управления данными на уровне источников данных развивалось управление данными в центрах сбора (мировых и национальных центрах данных). После создания в 1957 г. системы мировых центров данных началась работа по занесению данных на технические носители по различным дисциплинам. По мере увеличения числа дисциплин, по которым собирались данные, накопления данных в различных форматах, перехода обработки данных с одного на другое поколение ЭВМ, существенно усложнилась проблема управления данными в центрах сбора. Необходимо не только отслеживать форматы сбора данных, но и правила конвертирования, чтобы не потерять информацию. Появилась проблема дублирования данных, полученных из разных источников (от разных стран и Мировых центров данных). На первое место выдвинулась проблема качества данных. Одной из важных проблем стало создание упорядоченных БД с эффективным доступом к ним. Для решения этих задач создаются:
Так как большого опыта в управлении огромными массивами данных (сотни Гигабайт) не было ни в России, ни в других странах, то каждый центр разрабатывал свои технологии управления данными. Только в девяностых годах, когда основные дисциплинарные массивы с большей или меньшей полнотой были переведены на современные технические носители, а возможности персональных ЭВМ позволили обрабатывать эти данные, наилучшим способом управления данными в центре стало применение мощной коммерческой СУБД. При этом стало возможным создать интегрированную БД (т.е. объединить в рамках одной БД несколько дисциплинарных массивов). Главной проблемой управления данными в центрах обработки данных становится качество, сохранность и восстановление данных после сбоев.
Безусловно, проблема управления сбором данных остается, но она смещается на уровень управления данными в экспедициях, проектах и в Интернет. Критерием управления данными в центрах является полнота сбора данных и последующее длительное использование данных на основе современных средств Интернет и на компактных дисках.
5. Управление данными в отдельных проектах
План управления данными проекта отражает руководящие документы, необходимые для подготовки решений по переработке данных. Критериями управления данными в этом случае являются:
План управления данными формируется на этапе подготовки научных предложений по проекту в виде раздела управления данными или самостоятельного документа. План управления данными должен отражать проектные решения по технологиям сбора данных, подходы к организации БД, используемые стандарты и др., которые могут более эффективно использоваться в проекте. Сейчас для большинства проектов управление данными есть часть большой работы, для которой создаются специальные группы по отдельным дисциплинам или научным направлениям исследований. План управления данными на этом уровне должен отражать:
Управление данными и знаниями на уровне корпорации
Управлению данными в крупных корпорациях стали уделять больше внимания только в последние годы. Главными критериями управления данными здесь является оперативное обеспечение ЛПР тенденциями изменения отслеживаемых показателей.
Но, к сожалению, ЛПР сами не всегда знают, какие показатели им нужно отслеживать, чтобы успешно управлять предприятием, какие значения показателей являются индикаторными. Руководитель предъявляет кажущиеся хаотичными требования к информационному обеспечению именно потому, что он не всегда знает, что ждет организацию завтра.
ЛПР возлагают большие надежды на аналитиков, которые отслеживают тенденции на основе массивов и БД. Но любая экстраполяция неточна. Занимаясь только экстраполяцией тенденции изменения показателей, можно обеспечивать себе вполне устойчивое существование до тех пор, пока не изменится тенденция. Есть аналитики, которые улавливают не только тенденции, но могут дать вероятность изменений.
Отслеживание тенденций изменений показателей бизнеса и прогнозирование ситуации на рынке должно быть основной задачей ИТ-технологий. Для этого нужно вести информационный поиск (бизнес разведку) и анализ данных. Практически каждый ЛПР в той или иной мере имеет дело с управлением знаниями и с извлечением важной информации и знаний из неструктурированной информации, их обработкой и распространением. Это тоже должно быть составной частью плана управления данными на уровне корпорации.
План управления данными должен обеспечить получение знаний, их фиксацию, отчуждение от носителей, распространение и доставку потребителям в масштабах всей организации, а затем обеспечить сопоставление информации, поступившей в компанию через разные источники (прежде всего, через сотрудников различных подразделений, которые взаимодействуют с партнерами, клиентами, коллегами из других организаций). Анализ информации из множества источников, а также анализ различий позволяет выявить очень важные изменения тенденций. Для такого анализа необходимо применить ИТ-инструменты.
Обеспечение обмена сведениями между разными подразделениями это задача управления данными. Наряду с этим в плане должна быть отражена технологическая поддержка информационного взаимодействия, включая разработку и эксплуатацию БД. Вопросы хранения, разработки политики в области корпоративной структуры хранения и подготовки специалистов, способных организовать эффективное управление этой структурой должно являться частью плана управления данными.
План управления данными должен помочь создать корпоративную культуру совместного использования информации и знаний. Управление данными находится пока на ранней стадии развития.
Управление данными с помощью Интернет
Для этого на сайтах организаций, отвечающих за проект, сосредотачивается вся необходимая информация по управлению данными. Сайт становится главным информационным средством для оперативного управления данными. Web-сайт позволяет не только информировать, но и контролировать число информационных ресурсов, время их актуализации, число посещений, выявлять наиболее активных пользователей и наиболее востребованные информационные ресурсы, и т.п. Основными методами управления данными в Интернет являются:
Вопросы управления инфраструктурой хранения данных в Интернет, выстраивания корпоративной политики использования ИР практически не рассматриваются в компаниях. При этом используются серверы БД, приложений, Web серверы и разнообразные подходы к виртуализации, консолидации, интеграции данных. А необходим общий взгляд на архитектуру хранения, доступа через различные устройства, анализ достоинств и ограничений решений разных производителей, понимание общих проблем построения неоднородных сетевых инфраструктур хранения.
Основным объектом управления данными становятся распределенные информационные ресурсы. Функциями управления распределенными ресурсами являются:
Состав и структура Плана управления данными
В связи с тем, что в исследовательских проектах, программах и экспериментах иногда принимает участие много организаций и стран, наблюдается слабая взаимосвязь между исследователями различных наук; мало внимания уделяется междисциплинарным исследованиям; координация исследований между различными ведомствами одной страны недостаточна; текущие программы исследований, как правило, ограничены специфическими объектами исследований и собирают относительно небольшое число измеряемых параметров, а координирующие организации не достаточно внимания уделяют управлению данными, необходима разработка плана управления данными. Основными этапами создания плана управления данными являются:
План управления данными должен включать:
Целями управления данными являются:
Критериями реализации ПУД может быть 100% полнота сбора данных и доступность данных - в течение 30 мин. после измерения.
Источниками информации для подготовки разделов «Обзор» и «Описание БД» являются:
Основным методом при выполнении этих разделов является поиск информации, по результатам которого дается:
Основная концепция управления данными. В этом разделе рассматриваются принципы управления, политика управления данными, объект и функции управления, документирование данных, применяемых информационных систем, использование стандартов, контроль качества данных. Методология управления данными должна быть основана на применении самых эффективных средств, разработанных в рамках международного сотрудничества или отдельных странах. Важным моментом Плана управления данными должны быть наличие нормативных документов (статус информационных технологий, включающий правила взаимодействия с информационными системами, обмена данными и т.п.).
Классификация, поиск и инвентаризация, сбор и обмен данными. Представляются методы создания баз метаданных, поиска и обмена данными, распространения информации и продукции. Одной из главных задач любого проекта является создание баз метаданных.
Методы обработки данных. В этом разделе рассматриваются методы вычисления статистических характеристик, создания расчетных БД и временных серий наблюдений, развитие приложений по обработке данных, ГИС применений.
Программное обеспечение для обработки данных. План управления данными включает программное обеспечение для сбора текущих, исторических, расчетных и модельных данные, получения информационной продукции. При разработке программного обеспечения используются следующие общие решения: стандарты на методы наблюдений, форматы исходных, модельных данных, метаданных, интерфейс, термины и определения, языки описания данных и манипуляции. Рекомендуется использовать современные инструментальные средства для СУБД, ГИС, СППР и др. на всех стадиях обработки данных (сбора, накопления, хранения, вычисления, анализа, интерпретации и распространения данных).
Международное сотрудничество. В этом разделе отражаются международные связи, участие в программах и проектах, роль различных организаций.
Использование сетей для управления данными. Определяются стандарты на технические средства и программное обеспечение для использования Интернет.
Основные шаги реализации Плана управления данными включают:
разработка интегрированной БД.
К Плану управления данными прилагаются списки комитетов, рабочих групп, участвующих организаций, описание наблюдательных национальных и международных проектов для данного региона; примеры описания форматов хранения и обмена данными, применяемых кодов и классификаторов, что способствует лучшему пониманию объединения интересов, общественных потребностей и правовых вопросов всеми участниками проекта.
7.Администрирование БД
Типы администраторов и их обязанности могут отличаться в зависимости от конфигурации СУБД и от конкретной организации. В крупных системах, например, обязанности администратора БД могут распределяться среди нескольких специалистов. В то же время в небольших системах один человек может выполнять функции нескольких типов АДМ одновременно. У каждой компании свои потребности, основанные на характере используемых приложений.
Маленькие центры, имеющие только сайт в Интернете, небольшие производственные фирмы, или даже крупные отделы, только-только переходящие на использование мощной СУБД, вполне могут обойтись одним АБД, выполняющим весь спектр задач. При этом АБД занимается поддержкой небольшой локальной сети, обновлением контента Интернет -сайта, сопровождением правовых и бухгалтерских программ. Задачи, актуальные для небольших фирм, не требуют громоздких программных комплексов по обработке информационного потока компании, а разработку дополнительных приложений выгоднее отдавать специализированным ИТ–компаниям.
Для средних организаций характерна некоторая избыточность персонала и при этом имеется определенная выгода от совмещения обязанностей несколькими людьми, поскольку можно безболезненно отправить сотрудника на учебу или в отпуск, сообща работать по вечерам и выходным и так далее. Задачи средних компаний и информационный поток внутри них приводят к необходимости создания отдельного ИТ- подразделения. Уровень подготовки и численность отдела варьируется в зависимости от решаемых задач. Это могут быть специалисты по локальным сетям, базам данных, безопасности, различным правовым и бухгалтерским системам.
В крупных центрах существует четкое разделение АБД по классам, в каждом из которых присутствует по несколько АБД различного опыта, благодаря чему текучесть кадров минимально сказывается на эксплуатации БД [3].
Рисунок 2 - Типовая схема ИТ-компании (Источник: CNews Analytics)
Важным моментом работы АБД является структура ИТ-компании. Типовая схема компании дана на рис. 2.
Служба технической поддержки выполняет ежедневную рутинную и неблагодарную работу, связанную с поддержкой пользователей: принимает информацию о сбоях, общается с пользователями, поддерживает информационные потоки.
Отдел программной поддержки решает частные проблемы, возникающие с программным обеспечением, и создает новые информационные продукты. Штат в основном состоит из программистов, технических писателей и тестировщиков.
Аналитический сектор проводит анализ бизнес–процессов, разрабатывает архитектуру и средства визуального отображения информации.
Сектор управления проектами курирует проекты и распределяет задания, которые формулирует руководство компании.
В зависимости от размеров информационного управления или компании аналитики могут входить, как в сектор управления проектами, так и в отдел программной поддержки. В некоторых компаниях, имеющих большое количество проектов включает в штат менеджеров проектов, отвечающих за тот или иной проект, в который вовлечено достаточно большое число подразделений ИТ компании.
Сектор контроля качества данных призван контролировать и стандартизировать структуры данных и тестировать готовые программные решения.
Служба безопасности состоит из инженеров по безопасности и практически всегда выделяется в отдельный отдел. Размер штата службы и ее роль на предприятии диктуются спецификой хозяйственной деятельности компании, уровнем ее инновационности, статусом.
В ИТ–компании одной из основных задач становится создание готового продукта – программы для управления информационными потоками. В состав ИТ компании могут входить различные специализированные на конкретных задачах отделы. Типовая схема такого подразделения выглядит следующим образом, рис.2. Для эффективной работы подразделения руководству необходимо четко определить возможные задачи. Именно, исходя из них, следует формировать штат сотрудников. Важно также представлять ценность каждого сотрудника в целом для ИТ компании. При этом, независимо от размеров компании, структура ИТ-отделов будет во многом схожа.
Можно выделить основные типы администрирования, характерные для всех систем:
Кроме того, в зависимости от опыта администраторы БД могут иметь следующие должности и выполнять разные обязанности:
В больших организациях, кроме АДБ, имеются аналитики, архитекторы, распределение их ответственности дано в табл.2.
Таблица 2 - Распределения ответственности при внедрении решения для создания БД
|
Объект |
Требования к данным |
Ответственность |
|
Модель бизнес-процессов |
Определение бизнес-процессов, функций |
Аналитики |
|
Архитектура данных |
Определение объектов, атрибутов, связей |
Архитекторы и аналитики данных |
|
Архитектура баз данных |
Проектирование баз данных Определения таблиц Определения столбцов, ключей |
Администраторы баз данных |
|
Инфраструктура |
Инструментальные средства Программное обеспечение Сеть |
Архитекторы инфраструктуры |
|
Архитектура приложений |
Проектирование приложений Взаимодействие приложений |
Архитекторы приложений |
Корпоративный архитектор — это специалист, который разрабатывает инфраструктуру корпоративной системы, занимается ее проектированием и следит за ходом ее реализации. Именно архитектор должен воспрепятствовать проведению инвестиций в технологию, которую в недалеком будущем предполагается заменить. Архитектор должен найти в организации общие бизнес-процессы, допускающие повторное использование сервисов, созданных ИТ-службой. Корпоративный архитектор должен мыслить обобщенно, охватывая своим взором приложения, форматы данных и аппаратные платформы, продумывая порядок взаимодействия этих трех составных частей друг с другом. Корпоративный архитектор должен быть универсалом с глубокими знаниями прикладного программного обеспечения, данных и оборудования, хорошо разбираться в бизнесе и уметь выделять повторяющиеся процессы или составные их части.
Кроме корпоративного архитектора в крупных организациях должны быть системный архитектор или архитектор программного обеспечения. Конечным результатом работы архитектора является проект системы. Именно архитектор указывает, в какие технологии компании следует проводить инвестиции. Хороший архитектор должен быть лидером. Почти всегда у него в подчинении команда, в состав которой входят специалисты по различным технологиям и бизнес-процессам.
Основные обязанности АБД являются стандартом для большинства систем, в то время как дополнительные могут варьироваться в зависимости от конкретной организации и опыта. В действительности, для многих компаний АБД является основным источником опыта и знаний по СУБД. Для выполнения своих задач, АБД должен иметь специальные привилегии при работе с аппаратно - программным комплексом. Эти привилегии позволяют выполнять те команды, которые недоступны обычным пользователям.
Задачи АБД имеет смысл разбить на группы в соответствии с частотой выполнения (ежедневные, еженедельные и ежемесячные задачи).
Разработчики БД модернизируют ПС, участвуют в разборе сбоев, связанных с эксплуатацией ПС; систематизируют применяемые ПС и области их применения, дают рекомендации по эффективному использованию ПС. Администрация организации выдает АБД следующую информацию:
ИТ - подразделение информирует администрацию организации о состоянии проектирования, внедрения и эксплуатации БД, а также о производстве продукции за счет использования БД и о любых возникающих ограничениях. При этом предаваемая информация должна отражать следующие аспекты: планы ввода новых технологий и реализации новых ПС, оценку сроков разработки и потребности в ресурсах трудовых, технических (машинное время, память на дисках и др.), состояние средств защиты и контроля доступа к данным, необходимые ПС для обеспечения пользователей, руководства организации, состояние готовности БД, ПС и эксплутационные характеристики системы.
ИТ – подразделение должны иметь связи с другими учреждениями по вопросам создания, региональных и тематических БД, учреждениями других ведомств по вопросам координации работ в рамках общественных советов. Все вопросы эксплуатации БД, обязанности руководителей и исполнителей должны быть отражены в Положении о подразделении и соответствующих должностных инструкциях.
выберите правильный формат физического хранения данных (применяйте для своего архива такие форматы данных, которые можно прочесть через 20 и более лет);
используйте диски для однократной записи, применяемые форматы данных не будут иметь никакого значения, если физические носители, на которых они записаны, станут нечитаемыми или если технические компании перестанут поддерживать устройства, способные их читать, поэтому применяйте наиболее распространенные дисководы - CD и DVD;
применяйте диски CD-R или DVD+R и воздержитесь от RW-носителей, R-диски стабильнее, чем RW;
создавайте несколько копий, при этом повышаются шансы на то, что хотя бы одна из них уцелеет, если возможно, сохраняйте в двух-трех разных форматах;
храните носители (оптические диски) в прохладном сухом месте подальше от прямых солнечных лучей;
проверяйте носители раз в несколько лет, удостоверьтесь в том, что все содержащиеся на них файлы по-прежнему считываются.
Для структурированных данных используйте формат ASCII; для изображений - файлы с расширением .bmp, .tif и .jpg; текстов.txt,.doc, .html. Если изображение еще не переведено в формат .jpg, то лучше хранить его в несжатом tif-файле, так как это позволит сберечь больше деталей. Для реактора типа Word, используйте шрифт Times New Ruman. Для структурированных файлов очень важен и формат логического хранения данных. Во многих отраслях имеются стандарты на форматы хранения (для библиографии, финансовых документов, научных данных - NetCdf, описания персоны, проектов, др.). В связи с широким применением языка XML появились стандарты для новостной информации – RSS, описания интернет-ресурсов – Dublin Core, др.
Американские инвестиционные банки оценивают потери от одной минуты простоя своей информационной системы в 80 млн. долл. Различного рода катастрофы также влекут существенные потери, которые сопоставимы с простоем системы, на:
затраты на восстановление информации;
затраты на восстановление работоспособности системы;
ущерб, нанесенный имиджу компании;
убытки от невосполнимых потерь информации.
Восстановление работоспособности после аварии. Надо определить, какие системы являются критически важными для организации, и какие события могут привести к существенным изменениям в его функционировании. Системы надо восстанавливать в определенном порядке, предусматривая их связи с Интернет и локальными сетями. Составьте детальный каталог всех серверов и услуг и предусмотрите необходимое время восстановления для каждого из них. Некоторые должны быть запущены через несколько минут, а некоторые можно включить через несколько часов, а то и дней. Решения могут быть самыми разными, начиная от покупки противопожарного сейфа, чтобы хранить сменные носители со скопированными файлами, и заканчивая создание распределенной БД с серверами, на которые в онлайновом режиме будет копироваться вся необходимая информация.
Типичные стратегические и тактические ошибки, которые возникают при организации резервирования информационных систем, это выбор места расположения центра для хранения резервных информационных систем; техническая оснащенность; организация доступа к резервным системам; организация резервного офиса и доступ к нему. Рекомендации для организации системы резервирования:
разработать комплексный план, учитывающий все аспекты резервного копирования и восстановления; определить основных участников и их роли; составить документацию, описывающую процессы и процедуры, назначить ответственных и постоянно контролировать их работу;
рассмотреть возможные последствия чрезвычайных ситуаций;
определить, какие данные требуют частого создания резервных копий;
определить целевую точку и время восстановления для каждого класса данных;
определить, какие данные требуют репликации (удаленной или локальной) для обеспечения непрерывности бизнеса при чрезвычайных ситуациях или быстрого восстановления;
планируя архитектуру, определить расстояние до альтернативных узлов и учесть факторы, влияющие на восстановление (извлечение данных с использованием сети или транспортировка лент с резервными копиями);
определить основных участников процесса восстановления;
при создании архивов на ленте, во вторичном хранилище или ассоциативных хранилищах данных необходимо позаботиться о их защите;
решить вопросы архитектуры и обслуживания техники, которая должна обеспечить долговременную работу и возможность расширения;
выяснить соотношение затрат на быстрое восстановление данных с диска с потерями рабочего времени и дохода за время ожидания восстановления информации с ленты.
Резервное копирование и восстановление данных должно включать:
соглашение об уровне обслуживания в части бесперебойного доступа к информации;
периодичность резервного копирования, графики и автономный/оперативный доступ ко всем типам информации, классифицированным по значимости;
определение целевой точки и целевого времени восстановления в совокупности с планом сохранения непрерывности бизнеса и восстановления в аварийной ситуации;
графики сохранения данных на удаленной площадке;
репликация данных на диске, определение необходимого количества копий;
поддержка данных о создании, тестировании и развертывании информации для резервного копирования, восстановления и порядок возобновления исходного состояния в чрезвычайных ситуациях;
инструкции относительно контрольных точек, графиков и интерпретации всех видов информации — критически важной, разовой, электронных сообщений, пользовательских данных, личных каталогов и т. д.
инструкции, определяющие, какая информация сохраняется и зачем;
безопасность копий данных (физическая и логическая);
правила для процедур сохранения и архивирования данных — как долго и на каких носителях хранится информация, каково время доступа и какие данные переносятся из первичной памяти во вторичную и почему;
как защищается первичная, вторичная память, на каких носителях и с какой периодичностью;
кто распоряжается процессами и устанавливает правила резервного копирования и восстановления (в число распоряжающихся должны входить не только системный администратор, но и владельцы приложений или информации);
контрольные записи, подтверждающие надлежащее выполнение правил и процедур, следование стратегии.
Необходимо составить расписание для резервного копирования системы. Для выполнения автоматического резервного копирования без привлечения обслуживающего персонала требуется возможность его проведения в режиме online. Если система должна находиться в рабочем режиме 24 часа в сутки, или если время, необходимое для выполнения резервного копирования превышает размер доступного окна, то планирование операций резервного копирования и конфигурирование соответствующих средств значительно усложняются.
Резервное копирование небольших БД может легко осуществляться при наличии всего одного накопителя на магнитной ленте Exabyte или DAT. Резервное копирование осуществляется с периодичностью один раз в сутки. Систему хранения останавливают буквально на минуту для создания моментальной копии, а затем в конце рабочего дня создается полная резервная копия. Для увеличения пропускной способности несколько устройств могут работать параллельно.
Использование зеркалирования дисков для облегчения резервного копирования. Простым, но эффективным способом сокращения времени резервного копирования является выполнение копирования на отдельный диск. Организация зеркалирования данных может осуществляться по ряду причин, в том числе для защиты от повреждения диска, сохранения непрерывности бизнеса при запланированных простоях, восстановления после катастроф из удаленного резервного центра и улучшения локального доступа к данным. Известны два типа зеркалирования: синхронное и асинхронное.
При синхронном зеркалировании данные сохраняются одновременно. Обе копии обновляются до того, как операционной системе приложения посылается подтверждение о завершении операции записи. Это дорогой способ, и он может снизить общую производительность сети хранения.
При асинхронном зеркалировании вторая копия данных может кэшироваться, не гарантируется их полная идентичность на зеркалах в случае возникновения проблемы. Однако стоимость этого способа невысока.
Основной фактор выбора между синхронным и асинхронным зеркалированием — производительность. Для приложений пакетной обработки задержка в несколько секунд допустима или даже незаметна. Для систем, передающих транзакции, или интерактивных приложений с интенсивным обменом информации даже секундная задержка может оказаться неприемлемой. Безусловно для создания копий больших БД необходимо использовать промышленные системы хранения данных, сравнение систем хранения данных представлена в табл.3.
Таблица 3 - Сравнительные характеристики систем хранения данных [CNews Analyticsъ
|
Характеристика |
NAS (Network Attached Storage) – сетевая система хранения данных |
SAS / DAS (Server Attached Storage/Direct Attach Storage), система хранения, подключенная к серверу |
SAN (Storage Area Network), cеть хранения данных |
TSM (Tivoli Storage Manager) |
|
Протоколы передачи данных |
CIFS, HTTP, NFS, FTP |
SCSI, SSA |
SCSI |
|
|
Скорость передачи |
не менее 100 МБ/с на один порт |
несколько сот МБ/с |
до 1 Гб/с на один порт |
|
|
Сетевые протоколы |
TCP/IP через Ethernet, FDDI, ATM, Gigabit Ethernet |
SCSI-интерфейс сервера, сетевой протокол неприемлем |
Fibre Channel, Gigabit Ethernet |
|
|
Масштабирование |
Качественное, но снижает пропускную способность сети |
Ограничено количеством подключаемых устройств и производительностью единственного сервера |
Самое эффективное |
|
|
Миграция данных |
Используются способы резервирования/ восстановления |
Снижает производительность сервера |
Обеспечивается построение систем хранения высокой готовности с возможностью дублирования в реальном времени |
функция дедубликации, восстановление отдельных почтовых ящиков Microsoft Exchange и элементов каталога Active Directory |
В чем нуждается администратор БД?
Потребности администратора зависят от его обязанностей и квалификации. Инструментальные средства могут освободить его от лишних манипуляций, чреватых ошибками и отнимающих много времени. Основными инструментальными средствами АБД являются:
1) средства профилактического мониторинга, которые избавляют администратора от экстренных мер, разгружают администратора по вечерам и выходным, ускоряют приобретение опыта;
2) средства диагностики, позволяющие сконцентрироваться на других задачах;
3) средства анализа, помогающие при планировании роста БД и будущих затрат;
4) средства технического обслуживания, которые помогают при резервном копировании и восстановлении данных, сокращая время операции и уменьшая число ошибок, помогают при реорганизациях, экономя время, уменьшая количество ошибок и длительность профилактических окон, способствуют высокой доступности данных, создавая " незаметные " с точки зрения системы профилактические окна и помогая при резервировании / восстановлении системы.
Скорость и надежность работы приложений зависят от производительности всех компонентов: сервера баз данных, сервера приложений, Web - cервера, клиентской части, аппаратной платформы хранения данных. Управление производительностью приложений будет эффективным в том случае, если обеспечивается мониторинг, идентификация и анализ узких мест на всех уровнях и увязываются симптомы с причинами даже в тех случаях, когда они будут относиться к разным этапам реализации приложения. При этом необходимы инструменты не только для оперативного сбора статистики, но и для анализа тенденций в производительности, который позволит предотвращать повторение проблемных ситуаций.
Для повышения эффективности эксплуатации БД необходимо проводить упреждающий мониторинг производительности, который использует базовые параметры работы системы и непрерывное наблюдение. Упреждающий мониторинг производительности - это несложная система, которая позволяет решить проблемы до того, как они станут критическими.
Базовые параметры - это набор параметров, отображающих поведение сервера и приложения в обычных условиях. Базовые параметры получаются как средние по результатам нескольких замеров, выполненных в одинаковых условиях; они являются ориентирами для сравнения, табл.4.
Эталон показывает производительность системы при определенном уровне загрузки сервера, что позволяет сравнить производительность промышленного сервера при таком уровне и определить показатели сервера, насколько они выше или ниже нормы (т.е. когда сервер работает плохо).
Таблица 4 - Метрики для определения базовых параметров
|
Объект и счетчик |
Описание |
|
Память (страниц/с) |
Число страниц чтения или записи на диск в секунду. Этот счетчик - первичный индикатор типов ошибок, вызванных системными задержками или проблемами с производительностью |
|
Трафик (бит/с) |
Число бит, проходящих по сетевому интерфейсу в секунду |
|
Скорость обмена между RAM и дисками (бит/с) |
Оценка дисковых операций чтения/записи. |
|
Загрузка процессора |
Процентное соотношение времени, которое процессор тратит выполнение рабочего потока. |
|
Рост файла транзакций |
На сколько, для конкретной базы данных, вырос файл транзакций. |
|
Процент записи файлов журналов |
Процентное отношение свободного места в журнальном файле. |
|
Макс число транзакций в очереди |
Наблюдайте за тем, когда транзакции начинают выстраиваться в очередь, это указывает на то, что дисковый ввод/вывод может быть медленным |
|
Число пользовательских подключений к серверу БД |
Они могут указывать на сетевые проблемы и свидетельствовать о нагрузках и замедлении |
Мониторинг - это плановое наблюдение в режиме реального времени за сервером на предопределенных условиях (совокупностях условий, определенных для дальнейшего исследования или предупреждений). Например, если потребуется узнать, сколько времени занимает удачное выполнение важного бизнес-приложения, сколько времени занимает резервное копирование или когда определенные значения производительности будут достигнуты, то за этими конкретными событиями ведется наблюдение.
Ранжировать инциденты нужно в зависимости от степени воздействия и критичности. Степень воздействия определяется убытками, возникшими из-за возникшего инцидента. Критичность является характеристикой качества исполнения бизнес-процессов. Например, в [2] предлагается 4 уровня критичности инцидентов, табл.5: максимально критично, критично, условно критично и не критично. Под устранением инцидента понимается предоставление "временного решения", которое позволит восстановить нормальное функционирование бизнеса.
Таблица 5 - Уровни критичности инцидентов (Источник: CBOSS, 2009)
|
Уровень |
Описание |
|
Максимально критично |
Произошла остановка работы одного или нескольких основных бизнес-процессов компании. На момент обращения проблема влечет прямые финансовые потери для клиента. Решение требуется незамедлительно. |
|
Критично |
Проблемы, наличие которых представляет угрозу остановки работы основных бизнес-процессов компании, потенциально может повлечь финансовые потери либо нанести урон имиджу клиента. |
|
Условно критично |
Проблемы, решение которых необходимо компании в определенные сроки или к обозначенной дате (требуется подготовка отчетной документации) |
|
Не критично |
Проблемы, которые не приводят к остановке работы основных технологических процессов, их решение может быть отложено на срок более одного месяца. |
Рекомендации по защите БД
Рекомендации, которые помогут АБД защитить БД.
Постоянно оценивайте свои действия с точки зрения их безопасности как при разработке приложений, так и при выполнении повседневных задач по управлению пользователями и данными. Обучайте пользователей думать так же.
Принцип минимальных привилегий предполагает, что пользователи и приложения наделяются минимальным набором прав и привилегий, необходимым для нормального функционирования. В результате не только ограничивается доступ пользователей к базе данных, но и возникает необходимость в регулярном пересмотре прав доступа и их уточнении.
Минимизируйте пространство атаки - чем сложнее БД, тем больше периметр для атаки. Постарайтесь ограничить этот периметр, устраняя те компоненты, которые не используются.
Управляйте паролями. Одна из главных и наиболее простых целей для хакерских атак — учетные записи пользователей с установленными по умолчанию или слабыми паролями. Список паролей, назначаемых по умолчанию, можно найти в Интернете, и есть много инструментов, которые помогают хакерам взламывать эти пароли.
Помните, что шифрование — это не панацея. Шифрование — это, как правило, первое, что приходит в голову, когда задумываешься о безопасности данных, и его, несомненно, имеет смысл рекомендовать для защиты важной информации. Однако такой способ защиты стоит недешево, да и сам по себе он не прост в использовании и управлении. Шифруйте только критически важные данные, для защиты которых это просто необходимо. Внимательно подходите к управлению ключами шифрования/дешифрования и меняйте их регулярно. Очень важно сочетать шифрование с другими средствами и процедурами, такими как мониторинг активности, аудит, периодическая оценка уязвимости и аутентификация пользователей.
Подход к обеспечению безопасности должен быть комплексным. Многие компании выделяют средства и ресурсы на обеспечение безопасности баз данных, но пренебрегают этим при разработке и тестировании среды для этих баз, а также при создании предварительных демонстрационных версий. Поскольку демонстрационный код впоследствии часто переносится в окончательную версию программы, он должен быть так же безопасен, как и основной код. Кроме того, часто реальные данные используются во вспомогательных средах без всякой маскировки. Настоятельно рекомендуется относиться к вспомогательным инструментам так же тщательно, как и к основным.
Используйте выпускаемые фирмами разработчиками заплатки для используемых инструментов. Распространение программных заплаток обычно занимает несколько месяцев. И еще несколько месяцев заказчики устанавливают их в свои программы, поскольку необходимо время на тестирование обновлений. Многие заказчики пренебрегают заплатками, и тогда их БД остаются уязвимыми для самых разных атак. Устанавливать заплатки следует сразу по их получении.
Применяйте заповеди начинающего АБД [1].
Выводы
Управление данными есть процесс, который начинается с измерительной программы экспедиции (проекта) или создания БД и заканчивается доступом научной общественности к качественно проконтролированным массивам данных. То есть план управления данными должен быть ключевым элементом всех крупных проектов и программ.
План управления данными есть специальная активность, выполняемая в рамках национальной и международной политики, основанной на лучшей практике, например разработанных в рамках международного обмена данными. План управления данными должен описывать работу, технологические требования и соответствующие результаты в проектировании измерительной активности, отчетности по сбору данных, документировании, контроле качества и создании БД, электронной публикации данных.
Адекватное управление данными определяется возможностями национальных организаций политическими аспектами, техническими проблемами, условиями финансирования проектов, хорошей координацией всех участников проекта, наличием соответствующего квалифицированного штата, социальными льготами (для проведения экспедиционных работ).
Должность администратора БД является одной из самых недооцениваемых на предприятии. АБД в ответе практически за все, что только может пойти не так. Довольно неблагодарно считать устойчивое функционирование системы само собой разумеющимся фактом, а противоположную ситуацию - исключительно виной администратора БД. АБД нуждается в разнообразии средств, способных сделать его работу более продуктивной и избавить от авралов по вечерам и выходным. Кроме того, инструментальные средства позволяют АБД сосредоточиться на выполнении своих непосредственных обязанностей вместо того, чтобы заниматься "пожаротушением", решением неотложных проблем и выполнением рутинных, но от этого не менее подверженных ошибкам, процедур, таких как резервное копирование и реорганизации.
Список литературы
Перечень вопросов для самопроверки
1.Что такое план управления данными?
2.Что должен включать план управления данными?