https://ee.msup.com.cn/course?aid=2806&id=15443

1. 旷视AI产品背后的研发效能工具建设
刘天伟
2021.10

2. 个人介绍
刘天伟，2013.7毕业于大连理工大学。在豆瓣开始第一份工作，2017.9加入旷视，现任中台技术部平台开发团队和算法产品部
基础平台团队Leader，主任架构师。
2013.7 ~ 2017.9 2017.9 ~ 今
互联网/小清新/ToC AIoT/商业范/ToB
Golang/Python/JS
私有云DevOps平台、云原生PaaS平台、AI生产力平台
私有化场景、自动化运维、云原生、研发效能、大型算力调度
中台、Brain++团队
Python
公有云PaaS平台(DAE)
Web基础架构、App Engine、AutoScale
DAE组

3. 目录 从研发到交付的全流程PaaS平台实践
旷视研发效能建设全景图和展望
旷视产品研发中面临的挑战
1
2
3

4. “
”
旷视产品研发中面对的挑战
01 • 旷视是做什么的
• AI产品开发特点是什么
• 旷视研发效能中面对的挑战有哪些

5. 旷视是做什么的
消费物联网 城市物联网 供应链物联网
智慧物流
消费电子
SaaS
智慧城市
楼宇园区
智慧物流
工业自动化
旷视成立于2011年，是人工智能产品
和解决方案公司，目前专注于算法能创造
极大价值的领域：消费物联网、城市物联
网和供应链物联网。向客户提供包括算法、
软件和硬件产品在内的全栈式、一体化解
决方案。
MegEngine
深度学习框架
MegData
数据管理平台
MegCompute
深度学习云计算平台
Brain++

6. 算法落地链条长
算法产品化六字箴言：采洗标、训验推
AI产品开发的特点
私有化重交付
ToB为主：异构、定制化、迭代升级
多团队密切配合
多流程：SAFe/IPD
多团队配合是一项系统工程
数据采集 数据清洗 数据标注 模型训练 模型验证 模型发布
SDK集成
核心服务开发
伴随测试
核心服务
内部发布
伴随测试 业务系统开发
业务系统
内部发布
QA发版验证 交付中心
E2E验证
交付中心
现场交付
版本升级 长期维护
数据工程师 算法工程师
基础平台工程师
产品工程师
交付工程师/技术支持

7. 旷视在研发效能面临的挑战
产品线的快速增加，新人工程师的大量加入，
让整个组织复杂性提升，进而带来了熵增
建设一站式的研发效能平台 vs 目前各种团队
独立维护若干工具
更流畅的开发体验，更高的研发效率，
是AI产品竞争力的一部分
从算法生产、SDK集成、业务开发再到内部
E2E测试、发布、交付，最后是现场运维、
升级补丁，全流程都需要标准化
规模扩大带来复杂性提升
研发流程标准化
烟囱林立的各种内部系统
研发服务器重资产
私有化困境
熵增 孤岛
重资产
效率
标准化 私有化
旷视
研发效能挑战
6K+ 服务器、1.3w+ 显卡供内部开发、
测试使用，如何统一池化管理，降本增
效是逃不掉的话题
离线运行、全程断网、非SRE实施、长时间无人
值守、非标场景多
Time To Market

8. 私有化场景的具体问题&挑战
私有化交付中大家都在问什么？
1. 产品交付、运维的规范和流程是什么？如何部署？
2. 没法远程到现场，如何OnCall？
3. 运维巡检时，我该做点啥？
4. 现场网络好像有问题，我要怎么排查？
5. 数据库数据被误删了，有办法恢复吗？
6. 机器断电宕机，电力恢复后机器无法启动怎么办？
7. 删除目录时不小心多写了个空格，变成了rm -rf / xxx，马上就终止但好像系统挂了，怎么办？
旷视AI产品当前主要是针对私有化、ToB场景的
旷视在城市物联网、供应链物联网所涉及的AI产品，当前阶段主要场景都是以私有化方式交
付为主的，这深刻影响了产品研发模式、交付和运维方式。

9. 私有化场景的问题&挑战(2)
私有化交付挑战总结
2
1
3
4
6
5
私有化
• 离线运行、全程断网
非SA实施
• 技术支持/项目经理/集成商
运维条件恶劣
• 长时间无人值守
• 操作和问题反馈完全依赖现场人员
部署形态
• 部署方案实施前确定
• 升级、扩容需求
项目多且杂
• 1000+ 现场
• 10+ 业务线
异构性
• 体系结构、OS、显卡
• 机器规模1-500、多种网络

