王晓波：公司快速发展期，同程的技术团队管理演变之路
为了加深EGO会员之间的相互了解，同时也为大家提供更多线上相互学习交流的机会，EGO正式启动会员群线上分享活动。本文是根据王晓波分享主题“同程的技术团队管理演变之路”的内容整理而成。
随着公司快速的发展、业务的增长、流量的增加、订单的爆增，你会不会发现原有的系统开始逐显疲态，故障频出、弊端不断地显露、扩展性遇到瓶颈、系统显得越加臃肿等方面的问题开始不断出现。此时，系统对业务的发展逐渐表现的力不从心，这时，我们需要对系统和整个技术团队进行一次全面的体检，让他们健康的进化。具体来讲，我们应该如何做、如何去实现这个目标呢？接下来，EGO会员、同程旅游LY.com首席架构师王晓波为我们分享他的技术团队管理演变之路。
对于文章开头提到的公司快速发展期在技术上面临的那些问题，仔细分析之后我们会发现痛点如下：
1. 薄弱的系统基础
原来在流量较少时设计的系统，在技术架构上存在着固有的瓶颈。之前为了快速上线而仓促开发的系统基本上没有扩展能力，各系统之间的关系也不甚合理。
这可以总结为：技术老旧单一、技术的深度不够、架构不合理、基础能力支持弱。这里表现的现象就是在流量压力下，系统存在处处风险、处处宕机。
2. 整体运维体系上的不足
原来系统较小时整个运维体系比较薄弱，运维体系较小，没有形成一整套运维的基础技术体系，只是一小队人员在做着发布、重启等基础的运维工作。当系统增大时，这就会出现各种混乱，如每台机器上部署了什么、互相之间的关系又是什么、当故障发生时究竟是哪里在报错等，这就好像运维人员永远都不知道开发人员在做什么。
这可以总结为：完全的人肉运维、自动化程度不够、运维无开发能力。这里表现的现象就是故障频发、处理速度慢和处处受到指责。
3. 在系统安全方面投入少
之前很少被人关注的安全问题这几年成为一个个的大热点。而我们之前在这一块的投入相对较少，甚至说安全是什么、该怎么做，都感觉无从下手。
这可以总结为：安全还停留在口号上、没有专业的安全工程师、安全相关的技术能力较差。这里表现的现象就是每当看到其他网站的漏洞被曝时，总是担心自己是否也存在这样的的安全漏洞，但却无从下手改变这一切。
4. 系统的其他方面也存在问题
再从另外的一些角度来看:交易订单、客户体验、系统处理的及时性、系统的性能、功能的可扩展性、系统的可伸缩性等方面也均出现了问题。
图1
对于业务来说，这样的系统无法很好的起到支撑作用，所以，这就到了我们必须要改变的时候。
那么，诸多的痛点是因何而产生呢？是我们能力太差？是我们投入不够？还是我们对技术不够钻研？
其实都不是。这是企业从弱小变强大的一个必然过程。在我们网站还比较小的时候，我们往往把精力都集中在业务的创新上。这时表现为，很多功能都是因业务而产生的灵感创作。这时系统的流量压力也比较小，所以在此时系统最重要的是支持业务的快速迭代，然而在技术上考虑并不多，事实上留给技术的思考和开发成本较少，但也就是因为这种模式，业务才能快速成长带来更多的流量。
然而在这样一天天的成长壮大中，我们的流量越来越大，这时对于技术而言就产生了技术的债务。我们对它仔细分析之后发现，债务主要集中在以下几个方面：
系统基础技术的债务：长时间的快速迭代过程中对于基础技术的投入过少，导致业务系统所依赖的基础架构不稳定。
人员的债务：长期的快速开发导致我们拥有了很好的业务系统开发人员，但是对于像基础框架、运维、安全等基础层面的工程师准备不足。
快速开发的债务：在之前的快速开发中，我们舍弃了很多应当被考虑的技术细节，这些细节在流量不大时没有显现。然而随着流量的变大，这些缺失的技术细节产生的问题也越来越大。
所以我们应该从清理技术债务这个角度去对我们的痛点进行一一反思。
图2
总而言之，我们需要对整体的技术架构进行升级，对我们的基础技术工程师团队进行大量的建设，对我们的一些业务系统进行重构。这时，我们的技术团队就需要一批更加优秀的新鲜血液。
那么在技术升级和演变过程中，我们究竟需要一支什么样的技术团队来完成新老技术体系更替的这个过程呢?我们现在再回忆一下之前对于痛点的分析。
首先，我们目前的团队已经能比较好的应对业务需求的开发，但是我们系统在流量压力增大之后，处于一个不稳定的状态。这个问题的原因在于我们目前对于基础中间件的研发能力太弱小，团队缺乏底层基础技术开发细胞。所以，基础研发急需引入优秀的技术细胞。
其次，我们目前的运维体系比较老旧，团队人员基本处于发布、重启、上服务器等基础操作的工作状态，缺乏对运维整体的思考、监控和自动化。这样的工作状态会导致运维工作人员进入一个无序、繁杂的死循环。因此，运维团队急需进行整体升级。
最后，目前我们对于诸如安全之类新的挑战，现有团队的技术处于空白状态，完全无法应对这类挑战。所以为了让我们的团队具备这样的能力，急需组建一支面对这类新挑战的技术团队，从而保障我们系统的可控性。
1、人才培养
现在我们已经知道问题的所在，问题看似复杂，但归结为一点就是我们需要培养或引进更好的技术人才，让我们团队更具有技术上的战斗力来解决这些问题。这里我们谈到了培养和引进，那么我们首先来讨论一下如何从现有的技术团队中培养出优秀的人才。
现有的技术团队中其实也不乏有潜力的、对技术钻研狂热的技术爱好分子，但是受限于目前的技术环境、眼界和认识不够，对于这类人我们需要打开他们的技术眼界，指明他们的技术发展学习道路。
2、人才招聘
当然我们不能完全以培养这种方式来补足所有我们需要的技术人才，这里就必须从外部引进。说到引进人才这个话题，这就是业内老大难的问题了——“痛苦的招聘”。
我们回过头来仔细想想，这样的招聘真的有那么痛苦吗？其实根本的原因还在于我们没有真正的想好我们需要什么样的人、从哪里去找这些人。最有效的方式恐怕大多数人都会想到，去一些BAT类型的互联网公司挖角，但往往这种方式很难行得通，因为现在所能提供的技术环境和这类公司是无法相比的，在这时可能除了金钱，没有第二种方式去吸引这些人了。所以我们的办法是先营造一个良好的技术氛围、明确我们的工作目标。
所以，我们需要的是一个具有良好的技术氛围，并且有明确的技术目标的一个团队，这样才能有效的解决现有的问题。当然这里说起来很简单，想要团队拥有这样的良性循环，我们更多的是需要去运营这个团队，而非只是简单的组建这个团队。
一个良好的团队应该让团队的绝大部分成员都能发挥出自己应有的能力，并且有明确的发展目标，这里就像一个企业一样，它需要经营而不是纯粹的管理。既然要经营它，那么我们想一下，哪些方面是需要经营的呢？
首先，技术的工作是一个团队的工作，团队中虽然拥有了很多优秀的技术骨干，但是如何更好的将他们搭配起来产生1+1大于2的效果，是经营好这个团队的基本要素。
因为每个开发者总有他擅长和不擅长的方面，团队中的每个小组其实应该由擅长各个方向的不同人员组合而成。
经过我们进一步分析之后，这个问题其实就是团队人员配置问题要解决很简单，我们不应该只依赖两个大神，而是应该给他们一个完整的团队，所以我们在这个团队中又配备了代码研发人员和硬件设备管理人员。到现在，同程的这个安全团队已经在安全业内小有名气，做出很多业内称赞的东西，比如，开放所有的漏洞供社区学习等。
图3
所以，经营团队的首要目标就是要让团队的每一个小组拥有一个完整的生态系统，一个可以互相搭配着干活的团队。
一个搭配比较合理的团队，只是团队经营的一个基础，在团队的整个日常工作中，我们还需要用更多开放的心态去运作团队的交流和学习。在这里，可能会有人有这样的想法:好不容易招来的人，如果出去参与交流会存在被挖角的可能，所以应该把他们藏起来。但是这样的想法恰恰是这些人准备离开的原因之一，因为团队在限制他。我们的做法是更多的去想一想这些人为什么加入我们并在这里长期发展。正是因为我们的开放、我们在社区的交流、我们对技术的追求才使得他们在这里更有激情的为团队的目标去奋斗。所以，我们应该更大的程度去鼓励交流，这样才能让团队更好的成长和补足自己的缺点。
在这里我举个例子，我们的运维团队的发展，起初我们的运维团队处于重复劳动的状态，为了提升团队，我们也招聘到了有很好运维技术能力的人员加入团队，并且自己也规划了发展的方向和目标，但是我们觉得这样还不够，总感觉业内还有更新的前沿的知识，我们还是不知道。所以我们带着团队进行了多家公司的走访和学习交流，学习的对象小到创业型公司，大到BAT级别的公司，在这过程中我们认识到，运维在今天已不是单纯的自动化就能满足了，它应该正在发生着一场更大革命（devops的思想），所以我们对运维团队重新进行了一个规划。
图4
如今，在这个团队的努力下，我们已经完成了运维的整体系统化、基础设施的云化，线上也有近3000个实例的Docker容器正在运行。最后，在有开发的氛围、搭配合理的团队基础上，作为团队的管理者应该将更多的技术管理权限下放，让每一个小团队更加自由的去发挥自己的特长，不要过多的约束他们。但是也不是完全的放纵，作为整个大团队的管理者应该更多的从技术方向性的角度去引导技术的走向，而非关注实施的技术细节。
经营好一个团队是一门很深的学问，这里只是探讨了几个常见的思路，除了经营之外，我们还需要关注整个团队技术人员的可持续发展，这样才能保证团队的良性发展。
任何一个团队都不可能长时间的保持人员不流失、永远是同一批人在奋斗。团队的人员流动是一个团队健康成长过程中必须面对的一个事情。那么，怎样去做好团队的新陈代谢，使团队可持续发展下去，这也是值得我们探讨的。
我们应该更多的去发掘团队内部新成员的成长，让他们有足够的空间去长大，而且需要不停的引进新鲜血液，哪怕这时候团队需求并不是非常的强烈。这些新人的进入会给团队带入新的思想，同时也会让团队内部保持良好的竞争状态，当然这里也不能过度竞争。另外，我们认为任何一个团队的领导者必须提升自身的技术修养，因为，技术每天都在日新月异的变化，如果领导者对新技术不敏感，那么会导致原来很有技术前瞻性的团队慢慢变为我们需要去革命的老思想团队。
团队的自身学习性，也是团队可持续性发展的一个关键点，在这里我们可以更好的去营造学习气氛，让团队所有人都喜欢学习，对新技术保持一种敏感的追踪态度，不排斥新技术的引入，大胆的在项目中尝试。
团队的可持续发展也是我们对于技术团队管理之中非常重要的一个环节，它关系着整个团队的未来发展。
以上正是我们在整个技术团队管理演化之路上的经验和认识。一切过程全是为了系统的更快、更稳和更好。从总结角度来看我们做了这样的几件事:
发现问题的核心:我们必须发现当前问题的核心点在哪里，在我们的处理过程中，我们的核心是对技术债务的清理。
明确我们需要什么样的技术团队来解决技术债务，这个作为团队发展的第一要务进行处理。
我们如何找到优秀的技术人员组建我们的技术团队，这应该是内外兼修的一个过程。
一个团队不仅在于组建，还需要更多的经营，这才能真正的让团队发挥自己的价值。
团队的可持续发展不容忽视，这直接关系到整个团队的未来。
问题1：为新产品研发做技术方案和框架选择，您会从哪些方面考虑？
答：如果是一个新产品系统框架的选择，一般我们会从这样几个方向考虑:首先是要考虑这个项目的开发周期是否很紧，这个用来决定选择哪个更快速的框架。其次考虑的是这个应用维护多长时间，这个用来决定选择何种更稳定的框架。其次就是对于目前人力资源的考虑，这个决定了我们选择技术难度的问题，如果人员能力一般，就不能选择太深入复杂的技术。最后，我们考虑的是技术的方向性，我们需要一个更加持有稳定发展的技术方向，因为这个决定我们未来如何改造这个系统。
问题2：在网站早期，如何在硬件不升级的基础上优化网站的性能？
答:这个问题首先从业务上分析，对于一个初期的网站来说首先看一下能否动静分离，让静态部分做好更多缓存。对于动态部分代码进一步优化并在数据层做好分析，在可以的情况下对一切可以缓存的数据进行缓存，哪怕是10分钟。然后对数据库的每一条sql进行必要的优化和对表结构的优化。当然这些更多的是要居于业务的角度去考虑。
问题3：你们是自己建的Docker容器云吗？
答:这是我们自己建的Docker容器云，在Docker上面，我们认为Docker本身的基础功能是比较稳定的，只是一些新的想法还比较激进。我们在使用过程中也是用其基本功能并进一步的推进新功能的引入，当然这个我们是逐步进行的。对于Docker，我们的主要考虑是容器技术在建私有云时，它的优势非常明显而且也足够的轻。这个话题比较长后面可以详细讨论。
问题4：你们是否使用了微服务架构，如何拆分微服务的大小颗粒度?
答：我们的服务框架能做到治理、注册等等。在微服务上面我们也在推进，但并没有完全使用微服务化。对于拆分的颗粒度，我们目前的想法是必须以业务为原子单位进行拆分。
加入我们