2021-10-16 EE卓越工程生产力大会（上午）

许久没有现场参与业界DEVOPS大会了。对我来说，参加业界大会一方面是眼界上的开拓，另一方面是前进方向的校正，也知道天高地厚了。去年参加的很多，感触很多，今年参加以后发现业界整体技术又有一次跃进。

今日参加EE大会，主要关注还是DEVOPS和质量。笔记如下。

1. 极简-DEVOPS云原生转型之道（曾海剑）

运营商使用SOW松散方式，对外包进行管理（所谓交钥匙的模式）。在此模式下如何进行转型？

（1）驱动力

• 返工多，瀑布模式导致的返工多

• 质量低，通过运维来弥补软件质量的缺陷

• 统维难，不同部门不同项目，环境各自部署，维护各自承担

• 定位难，出现故障难于定位是研发问题还是运维问题。沟通成本高

人员流失快，且研发的核心痛点：浪费、质量。

外包型企业，没有获得源代码会带来项目绑架的情况。

从物理机到虚拟化到容器化，解决运维的痛点。不需要再去思考如何修理容器。

（2）转型之痛

1. 放养阶段：研发效能团队建工具链，开发人员自己配置流水线（开发人员不懂工具链，不懂k8s，组织培训费时费力不讨好）

2. 保姆阶段：开发人员题需求，研发效能团队配置流水线（累死研发效能团队）

3. 自助阶段：把配置变成编排，开发人员自助编排流水线

核心思想是如何让开发人员零知识将代码发布到生产环境。

研发效能的思考：增效减负。减负指的是降低学习成本，减低沟通成本，降低配置成本。

（3）极简实践

一开始是开源方案，发现开源方案面向的都是专家，比如jenkins，gitlab CI/CD都是通过编程来实现流水线。

设计初衷——极简

• 简化复杂的技术：开发团队能力参差不齐，降低接入门槛，减低调试沟通工作量

• 简化复杂的流程：吧复杂的流程原子化，面向结果，隐藏复杂的环境就绪流程，隐藏复杂的编排发布流程

• 简化复杂的权限：通过统一接口编排能力，简化权限体系，面向多租户共用云环境

实现了动态编排、多模块流水线（一个流水线可以支持多个微服务）

一条流水线管理一个微服务，会导致难以对微服务的上线、灰度进行控制的问题。（通过服务网格解决）

服务编排——进化

微服务1.0，使用springcloud。通过开发方式实现服务治理，诞生背景是虚拟化

微服务2.0，使用Istio，以配置方式实现服务治理，不受语言限制，诞生背景是容器化

Dory效益

Dory从18年开始探索建设，近期将开源

2. 云原生容器化落地实践（去哪儿-邹晟）

（1）背景与收益

痛点：环境不一致、环境交付慢、服务器多运维成本高、降服务器成本、SDK推动升级难，周期长

1000，5000，8000虚机时出现质变（主要是物理设备故障，需要人工确认，KVM进行平移）

我们眼中的云原生：

• 是什么：云原生是一系列可以为业务赋能的技术架构准则，遵循它可以使应用具有扩展性、伸缩性、移植性、韧性等特点

• 为什么：基础架构需要演进，它可以让业务更敏捷

• 怎么做：DEVOPS、微服务、容器化、可观测性、反脆弱性（混沌工程）、service mesh、serverless

业务价值：

• PO：敏捷性、弹性伸缩、资源成本

• DEV/QA：环境稳定性、环境一致性

• DEV/OPS：节省人力

去哪儿容器化进程

容器化进程

（2）实践路线图

容器化落地策略：尽量少改动业务性

1. IaaS层：re-host（评估最小成本）

2. PaaS层：re-platform

3. 应用层：refactor（通过service-mesh，将熔断限流平移）

re-host五步：价值认同、制定规范、工具建设、迁移落地、验收

（3）关键实践

实践1 - 价值认同：容器化的ROI是多少，怎么证明？

1. 自证价值-自己的服务先容器化

2. 放大价值-解决业务线实际问题

3. 技术宣讲-价值宣传，找VIP用户

实践2 - 规范制定

规范制定

关注几个点：日志的统一，实时和离线Loki的使用，部署路径，端口号统一，新应用禁止KVM部署。

实践3 - 工具建设

工具平台

通过对工具平台改造实现全自动化

CD：使用KubeSphere实现多集群管理平台。发布系统调用编译模块调用部署模块调用kubesphere。

应用画像

实践4 - 迁移落地

1. 前置校验：编译阶段自动检查配置
2. 测试环境验证：自动升级SDK
3. 线上验证：灰度发布，自动化验证
4. 混合部署：kvm和容器混合部署
5. 全量部署
6. 观察：7天正常后停止KVM

资源成本：容器化前单机部署的kvm数：14个；容器化后单机部署的pod数：20个

（4）总结与规划

价值认同：从上而下推进。知之不深，则行之不笃；知之愈明，则行之愈笃。

产品同理心：用户收益、迁移成本、使用成本

工程化方法：自动化前置检查、升级SDK、测试、迁移

未来规划：稳定性治理、资源利用率提升、service mesh落地

3. 工程师文化（华为）

• 对工程师文化的思考
• 企业在全面云转型中，如何重塑匹配的工程师文化？
• 工具平台

对工程师文化的思考

企业工程师文化，不是脱离具体环境，独立存在的

文化不是你要求人家做什么，而且团队领导做什么，别人跟着做。

影响工程师文化的因素
企业顶层文化：以客户为中心，质量优先……关键是，真正在执行的是什么？
问题：会不会变成以一线销售为优先？

价值创造过程：商业模式，产品交付模式，研发模式，软件工程实践，工程师的工作方法，逐步影响
设备供应商和云服务供应商完全不一样，文化就要转变。

组织，授权管理体系

• 以流程为中心 vs 以人为中心
• 矩阵组织

• 管控中心 vs 能力中心

  
  

企业在全面云转型中，如何重塑匹配的工程师文化？

正视差异和差距，穷则变，变则通，通则久。

从why转变为why not？
工具平台不听汇报，听使用工具的人的声音。
最佳实践不可复制，都是属于企业自己的。

PS：华为的思路下，要求开发变成对ops也了解的全栈，和广东移动的理念不太一样。

不能因为管理者的害怕而走回头路。质量的严峻挑战。

代码分支的维护，质量要求严格。

平台支撑

实现在家编码，这是组织文化变更带来的。

公司内总会有不停造轮子的情况，通过内部开源来减少造轮子的情况。

正确的激励，树立CleanCode导向。奖励软件工匠（编程超过10-15年的人）

信任和不信任的度？
稳步才能保证变更不回弹。