开发运维(DevOps)在19%的IT公司中已经在用，另外19%处于试验阶段，还有35%打算在2017年实现开发运维。以上数据源于上周刚举行了数据中心、基础设施和运维大会的某大型分析公司的调查结果。明年，将是开发运维跨越鸿沟的一年。
![devops-security]()
随着开发运维逐渐成为主流，将安全融入其守则是不可避免的。无论“开发安全运维”这词儿是否流行，安全必须提升位序以更早进入软件供应链的时代已经到来。
什么是开发运维?
在将安全囊括进开发运维之前，先定义好开发运维或许会有所帮助。难点之一，是每个开发运维项目都是独特的。畅销开发运维书《凤凰计划》作者之一乔治·斯巴福德曾说过：“让5个人来定义开发运维，你会得到7种不同答案。”
Gartner对开发运维有个定义，使用了内部术语，对不熟悉敏捷开发方法的人而言不太能理解。定义开发运维存在阻力，因为固定的行业标准可能会有违以***公司业务需求的方式实现的目标。
因此，没有标准定义，反而有助于理解这段公案。敏捷开发是在需要更快创新的压力下出现的。然而，开发发布速度，受限于基础设施和运维。因而，开发与运维合作更紧密的压力就是开发运维的推动力。
作为草根运动，尽管在定义上一直存在争议，开发运维支持以下几大原则倒是越来越获得共识了：
- 开发运维的存在有助于帮助公司取得成功
- 涵盖很广，但焦点在IT
- 基础是敏捷和精益
- (协作)文化很重要
- 反馈是创新之源
- 自动化能帮忙
***，开发运维是关于使用协作、敏捷方法解决业务问题或运用信息技术抓住商机的。
开发运维与安全如何交织?
如果公司正运用开发运维，下列6条原则可供用以使安全支持开发运维工作：
1. 开发运维的存在有助于帮助公司取得成功
安全一直享有“说否部门”的美誉，尽管靠策略缓解风险依然是信息安全的一个重要组成部分，业务需求也必须在这些策略中占据同等重要地位，而不是仅仅从安全实践方面考虑。二者不应是相互敌对的，业务部门必须了解风险，承认风险，同时，在共同协作中，安全部门必须着重考虑如何帮助公司取得竞争优势。
2. 涵盖很广，但焦点落在IT
公司想要在被数字化改变了的世界取胜(想想Uber对出租车行业做了什么)，IT就处在这一转变的中心位置。但它并不是一个人孤零零坐在圆心。与公司其他部门，比如人力资源、财务、运营甚至外部供应商的配合是必需的。信息安全应在风险耐受和公司监管要求之内，持续寻求尽可能无摩擦的相互交流。
3. 基础是敏捷和精益
理解从丰田制造运营中借用来的敏捷宣言和精益原则，将大大有益于安全人士融进开发运维。安全必须配合各项工作达成持续集成/交付/部署，并提供积极清除软件供应链中各种限制(比如许可等待时间)的方法。
4. 文化很重要
开发运维与之前做法的***不同，就是对协作的强调。这是一种分享共同目标以有所成的文化思维，也是代表业务而非技术产出的标尺。安全应该融入减少风险的协同努力，而不是表现得像是疏离在外的批评者。
5. 反馈是创新之源
实验和学习对开发运维很重要，而这些需要足够的反馈，尤其是来自业务部门的。该反馈需要暴露给每个人，以便能够做出改善和更大的创新，但这也要求类似“无可非议的解剖”之类的东西来改进系统。安全文化在开发运维中必须避免沦为指责文化。
6. 自动化能帮忙
自动化带来了更快更便利更高质量的交付。工具是开发运维的力量倍增器，但不是其基础。自动化不能强化协作，但确实能让协作更方便。用作测试、认证或监视的安全工具应包含在开发运维工具链中，它们的输出应被广泛共享以形成提升。
2017是信息安全团队与开发运维携手共建，成为业务和其他IT部门更好的合作伙伴的一年。公司企业依赖这种能力来进行更快的创新和保持更低的风险，借此抓住机会，扛住数字化压力。
