专栏首页Forrest随想录运维需不需要懂产品和运营呢?

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

一、架构实施和架构运维

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

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

d、。。。。。。。

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

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

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

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

三、思考一下

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

相关阅读

关于这块分享,之前也分享过一些观点

1、《我所理解的SRE、PE和应用运维(上)》

2、《我所理解的SRE、PE和应用运维(下)》

本文分享自微信公众号 - Forrest随想录(forrest_thinking),作者:赵成

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-08-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 应用运维的发展趋势和发展建议

    上两篇SRE文章写完后,是计划写一篇应用运维发展趋势和发展建议的文章,前两天阿里的毕玄大神分享了一篇《阿里应用运维体系的变迁》的文章,讲述了阿里整个应用运维发展...

    赵成
  • 有运维专家推荐吗?

    因为工作行业的原因,会有很多的同行或朋友找我推荐一些有运维经验的人,或者直接希望要运维专家。

    赵成
  • 谈谈运维的价值

    2016GOPS上海大会参加完有一些感受和感想,最近一直在思考,再就是前两天在高效运维的群里,大家又谈到运维苦逼,没有成就感的事情,也促使我更加的想表达一下运维...

    赵成
  • Linux运维人,该醒醒了,2019年要变天了

    外界都说运维只是处于被动低效率手工救火的状态,企业对其重视程度不高,提起运维很多人能联想到的字眼就有“苦逼”、“辛苦”、“加班”、“背锅”。在大数据、人工智能、...

    马哥linux运维
  • 运维未来的发展方向是智能运维(AIops)

    近年来运维技术飞速发展,运维团队大多建设好了各种系统:虚拟化、容器化、持续集成等等。但是如何有效的利用这些系统最终实现站点的高可用、高性能和高可扩展?随着智能化...

    日志易
  • 谈AIOps基础-从自动化运维到智能化运维

    今天准备谈下AIOps的内容,在我前面已经写过多篇文章谈DevOps研发运维一体化方面的内容,原来也一直看到AIOps的概念,潜意识里面理解是DevOps里面的...

    IT大咖说
  • 一文帮你理解整个 SRE 运维体系!

    在任何有一定规模的企业内部,一旦推行起来整个SRE的运维模式,那么对于可观测性系统的建设将变得尤为重要,而在整个可观测性系统中,通常我们会分为如下三个方面:

    杰哥的IT之旅
  • 运维数据生态之数据思维

    前言:在上一篇文章《建立数据指标体系,推动DevOps全链路度量闭环》中,我们描述了基于数据来建立数据指标体系,通过指标体系达到主观事件客观呈现的效果。信通院的...

    顾黄亮
  • 自动化运维时代,运维失去价值了吗?

    最近一直在思考,大家又谈到运维苦逼,没有成就感的事情,也促使我更加的想表达一下运维价值方面的东西。

    taskctl官方频道
  • 云时代的运维正是不折不扣的架构师

    上学那会,每当作文中引用到张良这个典故,总喜欢用 “运筹帷幄之中,决胜千里之外” 来赞美张良雄才大略,指挥若定,现在还让我用的话,我会把这句话送给运维同学。

    用户5166556

扫码关注云+社区

领取腾讯云代金券