前  言

90年代末期和21世纪早期，市场主要以传统C/S架构为主，而且流行胖客户端，对于服务器端的压力较小，运维对于企业的价值并不是很高，也往往被视为成本部门。当时软件本身开发、测试的时间成本较高且企业多采用瀑布式的开发模型，客户端软件发布往往是一个重量级操作，经常以年为周期发布新版本。运维人员不用和开发人员直接高频接触，甚至针对一些纯离线业务，并不设有运维人员岗位。随着互联网的发展，由传统客户端软件逐步演变为面向PC和手机终端的业务。这时候软件架构逐渐往B/S架构发展，大量业务开始依赖服务器端的计算，多频次版本迭代取代了年度级别的产品发布，确保稳定持续的提供可用服务变得愈发重要。长期以来，开发者和运维人员的协作方式是分裂的：开发者做的事情是将程序打包，交给运维部门进行部署上线；而运维部门负责将程序安装与部署到生产环境。运维人员不关心代码是如何运作的，开发人员不知道代码如何运行在服务器上，导致了生产效率低、故障排除速度慢的问题。随着开发和运维协作问题对于发布速度的影响不断加深，软件行业的工程师借鉴制造业中例如“精益制造”的先进理念，通过研究新的管理方法，引入自动化集成，使软件开发周期中的研发、测试、部署团队能够更紧密的结合，以提升生产力。其中，DevOps和SRE是其中较为流行的两个开发理念。

— DevOps：开发运维强力催化剂 —

DevOps旨在关注全流程效率提升，制定一系列指导原则以改进开发和IT运维的交互关系，缩小开发和运维团队之间的工作差异，让有效的交付生产系统更加稳定和可维护。

在DevOps文化中，企业需要关注开发交付流程的优化，监控反馈机制的完善和应急处置能力的积累。DevOps主张三种原则：流动原则、反馈原则、持续学习原则。流动原则主张使工作能快速稳定的从开发端流动到运维端，实践包含流水线构建、自动化测试、可持续集成构建等，通过降低每次交付规模来增强工作内容的可视化。反馈原则体现在开发过程中构建反馈回路，引入同行部门评审，将质量控制和决策的权力渗透在各个团队，并通过监控机制及时遏制问题，帮助企业持续积累经验防止类似问题复发。持续学习通过建立持续学习和改进的制度文化提升团队能力，包含学习复盘、流水线保护运作等实作，帮助团队快速地适应变化的市场环境，提高企业竞争力。

总体来看，DevOps更像是一个抽象类别的指导方针，并不告诉怎么做才会成功，而是制订一些基本原则帮助企业根据实际情况制定符合本企业特点的开发和管理方式，只要符合理念，就可以说是DevOps文化的实践。不同规模、不同种类业务和不同研发及生产环境的公司其实际执行DevOps理念的方式均不尽相同。

— SRE：Google开发运维理念实作

—除了DevOps，我们往往还会听到一个与开发运维协作效率相关的名词——SRE（Site Reliability Engineering）。SRE一词的出现实际上早于DevOps，与DevOps不同，SRE是Google在2003年定义的一个岗位，发展到后面才逐步演变为一种工程思维。那么Google为什么会提出SRE呢？作为大型的网站公司，Google为全球十几亿用户提供服务，即使是短暂的服务不可用，也会带来大量的损失。因此，服务可用性对Google至关重要，使得Google的运维人员需要对开发有深入了解才能更好的完成工作，在出现应急故障时进行及时排除并解决。

SRE的工作职责可以总结为紧急事件处理、日常运维和工具与业务开发三个方面。可以看出，SRE与普通运维不同，不仅包含了运维职责，还要兼顾开发。这样的要求使得SRE深入产品研发和架构中，能够了理解产品的开发流程和设计理念，便于更好的在应急事件发生后及时定位和解决问题。

• 紧急事件处理

  
  
  

SRE团队主张系统能及时监控到应急事件的产生，并发到相应的负责人。应急事件出现后，团队每个人都明确责任分工，如果发生跨部门之间协作的问题，也会持续不停的跟踪处理，保证问题以最快的速度解决。

• 日常运维

  
  
  

