Вход на сайт

.

IT

: cодержит 132 терминов

Добавить термин

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

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

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

Принцып работы:

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

Набор инстркментов:

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

  1. Code — разработка и анализ кода, инструменты контроля версий, слияние кода;
  2. Build — инструменты непрерывной интеграции, статус сборки;
  3. Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;
  4. Пакет — репозиторий артефактов, предварительная установка приложения;
  5. Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
  6. Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;
  7. Мониторинг — мониторинг производительности приложений, опыт работы с конечным пользователем.

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

Такие инструменты, как управление контейнеризацией (Docker, Kubernetes), непрерывной интеграцией (Jenkins, GitLab), развёртывания сред по шаблону (Puppet, Ansible, Terraform) и многие другие — часто используются и часто упоминаются в дискуссиях по инструментам DevOps.

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

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

Непрерывная интеграция (CI, англ. Continuous Integration) — практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем.

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

Впервые концептуализирована и предложена Гради Бучем в 1991 году. Является одним из основных элементов практики экстремального программирования.

Организация:

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

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

  • получение исходного кода из репозитория;
  • сборка проекта;
  • выполнение тестов;
  • развёртывание готового проекта;
  • отправка отчетов.

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

Сборки по расписанию (англ. daily build — ежедневная сборка), как правило, проводятся в нерабочее время, ночью (англ. nightly build), планируются таким образом, чтобы к началу очередного рабочего дня были готовы результаты тестирования. Для различия дополнительно вводится система нумерации сборок — обычно, каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой. Исходные тексты и другие исходные данные при взятии их из репозитория (хранилища) системы контроля версий помечаются номером сборки. Благодаря этому, точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.

Преимущества и недостатки:

К преимуществам непрерывной интеграции относятся следующие моменты:

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

При этом, практика не лишена недостатков, в частности:

  • значительные затраты на поддержку работы непрерывной интеграции;
  • необходимость в дополнительных вычислительных ресурсах под нужды непрерывной интеграции;

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

CIO

Директор по информационным технологиям  - Chief Information Officer, или ИТ-директор (англ. Information Technology (IT) Director) — руководитель, относящийся к категории топ-менеджмента, высшего руководства предприятия (компании). Определяет информационную стратегию компании, принимает решения на высшем уровне, как правило, руководит работой департамента или службы по информационным технологиям (ИТ или АйТи (от англ. IT)) компании.

В типичной схеме управления компанией часто занимает пост вице-президента и подотчётен президенту компании или генеральному директору. Часто является членом совета директоров.

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

АйТи-директор (англ. Chief Information Officer (CIO), Chief Digital Information Officer (CDIO), Information Technology (IT) Director) — руководящая должность в западных компаниях, соответствует российскому «Директор по информационным технологиям». Один из руководителей корпорации, отвечающий за её информационные технологии, в его ведении обычно находится вся информационная часть компании.

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

Платёжные контакты.

Client Activated Object — объект активируемый клиентом.

CTO

Англ. Chief technical officer или Chief technology officer — Технический директор — руководящая должность в западных компаниях, соответствует русскому «главный инженер».

Один из руководителей корпорации, отвечающий за её развитие и разработку новых продуктов. 

В ведении CTO обычно находится вся технологическая часть производства.

Англ. Chief Information Security Officer — руководитель отдела IT-безопасности, (главный) директор по IT-безопасности. CISO может подчиняться как CIO, так и CSO.

ARIS (акроним от англ. Architecture of Integrated Information Systems) — методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера.

Методология:

Любая организация в методологии ARIS рассматривается с пяти точек зрения: организационной, функциональной, обрабатываемых данных, структуры бизнес-процессов, продуктов и услуг. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей. Также инструментарий поставляется с набором референтных моделей, заранее разработанных для типичных процессов в различных отраслях. Общий принцип в инструментарии — возможность интеграции моделей разных типов в рамках одного репозитория посредством декомпозиции (детализации) объектов. Таким образом, любую организацию можно описать с помощью иерархии моделей — от обобщения: например, процессы верхнего уровня с помощью модели VACD (англ. value added chain diagram) до уровня процедур и ресурсного окружения функций.

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

  1. eEPC (англ. extended event-driven process chain) — метод описания процессов;
  2. ERM (англ. entity-relationship model) — модель «сущность-связь» для описания структуры данных;
  3. UML (англ. unified modeling language) — унифицированный объектно-ориентированный язык моделирования.

