阿里巴巴集团成长集编委会
　　由阿里巴巴集团不同业务线及不同技术领域内的人员组成的虚拟组织。技术人员都知道软件开发过程中的八二原则，理解大多数问题发生在何处，发生的原因，如何解决，变得尤为重要。阿里巴巴集团业务飞速发展，技术人员积累了大量丰富的线上问题排查及解决的案例和经验。
　　成长集编委会从中挑选了一些优秀的技术案例，侧重于对问题的还原和分析。我们希望，曾经踩过的坑都能具有其意义和使命，而后来者通过学习前人的经验，防微杜渐，快速成长。

　　《逆流而上：阿里巴巴技术成长之路》是阿里巴巴集团荣耀背后的技术血泪史。《逆流而上：阿里巴巴技术成长之路》通过分享业务运行过程中各个领域发生的典型“踩坑”案例，帮助大家快速提升自我及团队协作，学习到宝贵的处理经验及实践方案，为互联网生产系统的稳定共同努力。从基础架构、中间件、数据库、云计算、大数据等技术领域中不断积累经验，颠覆技术瓶颈，不断创新以适应不断增长的需求。
　　《逆流而上：阿里巴巴技术成长之路》主要面向互联网技术从业人员和在校师生，使读者能够通过此书基本了解阿里在各技术领域的能力，学习在如此规模下可能出现的问题以及解决方案的探讨和沉淀分享。

　　这本《逆流而上：阿里巴巴技术成长之路》总结了近年来阿里巴巴集团在重要领域中遇到的故障和排查方法。从故障中得到的教训，剖析出来的架构缺陷，折射出来的实现问题以及运维过程中的疏忽和错误都是很真实的，很具有说服力。他山之石，可以攻玉，希望为广大开发和运维工程师带来帮助。

　　——阿里云资深总监吴结生



　　古语说：前人栽树，后人乘凉。本书创作旨在让历史的经验传承下去，帮助到更多的人。它汇集了阿里巴巴集团各个BU技术人员在日常工作中所遇到的典型踩坑案例，这些案例全部来自线上生产实践，涉及基础设施、中间件、数据库、业务开发以及稳定性建设，基本涵盖了阿里巴巴所有的技术兵种，这是一本非常全面的技术踩坑实践书，具有很重要的参考意义。

　　——阿里云研究员褚霸



　　阿里巴巴的技术人员日常的研发运维过程，就是不断和新问题斗智斗勇的过程，我们会鼓励把遇到的挑战和问题总结出来，所以在这个过程中积累了大量的总结资料，这些资料有些总结到了产品里，成为架构、系统的一部分，有些不断被学习变成了其他更多同事的新能力。

　　——中间件技术部研究员小邪



　　在我带领阿里巴巴GOC（全球运行指挥中心）团队期间，天天面对不断发生的大小故障，尤其是重复发生的故障。而此书恰恰是在这种思考之下所采取的行动之一。成功难以模仿，教训可以学习。每篇文章的背后都是血淋淋的教训，值得每一个技术人员好好阅读。

　　——菜鸟资深专家王乐

