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

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

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

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

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

1、Проектирование платформ

Проектирование Платформа входит в десятку главных стратегических технологических тенденций, опубликованных Gartner в 2023 году. Gartner прогнозирует, что к 2026 году 80% разработок программного Организация по обеспечению программного обеспечения создаст команду платформы,75% из них будут включать портал самообслуживания для разработчиков.,Его основной акцент делается наТехнологии и возможности продукта на базе облачной платформы,С точки зрения потребителя инфраструктуры,Инкапсулируйте инфраструктуру в сервисы платформы,Цепочка облачных инструментов и интеграция сервисов、образовать небольшой масштаб Платформизациякоманда。Отечественная практика больше ориентирована на исследования и разработки.,В отрасли также есть разные голоса.,включать Проектирование Платформа с меньшим вниманием заменяет DevOps и т. д. Эксплуатация и обслуживаниесуществовать Проектирование концепции приложений и сервис-ориентированной архитектуры платформы относительно согласованы, но нет дизайна и определения. и обслуживание Как практикуют организации Проектирование платформа. Конечно, это тоже Эксплуатация и обслуживание – это ситуация, с которой мы обычно сталкиваемся как последнее звено в бизнесе.

2、Управление архитектурой эксплуатации и обслуживания

Существуют также некоторые национальные стандарты и организации, которые дают некоторые определения.,Потому что это действительно ситуация, с которой обычно сталкиваются средние и крупные предприятия в Китае.,Поэтому существуют такие понятия, как iPaaS и aPaaS. Но как управлять,Часто приходится переходить реку, нащупывая камни.,Из различных измерений, таких как процессы, данные, сценарии и т. д.,Общий образец предварительно определяется какОткройте API сетчатого дымохода.,Такие как: наблюденией сексуальная интеграция,Необходимо открыть CMDB для завершения определения объекта.,В то же время Trace, Log и Metric подключаются для объединения данных и других операций. Однако,В этом процессе еще придется столкнуться со многими трудностями.,Одним из них является отсутствие перспективы с общей точки зрения Эксплуатация и обслуживание.,Во-вторых, не хватает эффективных методов управления и успешных практик, которыми можно было бы воспользоваться.。в конечном итоге может впасть в«Богатые инструменты, запутанная конструкция»статус。

3、система СРЕ

SREЭто набор целейсуществоватьпроходитьразработка программного обеспеченияспособПовышение надежности приложенийсистема,использоватьразработка программного управление программным обеспечением и технический подход к решению Эксплуатация и обслуживаниевопроссистема,Среди них особенныйАкцент на упреждающее управление и избежание рисков,включатьнравиться Эксплуатация и работа по обслуживанию ограничена менее чем 50%, сталкивается с неопределенностью, максимально автоматизирована и упрощена. В целях лучшей практики отечественные компании обычно предпочитают поддерживать Эксплуатацию. и обслуживаниеразвитый Эксплуатация и платформа обслуживания для быстрого построения Эксплуатация и обслуживаниесистематическийразработка программного программная способность. Хотя это связано с Эксплуатация и Платформа обслуживания перекрывается, но система глубоко не изучена Ассоциация СРЕ и платформы.

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

1. Предприятия создали множество инструментов, но бремя становится все тяжелее. Трудно соединить инструменты горизонтально и управлять вертикальной структурой. Как решить проблему?
2. Бизнес и потребности меняются,Например, архитектура приложений постепенно переходит от традиционной к облачной.,Может ли существующая архитектура системы Эксплуатация и обслуживание удовлетворить потребности бизнеса? Можно ли цитировать оригинальные способности?,Какие новые возможности необходимы и как их создать?
3. Данные и ИИ、большая языковая модель, наблюдение и другие области технологического развития, Эксплуатация и Существует ли еще определение платформы обслуживания? Как архитектурно поддерживать новую сцену Расширять?
4. ……

таким образом我们把вопрос聚焦существоватьверно Платформизацияиз По определению：Платформа эксплуатации и обслуживания — это определение бизнеса по эксплуатации и обслуживанию на уровне архитектуры программного обеспечения. Масштабируемость, высокая связанность и низкая связанность — это основные тесты и проверки платформы эксплуатации и обслуживания.

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

Платформа эксплуатации и обслуживания — это практика абстрагирования общей архитектуры.

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

