12 2 ТЕХНИЧЕСКИЕ КОМПОНЕНТЫ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ УВК

Состав технических
компонентов УВК

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

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

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

Технические
компоненты должны удовлетворять
требованиям:

Состав программных
компонентов УВК

Системное программное
обеспечение (ПО) и общее прикладное ПО
образуют математическое обеспечение
УВК и входят в комплект его поставки.

Системное ПО УВК
– это совокупность ПО ЭВМ (процессора)
и дополнительных программных средств,
обеспечивающих:

Дополнительные
программные средства создает разработчик
УВК, а обеспечивает ими потребителя –
изготовитель УВК.

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

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

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

3 Требования к увк

Виды совместимости
компонентов УВК обеспечиваются следующими
мерами:

ИТ-архитектура предприятия

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

Следующей ступенью развития ИТ-архитектуры явилось понятие корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). На этом этапе ИТ-архитектура включала в себя помимо технологического уровня описания архитектуры информации и архитектуры прикладных систем. Основное направление работ в этом случае состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем. Обобщенная ИТ – архитектура должна включать в себя как логические, так и технические компоненты. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Техническая архитектура определяет конкретные стандарты и правила, которые будут использоваться для реализации логической архитектуры.

Такой подход обеспечивает более эффективное взаимодействие структурных подразделений организации8:

· совместный доступ к информации различных подразделений, а также внешних организаций (клиентов, партнеров, поставщиков);

· уменьшение дублирования близких по функционалу прикладных информационных систем для различных бизнес-подразделений;

· решение проблемы интеграции и взаимодействия информационных систем.

· Традиционно ИТ – архитектуру предприятия представляют в виде трех взаимосвязанных компонентов:

· Enterprise Information Architecture (EIA) – информационная архитектура;

· Enterprise Solution Architecture (ESA) – архитектура прикладных решений;

· Enterprise Technical Architecture (ETA) – техническая архитектура.

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

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

Информационная архитектура (EIA – Enterprise Information Architecture) или архитектура информации – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий в себя:

· базы данных и хранилища данных;

· информационные потоки (как внутри организации, так и связи с внешним миром).

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

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

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

Формирование информационной архитектуры предприятия требует определения связей между функциями ИС и автоматизированными операциями в бизнес-процессах предприятия. При этом уточняется, какая информация необходима для функционирования текущих бизнес-процессов компании, а какая – для создания новых.

В процессе разработки информационной архитектуры предприятия решаются следующие задачи:

· идентификация существующих данных, определение их источников и процедур использования;

· оптимизация данных за счет сокращения дублирования, исключение неоднозначности и противоречивости информации;

· минимизация перемещения данных за счет их оптимального расположения;

· интеграция метаданных для обеспечения их целостного представления;

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

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

Модели, описывающие информационную архитектуру, различаются уровнем абстракции:

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

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

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

Рис. 1.18. Информационная архитектура

Архитектура прикладных решений (ESA – Enterprise Solution Architecture) или архитектура приложений состоит из совокупности программных продуктов и интерфейсов между ними.

В архитектуре прикладных решений выделают два направления:

· разработка прикладных систем;

· использование прикладных систем.

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

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

· компоненты и структура системы – внутренняя структура системы, включающая в себя информацию о программных продуктах и базах данных;

· интерфейсы – описывают взаимодействие приложений с внешними объектами (программными продуктами, пользователями).

Информационная система (ИС или приложение – Application) – это программно-аппаратный комплекс, объединяющий в себе компоненты системы, хранилище данных и базы данных, обеспечивающий выполнение определенных бизнес функций предприятия. И С может иметь одну или несколько инсталляций (экземпляров – Application Instance), которые установлены на серверах и дисковых массивах (Рис. 1.19).

Приложение имеет определенный набор функций (Application function), обеспечивающих поддержку ИТ-сервисов (IT service) и бизнес-процессов (Business process).

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

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

Рис. 1.19. Связи информационной системы

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

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

В соответствии с классификацией по архитектурным стилям принято выделять следующие основные группы информационных систем:

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

· приложения, осуществляющие операции в реальном времени (Real-Time operations) – это информационные системы, обеспечивающие бизнес-процессы организации, требующие непрерывного мониторинга и информационного обеспечения (к таким системам можно отнести ИС, обеспечивающие транспортных операций в аэропорту и на железной дороге);

