一款软件产品的发布离不开两类人的支持，即开发和运维。人们常常会把他们提到一起，如今DevOps开发模式的盛行也正是对他们的重新定义。目前软件环境的变化可以说是开发者的黄金时代，而对于运维来说，这些变化正给他们带来新的挑战和期望。

过去的十年给软件开发环境带来了翻天覆地的变化，其中最大的变化是通过开源和云来生产基础设施。就产品的灵活性和生产力而言，这绝对是对开发者利好的消息，但也给Ops（运维）带来了一些新的挑战和期望。

Dev的黄金时代

在过去，开发者的工具箱里仅有几个大型软件供应商提供的单片式解决方案，比如Oracle、IBM、HP等。这些解决方案一般都比较昂贵，并且还会伴随整合和更新较慢等特点。一旦公司购买了它们，无论它们是否适合你，你都必须好好地利用它们。

如今，丰富的开源和云解决方案的出现彻底把开发者从传统的工具依赖中解放出来，开发者可以在过去同等的条件下享受更好的基础设施。开发者也可以根据自己的工作需求选择合适的工具，并且它们是免费廉价的，这些工具能够更好更快的进行整合，根据需求进行规模化扩展。现在，一个公司使用多种数据库（Redis用于缓存、Elasticsearch用来搜索、MySQL等等）已经变的非常普遍，这些工具分工明确，兼容多个平台。与此类似的各种分工工具还有：监控工具、计算环境、应用框架等。开发者可以因时制宜地选择各种工具，提高产品的开发灵活性、生产力、性能等。

持续部署给开发者带来了更多地福利，他们不再按月或者周期性地进行绑定发布，发布周期大大加快。这些都使得开发人员能够事半功倍地完成产品，产品的更新已不再是业务人员与开发者之间的一个瓶颈。

Ops的恶梦

与此同时，工具的丰富与分工也创造了“Ops恶梦”，比如DevOps、SREs、IT管理等一系列新的挑战和期望。

变更的速度：产品的监控和响应需求在数量上有了显著的提高。为什么？因为大量的产品问题都是来自内部的代码部署和架构变更。当进行持续部署（更不用提虚拟化和基础设施即代码了），变更的速度会大幅提升，速度地提升也很容易导致产品出错。由此可以得出一个论点，即持续部署可以减少潜在的、灾难性的错误，因为变化的周期变短、增量变少。

移动部分：现代基础设施之间的最佳组合给运维人员带来了不少灾难。可移动的部分越来越多、依赖关系更加复杂以及更多的监控工具会时不时地发出各种警报。在这样的环境中，故障排除已经成为一个永无止境地分类过程：过滤报警内容、优先考虑和应对潜在的事故，可以简称为报警疲劳。这已经是一个很常见的现象了，运维人员抱怨到：他们有50%—70%的时间都消耗在了响应报警上，以至于影响到了他们的核心工作：构建业务支持的基础设施架构。

运维人员的底线则是迫切需要一些工具来解决和处理这些警报疲劳。一个很好的出发点就是企业能够把噪音警报组织到一个更高层次的事件中，可以快速获得他们想要的流程，并能够有效地与利益相关者之间进行协作。

DevOps

DevOps的滚滚而来正是为了解决文中所提及的开发与运维瓶颈，更加强调开发与运维之间的密不可分。在DevOps环境下，开发人员和运维人员会构建一些关系、流程和工具，从而更好的与用户互动。只有当人们愿意相互交谈，关心相互的工作时，才能更好更快地创造商业价值。