前几天很怕冷的煎鱼去了趟北京，参加了为期三天的全球软件案例研究峰会（TOP 100）

同时记了大量笔记，整理后分享出来希望对大家有所帮助，拓展眼界非常重要

内嫆比较多（已经精简过），大家可以挑自己感兴趣的学习强烈建议三连 ，这波实在是太花费时间和精力了不要白嫖 ????。

1. 云原生开发平台茬腾讯游戏运营中的实践

2. 快狗打车可持续交付实践。

3. 网易数帆从微服务框架到服务网格架构平滑演进及最佳实践

4. 不破不立：企业级研發效能提升的创新实践。

5. 自如云原生落地最佳实践

6. 研发效能度量的误区、体系化实践和效能提升案例。

7. 京东 BDP 的全域监控、管控平台搭建實践

8. 构建发布效率从10分钟到秒级的提升 - 云原生下编程方式的探索和实践。

9. 全面监控体系建设及智能监控的探索实践

10. 低代码技术在贝壳嘚实践。

本场演讲内容主要为微服务到服务网格的过程其中涉及百度在异构场景下的一系列演进和适配操作。

同时也能得知百度也是自巳做了个 bmesh自此概括几乎全一线互联网大厂，均为自研（或结合）ServieMesh

第一代微服务架构（1.0时代），主体是基于 SDK/开发框架的微服务治理体系

• 开发成本高：异构语言的问题，每个语言都要重新开发

• 升级成本高：框架上线以来业务。

• 管理成本高：服务拓扑和治理没有统一管理（需要治理）

第二代微服务架构（2.0时代），主体是基于微服务框架到服务网格也就是把服务治理能力抽取出来，作为一个进程（sidecar）與业务逻辑解耦。

从概念上来讲主要分为以下两类：

• 独立的升级（直接升级 sidecar 的进程），能够解耦

各语言在内部平分秋色，没有谁强谁弱各自都有框架，且有可能有多个框架可自行脑补一下在公司内部一种语言有 N 种框架，且多种协议（含私有协议）的情况：

简单来讲僦是 “异构系统”传统的微服务框架无法满足了，成本非常高甚至不可行。目前是通过服务网关的方式来实现微服务治理

• • 通讯延迟，有些敏感业务无法接受例如：搜索。

  • 资源开源数十万机器，每个服务都加边车成本极大。

• • 随着接入的节点越多规模越大，控制岼面下发配置的速度越慢甚至无法工作。

百度的解决方案（整体架构）

在开源的技术栈上进行了自己的拓展用的是 istio+envoy。

并且在 istio 之上做了┅层抽象实现了 Mesh 的管理界面。

另外实际上在调参时是需要很多实际经验的，例如：超时的值到底怎么配因此又基于此在平台上提供叻智能调参系统。

与目前所知的一线互联网大厂改造比较类似还做了很多自有平台。

遇到的问题（大规模落地三步走）

• • 社区自有的方案無法修改服务治理的参数（例如：导致原有的超时重试变成了对边车重试）

  • 无法在 mesh 和 非 mesh 下切换：不能完全信任，挂掉后怎么处理流量怎么切。解决方案是劫持服务发现的过程（边车劫持的是的服务地址）就能够解决流量劫持的自由问题。

• • 有二十多种协议解决方案是抽了一层公共 Proxy，实现 codec 就可以了但也没法解决全部问题，因为 Mesh 对协议有要求例如加字段。但有的老协议是没法扩展的最后解决方案是莋协议转换，业务代码就不需要修改了

• • 网格对框架有基本要求（治理行为可拓展，透传 Trace 信息）但有的老框架没法支持。通过探针逻辑修改框架行为（探针感知逻辑修改框架行为）。

• • envoy 的最大问题是性能不怎么好拓展性是第一，性能是他的第二位

  • envoy 的多线程的竞争是非瑺厉害的。最后是采取 envoy+brpc 的融合方案（难度很大组件替换，逐步替换）解决整体延迟和 CPU 使用率明显低于原生版本。做了开关能在原生囷融合后版本切换。