SRE的日常运维工作需要保证系统能够进行正常更新、快速迭代，并进行容量管理。同时，SRE也要对业务有深入了解，能够向公司提出资源分配和规划方案，并确保这些方案的提出有数据支撑，能够解决问题。

• 工具与业务开发

  
  
  

SRE在研发方面一方面参与了公司自动化管理工具开发、产品架构设计等工作；另一方面与业务部门之间进行配合并给予反馈，帮助产品部门确定数据指标，给予需求和成本方面的决策帮助。

足够的开发能力使得SRE能够深入研发过程，在应急处置和日常运维时可以避免旧时因运维人员技术栈广度不够且对产品研发过程理解不足造成的部署效率问题。

— SRE实作与DevOps理念的区别 —

SRE岗位专注于开发和运维工作内容本身，更依靠人的能力去兼顾开发与运维。而DevOps并不是一套具体的实作细则，其理念贯穿了开发、测试、运维，专注于利用自动化工具和流程管理方法以缩短新功能的交付时间，加速技术价值流。较于DevOps，SRE作为一个具体岗位更偏向于包含更多的实现细节，强调“人”的作用；而DevOps文化更突出反馈、工具贯穿开发生命周期的作用，更强调“规则”的控制力。

— DevOps和SRE在容器时代的演变 —


容器技术的发展使得DevOps广泛落地虚拟化技术的出现对于DevOps的落地起到关键作用。Devops实现的技术关键在于自动化部署、标准化交付、应用隔离和配置管理等，而虚拟化技术的出现则提供了技术保障。在初期，DevOps的流水线构建主要依靠Vagrant提供虚拟化技术实现应用隔离和部署，利用Puppet、Chef进行配置管理。但基于虚拟机的隔离和编排依旧繁琐而笨重，导致启动速度慢、传递交付笨重。

随着容器技术的出现，轻量级隔离和资源管理优势令互联网企业开始重视。Docker带来了更轻量的运行、更快速的启动和更便捷的分发模式，由此开启了DevOps的容器实现时代。Docker为DevOps的实施提供了更多在开发部署和编排的操作延展性，流水线的所有环节都是流畅的，易配置的。开发者在代码提交后生成应用镜像，并在自动化测试通过后服务以镜像的形式产出并上传到镜像仓库中，便于后续测试、部署上线。环境配置文件和应用一次性打包确保了环境的一致性，使得定位复现问题更方便。镜像的可复用性和更新的叠加性也使得应用的回滚、升级都变得容易。

此外，伴随着容器技术的成熟，应用微服务化也日益流行。微服务化和DevOps的发展是互相成就的：微服务的出现是为了实现开发的快速、敏捷、反馈，这本身就与DevOps的理念相合；而稳定、自动化的流水线又是应用微服务化得以实现的基础设施。另外，微服务化解耦了服务，使应用的运行更稳定，仅在对应功能的下的容器里进行操作即可实现功能变更，提升自动化框架成功率。可以说，微服务不光是一种应用架构，更是包含了敏捷开发、DevOps容器等技术的综合实践。

SRE面向云的变化

随着大数据和云计算时代的到来，依靠分布式服务器所构建起来的“云”集群带来了强大的计算能力；资源的动态伸缩、高扩展性也使得集群的架构变得更加复杂多元，极大增加了运维难度。因此，如何保证复杂云业务环境高可用，同时维持高频度的迭代更新为SRE带来了新的挑战。

对于SRE来说，如果和以往一样依然通过人力运维大规模复杂集群必定是不可取的，依靠自动化工具进行管理则省时省力。以Google为例，首先它开发了集群编排工具Borg（Kubernetes是它的开源实现），使云系统的软件业务运行不受硬件故障的影响，实现整个容器集群的自治；Bigtable、Spanner等工具则带来了集群级别的可持久化的存储系统，以保证数据多副本和一致。此外，大规模应用监控必不可缺，需要针对容器集群进行自动监管，Google通过监控工具Borgmon（启发了Prometheus的实现）对容器云集群无间断监控以及基于时间序列的告警。这些工具使SRE不再需要直接做一线的运维操作，但对这些系统框架的掌握成为了架构“云”化时代下对SRE从业者的基本要求。