　　推荐序一
　　我从2009年9月25日奉命组建淘宝技术保障部，到2016年4月1日移交AIS(AlibabaInfrastructureService)给新任CTO，历时2380天、大约每3小时经历一次故障，可以说每天的生活就是从一个故障走向另一个故障，那段日子里我无时不刻不在琢磨如何保障并提升阿里平台的生产稳定性。淘宝/支付宝的可用性从2009年的99.5%到2010年的99.95%，到后来逐年提升并保持到现在的99.99%，由AIS牵头、协同集团各BU的技术小二集体为此付出了巨大而卓有成效的努力。从我的视角看，有以下三点经验：
　　一、做好顶层设计
　　“不谋全局者，不足谋一域”。生产稳定性的保障不能只埋头于一时一事的细节中，按照马老师在2009年底对我讲“不仅要救火，更是要防火”的要求，必须做好顶层制度设计：
　　1、研发和运维团队要能够“向对方靠近迈一步、互相理解和尊重”，这其中过程改进（SPI）和配置管理（SCM）同学们可以起到独特的承上启下贯通作用。这样技术保障部的基本组成是：
　　SPI+SCM+ProductionEngineer+DBA+System/NetworkEngineer
　　而且团队逐步要加强研发能力、能够对整个系统架构进行代码级的把控。
　　2、故障的标准统一以及处理流程的持续强化。2009年底我们讨论明确淘宝/支付宝的P1故障定义为“成交下跌10%且持续10分钟以上”，以此为准绳，统一思想和故障处理应急指挥体系，以及坚持事后故障复盘。事实证明，牵住了这个“牛鼻子”对稳定性工作有了很大提升。
　　3、坚持建设阿里经济体统一的基础设施平台。AIS从小变大的过程，就是淘宝、阿里云、B2B、支付宝等技术保障团队逐步融合的过程；也是原本分散的各种软硬件基础设施逐步融合的历程，坚持“书同文、车同轨、行同伦”。没有统一的基础设施和标准规范（包括IDC、网络、服务器、OS、中间件、数据库、业务应用、研发运维系统及工具、支持HTTPS标准等），就根本做不到今天的稳定性。
　　二、坚持技术创新
　　阿里巴巴过去18年的大发展是业务不断创新的过程，同样，阿里生产系统的稳定性也经历了持续不断的技术创新：
　　1、积极推动“去IOE”和金融级云数据库OceanBase的发展及成熟。此创新使得阿里交易和支付系统架构可以灵活支撑业务飞速发展，技术完全自主可控、积累了众多基础工程技术和人才，也大幅降低了技术成本。
　　2、“异地多活”和全链路压测。2010年我们就开始从青岛机房尝试做淘宝交易的“异地多活”，历经多年的反复技术尝试，终于有了今天北部、中部、南部的多机房同时支撑交易支付的能力。2012年双11零点惊魂促使我们下决心搞定“全链路压测”，用模拟的流量进行极限压测以获得生产系统的真实负载能力，经过2013、2014连续两年的实战摸索，现在已然成为我们双11稳定运行的利器。
　　3、云计算技术的逐步应用和强大。2009年阿里云正式成立，2012年双11天猫电商云平台“聚石塔”首次采用阿里云的产品支撑，到今天云计算在阿里巴巴平台广泛的使用和“云化”，都是咬牙坚持技术创新的结果。
　　4、统一计算平台到ODPS。没有统一的计算平台，不仅造成技术力量分散且成本不可控，更会导致数据生产和维护的混乱，是稳定性的大患。2014年启动“登月计划”，打造阿里集团统一的底层大数据平台，满足安全性、可管理、能开放等重要业务需求，在2015年6月完成了阿里所有数据业务的运行平台从Hadoop升级到飞天ODPS；同时在迁移过程中建立数据管理基本规则，做到业务的升级再造和数据通用。
　　三、组织管理创新
　　阿里经济体是一个朝气蓬勃的商业生态，一直在持续不断的进行业务创新；背后支撑这个生态的是一个超级复杂的技术体系，运行维护这个技术体系也需要进行组织管理方面的创新。
　　1、设置PE(ProductionEngineer，生产工程师)岗位，掌控业务应用的生产维护工作，这个岗位介于业务研发、DBA和系统及网络工程师之间，起到重要的桥梁纽带作用，为对口各BU的业务平稳运行负责。
　　2、成立GOC(GlobalOperationsCenter，全球运行指挥中心)、指定生产应急值班长，牵头负责整个阿里经济体技术平台的日常运行维护。故障的监控、报警、指挥、消防、事后复盘等全流程的运行管理，并通过持续的故障演练保障系统稳定性。特别的，2015年启动对核心交易和支付系统的“生产突袭”，是一种特别有效、真刀真枪的检验业务生产连续性能力的举措，应该长期坚持做下去。
　　3、面对“双11”的技术保障体系。针对每年一度的天猫全球狂欢节，日常的保障措施是远远不够的，需要成立单独的技术“团部”掌控全局、各关键链条上的BU成立“技术连部”决策局部稳定性，以及精干的“情报分拣中心”担当最辛苦的枢纽、负责判断每条业务线情报员上报的各种异常信息并即时给出动作。
　　有了顶层设计、技术创新和组织变革，最终落实生产稳定性的，还是靠一线技术小二一行行的编码、一次次的测试、日复一日不厌其烦的故障排查工作，以及我们对维护生产稳定性小二们工作的重视、肯定和发自内心的欣赏。他们不是所谓的技术大牛或大V，不会在各种论坛上侃侃而谈、也不会书写高大上的PPT；他们面对日常一个个突发的故障，遭受委屈、忍受冤枉、不惧倒霉，坚忍不拔；他们是脚踏实地、埋头苦干的无名英雄，是阿里技术的脊梁。这本书《逆流而上：阿里巴巴技术成长案例集》就是负责阿里大平台生产稳定性的部分技术小二的代表，把他们这些年在基础架构、中间件、数据库、业务研发、运行管理等大型互联网平台的稳定性建设中积累的实战宝贵经验，用平实无华的语言娓娓道来，这些技术沉淀既是对过往典型故障的深度分析，也是跟同行们切磋交流的宝贵知识财富。
　　我要深深的感谢过往七年里为阿里生产系统稳定性付出努力的所有技术小二，也特别高兴看到《逆流而上》的出版并愉快的推荐给所有关心互联网平台稳定性的同行们。
　　刘振飞
　　阿里巴巴集团首席风险官(CRO)
　　原阿里技术保障部(AIS)负责人
　　推荐序二
　　外界对于阿里巴巴技术的了解，大多要么是双11又创造了交易和支付的世界峰值纪录，要么是阿里云技术的高大上，要么是又出了什么黑科技，非常炫。在这炫丽的背后，有那么一群技术人，是他们支撑了7X24小时不间断的Online服务，是他们让无数的业务想法变成了现实，他们付出了艰苦的努力，也踩过了无数的坑，感谢在背后默默付出的阿里技术人！
　　这本《成长集》，从业务运行的角度，收集了不少的实际案例，来自阿里的多个技术团队，内容从第三方的运营商、DNS到IDC机房、服务器、网络到存储、中间件、数据库到业务系统和运行管理，几乎囊括了运行的所有技术环节。也验证了技术之外的经验“对生产系统保持敬畏之心”“千里之堤，毁于蚁穴”，所有的这些，都极具参考价值。
　　共享是互联网最重要的精神，阿里巴巴技术人希望将这些血和泪的教训分享出来，和技术同仁共同成长，如果说这些分享能够给同行带来一些共鸣或者启发，那将是阿里技术人最大的幸福！
　　周明
　　阿里巴巴集团副总裁
　　阿里基础设施事业群（AIS）
　　……

