Классификация КИС.
Различают заказные (уникальные)итиражируемые (типовые, адаптируемые) КИС.
Заказные КИС
Под заказными КИСобычно понимают системы, создаваемые для конкретного предприятия, не имеющие аналогов и не подлежащие в дальнейшем тиражированию.
Подобные системы используются либо для автоматизации деятельности предприятий с уникальными характеристиками либо для решения крайне ограниченного круга специальных задач.
Заказные системы, как правило, либо вообще не имеют прототипов, либо использование прототипа требует значительных его изменений, имеющих качественный характер. Разработка заказной КИС сопряжена с повышенным риском в плане получения требуемых результатов.
КАНОНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ ЗАКАХНЫХ КИС
|
|
ДОСТОИНСТВА – полное соответствие полученного продукта требованиям заказчика, простота внедрения и эксплуатации, короткое время отклика на требования модификации компонент системы (в случае выполнения проекта штатными силами предприятия)
НЕДОСТАТКИ – уникальные решения стоят дороже типовых; в рамках "лоскутной автоматизации" (так говорят критики заказных решений) достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему. Создавая свои отделы и управления автоматизации, предприятия пытаются "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводят к непрерывным доработкам программных продуктов для удовлетворения все новых и новых потребностей отдельных ключевых сотрудников. | ||||||
Тиражируемые (адаптируемые) КИС
ТИПОВОЕ ПРОЕКТИРОВАНИЕ (ТП). В связи с возрастающей потребностью в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий, системы начали проектироваться "сверху-вниз", т.е. в предположении, что один программный комплекс должен удовлетворять потребности многих пользователей. Из всей совокупности направлений разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и управления производственными и технологическими процессами.
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Референтная модель бизнес-процесса
Разработка тиражируемой КИС для предприятия может вестись на основе референтной модели.Референтнаямодель представляет собой описание системы, функций, структур и процессов, типовых для некоторой отрасли. В ней отражаются типовые особенности, присущие определенному классу предприятий. Ряд компаний–производителей адаптируемых (тиражируемых) КИС совместно с крупными консалтинговыми фирмами в течение ряда лет ведет разработку референтных моделей для предприятий автомобильной, авиационной и других отраслей.
Референтные модели входят в состав многих систем класса MRPII/ERP, что позволяет значительно сократить сроки их внедрения на предприятия.
Референтная модель в начале работы по автоматизации предприятия может представлять собой описание существующей системы (как есть) и служит точкой отсчета, с которой начинаются работы по совершенствованию КИС.
Референтная модель — это модель эффективного бизнес-процесса, созданная для предприятия конкретной отрасли, внедренная на практике и предназначенная для использования при разработке/реорганизации бизнес-процессов на других предприятиях. По сути, референтные модели представляют собой эталонные схемы организации бизнеса, разработанные для конкретных бизнес-процессов на основе реального опыта внедрения в различных компаниях по всему миру. Они включают в себя проверенные на практике процедуры и методы организации управления. Референтные модели позволяют предприятиям начать разработку собственных моделей на базе уже готового набора функций и процессов.
Референтная модель бизнес-процесса представляет собой совокупность логически взаимосвязанных функций. Для каждой функции указывается исполнитель, входные и выходные данные, документы или информационные объекты. Элементы (функции) референтной модели бизнес-процесса содержат ссылки на соответствующие объекты ИС, а также документы и другую информацию (пользовательские инструкции, ответственных разработчиков), расположенную в репозитории (хранилище объектов) проекта. Отсюда и название — референтная модель (в переводе с английского ссылочная модель).
ДОСТОИНСТВА типовых решений– относительная дешевизна готовых решений, их надежность за счет накопленного опыта эксплуатации.
НЕДОСТАТКИ
Сама идея использования универсального продукта накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.
Суть проблемы адаптации тиражируемых КИС, т.е. приспособления к условиям работы на конкретном предприятии в том, что в конечном итоге каждая КИС уникальна, но вместе с тем ей присущи и общие, типовые свойства. Требования к адаптации и сложность их реализации существенно зависят от предметной области, масштабов автоматизируемой системы. ( Даже первые программы, решавшие отдельные задачи автоматизации, создавались с учетом необходимости их настройки по параметрам ).
Часто используется также следующая классификация. КИС делятся на три большие группы:
простые (“коробочные”);
среднего класса;
высшего класса
Простые (“коробочные”)КИС реализуют небольшое число бизнес-процессов организации. Типичным примером систем подобного типа являются бухгалтерские, складские и небольшие торговые системы наиболее широко представленные на российском рынке. Например, системы таких фирм как 1С-Предприятие, Инфин, Супер-Менеджер и т.д.
Отличительной особенностью таких продуктов является относительная легкость в освоении, что в сочетании с низкой ценой, соответствием российскому законодательству и возможностью выбрать систему, наиболее подходящую к собственным потребностям, приносит им широкую популярность.
Системы среднего классаотличаются большей глубиной и широтой охвата функций. Данные системы предлагают российские и зарубежные компании. Как правило, это системы, которые позволяют вести учет деятельности предприятия по многим или нескольким направлениям:
финансы;
логистика (система поставок, система материально-технического снабжения);
персонал;
сбыт.
Они нуждаются в настройке, которую в большинстве случаев осуществляют специалисты фирмы-разработчика, а также требуют подготовку и обучение пользователей.
Эти системы больше всего подходят для средних и некоторых крупных предприятий в силу своей развитой функциональности и более высокой, по сравнению с первым классом, стоимости. Из российских систем данного класса можно выделить, например, продукцию компаний Галактика, Парус, БЭСТ-ПРО, ТБ.Корпорация; зарубежные – PRO/MIS.
К высшему классуотносятся системы, которые отличаются высоким уровнем детализации хозяйственной деятельности предприятия. Современные версии таких систем обеспечивают планирование и управление всеми ресурсами организации (ERP-системы).
Как правило, при внедрении таких систем производится моделирование существующих на предприятии бизнес-процессов и настройка параметров системы под требования бизнеса.
Однако значительная избыточность и большое количество настраиваемых параметров системы обуславливают длительный срок ее внедрения, и также необходимость наличия на предприятии специального подразделения или группы специалистов, которые будут осуществлять перенастройку системы в соответствии с изменениями бизнес-процессов.
На российском рынке имеется большой выбор КИС высшего класса, и их число растет. Признанными мировыми лидерами являются, например, R3 фирмыSAP,SyteLineпроизводителяSYMIX,BaanфирмыBaan,OracleApplicationкомпанииOracle.
2. Резервирование корпоративных данных
Под резервным копированием понимается комплекс мер, направленных на создание копий содержимого файлов баз данных и файлов журнала транзакций (Транзакция — группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными.), которые используются при сбое для возвращения системы в состояние, непосредственно ему предшествующее. Создание резервных копий – один из важнейших элементов в работе администратора баз данных. Администратор должен выбрать оптимальную стратегию создания копий и в дальнейшем пунктуально ее придерживаться.
Современная СУБД может предоставлять несколько различных способов создания резервной копии базы корпоративных данных.
Простейшим из этих способов, который поддерживает любая СУБД, является создание полной резервной копии (full backup, database backup) – точной копии базы данных на текущий момент времени.
ПОЛНАЯ КОПИЯ является стандартным типом резервного копирования. Этот тип резервирования предполагает полное копирование всей информации, имеющейся в БД – все объекты, системные таблицы и данные. В качестве приемника данных может выступать магнитный диск (device) большого объема или устройство резервного копирования - стример (streamer - устройство потоковой записи на магнитную ленту, применяется для резервного копирования и архивирования данных). Создание полной копии является необходимым условием реализации плана резервного копирования, независимо от выбранной стратегии.
Полное копирование имеет свои преимущества и недостатки. Преимущество – для приведения поврежденной системы в рабочее состояние достаточно восстановить лишь один архив (копию). К недостаткам относится длительное время создания архива даже в случае внесения в БД незначительных изменений в интервал времени между созданием очередной резервной копии. Периодичность создания полной копии определяется степенью активности системы.
Совет. СУБД может допускать создание полной резервной копии базы данных во время ее использования, что не требует останавливать (блокировать) систему для этого. Тем не менее, некоторые типы операций не могут быть выполнены во время создания резервной копии. Это операции по изменению структуры базы данных – такие, как создание и удаление файлов или создание индексов, и выполнение нерегистрируемых операций.
Второй тип создания резервной копии, предоставляемый СУБД (не всеми), называется дифференциальным резервированием (differential backup) или разностным копированием. При дифференциальном резервировании записывает только та информация, которая была изменена после последнего полного резервирования. Преимуществом дифференциального резервирования является то, что для выполнения этого процесса требуется намного меньше дискового пространства, и при этом достигается большая скорость выполнения операции резервирования данных.
РАЗНОСТНОЕ КОПИРОВАНИЕ было разработано с целью уменьшения времени, необходимого для получения копии базы данных. В основе разностной копии лежит отслеживание изменений, вносимых пользователями в базу данных. Достаточно применить ее после восстановления полной резервной копии (которая делается один раз в большой промежуток времени), чтобы целиком восстановить систему в актуальном состоянии. В больших базах данных с относительно небольшим количеством изменений разностное копирование является наиболее оптимальным методом резервирования данных.
Совет. Дифференциальное резервирование имеет смысл применять, только если был изменен относительно небольшой процент данных. Например, можно выполнять дифференциальное резервирование каждый день, в то время как полное – один раз в неделю.
Третий тип создания резервной копии, предоставляемый СУБД (теми, которые в принципе поддерживают механизм транзакций), называется резервированием журнала транзакций (transaction log backup). В журнал транзакций записываются все транзакции, выполненные после последнего резервного копирования журнала транзакций.
КОПИЯ ЖУРНАЛА ТРАНЗАКЦИЙ. В двух предыдущих типах резервного копирования фиксируется состояние системы на конкретный момент времени. Однако они не помогут, если потребуется восстановить систему в промежуточном состоянии (например, в состоянии за полчаса до выполнения полного копирования). Резервное копирование журнала транзакций позволяет сохранить информацию обо всех транзакциях (операциях), выполненных в базе данных. Такая копия содержит непрерывную цепочку изменений, которым подверглись данные со времени последнего архивирования любого типа. Таким образом, она отображает всеоперации изменения данных.
Копия журнала транзакций сама по себе не представляет какой-либо ценности, поскольку содержит исключительно сведения о транзакциях. Однако в сочетании с копией БД она позволяет вернуть БД в состояние на любой момент времени, в том числе и в точку, непосредственно предшествующую сбою. Для этого необходимо иметь непрерывную последовательность копий журнала транзакций, которые создавались после последнего копирования БД. Совместное использование двух типов копирования нашло широкое применение в системах оперативной обработки транзакций, где изменения происходят достаточно часто и потеря даже одной транзакции неприемлема.
Совет. Резервирование журнала транзакций дает возможность восстанавливать состояние базы данных на определенный момент времени. Это может быть полезно, например, если ошибка оператора привела к вводу некорректной информации в базу данных. Вы можете использовать резервную копию журнала транзакций для восстановления состояния базы данных, которое она имела до ввода ошибочной информации.
СУБД-сервер использует резервирование журнала транзакций для восстановления базы данных автоматически, если происходит сбой сервера, и его также можно использовать в сочетании с полным резервированием и дифференциальным резервированием для восстановления системы. Преимуществом резервирования журнала транзакций является то, что в большинстве случаев получившийся резервный файл будет меньше, чем аналогичный при полном резервировании и дифференциальном резервировании.
Совет. В некоторых случаях, резервная копия журнала транзакций может быть больше, чем резервная копия всей базы данных. Это возможно, если небольшая группа записей изменялась регулярно. В этом случае лучше сделать полное резервирование или создавать резервную копию журнала транзакций как можно чаще.
Четвертый тип - резервное копирование файлов и групп файлов – в этом случае создаются резервные копии отдельных файлов и групп файлов БД, а не всей базы данных целиком, то есть выполняется частичное архивирование данных (что позволяет сильно сэкономить время). В основе этого подхода лежит возможность привязывания таблицы или даже отдельного столбца к конкретному файлу или группе файлов. Все данные, принадлежащие столбцу, будут размещаться только в указанном файле. Используя данный тип резервирования, можно создать копию отдельной таблицы БД. Это бывает полезно, когда большую часть БД составляет практически неизменяемая справочная информация.
КАК ЧАСТО НАДО ВЫПОЛНЯТЬ РЕЗЕРВИРОВАНИЕ ДАННЫХ
Резервная копия БД – это ее снимок (фиксация) в определенный момент времени, а журнал транзакций содержит все изменения с тех пор, как был сделан этот снимок.
Минимальныетребования к активным системам – БД необходимо резервировать каждую неделю, разностную копию создавать раз в три дня, а журнал транзакций – каждый день.
Максимальные
|
Тип резервирования |
Частота |
|
Полное резервирование |
Ежедневно |
|
Разностная копия |
Каждые 4 часа |
|
Резервирование журнала транзакций |
Каждые 30 минут |
Совет.Разрабатывая стратегию резервирования данных, сначала следует определить, какие данные являются более важными. Как правило, не требуется сохранять временную информацию. Также не необходимости в частом регулярном создании копий данных, доступных только для чтения.
Очевидно, что долго хранить абсолютно все резервные копии не имеет смысла. При соответствующем графике резервирования достаточно сохранять резервные копии не старше месяца. В каждом конкретном случае этот срок может изменяться как в сторону увеличения, так и в сторону сокращения.
Резервное копирование требует определенных затрат и может серьезно сказаться на производительности сервера в целом. По этой причине лучше всего выполнять его в момент наименьшей нагрузки сервера.
Но самое главное в любой схеме резервного копирования – это систематичность и регулярность.
РЕЖИМЫ РЕЗЕРВНОГО КОПИРОВАНИЯ
Резервное копирование может выполняться в следующих режимах:
режим холодного резервирования
режим горячего резервирования
режим зеркалирования
1. Как показывает практика, резервирование базы данныхлучше всего проводить в«холодном» виде, когда перед резервированием БД закрывается и становится неактивной. Такое резервирование лучше всего выполнять в ночное время, когда пользователей можно отключить от базы. Однако во многих случаях этот вариант неприемлем. Во-первых, современные базы данных нередко достигают в объеме сотен и тысяч гигабайт, поэтому их копирование требует слишком много времени, особенно при копировании на магнитные ленты и даже целой ночи для этого может не хватить. Блокировать доступ к базе для выполнения резервирования на длительное время крайне нежелательно. Во-вторых, нередко СУБД работают в режиме on-line (например, на Internet - серверах), и отключение их в принципе невозможно.
2. В режиме горячего резервированияактивная БД копируется на системный диск без остановки системы. Этот наиболее популярный подход к резервированию активных БД заключается в том, что в определенный момент времени начинает создаваться полная копия базы. Все последующие обращения к базе в момент резервирования либо кэшируются (то есть заносятся в специальный буфер-кэш), либо заносятся на диск с помощью переадресации. После завершения резервного копирования (получения полной копии) эти обновления вносятся в БД. Очевидно, чтобы сохранить целостность данных, БД должна устойчиво функционировать в момент резервирования
3. Зеркальное отображение баз данныхработает на стандартном серверном аппаратном обеспечении и позволяет организовать непрерывный поток изменений журнала транзакций от сервера-источника (основной сервер) к серверу-получателю (резервный сервер).
В данном случае система развернута на двух функционально эквивалентных СУБД-серверах, каждый из которых поддерживает очередную резервную копию, то есть вся система дублируется. Средства зеркалирования баз данных позволяют обеспечить действительно высокую отказоустойчивость СУБД за счет создания в режиме реального времени точной копии базы данных на резервном сервере. В случае отказа основного сервера исполнение автоматически передается на резервный сервер.
При организации зеркалирования в общем случае используются три SQL-сервера, два из которых представляют собой серверы высокой готовности. Это многопроцессорные системы с разделяемой памятью, подключенные к RAID-дискам. Если первая система дает сбой, резервная запускается с системных дисков. Если сбой дает диск, то контроль четности RAID заставляет сменить неисправный диск на запасной. Такая конфигурация выдерживает любой одиночный сбой диска или процессора.
На основном (principal) размещается главная база данных. Именно к этому серверу подключаются приложения; на нем же обрабатываются транзакции. Зеркальный сервер резерва (mirror) содержит копию; он является местом назначения переданных записей журналов транзакций и находится в состоянии ожидания. Третий сервер, свидетель (witness), отслеживает состояние двух других серверов и позволяет организовать автоматическое переключение в случае сбоя. Именно свидетель делает выбор сервера, поскольку знает, какой из них в данный момент является основным, а какой - зеркальным. Для автоматического переключения клиентов в случае отказа основного сервера используется функция автоматического перенаправления клиентов.
Вместо полного копирования журналов транзакций между серверами устанавливается специализированный сеанс зеркалирования, который используется для передачи между серверами отдельных записей транзакций. По мере того, как записи транзакций генерируются на основном сервере, они также сохраняются в журнале транзакций зеркального сервера, а изменения фиксируются в его базе данных. При этом резервные копии основной БД используются только для инициализации зеркальной БД на зеркальном сервере. Важно знать следующее:
если зеркальное отображение БД активировано, нельзя создавать обычные резервные копии и восстанавливать их для зеркальной БД;
резервную копию основной БД нельзя восстанавливать обычным образом, после переключения на зеркальный сервер, он сам скорректирует зеркальную БД.
Имеется дополнительная возможность организации доступа для чтения данных из зеркальной копии БД с использованием снимков (snapshot) базы данных. Снимок — это специальный объект, представляющий собой доступную только для чтения копию базы данных в определенный момент времени. Максимальный размер, который может иметь снимок, равен размеру исходной базы данных в момент создания.
SQL Server позволяет создавать множественные снимки базы данных в различные моменты времени. Можно настроить периодическое создание снимков — каждый день или каждый час. В случае непреднамеренного удаления данных их можно восстановить из наиболее свежего снимка. Рекомендуется создавать снимки базы данных перед выполнением сложных задач и запросов, в результате которых данные могут быть испорчены.
Сеанс зеркалирования может быть настроен для работы в синхронном или асинхронном режиме. В синхронном режиме изменения в базе основного сервера завершаются только в том случае, когда завершена запись этих изменений в базу данных на резервном сервере. В этом режиме задержки определяются скоростью передачи данных по сети и объемом изменений. Тем не менее, допустимой считается задержка не более, чем в одну или две транзакции. Асинхронный режим позволяет добиться увеличения скорости работы и сократить задержки, поскольку завершение изменений основным сервером осуществляется без подтверждения от резервной базы данных. В этом случае практически нет задержки записи.
С точки зрения клиента, восстановление в случае отказа основного сервера происходит автоматически и практически немедленно. Если основной сервер становится недоступным, приложения переключаются на зеркальный сервер, который становится основным. А отключившийся основной сервер после восстановления берет на себя функцию зеркала и получает записи журналов транзакций.
Самым современным на сегодняметодом зеркального копирования являетсяметод глобального кворума. В этом случае главный и резервный сервер связаны посредством глобальной линии связи с высокой избыточностью. Клиенты могут подключаться к любому серверу, поскольку те работают параллельно, а взаимодействием серверов управляет распределенный менеджер блокировок. Дисковая подсистема высокой готовностиRAIDсоединена с серверами в нескольких точках через вторую глобальную линию связи. Тактовые импульсы отслеживают наличие связи между различными дисками и процессорами. В этой архитектуре обе системы (и главная, и резервная) находятся в актуальном состоянии. Любой единичный сбой узла, процессора или диска незаметен для конечного пользователя, за исключением потери производительности. Эту архитектуру использует большинство приложений, поддерживающих денежные переводы, а также многие крупные биржи. К недостаткам относят:
Распределенный менеджер блокировок представляет собой потенциально узкое место системы
архитектура является дорогостоящей
для работы с такой системой нужны специально подготовленные специалисты
Выбор устройств и носителей для резервного копирования
Для создания резервных копий данных существует множество решений. Некоторые из них высокопроизводительны, но дороги. Другие – медленны, но очень надежны. Решение реализации резервного копирования, соответствующее индивидуальным требованиям каждой организации, зависит от следующих факторов: