Эта статья предоставлена ​​пользователем сообщества Tencent Blue Whale Zhiyun: CanWay.

краткое содержание：Автор опирается на собственное техническое и отраслевое понимание.,Проанализируйте значение и практику интеграции эксплуатации и технического обслуживания.

Использование ключевых слов：Комплексная эксплуатация и техническое обслуживание、Эксплуатация и обслуживание платформы、Цифровое интеллектуальное управление и обслуживание、Эксплуатация и обслуживание PaaS、Система инструментов для эксплуатации и технического обслуживания、Синий кит и т. д.

Автор этой статьи：Менеджер по продуктам и решениям Jiawei Blue Whale по эксплуатации и техническому обслуживанию Чжан Мин

Полный текст состоит из 7100 слов, предполагаемое время чтения — 16 минут.

Обобщена концепция интеграции эксплуатации и технического обслуживания.

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

Что такое эксплуатация и техническое обслуживание

Мы используем бизнес-архитектуру, определенную TOGAF, для определения бизнеса по эксплуатации и техническому обслуживанию. Бизнес по эксплуатации и техническому обслуживанию представляет собой совокупное описание позиционирования ценности, управления, организации и ключевых бизнес-процессов. В абстрактных терминах необходимо ответить на несколько вопросов: что. что делать (бизнес-возможности), кто это будет делать (бизнес-роль), как это делать (бизнес-процесс), необходимые приложения (архитектура приложений для эксплуатации и обслуживания), необходимые данные (архитектура данных для эксплуатации и обслуживания), требуемые технологии (технические изменения) и разработки в области эксплуатации и технического обслуживания);

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

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

В качестве примера возьмем общую тему управления ИТ-услугами:

Рисунок 1. (Общая) Бизнес-архитектура управления ИТ-услугами

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

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

Система инструментов: имеет такие функции, как самообслуживание, выпуск услуг, управление каталогом услуг, управление SLA, определение услуг и процессов, управление запросами, управление событиями, управление проблемами, управление изменениями, управление выпусками и т. д. и связана с ITOM. через ключевые деловые отношения, такие как выпуск, ввод в производство и вызов инструментов автоматизации выпуска и т. д.;

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

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

Для дальнейшего углубления понимания здесь особенно рекомендуется статья президента ICBC Хоу «Исследование интегрированной и автоматизированной системы эксплуатации и технического обслуживания» (эта статья также неоднократно опирается на его идеи).

Какова логика взаимодействия бизнес-единиц и бизнеса?

Крупную систему эксплуатации и обслуживания можно разобрать на несколько бизнес-поддоменов.,Практика ITIL помогла нам подвести некий итог,Однако технического руководства недостаточно; вообще говоря, эксплуатация и техническое обслуживание рассматриваются с точки зрения общей эксплуатации и технического обслуживания в отрасли бизнес-дизайна.,Мы можем определить, что основные темы эксплуатации и технического обслуживания делятся на две категории: менеджмент обслуживания и технический менеджмент. Управление услугами — это процесс управления центром обработки данных, предоставляющий соответствующим заинтересованным сторонам услуги, которые действительно отражают ценность центра обработки данных. Техническое управление осуществляется с точки зрения внутреннего развития центра обработки данных.,Обеспечивать дальновидную, Системную систему улучшения обслуживания деятельность по управлению исследованиями в области технологических инноваций. И будет расширено управление услугами, включая: управление конфигурацией.、Управление изменениями、управление инцидентами、Управление производством、управление проблемами、Управление аварийным аварийным восстановлением、Мониторинг и управление、Управление эксплуатацией и т. д.; техническое управление включает управление архитектурой.、Операции, развитие и управление、Управление данными и т. д.

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

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

Рисунок 2. Проект взаимодействия между бизнес-сферой аварийного восстановления и управления чрезвычайными ситуациями и внешним бизнесом.

Интегрирована ли архитектура приложений для реализации бизнеса?

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

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

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

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

Далее Гуань Чжун Пянь Бао исследует внедрение интегрированной системы эксплуатации и технического обслуживания.

Модель разборки бизнеса по эксплуатации и техническому обслуживанию

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

Определение бизнес-архитектуры

Определите четыре элемента: роли, процессы действий, системы инструментов и объекты действий. Давайте возьмем известную бизнес-тему управления конфигурациями в качестве примера для проведения анализа дизассемблирования.

Рисунок 3: Управление конфигурациямибизнес-дизайн

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

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

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

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

