业务技术协同线上化的硬盘式研发管理实践

摘要: 在云效平台策划推出的《持续集成与交付:阿里最佳实践》专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践。

摘要:在云效平台策划推出的《持续集成与交付:阿里最佳实践》专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践。

以下内容根据演讲嘉宾视频以及PPT整理而成。

演讲嘉宾介绍

代平,阿里云效产品专家。在本次分享中,代平谈到自己的职业生涯目前总共经历了三个阶段,第一个阶段她从事研发、测试以及项目管理工作,在这个阶段水深火热地工作了四年,积累了大量的项目开发、测试以及管理经验。第二个阶段从事测试的提效工具和项目管理产品的设计工作,在之前做过四年的研发测试以及项目管理之后,代平发现很多事情都是需要针对性地做产品才可能提高效率的,所以她转型开始做了一些提效的工具以及项目管理产品的相关工作。在第三个阶段,随着对于研发全链路产品的了解,加上行业客户的使用诉求就转型去做研发全过程闭环整合的产品,并且在这个时候就开始结合行业客户所遇到的问题对于一些专项性的产品进行探索。

本期分享的主题是业务技术协同线上化的硬盘式研发管理实践,在分享中主要将和大家探讨研发综合产品管理效能平台应该如何实现,以及如何打通需求、开发、测试、发布这样的产品研发全过程,希望能够给大家带来收获。

本次分享的内容主要分为以下四个部分:
一、互联网研发管理背景
二、常见的研发提效策略及其问题
三、云效支撑的研发管理实践
四、实践最佳路径和效果

一、互联网研发管理背景
互联网研发的特点

随着互联网的发展,不仅仅是互联网公司的研发,就连传统企业的研发模式也开始受到互联网的影响,各行各业都在向“互联网+”模式转型,这就导致互联网的研发有如下的这些特点:

  1. 变化,市场需求变化的速度非常快,这就导致研发需要快速适应市场需求的变化。
  2. 体验,给用户带来的体验要好,现在因为人们获取信息获取产品实在是太便捷了,因为客户往往会有非常多的选择,所以如果产品在功能、安全或者体验上稍稍落后就会被客户摒弃。
  3. 速度,互联网市场的竞争非常激烈,产品的研发速度是关乎生死的,也会影响最终的成果。

互联网研发的问题

因为互联网研发有着前面提到的这些特点,也就导致了在研发过程中出现了如上图所示的这一些常见的问题,比如业务迭代速度非常快,直接导致项目的并行量非常大;因为业务发展速度快,所以应用的增长也非常迅速,导致无论是开发同学还是测试同学在搭建环境时的工作都会变得非常复杂;除此之外因为研发同学在研发过程中需要与各个角色进行一些协调,所以这带来的研发成本也会非常高;与此同时,测试的成本也在急剧增长,而且使用的人肉测试也会比较多。这样就直接导致最终的结果是业务很难快速地交付到客户手中。

互联网研发终极大招

那么,对于这些问题应该如何应对呢?其实就需要互联网研发的终极大招。大家都知道,天下武功是唯快不破的,所以提高效率就是互联网研发的关键。

二、常见的研发提效策略及其问题
既然知道了互联网研发的终极大招是唯快不破,那又应该如何去提高研发的效率呢?

对于这个问题,有一些公司首先会想到的就是使用一些通讯工具进行即时沟通,比如使用电话或者会议等方式推动一些事务的进展。然而如果站在开发同学的角度来看,因为他们的日常工作产出的最终结果是代码,而编程这项工作需要在大段整段的时间内进行才能够保证有较高的效率。如下图所示,前面浅绿色的时间段指的是进入状态的时间,因为开发同学往往需要这样的一段时间进行状态的转换,中间这段深绿色的时间段就是进入状态的时间,这段时间就是比较高效的编程的黄金时间,在一天当中大概会有四五个小时,而后面的这段灰色的时间段指的就是在后面会慢慢变得疲惫,状态也开始松懈下来。所以真正有效的就是中间的这段黄金时间,在这个时间段内是研发同学最不希望被打扰的,因为一旦被打扰了那么效率就会降低。据说在Facebook不少程序员在编码的时候就喜欢在桌子面前放一张牌,上面写着“Don‘t disturb I‘m coding”,也就是“请勿打扰,我在编程”的意思。

