情景 我们想搭建一套线上变更前，上线代码的一个回归验证环境，跑测试用例的平台工具已经有了，苦于整套链路没有搭建好，并且总有问题，测试用例跑不通。
目标
1.项目的目标是15分钟(有可能的话尽量控制在5分钟内)跑成功100w案例(测试用例)；案例包含两套环境，每套环境不仅要和预期的结果一致，而且要求同一个案例两套环境结果要相同(目前回归验证平台的做法是一个案例要等两个环境结果都返回才算一个事务结束，这会增长用例执行时间)。 2.项目的目标并不是我的目标，我们团队实际上不是自动化回归环境的开发者而是使用者，我们希望尽量少的投入人力成本最好是不投入人力成本让环境稳定运行。
行动
小处着手，各个击破
如果开展一个新项目，同事之间之前没有合作过。这时候一个比较好的融入方法是小处着手，踏踏实实的做些事情，解决问题，建立一定的影响力，再去协调大家，让别人来配合自己的思路。
我刚做这个项目第一周解决了十几个小问题，比如有个现象是超时的问题，最终定位是mock（模拟外部服务的打桩）服务磁盘被打满导致。解决方法是首先手工清理磁盘，先不block别人，然后给自己制定了一个任务：将服务改成自动归档和清理日志的模式，作为一个低优先级的事情进行(最终在1周后完成了自动清理日志)。
这个例子里涉及到2个小的做事方法，第一是时间管理的四象限理论。
事情要分轻重缓急，人工清理日志不block别人是紧急的事情。自动清理日志是长期从根本上解决问题，是必须要做的事情，但是没有那么紧急，这时候只要将事情记录下来，在自己相对空闲的时候来做。
第二是做正确的事而不是容易的事。
长期从根本上解决问题是正确的事，但是相比手动清理日志而言要难一些。因为我从来没有接触过这部分的代码，连代码权限都是托人给开通的。后续代码改好了测试好了要发布，发布的权限也没有，一系列的问题很繁琐。相比较而言手动清理日志更简单，但是为长远考虑，如果哪段时间我忘了要把日志清理一下，又出了问题，结果就是别人发现超时了，找到我，我遇到这个环境的问题80%是超时问题，所以需要重新排查，最终定位到问题清理了日志，告知大家原因，大家跟我说感谢及时响应解决了问题，心里暗暗给我打上了【同样的问题反复出现，做事不靠谱】的标签。所以做事：事前要推演，事中要敬畏，事后要复盘。
采用科学方法应对性能问题
对于性能问题的排查效果的衡量采用《性能之巅》中的USE法配合科学法进行验证。
排查采用USE法，USE法应用于性能研究，用来识别系统瓶颈，就是对于所有的资源，查看的使用率、饱和度和错误。
效果衡量采用科学法，科学法研究未知的问题是通过假设和实验，总结下来有以下步骤：
1.问题 2.假设 3.预测 4.实验 5.分析
在此项目中举例来说，就是对于性能问题从CPU、IO、内存SWAP等系统指标和业务日志中的错误来找到影响性能的因素。在验证的时候先明确问题：比如返回一个错误，查看日志是调用超时引起。使用USE工具查看指标，得出假设内存是影响性能的瓶颈。预测内存的减少会提高或降级性能。实验时只改变内存一个因素，确保其他环境和上次验证时一致，对实验结果和假设进行对比分析，得出如果将所有2核4G虚拟机合成半数4核8G虚拟机提供服务性能可能会显著提高的进一步假设。这个问题的具体分析后面会讲。
以终为始
在项目目标中提到，我们团队实际上自动化回归平台的用户，不是开发者。所以我做这个项目对团队的产出很有限。我也会面临一些压力，需要从这个事情中抽身出来，集中精力加入到我们团队的重点项目当中。
于是在我加入两周后，我梳理了一些解决问题的文档，跟项目其他同事沟通说如果遇到问题能不能先按照文档排查，如果问题解决不了再找我。当时，他们勉强同意。结果第二天，就是上面提到的2核3.7G虚拟机重做成了4核8G虚拟机的事情，那天冲做好的没有部署服务的机器交付过来了，这时候需要重新搭建环境，我请别人帮忙别人自然没有时间处理。
我搭建好环境之后，我也把怎么搭建一套我们这边服务的流程写成文档，看看自动化回归环境那边可否出人来cover这件事。因为当时也是有点压力，所以沟通上也比较生硬，很强硬的希望能把问题分担出去。
沟通到最后，我自己的理念价值观又回来了:成就别人就是成就自己；解放自己最根本的方式就是处理好自己的问题。所以我最后说我们团队的问题我们自己来处理，这点没有分歧，挂了电话，后来又就自己的行为跟当事人道了歉。
这件事情我处理的不好，根本原因是没有以终为始的做好事前推演。事情本来很简单，如果我在沟通前推演一番就知道：
如果目前回归环境的问题没有彻底解决，就算有文档也还会找到我。这时候我会很被动。找我解决问题，我再去解决，不从源头上分析问题根源，头痛医头脚痛医脚，总体对我时间的占用是延长的。
对自动化回归环境这个项目来说，我们团队在整条链路中起着至关重要的作用，核心链路里面3/5的项目都属于我们团队，我由于有着代码权限、我们团队的人力配合资源、加上技术和工作经验等原因，实际上在主导着项目的推进，是每周完成预定目标的重要原因，如果我这边为项目考虑的少了，整个项目就会不能完成既定的目标。我没有成就这个项目，虽然我不是项目的主责任人，项目失败的负面影响会一点不少的都回馈身上，甚至我们团队上。很明显会得不偿失。
从第一周开始，我就总结出了要想做好这个项目的根本方针就是刨根问题，解决所有问题，并且也知道只有解决问题才能解放自己，但是没能时刻以终为始的坚持，和以此原则和各方沟通，阐述自己的观点，是其中的失误。
结果
按照每周目标完成了任务。
问题分析
我们回到有个超时问题，将所有2核4G虚拟机合成半数4核8G虚拟机来做为解决方案的那里。用5why做一个根本原因分析。
1.为什么会超时？ 同样部署在2C3.7G机器上的同样的服务，有的机器超时，有的不超时，初步排查是性能原因。 2.怎样判定是否是性能原因？ 超时的机器特征为：GC频繁（其他机器GC为每分钟3次以内，问题机器为每秒2次以上）、IO高。内存使用上较其他机器多出约100M(JAVA程序，经过测试，JVM堆配置为3G性能高，其他机器占用总内存为3.5G左右，问题机器占用3.6G) 3.GC频繁、IO高、内存高之间有什么关系？
GC频繁的根本原因，是内存不足，需要垃圾回收导致。
GC频繁和IO高的关系：从原理上JVM参数有配置GC打开写GC日志，写GC会调用操作系统write()操作，这是一个IO操作。GC造成stop the world停顿，停顿会造成响应时间的延长，IO连接不释放，极大的加剧了IO问题。造成滚雪球效应。
内存不足会造成频繁的在磁盘上进行文件交换，加剧IO问题。 4.为什么会内存不足？ 线上机器都是4C8G，而我们团队的系统也是按照这个配置来设计，利用了很多内存缓存的技术，是造成内存不足的根本原因。 5.为什么超时是个别机器？ 因为我们压测并发量是一点点加上去的，所以是压测到了有机器有问题就不再增加并发量，实际上再增加并发量会有更多机器暴露超时问题。内存不足，会造成频繁的在磁盘上进行文件交换。虽然这些机器CPU、内存、磁盘的大小是相同的，但是磁盘转速是不相同的。磁盘与内存之间文件交换慢会进一步加剧内存问题，产生蝴蝶效应。
总结
化平凡为神奇
金庸经典《射雕英雄传》里，黄蓉为了让洪七公交自己和靖哥哥武功，天天对师傅美食相待，在做了“玉笛谁家听落梅”这样一些世间珍品之后，信心满满的告诉自己的吃货师傅七公说今天要做的是"炒白菜"。七公立刻两眼放光，面露欣赏之色，说：“好，我倒要看看你怎样化平凡为神奇。” 最后，黄蓉以自己的独家神技成为了丐帮第十九代帮主。
我选择了专注于稳定性这个领域，就意味着选择了时刻准备着加班、半夜被叫起来，每天以以后不需要加班，不会半夜被叫起来为目标。想实现这个目标单纯靠隔离、限流、熔断等工程手段是做不到的。通常面临的是枯燥的发现问题、排查问题、解决问题、线上运维这些看起来并不高大上的工作，而在做这种工作的过程中能够使用技术和方法，集腋成裘，将平凡的小事做成很牛的大事，就是稳定性领域努力的方向。
