这个场景再现了过去三年来的主要矛盾根源，也是不可调解之重要因素，两方各有原因，且都很难解决，毕竟这个是持久时间下的产物，目前无法解决，所以一味的痴心妄想自己的缺席，然他们自治几乎是行不通的。
人吶，每个阶段都有每个阶段的主流思想和价值追求。这个阶段尤其跟年龄精力相关，比如年轻时意气风发，觉得什么事情都有可能，什么事情都想做，但也在不断的犹豫徘徊中度过，觉得看不到边际界限，那种痛苦思量很难熬。
渐渐地年龄大了，被很多现实问题所左右以后，界限小了，想法也少了，人就开始变得死气沉沉，变得没有精神，木讷的不行，窃以为，这才是人最可怕的地方。不论什么时候，都不要放弃追求，尤其是彷徨的经历，恰恰是开始进步的标志。
人呐，还是不能没有追求，不管是物质的，精神层面的，没有追求的人就没有精气神，就死气沉沉像瘫烂泥。
大事难事看担当，顺境逆境看襟度。«小窗幽记»里的这句配合上«无量寿经»中的勇猛精进，真无敌也。
“多凿，往深了凿，看问题要辩证，不要目光短浅。”
—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，最常见的问题就是
通过搜索来寻找信息的意识应该无时不在。
PCE - purchase
OMA - order
OFS - shipment
ps: 原来ctrl + enter可以实现notes自由缩进。
有些事情想清楚了着实不容易，况且很多时候还被自己rollback，比如刚工作时容易被外界所影响，任何时候看见的都是消极的一面，容易被外界不相干的人和事干扰。因为各种事扰乱心神，最后忘记的都是最最重要的事情。说到底都是自律性太差。
刚工作的时候最容易在职场上碰壁，还记得14年在VBS的时候犯得一个很大的错误。由于team当时业务不怎么样，一直做最低端的processor层的migration工作，后来渐渐的新来team的人都走了一波一波的。我们几个刚校招进来的同事也被安排在做一些相关的无聊工作。每天就是维护再也不用的系统和做做千篇一律的processor的工作，再者就是整一些anvil的事。一直觉得这种没有营养内容的事做的根本没有意义。更为甚者的是，在那边待了二年半也是升职无望。当时真的觉得一切都是team的错，老板的错，为什么没有分给自己有竞争力的项目，能让自己promotion的项目，总是做一些无聊的事，在这上面浪费无数的时间。渐渐的发现这种抱怨变成了每天自己工作的常态心情，不想顾着做好事，不愿意加班，不愿意承担责任，只知道做表面上的工作，却没有做任何framework上的工作，对底层的东西也不甚了解。以至于做事情一直是这样不求甚解。工作中的机会总是转眼即逝的，如果此时不好好抓住，很有可能自己就此Miss了。当一年后开始回味xiaopeng的recall时，当时觉得这事真的是神奇，可能是老天想给自己再来一次的机会。但渐渐的后来才发现，事业场这事只问利益得失，hua的举动也可以得到印证。
但这些其实都印证了一个问题，如果平时的工作中能够很好的抓住重点，有意识的去抓住一些事，不是再因为老板给你的事而一再的推诿退缩，那其实你的事业很有进步的空间的。
现在每天经常因为一些事睡不着，对于自己的职业方向就是一个重点。真的没有想过一些很简单的事，却一次一次的在自己的身上发生，没有缺乏总结。对于一些能够一劳永逸解决的问题，很快的通过自己的方式来把解决掉。最简单的timber log的问题，alias的问题就是一个很好的例子。
其实还有一个比较困惑的点就是工作中太琐碎的事，由于身处偏远地带，Seattle之外的本来就很难被顾及，渐渐的之前跟着xuegang做的，迟早就一天需要自己来单干，所以这件事便显得非常有必要了。xiaopeng说的很对，树立自己的visibility，树立自己的reputation，尤其要提高自信，自觉的来做这件事。
遂发现，尝试的次数和你所获得的收益永远成正比。多交流，多试错，多见识，才能多长智。
There is a case for remote-overrides: users have overridden apollo activate scripts and then run brazil ws env update for remote-overrides.
In this case, users have to run activate after running remote override update command.
It would be really powerful if after I run 'brazil ws env update' that environment also activated. This could be controlled by a flag (--activate).