而且使用沟通的方式推动事务进展也会存在一些问题,一般而言,沟通的方式主要分为三种:同步型,比如电话或者会议;异步型,像微信、钉钉这些通讯工具;邮件,其实邮件也可以看做是异步通信的方式,但是一般用于发布通知。

同步的沟通工具存在一个比较大的问题就是具有破坏性,就像上面提到的当开发同学正在高效地编程的时候,这时候突然有一个电话打进来或者有个会议需要参加,那么效率就必然会降低。同时这样的沟通方式也有一定的延迟性,比如在开会时需要协调的人越多,时间的延迟就会越严重,因为需要约定一个大家都有时间的时刻才能开会,举个例子今天下午需要决定的事情,突然有个关键人物没有时间了,就只能将会议推迟到明天或者更后面,所以对于开会而言,人员越多时间效率就会越低,延迟性也就会越高。与此同时,还需要进行调频,这就如同之前大家使用收音机在找到自己想要收听的节目之前需要进行调台一样,在开会这种方式中,当将相关的人聚集在一起之后,还需要将大家的注意力集中在当前的这个事件上,也就是需要将大家的注意力从他们原来做的事情上拉到现在要做的事情上去。而这对于参与者而言往往是被动接受的,所以参与度也会比较低,在这样的情况下往往无法取得预期的结果。

这样的沟通方式不仅仅是效率比较低的问题,同时还有两个更深层次的问题。第一个问题就是如果一个公司没有统一的任务处理机制,不同团队就可能采用不同的任务处理方式,那么可能某些团队就会使用邮件作为沟通方式,而有的就可能采用开会的方式,甚至有些协作是靠刷脸进行的,谁和我更熟悉就先解决谁的问题,这样的效率就会比较低。其实这样的方式很容易让大家联想到乡村小路,有的是这样走的,有的是那样走的,乡村小路的特点就是不平、不直、不通并且不一致。大家都知道“要想富,先修路”,只有统一并且宽敞的信息高速公路才能加快研发任务的处理速度。

第二个问题就是内容没有沉淀下来,如果后面的人想要查看前面的人沉淀下来的经验的话,就需要到处去找、到处去问。代平谈到自己所在的团队之前也是这样的,最早需要做一些项目的统计以及汇报工作的时候,就需要专门找一个人,花费一个星期或者两个星期的时间去向各个项目管理者搜集各个项目的情况去做汇总的展示。可以试想一下,这种方式下,在研发中的无论是过程数据还是结果数据都会是散落的,而对于公司而言,这些数据就如同宝石一样是非常宝贵的东西,但是却是散落在各处的。那么如果整个研发过程的数据就如同在一个硬盘上一样全部存储下来,那么对于公司而言将会是多么巨大的一笔财富,后续即使以前的同学离职了,新的同学也可以通过这些沉淀下来的数据参考查证以前同学留下来的路径以及路径上记录了什么东西。举个例子,大家都知道的每年天猫的双11,在前几年刚开始做的时候它的沉淀是很少的,所以成本也会比较高,准备双11都需要提前很长时间,而且这个周期会非常长,而现在准备的时间周期就会变得越来越短了,这正是因为有了前面的经验积累。比如之前就看到去年双11的成交额预测项目组的同学在自己的项目文档中就写道他们在采取分时成交预测方案的时候就参考了之前承担这项任务的同学的方案,然后对于原来的算法进行调优。那么可以设想在2017年,对于负责双11的同学而言,之前几年的算法或许都可以作为参考,这样就可以站在前人的肩膀上继续前进。

