这个场景再现了过去三年来的主要矛盾根源，也是不可调解之重要因素，两方各有原因，且都很难解决，毕竟这个是持久时间下的产物，目前无法解决，所以一味的痴心妄想自己的缺席，然他们自治几乎是行不通的。
人吶，每个阶段都有每个阶段的主流思想和价值追求。这个阶段尤其跟年龄精力相关，比如年轻时意气风发，觉得什么事情都有可能，什么事情都想做，但也在不断的犹豫徘徊中度过，觉得看不到边际界限，那种痛苦思量很难熬。
渐渐地年龄大了，被很多现实问题所左右以后，界限小了，想法也少了，人就开始变得死气沉沉，变得没有精神，木讷的不行，窃以为，这才是人最可怕的地方。不论什么时候，都不要放弃追求，尤其是彷徨的经历，恰恰是开始进步的标志。
人呐，还是不能没有追求，不管是物质的，精神层面的，没有追求的人就没有精气神，就死气沉沉像瘫烂泥。
大事难事看担当，顺境逆境看襟度。«小窗幽记»里的这句配合上«无量寿经»中的勇猛精进，真无敌也。
“多凿，往深了凿，看问题要辩证，不要目光短浅。”
—for PCES low sev tickets analysis feedback.
“code change, project不会自己跑来。”
—for LeanDB & DynamoDB optimization.
突然发现一个很神奇的模式，从小到大都有应验。
当面对压力拖延症开始发作的时候，心态就会容易崩塌，就会开始对以前和未来的状态进行反思和挖掘。以此来调整以后的决策方向和选择。真正开始拼体力和素质的时候到了，危机感渐甚，紧迫感愈强。
Jing的Oral English真是native，并且Presentation做的真好，遂想到要真的做到此，Documentation的功力尤其要见长；同时对于知识的深入理解和深入浅出的表述你的问题显得尤为重要。Goals:
一直很难找到一个有效的方法来应对PER log太大没法vim进去查找的问题，每次进去就ssh loss connection，今天忽然发现，直接根据ThreadID来grep重定向查找，不要太好。
其实人在任何阶段，任何时候，对于眼前的事都是有确定的答案的，当然这个答案也没有对错，可能在当时是对的，但后来是错的，或者当时觉得是错的，但后来证明时对的。不同的结果只因时间变了，上下文也变了。但也有一些东西是肯定不会变的，比如我TM永远都不会忘记engagement在回去车上对自己说的哪些话。
渐渐地会在自己身上总结出一些规律。比如越来越发现，人过一阶段就需要颓废一下，来修正下自己，反思自己前段时间的状态和走过的路。于是近期就发现，自己慢慢的成为了真实社会中的观众，没有观点，没有参与，只在作为一个死阿宅一样的旁观者。好可怕……
这次这个incident的weblab remove来的值得，虽然负荆请罪了一个COE，但所获确实很多。对于shipment workflow的很多知识都有收获。
一个PFW的workflow如果slip进了shipment，往往很难从CS那边cancel，或者从fulfilllment端请求cancel往往也是吃力不讨好。而payments这边的处理也经常会形成stuck，以至于很多customer contact，从上到下各层的contact都在，但几乎一致是疲于奔命，没有切实有效的解决方案来处理此类事故。在PCESIL里加直接的hard decline有点过于武断，其实我们所需要的是在PCESIL端提供一个面向client的自动hard decline的措施，但不是hard decline这个payment operation或是execution，而是从client的角度，hard decline一个PFW或者shipment。就有点向一个operation层面的最基本的保障。且不需要我们自己来进入，如果client面对客户投诉，可以直接通过ninji team来做。
还有一类问题是关于PUMA的，不像PPS的PCR一般是translate好了直接放在PCDS的DB里，PUMA的paymentplan只是保存了一个PCR的版本号，如果任何时候需要，PC这边都是直接在线翻译的。之前一直纳闷PUMA版的PCR应该怎么backfill，现在才恍然大悟，原来只要直接backfill PaymentPlan就行，PaymentContractTranslator会自动拿到最新的版本。
对于SPOD的认知也有了些改变。在EPG算矩阵最终决定生成PE时，会附属上所有必要的SPOD的信息，这时候的PaymentInstrument的信息也会附在上面，而最终会走到算PE是否有效的问题，如今很多tt都是关于AmountRequested和AavailableBalance不一致，如果遇到这种情况，基本从两处分析，其一是requestedAmount计算是否有问题，比如在请求里的valueExchange的item是否是计算有问题，一些税，传入参数的计算等等；其二就是从consumable的amount，最常见的问题就是