可以说SRE一方面在适应云环境对工作内容带来的变化，另一方面推动了容器集群管理和微服务架构的发展，进一步提高了服务云端化后的可靠性。集群监控跟踪能力的提升也使SRE可以对服务运行中的各环节进行自动化的数据收集和追踪，高价值的数据资产为SRE团队深入了解应用上线后的性能问题和用户行为带来便利，从而形成正向的反馈回环。

—星环科技TDC：DevOps理念实践 —

现代的开发模式不仅要有理论上的支撑，基础的工具也是流程运作必不可少的要素。一些公司开始为企业构建平台级的应用管理系统，星环科技大数据云平台TDC便是其中之一。TDC一直致力于为企业提供全面的数字化建设支持，除了应用部署能力，还提供支持服务线上应用开发的DevOps工作台，为企业的开发、上架、部署、运维提供一站式解决方案。

TDC-DevOps工作台工作流程

TDC—DevOps工作台整合了包括GitLab代码管理、镜像构建、镜像管理、部署等一系列开发管理工具，贯穿应用开发、构建、测试全过程。下面以星环科技内部采用的开发过程为例，介绍应用是如何从代码开发到部署上TDC的。

首先，代码通过开发平台集成的GitLab进行管理，代码提交后，分别经过以下四个阶段，产生不同成熟度的镜像。

• Precommit：开发人员本地代码commit到Gitlab仓库后，在合并到主干分支之前，由GitLab pipeline自动化触发单元测试和静态代码检查，此阶段称为precommit，测试通过后则可被合并从而进入postcommit阶段。

• Postcommit：postcommit阶段会对合并后的代码进行构建，产生的Java代码包被推送到软件包管理库，而容器镜像和charts被推送到镜像管理库。随后TDC的包管理工具WALM将容器应用部署到开发测试环境中，并在Jenkins上覆盖基础测试。这个阶段的测试通过后，应用镜像将会被打上postcommit标签。

• Gold：通过postcommit的镜像将在Jenkins上继续进行更全面的集成测试，这个阶段完成后，镜像将会被打上gold标签。

• Release：版本发布前，测试人员从gold镜像中挑选出满足当前发布一个版本，进行发布验证，如果可以满足生产环境的需求，则被release版本推送到生产环境仓库中，由运维/SRE人员进行生产环境的部署、升级等操作。

• 
  

TDC开发质量管控流程图

TDC提供的能力在于，它使上述过程不需要在各个平台间跳转完成，只需要在统一的操作平台上一体化的实现。而应用开发完成后，运维/SRE人员仅需通过TDC提供的可视化上架和部署接口，便可以快速进行上架。然后通过资源参数配置，实现应用一键部署。

TDC应用上架图

此外，星环科技自主研发、整合了一系列运维工具，形成一套完整的治理中心来协助应用运维。TDC的运维管理工具能够对应用的时序指标如CPU、内存等进行收集、监控和告警；而且可以通过分布式服务的故障追踪，快速定位微服务故障点以便于及时处理；同时内置日志管理平台，以帮助进行日志分析。

TDC—Aquila平台运维管理组件

作为星环科技自主研发的数据平台，TDC DevOps平台集合了DevOps和SRE的管理特色，开发整合了一系列自动化组件，为企业的应用管理实践带来了看得见的便利：开发阶段中环环相扣的质量管控流程加速了开发；简易的上架和部署为运维人员节约了精力；自研的运维管理组件则提高了日常维护的效率。企业通过星环科技TDC DevOps工作台可以实现对DevOps和SRE理念的优秀实践。

— 软件开发/运维流程的未来趋势 —

在未来，自动化、敏捷和快速反馈依旧会是软件开发交付的趋势。随着跨云业务的发展，开发运维间的协同也会不断在云端进行；伴随着云联邦场景，跨云测试环境以及代码跨云端自动化部署和交付或将变为广泛实践。智能运维或将从实验走向落地，对云系统全链路进行问题跟踪监控、归纳和预测，保证各类云业务在生产中更稳定的迭代及运行。此外，安全问题也会逐渐成为关注焦点，目前安全团队和开发团队开发相对独立，安全测试引入流水线已是所需。

