| Access (Доступ)
|
| — | Возможность получения каких-либо ресурсов системы в зависимости от прав пользователя. |
| Acquisition (Заказ)
|
| — | Процесс приобретения системы, программного продукта, сервиса или программной услуги. |
| Agreement (Соглашение)
|
| — | Определение границ и условий, при которых будут осуществляться рабочие Взаимоотношения. |
| Alerts (Сигналы)
|
| — | Предупреждения, порождаемые событиями, превысившими заранее заданный порог. |
| Assets (Активы)
|
| — | Активы, участвующие в реализации бизнес-процесса. Могут включать людей, приспособления, компьютерные системы, сети, бумажные отчеты, факсимильные машины и т.д. 2) Контролируемые предприятием хозяйственные ресурсы, которые получены в результате предыдущих операций и должны принести доход или иную экономическую выгоду в будущем. |
| Audit (Аудит)
|
| — | Проверка, выполняемая компетентным органом (лицом) с целью обеспечения независимой оценки и степени соответствия программных продуктов или процессов установленным требованиям. |
| Availability (Доступность)
|
| — | Способность компонентов или сервисов исполнять требуемые от них функции в установленные моменты или периоды времени. |
| Availability Management (Управление доступностью)
|
| — | Процесс разработки, внедрения, измерения и управления сервисами ИТ для обеспечения установленных требований по доступности. |
| Availability Plan (План доступности)
|
| — | План, рассматривающий перспективы доступности и нацеленный на совершенствование запаса доступности инфраструктуры ИТ для того, чтобы гарантировать, что существующие и будущие уровни доступности, будучи эффективными по стоимости, могут поставляться регулярно по времени. |
| Availability ratio (Уровень доступности)
|
| — | Отношение времени, когда сервис реально доступен ко всему оговоренному в соглашении времени, когда сервис должен быть доступен (Эквивалент доступности в измеряемом виде). |
| Awareness (Осведомлённость)
|
| — | Осведомлённость персонала второй линии поддержки о ситуации на первой линии поддержки. Часто персонал второй линии поддержки не вовлекается в происходящие на SD процессы и постепенно взаимодействие с персоналом первой линии поддержки ухудшается. Рекомендуется привлекать представителей второй линии к работе в качестве операторов на постоянной основе или в качестве ротации. |
| Baseline (Базис)
|
| — | 1) Официально зарегистрированный в конкретный момент времени снимок или состояние системы. Хотя может быть модифицированным позже, базис остается неизменным и доступным как справочник первоначального состояния; также используется и для сравнения с текущим состоянием.
2) Официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени жизненного цикла элемента конфигурации. |
| Build (Построение)
|
| — | Финальный этап в построении рабочей конфигурации. Процесс включает в себя выбор одного из нескольких Учётных Элементов, дальнейшее их объединение, дальнейшее их объединение и использование с целью получения результирующих Учётных Элементов. |
| Capacity Database (База данных ресурсных мощностей)
|
| — | Содержит технические спецификации подготовленных или измененных Учетных элементов с описанием требований по производительности, ожидаемой загрузке и их потребности в рамках ресурсов ИТ |
| Capacity Management (Управление мощностями)
|
| — | Процесс, контролирующий все изменения в инфраструктуре ИТ или обновления, ассоциированные с сервисами ИТ, в соответствии с принятыми процедурами утверждения изменений для того, чтобы свести к минимуму негативные воздействия на качество услуг ИТ и непрерывность бизнеса (один из 10 основных процессов). |
| Capacity Plan (План мощностей)
|
| — | Описание уровней использования существующих ресурсов и производительности услуг, а таже прогнозы развития мощностей в будущем на основе анализа планов и стратегии бизнеса. |
| Change (Изменение)
|
| — | Добавление, изменение или удаление принятого или поддерживаемого оборудования, программного обеспечения, приложений, услуг (сервисов), окружения, систем, документации. |
| Change Advisory Board (Консультативный комитет по принятию изменений)
|
| — | Группа специалистов, которая может предоставить экспертные рекомендации Управлению изменениями на осуществление изменений. Обычно Комитет состоит из представителей всех областей службы ИТ, а также представителей бизнес-подразделений. |
| Change control (Контроль над внесением изменений)
|
| — | Процедура, обеспечивающая контроль над всеми производимыми изменениями, включая подачу документов, анализ, принятие решения, одобрение, внедрение и последующее сопровождение. |
| Change document (Документ об изменении)
|
| — | Документами об изменениях могут быть: запросы на изменение, формы контроля внесения изменений, приказы на внесение изменений, записи в базу данных об изменении. |
| Change history (История изменений)
|
| — | Поддающаяся проверке информация о произведённых изменениях (что было сделано, когда, кем и почему). |
| Change log (Журнал изменений)
|
| — | Журнал запросов на внесение изменений, содержащий информацию о каждом изменении, его оценке, какие решения были приняты и их текущий статус (начато, пересматривается, принято, внедряется или завершено). |
| Change Management (Управление изменениями)
|
| — | Процесс контроля и управления внесением изменений в инфраструктуру и различные аспекты сервисов, ответственный за минимизацию разрушений для предоставляемых сервисов при внесении изменений (один из 10 основных процессов). |
| Change record (Запись об изменении)
|
| — | Запись, содержащая разнообразные детали о производимых изменениях: каких элементов они касаются, кем запланированы, кем и каким образом исполняются. |
| Change Request (Запрос на изменение)
|
| — | Документ определяющий требования к изменениям, которые необходимо новой внести в новую версию ПО |
| CI Level (Уровень Учётного элемента)
|
| — | Самый низкий уровень, на котором опознаваемые Учётные элементы ещё могут быть уникально охарактеризованы (Рассматривается вместе с CI). |
| CI Status (Статус Учётного Элемента)
|
| — | Дискретный показатель, отражающий состояние Учётного элемента в конкретный момент времени своего жизненного цикла. |
| Classification (Классификация)
|
| — | Процесс: формальной группировки Учётных Элементов по типу; идентификации Изменений по типу; идентификации Инцидентов, Проблем и Известных ошибок по происхождению, симптомам и причинам. |
| Closure (Закрытие )
|
| — | Ситуация, когда заявка уже обработана, клиент полностью удовлетворен решением и инцидент разрешён. |
| Component Failure Impact Analysis (Анализ влияния сбоев компонент инфраструктуры ИТ)
|
| — | Метод может использоваться, чтобы предсказывать и оценивать воздействие на услугу ИТ. Результат CFIA может быть использован, чтобы определить, где необходима дополнительная устойчивость инфраструктуры, чтобы предотвратить или минимизировать воздействие сбоев на бизнес и пользователей. |
| Configuration baseline (Конфигурационный Базис)
|
| — | Описание конфигурации системы, установленное в выделенный момент времени и охватывающее как структуру, так и детали продукта или системы и позволяющее при необходимости в будущем восстановить исходное состояние. |
| Configuration control (Контроль над конфигурациями )
|
| — | Деятельность по контролю над внесением изменений в Учётные Элементы после формального утверждения конфигурационных документов. Включает в себя оценку необходимости, координацию, принятие либо отказ от принятия изменений. Внесение изменений включает в себя собственно изменения, различные отклонения и отказы, способные оказать влияние на конфигурацию. |
| Configuration documentation (Конфигурационная документация)
|
| — | Документы, которые определяют требования, дизайн систем, способ построения, пути создания и порядок проверки Учётного Элемента |
| Configuration identification (Идентификация конфигурации )
|
| — | Действия по определению структуры продукта, по выбору Учётных Элементов и документации об их физических и функциональных возможностях, включая интерфейсы и имевшие место изменения. Идентификация также включает в себя размещение идентификационных характеристик на Учётных Элементах, а также уникальное кодирование конфигурационных форм контроля, ассоциированных с изменениями и проблемами. |
| Configuration Item (Учётный Элемент)
|
| — | Отдельный компонент инфраструктуры — или любой другой компонент (например, запрос на изменение), ассоциированный с инфраструктурой -который находится (или должен находиться) под контролем Управления конфигурациями. Может варьироваться по сложности, размеру, типу, от всей системы в целом (включая оборудование, программное обеспечение и документацию) до отдельного модуля или незначительного элемента оборудования. |
| Configuration Management (Управление конфигурациями)
|
| — | Процесс распознавания и определения Учётных элементов системы, контроля полноты и корректности записей по ним, а также регистрации и отслеживания статусов Учётных элементов и Запросов на внесение изменений (один из 10 основных процессов) |
| Configuration Management Database (База Данных Учетных Элементов)
|
| — | База данных Учётных Элементов, содержащая все значимые сведения о каждом из Учётных Элементов, а также описание взаимосвязей между ними. |
| Configuration Management tool (Средство для Управления конфигурациями)
|
| — | Программный продукт, предоставляющий автоматизированную поддержку для внесения изменений, контроля над конфигурациями или версиями. |
| Configuration Manager (Менеджер конфигураций )
|
| — | Сотрудник (Хозяин, лидер, владелец, лицо принимающее решение), осуществляющий общее руководство процессом Управления конфигурациями. Рассматривает спорные ситуации и принимает по ним решения. Анализирует текущий процесс и разрабатывает меры по его совершенствованию. |
| Configuration structure (Конфигурационная структура)
|
| — | Иерархия всех Учётных Элементов, образующих конфигурацию |
| Critical Incident (Критичный инцидент)
|
| — | Инцидент, который напрямую препятствует выполнению производственного цикла. |
| Data Base (База данных)
|
| — | Программно-аппаратный комплекс обеспечивающий хранение данных в форме реляционных таблиц |
| Data Mart (Витрина данных)
|
| — | Совместно используемая, аналитическая структура данных, которая поддерживает одну предметную область, приложение или отдел. |
| Data Transformation (Преобразование данных)
|
| — | это набор процедурных операций, применяемых к собранным первичным данным, для получения из них целевых с точки зрения хранения и публикации в КХД. |
| DataWareHouse (Хранилище данных)
|
| — | Предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия управленческих решений. |
| Definitive Software Library (Эталонная библиотека программного обеспечения)
|
| — | Библиотека, в которой хранятся защищенные версии всех программных Учётных элементов… Это физическая или электронная библиотека или хранилище, где хранятся мастер-копии версий программного обеспечения. Хранилища должны быть отделены от мест, где хранится ПО, которое тестируется или разрабатывается. К DSL также могут относиться физические хранилища для хранения мастер-копий bought — in программного обеспечения. В DSL следует хранить только авторизованное ПО, проконтролированное и авторизованное Управлениями изменениями и релизами. |
| Delta Release (Дельта-релиз)
|
| — | Частичный релиз, который включает в себя только те Учётные элементы в рамках релиза, которые будут изменены, а также которые возникнут после последнего внедрённого релиза. К примеру, если рассмотреть релиз программы, то дельта-релиз состоит только из тех модулей, которые будут изменены, или являются новыми с тех пор, как был выпущен последний полный релиз программы или последний дельта-релиз определённых модулей. |
| Directory (Справочник)
|
| — | Совокупность данных об объектах, состоящая из идентификаторов и ссылок на соответствующие им элементы данных. Каждый объект описывается набором параметров (параметр может являться значением из классификатора или содержать другую дополнительную информацию об объекте). |
| Disaster recovery planning (Планирование восстановления после разрушений)
|
| — | Серия мероприятий, направленных только на восстановление процессов, разрушенных в основном в результате физических повреждений процессов. |
| Environment (Окружающая среда)
|
| — | Набор вспомогательного оборудования, программного обеспечения, сетевых коммуникаций и процедур работающих одновременно для обеспечения отдельных элементов цельного сервиса. Каждый вариант окружающей среды имеет свои собственные, уникальные характеристики, позволяющие его описать. |
| Error (Ошибка)
|
| — | Это инцидент с известной корневой причиной |
| Escalation (Эскалация)
|
| — | Организационный механизм, помогающий управлять и контролировать процессы или объекты по определенному общему признаку в соответствии с определёнными критериями. |
| Evaluation (Оценка)
|
| — | Систематическое определение степени соответствия объекта установленным критериям. |
| Fault Tree Analysis (Анализ дерева отказов)
|
| — | Это метод, который может использоваться, чтобы определить цепь событий, которые приводят к разрушению сервиса ИТ. FTА в соединении с методами вычисления может предложить детальные модели доступность. Метод может использоваться, чтобы оценить улучшение доступности, которое может быть достигнуто индивидуальным подходом к вариантам инфраструктуры ИТ. |
| Fault-Tolerance (Отказоустойчивость)
|
| — | Способность компоненты или системы продолжать функционировать даже тогда, когда один или более связанных с ней компонентов вышли из строя. |
| First line (Первая линия)
|
| — | Группа операторов, которая начинает прогресс общения с клиентами, регистрации и дальнейшего сопровождения всех поступающих от них заявок. |
| Form (Форма)
|
| — | Структурированный интерфейс ввода или редактирования записи, построенный из полей предназначенных для заполнения. Некоторые поля обязательны для ввода. |
| Forward Schedule of Changes (Список предстоящих изменений )
|
| — | Список, содержащий детали планируемых изменений и даты их осуществления. Он должен быть согласован как с заказчиками, так и с Управлением уровнем сервиса, Управлением доступностью и руководителем, службы Service Desk. |
| Full Release (Полный релиз)
|
| — | Совокупность всех компонентов релиза, которые строились, тестировались, распространялись и внедрялись одновременно. |
| Functional escalation (Функциональная эскалация)
|
| — | Назначение ответственного специалиста по уровню опыта и технической компетенции (горизонтальная эскалация). |
| Gradual recovery (Постепенное восстановление)
|
| — | Подходит для организаций, которые не нуждаются в моментальном восстановлении бизнес процессов и могут работать без восстановления ИТ средств больше 72 часов. |
| Hard charging (Сильное влияние)
|
| — | Описание ситуации, когда в пределах организации реальные резервы пересылаются от пользователя к ИТ — организации в уплату за установление сервисов ИТ |
| Hierarchical escalation (Иерархическая эскалация)
|
| — | Назначение ответственного сотрудника по уровню административной ответственности (вертикальная эскалация) |
| Hotstandby (Горячий резерв)
|
| — | Специальные компоненты инфраструктуры, предназначенные для немедленного восстановления сервисов, повреждённых в результате инцидента. От немедленного восстановления отличается тем, что восстановление сервисов происходит в течение 2-4 часов. |
| Identification (Идентификация)
|
| — | Процесс распознавания объекта по его идентификационному коду. |
| Immediate recovery (Немедленное восстановление)
|
| — | Немедленное восстановление сервисов, следующих за каким-то неисправным инцидентом. Подразумевает мгновенное наличие сервисов. |
| Impact (Влияние)
|
| — | Мера бизнес-критичности возникшего инцидента. Метрика для определения приоритета разрешения инцидента. Помогает операторам определить степень серьёзности инцидента. |
| Impact Analysis (Анализ влияния)
|
| — | Идентификация критичных бизнес процессов, потенциального ущерба или потери, которая может быть вызвана разрушением процессов. |
| Incident (Инцидент)
|
| — | Любое событие, не являющееся частью нормального функционирования сервиса и при этом влияющее или способное оказать влияние на снижение качества сервиса или полное прекращение его предоставления. |
| Incident Escalation (Эскалация Инцидента)
|
| — | Процесс выбора подходящего специалиста или руководителя для обработки такого инцидента, параметры обработки которого превышают установленные пороги |
| Incident Management (Процесс Управления Инцидентами )
|
| — | Процесс оперативного устранения инцидентов и Запросов на обслуживание услуг, предоставляемых клиентам в соответствии \\\' с подписанными Соглашениями об уровнях обслуживания. |
| Incident owner (Владелец инцидента)
|
| — | Лицо, ответственное за ход разрешения данного инцидента вплоть до его закрытия. |
| Incident-matching process (Процесс поиска подобного инцидента)
|
| — | Первая фаза Ре-активного контроля проблем (идентификация и регистрация), связанного с выявлением настоящих причин возникающих инцидентов с целью предотвращения их проявления в будущем. |
| Information Technology Service Management Reference Model (Эталонная модель организации управления ИТ-службами)
|
| — | Эталонная модель организации управления информационной службой для обеспечения качества предоставляемых услуг. |
| Insulation (Изоляция инцидента)
|
| — | Процесс уточнения признаков инцидента методом поиска уже существующих решений, зарегистрированных в базе знаний. |
| Integration (Интеграция)
|
| — | Один из элементов процесса внедрения, ответственный за организацию взаимодействия и совместного функционирования нескольких процессов или сервисов. |
| Integrity (Целостность)
|
| — | Сохранение точности и полноты соответствующей информации и программного обеспечения. |
| Interface (Интерфейс)
|
| — | Средства для обеспечения физического или функционального взаимодействия между различными Учётными Элементами. |
| Intermediate recovery (Промежуточное восстановление)
|
| — | Ранее называлось \\\«тёплый резерв\\\». Обычно включает в себя восстановление критичных систем в пределах между 24 и 12 часами и используется организациями, которые нуждаются в восстановлении ИТ оборудования в пределах заранее установленного времени для предотвращения влияния бизнес процессов. И еще: синоним Warm standby |
| IT Service Continuity Management (Управление непрерывностью предоставления услуг ИТ )
|
| — | Прогресс, организующий ряд мероприятий по восстановлению функционирования подразделений ИТ для продолжения предоставления сервисов, не ниже оговоренного в SLA уровня, которые удовлетворяют минимальным требованиям бизнеса даже в случае наличия каких-либо сбоев. Процесс включает в себя планирование как резервных вариантов отдельных компонентов сервисов ИТ, так и полностью альтернативных ресурсов. |
| ITIL (IT Infrastructure Library) (Библиотека ITIL)
|
| — | Библиотека передового опыта в области управления информационными технологиями. Серия книг, в которых описан мировой опыт в управлении сервисами ИТ. Первые материалы опубликованы в 1989 году. Разработчик и владелец CCTA/OGC. |
| Knowledge base (База знаний )
|
| — | Логически структурированный набор информации в определенной области знаний, выполненный с целью обеспечения полноты и актуальности осуществления процесса анализа и заключений. |
| Known Bottle Neck (База данных узких мест )
|
| — | Узкое место (bottleneck) это такое условие или состояние дел, при котором замедляется свободное функционирование или появляются некоторые ограничения. |
| Known error (Известная ошибка)
|
| — | Инцидент или проблема, для которых известна корневая причина её возникновения и разработаны способы временного устранения или найдено долговременное альтернативное решение |
| KPI (Key Performance Indicators) (Ключевые индикаторы эффективности)
|
| — | Показатели, которые могут быть использованы для оценки результативности и эффективности действий, процессов и функций управления. |
| Maintainability (Восстанавливаемость)
|
| — | Приспособленность компоненты или системы к восстан |