10. 01
技术工具演进不一
CI场景具体问题
02
CI机器资源浪费或不足
03
• Gitlab-CI无共用CI组件功能。
• Jenkins 自定义插件有一定门槛且不易
用、不稳定。
• 无法在内部使用更现代化的Circle Orbs
或Github Action 共享CI机制。
• 没有工具化、开箱即用的CI最佳实践。
不易复用自研的CI组件
04
“粘合剂”效果差
旷视传统的CI，以Jenkins、Gitlab-CI、放弃CI三大工具为主，彻底散养，各自为政。
• 团队CI各自为政，导致CI资源要么不够
用、要么浪费。
• 没有CI资源池或机器池，想推广CICD实
践的团队第一步就是去申请机器、搭环
境、接入各种系统，做了半天，业务系
统也没用上CICD。
• 上古时代的Jenkins，一个高可用需求会
劝退很多团队且安全性堪忧。
• Gitlab-CI与Code部分集成足够简单，
但用起来各种小毛病，且无法满足复杂
CI需求，比如E2E测试、人工卡点等。
• 公司内总是充斥着各种内部支撑系统(权
限、认证、SSO、IM)，各种自研PaaS
类平台(DevOps、MCD、Brain++)，
可能要做着重复的、hack的、不顺滑的
Jenkins/Gitlab对接工作。

11. AI训练场景具体问题
易用性
让算法工程师如何“零”
学习成本的开启和调试训
练任务，如何简单的“召
唤”海量显卡进行运算。
AI训练问题
流水线
AI训练平台如何与数据来源
的采集-清洗-标注平台打通，
如何与模型去处的集成-部
署-私有化形成流水线。
海量存储
存储一方面是几十PB的数据
如何安全存储，一方面是海
量小文如何高效加速读取。
硬件成本和运维
4000台机器、13000
张显卡形成的算力池，
如何提升利用率，如何
低成本的运维。

12. 提升研发效能的手段
流程机制
敏捷开发、IPD等，提升多团队协作能力
工具平台
最大程度实现团队流程、机制的一致性
人员能力
Code编写及Review规范等
研发效能
提升手段

13. “
”
从研发到交付的全流程PaaS
平台实践
02 • 设计思路
• 设计过程
• 当前状态
• 核心功能漫游

14. 导航
旷视研发效能中面临的挑战
旷视研发效能建设全景图
从研发到交付全流程PaaS台实践
设计思路 设计过程 当前状态 核心功能漫游
DevOps软件开发过程
云原生挑战
PaaS定位
设计原则
设计关键点
整体架构
功能分层图
承载应用规模
演进过程
可观测性
基础设施
私有化
Service Mesh
边缘计算

15. 设计思路：回顾一下典型的DevOps软件研发过程
需求阶段 开发测试阶段 部署上线阶段
业务需求
Merge
Request
部署 版本交付 客户交付
需求设计 Coding 构建 测试 部署上线
想法
需求分析
PRD管理
UT
代码扫描
Code Review
架构设计
代码编写
编译打包
Docker镜
像
测试用例 监控告警
预发布环境 版本管理
运维巡检
OnCall工单
用户

16. 设计思路：云原生时代
IaaS 上云 PaaS 上云
1. 关键：对应用无侵入
2. 特征：计算、存储和网络
3. 技术：
• 虚拟化、OpenStack
• AWS、阿里云
1. 关键：直接影响应用架构
2. 特征：数据库、中间件、可观测性、应用生命周期
托管
3. 技术：
• Docker、Kubernetes、Service Mesh
• IaC、GitOps、BaaS
4. 核心问题
• 业务无关能力如何解耦到平台？
• 平台与业务之间协议如何定义？
• 业务如何不被特定平台绑定？
• 应用架构如何调整？
公有云IaaS + Kubernetes + CI

