精华内容
下载资源
问答
  • 企业软件的组件不能标准化、模块化的原因是什么?因为此话题说来话长,所以特写一篇博文以回复。一、企业软件的组件为啥不能标准化企业软件是映射企业现实的。只有给企业现实建立3D扫描模型,才能很好的把这个企业...
    微博上有朋友问:十来年前很多ERP类企业软件就号称模块化、积木化、业务组件化,按需拼装,即插即用。今天来看,还是忽悠成分居多。企业软件的组件不能标准化、模块化的原因是什么?


    因为此话题说来话长,所以特写一篇博文以回复。


    一、企业软件的组件为啥不能标准化?


    企业软件是映射企业现实的。只有给企业现实建立3D扫描模型,才能很好的把这个企业3D扫描模型转换为企业软件。


    有什么工具、方法来把企业现实做成企业3D扫描模型呢?这就是企业业务建模。


    我个人的企业业务建模方法是:


    1、业务流程层面,通过组织流程法来建模。先定义企业的组织层级/部门、岗位。再逐一定义每个岗位的职责。再逐一把每个职责展开为一级流程和二级细化流程。再把每个流程节点的输入输出详细格式要求定义出来。这样就把业务流程层面建模起来了。这就类似给企业的业务拍个照片。但依照这样的业务流程模型做出来的软件,也就就是个企业E化,对改进企业的问题帮助并不大。不过,对于中国企业还是合适的。因为大部分中国企业连自己的组织/岗位职责都说不清楚,管理水平还处于一屁股坐在地上的水平。


    2、但是,企业养了这么多细分专业细分岗位的人,成立了这么多部门,其实都是为了支撑企业的战略目标的。这些都是企业的资源,而企业的资源又不是无限的,所以就需要做好企业资源规划。首先要确定企业的战略,分解战略到行动方案/行动组织/行动计划/行动考核。这样就可以调动企业所有资源,打穿各个部门各个岗位,组织整合资源,为企业战略支撑实现而服务。企业的主干不外乎是生产、销售、服务这三大块。所以需要围绕这三大块开展打穿整个链条的业务模型。在这样业务模型基础上建立的企业软件,才是真正的企业级管理软件,因为这个模型是站在整个企业的视角上看问题的,不是一个部门的业务E化这么简单。


    3、但是这样的企业软件还不能称作为ERP。因为ERP是企业资源计划。计划是要PDCA的,要管控关键节点、关键产物。所以必须在这样的链条内置PDCA,才是真正意义上的企业资源计划。


    4、但这样做后,还没有洞穿本质。毕竟企业是通过做事而去赚钱的。而我们上述几个步骤都在细研如何做事。但企业经营不是事情做了目的就达到了,不是目的达到了就赚钱了。很多企业员工把事做了,把事当成了目的,以为事做了目的也就顺理达成了。这样的思维是错的。所以需要在流程的每个关键流程节点中要内嵌财务收支预测、管控、核算这条线。


    你看,一条支撑战略行动的打穿业务链条,附上业务管控层的PDCA,再附上财务管控层的PDCA,这才是一个丰满的企业业务建模。


    这样做出来的企业业务模型,才是最体系、结构、完备的业务模型。只有通过这样业务模型而映射出来的企业软件,才是真正有实力的企业软件。


    但话说回来了,随便找一家ERP软件提供商,我看看谁是这么干的?谁能理直气壮的立刻拿出这些东西。我相信很少ERP软件提供商能拿出来。


    ERP软件商也是企业,只要是企业,就能应用企业资源计划,就得需要战略管控、业务管控、财务管控。所以我说企业资源规划ERP不是MRP的一个扩展。所以我也老说哪个ERP软件商自己不用ERP,就是耍流氓。如果一个ERP软件商自己的战略管控、业务管控、财务管控都没有章法没有方法,那它做出来的ERP软件也一定是没有方法的。也就是说,大部分ERP都是假ERP,其实只是按照我说的第一层:组织流程法来机械映射的。所以只要企业组织、业务流程一变化,这套ERP就不适合用了。核心原因就在于此。


    二、企业软件的组件为啥不能模块化?


    这个问题的核心是企业业务流程是链条状的,而模块化的本质是独立封闭解耦的。链条和独立,这就形成了天然的阻抗。


    分分合合,关键就在于先解耦,然后怎么串起来。这样就既独立又联合,又有珍珠又有项链。但要想把珍珠串成项链,需要每颗珍珠有窟窿眼。在软件领域中这被称为接口。


    企业有很多的部门,这都是人为划分的。部门可以不断组合拆分。企业也有许多的岗位,每个岗位也有职责,但这些岗位以及岗位的职责都是人为划分的。都可以根据企业变化不断拆分。而企业对外提供的服务相对比较固定,一般增加的服务也是现有服务的一个上下游延展,不太容易能出现一个全新的服务。因为能提供什么服务,这和企业的能力有关。除非企业新增加新的业务线,外招或培养新的能力、新的岗位,以提供新的服务。


    这样来看,按组织流程法、按战略行动法梳理得来的业务模型,想映射成软件,还不容易模块化。只有从企业对外提供的服务,从外向内来梳理,得出的业务接口才是相对比较稳定的,再经过技术架构接口设计,那么接口也就容易形成可扩展、向下兼容性的接口。


    这种梳理方法,从咱们业务模型梳理方法来看,属于以客户为起端的打穿业务链条方法。这比企业战略行动从上到下梳理的方法还要稳固。因为中国内外环境多变,中国企业主又尤其爱超车,所以企业的战略也往往连年变化、重点各有不同。而从客户角度发起业务链条打穿,客户是一切的根,是企业的衣食父母,客户的满意和贴近才是正道。所以,我比较推崇这种方法,先做好客户关系管理。客户关系管理是一个体系、一个战略,以此细化有客户细分、客户体验流程再造等。但往往很多企业其实并不了解他自己的客户。说来别笑,真是这样,看似天天销售、服务跑客户,其实是在跑单子,对客户的关键人需求、产品使用情况和不满意地方并不了解。所以说,要做客户细分、客户体验流程再造,首先去了解你自己的客户。


    为什么讲模块化,就又讲起了业务模型梳理方法又讲起了客户关系管理?其实质就是试图找到一个相对稳定的描述企业业务模型的方法。只有在相对稳定的企业业务模型之上梳理的接口才是相对稳定的。


    有了稳定的模型和清晰的接口,模块化就容易形成既独立封闭,又相互关联。但这还并不足以解决企业业务流程的流状性和模块独立性的天然阻抗。


    我们知道,企业软件往往是通过一些状态值来控制模块和模块之间的关联,数据和数据之间的关联。在咱们社会有红绿灯,三种状态,但在企业状态中往往有更多的状态。这就不能用咱们开关这种简单的方法来控制。虽然在IT界提供了企业服务总线进行服务之间的连接、数据之间的传递、消息之间的传递,但毕竟它只是提供了一个技术实现方法,到了具体的业务模块之间的流转,还需要我们画出状态图。


    但每个流程节点都可能有N种状态,这么多节点,这么多状态,之间的互相影响关系是什么,状态复杂了,就会遗漏影响关系。这就类似牵一发动全身。所以现在又有一些算法专门用于校验状态机相互依赖性。这在一些RPG和即时战略游戏中常用。所以这也是我研究这些游戏机制的原因。


    只有这样设计出的软件,才能真正模块化。
    展开全文
  • 运维标准化

    万次阅读 2016-09-28 15:08:03
    由于自己一直是做应用运维的,所以今天主要是和大家讲应用...第三部分:给案例讲讲运维能做什么? 第一部分:应用运维是什么 其实很多时候非运维的人员不知道运维是什么,他们都理解你们是


    由于自己一直是做应用运维的,所以今天主要是和大家讲应用运维相关的,我个人总结了一些体系和方法论,希望能对你们有帮助。



    第一部分:我讲应用运维是什么;

    第二部分:我讲应用运维需要什么样的团队;

    第三部分:给个案例讲讲运维能做什么?



    第一部分:应用运维是什么


    其实很多时候非运维的人员不知道运维是什么,他们都理解你们是网管、提供服务器的,处理故障的,其实这些都不是。


    恰好Blues提议我去产品经理社区讲讲运维,那么我要把运维和他们讲清楚,我就不断在想运维是什么?



    对于我来说,运维就是技术运营,和产品运营差不多。



    对于用户的需求,一方面有实际的产品实现服务交付,另一个方面需要技术去支撑产品,无论是客户端还是服务端、无论是网络还是服务器,涉及的技术很多,因此我觉得对于运维来说,如何把你维护的技术栈运营好是非常重要的。而把产品和技术拉到同一个点上的就是用户价值。那什么是用户价值呢?





    我把客户的价值是获取服务需要一定的成本之上,所获得的服务能力。这个里面有产品提供的功能能力(产品指标)、获取的可用性(运维指标)、体验(产品+运维指标)和成本(产品+运维指标)。


    其实这个思路确定之后,会影响我们后续很多应用的方法论以及团队之间合作的感觉。我们运维和产品、技术等等都是服务于用户,最终的价值点都是用户的,这样把我们的合作点都拉到了相同的对象上来了。



    接下来我讲我整个应用运维的方法论。我把它理解成几部分,

    第一:运维整体的原则;



    我很多时候都看这个,一定是价值导向。前面讲了用户的价值导向,我们技术运营的好,就是让用户使用我们的产品很爽。


    涉及这么多的技术栈靠人肉一定是没法运营好的,这个时候必须要平台支撑,我把平台分成两部分,一部分是自动化平台(实现价值交付),一部分是数据化平台(实现价值衡量)。


    服务透明,分成两部分,一部分是离线服务,一部分是在线服务。离线服务比如说运维服务器资源提供,运维扩容能力,甚至是ITIL的服务等等,这些服务能力一定要对研发和业务部门透明。千万别设置很多的表格来让研发或者产品理解。


    在线服务的透明,我其实讲得更多的是服务公共化能力,打造公共化的服务平台。原生memcache、mysql都是组件,而不是服务。而需要在此基础上让他们具备可运维性,一个重要衡量基准就是透明性。



    最后一定要数据来驱动,别动不动跑到研发那边说,你这个不好那个不好,拿一些数据出来,告诉他们那个地方不好,包括我们自己哪儿不好,其实这个和服务部分也有些关联。我们的数据驱动可以驱动我们内部的服务优化,另外一个就是驱动线上的服务优化了。



    用户价值已经说了,接下来说说平台。


    在很多运维人的眼里,ITIL就是运维的平台,而我说不是,我很多观点都在讲去ITIL化,去ITIL到底要去什么呢。




    一个是去流程化的意识,一个是去服务化的意识。



    在一个故障发生的时候,不要埋怨人做错了什么,我是不是可以通过流程或者加入什么审核机制来规避掉,那是传统的做法,不建议。建议找技术驱动优化的方法,待会儿后面有个案例会说这个观点。



    去服务化,是因为现在的运维服务范畴已经大大的发生了变化,这个服务的边界已经拓展了很多。最低级的如果你还按照服务某个研发或者业务的方式去做运维的,最后运维是没有出路的。高级一点,我把ITIL里面涉及到的一一几个流程做成产品,封装服务,其实你会发现很多服务在互联网化下已经发生变化了。


    因此我自己把运维平台做了一个总结,我觉得可以适用大部分团队。



    (注意这个图中写了“此服务非彼服务”,这个服务是将的一种动态能力,而ITIL服务讲的是一种静态能力。)


    里面你可以理解有几个部分,基础架构及服务(IAAS及私有IT设施),配置及服务(CMDB)、架构及服务(公共服务能力那块)、数据及服务、监控及服务、持续集成服务、适当的考虑一下ITIL那块服务能力的封装,比如说事件。问题管理就不需要了,做了这么多家,从来没有去实现问题管理,发现也没什么问题。


    架构及服务,我后面在运维路径里面再讲一下。数据及服务,我把技术数据的本质理解成指标和事件数据,运维应该有能力去采集这些数据,然后分析、在此基础上进行告警。甚至我觉得监控是数据服务上一个场景,因为对于很多用户来说,监控的维度非常复杂,其实想传统的nagios和zabbix完全不能满足这种柔性。



    刚刚讲了整体的原则。接下来我把应用运维三部曲,做应用运维都是在这个路径上去走。





    第一步做标准化,第二步做公共服务化,第三步做服务去状态化。


    这个我之前写过一篇文章,里面详细介绍了每部分的内容,这个地方再简单的和大家过一下。



    一定不要忽略标准化的价值,当你从底向上把运维标准化做好了,你以后的运维成本会大大的降低,比如说自动化,甚至是服务发现等等。我之前把标准化分成:服务器的、OS的、机房部署的、应用环境的等等。这个里面发挥一下想象力,能标准化就标准化,小到一个进程的属主和路径,达到机房甚至是架构选型。特别是架构选型这块,一定不要被开发牵着走,特别是有些研发说性能很高,我希望你们给到的回复是,我多给你几台服务器。



    还有一个标准化很重要的是协议,在YY有一个标准化的YY协议,目前我负责的业务这边都采用http协议,在统一协议之上做一些运维能力封装特别简单,比如说监控、数据采集等等。


    服务化,我刚才说mc、mysql都是组件化能力,不是服务化能力,真正服务化的平台一定是运维友好的,一定是对前端应用是无状态感知的,比如说mysql扩容和迁移等等,都可以做到对APP无感知,这才是服务化能力。


    无状态,等我们所有基础设施都标准化了,这个时候,我们就要去无状态化了,去识别架构中的单点问题,挖掘出来优化他。这个里面有方法论可以遵循,早期腾讯有个海量服务运营之道,大家可以网上找找。


    我这次有个项目优化也遵循了这个原则,收到很好的效果。


    应用运维也有了路径,接下来就是怎么落地了,那么我会在不同的阶段,制定不同的方向,比如说我现在的团队来说,我的方向如下:



    就是做数据化运维、自动化运维和精细化运维。


    紧扣当前阶段的目标,识别当前团队的矛盾点,设定具体的KPI方向,持续以周为单位进行跟踪。


    都会有明确的要求,每周滚动。这个群里面很多我的同事。这个地方的建议,一定不要把扩容变更能力、服务器提供能力作为指标放到你的KPI中。做得不透明和不好是我们的耻辱,做得好是应该的。所以很多时候我说运维是要带着耻辱感去工作,每天我做重复的事情,点按钮,敲命令就该想想什么地方要改进了。



    第一部分什么是应用运维我讲完了,什么是应用运维--》整体的指导原则--》应用运维的实现路径--->运维的工作方向---》最后到运维的KPI持续滚动。




    这是运维团队能力要求,里面有三个部分,业务运维即应用运维、运维研发、运维技术研究。



    我希望大家日常的运维工作,在业务运维这块越少越好,而运维研发和技术研究越多越好。还有一个非常重要的东西,运维工作是什么驱动的,这个代表着不同类型的三种团队。




    问题驱动,救火队员,你天天在救火,有没有感觉每天半夜要起来苦逼,如果是这样的话,一定要去把问题找出来,这个阶段都有,按照我说的三部走一定可以解决。



    事务和需求驱动,我觉得就是一个保姆角色,做内部服务的提供者,研发找我要服务器,我给服务器,找我部署,我去部署,找我做什么我就干什么。最后一个是价值、优化、用户驱动的运维团队,我们需要走出来,把自己的能力放大一下,运维能做的事情很多呢,三部曲里面那么多东西可以做,还有自动化平台建设,还有数据化平台建设。






    个人能力模型,其实这个是腾讯的职级通道体系里面给的,他分成了10个维度对应用运维提出了要求,其实我觉得写得不是很好,忽略了运维研发能力要求和运维规划能力要求。



    特别是T3、T4职级,我觉得一定是从运维研发能力走过来的,只有你做过自动化,你才能对运维的东西进行抽象,其实这个和测试一样,长期做功能测试,你最后都失去了对测试美好愿景的想象,运维也是如此的。


    技术能力希望大家再全栈一点,很多应用运维一个薄弱的环节就是对数据能力的了解。其实我有时候还建议大家去看看Oracle数据库呢,这个能力非常重要。恰恰我觉得应用运维做到最后如果能不了解业务就最好了,做到业务无差异化运维。


    其实运维开始非常苦逼,是吧!但是你把这个事情当成一个挑战来看和对自己的一个不断完美的要求,你会觉得运维是有很多美感的,这个美感我在之前一篇文章里面讲过了。在此就不复述了。



    (图还是要给,强化一下大家对美感的认识)


    这一部分我讲了团队能力要求,驱动模型,个人能力要求和运维美感,不全是苦逼。


    最后一部分我讲一下一个故障看运维的价值。



    说一下家丑,去年12月13号,我们一个核心业务,因为交换机故障,导致我们服务终端45分钟,100%服务不可用,耻辱。


    这个故障暴漏了很多问题,我们有冷备中心用不起来,复盘的时候发现很多架构问题。



    问题真的很多很多,这个地方有个经验,问题是运维最好的老师,特别是线上故障,如果一个故障产生的时候,运维一定要挑头把这个故障进行复盘(腾讯运维的经验),最后你能识别出很多需要改进的地方。



    好吧,问题已经发生了,我们要解决它,领导说了,别跟我说那么多没用的,简单指标,5分钟发现故障、三分钟解决。怎么解决啊,几乎是不可能的任务,不过领导说的,咱们硬着头皮也要挑战一下。不过UC有一个很棒的地方,团队合作特别好,一群优秀的人。我们就成立了一个专项组:把产品、测试、运维、研发、还有项目管理都卷进来了。



    13号出的故障,14号我们复盘了,15号了,我们就成立项目组了。



    简单而极致的要求是我们平时需要不断告诉自己的,最怕的心里状态是这个故障跟我没关系,头都不挑,其次一种怕,就是说技术能力不足,会不会被研发挑战。


    不要怕呢,我们都是为用户服务的。



    其实从这个节奏来说,UC的响应速度非常快。

    我在项目一开始,也确定了一些原则,其中总结起来最核心的就是”技术驱动优化“,而不是流程优化。




    这个里面分成了六个方向:服务降级、双中心、统一调度、过载保护、业务分离、立体化监控。


    为什么需要这些简单的原则?这个有利于项目一致的理解。其实刚刚头条新闻也发生了500错误,从服务影响时间来看,30分钟左右,我猜是后台数据库压力过大导致,在这些原则里面都能找到解决方案,比如说过载保护,服务分离等等。


    这些原则和方向许多都是运维参与的,比如说双中心就涉及到运维参与方案的讨论,给出数据双中心的方案、立体化监控也是80%是运维来做的,统一调度,我们借助了天雷调度(httpdns)。


    然后在这六个方向上我们就制定了具体的改进措施,最终完成了刚才说的5+3目标。



    这个故障其实可以看到运维很多东西可以做的,首先运维一定牵头,第二运维一定要提出自己的要求,第三运维跟进参与整个改进方案的实施,第四,运维要最后给出最终的结果报告,我们做了这么多到底怎么样。




    自己希望的一个愿景吧,没有操作就是好的运维,最后应用运维没有运维就是好的运维。


    其实许多时候不要让大家感受到我们运维,我们运维就是成功了,运维的SAAS化一定是未来的趋势。



    自己也倡导了一些运维理念:





    接下来是问答环节


    1、目前自动化运维这块有什么好的学习建议吗?



    王:我对自动化有分层化的理解,我建议应用运维第一个把持续集成作为重点,其次是把配置管理作为方向(比如说puppet、saltstack)等等。


    持续集成带来的收益非常大,可以把运维从日常繁琐、低价值的任务中释放出来,并且是跨越了研发、测试和运维三个团队,这个里面解放了几个团队的生产力,收益很大。


    但我建议你们持续集成一定以标准化为前提,否则做起来很累。具体的表述见文章:【平台篇】运维自动化平台深度解码



    2、问题类似:技术驱动,那些技术?



    王:这个技术驱动,其实是一些技术的方法论,基于这个方法论,当然你也需要很多的技术储备,无论是存储的、还是应用的,还是协议的,还是程序研发的,甚至是测试的,都需要了解了,全栈。



    3、请问,很多企业把运维细化到分片分区管理,你说的运维理念又很难实施了。



    王:这个应该是传统企业来的吧,这个变革力就看大家的要求了。我的预见是总有一天用户会逼着你做出改变,这种外力比内力推动力更强。



    4、具体的学习路线



    王:如饥似渴的学习和运维相关的一切知识,ITIL、网络的、操作系统、应用组件的.....没有好的学习路线来遵循,把你岗位上做到机制,把周边知识都吸收进来,比如说你从网络上去看应用运维



    5、学习建议



    王:我的建议不要浮于表面做运维,当你遇到一个不懂的问题时候,你要深究到底,然后顺着他就可以打开知识体系了,举两个简单的例子,top命令看到的那些CPU占用的指标,user、sys、idle、io....我以前面试就经常问这个,可惜很多人都不知道。


    如果你能说出来原理,就说明你把知识地图打开了。其次我们经常定位问题用的strace,但你真正的去了解strace原理的时候,里面有很多操作系统的知识涉及到,当年因为strace,我还把操作系统的书重新看了一遍。不放过任何一个细节,总结和思考自己目前正在做的。我觉得其他的东西都好解决了。



    6、请教:运维人如何做绩效考核?东西很难量化,主观意识太强?


    参考:

    由于自己一直是做应用运维的,所以今天主要是和大家讲应用运维相关的,我个人总结了一些体系和方法论,希望能对你们有帮助。



    第一部分:我讲应用运维是什么;

    第二部分:我讲应用运维需要什么样的团队;

    第三部分:给个案例讲讲运维能做什么?



    第一部分:应用运维是什么


    其实很多时候非运维的人员不知道运维是什么,他们都理解你们是网管、提供服务器的,处理故障的,其实这些都不是。


    恰好Blues提议我去产品经理社区讲讲运维,那么我要把运维和他们讲清楚,我就不断在想运维是什么?



    对于我来说,运维就是技术运营,和产品运营差不多。



    对于用户的需求,一方面有实际的产品实现服务交付,另一个方面需要技术去支撑产品,无论是客户端还是服务端、无论是网络还是服务器,涉及的技术很多,因此我觉得对于运维来说,如何把你维护的技术栈运营好是非常重要的。而把产品和技术拉到同一个点上的就是用户价值。那什么是用户价值呢?





    我把客户的价值是获取服务需要一定的成本之上,所获得的服务能力。这个里面有产品提供的功能能力(产品指标)、获取的可用性(运维指标)、体验(产品+运维指标)和成本(产品+运维指标)。


    其实这个思路确定之后,会影响我们后续很多应用的方法论以及团队之间合作的感觉。我们运维和产品、技术等等都是服务于用户,最终的价值点都是用户的,这样把我们的合作点都拉到了相同的对象上来了。



    接下来我讲我整个应用运维的方法论。我把它理解成几部分,

    第一:运维整体的原则;



    我很多时候都看这个,一定是价值导向。前面讲了用户的价值导向,我们技术运营的好,就是让用户使用我们的产品很爽。


    涉及这么多的技术栈靠人肉一定是没法运营好的,这个时候必须要平台支撑,我把平台分成两部分,一部分是自动化平台(实现价值交付),一部分是数据化平台(实现价值衡量)。


    服务透明,分成两部分,一部分是离线服务,一部分是在线服务。离线服务比如说运维服务器资源提供,运维扩容能力,甚至是ITIL的服务等等,这些服务能力一定要对研发和业务部门透明。千万别设置很多的表格来让研发或者产品理解。


    在线服务的透明,我其实讲得更多的是服务公共化能力,打造公共化的服务平台。原生memcache、mysql都是组件,而不是服务。而需要在此基础上让他们具备可运维性,一个重要衡量基准就是透明性。



    最后一定要数据来驱动,别动不动跑到研发那边说,你这个不好那个不好,拿一些数据出来,告诉他们那个地方不好,包括我们自己哪儿不好,其实这个和服务部分也有些关联。我们的数据驱动可以驱动我们内部的服务优化,另外一个就是驱动线上的服务优化了。



    用户价值已经说了,接下来说说平台。


    在很多运维人的眼里,ITIL就是运维的平台,而我说不是,我很多观点都在讲去ITIL化,去ITIL到底要去什么呢。




    一个是去流程化的意识,一个是去服务化的意识。



    在一个故障发生的时候,不要埋怨人做错了什么,我是不是可以通过流程或者加入什么审核机制来规避掉,那是传统的做法,不建议。建议找技术驱动优化的方法,待会儿后面有个案例会说这个观点。



    去服务化,是因为现在的运维服务范畴已经大大的发生了变化,这个服务的边界已经拓展了很多。最低级的如果你还按照服务某个研发或者业务的方式去做运维的,最后运维是没有出路的。高级一点,我把ITIL里面涉及到的一一几个流程做成产品,封装服务,其实你会发现很多服务在互联网化下已经发生变化了。


    因此我自己把运维平台做了一个总结,我觉得可以适用大部分团队。



    (注意这个图中写了“此服务非彼服务”,这个服务是将的一种动态能力,而ITIL服务讲的是一种静态能力。)


    里面你可以理解有几个部分,基础架构及服务(IAAS及私有IT设施),配置及服务(CMDB)、架构及服务(公共服务能力那块)、数据及服务、监控及服务、持续集成服务、适当的考虑一下ITIL那块服务能力的封装,比如说事件。问题管理就不需要了,做了这么多家,从来没有去实现问题管理,发现也没什么问题。


    架构及服务,我后面在运维路径里面再讲一下。数据及服务,我把技术数据的本质理解成指标和事件数据,运维应该有能力去采集这些数据,然后分析、在此基础上进行告警。甚至我觉得监控是数据服务上一个场景,因为对于很多用户来说,监控的维度非常复杂,其实想传统的nagios和zabbix完全不能满足这种柔性。



    刚刚讲了整体的原则。接下来我把应用运维三部曲,做应用运维都是在这个路径上去走。





    第一步做标准化,第二步做公共服务化,第三步做服务去状态化。


    这个我之前写过一篇文章,里面详细介绍了每部分的内容,这个地方再简单的和大家过一下。



    一定不要忽略标准化的价值,当你从底向上把运维标准化做好了,你以后的运维成本会大大的降低,比如说自动化,甚至是服务发现等等。我之前把标准化分成:服务器的、OS的、机房部署的、应用环境的等等。这个里面发挥一下想象力,能标准化就标准化,小到一个进程的属主和路径,达到机房甚至是架构选型。特别是架构选型这块,一定不要被开发牵着走,特别是有些研发说性能很高,我希望你们给到的回复是,我多给你几台服务器。



    还有一个标准化很重要的是协议,在YY有一个标准化的YY协议,目前我负责的业务这边都采用http协议,在统一协议之上做一些运维能力封装特别简单,比如说监控、数据采集等等。


    服务化,我刚才说mc、mysql都是组件化能力,不是服务化能力,真正服务化的平台一定是运维友好的,一定是对前端应用是无状态感知的,比如说mysql扩容和迁移等等,都可以做到对APP无感知,这才是服务化能力。


    无状态,等我们所有基础设施都标准化了,这个时候,我们就要去无状态化了,去识别架构中的单点问题,挖掘出来优化他。这个里面有方法论可以遵循,早期腾讯有个海量服务运营之道,大家可以网上找找。


    我这次有个项目优化也遵循了这个原则,收到很好的效果。


    应用运维也有了路径,接下来就是怎么落地了,那么我会在不同的阶段,制定不同的方向,比如说我现在的团队来说,我的方向如下:



    就是做数据化运维、自动化运维和精细化运维。


    紧扣当前阶段的目标,识别当前团队的矛盾点,设定具体的KPI方向,持续以周为单位进行跟踪。


    都会有明确的要求,每周滚动。这个群里面很多我的同事。这个地方的建议,一定不要把扩容变更能力、服务器提供能力作为指标放到你的KPI中。做得不透明和不好是我们的耻辱,做得好是应该的。所以很多时候我说运维是要带着耻辱感去工作,每天我做重复的事情,点按钮,敲命令就该想想什么地方要改进了。



    第一部分什么是应用运维我讲完了,什么是应用运维--》整体的指导原则--》应用运维的实现路径--->运维的工作方向---》最后到运维的KPI持续滚动。




    这是运维团队能力要求,里面有三个部分,业务运维即应用运维、运维研发、运维技术研究。



    我希望大家日常的运维工作,在业务运维这块越少越好,而运维研发和技术研究越多越好。还有一个非常重要的东西,运维工作是什么驱动的,这个代表着不同类型的三种团队。




    问题驱动,救火队员,你天天在救火,有没有感觉每天半夜要起来苦逼,如果是这样的话,一定要去把问题找出来,这个阶段都有,按照我说的三部走一定可以解决。



    事务和需求驱动,我觉得就是一个保姆角色,做内部服务的提供者,研发找我要服务器,我给服务器,找我部署,我去部署,找我做什么我就干什么。最后一个是价值、优化、用户驱动的运维团队,我们需要走出来,把自己的能力放大一下,运维能做的事情很多呢,三部曲里面那么多东西可以做,还有自动化平台建设,还有数据化平台建设。






    个人能力模型,其实这个是腾讯的职级通道体系里面给的,他分成了10个维度对应用运维提出了要求,其实我觉得写得不是很好,忽略了运维研发能力要求和运维规划能力要求。



    特别是T3、T4职级,我觉得一定是从运维研发能力走过来的,只有你做过自动化,你才能对运维的东西进行抽象,其实这个和测试一样,长期做功能测试,你最后都失去了对测试美好愿景的想象,运维也是如此的。


    技术能力希望大家再全栈一点,很多应用运维一个薄弱的环节就是对数据能力的了解。其实我有时候还建议大家去看看Oracle数据库呢,这个能力非常重要。恰恰我觉得应用运维做到最后如果能不了解业务就最好了,做到业务无差异化运维。


    其实运维开始非常苦逼,是吧!但是你把这个事情当成一个挑战来看和对自己的一个不断完美的要求,你会觉得运维是有很多美感的,这个美感我在之前一篇文章里面讲过了。在此就不复述了。



    (图还是要给,强化一下大家对美感的认识)


    这一部分我讲了团队能力要求,驱动模型,个人能力要求和运维美感,不全是苦逼。


    最后一部分我讲一下一个故障看运维的价值。



    说一下家丑,去年12月13号,我们一个核心业务,因为交换机故障,导致我们服务终端45分钟,100%服务不可用,耻辱。


    这个故障暴漏了很多问题,我们有冷备中心用不起来,复盘的时候发现很多架构问题。



    问题真的很多很多,这个地方有个经验,问题是运维最好的老师,特别是线上故障,如果一个故障产生的时候,运维一定要挑头把这个故障进行复盘(腾讯运维的经验),最后你能识别出很多需要改进的地方。



    好吧,问题已经发生了,我们要解决它,领导说了,别跟我说那么多没用的,简单指标,5分钟发现故障、三分钟解决。怎么解决啊,几乎是不可能的任务,不过领导说的,咱们硬着头皮也要挑战一下。不过UC有一个很棒的地方,团队合作特别好,一群优秀的人。我们就成立了一个专项组:把产品、测试、运维、研发、还有项目管理都卷进来了。



    13号出的故障,14号我们复盘了,15号了,我们就成立项目组了。



    简单而极致的要求是我们平时需要不断告诉自己的,最怕的心里状态是这个故障跟我没关系,头都不挑,其次一种怕,就是说技术能力不足,会不会被研发挑战。


    不要怕呢,我们都是为用户服务的。



    其实从这个节奏来说,UC的响应速度非常快。

    我在项目一开始,也确定了一些原则,其中总结起来最核心的就是”技术驱动优化“,而不是流程优化。




    这个里面分成了六个方向:服务降级、双中心、统一调度、过载保护、业务分离、立体化监控。


    为什么需要这些简单的原则?这个有利于项目一致的理解。其实刚刚头条新闻也发生了500错误,从服务影响时间来看,30分钟左右,我猜是后台数据库压力过大导致,在这些原则里面都能找到解决方案,比如说过载保护,服务分离等等。


    这些原则和方向许多都是运维参与的,比如说双中心就涉及到运维参与方案的讨论,给出数据双中心的方案、立体化监控也是80%是运维来做的,统一调度,我们借助了天雷调度(httpdns)。


    然后在这六个方向上我们就制定了具体的改进措施,最终完成了刚才说的5+3目标。



    这个故障其实可以看到运维很多东西可以做的,首先运维一定牵头,第二运维一定要提出自己的要求,第三运维跟进参与整个改进方案的实施,第四,运维要最后给出最终的结果报告,我们做了这么多到底怎么样。




    自己希望的一个愿景吧,没有操作就是好的运维,最后应用运维没有运维就是好的运维。


    其实许多时候不要让大家感受到我们运维,我们运维就是成功了,运维的SAAS化一定是未来的趋势。



    自己也倡导了一些运维理念:





    接下来是问答环节


    1、目前自动化运维这块有什么好的学习建议吗?



    王:我对自动化有分层化的理解,我建议应用运维第一个把持续集成作为重点,其次是把配置管理作为方向(比如说puppet、saltstack)等等。


    持续集成带来的收益非常大,可以把运维从日常繁琐、低价值的任务中释放出来,并且是跨越了研发、测试和运维三个团队,这个里面解放了几个团队的生产力,收益很大。


    但我建议你们持续集成一定以标准化为前提,否则做起来很累。具体的表述见文章:【平台篇】运维自动化平台深度解码



    2、问题类似:技术驱动,那些技术?



    王:这个技术驱动,其实是一些技术的方法论,基于这个方法论,当然你也需要很多的技术储备,无论是存储的、还是应用的,还是协议的,还是程序研发的,甚至是测试的,都需要了解了,全栈。



    3、请问,很多企业把运维细化到分片分区管理,你说的运维理念又很难实施了。



    王:这个应该是传统企业来的吧,这个变革力就看大家的要求了。我的预见是总有一天用户会逼着你做出改变,这种外力比内力推动力更强。



    4、具体的学习路线



    王:如饥似渴的学习和运维相关的一切知识,ITIL、网络的、操作系统、应用组件的.....没有好的学习路线来遵循,把你岗位上做到机制,把周边知识都吸收进来,比如说你从网络上去看应用运维



    5、学习建议



    王:我的建议不要浮于表面做运维,当你遇到一个不懂的问题时候,你要深究到底,然后顺着他就可以打开知识体系了,举两个简单的例子,top命令看到的那些CPU占用的指标,user、sys、idle、io....我以前面试就经常问这个,可惜很多人都不知道。


    如果你能说出来原理,就说明你把知识地图打开了。其次我们经常定位问题用的strace,但你真正的去了解strace原理的时候,里面有很多操作系统的知识涉及到,当年因为strace,我还把操作系统的书重新看了一遍。不放过任何一个细节,总结和思考自己目前正在做的。我觉得其他的东西都好解决了。



    6、请教:运维人如何做绩效考核?东西很难量化,主观意识太强?



    http://chuansong.me/n/1435258

    由于自己一直是做应用运维的,所以今天主要是和大家讲应用运维相关的,我个人总结了一些体系和方法论,希望能对你们有帮助。



    第一部分:我讲应用运维是什么;

    第二部分:我讲应用运维需要什么样的团队;

    第三部分:给个案例讲讲运维能做什么?



    第一部分:应用运维是什么


    其实很多时候非运维的人员不知道运维是什么,他们都理解你们是网管、提供服务器的,处理故障的,其实这些都不是。


    恰好Blues提议我去产品经理社区讲讲运维,那么我要把运维和他们讲清楚,我就不断在想运维是什么?



    对于我来说,运维就是技术运营,和产品运营差不多。



    对于用户的需求,一方面有实际的产品实现服务交付,另一个方面需要技术去支撑产品,无论是客户端还是服务端、无论是网络还是服务器,涉及的技术很多,因此我觉得对于运维来说,如何把你维护的技术栈运营好是非常重要的。而把产品和技术拉到同一个点上的就是用户价值。那什么是用户价值呢?





    我把客户的价值是获取服务需要一定的成本之上,所获得的服务能力。这个里面有产品提供的功能能力(产品指标)、获取的可用性(运维指标)、体验(产品+运维指标)和成本(产品+运维指标)。


    其实这个思路确定之后,会影响我们后续很多应用的方法论以及团队之间合作的感觉。我们运维和产品、技术等等都是服务于用户,最终的价值点都是用户的,这样把我们的合作点都拉到了相同的对象上来了。



    接下来我讲我整个应用运维的方法论。我把它理解成几部分,

    第一:运维整体的原则;



    我很多时候都看这个,一定是价值导向。前面讲了用户的价值导向,我们技术运营的好,就是让用户使用我们的产品很爽。


    涉及这么多的技术栈靠人肉一定是没法运营好的,这个时候必须要平台支撑,我把平台分成两部分,一部分是自动化平台(实现价值交付),一部分是数据化平台(实现价值衡量)。


    服务透明,分成两部分,一部分是离线服务,一部分是在线服务。离线服务比如说运维服务器资源提供,运维扩容能力,甚至是ITIL的服务等等,这些服务能力一定要对研发和业务部门透明。千万别设置很多的表格来让研发或者产品理解。


    在线服务的透明,我其实讲得更多的是服务公共化能力,打造公共化的服务平台。原生memcache、mysql都是组件,而不是服务。而需要在此基础上让他们具备可运维性,一个重要衡量基准就是透明性。



    最后一定要数据来驱动,别动不动跑到研发那边说,你这个不好那个不好,拿一些数据出来,告诉他们那个地方不好,包括我们自己哪儿不好,其实这个和服务部分也有些关联。我们的数据驱动可以驱动我们内部的服务优化,另外一个就是驱动线上的服务优化了。



    用户价值已经说了,接下来说说平台。


    在很多运维人的眼里,ITIL就是运维的平台,而我说不是,我很多观点都在讲去ITIL化,去ITIL到底要去什么呢。




    一个是去流程化的意识,一个是去服务化的意识。



    在一个故障发生的时候,不要埋怨人做错了什么,我是不是可以通过流程或者加入什么审核机制来规避掉,那是传统的做法,不建议。建议找技术驱动优化的方法,待会儿后面有个案例会说这个观点。



    去服务化,是因为现在的运维服务范畴已经大大的发生了变化,这个服务的边界已经拓展了很多。最低级的如果你还按照服务某个研发或者业务的方式去做运维的,最后运维是没有出路的。高级一点,我把ITIL里面涉及到的一一几个流程做成产品,封装服务,其实你会发现很多服务在互联网化下已经发生变化了。


    因此我自己把运维平台做了一个总结,我觉得可以适用大部分团队。



    (注意这个图中写了“此服务非彼服务”,这个服务是将的一种动态能力,而ITIL服务讲的是一种静态能力。)


    里面你可以理解有几个部分,基础架构及服务(IAAS及私有IT设施),配置及服务(CMDB)、架构及服务(公共服务能力那块)、数据及服务、监控及服务、持续集成服务、适当的考虑一下ITIL那块服务能力的封装,比如说事件。问题管理就不需要了,做了这么多家,从来没有去实现问题管理,发现也没什么问题。


    架构及服务,我后面在运维路径里面再讲一下。数据及服务,我把技术数据的本质理解成指标和事件数据,运维应该有能力去采集这些数据,然后分析、在此基础上进行告警。甚至我觉得监控是数据服务上一个场景,因为对于很多用户来说,监控的维度非常复杂,其实想传统的nagios和zabbix完全不能满足这种柔性。



    刚刚讲了整体的原则。接下来我把应用运维三部曲,做应用运维都是在这个路径上去走。





    第一步做标准化,第二步做公共服务化,第三步做服务去状态化。


    这个我之前写过一篇文章,里面详细介绍了每部分的内容,这个地方再简单的和大家过一下。



    一定不要忽略标准化的价值,当你从底向上把运维标准化做好了,你以后的运维成本会大大的降低,比如说自动化,甚至是服务发现等等。我之前把标准化分成:服务器的、OS的、机房部署的、应用环境的等等。这个里面发挥一下想象力,能标准化就标准化,小到一个进程的属主和路径,达到机房甚至是架构选型。特别是架构选型这块,一定不要被开发牵着走,特别是有些研发说性能很高,我希望你们给到的回复是,我多给你几台服务器。



    还有一个标准化很重要的是协议,在YY有一个标准化的YY协议,目前我负责的业务这边都采用http协议,在统一协议之上做一些运维能力封装特别简单,比如说监控、数据采集等等。


    服务化,我刚才说mc、mysql都是组件化能力,不是服务化能力,真正服务化的平台一定是运维友好的,一定是对前端应用是无状态感知的,比如说mysql扩容和迁移等等,都可以做到对APP无感知,这才是服务化能力。


    无状态,等我们所有基础设施都标准化了,这个时候,我们就要去无状态化了,去识别架构中的单点问题,挖掘出来优化他。这个里面有方法论可以遵循,早期腾讯有个海量服务运营之道,大家可以网上找找。


    我这次有个项目优化也遵循了这个原则,收到很好的效果。


    应用运维也有了路径,接下来就是怎么落地了,那么我会在不同的阶段,制定不同的方向,比如说我现在的团队来说,我的方向如下:



    就是做数据化运维、自动化运维和精细化运维。


    紧扣当前阶段的目标,识别当前团队的矛盾点,设定具体的KPI方向,持续以周为单位进行跟踪。


    都会有明确的要求,每周滚动。这个群里面很多我的同事。这个地方的建议,一定不要把扩容变更能力、服务器提供能力作为指标放到你的KPI中。做得不透明和不好是我们的耻辱,做得好是应该的。所以很多时候我说运维是要带着耻辱感去工作,每天我做重复的事情,点按钮,敲命令就该想想什么地方要改进了。



    第一部分什么是应用运维我讲完了,什么是应用运维--》整体的指导原则--》应用运维的实现路径--->运维的工作方向---》最后到运维的KPI持续滚动。




    这是运维团队能力要求,里面有三个部分,业务运维即应用运维、运维研发、运维技术研究。



    我希望大家日常的运维工作,在业务运维这块越少越好,而运维研发和技术研究越多越好。还有一个非常重要的东西,运维工作是什么驱动的,这个代表着不同类型的三种团队。




    问题驱动,救火队员,你天天在救火,有没有感觉每天半夜要起来苦逼,如果是这样的话,一定要去把问题找出来,这个阶段都有,按照我说的三部走一定可以解决。



    事务和需求驱动,我觉得就是一个保姆角色,做内部服务的提供者,研发找我要服务器,我给服务器,找我部署,我去部署,找我做什么我就干什么。最后一个是价值、优化、用户驱动的运维团队,我们需要走出来,把自己的能力放大一下,运维能做的事情很多呢,三部曲里面那么多东西可以做,还有自动化平台建设,还有数据化平台建设。






    个人能力模型,其实这个是腾讯的职级通道体系里面给的,他分成了10个维度对应用运维提出了要求,其实我觉得写得不是很好,忽略了运维研发能力要求和运维规划能力要求。



    特别是T3、T4职级,我觉得一定是从运维研发能力走过来的,只有你做过自动化,你才能对运维的东西进行抽象,其实这个和测试一样,长期做功能测试,你最后都失去了对测试美好愿景的想象,运维也是如此的。


    技术能力希望大家再全栈一点,很多应用运维一个薄弱的环节就是对数据能力的了解。其实我有时候还建议大家去看看Oracle数据库呢,这个能力非常重要。恰恰我觉得应用运维做到最后如果能不了解业务就最好了,做到业务无差异化运维。


    其实运维开始非常苦逼,是吧!但是你把这个事情当成一个挑战来看和对自己的一个不断完美的要求,你会觉得运维是有很多美感的,这个美感我在之前一篇文章里面讲过了。在此就不复述了。



    (图还是要给,强化一下大家对美感的认识)


    这一部分我讲了团队能力要求,驱动模型,个人能力要求和运维美感,不全是苦逼。


    最后一部分我讲一下一个故障看运维的价值。



    说一下家丑,去年12月13号,我们一个核心业务,因为交换机故障,导致我们服务终端45分钟,100%服务不可用,耻辱。


    这个故障暴漏了很多问题,我们有冷备中心用不起来,复盘的时候发现很多架构问题。



    问题真的很多很多,这个地方有个经验,问题是运维最好的老师,特别是线上故障,如果一个故障产生的时候,运维一定要挑头把这个故障进行复盘(腾讯运维的经验),最后你能识别出很多需要改进的地方。



    好吧,问题已经发生了,我们要解决它,领导说了,别跟我说那么多没用的,简单指标,5分钟发现故障、三分钟解决。怎么解决啊,几乎是不可能的任务,不过领导说的,咱们硬着头皮也要挑战一下。不过UC有一个很棒的地方,团队合作特别好,一群优秀的人。我们就成立了一个专项组:把产品、测试、运维、研发、还有项目管理都卷进来了。



    13号出的故障,14号我们复盘了,15号了,我们就成立项目组了。



    简单而极致的要求是我们平时需要不断告诉自己的,最怕的心里状态是这个故障跟我没关系,头都不挑,其次一种怕,就是说技术能力不足,会不会被研发挑战。


    不要怕呢,我们都是为用户服务的。



    其实从这个节奏来说,UC的响应速度非常快。

    我在项目一开始,也确定了一些原则,其中总结起来最核心的就是”技术驱动优化“,而不是流程优化。




    这个里面分成了六个方向:服务降级、双中心、统一调度、过载保护、业务分离、立体化监控。


    为什么需要这些简单的原则?这个有利于项目一致的理解。其实刚刚头条新闻也发生了500错误,从服务影响时间来看,30分钟左右,我猜是后台数据库压力过大导致,在这些原则里面都能找到解决方案,比如说过载保护,服务分离等等。


    这些原则和方向许多都是运维参与的,比如说双中心就涉及到运维参与方案的讨论,给出数据双中心的方案、立体化监控也是80%是运维来做的,统一调度,我们借助了天雷调度(httpdns)。


    然后在这六个方向上我们就制定了具体的改进措施,最终完成了刚才说的5+3目标。



    这个故障其实可以看到运维很多东西可以做的,首先运维一定牵头,第二运维一定要提出自己的要求,第三运维跟进参与整个改进方案的实施,第四,运维要最后给出最终的结果报告,我们做了这么多到底怎么样。




    自己希望的一个愿景吧,没有操作就是好的运维,最后应用运维没有运维就是好的运维。


    其实许多时候不要让大家感受到我们运维,我们运维就是成功了,运维的SAAS化一定是未来的趋势。



    自己也倡导了一些运维理念:





    接下来是问答环节


    1、目前自动化运维这块有什么好的学习建议吗?



    王:我对自动化有分层化的理解,我建议应用运维第一个把持续集成作为重点,其次是把配置管理作为方向(比如说puppet、saltstack)等等。


    持续集成带来的收益非常大,可以把运维从日常繁琐、低价值的任务中释放出来,并且是跨越了研发、测试和运维三个团队,这个里面解放了几个团队的生产力,收益很大。


    但我建议你们持续集成一定以标准化为前提,否则做起来很累。具体的表述见文章:【平台篇】运维自动化平台深度解码



    2、问题类似:技术驱动,那些技术?



    王:这个技术驱动,其实是一些技术的方法论,基于这个方法论,当然你也需要很多的技术储备,无论是存储的、还是应用的,还是协议的,还是程序研发的,甚至是测试的,都需要了解了,全栈。



    3、请问,很多企业把运维细化到分片分区管理,你说的运维理念又很难实施了。



    王:这个应该是传统企业来的吧,这个变革力就看大家的要求了。我的预见是总有一天用户会逼着你做出改变,这种外力比内力推动力更强。



    4、具体的学习路线



    王:如饥似渴的学习和运维相关的一切知识,ITIL、网络的、操作系统、应用组件的.....没有好的学习路线来遵循,把你岗位上做到机制,把周边知识都吸收进来,比如说你从网络上去看应用运维



    5、学习建议



    王:我的建议不要浮于表面做运维,当你遇到一个不懂的问题时候,你要深究到底,然后顺着他就可以打开知识体系了,举两个简单的例子,top命令看到的那些CPU占用的指标,user、sys、idle、io....我以前面试就经常问这个,可惜很多人都不知道。


    如果你能说出来原理,就说明你把知识地图打开了。其次我们经常定位问题用的strace,但你真正的去了解strace原理的时候,里面有很多操作系统的知识涉及到,当年因为strace,我还把操作系统的书重新看了一遍。不放过任何一个细节,总结和思考自己目前正在做的。我觉得其他的东西都好解决了。



    6、请教:运维人如何做绩效考核?东西很难量化,主观意识太强?


    展开全文
  • 企业数据标准规划、建设和应用

    千次阅读 2016-11-29 10:32:21
    今天我分享的内容,整体包括三个部分:第一部分主要介绍为什么要建标准,建设数据标准带来价值是什么;什么是数据标准,业界数据标准体系架构,数据标准具体表现形式是什么样的,数据标准包含内容有哪些; 第二部分...

    今天我分享的内容,整体包括三个部分:

    第一部分主要介绍为什么要建标准,建设数据标准带来价值是什么;什么是数据标准,业界数据标准体系架构,数据标准具体表现形式是什么样的,数据标准包含内容有哪些;
    
    第二部分结合我们数据标准实施经验,介绍标准如何建立、落地、维护的整个流程;并介绍几个标准落地的几个关键点;
    
    第三部分给出了一个案例,描述典型的数据标准实施路径,供参考。
    

    一、企业数据建设现状

    图片描述

    长久以来,大多数的系统都是在某些业务需求的基础上建立,没有考虑与其他系统的功能重复和数据重复,数据一致性和可用性的矛盾突出。由于缺乏这种对数据整体设计考虑,造成多种数据问题:

    数据需求缺乏规范,造成数据对象多份存储,存储结构各异,严重影响数据共享。
    

    例如:某金融公司客户信息存在于财务和产品两个系统中,由于建设时期和团队不同,其中对客户代码长度的定义不一致,财务系统中定义为4位,产品系统中定义为6位,导致同样的数据要素在财务系统和客户系统中标准不一致,造成同一客户财务和产品信息不能很好打通。

    数据标准依据各异,造成统计口径无法匹配。
    

    例如:某金融公司原有系统,业务类型采用业界标准包括资产收购与经营、投资、融资顾问等;由于公司发展,开展了新的业务,因此后来的系统中采用公司新标准,出现了商业收购、阶段性投融资等业务类型。结果新旧系统在业务类型上不一致,业务人员要人为的做关联。

    业务口径不统一,造成沟通困难,发生歧义。
    

    例如:某业务部门,需要财务部门提供一份月报表,由于对“余额”一词有不同的理解,一个认为是“期初余额”,而另一个认为是“期末余额”,造成统计结果大相径庭。经过多次沟通,才达到满意效果。

    数据缺乏标准造成的问题还有很多,总的来说,需要从数据对象、代码、业务指标等多方面实现标准化,才能从根本上减少这些数据问题。那数据标准能给我们带来什么?

    图片描述

    标准可以在业务、技术、管理多个方面给我们提供支撑。

    业务方面:

    提升业务规范性
    

    通过标准可以明确很多数据业务含义,使得不同业务部门之间,以及业务与技术之间沟通更加通畅,避免歧义。

    例如通过客户数据标准,我们在讲客户的时候,大家理解的是一致的,只有办了银行卡的人,才是银行客户。而不会再有认为在网站注册、或者通过本行转账的人都是客户的理解。

    提升数据对业务分析支持度
    

    通过数据标准,可以明确的把某个数据主题(例如客户)信息分为多类,例如基本信息、联系信息、财务信息等,为多维度分析和深度挖掘提供依据。

    通过数据标准,实现数据信息统一一致,使得数据更容易在各业务部门之间流转。
    

    技术方面:

    首先,相同结构的数据,才更容易实现共享和交换;因此公司内部标准促进数据在企业内部流转,行业标准促进数据在企业之间流转;
    
    其次,相同的数据标准,减少大量的转换、清洗工作,极大的提升数据处理效率;数据处理过程中也会减少出差几率,提升问题质量。
    

    管理方面:

    数据标准更多的是能提供完整、及时、准确、高质量的数据,为决策支持、精细化管理等提供支撑。
    

    那么,到底什么是数据标准呢?

    图片描述

    一般我们直观认为数据标准就是几个文档,描述了一些规范和要求,需要大家去遵守。

    更严谨一点定义,数据标准是为了使企业内外部使用和交换的数据是一致和准确的,经协商一致制定并由相关主管机构批准,共同使用和重复使用的一种规范性文件。

    而我们认为数据标准又不仅仅是一套规范,而是一套由管理规范、管控流程、技术工具共同组成的体系,是通过这套体系逐步实现信息标准化的过程。数据标准化是通过一整套的数据规范、管控流程和技术工具来确保的各种重要信息,例如产品、客户、机构、账户等在全公司内外的使用和交换都是一致、准确的过程。

    另外,数据标准也不仅仅是技术或者业务一个部门的事情,它是在数据层面上对重要业务主题的统一规范,也是业务规范在数据层面上的实现。数据标准实施依赖于业务部门之间的共识,以及业务和技术之间的配合。

    那么业界常用的数据标准体系是什么样的呢?标准长什么样,包含哪些内容?下面我会对数据标准的分类和参考体系、内容和形式做一下简单介绍,可以做一个直观的理解。

    图片描述

    首先,数据标准根据不同的数据域分为基础、分析类和专有类三类

    基础类数标是企业日常业务开展过程中所产生的具有共同业务特征的基础性数据,如客户、产品、财务等;
    
    分析类数标是为满足公司内部管理需要及外部监管要求,在基础性数据基础上按一定统计、分析规则加工后的数据;
    
    专有类数标是公司架构下子公司在业务经营及管理分析中所涉及的特有数据。
    

    其中,针对基础类数标,可以看一下金融行业经常用的数据标准十大主题模型。该模型是以主题组织数据,包括客户、资产、机构、产品等主题。

    那么针对某个数据主题,数据标准到底由那几部分组成呢?

    图片描述

    一般数据标准会包括:主题定义、信息项、标准代码三个文档,其中:

    标准主题定义文档:主要是记录数据标准的定义、分类,用于规范和识别数据的主题归属;
    
    标准信息项文档:记录数据主题的信息项业务属性(分类、业务含义、业务逻辑)和技术属性(类型、长度、默认规则);
    
    标准代码文档:记录信息项固定码值的编码、分类、使用规则等。
    

    信息项文档是数据标准的核心。内容包括分类、业务描述和技术描述,一般由信息大类、信息小类、信息项、信息项描述、信息类别、长度共6项组成。当然这些内容也可以调整,例如信息大类、小类,可以合并,或者拆除更多层级。

    信息大、小类是对信息项的常规分类,例如:例如客户信息大类包括基本信息、联系信息、关联信息、财务信息、风险信息、评价信息、往来信息七大类;信息小类,包括:客户编号、名称、证件、地址、评级信息、模型评分、等级、开办业务等;

    信息项是用来描述一个事物的最基本元素。表示一个事物的识别、限制、数量、分类、状态,或者事物间的关系,例如客户信息的名称、年龄、性别等;

    信息项描述是描写或者规范信息项的具体业务描述及界定;

    信息类别是根据业务需求,定义相应的信息项在数据库中所需要的技术格式。例如:编号、标志、代码、金额、日期、数值、文本等;

    长度是信息项的数据长度,供各系统建设参考使用。

    二、如何建设数据标准

    图片描述

    一般数据包标准包括制定、落地、维护等过程。其中制定过程包括规划、调研、设计;落地过程通过映射、标准执行等实现;维护过程保证了数据标准的持续更新。

    1、首先,在标准制定过程中的第一个阶段,标准规划阶段,要根据业界经验和企业实际情况确定实施范围,并根据优先级和难易度制定计划。

    例如,在金融行业,以金融行业十大主题为依据开展,通过业务了解,确定产品、客户、财务等几个主题是关键主题,其他主题业务关联性很弱;因此,确定实施范围,并根据紧迫度、资金等因此确定了实施计划,分多期建立。
    

    2、接下来,在调研阶段,通过制定调查问卷、安排现场访谈、收集文档资料等手段,针对各个业务系统以及应用系统进行调研,了解跟标准相关的内容,包括现有定义、使用习惯、数据分布、数据流向、业务规则、服务部门等,形成调研报告,分析问题,并讨论解决方案。

    实施过程中,如果多个部门不清楚项目意义和项目目标,首先需要对各部门做项目宣讲,让他们有充分了解。
    
    然后,通过调研问卷方式进行初步了解沟通,同期开始大批量研究企业现有的文档了解业务和数据集。
    
    最后,通过当面访谈深入了解信息,并讨论问题与解决方案。最终通过开评审会方式确定解决方案,并给出分析报告。
    

    3、有了素材,接下来就是开始标准设计工作。

    在这个阶段主要是在方法论指导下,完成数据标准设计和定义工作,包括数据业务描述定义(业务属性)、类型长度定义(技术属性)、其他标准信息定义。
    
    设计出定义与分类、信息项、标准码等文档,并通过各部门的评审验证。最终达成一致,形成企业级标准。
    

    到此,标准制定工作完毕。

    4、接下来主要是标准如何落地工作。把已定义的数据标准与业务系统、业务应用进行映射,标明标准和现状的关系以及可能影响到的应用。

    标准落地一般通过两种方式:
    
    1)新系统建设,直接参考数据标准;
    
    2)旧系统通过标准映射,实现数据关系转换,以及指导后续数据平台建设。
    

    5、做完数据标准映射,接下了就是标准落地执行。

    这个过程一般需要借助专业的工具实现标准落地检查。标准执行一般有两个过程
    
    1)第一步分析出来现有问题,例如数据缺失、数据不一致等;
    
    2)第二步修正,例如补录数据、修改系统、新建系统等。
    
    通过这些措施,逐步规范数据建设过程,实现数据标准的落地。
    

    6、数据标准也不是一成不变的,随着业务发展,有些标准需要不断的修订和完善。因此数据标准还有一个关键的管理环节,那就是需要能持续维护改进。

    在数据标准维护阶段,需要有相应的需求收集、需求评审、变更评审、发布等多个步骤,并能对所有的修订做版本管理,以方便将来问题查找。
    

    以上讲了数据标准管理的全过程,接下来我对数据标准落地的几个关键点做一个简单介绍。

    图片描述

    第一条关键点:数据标准应该只管理核心数据定义

    首先,标准不是模型,标准是可落地的核心元素。
    
    企业实际数据模型中有上万个字段,有些模型还会经常变换更新,如果把这些信息全部纳入到标准体系中,并且和数据标准建立映射,管理起来非常困难,很难真正实现落地。
    
    因此要实现数据标准落地,不能一味追求大而全,更多的是应该关注在众多数据中挑选出的核心数据,只管理这些核心数据定义,依照核心数据建立标准,就可以实现企业数据治理的目标,还能提升数据治理的效率。 
    
    其次,针对核心数据标准主题选择要多维度考虑。
    
    数据标准只会关注跟业务关联度高的,能够促进业务的规范管理的数据。因此,数据标准制定,选择标准主题很重要。
    
    在这里,我们通过业务影响度、系统关联度和可实施性等三个方面对各主题做分析,获取各数据主题建设的重要、紧迫程度。
    
    其中,
    
    1、针对业务影响度,可以通过组织集中讲解、面谈解答以及调查问卷等多种调研活动;获得主题涉及的问题数量、问题影响业务数量、问题影响业务的重要性;
    
    2、应用系统关联度,可以通过分析各部门关注次数、各系统和系统模块使用次数;并通过对应用系统功能梳理,提炼相关实体;以及对相关实体,进行数据主题归结,形成主题在系统中的分布情况;
    
    3、可实施分析,可以通过产品手册、各业务部门体系文件,获得主题定义和分类,以及信息项情况;分析获得数据差异性;获得数据定义不一致程度、业务规则整合难度。
    

    通过分析,每个主题关系的业务系统数量不同,业务关注程度也不同,可实施程度不同(差异量,技术等),最终形成主题选择分析图表。在这里每一个度量维度都有加权,通过评分确定实施优先级,例如其中评分在满分的50%以上的,作为本期实施的依据,最终选定实施范围。例如上面的产品、财务、机构、客户四个主题。

    图片描述

    第二条关键点:数据标准要包括技术与业务两种属性

    1、数据标准主要是针对业务,企业很多业务的语义十分依赖业务人员的人工梳理,难度大效率低,很可能出现因为梳理人员没有及时梳理,而造成业务语义难以被及时发现和管理的问题。

    未来企业将会面临数字化转型,从非结构化的文档中,将大部分业务语义抽取出来,并统一管理,成为未来的发展趋势,这种能力可以通过自然语言分析技术来实现,企业可以通过综合多个材料中对同一业务的描述,分析出最新与最广泛认可的业务定义,由业务人员确认之后,识别出业务语义,这样大大减少了业务人员的工作量,提升了业务人员梳理业务语义的积极性。

    2、在企业数据治理中,任何一个数据标准,如果没有对应的技术手段,都将难以落地,所以企业建立数据标准时,需要加入信息项的英文名称,来和实际数据库表中的字段相对应。

    在数据标准中加入信息项的英文名称能给企业数据治理带来两方面的好处:

    在做模型设计的时候,标准可以直接与模型设计工具集成,设计模型时就可以直接引用标准。
    
    对已有系统,标准能够通过英文名称直接和应用系统的相关字段对应,自动发现与不符合标准的字段,并通过元数据直接通知给相应的系统。
    

    3、标准中有了技术和业务信息,还需要有效的关联才能发挥效用。对于企业数据管理来说,技术能弄懂业务的前提是技术与业务之间要有对应,这种对应不能靠大量的人工梳理完成,否则业务部门负担很重,积极性不高。需要能够通过技术手段,利用数据治理工具提供商的行业实践积累,形成业务与技术的自动关联库,自动完成业务与技术对应,将能大大减少业务人员的工作量,同时提升技术与业务关联的准确度,消除业务与技术之间的鸿沟。

    图片描述

    第三条关键点:数据标准要持续更新

    对于企业数据治理来说,有很多数据标准建立以后,往往只是一套书,没有根据企业业务发展及时做出更新,时间长了就成为了摆设,实际上,数据标准是需要随着企业的业务变化而不断进行修订的,比如在企业拓展新业务的时候,需要增加相应的标准进去,对于没有价值的标准,也要及时废弃。只有这样,才能保证数据标准一直能适应业务发展需要,促进标准落地。

    三、数据标准实施案例

    图片描述

    一般企业数据标准建设完,只停留在册子和书本上,缺乏落地手段,不能有效执行;另外,针对数据标准本身缺乏管理,不能有效适应新业务发展。

    某银行数据管理建设思路侧重于事前预防,将各领域数据管理的要求融入到系统研发当中,从需求编写和需求分析等数据产生源头进行管理。严格按照数据标准进行需求编写,结合数据质量管理、元数据管理串联整个软件生命周期。同时在这个过程中,不断的验证和修订数据标准,使得数据标准一直能够适应新业务的发展需要。

    通过项目实施:

    借助技术手段实现了数据标准的实施落地。在需求、开发、上线等各阶段都会有数标检查,实现全生命周期数据管控;
    
    通过系统管理,推进了数标的持续更新,保持了数据标准生命力。
    

    普元云计算专区:http://primeton.csdn.net/m/zone/primeton/index#

    普元公众号:

    图片描述

    展开全文
  • 从零搭建一自动运维体系

    万次阅读 多人点赞 2018-03-23 00:00:00
    作者简介:胥峰,著有畅销书《Linux运维最佳实践》、译著《DevOps:软件架构师行动指南》,资深运维专家,有 11 年...对自动运维体系的需求,是随着业务的增长、对运维效率和质量的要求不断提高而产生的。前言:在很
        

    640?wxfrom=5&wx_lazy=1

    640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

    作者简介:

    640?wx_fmt=png&wxfrom=5&wx_lazy=1

    胥峰,著有畅销书《Linux运维最佳实践》、译著《DevOps:软件架构师行动指南》,资深运维专家,有 11 年运维经验,在业界颇具威望和影响力。2006 年毕业于南京大学,曾就职于盛大游戏等大型知名互联网公司,现就职于Garena Singapore 。拥有工信部认证高级信息系统项目管理师资格。

    对自动化运维体系的需求,是随着业务的增长、对运维效率和质量的要求不断提高而产生的。

    前言:

    在很多初创公司和中小型企业里,运维还停留在“刀耕火种”的原始状态,这里所说的“刀”和“火”就是运维人员的远程客户端,例如SecureCRT和Windows远程桌面。

    在这种工作方式下,服务器的安装、初始化,软件部署、服务发布和监控都是通过手动方式来完成的,需要运维人员登录到服务器上,一台一台去管理和维护。这种非并发的线性工作方式是制约效率的最大障碍。

    同时,因为手动的操作方式过于依赖运维人员的执行顺序和操作步骤,稍有不慎即可能导致服务器配置不一致,也就是同一组服务器的配置上出现差异。有时候,这种差异是很难直接检查出来的,例如在一个负载均衡组里面个别服务器的异常就很难发现。

    随着业务的发展,服务器数量越来越多,运维人员开始转向使用脚本和批量管理工具。脚本和批量管理工具与“刀耕火种”的工作方式相比,确实提升了效率和工程质量。

    但这个方式仍然有很多问题。

    • 第一是脚本的非标准化的问题。不同运维人员写的脚本在所用的编程语言、编码风格和健壮性方面存在巨大差异,同时这些脚本的版本管理也是一个挑战。

    • 第二是脚本的传承问题,人员的离职和工作交接,都会导致脚本无法很好地在运维人员之间传承和再利用,因为下一个运维人员可能无法理解和修改前一个运维人员编写的脚本功能。

    • 第三是批量管理工具的选择。不同的管理人员选择不同的批量管理工具必然会带来管理混乱的问题,也无法很好地实现在运维人员之间互相备份工作的需求。

    因此,对构建自动化运维体系的要求变得越来越迫切。通过自动化运维体系来实现标准化和提高工程效率,是唯一正确的选择。那么如何建设自动化运维体系呢?

    本案例研究分为三个大的方面:

    • 第一个是为什么要建设自动化运维体系,就是解决“3W”中的Why和What的问题,即为什么和是什么。

    • 第二个是介绍我司各个运维子系统是怎样设计、运行和处理问题的,解决“3W”中的How的问题,也就是怎样去做的。

    • 第三个是对我司在自动化运维过程中遇到的一些问题的思考,做一个总结。

    一、建设自动化运维体系的原因

    先来看一下我们为什么要建设一个自动化运维体系。首先来看运维遇到的一些挑战,如下图所示。

    640?wx_fmt=png

    运维面对的挑战

    第一个是游戏的需求。它表现为三个方面:

    • 一是游戏数量多,我司现在运营的游戏多达近百款。

    • 二是游戏架构复杂。游戏公司和一般的互联网公司有一个很大的区别,就是游戏的来源可能有很多,比如有国外的、国内的,有大厂商的、小厂商的;每个游戏的架构可能不一样,有的是分区制的,有的是集中制的,各种各样的需求。

    • 三是操作系统种类多,这与刚才的情况类似,游戏开发者的背景与编程喜好不一样,会有Windows、Linux等。

    第二个是在硬件环境方面,主要表现为服务器数量多、服务器型号多。因为公司从建立到现在有十几年的时间了,在这个过程中分批、分期采购的服务器几乎横跨各大OEM厂商的各大产品线,型号多而杂。

    最后是人的因素。我们在建设自动化运维体系过程中,有一个比较重要的考虑点是人的因素。如果大家的技术能力都很强,很多时候一个人可以完成所有工作,可能也就不需要自动化运维体系了。正是因为每个运维人员的能力不一样,技术水平参差不齐,甚至是运维习惯和工具也不一样,导致我们必须要创建一套规范的自动化运维体系,来提升工作效率。

    二、建设自动化运维体系的目标

    再看一下建设这套自动化运维体系的目标,也就是说我们的原则是什么?笔者将自动化运维体系的建设目标总结为四个词。

    • 第一个是“完备”,这个系统要能涵盖所有的运维需求。

    • 第二个是“简洁”,简单好用。如果系统的操作流程、操作界面、设计思想都比较复杂,运维人员的学习成本就会很高,使用的效果是会打折扣的,系统的能力、发挥的效率也会因此打折扣。

    • 第三个是“高效”,特别是在批量处理或者执行特定任务时,我们希望系统能够及时给用户反馈。

    • 第四个是“安全”,如果一个系统不安全,可能导致很快就被黑客接管了。所以安全也是重要的因素。

    三、自动化运维体系的结构和运作方式

    下图所示是我司当前自动化运维体系的几个子系统,我们来看一看它们是怎样联合起来工作的。首先服务器会经由自动化安装系统完成安装,然后会被自动化运维平台接管。自动化运维平台会对自动化安检系统、自动化客户端更新系统和服务器端更新系统提供底层支撑。自动化数据分析系统和自动化客户端更新系统会有关联关系。自动化数据分析系统会对自动化客户端更新系统的结果给予反馈。

    640?wx_fmt=png

    自动化运维体系结构图

    下面我们来看一下每个子系统是如何设计和工作的。

    3.1、自动化安装系统

    说到自动化安装,大家可能并不陌生,我们刚才说到挑战是“两多两少”,型号多、操作系统多,但是人少,可用时间也比较少。

    如下图所示,整个流程采用通用的框架,首先由PXE启动,选择需要安装的操作系统类型(安装Windows或者Linux),然后根据Windows系统自动识别出需要安装的驱动。服务器交付用户之前,会进行基本的安全设置,例如防火墙设置以及关闭Windows共享,这在一定程度上提高了安全性,也减少了需要人工做的一些操作。

    640?wx_fmt=png

    自动化安装流程图

    3.2、自动化运维平台

    当服务器由自动化安装系统安装完成以后,就会被自动化运维平台接管。自动化运维平台是运维人员的作业平台,它主要解决的问题就是因服务器、操作系统异构而且数量特别多而带来的管理问题。操作系统是五花八门的,我们在设计系统过程中考虑了以下几个因素:

    • 把整个系统的用户界面设计成基于浏览器的架构。运维工程师无论何时何地都可以登录管理系统进行运维操作,这样的话就比较方便。由Octopod服务器对被操作的机器发布指令。

    • 统一管理异构服务器。大家以前可能对Windows深恶痛绝,其实Windows也可以管得很好。我们使用开源的SSH方式管理Windows,这样就可以对系统进行批量的补丁更新,还可以做批量的密码管理和操作。

    • 充分利用现有协议和工具。这个平台的特点是所有的系统使用SSH管理,而不是自己开发一些Agent,这也体现了自动化运维的观点。很多时候我们没必要重新造轮子,即使自己造出一套客户端的方法,大部分时候也并没有在生产环境里得到严格的验证。而SSH协议本身已经存在很多年了,而且已经在我司使用了很多年,该出的问题已经出了,相对于造轮子,使用SSH更加稳定,更经得起考验,使用起来更方便。

    3.3、自动化安检系统

    下一个系统是自动化安检系统。由于我们的子系统比较多,业务也比较多,怎样设计一套系统去保障它们的安全呢?这里主要是两个系统:自动化安检平台和服务器端。

    • 先来看自动化安检平台。游戏公司和一般的互联网公司有一个区别,就是前者需要给玩家发送很多的客户端(特别是有的客户端比较大),或者补丁文件,去更新、下载和安装。如果这些文件里面出现病毒和木马,将是一件很糟糕的事情,甚至会对业务和公司的声誉造成恶劣影响。当这些文件被发到玩家电脑上之前,必须经过病毒检测系统检测,确保它没有被注入相应的病毒代码。

    • 再来看服务器端,主要是通过安全扫描架构来保障安全。安全并不是一蹴而就,一劳永逸的。如果不对系统持续地检查、检测、探测,那么你的一些误操作会导致系统暴露在互联网上,或者是暴露在恶意攻击者的眼皮之下。通过一种主动、自发的安全扫描架构对所有服务器进行安全扫描,就能在很大程度上规避这样的问题。举一个例子,去年我们遇到过一个情况,某款交换机ACL达到一定的数量的时候,就完全失效了。如果没有相关的配套机制去检查和检测,那么你的服务器、你认为保护得很好的端口或者是敏感的IP可能已经暴露。所以,通过这种主动的探测可以减少很多系统的或者是人为的安全问题。

    3.4、自动化客户端更新系统

    游戏是有周期性的,特别是在游戏发布当天或者有版本更新的时候,这时候玩家活跃度很高,下载行为也是比较多的,但是平时的更新和下载带宽可能并不大,这也是游戏很显著的特点。这个特点对于我们构建这样一个分发系统提出了很大的挑战。第一个挑战就是在高峰时游戏产生的带宽可能达到数百GB。第二是很多小运营商或者中小规模的运营商会有一些缓存机制,这个缓存机制如果处理得不好,会对业务造成影响,也就是非法缓存的问题。第三是关于DNS调度的问题。DNS调度本身是基于玩家本身的Local DNS的机制解析的,会有调度不准确的问题。第四是DNS污染,或者是DNS TTL的机制导致调度不那么灵敏和准确。针对这些问题,我们有下面两套系统来解决。

    第一套是Autopatch系统,它解决的是大文件更新的下载问题,再就是多家CDN厂商流量调度。其操作流程也比较简单,由运维人员上传文件、安检,然后同步到CDN,由CDN分发到相关边缘节点,最后解压文件。刚才说到游戏的周期性特点,就是平时带宽不是很大,但是在某个节点的时候,或者是重大活动的时候,带宽比较大。如果自己构建一套CDN系统,可能不是很划算,所以我们引入国内多家比较大型的CDN厂商调度资源。我们通过302的方法调度,而不是把域名给其中一家或几家。因为直接使用CNAME的话很难按比例调度,特别是带宽大的时候,一家CDN厂商解决不了,或者是一家发生局部故障,需要快速切除。而通过集中的调度系统就可以实现按比例调度的功能。用户发过来的所有请求,首先要在我们这边进行调度,但是本身并不产生直接下载带宽,而是通过相关算法,按比例和区域调度给第三方的CDN厂商,然后玩家实际是由第三方CDN厂商节点去下载客户端的。

    第二套是Dorado系统。刚刚讲到小运营商或者某些运营商的非法缓存机制会对业务造成影响,那么对于某些关键的文件,如果缓存的是一个旧版本,可能会造成很大的问题。比如我们的区服列表,如果我们服务器端增加了新的区服,在客户端没有显现出来,就导致玩家没有办法进入到新的区服去玩。针对这些问题,我们设计了内部代号为Dorado的系统,因为这些文件本身是比较小的,而且数量也不是特别多,但是需要用HTTPS加密,通过加密规避小运营商的缓存问题。所以我们对于这些关键文件,全部有自有节点,在节点上支持HTTPS加密方法,规避小运营商缓存带来的一些问题。

    3.5、自动化服务器端更新系统

    我们采用的服务器端更新模式也是一种比较传统的类似于CDN的方式,是由目标服务器通过缓存节点到中央节点下载,由缓存节点缓存控制,这样可以减少网间传输的数据量以及提高效率。我们在设计这套系统的时候,也想过用P2P去做。大家想P2P是很炫,又节省带宽,但是用于生产环境中大文件分发的时候会有几个问题。一是安全控制的问题,很难让这些服务器之间又能传数据又能进行安全端口的保护。二是在P2P里做流量控制或者流量限定也是一个挑战。所以最终我们采用了一个看起来比较简单的架构。

    3.6、自动化数据分析系统

    说到客户端更新,其实更新的效果如何,玩家到底有没有安装成功或者进入游戏,很多时候我们也很茫然,只能看日志。但是日志里面的很多信息是不完善和不完整的。下载客户端的时候,如果看HTTP的日志的话,里面是206的代码,很难计算出玩家到底完整下载了多少客户端,甚至他有没有下载下来,校验结果是否正确,也很难知道。所以我们最终设计了一个自动化数据分析系统,目标就是分析从用户开始下载到他登录游戏,数据到底是怎样转化的。最理想的一种情况是用户下载客户端以后,就进入了游戏,但这是一个理想情况。很多时候,比如因为网络不好,导致用户最终没有下载成功,或者是因为账号的一些问题,用户最终没有登录到游戏里面去。所以,展现出来的数据就是一个漏斗状。我们的目标就是让最终登录的用户数接近于起初下载客户端的用户数。

    我们来看一下系统的架构。首先由玩家这边的下载器或者是安装客户端,游戏客户端里面集成一些SDK,对于任何一个关键点,比如“下载”按钮或者“终止”按钮的数据都上报,当然这里面不会涉及敏感信息。上报以后会有Tomcat集群,集群处理以后会将数据写入MongoDB。

    看一下这个游戏在引导过程中有什么问题,左边的这一列它分为三个文件,有一个是3MB,有两个是2G多的文件,其实大家可以想像一下。很多时候玩家看到小的文件就把小的文件直接下载安装了,但是实际上并不完整。这一点也告诉我们,其实很多时候在运营或者是业务方面,在引导方面也是要比较合理才能去规避掉一些问题。

    3.7、自动化数据备份系统

    我们第一个版本的备份系统,它的设计和实现是比较简单的:不同的机房会有一台FTP服务器,本机房的数据写入FTP服务器,然后写入磁带,但是这样就导致磁带是分散的,没有集中存放的地方;另外,基于FTP的上传会有带宽甚至有延迟的要求。

    后来我们设计了一个集中的备份系统。它主要解决了以下两个问题。

    第一是简化配置。我们所有机房的全部配置,用一个负载均衡器的IP就可以了,当客户端需要上传文件时,通过负载均衡器获取实际上传的地址,然后上传文件,由左边第二个框里面的服务器进行接收,并且根据MD5值进行校验,如果校验没有问题,就转到Hadoop的HDFS集群里面去。目前这个集群有数十PB的规模,每天上传量有几个TB。

    第二是提高传输效率和成功率。大家会想一个问题,在中国,网络环境十分复杂,运营商之间存在隔阂甚至是壁垒,导致网络不稳定,丢包和延迟的问题是怎样解决的呢?如果基于TCP传输大文件,理论上存在单个连接上带宽延时积的限制。这里我们创新的是,客户端的上传采用UDP协议,UDP本身没有任何控制,说白了就是客户端可以任意、使劲地发文件。最终会由服务器端检查你收到了哪些文件片段,然后通知客户端补传一些没上传的片段就可以了。基于这种方式能规避很多因为网络抖动或网络延迟比较大而导致的问题。当然,在客户端做流量控制也是可以的。在遇到问题的时候多想想,或许能找到不走寻常路的解决方案。

    3.8、自动化监控报警系统

    再看一下游戏的自动化监控报警系统(如下图所示)。游戏的架构中有游戏客户端、服务器端、网络链路,所以必须要有比较完整的体系进行全方位、立体式的监控,才能保证在业务发生问题之前进行预警,或者在发生问题时报警。

    640?wx_fmt=png

    对于机房链路,有IDC(Internet Data Center)的网络质量监控;在服务器、网络设备和硬件方面,我们会做服务器的健康检查、性能监控,以及网络设备和流量监控;在系统程序方面,我们会收集和分析系统日志;在游戏服务器端应用方面,有服务器端的程序监控;在客户端方面,我们会收集植入的SDK做下载更新后的效果,以及收集崩溃的数据。

    作为运维人员,我们考虑问题或者设计架构的时候,视角不能仅局限于一个技术方面,或者选用多炫酷、多么牛的技术,要想想技术在业务方面的架构,或者能否通过业务指标监控我们的运维能力与运维系统。在游戏里,有一个很重要的指标就是在线人数,通过监控在线人数这个业务指标,就可以知道系统是否工作正常,是不是有漏报、误报的情况,因为很多时候任何一个环节出了问题,最终都会体现在业务上,在产生价值的数据上。所以我们有一套监控在线人数的系统,每个游戏上线之前会接入这个系统,把在线的人数实时汇集到系统里面。如果发生异常的抖动,系统中都会有所显示,也就可以知道是否发生了问题。

    以上讲的是一个框架,下面我们看一下细节,怎样做服务器的监控。首先由运维工程师在监控策略平台配置监控策略,监控策略平台会将这些数据格式化成相关格式,然后推送给自动化运维平台。自动化运维平台会判断是这些数据是外部来的,还是远程检测到的;是网络模拟的,还是本地的监控得到的。比如流量、本地进程的监控、本地日志的监控,会分别推给远程探测服务器,或者游戏服务器本身,然后由它们上报数据。数据上报以后,根据运维工程师配置的阈值,会触发相关的报警,然后通知运维工程师进行相关处理。因为虽然游戏多种多样,操作系统五花八门,但是总有一些大家可以公用的东西,比如监控的模板或者监控的策略,我们对服务器的东西也进行了整合汇总。大家可以看到我们里面有很丰富的插件,运维人员只要选择相关的插件,配一下阈值和周期,就可以节省时间和学习成本,提高配置策略的效率。当配置策略完成以后,直接绑定到想要监控的服务器上就可以了。

    总结

    我们从2000年初到现在一直在做自动化运维体系,对过去进行总结,我觉得有3个方面可以供大家参考。

    第一是循序渐进的原则,特别是中小公司或者初创公司,很多时候并不需要一个“高大上”的系统。聚焦当前的问题,把当前的问题处理好,后面的问题也就迎刃而解。如果一开始设计的系统很庞大、功能特别丰富,会导致一些无法控制的局面。比如这个系统可能最后做不下去了,或者因为耦合性太强,开发控制不了了,或者项目因为经费问题搁浅了。但是如果一开始的目标是解决一些特定的问题,有针对性,那么推进起来也会比较简单。在我司的自动化运维体系建设过程中,我们首先构建的是一个基础的服务器批量操作平台,先把一部分需要重复执行的工作搬到平台上来,再依据运维的需求丰富这个操作平台的功能和提升效率,最后把周边的系统打通,相互对接,形成完整的自动化运维体系。

    第二是考虑可扩展性。设计系统的时候,功能或者设计方面可能不用考虑那么多,但是要考虑当服务器数量发生比较大的扩张时,系统是否还能支撑,比如数量级从十到百,或者上千了,这个系统是否还是可用的。

    第三是以实用为目的。这在我们系统中也是有体现的。很多情况下,市面上可能已经有比较成熟的协议和工具,拿来评估看看它们在生产环境里面是否可用,如果能用就直接用,没必要自己再去做一套。自己做的这一套工具,很多方面没有经过验证,可能会带来安全问题。基于成熟的协议和框架去做,可以提升效率,保证稳定性和安全性。在“自动化运维平台”一节可以看到,我们并没有自己从头开始研发一套Agent植入到被管理的服务器上,而是用了开源的SSH协议和成熟的OpenSSH软件。这体现了优先考虑开源方案加一部分二次开发而不是重复造轮子的思想。

    640?wx_fmt=png

    640?wx_fmt=png

    640?wx_fmt=png

    如果您对其中内容表示质疑,欢迎指出并发表意见,一经采纳,您将成为内测版读者,《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。


    想与胥峰老师直接交流?请加入 DevOps 三十六计交流群

    入群请加微信:gaoxiaoyunweiliuce


    关注 DevOps 三十六计公众号

    我们将长期发布 DevOps 三十六计完整内容

    640?wx_fmt=jpeg

    更多相关文章阅读

    携程运维自动化平台,上万服务器变更也可以很轻松

    顺丰全栈资源下的自动化运维灵魂

    去哪儿网的硬件自动化运维体系建设之路

    阿里大规模计算平台的自动化、精细化运维之路


    GOPS 深圳站完整日程新鲜出炉⬇️

    640?wx_fmt=jpeg


    点击阅读原文,有更多惊喜

    展开全文
  • ERP即企业资源计划系统,是指建立在信息技术的基础上,以系统的管理思想,为企业决策层及员工提供的管理平台。它是一种跨地区、跨部门、甚至跨公司整合实时信息的企业管理系统。
  • 简介: 微前端架构旨在解决单体应用在一相对长的时间跨度下,由于参与的人员、团队的增加,从一普通应用演变成一巨石应用(Frontend Monolith),随之而来的应用不可维护问题。这类问题在企业级 Web 应用中尤为...
  • 个人信息去标识化框架及标准化

    千次阅读 2018-03-09 14:31:59
    个人信息去标识化框架及标准化谢安明1,金涛2,周涛11. 北京启明星辰信息安全技术有限公司,北京 100081 2. 清华大学软件学院,北京 100084摘要:随着大数据...
  • 摘要:数字转型的本质是:在 “数据+算法” 定义的世界中,以智能数据服务的流动,化解复杂系统的不确定性,优化资源配置效率,构建企业新型竞争优势。我们要换一视角,我们从一种静态思维、机...
  • 前言 近年来,随着云计算、大数据、人工智能技术的高速发展,DevOps、AIOps等新文化、新理念的冲击,几乎所有企业的信息...在这场席卷全球企业的变革中,自动运维体系建设就是非常重要且基础的一部分内容。 在...
  • 浅析企业ERP系统运维体系的建立

    千次阅读 2016-05-24 20:36:44
    浅析企业ERP系统运维体系的建立 1 ERP系统的运维简介 ERP系统的运维是指ERP系统上线后的运行和维护保障。ERP系统上线既是系统建设的结束,同时又是一新的起点,需要付出更多的时间和精力来开展系统维护工作,...
  • 互联网企业:如何建设数据安全体系? 原创: 赵彦 美团点评技术团队 总第248篇 2018年 第40篇 一、背景 Facebook数据泄露事件一度成为互联网行业的焦点,百亿美元市值瞬间蒸发,这代价足以在地球上养活一...
  • utm_medium=referral一、背景Facebook数据泄露事件一度成为互联网行业的焦点,百亿美元市值瞬间蒸发,这代价足以在地球上养活一支绝对庞大的安全团队,甚至可以直接收购家规模比较大的安全公司了。虽然媒体上....
  • 上一篇:基于欧美法律法规的企业隐私合规体系建设经验总结(三) 下一篇:基于欧美法律法规的企业隐私合规体系建设经验总结(五) 引子 在2019年,我有幸主导了公司的隐私合规体系建设。几乎是从零开始,完成了ISO ...
  • 数据仓库与元数据管理标准化

    千次阅读 2014-08-11 11:24:24
    数据仓库中的数据是从许多业务处理系统中抽取、转换而来,对于这样一复杂的企业数据环境,如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。 2. ...
  • 建立企业体系结构的更佳途径

    千次阅读 2006-11-13 22:34:00
    show toc 欢迎来到 MSDN > 体系结构 建立企业体系结构的更佳途径 发布日期: 2006-6-13 | 更新日期: 2006-6-13
  • 重磅丨2018年人工智能标准化白皮书

    千次阅读 2018-01-25 00:00:00
    ▌1 前言1.1 研究背景人工智能概念诞生于 1956 年,在半多世纪的发展历程中,由于受到智能 算法、计算速度、存储水平等多方面因素的影响,人工智能技术和应用发展经历 了多次高潮和低谷。2006 年以来,以深度学习...
  • 据工信部1月15日消息,为加快推进智能制造综合标准化工作,加强顶层设计,构建智能制造综合标准体系,发挥智能制造标准的规范和引领作用,工业和信息化部、国家标准化管理委员会组织开展智能制造综合标准化体系建设...
  • JSON处理器 fastjsonfastjson 是一性能很好的 Java 语言实现的 JSON 解析器和生成器,来自阿里巴巴的工程师开发。主要特点:快速FAST (比其它任何基于Java的解析器和生成器更快,包括jackson)强大(支持普通JDK类...
  • 1. 为什么说企业数字转型需要进行微服务架构升级 主要描述传统企业IT应用受互联网冲击的大背景,引出传统企业转系需要在架构上向互联网企业学习。 2. 传统企业实施微服务架构的难点是什么:历史包袱太重 从传统...
  • 核心观点本文构建智慧情景模型,它是构建智慧企业架构框架的...文章提出,企业要完成数字转型,首先是管理层的观念、理念转变,并要具备数字领导力,积极主动推动数字转型,做数字转型的领导者和先锋。其次,
  • 什么是企业信息建设企业...从内容上看,企业信息主要包括企业产品设计的信息企业生产过程的信息企业产品销售的信息、经营管理信息、决策信息以及信息人才队伍的培养等多方面。由于企业信息...
  • 目标管理体系:OKR

    千次阅读 2016-09-09 14:09:01
    一、什么是OKR体系? OKR体系的全称是Objectives & Key Results,即目标与关键成果。... OKR是企业进行目标管理的一简单有效的系统,能够将目标管理自上而下贯穿到基层。对一项目来说,设定目标是非常
  • 分布式微服务架构体系详解

    万次阅读 多人点赞 2018-07-10 23:30:02
    微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂...
  • 什么是用户运营?它以最大提升用户价值为目的,通过各类运营手段提高活跃度、留存率或者付费指标。在用户运营体系中,有一经典的框架叫做AARRR,即新增、留存、活跃、传播、...
  • 前言: 高效读书,一张逻辑图读懂、读薄书中重点。...2.1.这里所说的全集其实算不上是全集,只是一相对的、偏实操的集合,真正意义上的全集引用了国际上的诸多标准、指南和最佳实践 2.2.图13-1 是站在安全职能的角..
  • 种ESB(企业服务总线)介绍

    万次阅读 2018-07-16 19:24:45
    ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。...ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口(例如 IBM的WebSphere MQ、Tibco的Rendezv...
  • 供应链管理,阿米巴管理,能源化工行业四大业务特点,六大管理现状,管理经营数据五大问题,能源化工行业数据四大特点,基于能源行业业务、管理、数据特点的数据决策管理支持方案(PC端集成、移动办公、微信集成、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 74,006
精华内容 29,602
关键字:

企业标准化体系分几个部分