首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >重磅!独家解密新版技术运营标准及案例分析

重磅!独家解密新版技术运营标准及案例分析

作者头像
腾讯技术工程官方号
发布2019-09-29 10:40:11
1.6K0
发布2019-09-29 10:40:11
举报

导语:2019年9月6日,GNSEC 全球新一代软件工程高峰论坛,腾讯技术专家、《技术运营标准》核心编写专家 梁定安(大梁)全面、系统地分享了技术运营标准的七大模块及案例。 新版技术运营标准分别以七大技术运营的维度,提供可量化和可评测的运维能力成熟度检查项,供广大企业的运维同仁参考与自评,找准技术运营能力提升的路径。以下是演讲全文。

梁定安

腾讯技术专家

《技术运营标准》核心编写专家

大家下午好,很荣幸能给大家介绍 DevOps 标准的技术运营模块,技术运营总共有七个模块,核心的起草专家有三名,我今天作为代表给大家全面的介绍下,还会有结合案例把标准的内容串起来和大家分享交流。

先简单的自我介绍,我叫大梁,是高效运维社区的老朋友,现在在腾讯云负责售后技术支持工作,大家如果遇到腾讯云的使用或技术问题都可以找我,或者有意愿加入腾讯云的也可以联系我。

今天主要是分四个部分聊一下技术运营模块:

1. 技术运营标准简介

为什么要做这个标准?源自于几个核心起草的专家,都是来自于互联网行业。互联行业没有太多传统的软件工程时代的包袱,从一开始业务架构就朝着分布式来设计,应对着大规模、高并发的服务场景。因此,支撑业务应用的运维平台、技术运营能力也是按这样的思路来设计的。

李克强总理曾经说要以”用电量”衡量中国 GDP 的发展,马化腾先生也提出“用云量”将成未来经济发展重要指标,弦外之音是企业的 IT 规模将越来越大,那么做 IT 支持和运营的同学就会面临着解决大规模的运维技术难题。

在云计算盛行的当下,在开源技术和云能力的加持下,怎么样通过系统平台开源的方案,构建成企业应用的技术运营的方案?将是广大运维人员,也是技术运营标准所关注和希望找到答案的。

介绍下照片中几位参与标准编写的专家们的初心,早在2015年这张照片上的专家们就在起草写互联网应用运维框架,这就是技术运营标准的前身。

随后我们在原框架内容的基础上做了多次的修改,整个 DevOps 标准经历三年三稿,不断有各行业的专家提出建议,标准内容也得到迭代和完善。使它能够被各个企业所应用,并最后有幸在2019年7月份的 DOIS 大会上正式对外发布。

技术运营标准可以分成两大块能力组成,它是企业的软能力和硬技术,今天我会将七大模块按照这两个能力抽象介绍一下。

在编写标准时,参考很多框架和方法论,我们希望技术运营标准的内容能够更接地气,能够给予企业直接的指导和运用场景对标。因此,本标准的内容覆盖很多技术细节点,企业可以对照着完成自评估与制定规划。

同时,也希望中国企业在云计算这波浪潮中,能够将互联网的技术优势发挥好,看能否在技术运营的垂直领域创造一个新高度。这一切都是依赖于我们国内的统一,这也是本标准的价值,借助信通院、行业协会和社区的力量,将中国运维行业的精华融合,形成行业标准规范。

2. 标准的框架与设计思路

下图是 DevOps 标准全局的框架,持续交付已经发布一年多的时间,备受金融科技的企业的拥戴。随着技术运营标准的推广和评审,希望它的影响力能让更多企业受惠。

在设计技术运营的七个模块,我们更看重标准应该从务虚到务实,此前社区对外发布的技术运营简化版,里面写的内容都是可以被实施落地的。

技术运营框架主体的设计思路,因为有腾讯系的作者的缘故,标准的设计参考了很多腾讯内部对技术运营的理解。腾讯对于技术运营岗位的定义,是希望技术运营团队能够给线上的业务做到几个角度的保障。

一是质量,二是效率,三是成本。你会发现在技术运营的框架是围绕这三个角度写的,我们需要质量做的好监控能力要做到什么样;需要什么样的技术实现能够兼顾质量和效率;对于运行态的生产环境的怎样保证高可用等等,都是技术运营核心关心的主题。

监控管理、事件与变更管理、配置管理、容量与成本管理、高可用管理、业务连续性管理,这6大能力项的最终目的是要服务于企业的价值,但企业的用户价值实现与否并未体现,所以有了用户体验管理的第7个能力项。

