精华内容
下载资源
问答
  • 蓝鲸是腾讯游戏应用运维(ARE)技术生态体系的代号,由正在逐步产品的六大运维平台和众多应用运维(含devops)、运营规划等人员构成。在应用运维这一领域,蓝鲸以“独特”的方式承载着半个腾讯,也承载着国内游戏...
  • 传统运维的弊端: ...由于这些问题的存在,自动化应该遵循四化原则:管理体系化、工作流程化、人员专业化、任务自动化。 以监控作为自动化运维的核心概念 运维工作效率不高,主要原因是响应速度。由于大量的人...

    传统运维的弊端:

    1.由人来发起运维事件,运维人员被动、效率低。

    2.系统异构性大,缺乏高效的运维流程。

    3.随着云计算大数据的爆发带来更大的困难,极度缺乏一套高效的运维工具。

    由于这些问题的存在,自动化应该遵循四化原则:管理体系化、工作流程化、人员专业化、任务自动化。

    以监控作为自动化运维的核心概念

    运维工作效率不高,主要原因是响应速度。由于大量的人员长期盯着报警页面,等待故障,然后通知相应人员。所以在生产系统中,需将服务器的状态监控作为自动化运维的核心问题。下图为自动化运维平台处理流程图,由监控来驱动运维事件的发起、处理和结束,由ElkStack 、Zabbix 和 Zabbix-Agent来获取到服务器的日常工作状态和服务信息,并生成时序统计图等用于成果分析。

    通过精准有效的报警策略做到专业的事由专业的人去做。生产系统已经实现了邮件、微信、短信告警等功能,可以根据故障类型和影响级别及时通知到相应人员,并且可以根据SLA进行事件升级。后续还可以针对微信平台进行持续开发,提供更多功能,比如说模板化处理机制的问题。

    举个例子,服务器的磁盘占用率达到百分九十的时候,告警也会自动通过微信通知到相应的处理人员,这时候处理人员只需采取从微信中选择,并操作对应的清理垃圾模板,如:数据修复模板、清理历史日志模板等,进行清理作业即可。

    以模板化部署为自动化运维的必备利器

    对于运维工程师来说,真正意义上维护服务器的工作并不算繁重,真正繁重的应该是环境的部署,有的时候环境实施部署会占据到运维工作百分之八十以上的时间。由于操作系统版本的不统一,手动且随意的初始化系统环境,不同软件包的版本更新等一系列的问题,会导致工程师部署运维工具或公司产品时,总会出现各种各样非常奇妙的囧境。

    所以,我将模板化部署作为自动化运维的第二块内容,下图为自动化运维平台流程范例。通过cobber可以模板化操作系统,系统初始化配置,软件包版本控制,从而做到整个计算机集群基础环境完全一模一样。减少了因为基础环境不同而导致部署错误。

    当然仅仅是系统的模板标准化还远远不够,我们还可以通过结合Ansible Playbook 将运维常用的工具脚本化,这样不仅仅是为了减少人为因素的出错点,更可以通过批量执行大大的提高工作效率。同时,还可以通过Ansible 进行并行的配置管理。

    在我设计的运维平台中有两个核心组件,分别是告警调度引擎(messageserver)和事件调度引擎(jobserver),告警调度引擎主要作用于分析日常报警信息,通过报警事件、时间、机器、类别等维度生成图表。事件调度引擎的主要功能是根据相应的告警项目,自动处理事件从而实现自动化运维的目的。

    自动化技术思想

    有了上述的几张图和方案,相信运维的大部分效率是可以带动起来的。但是,这真的就是自动化吗?当然不是,自动化运维不仅仅是工具上的革新,更多的是思想上的转变,流程上的优化,这将会是一个持续改进的过程。

    首先,运维需要规范化流程化。其次,运维工具容器化,将常用的运维工具和公司产品构建到容器或者VM中,尽量减少部署时间。再次,日常维护需脚本化,通过配置管理工具实现自动配置维护,并且尽量减少人工的处理与参与。最后,是自动化。

    我认为一个真正的自动化运维平台并不只是通过人或者通过技术去减少人工的参与成本,而是需要和运维产品相结合,最终做到智能运维。这样的话产品本身就可以做到自维护,从而形成一个完整的个体。

    我们在自动化运维平台建设的多年实践中,往往花时间最多的是在运维流程优化、权限控制、日志审核、等功能上。后期我们还整合了跳板机的功能并应用整合到我们的自动化运维平台中。

    现在部署一套环境仅需要二十分钟。100台服务器同时上线效率提高了35倍。环境日常维护或者应用部署上线已经很少登陆到单独的节点上去操作,只要通过系统统一的平台操作基本都能搞定。我想或许自动化运维只是Ops到DevOps转型所衍生出的一种特性吧!未来将走向全面智能运维时代。





    作者:季文轩
    来源:51CTO
    展开全文
  • 业财一体的基本思想是将设计院经营中的三大主要流程,即业务流程、财务会计流程、管理流程有机结合,使财务数据和业务融为一体。在行业新常态的近几年,工程设计企业逐渐向管理、策划、经营等方向转型,EPC/PPP/全...
  • 【文章一】腾讯蓝鲸体系架构及设计思想 原文文章链接:http://os.51cto.com/art/201507/484679_all.htm 作者介绍  党受辉(咖啡党)  腾讯游戏 蓝鲸产品中心总监  目前负责腾讯游戏运维支撑体系(蓝鲸)的建设...

    【文章一】腾讯蓝鲸体系架构及设计思想

    原文文章链接:http://os.51cto.com/art/201507/484679_all.htm

    作者介绍

        党受辉(咖啡党)
        腾讯游戏 蓝鲸产品中心总监
        目前负责腾讯游戏运维支撑体系(蓝鲸)的建设和运营,致力于打造行业级的基础运维无人值守解决方案,以及数据化增值运维解决方案,推动devops生态。
        十余年来专注行业信息化及运维领域,做过多年运维团队管理,期间为不同类型的游戏及千万PCU级游戏平台设计过自动化运营系统。

    引子

    最近,在运维圈里看到触控科技的萧总提出的一个概念“运维2.0”,学习之后,感触颇多,和几年前腾讯游戏的应用运维团队发起的“运维转型”战略项目神似,那个项目在数年间几乎重塑了“应用运维”在腾讯游戏的定义,而在过程中带动并承载这次转型的具体实现,叫蓝鲸。

    蓝鲸是腾讯游戏应用运维(ARE)技术生态体系的代号,由正在逐步产品化的六大运维平台和众多应用运维(含devops)、运营规划等人员构成。

    在应用运维这一领域,蓝鲸以“独特”的方式承载着半个腾讯,也承载着国内游戏行业半数份额。

    出自应用运维团队的蓝鲸体系,最初的设计理念,是希望能武装运维,使其可以提供更高维度的服务。例如,为产品、策划、运营等岗位提供:

    • 自助化的运营工具;

    • 数据化决策支持;

    • 直接的用户体验改善等。

    本文尝试以半叙事的方式,概述蓝鲸出现的背景,设计理念,和落地方式,希望业界广大应用运维同行们,在我们的发展历程中能找到自己现阶段的影子,共鸣共勉,共同努力,繁荣应用运维生态。

    1. 蓝鲸的背景:运维转型

    十年前,我们的业务运维忙于这些工作:服务器、网络、OS、DB、发布、变更、监控、故障处理、运营环境信息维护提取等等。

    这些工作大多是被动的,或者说是“需求驱动型的“,运维大多数时候在被动的为产品、策划、运营、开发等合作岗位的同学提供操作服务,而且很多是重复性的操作服务。五年前,我们的一个运维小组发起了转型尝试,目标是使我们的运维团队从“操作服务输出”,转型为“解决方案服务输出”。三年前,也就是2012年,依据这个先行试点团队的效果评估,整个腾讯游戏的十余个运维团队(目前200+运维)走上了艰难的转型之路,作为落地承载方案的蓝鲸体系同时开始构建。
    当年促使我们决心转型的原因,可以归结为以下三点:

    原因1:业务红海化

    行业竞争很激烈,精细化运营越来越重要。产品和运营人员忙于更贴近用户体验的业务设计和运营设计,开发团队忙于更快更可靠的实现,运维团队则希望为用户提供更高的可用性,不论是刮风下雨,还是发布变更,都能将业务可用性保持在无限接近7*24(此处省略几万字)。
    在此之上,还需要能为产品策划运营等其它岗位提供各类运营工具以提高“产品运营”的效率(一直以来,腾讯运维的职能在内部被定义为“技术运营”,所有运维们所在的职级通道就叫做“技术运营通道”),甚至能为运营决策提供准确的数据依据。



    原因2:“传统运维”生存空间塌缩

    几年前我们预感到“传统运维”的职能空间会被逐步压缩:
        比如一些新技术对运维的传统工作会有一些冲击(此处省略几万字),这一点到今天已经不用再展开说了,近一年运维领域各类危机言论开始满天飞了。
        再比如开发团队出于追求更高可用性等原因,在运维不给力的情况下会直接涉足精细化运营领域。虽然我们认为运维始终是不可或缺的,但也不得不承认传统运维的需求量会有一定的减少,岗位的萎缩对所有从业者都不是好消息,出于自救我们也要尝试转型。

    原因3:我们太累了

    那些年,腾讯游戏疯狂的增长,如果不转型,别提什么辅助决策这样的高级玩意儿,就是发布变更、故障处理之类的运维基础工作都会把我们拖死。



    因此,运维转型的长远目标可以归结为:

    1. 将基础运维服务(发布变更、监控处理、数值调整、数据提取等)尽可能做到运维无人值守,运维提供解决方案(工具);

    2. 同事负责随时调整解决方案,但不能提供重复性的操作服务,由使用者自助或者外包团队操作

    3. 运维分出一部分精力,尝试“用户体验优化”和“运营决策辅助”等运维增值服务



    2. 蓝鲸的涉及思想

    和很多公司的情况不同,在腾讯游戏设计运维技术体系,有4个天然的难处。

    1.    在运维眼里,这里几乎有着互联网行业中所有的业务类型:有重客户端游戏,网页游戏,各类官网,移动终端游戏,大型游戏平台(平铺式架构,拓扑关系复杂,模块数量上百,服务器数量几千)……

    2.    这里几乎有着互联网行业中所有的流行技术,因为腾讯游戏300多款业务中,大多数是由世界各地开发商开发出来,由腾讯独家代理的所谓“独代游戏”。 因此,这些游戏所使用的开发语言、开发框架、操作系统、数据库等技术组合,是没有直观规律的。而且由于游戏从签订代理合同到上线运营之间的间隔时间越来越短,开发商很难为了运维体系而对架构或技术做大规模的修改。

    3.    300多款游戏相互之间是没有关系的,发布变更、故障处理等运维操作场景和操作流程是没有直观规律的,即便是同一个游戏,也可能因为上了一个新版本,新增了几种后台server,或者改变了表结构,而导致运维操作流程发生改变。

    4.    这些游戏的服务器数量,也就是操作单元,有十余万,而随着容器技术的普及,操作单元的数量还会暴涨。

    因此,蓝鲸的设计,不能侵入业务架构,不能依赖业务架构,不能依赖业务所使用的技术,不能依赖有统一的运维操作流程。

    甚至,也最好别指望开发商为你做什么改造,还得支持海量场景(最好能支持十万级操作单元并发)。

    最终,我们总结出来的共同点是:

        运维通过linux命令,可以搞定所有“发布变更故障处理等”运维操作流程。

    虽然只有这一点,但也足够了,这至少说明,运维的基础服务,不论是发布变更还是告警处理,都是可以分步骤的,步骤可能是串行的,也可能有分支结构。

    蓝鲸的设计思路是:尽可能将单个步骤抽象为原子,再将原子自动化,而后通过任务引擎连接成“串”或者“树状分支结构”实现全自动化。

    这种参照SOA的设计,其最大优点在于不依赖业务类型,不依赖架构,不依赖场景,只要运维手工能做的,都可以做成无人值守。

    运维需要做两件事,将原子自动化和将原子集成为工具,这两件事也正是蓝鲸体系武装运维的切入点。

    1)将原子自动化:

    运维通过命令可以做的步骤,在蓝鲸作业平台上封装个脚本,就变成了可集成的自动化原子,而运维通过其他运营系统页面操作的步骤,由蓝鲸集成平台中的ESB平台与其对接好接口之后,也变成了可集成的自动化原子。

    2)将原子集成为工具:

    运维/运营工具的开发对传统运维是有一定障碍的,蓝鲸通过几方面的工作来解决这个问题。在“蓝鲸集成平台”(蓝鲸体系目前有6个平台)中构建了一个PaaS模块,业务运维(devops)无需关注找服务器、部署环境(各种包、mysql、nginx等)等步骤,只需要写好工具本身的逻辑代码上装到PaaS容器就行了,同时还免除了工具的运维成本(高可用、故障修复等)。基于docker技术,工具的部署也是一键式的。


    其次是开发了一套工具代码框架,内置了统一登录、权限、tag等通用功能,更重要的是,不需要一个一个去对接各个系统的接口(原子),因为ESB模块都封装好了,只要写个函数就可以调用这些原子。



    再有就是解决运维的前端开发难题——前端样例库。提供了“从各种页面元素到不同类型的运维工具的页面组合套餐”,减少了运维消耗在前端开发上的时间。



    最后,还为蓝鲸开发者提供培训,一般来说,新进毕业生在通过四周以内的培训之后,就可以独立在蓝鲸集成平台中构建APP工具。


    到此,蓝鲸已经基本解决了运维构建工具高门槛的问题,而且可以随时低成本的根据业务变化(例如新增了模块,导致发布变更、告警处理流程都变了)调整工具。

    运维在“转型”的过程中,需要补充或者需要强化的技能,只有python(Django)和shell及初浅的web开发,这对大多数运维来说,都是可以接受的。

    在这种设计模式下,蓝鲸团队的建设方向就很清晰了:

    1.    继续降低工具本身的开发成本,提高PaaS模块的可靠性;

    2.    扩展原子服务,找出运维海量操作流程中,重复度最高的一些原子,构建成平台,封装接口提供给PaaS作为自动化原子,让运维更轻松的调度更多节点,提升单个节点功能密度,升级拓展更多的流程,直到把流程升级到运维无人值守,升级到对产品、策划等岗位的闭环服务为止。

    经过三年的发展,蓝鲸体系构建了六个平台,其中后四个都是直接或间接提供原子服务供运维集成的功能性平台:


        蓝鲸集成平台:包含PaaS、ESB、开发框架、web样例等模块,是运维制作工具APP的平台。

        蓝鲸移动平台:蓝鲸体系的移动端操作入口。

        蓝鲸作业平台:各种大小文件传输,含参脚本执行类的动作,可以在蓝鲸作业平台封装,通过接口操控。

        蓝鲸配置平台:从业务的各层分级结构到子节点的各类属性,都可以直观的存储于蓝鲸配置平台,通过接口存取。

        蓝鲸管控平台:一套基于海量标准设计的管控系统,为作业平台提供文件管道和任务管道,为数据平台提供数据管道等,整个蓝鲸体系对OS及容器单元、大数据的所有管控,只依赖管控平台的一个智能agent。

        蓝鲸数据平台:基于kafka、storm构建的供应用运维使用的实时计算平台,为上层蓝鲸集成平台上的智能决策类工具族、数据视图类工具族、辅助决策类工具族提供大数据处理及实时计算能力。

    Storm之类的技术早已不新鲜,但供运维“使用”的比较少见。上述平台大多是由运维“维护”的,为了适应运维的技能树,蓝鲸数据平台包括如下特性:

    1.    提供了在线IDE,运维可以用相对熟悉的yaml语言描述运算逻辑,而不需要学习java;

    2.    通过各种渠道对接了大量常用的运营环境数据(客户端数据、服务端数据、网络数据、自定义数据源、在线、登陆、发布变更、营销活动、故障等运营事件);

    3.    提供了数据字典供运维针对个性化的业务选用实时数据组合来做“运维自动决策”或者“辅助运营决策”。

    目前已有的这六个平台的组合,给了应用运维近乎无限的发挥空间。

    我们内部有三个运维中心,十几个应用运维组,他们各自支持着不同的业务,各自处于不同的发展阶段和能力水平。

    出自应用运维团队的蓝鲸团队,在与他们不断的磨合中持续改进着各个平台,武装应用运维逐级提升服务能力。

    一般来说,分三个阶段:

    阶段1:运维基础工作自动化

    大家“尽量”将重复性的,由“运营环境”触发的工作,例如缩容、扩容、开区、合服、告警处理、故障处理等做成全自动化的无人值守,业务架构或者业务需求有变化的时候才去调整解决方案,这算是解放了应用运维自己,至少晚上可以好好睡觉。

    因为这类运维基础服务,应用运维必须做好,至于付出的成本和代价,产品策划和开发团队其实并不在意。或许只有运维经理或运维总监在意,不但在意团队做这类工作的质量成本和效率,还在意做的方式,至少在一个组织架构下,必须是相对标准化的,绝不能是一个人搞一套,走一个员工就要对单个业务的单个场景工具做交接或者推倒重来。至少在蓝鲸体系下,这类工具用的都是相同的原子组件,相同的集成方式。


    阶段2:辅助产品运营自动化

    将“人”(产品、策划、开发等)触发的工作例如发布、变更、配置调整、日志或数据提取等工作封装成蓝鲸集成平台上的自助APP工具,由产品自己操作或者转给外包操作。
    这样既进一步解放了应用运维自己,也让相关岗位的同事不用再看运维脸色,等运维排期,自己就能随时做“产品运营”。
    如果做到这一步,应用运维就算是切入业务运营核心流程了,因为越是竞争激烈的重点产品,在“运营”过程中越需要频繁的做重复性的不涉及业务架构的功能或配置调整,例如改数值、改图片、上传加载新脚本等等,其实就是业务的“后台管理端”。不同业务的管理端,功能大多各不相同,在过去往往是业务开发兼做管理端,自己找服务器、搭环境、写代码、部署、最可怕的是产品用的不习惯,整天改改改……这对业务开发来说简直是噩梦,因为他们的本职工作(业务功能开发)不会因为一个管理端而减少,而且业务开发团队的人手永远是不够的,所以大多数业务开发团队都会让新手做这类“永远做不完”的工作。

    现在运维能干这类工作,而且不用考虑工具自身的高可用和运维(PaaS是免运维的),用业务开发的话讲,“现在的运维真是帮上大忙了”。
    在我们内部的某些产品团队,每当设计一个新产品,业务开发和应用运维团队会各自收到来自产品策划人员发来的需求设计,运维的那一份是《运营工具交互设计文档》。
    而在我们内部,个别团队的业务开发在应用运维忙不过来的时候偶尔会自己跑到“蓝鲸集成平台”开发“后台管理端”,然后再和应用运维商量后续修改维护谁来做,很有联合team的感觉。
    达到这个阶段,应用运维实际上已经在支持“产品自动化运营”了。




    阶段3:数据化运维

    接下来,当蓝鲸团队将大数据实时汇集计算的能力作为原子服务并入蓝鲸体系的时候,应用运维的职能翻开了新的一页,也就是第三个阶段。

    在传统模式下,应用运维如果想做运营环境大数据分析,需要自己写脚本采集日志或OS指标,传输,入库,交叉查询计算,再搞几个页面展示出来,虽说有开源的东西能做一部分,但一来承载有限,二来易用性不够,最关键的,实时性、稳定性、完整性等都有欠缺。

    而让业务开发团队做这个,也真是为难了,比做“管理端”更为难:

    因为相对于单个项目开发团队来说,实现实时计算所投入的成本相对太高了。所以很多公司选择在支撑团队内,为所有的业务部门专门组建“商业智能组”或者“数据挖掘组”之类的公共服务团队。

    但这类团队大都在忙于做“经营类数据分析”,而且人手永远“不够用”,很少有舍得用他们给运维做运营环境数据分析的,应用运维们可能更多的在底下做这些数据平台的“运维”工作,而不是在使用大数据平台。

    蓝鲸数据平台是参照运维的技能树量身设计的,运维做运营环境大数据分析,只需要做三件事:

    1.    写脚本描述采集内容,给svr上部署的“蓝鲸管控平台agent”,管控平台会进行实时数据汇集,把各地海量svr上的数据汇集到kafka集群;

    2.    用yaml描述所上报数据的计算逻辑,用于storm实时计算;

    3.    在蓝鲸集成平台上用APP来展示实时数据视图。

    比如,通过各地的服务器日志实时分析用户的登录、注册、消费、等各种指标,找出区域性的用户使用问题。

    再比如,上了一个新功能,可以通过和研发约定的日志分析用户的使用情况和各种用户行为,或者为了某个营销活动或者新版本,临时的专项设置一些精细化监控,或者为了定位某个问题。

    应用运维一般来说都是对口服务某个业务的,对自己的业务形态以及从用户的角度如何使用都很熟悉,这就决定了:运维是可以理解产品运营策略的,也有能力推测出哪些数据经过怎样的处理,是有辅助运营价值的。

    蓝鲸数据平台的出现,降低了运维使用大数据的门槛,直接推动了“运维增值服务”的拓展。

    在我们应用运维团队内部,催生了很多由应用运维团队主导的,基于大数据的运维服务化项目,比如探索中的“云梯项目”。也就是说在这个阶段,“数据化运维”、“大数据运维”等说法,在蓝鲸体系中不是说着玩的,而是很普通的日常工作。

    从应用运维“岗位价值”的角度来说(我们认为一个岗位的价值可以从被其他岗位替代成本来衡量),当蓝鲸体系将应用运维武装到第三个阶段,就算是逆天了。

    如果说第一个阶段的运维工作,开发等团队可以通过IaaS的高弹性(现在还不大靠谱)及业务架构的高可用(假设他们做得到)轻松替代的话,那在第二个阶段就要付出一些成本了,毕竟是硬性增加了开发团队的建设及维护工作量。

    而在第三个阶段,对业务开发来说就太为难了,也就是说应用运维们借助蓝鲸数据平台可以大量进行业务开发团队从成本上难以承受的工作——运营环境大数据分析,来进行产品运营的决策辅助。

    所以,业界当前在担忧的运维危机,我们在几年前也担心过,而现在无所谓了。

    “数据运维”在我们内部还属于优化推进阶段,蓝鲸数据平台也在逐步成熟中,我们希望协助产品策划人员,在红海竞争中通过我们对精细化运营的一些努力,为业务提升一点点竞争力。
    我们希望为产品策划人员提供尽可能全面的辅助运营服务,或许当他们某一天离开腾讯后,会感觉各种不适应。

    记得我们在杭州办蓝鲸沙龙那次,中间茶歇的时候,有个哥们跟我们说了一句话“我现在感觉腾讯游戏成功的背后有很多我们不知道的因素”。

    虽然我们很清楚,在腾讯游戏发展的过程中我们所起到的必然不是决定性因素,可能只是其中很小很小的一部分,但他的这句话里所流露出来的那一点点意思,依然给了我们很大的鼓励。在腾讯的很多部门,即便是边角的支撑团队,也在为其所支撑的产品线的市场竞争力和口碑而倾尽全力。


    3. 蓝鲸服务

    蓝鲸的服务可以分成两类:PaaS和SaaS。

    上边提到的所有服务,都是PaaS:

    1.    比如蓝鲸集成平台,不管门槛多低,应用运维都需要自己去开发工具APP;

    2.    比如蓝鲸作业平台,应用运维需要自己上去写脚本;

    3.    再比如蓝鲸数据平台,运维需要自己用脚本写采集逻辑、用yaml写计算逻辑,如果需要结果的实时展示,还得在蓝鲸集成平台做展示APP。

    对应用运维来说,PaaS服务是万能的,几乎没有场景限制,只要是原子能覆盖的流程,都能做得出来,非常灵活,还能最大化发挥应用运维的技能,体现其价值:

    1.    比如可以针对某一种发布做个蓝鲸APP

    2.    可以针对某个告警的处理逻辑做个“故障自动恢复”工具APP

    3.    针对某个场景,开发一个实时刷新的数据视图APP…

    蓝鲸大力发展PaaS服务,也印证了我们的理念:即依靠运维,武装运维,使其能提供更高维度的服务,而不是取代运维,同时迎合了 运营、开发、测试等岗位人员的需求。

    用PaaS构建的服务工具,适配场景几乎无限制,高度的定制化使得体验最好,但有“重复建设”以及对于基础运维服务“难以统一化管理”的问题。

    因此在很多高频场景,蓝鲸也联合应用运维团队,提供了不少SaaS。

    比如针对发布变更场景,结合蓝鲸集成平台上大量的发布变更类工具,蓝鲸推出了“标准运维”APP,使得已经慢慢变成大多数应用运维负担的大量的花样繁多的“操作类APP”得以下架。

    这样使得我们逐步的在应用层构建起了标准化场景组件,再允许大家从其他的APP调用“标准运维”接口,也就是说,进行更高层面的“场景调度”。

    或者直接使用“标准运维”提供的APP Maker功能针对某一操作流程,拖拽生成类似于快捷方式的“轻应用”,以实现轻量操作类APP的免开发拖拽生成。

    这样,也使得蓝鲸生态在运维基础服务层面对业务来说更加安全可靠,面对运维人员的流动,抗风险能力更强。


    再比如,在告警处理及故障恢复场景,为了避免运维制作大量针对不同业务的“故障自动恢复”类工具,蓝鲸团队提供了通用的“故障自愈”服务:


     1.   将基础告警及自定义告警的产生封装成了通用服务;


     2.   将告警处理中常用的一些节点封装成组件再集成为套餐供运维通过图形化界面选用。


    当然为了适配个性化的场景,也提供了PaaS编辑器,允许运维用python语言自定义复杂的故障分析树。



    4. 收尾

    运维是一个被压抑了太久的岗位。在行业的一些交流中,很多公司的运维说他们虽然掌控着运营环境,却在逐渐地被排挤出业务的关键流程中,感到对未来很迷茫。

    我只能说,没有充分利用运维的价值,这是他们整个公司的损失,每个业务都是有专职运维的,运维了解运营环境,了解业务架构,了解产品本身,有着丰富的想象力。

    而蓝鲸,就是要让运维的想象力爆发出来,并施加到业务上。

    蓝鲸,是腾讯游戏的运维们从实战中“总结、提炼、构想、设计、建设”出来的体系,其设计初衷是武装运维,使其能提供更高维度的服务,而不是取代运维,同时迎合了运营、开发、测试等岗位人员的需求。

    在所谓的“运维危机”时代,我们更懂得,并成功验证了运维对业务的价值。

    蓝鲸曾支撑腾讯游戏走过了不同层级的标准化、自动化时代,当前正在和应用运维一起探索服务化。而我们自己也在慢慢的将各平台逐步产品化,以支持腾讯的投资公司以及自己部署在公有云上的业务和我们的合作伙伴。

    希望在经过更多的磨合及历练之后,有一天我们可以和大家一起走的更远。

    一个周末写下这些,对于在高效运维群的分享做背景和概要介绍应该足够了,其他更详细的内容和案例,我们本周四(16号)群里见,当然后续我们还会在各地组织蓝鲸沙龙,和业界同行共同探讨应用运维(ARE)的发展方向。

    ----------------------------------------

    另外一篇文章:解读腾讯云蓝鲸平台:运维效率提10倍很简单

    链接为:http://news.yesky.com/prnews/328/87364828.shtml





    展开全文
  • 在轻薄前端为第一目标的前提下,去框架是必须的。   大家都在说不要重复造车轮,背后一个很大原因是造车轮并不容易,并不是谁都有这个经验和能力。 大家掂量一下自己并环顾周围,有多少人能够从零构架UI组件...

    网络前端需要体积小巧。

    所有的框架,包括JQuery都存在冗余(用不上的功能)。你无法对其做减法去除不必要的代码。

    在轻薄前端为第一目标的前提下,去框架化是必须的。

     

    大家都在说不要重复造车轮,背后一个很大原因是造车轮并不容易,并不是谁都有这个经验和能力。

    大家掂量一下自己并环顾周围,有多少人能够从零构架UI组件体系?有几个人能够构架适合不同场景需求的灵活的自定义UI组件体系?

     

    为什么会这样?

    如果前端应用的UI开发和模式化(比如网络通信模式,输入校验模式等)开发足够简单,那么很多人就会涉足这个领域。

    能够做到吗?

    当然能。

    这只不过是一层未被捅破的窗户纸,并没有想象中的那么难。

     

     

    如积木般能够拆卸组装的UI组件体系是非常有必要性的,无论网络带宽是否充裕。

    展开全文
  • 对无线通信装备工厂级、设备级、系统级模块化设计进行了分析,根据软件通信体系结构,提出了模块化通信装备的设计思想,对其相应的标准体系和验证模型进行了重点研究。
  • 一个人最宝贵的应该是思想,一个程序员最宝贵的东西应该是算法思想和编程经验。 我将在此星球,撰写系列纯技术文章。 目前规划是: 基础算法系列 设计模式系列 软件架构系列 程序员的数学系列 机器学习系列 深度...

    最近听人讲解唐诗,忽然特别喜欢「斐然」一词。我觉得人生应该如此,潇洒而不拘。

    程序员的坎应该是年龄,三旬已是老汉,可出于热爱我希望自己能编程到老。

    一个人最宝贵的应该是思想,一个程序员最宝贵的东西应该是算法思想和编程经验。

    我将在此星球,撰写系列纯技术文章。

    目前规划是:

    1. 基础算法系列
    2. 设计模式系列
    3. 软件架构系列
    4. 程序员的数学系列
    5. 机器学习系列
    6. 深度学习系列

    甚至自动驾驶系列。

    价格方面,我会根据内容的充实程度,不断向上调整价格,也算是对早期加入的同学的另一种感谢。

    我本身是「终身学习」理念的支持者,也愿意做一个践行者。

    人需要见多识广,但一个人的尊严无非建立在体系化的认知上。

    如果你热爱,一直热爱,愿意继续热爱,那加入吧。我毕生所学,都会以体系化的形式沉淀下来,相信能让你有所收获。

    当然,CSDN 我也会继续更新,但可能会碎片化一点,我很感谢 CSDN 给我提供这么一个写作的平台。

    相信我,你并不孤独,脚踏实地,穿越年岁,你我终将斐然自成。

    在这里插入图片描述

    展开全文
  • 2、什么是架构设计思想? 3、为什么使用架构,自动架构设计带来的好处、有哪些核心类库以及他们的作用? 4、结合实际工作谈谈遇到的架构使用问题。 1.什么是软件架构? 软件架构(software architecture)是一...
  • 同时为应对高校教学科研学习及生活对网络服务提出的挑战,以服务为中心,可重构网络体系结构对多样业务的强针对性承载能力为思想设计了一种新型基于可重构网络体系的虚拟校园网架构。校园网从传统架构演进到...
  • 利用网络、信息和人工智能等技术实现企业智能建设是摆在煤炭...在选煤厂智能化体系结构的基础上设计出智能选煤厂的系统构成框图及其相互关系。智能体系结构和系统构成方案为选煤厂的智能建设提供了依据。
  • 摘 要: 介绍了一种基于软件无线电思想的中频数字接收机系统设计方案。它采用数字下变频器HSP50214B、数字科斯塔司环HSP50210、TMS320C542构成单元,通过配置不同软件实现对多种类型信号的解调接收。关键词: 软件...
  • 与传统的航空维修保障装备系统相比较,提出航空维修保障装备信息系统的体系结构设计和应用结构设计。该系统能够保证在航空维修保障装备系统的实际工作中,管理人员、技术人员、信息和装备之间的完整结合,使各种...
  • 新员工职业培训课程体系

    千次阅读 2008-09-19 14:31:00
    课程体系设计背景和设计思想 现在,从高校招聘人员仍然是很多组织解决人才缺口的重要途径,从高校招聘的新员工最大的特点是潜力大,可塑性强,因此很多希望强调和凸现自己文化的组织特别愿意操高校招聘,到岗后自己...
  • 个人认为想要成为架构师就必须搭建自己的知识体系,形成系统,结构。 于是借鉴一些大神的学习思维导图,整理了个人学习路线与知识架构。 后续会一直维护并充实此知识体系,并记录自己的所有学习过程与成果。 ...
  • 来自2020中国软件技术大会的PPT 分享版 技术架构变革 孙玄 ...关键字:架构设计 技术架构 架构师 软件架构 新基建 数字 转型 架构体系 说 明:本资源收集于网络,如侵犯了您的权益,请与我联系告知以便删除。 ...
  • 纵向价值链打通:实现数据信息(构建元数据管理系统)、信息知识(构建数据血缘关系和知识分享平台)、知识智慧设计领域分析模型); (2)指导思想: a.用户思维-与一线销售/咨询紧密配合获取真实用户业务...
  • 一个好的电商平台,是一个能够接收高并发的,且没有延迟的快速响应系统,这里必须提到的是模块化设计思想。让各自的业务自成体系。独立运行,各自关联。一个网站的首页是访问量最大的网页之一。如何让其快速响应呢,...
  • 个人认为想要成为架构师就必须搭建自己的知识体系,形成系统,结构。 于是借鉴一些大神的学习思维导图,整理了个人学习路线与知识架构。 后续会一直维护并充实此知识体系,并记录自己的所有学习过程与成果。 ...
  • 2.3 Spark基本设计思想 2.3.1 Spark模块设计 整个Spark主要由以下模块组成: Spark Core:Spark的核心功能实现,包括:SparkContext的初始(Driver Application通过SparkContext提交)、部署模式、存储体系、...
  • 摘 要: 介绍了一种基于软件无线电思想的中频数字接收机系统设计方案。它采用数字下变频器HSP50214B、数字科斯塔司环HSP50210、TMS320C542构成核心单元,通过配置不同软件实现对多种类型信号的解调接收。关键词: ...
  • 持续部署的设计思想1.开篇明意1.1 整体结构图1.2 结构介绍2.为什么要做持续部署(讲个故事)2.1发布项目是种修行2.2测试效果不一致2.3快速横向部署3.结语 1.开篇明意 1.1 整体结构图 首先,这张图不是我的原创,...
  • 发展背景,存在价值及其描述方法和基本构成模型的基础之后,阐述了软件体系结构的软件设计方法,解释并分析开发过程中用到的设计模式,建模方法,软件体系结构风格,以及软件工程领域的模块化思想等知识和技术,并在此基础...
  • 一 六大设计原则在法理学中,...法律原则是指在一定法律体系中作为法律规则的指导思想,基本或本原的、综合的、稳定的原理和准则,内容上只包含“大方针”,而并未有具体规则,比如,如果车上有马上临产的孕妇,闯红...
  • 嵌入式软件设计中的哲学思想

    千次阅读 2013-07-29 14:54:45
    哲学是世界观系统和理论体系。它研究了自然界、人类社会和人类思维的最一般的本质和规律。自然辩证法研究的是人与自然界的关系,人们认识自然改造自然的一般规律,以及科学技术发生与发展的一般规律。中国工程...
  • Spring DAO层的设计思想

    千次阅读 2010-06-07 06:54:00
    Spring面向DAO制定了一个通用的异常体系,屏蔽具体持久技术的异常,使业务层和具体的持久技术达到解耦。此外,Spring 提供了模板类简化各种持久技术的使用。通用的异常体系及模板类是Spring整合各种五花八门...
  • 1.引言 在计算机课程中,“C++程序设计是计算机专业的一门必修基础课,该语言以其高效而又实用的特性:既可以进行过程程序设计,又可进行面向对象的程序设计,因此逐步成为各高校程序设计课程中的主流。...
  • 关于appium自动环境的安装,网上有很多教程,我就不重复赘述,后面陆续写出设计思想,贴出核心代码 报告生成截图: 2、jenkisn 每隔8分钟构建一次自动用例,线上主要页面每隔8分钟监控一遍 3、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 815
精华内容 326
关键字:

化思想体系化设计