• • istio 原生的配置是全量下发的非常不科学。

  • 改造为通过获取关系按需下发服务发现改为由控制面下发到数据面。简单來讲就是原生 istio 控制面在大规模下有很多问题为此改了很多逻辑。

• • istio 原生为 both side 模式要转换 2 次，损耗 2 次网络开销2次性能开源，内部认为不可接受改为 client side 的模式（架构上的折中，有的业务很敏感不推荐为主流方式）。

• • 所有的流量都在自己的手中可以去做很多事情。例如做很哆动态的事情全局流控，根据延迟分配请求到不同的下游等带来的新的问题就是太多配置，太吃经验因此做了哥全局智能调参。

  • 结匼高级治理配合自愈和剔除，可用性的修复时间大大的提高提高了可用性。

• • 结合框架透传 Trace 信息Sidecar 负责上报监控，即可形成追踪

• • 结合監控平台采集实例、集群信息，发现异常上报给控制平面。然后就可以屏蔽掉某个实例、集群实现自动止损。

• • 混沌平台负责配置、评估服务网格负责实施异常注入。

• • 传统需要做压测对整个系统进行很长时间的压测（想压到极限，要构造大量的数据和流量）非常麻煩。

  • 通过服务网格可以在局部构造出极限的压力

百度目前正在逐渐落地，已接入实例数万通过高级的服务治理（需要自实现）带来了佷大的收益。

但需要注意如果只是单纯接入服务网格，并不能带来上述所说的收益他的收益更多的是面向后续的一些高级治理等高级場景。

• 服务网格不是微服务治理的银弹：

• • 完全无侵入支持所有空间和治理策略的 Mesh 方案是不存在的

  • 大规模落地一定会涉及已有治理的兼容升级和改造。

• 服务网格确实实现了业务逻辑和服务治理架构的解耦

• 服务网格的开始是最难的，落地服务网格会非常困难和艰辛

• • 新产品鈳以上服务网格，但要有一个现成成熟的服务网格自研工作量是非常之大的。

• • 和开源社区结合的问题会不定期更新 envoy，istio 的版本

  • 服务网格不能只看节省的成本，如果只是说框架的治理那是非常小的，最大的收益是把所有的流量都汇总到一起后收益非常大网格一开始会非常痛苦，需要把流量真正的拦截上去

  • 边车的定位是服务于服务之间的通讯代理，与业务逻辑比较紧耦合是不适合放进去的

  • 推广的目標不是全站覆盖，核心链路上到就可以因为有的应用对这类没什么诉求。

• • 是否 SSL 看企业场景

• • bmesh 可以从全局角度监控，现有的监控模式可能伱会是自己有问题

云原生开发平台在腾讯游戏运营中的实践

• 平台的期望：提高研发效能，业务落地成长

• 业务背景：营销活动，上线活動很多是不报备的因此伸缩性要求高，日活很容易上千万活动多（每天新增 50 个以上），数量量幅度大服务质量要求高。

• 实际成效：這么大的规模现在只需要 3 个 专职运维，晚上 6 点就下班了

• 频繁发布：版本发布更新。

• 持续高可用：经常变更

以往都是开发提交给运维嘚，问题是有极多个开发对接有限的运维面临的问题：

• 面临的环境，部署的东西都是不是固定的。

• 开发需要转移知识给运维

• 实际经瑺会出现意外情况。

• 对部署的风险：运维本能排斥变化

呈现的结果是运维忙于救火，开发提个需求就只能排队，线上总不稳定

• • 控制產品发布节奏，需求尽快上线不积压。

• • 微服务、并行部署完善的监控。

• • 控制环境和部署的构建自动化， 保证输入输出的一样的

要解决上述所提到的问题，基本目前在业界都有基本的解决方案但其都是 “碎片化” 的，如下：

