63434

УПРАВЛЕНИЕ ДАННЫМИ

Лекция

Информатика, кибернетика и программирование

Управление данными необходимый процесс Основная концепция управления данными Управление данными в экспедициях и экспериментах пунктах измерений Управление данными в центрах обработки данных Управление данными в отдельных проектах Управление данными...

Русский

2014-06-20

328.5 KB

1 чел.

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 серверы и разнообразные подходы к виртуализации, консолидации, интеграции данных. А необходим общий взгляд на архитектуру хранения, доступа через различные устройства, анализ достоинств и ограничений решений разных производителей, понимание общих проблем построения неоднородных сетевых инфраструктур хранения.

Основным объектом управления данными становятся распределенные информационные ресурсы. Функциями управления распределенными ресурсами являются:

  •  управление серверами и системами хранения (определение концепции хранения данных, виртуализация доступа к данным, создание сети распределенного хранения данных, по управлению сетями);
  •  управление защитой данных (системы резервирования и восстановления Backup);
  •  обеспечение высокой готовности данных и приложений, вне зависимости от марок оборудования и уровня распределенности информационной среды организации;
  •  аварийное восстановление (защита данных и программ по обеспечению высокой доступности, планирование и реализация восстановления систем в случае серьезных повреждений);
  •  управление производительностью приложений (анализ и контроль выполнения приложений на всех уровнях — от прикладных запросов до обращений к физическому хранению данных).

Состав и структура Плана управления данными

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

  •  идентификация пользователей, участвующих организаций в исследовании региона и требований пользователей к информационному обеспечению;
  •  постановка и описание проблем исследования;
  •  создание баз метаданных;
  •  описание имеющихся программных средств анализа и прогноза, развитие новых приложений;
  •  описание методов использования программных средств (СУБД, ГИС, технологий сбора данных);
  •  разработка первой версии Плана управления данными;
  •  определение финансовых источников для разработки Плана управления данными и его реализации.

План управления данными должен включать:

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

Целями управления данными являются:

  •  максимизация полноты сбора данных с широким использованием ИТ стандартов;
  •  эффективное использование данных в течение выполняемых проектов (программ) и последующее длительное применение данных сообществом путем использования современных средств Интернет, компактных дисков.

Критериями реализации ПУД может быть 100% полнота сбора данных и  доступность данных - в течение 30 мин. после измерения.

Источниками информации для подготовки разделов «Обзор» и «Описание БД» являются:

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

Основным методом при выполнении этих разделов является поиск информации, по результатам которого дается:

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

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

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

Методы обработки данных. В этом разделе рассматриваются методы вычисления статистических характеристик, создания расчетных БД и временных серий наблюдений, развитие приложений по обработке данных, ГИС применений.

Программное обеспечение для обработки данных. План управления данными включает программное обеспечение для сбора текущих, исторических, расчетных и модельных данные, получения информационной продукции. При разработке программного обеспечения используются следующие общие решения: стандарты на методы наблюдений, форматы исходных, модельных данных, метаданных, интерфейс, термины и определения, языки описания данных и манипуляции. Рекомендуется использовать современные инструментальные средства для СУБД, ГИС, СППР и др. на всех стадиях обработки данных (сбора, накопления, хранения, вычисления, анализа, интерпретации и распространения данных).

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

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

Основные шаги реализации Плана управления данными включают:

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

разработка интегрированной БД.

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

7.Администрирование БД

Типы администраторов и их обязанности могут отличаться в зависимости от конфигурации СУБД и от конкретной организации. В крупных системах, например, обязанности администратора БД могут распределяться среди нескольких специалистов. В то же время в небольших системах один человек может выполнять функции нескольких типов АДМ одновременно. У каждой компании свои потребности, основанные на характере используемых приложений.

Маленькие центры, имеющие только сайт в Интернете, небольшие производственные фирмы, или даже крупные отделы, только-только переходящие на использование мощной СУБД, вполне могут обойтись одним АБД, выполняющим весь спектр задач.  При этом АБД занимается поддержкой небольшой локальной сети, обновлением контента Интернет -сайта, сопровождением правовых и бухгалтерских программ. Задачи, актуальные для небольших фирм, не требуют громоздких программных комплексов по обработке информационного потока компании, а разработку дополнительных приложений выгоднее отдавать специализированным ИТ–компаниям.

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

