收到了猫大人对瞅瞅君的人生第一封投诉信：

投诉信

原因之一是瞅瞅君虽然尽最大努力想快点回家but还是被所谓创新会拖延至12点...听着愁愁君巴巴布拉的吐槽之时猫大人很鄙视--你不也是其中一份子吗？！

原因之二是猫大人头一天因感冒请假，自以为可以错过听写暗自得意，结果昨天“一对一”的超高级待遇--补听写，且错的有点惨...让猫大人觉得“今天真倒霉”（对不起，哈哈哈哈哈哈哈哈..........）

好吧~我错了

明天继续努力！

咱们开始吧

为啥要看同时拆两本南辕北辙的书？主要原因就是那个晚上7:30--12:05的“创新or抱怨”大会吧

大BOSS说要一对一解决问题，how？

问题是啥是要解决的问题？？？

薄薄的一本小书~

and

也是薄薄的一本书~

目  录 一· · · · · ·

第一部分　问题是什么？　　1

第1章　一个问题　　3

第2章　彼得发起了一个请愿　　9

第3章　你的问题是什么？　　16

第二部　分这次的问题是什么？　　29

第4章　比利战胜投标人　　31

第5章　比利忍住没说　　39

第6章　比利反思投标案　　42

第三部分　问题到底是什么？　　49

第7章　无尽的链条　　51

第8章　忽视不协调之处　　57

第9章　找到问题所属的层面　　66

第10章　注意你所表达的含义　　73

第四部分　问题该由谁解决？　　81

第11章　烟雾缭绕　　83

第12章　校园停车难问题　　89

第13章　隧道尽头的灯光　　96

第五部分　问题来自哪里？　　103

第14章　詹妮特·贾沃斯基遇上了混蛋　　105

第15章　麦特兹锡恩先生解决了问题　　111

第16章　找事让人做的人和领赏的人　　119

第17章　考试和其他谜题　　126

第六部分　你真的想解决问题吗？　　133

第18章　不怕累的汤姆被玩具耍了　　135

第19章　佩兴丝的计谋　　147

第20章　一项优先任务　　153

目录二

第1章 基础架构高可用 1

1.1 明察秋毫，域名解析排查技巧 2

1.2 智能定位，网络端到端静默丢包点迅速锁定 14

1.3 灵活调度，对接运营商网络流量的容灾策略 20

1.4 抽丝剥茧，深挖云盘挂起背后的真相 23

1.5 存储的底线，SSD数据不一致 31

第2章 中间件使用常见隐患与预防 37

2.1 高并发“热点”缓存数据快速“退火” 38

2.2 自我保护，让系统坚如磐石 42

2.3 机房容灾，VIPServer软负载流量调度实例 46

2.4 山洪暴发，高流量触发Tomcat bug引起集群崩溃 59

第3章 数据库常见问题 73

3.1 性能的杀手-SQL执行计划 74

3.2 波谲云诡，数据库延迟 83

3.3 风暴来袭，AliSQL连接池调优 92

3.4 防患于未然，ORM规约变更案例 99

3.5 云数据库：SQL优化经典案例 103

第4章 业务研发经典案例 120

4.1 幂等控制，分布式锁超时情况和业务重试的并发 121

4.2 另类解法，分布式一致性 125

4.3 大道至简，从故障模型的边界状态切换到原始状态 129

4.4 疑案追踪，JSON序列化不一致 139

4.5 从现象到本质，不保证顺序的Class.getMethodsJVM实现 147

4.6 破解超时迷局，浅析启动初期load飙高问题 156

4.7 洞悉千丝万缕，浅谈JIT编译优化的误区 163

第5章 运行管理域稳定性建设 170

5.1 洞若观火，让故障无处遁形 171

5.2 体系化思考，高效解决运营商问题 179

5.3 以战养兵，以故障演练提升系统稳定性 185

不谋全局者 不足谋一域

---

两本书的不同在于--GET的是一个“点”
两本书相同之处在于--解决问题的方法！

ok，咱们开始了
《亮灯》：

第一步、问题是什么？

第二步、谁遇到了问题？

第三步、问题的本质是什么？

嘿嘿

每一个解决方案基本上就是下一个问题的来源

假装恍然大悟！

1、当别人可以妥善解决自己的问题时，不要越俎代庖

2、谁有问题？或者说是谁的问题？--如果这是别人的问题，就把它当成是别人的问题

3、提供解决方案的人和用此方案解决的后果无关联，那就是一个糟糕的方案！

