面向互联网的技术团队建设的一些想法

【管理部分】

谈谈互联网产品开发的特点

互联网的产品大都是面向海量用户的服务，且用户分布区域广泛，其教育水平、习惯也大多不同，具有高度不确定性，我们必须非常关注用户的行为和反馈。因而，在互联网产品服务的整个用户研究，需求分析、产品研发及交付服务的过程中，都采用探索式、适应性的研发理念进行产品的研发。通常，会把整个产品研发周期划分为若干个迭代，采用迭代式的演进过程，不断的去交付新的产品特性，并通过观察用户的行为和反馈获取，进而随时调整产品的思路和方向。一切以用户价值为核心是互联网产品最核心的特点，而以价值驱动的敏捷开发方法非常符合这一特点。

敏捷项目管理实践，通过小步快跑，快速迭代、增量交付用户价值，不断获取用户反馈，持续、快速的调整产品，验证并适合用户价值。正是通过这些实践活动，我们以迭代的、增量的交付用户价值，最大限度的保证产品朝着符合用户实际需求方向发展。

谈谈技术团队

基于互联网业务的敏捷团队，大部分大型的互联网公司都偏向以下三种文化或者原则：

１)、自组织文化

如google、facebook等互联网企业，他们很少甚至没有特定的项目流程，通常怎么敏捷怎么做，具有浓厚的工程师驱动文化。敏捷团队的自组织特性弱化了团队技术领导这个角色，强调自我管理和自我驱动，对于每个人的能力和素质要求更高，但是会让我们做的更高效、更敏捷，可以走的更稳、更远。

２）、追求一体化

一体化团队作为敏捷开发方法中最具精益思想基因的实践，是指每个项目团队包括分析，开发，测试等角色，使团队满足一个需求从设计，开发到测试各个阶段顺利完成，达到符合质量标准并满足需求的软件。每个一体化团队一般都依附于某个产品，每个角色都为产品的发展贡献着自己的智慧。

3）、追求全功能

这里所指的全功能是希望项目团队能打破工程师角色之间的边界，如研发、测试和前端工程师的界线，消除开发、测试流程中一些潜在浪费，提高效率。在项目团队内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。

为什么要提倡打破边界？项目整体效率依赖于项目过程中各环节的工作效率，而整体效率的优化往往依赖于均衡生产，即消除生产的波峰(过度生产)和波谷(生产不足)，只有局部效率的增加无法直接转换为整体效率的增加(就象桶能装多少水，决定于最短的那块板)。整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。[对小团队尤其重要，这也是风险管理所需要的。大团队每个角色和岗位都会设置若干人，通过人数的优势达到了均衡生产，但对于小团队，某个角色可能只有一个人力，如果这个人工作受到影响，整个团队的链条都要受到很大的影响，打破角色的界限，最大限度的降低了这些风险]

技术团队的建设首先要从两个方面入手，一个是专业化分工，二是梯队作战模型。追求全功能或者均衡生产，并不是说每个人不分主次的全面发展，而是在保证一定的专业分工、深入专研的基础上，在技能上要有适当的广度。比如在我们团队，按照技术领域可以做以下组织模型：

目前团队成员还比较少，如果每个人都均衡发展，对于技术体系就不会深入；但是如果都划定清晰的方向，只走专业化路线，意味着每个方向只有一两个人，项目开展就很难调动人力，这也是不可能的。所以每个方向固定第一梯队的人员，在该方向上能够专业化发展，同时每个方向的第一梯队的人员又将是其他方向的第二梯队，保证人力资源能够均衡的被调配，满足各种项目的开展。同样在岗位上，我们依然是按照这个思路来进行，每个人都应具备“架构设计”、“程序开发”、“质量测试”的部分能力，打破角色之间的界限。这对每个人的整体素质要求是非常高的。

除了专业化分工之外，我们还需要建立梯队模型，将人力资源和时间分配的更加均衡。如下图所示：