17. 设计思路：云原生挑战
1.云资源与DevOps平台割裂的体验
DevOps流程中充斥着大量外部平台(xx
云控制台操作工程师)创建过程，整体工
作效率不高。
问题：使用了类似阿里云/AWS这类公有云IaaS服务和Kubernetes，再加上一点CI，跟内部Gitlab打通，就能满足公司内部
PaaS平台需求，就是云原生时代的PaaS平台吗？能满足DevOps目标吗？
2.研发/运维/基础设施关注点耦合 3.企业内部的种种特例
K8s YAML中没有App概念、其定位也
不是终端用户。
1. 混合云：自建IDC、多厂商的公有云、客
户专有云接入。
2. 企业内部研发流程整合：权限、私有代码
源、加密授权、复杂上线审批等。
3. 企业内部资源复用：CI、最佳实践沉淀。

18. 设计思路：内部PaaS定位
1. DevOps软件研发过程是比较实际的，对企业研发效能提升有帮助，需要一个PaaS平台来做支撑。
2. 云原生时代下，PaaS平台的构建也要用相关技术，典型的就是Kubernetes。
3. Kubernetes抽象层次低，定位一个分布式操作系统的内核，不是一个PaaS平台。
调
研
结
论
面向公司全体研发，混合云场景下，在Kubernetes的基础上定义Application概念，提供基于
Gitlab的CI和应用周边基础设施，形成内部完善的PaaS平台，让业务程序向云原生架构演进，提升
DevOps水平和整体研发效能。
名称：Megvii Cloud DevOps Platform = MCD
定
位

19. 设计思路：功能上最初的想法

20. 导航
旷视研发效能中面临的挑战
旷视研发效能建设全景图
从研发到交付全流程PaaS台实践
设计思路 设计过程 当前状态 核心功能漫游
DevOps软件开发过程
云原生挑战
PaaS定位
设计原则
设计关键点
整体架构
功能分层图
承载应用规模
演进过程
可观测性
基础设施
私有化
Service Mesh
边缘计算

21. 设计过程
1. 从开发者视角(Dev/QA/Support)出发，屏蔽K8s复杂的细节。
2. 讲究不同组件的配合，单一工具要尽量满足KISS原则。
3. PaaS化的顶层全流程设计，但每个环节可以在一定规约下进
行工具替换。
设计原则
基本问题
1. DevOps软件开发过程是什么？
• DevOps 不是将每个Dev都变成Ops，而是所有工程师
在统一世界观的前提下，在一个不断演进的底层平台上，
完成研发全流程，提升TTM(Time To Market)的时间。
2. 专有PaaS在企业内部有生命力吗？
• 企业内部的PaaS是一个需求收敛的平台，具备扩展性但
不是让每个开发者都承担扩整性的成本开销，核心是提
升公司整体的开发体验和效率。
3. MCD 平台对内部意味着什么？
• 对于开发者，尽可能屏蔽底层细节，专注于业务自身。
• 对于QA，尽可能简化环境复现，随时复制和销毁环境。
• 对于交付同学，尽可能界面化操作，不需要写code，
绝大部分交付不需要学习k8s等，只专注与业务相关的
配置，并保证交付过程足够标准化。
设计关键

22. 设计过程：概念模型定义
1. MCD对应N个IDC，SA规划
2. 1个IDC对应N个K8s集群，SA规划
3. 1个K8s集群对应N个节点池，SA规划
4. 1个K8s集群对应N个产品线，业务规划
5. 1个专属节点池属于某个产品线，SA规划
6. 1个产品线包含N个App，业务规划
7. 1个产品线对应1个K8s的namespace
8. App name 在MCD层面全局唯一
9. 一个App对应一个Gitlab上的某个Repo的
app.yaml 或某个AppPackage的app.yaml
10. 一个App有多个Component，可以依赖
多个Infra
11. Infra可以是产品线级别或Cluster级别或
IDC级别的
12. 每个App有自己的Infra隔离
IDC: 自建IDC、阿里云、客户私有IDC
Cluster：Kubernetes集群
NodePool：专属节点池、通用节点池
AppPool：K8s中Namespace、环境
Application：应用
Infra:
基础设施
Component: 工作负载
Web Service
Cron Daemon
Job Infra

23. 设计过程： app.yaml
Kubernetes YAML困扰
1. 开发者视角：不照搬Kubernetes YAML，从开发者角度出发，
对开发者友好，并有较大的灵活性。
2. 配置分离：将某些运营类配置放到MCD Web中，比如
Release Manager、AutoScale策略、ConfigMap、自定义
告警等，保证Code Repo中app.yaml是与代码逻辑有密切
关系的。
3. 映射原则：每个app.yaml对应MCD中的一个产品线中的一
个app，产品线可以自由复制；每个Code Repo可以有多个
app.yaml；离线部署是从AppPackage为起点，绑定一个
app.yaml。
设计原则

