假如我来架构12306网站---文章来自csdn（Jackxin Xu IT技术专栏）

（一）概论

序言：  此文的撰写始于国庆期间，当中因为工做过于繁忙而不断终止撰写，最近在设计另外一个电商平台时再次萌发了完善此文而且发布此文的想法，指望本身的绵薄之力可以给予各位同行一些火花，共同推动国内的大型在线交易系统的研发工做，本文更多地站在软件工程角度来看待整个问题，有关后续的技术问题研究，将在另外的博文中予以探讨。

 

   一年一度的国庆大假刚落下帷幕，因为此次长假是历史上最长的一次，所以出行问题备受关注，而铁路出行做为最主要的出行方式更是你们讨论的热点，老生常谈的购票难问题又被提起。这几天我在网站上也看到不少关于12306.cn的讨论，不少网友都发表了本身对于铁道部购票网站的不满，更有不少同行讨论了关于12306网站的设计问题，期待可以贡献本身的绵薄之力，我仔细拜读了其中至少10篇文章，不少同行可能是站在技术的角度来考虑，其中不乏不少有创意的想法，纯粹的技术设计能解决一些问题，不过彷佛不可以全面地解决这个庞大的、堪称瞬间流量“世界第一”的实时交易网站，目前12306的问题与其说是一个技术问题，还不如说它是个软件工程问题，道理很是简单，请看以下的新闻报导：

        [[[回望12306网站在2011年12月底以来的表现，铁道部高层也直呼想不到。       铁道部副部长胡亚东介绍，今年第一次在全国铁路实行网络电话订票，截至1月8日已经达到天天200万张，12306网站的注册用户已超过1000万人。1月1日至7日，“12306”网站日均点击次数已经超过了10亿次，专家认为瞬间点击可能达到了“世界第一”。         高度的关注、巨大的访问量，致使12306网站频繁出现系统崩溃、没法登录、没法支付等状况。         “像春运这样庞大的需求量，难道铁道部没有预想到并有所准备？”隆梅资本管理有限公司副总经理马宏兴对此困惑不解。       在探究12306网站问题的深层缘由以及解决之道时，各家见解不一样，“12306网站的问题最终仍是系统架构的问题。由于用户有大量的动态、交互式访问，全部的请求都会发送到12306网站的服务器端，同时在线并发用户数量太多，致使网站无力承载，形成拥堵。”华南师范大学计算机学院副院长单志龙认为。           又有说法认为，若是给12306网站增长服务器和带宽，也可以缓解拥堵的症状。这一观点铁道部内部颇为认同。       “得认可，咱们对访问量估计得不足。”铁道部信息技术中心一位中层向记者透露，12306网站曾在2011年春运期间试运行，高峰时段访问量约在1亿点击量，所以，信息中心估计2012年春运期间的访问量约在3亿至4亿。       可是，结果却大大出乎人们的预料。“12306”网站在1月9日的日点击量达到14亿次，是原来料想峰值的5倍之多。“崩溃”在所不免！]]]