Функциональный архитектурный дизайн

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

Продолжаем разбирать тему управления конфигурациями:

Рисунок 4. Проект архитектуры приложения управления конфигурацией.

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

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

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

Связано с другими сферами бизнеса

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

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

Подводя итог, это помогает нам определить несколько вещей:

Определить границы бизнес-домена

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

Определить логику подключения бизнес-доменов

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

Функции служат бизнесу

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

Многомерное построение бизнеса, приложений, данных и технологий для содействия интеграции

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

Бизнес-уровень основан на сквозном проникновении процесса.

В основе лежит интеграция эксплуатации, управления и утилизации со следующими сценариями развертывания:

Интегрированная эксплуатация и управление

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

Более типичным является сценарий привязки тревоги к событию:

Рисунок 5: Процесс жизненного цикла сигнализации

Интеграция эксплуатации и утилизации

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

Комплексное управление и утилизация

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

Рисунок 6: Механизм процесса управления

Рисунок 7: Механизм процесса выполнения

Архитектура приложения основана на единой объектной модели.

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

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

Рисунок 8: Единая объектная модель

Рисунок 9: Построение объектов наблюдения и управление показателями на основе объектной модели

Уровень данных основан на системе управления данными для поддержки сценариев.

Данные по эксплуатации и техническому обслуживанию можно разделить на 5 областей:

Область конфигурации: система управления ИТ-активами, основная информация, технические параметры и информация о корреляции различных типов электронного информационного оборудования в управлении конфигурацией, включая ПК, серверы, устройства хранения данных, сетевое оборудование, оборудование безопасности, вспомогательное оборудование, оборудование компьютерного зала, пакет. программное обеспечение и прикладное системное программное обеспечение и т. д.;

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

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

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

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

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

Как спроектировать логику и связь между данными эксплуатации и технического обслуживания?

Каково позиционирование платформы эксплуатации и обслуживания больших данных?

Как продолжать строить сценарии потребления данных?

Как интегрировать данные и ИИ?

Ключевая логика:

Рисунок 10. Архитектура управления на основе данных эксплуатации и технического обслуживания.

Вот несколько практических рекомендаций:

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

Рисунок 11: Пример сцены наблюдения с точки зрения тревоги

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

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

Техническая архитектура основана на унифицированной архитектуре конвейера управления и контроля и платформы.

Унифицированный конвейер управления и контроля относится к конвейеру объектов эксплуатации и обслуживания, который адаптируется к различным приложениям эксплуатации и обслуживания. Ядро включает три конструкции:

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

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

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

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

Рисунок 12. Пример архитектуры платформенной технологии.

Пример проектирования комплексной эксплуатации и технического обслуживания в рамках серийной версии

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

Установите сцену

Существует более 100 бизнес-систем, более 5 Вт хост-узлов и более 5000 хост-узлов кластера K8S, что обеспечивает высококачественный, высокий уровень безопасности и высокую эффективность унифицированного выпуска;

бизнес-дизайн

Организационная роль:

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

Рабочий процесс:

Посредством основных процессов планирования производства, проверки программы, проверки производства, выполнения производства и проверки приложений каждый процесс может быть дополнительно расширен до конкретных ролевых действий;

Ключевые виды деятельности:

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

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

③Руководители и руководители контролируют выпуск больших экранов и получают данные оперативного анализа...

Нормативные указания:

«Меры управления эксплуатацией производственного релиза»: архитектура приложения и операционная среда, процесс выпуска, рутинная обработка ошибок, аварийный откат;

Конструкция инструмента

Уровень доступа:

Подключайтесь к различным средам и различным объектам ресурсов, в основном к хостовым и контейнерным средам;

Логический уровень:

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

Уровень интерфейса:

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

Внешняя интеграция:

Связано с DevOps, активирует маскирование времени тревоги и связано с процессом изменений ITSM;

Пример оформления пола:

Рисунок 13: Функциональный дизайн интегрированной системы выпуска и производства.

Интерфейс продукта инструмента:

Рисунок 14: Пример функционального интерфейса интегрированной системы выпуска и производства.

Итак, на этом этапе давайте кратко подведем некоторые итоги:

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

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

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

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

Наконец, вы можете поговорить с Цзявэй Синим Китом в любое время!

Резюме: Вышеизложенное представляет собой авторский анализ комплексной эксплуатации и обслуживания. Добро пожаловать для обсуждения и обмена, спасибо!