网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

但是也有一个很重要的问题需要考虑，静态代码分析工具通常需要花费很长时间才能运行完，以数小时或天记。在这种情况下，信息安全就必须注明特定的有安全隐患的模块，比如加密，认证模块。只要这些模块变化，一轮全面的信息安全测试就运行，否则部署就可以继续，而不需要全覆盖信息安全测试。

需要特别提到的一点是，我们观察到，相较于标准的功能单元测试，DevOps工作流依赖于检测和恢复更多一点。换句话说，当然开发以软件套件的方式交付的时候，那么部署变更和补丁就比较困难，同时QA也严重依赖代码测试来验证功能的正确性。另一方面，当软件以服务的形式交付，缺陷就可以被很快修复。而且QA也可以减少测试依赖，取而代之的更多依赖缺陷的生产监控，只要缺陷能被快速的修复。

代码故障恢复可借助于“功能标签”等手段，通过以配置的形式来启用或禁用某些代码功能，从而达到避免推出一个全功能部署，而只部署通过测试的功能至生产。

当功能不可用或性能出现下降等较坏的情况发生的时候，依赖于检测和恢复进行QA将会一种更好的选择。但是当面对损失保密性或数据和系统一致性的时候，我们就不可以依赖检测和恢复这种方法。取而代之的是，在部署之前，必须进行充分的测试，否则可能导致重大的安全事故。

通常，在软件开发项目中，开发都会用完所有计划中的时间用于开发功能。这样会导致无法充分解决IT运维的问题，于是他们就在定义，创建和测试数据库、操作系统、网络、虚拟化等代码依赖的方面直接抄捷径，以此节省时间。

所以这就是开发和IT运维以及次优结果之间的永恒的紧张关系的主要原因。后果很严重，比如不适当的定义和指定环境、无法重部署、代码和环境的不兼容等等。

在这种模式下，我们会再开发过程的早期提出环境要求，并强制代码和环境必须被一起测试的策略，一旦使用敏捷开发方法，我们可以做到非常简洁和优雅。

按敏捷的要求，在每个迭代结束后，我们就会发布能运行且可被部署的代码，通常时间为两周。我们将修改敏捷迭代周期策略，不仅仅只交付能运行且可被部署的代码，同时在每个迭代周期的早期，还必须准备好环境用于部署这些代码。

由此，我们不再让IT运维负责创建生产环境的规格要求，取而代之的，建立一个自动化的环境创建流程，这种机制不仅仅只创建生产环境，同时也包括开发和QA环境。

通过使得环境早期即可用，甚至可能早于软件项目开始之前，开发和QA可以在统一和稳定的环境中运行和测试他们的代码，从而控制不同环境之间的差异。

此外，通过保持不同阶段（例如，开发、QA、集成测试、生产）尽可能小的差异，在生产部署之前，我们就能发现并修复代码和环境之间的互操作性问题。

理想情况下，我们建立的部署机制是完全自动化的。可以使用像Shell脚本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等很多工具来完成。

BrowserMob前CEO，Patrick Lightbody曾经说过，“当我们在凌晨2点叫醒开发工程师来解决问题时，缺陷被修复的比以前更快了，这真是一个惊人的反馈回路”，

这是我最喜欢的引用之一。

它强调了问题的关键点，开发一般会在周五的5点提交代码，然后高高兴兴的回家，而IT运维则要花费一整个周末来收拾残局。更糟的是，缺陷和已知错误在生产上不断递归，迫使IT运维不停的救火，而根本原因从不被修复，造成这种现象的原因就是开发总是关注开发新功能。

第二种模式的一个重要要素就是缩短和放大反馈回路，使得开发更贴近客户体验(包括IT运维和最终用户)

注意这里的对称性，模式一讨论的尽早让环境统一并可用即是将IT运维嵌入到开中发，而模式二则为将开发嵌入到IT运维中。