清华大佬吐血整理5000字真言 | 快速学习大厂们的软件案例经验！

Posted 2021-06-15 程序员小濠

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了清华大佬吐血整理5000字真言 | 快速学习大厂们的软件案例经验！相关的知识，希望对你有一定的参考价值。

这篇文章主要向大家介绍吐血整理 | 快速学习大厂们的软件案例经验,主要内容包括基础应用、实用技巧、原理机制等方面，希望对大家有所帮助。

如有任何问题或建议，欢迎及时交流和碰撞。测试交流群：175317069

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

同时记了一些笔记，整理后分享出来，但愿对你们有所帮助，拓展眼界很是重要。mysql

内容比较多（已经精简过），你们能够挑本身感兴趣的学习，建议三连。git

一级目录以下：github

百度内部业务 ServieMesh 实践。
云原生开发平台在腾讯游戏运营中的实践。
快狗打车可持续交付实践。
网易数帆从微服务框架到服务网格架构平滑演进及最佳实践。
不破不立：企业级研发效能提高的创新实践。
自如云原生落地最佳实践。
研发效能度量的误区、体系化实践和效能提高案例。
京东 BDP 的全域监控、管控平台搭建实践。
构建发布效率从10分钟到秒级的提高 - 云原生下编程方式的探索和实践。
全面监控体系建设及智能监控的探索实践。
低代码技术在贝壳的实践。

百度内部业务 ServieMesh 实践

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

同时也能得知百度也是本身作了个 bmesh，自此归纳几乎全一线互联网大厂，均为自研（或结合）ServieMesh。redis

总体演进

1.0 时代

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

主要存在如下问题：sql

开发成本高：异构语言的问题，每一个语言都要从新开发。
升级成本高：框架上线以来业务。
管理成本高：服务拓扑和治理没有统一管理（须要治理）。

2.0时代

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

从概念上来说，主要分为如下两类：数据库

数据平面
- 与业务无关。
- 与语言无关。
- 独立的升级（直接升级 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 以及本身的小程序。
  - 支持后台管理增删改查，小程序，中后台等。
- 将来：
  - 后期会引入智能化，将会持续开源。