所以不仅仅需要将原本不平、不直、不通并且不一致的沟通路径用信息高速公路取代,并且需要将公司的一些项目的数据资产包括过程、文档、结果以及代码统一用于建造公司的类似于数据资产金字塔的硬盘中,将这些数据全部保存下来,这就是云效平台硬盘式研发管理的主体思路,也就是从各种路径独立转变到建立一条整体相通的信息大道,并将数据进行汇总进而做统一的展示、记录和存储的构想。

其实现在也有不少公司也意识到了这一点并开始建立自己公司的研发信息高速公路,他们的做法往往是通过引入一些平台产品来建设自己的信息高速公路,并且通过这样方式沉淀出自己公司的硬盘式金字塔将数据存储下来。这样的趋势如下图所示,通过这些数据不难发现,之前的一部分比例有自建的,也就是使用一些开源工具做集成;也有一些公司使用各自独立的环节独立分割的工具平台实现的,为什么这样做呢,其实在很早之前大家记录Bug往往会使用QC,而这个工具在互联网的“原始年代”还是比较好用的;还有的就是倾向于使用单个厂商的工具平台,也有一些国外的公司能够提供一些比较全面的产品工具平台。在刚开始时,大家很少采取这种单个厂商的全工具平台,因为之前这样的最佳实践也比较少,所以技术也不是很成熟,而慢慢发现随着技术的发展,现在大家开始倾向于选择单个厂商的具有最佳实践的全工具平台,同时如果这样的平台能够具有松耦合性,能够使用多种复合开源或者第三方工具进行良好的集成将是最好的。

三、云效支撑的研发管理实践
接下来分享一下云效是如何支撑研发管理实践的。如下图所示的是云效平台整体的架构图,这就是云效的研发信息高速公路,它可以让研发同学以及包括产品、测试和运维等其他的相关同学将自己的日常工作放在这个平台上。需求、做项目、设计技术方案、编码、代码的审阅、测试、发布以及所有工作项的评论等全部记录在云效平台上。

因为云效平台的核心原则就是平台化、流程化和自动化,也就是说希望制定一套标准化的流程,例如持续部署流程、代码流程、代码管理流程等,之后将这些流程通过自动化的方式以及自动化的工具实现出来,这就是云效平台的基本原则。有了这些原则之后就在平台之上建立了配置管理、持续集成、持续交付、环境自动化、分层自动化以及集成自动化这些相关的子系统。有了这些子系统之后就创建了一个可靠可重复的交付流水线,这应该如何理解呢?也就是比如说在提交与编译阶段的并行研发、编译构建和单元测试,在测试与验证阶段的环境部署、系统测试和集成测试,以及在发布与运维阶段的生产交付、发布回滚和生产监控都是可以通过云效平台的相关产品进行效率提升的。在可靠可重复的交付流水线建设完成之后,云效团队又将之前所做的研发综合效能管理方面的东西,包括业务模型分层、业务规划、研发资源管理以及ROI复盘等,全部在云效平台上进行呈现。而将包括需求跟踪矩阵、迭代计划、任务分解流转以及度量与改进在内的这些构建成了协同工作流,每一个人都可以在平台上评论所有的工作项并提出方案或者进行顶踩,这样就保证了开发的质量、效率以及评论和文档等所有相关的数据都存储在平台之上。项目维度的互动和多角色之间的沟通协作全部都是在云效平台上进行的,参与项目的人员使用相同的系统进行相互协作,这样对组织效率和业务也能够起到很好的促进作用。除此之外,云效平台还支持私有云部署,而且对于Docker等开发框架以及最简单的J2EE工程项目等也能够提供良好的支持。

