五.DevOps 的四个重要层面
认真评估你的软件的交付机制以及运维团队左移和右移的程度是你选择采用何种 DevOps 分合策略，以及 DevOps 实践是否成功的关键因素。
DevOps 的分与合，与运维工作的左移右移，云技术的发展，云原生标准的统一有极大关系，DevOps 概念可以在很多层面上得到体现，本文就其中主要的，可以让 DevOps 团队真切感知的四个层面来做简要介绍：
从人员管理层面看 DevOps 要想实践 DevOps 的分与合，必须要配置上合适的团队配置。这里有若干种配置的分类：
- 第一种模式属于 Dev 和 Ops 分的比较彻底的类型，这种人员模型可以适配业务运维左移程度较少，交付流程较为标准化的场景，运维团队制定流程，流程和运维服务共享给所有开发团队。
- 第二种模式属于 Dev 和 Ops 合的比较彻底的类型，这种人员模型可以适配业务运维左移程度很高，基础设施运维右移程度也很高的场景，基本上实现了每个开发团队配合云就能完整实现闭环，已经没有传统意义的独立运维部门。
- 第三种模式属于 Dev 和 Ops 部分分开、部分合并的类型，这种人员模型可以适配业务运维左移程度较多，但基础设施运维右移程度较少的场景，适用于希望能实现开发团队闭环，又对云基础设施有信任问题，需要自建基础设施（例如私有云，或基于公有云的私有基础设施）类型的团队，这种模式跟第二种模式的唯一差异是是否有自主基础设施运维团队，在超大规模 DevOps 建设私有云的场景多见。
- 第四种模式属于 Dev 和 Ops 的合并已经达到极致，可以完全无运维团队工作，在使用云基础设施和合适的开发工具基础上就可以实现开发团队内完整闭环，例如全量使用 Serverless 技术，无需担心负载均衡，弹性扩缩容，监控等基础设施工作。
没有哪个模式是完美的，在实践自己的 DevOps 人员配置的时候，要想清楚自己的实际场景，当想清楚自己的人员配置的时候，要想保持高效就要考虑这些人与人之间信息如何流转顺畅。
从信息流转层面看 DevOps DevOps 是一种协作文化，协作流程，而协作的本质是顺畅、精准的信息流转。一个简化的典型的 DevOps 信息流转模型大致如下：
信息流转顺畅和精准的根本在于信息是否是结构化、流程化、标准化的。一个所有信息流转都依赖聊天群、开会、邮件等形式解决，看似能够一触即达的信息流转，往往会有重点不突出，信息遗漏，信息依赖人为跟进等问题，其实是不顺畅也不精确的。
核心要把握 DevOps 实践团队的如下节点是否信息传输顺畅且精准：
- 开发交付测试阶段：信息提供方是开发、主接收方是测试、抄送方是产品经理、项目经理、运维等，这个提测申请是否结构化？是否具备标准？有没有流程？是否有专用工具支撑？
- 测试回馈：信息提供方是测试，主接收方是开发、抄送方产品经理、项目经理等，这个信息最简单的方式是采用体系化的缺陷管理系统配合上下游来一起管理，细化流程和标准后即可实现顺畅，精准传达
- 交付发布：信息主提供方是开发，主接收方是运维，抄送方是产品经理、测试、项目经理等，这个阶段的自动化程度是相当重要的，要想实现自动化，前提是结构化、流程化、标准化先行。在本文的后续段落中会以 Kubernetes 体系的自动部署为实战来介绍如何结构化、流程化、标准化最终实现自动化
这几个关键环节都定义好标准和流程的时候，再次要去看其他环节的细化信息流转问题，接下来就是需要考虑使用何种工具系统为此标准和流程提速的时候了。
从工具系统层面看 DevOps DevOps 的协作文化目的是提升团队的效能，而自动化工具是必备的，好的工具体系应该是整合的、角色切面的、自动流转的。工具系统目标是顺畅精准的传输信息并且高效的执行机械化操作。
整合性：DevOps 的开源、商业软件有很多款，然而大多数软件系统之间都是弱整合状态，很多都是宣称支持 OAuth 或者 LDAP 用户体系就算整合了，这里面的差距还很大，例如 Jira 的项目和 GitLab 的项目，GitLab 的项目与 TestLink 的测试计划，这些实际的概念在不同的系统之间都遵从着不同的产品设计哲学，实际上弱整合的工具系统在提升团队信息流转效率上并没有太大帮助。
角色切面：好的 DevOps 工具系统应该像是一个为工厂量身定制的生产流水线，各个角色各司其职，关注精准的信息，执行标准的操作，输出标准的结果。在弱整合的工具系统里可能不同系统的用户、角色、权限设计都有很大差异，难以实现角色切面。例如一套基于 Jira GitLab jenkins Kubernetes 的体系，运维角色应该加入 Jira 的项目中么？产品经理是否需要关注 jenkins 的 Job 执行状态？
自动流转：自动流转是为了解决重复性的机械劳动而设计的，要想具备自动流转的特性，整合性和角色切面也必须设计的非常好，开发完毕到提测自动部署，测试通过到自动发布，在设计好流程和标准后都是一些机械化的重复劳动。
工具系统不是万能的，有时候你会发现有了好的人员结构、信息流转方式、整合性的工具系统，实践起 DevOps 还是有一定困难，那你可以看看如下这个点：技术架构。
从技术架构层面看 DevOps 技术架构对 DevOps 的影响主要体现在构建、部署、运维环节。不同的软件类型，技术架构在这三方面是有很大差异的。例如单机手游，只有构建和发布市场，基本不存在部署、运维环节。而微服务架构 SaaS 化的多租户云服务在这方面就复杂的多。
这里以典型的服务器端应用的技术架构升级过程来作简要分析，例如对于一个基于 Spring 框架写成的 Java Web 应用，其发展历程可能是这样的：
- 单体 Tomcat：构建一般使用 IDE 配合 Maven/Gradle，少许团队会使用 Jenkins 之类的进行自动化构建 war 包，部署往往选择 scp/sftp 形式进行发布，停机部署，需要运维人员专门人工操作，容易出现错误
- 多实例 Tomcat Nginx 负载均衡 动静分离：构建开始变的复杂，前端的 js css 等需要进行独立的压缩和上传，部署过程有很多运维团队开始选用 Ansible 之类的便于管理 Nginx 的复杂配置文件和多实例并行发布，Ansible 等工具为自动化的发布提供了诸多便利，但仍然要求运维人员去撰写难以维护的 playbook 和服务器的基础软件环境
- 前后端分离 容器化：当以 Docker 为代表的容器技术开始流行的时候，团队开始尝试构建的结果不再局限到 war 包层面，可以把前端和后端分别构建出 Docker 镜像，以 Docker 镜像作为标准交付，但服务的配置信息、扩缩容能力，健康检查等问题仍然困扰着运维团队
- 微服务化架构 容积集群部署：以 Kubernetes，Istio Service Mesh等为代表的容器集群编排和微服务技术开始逐步进入大家的视野，部分团队开始尝试让开发团队自主通过 Kubernetes 工作负载 Yaml 文件、ConfigMap 等形式管理配置信息，使用 Service 配合微服务的流量控制体系进行灰度控制、服务降级、熔断处理、标准化健康检查监控等
- Serverless 无服务器架构：以 Serverless Framework、AWS Lambda、Knative 等为代表的新一代无服务器架构的服务器端应用已经帮助一些技术领先的团队实现了进一步的去运维化，后端开发只需要按照云函数的定义要求进行少量的声明或者配置，即可实现全套的 CI/CD、负载均衡、弹性伸缩、生产级别高可用等能力。如果你还不知道什么是 Serverless，欢迎来这里了解：https://cloud.tencent.com/product/sls
云的发展也映射着技术架构的变迁，也引领着基础设施运维的右移，大致分为三个阶段：
- VM/虚拟机 实现了去硬件化 Hardwareless
- Container/容器 实现了去操作系统化 OSless
- 云函数/Serverless 实现了去服务化 Serverless
每一种技术架构的 DevOps 的实践模式是有差异的，分与合的程度也不一样。仔细品味这些技术架构的特点，认真评估自身团队业务运维左移和右移的程度，就可以选择出合适的人员管理模式、选择适合自己的工具系统，形成顺畅、精准的信息流转，从而让 DevOps 的实践取得实质性成果。
六.DevOps 的粘合剂：持续部署
持续部署是软件交付的一种形式，常用于服务器端软件的交付，在这里我们以 CODING CD Kubernetes 来简要讲述一个服务器软件持续部署模式，我们假定团队现在的各方面基本情况如下：
- 业务运维部分左移：常规发布、配置管理等基础业务运维左移到开发团队
- 基础设施运维部分右移：基础计算资源由云全托管，直接使用云的 Kubernetes 集群，负载均衡器，数据库等
- 开发团队和运维团队分离：运维团队更多的是制定业务运维规范标准和流程，在云的基础上层进行更高层次的基础设施运维，如制作业务监控体系，信息安全，日志系统等
- 整合式 DevOps 系统：直接使用 CODING 提供的集敏捷项目管理，测试管理，代码管理，持续集成，制品库，持续部署为一体的 SaaS 服务
- 简单的微服务技术架构：未引入如 Istio 等高级微服务架构（引入微服务架构的持续部署跟此示例类似，但细节过多，不适于在此文详述），使用 Docker 镜像 Kubernetes
这种模式可能是适合目前国内大多数团队的现状的模式，具备相当的代表性，跟此模式有差异的团队也可以通过此模式来品味本文的 DevOps 思考，去改进自身的实践。