这是一个漏斗模型，在人力和时间分配方面，自上而下优先级逐级递减。项目开发直接面对着需求，它的核心是“快”，要有快速响应需求的能力，以最快的进度完成产品的增量交付。为了更快的响应，在架构设计、程序开发方面遵循“适可而止”的原则，不要过度设计，在可容忍的范围内可以适当降低程序的质量。如果仅仅只做这些，我们的产品和系统是早晚都会出现问题，所以我们还需要下一个环节：产品优化。这个环节的核心是“精”，精益求精，将以前的瑕疵、隐患去除掉，考虑到更久的将来，不断地调整我们的架构，不断优化我们的程序，整个改进的进程和系统的发展进程相呼应，保证系统的平滑发展。仅仅这些就够了吗？显然不够！项目开发如何快？产品优化如何精？源于我们深厚的积累，研发的重要性就是体现在厚积薄发，全面提升整个团队的技术厚度，提高开发的效率。我们团队有自己的框架和平台，大大的加快了我们项目开发的速度。

通过这个漏斗模型，我们将人力和时间按照这个层次结构，进行均匀的分配，保证我们的计划进度的执行非常平滑，没有过分的紧张，也没有过度的松懈。将以往我们的开发如过山车般的进程变成在一条平路上匀速前行。

谈谈CMMI

公司最近在搞CMMI3，过程的持续改进是我们一直都需要去做的，引入CMMI，可以帮我们更好的进行过程的改进。我们的团队涉足企业信息化，软件项目和互联网项目，其实每件事物都有它自己特定的环境，都有自己繁衍的土壤，我们在这个过程中一定要有区别的对待，真正的遵循事物发展的规律，否则好心不一定能做好事。

各大软件公司搞CMMI 基本都是招标用的，这是中标的一个有力的砝码，更适合B2B的公司。而互联网公司，他们根本的生存法则不是依赖外包项目，产品销售进行的，而是针对终端用户推出的服务产品，提供非常好的使用体验，获得用户的认可，从而获得公司的发展。所以这就是为什么做互联网的企业很少去评CMMI，很多一流的互联网公司的产品研发过程甚至都达不到CMMI的要求。

网上对于这方面的讨论也特别多，但是我们既然要做CMMI，是因为我们还有软件开发的业务范围，我们也真正的想通过CMMI提升整个团队的研发水平，改进我们的过程。但是我也真心的希望CMMI在进行的过程中，一定是能深入到不同的项目团队，探究每个项目和业务方向的特点，找出适合每个团队发展的业务流程和管理模式，而不要凡事一刀切，一个标准，一个模式，或者更可怕的是将以往实施的案例不加考量的就转移到我们身上，反过来成为我们前进的阻力。

分享网上的一些观点：

互联网中小企业，CMM/CMMI 应当缓行

是什么让互联网公司无法达到 CMMI 评定要求？

我一年前的博客：

CMMI和敏捷双剑合璧的一点点看法

【技术部分】

谈谈技术

作为技术团队的负责人，我一直在思考我们需要什么样的技术，特别像我们整个团队和领导都具有企业应用开发的背景，如何适应互联网应用开发的需要，如何要转变观念，用合适的技术解决特定领域的问题。

在谈具体技术之前，我想还是和我们以前一直从事的企业应用开发做一个比较，这样我们能更加直观的知道我们需要做哪些改变，哪些才是我们未来的技术方向。

 

	企业应用	互联网应用
行业领域	区分行业，各自领域业务背景不一样，并形成了一定的门槛。	跨行业，按应用类型区分，比如blog，wiki，个人门店等。
业务逻辑	业务逻辑复杂，涉及大量的数据和多人协同处理。（适合采用EA、ROSE等UML设计工具进行复杂的设计）	业务逻辑简单，大部分是通过页面进行数据的增删改查。
数据一致性	强调数据一致性，需要通过事务，交易中间件，数据库锁，java同步机制来保证数据的一致性。	要求有事务，但和高并发博弈中，让位给高并发。
数据复杂度	数据复杂，有大量的表，表之间有复杂的牵涉关系，在某些行业维护这些表之间的关系和数据就需要一个团队。	数据不复杂，表之间的关联不多
并发量	不是特别大，比如通用应用为100~200并发，重度并发500的系统就能满足国内大部分的系统要求。	强调高并发，支持用户数量多，并采取企业开发中极少采用的技术，比如web反向代理，memcache（分布式缓存），表的垂直分隔、水平分隔，强调高速读低速写。支持百万用户。
系统集成	关键系统需要和很多外部系统集成，集成的方式可能采取esb，jms，web service，socket	弱。极少需要和其他系统集成。集成的方式采用轻量级的webservice，如restful风格的webservice，甚至还有javascript和iframe的方式
用户交互	强调界面交互和数据表达，需要支持多种数据展现方式，需要众多数据在页面上的展现，传输	弱。交互不多，表现方式简单，更多的是数据的增删改查。 但对用户的操作和使用体验要求特别高。
开发过程	强调软件过程，讲究行业经验，需要撰写大量的文档和多人的协同，需要版本控制和问题跟踪回溯。	强调敏捷，快速开发，基本不需要版本控制。

 