以上就是对于一整套的信息高速公路的展现。接下来带领大家大概看一下云效平台硬盘式研发管理的总体流程,下图展示的是偏重研发的过程。下图所示的就是研发流程的示意,从上层的业务方进行业务规划开始,之后需要进行组织人员的安排,再到立项之后的需求确立。对于需求的确立而言,需要通过需求跟踪矩阵将需求横向化、标准化。需求是可以分解和拆解的,也是可以配置的,需求的变更记录、评审记录包括对于需求的评论、顶踩全部会在这个平台上记录下来,在平台之上还可以实现责任人以及状态的流转和变更来记录需求到了什么样状态,这样就能够提升需求的质量,控制需求的范围,这是从横向上来看这条线。而从纵向上来看,需求是和后面的整个项目串联起来的,因为需求确定之后就可以进行迭代拆分、评估工作项的资源以及进行任务分解、测试用例的设计实现以及与Bug相关的一些东西都是可以通过需求串接起来的,这样就保证了需求与后续工作的关系都可以透视出来,这样有利于对于整体风险的把控。在整个项目过程结束之后,可以将项目的全部代码发布到代码库中,然后通过云效平台的指挥部这个产品对于整个项目进行复盘并评估出项目的投入和产出。

这里大家可能会产生一个疑问,看上去整个研发过程的工作都是记录在这个平台上面的,那么有没有一些研发相关工作是没有记录在云效平台之上的呢?这个问题的回答是:没有!云效平台提倡硬盘式记录,如果工作没有在平台上记录,那就相当于没有工作的产出。可以设想一下如果公司的一名员工来到公司之后做了很多年,既没有留下一行代码,也没有留下任何对于技术方案或者需求的变更、评审进行讨论的东西,这样对于公司而言这名员工又给公司留下了什么呢?所以,站在公司的角度,希望每一个来公司的员工都能够积累下一些属于这个员工自己的在公司所做的工作,并且全部都记录在公司的平台之上,进而固化成公司的数字资产。

在阿里巴巴一些比较高级的技术专家可以在云效平台上做些什么事情呢?其实可能一些高P的技术专家不会亲自去写代码了,但是可以在平台上Review一些技术方案并给出一些评论和指导,甚至还可以进行代码的审阅。对于这些高P的技术专家而言,可能他们的一个技术评论就可能帮助开发同学避免很多坑,这样就能够节省大量的时间。而对于管理者而言,在这个平台之上,他们所需要做的事情就是促使团队在这个平台上产出有价值的东西并记录在这个硬盘上面,从而沉淀出整个公司的数字金字塔。并且管理者M是可以看到自己团队的所有成员的全部产出的。那么既然主管可以看到每个人的产出,那么是不是就可以看到究竟谁的工作做得多或者少呢?

谈到这里就有一个问题了,主管看到员工都在做什么,是为了抓到偷懒的还是鼓励干活多的同学呢?代平谈到作为管理者而言,他们的答案是鼓励干活比较多的同学,其实在工作中要想偷懒太容易了,而管理者所关注的则是团队中成员在平台上面写了多少行代码,写出了多少个测试用例,提出了多少个Bug以及设计了多少个技术方案,以及对这些技术方案的评论是什么。

接下来带领大家一起看一下云效产品的部分页面,也就是云效产品是如何呈现员工的工作情况的。以下图所展示的是项目概况页面,这里包含了项目的整体进度、概要、里程碑信息、风险信息、负责人以及项目成员、相关的子项目、及时滚动显示的项目动态、通知信息等。除此之外,项目中各个角色所需要做的工作项等的内容也是通过一些服务呈现的,比如需求页、任务页、迭代、测试用例缺陷、以及自动化、单测集成、环境搭建以及整个系统数据的报表还有发布等,这些内容都会以项目的维度进行展示。

一个项目的管理者或者项目成员到云效平台上就可以看到与项目相关的所有内容。以产品为例,从源头的需求角度来看平台上的页面又会记录什么呢?如下图所示的就是需求页面的展示,在这里就可以看到整个需求跟踪矩阵的列表,这里提供了看板和数表这两种模式来显示项目需求的优先级、是否上线、迭代情况、创建者以及当前的负责人等状态信息,点击每个需求条目之后就可以看到这条需求的详细情况,包括需求的具体内容以及相关联的需求的状态以及相关的一些任务的状态,需求详细信息中还包含一些相关的评论,这样做是为了鼓励将需求拿出来给大家分析是否合理,项目中的每个成员都可以去评论或者顶踩,也可以提出更好的方案。

