作者：京东研发体系
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
京东技术解密试读：
编委会
特邀顾问：李大学马松曹鹏肖军何刚熊宇红
刘轶孙晖陈伟赵延涛翁志江川
总编：吕建伟
副总编：刘艳光樊晨刘坤苗马沛刘家瑞
编委会成员：许立龙张侃李刚王先科王大泳王晓钟
彭青王宇章爱文暴丹王晓琼李昂
王彪欧阳波谭悦娴陈鲲李鹏涛吴新红
王茹张华刘磊谭聂王超杨洪涛
南婕王远李鑫章耿丁俊桂创华
王松林梁秋实赵海峰郭理靖孙学斌侯超
李松峰赵刚靳简明侯会满张斯聪王威
陈玉兰高慧刘朋飞张立军胡浩谢蔚
马斗张国利郭建华董浩李帅张蔷
推荐序一
我曾经在很多场合谈到京东可以高速发展到今天的规模的原因，其中最核心的是坚持“倒三角”战略：建立出色的团队；打造财务、物流和技术三大核心系统；降低成本、提升效率；为用户带来最佳体验。在《京东技术解密》一书中，大家会看到技术驱动的力量，这也是京东第一次全面展示自己的技术体系。
过去十年，京东在技术领域做了些什么呢?2004年刚刚上线时，我们叫京东多媒体。当时京东只有一组简单展示IT产品的网页，而如今京东已经是覆盖PC端、移动端，并完整支撑物流、订单、交易、商品、财务系统的巨大电商平台；当年我们的技术部门只是一个四五人的小组，现在京东集团有了超过4000人的技术研发团队，其中还有不少牛人；最初京东的技术平台是外购的简单ASP“个人网站系统”，而目前我们的技术架构除了满足京东自身应用需求外，更是具备了为用户提供资源服务的云计算、大数据平台。十年来，京东的技术平台实现了高速成长，成为驱动京东成长的基础，也为京东未来的发展储备了充足的动力。
在京东技术平台的发展过程中，有过很多激动人心的时刻。读到这本书，我仿佛又回到那些对京东成长至关重要的时间点，回想起并肩战斗，现在已经成为京东各个领域骨干的伙伴们。在这里，我要再次感谢京东的技术团队，感谢你们的辛勤努力让京东有了今天的地位，让用户有了优质的体验，让京东的“触角”得以自如延伸。
京东人从来不沉浸在过去的喜悦中，京东的梦想绝不止于此。我们对自己不满足，因为我们坚信京东还有更远大、更宏伟的目标，还可以做得更好。“永不知足、永无止境”的精神流淌在我们的血液里、刻在我们的骨子上。京东的技术平台也会一路披荆斩棘、勇往直前。
技术的成长支撑了过去十年京东的高速发展，放眼未来，技术将不再只是幕后英雄、支撑平台，而将成为驱动京东进一步做大做强的动力来源。按照我们的规划，京东将以技术为驱动建立先进的供应链服务、开放服务业务和数据金融业务，在我们引以为傲的业务布局上全面发力。
对于用户来说，京东技术平台的进步会给用户带来完全不同的购物体验。我认为，未来用户将拥有身临其境的神奇购物体验，挑选产品及下单会更加自然和便捷；配送则会比今天更迅捷，从而一步步实现京东的愿景——让生活变得简单快乐。
我期待京东技术的美好明天——拥有出色的团队、坚实的基础、务实的架构和创新的管理，让技术驱动京东走得更快、更远。
京东集团创始人兼首席执行官
刘强东
2014.10
推荐序二
京东的朋友送来一个书稿，关于京东技术团队十年来走过的路，向我约一个序言。
作为一个消费者，我很喜欢京东网购正品和快速这两大特点。京东仅用十年便快速崛起，成为千万消费者喜爱的电商品牌。要将一个大型服务平台做到优质已非易事，做一个可信任可依赖、服务范围覆盖全国的电商生态，更是无比艰难。通过本书，读者可以感受到京东技术团队十年来的付出和坚持。“十年如一日”的坚持
在业务高速发展的背后，技术上会有很多坑很多歧路，即使有一个坑解决不当或迟缓，都可能导致服务质量变得糟糕、业务受损、挫伤品牌。在每一个关键时刻，及时填平这些坑，是技术团队经常要面对的挑战。
应对这些挑战并不容易，除了技能和经验，还需要热爱这个行业及团队。对技术架构的追求是永无止境的，不存在最完美的架构，技术团队需要有“十年磨一剑”的精神，用“十年如一日”的坚持和专注，解决领域内一个又一个的实践问题——先扛住、再优化、再提炼，跌倒了再爬起来。
技术人员往往比较沉静，他们很少面对聚光灯，不会像资本、市场、产品那样有很多盛大的发布会，但他们是真正的幕后英雄。
信任和传承的团队文化
大型服务平台高速发展的背后，一定有许许多多的组织问题，少不了磕磕碰碰、问题矛盾。正如没有完美的技术架构一样，也不会有绝对完美的技术组织。技术团队的组织演进也是一个动态发展的过程。只要团队秉持相互信任和主动传承的理念，方法总比困难多。
技术团队的工作很辛苦，但又充满了乐趣和成就感。当一个技术团队在高难度的挑战中，不断战胜自我，磨合出信任和传承，其所处环境就可以成为人才辈出的乐土。
在这里祝福京东的技术团队，可以发展得越来越好，培养出越来越多的技术大牛，研发出更多更优美的技术，给亿万消费者创造更优雅的电商体验。
腾讯创始人之一、前CTO
Tony 张志东
2014.10
打造最有影响力的技术团队
李大学
2008年我加入京东，见证了京东技术团队从30至4000人的成长历程，也见证了京东是怎么从业务为主的公司，变成技术驱动的公司。下面，结合京东具体的事来讲一下其中的见闻和感触。
京东研发组织架构
京东技术团队目前有超过4000名员工，拥有北京、上海、深圳、成都、沈阳5大研究院。
京东的系统比较复杂，涵盖电商全流程全价值链，从前端的交易系统到供应链，到仓储、配送、客服以及售后，除了财务报表之外，几乎全部系统都是自己研发的。京东的全部业务都在线上运行。京东CEO刘强东现在一年时间里只有一两个月在国内，大部分时间在国外。他通过信息系统可以看到所有的生产情况，所有的数据一目了然，比如说仓储某个环节拥堵了他都知道。
京东的信息系统支持了京东连续多年以高于行业平均增速的速度增长——2013年市场交易额突破1000亿元，达到1255亿元。10年时间，实现了10000倍的增长，背后靠的就是信息系统。
在2013年年中，京东以“电子商务”为基础的“四架马车”的战略已经基本完善，包括电商业务、物流平台、技术平台和互联网金融业务。在围绕管理提升、组织能力和组织协同方面，京东也正在进行更多有益的探索和尝试。京东正在发生一个蜕变，从一个中国型的电子商务公司，变成产业链的整合者。而京东战略的核心，还是要以技术为驱动。
组织架构调整：研发体系分为9大模块4个平台
管理4000人的团队，我觉得组织架构优化是比较重要的一件事。以前京东的技术团队一直是职能化结构：产品部、研发部、测试部以及运维部门。而当我们的产品线和项目多了以后，人也多了，要分优先级就非常复杂，沟通也要非常多，部门协作就很困难。
京东今年对技术团队做了调整，研发体系分为9大模块，基本是上按照客户、事业部的组织形式来划分的。
其中，云平台和运维两个部门主要是负责底层的网络服务，以及解决顶层的技术架构问题，是提供技术支持的平台。同时负责研究统一的研发工具，包括日志、监控和流程引擎等，通过这些工具可以提高其他研发部门的效率，也使他们不用再重复开发组件。由此可见，这两个部门的职能是提供基础设施，提供统一的工具和平台。
营销研发部面向采销体系，采销体系主要是做网上营销的，是我们整个公司的火车头。我们为采销体系开发3大系统：一是交易系统，保证交易系统的稳定，同时实现网站转换率提升、用户体验优化；二是供应链系统，与供应商连接，对订货量进行预测，很多相关的供应链控制手段也是在该部门实现的；三是开放平台，要把整个供应链系统开放给第三方卖家。
运营研发部是针对COO体系，也就是订单生产体系的，仓储系统、配送系统、客服系统都是由运营研发部负责的。
职能研发部主要是职能体系的内部信息化管理部门，涉及诸如行政、人事、战略等职能体系，也包括我们的财务部门。
营销研发部、运营研发部以及职能研发部这3大部门支撑了我们内部所有的业务。而其他部门则都是为这3个研发部门服务的。
大数据部提供统一的大数据技术平台。数据平台是基于Hadoop的，在这上面做统一数据的采集、抽取、存储、处理、挖掘，以及在这上面开发一些数据增值产品。我们的搜索、推荐系统、开放数据服务都是在这个部门完成的。
移动部负责客户端的建设和移动的创新，是一个发展非常快的事业部。
研究院是一个统称，我们有一个专门的部门负责全国研究院的建设。
最后，我们还有一个部门，类似综合管理部，叫技术研发管理部，主要负责管理体系的建设，包括SQA、PMO、一个IT服务台，以及24小时的监控与运营。我们有一个400电话，系统有问题的时候，外部和内部都可以通过打这个电话进入处理流程，先由运营人员处理，处理不了的交给研发部门。之所以把研发部门往后放，是因为研发人员是不愿意直接处理问题的，他们更愿意写代码。通过运营部门的过滤，80%的系统问题都已被直接处理。
整个结构调整，我觉得还是比较成功的，大大提升了客户的满意度。以前的客户跟我们很多部门沟通，现在只需要跟一个部门沟通，而每一个部门的客户都是明确的，所以部门的主要职责可聚焦为提高客户满意度。
虽然我们有9个部门，但实际上我们把整个研发团队分成了3个层次4个平台：
第一层是技术平台，主要基于之前提到的云平台和运维这两个部门，打造基于云的技术架构，支撑其上所有的应用。
第二层有两块，首先是大数据平台。我们把数据独立出来，不能让每个应用都处理数据。如果每个应用都处理数据的话，这些数据就乱了，而且这些数据可能形成孤岛，很难共享，很难在整个企业里面流通。其次是电商开放API平台，我们把电商的核心平台建立起来，同时以API服务的方式进行服务，这对价值链长、流程和系统复杂的公司来说是很重要的。
第三层是应用平台。因为有了以上两层作为支撑，在上面做具体应用就非常方便了。所以我们的应用平台，包括我们自己的网站、移动客户端、内部的ERP及外部的ISV开发应用，都可以调用电商核心API，同时相应的数据都进入大数据平台。而且，这些应用都可以在应用平台上实现。
在京东，我们针对企业架构有一些比较好的实践。大家可以对比一下，参照这样的模型打造我们的信息系统有什么好处。以前我们要开发一个需求时，不得不从前端的网站开始梳理，到采销系统，再到仓储、配送。因为整个价值链很长，需要大量的沟通和配合。现在通过电商开放API就很简单了，减少了各个系统之间的沟通和耦合。由于电商业务发展比较快，这种开发应用的模式更适合业务部门快速变化的需求。
通过这4个平台，大家看到这里面有一个逻辑，最底层的实际上是我们的技术架构，用来解决架构的问题。其上的数据这块起数据治理作用，API平台解决服务治理问题。开发都是基于SOA的，大家都使用某个服务的时候，就会出现混乱，需要治理平台来加以解决。这三个关键把握住，应用平台上面的应用可以丰富多彩，我们的系统逻辑也会比较清晰。
IT管理123：1个愿景、2个重点、3个体系
MBA、EMBA这些理论都是来自生产线，从一线工人那里来的，这些管理理论现在对IT来讲都不成熟，所以在IT管理方面我们正在探索。
首先，要有一个愿景。几十人的团队靠身体力行，几百人的团队靠体系，几千人的团队要靠愿景。有愿景以后团队就有使命感、自豪感和成就感。
两个重点工作，一是文化。团队大了以后，文化、氛围是最重要的。
对整个公司来讲，比如老刘，再如其他业务部门的高管，他们能不能尊重技术，公司能不能形成尊重技术的氛围，这是公司的技术总负责人要考虑的。我要打造一个环境，尊重这些专家。
在研发部内部，我提了3个词，第一是信任，第二是分享，第三是成长。
信任就是授权，信任可以减少沟通的成本，上级对下级、下级对上级、同级之间都要形成信任的氛围。比如说研发人员有可能制造了一个事故，你认为他是故意的，还是为了创新?你违背流程，犯错当然是要惩罚的。然而京东定了一条规矩，因为创新出错，我们是宽容不惩罚的。宽容失败在研发体系里可以形成一个氛围，这也基于对员工的信任。
分享是指分享最佳实践。4000人的团队里面一定有一些人在某方面做得很好，我会让他们分享，供其他人学习。我们也提倡容忍失败，从错误中当吸取教训，获得经验。从最佳实践学习，从错误当中学习都是为了分享经验，为了进一步提高。开发人员每天都写代码，会有一些值得骄傲的代码，去年我们开展了一个活动，让他们秀出来给其他人看。这些代码不需要是一个系统，可能只是自己的一点心得。每周五下午的这个活动，非常火爆。这样程序员在写代码的时候，就想写出好的代码，在学习别人代码的时候，就想模仿别人的长处。我们内部有一个类似GitHub的软件，可以让程序员把分享的代码放在上面。分享对研发人员是很重要的，可以帮助研发人员快速成长。
关于成长，因为研发人员普遍年轻，普遍希望学习和成长，我们就在内部打造成长的文化，包括给他们培训。京东的技术人员是按T1～T6分级的。T1是学校刚出来的，T2是毕业两三年但水平还不足的，我们让T3、T4给他们授课，每天培训，让他们成长。我们也从外面请一些老师给我们讲课。比如，有一年做了一个UML的培训，效果非常好，大家学到一些架构和思维的方法，掌握了一些工具。我们又开始对研发经理进行培训，大家都踊跃参加，他们提升了，我们的研发效率就提升了，创新就增加了。
两个重点的另一个就是结构。研发管理中有很多问题是结构的问题。
团队到几千人的时候，要特别关注结构。刚才谈到人才结构，人才结构就是梯队的问题，人才梯队是非常重要的。以前低级别的人才多，T3、T4、T5太少了。为此曾发微博招聘，收到几百份简历。关于人才结构我们还做了一件事，把管理和技术分开，以前技术的人到一定程度必须转到管理，待遇才能提高，现在我们区分开，技术人员也分级，在结构上就解决了很多的问题。还有一个结构就是我们的组织结构，前文曾提到对其的调整，改为按客户方向划分，也非常成功。
最后再谈谈3个体系。
第一个就是产品体系。我们公司的体验，不管是消费者的体验、第三方卖家的体验、供应商的体验，还是内部业务部门的体验，都是产品驱动的。我们打造让产品经理说了算的文化。以前产品做什么，首先是被业务部门绑架，业务部门说你这个东西要做成什么样的，产品经理记下来，然后直接找研发做，这是有问题的。另外，我们的管理者想把一个东西做好，主观上会按个人的好恶指挥产品，这样也把产品经理绑架了。然后，开发人员说这样设计太麻烦，那样做更好，又绑架一次。3个绑架像3座大山，把产品经理毁灭了。我们提出让产品经理说了算，不是管理者说了算，不是业务部门说了算。比如说每个采销部门，都想定搜索排序的规则，但是我们内部有一个铁的纪律——搜索的规则只为转化率负责。业务部门告诉你的只是建议，产品经理就有自己发挥的空间，能为最终的用户体验负责，这是非常好的。把产品体系打造出来后，我们也成立了产品委员会，再选出委员会的常务委员。
第二个是架构体系。架构让架构师说了算，不是管理者说了算。管理者往往认为自己在专业方面很厉害，但实际他也有天花板。为让架构师说了算，我们成立了架构委员会，跟产品委员会一样，由委员会决定京东的架构是什么样的。京东技术架构的规划、实施和评审，都是架构委员会的工作。
第三个就是管理体系。管理体系有两方面，第一方面是项目管理，就是加大项目经理的权力，实行项目经理负责制。一旦项目立项了，项目经理的权力很大，对项目，包括进度、质量、投入产出，都是直接负责的。项目部有奖金，奖金驱动项目，项目奖金怎么分配，项目经理有决定权，并且权力很大，研发人员到项目里面，考核也由项目经理说了算。我们有一个项目管理平台，在上面所有项目的情况一目了然。而且，项目里面的每个人、每项工作，都可以按人和部门列出来，可按人、项目和部门统计，人效一清二楚。所以大的团队要靠系统进行管理。管理体系的第二个方面是领导力系统。京东4000人的团队，有12个部门，每个部门 300 以上，300 人的管理难度是很大的。难度主要来自管人，我管的人不能超过14个，多了就没法管了。管人必须要有影响力，要有领导力。我们在领导力上是很薄弱的，因为很多技术管理者都是从专家转过来的，所以用的语言都是计算机语言，都是专业的语言，EQ普遍不高，但是领导力系统对EQ要求很高，特别是跟业务部门沟通的时候。“管理123”是我的心得，也是我们研发体系贯彻的东西，效果还是不错的。
给团队一个愿景：做中国最有影响力的技术团队
京东的愿景原来是“让购物变得简单快乐”，今年做了一个调整，改成“让生活变得简单快乐”。而针对4000人的技术研发团队，在服从公司愿景前提下，我们提出了一个更符合京东研发人的愿景：“做中国最具影响力的技术团队”。这个口号提出来以后，我们的研发人员挺高兴的，感觉有一种自豪感，更有一种成就感和使命感，觉得这比较符合我们工程师的愿望。京东在研发上的投入每年都有增加，在中国企业的研发团队里面，我们算是投入比较大的。如果持续这样投入，我们研发人员有信心把技术做得更好。我们的技术人员看到自己的系统在公司发展中不断的成长，也会有很强的自豪感。
30人的团队，管理者可能身体力行、以身作则，因为大家都看着你，你怎么干，大家跟着你，你要注意细节。300人的时候要建一个体系，起码要有项目管理，这是很重要的，否则300人管起来就很困难。但是到4000人的时候，我觉得要有一个愿景，没有愿景这4000人的目标就不一样，很难团结起来。再次强调京东研发人的愿景：“做中国最具影响力的技术团队”！
618
618网上购物节的树立可以说是京东的成人礼，也给京东研发带来每年一次的大考，更为京东技术架构提供了飞跃的机会。618会战团队如何进行核心网络技术/订单系统/交易系统的扩展升级、又如何度过那深刻难忘的不眠之夜，本篇为您娓娓道来。·促销手记·数据中心网络大优化·高性能的交易系统·海量订单处理
1 阳光灿烂的日子——促销手记
双11日记在整理《京东技术解密》这本书的这一章节时，我们采访了很多位深度参与京东历年618和双11大促活动的技术人，听他们讲了很多突破想象的故事。但是，几乎所有的人，都不约而同地多次用“战场”、“战斗”来形容自己当时的工作状态，这也是我们现在回看京东过去十年的技术发展历程时，能想到的最为贴切的词汇。
2013年11月8日，周五，距离双11还有3天时间“这一次不能挂！”，这是周末下班前飞哥对我们说的一句话。说这句话的时候，飞哥眉头紧锁，表情凝重。一只手暗暗地握紧了拳头，另一只手坦然地接过了我递过去的橙子。“公司又开始发水果了啊，这么给力！”。
没有人可以否认，双11很重要。“对于网民，这是一个举国狂欢的日子；对于我们，这是一场没有硝烟的战争。这一天，在所有的人都以为我们和往常一样坐在电脑前的时候，其实我们早已化身战士，身披黄金战甲。我们的面前，是一群兵强马壮的敌人；我们的背后，是支持我们的可爱用户。战争结束后，我们要和用户一起分享丰收的喜悦……”。“拉倒吧，貌似去年的双11你躺在床上睡大觉呢吧！”，正当我沉浸在美好的回忆之中，贤军同学的话把我带回现实。“哪有，去年的双11我明明在家里上京东下了一大笔订单……”。虽然去年双11没有来公司值班，但是在第二天上班期间看到每一个兄弟还在竭尽全力坚守岗位，已经废寝忘食通宵达旦，那一场景让我至今难忘。
2013年11月10日，周日，距离双11还有1天时间
周末的地铁里人来人往，最显眼的当然是地铁两侧京东和天猫的广告，大胡子男人和被晒黑了的女人用各自独有的方式展示了“双11不能等”的心情。地铁门开了，迫不及待的人群瞬间把我冲上了地铁，在进入车厢的那一瞬间，有一种终于抢到宝贝的成就感。
晚上8点，维多利亚的会议室里人山人海，以老马为总指挥的战斗指挥部，每一个人都精神饱满、斗志昂扬。我们的飞哥更是一心想打破他当年连续72小时不下火线的纪录，当然，我们如今的系统已不是当年的系统，他已没有破纪录的机会了。
2013年11月11日，周一，双11当天
这一天就这样到来了，早上睁眼看手机，日期处赫然写着：11月11日。
比平时早一小时到公司，发现大家竟然都到了。“龙哥，赶紧观察线上日志和监控系统”，还没有来得及坐下，就已经有任务下达了。从大半个月前我们小组成员就开始精心备战，包括代码的优化、系统的调优、架构的升级、接口调用量估算、线上日记地址及监控统计……今天终于正式迎来了对我们的检阅。
11月的北京已经进入了初冬，办公室里却涌动出热浪，在空调呼呼的背景音下，每个人都在目不转睛地盯着电脑屏幕。偶尔有人摘下眼镜，用衣服的一角擦拭一下镜片，又继续抬起头盯着屏幕。“量上来了，又上来了！”，有存同学的大嗓门时不时地在提醒我们今天是一个特殊的日子；老耿已经在自己的办公桌和DBA办公室之间辗转来回多趟，终于在第N次回来后看见他脸上露出了舒心的笑容；老陶那边的促销是挑战最大的，各种促销秒杀活动，除了考验系统的支撑强度，还在考验着他们的心理素质；世超同学则不停地接着电话，不断解释诸如为什么库存一直同步不了等问题；而洪来同学则在忙着解决商家商品线上的各种问题……
这一刻，每一个人都十分忙碌。
2013年11月12号，周二，双11结束的第2天
在双11结束的凌晨，看到好多同事发表了欢送双11的状态。日流量新高，日订单量新高，日配送量新高……各式各样的数据表明，我们再次创造了奇迹。
POP（开放平台商家）商家客户端在双11期间没有出现任何问题；双11当天，各系统中心单日接口调用量均创新高；商家中心、商品中心核心接口调用量均达到预期，且在处理关键的库存和价格时，响应稳定及时；双11期间，参与促销的商家占96%，近千万款商品参与了促销，所有接口较平日调用量均有大幅度增长。各种各样的数据表明，在京东流量上涨的同时，我们的系统经受住了巨大的考验。
除此之外，这期间还涌现出了各种感人事迹。贤军同学主动请缨留在公司通宵值守；飞哥在发烧的情况下，全然不顾会传染给我们的风险，毅然坚持加班到半夜；陈川和欧阳同学在下班的路上得知系统报警后，在公司和老婆之间坚决地选择了公司……
非常喜欢一本书中的一句话，“你是一个什么样的人，你就会遇到什么样的战友！你相信梦想，梦想就会相信你！”我很庆幸我的身边有这样一群战友，我也相信这次的双11绝不会是一个终点，它是我们又一个新的起点。
下一个双11，下一个10年……愿我们永远同在！大数据平台的战斗
2013年的双11，对于数据部来说，他们领到的任务是为后台商家提供双11销售成果的关键分析数据，以及给每个商家提供云图功能的实时数据。最重要的是，必须以最快的响应速度向公司提供双11的最终销售数据和流量数据。在这个过程中，挑战无处不在。
11月10日 17点～20点
双11前夜备战，大家都摩拳擦掌，早早进入了战备状态。
11月10日20点～22点
网站浏览量快速上升，已经是平时的两倍多。商家实时销售量、实时访客的前端展现服务器的资源消耗猛涨了上去，按这个趋势发展下去前端实时报表服务扛不了多长时间了。不过兄弟们在双11前都制定了紧急预案，大家立刻开始了预案实施。实时展现的兄弟们有条不紊地切换了另一套展现方案，实时系统的兄弟紧接着做了数据推送接口程序的切换。忙碌之后，实时报表展现的服务器压力降下来了，前端展现也没有出现任何时间的数据断点，也就是说，丝毫没有影响商家对自己实时销售、浏览情况的追踪。
11月10日22点～24点
第一波用户流量高峰到达，从实时数据上看PV接近618和去年双11的两倍。我们抗住了第一波高峰！
11月11日 0点～4点
实时系统平稳运行，现在是Hadoop批处理任务上场的时间。
订单数据，对公司来说是最重要的计算销售指标的数据。过了零点，开始抽取线上数据的流程。10分钟后，数据仓库的同事发现订单表数据抽取速度过慢，还不到平时的1/5。问题来了，我们通知运维找DBA的同事和网络的同事排查问题，最终在维多利亚双11指挥部，SQL Server DBA的同事发现我们抽取的数据源网络有问题，因此紧急切换了问题数据源。很快我们就顺利地抽取了线上的生产数据，Hadoop数据仓库运转正常，并在早上8点前完成了前一天所有数据的各项核心指标。
11月11日8点～12点
白天的高峰再次袭来，这次的时间更长，更猛烈。实时系统平稳运行，计算着每时每刻的用户浏览量，从数据趋势来看，今天的PV毫无疑问又一次超过了行业和平均增长幅度。
11月11日12点～20点
浏览量还在急速上升，用户浏览日志服务器的同事说要扛不住了，需要紧急增加1/3的日志服务器。实时系统和Hadoop批处理的兄弟们又开始了数据接入的准备工作。18：30，日志系统准备好了新的日志服务器上线。19：00，成功测试完成，开始切换。大家盯着实时报表，时刻观察着切换可能引起的数据异常。10分钟过去了，20分钟过去了……浏览数据在晚高峰中平稳地增长着，切换成功了。
11月11日20点～24点
今天大家都在，为了见证京东又一个销售和流量的高峰。在大屏幕前，流量还在一点一点地上升。大家围着我们大数据平台的总监，讨论着这一年的进步。Hadoop数据仓库从无到有；实时系统在关键时刻越来越稳健的运行；数据传输工具从第一代发展到了第二代，现在可以支撑每天数百GB异构数据源数据传输；调度系统、监控系统更加完善；团队也日益壮大。整个数据仓库的生态系统在茁壮地成长着，未来我们京东的大数据蓝图也在今天实现了很大程度的预演。临近24点，我们在实时报表前合影留念，以纪念这个难忘的双11。
11月12日 0点～3点
现在最紧张的时间到了，昨天到底有多少销售量，有多少PV的谜团要揭开了。
仅用80分钟大家就把数据量已经超过1个亿订单表的数据从生产SQL Server抽到了Hadoop上。
又过了30分钟，浏览日志数据在Hadoop上处理完成。
11月12日3点～6点
Hadoop数据仓库开始了计算流程，核心指标以最快的速度计算完成。在各个数据需求方9点钟上班的时候，已经能够看到了京东双11的各项核心指标了。
此刻，新一天的太阳升起。晨曦中，数据仓库的同事终于可以回家安心地睡觉了。在大家休息的时候，我们在战斗；在大家看到胜利成果的时候，我们已经离去。这就是京东数据部大数据平台同事的双11，也是每个研发同事的双11！交易系统的抗压会战
每次大促过后，交易系统的上游和下游在高压情况下，都会暴露出一些不同的问题。目前一年两次的大促活动，老宋所在的交易组的伙伴们，考虑的最多的就是，如何避免618遇到的问题在双11重演，如何应付双11出现的新状况，如何提前做预案等问题。
老宋回想着今年的618，交易组系统的上游系统遇到瓶颈，购物车在不停地关闭一台服务器，再打开另一台服务器，然后重启上一台关闭的服务器，一直这样，不停地重启、再重启。否则购物车服务器马上就会遇到瓶颈，导致用户进入购物车后无法正常下单。双11前夕，交易组领导老王签下军令状，首要任务就是优化交易系统性能。为此，老王亲自组建了虚拟性能小组，开始调整Nginx配置、合并异步调用减轻购物车压力、优化用户和商品接口、实现内存计算防刷以及进行各种降级方案、备节点、异步节点和亦庄机房的多次演练等，将很多性能方面的工作都当成了日常任务解决。
双11接受检验前夕，在加压测试中发现，经过优化的上游系统表现出色，购物车和下单系统没有遇到任何瓶颈，之前性能优化的工作已经产生了效果，淋漓尽致地发挥了作用。但是，下游系统又遇到了较大的挑战，产生了比如订单任务积压、很多支付用户订单状态不能流转、3COD挂掉导致SOP订单不能选择货到付款等问题。如果真的到了双11，这些问题可能又将导致一次次糟糕的商家和用户体验。好在经过提前的预演，老王可以胸有成竹地开始第二轮带着团队不断解决系统在高压下存在的各种问题。
下游系统出现的问题与系统架构关系密切，每次老王开始讲解订单任务和中间件的系统架构时，都会画出很庞大的交错复杂的架构图。老王时常在想，我们一定要做减法，给下游系统瘦身；干掉冗余的部分，让一些逻辑关系迁移出去……架构调整的压力已兵临城下。JOS备战
进入6月，整个进出北辰大厦的人，好像走路的节奏都变快了，虽然整座大厦的冷气让室内温度降到了22度，但是你会感到618似乎带着京城40度的高温向你一股一股地扑面而来。
JOS开放平台备战。JOS开放平台是京东对外的一个门户，也是众多后端服务接口正常调用的重要桥梁之一，JOS的团队清醒地认识到了这一点。JOS平台负责API开放的老黄认为，JOS系统的负载时刻与618活动脉搏相通相连，用户的每一次授权登录对我们来说，都是最好回馈；商家的每一次活动上架都实时挑动着团队成员的每根神经；商家最后的欢喜出库也在考验着JOS团队这几个月来不懈的付出。为了今年的618大促，JOS团队已经提前几个月开始准备了。
经历了2013年的618和双11，JOS网关在整体稳定性上已经有了明显提升。但是为了迎接2014年的618，JOS团队仍然对网关的效率和性能做了整体分析和评估，他们认为JOS系统需要做综合的升级处理。老黄认为，我们首先应考虑的是稳，618的第一宗旨是“稳定压倒一切”。但是现在，对JOS系统的后端服务接口评估后发现有快有慢，这一点必须调整、完善。
不仅JOS开放平台后端服务的一部分接口处理时间有快有慢，而且一些系统的容量规划、发布时间和服务质量也有参差不齐的情况。考虑到开放平台作为一个对外的门户，HTTP请求的同步性+容器管理线程生命周期，将会使得单个服务不可用波及平台，最终导致后端服务都无法被访问，因此，这里需要改变传统容器的请求处理方式。（假如一个服务出现问题，同时3秒钟为服务调用超时时间，如果一个应用服务器最大容器线程为600个，那么单机最差情况1秒就只能处理600/3个请求，这意味正常的后端服务由于得不到路由中转，也被外部认为不可用）将容器线程池独立出来处理连接，而业务处理交给后端业务线程池处理，业务线程池可以根据业务优先级设定一些预留和限制模型，即共享线程池，使限制线程池被独占。JOS团队做了“异步模型封装+业务管道化+业务权重线程池”的处理，异步模型设计提升了系统的响应时间，而配合权重线程池处理则实现服务之间质量影响隔离以及服务与平台稳定性隔离，通过隔离保证了系统的稳定运行。
在今年618的总结中，JOS平台负责的618前后3天的接口调用总量与去年618和双11的调用总量相比，高出了近3倍。而接口平均响应速度比去年618提升82%，比去年双11提升了25.6%。2014年618（右）与2013年618（左）和双11（中）的接口平均调用成功率比较青龙系统的一次意外之旅
2014年6月19日16层成都会议室整个指挥中心，除了通宵后仍然坚守在监控岗位的值班同事，最抢眼的就是墙壁和桌面上各个生产系统的监控图表了——流量监控、服务器性能监控、接口性能监控……各种监控，有图有真相，一旦哪里突发异常，系统负责人立刻会做出响应。对于青龙系统，2014年6月19日是系统负载最大的一天，订单的洪峰通常晚一天到达配送，从早上5点后，系统访问量开始直线上涨，这段时间大家重点监控数据库的负载、Worker任务的积压情况。直到早上8点后访问量开始下降，系统性能指标一切正常，大家悬着的一颗心终于放下了。为了今年的618大促，我们提前几个月就开始了准备，回想整个过程，有意外也有惊喜，但更多的是充满了荷尔蒙的刺激。
经历了2013年的618和双11，青龙系统稳定的度过了一段比较长的时间。为了备战今年的618，我们决定将数据库安全等级提高，2014年4月5日凌晨开始修改数据库密码，青龙上下一共几十个应用，按照系统的依赖顺序编写了一份操作步骤。按照这个步骤，凌晨的切换非常顺利，直到早晨业务高峰前系统都运行正常。当大家认为系统已经运行稳定的时候，忽然收到报警，紧接着大家就一直埋头处理报警，直到下午才完全解决问题。发现是切换的操作步骤出现了问题，导致各系统间依赖访问量比平时大了很多，访问异常会再次出现恶性循环的重试，直到超过了系统最大的负载。
发现这个问题后，我们反思，如果我们的系统自我保护能力很强，或者我们的系统有降级方案，再或者我们有完备的应急预案……那么这个问题就不会这么轻易地危及到系统的正常运行，IPO在即，618在即，警钟已经敲响，我们必须行动。用一句话描述我们当时的状况，那就是“自助者天助之”。基于这套我们自己开发的系统，也是我们最为清楚和熟悉的系统，我们对青龙运单展开了一系列的可能出现问题点的设想。
1. MemCache缓存单点的问题，一旦性能出现问题，扩展不方便，且现在没有专门的维护团队；
2. 依赖底层基本资料服务问题，假如基本资料不可用，运单本身的部分服务也间接受到影响；
3. RAC生产库一旦出现宕机或性能问题，本身的性能会受到很大影响，间接影响到其他上游业务系统。
针对这些风险点，我们组内进行了多轮的头脑风暴，最终得出一套切实可行的解决方案。
经过了短时间的开发，第一阶段的成果在2014年5月初顺利完成上线。紧接着，我们开始了第二阶段的开发改造。第二阶段很重要，不仅留给我们的时间紧，而且修改点覆盖面广。从2014年5月中旬开始，对新的一版程序进行线上发布。这次发布后，我们专门对数据库的性能做了分析，发现加了全量缓存后，数据库的负载不但没有降低，反而升高了。经过分析最后认定是业务流水表缓存刷新的问题导致，最后针对业务量大、访问量少的数据缓存机制做了策略调整。再次发布后，数据库负载明显降低，缓存命中率直线上升。系统优化的同时，我们还编写了切实可行的系统应急预案，配套本次的优化改进。在所有优化点都上线后，经过评估，我们认定即使单量翻几番，系统也可以平稳的应对了。不平凡的2014年“2014年对于京东来说，注定是不平凡的一年”，李大学在今年的618会战中说道：“京东的技术研发团队在每一年的618实战中，都能够得到充分的历练。可以看到，我们的系统一年比一年完善，战绩一年比一年精彩。能参与618战斗的技术人是幸运的，如果要问我一个计算机工程师该以怎样的态度和方式来工作和学习?我有一条朴素的建议，也许能够很好地解答，那就是——参与618，发现问题，解决问题。不要绕开问题本身，多做事情，不会吃亏，即使不是你的事情。”这看似简单的建议，其实并不是很容易能够做到。但是，2014年的618，研发体系真正做到了这一点。（作者/马沛、许立龙、张侃、李刚、王先科）
2 骇客帝国——数据中心网络大优化
IPO蜜月期的6182014年的618，对于京东来说是一个具有非同寻常意义的618。
2014年5月22日，京东正式在美国纳斯达克挂牌上市。本来618对于京东研发来说，是每年一次的自我检验、持续提升的过程。但今年618却成为了京东IPO后需要向市场和投资者交付的第一张重要答卷，而京东研发所在的技术体系则是完成这项工作的重要环节。
仍处于IPO蜜月期的京东面临着一系列的挑战。首先，是IPO之后来自社会各方的压力。与往年不同，这次京东确实需要通过一个完美的618盛典来巩固自己的行业地位和增强投资者的信心。其次，是与易迅、微信等业务的融合。京东在IPO之前与腾讯迅速达成了战略合作关系，京东需要快速将战略合作成果落地，将资源和人气转化为收益。最后，是自身业务高速发展带来的压力。京东销售额连续多年以高于行业平均增速的速度增长，其影响直接体现在网站访问量、成交量和网络流量的倍数增长上。京东研发需要在满足业务高速增长的情况下，完成对架构和系统的快速升级和持续优化。
挑战和压力是客观存在的，虽然并不会因IPO而发生本质上的改变，但京东公司上上下下都意识到了这次618的特殊性和重要性，以及公司内外对这次618的殷切期望，因此，京东研发系统在备战618过程中，给予了更多的重视和投入。
618每年只有一次，但是从2013年618刚刚结束之际，京东研发的2014年618备战工作就已经开始了。核心服务
笔者所在的部门是隶属于京东研发中心运维部的基础架构部，主要负责面向数据中心的系统和网络基础平台的运营工作。
其中，京东数据中心网络，包含3个核心服务：CDW、负载均衡、基础网络。这3个服务几乎承载了京东所有的业务和流量，属于最关键的基础网络服务，直接关系到业务系统的服务能力和质量。也正因为他们属于支撑其他业务系统的基础平台，导致在建设周期、方案优化和架构升级等方面，受到更多的制约和限制。在业务爆炸式增长时期，基础架构更多满足的是业务高速增长需求，为此在架构可用性、扩展性等方面留下了很多问题和遗憾，进而影响了基础架构服务的长期可持续发展。随着业务系统的进一步增长、数据中心规模的加速膨胀，这些遗留问题的负面影响就愈发地突显出来，甚至造成业务应用服务质量和可用性的明显下降。
除了历史原因留下的旧伤，还有互联网技术发展带来的新需求。前端应用的技术演进、分布式系统的大量应用、云计算和SDN等新技术的推广，对基础架构提出了前所未有的挑战。这三项网络服务，都面对着看似各不相同的问题。CDN、负载均衡、基础网络面对的主要问题
CDN面对的问题2009年，运维部元老Gavin在对CDN几乎零经验的情况下，通过在网上查找资料自学、大量实验和环境测试，搭建了基于Squid实现的第一版京东CDN服务。出于好奇我特别找到Gavin了解当时决定自建CDN的原因，原来是因为当时使用的商用CDN服务出现了几次严重的故障，促使Gavin决定自己来做，看来自己动手的基因真的是深入互联网公司的骨髓。在无法获得更多外部支持的情况下，CDN团队几位成员自学自建，在不断摸索的过程中逐步发展和完善着CDN服务，京东CDN的规模随着业务和流量的快速增长也越发突显出其重要性。2013年上半年，京东CDN完成了全部节点从Squid向ATS的迁移，全国总共几十个CDN节点，承载了90%的互联网流量，当年618互联网峰值流量超过100G。相信很多企业都有过类似从无到有的成长经历，无论是对企业还是个人，这都是极其宝贵的财富。在信息高度发达的今天，我们可以通过各种渠道获得丰富的理论知识、技术方案和应用案例，但在面临诸多需求和选择的情况下，能够准确地把握核心需求、找到适合自身的最佳选择、确立中长期发展的方向和策略，恰恰需要在专业领域长期的实践和积累。但是，从2013年开始，CDN产品的一些问题也逐渐暴露出来，集群性能不足、系统结构缺陷、提展性较差等等，这些问题仅仅依靠升级硬件、更改软件、增加带宽已经远远不能解决了。另外，早期出于成本、需求等多方面考虑，CDN节点主要使用的是二级运营商的数据中心和网络，尽管其机房环境和服务水平远远优于一级运营商，但由于中国电信行业的特殊情况，导致二级运营商网络质量相对较差，这对京东网站的服务质量造成了致命的影响。
负载均衡面对的问题
京东自从开始使用负载均衡服务以来，就一直在使用商用设备。在业务上有客观需要，企业具有一定购买能力，但自身又没有负载均衡产品的独立开发能力的情况下，使用商业负载均衡产品似乎是一个自然而然的选择。
在京东的业务场景中，基本上所有面向公网的业务均通过负载均衡提供服务，与此同时面向数据中心内部的业务也大量使用了负载均衡技术，有一些确实是负载的需要，还有一些是为了容错，甚至一些 NAT 之类的网络服务也部署在负载均衡设备上。随着业务和网络规模的持续增长，负载均衡的压力也越来越大。伴随时间的推移，网络中出现了不同品牌、不同型号、具有相当规模的商用负载均衡设备。
终于，负载均衡服务的各种问题开始大量出现，主要是性能和结构的问题。无论是老款设备还是新型设备，都开始出现单机性能不足的情况，为了缓解设备压力只好不断增加设备数量、选择更高性能的型号。由于商用负载均衡产品基本都是两台一组的Active-Standby结构，因此每增加一组设备，就要将原有设备上的业务做一次拆分，这是一个非常痛苦、不优雅的过程，其管理维护成本高、风险大、缺少弹性。
实际上，此时已经有很多互联网同行在使用LVS等开源负载均衡软件，并形成了许多相对成熟的解决方案，为了与商用产品区别我们称之为软件负载均衡。但是，软件负载均衡需要具有一定的开发和调优能力，否则其服务能力还无法达到替代商用产品的水平。京东一直在软件负载均衡方面积蓄力量，只是还未遇到一个适时的引爆点。
基础网络面对的问题
基础网络主要具有3个核心功能，或者称为服务。
第一项是服务器等主机设备的网络接入服务，这部分功能主要影响的是主机设备网络的有效接入带宽和可用性。虽然从2010年之后数据中心以太网的物理接入带宽基本都达到了1000Mbps，但实际上由于TOR、汇聚设备等上行链路的带宽收敛，导致主机设备的平均有效带宽远远低于1000M。随着近些年主机设备流量的快速增长，接入带宽不足的问题愈发突显。
第二项是数据中心的互联网接入服务，这部分功能主要影响的是数据中心整体可以提供互联网服务的容量和质量。随着大型集群、分布式应用、大数据应用等技术架构的广泛使用，尽管互联网流量在保持较高速度的持续增长，但数据中心内部交换的东西流量增长还是远远地超过了互联网的南北向流量增长，二者对比由原来的南北向流量占大多数，转变为了当前的东西向流量占大多数。二者流量的总体增长给主机接入、互联网接入同时带来极大的挑战。
第三项是数据中心之间的互联服务，这部分功能主要影响的是网络对跨数据中心的数据调度和分布式应用的支撑能力，以及相对于互联网的网络质量优化能力。如果一定要套用目前最流行和高大上的概念，那么数据中心云就是这项服务的最佳诠释。数据中心界限的模糊化、网络服务的平台化，是上层应用和网络自身发展的综合需要。而高带宽专线、基于DWDM的传输系统是实现目标的必经之路，多数据中心的网络架构则是决定服务性能、扩展性的核心保障。
京东在基础网络上早期投入较少，在业务快速增长时，首先需要保证的是满足设备规模的增长，在网络容量、可靠性和扩展性方面没有来得及深思熟虑，而基础架构位于 IT 服务体系底层，建设周期长、迭代更新慢，很快在资源和性能方面出现了问题。例如，部分老网络存在10∶1收敛比的接入网络，在2010年后的网络设备替换时仍使用了HSRP+STP的结构，导致网络带宽和资源利用率变相降低，随着设备老化和规模增加，频繁出现带宽拥塞和局部故障。二级运营商的网络稳定性方面影响的不只是 CDN 业务，还影响着所有数据中心的公网业务。对于数据中心的内部网络结构，由于早期设计的缺陷，也降低了网络服务的稳定性和升级改造的可靠性，大量核心业务应用对网络的过度依赖，导致基础网络成为一个日益恶化的肿瘤，进退两难。
在经历了2012年618之后，我们逐步意识到，CDN、负载均衡和基础网络在上述各个方面存在问题的解决，已经迫在眉睫。提升改进
核心问题鉴定和发展目标确立
我们经过慎重的思考和总结，回避了大量应急救火的事务干扰，将面对的各类问题抽象为5大核心问题，即性能、容量、扩展性、可靠性和监控。基础网络服务持续发展的5个核心问题这5个问题，相互影响、彼此呼应，性能可以影响容量，容量规划依赖良好的扩展性，而无论多好的设计和架构如果没有足够的可靠性保障，就失去了最基本的价值和意义。而这一切，都需要通过监控系统进行分析和确认，在真实数据的基础上，掌握服务的运行状态，并根据数据和结果反向修正架构和策略，实际上这是一个服务可视化的过程。基于以上认识，在2013年618至2014年618这一年时间里，京东在数据中心基础网络服务方面实施了一系列颇具成效的举措。
CDN提升2013年上半年京东CDN全部改造为HAProxy+ATS的结构。接下来，首先实现了将HAProxy的单机性能提升一倍，在此基础上再将HAProxy的多个1000M网卡绑定方式升级为单个10G网卡接入，这样在除了网卡之外硬件配置不变的情况下就显著地提升了单台HAProxy的服务能力，这是商用产品很难达到的。CDN服务为支撑618完成的改进工作
其次，对软件负载均衡的架构进行升级，从Active-Standby双机主备模式转换为Multi-Active多主模式，这个转换是通过在集群中增加一台三层交换机来实现的。交换机完成基于流转发的ECMP工作，这样负载集群的容量上限就直接产生了至少几倍的增长，并且可以通过三层交换机16-Way ECMP、32-Way ECMP等不断提升集群的容量。京东LVS集群的架构升级
到这里就不得不提到实现了上述本质改变的核心人物思兴，正是思兴加入京东之后主导了对Linux内核、HAProxy和LVS相关产品的深度开发和优化，京东长期的积累和需求，与思兴的将想法实现的能力，像化学反应一样产生了神奇的效应。个人认为是思兴的工作成果，促使运维体系一些知觉灵敏者意识到开发工作的重要性，并将“开发”一词从纯面向前台业务突破到面向运维、面向一切需要开发的领域，这是另外一个话题，就此打住。
在上述两项核心优化工作完成的基础上，在过去的一年里京东CDN单节点实际部署的能力提升了6倍，全网CDN节点数增加了20%，并对全网超过50%的CDN进行互联网接入千兆改万兆的升级和架构升级，以及增加一级运营商网络CDN节点的比例。同时，针对业务需求实现了一些CDN功能升级，例如秒级清除缓存、热点URL负载等。最后，实现了对CDN节点流量和质量的分钟级监控，并实现基于日志的数据分析。
负载均衡提升负载均衡服务为支撑618完成的改进工作
京东一直在使用各类软件负载均衡产品，其中最常见的是LVS、HAProxy和Nginx。实际上思兴来到京东后的第一件也是最重要一件工作，是将软负载的集群确定为LVS+HAProxy结构，我和Apollo共同参与其中。经过几次结构优化，大量的问题处理和开发，最终稳定为Flow-based ECMP+LVS+HAProxy的结构，这部分优化内容与CDN的软件负载均衡基本相同。
与商用负载均衡产品相比较，软负载集群具备以下优势：
1. 性能和容量实现几倍到几十倍的增长；
2. 具有良好的扩展性，可以按需平滑水平扩容；
3. 具有良好的可靠性，局部故障不中断服务；
4. 可快速实现新增业务和管理需求，可维护性和可视化程度显著提高；
5. 同等性能成本显著降低，持续服务能力显著提升。
当然，设备数量增加、功耗增加、结构复杂度增加、管理维护成本增加也是显而易见的，但相对收益来讲这些代价几乎可以忽略不计。
在过去的一年里，软件负载均衡单机性能提升一倍，集群容量提高10倍，替代了90%的商用负载均衡设备，将接近90%的业务逐步迁移到软负载产品上，软负载集群规模扩大了10倍左右，服务中断时间大幅度下降。在开发和使用过程中，针对消除缺陷、性能提升和功能提升累计开发了三十多个补丁，增加了内核监控模块实现对VIP的Bps/pps/qps流量监控和面向业务颗粒的监控，解决了HAProxy多CPU负载不均、Keepalived特定版本因Gratuitous-ARP实现缺陷导致VIP主备切换失效等相对复杂的问题，并在2014年618之前实现了HTTP Anti-flood的一期功能。
思兴和其所在的系统开发团队，是实现上述工作的关键因素，个人认为这就是京东基础网络应用发生质变的引爆点。但不得不说明的是，如果优质产品是种子，那么良好运维就是种子赖以生存的土壤，优良的产品和设计是为了满足需求和解决问题，但脱离应用场景、偏离真实需求的产品设计容易出现闭门造车、纸上谈兵的问题。另外，再好的产品也需要优质的运维才能保证其持续、良好的发展，基础架构类服务更加看重产品的长久生命力和稳定性，只有开放、包容的技术环境才能产生优质的产品和服务。
基础网络提升基础网络服务为支撑618完成的改进工作
京东的数据中心基础网络，是所有已知问题中最突出的，因为它影响着所有上层服务和应用。在相当长的一段时间内，很多应用都认为带宽拥塞是导致其服务质量下降和引发故障的唯一原因。事实上一些早期网络环境中，10（1的接入网络收敛比也确实授人以柄，而更加麻烦的是由于网络监控远远落后于网络规模的发展，导致监控的覆盖范围和准确性不足以反映网络服务的质量和运行状态，这种功能缺失造成了业务与网络相互推诿、纠缠不清的局面。另外，早期网络结构的性能不足、不可靠导致一些本来微不足道的故障和操作，被放大成影响服务的事故和复杂操作，这些都给网络优化造成一定的障碍。
为了解决以上问题，京东网络团队从两个方向着手解决问题。
首先，解决影响用户的迫切问题。在遇到用户反馈的问题时，深入分析找到本质原因，进而确认基础网络最紧急和优先的问题。同时，自主设计和开发基于SNMP的网络监控工具，实现网络设备分钟级的流量监控，覆盖所有核心、汇聚、三层设备、所有接入交换机的上联接口，再覆盖一些收敛比较大的早期网络接入交换机下联端口。这样用户发生问题时，就可以准确认定位
试读结束[说明：试读内容隐藏了图片]