标签：learn 灵活 操作系统 依赖 团队 微服务架构 点击 https 部署
本文首先会和大家分享当前整个应用生命周期的演变历程，然后讲解云计算模式下 DevOps 建设包含的过程、流程规范和标准，最后讲解云原生时代到来会带来哪些改变，以及标准化的建设会有哪些改变和突破。
企业数字化转型过程和云的迭代发展是相互作用的。在 2007 年之前主要用物理机来作为我们当前应用的载体。而在 2007 年，KVM 诞生，它能让底层操作系统和一些虚拟的网络设备做一些虚拟化的输出。2007 年 - 2010 年是虚拟化发展较好的周期，VMware 和 openstack 是当时的代表生态。到了 2013 年 Docker 开服，云计算迎来了蓬勃发展的周期。2014 年，企业的部分业务开始逐步迁移云上。2017 年后到今天为止，在云原生的模式下，开发人员或者整个 it 部门更聚焦在业务的发展上，所有我们不关心的部分可以全部由云来管理。云开发不必关心开发在哪里，云服务不关心调用到哪里，而云资源方面也不用关心运行到了哪里。这就是从基础设施上云到业务上云，再到当前的全栈云，这样的一条全企业数字化转型之路。
在物理机阶段，使用的是单体架构，这样的架构系统封闭、无法复用，且高度耦合，内部交互复杂。而在第二阶段，采用了面向服务的 SOA 架构，这种架构通常需要 ESB 进行系统集成，进行应用模块解耦，需要统一部署。但是这种架构通常需要较大规模的团队，且可能存在职责割裂。第三阶段是当前使用的比较多的微服务架构，它能充分利用 DevOps，完全解耦能充分利用云化资源自动弹性伸缩等特性，支持高可用，能升级、扩容但不中断业务。
这张图片能较好的展示应用的生命周期管理，以应用为中心，在应用之上是基础资源管理层面，这个层面可以管理应用对应的资产、环境、资源、流水线、部署和监控，这是以基础资源为核心思想下 DevOps 的建设方向。随着越来越云化和微服务化，我们关注的视角从基础资源逐步转成服务思想。
在物理机时代，随着业务的发展，可能会出现基础设施增长，软件复杂度提升，流量冲击和更新频率变高这些问题。基础设施增长和软件复杂程度提升会给运维带来压力，流量冲击要求运维的测试要有多样的变化，更高的更新频率要求研发人员的快速反馈以及更灵活的需求变更。
在这样的情况下，DevOps 建设迫在眉睫，企业需要提升应用交付的效率和质量，需要越来越多样化的应用部署方式。DevOps 建设要首先要做的是敏捷的建设，因此需要更灵活的需求管理工具，在整个应用交付阶段需要自动化构建和环境快速管理。然后在测试的阶段，我们需要做自动化测试，才能在流程中管控好质量，另外还需要有一个统一的制品管理。从软件开发到应用交付之间，需要有一套统一的制品库将所有的制品进行统一纳管，基于统一的制品可以进行智能化的验收测试。在这整个阶段，核心准则是版本控制一切，内建质量、自动化，过程度量。
这个图片是端到端的 DevOps 能力图谱，建设的重点在图谱下方的持续交付工具链。我们需要采取统一的代码管理工具，帮助我们自动化的提升代码的质量。在安全方面，我们也会运用安全扫描工具集成到流程中，让它进行自动编译。另外，在持续部署阶段，要做好数据库的发布，对不同版本的接口做好管理，并结合一些好的自动化的工具做自动化测试。这些功能点需要一个交付部署流水线串连起来。
我们可以看到，在端到端的能力中会有很多步骤，也需要非常多的工具去执行，如何将这些工具进行很好的串连呢？在企业生产过程中，核心目标有三项：效率、质量和成本，因此可以沿用制造业的流水线来帮助我们快速的生产软件。流水线中我们需要关注 4 项指标：发布频率、变更时长、服务恢复时长和变更失败率。
云原生是一个复杂的东西，它包含开发过程、应用依赖、编排管理、流程管理、数据分析以及非常多的组件。在云计算的模式下，我们可以做到快速交付应用、成果快速发布，但是我们交付的产品是否能给业务带来增长，满足客户的需要呢？这就涉及到如何将应用交付转变为价值交付。通过可靠、可重复的流水线，快速进行软件生产，提升应用效率和软件交付效率，这就是应用交付。而价值交付是指能够快速地响应市场变化，在客户需求不确定的情况下，生产出客户满意的软件。
如何实现价值交付？要基于可靠可重复的流水线，简历自动化的应用交付体系。将敏捷过程全面融入到 DevOps 体系中。架构全面微服务转型，基础设施云化，让开发专注于业务开发。将运营纳入到 DevOps 范畴，实现数字化运营。
CODING DevOps 系列第三课：云计算、云原生模式下 DevOps 的建设
标签：learn 灵活 操作系统 依赖 团队 微服务架构 点击 https 部署
原文地址：https://www.cnblogs.com/codingdevops/p/13157886.html