В крупных центрах существует четкое разделение АБД по классам, в каждом из которых присутствует по несколько АБД различного опыта, благодаря чему текучесть кадров минимально сказывается на эксплуатации БД [3].

Рисунок 2 - Типовая схема ИТ-компании (Источник: CNews Analytics)

Важным моментом работы АБД является структура ИТ-компании. Типовая схема компании дана на рис. 2.

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

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

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

Сектор управления проектами курирует проекты и распределяет задания, которые формулирует руководство компании.

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

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

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

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

Можно выделить основные типы администрирования, характерные для всех систем:

  •  администрирование БД;
  •  администрирование защиты данных;
  •  администрирование компьютеров;
  •  администрирование сетей;
  •  администрирование Интернет (Web-мастера);
  •  администрирование телефонной связи;
  •  администрирование почтовых систем;
  •  администрирование мэйнфреймов;
  •  администрирование приложений.

Кроме того, в зависимости от опыта администраторы БД могут иметь следующие должности и выполнять разные обязанности:

  1.  Оперативные АБД:
  •  манипулирует дисковым пространством;
  •  наблюдают за текущей производительностью системы;
  •  реагируют на возникающие неисправности БД;
  •  обновляют системное ПО и СУБД;
  •  контролируют структурные изменения БД;
  •  запускают процедуры резервного копирования данных;
  •  выполняют восстановление данных;
  •  создают и управляют тестовыми конфигурациями БД;
  •  отвечают за целостность информационных ресурсов компании;
  •  отвечают за создание, обновление и сохранность резервных копий файлов.
  1.  Тактические АБД:
  •  реализуют схемы размещения информации;
  •  утверждают процедуры резервного копирования и восстановления данных;
  •  разрабатывают и внедряют структурные элементы БД (таблицы, столбцы, размеры объектов, индексацию и т.п.; скрипты изменения схемы БД);
  •  определяет конфигурационные параметры БД;
  •  утверждают план действий в случае аварийной ситуации;
  •  знают в мельчайших подробностях существующие механизмы восстановления программного обеспечения СУБД;
  •  локализуют неисправности, решают предполагаемые проблемы, которые могут возникнуть в будущем;
  •  анализируют данных по статистике доступа, сбоев и др.;
  •  предоставление помощи разработчикам по SQL и хранимым процедурам;
  •  документируют среду СУБД, включая конфигурацию оборудования, обновления и изменения программного обеспечения и СУБД, а также все вопросы, связанные с изменением системы и ее параметров.  
  1.  Стратегические АБД:
  •  выбирают поставщика СУБД;
  •  устанавливают корпоративные стандарты данных;
  •  внедряют методы обмена данных в рамках предприятия;
  •  определяют корпоративную стратегию резервирования и восстановления данных;
  •  обеспечивают соответствующий уровень информационной безопасности, следя за тем, чтобы доступ к данным имели только те люди, которые в нем нуждаются;
  •  устанавливают корпоративный подход к ликвидации последствий аварии и обеспечению доступности данных;
  •  создают элементы физической схемы;
  •  поддерживают связь пользователей с системой;
  •  устанавливают новое программное обеспечение, тестируют все программы перед введением их в рабочую среду;
  •  конфигурируют программное и аппаратное обеспечение (вместе с системным администратором), вместе с системным администратором производят установку программ, конфигурирование программного и аппаратного обеспечения, чтобы рабочие станции функционировали наиболее оптимально;
  •  проверяют и тестируют новые программы;
  •  оценивают приобретений нового программного и аппаратного обеспечения;
  •  планируют нагрузки системы и необходимого объема памяти;
  •  разрабатывает производственные стандарты и соглашения по именам;
  •  моделируют и оптимизируют данных.
  1.  Старшие АБД:
  •  досконально знают свой персонал;
  •  пользуются высоким спросом;
  •  могут написать любой скрипт;
  •  тратят много времени на подготовку младших АБД.
  1.  Младшие АБД:
  •  мечтают стать старшим АБД;
  •  не слишком сильны в написании скриптов;
  •  имеют большую склонность к использованию средств управления БД;
  •  настраивают SQL и программное обеспечение СУБД.
  1.  Прикладные АБД:
  •  в курсе информационных нужд компании;
  •  помогают в разработке прикладных задач;
  •  отвечают за разработку схемы и ее изменения;
  •  вместе с системным АБД обеспечивают должный уровень резервирования, восстановления данных;
  •  занимаются построением тестовых БД;
  •  создают БД, табличные пространства, таблицы, представления и индексы согласно спецификации разработчика приложений;
  •  периодическая проверяют производительность системы и производят изменения для поддержки необходимого уровня производительности;
  •  поддерживают целостность данных БД.
  1.  Системные администраторы:
  •  отвечают за поддержку многопользовательской компьютерной системы, включая локальные вычислительные сети, глобальные вычислительные сети, телефонные системы или системы голосовой почты;
  •  отвечают за все необходимое для резервирования и восстановления данных;
  •  контролируют производительность системы в целом;
  •  осуществляют поиск и устранение неисправностей;
  •  в курсе нынешних и будущих потребностей БД в плане емкости дисков;
  •  в курсе текущего состояния и нужд БД;
  •  умеют определять узкие места системы, ограничивающие ее производительность,
  •  обладают знаниями, необходимыми для решения вопросов оптимизации быстродействия БД;
  •  добавляют и конфигурируют новые рабочие станции;
  •  создают пользовательские учетные записи;
  •  устанавливают общесистемное программное обеспечение;
  •  выполняют процедуры для предотвращения распространения вирусов;
  •  выделяют дисковое пространство;
  •  консультируют разработчиков и конечных пользователей, отвечают на вопросы.
  1.  Наемные  АБД:
  •  приглашаются под конкретную задачу или в качестве консультантов;
  •  передают персоналу необходимые знания;
  •  фиксируют свои действия;
  •  прекрасно разбираются в предметной области;
  •  хороши в качестве временного персонала, для оценки проекта или системы.
  1.  Администраторы-руководители:
  •  проводят еженедельные совещания;
  •  определяют перечень первоочередных задач;
  •  устанавливают и оглашают официальный курс и стратегию;
  •  утверждают и корректируют должностные инструкции и список обязанностей;
  •  следят за наличием соответствующей документации.