На следующем рисунке показана взаимосвязь между бизнесом по эксплуатации и обслуживанию и возможностями инструментов.

Рисунок 1. Эксплуатация и обслуживание. Взаимосвязь между бизнесом и возможностями инструментов.

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

Рис. 2. Распределение функций одного инструмента

Понимание этих четырех уровней таково:

1、Полный замкнутый цикл из уровня объекта, уровня доступа, логического уровня и уровня интерфейса;Например, мы строим систему мониторинга,Независимо от того, проводились ли самостоятельные исследования, используя программное обеспечение с открытым исходным кодом или коммерческое программное обеспечение.,Проходит слой объектаAgent、зонд、Протокол или Kafka для доступа к индикаторам, логически основным процессом является сбор данных;、данные Обнаружение、Тревога、Анализ и утилизация、вид.

2、Дизайн слоя доступа:Он основан на всестороннем рассмотрении объектов и логики.,Например, для мониторинга хоста,Первое, что необходимо учитывать при выборе уровня доступа, — это возможность адаптироваться к различным хост-объектам.,И самое главное — получить индикаторные данные; второе — рассмотрение обнаружения данных на основе логического уровня;,Приходитьдизайнколлекцияданныеобъект、Частота сбора、Сбор и передача и т.д.

3、Логический дизайн слоев:Это модуль замкнутого цикла, основанный на функциональных областях.,Например, объектная модель для мониторинга и сигнализации на основе бизнес-архитектуры и иерархической модели.,Означает, что вам нужна небольшая CMDB в инструменте мониторинга.,Приходить Мониторинг технического обслуживанияобъектки индикаторыизданныеустанавливать。

4、Дизайн слоя интерфейса:Это инструментиспользовать Роль,Затем сопоставьте их с должностными обязанностями компании. Это также плюсы и минусы одного инструмента.,Хорошая вещь - самозамкнутый контур,Плохо то, что трудно удовлетворить Эксплуатация и обслуживание Ролевой аспект управления должностными обязанностями организации.

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

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

Во-вторых, архитектура дымохода приведет к проблемам дублирования строительных и технических долгов.Повторяющуюся конструкцию легко понять.,Например, каждый инструмент имеет уровень доступа, который взаимодействует с целевым устройством.,Если сделать набор из каждого инструмента,Это означает, что на ИТ-объектах будет все больше и больше Агентов или конвейеров. Технический долг является неизбежной проблемой развития. При достижении N+1-й сцены,Вас ждет оригинальная техническая архитектура、функция иданные Поставщик не может удовлетворить требования нового строительства。Это также является основой для многих компаний для создания регуляторного контроля.Эксплуатация и обслуживаниесистематическое, но существенное Эксплуатация и Деятельность по обслуживанию не имеет веских оснований для улучшений и изменений.

Итак, вот несколько очень важных мыслей:

1. Какой панорамный вид нужен компании? и возможности системы обслуживания;
2. Как определить взаимосвязь между способностями;
3. Как объединить способности, чтобы удовлетворить Расширять сексуальные сценарии;
4. Как развиваться поэтапно и по уровням.

Например: Мы описываем более комплексный бизнес-сценарий эксплуатации и обслуживания: управление жизненным циклом ресурсов. Мы примерно описываем его как следующую бизнес-логику:

Рисунок 3. Бизнес-сценарий управления жизненным циклом ресурсов.

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

1. Например ВсеОбщие модули, такие как доступ к объектам, CMDB и оркестровка процессов.,CMDB для доставки ресурсов должна содержать ресурсы в конвейере.,Доступ к объектам используется для автоматической доставки.,Оркестрация процессов используется для координации процесса утверждения заказов на работу и автоматической доставки. Означает ли это доставку ресурсов?,нужноCMDB、процессдвигатель、Можем ли мы быть удовлетворены, если нам придется реализовать автоматическую доставку и так далее?
2. данныеуровень,ВсеНеобходимо использовать некоторые ключевые данные,такие как организационные роли、Конфигурацияданные、нагрузкаданные、расходыданные、бегатьданныеждать。

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

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

Рисунок 4. Общая архитектура платформы «Эксплуатация и обслуживание».

Вот несколько основных архитектурных абстракций и соображений дизайна:

1、Разберитесь со сценой

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