根据这个表格，我们非常明显的看到企业应用和互联网应用的巨大不同，应用的不同决定了技术的差异，企业应用要求系统的稳定性、程序的复用性、数据操作的严谨性、业务的集成性，而互联网应用要求高并发、高扩展、高可用性。通过下面的表格，我们从各种技术方面，直观的看到我们需要什么样的技术，哪些是我们已经具有的，哪些是我们需要不断完善的。

 

	企业应用	互联网应用	备注说明
开发语言或平台	Java、.NET等	PHP,Java,.NET,Ruby,Python等	企业应用普遍采用成熟稳定、面向对象的语言，而互联网应用普遍采用语法简单，能快速开发的动态语言。
操作系统或运行环境	Linux，Unix，WinServer	Linux，WinServer	在这一点上，两种应用基本都会采用Linux系统，这和采用跨平台的语言和操作系统本身的特点有关。企业应用可能会绑定一些商用的操作系统
关系数据库	Oracle，DB2，MSSQL	MySQL、MSSQL、PostgreSQL	企业级市场，Oracle是老大，互联网市场MySQL是王者。戏剧性的是两种数据库都归属于Oracle公司了。随着Oracle公司对MySQL的控制，人们开始逐渐选择其他数据库，比如PostgreSQL
NoSQL	EHCache，JBossCache等	Memcached、MongoDB、Hadoop、Redis，Membase等	企业应用由于对于数据一致性的要求特别高，一般不采用非关系数据库。但是互联网应用要解决在高并发访问下的快速的读，会大量的采用NoSQL的方案，比如Memcached这是使用最多的。随着互联网应用的蓬勃发展，越来越多的NoSQL被采用来解决某一领域的问题，比如海量数据的存储及分布式计算（Hadoop、MongoDB等），基于内存的快速读取（Redis等）
服务器	JBoss、Weblogic、IIS、GlassFish、Tomcat	Apache、Tomcat、IIS、Jetty、Nginx、Squid等	企业应用一般采用计算性能高的商业应用服务器；而互联网应用一般会采用开源的轻量级的web服务器，但是由于互联网自身轻计算，重并发的特点，一般会分为代理服务器，缓存服务器，负载均衡服务器等几个层次。
其他	消息服务、SOAP、流程化、平台化、数据仓库、BI等	消息服务、rest、前端开发技术、海量数据存储、图片处理、搜索技术、分布式实时计算、数据挖掘等	企业应用注重对业务的梳理、数据的复杂查询计算和管理、强调单点服务器和数据库的计算能力。而互联网应用侧重于前端技术的应用以增强用户体验、需要大量的图片处理和读取，需要架构文件服务，在架构上更加侧重水平扩展能力（包括应用、数据库等），数据库的地位相比企业应用来说要降低很多，取而代之的是采用各种各样的技术实现高并发、高负载。

 

对于我们团队，我们的业务主要在互联网领域开展，但是我们的管理又属于企业应用的范畴，我们的开发领域基本囊括了企业应用和互联网应用，所以对于技术团队的要求是非常非常高的，我们不仅仅根据不同的领域进行专业化划分，我们更需要学习更多更实用的技术解决各个领域的问题。

谈谈架构设计

我们张口闭口的谈架构，但是何为架构，可能谁也说不清楚，因为大家对架构的理解不同。从字面的意思来讲，架构就是确定一个事物的骨架和结构，从整体上勾勒出事物的意识形态。架构又分为很多种，管理企业需要进行组织架构，就IT而言，实施系统需要系统架构和业务架构，开发软件需要软件架构，还有信息架构、基础架构、数据库架构等等。我们在讨论架构时，总是意见分歧很大，是因为我们并没有为“架构”设立边界，不同的人对架构的定义是不一样的。下面我谈的架构主要集中在系统架构和软件架构。

我对架构和架构师的一些认识和观点：

Ø 软件架构设计需要以长远的眼光以宏观视角从整体出发，深入分析外部环境、竞争对手与内部资源，明晰各方面的关注点，并平衡他们之间的利益，使大家可以明确目标，达成共识，解决主要矛盾。

