NetOps 需要敏捷，因为云可能会在一夜之间发生变化

NetOps 需要采用 DevOps 方法和原则来恢复稳定性和速度的平衡，以支持在公共云中部署的越来越多的应用。

从网络角度来看，人们认为，采用 DevOps 的团队已经用稳定性和安全性换取了速度。

在很多情况下，这确实是事实。 还记得Arxan 和 IBM在物联网和移动应用安全性方面的精彩见解吗？ 我们了解到，大多数受访者认为“急于发布”是发布包含易受攻击代码的应用的主要原因。 速度胜过安全性和稳定性。

在稳定性方面，可量化的数据较少，但轶事证据却大量存在。 最值得注意的是，当“云”一夜之间发生变化时，云合作伙伴的疯狂反应。

沒有人告訴我。 有人只是注意到有东西坏了。 经过调查，其原因无非是底层基础设施的变化。 毫无疑问，这一变化对提供商甚至客户都是有利的，但却导致了大量依赖于该基础设施的解决方案的破坏。

您无法控制公共云。

也许我需要以零规则作为“云规则”来开始，因为它对您的理智以及采用云的方式至关重要。

云基础设施不属于你。 你无法控制它，也无法改变它，但提供商肯定可以（而且确实会这样做）。 如果您以与企业数据中心基础设施相同的思维方式来对待云计算，那么您将会陷入困境。

您所能做的就是对这些变化做出反应。 可以帮助您及时做出反应的 DevOps 方法之一是基础设施即代码。 请记住，基础设施即代码是一个比喻，它的意思是将部署、配置和管理基础设施的配置、模板和脚本视为代码。

关键在于采用声明式部署模型，这意味着尽可能使用模板来描述您希望基础设施做什么，而不是它应该如何做。

面对云基础设施中意外（但不出所料）的变化，使用声明性模型能够实现更高的灵活性（反应速度）。 是的，它们会破裂。 但您将能够更快地适应，因为您只需要解决中央（共享）模板中的更改即可。

您不需要修改代码本身，也不需要彻底更改现有配置（就像修补一样，只是更可怕）。 与修改代码、安装程序或 PDF 中的传统“安装指南”相比，您可以更快地修改、测试和重新部署模板。

云将会改变——你必须做出反应。 您需要保持敏捷 – 并遵循其原则来快速应对您无法控制的变化。

敏捷方法加上公共云基础设施的声明式模型是在不牺牲速度的情况下恢复应用稳定性的最佳方式。