笔者连日来也萌发了一个想法，假如让我来设计12306网站，我做为总架构师，该当如何考虑呢？本身虽然经历过众多的大项目的全生命周期跟踪管理，对于软件工程应该是有必定的研究，但像如此巨型项目，应该如何来设计、管控与实施？ 确实也颇伤脑筋，下面就笔者根据本身多年根植于IT研发的经验，特别是近年来对于巨型网站譬如国内的淘宝、京东等，国外的Facebook、Google等的跟踪研究经验谈谈本身的见解。
1. 需求分析阶段 需求分析是相当重要的，对于12306而言，需求分析的重点应该须要得出以下方面的关键数据才算需求分析基本结束： 终端用户方面的： 访问用户数量、整体注册用户数量、平时访问用户的峰值、平时访问用户的谷值、大假期访问用户的峰值、大假期访问用户的谷值、小假期访问用户的峰值、小假期访问用户的谷值； 用户的地域分布性、用户可能介入的设备、用户接入的网络情况统计分析； 后台服务方面的： 关键购票流程业务分析： 购票的基本流程分析、一次购票的TPS数量分析、一次购票的用户流量分析、一次购票的用户静态流量分析、一次购票的用户动态流量分析； 这其中又分为初次购票与再次购票两种状况，流程稍微有些不一样； 系统提供的其余服务统计分析； 前面所说的的大假在国内目前只有2个即春节与国庆，小假较多譬如清明、端午、中秋等。 对于用户访问用户数、流量、网络、后台的TPS数量可以创建一个数学预测模型那就很是的清晰了，对于后续的设计指导意义相当重要；
对于如此大的网站在安全性方面的需求须要作重点调研，另外因为是实时交易网站，还须要考虑金融安全问题，安全方面还得从以下两个方面来全面考虑：    内部安全，主要关注资金以及交易的安全，特别是防止内部人员尤为是系统管理员；    外部安全，主要关注如何确保拒绝外部恶意入侵与攻击成为一个核心，特别是相似DDOS之类的攻击； 对照笔者的论述以及前面的新闻内容，不难发现，12306的设计组很是明显没有充分深刻地进行需求调研与数据模型分析，特别是预案设计，所以笔者才敢说这更是个工程问题，而不彻底是个纯粹的技术问题。
2. 系统原型设计阶段 国内不少的软件公司不过重视原型设计，这点对于小软件开发可有可无，但是一旦到了大型软件的开发之时，不重视原型设计会失败得很惨，笔者曾经在后期救过一个ITSM管理系统的开发，究其缘由，其中很重要的一条是对于原型设计不过重视，特别是在应用了大量的新技术而未进行原型设计是一件风险极大的事情，在笔者亲身带的几十个项目中有一部分就是这种状况，其中几个项目的痛苦经历（通宵达昼的加班长达1-2个月）更是令我终生难忘；
根据前面的需求方面的分析讨论，不难发现12306的原型设计中须要解决的问题以下： 前端Web服务器基于巨量访问的（秒均访问千万级别）可伸缩性模式验证：    这块可供选择的技术包括以下一些：基于CDN的Internet缓存加速技术、基于Apache Server+JBoss(Weblogic)的组合服务不一样的、基于不一样接口的调用原型研究、请求排队技术等的原型研究；
后端数据库读写基于火车票应用的可扩展模式；    你们都知道，借鉴Facebook的巨量数据处理经验，必须基于现代数据库的分区技术、分布式处理技术而且经过后续的查询结果集成技术来实现巨量交易数据的可扩展性，基于巨量数据应用的可扩展模式一般有以下模式：   水平扩展技术，一般是基于分区技术来实施，维度是分区技术进行选择时的关键，针对于火车票的交易数据而言，时间维度是最好的选择，具体执行而言，能够将天天的车票交易信息放到某一分区上来执行，这样对于后续的数据维护（存储备份等）都将带来极大的方便；       垂直扩展技术，一般是基于地域等实现的分布式扩展，针对于火车票的交易数据而言，如何将不一样地域的车票、车次信息划归为不一样的数据库服务器来执行，确保在数据交易上的广域可并行性；
对于12306系统，笔者建议最好可以按照列车始发与到达站的地域性进行垂直切割，而交易数据按照时间来进行横向水平扩展造成不一样的子数据库，同时经过中间的缓存服务器、索引服务器、集成服务器将不一样的数据进行地整合过来，提供给前端的应用服务器，所以从系统架构上来看这个结构图形以下：

