Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address.
Learn more about clone URLs
Уровни критичности ИС
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
| Mission Critical- системы, работающие в режиме «боевого дежурства». К таким системам относятся: остро критические с точки зрения государственного управления или внешних факторов – например экологии, приложения, а также технологические приложения, работающие в режиме реального времени. Выход из строя этих систем влечет за собой невосполнимые потери для управления, в т.ч. угрозу жизни и здоровью персонала и населения. Рекомендованное время восстановления подобных систем после отказа менее 10 минут. Для таких систем должны использоваться специализированные серверные платформы и инфраструктурные уровни с полным многократным резервированием всех компонентов, в том числе с использованием резервных удаленных ЦОД; |
| Business Critical– системы, критические для управления, с режимом работы 24х7х365. Выход из строя этих систем влечет за собой значительные бизнес потери для органов государственной власти. Рекомендованное время восстановления подобных систем после отказа менее 2 часов. Для таких систем должны использоваться кластерные решения и инфраструктурные уровни с частичным резервированием используемых инфраструктурных компонентов; |
| Business Operational — обычные бизнес-приложения — системы, не требующие работы в реальном времени, с режимом работы 8х5. Рекомендованное время восстановления подобных систем после отказа 4-6 часа. Для таких систем рекомендуется использовать резервирование хранения данных и электропитания; |
| Office Production — не критические для управления приложения, персональные данные. Рекомендованное время восстановления подобных систем после отказа 1-2 рабочих дня. |
Какое оборудование является важным (критичным)?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Источник: gist.github.com
УРОВНИ КРИТИЧНОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ
В соответствии с данными показателями, все информационные системы на предприятии делят на несколько уровней критичности (4):
- СИСТЕМЫ НЕПРЕРЫВНОГО ДЕЙСТВИЯ. Mision-Critical. Системы непрерывного действия для решения особо важных (критичных) задач. Сбой систем подобного уровня выводит из строя, парализует работу всего комплекса информационных систем или оказывает существенное влияние на функционирование компании.
Показатель функционирования информационной системы уровня Mision-Critical
Как сэкономить на запуске бизнеса
· сбой информационной системы парализует работу компании.
- СИСТЕМЫ BusinEss-Critical. Системы, критичные для эффективности бизнеса, но при этом не оказывающие прямого воздействия на него (т.к. подобные операции могут быть выполнены вручную). Но, в случае их остановки, бизнес будет нести существенные финансовые потери.
Показатели функционирования ИС уровня Business-Critical:
· Сбой ИС приводит к значительным финансовым потерям
· Сбой ИС может привести в сбою работы систем Mision-Critical
· Данной МС пользуются более 500 человек, непосредственно связанных с обслуживанием клиентов
- СИСТЕМЫ BUSINESS OPERATIONAL. Системы, обеспечивающие функционирование бизнеса. Информационные системы данного уровня используются бизнесом для увеличения его эффективности, но при этом, их отключение на непродолжительное время не приведет существенным финансовым потерям. Долгосрочное отключение этих систем будет влиять на эффективность бизнеса.
Показатели функционирования ИС уровня Business Operational:
· Сбой ИС приводит к финансовым потерям
· Сбой ИС, возможно, приводит к сбою работы систем BusinEss-Critical
- СИСТЕМЫ OFFICE PRODUCTIVITY. Системы внутреннего использования. К данному уровню относятся информационные системы, обеспечивающие эффективность выполнения офисных операций. Эти системы не являются важными для функционирования предприятия в целом, но необходимы для увеличения эффективности работы персонала.
Показатель функционирования ИС уровня OFFICE PRODUCTIVITY —
· сравнение с прочими аналогичными системами
Агоритм определения уровня критичности системы:
- Определение перечня основных бизнес-процессов предприятия, остановка функционирования которых парализует работу компании или ведет к существенным финансовым потерям
- Анализ существующих информационных систем. Их связь с основными бизнес-процессами. Определение важности тех или иных ресурсов (речь идет об информационных системах и их компонентах) для функционирования основных бизнес-процессов компании.
- Построение общей модели информационных систем, в которой определяются основные взаимосвязи между информационными, программными, техническими и людскими ресурсами. Определяются способы их взаимодействия
- Оценка экономического ущерба, связанного со сбоем в работе информационной системы, и вероятность его возникновения
- Непосредственно оценка уровня критичности информационной системы, на основании той информации, которая получена на предыдущих этапах
Моделирование архитектуры корпоративной информационной системы
Задача по созданию информационной системы – многоэтапный процесс, состоящий из подзадач. (см лекцию от 9.09.09).
· Функциональное моделирование (функциональный анализ)
· Структурное моделирование (организационная структура)
A – функциональная логика
B – модели потоков данных
C – модели анализа состояний
D – статистические модели развития, сценарии
Все модели должны соответствовать общему направлению бизнеса!
Задача ИТ-менеджера – проектируемая система не должна стать «тормозом» для компании. Принципа «как у соседа» быть не должно!
Использование технологии моделирования и соответствующие им инструментальные средства
| Методы | Стратегический уровень | Структурный уровень | Операционный уровень | Инструментальные средства | Комментарии |
| Функциональные методы | обязательно | обязательно | обязательно | FH-методы IDEF0-методы | Получаем Иерархическую функциональную модель |
| Информационные методы | обязательно | обязательно | обязательно | ERDiagr – диаграммы IDEF1x | Моделирование данных |
| Структурные методы | не обязательно | обязательно | обязательно | Четких стандартов нет при формировании модели | |
| Функциональная логика (группа А) | обязательно | обязательно | не обязательно | Function Logic CPN-методы | — ORACLE CASE Methods — Сети Петри |
| Модели потоков данных (гр. B) | не обязательно | обязательно | не обязательно | Идеология IDEF0 | Диаграммы потоков данных |
| Модели анализа состояний (гр. С) | не обязательно | обязательно | не обязательно | Моделирование процессов: ARIS, Business Studio | Моделирование процессов: |
| Статистические модели развития, сценарии (гр. D) | не обязательно | обязательно | не обязательно | SSADM | Сценарный подход |
Модели, используемые для определения потребностей бизнеса, должны обосновывать целесообразность его трансформации. При этом ИС должна быть открыта в отношении введения новых процедур (функциональные модули ERP-системы).
При этом существует т.н. предел гибкости системы.
В 1987 Джон Захман объединил основные технологии моделирования в одной схеме. Ее использование полезно при проектировании и развитии корпоративной информационной системы. В данной схеме, архитектура ИС определяется как результат представления различных точек зрения заинтересованных лиц. Таким образом, существует некое множество архитектур, каждое из которых зависит от того, кем является заинтересованное лицо, и на каком аспекте оно концентрирует свое внимание. Эти представления соответствуют тому, как видят Информационную систему Заказчик, Проектировщик, Разработчик в проекции трех основных аспектов:
- ДАННЫЕ
- ФУНКЦИИ
- СЕТЕВАЯ СТРУКТУРА
Разработка любой ИС должна начинается с анализа аспектов деятельности предприятия.
Изучение этих аспектов должно сопровождаться формализацией их представления в виде некоторой схемы, согласованной со всеми участниками проекта. В дальнейшем, эти описания различных сторон деятельности предприятия преобразуются в спецификации проектируемой системы.
В схеме Захмана каждая строка соответствует определенной точке зрения участника проекта (уровень участника также должен быть определен), а в столбцах указаны аспекты деятельности предприятия.
Взаимосвязь бизнес-модели предприятия и архитектуры корпоративной информационной системы предприятия
(классическая схема Захмана)
| Уровни/точки зрения | Данные (ЧТО?) | Функции (КАК?) | Сеть (ГДЕ?) |
| Миссия и стратегия предприятия Аналитики, топ-менеджеры | Список данных, информации, знаний, объектов, важных для бизнеса | Список процессов, выполняемых бизнесом | Список территорий действия бизнеса (пространственное распределение бизнеса) |
| Концептуальная бизнес-модель предприятия Инвестор, акционер | Семантическая модель (числа, связи) – финансовая модель (структура баланса, например) (статьи затрат и тп) | Модели бизнес-процесса (вход-преобразование-выход) | Логистическая модель |
| Логическая модель (модель системы) Проектировщик, системный архитектор | Логическая модель данных (движение данных) | Архитектура приложений и логическая связь между этими приложениями | Архитектура распределенной системы |
| Технологическая модель Разработчик (builder) | Физическая модель данных | Разработка системы в целом | Технологическая архитектура, с соответствующей ей инфраструктурой |
| Детальное представление ИС (субподрядчики) Программисты | Определение конкретных данных (вплоть до кубиков в OLAP-технологиях) | Программы | Архитектура сети (ЛВС, связь) (оптоволокно, wi-fi) |
| Уровень пользователя (тот, кто будет там работать) | Например, Данные | Например, Функции | Например, Коммуникации |
Характеристика взгляда. Взгляд состоит из двух основных частей:
- Описание взгляда, которое включает следующие составляющие:
· Точка зрения (статус человека, имеющего данный взгляд)
· Что показывает данный взгляд
· Техника или язык, описывающий данных взгляд (методология IDEF, функциональные диаграммы)
· Уровень деятельности (стратегический, структурный, операционный)
· Предметная область (насколько широкая, чем ограничена)
· Предполагаемое использование (где, при разработке чего использовать)
· Пользователи (заинтересованные лица, те, кто будут использовать данный взгляд)
· Граничные предположения (интеграция взглядов)
- Управляющая информация о взгляд
· Как был разработан взгляд
· С кем контактировать для управления изменениями
· Насколько взгляд полон и определен
· Составные части (термины, диаграммы, критические факторы успеха и т.д.)
Вопросу ЧТО? соответствует колонка данных.
Для ИС этот вопрос относится к сущностям данных и их связям. В данном случае, внимание сосредоточено на том, из чего состоят данные, а не на том, как они используются.
Вопросу КАК? соответствует колонка функций.
Здесь обычно описывается функционирование отдельных частей системы с помощью модели ВХОД-ВЫХОД.
В ИС функции обычно представлены
- ВХОДАМИ (элементы данных),
- ПРОЦЕССАМИ ПРЕОБРАЗОВАНИЯ и
- ВЫХОДАМИ (информация)
При этом, внимание уделяется не столько отдельным частям и их связям, сколько тому, как эти части взаимодействуют при выполнении общей задачи
Вопросу ГДЕ? соответствует колонка сетевой структуры.
Описание положения элементов ИС и механизмов их взаимодействия.
Кроме классической схемы Захмана, ориентированной на проектирование информационной системы с полной автоматизацией, существует расширенная схема, включающая дополнительно три аспекта: почему?, кто?, когда?
| МОТИВЫ (почему?) | ЛЮДИ (кто?) | ВРЕМЯ (когда?) | СТОИМОСТЬ (сколько?) | |
| Миссия и стратегия предприятия Аналитики, топ-менеджеры | Конкуренты, новые товары, … | Партнеры, филиалы, клиенты | Главные события в ведении бизнеса | Стоимость инвестиционного проекта (чистая текущая стоимость проекта) |
| Концептуальная бизнес-модель предприятия Инвестор, акционер | Например, бизнес-план | Например модель «work flow» | Например, сетевой график | |
| Логическая модель (модель системы) Проектировщик, системный архитектор | Например, бизнес-правила | Например, архитектура пользовательского интерфейса | Например, структура процесса (обработка данных) | |
| Технологическая модель Разработчик (builder) | Например, условия действия | Например, архитектура презентаций (материала) (уровни презентаций – информация для директора/кладовщика) | Например, структура контроля (конкретные временные параметры, контроль выполнения целей) | |
| Детальное представление ИС (субподрядчики) Программисты | Например, описание (конкретизация) правил поведения | Например, архитектура безопасности | Например, определение времени | |
| Уровень/взгляд пользователя (тот, кто будет там работать) | Например, стратегия | Например, организация (место в орг.структуре) | Например, расписание (график работы пользователя, регламенты работ по каждому рабочему месту) |
- Окупится проект или нет (окупаемость)
- Насколько быстро окупится (период окупаемости)
- Риски проекта
РАСШИРЕННАЯ схема Захмана
| Уровни/точки зрения | Данные (ЧТО?) | Функции (КАК?) | Сеть (ГДЕ?) | МОТИВЫ (почему?) | ЛЮДИ (кто?) | ВРЕМЯ (когда?) | СТОИМОСТЬ (сколько?) |
| Миссия и стратегия предприятия Аналитики, топ-менеджеры | Список данных, информации, знаний, объектов, важных для бизнеса | Список процессов, выполняемых бизнесом | Список территорий действия бизнеса (пространственное распределение бизнеса) | Конкуренты, новые товары, … | Партнеры, филиалы, клиенты | Главные события в ведении бизнеса | Стоимость инвестиционного проекта (чистая текущая стоимость проекта) |
| Концептуальная бизнес-модель предприятия Инвестор, акционер | Семантическая модель (числа, связи) – финансовая модель (структура баланса, например) (статьи затрат и тп) | Модели бизнес-процесса (вход-преобразование-выход) | Логистическая модель | Например, бизнес-план | Например модель «work flow» | Например, сетевой график | |
| Логическая модель (модель системы) Проектировщик, системный архитектор | Логическая модель данных (движение данных) | Архитектура приложений и логическая связь между этими приложениями | Архитектура распределенной системы | Например, бизнес-правила | Например, архитектура пользовательского интерфейса | Например, структура процесса (обработка данных) | |
| Технологическая модель Разработчик ( builder ) | Физическая модель данных | Разработка системы в целом | Технологическая архитектура, с соответствующей ей инфраструктурой | Например, условия действия | Например, архитектура презентаций (материала) (уровни презентаций – информация для директора/кладовщика) | Например, структура контроля (конкретные временные параметры, контроль выполнения целей) | |
| Детальное представление ИС (субподрядчики) Программисты | Определение конкретных данных (вплоть до кубиков в OLAP-технологиях) | Программы | Архитектура сети (ЛВС, связь) (оптоволокно, wi-fi) | Например, описание (конкретизация) правил поведения | Например, архитектура безопасности | Например, определение времени | |
| Уровень пользователя (тот, кто будет там работать) | Например, Данные | Например, Функции | Например, Коммуникации | Например, стратегия | Например, организация (место в орг.структуре) | Например, расписание (график работы пользователя, регламенты работ по каждому рабочему месту) |
Источник: mykonspekts.ru
Критическая система
A критическая система является система, которая должна быть высоконадежной и сохранять эту надежность по мере развития без чрезмерных затрат.
Общее описание
Для таких систем при разработке должны использоваться надежные методы и технологии. Следовательно, критические системы обычно разрабатываются с использованием хорошо проверенных методов, а не более новых методов, которые не были предметом обширного практического опыта. Разработчики критических систем по своей природе консервативны, предпочитая использовать старые методы, чьи сильные и слабые стороны понятны, а не новые методы, которые могут показаться лучше, но чьи долгосрочные проблемы неизвестны.
Дорогие методы разработки программного обеспечения. которые не рентабельны для некритических систем, иногда могут использоваться для разработки критических систем. Например, формальные математические методы разработки программного обеспечения успешно используются для систем, критичных к безопасности. Одна из причин, по которой используются эти формальные методы, заключается в том, что они помогают сократить объем необходимого тестирования. Для критически важных систем затраты на верификацию и валидацию обычно очень высоки — более 50% от общих затрат на разработку системы.
Классификация
Критическая система выделяется последствиями, связанными с отказом системы или функции. Аналогичным образом, критические системы дополнительно различаются на отказоустойчивые и отказоустойчивые системы в соответствии с допуском, который они должны проявлять к отказам:
- Отказоустойчивые — обычно требуются для работы не только в номинальных условиях (ожидаемых), но и в ухудшенных. ситуации, когда некоторые части не работают должным образом. Например, самолеты являются отказоустойчивыми, поскольку они должны иметь возможность летать даже в случае отказа некоторых компонентов.
- Отказоустойчивые — должны безопасно отключаться в случае единичного или множественного отказа. Поезда являются отказоустойчивыми системами, потому что остановки поезда обычно достаточно для перевода в безопасное состояние.
Критично для безопасности
Критически важные для безопасности системы имеют дело со сценариями, которые могут привести к гибели людей, серьезным травмам или ущербу к окружающей среде. Примерами систем, критически важных для безопасности, являются система управления химическим производством, самолет, контроллер беспилотной системы метро, контроллер атомной станции и т. Д.
Критически важная
Критически важные системы созданы, чтобы избежать невозможности завершить общую систему, цели проекта или одну из целей, для которых система была разработана. Примерами критически важных систем являются навигационная система для космического корабля, программное обеспечение, управляющее системой обработки багажа аэропорта и т. Д.
Критически важными для бизнеса
Критически важными для бизнеса системами являются запрограммированы на избежание значительных материальных или нематериальных экономических затрат; например, потеря бизнеса или ущерб репутации. Часто это происходит из-за прерывания обслуживания, вызванного непригодностью системы. Примерами критически важных для бизнеса систем являются система учета клиентов в банке, система биржевой торговли, ERP-система компании, поисковая система в Интернете и т. Д.
Безопасность критически важна
Критически важные системы безопасности имеют дело с потерей конфиденциальных данных в результате кражи или случайной потери.
См. Также
- Теория надежности
- Надежная конструкция системы
- Избыточность (инженерия)
- Фактор безопасность
- Формальные методы
Источник: alphapedia.ru