24. 设计过程： app.yaml
Component抽象
Web：HTTP(s)服务，对应K8s中Deployment或
StatefulSet(极少)，会自动创建Service、Ingress和内部
域名，绝大部分为无状态服务。
Service: 微服务，没有HTTP的K8s Deployment或
StatefulSet (极少)，并非K8s中Service概念，绝大部分
为无状态服务，对内提供TCP/UDP的RPC服务。
Daemon：MQ Worker 或Daemon，用来执行常驻任
务，不是K8s中的Daemonset，不需要对外提供HTTP、
RPC服务，也不需要对应的域名、Service和Ingress。
Cron：定时任务，对应K8s的CronJob。
Job：一次性任务，mcd-cli或MCD Web手工触发执行，
对应K8s的Job。
Infra：提供开箱即用的基础设施，不用关心运维、
高可用、灾备和性能调优等话题，提供app级别隔
离机制，多为自定义的开源软件 Helm包部署到
MCD中。

25. 设计过程：最小的应用
Dockerfile
app.yaml
1
定义应用形态与抽象
app.py
2
3
定义应用自身逻辑
定义镜像构建方法

26. 设计过程：最小的应用
一个MCD中的最简单的App，意味着自带了如下能力：
1. 一个内部域名：${appname}.mcd.megvii-inc.com。
2. 一个permdir目录：是一个持久化的、分布式的App存储目录，创建App后即可使用。
3. 一个CI流程：每个mcd app都至少有一个内建的CI流程，用来实现代码构建和镜像分发，同
时有一个完整的Pipeline产品提供底层支撑，可以做自定义，类似Github Action。
4. 一套监控告警：能对app web流量、资源使用等进行指标采集、监控和告警推送。
5. 天然私有化：部署到MCD中的app，都可以不做任何业务代码的变更，实现客户隔离环境的
私有化。
6. 一套常用的基础设施：数据库、队列、缓存等基础设施，开箱即用。
开发者不用关心CI如何搭建、机器资源如何申请，不用学习和运维复杂的K8s，不用
思考如何私有化，可以更专注于业务自身。

27. 设计过程：系统架构
MCD-Cli、MCD Portal Web
接入层
Runtime层
app.yaml 解析与映射
App Component 转化
App 监控映射 App 告警关联
Infra CRD
Infra Controller
GitOps 关联 账户
权限
依赖层
数据库 可观测性
基础设施 调度
存储
调试
边缘计算
MCD-Agent
Service Mesh
底层基座
BootOS