3. 原型验证阶段 针对系统的原型设计，须要针对相应的子系统来验证原型的技术稳定性与成熟度，具体而言分别分为以下几段： 针对前端访问的巨量级别的HTTP负载均衡子系统验证，特别是验证针对单个数据农场的服务响应能力，须要验证单个服务器的HTTP极限响应数量、动态扩展机制、网络带宽占用状况等； 针对中间访问的缓存子系统、索引子系统、集成子系统，须要验证依照前端的用户请求如何将链接到后端不一样的数据库上进行相应的数据分布化集成服务； 针对后端访问的数据库垂直、水平切割技术，基于地域的垂直切割与基于时间的水平切割技术而且结合存储方面的分布式来扩充数据库系统的事务能力；
4. 系统正式设计阶段 正式设计整个系统时要考虑的设计方面仍是挺多的，分别列出以下。 功能性设计： 前端Web服务器设计，能够按照Apache来负责静态页面响应处理、JBOSS/WEBLOGIC负责动态页面响应处理来进行设计，同时能够考虑将整个资源放到内存里面而使得Apache服务器对于静态资源的调用完全离开磁盘I/O的制限，从而最大程度上提高前端Web服务器响应能力，这点笔者在一个游戏网站的后端服务器上曾经使用过，总体的web server响应能力提高了好几倍； 具体的业务设计须要依照个业务的流程来拆解实施，此设计的关键是在于将前段的业务如何可以跟后端的高度扩展的分布数据库可以集成对应起来；
后端数据库处理系统能够考虑按照以下的模式来予以完善设计：   将前段系统的运算分解与将各服务器进行（结果集成子系统）、使用成熟的反向搜索引擎系统做为前端的车站查询系统（搜索引擎子系统）、中间基于车次的具体查询可使用缓存系统来实现（缓存子系统）、交易数据将写入到RDBMS之中（可水平、垂直扩展的事务处理子系统）； 这样设计的好处主要是将各类交易以及访问可以最大程度上的并行化，实现分布式集成化处理，从而最大程度上提高系统的总体处理能力；
存储子系统的设计： 主要是如何在RDMMS之间可以最大化各数据库的I/O处理能力同时提供不一样地域（数据农场）的数据同步服务支持，同时对于从网络条件来看，建议将不一样数据中心互联的光纤与用户请求的光纤分开了确保后端的数据同步响应不受前端的密集巨量请求服务之影响。
安全性设计： 前端的安全性设计主要包括防止诸如拒绝访问攻击(DDOS)、脚本注入攻击、用户信息安全、系统入侵等，后端的安全性设计主要是要考虑帐户信息、交易的安全等； 一般来讲，前端能够考虑基于防火墙以及各类访问监测技术来作统计分析监控各类异常状况，然后端主要是基于数据加密、交易通道安全、数据库防篡改设计等来实施。
冗余设计： 包括依照地域、用户群创建不一样的数据中心的设计、基于DNS区域解析规划设计、基于各服务器角色进行的冗余设计（WEB服务器、搜索服务器、缓存服务器、集成服务器、数据库服务器、存储服务器等）所进行的数据的冗余设计，譬如常见的集群技术、热备以及热切技术等都可考虑在此应用； 其实笔者使用了中国国内的服务器以及美国的服务器分别解析了12306.cn域名地址，显示了两个不一样的地址，这已说明12306设计组已经考虑了这些内容： 从美国PING将会发现： ping www.12306.cn PING 08911.xdwscache.glb0.lxdns.com (183.60.136.64) 56(84) bytes of data. 64 bytes from 183.60.136.64: icmp_seq=1 ttl=49 time=171 ms 64 bytes from 183.60.136.64: icmp_seq=2 ttl=49 time=171 ms
从上海PING将会发现： ping www.12306.cn Pinging 08911.xdwscache.glb0.lxdns.com [211.144.81.22] with 32 bytes of data: Reply from 211.144.81.22: bytes=32 time=11ms TTL=59 Reply from 211.144.81.22: bytes=32 time=10ms TTL=59
部署与维护设计： 部署设计的关键是确保各类角色的服务器如何可以实现快速复制扩展，在紧急须要时可以快速部署实施，同时对于服务器集群在进行升级时如何快速批量地更新整个执行包； 维护设计的关键考虑因素是系统运行的监控与报警系统设计，监控的指标就前端包括整个系统的访问数量、单个客户端的访问频率、访问的URL分布等，后端须要监控的是各服务器的使用量、负载量同时以此进行上报到监控服务器来决定相应的服务器是否须要进行动态扩展；
5. 开发实施阶段 针对于此巨型交易系统的开发，在开发阶段的关键因素是代码品质控制，建议采用软件工程成熟的Coding->Review->UT控制技术（基于TDD的开发模式）来完成个模块以及集成子系统的品质管控，在此特别提醒的是对于Review、UT段的密度须要作硬性的规定，流程裁剪时建议采用高密开发模式确保此阶段的品质管控目标，在此不得很少说一句的是不少时候不少的公司、开发人员老是错误地认为这些流程过于复杂，浪费时间，其实从各类实际的项目实施经从来看，此处多花了2-3倍的开发时间能够避免后续5-10甚至数十倍调试时间(Bug fix)的投入，总体上来算仍是很是值得的，对于大型项目尤为如此，笔者在不少大型项目的集成阶段碰到集成不顺畅、没法按时完成集成任务时，开发、测试人员都是通宵达昼地加班，这其中不少的工做都是无用功，何不在开发实施阶段将系统的测试密度进行加大呢？构建质量上更好的组件（部件、模块），这样到集成的时候就不手忙脚乱了。
因为此系统的规模很是大，所以在详细设计、开发时，应该考虑到各子系统必须设计得很是易于测试，特别是易于进行单体测试与自动化测试，这点能够大幅下降项目的执行成本;
6. 测试阶段 对此巨型系统的构建完毕后须要经历子系统集成测试、系统总集成测试两个阶段，而且须要按照以下不一样的测试种类来进行逐个测试确认：  功能测试、性能测试、安全测试、破坏性测试、持久运行能力测试等 功能测试须要针对多服务器角色集成后按照设计所提供的功能清单依据测试密度以及测试的分布性来肯定不一样方面的测试case，依据此来分步执行此功能测试，而且依照测试执行的结果来分析各个模块的缺陷密度以及缺陷的消化曲线，以此指导后期的开发设计工做，并藉此可尽快完成功能方面的验收确认；
性能测试针对这个案列相对比较复杂，因为服务器角色不少，其基本的思路仍是分析肯定前端各业务的使用比例，编写开发自动化测试脚原本模拟用户的操做行为，而且在测试环境下针对特定的服务器数量的集群发起服务请求，同时完整地检测每一个角色服务器的CPU/Memory/Disk I|O/Network方面的性能参数值，经过不断增减客户端请求数（伴随客户端机器的增长、譬如初期使用100台，逐步增长到200台测试机）来观察服务器的性能反应，分析出拐点，同时须要测试出系统的极限吞吐量(RPS,TPS等值)，而且测试出增长不一样的服务器角色对于这些吞吐量的影响，同时在此阶段须要开发人员的协助来针对不一样的角色根据测试结果进行性能调优工做；
安全测试，须要针对如下不一样的场景进行模拟攻击测试： 外部安全而言： 包括脚本注入攻击、端口扫描、拒绝服务攻击、主机入侵等安全测试都须要逐个进行验证，确保系统的外部安全； 内部安全而言： 包括各服务器的数据的安全、密码安全等进行测试；
破坏性测试，须要就各个角色服务器所对应的物理服务器进行不一样部位失效、移除等试验，看看整个服务器集群的监控、维护服务以及服务输出吞吐的影响，而且完善后续的各类系统对应的维护流程；
持久运行能力测试须要，待系统达到Beta测试版本要求以后，须要针对待部署的系统进行必定负载量持续运行至少2周以上，而且观测系统的稳定性方面的反应，同时就数据库的增加、日志的增加等各类状况进行综合评估而且须要结合后续的部署维护作适当完善性调整；
7. 部署阶段

