本来这篇是打算直接写运维角色到底发生了哪些变化,起到了哪些更有价值地作用的,但是觉得铺垫还不够,所以先写写架构标准的问题,下篇就差不多就可以直接写角色的转变了。
一、问题回顾
接上篇《运维架构是全站技术架构中不可分割的一部分》,文中提到一个问题,运维架构和技术架构的脱节这个问题到底出在哪了?到底谁应该承担这个责任?
一开始,我个人第一反应,承担这个责任的或许应该是架构师这样的角色吧,毕竟这不是个单纯的技术问题。
但是仔细考虑过后,我觉得这样也会有问题。因为从服务化之后,整个架构就已经是去中心化的了,我们可以看一下自己的周边,现在架构师的角色已经更多的往垂直领域发展了,如业务架构师(交易、支付、商品、营销、类目等),或者某个技术领域的专家,如分布式服务、消息、缓存和 DB,更大的方向上如大数据、搜索等等方面。我想这也是去中心化之后的必然结果,大家都是朝着某个更加聚焦、更加专业的方向发展。因为每个专业方向的特点又不相同,这时就很难再出现能把全站的架构讲的清清楚楚的人了。
所以,我们如果只是想当然的认为应该是 xxx 角色要承担责任,这样难免会片面。
二、怎么解决呢?
现实情况下,既然靠单个人或角色解决不了的问题,那就靠团队,靠良好的组织协作、靠共同遵守的架构契约来完成。这里我是从运维的角度来考虑架构契约,可能更多的还有前后端架构契约、接口设计契约等等,这个更偏向开发内部自行遵守,就不班门弄斧了。
三、架构契约中的运维部分—架构标准化
上面提到的团队和团队协作,这个就不多说了,组织定期的例会讨论,多参加彼此技术方案会议,随时随地的交流,这个只要保持开放的心态和合作模式都是可以做到的。
还是想再说一下,千万不要出现,开发说这个应该是运维考虑的事情,跟我们无关,运维说这个应该是开发的事情,开发想不不清楚让我们怎么办?如果都是这种心态就完蛋了,建议双方都往前走一步,大家要有共赢的心态才可以。
但是沟通讨论以及会议只是形式,最关键和重要的是各方要能制定出共同遵守的架构契约来。 简单来说,就是要遵循统一的标准,并使其横向延伸到运维阶段的平台中去,一脉相承,比如发布系统、监控、稳定性等平台系统,从而使得运维的体系能够更好的支持业务架构体系。而不是我们之前所说的,每个运维的平台都是一个个孤岛,无法形成体系。
重点谈谈关于架构标准化,之前提到的标准,更多的还是偏运维层面的标准,比如硬件资源标准、应用标准、部署标准等,这些在《如何打造一个以应用为核心的运维体系》文章介绍过,不多解释。但是架构标准就很少有提到了,直观看上去这一点跟运维并没有很大的关系。
但事实正好相反,我们可以一起分析下。按照我们自己的经验,在做业务服务化的早期,我们也没有意识去关注架构标准,结果就会出现以下几个场景:
1、分布式服务化框架,虽然绝大部分团队用 Java,但是因为有的团队对 PHP 特别熟悉,所以就用 PHP 去做服务化,后面遇到的问题就是 Java 的服务化接口和 PHP 的服务化接口该怎么相互调用,所以到了后来我们的服务化框架还要提供 PHP-Proxy 来适配 PHP 的服务化接口;
2、分布式 DB 中间件,有的团队觉得我们自研的分布式 DB 框架不好用,对分库分表的支持不够友好,就去自研一套出来,或者去引入其他的开源的框架进来。平时使用没问题,但是到了后期要做一些统一的策略就很难搞,比如 DB 访问策略、账号密码管控、路由策略优化、慢 SQL 统计和优化等等;
3、分布式的缓存,有的直接使用 redis,redis 可能还会有主备或者 Cluster,有的搞个开源的 Codis 方案等等
4、接入层上,有的期望用 Nginx 直接做 7 层负载,版本上有期望用 TEngine,有的期望用 Openresty,还有的期望用 LVS 有个 VIP 就够了;
5、稳定性上,比如全链路,如果要做统一的 Trace 打点,本来在一套框架上就可以实现的,结果要再多个框架上实现。对于开关、限流、降级这些策略也一样,很难统一。实际上为后续的体系建设增加了很多额外的工作;
6、上线后的日志采集,因为跟其它团队使用的框架不一样,自己在搞一套日志采集的系统,说白了都是 ELK,但是因为太个性化不统一,只能自己搞个;
以上,还不包括之前提到的类似于 Java 版本,启停方式,web 容器类型、各种部署目录等等。所以到了运维阶段,不统一不标准,压根就没法玩下去了。这个时候我就不难理解,架构的标准对于运维阶段的建设其实是有决定性的意义的。
可能有的人会说我们做的 low,管理上有问题,我不否认,现在回过头来看,当时确实是 low 了,管理上确实无意识没经验。不过在当时的情况下,特别是在初期,除非团队中能有一个技能和经验非常全面的角色,端到端 hold 住全局,否则只能是靠摸爬滚打摸索出来。现实情况,我之前经历的多个项目,包括在华为的大型的电信和互联网项目,以及当前我接触到的很多的团队也仍然还是这种玩法,必然得走很长一段分久必合的道路才能走到正道上来,而且这种能力超群的牛人,我不敢说没有,但是我能遇到的真的凤毛麟角。
根本上,还是经验意识上的缺失,而且在这一块,架构的资料中貌似很少有涉及到这一部分的内容。当然,最终期望这样的经验能够给到业界一些帮助和指导。
所以这个时候,运维必须要有意识参与进去制定架构标准,并强势的约束,所谓的约束是要体现在技术平台上的,比如在发布系统和安装部署上做约束,以 Java 举例,只支持固定 1-2 个 Java 版本,目录都约定好,容器约定好,服务化的框架约定好,这些约定好之后,如果线上要做变更,做发布,必须接入这套体系,否则坚决不让你上线,而且到了后面随着集群规模的增大,开发想绕都绕不开,因为完全靠手工已经是不可能的事情了,比如下图,是一个应用单机的发布部署过程,如果这个应用有 100 台机器怎么办?
再比如,稳定性上,我们做全链路,我们只针对标准的分布式框架做打点(当然精力有限,也不可能支持所有的框架),如果你选择的不是标准框架,而是自研或自己引入的,抱歉,打点只能自己做。这个时候遇到性能瓶颈或链路上的异常,如果使用的是标准框架,有全链路根据平台的支持,日志采集、分析和报表呈现就很方便,问题定位过程相对高效一些,如果不是,抱歉,只能手工的去定位了,一个请求分布那个应用的那台机器上去了,在这样一个分布式的环境中,效率可想而知。同样的,开关、限流、降级策略下发等等,一样会有相同的问题。
作为线上资源的控制者,稳定性的 Owner,运维,你有权利 Say No!
当然,历史原因造成的架构标准不统一的问题,是需要 Dev 和 Ops 共同合作去改造的,而不是很强势地单纯地去提要求,这个涉及双方合作方式的问题,后面再单独写篇文章。
四、我们参与了架构标准的制定,接下来呢?
上篇讲了技术架构与运维脱节的问题,这篇算是进了一步,运维真正的参与到了架构设计中,确切说是架构标准制定中,运维虽然不是架构的实现者和开发者,但确是维护架构统一和标准的执行者。整个过程,运维的角色和作用也在悄然发生着变化。
本来这篇是打算直接写运维角色到底发生了哪些变化,起到了哪些更有价值地作用的,但是觉得铺垫还不够,所以先写写架构标准的问题,下篇就差不多就可以直接写角色的转变了。
本文转载自成哥的世界公众号。
原文链接:https://mp.weixin.qq.com/s/osAaLEfI3QXU3oWEcXLBbg
评论