2、Разбор сценариев на бизнес-домены

Для этого требуется ссылка на включение ITIL.、TOGAFждать Достичь отраслевого консенсусаизконцепция Понятно。НапримерУправление мощностями,от Управление мощностямибизнесугол,Далее следуют следующие узлы основных ценностей.：Планирование производительности、Мониторинг производительности、Анализируйте и оценивайте производительность、Оптимизация производительности.

отфункциональный уровеньтогда есть по крайней мере：объектуправлять（ресурсибизнес Два размера емкости）、данныеколлекция、данные Агрегация и расчет、Настройки пороговых значений индикатора и Тревога、Просмотр отчета о производительности、аналитический отчет、Предложения по оптимизации、Планирование мощности (требуются соответствующие возможности автоматизации), а затем необходимо интегрировать CMDB.、Индикаторы мониторингаданные、Автоматизированное выполнение、Эксплуатация и обслуживаниеданныеиметь дело сждатьнезависимая система。

3、Бизнес-домены требуют общих возможностей

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

4、окончательные абстрактные технические возможности

5способность Всенужно немногоОпределения общедоступных объектов, конвейеры данных и выполнения, а также базовые механизмы.ждать,таким образом Сразуиметь ПонятноединыйAgentдизайн、Единая объектная модельдизайн、Унифицировать операции иданныетрубопроводдизайнждать；этот Образец Сразуиметь Понятно Техническая базаиздизайн。

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

• Расширяемый

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

• Высокая сплоченность

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

• низкая связь

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

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

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

Первым шагом является включение общих модулей.

Абстрактная природа общих модулей — это процесс накопления,Удовлетворение потребностей в инструментах,демонтироватьУровень исходящего доступаилогический уровеньизобщая способность,Затемодин Приходитьдизайн,этот Образец逐步накапливать, сокращать,Могут быть нарисованы элементы способностей с разумными границами.,ЗатемзарегистрироватьсяприезжатьiPaaS（integration platform as a сервис), предоставляет модули и потребление данных для инструментов в виде компонентов, взяв в качестве примера CMDB, CMDB имеет два определения: одно — это технический атом, который служит объектной моделью всех систем эксплуатации и обслуживания, а другое — бизнес-атом, отвечающий конкретным потребностям предприятия, управление конфигурациями и сценарии использования.

Второй шаг — автоматизация потребления мощности.

По предприятиям разного размера,Построить систему Эксплуатация и обслуживание из минимизации «1 ПО мониторинга».,Максимально предоставляйте разные инструменты для разных ролей и сценариев.,Очень важные архитектурные требования для построения инструментальной области.Сразудаможет быть автономнымиРасширять,Это также второй ключевой момент абстракции архитектуры платформы. Если нет такого слоя поддержки,Это приведет к тому, что строительство платформы будет выполняться в фоновом режиме.,и没иметь场景活动из Функцияподдерживать；этоткогдаaPaaS（application platform as a сервис) станет очень важным, и эту архитектуру можно будет использовать для достижения развития эксплуатации и обслуживания предприятия или независимой и контролируемой трансформации.

Третий шаг – построение плана сценария мероприятия.

PaaS — это архитектура интеграции программного обеспечения, основанная на возможностях.,способность удовлетворять меняющиеся потребности,Итак, если мы посмотрим снизу вверх,iPaaS абстрагирует технические возможности,Интеграция и интеграция отдельных областей инструментов на базе APaaS,Далее вверху находится комбинированный инструмент,иэтотвнутриизвесьСбор возможностей, данных и услуг,СразуподдерживатьПонятноРасширение деятельности по эксплуатации и техническому обслуживанию。

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

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

Рисунок 5 Схема строительства Эксплуатация и обслуживание и примеры этапов

Поэтому абстракция архитектуры платформы должна быть сделана хорошо.,Должна быть определенная степень «сдержанности» и «твердости».,сдержанностьсуществоватьбыть достаточнымУважайте важность закладки фундамента и не попадайтесь в волну инструментов.；ФирмаПродолжать осуществлять архитектурное управление,особенно Гарантироватьобъект Модель、процесспроникатьиданныеоперацииизединый。

А теперь давайте посмотрим, как решить проблемы перед платформизацией:

1. Компания создала много инструментов, но нагрузка становится все тяжелее. Трудно соединить инструменты горизонтально и управлять вертикальной структурой. Как решить проблему?

отвечать：Разделение возможностей и сценариев,Стратификация возможностей,Основные 5 способностей: Конфигурация, наблюдение, выполнение, процесс, интеллектуальный анализпройти,Логика прохождения через это исходит из сценариев и бизнес-планирования.,Чтобы разобраться в этом, вы можете обратиться к трем строкам: CMDB служит объектной моделью для построения всей системы.,ITSM как процесс реализации каждой бизнес-домены,кданные Модельно-ориентированное построение операционной системы。

Например: существует сценарий относительно высокого уровня, анализ неисправностей. Чтобы реализовать анализ неисправностей, необходимо соединить наблюдения, сигналы тревоги, события и удаления туда и обратно. Затем для анализа неисправностей необходимо использовать CMDB в качестве метаданных объекта бизнеса. и ресурсы, сигналы тревоги и удаление должны использовать ITSM. Откройте основной процесс событий и, наконец, используйте данные и искусственный интеллект для интеграции трассировки, журнала, метрики, изменения, рабочих заданий и т. д., чтобы создавать такие сценарии, как области воздействия сбоев, снимки сигналов тревоги, деревья принятия решений о неисправностях, расположение компонентов неисправностей и т. д. Интегрировать этот единый API сложно.

2. Бизнес и потребности меняются. Например, если архитектура приложений постепенно переходит от традиционной к облачной, сможет ли существующая архитектура системы эксплуатации и обслуживания удовлетворить потребности бизнеса? Можно ли использовать исходные возможности? Какие новые возможности необходимы и как их создать?

Ответ: Cloud own Эксплуатация и сцена обслуживания в качестве примера,Существующие платформы эксплуатации и обслуживания могут быть полностью использованы.,Затем Делатьнравитьсяизменение вниз：Уровень доступа может адаптироваться к контейнерам, облачным компонентам и объектам микросервисов.；Сделайте облако логического слоя родным Эксплуатация и обслуживаниеболее критичныйизнаблюдаемый、управление чрезвычайными ситуациями、Хаос-инжиниринг、Управление мощности и интеллектуальные приложения；правила уровня каналасуществовать原иметьиз Добавлено по способностимногомерныйградусный вид или улучшенный мобильный терминалждать Вот и все。

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

Ответ: Архитектурный уровень по-прежнему является платформенной архитектурой.,Давайте посмотрим на позиционирование каждого технического изменения на архитектурном уровне.,Данные и ИИэто способность,Используется для сцены одобрения.,Например, анализ неисправностей и определение местоположения.,Затем отрегулируйтеиспользоватьданныеанализироватьи Модельизспособность；

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

наблюдаемыйоснован наCMDBизобъектединый、многомерныйданные Слияние,Приходите в Расширять, чтобы увидеть больше сцен.,нравитьсяTraceиLogизассоциация、Тревогаизмногомерныйинформация平面、Сверление в топологическом состоянии и т.д.

……

Изменения и изменения в платформах эксплуатации и обслуживания

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

1. Слой объекта будет продолжать обновляться:особенносуществоватьконтейнер、Распределенные компоненты、Кросс-облако、Продолжайте развиваться на Синьчуане и других объектах.
2. Уровень возможностей будет добавлять новые возможности по мере развития технологии:особенно Данные и Способность ИИ выполнять Эксплуатацию на основе объединения данных и Сцена обслуживания богаче,наблюдаемыйиз Ядро такжесуществоватьединый Модельобъектимногомерныйданные Слияние上才иметь更好изразвивать。
3. Сценарий будет развиваться и углубляться по мере изменения структуры бизнеса:данныеоперации、Интеллектуальная модель мониторинга、Сценарии эксплуатации и обслуживания распределенных облачных приложений、Планирование вычислительной мощностиждатьбудет продолжать углубляться,И оно по-прежнему основано на улучшении способностей.
4. Уровень канала будет разнообразным и гибким:большая языковая Модель потребительского опыта укрепит каналы и интерфейсные связи с пользователями.
5. Архитектура будет продолжать управляться по мере развития возможностей и сценариев:Архитектурауровеньновключать Эксплуатация и обслуживание дальнейшего развития самой облачной платформы и углубления разделения возможностей.

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

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

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

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