大家要注意一点，在云原生发展下，对于资源层的运维都会转向类似阿里云等公有云服务厂商来统一提供，企业更多的是做服务层和应用层运维监控。
在这种情况下可以看到后续企业研发团队实际上没有专门的运维人员，而是由技术人员来兼顾应用层运维工作。这本身就是一个大的发展趋势，传统运维或工程人员要有这个风险意识。否则传统运维人员自己就要转型到应用层，属性应用层和业务运维内容。
研发运维一体化，对于企业端来讲，不是还保留研发和运维两个岗位角色，而是完全专职化的偏资源运维岗位没有了，而是变成了研发人员的一个兼顾角色。
这个观点我也是第一次提出，请大家仔细思考。
IT管控核心是研发资产可视化
记得是有一个晚上，朋友突然找我让我出去聊下有急事，过去后才知道是由于内部管理或利益分配的诸多原因，在这里不方便细问，这个开发负责人逐步要离职走准备去单独干，而且可能还准备把几个核心开发都带走。由于我朋友本身也不是技术和IT出身，遇到这种事情本身还是一抹黑找不到对策，找到我的原因无碍乎是问我这边的技术人员或团队能不能先把他那边的系统和开发工作先承接过去下。
前期没有完整的研发流程，需求文档也不完善，而且在离职的时候提交的文档，代码是否完备这些即使是有经验的技术人员去验证本身也存在相当的难度，到了最后离职谈判阶段实际上我朋友本身已经处于相当被动的地位。
在这个时候来谈工作交接或找人接替本身也为时已晚。而实际上具体分析个人理解实际上这个问题很多非技术背景的领导都会遇到，造成的原因主要是。
1. 核心研发资产，包括需求设计文档，源代码往往掌控在关键的一个人手里面，或者干脆无文档
2. 研发过程不透明，研发资产没有显性化，他人很难短期接手
而要解决这个问题，个人理解至少需要从几个方面来考虑，第一就是我们常说的研发团队划分，岗位角色设置上面要考虑分离，关键岗位角色要考虑有备份和AB角，能够相互替代。第二就是我们说的研发过程流程改进，研发资产的可视化。
而对于第二点，实施DevOps平台本身就是一个很好的支撑，即研发资产可视，过程可视，你每天新产生的代码都要检入，并进行相关的代码检查和自动化测试，整个持续集成和自动化构建确保了进入到我们配置管理库的代码是编译通过的。其次，我们自动构建完成的部署包本身就是推送给测试人员进行测试的部署包，中间不需要开发人员去插手或增加小动作，那么测试人员测试通过的版本，一定就是当前代码已经实现的版本。
即在整个DevOps持续集成过程中，实现了研发资产的持续落地可视化，这个可视化不仅仅是整个研发版本的可视，更是中间各个阶段的可视化，即使你团队所有人员都离职，我们也应该能够确保当前研发资产库里面的代码能够自动化构建完成并形成当前的应用版本。代码当前是全的没有遗漏，而且代码完全和当前功能对应。
还有就是，在实施SOA项目的过程中，我们也经常和甲方沟通，当时有一个甲方就提到一个关键点，当要给完整的业务系统招标选择了要给供应商来定制开发后，在项目验收完成后虽然提交了相关的文档，相关的源代码，但是发现后续的运维甲方根本无法承接。包括乙方提供的源代码本身都无法编译通过，即使能够编译通过构建出来的版本功能也和当前生产环境功能有明显差异。甲方如果本身不是专业的IT类公司实际上很难在验收的时候发现这些问题，也就是说最终验收你得到的文档，代码等内容实际上完全无法支撑甲方运维。
而这个问题和前面一个问题很类似，就甲方来说如何加强对开发商的管控，如何确保开发商定制的系统版本和当前的研发文档，源代码资产等是时刻同步的。如何确保最终验收的研发交付文档，代码就是和当前生产环境运行的系统版本是一致的？
