运维的敏捷才能支撑研发的敏捷，敏捷运维≠不稳定运维！！

跟一个朋友聊 DevOps的问题，我提出 “以SRE的实践经验来看， 运维的敏捷才能支撑研发的敏捷 ” ，他直接告诉我说 “ 运维平台不能敏捷， 敏捷 = 不稳定，运维不能不稳定 ” ，也就是说，为了系统的稳定，运维是没法做敏捷的。 这直接把敏捷和稳定运行对立起来了。可能也是最近几年很多人鼓吹的敏态和稳态二元运维所导致的。但敏态运维和稳态运维真的就对立吗？只能二选一？那运维自动化算敏态还是稳态？AIOps 算敏态还是稳态？

稳态和敏态

什么是敏态？什么是稳态？敏态和稳态原是动态系统理论中的概念。稳态指系统在长时间运行后收敛到的稳定状态。敏态表示系统对外界扰动的响应能力。稳态用来描述系统在无外界干扰的情况下的平衡状态，长期均衡下的运行状态；敏态用于描述系统对内外部环境变化的敏感程度和适应能力。敏态系统具有较高的灵活性和适应性，能够面对变化时快速调整，并恢复到一个新的稳定状态。

稳态和敏态分析都是用来描述系统行为的概念，用来评估系统的稳定性和可靠性。不管稳态或者敏态，最终都要达到一种稳定的平衡状态。稳态更多是一种行为结果状态，而敏态是一种响应变化的能力，其最终需要回归稳态运行。用稳态和敏态的概念来讨论运维，有助于我们理解业务应用系统的动态状态变化和稳定性以及适应性。

稳态应用和敏态应用

在讨论业务应用系统运维之前，我们先从响应需求看下应用类型。有些业务需求变化比较快，比如我们常说的互联网类业务，需要经常策划一些营销、秒杀等活动以提升营收和影响力；这些业务应用系统通常我们称为敏态业务应用。而一些不需要经常变更的应用系统，比如说财务、人力等管理类应用，并不需要频繁的变更，可以称为稳态应用。不过也有很多人把传统开发模式开发的应用系统称为稳态应用，用敏捷研发模式开发的应用系统称为敏态应用，从而形成以双态研发模式来划分敏态和稳态业务。这种方式有点简单粗暴，并不能体现真正的业务真实的需求。管理类系统也可以采用敏捷的研发方式，但他们可能并不是敏态应用系统，并不需要非常敏捷的响应能力。通常这些系统的变更是基于政策或规则的变化才需要变更，比如说，财务计税政策和规则的变革，就需要变更财务应用。但这通常是有一定的缓冲期。因此稳态应用和敏态应用不能简单以研发模式来划分，而应该看需求响应是否需要敏捷来定义。

稳态业务运维和敏态业务运维

稳态业务并不需要频繁的变更，通常使稳态应用系统保持平衡状态稳定运行，做好灾备、备份等就可以了。但稳态也并不是不能做到敏捷变更，敏捷变更对稳态业务应用同样重要，这是系统应用对变化的适应能力，响应越快，就越快地重新达到平衡和稳定运行。而敏态业务，则是必须具有的敏捷响应能力。业务的类型并不一定和业务系统的维护方式保持一致，稳态业务和敏态业务都可以采用敏捷的研发方式和敏捷的运维方式。比如说，都可以采用微服务架构方式，从而实现更多的复用和共享。

不管是否是敏态应用，在系统出现意外故障时，敏捷的响应能力是否对系统的恢复具有帮助？这样的能力是否可以称为敏捷运维能力？是否同样可以构建敏捷运维平台？因此，敏捷不是只指研发。系统的稳定运行也不代表不能具备敏捷的响应能力、敏捷的运维能力。异常情况、意外情况，快速的恢复是至关重要的能力。即便稳态的业务，具备敏捷的变更能力，甚至用户无感、业务无影响的变更能力，而不只是敏捷研发迭代，都是企业运维和研发能力的重要体现。仅有敏捷研发远远不够。

敏捷不是只指研发

有人把研发分为敏捷研发和传统研发两种模式，从而也让很多人觉得运维也存在敏态和稳态运维，敏捷研发的系统就是敏态运维方式，传统方法研发的系统就沿用传统的运维模式。可能也是受众多厂商的所谓的DevOps思想的影响，关注持续集成和持续交付部署，却不怎么关注如何实现持续的稳定运行。其实，很多人谈敏捷的时候指的是研发的敏捷，自觉不自觉的排除了运维的敏捷，这是一种长期耳濡目染被影响形成的根深蒂固的思想，想改变有时的确不容易。但很多根深蒂固的思想往往是过时的，难以与时俱进的，因此需要改变。