28. 设计过程：功能分层
集群运维
App
可观测性
监
控
告
警
观
测
台
节点层面
Kubernetes层
面
内建60+告警
内建200+监控
内建App层面告警 自定义告警
自定义MCD仪表盘
监
控
告
警
基
础
环
境
内核参数优化
NTP时间同步
Cron.d/resolv.co
nfd等配置同步
上游DNS配置
自定义Prometheus
监控
自定义Probe监控
内建App层面监控
日
志
Pod实时日志
Loki高级日志(主)
开发者工具 mcd-cli Debug SideCar
K8s事件审计
告警静默 内建告警模板修改
Pod状态 MCD操作审计
App管理与
生命周期
追
溯
基于Trace的告警
事件追溯
内建日志趋势统计 Jaeger 调用链
Java Agent自动注入
OpenTelemetry
集中观测台 产品线应用依赖图
资源计费
Web
Terminal
操作回放
文件操作
mcd-go-sdk
JVM观测
Permdir
实时K8s事件流
Sentry无缝集成
内
建
资
源
内部域名
版
本
来
源
GitOps(在线)
访
问
应用路由 外部域名 TLS证书 OAuth代理
调用链高级搜索
AppPackage(离线)
应
用
部
署
常规部署
回滚
灰
度
灰度
权重
Header
灰度
Cookie
灰度
强制
部署
条件
组合
tag
Web
审核
记录
多阶段审核
审核自定义
预
发
布
任意点创建
Pre独立域名
Pre固定域名
Pre自动回收
配
置
历史变更 回滚 热更新 确认更新
多种
模式
环境变量
文件挂载
Sidecar 镜像
Go模板渲染
内网临时端口访
问机制
工
作
负
载
Fast-
Permdir
Service
Cron
Daemon
Job
自定义
app
yaml
appname
runtime
infra
app_dep
atp(CI)
与主app
同等的
监控告警
commit
应
用
管
理
全局
Dashboard
MCD
Status
全局SLA
关键组件SLA
旁路检测
多
集
群
自建Kubernetes集群
阿里云ACK
Brain++
其他第三方Kubernetes
多
IDC
联动
BootOS
基础OS
环境
集
群
管
理
节点超售
专用节点池
K9s + kubectl web终端
产品线
基
础
设
施
集群维度
产品线维度
Infra Operator
内建48个
可自选的
基础设施
Web参数定义
Helm集成
单机+高可用
基础设施
标准化
监控运维
app.yaml
infra依赖
自动注入
隔离机制
MCD及K8s
自身依赖
基础设施
托管
产
品
线
快照离线导出导入
产品线快照
产品线复制
Namespace隔离
批量部署
API-Gateway
ServiceMesh
多环境递进式
研发模式
资源配额
产品线观测台
产品线事件追溯
TLS证书管理
产品线业务配置
节点池绑定
通知
钉钉/邮件
副本/资源变更
上线/告警
阿里云ARMS启用
下线
邮件服务器
Ingress/LVS
K8s密钥管理
关联DevOps
DevOps
托管
1:1绑定
syslog
IPMI转储
CI无缝集成
Gitlab集成
Pipeline底层支撑
开发环境
完全私有化
设
备
NVIDIA显卡
MC40
寒武纪
加密授权托管
全界面化集群安装
ES
日
志
(备)
调
度
自动水平扩展HPA
资源设置
部署
策略
垂直扩展VPA建议
多维度亲和性设置
个人页|定制仪表盘
本地-云端联调
VSCode插件
边缘
计算
KubeEdge集成
MCD
Agent
k3s集成
Tunnel隧道
KubeEdge Model
API
App边缘模式

29. 设计过程：推荐发布过程

30. 设计过程：MCD的特点总结
1. 万物起点是Application
• 以App为基础进行构建、资源抽象、权限管
理，并将监控、告警、可观测性完全融入到
App的概念中。
2. 与Commit关联的发布机制
• 不管是公有云或公司内部的GitOps，还是私有
化中AppPackage机制，部署记录都能追溯到
代码的某个commit，确保版本无歧义。
3. 面向开发者，屏蔽Kubernetes细节
• 通过自定义的app.yaml和从内部实践推导出来的
特定工作负载，易用开发者使用，不用陷入K8s
yaml和各种概念细节中，较高层次抽象。
4.与环境无关
• 适配任意K8s集群和云环境，同时应用一旦
在MCD集群运行起来，就能实现私有化，实
现与底层环境无关。

31. 设计过程：MCD与研发效能挑战的映射关系
1.规模扩大带来
复杂性提升
3.研发流程
标准化
4.烟囱林立的
各种内部系统
5.研发服务器
重资产
6.私有化
困境
熵增 孤岛
重资
产
效率
标准
化
私有
化
旷视
研发效能挑战
2.Time To
Market
1. 复杂性：MCD屏蔽K8s细节，提供完全面向开发者的应用抽象，最大程度降低开发者层面的复杂性。
2. TTM：减少开发者与业务核心逻辑无关的工作，缩短发布周期。
3. 流程标准化：MCD在CI、CD、部署、交付、可观性等方面做最大程度标准化，开箱即用。
4. 烟囱林立：MCD目标是在PaaS层面做一站式的平台。
5. 服务器池化：MCD使用者不感知集群、机器的存在，MCD做资源池化。
6. 私有化：MCD在K8s、App和MCD自身三种层面做私有化，提供某种范式下的私有化交付的能力。

32. 导航
旷视研发效能中面临的挑战
旷视研发效能建设全景图
从研发到交付全流程PaaS台实践
设计思路 设计过程 当前状态 核心功能漫游
DevOps软件开发过程
云原生挑战
PaaS定位
设计原则
设计关键点
整体架构
功能分层图
承载应用规模
演进过程
可观测性
基础设施
私有化
Service Mesh
边缘计算

