UDN-企业互联网技术人气社区

板块导航

浏览  : 1696
回复  : 0

[资讯] 用户导向的全球研发团队运维转型之路

[复制链接]
饼干妹妹的头像 楼主
发表于 2017-1-16 21:36:11 | 显示全部楼层 |阅读模式
本帖最后由 饼干妹妹 于 2017-1-16 21:37 编辑

  前言
  
  今天给大家分享的是从去年下半年开始,我带领团队在接受欧洲大区的应用运维工作,以及转变工作模式的过程。做到现在,从实际效果来看还不错,各方面的评价和应用的稳定情况都在提升。
  
  首先会介绍一下工作的背景,中间会将我们都做了哪些事情帮助我们尽快进入角色发挥作用,以及回头来看总结出来的一些心得,希望对大家有些启发。
  
  在最开始先讲个小故事:有一次和家人自驾游,路上非常堵。儿子被堵的不要不要地之后,好像突然发现新大陆一样地大叫:“爸爸爸爸,对面那个车道车子很少,我们开到那边去吧!”我当时脑子好像一下子短路了,深深地泛起了一种“你说的如此在理,我竟然无言以对”的感觉。
  
  我愣了几秒钟之后和他解释说:“我们不是只要开得快地,首先要开的方向对啊,如果方向不对,可能离我们要去的地方越开越远对不对?”其实工作策略的制定也是一样。
  
  这个案例来自于传统行业的应用运维实践,从技术上说性感程度一定比不上互联网,但是我想方法和方向上的思考应该是相通的。
640.webp (8).jpg
  
  传统行业从单纯的数据体量上来说可能没法和互联网行业相比,但是它们有自己的运维难点。以金融行业为例,我们的业务复杂度特别高,单纯欧洲大区的本地系统就超过150个,这还不算全球统一使用的集团系统。
  
  单日的平均交易量在百万到千万级别,这个量听起来不算特别高,但是每条数据可能需要端到端跑过这150多个系统中的1/3甚至更多,这个过程的复杂度,对系统间的衔接性和延续性要求都非常高。
  
  金融企业运维背景
  
  金融行业非常强调系统安全、权限保护,系统开发、运维和操作之间的权限是隔离的,不同架构层次上的组件的访问和操作权限也是隔离的。
640.webp (7).jpg
  
  开发没法直接访问线上环境,应用运维团队能看到线上环境但是没有权限直接修改,也无法获取中间件诸如消息中间件、文件服务器等更底层的信息。这从客观上增加了应用运维的难度。
  
  之前的应用运维团队主要由印度团队进行支持,客观来说印度团队的执行力和纪律性都非常强,但是似乎从解决问题的主动性和分析问题、解决问题的动手能力上弱一些,并且跨时区支持的客观困难和随着时间推移带来的人员流失,知识积累和传承也成了问题。
  
  新人只知道按照操作手册工作,并且很有可能是没更新过的版本。这样带来的后果就是问题反复出现,得不到根本解决。我们跳进去之前,我看了一年的历史数据,平均来说一个月大概出现7000多个故障单,其中排名前十的系统占到60%。
  
  金融企业面临的问题
  
  在这样的客观情况下,重重的限制导致没法做充分的根源分析,问题得不到彻底解决,出现了这样一些现象:
  
  •   问题是用户首先发现的而不是运维首先发现的;
  •   问题发生很久之后才被运维发现,这时候留给抢救和恢复的时间已经很短,一些实际的业务损失已经形成;
  •   由于权限隔离,为了定位一个问题,需要把不同角色的人拉进来,从不同角度来查询信息,信息获取和分析的效率非常低;
  •   同样的,因为权限控制的问题,不同角色的人不能跨越式操作,必须经过完整但是冗长的确认和审批流程,问题解决的效率更低;
  •   由于这些信息孤岛的存在,以及前面提到过的知识流失的问题,问题的根源通常得不到彻底洞察和解决,未来同样的问题会一再出现;