对于如此巨型系统的部署调试工做，也是个不大不小的工程，那么如何确保部署调试工做进展的顺利，根据笔者多年维护广域网系统的经验，有以下几点须要注意：

 -> 如何管理好不一样的服务器之间的发行版本问题，确保发布不会乱，特别是小版本的升级上部署不会乱是个关键，不然对于数以千计的服务器那绝对是个灾难；

 ->如何可以快速解决单次发布的升级与回退问题一样是很重要，这当中笔者的经验是使用一个通过验证的发布部署流程以及校验流程，整个过程最后放在一个发布脚本中，对于具体的升级与回退，维护人员只须要执行一次命令便可完成，而且对于每一个版本发布完毕后的校验工做尤为重要，必须在脚本中予以体现；

 ->最后一点对于部署而言，任何部署都必需要有回滚方案配套，确保任什么时候间点上系统皆可用；

 

8. 运行维护阶段 在运行维护阶段有不少细节须要配套考虑：   ->系统总体的实时状态监控，包括各类角色的应用主机的监控、网络设备的监控、用户访问流量的监控、服务可用性监控、安全监控等；   ->系统巨量的交易数据转储、交易日志的转储问题， 这个问题的解决须要结合前面在设计时的 数据库垂直（按时间维度）扩展以及日志按照天的维度来进行维护的方式进行有计划地转储到不一样时间段的历史库中，而且经过数据的清洗、整理将部分重要数据转入到OLAP/OLTP系统中，为后续系统基于实时交易数据的联机分析改进业务提供帮助；
9. 优化阶段

  ->业务流程优化：这块最主要的问题是将购票这个核心业务按照计算机易于执行计算的模型来进行不断地优化，同时体验，譬如异步事务提交优化、排队技术等皆可使用在用户的模型上，同时能够向用户提供预订业务等来下降某个时段的网站流量压力，使得流量的总体峰值、谷值差距缩小不少；

  ->架构设计优化：在数据库的分区（垂直、水平分区）方面不断地进行优化，同时对于单数据库，就事务处理能力方面进行优化存储方面的操做，譬如使用固态硬盘替代传统的SCSI盘等，并行虚拟写技术等大幅提高磁盘I/O操做能力、或者采用内存数据库技术来管理好读写分离（读自内存、写到内存与磁盘同时），这样能够在数据库层面上得到性能的大幅提高；若是可以配合系统压力测试模型来获取其性能衰减曲线图针对性地优化，其效果将更加明显；

 在中间层服务器上，如何将不一样的车次分布在大小几百个数据库上，而且使用反向搜索引擎技术来链接前端的访问请求到后端的数据库服务器之间的映射与集成（这点能够参考MapReduce并行算法）；

在应用层服务器上，如何将静态内容与动态内容予以剥离，而且无需保存的内容（只读）内容全放在内存中，如何平衡CDN加速与后端Web server的服务架构也是不断提高单个农场集群服务能力的关键与核心；

  ->性能优化： 这些优化是很是之多的，譬如针对Web server的socket链接池优化、日志优化，针对中间集成服务器的并行任务分解与结果集成优化，基于后端数据库服务器的数据计算模型、访问方式、冗余与数据同步、传递优化、数据分区优化等；

  ->其余调优：其余方面的调优譬如基于监控的优化、基于大并发量的快速响应与扩展优化等等；