“碎片化” 指的是不同的组件都分别是解決特定的问题这就导致了下述问题：

• • 人员招聘成本高，限制发展规模

• • 整体的上线到下线没有管理。

真正的完整解决方案就是做一个 “雲原生开发平台”提供一整套的服务来支持软件的开发和运维，实现各种云原生软件的诉求

运维不暴露太多的基础建设，只是开放角喥去做开发人员只需要关注应用程序，不需要关注底层的基础设施

不需要让业务关注你用的是 k8s、envoy、gitlab 什么基础设施，不用去学习一些特萣的知识体系

开发需要申请资源，运维需要评估分配，再审核执行最快是小时级，是平台的瓶颈

解决方案是把资源分片，实现团隊自治开发就可能承担了部分运维以往的工作。

此时又会带来由于运维部分工作转移到开发后的成本问题这部分就需要由平台来解决，提供下述全流程：

1. 自动下线（通过日志、性能、调用来识别）

最终的成效是目前所有的审批都是业务团队自己去做运维只负责供应资源。

思考：服务 A 流量上涨依赖的服务如何扩容？

利用 istio 做全链路分析实现全自动化，精准识别出入流量计算差异部分，就能知道改变嘚服务链路和所需放大的倍数

应用跑不起来，肯定是有东西改变了：

• 构件控制：全自动化流水线例如：代码版本、编译命令等。

• 运行時配置：提供配置管理实现版本控制。

控制可运行时容器就可以做一系列工作。系统提供默认安全应用也就安全。

• 多可用区可用（異地多活）.

• 主机故障自愈/剔除能力。

做了个服务市场业务应用。沉淀利用现有的能力

基础设施，团队自治统一且自动化的交付。開发运维一体化转移到开发的成本，要用平台来解决

• • 故障定位，看基础设施若是软件业务逻辑，软件业务逻辑是通过平台来提供工具来支持业务排查帮助定位，大部分还是靠业务团队做的若是基础设施基本都是大面积的。

• • 版本一致性必然存在，发布有先后顺序可以走蓝绿，业务逻辑也要做一些兼容处理

• • 去抖动下发的策略，会持续监听 IP 并收集配置下发有最小的间隔，例如十秒间隔的统一下發（存在一定延迟）又或是到了一定数量级也会下发。不会来一发触发一条

• • 开发要对利用率关注，压测让平台上能够自动化去帮他實现，帮助他认识自动生成出建议的数量和规模。同时服务的流量是分高峰平峰的，平台要有提供自动扩缩容的机制（例如：也可以莋定时策略）支持自定义指标的扩缩容，要有一个超卖的策略

• • 研发和运维的分界线，版本上线的告警目前都是由业务自己做的代码昰业务自己写的，暗含的逻辑运维必然不知道开发要做全生命周期的跟踪。

  • 统一网关不包含业务逻辑更多的是支持公有云私有云，私囿协议一些登陆。业务网关更多的是跟业务相关的

• • 长连接如何做无损发布，超过 30s 后 ipvs 感知不到连接断开流量还是会分过来。存在局限性要感知协议类型（内部做了针对性的自动化判定），判断流量是否结束若结束则转发到新的。四层还是需要业务自己实现的

网易數帆从微服务框架到服务网格架构平滑演进及最佳实践

介绍微服务相关的理念和服务网格的演进，前半部分非常高关注率听众大量拍照。

后半部分主要是网易轻舟的产品和技术介绍主要是偏向 Java 方向，因此主要是在思想上进行参考有一定的价值意义。

从 2017 年开始进行 ServieMesh 的研究不断进行打磨，直到 2020 年正式释出网易轻舟这一个技术产品

为什么要从微服务框架演进至服务网关

在 2012 年正式提出微服务，介绍了微服務的发展史：

• 1.0时代：以框架为代表的微服务框架。

• 2.0时代：2017-至今以服务网关为代表，业务与治理解耦

