【编者按】随着 DevOps 被欲来越多机构采用，一些共性的问题也暴露出来。近日，Joe Yankel 在「Devops Q&A: Frequently Asked Questions」一文中总结了近段时间参与各种活动中经常遇见的几个问题。本文系 OneAPM 工程师编译整理：

从 11 月至今，在维护 DevOps 博客、参加网络研讨会与各种会议的过程中，笔者遇见了很多有关 DevOps 的各方面问题，包括变更管理、安全性与具体方法。本文将就几个频繁被问及的问题进行回答。

1. 变更与发布管理与 DevOps 如何集成？

首先，变更一直是 DevOps 文化之一。Gene Kim在 “The Three Ways”中描述了支撑 DevOps 的 3 个原则，他表示，DevOps 的一个核心原则（第 2 条）就是增强 feedback loop（反馈环）。通过持续反复的反馈回路，开发者能够快速响应客户需求。feedback loop 是变更管理发挥作用的环节。一般来讲，在情况脱离预期时就会对变更管理，或者由客户（内部或者外部客户）决定变更应当进行，以增强商业价值。事实上，这种类型的变更是良性的，开发者应当促成这种变更。

在没有 DevOps 并缺少持续集成（CI）与持续交付（CD）激励的情况下，正式发布之前，没人会对变更提出要求。但随着 CI 与 CD 到位，release 会更快速更频繁。从而，客户有机会提前发现是否需要变更。快速提交能让他们更迅速地评估产品与自身需求，从而反过来促成需求的变更。事实上，没什么比能亲眼看到、亲手使用更加清晰产品需要变更的方向。

2. 在这样一个迭代环境/流程中，如何确保一直兼顾安全性需求？在 DevOps 环节中是否需要专门的安全人员？

安全性在整个 DevOps 环节中的优先级一直是最高的。下图是用来描述 DevOps 典型的文氏图（Venn diagram）：

实际上，人们经常忽视安全性，甚至没有画出这一环节。在描述安全的 DevOps 时，SEI's CERT Division中推荐使用的图表如下：

必须时刻考虑到安全性问题，同时整个 DevOps 环节都应当有安全专家的参与。不能指望开发或支持团队在项目中作出安全决策。如果对公司来说，安全性举足轻重（并且近期一直如此），那么专门的安全/隐私专家就非常必要。专业的开发或运营人员应当精通以下方面：

• 数据隐私性
• 入侵侦测
• 入侵载体
• 通用漏洞列表（CVEs）
• 安全性封装
• 身份验证
• 授权
• 安全标准合规性

微软 SDL（安全开发周期）列出了在一个项目周期中引入安全性的方式。在整个项目周期中，至少应当有一名专业的安全人员与 DevOps 团队紧密合作，他会考虑其他人不会考虑到的安全性相关问题，结果显然喜闻乐见。

3. DevOps 是否只能用于敏捷开发中，还是适用于任何种类的开发周期？

DevOps 的确是敏捷开发的延伸，但它更多是一种文化或理念（请参看第一个问题中提到的「The Three Ways」）。无需采用敏捷开发便可使用 DevOps，因为很明显使用 DevOps 会比普通的SDLC（软件开发生命周期）更为高效，但单独使用 DevOps 可能困难度更高一些。敏捷开发当然比其他的 SDLC（例如瀑布开发）对 DevOps 帮助更大。不使用敏捷开发仍能达成目的，但使用后效果更佳。

原文链接：Devops Q&A: Frequently Asked Questions

OneAPM 是应用性能管理领域的新兴领军企业，能帮助运维人员进行故障预警和定位，减少业务系统维护的工作量，同时还能提供可追溯的性能数据，量化运维部门的业务价值。想告别加班熬夜，欢迎免费注册使用！