写到此，感受上彷佛已经设计完毕了，不过忽然回头一望，还真发现内容很是之多，可能有实战经验的朋友确定会提到此系统属于“过分设计”了，不过笔者在此要说的是，确实这个最后的提醒是很是有必要的，任何系统的设计特别是如此复杂的系统的设计只能是须要经过时间来按部就班，先原型后实际系统而且遵循几轮研发调优（含架构设计调优），最后逐渐演变到一个真实成熟的系统，任何超前的设计最终都被证实是无用功而遭废弃；
不少的网友对于12306的网站的技术议论纷纭，而且提出了众多的创造性想法，笔者在提出本身的想法后还有几点补充想法供你们参考： 1. 其实此网站的需求不是一个纯粹的技术问题，试想一下，真的按照国庆、春节的高峰访问需求来设计、部署整个系统的时候，在平时的时候大部分机器都是浪费的，如何平衡峰值与谷值时矛盾是个技术问题，可背后掩盖着的是全中国13亿多人口在短短的10-15天内完成众多的人口迁徙，如此巨大的工程放在任何一个国家都是难于解决的问题，如何从需求层面来化解这个短时间内的巨量人口流动问题才是此问题的命根； 正所谓 “ 解决火车票购买过程容易，而解决人人能买到火车票难！！！” 2. 此问题的求解永远是个迭代过程，须要看到的是很难有人可以在短时间内设计而且实现这么一个巨量系统，这个工程问题的求解是拆解为不一样的子模块来分步实现，而且逐步迭代优化求解的过程；

3. 此问题的解决必须是个系统工程，牵涉到资金、技术、人才、时间 这4个基本要素，不少的同行过于看重人才与技术，而忽略了资金等前提性因素，试想若是只有3000万预算让你来设计实现这个巨型交易系统，你能解决么？ 不说别的，光性能模拟测试就须要调动数以万计的前端机器来在全国范围内不一样的典型区域发起海量请求，这些是个小资金可以解决得了的问题么？

 

后记： 笔者深知，任何技术的讨论必然会引发一些争议，整个技术的发展必需要经历这样的纷争才能进步与提升，在此博文发布的几天内，备受各位同行的关注，笔者很是感谢，也发现了诸多不友好的言辞， 对于有相似架构经验、大项目经历的同行一看就明白，而无此经历的同行看起来相对比较而言没有感受，笔者在此指望技术纷争的同行不要爆粗，你们共同的目的是为了推进技术交流，推进你个人技术进步，推进国家与民族的技术发展。

 

（二）浅谈需求调研