除此之外,需求的详细内容页面还会显示需求各个版本的修订记录、变更记录、评审记录以及操作记录等信息,对于每一个工作项都有这样类似硬盘式的记录,包括这个需求所包含的任务、用例、缺陷、分支等工作项也会在详细信息中进行展示。上图的页面中最右边展示的则是需求属性以及附件,这里包含了优先级信息、迭代信息、所属的项目、关联的项目、模块信息、版本信息、进度信息以及经过技术同学评估之后计算出的大概的工作量,还有就是一些自定义的标签、发生变更之后需要通知的对象信息,以及与该需求相关的附件。这就是需求页面的大致情况,因为这部分是项目的源头,所以其包含的信息量是非常大的,所以需要以硬盘的形式全部存储下来。总之,云效平台在横向上会将需求所有相关的信息全部记录下来;对于纵向而言,像任务拆分、用例、缺陷以及开发分支等所有项目相关的内容都可以在这里记录下来,以此串联起整个需求的过程,直到产品发布上线。

接下来再为大家介绍一下如下图所示的集成自动化的页面。下图的页面所展示的就是某一个项目的集成自动化的情况。因为云效平台最擅长的一面就是相关的UI自动化、接口自动化以及单测的情况,这些都是可以全部集成在一个平台上执行的,而且历史的执行结果将会全部展示在页面上,集成的通过率情况如何,有多少成功和失败也都会在页面上展示出来。测试件在执行的时候绑定的环境情况,项目中各个部分所执行的测试件情况等,这些项目相关的自动化情况也都会页面上得到展示。这样大家对于硬盘数据的管理就会有一个直接的概念,项目中所有的信息都可以在一个统一的平台上呈现出来。

四、实践最佳路径和效果
那么,在云效平台上的最佳实践路径和实践效果是如何的呢?其实对于云效平台而言,阿里的实践也不是一帆风顺的,在刚开始起步阶段也不是非常规范,从最初的最简单的Bug系统再到项目和任务、再到讨论以及文档管理,都是一步步实现的,并且在后面将很多的自动化工具和产品也集成到一起。

实践并非一步到位
之后在实践的过程中发现了与其他公司一样的问题,这些工具都是比较零散的,那么就一边将这些系统进行集成,一边进行系统重构,让这些子系统的数据能够互通,这样才得以统一,形成了阿里巴巴统一的信息高速公路。只有这个信息高速公路建成之后才有可能构建出阿里研发资产的金字塔,将数据全部像硬盘一样存储下来。在实践的过程中有一个基本的原则就是统一高于好用,这又应该如何理解呢?其实就是在刚开始的时候,各个团队想要使用的工具往往会是不同的,如果不同团队沟通方式不同或者使用的工具不同,那么对于整个公司而言,效率就会比较低下。所以在云效平台的实践中坚持的基本原则是统一高于好用,公司是需要一个统一的研发管理平台的,而不是各种好用的工具的简单堆叠。

实践中遇到的挑战
其实在云效平台的实践过程中也遇到了不少的挑战。引入一整套的研发管理工具平台,无论对于阿里巴巴自己还是客户而言,都会需要转变工作习惯,需要从线下的各种不同的方式引导到线上并且使用统一的方式,使得从业务同学到研发同学都是按照这一套规范的路径完成工作。总结下来有这样三个比较好的措施:

  1. 宣导,就是告诉大家我们为什么要做这件事情,引导大家进行思维的转变。阿里巴巴也在这个方面开过不少的会议来讨论为什么要构建大中台来支撑前台的业务,所以也是需要不停地进行宣传的。
  2. 由易到难,要从简单的事情出发,从易到难地推动这件事情。这在云效平台的实践中也是一样的,云效平台也是从最简单的缺陷的录入,到项目的录入,再到任务的拆解,最后到将各种工具引入上来进行统一的,存在一个循序渐进的过程,因为想要建立的是统一的研发管理大中台,所以推动的团队也是先从技术团队入手,一直推广到业务团队,让他们也在平台上做需求以及业务规划。
  3. 专人负责,无论是对于阿里巴巴还是客户的公司而言,如果有专人负责的话实施往往会比较顺利。常见的负责的组织就是PMO组织,也就是项目管理专员,如果有专人去负责、宣导、实施和复盘,并且从系统中拿到一些数据并发现问题或者可预见性的瓶颈,并进行汇报,再通过管理层的资源解决问题,如此就能够加速硬盘式研发管理实践的落地。