--瞅瞅君的亲身体会与总结

4、大多数情况下，问题的根源在你自己

5、世界上有两种人，一种人做事，另一种人制造出事来让其他人做。远离那些找事儿让别人做的人，你就能过好日子了

AND，世界上有两种人，一种人做事，另一种人领赏。做第一种人吧，那里的争斗比较少

那些找活让你干的人可没有时间来看你在做什么，问题从哪里来就把它送回哪儿去，其实，他们可喜欢自己的工作了

6、通常称作“问题解决”的情况其实是“解谜题”

问题是谁出的？

他想对我做什么？

考试也是如此

啊哈

《逆流》：

讲真，里面的大批量问题瞅瞅君都不懂

1、何为之“平台”

书同文，车同轨，行同伦

瞅瞅君2018年面对的最多的就是“我们要做平台”“我们要赋能”“我们要融合”。。。

what？

然后就是各种大理论、大场面、大架构

how？

真实的自己是满头酱紫

无他，学啊找啊，这一点还是瞅瞅君的强项了啦

看到序:

他们不是所谓的技术大牛或大V，不会在各种论坛上侃侃而谈，也不会书写高大上的PPT；他们面对日常一个个突发的故障，遭受委屈、忍受冤枉、不惧倒霉、坚韧不拔；他们是脚踏实地、埋头苦干的无名英雄，是阿里技术的脊梁

超级有共鸣，有没有！有没有！有没有！！！

书中各种问题排查，都是以秒S计，基本模式总结如下：
某一类问题
1、背景--截屏(ง •_•)ง（有图有真相，关键日志记录，所有都要一起回滚）
2、问题排查（穷尽）
2-1、现象排查
2-2、疑问：出题出在哪里？
业务线的问题往往都隐藏在业务和技术结合的系统抽象和系统流程中，排查链极其长且复杂
2-3、试错
2-4、原因定位
3、深入分析（细节分析）
3-1、直接原因尚未找到之时，首要考虑的是如何快速消除影响，然后再来分析具体原因
3-2、应用平时应该经常梳理自己依赖的系统出问题时对自己的最坏影响是什么，如果不能接受这个结果，要考虑如何接入能把损失降到最低
3-3、系统的稳定性体现在一点一滴上，任何一种改动和方案都应该从分考虑和验证
4、涉及知识点（真的是语文意义上的知识点）
5、解决方案
Convert Partial Failure to Fail-Stop Failure
即将分布式系统中发生的无法处理的局部故障直接转换为标准流程中的失败，也即停止故障
(ps:这一部分的排查逻辑，瞅瞅君确实没太看懂，个人理解是个性化支持的同时是保留标准化备选的，当系统发现问题，需要快速提交能收敛问题影响、简单有效的解决方案，才是重点）
6、小结（此处“金句”颇多）
6-1、 整个IO链路理解的越清楚，就越容易看到问题背后的真相
(ง •_•)ง6-2、依据墨菲定律，凡是可能出错的事有很大几率会出错，所以任何的细小问题都不可忽视
6-3、大集群带来了很多优势，但随着流量的上涨，也形成了一个巨大的单点，后续应用的去中心化方案实施落地，也是针对这个点开展的
高并发的问题的复杂性导致排查难度很大，但没有捷径可以走，更需要耐心、细心
(ง •_•)ง6-4、在阿里系的DBA职位描述中有条要求是DBA需要深入了解业务，当DBA深入的了解业务之后，即能站在业务之上，又能站在DB角度考虑，这个时候再去做优化，有时候能达到事半功倍的效果
6-5、当我们对技术细节了解不够深入的时候，尽量不要建立在假设的前提下来实现我们的逻辑
6-6、 一切用结果说话，对下游组件零信任 每一位技术人员都需要有主动承担的精神，对自己的行为负责，对自己的产品负责，对用户负责 

NB在于--  最后一章的GOC
故障应急响应全局流程图+全维度监控+故障复盘流程+ 故障画像分析
回答了HOW有木有？

此刻本尊~

那堆堆图，真的得了解了，才能画出来啊。。。

---

小结于自己，
2019年，学习继续、好奇继续、困惑继续、焦虑依然能继续。。。
唯一差别，
瞅瞅君努力给自己构建了一个智能系统（目前为“初代”，不好意思）
So，
敬畏时间，提高概率，
在边界内做看起来傻逼的牛逼事，能说过去傻逼，绝不承认未来傻逼

========================END===========================