企业的初心是要为客户提供价值。该标准有1—5级,前期信通院主导的行业问卷调查,国内的技术运营能力现状是1.5级,大家能来参会都是大于1.5级的,可以想像一下低于1.5级的企业有很多。用一句话来概括二级是中等规模的企业,已经有二级的能力帮助它完成很多技术运营的目标和效果。

之前在各大技术峰会上,听到 BAT 的运维实践分享,动不动就是几十万台的服务器的规模,监控流的数据量动辄几P。然而很多企业不需要这么海量的技术能力,马化腾先生天天说要做产业的助推器,做技术运营的标准也是同理。

我们应该换一种姿态,从维护几十万台规模的运维能力中总结经验,再从这些经验中,找到适用于不同规模企业的能力项。

例如,服务器的规模在5000台左右,细看技术运营标准的二级已经可以实现很多高效的运维能力。或者通过技术运营标准的运营,让企业从上到下的达成共同的认知,有个统一的运维能力规划,朝着三级的能力来建设技术运营平台和自动化能力,从被动运维转变成主动运维,将是很大的进步。

在规划技术运营标准时,我们有考虑到技术运营的七个模块不应是相互割裂的。有研发背景的小伙伴,都应该能够很好的理解在 DevOps 标准当中持续交付相对是比较好写的。因为过去已经有很多成型的方法论支持着研发过程管理,有很多理论被总结和整理出来,DevOps 的持续交付可以说是集百家所长的产物。但是在行业里面就技术运营的话题是没有公认的定义。而这次技术运营标准中的七大模块,也是经过专家们反复斟酌讨论出来的。

我用一个例子来介绍下模块与模块之间的关系,大家看配置管理,垂直的纵深是层层递进,从人肉支持到平台化自动化的递进,纵向的能力描述更多的是站在维护对象的全生命周期来叙述的。七大模块间的横向能力,则是在同一生命周期阶段中,相关联的能力描述,如监控二级是对常见的场景进行管理,对该阶段的流程、场景、高可用、容量和成本、用户体验的管理方案。在技术运营标准中,七大模块关联互补,能力层级的递进也是相对平滑的。

技术运营和持续交付中存在着重叠的能力项,为什么?当时考虑到持续交互配置管理能不能包含技术运营的话题,结论肯定是不行的。因为在做软件构建研发的过程,考虑的是软件质量的版本控制,但是在技术运营中,考虑更多的是生产环境维护的质量或变更管理等。同是配置管理,但管理的对象不一样。

3. 标准的“硬”技术与案例解读

介绍完背景的知识,进入到标准中硬的技术部分,包括四个模块,就是监控管理、配置管理、高可用管理、容量与成本管理,里面所描述的所有内容都是具体技术实践。

我给大家举一个例子,在持续交付流程后,技术运营会收到流程传递的配置对象和配置数据,监控可以基于配置数据执行数据采集、处理、应用,看看的数据又可以用作变更管理或容量成本管理的用途。容量的数据将是预算与核算管理的重要数据支撑,同时运营成本的理清,也能更好的支撑我们规划数据高可用的架构能力。

举个实际运用的例子,应用程序发布后,1 有标准运维流程支持完成配置录入。2 监控系统可以根据配置数据库的配置记录,按要求采集对应的应用程序的运用信息到监控系统中。3 监控数据可以组装成基础设施容量和业务容量。同时,4 容量数据可以服务于变更能力,如弹性能力、柔性能力、运行与维护。结合实际运用的容量数据,5 可以确保应用程序的成本合理性,并基于此做预算与核算。

同理,如果要实现进程自愈的自动化运维的能力,只需要在应用程序部署到生产环境后,在配置数据库中,注册上对应的运行IP、进程名称、启动命令等配置信息。监控系统具备在对应的IP上监控对应的进程名称的功能,当进程不存在时,自动化调用该进程的启动命令,既可以实现一连串的自动化运维操作。

通过这个案例,希望大家能够更好的理解四个模块四个模块之间的关联关系,在企业的实际运维工作中,如果能很好的通过流程或平台能力,将四大模块的能力组合使用,将会使企业运维能力上升一个台阶。

为什么如此简单的进程自愈仍要把它能力分级?试想下,如果不走配置对象管理这一步骤,当一个告警说某某IP上的进程不存在时,我们无从求证该IP上是否需要部署该进程,这也是先规划再运营的一个典范。运维的规划不是凭空而来的,而是通过每一次持续交付过程的软件构建发布而来,从软件的发布源头就确保配置的准确性。

监控管理的分级主要是由监控数据流处理的三部分组成:监控采集、数据管理、数据应用。

配置管理能力更多的是考虑到能力阶梯式提升,大部分企业如果没有独立的配置管理系统,最大的配置管理系统就是Excel表格,好一点的可能是在线的表格。其实,当企业IT的规模很小时,未必就需要一个功能很强大的配置管理系统来支持运维工作。