SRE的思想虽然起源于互联网系统运维，其却适用于任何行业和系统敏捷变更和可靠性运维的场景。很多人鼓吹 ”DevOps已死 ” ，就在于对DevOps “研发运维一体化”的误解和误用。还有可能就是研发人员对运维天生的优越感和排斥感作祟。但试想，一个不懂运维的研发能做好研发吗？能研发出高可靠性、高稳定性、高韧性、高可观测性的软件吗？如果对部署、对网络、对操作系统、对存储等不了解的研发，如何能考虑高可用部署、性能优化、参数优化配置等等，很多研发的问题最终是需要依赖于底层的基础设施资源，不论再高级的开发语言，如果操作系统参数配置不合理，比如openfiles 设置很小，运行一段可能就会出现"Too many files open"异常；或者磁盘分区配置不合理，空间不足导致进程hang 或者驱逐重启等。研发运维一体化的目的就是让研发人员懂运维，运维人员也要懂研发，这样才能以运维的视角考虑研发应用软件的可靠性、性能等设计实现，而运维懂研发，则能开发自动化的运维工具，以研发的视角快速定位异常、找到根因并解决问题，提升软件应用的可靠性、可观测行、稳定性和韧性等。

变更频度

无论稳态还是敏态系统，系统变更是正常的需求，区别在于变更频度。支持频繁变更可以称为敏态，不支持频繁变更也不能称为稳态，稳态是一种系统运行状态，而不是用传统开发模式开发的系统称为稳态系统。不管什么模式开发的系统，如果频繁的崩溃、异常、错误、重启等，无论从什么角度看，系统都是不稳定的，不能称为稳态系统。当然，稳态业务相关的系统可以称为稳态业务系统，不过并不代表是稳定的稳态系统，所以稳态业务系统不等于稳态系统。

系统稳定并不是一成不变。而且即便是什么也不改动，系统也一直在动态运行过程中，在某个时点就可能破坏稳定，带来系统异常，比如磁盘空间满、网口损坏、openfiles 达到最大值等等，所以为了系统稳定，并不能害怕系统变更。系统变更就会带来扰动，就可能使系统处于不稳定状态，不管高频度变更或低频度变更，都是一样的，因此，需要具备快速的处理能力、自动化的处理能力，甚至智能化的处理能力。特别如果采用微服务架构，势必带来微服务数量的增长，对运维的敏捷响应能力就要求非常高。你说为了稳定，运维不能敏捷吗？敏捷和稳定并不矛盾，敏捷才可能更快地带来稳定，因此，运维的敏捷是确保系统稳定运行的重要措施和手段。也只有像SRE 一样，实现运维的敏捷，才能支撑研发的敏捷。

从SRE看运维的敏捷

Devops的“研发运维一体化”误导了很多人。SRE从运维的视角为我们提供了非常有价值的参考。SRE 强调稳定性、可靠性和韧性，怎么做到的？靠自动化的工具，消除重复性、手工性的操作。自动化是不是一种敏捷方法？自动化的方法不是常用的运维方式吗？因此，通过自动化的方法和工具实现应用系统的敏捷变更和稳定运行，二者并不矛盾，并且是相辅相成的。从而支撑频繁的变更，也保证系统的稳定运行。

具备对内外部变化的敏感响应能力和适应性，是系统运维需要具备的能力。SRE虽然没有提敏捷运维，但他们所做的事情是实现敏捷的运维，从而支持敏捷的研发。通过错误预算，让研发对自己的代码负责，为自己的代码逻辑错误买单，也变相的促进了研发质量的提升，确保应用系统的稳定性和韧性。通过自动化的工具，实现快速的备份、高可用部署、回滚、恢复等能力。这些能力都做到了敏捷，系统的稳定性也得到了保障。

换个视角看研发和运维

不是运维平台不能敏捷，而是敏捷运维才能支撑敏捷研发。运维不敏捷，不能快速响应并适应新的状态，就做不到支撑敏捷研发。无论研发多么敏捷，不能变更，或者变更总是出问题，为了避免担责，造一大堆的审批流程，做不到敏捷，也不是DevOps 的研发运维一体化。运维的敏捷需要自动化的工具以及平台的支撑，这也和当前很多人鼓吹的平台工程是一致的，这些平台工程一部分就是运维平台，比如说容器化PaaS 平台，用来部署和运行容器化应用。通过自动化测试、灰度发布、多版本并行运行、流量切换、高可用部署等手段实现用户无关、业务无影响的变更，从而实现业务应用系统的“稳定运行“。这里的”稳定“是一种动态的稳定，可能在运维端需要不断的自动化调整、变更、切换等，但对于客户、业务来说，可能是无感的，这都需要运维平台的敏捷处理。所以说，运维的敏捷才能支撑研发的敏捷，运维的敏捷比研发的敏捷更重要。

基于根深蒂固的思想认知，很多人看不上运维，总觉得那是修电脑的，很低端的工作。但互联网和数字化使运维的工作重要性提升到了超越研发的程度。如果不改变认识，就做不好运维工作，无法真正实现运维的价值，无法真正提升研发运维一体化的能力。也可能就是基础不牢，就无法支撑敏捷研发。研发也就只能是局部的最优，无法实现软件工程全链路的价值优化。