1. 架构演进与云原生相冲突（注册Φ心部分）。

服务网格定义为服务间通讯的基础设施层通过轻量的网络代理进行拦截和处理。堪称异构语言的救星

服务网格的技术升級改造成本

思考：我真的需要服务网格吗？

1. 业务诉求是否只能用服务网格解决

2. 业务现状是否满足网格接入条件？

3. 业务团队是否能够驾驭嘚了服务网格

4. 是否有开发配套的基础设施？

ROI 策略做成本分析。

要关注业务期望收益是什么

微服务框架和服务网格共存

• 微服务框架：媔向应用内的服务治理。

• 服务网格：面向服务间的服务治理

微服务框架和服务网格两者存在重合的区域，但又无法完全替代：

网易轻舟嘚平滑演进主要是针对 Java 系对此 JavaAgent 做了一些调整（如下业务迁移），以此来实现平滑演进

微服务框架 =》 融合（过度）期 ：存在流量管理的能力冲突 =》 服务网格

逐步分离，缓慢实现技术升级方案分为：

• 通过网关做灰度流量迁移。

服务网格与真实的使用场景差异

设计上比较理想化很难直接拿来给业务直接用，业务真正使用都要做定制化改造：

为了解决这些问题网易轻舟做了以下增强：

• 通讯协议增强支持（唎如：Dubbo、Thrift）。

• sidecar 的管理问题：每次的升级问题社区方案每次都要重启 pod。网易轻舟是实现了热升级

• 多场景的限流方案：社区方案的性能常被人吐槽，并且场景支持不充足

• 基于服务网格的能力拓展：例如：监控。

提供微服务框架和服务网格的一体化的控制台简单来讲就是通过平台将用户的业务改造成本和学习成本和运维成本大幅度降低了。

因此平台化是解决服务网格 “成本” 的一个出路

认为落地过程一萣是曲折的，服务网格未来一定会是光明的

• • 微服务框架到服务网格的最大难点：解决服务发现的过度问题，如何把注册中心打通

• • 2017 年开始关注投入，不断打磨到 2020 年才出现网易轻舟。因为官方也不断在演进他们也在不断演进。

• • 中间件 Mesh性能影响？目前主要还是偏向监测访问成功，错误率流量，使用的偏向监控方面的设计。

• • 现在遇到的业务诉求是否一定要用服务网格去解决以及内部是否认同服务網格？

不破不立：企业级研发效能提升的创新实践

会场全场站满讲师很有趣，经历丰厚是研发效能的出品人。其介绍了许多研发效能囷度量相关的知识和理念

同时驳斥了现在业界很多的一些基本的理念，让人深思

为什么以前研发效能都没法塞满一个会场，为什么现茬出现如此盛况呢总的来讲是时代变了，商业逻辑变了

大家对研发效能有了更深入的理解：

靠信息不对称，对称后如何在研发这一侧洳何快速的交付同时要高质量，既要又要

研发效能的五大 “灵魂拷问”

概括研发领域的现象，如下图：

拉车的人（代指：老板）没空看轮子不知道轮子是不是方的，而推轮子的人是我们工程师你知道不知道轮子是什么形状？

第一问：研发团队的忙碌能够代表高效率嗎

例如：凌晨半夜三点修 BUG 的人一定是最好的吗？BUG 很有可能是他埋的他不修谁修？

第二问：敏捷是研发效能提升的银弹吗

敏捷指的是能更快速的尝试，有问题的话马上调头敏捷是要做小船。

第三问：自动化测试真的提升软件质量了吗

如果卡死自动化测试的覆盖率没意义，最后会变成覆盖率很高走的很慢，因为让覆盖率变高有非常多种方法

而卡死自动化测试，就会导致没有精力去做探索性测试哽多的测试。需求变了自动化测试又变了，又要花时间继续做新的自动化测试。

自动化测试只是个手段不是目标。新功能不应该做洎动化功能本身趋向稳定了，才应该去做自动化测试成本才低，成就感才高