· аналитические приложения, бизнес-аналитика, поддержка принятия управленческих решений (Analytical and Business Intelligence) – то есть все ИС, связанные с управлением знаниями, обеспечивающие сбор и анализ больших массивов данных в короткие промежутки времени;

· приложения для осуществления совместной работы (Collaborative) – включает различные средства взаимодействия пользователей внутри компаниями;

· корпоративные и обслуживающие приложения (Utility) – включают в себя стандартные приложения, обеспечивающие функционирование основных бизнес-процессов компании (в этот раздел попадают такие группы систем как CRM-системы для управления взаимоотношением с клиентами, ERP-системы для управления ресурсами предприятия и другие).

В таблице (Таблица 1.2) представлены характеристики основных типов прикладных систем. Следует отметить, что большое количество приложений может попадать одновременно в несколько групп по данной классификации.

Таблица 1.2 – Характеристики основных типов прикладных систем

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

Текущий профиль информационных систем (existing portfolio) – описывает существующие приложения, компоненты, интерфейсы и связанные с ними бизнес-процессы (текущая архитектура приложений).

Планируемый профиль информационных систем (planned portfolio) – описывает необходимую для бизнеса функциональность информационной системы в будущем (целевая архитектура приложений).

План миграции (migration planning) – это документ, описывающий набор изменений, необходимых для перехода из текущего состояния информационной системы в планируемое (целевое). На основании плана миграции активируются проекты внедрения новых информационных систем или внесения изменений в существующие системы.

Оценка портфеля информационных систем (Application portfolio assessment) – используется для идентификации проблемных областей и возможностей удовлетворения потребностей бизнеса и состоит из следующих разделов:

· вывод приложений из эксплуатации, замена (phase out / replace);

· переоценка необходимости приложений (re-evaluate / reposition);

· разработка новой инфраструктуры ИС (application infrastructure development);

· обеспечение сопровождения и развития ИС (maintain / evolve).

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

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

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

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

3) Большое количество сотрудников (свыше 500) не может выполнять свои непосредственные обязанности. Подобная ситуация может привести к совершенно неожиданным потерям для предприятия.

В соответствии с представленными выше критериями все ИС на предприятии можно разделить на следующие уровни критичности:

Level 1. Mission-Critical. Системы непрерывного действия для решения особо важных (критичных) задач. Сбой систем подобного уровня выводит из строя, парализует работу всего комплекса информационных систем или оказывает существенное влияние на функционирование компании.

Показатель функционирования ИС уровня Mission-Critical – сбой ИС парализует работу компании (например, компания не может предоставлять основные услуги Абоненту).

Level 2. Business-Critical. Системы, критичные для бизнеса. Системы, обеспечивающие эффективное выполнение бизнес-процессов компании, но при этом не оказывающие прямого воздействия на них. Предприятие может функционировать без информационных систем этого уровня (т.к. подобные операции могут быть выполнены вручную), но, в случае их остановки, будет нести существенные финансовые потери. К подобному уровню также относятся системы, чрезвычайно чувствительные к временным рамкам (например, ИС – периодически передающие информацию в системы Mission-Critical). Соответственно, информационные системы данного класса должны функционировать в непрерывном режиме при условии, что потери, связанные с их остановкой, существенно превышают расходы на содержание.

Показатели функционирования ИС уровня Business-Critical:

· сбой ИС приводит к существенным финансовым потерям;

· сбой ИС может привести к сбою работы систем Mission-Critical;

· данной ИС пользуются более 500 человек, непосредственно связанных с обслуживанием клиентов.

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

Показатели функционирования ИС уровня Business Operational:

· сбой ИС приводит к финансовым потерям;

· сбой ИС, возможно, приводит к сбою работы систем Business-Critical.

Level 4. Office Productivity. Системы внутреннего использования. К данному уровню относятся информационные системы, обеспечивающие эффективность выполнения офисных операций. Эти системы не являются важными для функционирования предприятия в целом, но необходимы для увеличения эффективности работы персонала. Показатель функционирования ИС уровня Office Productivity – сравнение с прочими аналогичными системами.