640.webp (6).jpg


  这些现象我们在自己跳进去之前,跟着原有的运维团队跑过一段时间,日子是非常苦的,基本上三班倒,并且一个问题的解决可能都需要5、6个小时。如果不幸发生在快下班的时候,跟跑到凌晨也得等到彻底结束,生活非常痛苦。
  
  但是,不得不说,其实我们的用户在线上事故中比IT要更痛苦。讲个段子,有一次和一个内部的用户聊天,他说你都不知道,每次出了事故如果影响到了业务交付,我们必须要部门的头写一个事故说明书,签字、传真向我们的客户说明并道歉,里面要解释为什么做错了,下次会怎么改进保证不会再犯。
  
  我们有一些客户呢,他们是替一些皇室做理财的,如果我们的事故影响到了他的业务,他可能要拿着我们的说明书以及他们自己的报告,上门向他们的客户道歉。这种直面业务的压力,真的是比IT要更痛苦。
  
  我们该如何采取行动
  
  我们是去年下半年被拉到这个工作里面来的。一开始的确有点慌,感觉是个大坑,但是没有办法,工作接到手上就要做好。
  
  我们做了下面这么几件事情。首先花了很长时间做了一个 retrospective,回顾过去一年发生的线上事故,做根源分析,用的是精益里面的 5 why 的方法。对一个问题问5次为什么,最后得到的答案才是真正的根本原因。
  
  找到根本原因之后,会总结出一个应急预案,这个应急预案的目标是保持系统可持续性或者可恢复性。
  
  我关心的不是问题出在哪一段代码应该怎么 fix ,而是问题一旦发生怎样用标准姿势最快地让系统恢复原状继续执行。
  
  回顾的第二个层面是所有的用户请求以及系统后台日志记录下的异常。对用户请求的分析会看请求的类型是不是集中在某个领域,因为系统没有提供需要的功能而不得不后台操作。对后台抛出的异常则会看一下是不是对系统稳定性造成风险。
  
  对这两类问题的分析得出两类改进。
  
  一是可用性改进,让用户以自服务的方式得到所需.
  
  二是健壮性改进,消除异常隐患。
640.webp (5).jpg
  
  做的第二件事情是 appersona 。这个是我造出来的一个词,大家可能都知道 persona 是用户画像, appersona 就是替应用画像,把准备接受的应用基本情况做一个摸底。画些什么东西呢?
  
  第一我要明确应用的业务指标是什么?比如说你什么时候从哪个客户收到什么业务数据,什么时候产出什么样的数据或者内容给谁。整个业务处理关键路径是什么,包括哪几步。
  
  第二是关于工程纪律 ,150多个系统,很多事遗留系统,可能连专门的研发都没有,经过3、4年甚至更长缺少恰当的维护,很可能埋了很多坑。不把基本的配置管理和交付流程情况弄清楚,接手的基本上就是个定时炸弹。
  
  第三是上下游接口, 其他外部依赖系统的接口和相关的服务水平协议(SLA)或者服务水平目标(SLO) - 期待的输入约束是什么,保证的返回是怎么样,相关系统的可用性保证是怎么样。
  
  第四是是整个应用系统的拓扑,基础设施是双活还是单活,灾备和热备服务器在哪里,谁在支持,切换流程如何,还有什么中间件系统,他们与系统的连接方式是什么。
  
  以及所有这些模块和环境的维护者是谁,我们可以通过什么样的流程拿到什么样的权限。最后根据前面所有的信息做一个重点干系人矩阵,并且和这些干系人都取得联系,至少打个招呼说声你好,我们来敲门了,以后多多合作。
 
640.webp (4).jpg
 
  接下来我们做了一个 top down 的 APM 目标分解。GARTNER 在2014的 APM 报告把 APM 关注领域分成了4个象限。
  
  首先是传统的自底向上的,面向基础设施的 APM,首先关注的是网络、硬件、基础设施的指标。但是随着数字化深入到每个行业,TOP DOWN 自顶向下的模式收到了更多重视。
  
  它从业务指标出发,分析运维需要监控的内容。我们的 APM 分解,就是从业务流程和关键指标出发,分析系统拓扑和关键路径,在两者之间进行匹配,哪个业务指标能够被对应到哪条系统处理流程,或者哪一步所在的系统环境。基于这两块的信息归纳出监控规则。
  
  监控的方向可以分成三类:
  
  第一类监控状态的0和1,所谓的是不是存在,是不是发生。
  
  第二类是基于统计信息的,比如说做常规的系统性能健康巡检里面做统计值对比 – 过去一个小时里面某个重要业务指标对比过去一个月平均值如果发生了剧烈的跃迁,应该要做什么事情。
  
  第三类是针对业务最终交付的业务和服务的数量与质量的监控。