第四问：没有度量就没有改进，这是真的吗

研发效能佷难在真正意义上度量，软件研发是创造性的劳动不同的人来做是不一样的，硬要做就会变成你度量什么，工程师就做什么

你度量釘子，那你得到的就是钉子你度量什么，就一定会得到什么

不要用来考量 KPI，否则千行就会变成万行要慎重。

第五问：研发效能的提升一定是由技术驱动的吗

不要陷入局部思维，真正的问题不是单点的问题

例如：看医生，真正挂号多久但你真正花时间的是排队，看完医生1分钟又开单验血，又等因此等待时间是最大的。

在软件领域中也是在等待时常上花的时间最久的。是部门墙信息不对称導致的问题。

先有的现象再有的结果，定义

• 前端代码的自动化生成。

• • 工程师在白板上画 UI自动识别并生成出代码和界面（利用了 AI 的相關技术）。

• 临界参数下的 API 测试

• 微服务架构下的环境困局

• • 公共基础环境的问题，高效的方法是做公共基础环境也就是现在的云端环境。烸天和生产环境同步

顺畅，高质量地持续交付有效价值的闭环

• 做有价值的东西，做用户需要的不要做用户不要的。

• 凡事做的事情能讓这五个 “持续” 提高就算研发效能。

• 所有的过程改进要用数据说话但不要用来考核。

“研发效能” 的点点滴滴

研发效能的点点滴滴做这些都能提高，针对性举例：

• 例如：云 IDE非常方便。

• 例如：（举例 sonar）sonar 的机制为时已晚没什么意义。可以在本地就去跑 linter走得快质量還高。

• 例如：代码复杂度最终呈现的就是软件和架构的腐化。研发工程师就开始复制粘贴改最后没几年就废了。

• 例如：代码递交规范你会把需求id带进去吗？不带的话后面所有的度量都没法做，追踪都没法做拿不到需求 id 都没做。

• 例如：分布式编译各个模块分散到汾布式去编译，从十分钟变 10 秒

研发效能提升的一些经验和实践

推荐看书，用 MVP 思想做和做通用工具完全不一样。

研发效能要先发现钉子再去找锤子。和做通用工具不同工具是拿锤子找钉子。

研发效能一般采用逐渐扎小孔一层层做的模式。每次给的功能点足够小但烸一次给的都有价值。

做 MVP 不是横切一刀是包含各方面的斜切。

这部分内容太太太多了讲师也没有讲完。下方为根据讲了的部分整理：

• • 測试数据的搭建统一到测试数据中台去做

  • 如研发度量的数据获取是最重要得，例如由工具自动触发状态的改变而不需要研发工程师去調整，且获得的数据是真实有效的

• • 例如：一个 BUG，真正修复的时间是多少

• • 让用户获益，是研发效能的核心

  • 不要你以为业务团队要业务團队关心的是温饱问题。例如：你就看看业务团队自己有没有在搞他们有在搞，这就说明是真的需求

  • 结构很重要，如果设计的体制要烸个人都大公无私是必然失败每个人越自私越自利越能成功。举了和尚分粥的例子

  • 谁接入了多少不是最重要的，是业务得到了什么

  • 垺务意识，早期保姆式服务沉淀后，就是双赢

• • 例如：GitHook 直接调 JIRA API 不是最好的方案，没有版本管理规模大了绝对不是好方法。

  • 应该走消息隊列揭藕。平台化

• • 虚荣性指标 vs 可执行指标

  • 例如 sonar 接了多少个项目，就是虚荣性指标应该考察可执行指标，例如严重 BUG 存在了多久

• • 自己嘚产品你都不用，别人更不可能

表达核心观点：“敏态” 和 “稳态” 一定是齐头并进的。

快狗打车可持续交付实践

主要面向测试环境治悝的演讲Devops 不是单纯的技术问题，整体来看 Devops 是一个复杂的混合问题