Алгоритм определения уровня критичности систем:

1) Определение перечня основных бизнес-процессов предприятия, остановка функционирования которых парализует работу компании или ведет к существенным финансовым потерям.

2) Анализ существующих ИС и их взаимосвязь с основными бизнес-процессами компании. Определение важности тех или иных ресурсов (информационных систем и их компонентов) для функционирования основных бизнес-процессов компании.

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

4) Оценка экономического ущерба, связанного с остановкой ИС и вероятность его возникновения.

5) Оценка уровня критичности ИС для функционирования предприятия на основании информации собранной на предыдущих шагах.

1.2.5. Техническая архитектура ИС предприятия (ETA)

Техническая архитектура ИС предприятия (ETA – Enterprise Technical Architecture) формируется из совокупности программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений ИС. Основное назначение технической архитектуры – это обеспечение надежных ИТ-сервисов в рамках всего предприятия в целом.

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

Специалисты компании Gartner Group выделяют шесть архитектурных компонент (сервисов), которые заложены в основу технологической архитектуры ИС:

· сервисы данных: системы управления базами данных, хранилища данных, системы поддержки принятия решений (Business Intelligence);

· прикладные сервисы: языки программирования, средства разработки приложений, системы коллективной работы;

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

· вычислительная инфраструктура: операционные системы и аппаратные средства;

· сетевые сервисы, локальные сети: сетевое аппаратное обеспечение.

· сервисы безопасности, авторизация: аутентификация, сетевая безопасность, физическая безопасность центров обработки данных.

На уровне технической архитектуры выделяют две группы требований к программно-аппаратным средствам:

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

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

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

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

· обеспечение реализации процесса;

· контроль качества процесса.

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

Вопросы для самоконтроля к теме 1

1) Охарактеризуйте содержательную часть информационного менеджмента.

2) В чем заключаются основные цель и задачи информационного менеджмента?

3) Что представляет собой информация как фактор производства и как основа процесса принятия управленческого решения?

4) Что принято относить к информационным технологиям?

5) Назовите, какие Вы знаете технологии построения корпоративной информационной сети?

6) Для каких целей в крупных организациях используют хранилища данных?

7) Что такое OLAP-технологии и для чего их используют?

8) В чем проявляется связь между информационными системами и информационными технологиями?

9) Назовите основные требования, предъявляемые к информационной системе организации.

10) Что понимают под термином «метамодель» организации, как она формируется?

11) Охарактеризуйте взаимосвязь архитектур бизнеса и его информационной системы.

12) На чем основано управление ИТ-портфелем предприятия?

13) Какие уровни абстракции архитектуры предприятия Вы знаете?

14) В чем проявляется стратегическое соответствие бизнеса и информационной системы предприятия?

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

16) Как формируется бизнес-архитектура предприятия?

17) Какие уровни критичности информационной системы предприятия существуют и как они определяются?

18) Что понимают под технической архитектурой информационной системы предприятия?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот
технологический принцип наиболее
активно развивается в настоящее время.
Он используется в качестве одного из
компонентов в нескольких крупных
антивирусах, и в качестве основы — в
отдельных утилитах, специализирующихся
на мониторинге системы (их называют
«HIPS-утилитами», «HIPS’ами» — это Prevx,
CyberHawk и ряд других).

Это
наиболее абстрактный способ сбора
информации о предположительно зараженной
системе.

Данный
метод основан на следующих положениях:

Исходя
из этих положений мы можем судить о
состоянии системы (и, следовательно, о
возможном присутствии в ней вредоносных
программ), сравнивая его с эталоном (за
эталон принимается «здоровое» состояние
системы) или анализируя совокупность
отдельных ее параметров.

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

Технические составлящие проекта разработки ПО

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

Цель этой статьи проста. Я хочу чтобы вы в общих чертах ознакомились с наиболее популярными техническими компонентами используемыми во всех проектах.

На вопрос «А зачем менеджеру знать техническую часть, если его работа практически никак к ней не относится?» отвечу: «Потому, что невозможно достичь высокого качества в управлении IT-проектами, если ты не знаешь какими понятиями и инструментами твои команды оперируют, и как твои проекты технически устроены».

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

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

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