前言： 此文的是续接假如我来架构12306网站(一) - 概论一文，目的是继续探讨整个项目的开发链条，将项目开发中的每一个环节都进行必定程度的剖析研究，跟各位同行切磋技艺，共同提升，但毕竟此项目带有虚拟性，若有言之不妥之处，还请各位同行予以谅解。
需求分析是相当重要的，对于每一个系统而言，需求是生命线，是一切后续工做的源头，笔者在大量的项目实践中发现成功的项目每每在需求定义上相对比较清晰，双方的沟通很顺畅，而死搅难缠的项目每每在需求阶段就能发现苗头，沟通上也困难重重，从某种意义上来说，一个系统的开发其实就是系统开发商与客户的一次“恋爱”行为，系统从某种程度上就是双方“恋爱”的结果，可否有好的结果，取决于双方是否投入了充足的精力，是否有高度统一的认识以及一致的协调配合，在这里笔者我的很是反对以下两种片面的认识，     ->系统开发是开发供应商（俗称“乙方”）的事情。这种思路在客户（“甲方”）中很广泛存在，甲方不少时候都认为签好合同付好钱后就等待系统上线了，这个对于跨行业过来对IT几无了解的客户存在得极为广泛，其实客户在整个过程当中起着极为关键的做用，能够绝不夸张地讲，一个系统的成功是甲方的成熟度+乙方的成熟度的和值可以达到成熟的结果。     ->需求是调研出来的，这种思路在开发商（“乙方”）中广泛存在，开发人员老是认为需求应该是客户的事情，这些认识都是片面与有害的，需求来源于调研，但又要基于现实的模型进行适度的优化而且设计后的出来的结果，这个也是不少系统失败的一个极为重要的缘由，毕竟电脑系统的操做跟纸张操做模型存在着巨大的差距。
不少的项目经理，作了不少年的项目，然而对于需求的重要做用，依然认识不清，当项目成功的时候，归于客户“好说话”，当项目碰到困难或者失败的时候，归于客户“不讲道理”，固然鉴于国内目前的信息业现状，咱们只能说应用科学合理的管理方式来提升项目的成功几率，但确实没法保证项目百分之百成功。
笔者认为，为了确保一个项目的需求阶段可以取得成功，以下方面是必不可少的：     a. 合同中有关工做任务的定义，即俗称的SOW定义必须很清晰，不少的开发公司的合同在这块定义极度不清晰，笔者见过的最极端的例子就是只有寥寥数语来简单介绍此合同对应的工做范围，若是各位有幸碰到这样的合同，惟一能作的就是牢牢拉住客户关系，烧香拜佛了，乞求客户控制需求欲望了，不要将一个几十万的MIS系统演变为一个数百万的ERP系统了。 那什么样的定义才能称为清晰的范围定义呢？ 笔者认为必须知足以下标准：         -> 流程定义清晰，板块划分明确； 若是没法划分的部分建议不要放到合同中，不然害人也害己；         -> 角色分明，功能点定义明确；若是都不知道有几个用户须要使用此系统，那角色定义以及功能点定义确定就是一塌糊涂；         -> 必须量化每一个功能点，建议你们使用业务信息字段数量以及页面数量、流程数量、报表数量的定义放到此SOW，量化是最好的去模糊手段；     b. 定义好项目的管理组织结构，梳理好双方的项目管理组织结构，创建通畅的项目沟通渠道，而且将决策人员在关键点确认上必须予以加入，此处理论上很好解释，实践中的难处在于如何真实地肯定这些实际的内容，笔者的建议是直接咨询付款决定人由他/她来直接告诉你这个结构是最为合适的；     c. 控制好需求确认流程以及需求变动流程，而且严格造成文档， 此处的流程与文档是需求的关键环节，不少的年轻项目经理，因为阅历比较浅，老是依赖于口头上的确认，以致于往后发生争执时，只能顿足捶胸地说，悔当初没能记下来这个那个；其实严格的流程是保证效率的关键，而文档是证据管理的根子，同时证据管理又是项目管理的关键环节，忽视证据管理的项目管理失败是在所不免的；     d. 跟客户的干系人必须讲清楚项目的最终目标是什么，不少时候这些关键控制人老是热衷于尽力提需求，老是尽力将系统变为一个尽善尽美的系统，这个时候必须得统一你们的思路，双方的目标不是构建尽善尽美的系统，而是构建一个可用、适用系统，可以知足大多数目前可以看到的清晰需求（在合同当中严格定义过的系统），另外特别须要强调的是，尽善尽美的系统原本就不存在，人类对事物的认识老是按照哲学规律在逐步深刻的，此处笔者经常使用的例子就是乔布斯作iPhone与iPad，在此以前他失败过多少回，况且iPhone/iPad也经历了这么多代，若是他老人家能构造一个近乎完美的iPhone，哪儿还来iPhone3, iPhone4, iPhone5这么多代的发展呢？
结合本文的主题，假如我来架构12306网站，如何来实施需求调研工程呢？笔者根据本身的经验，大致能够分为以下几方面： 功能需求： 从12306设计的功能角度来看，主要需实现以下2大块业务： 主营业务需求： 此处包含了以下几个大块的基本需求。     客运服务需求，此处系统需求的核心是构建一个以用户为中心，围绕用户在铁路旅行方面的服务需求来进行展开的各项服务，其基础服务包含以下几块：        出行服务： 用户注册、车票预订、退票服务、余票查询、列车时刻表查询、车次查询、发到站查询、票价查询、中转查询、车站通过、车次查询、起售时间查询、正晚点查询、客票代售点、铁路旅程规划等；        接行服务： 车次查询、列车时刻表查询、发到站查询、正晚点查询、旅客信息查询、列车信息、乘务服务信息查询、接行信息服务等；        托运服务： 提供货物交运、状态监控、到站提取、安全保证服务等；        用户支付服务： 便捷支付（主流银行以及网银支付）、支付帐单、对帐查询、退款、支付投诉等各类支付服务；     货运服务需求，此处系统需求的核心是构建一个以服务于货运主的货运需求为核心的各项服务，其基础服务包含以下几块：        货运服务：其中包含整车、散货、小件物品运输业务办理、跟货运相关的理赔业务的办理等；        货运信息服务：其中包含货运路线、车辆运输参数、运输能力、运价、保价、运输时刻信息、货物安全保障信息、运输方案等各类运输信息服务，其目的是帮助货主寻求合适的运输方案，提供便捷的货运服务；        支付服务： 企业支付服务（含线上与线下支付服务），我的支付服务、支付安全等；     信息发布需求，此处提供是铁路运输相关的各种法律、法规、发文、消息、新闻等各种信息；     后台管理需求，包含以下几部分：            客运管理后台，提供各种客运相关的基础数据譬如列车班次信息、时刻表信息、票价信息、车票分配策略调控、列车运行时刻信息、各类起售时刻信息等；        货运管理后台，提供各种货运相关的基础数据譬如列车的车辆运输参数、线路信息、运力、运能、时刻、运价等各种跟货运相关的信息；            信息发布管理后台，提供跟铁路运输相关的各类法规、规程、信息集装、新闻、公告信息等的录入、维护等；        各种角色的管理，提供各类级别的角色管理，而且这些角色还须要跟各列车车次以及路局等直接相关联；        其余系统级别的后台管理服务，譬如用户管理、用户投诉、角色管理、系统维护服务、系统监控服务等； 增值业务需求：     目前的12306网站暂时不提供此类业务，但笔者认为凭借着铁路在全国齐全的路网以及运价、运能的优点，在中长途的货物运输上面，公路以及民航几乎无力与其进行全面竞争，所以此处的增值业务仍是大有做为的。     物流增值服务： 考虑到铁路的布局全面性，所以建设现代化的大型物流基地，培养造成一批网络化、链条化、规模化、具备知名品牌的大型现代物流企业，为目前的货运服务提供延伸的现代物流服务而不只仅局限于铁路运输服务是很是有切入价值的，此块增值业务为其最大的增值服务；     电子商务服务： 因为铁路几乎掌握全国70%以上的大宗货物运输服务，所以对于供需双方的信息以及货物信息以及季节性具备很是强的全局掌握性，由此引起的信息匹配增值服务也能够极大地服务于各大型制造、物流、贸易类型的企业，由此而引起的各种电子商务增值服务也是独具自然优点的；     其余类型的增值服务： 针对服务的我的、企业等提供各种增值服务，譬如各种出行方案挖掘、VIP服务、运输类数据挖掘带来的运输方案优化等各种增值服务将极大地带动铁路的运营活力的发挥，同时为铁路带来大量的增值收益。
性能需求：      精度方面的需求： 其中包括了用户的数据精度，特别是时间、金额、密码等重要敏感数据的精度要求以及各种计量规则方面的需求（含四舍五入规则等），依照铁道部的要求制定出相应的精度方面的要求；      响应时间与时间特性方面的需求： 因为此系统服务的用户数量很是巨大，初步估算都是在数千万并发用户级别，而且考虑到后面的交易系统依然沿用了诸多旧的交易系统，所以在响应时间方面过去的基于TPS的计算模型比较难于精确地预估到在响应速度方面的需求，此处笔者建议经过原型系统的演绎方式来作，具体地来讲先投入一部分资金依照目前的核心业务需求开发出一个原型交易系统，依照铁道路内部的系统架构来部署一个小型测试系统（譬如20台服务器规模）实施测试，而后作适量的服务器增减来测算CPU/Memory/Disk IOPS/Network bandwidth与用户数量的变化关系曲线图来测试用户的响应时间等方面的需求，逐步求精，但在实际的用户需求规划时依然须要坚持平时用户的单个页面响应速度<2秒，高峰时<5s这样的计算与设计标准，达到优良的用户体验；
安全性需求：   外部安全需求     防黑客入侵，须要防止黑客从外部入侵的以下几种手段：     利用操做系统以及防火墙的漏洞等进行入侵获取高级别的权限；     利用特洛伊木马程序来感染而且获取系统的高级别权限或者窃取敏感的交易数据；     口令猜想，经过暴力破解以及字典攻击等方式来实施管理员口令猜想，以期实现对系统的入侵；     缓冲区溢出攻击技术；     扫描探测技术；     防拒绝服务攻击(DDOS)，多人同时向主机提出Web请求，在流量到达必定的程度以后致使系统没法为真实正常的用户提供访问服务；     防页面注入攻击，经过HTML、Javascript、SQL等人为地构造计算逻辑来攻入系统致使系统的崩溃或者数据异常；     防IP假装技术，经过截获、分析数据传送包来分析同时构造新的数据包发送到服务器来实施攻击；   内部安全需求     防止数据丢失与被盗的安全机制，须要杜绝生产环境下的数据丢失以及被盗，创建起一整套数据的储运、销毁等的数据安全保障机制；     防止管理员密码遗失与被盗的安全机制，对于管理员密码，必须以必定强度的加密格式予以安全存放，同时创建严格的管理制度，禁止管理员私自将本身的密码在未经流程许可的前提下告知他人等行为发生，避免密码的传播与遗失、被盗等情形；     防止交易数据篡改，特别是要防止超级管理员（含应用管理员与数据库管理员）在未经许可的流程下私自篡改系统数据，另外更改数据的行为系统都要有能够审核的记录，特别是帐户与交易信息必须具有修正历史可供查阅；
高可用性方面需求（HA)： 能够肯定的是在高可用的规划方面，应该将此系统的定位肯定在7*12小时的可用度在99.9%这个级别，用户的系统可访问度定义在95%以上，这样总体的高可用可以达到大多数用户的心理预期。
系统接口方面的需求：12306系统因为关联了众多的铁路局的内部管理系统以及调度系统，另外也关联了众多的支付接口，所以系统的接口部份内容极为众多，大致上按照性质能够划分为两个大类 即内部系统接口以及外部系统结构，另外按照提供与调用的关系 分为12306提供给其余系统的接口与调用其余系统的接口， 对于提供接口，须要明确接口标准，建议采用Restful格式来提供给其余系统而且对于普通讯息能够走HTTP通道，而交易信息必须走HTTPS通道来实施，对于调用其余系统的接口将依照既有系统的接口形式来逐个细化实施；
软件的其余部分需求： 其余方面的需求主要包括以下几块：    运行环境方面的需求： 这当中包括了服务器端的硬件环境（服务器）、软件环境（操做系统、数据库、应用服务器、中间件）、网络环境（包括数据中心的布局以及分布式设计、网络链接以及容量设计）等方面的需求；另外对于客户端，须要明确指出支持的浏览器的种类以及版本、须要安装的安全组件（插件）等。 笔者特别须要提到的是不少需求调研都忘记确认运行环境， 结果到上线前用户使用Firefox甚至IE6等来检验发现根本没法进行验证运行的状况，其中的苦只有本身可以知晓了。    系统可维护方面的需求： 其中包括Bug修复流程、系统发布流程、系统升级部署流程、系统扩容流程方面的需求，考虑到此系统的服务器数量众多、地域分布有必定的广度，所以在设计此部分维护性需求时必须考虑到凡此种种状况。    系统可监控性方面的需求： 其中包含服务器端的常规监控（CPU/Memory/Disk I/O)以及网络流量监控，另外须要特别增长对于交易事务队列以及请求队列的队列长度、去化速度等方面的监控，从HTTP方面须要监控每一个request的去化速度以及队列长度，从而从各个方面全面地了解系统的当前性能指标。    其余需求包含了可移植性、可扩张性等各个方面的需求。
需求文档的写法： 此处列出需求文档的所有目录结构供你们参考，具体的文档内容就不贴出来了。 1. 引言     1.1 编写的目的     1.2 背景说明     1.3 术语定义    
2. 任务概述     2.1 目标描述     2.2 功能性需求     2.3 业务信息定义     2.4 约束条件    
3. 数据流图     3.1 全局数据流图 3.2 各子块数据流图
4. 系统接口     4.1 用户接口     4.2 硬件接口     4.3 软件接口    
5. 性能需求     5.1 精度要求     5.2 时间特征     5.3 灵活性    
6. 软件属性     6.1 可以使用性     6.2 系统安全性     6.3 可维护性     6.4 可移植性    
7. 系统配置需求     7.1系统硬件和软件配置 7.2网络配置     7.3网络拓扑图    
8. 其余需求     8.1 数据库需求     8.2 故障及其处理需求
能够绝不夸张地说，需求肯定的清晰程度以及双方的承认度，直接决定最终项目的成败与否，不少的同事老是抱怨客户在最后不讲道理，不留情面，其实仔细分析发现项目开始的时候项目组就已经沟通很不充分了，存在了巨大的隐患，留给整个项目的执行是无穷尽的遗憾。
项目需求的沟通能够简单、形象地总结为一句话： 需求调研就是了解在什么环境下（服务器、客户端环境、网络环境）实现怎么样的一个系统（功能列表），其可用度如何（性能、安全、可靠度）？       理论虽是如此，可实际执行的时候你们仍是发现存在以下的诸多问题： 1. 跟客户的一个领导将需求讨论清楚了，但是后面换了新领导，整个思路全变了，系统也必须大改， 如何控制需求？ 2. 跟客户下面的项目管理人员定义得很清楚了，但是等到最后给高层领导一看，才发现需求根本偏向了，怎么办？ 3. 在设计、开发过程当中，客户老是千方百计变着法子来添加需求，还会有种种这样那样子的理由，需求想控也控不住； 4. 碰到极端客户，就算你一开始跟他谈得很好，也签字承认了，到了后面一翻脸就说，这事儿我还得改，不然我就不打算让你上线？
如此种种，令不少理论派PMP的管理人员手足无措，也不知何从处理，根据笔者的我的经验来看，若是真的出现上述状况了，那咱们还得必须考虑一下，任何项目管理都是寄生于企业的管理生态与社会的交往生态当中，此处从PMP的经典理论已经没法来解决上述问题了，必须升华为管理生态以及客户关系生态来解决了，此时项目经理必须借助销售以及公司的其余各类途径来突破解决此问题了。

 

后记： 当项目经理真的可以站在管理生态与客户关系生态来解决项目管理的各类棘手问题之时，也恭喜各位已经突破性升级了，笔者在多年的工做实践中，不多看到这样的优秀的项目经理，正如笔者在参加PMP大会时常常听到的一句话，经济的发展不可或缺的是项目经理，此话既是套话，同时也是实话，可以深入理解项目管理的业务实践而且站在全局的角度来主动出击解决项目当中碰到的各类问题真可谓优秀项目经理，确实为经济发展大潮乃至人类发展大潮中的弄潮儿，必将得到我的职业乃至人生理想的成功