В больших организациях, кроме АДБ, имеются  аналитики, архитекторы, распределение их ответственности дано в табл.2.

Таблица 2 - Распределения ответственности при внедрении решения для создания БД

Объект

Требования к данным

Ответственность

Модель бизнес-процессов

Определение бизнес-процессов, функций

Аналитики

Архитектура данных

Определение объектов, атрибутов, связей

Архитекторы и аналитики данных

Архитектура баз данных

Проектирование баз данных

Определения таблиц

Определения столбцов, ключей

Администраторы баз данных

Инфраструктура

Инструментальные средства

Программное обеспечение

Сеть

Архитекторы инфраструктуры

Архитектура приложений

Проектирование приложений

Взаимодействие приложений

Архитекторы приложений

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

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

Основные обязанности АБД являются стандартом для большинства систем, в то время как дополнительные могут варьироваться в зависимости от конкретной организации и опыта. В действительности, для многих компаний АБД является основным источником опыта и знаний по СУБД. Для выполнения своих задач, АБД должен иметь специальные привилегии при работе с аппаратно - программным комплексом. Эти привилегии позволяют выполнять те команды, которые недоступны обычным пользователям.

Задачи АБД имеет смысл разбить на группы в соответствии с частотой выполнения (ежедневные, еженедельные и ежемесячные задачи).

Ежедневные задачи:

  •  проверка активности СУБД;
  •  просмотр регистрационных файлов СУБД и протокола ее работы;
  •  выявление нежелательных тенденций роста объектов в БД.

Еженедельные задачи:

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

Ежемесячные задачи:

  •  рассмотрение возможностей настройки БД (размеры буфера данных, буфера журнала БД и shared pool, др.);
    •  поиск и устранение проблем ввода/вывода;
    •  определение неблагоприятных тенденций производительности СУБД и подготовка предложений по решениям.