Например, вы используете браузер чтобы открыть эту страницу. В данном случае ваш браузер – это клиент, а программа, находящаяся по адресу https://keepsimple.io/ru, которая обрабатывает ваш запрос и открывает эту страницу – Веб-Сервер.

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

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

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

Хостингом называется сервис предоставления некоего пространства в Интернете для нашего сервера.

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

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

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

Промежуточные серверы (Staging Servers)

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

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

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

Каждый прямоугольник = один сервер:

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

Красный – это сервер среды разработки (Dev. Server, или просто Dev). На этом сервере разработчики постоянно что-то меняют, и здесь вполне может что-то не работать.

Бледно-желтый – QA сервер для тестирования. По сути, на Dev-е, где постоянная рутина, разрабатываются инкременты которые попали в Спринт. А сюда попадают те инкременты, которые были помечены разработчиками как «завершенные» и «готовые к тестированию» (мы же помним колонки «In Progress» и «Testing» на нашей Канбан доске?). Таким образом, тестировщики могут проводить свои тесты на своих серверах, зная, что эти серверы изолированы от того хаоса и нестабильности, который может происходить на Dev. Сервере.

Салатовый – UAT-2. Основное отличие от UAT в том, что если UAT, QA и Dev серверы могут иметь низкие технические характеристики (нет смысла арендовать дороженный сервер способный выдержать нагрузку десятков миллионов пользователей, когда твоя команда, которая занимается разработкой состоит из пары десятков человек), то UAT-2 это сервер, который по техническим параметрам полностью повторяет Production сервер. Делается это для того, чтобы провести на UAT-2 те тестирования, которые невозможно провести на предыдущих серверах (например, тот же stress-test нагрузки).

Кол-во серверов, и их предназначение определяется размером и критичностью проекта. Проект Keepsimple, например, имеет два сервера: Staging сервер, где мы вносим изменения и валидируем новые фичи, и Production сервер, с которого вы прямо сейчас читаете этот текст.

Системы тестирования, мониторинга и аналитики

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

К примеру, если наш проект имеет потенциальный рынок в 50 миллионов пользователей, и мы ожидаем, что в первую неделю нас посетит не менее 10 миллионов, мы можем провести стресс-тест сервера, с симуляцией нагрузки, используя специализированные онлайн сервисы (locust, loader.io etc), чтобы быть уверены, что мощности наших серверов хватит, чтобы справиться с этой нагрузкой. Если тест провален, мы просто идем к нашему Хостеру, покупаем дополнительные мощности, и проводим тесты заново.

Если мы хотим проанализировать, насколько эффективно открываются страницы нашего сайта на стороне пользователей, мы можем настроить дополнительные системы анализа продуктивности (sitespeed.io, pagespeed insights, monitis, new relic, zabbix, etc). Если по результатам анализа мы выявили, что некоторые компоненты нашей системы работают слишком медленно, тогда это может стать сигналом для разработчиков, чтобы открыть коды этих компонентов и найти пути для их оптимизации.

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

Если же мы хотим проводить специальный мониторинг какой-то специфической активности, нужной нам для каких-то конкретных целей, то для этого тоже есть целый ряд инструментов (graylog, kibana, logstash etc).

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

Мы бы хотели знать какие слова вводятся нашими пользователями в Google, прежде чем они попадут на наш сайт, и безусловно, не лишним было бы заодно знать какими устройствами они пользуются (smartphones, tablets, pc) и какими платформами (windows, linux, mac).

К счастью для нас, бОльшая часть этой информации легко получается если мы настроим Google Analytics. Сервис имеет бесплатную версию, поэтому его используют совершенно все, кому не лень (Мне не лень, Большой Брат следит за тобой. Keepsimple активно использует GA). Вообще, отдельно поизучать Google Analytics было бы полезно всем, кто работает в IT, как минимум для того, чтобы представить возможности этого внушительного инструмента.

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

На самом деле, я очень хотел написать про GIT, SVN, Непрерывную Интеграцию, Непрерывную Доставку и Непрерывное Развертывание (Continuous Integration (CI), Continuous Delivery (CD), Continuous Deployment), попутно указав разницу, и смысл каждой из этих практик, но мне кажется, что от этого статья станет слишком технической и сложной для освоения.

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

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