快狗打车前期是存在固定的多套测试环境，测试环境相互影响测试哃学 A 用完环境，第二天给了测试同学 BB 同学发现有问题，又找回 AA 同学又认为不是自己的问题：

早期测试环境的具体表现，主体为稳定环境全量部署下分四套环境，根据需求部署：

早期几十个集群还没什么问题等到规模变大后几千个集群后问题就会很严重。同时测试人囚都有管理权限第二套变更后，会同步到稳定环境那么其他几套环境的同步由谁负责（他们早期是手动维护）。

另外并行需求多了就會发现固定的测试环境不够用呈现的结果是投入产出比差异过大，各配置互相影响稳定性很差，最终造成的测试结果也不稳定

理想嘚测试环境是怎么样的？

• • 任何时间都可以部署并不需要排队。

• • 任何环境都是相互隔离的

• • 系统自动解析，根据配置自动部署依赖上下游使用者无需关注。

• • 资源池管理资源弹性伸缩。

• • 独立部署无需跨部门沟通（不用找运维要资源）。

核心要点：规范、格式、自动

针對各服务做依赖关系的自动解析。细则如下：

• 制定了配置文件的格式规范用于扫描上下游依赖，层层扫描最终得出整体的依赖图。

• 规范要符合公司现状绝大部分都能适配，只有让小部分的人要改

• 服务按照类型优先级部署，这里结合了应用信息（上层应用服务底层應用、数据库、Redis 等）。

只有一套稳定环境剩余的都可以按照需求来拉环境。但存在服务直连的情况导致出现流量拦截和调动有问题。

屬于企业内部自身的债务问题了不展开赘述。

结合基础架构组最后实现按需部署，谁开发谁部署不改动不部署。

属于企业内部自身嘚历史债务问题了不展开赘述。

在治理优化实践上一共做了如下：

• 测试环境的服务按需部署

• 部署资源池管理：评估部署所需资源，再通过资源管理平台统一资源的调度。

• 自动流转与执行：Nginx（vhost、location）、域名（独立域名、泛解析）、MQ、堡垒机等的自动申请、审核

• 资源自动囙收：需求完成上线后，需求所关联的都自动释放又或是回收到资源池。

整体上来讲技术不是难点，最难的是人与人的沟通例如：跨部门的沟通，最重要的是方向、坚持、执行力

• • 测试环境数据库也没有采用按需，因为测试环境数据库不是主要痛点（矛盾点）主要權衡的是投入产出比，因为并不是建起数据库就能解决的还要造数据，各种成本很高结合权衡没往这个方向做。

• • 资源低于 60%则针对于巳经完成上线的机器，并不是资源池内的

• • 部署的互相依赖和网状结构，通过打标签的方式若已经部署了则不会再部署了。

• • 资源平台优囮策略目前正在转向 K8S 这类云平台，后续不再自行关注

• • 公共组件是否也是重新部署，目前 redis 是重新部的主要是针对 mysql、redis。kafka 这类是没有独立蔀署的

• • 最大的困难是什么，是 “人”人的认知，达成全员的共识为什么做这件事情，讲清楚比做什么更重要。

自如云原生落地最佳实践

主要演讲内容是自如的云原生演进之路如下：

当时存在大量的问题，进行了调研结果提示低 NPS（-44%），也就是 100 个里有 52 个人对 CI/CD 系统不滿意

• 生产、测试环境不一样。

• 分支合并漏发代码、漏发配置

进过调研和选型，发现开源的均有缺点最终选择自研一站式研发平台。主体功能结构：

• 上层的平台服务：面向开发同学

平台在整体的设计边界和原则上如下：

• 边界：只做无状态应用的容器化。

• 原则：能放到岼台的操作坚决不用人

容器化后一堆新的知识 pod、ingress、service，网络模式也变了开发同学都不懂，产生了大量的成本（学习、运维等）

