作者：阿里巴巴集团成长集编委会
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
逆流而上：阿里巴巴技术成长之路试读：
内容简介
本书是阿里巴巴集团荣耀背后的技术血泪史。全书通过分享业务运行过程中各个领域发生的典型“踩坑”案例，帮助大家快速提升自我及团队协作，学习到宝贵的处理经验及实践方案，为互联网生产系统的稳定共同努力。从基础架构、中间件、数据库、云计算、大数据等技术领域中不断积累经验，颠覆技术瓶颈，不断创新以适应不断增长的需求。
本书主要面向互联网技术从业人员和在校师生，使读者能够通过此书基本了解阿里在各技术领域的能力，学习在如此规模下可能出现的问题以及解决方案的探讨和沉淀分享。
自序
2017年7月27日，阿里巴巴集团（简称为阿里）市值超过4040亿美元，成为亚洲第一。回首过去18年的历程，伴随着阿里业务从电商快速成长到覆盖金融、云计算、物流等众多行业的是阿里技术人在基础设施、操作系统、中间件、云等各个领域孜孜不倦的探索、创新和实践。
在每一个技术领域，我们尝试过业务问题多种不同的解法，无论是新技术还是成熟的解决方案，我们都充分验证，直至完全掌握。但在我们看来，最宝贵的并不是我们最终采用某种技术或方案的决定，而是大家在探索中遇到的问题以及解决办法，是对每种技术深入研究过程中积累的经验，是基于对技术深入理解的基础之上进行调优和定制的实践。
随着互联网的浪潮日益高涨，我们看到越来越多的技术人开始经历相似的过程，单纯“拿来主义”的技术方案已经无法满足各个行业层出不穷的业务创新，唯有完全掌握技术才能使之贴合业务需求，更好地服务客户，而掌握技术的关键就在于解决它在实际应用中产生的问题。所以，我们把阿里落地各类技术过程中遇到的问题以及解决方案分享给各位同仁，希望对大家开阔思路、少走弯路能够有所帮助。
本书总结了阿里巴巴集团的技术团队在基础架构、中间件、数据库、业务开发以及运行管理等领域的经典实践，从采用的方案、遇到的问题、解决方法以及对未来的思考等方面，全面介绍技术实践的细节。在编写方面，本书注重实操，包含代码示例、排查思路及处理流程，以便读者快速应用到自己的工作中。本书也特别邀请了首任的阿里稳定性负责人振飞和周明为本书撰写推荐序，分享他们一路走来的酸甜苦辣。
非常感谢阿里各条业务线的技术同人，在百忙之中安排时间总结、整理并撰写案例，用他们的经验反哺技术同行，这也是阿里技术人为互联网技术不断创新贡献的一点微薄之力。沈乘黄阿里基础设施事业群全球运行指挥中心总监
推荐序1
我从 2009 年 9 月 25 日奉命组建淘宝技术保障部，到 2016 年 4 月 1日移交AIS（Alibaba Infrastructure Service）给新任CTO，历时2380天，大约每 3小时经历一次故障，可以说每天的生活就是从一个故障走向另一个故障，那段日子里我无时无刻不在琢磨如何保障并提升阿里平台的生产稳定性。淘宝/支付宝的可用性从2009年的99.5%到2010年的99.95%，到后来逐年提升并保持到现在的99.99%，由AIS牵头、协同集团各BU的技术小二集体为此付出了巨大而卓有成效的努力。从我的视角看，有以下三点经验。
一、做好顶层设计“不谋全局者，不足谋一域”。生产稳定性的保障不能只埋头于一时一事的细节中，按照马云老师在2009年年底对我讲“不仅要救火，更要防火”的要求，必须做好顶层制度设计。
1.研发和运维团队要能够“向对方靠近并迈一步，互相理解和尊重”，这其中的过程改进（SPI）和配置管理（SCM）的同人可以起到独特的承上启下的作用。这样技术保障部的基本组成是：
SPI+SCM+Production Engineer+DBA+System/Network Engineer
而且团队要逐步加强研发能力，并能够对整个系统架构进行代码级的把控。
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（Production Engineer，生产工程师）岗位，掌控业务应用的生产维护工作，这个岗位介于业务研发、DBA和系统及网络工程师之间，起到重要的桥梁纽带作用，为对口各BU的业务平稳运行负责。
2.成立GOC（Global Operations Center，全球运行指挥中心）、指定生产应急值班长，牵头负责整个阿里经济体技术平台的日常运行和维护。故障的监控、报警、指挥、消防、事后复盘等全流程的运行管理，并通过持续的故障演练保障系统稳定性。特别是2015年启动对核心交易和支付系统的“生产突袭”，是一种特别有效、真刀真枪的检验业务生产连续性能力的举措，应该长期坚持做下去。
3.面对“双11”的技术保障体系。针对一年一度的天猫全球狂欢节，日常的保障措施是远远不够的，需要成立单独的技术“团部”掌控全局，各关键链条上的 BU 成立“技术连部”决策局部稳定性，以及精干的“情报分拣中心”担当最辛苦的枢纽，负责判断每条业务线情报员上报的各种异常信息并及时给出动作。
有了顶层设计、技术创新和组织变革，最终落实生产稳定性的还是靠一线技术小二一行行的编码、一次次的测试、日复一日不厌其烦的故障排查工作，以及我们对维护生产稳定性小二们工作的重视、肯定和发自内心的欣赏。他们不是所谓的技术大牛或大 V，不会在各种论坛上侃侃而谈，也不会书写高大上的 PPT；他们面对日常一个个突发的故障，遭受委屈、忍受冤枉、不惧倒霉、坚忍不拔；他们是脚踏实地、埋头苦干的无名英雄，是阿里技术的脊梁。这本书《逆流而上：阿里巴巴技术成长之路》就是负责阿里大平台生产稳定性的部分技术小二的代表，把他们这些年在基础架构、中间件、数据库、业务研发、运行管理等大型互联网平台的稳定性建设中积累的宝贵的实战经验，用平实无华的语言娓娓道来，这些技术沉淀既是对过往典型故障的深度分析，也是跟同行们切磋交流的宝贵知识财富。
我要深深地感谢过往七年里为阿里生产系统稳定性付出努力的所有技术小二，也特别高兴看到本书的出版，并愉快地推荐给所有关心互联网平台稳定性的同行们。刘振飞阿里巴巴集团首席风险官（CRO）原阿里技术保障部（AIS）负责人
推荐序2
外界对于阿里巴巴技术的了解，要么是“双11”又创造了交易和支付的世界峰值纪录，要么是阿里云技术的高大上，要么是又出了什么黑科技，非常炫。在这绚丽的背后，有那么一群技术人，是他们支撑了7×24小时不间断的Online服务，他们付出了艰苦的努力，也踩过了无数的坑，是他们让无数的业务想法变成了现实，感谢在背后默默付出的阿里技术人！
这本《逆流而上：阿里巴巴技术成长之路》从业务运行的角度，收集了不少的实际案例，来自阿里的多个技术团队，内容从第三方的运营商、DNS到IDC机房，服务器、网络到存储，中间件、数据库到业务系统和运行管理等，几乎囊括了运行的所有技术环节，也验证了技术之外的经验“对生产系统保持敬畏之心”“千里之堤，毁于蚁穴”，所有的这些都极具参考价值。
共享是互联网最重要的精神，阿里巴巴技术人希望将这些血和泪的教训分享出来，和技术同人共同成长，如果这些分享能够给同行带来一些共鸣或者启发，那将是阿里技术人最大的幸福！周明阿里巴巴集团副总裁阿里基础设施事业群（AIS）第1章基础架构高可用
互联网、电子商务、云计算、大数据等领域都离不开基础设施建设，基础设施的建设包含从服务器到 IDC、网络等一系列的过程。技术日新月异变化的过程，也给基础设施的建设带来了巨大的挑战。如何用研发能力解决基础设施稳定性是基础架构不断提升核心竞争力的关键。
本章从线上案例入手，从基础架构角度介绍了问题排查思路和创新设计概念，希望给读者带来启迪。1.1 明察秋毫，域名解析排查技巧
背景
网站服务是现在众多互联网服务中应用最广泛的服务之一，而且中国的网络环境更为复杂，几乎每个应用都会使用到域名。域名在互联网应用中是非常重要的一环，万一出现问题可能会导致整个网站无法访问，并且由于各地DNS（Domain Name System，域名系统）缓存，有时候恢复解析所需时间会比较长。本节针对几种典型的域名解析问题，做了简单的排查思路介绍，以期与读者交流。
域名解析的过程
用户使用终端（电脑、手机、Pad 等）上网时，电脑会设置一组 DNS （即缓存DNS，又叫Local DNS）作为一层“代理”、“缓存”，为当地局域网或其他用户提供高性能的解析迭代查询。这个缓存DNS一般是在用户连上网时自动分配的，不需要手工配置。当用户访问网站时，如www.example.com，会向缓存 DNS发送example对应的地址的查询请求。当缓存DNS收到请求后，如果其有相应的缓存且没过期，则直接响应；否则，向根DNS、顶级域DNS、主域名对应的权威DNS或更下级的权威DNS进行查询，直到查询到最终的地址，然后返回给客户端。
对网站管理者（更准确地说，是域名的管理者）来说，需要为域名设置解析，将域名指向自己的网络服务器。购买了域名，一般会使用注册商的DNS（即将注册商提供的DNS服务器作为购买的域名的权威DNS服务器），或者使用第三方的 DNS。如果使用注册商的 DNS，设置解析的流程会比较便捷；但如果使用第三方的DNS，需要在第三方添加域名、解析记录，然后在注册商处修改域名的DNS作为第三方提供的DNS名字。
在上述描述域名解析的过程中，有两种DNS的角色：
· 缓存DNS，又叫Local DNS或Cache DNS，一般是由网络接入服务提供商在近上网用户端做的缓存 DNS 服务器，主要用于迭代查询的缓存，其中的数据均来自向上级的查询得到，本身并无实际的权威数据，这既增加了解析速度，又减少了对权威DNS的查询数量，就好比是数据库中的Memcache。
· 权威 DNS，又叫 Authority DNS。由域名管理者负责管理，或委托其他 DNS 服务提供商进行管理，其中的记录均是由负责本域的管理员添加进来的。权威 DNS 是由上到下一级级授权的，如根 DNS （ROOT DNS）将各个后缀授权到各个后缀管理机构的顶级域 DNS （即注册局的 DNS），而各个顶级域 DNS 中又有指向下级域对应的DNS。
如何判断是否是解析异常
网站无法访问有多种原因，如网络异常、服务器异常、网站配置不正确、代理服务器异常等。
当你访问网站时，如果打开的页面内容和预期的不同，或报错信息中含有“resolve”相关字样，或提示“找不到网站服务器”时，就应该怀疑是不是解析方面的问题了。
排查解析问题用到的基本方法是用dig（或nslookup，本文以dig为例来说明，nslookup 相关命令请参考其对应的帮助文档）看能否正常解析到最终的IP。
如果无法获取到最终的 IP，或者获取到最终的 IP 不是网站的实际 IP （这个由域名网站管理员判断），就是解析异常了。
如下是一个正常的解析（部分域名用example.com/bar.com/bar.net等指代，部分IP地址使用1.1.1.1、2.1.1.1、2.2.2.2等代替，后续类同）。
如下场景能获取到解析值，但解析到的IP是错误的（具体原因后续分析）。
解析异常的排查分析
解析的技术原理，就是域名从根域将顶级域授权给顶级域的权威服务器，再由顶级域的权威服务器授权给主域名的DNS权威服务器；查询时，客户端查询Local DNS，再由Local DNS向根域、顶级域、主域名的权威DNS 查询。如果解析的值是 CNAME 或 NS，则再次查询对应的值，直到获取到IP或超时。
排查时，也是按照这个原理来进行的。
正常的迭代查询结果
技术人员可以用dig做手工的迭代查询，如下是正常的查询。
域名不存在或域名被Hold
当域名不存在（如域名输入错误，域名过期被删除等），或者域名存在但被 Hold （如域名未实名认证等，根据政策的不同，可能会有被ClientHold/ServerHold 的处理。被 Hold 的域名将从顶级域的 DNS 服务器中被删除）。总之，是在顶级域的DNS服务器中，把域名向下级授权的NS记录（域名服务器记录）删除了，导致查询时无法获取到主域名的 NS 记录。前面看到正常的迭代查询，一级级的是：
.IN NS ROOT_NS
TLD.IN NS TLD_NS
NAME.TLD IN NS DOMAIN_NS
HOST.NAME.TLD IN A IP
而域名不存在的，可以看到查询结果中并没有出现not-exists-domain.com**IN NS dns.dnsname.com 这样的记录，在顶级域的DNS中返回的是SOA记录（如SOA a.gtld-servers.net.nstld.verisign-grs.com.1493003321 1800 900 604800 86400）。
不存在域名的dig例子。
被阻断
正常的迭代查询是根、顶级域、域名的权威DNS一级级的NS授权，如果被阻断，在应该返回NS记录的响应中获取了A记录，而中间缺了DNS的由上到下的一级或多级的授权NS记录，这不合常理。
如下是被阻断域名（即在查询的过程中被劫持了，查询路径上某个服务器响应了一个伪造的DNS响应包，里面包含一个不正确的值，而这个包客户端无法分辨出真假）的dig例子。
缓存DNS劫持
如果配置的解析是到某IP地址A，而在有的Local DNS上却响应的是地址B，则可能是被缓存DNS劫持了。
国内的运营商有可能会在缓存DNS上做特殊的配置，将某些不存在的解析，或解析超时的解析指向其所谓的“纠错”页面，展示一些其运营商的业务内容。同时，如果运营商的缓存DNS安全性不足，则有可能被黑客利用，为缓存DNS投毒，导致域名被劫持到黑客设置的钓鱼网站。
如果发现域名在缓存DNS上解析出来的值不是自己设置的值，一定要提高警惕。
CNAME值无法解析
因运维的方便，或因域名解析管理的授权，很多时候会将域名做CNAME记录，交由另一个域名的管理者来管理，以指向最终的IP地址。最典型的这类应用是CDN服务：网站管理者将自己的域名指向CDN厂商提供的域名，由CDN厂商再将域名指向各地的CDN节点IP，或指向NAME （或多级CNAME）后，再指向最终的IP。也有些虚拟网站提供商或其他互联网应用提供的是一个子域名，需要服务的使用者将域名添加CNAME类型的解析，以指向这个名字。
再去查www.example.com.bar.net时，却查不到对应的下一层记录了。
部分解析异常
域名会指向两个或多个DNS服务器。但有时候会不小心同时指向多家DNS提供商的DNS服务器。如果服务器更换IP后只修改了其中一家DNS提供商的解析记录而忘记修改另一家了，就会造成解析有时候正常，有时候解析到旧的 IP地址上，或者使用其中一家的 DNS服务过期而清理了记录，也会造成解析不稳定，时好时不好，或部分地区不正常。
更换DNS但尚未完全生效
域名更换DNS提供商，或由第三方DNS提供商换为自己的DNS等，可能会涉及在新的DNS服务器上添加解析记录，然后在域名注册商处更改域名的 NS。但是，更改 NS 后不要急着在原 DNS 提供商处删除域名的记录。因更改NS后，最长48小时才能在全网生效，在这期间会有部分请求到原来的NS服务器上。如果原来的NS服务器上解析记录的整个域被清理了，则解析就会中断，造成部分用户无法访问。所以，更换域名 NS 时，一定要保证新老NS服务器上均保留一份正确的记录，且在老NS服务器上最少保留48小时。
resolv.conf配置不当
默认情况下，解析域名超时时，会进行重试。但有时候为了提高性能，会把超时时间缩短或限制重试次数，而当Local DNS中无缓存时，解析的时间会相对较长，也会导致解析偶尔失败，且问题不好处理，排查问题变得困难起来。如下面配置文件中的“options timeout：1 attempts：1 rotate”，即设置超时1时重试1次，这样的限制太严格了，建议删除这行配置而使用系统默认的值：
小结
域名是很多网络服务的入口，出现异常会造成很大损失，有时候由于各地缓存而造成域名问题无法快速恢复。
作为维护人员，在处理域名相关的变更时更需要多加注意。比如：域名是由权威 DNS和各地运营商或第三方机构的缓存 DNS等，在转移权威DNS服务提供商要在旧的DNS提供商中保留正确的解析至少48小时；在自己搭建DNS时，多加测试，注意兼容性；在配置多线路的智能解析（不同来源，指向不同的地址，即让DNS根据来源的不同而返回不同的值）时，要注意每个线路均能正常解析。出现问题时，可借助 dig/nslookup 等域名诊断工具以及域名的whois信息来诊断。1.2 智能定位，网络端到端静默丢包点迅速锁定
背景
随着阿里巴巴集团业务的高速发展，数据中心的数量和规模都在快速扩张，网络运营的设备数量、型号、软件版本的类型均呈快速增长的趋势，网络规模的扩张导致了相同故障发生概率下出现设备转发异常的次数也在不断增加，对业务影响和网络运营带来了很多风险和挑战。
常见的网络丢包故障发生在线路和端口级别，大都是因为线路质量劣化、线路流量拥塞、光模块故障等，这类问题网络运营团队有成熟的监控和自动化处理手段，可以确保故障被快速发现、定位和恢复。
在各类转发异常中，最困扰网络运营的难题就是静默丢包。静默丢包是发生在设备内部转发层面的，没有任何异常日志或告警的丢包故障。由于没有任何迹象可寻，静默丢包的发现和定位都是一个难题。
随着网络规模不断增加，网络设备静默丢包虽然为小概率事件，但其故障数量呈上升趋势，较长的故障定位和恢复时间都是业务所不能容忍的，网络运营是时候向静默丢包正式宣战了！
异常表现
静默丢包主要有下述异常表现。（1）特定流持续不通。（2）持续网络重传。（3）特定大小报文丢包。（4）固定时间出现丢包异常。
原因分析
若对静默丢包的原因进行详细分类，可以归为以下两类。
第一类：软失效
Parity Error产生的原因是芯片软失效，Parity Error是芯片软失效的一种校验方法。软失效是指高能粒子单元对芯片晶圆的撞击导致比特翻转而引起单比特错误、多比特错误及栓锁等，由于它对电路的损害不是永久性的，所以这种现象被称为软失效。
产生软失效的原因有以下三种。（1）芯片封装材料含有放射性元素引发芯片软失效。（2）来自宇宙和太阳系的高能中子芯片的原子核捕获产生附属的带电粒子，进而引发芯片软失效（是的，经常被大家调侃时说的太阳黑子爆发导致数据中心异常是真实发生的）。（3）低能中子会和芯片内部绝缘体材料发生原子反应，产生高能粒子，引发芯片软失效。
软失效易发生于半导体存储芯片中（如DRAM、SRAM、寄存器组），以及高速缓存和配置寄存器设备等。目前软失效无法完全避免，具有随机性和不确定性。软失效一般都是静默丢包问题的主要来源。
软失效又分SBE（Single-Bit Error，单比特错误）和MBE（Multi-Bit Error，多比特错误）两种情况，所谓单比特错误SBE，是指在一个数据字中因为芯片软失效引起的一个比特的错误，而多比特错误 MBE 是指在一个数据字中因为芯片软失效引起的两个或多个比特的错误。通常，发生多比特错误的概率较低，但一旦发生，就极难纠正错误比特。
为了降低软失效问题发生的概率，芯片和半导体厂商分别从工艺和系统两个方面着手改进。工艺级措施方面选用放射性元素含量极低的封装材料和采用新的绝缘体材料技术，系统级措施采用奇偶校验（Parity Protection）、纠错码（Error Correction Code，ECC）和双存储器的软硬件比较等技术来预防软失效的发生。
现有网络中各商用设备在关键转发表项上通过 ECC 字段来检测 SBE和MBE，当发生校验错误时通过发出告警信息告知用户，同时硬件可以通过ECC字段信息自动纠错SBE，但无法纠正MBE，MBE则是通过上报中断，采用软复位（soft reset）、硬复位（hard reset）或软件重刷硬件表项。这些都依赖于芯片厂商的开发程度、检验和恢复机制，以及设备厂商的软件支持程度，如果芯片和SDK支持不足对一些非关键表项没有覆盖检测和自修复，又或者在芯片没有覆盖到的关键表项，设备厂家没有通过有效的软件机制解决都会导致网络设备出现静默丢包的问题。
第二类：设备硬件故障、软件缺陷和性能问题
设备单板芯片或外围器件硬件故障，软件本身机制考虑不全或实现有误等缺陷以及设备内部通道异常或拥塞都会导致业务出现丢包或异常篡改。对于设备硬件故障和软件缺陷之类的各个版本和厂家的问题具有多样性且无通用性，这里就不展开了。
故障发现
现有的静默丢包网络监控手段有传统手段（SNMP（简单网络管理协议）集采和实时系统日志分析）、主动测试发现手段（各种大小报文并且变换源目的TCP端口的TCP fullmesh（全网状）ping）和人为可定义的巡检系统，但是受限于监控周期、巡检和flow覆盖能力以及安全要求，仍然会有一些特定五元组报文不通或间歇性丢包重传等静默丢包问题需要依靠业务上报。
故障定位和处理
由于业务提供访问异常流量的源目的在转发路径上会经过很多网络设备，在问题定位过程中需要在所有的网络设备端口上去部署流，然后根据比较计数来定位丢包点，这就要求对流统flow（特定五元组的流量）灵活的打标和染色能力进行计数比较来确定问题。
这里分别从特定流不通和随机丢包两种情况来说明传统的定位方法和步骤。
第一类：特定流不通
这种问题属于静默丢包类最常见的问题，业务抓包可以发现特定五元组的包数据持续永久不通，对于这种转发路径上报文计数从有到无的异常，相对来说定位条件和难度较低。假设现在发现源端口 1234、目的 IP 和端口为1.1.1.1：80的syn包不通而源端口为1235时是通的，则可以使用命令：sudo traceroute-Tp 80--sport=1234 1.1.1.1 和 sudo traceroute-Tp 80--sport=1235 1.1.1.1，这就相当于分别用异常流和正常流去做traceroute比较看断点在哪里，在断点的上下游设备上分别做流通，这种方式也受限于服务器本身 traceroute的版本和设备的 ttl超时答复功能开启等，通用的方法是服务器构造持续发送不通的特定流，路径上做流统抓取从有到无的故障点。
第二类：随机丢包
这种问题对传统定位具有很大的挑战性，不是有和无的区别，而是多和少。正如前面描述的流统局限性，先要搭建一个和业务流相近的环境，然后在所有转发途径的设备端口部署流统，这需要大量的人力资源和时间成本。
综上所述，流统是一个原理简单、定位准确的静默丢包定位手段，但是其最大的弊端是策略部署和报文统计环节的工作太重，需要在业务流所途径的所有 ECMP（Equal-CostMultipatchRoutig，等价路由）路径去部署策略并统计结果，人工实施一次流统大概耗时几个小时，如果一天要排查多个静默丢包的问题，其工作量可想而知。
由于这类问题的定位思路和方法是可以固化的，而且传统方式依赖于个人对设备命令的熟悉程度，并要自己去分析转发路径。因此，网络人员将固化的经验沉淀到系统中，以实现智能流统的自动化运营手段来提升整体工作效率。下面将详细描述静默丢包智能流统工具的实现和定位思路。（1）寻找丢包五元组
由于业务人员的水平参差不齐，无法准确给出丢包的五元组，这就需要借助智能化流统工具来定位发生丢包的五元组。输入用户提供的源目的IP后，系统会以源端自动构造报文（源目的端口不断变化）发送到目的端，目的端进行报文分析并返回结果，如图1-1所示。图1-1 定位丢包五元组的结果（2）自动发现网络拓扑、下发流统策略并发起测试
如图 1-2 所示，系统会根据输入的 AB 端服务器信息，自动发现途经的端到端网络拓扑，生成源到目的的转发路径，并下发流统策略，完成流量策略部署后，系统会通过安装在服务器上的AGENT，从服务器发起针对特定流的发包测试。图1-2 自动发现网络拓扑并部署流统策略（3）流统结果采集和诊断结果的展示
这个步骤是将所有设备上的流统计数进行采集分析并图形化展示丢包位置，该步骤代替了人脑分析的过程，自动反馈有问题的故障点并标红，这个时候整个定位过程就算完成了。
此时我们可以看到集群出口交换机的一条链路in流量已经减少了，证明流量在POD出口交换机→集群出口交换机转发时发生了丢包，如图1-3所示。图1-3 故障定位段落展示
在明确故障点之后，通常是优先恢复业务，由于网络设计上的冗余性，可以直接隔离异常芯片或板卡。通过隔离处理后发现业务恢复正常。
小结
通过智能流统的实现，逐渐将人从重复及固化的操作中解放出来。从人力上讲，传统方式需要多个跨团队的人员协作，演变成个人单兵作战完成问题定位；从时间上讲，由几小时简化到几分钟，大大降低了故障影响并缩短了定位时间。
未来，智能流统工具前向会和业务告警、网络监控系统结合，在业务异常时，自动启动并快速定位故障段落；后向会和网络自动化运维平台打通，在定位问题后触发自动化隔离，实现故障的自动发现、定位和解决，真正做到自动化运维。
随着更多的自动化运维工具的上线，也使网络运维自动化越来越迅捷和高效，网络运营已经进入了自动化、智能化的新阶段。1.3 灵活调度，对接运营商网络流量的容灾策略
引子
客服人员：“多个业务页面无法访问，集中在 A地区，基本都为 X运营商网路，已经收到大量客户反馈了。”
网络人员：“A 地区 X 运营商网络问题，已联系运营商，已经在修复中了。”
客服人员：“估计需要多久，用户们都很着急。”
网络人员：“暂时无法确定，在等运营商回复。”
客服人员：“恢复了吗？”
网络人员：“估计还需要2小时。”
客服人员：……
这样的对话在客服人员和网络人员之间经常发生，也经常有人发出这样的疑问：“当运营商网络出现问题时，用户真的只能干着急吗？”运营商修复时间一般较长，用户的业务受损是等不起的，那有什么其他办法降低影响吗？
背景
某日，网络运营团队通过互联网质量监控系统发现全国所有电信用户对华北一地区访问质量劣化，现象为该地区城网至电信全国所有方向网络发生大面积质量劣化，5 分钟后，网络人员快速执行流量调度容灾预案，将流量调度至其他地区后，用户业务影响恢复至正常水平。
为什么这次的运营商网络发生异常，网络运营团队可以快速恢复呢？下面会详细说明运营商容灾切换能力的建设过程。
原因分析
阿里巴巴在国内多个区域对外提供服务，每个区域都和国内的三大运营商及重要的二级运营商建立了带宽充足的互联电路。
如果在阿里巴巴某区域当地互联的运营商网络内发生故障，就会导致该运营商的所有用户访问阿里巴巴该区域的业务时，发生访问质量劣化，也就是本文开始时发生的那一幕。如果运营商骨干网发生故障，则可能导致运营商网内用户访问阿里巴巴多个区域时均发生不同程度的质量劣化。在运营商网内发生上述故障时，通过几个层面的合理流量调度，可以消除故障影响，快速恢复业务。
业务自身调度
某用户如果购买了多个区域的阿里云资源向外提供服务，并且实现了较好的业务容灾机制，当区域A的运营商X网络发生故障时，用户可以通过DNS容灾切换或CDN调度容灾切换，快速将区域A的业务切换到区域B，此时运营商X全国的用户访问原来受影响的区域A的服务时，实际访问路径已经切换到了区域 B，成功绕开了运营商 X 在区域 A 的网络故障点，快速恢复了业务。
对于重要业务，特别是易受到运营商网络内的时延大、抖动、丢包影响的网络质量敏感型业务，应重点建设业务层面的多地容灾切换机制，确保业务快速恢复。
阿里巴巴网络的区域出口容灾调度
要实现网络级别的快速容灾调度，秒级的互联网监控发现能力、故障调度决策系统和骨干网级别的SDN调度能力都是必不可少的。
秒级互联网监控系统：通过在运营商网内部署监测点，实时发起流量监控，阿里巴巴的业务监控团队可以模拟运营商用户对阿里巴巴业务的访问请求，一旦运营商网络内发生故障，该监控能力可以实现秒级的故障发现和定位，故障定位的精细程度可以细化到运营商网内地市级故障、省网级故障、骨干网级故障及阿里巴巴区域出口级故障等，应该说故障发生的位置距离阿里巴巴某区域和运营商互联的出口越近，则对阿里巴巴该区域的业务影响也就越大，当然运营商骨干网级别的故障可能对阿里巴巴多个区域的业务都会造成影响。
容灾调度决策系统：秒级互联网监控系统会将发现和定位的异常告警发送给容灾调度决策系统，决策系统会根据问题严重程度和故障定位情况，决策是否执行容灾切换，并将决策指令发送给阿里巴巴骨干网SDN调度系统。
阿里巴巴骨干网 SDN 调度系统：收到决策系统的调度指令后，SDN调度系统会通过调整阿里巴巴网内路由策略及和运营商互联的网间路由策略，实现运营商出口容灾切换，将区域A和运营商X的全部互联流量，双向都调整到区域B和运营商X互联的电路带宽上；业务访问的路径将从运营商直接访问区域A，变为运营商访问区域B，流量到达区域B后再通过阿里巴巴内网到达区域A，从而绕开运营商网内的故障点。
运营商出口容灾切换相比第一点提到的业务自身的容灾切换，其影响面较大，被切换区域的所有业务访问路径都会发生变化，伴随而来的是访问时延可能会造成一定增加，一般只有在区域A直连的运营商网络发生重大故障，影响了该区域所有业务访问时，决策系统才会决策这种区域出口级别的切换。
阿里巴巴网络的精细化容灾调度
如果运营商骨干网络发生故障，则现象是运营商部分省访问阿里巴巴区域A的业务质量发生劣化，此时如果决策区域出口切换动作显得太重，而且不能有效解决问题（即使将流量调整到区域 B，运营商网内仍有部分省访问区域B不好），就需要更加精细的SDN容灾调度能力。
对于这种SDN调度能力，阿里巴巴的出流量可以实现100%的精准调度，入流量的调度还要依靠运营商网络架构的合理性和规范性来配合实现。小结
综上所述，经过阿里巴巴网络运营团队长期的经验沉淀、总结提炼以及工具开发，通过互联网秒级监控系统、容灾决策系统和骨干网SDN调度系统的实现，对于运营商网内的故障，再也不是无计可施，而是拥有丰富的容灾切换能力，进一步结合业务自身的容灾切换能力，可以实现大部分问题的快速解决。1.4 抽丝剥茧，深挖云盘挂起背后的真相
引子
阿里云使用飞天分布式存储系统作为虚拟机云盘的终端设备，其主要有三个角色。
· master：负责集群元数据的管理、集群健康检查、数据安全等，多master之间采用primary-secondaries模式，基于PAXOS协议来保障服务高可用，primary 在地址服务器注册访问地址，多 master 在检测到primary异常后会自动修复，选举出新的primary。
· chunkserver：负责实际数据存储，通过冗余副本提供数据安全性。
· client：对外提供类 POSIX 的专有编程接口，存储服务的入口，满足多种场景下数据存储的需求。通过查询地址服务器解析 primary master地址，从primary获取元数据信息后和chunkserver交互完成数据存储。
背景
某日凌晨2点45分，阿里云ECS某测试集群存储系统primary master发生切换，随后陆续有虚拟机报警发生云盘挂起。2点53分，集群异常虚拟机开始逐渐恢复，2点54分，除个别长尾外，全部恢复正常。后来，开发人员调查发现该集群存储系统原 primary master 发生了磁盘故障，并在13 秒后主动触发了切换，新 primary 状态正常。磁盘故障后，master 行为完全符合预期，理论上虚拟机应该无感知，但现实是仍有部分虚拟机发生了云盘挂起。
原因定位
存储系统 primary master 因磁盘阵列卡或磁盘故障造成不可服务的问题之前也遇到过，为此，技术人员开发了存储健康检查功能，当 primary master发现服务异常后会触发primary自动切换。通过分析新primary master日志，确认此功能正常，老primary磁盘故障发生13秒后就主动触发并完成重新选举，新primary开始接受请求并对外提供服务。
存储系统新 primary 选举出来后，仍有虚拟机发生云盘挂起的现象和预期完全不符。因为老 primary 磁盘故障后先转变成只读，之后服务器重启以恢复服务，造成老primary服务日志全部丢失，这增加了调查的难度。后期通过仔细调查分析，发现如下不可解释的现象。
· 新primary服务器有老primary主动触发切换相关的日志。
· 老 master在切换后直接调用地址服务接口停止primary地址更新，同时调用ServiceExit退出，全路径无磁盘操作，理论不受磁盘影响。
· chunkserver 上和老 master 相关的远程调用（RPC）调用在 2 点 48分停止。
· 发生云盘挂起的虚拟存储系统client持续访问老的master。
因为当前运行的存储系统软件支持 Primary Master地址缓存功能，所以最初怀疑异常的虚拟机是否和缓存没有及时更新有关，但经过进一步排查，排除了这种可能，存储系统新老 primary从 02：45：17到 02：52：55在地址服务器频繁交替更新primary master的服务地址。
由上述现象可知，老 primary 进程的服务线程都已经停止工作，但是负责更新primary master服务地址的线程没有退出，并持续更新。在长达7分钟的时间内，更新线程能正常工作，无任何磁盘操作的ServiceExit未成功，后台负责停止更新线程服务的线程也不能正常执行。
根据存储系统的设计，primary master在启动后就会有一个单独的线程定期检查一个 volatile 变量 mMasterHasSuicide，如果 mMasterHasSuicide为true，直接调用AddressResolver：：Unregister停止更新服务地址。
mMasterHasSuicide设置为true是在触发切换后第一条指令，切换完成意味着mMasterHasSuicide肯定已经为true。另外，更新完mMasterHasSuicide后，老的primary master也会走自杀流程。
技术人员最初怀疑日志操作可能因磁盘故障造成退出失败，但经过仔细检查复查代码确认master使用全异步日志模式，服务线程只在内存中生成日志内容，由后台写盘线程负责日志落盘，服务线程不会因为磁盘故障阻塞。
存储团队的开发尝试多种方法调查问题的根本原因，但都收获不大。最终在翻查系统日志时，无意发现/var/log/check_hw/basemessages 记录了大量IO异常的日志，时间点恰好是问题恢复后。
根据统计结果，从02：52：52到02：52：55总共有211个扇区发生磁盘操作超时，通过把日志中的扇区转换成文件系统块号，然后使用系统工具debugfs的icheck命令可以查询其隶属的inode，使用ncheck命令可以完成inode到文件名的转换。但是在实际使用中发现，查询过程很慢，期间utility磁盘利用率一直保持在100%。既然通过文件系统块号查文件名方案不行，那反过来查是不是就没那么慢了呢？通过如下命令可以快速查询某个磁盘设备（比如挂载到/apsara的sda6）上文件和块号的对应关系。
得到输出结果之后，技术人员写了一个脚本，解析输出结果构建块号到文件名的索引表，并扫描了 211 个扇区对应的文件。经过分析发现，大部分报告磁盘操作超时的扇区对应文件已经删除，没有删除文件也基本是日志文件，在过滤掉这些文件后，剩余两个程序的可执行文件。
根据文件名和块号，可以获取块对应的storage_master文件内容。
从上面的信息可知，块 69757970正好对应 master文件在 ext3文件系统中的二级索引表（DIND）。所以，理论上，这个块发生读超时的话，超时期间，master从第1036个逻辑块开始的数据都不能访问了。基于上面的日志信息，技术人员推测，对于master的代码，操作系统默认不会把所有数据都从磁盘加载到内存中，只有在执行过程中，访问内存发生缺页中断，master 才会把相应的代码从磁盘加载到内存并继续执行，而如果发生磁盘挂起的情况下，读master程序主体数据在访问二级索引随之挂起，导致需要的代码不能加载，也就不能执行，从而触发了虚拟机的云盘挂起。
细节分析
为了证明这个问题，需要确认 AddressResolver：：Unregister 和ServiceExit 的代码在问题期间没在内存中，但磁盘故障机器已经被重启，不能直接验证这个猜测，所以技术人员用新 primary master 内存状态间接验证这个结论。
通过上面的分析信息可知，storage_master物理文件从位移0开始的内容被映射到从0x400000地址开始的一段内存空间。所以AddressResolver：：Unregister 和ServiceExit分别对应文件的逻辑块号[8700，8700]和 [7461，7462]都需要 storage_master 文件的二级索引信息才能正常访问。
Linux提供的mincore函数能够判断一个文件的某些块是否在内存中，在primary master正常运行一段时间后，我们使用基于mincore的开源工具vmtouch查看代码在内存中的加载情况：
分析发现，块7461（0x1d25）在内存中，块7461（0x1d26）和8700（0x21fc）不在内存中，块 7461 因为 ServiceExit 前面相邻代码被执行过，所以被捎带加载了，而 ServiceExit核心代码及地址服务的Unregister相关代码则因为从来没有被执行过而没有机会被加载，符合之前的推测。
确定原因后，我们模拟触发场景做了故障重现。
· 把存储服务storage_master 程序主体在内存中的缓存清除。
· 启动前端压力，让服务稳定运行一段时间。
· 加载磁盘读写劫持内核模块，drop掉master binary所在磁盘的所有IO。
分析模拟场景下存储服务master行为确定和异常集群相同，master没有退出，地址服务线程仍继续更新地址，最终确定问题原因。
解决方案
短期方案
· 在存储系统master进程启动后，master会通过mlock方法把程序主体对应的数据加载并锁定到内存中。
· 地址服务不再通过调用方法停止 primary 地址更新，而是在地址更新主路径检测某个变量的值，判断是否需要继续更新。
长期方案
· 存储系统去除对地址服务的强依赖，存储系统的客户端启动后会缓存master地址信息，并内部维护master地址的正确性，不再强依赖外部地址解析服务。
· 地址服务提供基于 version 的地址更新接口，避免老 master 用过期地址覆盖有效地址。
小结
存储服务master模块为了应对类似的磁盘故障，在开发过程中被精心设计了双重保险以确保其退出或者无害，其一是调用ServiceExit（内部调用_exit）以强制跳楼的方式退出；其二是调用地址服务的反注册接口，要求其不再更新老master地址，这样即使没有及时退出也无害，并且确保这两条路径中都没有阻塞的同步磁盘操作，以避免磁盘故障导致线程挂起。
本次磁盘故障中，双重保险的两个独立线程异常处理流程从来没有被跑到过，所以运行到相关路径时发现对应的代码段都不在内存中（线下演练，发现这是一个概率事件，与编译环境、运行环境、内存状况等众多基础环境因素相关），运行时产生缺页中断，中断处理程序会从磁盘上加载对应的代码段，因为磁盘阵列卡或磁盘故障，导致内核的中断处理线程挂起，代码段加载不回来，进而导致用户态的这 2个线程也挂起了；此时另外一个地址服务后台更新线程因为从启动开始就更新master地址，所以一直在内存中，从而运行没有受影响，在新master向地址服务器设置好正确地址后，它会反复用已经过期的老地址覆盖正确值，导致客户端解析出来的存储系统master地址一直在新老地址之间变化，最终部分虚拟机因为每次都拿到错误地址，造成云盘挂起。1.5 存储的底线，SSD数据不一致
背景
某业务方开发人员发现服务器异常掉电后，系统的文件数据不完整。
如图1-4所示，开发人员认为在035C7000这个文件地址之后，仍然有30KB 的数据，但服务器重启之后，文件显示这部分为空，直接读取数据发现全为0。他们怀疑这台机器的存储硬件（PCIE-SSD）出现了掉电丢数据的问题。图1-4 系统文件数据异常日志
问题排查
接到开发人员的问题，存储团队立刻进行了跟进，首先分析了PCIE-SSD的掉电数据保护机制。
PCIE-SSD对于异常掉电，有完善的保护机制，且根据之前的白盒黑盒的数据一致性测试和反复掉电测试，未发现问题，初步排除硬件方面的问题。深入分析
通过和开发人员的沟通，存储团队了解到业务方使用pwrite写数据，使用O_DIRECT，没有加O_SYNC。
这是一个非常大的怀疑点，如果没有O_SYNC，文件系统的元数据可能在掉电时并未写入PCIE-SSD（O_SYNC，在每个写操作，会等待磁盘返还结果后才返回，确保了数据一定落盘）。
但是要验证这个猜想，需要证明数据在 PCIE-SSD 上，仅是文件系统读不到这个数据（因为没有文件系统元数据）。
如图1-5所示，图中的0000512这一行，就是上面的035C7000。继续往下读（如图1-6所示）。图1-5 直接读取Aliflash裸数据图1-6 读取文件
连文件末尾的结束符都对的上，大小还刚好是业务方丢的 30KB。将此发给业务方确认，数据的确在盘上。
由于文件系统元数据未刷入磁盘，导致文件系统层面没有这个映射关系，所以读文件读不出，造成了数据丢失的假象。
相关知识点
试读结束[说明：试读内容隐藏了图片]