前  言

90年代末期和21世纪早期，市场主要以传统C/S架构为主，而且流行胖客户端，对于服务器端的压力较小，运维对于企业的价值并不是很高，也往往被视为成本部门。当时软件本身开发、测试的时间成本较高且企业多采用瀑布式的开发模型，客户端软件发布往往是一个重量级操作，经常以年为周期发布新版本。运维人员不用和开发人员直接高频接触，甚至针对一些纯离线业务，并不设有运维人员岗位。随着互联网的发展，由传统客户端软件逐步演变为面向PC和手机终端的业务。这时候软件架构逐渐往B/S架构发展，大量业务开始依赖服务器端的计算，多频次版本迭代取代了年度级别的产品发布，确保稳定持续的提供可用服务变得愈发重要。长期以来，开发者和运维人员的协作方式是分裂的：开发者做的事情是将程序打包，交给运维部门进行部署上线；而运维部门负责将程序安装与部署到生产环境。运维人员不关心代码是如何运作的，开发人员不知道代码如何运行在服务器上，导致了生产效率低、故障排除速度慢的问题。随着开发和运维协作问题对于发布速度的影响不断加深，软件行业的工程师借鉴制造业中例如“精益制造”的先进理念，通过研究新的管理方法，引入自动化集成，使软件开发周期中的研发、测试、部署团队能够更紧密的结合，以提升生产力。其中，DevOps和SRE是其中较为流行的两个开发理念。

— DevOps：开发运维强力催化剂 —

DevOps旨在关注全流程效率提升，制定一系列指导原则以改进开发和IT运维的交互关系，缩小开发和运维团队之间的工作差异，让有效的交付生产系统更加稳定和可维护。

在DevOps文化中，企业需要关注开发交付流程的优化，监控反馈机制的完善和应急处置能力的积累。DevOps主张三种原则：流动原则、反馈原则、持续学习原则。流动原则主张使工作能快速稳定的从开发端流动到运维端，实践包含流水线构建、自动化测试、可持续集成构建等，通过降低每次交付规模来增强工作内容的可视化。反馈原则体现在开发过程中构建反馈回路，引入同行部门评审，将质量控制和决策的权力渗透在各个团队，并通过监控机制及时遏制问题，帮助企业持续积累经验防止类似问题复发。持续学习通过建立持续学习和改进的制度文化提升团队能力，包含学习复盘、流水线保护运作等实作，帮助团队快速地适应变化的市场环境，提高企业竞争力。

总体来看，DevOps更像是一个抽象类别的指导方针，并不告诉怎么做才会成功，而是制订一些基本原则帮助企业根据实际情况制定符合本企业特点的开发和管理方式，只要符合理念，就可以说是DevOps文化的实践。不同规模、不同种类业务和不同研发及生产环境的公司其实际执行DevOps理念的方式均不尽相同。

— SRE：Google开发运维理念实作

—除了DevOps，我们往往还会听到一个与开发运维协作效率相关的名词——SRE（Site Reliability Engineering）。SRE一词的出现实际上早于DevOps，与DevOps不同，SRE是Google在2003年定义的一个岗位，发展到后面才逐步演变为一种工程思维。那么Google为什么会提出SRE呢？作为大型的网站公司，Google为全球十几亿用户提供服务，即使是短暂的服务不可用，也会带来大量的损失。因此，服务可用性对Google至关重要，使得Google的运维人员需要对开发有深入了解才能更好的完成工作，在出现应急故障时进行及时排除并解决。

SRE的工作职责可以总结为紧急事件处理、日常运维和工具与业务开发三个方面。可以看出，SRE与普通运维不同，不仅包含了运维职责，还要兼顾开发。这样的要求使得SRE深入产品研发和架构中，能够了理解产品的开发流程和设计理念，便于更好的在应急事件发生后及时定位和解决问题。

• 紧急事件处理

  
  
  

SRE团队主张系统能及时监控到应急事件的产生，并发到相应的负责人。应急事件出现后，团队每个人都明确责任分工，如果发生跨部门之间协作的问题，也会持续不停的跟踪处理，保证问题以最快的速度解决。

• 日常运维

  
  
  

