写点什么

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

  • 2020-03-18
  • 本文字数:3686 字

    阅读完需:约 12 分钟

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

一、架构实施和架构运维

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


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


2020-03-18 21:191188

评论 1 条评论

发布
暂无评论
发现更多内容

京东企业业务前端监控实践

京东零售技术

前端 监控 企业号 8 月 PK 榜

【AIGC】 0成本学习:AI工作流生成Joy(ComfyUI)

京东零售技术

AIGC 企业号 8 月 PK 榜

数据分析慢?火山引擎ByteHouse发布六大场景性能提升方案

字节跳动数据平台

数据库 云原生 OLAP 数仓

macOS Ventura 13.6.9 (22G830) 正式版发布,ISO、IPSW、PKG 下载

sysin

macos ISO ventura

macOS Sonoma 14.6.1 (23G93) 正式版发布,ISO、IPSW、PKG 下载

sysin

macos ISO Sonoma

危化品安全生产风险监测预警系统的构建与实施

天津汇柏科技有限公司

安全生产 安全生产平台

海外成品语聊交友软件APP(英语+阿拉伯语版本)相比定制研发,优势有哪些?

山东布谷科技胡月

源码搭建 语音直播源码 语音聊天APP源码 海外直播App开发 海外语聊APP

AI自动化应用开发,让创意与效率并驾齐驱!

霍格沃兹测试开发学社

AI安全新纪元:智能体驱动的网络安全新范式

云起无垠

AI 智能体

观测云产品更新 | 异常追踪、用户访问监测、链路、监控等

观测云

异常追踪

和鲸科技助力 Datathon 会前培训成功举行,“理-工-医-信”跨学科合作,以数据驱动医疗实践

ModelWhale

医疗AI R 语言 datathon 医疗大数据

LED显示屏行业可突破的六大领域

Dylan

云计算 虚拟现实 LED显示屏 全彩LED显示屏 led显示屏厂家

我叫小舞,跳舞的舞!新斗罗大陆游戏详细图文架设教程

echeverra

斗罗大陆

和鲸科技CEO范向伟出席江苏省信息技术应用学会软件技术专委会学术年会,解读“AI+教育”创新实践

ModelWhale

人工智能 软件 信息技术 产学研

MES系统是什么?MES软件有什么用?

万界星空科技

制造业 生产管理系统 mes 万界星空科技 生产管理

聚焦OLAP性能提升,火山引擎ByteHouse发布六大场景方案

字节跳动数据平台

数据库 大数据 云原生 Clickhouse 数仓

云图说|一图告诉你主机安全的运维效率如何提升超出预期

华为云开发者联盟

运维 主机安全 新版本 企业号 8 月 PK 榜 2024企业号8月pk

全国高校软件测试开发教学师资培训会圆满落幕

霍格沃兹测试开发学社

使用观测云构建业务的可观测性

观测云

可观测性 业务监控

全国高校软件测试开发教学师资培训会圆满落幕

测试人

软件测试

不可重复读和幻读有什么区别

江南一点雨

Java MySQL 面试题

数据分析的关键点有哪些?如何做好数据分析?

Aloudata

数据分析 指标平台 noetl

如何保护您的 Angular 应用程序:API 调用的端到端加密

哦豁完蛋了

技术同学如何应对降薪裁员

老张

职场 裁员 认知 互联网裁员

聚焦OLAP性能提升,火山引擎ByteHouse发布六大场景方案

字节跳动数据平台

数据库 云原生 Clickhouse 数仓

高价值数据源于结构化和非结构化融合分析

AI数据云Relyt

数据仓库 数据湖 数据分析 非结构化数据 AI-ready Data Cloud

24年内蒙古等级保护测评机构看这里!

行云管家

网络安全 等保 等级保护 内蒙古

大咖公开课 | AI自动化应用开发,让创意与效率并驾齐驱!

测试人

软件测试

运维需不需要懂产品和运营呢?_软件工程_成哥的世界_InfoQ精选文章