|
小欧有话说： 8月30日，在2016全球技术领导力峰会上，58集团CTO邢宏宇发表了《透过未来看现在，动态视角看技术决策》主题演讲。本文根据邢宏宇演讲内容整理而成，分享给未能到现场的你。文末附有演讲PPT下载哦！ 邢宏宇，58集团CTO。毕业于清华大学电子工程系，获得硕士学位。2005年-2015年在腾讯任职，历任搜索产品部副总经理、网络媒体产品技术部总经理、微博事业部总经理等职务。2015年正式加入58同城，并担任CTO一职，全面负责58同城、赶集网以及安居客的技术战略方向的制定、技术创新以及集团研发资源的规划、管理和调配。 今天跟大家分享的话题是关于技术决策的，相信每位做技术的同事，无时无刻不在面临一些决策问题，小到解决一个问题，大到设计整个技术体系。今天尝试从一个动态的视角来跟大家分享，看到底怎样去做这些的技术决策，有没有一些方法或规律可以遵循。 今天的主题是怎么样从一个动态的视角去看技术决策，那我们决策的动态思维到底在看些什么？我在这里帮大家做了一些提炼和总结。 第一是看业务，首先要分析你的核心业务模式是什么，包括业务的增长点，未来是用户的增长、流量的增长还是基于交易量的增长。业务模式不同，决定了你的技术选型和团队组织情况的不一样。其次，要看你的业务到底是平台型业务还是垂直化业务，是类似58、淘宝这样的平台类，还是某个垂直领域，如汽车电商之类的。最后，要分析你的业务里面是共性多一些还是差异化更多一些，这对你技术决策的选择也有很大的影响。 第二是看组织，看你内部的组织职能划分，包括你是按照专业职能划分的，比如按照产品、研发、运营、销售等职能划分的，还是按照业务单元、业务的组织形成来划分，这样每个小的职能是一个业务的闭环，里面包含了产品研发和运营销售等。所以，这里面组织形式的不同，也决定了技术选型的不同。 第三是看人才，因为所有的技术系统都是人做出来的，所以你在做一些选型判断的时候，不能脱离你的人才结构，包括团队的梯队情况、团队的人员规模，甚至要考虑到人才的获取能力是怎样的。 所以，决策的动态思维是看能不能预判未来的变化，来去制定今天的技术决策。换句话说，我们做技术决策，不能只看当下，要尽可能的去做未来的预判，看能不能看到两三年之后组织、业务和人才会发生什么样的变化，以此来制定你今天的技术决策。 特别要强调一点，不能用静态的思维解决当下的问题，这样头痛医头、治标不治本，到后面会有一连串问题出现。 所以，动态思维的核心要素是，首先要确定未来想达到的目标，但你也不可能一下子就做三年以后的事，所以你要把未来目标做一些推演和演进，变为当下的决策，再通过敏捷迭代的方式落地和执行。 决策的执行路径要着重几个点，第一个是要关注决策本身的连贯性，虽说决策的执行过程是一步一步迭代的，但是你决策的整个思路和方式是要有连贯性、要一致的。第二个是要关注决策本身的可迭代性，看它是不是可以迭代、可以被分解，如果你的技术决策是不能分解的、不能迭代的，那它真正落地的难度和挑战会非常大，甚至很可能推行不下去。第三个是要关注决策的敏捷性，看它是不是可以足够敏捷、足够快地去执行。 58是一家生活服务领域的公司，2005年成立，到今年已经有11年了，主要的业务涵盖房、招聘、生活服务、二手车等诸多领域。 过去58大概经历了3个技术阶段，第一个阶段是早期还是Windows单机的版本。第二个阶段，是从2010年到2015年，换成了基于Java、Linux的系统，同时，为了解决内部的效率和协同问题，58自己内部搭建了一个RPC的框架，也开始有一些基于Java包/库的共享。 到2015年，我们开始想58技术的架构体系未来改怎么变，是继续延续过去的模式，做一些小的改造就可以，还是需要一些更彻底的变革。换句话说，58技术的3.0升级要怎么做、什么时间来做？
首先看业务，业务我们在从单业务到多业务的转换过程。过去，58每个品类的产品基本上都做得差不多，但从去年开始，慢慢朝着纵深化的方向演进，房、车、招聘的产品越来越不一样，不断向着多业务的方向转换。另外，也从原来的单终端转变为多终端，而且移动端更强。最后，每个业务板块也重度向着垂直化的方向演进和发展。 组织从原来的按职能划分，慢慢变成了按各个BG业务划分的模式，在业务内开始形成一些小的产品、技术和运营的循环。因为58的业务特点，既有大量的业务共性，同时又要保证每个业务板块各自高效运作，所以是比较适合用这样平台+垂直化+BG化的模式的。 人才已经从原来几百人规模的小团队变成一个两千人规模的大团队，同时整个58大概是2万人的规模。这么大的团队大家可想而知，未来会对整个产品研发的效率产生非常大的挑战。 人才方面面临的另外一个问题，可能跟大部分的公司都类似，就是高级人才稀缺，获取他们充满挑战。主要还是因为整个互联网行业发展得太快了，人才的成长速度跟不上整个行业的发展速度。 了解这些背景，我们大概就能看清楚，未来几年58会发生怎样的演进。 再来看当时的技术现状是怎样的。 第一，当时的系统架构超级复杂，正是因为原来的设计模式都是基于库的共享，随着库的增加、人员的增加和项目的增加，耦合非常严重，剪不断、理还乱，处于一种没办法维护或往前发展的状态。 第二，其实跟第一点相关，大家会发现开发的效率在不断下降，就是因为互相之间的依赖比较多，甚至很多系统复杂到解释不清楚的情况。 第三，因为过去十多年的发展，58的技术在不同的阶段有不同的系统和产物，当时有些三五年前的系统、甚至是七八年的系统还在用，可以说是四世同堂、包袱沉重。 再回到刚刚提到的背景，会发现我们对业务的判断是未来会更多的从平台化向重度垂直化转变，每个业务都需要更好的、高效率的循环。同时，随着整个组织变成业务内闭环的模式，对研发效率的要求更高。面对现在两千人、未来可能三四千人这么庞大的研发团队，如果没有一个高效的技术模式的话，是很成问题的。 所以当时我们做的最基本的判断是，随着业务、组织、人才的演进变化，所有问题不会自然缓解，反而会加剧恶化，耦合会越来越严重，内部的效率也一定会随着人员的增加而下降。 基于这些判断，我们做的决策，就是不能做简单的优化。简单的优化并不能解决之前提到的各方面的挑战和问题，必须要做彻底的变革，现有的技术模式需要有根本的革新和升级，要能满足未来长期“可持续”发展。 另外，在解决问题时，不仅要考虑技术的改造，同时也要考虑业务的变革、产品的变化和技术的升级，以此对有些不再必需的功能做简化甚至取舍。 最后，因为团队规模和历史系统的复杂度，所以变革的时候方向要坚定，但方法要循序渐进，敏捷迭代，不能一蹴而就。 综合提炼，我们希望58的技术3.0变成58服务云，一个面向内部的服务云。 为了让大家更好地理解这些改造的理念，我们内部做了一些简单的提炼。
第二，两个分离。针对58的特点，我们当时明确了两个改造方向，定了两个分离，一个是前端展示和业务逻辑的分离，一个是在线和离线服务的分离。因为现在很多业务都用到了大数据分析，而大数据分析大部分是离线的业务，但过去58有在某些场景把在线和离线混用的情况，导致系统问题非常多。 第三，三个转变。也给大家提了三个转变，第一个，全面变成服务化的模式，把原来基于库的分享变成基于服务的提供，从根本上简化对外的接口，内部可以做得很复杂，而且内部可以做自我升级。第二个，重设计，一是重视设计，二是重新做设计。设计什么东西呢？重新分析你的业务特点和产品功能，做技术的分享和提炼。对业务的分析越彻底，技术的设计就更容易做得简单。重设计的过程是简化设计的过程，而不是把系统变得更复杂。第三个，转变是可管理的，我们认为一个可持续的系统一定是可管理的，如果这个新的架构系统不可管理，那它显然并不能长久的存在，所以我们新的改造全部要求可管理，适应未来可持续的发展，随着每个业务的差额越来越多，仍然可以保持非常好的内部效率。 这是我们提炼出来的核心架构图，经过提炼之后，核心的模块功能可以变得非常简单，从数据、缓存等核心服务到上面各个业务的垂直应用，每套系统配了统一的管理平台，所有的服务化都是可管理的，自我升级、包括冗灾全部在系统内完成。 我们把实施的过程做了拆解，大方向上分为三个阶段来完成。 1.2015-磐石：底层架构和基础服务再造 第一阶段是去年的时候，58做了整个基础服务的改造和升级，类似于在飞机飞行中换引擎或者汽车行驶中换轮胎。这使得我们有了一个非常好的技术基础设施，并且各个业务都可以很好的应用，目前已经完成了。 2.2016-盘古：业务架构和核心服务再造 第二个阶段是盘古，也是现在正在进行的，主要是对整个业务的架构和一些核心服务再造和升级，更贴近于业务的改造。 3.2017-女娲：业务线内服务改造和技术升级 第三个阶段是明年，会对每个业务线内的技术进行升级和改造，进程已经是从整体到局部了。 可以看到，虽然这是一个非常大的改造系统和过程，但58把它分解到几个不同的阶段，而不是一开始所有的系统就都要同时改造，同时每个阶段内部也做了迭代，可以说大到每个阶段，小到每个系统都是不断迭代改进的。 为什么要用这样的方式？大家不妨思考一下，如果把这几个步骤反过来，先做业务的改造，再做架构的升级可不可行。 实际中，放到当时的节点，你要考虑的问题不仅是技术上的改造问题，还要考虑到你的团队的接受度，看怎样才能用一种新的模式让大家更容易理解和接受。 58这么做的效果也比较明显，过去一年多的实践，基本上形成了一个非常好的多赢局面，可以看到系统的性能提升了1~10倍，稳定性也有了10倍的提升，同时效率得到大大改善，因为我们用了很多的简化设计，内部耦合依赖度大大减小，成本也下降为原来的1/2~1/3。 因此，一个好的技术决策和技术实施，是可以达成一个多赢的局面的，而且我们可以得出清醒的判断和结论，这样的改善不是短期的，而是长期并且可以持续去改善的。 中间也诞生了一些做得非常不错的系统，像我们自研的KV存储系统，每天1000亿次访问，还能做到毫秒级超低延迟，同时它的可靠性99.999%，性能也是传统的10倍左右，而且基本上免维护。 我们做一个简单的回顾，这中间决策的难点和动态决策的需要考虑是什么？还是回到开始的这张图，这里有几个非常重要的关键点。
第二，动态思维体现在整个目标是明确的，但是决策的执行过程是动态的，要把它变成一个可执行的迭代的过程。这里面又有几个要点需要关注。 1.正如刚刚讲的，目标一定要非常明确，不能轻易变，但是你执行的过程可以是动态的，可以选择不同的路径。 2.在改变的过程中必须要考虑到技术之外的问题，比如公司文化和团队对变革和新模式的接受度。这是一个自然存在的现象，不能忽略，因为团队都有惯性思维，而且都有一些固有的模式。至于解决方式，则是一定要让你的团队看到新架构的好处，就是要把你整体的大决策拆分成若干个小的决策和小的系统，让每个小系统的改造都能被内部团队看到效果。这样，随着成功改造的系统增多，团队对新模式接受度也会越来越强。 这也是我们为什么一开始就做底层架构改造的原因，因为底层架构跟业务的耦合相对没有那么强，我们能在对业务几乎没有任何影响的情况下，完成这些技术的改造和升级。在这个过程中，实际上有很多同事看到了技术改造的好处。 这样，当我们再推第二阶段，去做每个业务侧的改造升级的时候，大家的接受度就非常好，原来会质疑的东西也不再质疑了，甚至有些会主动的去拥抱变化。因此，公司的文化和团队是你决策过程中必须要考虑的。 3.如果是有一定历史的公司，要考虑到有些历史系统和现状之间的平衡问题，大家可能会很容易发现过去系统中做得不理想和不到位的地方，但是一定要抓大放小，一定要有优先级，要先做重要的事情，把问题逐步解决，不能一下子全部推倒重来。 4.先业务、后技术，这可能是很多技术人员容易忽略的，就是只站在技术的视角看问题，很可能你的技术系统用了很复杂的方法，效果却还是不好。所以，这个过程中一定要先业务后技术，先做业务的分析和分解，一定要花时间，某种意义上来说，你分析的越清楚、越透，应该可以做出越简单的系统。 当你把系统做复杂了，其实是说明你业务根本没有理清楚。任何一个复杂的系统都是不可靠的，都是不好用的，都是效率低的，请大家相信，好的系统是简单的。 5.先自由选择，后规定引导，在推进过程中，一定会遇到各种各样的困难、阻力，这里跟大家分享一个原则，就是早期的时候，要让团队更多的去做自由选择，换句话说更贴近于市场经济。当你做技术改造、变革、升级，甚至推一些新技术的时候，内部总会有一些团队更愿意尝试和拥抱新的东西，因此就需要尊重大家的自由选择，愿意做的团队先做，不愿意的团队没关系，晚一点再说，等有了好的样板之后接受的团队自然会越来越多。 到后期就需要做更多的规划和引导了，比方说十个团队中已经有六七个团队在用了，并且大家都觉得好，只有那两三个团队总是不用，那会儿就不能再让他自由选择了，可以做更多的主动推动和变革，因为你已经非常清楚这个模式已经经过充分验证，是没有问题的。 因此，早期要先自由选择，后期可以规划引导，千万不能倒过来，否则很多事情强推了，大家不接受，反倒会有问题，例如强推一段时间之后发现推不动，就不再坚持了，后面变成大家自由选择，那到最后结果就全乱了，我接触过一些这样的情况，大家一定要避免。 基本上回过头再看，站在58的视角，我们的业务、组织、人才的变化基本上印证了过去预测的情况，业务确实变得越来越垂直化；平台+BG化的模式非常清晰，需要我们强化平台和内部云服务，让业务侧能够更快速反应。 另外，我们发现，整个技术改造的过程，实际上也是人才迭代升级的过程。原来大家的技术视野、技术能力在一个水准，当你有一些新的系统给大家变化、让大家应用的时候，会发现人才的能力是在提升的。如果能在这个过程中，把人才的升级迭代和技术升级结合在一起，到后面越长远的时间效果就会越好，甚至到后期还会自我循环和自我运转。 |
|
|
