一级目录如下：
百度内部业务 ServieMesh 实践。
云原生开发平台在腾讯游戏运营中的实践。
快狗打车可持续交付实践。
网易数帆从微服务框架到服务网格架构平滑演进及最佳实践。
不破不立：企业级研发效能提升的创新实践。
自如云原生落地最佳实践。
研发效能度量的误区、体系化实践和效能提升案例。
京东 BDP 的全域监控、管控平台搭建实践。
构建发布效率从10分钟到秒级的提升 - 云原生下编程方式的探索和实践。
全面监控体系建设及智能监控的探索实践。
低代码技术在贝壳的实践。
百度内部业务 ServieMesh 实践
本场演讲内容主要为微服务到服务网格的过程。其中涉及百度在异构场景下的一系列演进和适配操作。
同时也能得知百度也是自己做了个 bmesh，自此概括几乎全一线互联网大厂，均为自研（或结合）ServieMesh。
整体演进
1.0 时代
第一代微服务架构（1.0时代），主体是基于 SDK/开发框架的微服务治理体系。
主要存在以下问题：
开发成本高：异构语言的问题，每个语言都要重新开发。
升级成本高：框架上线以来业务。
管理成本高：服务拓扑和治理没有统一管理（需要治理）。
2.0时代
第二代微服务架构（2.0时代），主体是基于微服务框架到服务网格，也就是把服务治理能力抽取出来，作为一个进程（sidecar），与业务逻辑解耦。
从概念上来讲，主要分为以下两类：
数据平面
与业务无关。
与语言无关。
独立的升级（直接升级 sidecar 的进程），能够解耦。
控制平面
能够统一的管控。
百度现状
各语言在内部平分秋色，没有谁强谁弱。各自都有框架，且有可能有多个框架，可自行脑补一下在公司内部一种语言有 N 种框架，且多种协议（含私有协议）的情况：
存在以下问题：
多个语言开发。
多个框架改造。
多个通讯协议。
简单来讲就是 “异构系统”，传统的微服务框架无法满足了，成本非常高，甚至不可行。只能通过服务网关的方式来实现微服务治理。
上服务网格的困难
改造成本：
各种内部框架的支持。
各种通讯协议的支持。
性能问题：
通讯延迟，有些敏感业务无法接受，例如：搜索。
资源开源，数十万机器，每个服务都加边车，成本极大。
规模问题：
随着接入的节点越多，规模越大，控制平面下发配置的速度越慢，甚至无法工作。
百度的解决方案（整体架构）
在开源的技术栈上进行了自己的拓展，用的是 istio+envoy。
并且在 istio 之上做了一层抽象，实现了 Mesh 的管理界面。
另外实际上在调参时，是需要很多实际经验的，例如：超时的值到底怎么配，因此又基于此在平台上提供了智能调参系统。
与目前所知的一线互联网大厂改造比较类似，区别在于还做了很多自有平台。
遇到的问题（大规模落地三步走）
解决接入问题
流量劫持方案：
社区自有的方案无法修改服务治理的参数（例如：导致原有的超时重试变成了对边车重试）。
iptables 存在性能问题。
无法在 mesh 和 非 mesh 下切换：不能完全信任，挂掉后怎么处理，流量怎么切。解决方案是劫持服务发现的过程（边车劫持的是的服务地址），就能够解决流量劫持的自由问题。
自有协议代理：有二十多种协议，解决方案是抽了一层公共 Proxy，实现 codec 就可以了。但也没法解决全部问题，因为 Mesh 对协议有要求，例如加字段。但有的老协议是没法扩展的。最后解决方案是做协议转换，业务代码就不需要修改了。
多框架支持：网格对框架有基本要求（治理行为可拓展，透传 Trace 信息），但有的老框架没法支持。通过探针逻辑修改框架行为（探针感知逻辑，修改框架行为）。
解决性能问题
网络性能优化：
envoy 的最大问题是性能不怎么好，拓展性是第一，性能是他的第二位。
envoy 的多线程的竞争是非常厉害的。最后是采取 envoy+brpc 的融合方案（难度很大，组件替换，逐步替换）解决，整体延迟和 CPU 使用率明显低于原生版本。做了开关，能在原生和融合后版本切换。
网络控制面优化：
istio 原生的配置是全量下发的，非常不科学。
改造为通过获取关系按需下发。服务发现改为由控制面下发到数据面。简单来讲就是原生 istio 控制面在大规模下有很多问题，为此改了很多逻辑。
网络性能优化：
istio 原生为 both side 模式，要转换 2 次，损耗 2 次网络开销，2次性能开源，内部认为不可接受。改为 client side 的模式（架构上的折中，有的业务很敏感，不推荐为主流方式）。
享受网格的红利
流量可操控：
所有的流量都在自己的手中，可以去做很多事情。例如做很多动态的事情，全局流控，根据延迟分配请求到不同的下游等，带来的新的问题就是太多配置，太吃经验，因此做了哥全局智能调参。
结合高级治理，配合自愈和剔除，可用性的修复时间大大的提高，提高了可用性。
服务可观测：
结合框架透传 Trace 信息，Sidecar 负责上报监控，即可形成追踪。
自动止损
结合监控平台采集实例、集群信息，发现异常，上报给控制平面。然后就可以屏蔽掉某个实例、集群。实现自动止损。
异常注入
混沌平台负责配置、评估，服务网格负责实施异常注入。
容量管理
传统需要做压测，对整个系统进行很长时间的压测（想压到极限，要构造大量的数据和流量），非常麻烦。
通过服务网格可以在局部构造出极限的压力。
落地情况
百度目前正在逐渐落地，已接入实例数万。通过高级的服务治理（需要自实现）带来了很大的收益。
但需要注意，如果只是单纯接入服务网格，并不能带来上述所说的收益。他的收益更多的是面向后续的一些高级治理等高级场景。
总结
服务网格不是微服务治理的银弹：
完全无侵入支持所有空间和治理策略的 Mesh 方案是不存在的。
大规模落地一定会涉及已有治理的兼容升级和改造。
服务网格确实实现了业务逻辑和服务治理架构的解耦。
服务网格的开始是最难的，落地服务网格会非常困难和艰辛。
QA
第一个：
新产品可以上服务网格，但要有一个现成成熟的服务网格，自研工作量是非常之大的。
第二个：
和开源社区结合的问题，会不定期更新 envoy，istio 的版本。
服务网格不能只看节省的成本，如果只是说框架的治理，那是非常小的，最大的收益是把所有的流量都汇总到一起后收益非常大。网格一开始会非常痛苦，需要把流量真正的拦截上去。
边车的定位是服务于服务之间的通讯代理，与业务逻辑比较紧耦合是不适合放进去的。
推广的目标不是全站覆盖，核心链路上到就可以，因为有的应用对这类没什么诉求。
第三个：
是否 SSL 看企业场景。
第四个：
bmesh 可以从全局角度监控，现有的监控模式可能你会是自己有问题。
云原生开发平台在腾讯游戏运营中的实践
平台的期望：提高研发效能，业务落地成长。
业务背景：营销活动，上线活动很多是不报备的，因此伸缩性要求高，日活很容易上千万。活动多（每天新增 50 个以上），数量量幅度大，服务质量要求高。
实际成效：这么大的规模，现在只需要 3 个 专职运维，晚上 6 点就下班了。
本质需求
频繁发布：版本发布更新。
动态伸缩：数据量大。
持续高可用：经常变更。
运维的任务
以往都是开发提交给运维的，问题是有极多个开发对接有限的运维。面临的问题：
面临的环境，部署的东西，都是不是固定的。
开发需要转移知识给运维。
实际经常会出现意外情况。
对部署的风险：运维本能排斥变化。
呈现的结果是运维忙于救火，开发提个需求，就只能排队，线上总不稳定。
解决办法
持续交付：
控制产品发布节奏，需求尽快上线，不积压。
打造部署安全网：
微服务、并行部署，完善的监控。
实现可重复性：
控制环境和部署的构建，自动化， 保证输入输出的一样的。
变化是必然的：
以故障是常态去设计。
碎片的解决方案
要解决上述所提到的问题，基本目前在业界都有基本的解决方案，但其都是 “碎片化” 的，如下：
“碎片化” 指的是不同的组件都分别是解决特定的问题。这就导致了下述问题：
各方面的学习成本高。
系统自动化程度低。
有经验开发人员有限：
人员招聘成本高，限制发展规模。
无生命周期：
整体的上线到下线没有管理。
云原生开发平台的设计
真正的完整解决方案就是做一个 “云原生开发平台”，提供一整套的服务来支持软件的开发和运维，实现各种云原生软件的诉求。
从设计角度上来讲：
运维不暴露太多的基础建设，只是开放角度去做。开发人员只需要关注应用程序，不需要关注底层的基础设施。
不需要让业务关注你用的是 k8s、envoy、gitlab 什么基础设施，不用去学习一些特定的知识体系。
资源评估中心化的运维
开发需要申请资源，运维需要评估，分配，再审核执行。最快是小时级，是平台的瓶颈。
解决方案是把资源分片，实现团队自治，开发就可能承担了部分运维以往的工作。
此时又会带来由于运维部分工作转移到开发后的成本问题，这部分就需要由平台来解决，提供下述全流程：
智能的容量评估
自动化提单/审批
自动下线（通过日志、性能、调用来识别）
自治并释放资源。
最终的成效是目前所有的审批都是业务团队自己去做，运维只负责供应资源。
微服务下的依赖问题
思考：服务 A 流量上涨，依赖的服务如何扩容？
利用 istio 做全链路分析，实现全自动化，精准识别出入流量，计算差异部分，就能知道改变的服务链路和所需放大的倍数。
实现可重复性
应用跑不起来，肯定是有东西改变了：
环境控制：镜像。
构件控制：全自动化流水线，例如：代码版本、编译命令等。
运行时配置：提供配置管理，实现版本控制。
控制可运行时容器，就可以做一系列工作。系统提供默认安全，应用也就安全。
变化是必然的
面向故障设计：
多可用区可用（异地多活？）.
主机故障自愈/剔除能力。
实例守护剔除能力。
配置恢复能力。
开发阶段如何提升效率
做了个服务市场，业务应用。沉淀利用现有的能力。
总结
基础设施，团队自治，统一且自动化的交付。开发运维一体化，转移到开发的成本，要用平台来解决。
QA
第一个：
故障定位，看基础设施，若是软件业务逻辑，软件业务逻辑是通过平台来提供工具来支持业务排查，帮助定位，大部分还是靠业务团队做的，若是基础设施基本都是大面积的。
第二个
版本一致性，必然存在，发布有先后顺序，可以走蓝绿，业务逻辑也要做一些兼容处理。
第三个
去抖动下发的策略，会持续监听 IP 并收集，配置下发有最小的间隔，例如十秒间隔的统一下发（存在一定延迟）。又或是到了一定数量级也会下发。不会来一发触发一条。
第四个
开发要对利用率关注，压测，让平台上能够自动化去帮他实现，帮助他认识，自动生成出建议的数量和规模。同时服务的流量是分高峰，平峰的，平台要有提供自动扩缩容的机制（例如：也可以做定时策略）。支持自定义指标的扩缩容，要有一个超卖的策略。
第五个
研发和运维的分界线，版本上线的告警目前都是由业务自己做的，代码是业务自己写的，暗含的逻辑运维必然不知道。开发要做全生命周期的跟踪。
统一网关不包含业务逻辑，更多的是支持公有云私有云，私有协议，一些登陆。业务网关更多的是跟业务相关的。
第六个
长连接如何做无损发布，超过 30s 后 ipvs 感知不到连接断开，流量还是会分过来。存在局限性，要感知协议类型（内部做了针对性的自动化判定），判断流量是否结束，若结束则转发到新的。四层还是需要业务自己实现的。
网易数帆从微服务框架到服务网格架构平滑演进及最佳实践
介绍微服务相关的理念和服务网格的演进，前半部分非常高关注率，听众大量拍照。
后半部分主要是网易轻舟的产品和技术介绍，主要是偏向 Java 方向，因此主要是在思想上进行参考，有一定的价值意义。
从 2017 年开始进行 ServieMesh 的研究，不断进行打磨，直到 2020 年正式释出网易轻舟这一个技术产品。
为什么要从微服务框架演进至服务网关
在 2012 年正式提出微服务，介绍了微服务的发展史：
1.0时代：2011-2017，以框架为代表的微服务框架。
2.0时代：2017-至今，以服务网关为代表，业务与治理解耦。
微服务框架存在的问题
适用范围。
升级成本。
侵入性。
治理能力有限。
框架负担。
架构演进与云原生相冲突（注册中心部分）。
服务网格的定义和优势
服务网格定义为服务间通讯的基础设施层，通过轻量的网络代理进行拦截和处理。堪称异构语言的救星。
服务网格的技术升级改造成本
思考：我真的需要服务网格吗？
业务诉求是否只能用服务网格解决？
业务现状是否满足网格接入条件？
业务团队是否能够驾驭得了服务网格？
是否有开发配套的基础设施？
演进的成本问题
ROI 策略，做成本分析。
接入诉求
要关注业务期望收益是什么？
微服务框架和服务网格共存
微服务框架：面向应用内的服务治理。
服务网格：面向服务间的服务治理。
微服务框架和服务网格两者存在重合的区域，但又无法完全替代：
网易轻舟的平滑演进主要是针对 Java 系，对此 JavaAgent 做了一些调整（如下业务迁移），以此来实现平滑演进。
业务迁移
微服务框架 =》 融合（过度）期 ：存在流量管理的能力冲突 =》 服务网格
逐步分离，缓慢实现技术升级。方案分为：
通过 JavaAgent 迁移。
通过网关做灰度流量迁移。
服务网格与真实的使用场景差异
设计上比较理想化，很难直接拿来给业务直接用，业务真正使用都要做定制化改造：
为了解决这些问题，网易轻舟做了以下增强：
通讯协议增强支持（例如：Dubbo、Thrift）。
sidecar 的管理问题：每次的升级问题，社区方案每次都要重启 pod。网易轻舟是实现了热升级。
多场景的限流方案：社区方案的性能常被人吐槽，并且场景支持不充足。
基于服务网格的能力拓展：例如：监控。
提供微服务框架和服务网格的一体化的控制台，简单来讲就是通过平台将用户的业务改造成本和学习成本和运维成本大幅度降低了。
因此平台化是解决服务网格 “成本” 的一个出路。
未来
中间件 Mesh
排障体系建设
故障演练体系
总结
认为落地过程一定是曲折的，服务网格未来一定会是光明的。
细节会是魔鬼。
QA
第一个：
微服务框架到服务网格的最大难点：解决服务发现的过度问题，如何把注册中心打通。
第二个：
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 用完环境，第二天给了测试同学 B，B 同学发现有问题，又找回 A。A 同学又认为不是自己的问题：
测试环境V1
早期测试环境的具体表现，主体为稳定环境全量部署，下分四套环境，根据需求部署：
早期几十个集群还没什么问题，等到规模变大后几千个集群后问题就会很严重。同时测试人人都有管理权限，第二套变更后，会同步到稳定环境，那么其他几套环境的同步由谁负责（他们早期是手动维护）。
另外并行需求多了就会发现固定的测试环境不够用。呈现的结果是投入产出比差异过大，各配置互相影响，稳定性很差，最终造成的测试结果也不稳定。
理想的测试环境是怎么样的？
即点即用
任何时间都可以部署，并不需要排队。
自动隔离
任何环境都是相互隔离的。
依赖关系
系统自动解析，根据配置自动部署依赖上下游，使用者无需关注。
缩放自如。
资源池管理，资源弹性伸缩。
独立闭环
独立部署，无需跨部门沟通（不用找运维要资源）。
第一轮的优化实践
核心要点：规范、格式、自动。
针对各服务做依赖关系的自动解析。细则如下：
制定了配置文件的格式规范，用于扫描上下游依赖，层层扫描，最终得出整体的依赖图。
规范要符合公司现状，绝大部分都能适配，只有让小部分的人要改。
服务按照类型优先级部署，这里结合了应用信息（上层应用服务，底层应用、数据库、Redis 等）。
测试环境 V2
只有一套稳定环境，剩余的都可以按照需求来拉环境。但存在服务直连的情况，导致出现流量拦截和调动有问题。
属于企业内部自身的债务问题了，不展开赘述。
测试环境 V3
结合基础架构组，最后实现按需部署，谁开发谁部署，不改动不部署。
属于企业内部自身的历史债务问题了，不展开赘述。
总结
在治理优化实践上一共做了如下：
测试环境的服务按需部署。
依赖环境的自动解析。
部署资源池管理：评估部署所需资源，再通过资源管理平台，统一资源的调度。
自动流转与执行：Nginx（vhost、location）、域名（独立域名、泛解析）、MQ、堡垒机等的自动申请、审核。
资源自动回收：需求完成上线后，需求所关联的都自动释放，又或是回收到资源池。
整体上来讲，技术不是难点，最难的是人与人的沟通，例如：跨部门的沟通，最重要的是方向、坚持、执行力。
QA
第一个：
测试环境数据库也没有采用按需，因为测试环境数据库不是主要痛点（矛盾点），主要权衡的是投入产出比，因为并不是建起数据库就能解决的，还要造数据，各种成本很高，结合权衡没往这个方向做。
第二个：
资源低于 60%，则针对于已经完成上线的机器，并不是资源池内的。
第三个：
部署的互相依赖和网状结构，通过打标签的方式，若已经部署了则不会再部署了。
第四个：
资源平台优化策略，目前正在转向 K8S 这类云平台，后续不再自行关注。
第五个：
公共组件是否也是重新部署，目前 redis 是重新部的，主要是针对 mysql、redis。kafka 这类是没有独立部署的。
第六个：
最大的困难是什么，是 “人”，人的认知，达成全员的共识，为什么做这件事情，讲清楚，比做什么更重要。
自如云原生落地最佳实践
主要演讲内容是自如的云原生演进之路，如下：
当时存在大量的问题，进行了调研。结果提示低 NPS（-44%），也就是 100 个里有 52 个人对 CI/CD 系统不满意。
具体的痛点：
运维人肉运维。
生产、测试环境不一样。
分支合并漏发代码、漏发配置。
上线发布一台台点。
kvm CPU 使用率低。
进过调研和选型，发现开源的均有缺点，最终选择自研一站式研发平台。主体功能结构：
上层的平台服务：面向开发同学。
下层的 K8S 等：面向 Ops 同学。
平台在整体的设计边界和原则上如下：
边界：只做无状态应用的容器化。
原则：能放到平台的操作坚决不用人。
容器化后遇到的问题
容器化后一堆新的知识 pod、ingress、service，网络模式也变了，开发同学都不懂，产生了大量的成本（学习、运维等）。
因此就决定了做应用平台，也就上面提到的平台服务。流程图如下：
CI/CD
定规范，统一环境。
定分支，统一分支模型。
在各个 feature 分支上进行开发。
release 分支环境用于集成和发布。
Dcoker/Deployment 零配置
根据创建应用所填写的信息自动配置，研发不需要关心。
工具-跳板机
在平台上做跳板机，不需要关心 IP，也不用登陆。
总结
云原生平台化，运维 0 参与。公司标准化（环境、分支等）。
不要闭门造车，统一思想，走 MVP（步子不要迈的太大）、持续运营、持续关注 NPS。
QA
第一个
流量染色，是为了动态的的调控服务调用。
第二个
数据库污染，利用账户体系来做。同时注意 mq 这类需要隔离。
第三个
webshell 创建 bash 不要太多，超过 32 个会有问题。产生僵尸进程。
第四个
微服务到云原生的成本，学习成本必然，把 dev 和 ops 放到一起。
第五个
目前自如是让业务在平台上配一个专门的探活接口，再去探活。
第六个
最大的阻力，就是人，CTO 把基础架构把运维放到了一起，形成了互补。组织结构要先调整。
研发效能度量的误区、体系化实践和效能提升案例
Devops 专题的出品人，会场火爆，全部站满。开局表示现在已经不再是讨论要不要 Devops，而是讨论怎么去做。
讲的很好，会场人员认可度高。
研发效能的情况
你的研发效率在业界属于什么水平？与竞争对手差距？
敏捷转 Devops 的转型有没有效果？是否可以量化评估吗？
软件交付效能的度量指标
部署频率。
变更前置时间。
服务恢复时间。
变更失败率。
研发效能评估（愿景）
阿里（211）
需求 2 周内交付。
变更 1 小时内完成发布。
需求 1 周内开发完毕。
腾讯
项目团队规模扩张控制在 20 人以下
迭代周期在 1 周内
研发效能度量的原则
结果指标 > 过程指标。
全局指标 > 局部指标。
定量指标 > 定性指标。
团队指标 > 个人指标。
指导性，可牵引行动。
全面性，可互相制约。
动态性，按阶段调整。
工具链网络
Devops 工具链网络：强调 “网络”，工具与工具的关联，代码与需求，代码与合并，与编译，各种信息能不能追溯到下面所有的环节（把工具串联集成起来）。而不是单单管理某一个领域。
项目协作域。
开发域。
测试域。
价值流的交付模型：要从用户、客户的视角去看，从端到端的角度去看，而不是开发、测试的角度。要从完整的一个用户需求提上来每一步的具体步骤。
工作流。
生命周期。
流动效率（不是资源的占用率）。
效能度量分析模型：软件研发效果，最终思考的是组织效能、业务结构。
交付效率：需求前置时间、产研交付周期、需求吞吐量。
交付质量：变更成功率、线上缺陷密度、故障恢复速度。
交付能力：变更前置时间、部署频率。
给出了分析模型里的大量的度量考察指标，并表示企业内部有更多，几百个。但要注意度量指标不在于多，在于精。不同阶段也不一样，要有北极星指标。
你做的实践不一定代表有用，但要不断地思考和实践并改善。例如单元覆盖率，有个公司永远在 80%+，后面发现是对 KPI 战法，甚至单元测试里没有断言（多个讲师提到）。
不仅要关注创造价值的工作，还要关注保护价值的工作：
业务需求。
产品需求。
研发需求。
企业内部实践
展示了京东内部的研发度量系统，看上去非常完善，可以进行多层次的下钻（事业部 -> 项目组 -> 研发人员）：
总结和避坑
成本问题：看板里的数据，如何让度量更准，那就是标准，那就需要大量培训。让需求和代码有关联，自动触发变更状态。自动化。
避免平均值陷阱：类似长尾问题，尽量用分位数。
度量不是为了控制，而是指导改进：如果是 KPI，你度量什么就会得到什么，只是不是以你所希望的方式得到的（古德哈特法则）。
总结：那些不懂数字的人是糟糕的，而那些只看数字的人是最最糟糕的。应该走下去看具体是什么达成的，走到工作现场，看看是否真的有改进。
京东 BDP 的全域监控、管控平台搭建实践
基本介绍
基于 Prometheus 生态进行了大量的改造：
采集端改造：PushGateway 会推数据到 Kafka，再另外消费。
模块拆解，作为不同的角色，读写分离，便于扩展。
数据采集。
预计算。
数据分析。
监控告警，
多级缓存：监控数据的数据是短时间内不会变的，会进行缓存（不同业务可配不同）。
kongming 服务：基于不同的 promql 决定执行什么策略，例如：实时作业、离线任务、集群调度等。相当于是一个拓展了，高级监控治理了。
监控实践
单点监控：常见面板，
组监控：业务提供黄金指标，自动生成对应的组监控，可以做到千人前面。
关系链监控：父级节点和大表盘。
平台实践
平台提供让业务选择，业务不需要关注底层的表达式：
在更具体的实践上：
告警通知：支持父子节点的通知。
告警通知：支持告警人的动态通知，支持业务在上报指标时指定的。
高级治理：利用所拓展的 kongming 模块，做了许多基于历史数据和现状的干预，例如：实时作业干预、智能调度（削峰、自愈等）。也就是相当于 “人工智能” 的那一块相关内容了。
总体来讲，做自动化也会是类似的思路，要拓展出一个模块。这样子你做什么都可以，只要基于 Prometheus 的一些表达式和数据源就可以了。
总结
监控系统不仅要能发现，还要哪能解决问题，监只是手段，控才是目标。
解决各种人力问题。
淘宝系 - 云原生下编程方式的探索和实践
淘宝现状
中心化：微服务化。
去中心化：FatSDK，以 SDK 的方式提供能力。能够保障稳定性和性能。淘系绝大部分都是采取的第二种模式。出问题的话，就只有你自己的服务有问题，不会影响其他依赖方。
在 SDK 上他们只提供 Java，其他你自己想办法，常见的可以做个代理。
通用能力下沉
把原有 SDK 的能力剥离到独立的进程，而不是像原本那样沉淀在应用中：
利用云原生的容器，提供运维能力容器，业务能力容器，解决中心化的问题。在此书其实是参照了 ServiceMesh 的方式，走 Sidecar 就好了。
解决多语言问题
加多一层，提供 GRPC API 来进行对接。对于业务来讲只需要面对标准化的 API 就可以了：
业务不会直接对外对接暴露，所有东西都是通过对外/对内的中间层来进行衔接：
开发市场
做了一个应用市场，业务开发可以提供组件能力上去，避免重复造轮子：
全面监控体系建设及智能监控的探索实践
PPT 内容比较抽象，简单来讲：AIOps = 大数据+算法+运维场景。
通过各项能力，建设了对于历史数据的分析，做了各种分析和告警合并等场景。每个模块都大致讲了，但均没有深入讲，只能大概听个响，与原有所知的监控思路基本一致。
智能运维业界目前没有开源方案，都是一线大厂分享的经验。放一张 PPT 图：
按分层自下往上看，基本是基于数据进行智能化的预示来达到效果。
低代码技术在贝壳的实践
更具体的演示效果可看平台方发的视频（期望/现状）。
提效
能覆盖到的场景基本把前端功效给去掉了，但同时后端的工作量会加大。
现状
河图1.0：已开源。定制化需求，一开始想让客户自己开发插件化，效果不行。最终决定走向智能化。
河图2.0：智能化。
后期会引入智能化，将会持续开源。
贝壳现在支持的是上传 sketch 设计稿，支持不同的 iOS，安卓，Flutter 以及自己的小程序。
支持后台管理增删改查，小程序，中后台等。
期望：自动识别设计稿，国外有，支持多端。
目前：
未来：
投入的人力
第一期：最初是3个人，做了两年，从 2019.1 做到 2020.12。
第二期：目前投了 10 个人。
复杂场景
第一类通用类：
目前可以解决。
例如配置系统可以用。
第二类定制化：
要靠智能识别。
目前的确只能解决一些通用常见的问题，复杂问题还需要人来解决。
总结
目前业界中其实存在着大量的方案和思路，很多大厂其实更多的会根据目前公司内的实际情况进行选型和设计。听这类会议/培训，一定要关注的是其解决思路和途中的思考，是为什么这么做，踩过什么坑，比较重要。
希望大家在看完后都能有进入心流的深度思考时间，那样你才能消化到知识，并转换到你实际的工作中去。