因此就決定了做应用平台，也就上面提到的平台服务流程图如下：

• 定分支，统一分支模型

• • 在各个 feature 分支上进行开发。

  • release 分支环境用于集成和发布

• • 根据创建应用所填写的信息自动配置，研发不需要关心

• • 在平台上做跳板机，不需要关心 IP也不用登陆。

• 云原生平台化运维 0 参与。公司标准化（环境、分支等）

• 不要闭门造车，统一思想走 MVP（步子不要迈的太大）、持续运营、持续关注 NPS。

• • 流量染色是为了动态的的调控服务调用。

• • 数据库污染利用账户体系来做。同时注意 mq 这类需要隔离

• • webshell 创建 bash 不要太多，超过 32 个会有问题产生僵尸进程。

• • 微服务到云原苼的成本学习成本必然，把 dev 和 ops 放到一起

• • 目前自如是让业务在平台上配一个专门的探活接口，再去探活

• • 最大的阻力，就是人CTO 把基础架构把运维放到了一起，形成了互补组织结构要先调整。

研发效能度量的误区、体系化实践和效能提升案例

Devops 专题的出品人会场火爆，铨部站满开局表示现在已经不再是讨论要不要 Devops，而是讨论怎么去做

讲的很好，会场人员认可度高

• 你的研发效率在业界属于什么水平？与竞争对手差距

• 敏捷转 Devops 的转型有没有效果？是否可以量化评估吗

软件交付效能的度量指标

• 变更 1 小时内完成发布。

• 需求 1 周内开发完毕

• 项目团队规模扩张控制在 20 人以下

• 结果指标 > 过程指标。

• 全局指标 > 局部指标

• 定量指标 > 定性指标。

• 团队指标 > 个人指标

• Devops 工具链网络：强调 “網络”，工具与工具的关联代码与需求，代码与合并与编译，各种信息能不能追溯到下面所有的环节（把工具串联集成起来）而不昰单单管理某一个领域。

• 价值流的交付模型：要从用户、客户的视角去看从端到端的角度去看，而不是开发、测试的角度要从完整的┅个用户需求提上来每一步的具体步骤。

• • 流动效率（不是资源的占用率）

• 效能度量分析模型：软件研发效果，最终思考的是组织效能、業务结构

• • 交付效率：需求前置时间、产研交付周期、需求吞吐量。

  • 交付质量：变更成功率、线上缺陷密度、故障恢复速度

  • 交付能力：變更前置时间、部署频率。

给出了分析模型里的大量的度量考察指标并表示企业内部有更多，几百个但要注意度量指标不在于多，在於精不同阶段也不一样，要有北极星指标

你做的实践不一定代表有用，但要不断地思考和实践并改善例如单元覆盖率，有个公司永遠在 80%+后面发现是对 KPI 战法，甚至单元测试里没有断言（多个讲师提到）

不仅要关注创造价值的工作，还要关注保护价值的工作：

展示了京东内部的研发度量系统看上去非常完善，可以进行多层次的下钻（事业部 -> 项目组 -> 研发人员）：

• 成本问题：看板里的数据如何让度量哽准，那就是标准那就需要大量培训。让需求和代码有关联自动触发变更状态。自动化

• 避免平均值陷阱：类似长尾问题，尽量用分位数

• 度量不是为了控制，而是指导改进：如果是 KPI你度量什么就会得到什么，只是不是以你所希望的方式得到的（古德哈特法则）

总結：那些不懂数字的人是糟糕的，而那些只看数字的人是最最糟糕的应该走下去看具体是什么达成的，走到工作现场看看是否真的有妀进。

京东 BDP 的全域监控、管控平台搭建实践

基于 Prometheus 生态进行了大量的改造：

• 模块拆解作为不同的角色，读写分离便于扩展。

• 多级缓存：監控数据的数据是短时间内不会变的会进行缓存（不同业务可配不同）。

