DevOps落地-总结：车联网行业、业务、困难、技术、工具链、方法论

工作回顾、一图胜千言

一图胜千言：

回顾过去2年，参加/负责了2个项目，《技术平台开发》、《IT基础设施项目》。涉及到的技术术语很多，日常工作也繁杂；

如有人问，在XX公司做什么，做出了什么成绩？工作确实有些“杂”，回答这个问题，很有必要复盘工作、系统思考、体系总结一下；

总结就是，在DevOps领域，主要是 CICD、容器平台、网络互联、工具链、应用容器环境设计 5个技术方面，做出了一点成果，支持公司车联网业务发展；

业务、行业的一点思考

用confluence画了一张图，公司的业务、技术都可以从这张图找到根源：

车联网业务

车联网，即把车、车主、车厂、数字服务商互联，如图所示，再此之上，承载各种业务场景。
典型的一个车企例子–特斯拉；而国内各大车企，或多或少，都想成为“特斯拉”。面临特斯拉这类互联网型车企的巨大挑战，网联化、数字化、智能化，车企的转型升级任务必要且紧迫；

三大ToB业务

公司的业务就是紧紧围绕车联网，围绕国内各大车企在，网联化、数字化、智能化、电动化，的转型需求。
公司业务围绕这张图开展的，客户是车企，提供技术服务。
根据公司定位；可总结为车企提供三大类技术服务：

• 平台建设，围绕 TSP平台建设，解决车、车主、车企连接问题；
• 生态聚合，打通 车主-TSP系统-数字服务提供商 链路；
• 数据增值，用大数据等技术助力车企拓展为数据企业；

图中当然还有其他业务，目前公司没有涉及，比如，

• 车机、Tbox车载硬件；
• 导航、支付等用车服务；
• 买车等营销服务；
• 保养、4S等养车服务；
• …等

困难、挑战

2018年，公司的技术栈为：
应用层，使用 Java/SpringCloud、Springboot/Nodejs、使用了微服务。
容器层，使用docker、docker-compose方式，没有使用kubernetes，没有容器平台。
网络层，没有明确规划，办公网络、云VPC网络、项目环境网络比较乱。
云平台层，共用一个阿里云，使用、权限比较混乱。

困难一：三低，效率低、士气低、质量低

• 效率低
  举些例子，这些例子是2018年初，我们遇到的效率问题。

活动	效率问题举例
构建	1. Jenkinsfile 维护工作量大、易出错。微服务化后，多个项目都几十上百个Git代码，每个Git一个Jenkinsfile，改一个环境地址要改几十上百个
部署	1. 微服务应用部署名称问题。不统一，易混乱；应用。
配置	1. 应用配置文件多问题。每次发布哪些配置更改过？
日志	1. 看应用日志问题。开发问，去哪里看日志，我不会用k8s，kubectl
监控	1. 看应用资源监控问题。开发问，我的应用CPU/MEM占用情况哪里能看？
调试	1. 应用调试问题。我怎么重启一下的服务，怎么查看监听的端口？2. 本地调试问题。我的应用要依赖XXX才能调试，我本地怎么访问XXX？
访问	1. 应用域名问题。我的服务部署上去，域名、IP是什么？2. NodePort端口冲突问题。应用这么多，多个Namespace，NodePort冲突！3. 域名混乱问题。微服务几十个应用，这么多域名，哪个域名是哪个服务的,？
权限	1. 运行环境权限问题。谁把我的应用重启了？
文档	1. 设计文档画图问题。2. 1. 设计文件拷来拷去，好麻烦，有没有在线编辑在线协作的，还能画图的
沉淀	1. 配置构建，手动部署 工作量大，易出错，重复工作，下个项目还得搞一遍；个人技术没法提高，问题一直重现，也没办法沉淀成公司成果，好烦；
xxxxxxxxxx

• 质量低
  一些举例

活动	质量问题举例
代码分支	1. 分支管理问题。谁又把没经过测试验证的代码合并进master分支？！
测试环境	1. 代码管理问题。Test环境的镜像版本能不能和Prod环境保持一致？
beta部署	1. 生产能不能有一种部署新版本，但是对线上影响小的方式。
生产权限	1. 生产环境在哪，怎么访问，我需要看生产环境的实时日志
xxxxxxxx

归纳起来就是，分支管理问题，环境部署问题，环境设计问题。

• 士气低
  加班多效率不高、产出还质量不高；上生产没有信心；上班心情不好啊。

困难二：多业务部门，项目支持问题

这个困难，是公司增长到200+人后，领导层进行内部组织架构改革。分五大业务部门。各个业务部门负责独立的年度API。也将 售前、产品经理、BA、前端开发、后端开发、QA等划归到业务部门。

问题来了，分还是合。建平台还是建烟囱？
DevOps建设的系统，之前都是平台化支持全公司的方向来建设的。同时DevOps 工作范围，从底层 云平台、网络、系统、容器、中间件、工具链系统，哪些应该平台化，哪些部门化？

技术、工具的一点思考

技术为业务而生。技术为效率、质量而生。技术也要紧跟新技术浪潮。
针对困难一，回顾来看，主要是通过：技术升级，来解决。
针对困难二，回顾来看，主要是通过：调整团队人员架构、明确职责、技术上改造适配多业务部门制，来解决。

我的工作 - 落地

目前升级到的技术栈，用一张技术图谱（上图）展示。
考虑困难与问题，结合业务背景作为需求，针对性的从多个技术层次解决。
围绕服务端技术栈升级改造，落地 应用容器环境设计、容器平台、CICD、网络互联、DevOps工具链、云平台。围绕解决困难一。