SRE的日常运维工作需要保证系统能够进行正常更新、快速迭代，并进行容量管理。同时，SRE也要对业务有深入了解，能够向公司提出资源分配和规划方案，并确保这些方案的提出有数据支撑，能够解决问题。

• 工具与业务开发

  
  
  

SRE在研发方面一方面参与了公司自动化管理工具开发、产品架构设计等工作；另一方面与业务部门之间进行配合并给予反馈，帮助产品部门确定数据指标，给予需求和成本方面的决策帮助。

足够的开发能力使得SRE能够深入研发过程，在应急处置和日常运维时可以避免旧时因运维人员技术栈广度不够且对产品研发过程理解不足造成的部署效率问题。

— SRE实作与DevOps理念的区别 —

SRE岗位专注于开发和运维工作内容本身，更依靠人的能力去兼顾开发与运维。而DevOps并不是一套具体的实作细则，其理念贯穿了开发、测试、运维，专注于利用自动化工具和流程管理方法以缩短新功能的交付时间，加速技术价值流。较于DevOps，SRE作为一个具体岗位更偏向于包含更多的实现细节，强调“人”的作用；而DevOps文化更突出反馈、工具贯穿开发生命周期的作用，更强调“规则”的控制力。

— DevOps和SRE在容器时代的演变 —


容器技术的发展使得DevOps广泛落地虚拟化技术的出现对于DevOps的落地起到关键作用。Devops实现的技术关键在于自动化部署、标准化交付、应用隔离和配置管理等，而虚拟化技术的出现则提供了技术保障。在初期，DevOps的流水线构建主要依靠Vagrant提供虚拟化技术实现应用隔离和部署，利用Puppet、Chef进行配置管理。但基于虚拟机的隔离和编排依旧繁琐而笨重，导致启动速度慢、传递交付笨重。

随着容器技术的出现，轻量级隔离和资源管理优势令互联网企业开始重视。Docker带来了更轻量的运行、更快速的启动和更便捷的分发模式，由此开启了DevOps的容器实现时代。Docker为DevOps的实施提供了更多在开发部署和编排的操作延展性，流水线的所有环节都是流畅的，易配置的。开发者在代码提交后生成应用镜像，并在自动化测试通过后服务以镜像的形式产出并上传到镜像仓库中，便于后续测试、部署上线。环境配置文件和应用一次性打包确保了环境的一致性，使得定位复现问题更方便。镜像的可复用性和更新的叠加性也使得应用的回滚、升级都变得容易。

此外，伴随着容器技术的成熟，应用微服务化也日益流行。微服务化和DevOps的发展是互相成就的：微服务的出现是为了实现开发的快速、敏捷、反馈，这本身就与DevOps的理念相合；而稳定、自动化的流水线又是应用微服务化得以实现的基础设施。另外，微服务化解耦了服务，使应用的运行更稳定，仅在对应功能的下的容器里进行操作即可实现功能变更，提升自动化框架成功率。可以说，微服务不光是一种应用架构，更是包含了敏捷开发、DevOps容器等技术的综合实践。

SRE面向云的变化

随着大数据和云计算时代的到来，依靠分布式服务器所构建起来的“云”集群带来了强大的计算能力；资源的动态伸缩、高扩展性也使得集群的架构变得更加复杂多元，极大增加了运维难度。因此，如何保证复杂云业务环境高可用，同时维持高频度的迭代更新为SRE带来了新的挑战。

对于SRE来说，如果和以往一样依然通过人力运维大规模复杂集群必定是不可取的，依靠自动化工具进行管理则省时省力。以Google为例，首先它开发了集群编排工具Borg（Kubernetes是它的开源实现），使云系统的软件业务运行不受硬件故障的影响，实现整个容器集群的自治；Bigtable、Spanner等工具则带来了集群级别的可持久化的存储系统，以保证数据多副本和一致。此外，大规模应用监控必不可缺，需要针对容器集群进行自动监管，Google通过监控工具Borgmon（启发了Prometheus的实现）对容器云集群无间断监控以及基于时间序列的告警。这些工具使SRE不再需要直接做一线的运维操作，但对这些系统框架的掌握成为了架构“云”化时代下对SRE从业者的基本要求。

