【IT168 技术】DevOps是Development和Operations的缩写，DevSecOps是Development、Security和Operations的缩写。John Willis(DevOps Cookbook合著者之一)称Patrick Debois是DevOps的缔造者，并且DevOps和SDN一样，被很多企业或分享人士无节操的宣称是已经尝试好多年的活动。

　　回顾IT项目，最起初是需求的理解和分解，这个问题的“银弹”基本被《人月神话》来宣扬，通过人月计算人力和工作量的匹配来进行管理;后续需求的实现的开发与测试，通过敏捷开发来弥补了鸿沟，从而通过快速不断迭代和持续集成保证需求的快速完成，提倡了测试从需求阶段就介入项目并启动项目测试活动;而现在发现，项目的需求理解和实现有了可衡量的模型，交付能力却出现了大量问题，尤其是随着敏捷开发的出现，版本发布速度激增，给运营人员上线或升级带来了不小的“心理阴影面积”，从而运营人员(这里的运营人员包括运营人员，但不等价于运维人员)今早参与项目的呼声越来越高;简单来说就是IT项目遇着技术的发展和实践经验的积累，现在到了解决项目交付的问题了，DevOps随之被提出，做安全的DevSecOps也跟着凑热闹，想通过这一理念从整个项目流程尽早开展安全方面的工作，并希望将安全的理念推广到每个项目的参与者，并在项目中实现安全策略快速到达决策者的目标。

　　为何现在会提出DevOps整个概念?个人理解主要有三个原因：，

　　第一，如上文所述，主要是IT项目技术的发展和经验积累导致运营人员在项目中的问题日益突出，而解决方案在需求分解、开发人员在实现、测试人员对项目充分测试等活动都已经通过前面的实践阶段得到模型化方案，即人月神话和敏捷开发;按照科学发展规律而言，也到了要解决运营同学问题的阶段;

　　第二，现在业务的规模随着积累也确实急剧膨胀，对于限制的运营人员对于项目上线或升级等确实都是很大的考验;举例来讲，Google很早就出现单数据中心10万+的服务器规模，面对如此庞大而复杂的线上环境业务，运营工作不做些创新，还是很难胜任的。在国内来讲，BAT等互联网公司，运营人员也是要求的能力非常高，既要能扛得动4U服务器，单手波动2U的TOR设备，还要能写各种shell/Python/JavaScript脚本，甚至用C/C++或Java开发应用程序;从技术上来讲，虚拟化和云计算都是属于运营人员的不断推动而诞生的，简单举例来说就是OpenStack社区，无论从选择编程语言Python还是北向接口的操作理念，都明显是面向运营人员的，而不是开发者或测试者，当然开源社区的实现方式不Care产品化也应承了运营的特点。

　　第三，以前业务除了规模较小外，也比较单一，并且业务之间关联性比较少，但是现在多种多样且有千丝万缕联系，所以靠以前部门单纯的项目流程无法满足业务开发者和运营者的约定，而造成开发者/测试者和运营者的鸿沟。

　　说到这里，就要明确一个事实，DevOps是说让运营人员今早参与项目的开发/测试，而不是说要开发/测试人员直接在生产环境进行相应活动;这个是任何一家企业都做不到的，无论是BAT或GAF(Google、AWS、Facebook)等互联网公司，还是以前的以交付产品或方案为主的通信设备公司，都是无法做到的。

　　说了这么多，如何应用DevOps或DevSecOps的理念哪? 建议如下：

　　第一，如DevOps的传道者所说，让运营和安全的理念让每一个解决方案、开发测试的多个跨部门写作人员都融入，并正确理解DevOps的做法与含义，其仅仅是一个项目组织方式，不存在DevOps者，这是一个群体做法，更不是说开发环境和生产环境合一，业界所谓的“全栈工程师”，也多是掌握了多种页面制作工具的开发者;

　　第二，尽快让项目人员学习并掌握DevOps的相关工具，比如测试自动化的开发工具(互联网公司的测试基本都是程序员，极少是手工测试的，甚至自动化测试脚本要在研发完成前评审通过)，并熟悉云平台的上线或升级步骤及痛点;

　　第三，管理层面整体拉通，而不是团队或个人的割裂行为，比如通过特性的微服务化，弱化部件间强耦合，每个特性的开发和升级都要达标灰度升级的要求;

　　第四，建立一套不断成熟完善的运营机制，并且运营的问题，要用运营的思维来解决;比如监控运营等，有些时候再租户不知情的情况下进行，是非常苦难的，那就尝试下将其做成租户的一种收费服务，在租户获取收益的同时也完成云平台所需要的数据。

　　总之，和SDN一样，每一个新概念都有其具体含义和做法，包括DevOps等;技术发展太快，需要我们不断学习，并走出自己的狭隘空间去看看，或许我们能进步更快。