运维需不需要懂产品和运营呢?

阅读数:1 2020 年 3 月 18 日 21:19

运维需不需要懂产品和运营呢?

一、架构实施和架构运维

继续接上文,我们制定或约定了架构标准,接下来就是架构的实施过程,架构实施应该怎么理解呢?我大致列一下过程应该就比较清晰了:

1、业务分析过程中,职责明确的业务模块从整体中拆分出来,比如用户、商品、交易、支付等等业务逻辑;

2、从服务化的角度拆分,这样一个大的业务逻辑可以拆分出更细的服务化模块,以商品为例,会有商品详情、库存、评价、价格、标签等等,如果继续细分可能还会有各种读写逻辑的功能化的服务拆出来,拆分的原则啥的我们这里不细说,这个基本取决于业务架构师的判断标准;

这个阶段拆出来的一个个模块,就是我们所说的应用了,这时就要开始应用名的定义,至此,一个应用的生命周期开始启动。

3、应用生命周期启动后,应用相关的信息就需要在运维系统内生成了,也就是我们所说的 CMDB 和应用配置管理相关的额信息。(应用相关的信息见文章《如何打造一个以应用为核心的运维体系》),重要的跟运维相关的如应用对应的 Gitlab 地址、基础软件模板和配置、以及对应的开发、测试和线上的资源需求;

4、根据上面拆分出来的应用,开发同学就要根据我们之前约定的架构标准,开始选择标准化的框架了,比如分布式服务化、消息、缓存、DB 中间件、以及稳定性和一些第三方的 SDK 包等等;

熟悉开发的同学都很清楚,上面这些框架选定好之后,按照 Spring Boot 的模式,可以自动生成整套的代码框架,就省去了手工引入各种二方包、三方包和一些固定的配置,也就是 Spring Boot 的“约定大于配置”的思路。这个也是目前绝大部分团队的选择的微服务的应用模式。
这样开发同学可以把更多的精力放到业务逻辑的实现上,而不是各种各样的框架引入和配置上面。所以,不仅仅是运维自动化,代码开发也一样在朝着更加自动化的方向发展。(再进一步,Spring Cloud 的体系则更加完善)

5、启动业务代码开发后,就该进入到持续交付阶段了,具体可以看《XXOps 实践:持续发布和部署》,不过前提是得先有持续交付的体系;

6、业务上线后,就进入持续运维和反馈阶段,如监控数据的分析、稳定性保障、核心应用和链路的容量评估、应急预案的制定和演练、强弱依赖的分析,以及从用户提交角度的数据分析和保障措施等等;

7、应急事件和故障的响应、处理及回溯机制,因为故障没有办法 100% 的避免(但是应该杜绝低级的人为失误和重复错误),我们要做的是故障的快速甚至是提前发现、业务的快速恢复,以及故障后的回溯和改进;

按照《聊聊架构》书中的架构生命周期的划分,上述过程,我们认为是架构的实施阶段,不过 1-4,更多的可以看成是开发为主进行实施的,5-7 阶段则应该更多的是运维为主的阶段(如果持续交付做的好,其实 5 也是可以以开发为主)。

不过,我的理解应该将 5-7 这个阶段拆分出来,定义成架构运维或架构看护阶段。图示下来,就是如下过程:

运维需不需要懂产品和运营呢?

从上图我们就可以看出,运维应该要体现的作用和价值了。

二、运维的角色转变和价值体现

1、技术产品

产品是指能够提供给市场,被人们使用和消费,并能满足人们某种需求的任何东西,包括有形的物品、无形的服务、组织、观念和他们的组合。(摘自百度百科)

整个运维过程中,运维一定要转变被动响应式的工作方式,要主动求变,其中最重要的就是树立起产品意识,将日常的人肉的、繁琐重复的工作不断的总结和提炼。

比如,是不是能够把自己原本靠人工完成的很多工作转化成需求?是不是能够把日常工作中运维和开发的痛点转化成需求?是不是能够把当前系统存在的问题和隐患找出来,在解决的过程中,经过分析总结提炼成需求?

当需求提炼出来之后,是否能够准确的传递给工具开发团队,并跟工具开发团队一起把需求真正的落地实现?

以上过程,就是将运维的人肉能力转化为平台能力的过程,比如持续发布,没有发布系统之前,完全靠人肉堆,开发、测试和运维一起上,还经常出问题。但是有了发布系统,将人做的事情转交给平台自动化去做,最终满足开发快速将代码发布上线的需求。

结合上面对产品的定义,看看我们上面做的事情,是不是就是一个技术产品的工作呢。当我们具备了这个意识,能有更多的工具做出来,逐步形成体系,我们的工作是不是变得更轻松了呢?

2、技术运营

运营的目的,和产品经理核心的不同是,要实现扩散,爆发,增长,收益等等。(摘自知乎)

通过上面的技术产品的工作,如果可以做出一些有针对的工具和平台来,但是仅仅有工具和平台就够了吗?不过,远远不够,为啥这样说呢?