落地：一段时间，某个技术方向上，进行预研、选型、规划、设计、部署、二次开发，投产、维护 ，持续循环。

当前情况，大数据PaaS还处于初步阶段，应用安全未成型。其余技术已成型，等下一轮技术才需要大幅更新。

容器平台落地–云计算、混合云、容器技术、微服务背景

目前已落地成型。私有云为 RKE/rancher/AD/网络互联。公有云为 容器服务采购/rancher/AD/网络互联。
回顾过程，这部分是最难落地的。
容器化、微服务化的应用架构，量上来了，系统和应用加了一层容器。
故，一定会遇到部署难，调试难，访问难，配置难的问题。难就难在，任何一个没有解决，都没法完全落地。
而解决这些困难，涉及个各技术面。上要跟应用框架（业务开发、架构师）一起解决，下要跟网络、基础设施一起解决。
我们的解决办法是

困难	办法
部署难	CICD二次开发，非常强调自动化、简单性
调试难	引入K8S UI（rancher），打通容器网络，支持本地调试
访问难	overlay、underlay网络统一IP规划，打通容器网络、办公网络；CD自动生成ingress 内网、公网域名
配置难	引入 spring config，nacos 配置中心

研发工具链落地 – DevOps 背景

目前DevOps工具链已落地近2年，没有大的变化。
该部分主要工作是，部署，相互集成，体验调优（速度、易用性）、多部门租户规范。
比较有体会的是，

• confluence有画图插件后，大家都非常喜欢用了（注：我画的这些图都是confluence里画的）。
• 围绕 用户体验为中心，持续优化。工具最好是好用才用，而不是强行推广。

网络互联落地 – 混合云、容器网络背景

ToB企业的典型企业网络：

云计算、容器技术下的ToB企业的典型混合云网络：

容器技术下，容器平台某Kubernetes(K8S)集群的容器网络：

网络互联落地，经过近一年多实践，取得很好的效果。
我们在网络互联方面做了些创造性、巧妙性的工作，取得了事半功倍的效果。
在云计算，公有云背景下，引入了Kubernetes 容器，应用容器的访问是一大效率问题。
解决这个问题，有几个心得：

• 从业务、应用的角度提需求去设计企业网络。
• 容器网络考虑在内的统一IP地址规划。即Kubernetes的CIDR。
• 容器网络考虑在内的网络互通。开发人员在办公网络里，快速访问容器应用，支持本地调试，业务流量打到办公网络，大幅提高了开发效率。
• 客户网络的互联技术vyos/openV|P|N。客户网络使用的设备千差万别，安全策略千差万别，一种适应性很强的网络技术给大幅提高了我们效率。满足异地协同研发。

应用容器环境设计

CICD 落地 – Kubernetes、微服务背景

我们CICD核心实现设计如下，我们部分开源出来 https://github.com/chimeh/cicd-s2e-runner

创新点：

1. runner也容器化，docker-compose方式。非常强调新项目启动、到客户环境快速建立CICD。
2. 强调使用简单化。无论什么语言，CICD只需要一条命令 s2i /path/to/src，完成源码检测、artifact构建、docker构建入库、部署K8S。
3. 及其方便集成。我们采用CLI、API方式集成，易于与多种多版本仓库工具链、Kubernetes集成。
4. runner抽象四大部分，快速定制CICD逻辑。runner由 client/cmd、secrets、templates、cicd-logic四大部分组成。
   

困难的解决

通过上个章节，各个层次的技术落地。工作汇总如下

技术层次	落地工作
业务层
应用层	nacos 容器化，CICD二次开发，自动化，域名自动化，非常强调自动；化、简单性；取好名称
PaaS-容器层	容器网络规划、rancher部署、私有云RKE，公有云TKE。引入K8S UI（rancher），打通容器网络，支持本地调试
PaaS-数据库、中间件层	买，库名规范，
PaaS大数据层	目前相关经验少
网络互联层	IP地址规划、overlay、underlay网络统一IP规划，打通容器网络、办公网络；CD自动生成ingress 内网、公网域名
云平台层	买、账号集成，采购流程，权限设计
xxxxxxxxxxxxxx

落地工作：一段时间，某个技术方向上，进行预研、选型、规划、设计、部署、二次开发，投产、维护 ，持续循环。

业务的技术、员工的技术

技术为业务而生，也要紧跟新技术浪潮。
技术承载业务，也助力员工技术成长。
现在回头看，云计算、容器技术、微服务背景下的技术栈升级改造，确实很有必要，具体体现在：

• 好招人；
  近一年面试过程中，候选人还是很认可公司技术栈的。所谓跳槽，看薪资、看平台、看行业、看技术、看薪资。看技术方面取得良好效果。

• 助力售前项目；
  公司积累的 容器、微服务、敏捷开发、CICD、DevOps等技术经验汇总成材料，在去竞标等方面，还是有不少助力；

• 有效提高了效率、质量，大体降低了成本；

• 有利岗位忠诚度、岗位满意度；
  “技术是不是过时了，积累的经验，跳槽是否有帮助？”多数技术岗会有这个问题，直接影响岗位忠诚度与满意度。虽然待遇、薪资无法跟大厂，但是技术栈对员工的技术成长方向是匹配的。

个人回顾，虽然容易感觉“杂”，体系化总结后，我觉得自己还是技术方面成长也是不少；

务实与务虚：项目实施、方法论、团队组织的一点思考

背景、问题、 目标、任务、成果

TODO

拿来主义与轮子

TODO

理论指导、最佳实践、套路、模板

TODO

成果与经验教训

TODO

总结

TODO