 |
The ITIL 4 service value system (SVS)
The ITIL 4 service value chain (SVC)
Costs, outcomes, value, risks scales
27.04.2021
14.05.2020
Некоторые термины ITILv3
Управление услугами(Service Management) это множество специализированных организационных возможностей для предоставления ценности заказчикам в форме услуг.
Заказчик(Customer) — это покупатель товаров или услуг. Заказчик для поставщика IT-услуг — это человек (группа людей), который заключает соглашения с поставщиком на предоставление IT-услуг и отвечает за то, чтобы предоставленные услуги были оплачены.
Поставщик услуг(Service provider) — это организация, поставляющая услуги одному или нескольким внутренним или внешним заказчикам.
Пользователь — это сотрудник организации, использующий IT-услугу для выполнения повседневной работы.
IT-услуга (сервис) — способ предоставления ценности заказчикам через содействие им в получении результатов на выходе, которых заказчики хотят достичь без владения специфическими затратами и рисками определённых потребностей. Зачастую определяется как «что делает продукт/сервис».
Полезность услуги — функциональность IT-услуги с точки зрения заказчика.
Гарантия — обещание или гарантия того, что продукт или услуга будет соответствовать согласованным требованиям.
Гарантия качества услуги — уверенность в том, что IT-сервис будет соответствовать согласованным требованиям. Может быть в виде формального соглашения, такого как SLA или договор, либо как маркетинговое сообщение или представление торговой марки.
Производительность (Performance) — мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой.
Ограничение — это запрет или невозможность выполнения каких-то действий.
Организация — это определенная форма сотрудничества людей.
Миссия — это короткое и четкое описание задач, стоящих перед организацией, и идеалов, в которые она верит.
Стратегические задачи (objectives) — это более подробное описание того, что хочет достичь организация в долгосрочной перспективе.
Политика организации (policy) — это совокупность всех решений и мер, принятых организацией для постановки стратегических задач и их достижения.
Критические факторы успеха (Critical Success Factors или CSFs) — факторы, которые обязательно должны реализовываться для успешности проекта, процесса, плана или услуги. Такие факторы формулируются для нескольких наиболее важных сфер интересов компании, называемых перспективами (проекциями) организации: заказчики/рынок, бизнес-процессы, персонал/инновации и финансы. Для измерения того, насколько успешно реализованы CSFs используется KPI.
Ключевой показатель производительности (Key Performance Indicator или KPI) — метрика, которая используется для управления процессом, услугой или деятельностью.
Портфель услуг- это полный набор услуг, которые предоставляются поставщиком услуг. Портфель услуг используется для управления всеми услугами на протяжении всего их жизненного цикла и включает три категории: 1) услуги в разработке (Service Pipeline) — услуги, находящиеся в стадии разработки; 2) каталог услуг для уже используемых или предлагаемых услуг и 3) услуг, выведенных из эксплуатации (retired Services).
Проектная документация услуги (Service Design Package или SDP) — документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла.
Пакет уровней услуг (Service Level Package или SLP) — это определенный уровень полезности и гарантии для отдельного пакета услуг.
Система управления знаниями по услугам (Service Knowledge Management System или SKMS) — набор инструментов и баз данных, которые используются для систематизации знаний и информации об услуге. Она сохраняет, управляет, обновляет и предоставляет всю информацию, которая необходима поставщику для управления услугой на всех этапах жизненного цикла.
Функции (Functions) — части организации, специализированные для того, чтобы выполнять определенные виды работ и отвечать за формирование соответствующих результатов. Функции обладают всеми необходимыми для выполнения работы возможностями и ресурсами. Возможности включают в себя собственные методы работы и накопленный опыт. Функции обеспечивают структурированность и стабильность организации.
Процесс — структурированный набор видов деятельности, спроектированный для достижения определенной цели. Процесс может включать в себя роли, ответственность, инструментарий и методы контроля, необходимые для формирования результатов.
Активность или деятельность (Activity) — набор действий, спроектированный с целью получения определенного результата. Активности обычно определяются как части процессов или планов, и документируются в процедурах.
Бизнес-единица (business unit или BU) — сегмент бизнеса, который имеет свои собственные метрики, планы, доходы и расходы. Каждая бизнес-единица владеет и управляет активами, которые использует для создания товаров и услуг с определенной ценностью.
Система управления конфигурацией (Configuration Management System или CMS) — набор инструментов и баз данных, которые используются поставщиком услуг для управления данными о конфигурациях.
Управление портфелем услуг (Service Portfolio Management или SPM) — процесс,
ответственный за управление Портфелем услуг. Управление портфелем услуг рассматривает Услуги в терминах предоставляемой ценности для бизнеса. Каталог услуг(Service Catalogue) — база данных или структурированный документ, содержащий информацию обо всех услугах в режиме промышленной эксплуатации, включая те услуги, которые доступны для развертывания.
Управление финансами(Financial Management) — функция и процессы, ответственные за управление бюджетом, учет и возмещение затрат поставщика услуг.
Управление мощностями (Capacity Management) — процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и IT-инфраструктуры требованиям согласованных Целевых показателей уровня услуги. Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование требований бизнеса.
Совокупная стоимость использования (Total Cost of Utilization или TCU) — полные затраты заказчика на использование услуги на протяжении всего ее жизненного цикла.
Учет затрат (Accounting) — процесс, отвечающий за идентификацию фактических затрат на предоставление ИТ-Услуги, их сопоставление с плановыми затратами, и управление отклонениями от Бюджета.
Соответствие (compliance) — обеспечение уверенности в соблюдении стандартов или набора руководящих документов, полноте и целостности чего-либо, использовании определенных установленных правил.
Моделирование переменных затрат (Variable Cost Dynamics или VCD) — техника, используемая для понимания, каким образом полные затраты подвергаются влиянию множества комплексных изменяющихся элементов (переменных), вносящих каждый свой вклад в предоставление услуг.
Требование к уровню услуг (Service Level Requirements или SLR) — требование заказчика к IT-услуге. SLR(ы) базируются на бизнес-целях и используются для переговоров и согласования Целевых показателей уровня услуги.
План обеспечения мощностей(Capacity Plan) используется для управления Ресурсами, необходимыми для предоставления IT-услуг. Этот план содержит сценарии для прогнозирования спроса со стороны бизнеса, и оценку затрат, необходимых для обеспечения согласованных Целевых показателей уровня услуги. Управление поставщиками (Supplier Management) — процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства.
Транзакция (Transaction) — дискретная функция, выполняемая ИТ-услугой. Например, перевод денег с одного банковского счета на другой. Одна Транзакция может содержать многочисленные добавления, удаления и изменения данных. при этом все они должны быть завершены успешно, в противном случае ни одна из них не должна быть выполнена (т.е. вся транзакция будет отменена).
Инсорсинг (Insourcing) — использование внутреннего поставщика услуг для управления ИТ-услугами.
Аутсорсинг (Outsourcing) — использование внешнего поставщика услуг для управления ИТ-услугами
Поставщик услуг прикладного ПО (Application Service Provider или ASP) — внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру.
Конфигурационная единица (Configuration Item или CI) — любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу.
Ключевой показатель производительности (Key Performance Indicator или KPI) — метрика, которая используется для управления процессом, услугой или деятельностью.
Управление уровнем услуг (Service Level Management или SLM) — процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. SLM ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLM отслеживает и отчитывается по Уровням услуг, выполняет регулярные обзоры для заказчиков.
План совершенствования услуг (Service Improvement plan) — формальный План для внедрения улучшений в процесс или услугу.
Обзор результатов внедрения (Post Implementation Review или PIR) — обзор, выполняемый после внедрения изменения или проекта. Он определяет успешность изменения или проекта и выявляет возможности для улучшения.
Соглашение операционного уровня (Operational Level Agreement или OLA) — cоглашение между поставщиком услуг и другой частью той же организации. OLA поддерживает поставщика услуг в
предоставлении услуг заказчикам. OLA определяет предоставляемые товары или
услуги и ответственность обеих сторон.
Управление мощностями (Capacity Management) — процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и инфраструктуры требованиям согласованных целевых показателей уровня услуги.
Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование бизнес-требований.
Мощность(Capacity) — максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги. Для некоторых типов конфигурационных единиц, мощность может быть выражена размером или объемом, например, жесткого диска.
Система управления мощностями (Capacity Management Information System или CMIS) — виртуальное хранилище для всех данных в рамках Управления мощностями, обычно имеет физически распределенную архитектуру.
Доступность (Availability) — способность конфигурационной единицы или услуги выполнять согласованную функцию, когда это требуется. Доступность определяется через надежность, сопровождаемость, обслуживаемость, производительность и безопасность.
Управление доступностью(Availability Management) — процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги. Управление доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным Целевым показателям уровня услуги в части Доступности.
План управления доступностью(Availability Plan) — план, обеспечивающий эффективное по затратам выполнение текущих и будущих требований доступности к услуге.
Надежность (Reliability) — мера того, как долго услуга, компонент или конфигурационная единица может выполнять согласованную функцию без прерывания.
Среднее время между инцидентами (Mean Time Between Service Incidents или MTBSI) — это среднее время от момента сбоя системы или услуги до следующего сбоя.
Среднее время между сбоями (Mean Time Between Failures или MTBF)— это среднее время, за которое конфигурационная единица или услуга может выполнять свои функции без перерыва. Измеряется от начала работы до момента следующего сбоя.
Среднее время восстановления услуги (Mean Time to Restore Service или MTRS) — среднее время, требуемое для восстановления конфигурационной единицы или услуги после сбоя. MTRS измеряется от момента сбоя конфигурационной единицы или услуги до момента полного восстановления и возврата к нормальной функциональности.
Критичная бизнес-функция (Vital Business Function или VBF) — функция в бизнес-процессе, критичная для успеха Бизнеса.
Сопровождаемость (Maintainability) — мера быстроты и эффективности восстановления нормальной работы конфигурационной единицы или услуги после сбоя.
Обслуживаемость (Serviceability) — способность поставщика третьей стороны выполнить условия договора. Этот договор будет включать в себя согласованные уровни надежности, сопровождаемости или доступности для конфигурационной единицы.
Ожидаемый простой услуги (Projected Service Outage или PSO) — документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов тестирования на согласованный Уровень услуг.
Управление непрерывностью услуг(IT Service Continuity Management или ITSCM) — процесс, ответственный за управление рисками, которые влияют на услуги. ITSCM
обеспечивает возможность поставщику услуг постоянно предоставлять минимально согласованный Уровень услуг, через снижение рисков до приемлемого уровня и Планирование восстановления услуг.
Управление непрерывностью бизнеса (Business Continuity Management или BCM) — бизнес-процесс, отвечающий за управление рисками, которые могут серьезно повлиять на бизнес. BCM защищает интересы ключевых заинтересованных сторон, репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя снижение рисков до приемлемого уровня и планирование способов восстановления бизнес-процессов в случае нарушения бизнеса. BCM устанавливает цели, охват и требования по отношению к Управлению непрерывности ИТ-услуг.
План обеспечения непрерывности услуг (IT Service Continuity Plan) — план, определяющий шаги, необходимые для восстановления одной или нескольких услуг.
План обеспечения непрерывности бизнеса (BusinessмContinuity Plan или BCP) — план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т.п.
Анализ влияния на бизнес (Business Impact Analysis или BIA) — деятельность в рамках процесса Управлении непрерывностью бизнеса, которая определяет критичные бизнес-функции и их зависимость от факторов окружения. Этими факторами могут быть поставщики, люди, другие бизнес-процессы, услуги и т.д.
Оценка рисков (Risk Assessment) — начальные шаги Управления рисками. Анализируется ценность активов для бизнеса, идентифицируются угрозы по отношению к этим активам, и оценивается уязвимость активов по отношению к этим угрозам.
Постепенное восстановление (Gradual Recovery) — способ восстановления, также известный как «холодное резервирование». Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем.
Промежуточное восстановление (Intermediate Recovery) — способ восстановления, также известный как «теплое резервирование». Предусматривается восстановление услуги в течение 24 — 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг.
Быстрое восстановление (Fast Recovery) — способ восстановления, также известный как «горячее резервирование». Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования.
Немедленное восстановление (Immediate recovery) — способ восстановления, также известный как «горячее резервирование». Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования.
Антикризисное управление (Crisis Management) — процесс, отвечающий за управление непрерывностью бизнеса в самом широком смысле. Команда антикризисного управления отвечает за стратегические вопросы, такие как управление взаимодействием со средствами массовой информации и доверием акционеров, а также принимает решение об инициации планов обеспечения непрерывности бизнеса.
Политика информационной безопасности (Security Policy) — система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей Управления информационной безопасностью.
Система управления информационной безопасностью (Information Security Management System или ISMS) — система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей управления информационной безопасностью.
Управление поставщиками (Supplier Management) — процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства.
Поставщик (Supplier) — третья сторона, ответственная за поставку товаров или услуг, необходимых для предоставления ИТ-услуг. Примеры поставщиков: вендоры программного и аппаратного обеспечения, сетевые телекоммуникационные провайдеры, а также аутсорсинговые организации.
База поставщиков и договоров (Supplier and Contract Database или SCD) — база данных или структурированный документ, используемый для управления договорами поставщиков на протяжении всего их жизненного цикла. SCD содержит ключевые атрибуты всех договоров с поставщиками.
Преобразование(Transition) — изменение в состоянии, соответствующее перемещению услуги или конфигурационной единицы из одной стадии жизненного цикла к следующей стадии.
Релиз (Release) — набор аппаратного обеспечения, программного обеспечения, документации, процессов или других компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в услугах. Содержание каждого релиза управляется, тестируется и развертывается как отдельная сущность.
Запрос на изменение (Request for Change или RFC) — формальное предложение на реализацию Изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате.
Тестирование (Test) — деятельность, которая верифицирует, что конфигурационная единица, услуга, процесс, и т.п., соответствует спецификации или согласованным требованиям.
Сборка(Build) — деятельность по компоновке нескольких и более конфигурационных единиц для формирования части услуги. Термин Сборка также используется в отношении релиза, который утвержден для распространения. Например, Сборка сервера или Сборка Ноутбука.
Развертывание(Deployment) — деятельность, отвечающая за перемещение нового или измененного оборудования, ПО, документации, процесса, и т.п., в среду промышленной эксплуатации.
Поддержка в начале эксплуатации (Early Life Support) — поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время Поддержки в начале эксплуатации поставщик услуг может пересматривать KPI, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами.
Среда (Environment) — подмножество ИТ-инфраструктуры, которое используется в различных целях.. Для сложных Сред есть возможность совместно использовать конфигурационные единицы, например Среды Тестовой и Промышленной эксплуатации могут использовать различные разделы на одном майнфрейме. Также используется в термине физической среды для обозначения помещения, кондиционирования, системы питания и т.п.
Среда промышленной эксплуатации (Live Environment) — управляемая среда, содержащая конфигурационные единицы в режиме промышленной эксплуатации, используемые для предоставления услуг.
Среда тестирования (Test Environment) — контролируемая среда, используемая для тестирования конфигурационных единиц, сборок, услуг, Процессов и т.п.
Среда сборки (Build Environment) — контролируемая среда, в которой собираются (компонуются) приложения, услуги и другие сборки перед их передачей в Среду тестирования или Среду промышленной эксплуатации.
Приемка(Acceptance) — формальное соглашение, определяющее, что услуга, процесс, План или другой результат завершен, является правильным, надежным и отвечает установленным требованиям. Приемке обычно предшествует оценка или тестирование, приемка часто обязательна для перехода к выполнению следующего этапа проекта или процесса.
Портфель заказчиков — база данных или структурированный документ, используемые для хранения информации обо всех Заказчиках поставщика услуг.
Портфель договоров — база данных или структурированный документ, используемый для управления договорами на оказание услуг или Соглашениями между поставщиками услуг и их заказчиками.
Пакет услуг (Service Package) — детализированное описание услуги, доступной для предоставления заказчикам.
Запись об изменении (Change Record) — запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного Запроса на изменение, даже если он впоследствии отклонен (отвергнут). Запись об изменении должна содержать информацию о конфигурационных единицах, которые затрагивает данное изменение. Записи об изменениях хранятся в Системе управления конфигурациями.
График изменений (Change Schedule) — документ, в котором перечислены все утвержденные изменения и их плановые сроки внедрения. Ожидаемый простой услуги (Projected Service Outage или PSO) — документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов испытаний на согласованный уровень услуг.
Комитет по изменениям(Change Advisory Board или CAB) — группа людей, консультирующих менеджера по изменениям при выполнении им оценки
соответствия, приоритезации и планирования изменений. Этот комитет обычно формируется из представителей всех заинтересованных сторон — поставщика услуг, бизнеса и третьих сторон, таких как прочие поставщики.
Комитет по срочным изменениям (Emergency Change Advisory Board или ECAB) -группа людей в составе Комитета по изменениям, которые принимают решения по Срочным изменениям с высоким влиянием. Необходимость участия в ECAB может быть выявлена непосредственно при созыве (организации) совещания и определяется исходя из сути Срочного изменения.
Управление активами и конфигурациями (Service Asset and Configuration Management или SACM) — процесс, ответственный за Управление конфигурациями и Управление активами.
Конфигурационная единица (Configuration Item или CI) — любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA).
Интерфейс поставщика услуг (Service Provider Interface или SPI) — интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами.
Библиотека эталонного ПО (Definitive Media Library (DML) — одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе правления конфигурациями. В релизе может быть использовано только программное обеспечение из DML.
Единица релиза (Release Unit) — компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя
программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей.
Пилот (Pilot) — ограниченное развертывание услуги, релиза или процесса в среде промышленной эксплуатации. Пилот используется для сокращения рисков и получения обратной связи, а также приемки от пользователей.
Базовое состояние (Baseline) — зафиксированное состояние, используемое как ориентир (контрольная точка).
Поддержка в начале эксплуатации (Early Life Support или ELP) — поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами.
Обходное решение (Workaround) — уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы. Обходные решения для проблем документируются в записях об известных ошибках. Обходные пути для инцидентов, которые не привязаны к записям о проблемах, документируются в записях об инцидентах.
Подтверждение(Validation) — деятельность, которая гарантирует, что новая или измененная услуга, процесс, план или другой результат отвечает нуждам бизнеса. Подтверждение гарантирует, что требования бизнеса удовлетворены, даже если они могли измениться по отношению к исходному результату проектирования.
Подтверждение и тестирование услуг (Service Validation and Testing) — процесс, ответственный за подтверждение и тестирование новой или измененной услуги. Подтверждение и тестирование услуг удостоверяется, что услуга соответствует ее спецификации проектирования и будет отвечать потребностям бизнеса.
Оценка (Evaluation) — процесс, ответственный за проведение оценки новой или изменяемой услуги для обеспечения управления рисками и помощи в принятии решения о продолжении проведения изменения.
Управление знаниями (Knowledge Management) — процесс, отвечающий за сбор, анализ, сохранение и предоставление знаний и информации в Организации. Первичная цель Управления знаниями — увеличение эффективности путем снижения необходимости в повторном поиске знаний. Данные-Информация-Знания-Мудрость (Data-to-Information-to-Knowledge-to-Wisdom или DIKW) — способ представления взаимосвязей между данными, информацией, знанием и мудростью. Концепция DIKW показывает, каким образом каждое из перечисленных понятий базируется на остальных.
Контроль операционного управления (IT Operations Control) — функция, отвечающая за мониторинг и контроль услуг и IT-инфраструктуры.
Операционное управление IT (IT Operations) — деятельности, выполняемые функцией Контроля операционного управления ИТ, в том числе консольное управление, планирование задач, резервное копирование, восстановление, печать и управление выводом.
Роль — набор ответственностей, деятельностей и полномочий, присвоенных сотруднику или команде. Роль определяется в процессе. Один сотрудник или команда может иметь (выполнять) много Ролей. Например, Роли Менеджера Конфигураций и Менеджера Изменений могут выполняться одним сотрудником.
Управление событиями (Event Management) — процесс,ответственный за управление событиями в течение жизненного цикла. Управление событиями одна из главных деятельностей операционного управления ИТ.
Событие (Event) — изменение состояния, которое имеет значение для управления конфигурационной единицей или услугой.
Активный мониторинг (Active Monitoring) — мониторинг конфигурационных единиц или услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга.
Пассивный мониторинг (Passive Moitoring) — мониторинг конфигурационной единицы, услуги или процесса, который основывается на предупреждениях или уведомлениях о текущем состоянии.
Управление инцидентами (Incident Management) — процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами — скорейшее восстановление услуги для пользователей.
Инцидент (Incident) — незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования.
Срочность (Urgency) — мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета.
Эскалация (Escalation) — деятельность, направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация.
Управление запросами на обслуживание (Request Fulfillment) — процесс, ответственный за управление жизненным циклом всех запросов на обслуживание.
Управление проблемами (Problem Management) — процесс, отвечающий за управление жизненным циклом всех проблем. Ключевыми целями Управления проблемами являются предотвращение инцидентов и минимизация влияния тех инцидентов, которые не могут быть предотвращены.
Проблема (Problem) — причина одного или нескольких инцидентов.
Диаграмма Ишикавы — методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма.
База известных ошибок (Known Error Database или KEDB) — база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами. База известных ошибок это часть Системы управления знаний по услугам (SKMS).
Управление доступом (Access Management) — процесс, отвечающий за допуск пользователей к использованию услуг, данных или других активов. Управление доступом помогает обеспечить конфиденциальность, целостность и доступность активов за счет того, что только авторизованные пользователи имеют возможность получить доступ или модифицировать активы.
Идентификатор (Identity) — уникальное наименование, используемое для идентификации пользователя, человека или роли. Идентификатор используется для предоставления прав пользователю, человеку или роли. Примерами идентификации могут быть имя пользователя Иванов Иван или Роль «Менеджер Изменений».
Непрерывное улучшение услуг (Continual Service Improvement или CSI) — постоянное улучшение услуг отвечает за управление улучшениями (совершенствованием) в процессах Управления услугами и предоставлении услуг. Производительность поставщика услуг постоянно измеряется, и разрабатываются меры по улучшению процессов, услуг и ИТ-инфраструктуры с целью увеличения эффективности, результативности и эффективности затрат.
Зафиксированное состояние (Benchmark) — состояние чего-либо, зафиксированное на определенный момент времени. Зафиксированное состояние может быть создано для конфигурациям, Процесса или любого другого набора данных.
Сравнение состояний (Benchmarking) — сравнение зафиксированного состояния с базовым состояние или с лучшей практикой. Термин сравнение состояний также используется в следующем смысле — создание серии зафиксированных состояний в течении определенного отрезка времени и сравнение полученных результатов для оценки прогресса или улучшения.
Система сбалансированных показателей (Balanced Scorecard) — инструмент управления, разработанный докторам Робертом Капланом (Гарвадская бизнес-школа, Harvard Business School) и Дэвидом Нортоном. Система сбалансированных показателей позволяет декомпозировать Стратегию до Ключевых показателей производительности (KPI). Соотнесение Производительности с KPI используется для демонстрации успешности исполнения Стратегии. Сбалансированный показатель состоит из 4-х главных блоков (областей, направлений), каждый из которых включает в себя небольшое количество KPI.
Заказчик(Customer) — это покупатель товаров или услуг. Заказчик для поставщика IT-услуг — это человек (группа людей), который заключает соглашения с поставщиком на предоставление IT-услуг и отвечает за то, чтобы предоставленные услуги были оплачены.
Поставщик услуг(Service provider) — это организация, поставляющая услуги одному или нескольким внутренним или внешним заказчикам.
Пользователь — это сотрудник организации, использующий IT-услугу для выполнения повседневной работы.
IT-услуга (сервис) — способ предоставления ценности заказчикам через содействие им в получении результатов на выходе, которых заказчики хотят достичь без владения специфическими затратами и рисками определённых потребностей. Зачастую определяется как «что делает продукт/сервис».
Полезность услуги — функциональность IT-услуги с точки зрения заказчика.
Гарантия — обещание или гарантия того, что продукт или услуга будет соответствовать согласованным требованиям.
Гарантия качества услуги — уверенность в том, что IT-сервис будет соответствовать согласованным требованиям. Может быть в виде формального соглашения, такого как SLA или договор, либо как маркетинговое сообщение или представление торговой марки.
Производительность (Performance) — мера того, что достигнуто или выработано системой, человеком, командой, процессом, или ИТ-услугой.
Ограничение — это запрет или невозможность выполнения каких-то действий.
Организация — это определенная форма сотрудничества людей.
Миссия — это короткое и четкое описание задач, стоящих перед организацией, и идеалов, в которые она верит.
Стратегические задачи (objectives) — это более подробное описание того, что хочет достичь организация в долгосрочной перспективе.
Политика организации (policy) — это совокупность всех решений и мер, принятых организацией для постановки стратегических задач и их достижения.
Критические факторы успеха (Critical Success Factors или CSFs) — факторы, которые обязательно должны реализовываться для успешности проекта, процесса, плана или услуги. Такие факторы формулируются для нескольких наиболее важных сфер интересов компании, называемых перспективами (проекциями) организации: заказчики/рынок, бизнес-процессы, персонал/инновации и финансы. Для измерения того, насколько успешно реализованы CSFs используется KPI.
Ключевой показатель производительности (Key Performance Indicator или KPI) — метрика, которая используется для управления процессом, услугой или деятельностью.
Портфель услуг- это полный набор услуг, которые предоставляются поставщиком услуг. Портфель услуг используется для управления всеми услугами на протяжении всего их жизненного цикла и включает три категории: 1) услуги в разработке (Service Pipeline) — услуги, находящиеся в стадии разработки; 2) каталог услуг для уже используемых или предлагаемых услуг и 3) услуг, выведенных из эксплуатации (retired Services).
Проектная документация услуги (Service Design Package или SDP) — документы, определяющие все аспекты услуги и требования к ней на каждой стадии жизненного цикла.
Пакет уровней услуг (Service Level Package или SLP) — это определенный уровень полезности и гарантии для отдельного пакета услуг.
Система управления знаниями по услугам (Service Knowledge Management System или SKMS) — набор инструментов и баз данных, которые используются для систематизации знаний и информации об услуге. Она сохраняет, управляет, обновляет и предоставляет всю информацию, которая необходима поставщику для управления услугой на всех этапах жизненного цикла.
Функции (Functions) — части организации, специализированные для того, чтобы выполнять определенные виды работ и отвечать за формирование соответствующих результатов. Функции обладают всеми необходимыми для выполнения работы возможностями и ресурсами. Возможности включают в себя собственные методы работы и накопленный опыт. Функции обеспечивают структурированность и стабильность организации.
Процесс — структурированный набор видов деятельности, спроектированный для достижения определенной цели. Процесс может включать в себя роли, ответственность, инструментарий и методы контроля, необходимые для формирования результатов.
Активность или деятельность (Activity) — набор действий, спроектированный с целью получения определенного результата. Активности обычно определяются как части процессов или планов, и документируются в процедурах.
Бизнес-единица (business unit или BU) — сегмент бизнеса, который имеет свои собственные метрики, планы, доходы и расходы. Каждая бизнес-единица владеет и управляет активами, которые использует для создания товаров и услуг с определенной ценностью.
Система управления конфигурацией (Configuration Management System или CMS) — набор инструментов и баз данных, которые используются поставщиком услуг для управления данными о конфигурациях.
Управление портфелем услуг (Service Portfolio Management или SPM) — процесс,
ответственный за управление Портфелем услуг. Управление портфелем услуг рассматривает Услуги в терминах предоставляемой ценности для бизнеса. Каталог услуг(Service Catalogue) — база данных или структурированный документ, содержащий информацию обо всех услугах в режиме промышленной эксплуатации, включая те услуги, которые доступны для развертывания.
Управление финансами(Financial Management) — функция и процессы, ответственные за управление бюджетом, учет и возмещение затрат поставщика услуг.
Управление мощностями (Capacity Management) — процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и IT-инфраструктуры требованиям согласованных Целевых показателей уровня услуги. Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование требований бизнеса.
Совокупная стоимость использования (Total Cost of Utilization или TCU) — полные затраты заказчика на использование услуги на протяжении всего ее жизненного цикла.
Учет затрат (Accounting) — процесс, отвечающий за идентификацию фактических затрат на предоставление ИТ-Услуги, их сопоставление с плановыми затратами, и управление отклонениями от Бюджета.
Соответствие (compliance) — обеспечение уверенности в соблюдении стандартов или набора руководящих документов, полноте и целостности чего-либо, использовании определенных установленных правил.
Моделирование переменных затрат (Variable Cost Dynamics или VCD) — техника, используемая для понимания, каким образом полные затраты подвергаются влиянию множества комплексных изменяющихся элементов (переменных), вносящих каждый свой вклад в предоставление услуг.
Требование к уровню услуг (Service Level Requirements или SLR) — требование заказчика к IT-услуге. SLR(ы) базируются на бизнес-целях и используются для переговоров и согласования Целевых показателей уровня услуги.
План обеспечения мощностей(Capacity Plan) используется для управления Ресурсами, необходимыми для предоставления IT-услуг. Этот план содержит сценарии для прогнозирования спроса со стороны бизнеса, и оценку затрат, необходимых для обеспечения согласованных Целевых показателей уровня услуги. Управление поставщиками (Supplier Management) — процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства.
Транзакция (Transaction) — дискретная функция, выполняемая ИТ-услугой. Например, перевод денег с одного банковского счета на другой. Одна Транзакция может содержать многочисленные добавления, удаления и изменения данных. при этом все они должны быть завершены успешно, в противном случае ни одна из них не должна быть выполнена (т.е. вся транзакция будет отменена).
Инсорсинг (Insourcing) — использование внутреннего поставщика услуг для управления ИТ-услугами.
Аутсорсинг (Outsourcing) — использование внешнего поставщика услуг для управления ИТ-услугами
Поставщик услуг прикладного ПО (Application Service Provider или ASP) — внешний поставщик услуг, который предоставляет услуги с использованием приложений, развернутых на мощностях провайдера. Пользователи получают доступ к приложениям посредством сетевого подключения к провайдеру.
Конфигурационная единица (Configuration Item или CI) — любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу.
Ключевой показатель производительности (Key Performance Indicator или KPI) — метрика, которая используется для управления процессом, услугой или деятельностью.
Управление уровнем услуг (Service Level Management или SLM) — процесс, ответственный за обсуждение Соглашений об уровне услуг, и гарантирующий их выполнение. SLM ответственен за то, что процессы Управления услугами, соглашения операционного уровня и внешние договоры будут соответствовать согласованным целевым показателям уровня услуги. SLM отслеживает и отчитывается по Уровням услуг, выполняет регулярные обзоры для заказчиков.
План совершенствования услуг (Service Improvement plan) — формальный План для внедрения улучшений в процесс или услугу.
Обзор результатов внедрения (Post Implementation Review или PIR) — обзор, выполняемый после внедрения изменения или проекта. Он определяет успешность изменения или проекта и выявляет возможности для улучшения.
Соглашение операционного уровня (Operational Level Agreement или OLA) — cоглашение между поставщиком услуг и другой частью той же организации. OLA поддерживает поставщика услуг в
предоставлении услуг заказчикам. OLA определяет предоставляемые товары или
услуги и ответственность обеих сторон.
Управление мощностями (Capacity Management) — процесс, отвечающий за своевременное и эффективное по затратам соответствие мощности услуг и инфраструктуры требованиям согласованных целевых показателей уровня услуги.
Управление мощностями принимает во внимание все ресурсы, необходимые для предоставления услуг, а также производит краткосрочное, среднесрочное и долгосрочное планирование бизнес-требований.
Мощность(Capacity) — максимальная пропускная способность, которую может обеспечить конфигурационная единица или услуга в рамках согласованных целевых показателей уровня услуги. Для некоторых типов конфигурационных единиц, мощность может быть выражена размером или объемом, например, жесткого диска.
Система управления мощностями (Capacity Management Information System или CMIS) — виртуальное хранилище для всех данных в рамках Управления мощностями, обычно имеет физически распределенную архитектуру.
Доступность (Availability) — способность конфигурационной единицы или услуги выполнять согласованную функцию, когда это требуется. Доступность определяется через надежность, сопровождаемость, обслуживаемость, производительность и безопасность.
Управление доступностью(Availability Management) — процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги. Управление доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным Целевым показателям уровня услуги в части Доступности.
План управления доступностью(Availability Plan) — план, обеспечивающий эффективное по затратам выполнение текущих и будущих требований доступности к услуге.
Надежность (Reliability) — мера того, как долго услуга, компонент или конфигурационная единица может выполнять согласованную функцию без прерывания.
Среднее время между инцидентами (Mean Time Between Service Incidents или MTBSI) — это среднее время от момента сбоя системы или услуги до следующего сбоя.
Среднее время между сбоями (Mean Time Between Failures или MTBF)— это среднее время, за которое конфигурационная единица или услуга может выполнять свои функции без перерыва. Измеряется от начала работы до момента следующего сбоя.
Среднее время восстановления услуги (Mean Time to Restore Service или MTRS) — среднее время, требуемое для восстановления конфигурационной единицы или услуги после сбоя. MTRS измеряется от момента сбоя конфигурационной единицы или услуги до момента полного восстановления и возврата к нормальной функциональности.
Критичная бизнес-функция (Vital Business Function или VBF) — функция в бизнес-процессе, критичная для успеха Бизнеса.
Сопровождаемость (Maintainability) — мера быстроты и эффективности восстановления нормальной работы конфигурационной единицы или услуги после сбоя.
Обслуживаемость (Serviceability) — способность поставщика третьей стороны выполнить условия договора. Этот договор будет включать в себя согласованные уровни надежности, сопровождаемости или доступности для конфигурационной единицы.
Ожидаемый простой услуги (Projected Service Outage или PSO) — документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов тестирования на согласованный Уровень услуг.
Управление непрерывностью услуг(IT Service Continuity Management или ITSCM) — процесс, ответственный за управление рисками, которые влияют на услуги. ITSCM
обеспечивает возможность поставщику услуг постоянно предоставлять минимально согласованный Уровень услуг, через снижение рисков до приемлемого уровня и Планирование восстановления услуг.
Управление непрерывностью бизнеса (Business Continuity Management или BCM) — бизнес-процесс, отвечающий за управление рисками, которые могут серьезно повлиять на бизнес. BCM защищает интересы ключевых заинтересованных сторон, репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя снижение рисков до приемлемого уровня и планирование способов восстановления бизнес-процессов в случае нарушения бизнеса. BCM устанавливает цели, охват и требования по отношению к Управлению непрерывности ИТ-услуг.
План обеспечения непрерывности услуг (IT Service Continuity Plan) — план, определяющий шаги, необходимые для восстановления одной или нескольких услуг.
План обеспечения непрерывности бизнеса (BusinessмContinuity Plan или BCP) — план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т.п.
Анализ влияния на бизнес (Business Impact Analysis или BIA) — деятельность в рамках процесса Управлении непрерывностью бизнеса, которая определяет критичные бизнес-функции и их зависимость от факторов окружения. Этими факторами могут быть поставщики, люди, другие бизнес-процессы, услуги и т.д.
Оценка рисков (Risk Assessment) — начальные шаги Управления рисками. Анализируется ценность активов для бизнеса, идентифицируются угрозы по отношению к этим активам, и оценивается уязвимость активов по отношению к этим угрозам.
Постепенное восстановление (Gradual Recovery) — способ восстановления, также известный как «холодное резервирование». Предусматривается восстановление услуги в течение более чем 72 часов. При постепенном восстановлении обычно задействован мобильный или стационарный резервный центр, оснащенный элементами жизнеобеспечения и сетевой разводкой, без компьютерных систем.
Промежуточное восстановление (Intermediate Recovery) — способ восстановления, также известный как «теплое резервирование». Предусматривается восстановление услуги в течение 24 — 72 часов. При промежуточном восстановлении обычно используется общий мобильный или стационарный резервный центр, оснащенный компьютерными системами и сетевыми компонентами. Конфигурирование аппаратного и программного обеспечения, а также восстановление данных выполняются в рамках Плана обеспечения непрерывности услуг.
Быстрое восстановление (Fast Recovery) — способ восстановления, также известный как «горячее резервирование». Предусматривается восстановление услуги за короткий промежуток времени, обычно менее 24 часов. При быстром восстановлении обычно используется выделенный стационарный резервный центр с компьютерными системами и ПО, сконфигурированными для работы услуг. Немедленное восстановление может занимать до 24 часов, если требуется восстановление данных резервного копирования.
Немедленное восстановление (Immediate recovery) — способ восстановления, также известный как «горячее резервирование». Предусматривается восстановление услуги без прерывания услуги. Немедленное восстановление обычно использует технологии зеркалирования, балансировки загрузки и разделения площадок установки оборудования.
Антикризисное управление (Crisis Management) — процесс, отвечающий за управление непрерывностью бизнеса в самом широком смысле. Команда антикризисного управления отвечает за стратегические вопросы, такие как управление взаимодействием со средствами массовой информации и доверием акционеров, а также принимает решение об инициации планов обеспечения непрерывности бизнеса.
Политика информационной безопасности (Security Policy) — система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей Управления информационной безопасностью.
Система управления информационной безопасностью (Information Security Management System или ISMS) — система политик, процессов, стандартов, руководящих документов и средств, которые обеспечивают организации достижение целей управления информационной безопасностью.
Управление поставщиками (Supplier Management) — процесс, ответственный за обеспечение того, что договоры с поставщиками соответствуют требованиям бизнеса, и все поставщики выполняют свои контрактные обязательства.
Поставщик (Supplier) — третья сторона, ответственная за поставку товаров или услуг, необходимых для предоставления ИТ-услуг. Примеры поставщиков: вендоры программного и аппаратного обеспечения, сетевые телекоммуникационные провайдеры, а также аутсорсинговые организации.
База поставщиков и договоров (Supplier and Contract Database или SCD) — база данных или структурированный документ, используемый для управления договорами поставщиков на протяжении всего их жизненного цикла. SCD содержит ключевые атрибуты всех договоров с поставщиками.
Преобразование(Transition) — изменение в состоянии, соответствующее перемещению услуги или конфигурационной единицы из одной стадии жизненного цикла к следующей стадии.
Релиз (Release) — набор аппаратного обеспечения, программного обеспечения, документации, процессов или других компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в услугах. Содержание каждого релиза управляется, тестируется и развертывается как отдельная сущность.
Запрос на изменение (Request for Change или RFC) — формальное предложение на реализацию Изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате.
Тестирование (Test) — деятельность, которая верифицирует, что конфигурационная единица, услуга, процесс, и т.п., соответствует спецификации или согласованным требованиям.
Сборка(Build) — деятельность по компоновке нескольких и более конфигурационных единиц для формирования части услуги. Термин Сборка также используется в отношении релиза, который утвержден для распространения. Например, Сборка сервера или Сборка Ноутбука.
Развертывание(Deployment) — деятельность, отвечающая за перемещение нового или измененного оборудования, ПО, документации, процесса, и т.п., в среду промышленной эксплуатации.
Поддержка в начале эксплуатации (Early Life Support) — поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время Поддержки в начале эксплуатации поставщик услуг может пересматривать KPI, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами.
Среда (Environment) — подмножество ИТ-инфраструктуры, которое используется в различных целях.. Для сложных Сред есть возможность совместно использовать конфигурационные единицы, например Среды Тестовой и Промышленной эксплуатации могут использовать различные разделы на одном майнфрейме. Также используется в термине физической среды для обозначения помещения, кондиционирования, системы питания и т.п.
Среда промышленной эксплуатации (Live Environment) — управляемая среда, содержащая конфигурационные единицы в режиме промышленной эксплуатации, используемые для предоставления услуг.
Среда тестирования (Test Environment) — контролируемая среда, используемая для тестирования конфигурационных единиц, сборок, услуг, Процессов и т.п.
Среда сборки (Build Environment) — контролируемая среда, в которой собираются (компонуются) приложения, услуги и другие сборки перед их передачей в Среду тестирования или Среду промышленной эксплуатации.
Приемка(Acceptance) — формальное соглашение, определяющее, что услуга, процесс, План или другой результат завершен, является правильным, надежным и отвечает установленным требованиям. Приемке обычно предшествует оценка или тестирование, приемка часто обязательна для перехода к выполнению следующего этапа проекта или процесса.
Портфель заказчиков — база данных или структурированный документ, используемые для хранения информации обо всех Заказчиках поставщика услуг.
Портфель договоров — база данных или структурированный документ, используемый для управления договорами на оказание услуг или Соглашениями между поставщиками услуг и их заказчиками.
Пакет услуг (Service Package) — детализированное описание услуги, доступной для предоставления заказчикам.
Запись об изменении (Change Record) — запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного Запроса на изменение, даже если он впоследствии отклонен (отвергнут). Запись об изменении должна содержать информацию о конфигурационных единицах, которые затрагивает данное изменение. Записи об изменениях хранятся в Системе управления конфигурациями.
График изменений (Change Schedule) — документ, в котором перечислены все утвержденные изменения и их плановые сроки внедрения. Ожидаемый простой услуги (Projected Service Outage или PSO) — документ, определяющий влияние спланированных изменений, деятельности по обслуживанию и планов испытаний на согласованный уровень услуг.
Комитет по изменениям(Change Advisory Board или CAB) — группа людей, консультирующих менеджера по изменениям при выполнении им оценки
соответствия, приоритезации и планирования изменений. Этот комитет обычно формируется из представителей всех заинтересованных сторон — поставщика услуг, бизнеса и третьих сторон, таких как прочие поставщики.
Комитет по срочным изменениям (Emergency Change Advisory Board или ECAB) -группа людей в составе Комитета по изменениям, которые принимают решения по Срочным изменениям с высоким влиянием. Необходимость участия в ECAB может быть выявлена непосредственно при созыве (организации) совещания и определяется исходя из сути Срочного изменения.
Управление активами и конфигурациями (Service Asset and Configuration Management или SACM) — процесс, ответственный за Управление конфигурациями и Управление активами.
Конфигурационная единица (Configuration Item или CI) — любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами КЕ являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA).
Интерфейс поставщика услуг (Service Provider Interface или SPI) — интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами.
Библиотека эталонного ПО (Definitive Media Library (DML) — одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. DML также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. DML является логически единым хранилищем, даже если физически места хранения распределены. Все программное обеспечение в DML находится под контролем Управления изменениями и Управления релизами, должно быть зарегистрировано в Системе правления конфигурациями. В релизе может быть использовано только программное обеспечение из DML.
Единица релиза (Release Unit) — компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя
программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей.
Пилот (Pilot) — ограниченное развертывание услуги, релиза или процесса в среде промышленной эксплуатации. Пилот используется для сокращения рисков и получения обратной связи, а также приемки от пользователей.
Базовое состояние (Baseline) — зафиксированное состояние, используемое как ориентир (контрольная точка).
Поддержка в начале эксплуатации (Early Life Support или ELP) — поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами.
Обходное решение (Workaround) — уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы. Обходные решения для проблем документируются в записях об известных ошибках. Обходные пути для инцидентов, которые не привязаны к записям о проблемах, документируются в записях об инцидентах.
Подтверждение(Validation) — деятельность, которая гарантирует, что новая или измененная услуга, процесс, план или другой результат отвечает нуждам бизнеса. Подтверждение гарантирует, что требования бизнеса удовлетворены, даже если они могли измениться по отношению к исходному результату проектирования.
Подтверждение и тестирование услуг (Service Validation and Testing) — процесс, ответственный за подтверждение и тестирование новой или измененной услуги. Подтверждение и тестирование услуг удостоверяется, что услуга соответствует ее спецификации проектирования и будет отвечать потребностям бизнеса.
Оценка (Evaluation) — процесс, ответственный за проведение оценки новой или изменяемой услуги для обеспечения управления рисками и помощи в принятии решения о продолжении проведения изменения.
Управление знаниями (Knowledge Management) — процесс, отвечающий за сбор, анализ, сохранение и предоставление знаний и информации в Организации. Первичная цель Управления знаниями — увеличение эффективности путем снижения необходимости в повторном поиске знаний. Данные-Информация-Знания-Мудрость (Data-to-Information-to-Knowledge-to-Wisdom или DIKW) — способ представления взаимосвязей между данными, информацией, знанием и мудростью. Концепция DIKW показывает, каким образом каждое из перечисленных понятий базируется на остальных.
Контроль операционного управления (IT Operations Control) — функция, отвечающая за мониторинг и контроль услуг и IT-инфраструктуры.
Операционное управление IT (IT Operations) — деятельности, выполняемые функцией Контроля операционного управления ИТ, в том числе консольное управление, планирование задач, резервное копирование, восстановление, печать и управление выводом.
Роль — набор ответственностей, деятельностей и полномочий, присвоенных сотруднику или команде. Роль определяется в процессе. Один сотрудник или команда может иметь (выполнять) много Ролей. Например, Роли Менеджера Конфигураций и Менеджера Изменений могут выполняться одним сотрудником.
Управление событиями (Event Management) — процесс,ответственный за управление событиями в течение жизненного цикла. Управление событиями одна из главных деятельностей операционного управления ИТ.
Событие (Event) — изменение состояния, которое имеет значение для управления конфигурационной единицей или услугой.
Активный мониторинг (Active Monitoring) — мониторинг конфигурационных единиц или услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга.
Пассивный мониторинг (Passive Moitoring) — мониторинг конфигурационной единицы, услуги или процесса, который основывается на предупреждениях или уведомлениях о текущем состоянии.
Управление инцидентами (Incident Management) — процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами — скорейшее восстановление услуги для пользователей.
Инцидент (Incident) — незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования.
Срочность (Urgency) — мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета.
Эскалация (Escalation) — деятельность, направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и Иерархическая эскалация.
Управление запросами на обслуживание (Request Fulfillment) — процесс, ответственный за управление жизненным циклом всех запросов на обслуживание.
Управление проблемами (Problem Management) — процесс, отвечающий за управление жизненным циклом всех проблем. Ключевыми целями Управления проблемами являются предотвращение инцидентов и минимизация влияния тех инцидентов, которые не могут быть предотвращены.
Проблема (Problem) — причина одного или нескольких инцидентов.
Диаграмма Ишикавы — методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма.
База известных ошибок (Known Error Database или KEDB) — база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами. База известных ошибок это часть Системы управления знаний по услугам (SKMS).
Управление доступом (Access Management) — процесс, отвечающий за допуск пользователей к использованию услуг, данных или других активов. Управление доступом помогает обеспечить конфиденциальность, целостность и доступность активов за счет того, что только авторизованные пользователи имеют возможность получить доступ или модифицировать активы.
Идентификатор (Identity) — уникальное наименование, используемое для идентификации пользователя, человека или роли. Идентификатор используется для предоставления прав пользователю, человеку или роли. Примерами идентификации могут быть имя пользователя Иванов Иван или Роль «Менеджер Изменений».
Непрерывное улучшение услуг (Continual Service Improvement или CSI) — постоянное улучшение услуг отвечает за управление улучшениями (совершенствованием) в процессах Управления услугами и предоставлении услуг. Производительность поставщика услуг постоянно измеряется, и разрабатываются меры по улучшению процессов, услуг и ИТ-инфраструктуры с целью увеличения эффективности, результативности и эффективности затрат.
Зафиксированное состояние (Benchmark) — состояние чего-либо, зафиксированное на определенный момент времени. Зафиксированное состояние может быть создано для конфигурациям, Процесса или любого другого набора данных.
Сравнение состояний (Benchmarking) — сравнение зафиксированного состояния с базовым состояние или с лучшей практикой. Термин сравнение состояний также используется в следующем смысле — создание серии зафиксированных состояний в течении определенного отрезка времени и сравнение полученных результатов для оценки прогресса или улучшения.
Система сбалансированных показателей (Balanced Scorecard) — инструмент управления, разработанный докторам Робертом Капланом (Гарвадская бизнес-школа, Harvard Business School) и Дэвидом Нортоном. Система сбалансированных показателей позволяет декомпозировать Стратегию до Ключевых показателей производительности (KPI). Соотнесение Производительности с KPI используется для демонстрации успешности исполнения Стратегии. Сбалансированный показатель состоит из 4-х главных блоков (областей, направлений), каждый из которых включает в себя небольшое количество KPI.
17.04.2020
Инвестиции в ИТ в контексте бизнес-стратегии - главное
 |
| Связь между портфелем прикладных систем и процессом бюджетирования |
 |
| Синхронизация портфеля инвестиций в ИТ и бизнес-стратегии |
18.06.2019
EJB-фасады для бинов Spring
Возникла идея сделать @Remote EJB с инъекциями из бинов на Spring. Было бы достаточно удобно - это избавляет от всякой промежуточной интеграции, цепляй удалённый бин и выполняй любую логику из Spring.
05.06.2019
Управление экземпляром через WLST и другие полезные вещи для CI/CD
WLST, ps-скрипты и другие вещи, которые могут оказаться полезными при реализации CI через Atlassian Bamboo на серверах Microsoft.
17.04.2019
Информация о сессиях приложения на Weblogic
Наиболее достоверную информацию о сессия приложения можно получить непосредственно из консоли WLST
23.07.2018
Анмаршаллинг XML в класс при помощи JAXB
public JAXBElement processFile(File file){
Class clazz = SomePojo.class;
JAXBElement jaxbElement = null;
try {
JAXBContext jaxbContext = JAXBContext.newInstance(clazz);
Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
jaxbElement = unmarshaller.unmarshal(new StreamSource(file), clazz);
} catch (Exception e) {
e.printStackTrace();
}
return jaxbElement;
}
27.04.2017
Список полей через java reflection
private List getElementMetadata(Class clazz){ List<Field> list = new ArrayList<>(); if (clazz.getSuperclass() != null && !clazz.getSuperclass().equals(Object.class)) { List<Field> sublist = getElementMetadata(clazz.getSuperclass()); for(Field field : sublist){ list.add(field); } } Field fields[] = clazz.getDeclaredFields(); for(Field field : fields){ list.add(field); } return list; }
05.12.2016
Установка и настройка Wildfly 10 под Debian 7
Прошел интересный квест по установке Wildfly 10 на Debian 7 с последующим созданием Data Source к базе Oracle 11g. Поехали.
0. Скрипт установки.
- создаем каталог $WILDFLY_HOME/modules/system/layers/base/com/oracle/ojdbc6/main/ (того, что подчеркнуто, в системе не было)
- заливаем в main собственно драйвер ojdbc6.jar и там же создаем файл module.xml следующего содержания:
2. Регистрируем драйвер:
3. Конфигурация датасорса в standalone.xml после выполнения всех операций:
0. Скрипт установки.
#!/bin/bash
WILDFLY_VERSION=10.0.0.Final
WILDFLY_FILENAME=wildfly-$WILDFLY_VERSION
WILDFLY_ARCHIVE_NAME=$WILDFLY_FILENAME.tar.gz
WILDFLY_DOWNLOAD_ADDRESS=http://download.jboss.org/wildfly/$WILDFLY_VERSION/$WILDFLY_ARCHIVE_NAME
INSTALL_DIR=/opt
WILDFLY_FULL_DIR=$INSTALL_DIR/$WILDFLY_FILENAME
WILDFLY_DIR=$INSTALL_DIR/wildfly
WILDFLY_USER="wildfly"
WILDFLY_SERVICE="wildfly"
WILDFLY_MODE="standalone"
WILDFLY_STARTUP_TIMEOUT=240
WILDFLY_SHUTDOWN_TIMEOUT=30
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root."
exit 1
fi
echo "Downloading: $WILDFLY_DOWNLOAD_ADDRESS..."
[ -e "$WILDFLY_ARCHIVE_NAME" ] && echo 'Wildfly archive already exists.'
if [ ! -e "$WILDFLY_ARCHIVE_NAME" ]; then
wget -q $WILDFLY_DOWNLOAD_ADDRESS
if [ $? -ne 0 ]; then
echo "Not possible to download Wildfly."
exit 1
fi
fi
echo "Cleaning up..."
rm -f "$WILDFLY_DIR"
rm -rf "$WILDFLY_FULL_DIR"
rm -rf "/var/run/$WILDFLY_SERVICE/"
rm -f "/etc/init.d/$WILDFLY_SERVICE"
echo "Installation..."
mkdir $WILDFLY_FULL_DIR
tar -xzf $WILDFLY_ARCHIVE_NAME -C $INSTALL_DIR
ln -s $WILDFLY_FULL_DIR/ $WILDFLY_DIR
useradd -s /sbin/nologin $WILDFLY_USER
chown -R $WILDFLY_USER:$WILDFLY_USER $WILDFLY_DIR
chown -R $WILDFLY_USER:$WILDFLY_USER $WILDFLY_DIR/
#mkdir -p /var/log/$WILDFLY_SERVICE
echo "Registrating Wildfly as service..."
# if should use systemd
if [ -x /bin/systemctl ]; then
# Script from $WILDFLY_DIR/docs/contrib/scripts/systemd/launch.sh didn't work for me
cat > $WILDFLY_DIR/bin/launch.sh << "EOF"
#!/bin/sh
if [ "x$WILDFLY_HOME" = "x" ]; then
WILDFLY_HOME="/opt/wildfly"
fi
if [ "x$1" = "xdomain" ]; then
echo 'Starting Wildfly in domain mode.'
$WILDFLY_HOME/bin/domain.sh -c $2 -b $3
#>> /var/log/$WILDFLY_SERVICE/server-`date +%Y-%m-%d`.log
else
echo 'Starting Wildfly in standalone mode.'
$WILDFLY_HOME/bin/standalone.sh -c $2 -b $3
#>> /var/log/$WILDFLY_SERVICE/server-`date +%Y-%m-%d`.log
fi
EOF
# $WILDFLY_HOME is not visible here
sed -i -e 's,WILDFLY_HOME=.*,WILDFLY_HOME='$WILDFLY_DIR',g' $WILDFLY_DIR/bin/launch.sh
#sed -i -e 's,$WILDFLY_SERVICE,'$WILDFLY_SERVICE',g' $WILDFLY_DIR/bin/launch.sh
chmod +x $WILDFLY_DIR/bin/launch.sh
cp $WILDFLY_DIR/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/$WILDFLY_SERVICE.service
WILDFLY_SERVICE_CONF=/etc/default/$WILDFLY_SERVICE
# To install multiple instances of Wildfly replace all hardcoding in systemd file
sed -i -e 's,EnvironmentFile=.*,EnvironmentFile='$WILDFLY_SERVICE_CONF',g' /etc/systemd/system/$WILDFLY_SERVICE.service
sed -i -e 's,User=.*,User='$WILDFLY_USER',g' /etc/systemd/system/$WILDFLY_SERVICE.service
sed -i -e 's,PIDFile=.*,PIDFile=/var/run/wildfly/'$WILDFLY_SERVICE'.pid,g' /etc/systemd/system/$WILDFLY_SERVICE.service
sed -i -e 's,ExecStart=.*,ExecStart='$WILDFLY_DIR'/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND,g' /etc/systemd/system/$WILDFLY_SERVICE.service
systemctl daemon-reload
#systemctl enable $WILDFLY_SERVICE.service
fi
# if non-systemd Debian-like distribution
if [ ! -x /bin/systemctl -a -r /lib/lsb/init-functions ]; then
cp $WILDFLY_DIR/docs/contrib/scripts/init.d/wildfly-init-debian.sh /etc/init.d/$WILDFLY_SERVICE
sed -i -e 's,NAME=wildfly,NAME='$WILDFLY_SERVICE',g' /etc/init.d/$WILDFLY_SERVICE
WILDFLY_SERVICE_CONF=/etc/default/$WILDFLY_SERVICE
fi
# if non-systemd RHEL-like distribution
if [ ! -x /bin/systemctl -a -r /etc/init.d/functions ]; then
cp $WILDFLY_DIR/docs/contrib/scripts/init.d/wildfly-init-redhat.sh /etc/init.d/$WILDFLY_SERVICE
WILDFLY_SERVICE_CONF=/etc/default/wildfly.conf
chmod 755 /etc/init.d/$WILDFLY_SERVICE
fi
# if neither Debian nor RHEL like distribution
if [ ! -x /bin/systemctl -a ! -r /lib/lsb/init-functions -a ! -r /etc/init.d/functions ]; then
cat > /etc/init.d/$WILDFLY_SERVICE << "EOF"
#!/bin/sh
### BEGIN INIT INFO
# Provides: ${WILDFLY_SERVICE}
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/Stop ${WILDFLY_FILENAME}
### END INIT INFO
WILDFLY_USER=${WILDFLY_USER}
WILDFLY_DIR=${WILDFLY_DIR}
case "$1" in
start)
echo "Starting ${WILDFLY_FILENAME}..."
start-stop-daemon --start --background --chuid $WILDFLY_USER --exec $WILDFLY_DIR/bin/standalone.sh
exit $?
;;
stop)
echo "Stopping ${WILDFLY_FILENAME}..."
start-stop-daemon --start --quiet --background --chuid $WILDFLY_USER --exec $WILDFLY_DIR/bin/jboss-cli.sh -- --connect command=:shutdown
exit $?
;;
log)
echo "Showing server.log..."
tail -500f $WILDFLY_DIR/standalone/log/server.log
;;
*)
echo "Usage: /etc/init.d/wildfly {start|stop}"
exit 1
;;
esac
exit 0
EOF
sed -i -e 's,${WILDFLY_USER},'$WILDFLY_USER',g; s,${WILDFLY_FILENAME},'$WILDFLY_FILENAME',g; s,${WILDFLY_SERVICE},'$WILDFLY_SERVICE',g; s,${WILDFLY_DIR},'$WILDFLY_DIR',g' /etc/init.d/$WILDFLY_SERVICE
chmod 755 /etc/init.d/$WILDFLY_SERVICE
fi
if [ ! -z "$WILDFLY_SERVICE_CONF" ]; then
echo "Configuring service..."
echo JBOSS_HOME=\"$WILDFLY_DIR\" > $WILDFLY_SERVICE_CONF
echo JBOSS_USER=$WILDFLY_USER >> $WILDFLY_SERVICE_CONF
echo WILDFLY_HOME=\"$WILDFLY_DIR\" > $WILDFLY_SERVICE_CONF
echo WILDFLY_USER=\"$WILDFLY_USER\" > $WILDFLY_SERVICE_CONF
echo STARTUP_WAIT=$WILDFLY_STARTUP_TIMEOUT >> $WILDFLY_SERVICE_CONF
echo SHUTDOWN_WAIT=$WILDFLY_SHUTDOWN_TIMEOUT >> $WILDFLY_SERVICE_CONF
echo WILDFLY_CONFIG=$WILDFLY_MODE.xml >> $WILDFLY_SERVICE_CONF
echo WILDFLY_MODE=$WILDFLY_MODE >> $WILDFLY_SERVICE_CONF
echo WILDFLY_BIND=0.0.0.0 >> $WILDFLY_SERVICE_CONF
fi
echo "Configuring application server..."
sed -i -e 's,<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000",<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" deployment-timeout="'$WILDFLY_STARTUP_TIMEOUT'",g' $WILDFLY_DIR/$WILDFLY_MODE/configuration/$WILDFLY_MODE.xml
sed -i -e 's,<inet-address value="${jboss.bind.address:127.0.0.1}"/>,<any-address/>,g' $WILDFLY_DIR/$WILDFLY_MODE/configuration/$WILDFLY_MODE.xml
sed -i -e 's,<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>,<socket-binding name="ajp" port="${jboss.ajp.port:28009}"/>,g' $WILDFLY_DIR/$WILDFLY_MODE/configuration/$WILDFLY_MODE.xml
sed -i -e 's,<socket-binding name="http" port="${jboss.http.port:8080}"/>,<socket-binding name="http" port="${jboss.http.port:28080}"/>,g' $WILDFLY_DIR/$WILDFLY_MODE/configuration/$WILDFLY_MODE.xml
sed -i -e 's,<socket-binding name="https" port="${jboss.https.port:8443}"/>,<socket-binding name="https" port="${jboss.https.port:28443}"/>,g' $WILDFLY_DIR/$WILDFLY_MODE/configuration/$WILDFLY_MODE.xml
sed -i -e 's,<socket-binding name="osgi-http" interface="management" port="8090"/>,<socket-binding name="osgi-http" interface="management" port="28090"/>,g' $WILDFLY_DIR/$WILDFLY_MODE/configuration/$WILDFLY_MODE.xml
[ -x /bin/systemctl ] && systemctl start $WILDFLY_SERVICE || service $WILDFLY_SERVICE start
echo "Done."
1. По умолчанию в контейнере нет драйвера JDBC и его надо поставить. Насколько я понимаю, для того, чтобы classloader смог загрузить его, он должен быть объявлен как модуль. По сути, процесс сводится к созданию кастом-модуля и регистрации оного в системе:- создаем каталог $WILDFLY_HOME/modules/system/layers/base/com/oracle/ojdbc6/main/ (того, что подчеркнуто, в системе не было)
- заливаем в main собственно драйвер ojdbc6.jar и там же создаем файл module.xml следующего содержания:
<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.oracle.ojdbc6"> <resources> <resource-root path="ojdbc6.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.resource.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
2. Регистрируем драйвер:
root@debian:/opt/wildfly-10.0.0.Final/bin# sh jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[standalone@localhost:9990 /] /subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle.ojdbc6,driver-class-name=oracle.jdbc.driver.OracleDriver)
{"outcome" => "success"}
[standalone@localhost:9990 /] exit
root@debian:/opt/wildfly-10.0.0.Final/bin#
3. Конфигурация датасорса в standalone.xml после выполнения всех операций:
<datasource jta="true" jndi-name="java:/OracleDS" pool-name="OracleDS" enabled="true" use-ccm="true"> <connection-url>jdbc:oracle:thin:@####:1521:DEV</connection-url> <driver>oracle</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> <background-validation>true</background-validation> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> </validation> </datasource>4. После перезагрузки на попытку деплоя любого приожения последует ругань DefaultDataSource is missing [jboss.naming.context.java.jboss.datasources.ExampleDS]. Решается удалением тестового датасорса через терминал JBoss:
# /subsystem=datasources/data-source=ExampleDS:remove() # /subsystem=ee/service=default-bindings:write-attribute(name=datasource,value=undefined)5. Может пригодится предустановленная заглушка security-domain:
<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <context-root>CrudJSF</context-root> <security-domain>jaspitest</security-domain> </jboss-web>
15.09.2016
Модификация запроса View Criteria в runtime
Для того, чтобы модифицировать предикаты, которыми оборачивается запрос из View Criteria, применяется перекрытый метод getCriteriaItemClause класса ViewObjectImpl. Например, мы можем вручную подцепить определеную bind-переменную в произвольное ограничение:
Ещё нюанс о галочке Ignore Null Values с обязательными bind-переменными:
@Override
public String getCriteriaItemClause(ViewCriteriaItem aVCI) {
VariableValueManager vm = this.ensureVariableManager();
ArrayList criteriaList = aVCI.getValues();
for (ViewCriteriaItemValue itemValue : criteriaList) {
if (itemValue.getIsBindVar()) {
Variable bindVariable = itemValue.getBindVariable();
Object variableValue = vm.getVariableValue(bindVariable);
// check for the special DESCRIPTION in the used bind variable
Object descProperty = bindVariable.getProperty("DESCRIPTION");
String description = (descProperty != null ? descProperty.toString() : "null");
if ("NAME".equalsIgnoreCase(description)) {
if (aVCI.getViewCriteria().getRootViewCriteria().isCriteriaForQuery()) {
if (variableValue != null) {
return "EMP.NAME LIKE ('%' || :p_name || '%')";
}
}
}
}
}
return super.getCriteriaItemClause(aVCI);
}
Про происходит: выполняется цикл по всем bind-переменным. Идентификация нужной переменной происходит по свойству DESCRIPTION. Если переменная найдена и она имеет значение, отличное от NULL, добавляется предикат. Иначе вызывается родительский метод.Ещё нюанс о галочке Ignore Null Values с обязательными bind-переменными:
Снятая галочка Ignore Null Values в случае с обязательными bind-переменными обеспечивает оборачивание запроса в ограничение ( = :p_var or :p_var is null) в любом случае, что в случае со сложными запросами может привести к сбиванию плана. Если галочка установлена, то ограничение добавляется только если переменная не NULL.
04.05.2016
Jdeveloper Design Time issue fix
Дополню пост про устранение глюка с отображением страниц в JDeveloper.
Для версии 11.1.2.2.39.61.83.1 нужно удалить следующие каталоги:
Для версии 11.1.2.2.39.61.83.1 нужно удалить следующие каталоги:
- o.jsp.feature
- o.j2ee.jstl
- o.j2ee.jpsconfig
- o.ide.appoverview
- o.j2ee.jsplib
12.02.2016
ADF: кастомный selection-listener и обновление данных в popup
Столкнулся с проблемой: не обновляется отображение переменной биндинга в popup-окне. Решается оборачиванием стандартного листенера в кастомный метод и программным добавлением partial trigger на элемент, инициирующий обновление переменной.
public void customListener(SelectionEvent selectionEvent) {
UIComponent component = selectionEvent.getComponent();
component.processUpdates(FacesContext.getCurrentInstance());
JSFUtils.resolveMethodExpression("#{bindings.AllUsersVO1.collectionModel.makeCurrent}", null,
new Class[]{SelectionEvent.class}, new Object[]{selectionEvent});
setExpressionValueCustom();
}
private void setExpressionValueCustom(){
ViewRowImpl row = (ViewRowImpl)JSFUtils.resolveExpression("#{bindings.AllUsersVO1.currentRow}");
JSFUtils.setExpressionValue("#{bindings.userLogin.inputValue}", row.getAttribute("Username"));
AdfFacesContext.getCurrentInstance().addPartialTarget(getP_delete());
}
getP_delete() - геттер объекта RichPopup.21.01.2016
ADF: Уход со страницы с незафиксированными данными
У концепции ADF есть интересное свойство: обязанность по отслеживанию незакоммиченных данных полностью ложится на программиста. Сложно сказать, как с этим планировалось справляться силами недоучившихся студентов, на которых рассчитано декларативное программирование в ADF. Да и не об этом речь. Речь пойдет о том, как уйти со страницы, которая создала новую запись в VO, связанном c EO, не зафиксировать эту запись, и потом благополучно вернуться обратно.
Что сразу приходит в голову:
Рабочее решение заключается в создании бина уровня приложения, унаследованного от PagePhaseListener, где мы будем анализировать страницу на ранней фазе жизненного цикла и отслеживать грязные данные. Создаем бин и прописываем его в adf-settings.xml:
Сам класс:
Код 9 - id фазы инициализаци Restore View. Интересно проследить жизненный цикл страницы-источника (откуда переходим) после изменения данных:
В целевой странице (куда переходим) грязные данные присутствуют во всем цикле:
Что сразу приходит в голову:
@PostConstruct
public void initBean() {
AppModuleImpl mod = (AppModuleImpl)ADFUtils.getBindingApplicationModule();
DBTransaction conn = mod.getDBTransaction();
if (conn.isDirty()) conn.rollback();
...
Так нехорошо, потому что initBean() будет вызываться при каждой активности на странице и транзакция будет теряться тогда, когда это не нужно. К тому же транзакция будет откатываться на фазе prepareRender, что тоже идеологически неверно. То есть контекст уже проинициализирован, загружена модель данных, проверены валидации, всё готово к прорисовке страницы - и тут мы сообщаем системе, что данные нужно изменить. Не знаю, что именно будет происходить глубоко внутри приложения, но думаю, что ничего хорошего.Рабочее решение заключается в создании бина уровня приложения, унаследованного от PagePhaseListener, где мы будем анализировать страницу на ранней фазе жизненного цикла и отслеживать грязные данные. Создаем бин и прописываем его в adf-settings.xml:
Сам класс:
import java.util.ArrayList;
import java.util.Map;
import javax.faces.context.FacesContext;
import javax.servlet.http.HttpServletRequest;
import oracle.adf.controller.v2.lifecycle.PagePhaseEvent;
import oracle.adf.controller.v2.lifecycle.PagePhaseListener;
import oracle.adf.share.ADFContext;
import oracle.jbo.server.DBTransaction;
import *.ADFUtils;
import *.AppModuleImpl;
public class PageListenerBean implements PagePhaseListener{
// если conn.isDirty() и переходим на из url из списка, то rollback
private static String[] deniedUrls = {"/myapp/faces/task-flow-definition/tree"};
@Override
public void beforePhase(PagePhaseEvent pagePhaseEvent) {
try{
if (pagePhaseEvent.getPhaseId() == 9){
AppModuleImpl mod = (AppModuleImpl)ADFUtils.getBindingApplicationModule();
DBTransaction conn = mod.getDBTransaction();
if (isPageChanged()){
if (changedToDisallowed()){
if (conn.isDirty()){
conn.rollback();
System.out.println("= rolled back!");
}
}
}
}
}catch(Exception e){
;
}
}
@Override
public void afterPhase(PagePhaseEvent pagePhaseEvent) {
;
}
private void setApplicationScopeParameter(String val){
ADFContext adfCtx = ADFContext.getCurrent();
Map applicationScope = adfCtx.getApplicationScope();
applicationScope.put("currentURL", val);
}
private String getApplicationScopeParameter(){
ADFContext adfCtx = ADFContext.getCurrent();
Map applicationScope = adfCtx.getApplicationScope();
return (String)applicationScope.get("currentURL");
}
private boolean isPageChanged(){
try{
if (!getCurrentUrl().equals(getApplicationScopeParameter())){
setApplicationScopeParameter(getCurrentUrl());
return true;
}
}catch(NullPointerException e){
System.out.println("--! PageListenerBean: can't get current url");
}
return false;
}
private boolean changedToDisallowed(){
for(String url : this.deniedUrls)
if (url.equals(getCurrentUrl()))
return true;
return false;
}
private String getCurrentUrl(){
FacesContext ctx = FacesContext.getCurrentInstance();
HttpServletRequest servletRequest = (HttpServletRequest) ctx.getExternalContext().getRequest();
return servletRequest.getRequestURI();
}
}
При каждом срабатывании проверяется соответствие текущего URL переменной #{applicationScope.currentURL}. Если страница отличается, находится в "стоп-листе" и данные грязные, тогда откатываем транзакцию. Стоп-лист введен во избежание непредвиденных потерь транзакции при единой фиксации нескольких страниц (такое может быть в приложении).Код 9 - id фазы инициализаци Restore View. Интересно проследить жизненный цикл страницы-источника (откуда переходим) после изменения данных:
14.01.2016
Переменные PL/SQL пакета: неочевидность
2 часа просидел над отладкой простейшего кода, не замечая подводного камня.
Допустим:
Итого: имена переменных пакета лучше начинать с префикса, либо использовать явное указание принадлежности переменной пакету.
Допустим:
create or replace package VARTEST is BANNER varchar2(255); procedure test (p_cur out sys_refcursor); end VARTEST; create or replace package body VARTEST is procedure test (p_cur out sys_refcursor) is begin open p_cur for select count(*) from v$version v where v.BANNER = BANNER; end test; end VARTEST;Вызовем-ка функцию
begin VARTEST.BANNER := 'some awsome text'; vartest.test(p_cur => :p_cur); end; -------------- count(*) 5Результат казался неожиданным, пока (случайно!) не выполнил запрос
select * from v$version v where v.BANNER = BANNER;Запрос, на удивление, выполнился и честно вернул всё содержимое вьюхи. Т.е. BANNER - это в данном случае имя поля, а не переменная пакета.
Итого: имена переменных пакета лучше начинать с префикса, либо использовать явное указание принадлежности переменной пакету.
27.10.2015
PL/SQL: MODEL (пример)
У движка отчетов JasperReports есть особенность: область детализации строго горизонтальна и занимает всю ширину страницы. Если нужно напечатать несколько маленьких бланков, которые умещаются по 2 штуки в ряд, то придется печатать всё-таки по одному.
Выход - подать на вход выборку, уже разбитую на 2 колонки.
Для простейших случаев наподобие представленного можно использовать MODEL - мощную инструкцию PL/SQL, позволяющую с выборкой производить операции с нетривиальной логикой. Применяется крайне редко в особо тяжелых случаях.
В приведенном примере сначала мы разбиваем выборку по колонкам в зависимости от четности/нечетности порядкового номера, затем на уровне выше с помощью функции LEAD склеиваем строки, чтобы убрать шахматный порядок в данных. Наконец, ограничением where id1 != 0 отсекаем пустые строки, образовавшиеся после склейки.select * from (select id1, name1, lead(id2, 1) over(order by null) id2, lead(name2, 1) over(order by null) name2 from (select id1, name1, id2, name2 from (select 1 r, 10 id, 'a' name from dual union select 2 r, 15 id, 'b' name from dual union select 3 r, 20 id, 'c' name from dual union select 4 r, 25 id, 'd' name from dual union select 5 r, 30 id, 'e' name from dual) model dimension by(r, id, name) measures(0 id1, cast(null as varchar2(255)) name1, 0 id2, cast(null as varchar2(255)) name2) rules(id1 [ mod(r, 2) != 0, id, name ] = cv(id), id2 [ mod(r, 2) = 0, id, name ] = cv(id), name1 [ mod(r, 2) != 0, id, name ] = cv(name), name2 [ mod(r, 2) = 0, id, name ] = cv(name)))) where id1 != 0
23.10.2015
PL/SQL: Месяцы в родительном падеже
Не хотелось плодить кучу условий и использовать какие-либо кириллические константы, поэтому вот:
function month_rodp(p_date in date) return varchar2 is mon varchar2(20); begin mon := trim(lower(to_char(p_date, 'MONTH'))); if (to_char(p_date, 'MM')) in (3,8) then mon := mon || chr(1072 using NCHAR_CS); else mon := substr(mon, 1, length(mon)-1) || chr(1103 using NCHAR_CS); end if; return mon; end month_rodp;