效果
硬盘式研发管理实践的最终的效果一方面是把员工脑海中的信息都数据化成为公司的研发资产,员工的工作也都会固化成为数据存储在公司的平台上面;另一方面统一的研发效能平台就如同信息高速公路一样,因为其是透明的,所以可以营造出一种在意工作过程并且在意相互帮助的工作氛围,团队成员之间也会鼓励积极共享代码并且参与讨论,这样他们也不会再去争抢地盘。最终会使得研发的效率更高,并且带来高效的横向协同。

在2015年9月底的时候,阿里巴巴的CEO逍遥子带领公司的总裁班子在美国走访了10余家百年老店,包括一些品牌翘楚以及创新公司,像Google、Facebook、苹果、特斯拉等。在他们回国后进行分享中,不少的总裁提到令他们印象深刻的是这些国外的创新公司的办公区都是有一些非常自在的休闲设施的,因为这些公司鼓励员工在一个最舒适的状态进行工作,比如会在园区中提供一些沙发、小花台、零食吧、咖啡吧等,甚至允许员工在家里办公。当然这些是有前提条件的,如果允许员工在家办公就需要有一套坚实的工程管理基础,要有一条可以帮助员工高效研发的信息高速公路,使得所有人的工作都是透明的,这样才能够让员工在这样舒适的条件下办公,这也是构建成信息高速公路之后,未来大家办公的场景。

原文链接

时间: 2024-10-31 07:40:36

业务技术协同线上化的硬盘式研发管理实践的相关文章

广告行业中那些趣事系列6:BERT线上化ALBERT优化原理及项目实践(附github)

摘要:BERT因为效果好和适用范围广两大优点,所以在NLP领域具有里程碑意义.实际项目中主要使用BERT来做文本分类任务,其实就是给文本打标签.因为原生态BERT预训练模型动辄几百兆甚至上千兆的大小,模型训练速度非常慢,对于BERT模型线上化非常不友好.本篇研究目前比较火的BERT最新派生产品ALBERT来完成BERT线上化服务.ALBERT使用参数减少技术来降低内存消耗从而最终达到提高BERT的训练速度,并且在主要基准测试中均名列前茅,可谓跑的快,还跑的好.希望对需要将BERT线上化感兴趣的小

一种线上服务日志切分与压缩方法

1.业务背景 对于线上业务而言,打印日志是一个系统运行状况的全面体检,日志打得约详细,越容易查找问题,但是机器磁盘是有限的,这时候很容易将磁盘撑爆.所以打印日志多少要选取一个平衡,打印适量的日志,只在关键环节,容易出错的地方打印日志即可.但是随着业务量的提升,即使我们控制了打印日志的频率,但日志文件的容量也在大量扩大.如果我们对日志文件的处理方式不当,日志文件将打到磁盘上线,新业务就再也刷不出来任何日志了. 因此,我们对日志的处理一般分为三个步骤: 打印当天日志,历史日志重命名为带日期格式,以示

线上服务应急与技术攻关方法论

