许久没有现场参与业界DEVOPS大会了。对我来说，参加业界大会一方面是眼界上的开拓，另一方面是前进方向的校正，也知道天高地厚了。去年参加的很多，感触很多，今年参加以后发现业界整体技术又有一次跃进。
今日参加EE大会，主要关注还是DEVOPS和质量。笔记如下。
1. 极简-DEVOPS云原生转型之道（曾海剑）
运营商使用SOW松散方式，对外包进行管理（所谓交钥匙的模式）。在此模式下如何进行转型？
（1）驱动力
返工多，瀑布模式导致的返工多
质量低，通过运维来弥补软件质量的缺陷
统维难，不同部门不同项目，环境各自部署，维护各自承担
定位难，出现故障难于定位是研发问题还是运维问题。沟通成本高
人员流失快，且研发的核心痛点：浪费、质量。
外包型企业，没有获得源代码会带来项目绑架的情况。
从物理机到虚拟化到容器化，解决运维的痛点。不需要再去思考如何修理容器。
（2）转型之痛
放养阶段：研发效能团队建工具链，开发人员自己配置流水线（开发人员不懂工具链，不懂k8s，组织培训费时费力不讨好）
保姆阶段：开发人员题需求，研发效能团队配置流水线（累死研发效能团队）
自助阶段：把配置变成编排，开发人员自助编排流水线
核心思想是如何让开发人员零知识将代码发布到生产环境。
研发效能的思考：增效减负。减负指的是降低学习成本，减低沟通成本，降低配置成本。
（3）极简实践
一开始是开源方案，发现开源方案面向的都是专家，比如jenkins，gitlab CI/CD都是通过编程来实现流水线。
设计初衷——极简
简化复杂的技术：开发团队能力参差不齐，降低接入门槛，减低调试沟通工作量
简化复杂的流程：吧复杂的流程原子化，面向结果，隐藏复杂的环境就绪流程，隐藏复杂的编排发布流程
简化复杂的权限：通过统一接口编排能力，简化权限体系，面向多租户共用云环境
实现了动态编排、多模块流水线（一个流水线可以支持多个微服务）
一条流水线管理一个微服务，会导致难以对微服务的上线、灰度进行控制的问题。（通过服务网格解决）
服务编排——进化
微服务1.0，使用springcloud。通过开发方式实现服务治理，诞生背景是虚拟化
微服务2.0，使用Istio，以配置方式实现服务治理，不受语言限制，诞生背景是容器化
Dory从18年开始探索建设，近期将开源
2. 云原生容器化落地实践（去哪儿-邹晟）
（1）背景与收益
痛点：环境不一致、环境交付慢、服务器多运维成本高、降服务器成本、SDK推动升级难，周期长
1000，5000，8000虚机时出现质变（主要是物理设备故障，需要人工确认，KVM进行平移）
我们眼中的云原生：
是什么：云原生是一系列可以为业务赋能的技术架构准则，遵循它可以使应用具有扩展性、伸缩性、移植性、韧性等特点
为什么：基础架构需要演进，它可以让业务更敏捷
怎么做：DEVOPS、微服务、容器化、可观测性、反脆弱性（混沌工程）、service mesh、serverless
业务价值：
PO：敏捷性、弹性伸缩、资源成本
DEV/QA：环境稳定性、环境一致性
DEV/OPS：节省人力
去哪儿容器化进程
（2）实践路线图
容器化落地策略：尽量少改动业务性
IaaS层：re-host（评估最小成本）
PaaS层：re-platform
应用层：refactor（通过service-mesh，将熔断限流平移）
re-host五步：价值认同、制定规范、工具建设、迁移落地、验收
（3）关键实践
实践1 - 价值认同：容器化的ROI是多少，怎么证明？
自证价值-自己的服务先容器化
放大价值-解决业务线实际问题
技术宣讲-价值宣传，找VIP用户
实践2 - 规范制定
关注几个点：日志的统一，实时和离线Loki的使用，部署路径，端口号统一，新应用禁止KVM部署。
实践3 - 工具建设
通过对工具平台改造实现全自动化
CD：使用KubeSphere实现多集群管理平台。发布系统调用编译模块调用部署模块调用kubesphere。
实践4 - 迁移落地
- 前置校验：编译阶段自动检查配置
- 测试环境验证：自动升级SDK
- 线上验证：灰度发布，自动化验证
- 混合部署：kvm和容器混合部署
- 全量部署
- 观察：7天正常后停止KVM
资源成本：容器化前单机部署的kvm数：14个；容器化后单机部署的pod数：20个
（4）总结与规划
价值认同：从上而下推进。知之不深，则行之不笃；知之愈明，则行之愈笃。
产品同理心：用户收益、迁移成本、使用成本
工程化方法：自动化前置检查、升级SDK、测试、迁移
未来规划：稳定性治理、资源利用率提升、service mesh落地
3. 工程师文化（华为）
- 对工程师文化的思考
- 企业在全面云转型中，如何重塑匹配的工程师文化？
- 工具平台
对工程师文化的思考
企业工程师文化，不是脱离具体环境，独立存在的
文化不是你要求人家做什么，而且团队领导做什么，别人跟着做。
影响工程师文化的因素
企业顶层文化：以客户为中心，质量优先……关键是，真正在执行的是什么？
问题：会不会变成以一线销售为优先？
价值创造过程：商业模式，产品交付模式，研发模式，软件工程实践，工程师的工作方法，逐步影响
设备供应商和云服务供应商完全不一样，文化就要转变。
组织，授权管理体系
- 以流程为中心 vs 以人为中心
- 矩阵组织
-
管控中心 vs 能力中心
企业在全面云转型中，如何重塑匹配的工程师文化？
正视差异和差距，穷则变，变则通，通则久。
从why转变为why not？
工具平台不听汇报，听使用工具的人的声音。
最佳实践不可复制，都是属于企业自己的。
PS：华为的思路下，要求开发变成对ops也了解的全栈，和广东移动的理念不太一样。
不能因为管理者的害怕而走回头路。质量的严峻挑战。
代码分支的维护，质量要求严格。
平台支撑
实现在家编码，这是组织文化变更带来的。
公司内总会有不停造轮子的情况，通过内部开源来减少造轮子的情况。
正确的激励，树立CleanCode导向。奖励软件工匠（编程超过10-15年的人）
信任和不信任的度？
稳步才能保证变更不回弹。