640.webp (3).jpg
  
  有了这些信息之后,我们对需要关心的内容有个全面的了解。基于这些信息,我们做了一套自己的监控系统。东西不复杂,思路和很多互联网厂商的内部监控差不多,实现也是从小到大一点点来的。
  
  最主要的一个特点是,设计的思路是自顶向下围绕业务指标分解分析展开的,所以对采样、查询和监控的语义表达能力、实时性有更一致的规划。首先是数据采样,去不同来源以不同形式采集度量数据,以有侵入和无侵入的方式。
  
  采样的以时序数据形式为主,保存在 no-sql 的平台里,在这个基础之上做数据聚合,包括在线和离线的运算,平均值、中值、最大最小值,甚至包括多维数据的复合之后再做统计。
  
  由于监控的规则最终可能来自于业务人员,我们基于一个相对固定的模式提供了类自然语言的规则定义,在背后把它转换成 drools 的规则,因为 drools 支持复杂事件处理和滑动时间窗口监控,这两点是我们比较看重的。
  
640.webp (2).jpg

  我们做的最后一个事情技术性没那么强,做起来非常费事并且需要一直坚持,但是坚持下来之后在解决问题时候非常管用。就是与主要干系人建立常规联系。
  
  包括和业务的联动,我们会定期分析用户提的请求,看看主要的类型是怎么样,是不是系统已经提供了这样的能力,有没有一个固定的pattern,是不是能够反馈到开发或者运维自己去做个改进。
  
  有一个例子就是我们发现一组用户在过去的一念里面,持续地针对他们的一个客户要求导出一个时间窗口的数据组合。
  
  我们发现系统没有实现这类功能,那么一方面我们和开发团队反馈这个需求,另一方面我们和用户约定好主动定时导出这样的数据,这样就不用用户反复来请求了。
  
  还有和开发的联动,这个包括前面提到的从业务联动和日常工作分析里面得出的系统健壮性和可用性的改进,反映去研发之后的跟进。
  
  和研发联动里面我们做了一个比较有意思的事情是引入了保质期的概念。因为接运维不是一锤子买卖,接了之后整个生命周期都需要对它负责。
  
  但是在这个过程里面研发团队还在不断地加功能,那怎么保证这锅汤不变味呢?我们要求研发对新上线的内容承诺一个保质期。
  
  具体来说就是当一个变更上线之后,我们希望研发团队先进行监控,在稳定运行至少一个月之后,并且完成了知识交接和对原有运维规则和应急预案影响评估,和相应的调整之后才敢接手。
  
  其他利益干系人主要是指中间件的监控和支持那一块,保证当问题发生在这些地方的时候,有一个常规的沟通和追踪渠道保证问题不至于沉没。
 
640.webp (1).jpg
 
  按照这样的思路做了一段时间之后,应该说还是取得了一些成绩。这里有几组数据:我们刚刚启动的时候是5个人的团队,做了3个月,开发出一套基本的监控系统,在它之上建立了13个系统的监控任务。
  
  对其中最主要的应用(占到用户问题总数的20%),提出15个健壮性改进,实现了其中3个,单月这个应用的用户问题减少了20%。提出了10个可用性建议,实现了其中三个,减少了这个应用30%的用户申告单请求。
  
  总结
  
  做一个小小的阶段性总结的话。在开展应用运维的工作的时候,我们的整个思路是这样的:围绕业务指标,关心用户真正关心的东西。有3个核心工作面:
  
  第一个是守护,守护业务,守护系统的可用性,系统的可延续性和可恢复性。从6西格玛的角度,就是保证可用性水平。
  
  第二是洞察,洞察包括有意识地采集、分析和处理或者是建立你自己的运维的业务层面的监控数据和规则,并且针对历史数据要有有意识、有规律地回顾,得到一些洞察和洞见,返回给用户和研发团队。
  
  第三是连接,运维其实是有着自己关注点的一个工种,研发不可能完全代替,在IT团队内部,你也没法一个人同时带两顶帽子。有不同的player,怎样在这些角色之间形成联系进而保证持续改进的闭环。运维在这当中得到的洞察力和对业务指标的敏感度是构成连接闭环的重要条件。
  
640.webp.jpg

  最后给大家分享一句话,“企业除了业务之外,没有别的问题”。互联网企业、传统企业从本质上都需要关注自己的业务,其中可能需要平衡短期利益和长期利益,但是企业的关注点,需要始终保持在业务上,否则将无法生存。

作者:李卓

640.webp (9).jpg

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部