海恩法则和墨菲定律 海恩法则指出: 每一起严重事故的背后,必然有29次轻微事故和300起未遂先兆以及1000起事故隐患. 海恩法则强调两点: (1)事故的发生是量的积累的结果: (2)再好的技术,再完美的规章,在实际操作层面,也无法取代人自身的素质和责任心. 根据海恩法则,一起重大事故发生之后,我们要在处理事故和解决问题的同事,还要及时的对同类问题的「事故征兆」和「事故苗头」进行排查并处理,以防止类似问题的再次发生,将问题在萌芽状态就将其解决掉,这可以作为互联网企业线上应急的指导思想. 墨菲定律

线上测试高可用集群部署文档【我的技术我做主】

线上测试高可用集群部署文档 目录: 目录:1 项目需求:2 实现方式:2 拓扑图:3 系统及软件版本:3 安装步骤:4 IP分配:4 LVS和keepalived的安装和配置:4 LVS主配置:4 LVS2备 配置:7 web服务器配置9 Mysql-MHA高可用:13 Mysql主配置:13 manager管理端操作:15 VIP切换:16 测试:26 下面是centos5.6的系统环境,如果是centos6版本,只需改动少许地方即可,步骤一致 . ---- by 金戈铁马行飞燕 项目需求:

尖峰7月线上技术分享--Hadoop、MySQL

7月2号晚20:30-22:30 东大博士Dasight分享主题<大数据与Hadoop漫谈> 7月5号晚20:30-22:30  原支付宝MySQL首席DBA分享主题<MySQL发展趋势,MySQL各个分支介绍>.<MySQL 5.6版本特性介绍及如何从MySQL 5.5向MySQL 5.6> 7月10号晚20:30-22:30 东大博士Dasight分享主题<Hadoop与Nosql技术的适用性分析> 7月12号晚20:30-22:30  原支付宝MySQ

7月26日云栖精选夜读:MySQL金融版线上发布会:它为什么是金融企业的首选_技术大佬、产品和神秘嘉宾本位“演绎”

原文地址 2017年8月10日,云栖社区将迎来一场特殊的直播--阿里云数据库MySQL金融版线上发布会. 届时,我们不仅请到了阿里云金融业务部总监九河.阿里云数据库掌门人褚霸以及阿里云数据库产品专家乙休来一起宣布这个好消息,同时还邀请到一位在金融界绝对是重磅级人物的神秘嘉宾,一起来聊一聊产品发布背后的故事. 热点热议 MySQL金融版线上发布会:它为什么是金融企业的首选,技术大佬.产品和神秘嘉宾本位"演绎" 作者:好麦 CVPR论文解读 | 剁手有了新方法,明星同款边看边买 作者:仁太

O2O 线下业务 和 线上业务,在特征工程上的差异

人工智能在外卖送达时预估上的应用 这篇讲清楚了 O2O 线下业务 和 线上业务,在特征工程上的差异: 原文地址:https://www.cnblogs.com/cx2016/p/11362871.html

weblogic线上业务真实环境故障集锦系列-1

线上192.168.XX.XX启动受管服务器报错 报错信息如下: 解决方法: vim  /data/weblogic/wlserver/user_projects/domains/base_domain/servers/AdminServer/security/boot.properties username=XXX password=XXX 保存后退出.使用上面的命令重启受管服务时,不再要求输入用户及密码. 不需要输入用户名和秘密后,就可以使用nohup后台启动服务了 nohup sh sta

支付这条线上 谁在赚钱谁在哭?

互联网.科技巨头不断的跨领域大动作,让整个互联网行业的态势显得错综复杂.只要是未来掌控互联网必不可少的细分领域,哪怕此前不是自身的主业,也一定要涉足其中.于是我们看到,支付宝花了2亿多想通过"集五福"强行杀入社交圈:微信不断在移动支付上兴风作浪--而就目前来看,最受关注的就是支付这一细分领域. 作为一切消费活动必不可少的中间手段,谁掌控了支付就意味着掌控住话语权和主动权.但理念.策略的不同,导致在支付上的表现形式和发展方向也各有不同.结果自然就是在支付这条线上,有的企业在疯狂赚大钱,有