33. 状态与演进
集群20个 应用部署 35519次
应用1377个 产品线113个
MCD 2020.7.1 正式上线
MCD版本迭代300次
提升：MCD在旷视内部第一次实现了面向公司级别的PaaS平台，结束
了之前虚拟机+nohup的应用托管方式。

34. 导航
旷视研发效能中面临的挑战
旷视研发效能建设全景图
从研发到交付全流程PaaS台实践
设计思路 设计过程 当前状态 核心功能漫游
DevOps软件开发过程
云原生挑战
PaaS定位
设计原则
设计关键点
整体架构
功能分层图
承载应用规模
演进过程
可观测性
基础设施
私有化
Service Mesh
边缘计算

35. 核心功能漫游

36. MCD App Dashboard UI

37. 开发者工具：MCD-Cli
1. app的初始化脚手架，支持自定义模板。
• 比如实现在内部一键创建一个Java或Golang类
型的MVP应用。
• 由于可以自定义模板并在内部集中注册，让最佳
实践的app从零创建变得可行。
2. 本地-远端便携调试功能
• 支持try-run功能，实现本地环境的一键启动和
快速验证。
• 本地与远端文件相互复制功能。
• app远端端口转发到本地端口，进行本地微服务
联调。
3. 私有化支撑
• 产品线snapshot的导出与下载。
MCD-Cli实现MCD Portal Web绝大部分操作功能
创建一个Golang类型最小App过程
1.如何创建一个应用？

38. 开发者工具：CI与Pipeline
2.如何对一个应用进行构建？
• 低操作成本：绝大部分应用只需要定义好Dockerfile和Makefile中docker-build-prepare section(optional)，就能自动与Gitlab Commit事件联动、CI自动构建、Pipeline自动绑定。
• 灵活扩展：当默认构建不满足要求或需要更复杂的CI支持时，可以编写类似Github Action的atp-ci.yaml，实现最大程度的定制化CI。
• CI共享：MCD CI背后由一个独立的产品Pipeline支持，可以实现各种级别的Action共享，包括step级别、task级别、job级别。

39. 开发者工具：CI与Pipeline(2)
2.如何对一个应用进行构建？
概念抽象：
1. 1个app可以包含n个workflow，workflow之间并行运行。
2. 1个workflow包含n个job，默认并行，可以设置needs参数，实现DAG依赖执行。每个Job对应一个runner。
3. 1个job可以包含n个step，串行执行，step之间共享存储上下文。
4. 1个code repo可以关联多个pipeline中的project，根据不同的触发条件进行区分和定制化。
5. Step/Workflow/Job都可以被实现为Action，进行CI共享。

40. App部署
3.如何对一个应用进行部署？

41. 可观测性
4.如何观测一个应用？
CNCF 技术雷达-可观测性工具
DORA(DevOps 研究与评估)定义：
监控是可以帮助团队观察和了解系统状态的工具或方案，用于收集一组预定义的指
标或日志。
可观测性是可以帮助团队有效调试其系统的工具或方案，基于对实现未定义的属性
和模式的探索。
监控和可观测性是一组推动实现更出色的软件交付表现和组织绩效的能力之一。

42. 可观测性(2)
4.如何观测一个应用？
Metrics：
- Prometheus + 各种Exporter，每个app都要暴露
metrics出来，将自身变成exporter
Logging：
- Loki 轻量易用，易于私有化
- Loki 与Grafana、Prometheus完美结合
- 提供产品线的全局遥测页面
Tracing：
- OpenTelemetry +Jaeger，并与loki联动
- Java runtime app自动注入agent，提供JVM观测
Events：
- K8s Events 按照节点、产品线、App、Pod实现不同维度
的分类存储，并存储到Loki中，实现日志联动
- Node Events记录syslog/kern.log/ipmi等关键点
- MCD 每个非GET操作、Web Terminal都被记录
Alert：
- 自定义与内建告警、日志关键词、Trace记录、Metrics指
标、Events事件都可以作为Alertmanager通知的内容
- MCD Web界面、钉钉、邮件多种通知渠道

43. 可观测性(3)
4.如何观测一个应用？
产品线遥测页面
Trace可查询 可定制的个人Dashboard页面
Logging-Tracing联动

