文章转载自：火线Zone社区
作者：汪照辉
说到DevOps解决的核心问题？他并不是简单的话把运维干掉。
为什么团队开发运维方式备受诟病？说到底还是一个效率问题，因为研发和运维之间的利益是不一致的，所以导致效率就很低下。其实DevOps目的最重要的理顺研发和运维之间的关系，能满足彼此之间的关系，调动大家积极性，从而提升效率。
在这种情况下，我们需要改变这种方式，需要考虑怎么去通过不管是组织架构，或者系统架构去做调整，然后去理顺这个关系。就是说怎么去重塑研发运维的架构，让彼此之间的利益能够互相满足，然后去提升效率。从我而言，分为几个视角。
一个是系统层次即应用层次的视角，我们从上层微服务架构的应用服务到微服务部署平台，到最后的资源，最终到底层的物理介质等等这些。在不同层次，运维的人员也都会不一样。
另外一个视角就是整个应用的周期过程，从需求到分析、设计、编码、测试，整个生命过程。这其中也涉及不同的角色。
还有很重要的一点是我们今天需要讨论的是管控安全，涉及不同的角度都需要把运维和开发的关系理顺，研发运维整个体系的效率才能提升上去。
从传统的组织架构而言，就是首先做个分层。我们现在的DevOps提倡这个研发运维一体化。那研发的话，可以把应用的研发运维这个职责承担起来，底层这基础设施资源这些可以由传统的运维去做，因为他们也是擅长这块的。所以可以由他们继续来做这方面的工作，就相当于说有我们原来的分段再去做分层的一个处理。
这样的话，原来的运维人员也不会说没有事情可干。
我们在谈DevOps的时候，从接触这些厂商来说的话，更多关注的是开发，关注运维相对会少。从Google S1视角来说的话，他们更关注运维，通常观点是不一样的，这个是值得我们去思考。
关注运维无疑是正确的，就是从实现开发运维一体化这个角度来说的话，以系统工程的思想来解决工程软件的问题时从整体上去思考，会比你单单去考虑研发要好很多。因为即便把研发的效率提升了，运维效率提升不上去，整体上效率还是有瓶颈的，还是解决不了实际的问题。
要重塑研发运维这个架构，首先要解决的就是人的关系。我们前几天在群内群嘲【详情可查看今天第三条文章】的时候说要把运维砍掉这个是有点儿太武断。你不能一刀把运维砍掉，而是要考虑这个人尽其才。
像国企的话是需要考虑社会责任的，不能无底线什么都做。在传统运维的基础上，去把这整个一个体系做重构之后，可以从原来的单体架构逐步过渡到融合架构。
从微服务容器包括DevOps这个思想来说的话，微服务主用微服务架构，然后逐渐构建可常用的服务，容器就可以很好的去匹配微服务架构来实现弹性伸缩等能力。从这个思考来说，我们就可以把公司内一些可共享的服务逐渐提取出来，成为中台云服务。然后把这些基础设施运维的活交给基础的运维人员去管理。
然后就是分层次了。
前台的话就是我们把这些业务应用作为前台的业务应用。其实从最简单的一个层次划分，就是前中后三台。我们手中的中台可能和阿里说的中台是不一样的，从应用架构角度来说，阿里中台更多的是从企业架构来说的，所以说是有一些差别的。
说到我们实际期望的DevOps平台是什么样的，我们作为一个用户都有一些自己的思考，所以我将从我的角度简单地做一个介绍。
我们要实现这个DevOps平台，首先就是需要你在部署的时候去做初始化。现在我们接触的这些厂商来说，这些什么角色都是让客户自己去定义，但其实作为一个平台的提供者，首先要知道你的平台能支持哪些能力、哪些角色，你要有初始的能力模板。
实现DevOps平台很重要一点，就是业务的一个处理能力。现在基本上是没有这方面的一个能力。但是这块无疑是非常关键的，对于我们来说非常关键的是业务部门如何收集需求并进行分析分解。再把这些公共的需求部分提取出来，这是很重要的。
为什么要实现中台，很重要的目的就是要实现复用，这是中台是非常有价值的一部分。如果你不做复用的话中台就没有意义。所以说最终要把这些业务中能够共享共用的东西提取出来，做一些中台服务。
但这些是在DevOps平台里面基本上是做不到的，所以我觉得这部分是比较重要的部分，从业务到项目规划，对于企业和终端用户来说，也是要求相对来说较高一些，因为它需要一个全局的规划能力，但现在的话，很多企业是其实是做不到的。因为现在基本都是项目制，来一个需求起一个项目，所以最终复用的能力是很低的。
从整个研发的角度，包括资源管理，很多人关注的是CI/CD，但从我个人角度来说，现在CI/CD并不是很重要的，因为CI/CD的实践相对来说是比较容易的。
一个项目和最终去部署交付的应用，其实包括交互的制品其实是不对等的，一个项目可能最终交付的是多个制品，也可能说多个项目交付一个制品。这个就是在根据我们整个规划去做的处理。如果用容器的话最终可能交付镜像，最终的是基于我们实际的应用需求来确定。在这块儿，我觉得很重要一点是度量的问题。目前很多平台都有相应的能力，但是在度量指标这块儿还是缺少深度的思考。
再说到整个API管理，可以作为DevOps的一部分，它更多在运维阶段是作为运维的一部分。但这部分也是很重要的。最终我们都在提倡生态，最终你要建设生态也是很重要的一部分内容。
再者对于安全这块儿，其实不只是DevOps安全，它会涉及各个层面。最重要的话就是在对的层次选择对的安全方式、反馈策略这是很重要的。
所以，我们需要从一个整体来考虑问题。就是说中台和多云管理，也是需要从根据企业实际情况来看，如果你仅仅把这些应用全部部署到公有云平台，根本不需要基础设施的运维，还是说我直接用SaaS服务根本用不着开发人员，所以不同的场景的话，需要的人员和投入是不一样的。
你不可能说把数据放在公有云上。也不可能说去直接用这个SaaS服务。所以说我们还是需要去选择不同的云平台。普通的资源需要一个统一的平台来管理。管理的话就是为了提供统一的资源服务。其实云的思想基本都是一致的。为什么说需要中台，其实就是要做服务，要做共享。
如果一个企业把日志、配置的认证的权限等这些组件全部做成中台服务化，那么一个企业就只需要一套日志服务，一套权限服务，也不需要每个开发一遍。这个可以节省多少工作量和成本。这样在企业内部就能提升效率，这也是我们所追求的目标，不管你用的DevOps或者用其他的，最终要提升的就是效率问题。
下面，简单分享一个案例。
这是某一家厂商所提供的一个方案。它有两个方向，四个方面。就是设计时，实现安全保护。运营时，实现持续监测响。四个方面包括的是，开发、测试、安全管控与运营，基本上只要包括这四个方面，就能基本上满足我们的需求。
实际上运行时都需要去考虑很多因素，在部署之前需要考虑镜像漏洞这些，尽量把所有关键因素消灭在运行之前，运行之后同时也需要考虑，因为毕竟还涉及网络、主机、容器、病毒等等，所以说在运营时需要并重。
安全左移也就是我们做的DevOps安全，有一个比较关注的模块就是无论如何，安全是很重要的一个前提，在这部分涉及很多安全的内容，比如说代码安全、配置文件安全，建设安全及微服务安全等等都需要做相应的一些检查，就是尽量把这些不安全的因素阻断在部署之前，这是我们需要实现的一个内容。
最后就是运营时需要我们做到看得清、管得了、防得住。同时，能够和我们整个体系无缝融合，这是要求我们要实现的能力。