Программный продукт:

Реализация методологии предполагается с задействованием специализированного программного продукта, обеспечивающего совместную работу над описаниями и диаграммами. Первая версия продукта выпущена в 1994 году. К концу 2000 года продукт был продан в 24 тыс. организаций. С 2009 года поставляется бесплатная версия инструмента — ARIS Express.

Продукт предусматривает серверную часть (ARIS Server) с централизованным репозиторием, хранимым в реляционной СУБД и серию пользовательских инструментов для ведения объектов и подготовки графических представлений (ARIS Toolset в ранних версиях, в версиях 2000-х годов — ARIS Business Architect, ARIS Designer).

К середине 2010-х годов также появилась публично-облачная версия продукта.

Продукт ARIS используется в различных проектах по реинжинирингу и оптимизации бизнес-процессов, ИТ-проектах типа внедрения и эксплуатации ERP-систем, в частности, есть проработанное интеграционное решение для SAP R/3. Также программное обеспечение ARIS составляет основу пакета Business Process Analysis Suite корпорации Oracle. Технически инструментарий ARIS достаточно простой для изучения, имеет интуитивно понятный интерфейс. Модели копируются и вставляются в файлы документов (например, формата Microsoft Word) в виде рисунков.

В продуктах ARIS предусмотрена возможность создания сценариев автоматизации составления различных аналитических отчётов, нормативных документов, новых моделей. Каждый сценарий представляет собой подпрограмму, запускаемую в ARIS Business Architect (либо Toolset — более ранней версии) или непосредственно на сервере ARIS. Сценарии пишутся на специальном языке программирования — SAX Basic. Для автоматизированного формирования того или иного отчёта в ARIS сценарии оперируют данными из базы моделей, вычленяя из неё конкретные объекты и модели.

Технология ARIS Script позволяет в автоматическом режиме производить:

  • формирование нормативных документов на основании моделей ARIS (например, паспорт процесса, регламент процесса);
  • формирование аналитических отчётов на основании моделей ARIS;
  • интеграцию ARIS Toolset с другими приложениями и базами данных;
  • Формирование базы моделей ARIS на основании готовых спецификаций.

Основные элементы, используемые в нотации ARIS:

  • Organizational chart:
    • Organizational unit;
    • Символ «Person»;
    • Символ «Location»;
    • Группа персон, роль: «Role».
  • Process landscape:
    • Process.
  • Business process:
    • Event — событие фиксирует состояние определенных параметров на определенный момент времени;
    • Activities — работа, определённое действие, выполняемое в течение некоторого промежутка времени;
    • Role — должность в организации;
    • IT system — информационная система, частный случай «хранилища данных»
    • Risks — риски;
    • Input and Output data — отправитель или получатель данных.
    • Process control via rules (and, or, xor) — перекрёсток («и», «или», «исключающее или»);
    • Proccess interface — средство связи с рассматриваемым процессом.
  • Data model:
    • Entity — сущность (таблица);
    • Attributes — атрибут сущности (поле таблицы);
    • Primary Key — уникальный атрибут сущности (первичный ключ таблицы);
    • Foreign Key — внешний ключ таблицы;
    • Relationship — отношения между сущностями (связь между таблицами);
  • IT infrastructure:
    • IT system;
    • Hardware;
    • Network;
    • Network components.
  • System landscape:
    • IT system;
    • Domain.
  • Deneral diagramm
AI

Иску́сственный интелле́кт (ИИ; англ. Artificial Intelligence, AI) — свойство интеллектуальных систем выполнять творческие функции, которые традиционно считаются прерогативой человека; наука и технология создания интеллектуальных машин, особенно интеллектуальных компьютерных программ.

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