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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. DevOps软件开发过程是什么？ • 1. 从开发者视角(Dev/QA/Support)出发，屏蔽K8s复杂的细节。 DevOps 不是将每个Dev都变成Ops，而是所有工程师 2. 讲究不同组件的配合，单一工具要尽量满足KISS原则。 在统一世界观的前提下，在一个不断演进的底层平台上， 3. PaaS化的顶层全流程设计，但每个环节可以在一定规约下进 完成研发全流程，提升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个产品线，业务规划 Web Service Cron Daemon Job Infra 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 Component: 工作负载 Application：应用 Infra: 基础设施 10. 一个App有多个Component，可以依赖 多个Infra 11. Infra可以是产品线级别或Cluster级别或 AppPool：K8s中Namespace、环境 NodePool：专属节点池、通用节点池 Cluster：Kubernetes集群 IDC: 自建IDC、阿里云、客户私有IDC IDC级别的 12. 每个App有自己的Infra隔离

23. 设计过程： app.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。 Kubernetes 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. 设计过程：最小的应用 1 app.yaml 定义应用形态与抽象 2 Dockerfile 定义镜像构建方法 3 app.py 定义应用自身逻辑

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 解析与映射 GitOps 关联 App Component 转化 Infra CRD App 监控映射 App 告警关联 Infra Controller 账户 权限 依赖层 基础设施 调试 可观测性 数据库 MCD-Agent 底层基座 调度 边缘计算 存储 Service Mesh BootOS

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

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

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

31. 设计过程：MCD与研发效能挑战的映射关系 1.规模扩大带来 复杂性提升 2.Time To Market 效率 3.研发流程 标准化 熵增 孤岛 旷视 研发效能挑战 标准 化 私有 化 4.烟囱林立的 各种内部系统 重资 产 5.研发服务器 重资产 6.私有化 困境 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. 状态与演进 MCD 2020.7.1 正式上线 应用1490个 产品线106个 集群20个 应用部署 35519次 提升：MCD在旷视内部第一次实现了面向公司级别的PaaS平台，结束 了之前虚拟机+nohup的应用托管方式。 MCD版本迭代300次

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

35. 核心功能漫游

36. MCD App Dashboard UI

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

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

42. 4.如何观测一个应用？ 可观测性(2) 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. 4.如何观测一个应用？ 可观测性(3) 产品线遥测页面 Trace可查询 Logging-Tracing联动 可定制的个人Dashboard页面

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

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

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

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

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

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

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

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

52. 问答时间 谢谢