Разработчики БД модернизируют ПС, участвуют в разборе сбоев, связанных с эксплуатацией ПС; систематизируют применяемые ПС и области их применения, дают рекомендации по эффективному использованию ПС. Администрация организации выдает АБД следующую информацию:

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

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

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

Повышение надежности работы БД

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

Чтобы не потерять данные АБД должен выполнять следующие рекомендации [5, 6]:

выберите правильный формат физического хранения данных (применяйте для своего архива такие форматы данных, которые можно прочесть через 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.  Правильно устанавливайте журнальные файлы. Журнальный файл должен быть в оперативном состоянии и доступен все время, пока база данных функционирует, в противном случае база данных обрушится. Настоятельно рекомендуется использовать несколько журнальных файлов. Определите размер журнальных файлов так, чтобы они переключались каждые 30-60 минут.
  2.  Создайте специальное табличное пространство для временных сегментов.
  3.  Обеспечьте наличие четырех управляющих файлов на различных дисках.
  4.  Установите размер буфера памяти для БД примерно в 25% от общего объема памяти, но установка должна учитывать и число пользователей.
  5.  Установите значение параметра совместно используемого объема примерно от 50% до 75% от принятого значения буфера памяти для БД. Распределите основные файлы данных (табличное пространство системы, табличное пространство для временных сегментов, табличное пространство для сегментов отката, журнальные файлы (файлы логов), диск операционной системы, файлы БД, содержащие интенсивно используемые таблицы, файлы БД, содержащие интенсивно используемые индексы) между несколькими дисками. Следует помнить, что операции ввода/вывода с индексами и записями журналов весьма различны. Это важно, когда журнальные файлы и индексы размещаются на одном и том же диске. Журнальные файлы записываются последовательно относительно большими порциями. Индексы читаются и пишутся произвольным образом. Помещение индексных файлов на то же самое устройство, что и журналов, может снизить скорость операций записей в журнал.
  6.  Храните файлы данных (таблицы) на иных дисках и контроллерах, чем те, где размещены соответствующие им файлы индексных данных. Используйте соглашения об именах и установках.
  7.  Используйте соглашения об именах для улучшения управления базой данных, а также для того, чтобы файлы базы не были "случайно" уничтожены.
  8.  Регулярно проверяйте размер табличных пространств и наличие свободного пространства.
  9.  Просматривайте сведения о таблицах и индексах на предмет потенциальных проблем с памятью и/или проведением их изменений, вызванных с фрагментацией и наличием сцеплений блоков.
  10.  Исключите фрагментацию таблиц, когда таблицы состоят из нескольких экстентов (участков); фрагментация строк имеет место, когда записи в таблицах обновляются, и блоки, в которых они содержались, не имеют достаточно места, чтобы сохранить измененные записи. Эта проблема известна, как "сцепление блоков"; фрагментация словаря БД имеет место, когда расширяются таблицы словаря данных.
  11.  Чаще исследуйте БД на предмет выявления фрагментации. Если фрагментация больше, чем пять экстентов для одной таблицы, обязательно найдите время, когда эту таблицу можно дефрагментировать. Исправляйте размеры экстентов до того, как фрагментация превратится в большую проблему.
  12.  Используйте утилиту EXPLAIN вместо трассировки, чтобы не ждать пока выполнится запрос. Используйте трассировку (ТРАСЕ) только для многозапросных пакетных работ, чтобы определить, какой из запросов является медленным.
  13.  Перемещайте файлы данных для балансировки файловых операций ввода/вывода.
  14.  Применяйте опцию параллельного выполнения в подходящих ситуациях, но проверяйте, насколько это выгодно. Планируйте простой системы, связанный с проведением системных действий, на нерабочее время организации. Файлы, которые должны быть резервированы на диск или ленту.
  15.  Разработайте планы резервирования и восстановления, которые включают, как создание резервного образа базы данных, экспорт, так и архивирование файлов.

Выводы

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

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

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

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

Список литературы

  1.  XX заповедей начинающего Администратора БД20 Tips for the Beginner DBA, by Richard . Niemiec, (Ричард Дж. Нимиц ) "SELECT", vol. 2, No 4, July 95 Copyright 1995 Международной группы пользователей Oracle (IOUG-A).
  2.  Белкин К. На ошибках учимся // Издательство "Открытые системы". Журнал "Директор ИС", N7, 2005. http://www.osp.ru/cio/2005/07/051.htm 
  3.  Давыд Кравченко. ИТ-штат компании: размер имеет значение // Cnews. [Электронный ресурс]. – Режим доступа: http://www.cnews.ru/reviews/articles/index.shtml?2006/04/26/200578, свободный. – Загл. с экрана.
  4.  Мартин Дж. Организация БД в вычислительных системах. - М.: Мир. 1980. с. 653
  5.  Храмцовская Н. Как хранить электронные документы? Советы эксперта. 10.04.08.  [Электронный ресурс]. – Режим доступа: http://www.cnews.ru/reviews/index.shtml?2008/04/10/296523_4, свободный. – Загл. с экрана.
  6.  ГОСТ Р /ISO/TR 15801:2009  Системы электронного документооборота. Управление документацией. Информация, сохраняемая в электронном виде: Рекомендации по обеспечению достоверности и надёжности. - М.- Стандартинформ. 2011. – 64 с.

Перечень вопросов для самопроверки

1.Что такое план управления данными?

2.Что должен включать план управления данными?


 

А также другие работы, которые могут Вас заинтересовать

71710. Определение данных 85 KB
  Для создания таблицы необходимо указать ее имя и определить столбцы. Определение столбца включает его имя и тип. Если указывается длина столбца, то она заключается в круглые скобки после типа. Кроме того, можно указать ограничения для столбца.
71711. МЕТОДЫ ОПРЕДЕЛЕНИЯ СТЕПЕНИ ОТВЕРЖДЕНИЯ ЛАКОКРАСОЧНЫХ ПОКРЫТИЙ 465.5 KB
  Метод основан на способности лакокрасочных покрытий в зависимости от степени отвержения удерживать на своей поверхности стеклянные шарики или бумагу при заданной нагрузке и заключается в определении времени в течение которого жидкий лакокрасочный слой превращается пленку с требуемой степенью высыхания.
71713. Программирование линейных алгоритмов. Работа с отладчиком 1.58 MB
  Линейная программа Если в программе все операторы выполняются последовательно, один за другим, такая программа называется линейной. Рассмотрим в качестве примера программу, вычисляющую результат по заданной формуле.
71714. Предварительная обработка статистических данных 111 KB
  Предварительная обработка статистических данный включает в себя: Сортировку данных по величине представление их в виде вариационного ряда; Вычисление основных числовых характеристик выборки: выборочного среднего выборочной дисперсии исправленной выборочной дисперсии и дополнительных...
71715. Оценка параметров распределения и проверка статистических гипотез о виде распределения 133 KB
  Сравнить эмпирические и теоретические частоты с помощью критерия Пирсона. Для этого составляют расчетную таблицу по которой находят наблюдаемое значение критерия Пирсона, затем по таблице критических точек распределения, по заданному уровню значимости и числу степеней свободы...
71716. ОБРАБОТКА АНКЕТЫ 94.5 KB
  Провести оценку по второму вопросу выбор профессии по 3х градусной односторонней шкале: мечта о психологии 10 баллов; желание где-то учиться 5 баллов; все равно где учиться 1 балл. Провести оценку по третьему вопросу жизненная цель по 4 градусной односторонней шкале...
71717. ОПРЕДЕЛЕНИЕ ГРАНУЛОМЕТРИЧЕСКОГО СОСТАВА ГРУНТА 55.5 KB
  Гранулометрическим составом грунта называется содержание в массе грунта частиц (фракций) различной крупности по отношению к общей массе сухого грунта. Определение гранулометрического состава состоит в разделении частиц, составляющих грунт, на отдельные группы (фракции), приведенные...
71718. ОПРЕДЕЛЕНИЕ ПЛОТНОСТИ ГРУНТА ЕСТЕСТВЕННОЙ (НЕНАРУШЕННОЙ) СТРУКТУРЫ И ЕГО ВЕСОВОЙ ВЛАЖНОСТИ 60.5 KB
  Эта характеристика используется при проектировании фундаментов для определения расчетного давления на основание напряжений от собственного веса грунта давления на ограждающие конструкции при расчете устойчивости откосов и т.