44. 基础设施
5. 应用如何使用最佳实践的基础设施？
1. 内建基础设施，app.yaml中声明式使用
• app.yaml 声明infra字段，默认就会创建该app
独享的基础设施，相关连接信息等被自动注入
到app Env中。
2. 多种隔离级别
• 产品线、K8s集群、IDC三种级别的基础设施部
署。
3. 运维保证，开箱即用
• 围绕各种基础设施，逐步建设完整的监控、告
警、灾备、高可用、私有化等方案。
• MCD 内建各种数据库的命令行控制工具，提供
类似dbshell的功能。
• 基础设施可以通过Web界面设置，实现可配置。
• 数据库、KV、队列服务、OSS

45. Service Mesh
6. 应用如何更好的服务化？
应用场景
IAP：通过Service Mesh Sidecar方式在旁路做请求拦截和OAuth
Proxy，并将用户信息以JWT方式传递给后台应用。
产品线级别微服务：
• 产品线 API Gateway
• 服务拓扑展示
• API级别观测性
• 服务级别的Trace呈现
产品线级别(默认)
LoadBalancer
App Component
Sidecar Proxy
App Component
Sidecar Proxy
Pod Pod
CNI CNI

46. 私有化
7. 如何把一个应用私有化？
MCD App与环境无关，可以实现一定程度的私有化
App私有化
MCD私有化
1
• 机器层面：建立在BootOS和私有云DevOps平台基础之上，由
DevOps托管机器环境、基础依赖(Docker Registry、数据库、etcd、
lvs)、加密授权等
• K8s层面：DevOps实现Web界面化的一键K8s/K3s安装、升级和运维。
• MCD层面：DevOps Web一键部署初始态MCD和基础设施依赖绑定。
AppPackge形态
2
3
• Snapshot机制：产品线、App的snapshot标记(定版)、snapshot导
出(发布)、snapshot导入(部署)、参数配置(现场环境适配)和批量部署。
• K8s YAML导出：自动将mcd app.yaml翻译成原生的k8s yaml，方
便部署到受限的第三方基于K8s开发的云平台上。
• Package机制：不同于GitOps，实现与Git的解耦，实现类似Helm的
Package管理机制，并也以Application抽象为中心。
AppPackage功能

47. 私有化：snapshot流程
7. 如何把一个应用私有化？
Step1：标记快照 Step2：快照下载
Step3：快照导入
Step4：更新部署

48. 边缘计算
边缘设备场景
• 方案：KubeEdge + MCD-Agent Device API
• 特点：
• MCD内建KubeEdge，按需使用。
• 通过MCD HTTP API 对Device/DeviceModel进行操作，在上层继续封装边缘设备管
理的业务程序，避免业务程序直接调用Kubernetes CRD API。
服务器单向网络或弱网场景
• 方案：MCD-Agent Tunnel
• 特点：在单向网络或弱网场景中，可以通过MCD-Agent内建的GRPC
Tunnel 实现通信(参考SuperEdge)。
轻量化算力盒子场景(旷视鸿图2000)
• 方案：K3s + MCD-lite +DevOps-Lite
• 特点：资源受限的算力盒子上，提供单机或集群的基本完整的
MCD PaaS功能，便于对算力芯片管理和服务部署。
MCD
边缘方案
8. 如何把一个应用部署到边缘集群？

49. “
”
旷视研发效能建设全景图和展望
03 • 工具全景图
• 下一步展望

50. 工具全景图
算法训练阶段 算法工程化和业务开发阶段 QA验证和发版阶段 现场交付阶段
算法工程师
研究员
平台工程师
产品工程师
QA
交付技术支持
交付技术支持
项目经理
深度学习框架
AI生产力平台
Ceph RBD块存储
自研100PB
的OSS
小文件加速
服务
存储
平台
框架
CI
平台
自研CI基础设施
私有云DevOps平台
PaaS平台
AI生产力平台-私有
化版本
定制OS发行版
测试平台
软件发布
DevOps-Orch
编排系统
SDC
统一的软件发布托管
ATP 业务集成测试平台
交付工具链
自研授权服务
DevOps-Import
运维巡检
DevOps-Swarm
运维中心

51. 下一步展望
01
02
03
PaaS平台演进
一站式研发效能平台
统一算力池
• 私有化（Kubernetes私有化托管）、可观测性(eBPF
的结合)。
• 进一步将AI训练、CICD、私有化部署等
环节无缝衔接，让流程更顺滑。
• Brain++ 托管旷视所有服务器，提供
统一的算力池。

52. 问答时间
谢谢