可以说SRE一方面在适应云环境对工作内容带来的变化，另一方面推动了容器集群管理和微服务架构的发展，进一步提高了服务云端化后的可靠性。集群监控跟踪能力的提升也使SRE可以对服务运行中的各环节进行自动化的数据收集和追踪，高价值的数据资产为SRE团队深入了解应用上线后的性能问题和用户行为带来便利，从而形成正向的反馈回环。

—星环科技TDC：DevOps理念实践 —

现代的开发模式不仅要有理论上的支撑，基础的工具也是流程运作必不可少的要素。一些公司开始为企业构建平台级的应用管理系统，星环科技大数据云平台TDC便是其中之一。TDC一直致力于为企业提供全面的数字化建设支持，除了应用部署能力，还提供支持服务线上应用开发的DevOps工作台，为企业的开发、上架、部署、运维提供一站式解决方案。

TDC-DevOps工作台工作流程

TDC—DevOps工作台整合了包括GitLab代码管理、镜像构建、镜像管理、部署等一系列开发管理工具，贯穿应用开发、构建、测试全过程。下面以星环科技内部采用的开发过程为例，介绍应用是如何从代码开发到部署上TDC的。

首先，代码通过开发平台集成的GitLab进行管理，代码提交后，分别经过以下四个阶段，产生不同成熟度的镜像。

• Precommit：开发人员本地代码commit到Gitlab仓库后，在合并到主干分支之前，由GitLab pipeline自动化触发单元测试和静态代码检查，此阶段称为precommit，测试通过后则可被合并从而进入postcommit阶段。

• Postcommit：postcommit阶段会对合并后的代码进行构建，产生的Java代码包被推送到软件包管理库，而容器镜像和charts被推送到镜像管理库。随后TDC的包管理工具WALM将容器应用部署到开发测试环境中，并在Jenkins上覆盖基础测试。这个阶段的测试通过后，应用镜像将会被打上postcommit标签。

• Gold：通过postcommit的镜像将在Jenkins上继续进行更全面的集成测试，这个阶段完成后，镜像将会被打上gold标签。

• Release：版本发布前，测试人员从gold镜像中挑选出满足当前发布一个版本，进行发布验证，如果可以满足生产环境的需求，则被release版本推送到生产环境仓库中，由运维/SRE人员进行生产环境的部署、升级等操作。

• 
  

TDC开发质量管控流程图

TDC提供的能力在于，它使上述过程不需要在各个平台间跳转完成，只需要在统一的操作平台上一体化的实现。而应用开发完成后，运维/SRE人员仅需通过TDC提供的可视化上架和部署接口，便可以快速进行上架。然后通过资源参数配置，实现应用一键部署。

TDC应用上架图

此外，星环科技自主研发、整合了一系列运维工具，形成一套完整的治理中心来协助应用运维。TDC的运维管理工具能够对应用的时序指标如CPU、内存等进行收集、监控和告警；而且可以通过分布式服务的故障追踪，快速定位微服务故障点以便于及时处理；同时内置日志管理平台，以帮助进行日志分析。

TDC—Aquila平台运维管理组件

作为星环科技自主研发的数据平台，TDC DevOps平台集合了DevOps和SRE的管理特色，开发整合了一系列自动化组件，为企业的应用管理实践带来了看得见的便利：开发阶段中环环相扣的质量管控流程加速了开发；简易的上架和部署为运维人员节约了精力；自研的运维管理组件则提高了日常维护的效率。企业通过星环科技TDC DevOps工作台可以实现对DevOps和SRE理念的优秀实践。

— 软件开发/运维流程的未来趋势 —

在未来，自动化、敏捷和快速反馈依旧会是软件开发交付的趋势。随着跨云业务的发展，开发运维间的协同也会不断在云端进行；伴随着云联邦场景，跨云测试环境以及代码跨云端自动化部署和交付或将变为广泛实践。智能运维或将从实验走向落地，对云系统全链路进行问题跟踪监控、归纳和预测，保证各类云业务在生产中更稳定的迭代及运行。此外，安全问题也会逐渐成为关注焦点，目前安全团队和开发团队开发相对独立，安全测试引入流水线已是所需。