第1章基础架构高可用1
1.1明察秋毫，域名解析排查技巧2
1.2智能定位，网络端到端静默丢包点迅速锁定.14
1.3灵活调度，对接运营商网络流量的容灾策略21
1.4抽丝剥茧，深挖云盘挂起背后的真相.25
1.5存储的底线，SSD数据不一致34
第2章中间件使用常见隐患与预防.40
2.1高并发“热点”缓存数据快速“退火”41
2.2自我保护，让系统坚如磐石45
2.3机房容灾，VIPServer软负载流量调度实例51
2.4山洪暴发，高流量触发Tomcatbug引起集群崩溃.65
第3章数据库常见问题.80
3.1性能杀手，SQL执行计划.81
3.2波谲云诡，数据库延迟.92
3.3风暴来袭，AliSQL连接池调优102
3.4防患于未然，ORM规约变更案例110
3.5云数据库，SQL优化经典案例114
第4章业务研发经典案例.133
4.1幂等控制，分布式锁超时情况和业务重试的并发134
4.2另类解法，分布式一致性139
4.3大道至简，从故障模型的边界状态切换到原始状态143
4.4疑案追踪，JSON序列化不一致154
4.5从现象到本质，不保证顺序的Class.getMethodsJVM实现.163
4.6破解超时迷局，浅析启动初期load飙高问题172
4.7洞悉千丝万缕，浅谈JIT编译优化的误区180
第5章运行管理域稳定性建设187
5.1洞若观火，让故障无处遁形188
5.2体系化思考，高效解决运营商问题197
5.3以战养兵，以故障演练提升系统稳定性203