运维架构是全站技术架构中不可分割的一部分

从这篇文章开始，准备从架构设计层面谈谈Dev和Ops的关系，而不是单纯从组织架构和协作模式上的Dev和Ops关系。

一、为什么要起这个话题？

上篇文章《如何打造一个以应用为核心的运维体系》中，隐含着一个很重要的观点，可运维性要在架构设计时就要统筹考虑，从一开始就得考虑进去，而不是到了运维这个环节再去考虑，否则就会出现很多的问题。但实际情况，很多技术团队在这一点上做的并不够，而是将全部的精力放到如何进行服务化或微服务的拆分上，放到分布式架构如分布式服务、分布式消息、分布式DB和缓存等等这些设计上，更多的是做了一些纵向的架构分解和技术钻研工作，但是架构的横向延伸和拉通考虑的明显不足。这样恰恰是忽略了整个软件生命周期中最长尾的运维环节，也反映出了很多公司对于运维这件事情的重视程度和理解深度不够。

二、出现的问题

从我个人经历的过程以及观察的情况看，通常的几个现象：

1、应用这个概念，在资源申请、域名申请、VIP申请、服务注册、发布部署、策略下发、监控等等这些环节不统一，各自独立一套；这个就是最典型的架构设计时，只考虑开发一个环节，没有将架构上拆分后的概念延伸贯穿到整个软件生命周期的问题。这个也将导致下面一系列的问题产生；

2、上面做不到，没有统一的标准和概念，各个平台之间就很难集成和打通，所谓的持续集成、持续发布、持续部署、持续交付等等这些环节仍然靠大量的人肉动作去做，还谈不上持续，效率自然上不去；

3、稳定性保障无从下手，大量的服务化应用，错综复杂的调用依赖，海量链路日志，问题排查困难，一个请求下来，到底跑到哪个应用去了都不知道；故障持续时间长，出现流量激增或基础部件故障，无法快速隔离、降级和恢复；

4、效率跟不上，还经常出问题，进而，团队协作效率降低，相互信任下降，就开始经常听到下面的言论：

开发抱怨：“运维做的不到位，申请个机器老半天，发布效率也提不上去，代码都写好了，上线咋这么费劲，严重降低了我们的工作效率，再有，出了问题还得我们上去定位，运维什么都帮不上。。。。。。。”；

运维抱怨：“开发的架构这么烂，配置五花八门，还得手工维护，我咋知道这些配置干嘛的，配错一个，就出故障，让我怎么自动化发布；日志放哪儿也不知道，一会这里，一会那里，出问题你说我咋定位。。。。。。；”

5、好了，出了问题，就开始撕逼扯皮，相互推诿，背了责任的一方又开始甩出背锅言论，感觉没有被公平对待。团队的氛围也开始出现bad smell。

三、问题出在哪儿了呢？

其实从开发的角度和运维的角度单独来看，双方的表达都没有问题，做的事情也都没有问题。但是双方都是只站在了自己的角度表达问题和情绪，恰恰都忽略了很重要的一点：运维和开发不是相互割裂的两个组织，运维的技术体系和全站整体的技术体系更是不可分割的，越是把它们割裂开看，越是站在各自的角度看问题，上面说的这些情况就越是无解，整个团队也会限于这种没完没了的、毫无意义的纠缠中，从长期看对团队和个人的发展都是很不利的。

所以根本原因，在于将开发和运维在技术和管理两个层面给割裂开了，详细描述如下：

1、运维阶段要面临的问题没想清楚，从一开始架构设计上就没有考虑清后续的运维阶段要面临的问题和事情，比如这么多应用，资源应该如何分配、发布的效率如何保障等等，而都是在考虑开发自身的需求和问题。不考虑运维面临的问题，这样实际就是把运维割裂在整个架构设计之外了。（这个责任在谁呢？）

2、运维团队的职责定位不清晰，整个技术架构朝着服务化的方向演进后，整个组织架构对于运维团队的定义也是模糊的，也就是运维到底要做什么，要承担什么样的职责，因为一个合理的架构落地，必然要有合理的组织架构去对应支撑才可以。运维定位不清晰，就相当于将运维团队给割裂在研发团队之外了。

四、未完待续：）

所以打算下篇就讲讲这个问题应该如何破局，在这样一个技术架构体系下，运维的角色应该要做什么样的转变，才能适应和支撑起对应的技术体系。（如果还是传统的硬件维护、网络维护、脚本编写这样的定位和要求，显然是跟不上技术发展的要求和节奏的。）

如果你已经有好的思路和建议了，欢迎先留言讨论。