本标准也是朝着这个思路去设计的,一级没有过多的去谈论配置管理平台的规划,更多的是从实现的效果入手,将基础设施对象纳入管理。二级则需要纳管应用软件的生命周期,如软件名称、发布环境、运行状态、进程信息等等。配置管理的能力提升,是取决于我们要解决运维场景的复杂度,是个循序渐进的过程。

在介绍高可用管理时,我想先以招行手机银行的案例介绍产品与技术协同的最佳状态。招行转帐功能操作后,会有6秒钟倒计时,其实在技术上转账并不需要耗费6秒的时间,但是从产品设计上预留的6秒,给予了业务调用的事务流程足够的失败重试时间。确保在用户界面见到的转账功能的成功率是极高的,这个产品功能的设计是很符合 DevOps精神。

在金融强事物型的交易调用链路中,有任何一环出错转帐就会失败,但是产品设计用6秒钟来完成事实上只需要1秒钟的业务流,在最坏的情况下最少可以重试6次,才给用户反馈结果,以此最大化的保障了服务请求的成功率。

这个是特别成功的案例,是产品、开发、测试、运维相亲相爱很好的结果,有一些场景光靠技术的办法解决,往往会需要投入昂贵的成本。因此,企业在构建高可用能力的同时,建议更多考虑 ROI,让成本花在刀刃上。

容量和成本管理也是这样的,一级客观的量化,大家能够通过一些技术的监控,能看到单台机器的容量,若按照硬件的维度聚集的方法聚集,或按照业务维度聚集,看看基础设施CPU是不是平均分布均匀的,能够看到这样的容量数据就 OK 了。

第二级要求能实现关联的计算和场景化的使用。举个场景化容量实用的例子,假设电商平台双十一要做运营活动,这个时候计算业务的容量,它就得关联分析,找到端到端的容量瓶颈点。而到三级的能力,则更多强调主动的管理,应该有更多优化思路被提出和执行。例如,为了一个运用活动是需要提前购买充足的设备容量,还是在技术上实现一个柔性策略扛过峰值即可,都可以根据我们对容量合理性的分析和成本的把控来决策。

4. 标准的“软”能力与案例解读

分享的第四部分是介绍标准中的软能力,这个其实很重要的,因为组织是要靠流程、组织、数据驱动等管理手段将技术能力串起来服务于业务目标的。

举个案例,业务如果要做一个重大活动的保障,首先我们需要定义业务的价值是什么?在元旦零点的微信发朋友圈功能,用户价值是要保障朋友圈消息的发送成功,但在元旦零点的高并发场景,为了扛住上亿用户同时在0:00的流量可能需要扩容10倍的服务器,那在成本合理的方案下,我们会选择适当的扩容,再配合用户排队或者延迟发送的方案。并以此建立完整个机制,确保标准的执行操作和应对异常场景的容灾和应急管控的方案,最终把技术服务的用户体验做到位。

技术运营的第一个介绍模块是用户体验管理,区别于传统行业运维的”封闭”,在互联网行业对用户重视程度特别高,运维也同样,这也是 DevOps 提倡的技术价值。为此,根据互联网企业的实践经验,把用户体验管理这部分的内容独立成一个模块,希望技术运营的能力提升一定是服务于用户价值的。

事件与变更管理核心逻辑是事前、事中、事后应该怎么做,需要有怎样的机制,需要有怎样的流程和仪式感,才能保证每次变更的质量和效率,同时有必要的流程支撑好运维阶段的事件管理。不同的能力分级,分别覆盖平台化、可视化、系统间的信息联动等。

最后就是连续性管理,这里参考了ITIL中对故障测量的 RTO 方法,对业务的影响评估和对风险的分析。运维组织对危机管理和应急管理的必要准备。

为什么有很多企业明明有业务容灾方案,但是偏偏在紧急关头不敢切换?因为,大家对业务容灾切过去是否正常心里没底,不知道切过去等待着大家的是恶魔还是天使。但如果这个容灾切换每天都在做,当真正故障来临需要调度切换时,它就是稀疏平常的事情,自然会执行的干脆迅速。

今天简单的给大家介绍了技术运营的七大模块,引用的一些案例希望能让大家更容易理解标准背后的目的,和更全面的了解 DevOps 技术运营的内容,谢谢大家。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-09-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯技术工程 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
CODING DevOps
CODING DevOps 一站式研发管理平台,包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务,涵盖软件开发从构想到交付的一切所需,使研发团队在云端高效协同,实践敏捷开发与 DevOps,提升软件交付质量与速度。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档