a、推广落地,工具做出来了是第一步,得要有人用,这就需要去推动落地。(跟业务上做出一个产品来,要去找渠道推广,要吸引流量过来,并最终产生经济收益是一个道理。)当然,我们在内部倒不必吸引用户来用,因为我们的技术产品更多地是标准、流程和规范的载体,既然大家之前都遵守了这套标准体系,那就必须使用(使用之前做些小范围的试用还是必须的),所以这个过程是可以强势一点的。比如线上仅保留发布系统一个变更入口,其他变更权限全部收回等等。

b、线上运行数据分析,应用上线或者每次变更上线后,线上运行的情况咋样,容量有没有降、RT 有没有上涨、监控有没有异常,业务量上是否有激增、用户体验有没有下降,用户和客服的反馈如何等等。以上这些维度和指标就需要一张张的数据报表呈现出来,通过数据分析来指导我们要做出哪些优化和调整。(想想看,业务运营是不是也非常关注业务数据报表的)

c、过程改进,工具更多的是一个执行角色,但是工具的使用是要配合大量的标准和流程一起来运作的,比如说持续交付,里面就会涉及持续集成,再往细里讲,代码分支应该如何合并,出现冲突后应该如何解决,自动化测试需要哪些用例,用例等级如何定义,测试验收的标准是什么,构建失败应该怎么处理,当团队成员无法达成一致的时候,应该如何决策等等;再比如,b 中提到的遇到的种种上线后的情况,应该对应什么样的机制处理下去,这些都是技术运营过程中所面临的问题。一方面要先有对应的流程机制确认下来,大家共同遵守,另一方面,执行过程中,如果有导致效率下降或者有更好的措施的时候,这个时候就需要过程上的改进。

我们面临的业务场景再不断变化,技术趋势不断发展,就决定了技术运营过程一个持续改进的过程。

运维需不需要懂产品和运营呢?

在腾讯,运维被定义为技术运营,我觉得还是很贴切的。我在很多大会上听海外的华人工程师分享,Operation 这个词都是被直译成运营。所以,我也很能理解老王在多次大会上都说,国内也不知道谁,把 IT Operation,IT 运营这么高端的一个词汇,给硬生生地非翻译成了运维这么个意思,确实无奈:)。
Anyway,不纠结。因为运维所发挥的技术运营的作用,这个能力其实才是运维的核心价值和转型的关键。

3、技术服务

我觉得两层含义,一个是一定要有服务的心态;另一个,提供解决方案,还是举个栗子:

比如,我们在线上运维过程中,发现有一块相对独立的业务,体量越来越大,随着用户的增多从一个非核心的业务变成了一个核心业务。但是,这个业务是用 C++ 来做的,架构上是分层架构,每层都是通过配置 IP 的方式进行接口调用,还有跨层的调用,调用逻辑很不清晰。遇到的比较突出的问题就是效率和稳定性:

a、发布的时候,就没法做到服务发现,要一台台改配置将流量迁移走,然后手工执行发布脚本同步代码,然后再将配置改回来进行验证是否成功了,随着机器数量越来越大,开发就吃不消了,太麻烦;

b、出现故障,唯一的手段就是回滚、重启、干瞪眼,类似降级、限流或开关的稳定性手段都没有;

c、线上容量也没法评估,发布个版本发现容量不够,就扩容,而不是真正去找一下性能下降的原因;

这个时候发现了问题,我跟团队一起去做的事情,找到对方的主要负责人和其主管(或者对方来找我们),大家一起坐下来,针对现在的问题和痛点,看如何改进,比如发布效率低,那发布的过程步骤是什么,我们一起看看什么地方可以改进和提升,比如有写死 IP 的情况,那是否可以做到分配从代码中分离,或者考虑服务发现的方案(服务发现考虑过,但是实现成本比较高,现在做需求还做不完),那是否可以利用现有的服务化框架,然后给中间件团队提需求尽快支持 C++ 的分布式服务呢?嗯,这个可行,我们一起找!

稳定性有问题,我们现有的稳定性系统支持开关、降级、限流,最近碰到的问题如果有降级措施的话,是可以将故障快速隔离的,然后介绍下现有稳定性的解决方案,评估了下,嗯,可以搞。

最后的结果是,双方共同配合进行改造,将一个维护效率和稳定性不高的业务大大改进了。

这个时候,运维虽然不是代码的实际开发者和改造者,但是通过解决方案和思路上支持,推动了业务架构上的演进。这里也不是开发同学能力水平不行,而是业务需求量大,实在没有这么大的精力去端到端关注全面的东西,但是两者一旦都向前走一步,擦出基情的火花,事情效果很显著了。所以我们配合一定要有共赢的心态,而不是你是你我是我一定要分的很清楚,当然这个过程中,我建议运维应该向前多走几步。

三、思考一下

技术产品、技术运营、技术服务,从这三个角度来做运维,运维还是原来那个运维吗?个人的成长空间、承担的职责以及价值的体现,是不是会大不一样呢?欢迎留言讨论。

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/jYQXJ_sZEhSs9o5Y-fFW4Q

评论

发布