Ø 架构师一定要有全局意识，不能过多的纠缠于细节。架构可以不过多关注功能，但必须考虑系统运行的场景和所处的领域，明晰关键点。

Ø 架构是一种平衡的艺术，最好的架构不是最完美的架构而是最适合未来一段时间的架构，架构要考虑到未来发展和当前资源的平衡，将性价比放在第一位考虑。

Ø 架构的确不容易改变，一个易变的架构不是好的架构，但是一个不能改变的架构也不是好的架构。架构的可变性也应该是架构设计的一部分，所以架构师要致力于设计一个可容易扩展的架构，在这方面如果我们经常拿盖房子作为比较是不合理的，软件架构的可伸缩性本身就是区别于传统行业架构设计的魅力所在。

Ø 架构师不仅仅有深厚的专业知识和技能，架构师必须具备必要的广度，特别是当前一个信息爆炸的时代，我们所遇到的各种情形都在当前的信息池中找到相应的解决方法和案例。架构师一定要掌握更多的信息，对信息进行系统的加工整理，在架构工作中首要想的是如何使用现有的解决方案，而不是闭门造车，不开放的醉心专研，重复发明轮子。现在有这么个说法，“掌握信息比掌握知识重要”，不是没有道理。

谈谈运维

单谈运维他是一个很泛的概念，有人认为很高深，有人可能没啥概念。其实运维是IT管理中一个很重要的环节，我们生产的系统如果没有运维的支持，它便存在着巨大的风险。我们一直在谈企业应用和互联网应用的区别，其实两者的区别也决定了这两个领域的运维也存在着很大的区别。

传统企业内网运维关注点是在安全、权限管理等重点，以及旧IT资产利用率，如何利用好现有的IT资产是他们目前迫切需要解决的问题。传统的企业内网，使用大量的小型机（IBM Power小型机、HP小型机、Sun小型机等）、高端网络和存储设备（Cisco、EMC、日立等），使用大量的商业数据库、ERP和中间件技术（IBM DB2、Oracle、SAP等）。企业的核心业务运行于这些设备和软件之上，业务年限长、历史遗留问题多，数据安全、业务连续性等是这些企业的生命线，往往通过购买厂商和集成商的服务来保证其IT业务的稳定性。
对于互联网运维，如何快速有效地部署，如何保证可利用率，如何处理大并发访问等是他们的头等要事。现代的互联网企业，大量使用PC服务器、普通硬盘盘阵和集群、先进的SSD技术，大量使用Linux、MySQL等开源软件。业务模式单一，软件技术、硬件设备更替迅速。性能优化、部署灵活、提升IT硬件利用率是他们的工作重点，业务领先的互联网企业背后都有一个强大的IT运维技术团队。

运维是一件极其繁琐，极其复杂的管理工作，这就要求运维工程师具有很广博的知识体系，不仅仅熟悉网络、硬件，还要了解开发，了解各个系统使用的技术和软件，通过大量的运维数据可以有效地指导架构和系统的优化，运维工程师一个典型的复合型的人才。

运维工程师的岗位职责：

　　1. 负责机房业务服务器的配置，维护，监控，调优，故障排除等；

　　2. 大用户量下高性能服务器系统部署方案的制定及实施；

　　3. 保障服务器与数据库安全，检查并消除安全漏洞；

　　4. 数据备份、数据监控、应急响应、故障排除、编写数据分析报告等。

就像我在谈架构时认为架构需要关注运维，指导开发一样，我还认为运维是关注开发、指导架构，一个好的架构师需要经过运维的过程，他才能深刻的预判到一个系统在未来的演变，以便今天可以实时可以扩展的架构。一个具备较高开发水平的运维工程师是向架构师进阶的最好路线。

谈谈云

当前云是一个很热的话题，所有的软件服务都尽可能的和“云”搭上边，但是具体什么是“云”，相比很多人都“云里雾里”的，不知所以。