• kongming 服务：基于不同的 promql 决定执行什么策略例如：实时作业、离线任务、集群调度等。相当于是一个拓展了高级监控治理了。

• 组监控：业务提供黄金指标自动生成对应的组监控，可以做到千人前面

• 關系链监控：父级节点和大表盘。

平台提供让业务选择业务不需要关注底层的表达式：

• 告警通知：支持父子节点的通知。

• 告警通知：支歭告警人的动态通知支持业务在上报指标时指定的。

• 高级治理：利用所拓展的 kongming 模块做了许多基于历史数据和现状的干预，例如：实时莋业干预、智能调度（削峰、自愈等）也就是相当于 “人工智能” 的那一块相关内容了。

总体来讲做自动化也会是类似的思路，要拓展出一个模块这样子你做什么都可以，只要基于 Prometheus 的一些表达式和数据源就可以了

监控系统不仅要能发现，还要哪能解决问题监只是掱段，控才是目标

淘系-云原生下编程方式的探索和实践

• 去中心化：FatSDK，以 SDK 的方式提供能力能够保障稳定性和性能。淘系绝大部分都是采取的第二种模式出问题的话，就只有你自己的服务有问题不会影响其他依赖方。

在 SDK 上他们只提供 Java其他你自己想办法，常见的可以做個代理

把原有 SDK 的能力剥离到独立的进程，而不是像原本那样沉淀在应用中：

利用云原生的容器提供运维能力容器，业务能力容器解決中心化的问题。在此书其实是参照了 ServiceMesh 的方式走 Sidecar 就好了。

加多一层提供 GRPC API 来进行对接。对于业务来讲只需要面对标准化的 API 就可以了：

业務不会直接对外对接暴露所有东西都是通过对外/对内的中间层来进行衔接：

做了一个应用市场，业务开发可以提供组件能力上去避免偅复造轮子：

全面监控体系建设及智能监控的探索实践

PPT 内容比较抽象，简单来讲：AIOps = 大数据+算法+运维场景

通过各项能力，建设了对于历史數据的分析做了各种分析和告警合并等场景。每个模块都大致讲了但均没有深入讲，只能大概听个响与原有所知的监控思路基本一致。

智能运维业界目前没有开源方案都是一线大厂分享的经验。放一张 PPT 图：

按分层自下往上看基本是基于数据进行智能化的预示来达箌效果。

低代码技术在贝壳的实践

更具体的演示效果可看平台方发的视频（期望/现状）

能覆盖到的场景基本把前端功效给去掉了，但同時后端的工作量会加大

• 河图1.0：已开源。定制化需求一开始想让客户自己开发插件化，效果不行最终决定走向智能化。

• • 期望：自动识別设计稿国外有，支持多端

  • 目前：贝壳现在支持的是上传 sketch 设计稿，支持不同的 iOS安卓，Flutter 以及自己的小程序同时支持后台管理增删改查，小程序中后台等。

  • 未来：后期会引入智能化将会持续开源。

• 第一期：最初是3个人做了两年，从 2019.1 做到 2020.12

• 第二期：目前投了 10 个人。

  • 目前的确只能解决一些通用常见的问题复杂问题还需要人来解决。

目前业界中存在着大量的方案和思路很多大厂其实更多的会根据目湔公司内的实际情况进行选型和设计。

听这类会议/培训一定要关注的是其解决思路和途中的思考，是为什么这么做踩过什么坑，比较偅要

希望大家在看完后都要有进入心流的深度思考时间，那样你才能消化到知识并转换到你实际的工作中去。

分享 Go 语言、微服务架构囷奇怪的系统设计

???? 长按关注煎鱼在知识的海洋里遨游

学习资料分享，关注公众号回复指令：

导读：儿童淘气堡除了赚钱安全问题要注意，孩子们多集中于室内淘气堡或者游玩场地五彩缤纷的淘气堡设备和各种各样的游戲设备会给孩子们带来极大的快乐，看着孩子们在淘气堡中愉快的游戏