“云计算”的概念应该是谷歌在5年前提出来，并得到快速的发展。“云”的诞生有其发展的必然性，而谷歌、亚马逊这样的互联网巨头是催发它的催化剂。这些互联网公司的核心的商业模式就是利用提供互联网相关的服务，从而带来巨额的营收，他们必然希望越来越多的人和企业接受互联网服务的模式，让一切服务都能通过互联网替代传统的方式，所以宣扬“云”，也是为了更加优化自己的商业模式。其次，这些巨头企业经过这么多年的发展，他们在服务器，数据中心，分布式计算方面建立起成熟的有效的解决方案，仅仅是为了支撑自身的服务，资源势必不能很好的利用，推行云计算，将自己的基础设施和平台以服务的方式出租出去，将闲置的资源加以更加合理的利用，这也是推行“云”的原因。“利”字当头，任何一个事物的发展怎能少了一个“利”。当然 “云”的发展给我们的信息生活带来了翻天覆地的变化，推动着整个信息产业的变革。

1、“云”让基础设施的建设更加集中，互联网服务更加的规模化，资源的分配更加的合理，避免了巨大的浪费。

2、“云”让我们的观念发生了转变，让我们更加接受互联网服务模式，为人类的生活提供了更大的便利。

3、“云”的诞生更加优化了互联网的服务模式，提升了互联网服务的盈利能力。

“云”其实就是“服务”，一切传统的信息处理的手段都通过服务的方式进行交付。而在服务上，又分为几个层次：IaaS（基础设施既是服务），PaaS（平台既是服务），SaaS（软件既是服务）。而在IaaS和PaaS层面上，一般由大型的厂商承担着，比如亚马逊、微软、谷歌等等，他们拥有天生的资源来做这些底层的，具有规模化的基础设施建设。而在中国，这些一般由政府驱动，由大型厂商来承接。中小型的公司只能在SaaS上，提供更加细分、更加个性化的软件服务，才是生存的王道。

我们张口闭口谈“云”，我们是“云笔记”，“云相册”，如果服务不具备规模化效益，没有将服务转化为盈利的能力，这个“云”只能算是一个普通的互联网服务，和个人博客和个人相册有什么区别。所以我们要做“云服务”，我们需要在基础设施、大数据计算方面有一定的掌握能力，这些不需要我们去创造，而是能很好的利用，将“云”相关的技术（虚拟化，mapreduce分布式计算，海量数据存储、负载集群等）很好的运用起来，这是支撑云的基础。在这个基础上，一定要做细分的“云”，有特点的“云”，提供用户最专业的个性化服务和解决方案，服务产生价值。

谈谈移动应用

上面谈了“云”，有“云”必然有“端”，“云”是服务的提供，“端”是服务的消费。目前最重要的两个端是PC端和移动终端，未来物联网建立，所有事物都俨然是“端”，在PC端，依然是传统的浏览器和客户端。随着移动互联网的发展，越来越多的服务已经开始向移动终端倾斜，利用移动终端的便利性，服务的提供和消费也变得越来越快捷。未来移动应用将带来一个崭新的时代，一个属于移动互联网的时代开始了。

但是目前为止，大部分的移动应用及其服务都没有非常好的盈利模式，依然处在“赔钱赚吆喝”的乱战中，移动互联网毕竟是传播介质的新的表现形式，而不是新的商业模式的建立。在国外由于知识产权的健全和对软件服务的尊重，移动互联网的发展更好一些。而在我国，单纯的依赖移动终端而实现自身商业模式的应用少之又少，大部分做的好应用还是集中在一些具有沉淀的大型厂商，就像腾讯，他的所有的移动应用都有很好的发展。他们不会将移动应用当成新的商业模式，而是变成对其原有的商业模式的一种优化，通过更多的端产品的提供，提供用户更多服务消费的出口，从而扩大其原有商业能力。

在移动应用的技术领域中，我们需要面对多个平台（ios，android，wp等），每个平台可能还需要面对不同设备的规格，移动开发也面临这很多很多的问题。很多厂商也在致力于利用一些中间的语言和技术来统一移动领域的开发，比如目前以html5、javascript、ruby等中间件平台也开始蓬勃发展起来了。最近google推出了将java转化为object-c的工具。未来的移动开发必然要面临也需要我们考虑如何解决跨平台的问题，特别对于中小企业，处于成本的考虑，我们也将不得不面对。

目前，我们要解决的是如何将原生语言和跨平台语言的结合，因为一个服务，多个终端，业务处理逻辑都是相同的，不同的更多是在UI层面和交互层面上。所以通过和中间语言的结合，比如javascript、lua等，可以更加优化移动应用的开发，降低开发和维护的成本，而且多个端都可以在一个统一有序的环境中发展。

 

http://www.oecp.cn/hi/yongtree/blog/1168609