序言

    世界上最大的勇气就是在压力下保持优雅，控制情绪这点还是比较难的，因为大部分人都是做的好心有所思，做的不好心如止水。。。蛮好，哈哈

    武将不可辱，成长就是放弃，很多东西都是有矛盾点的存在，如果一种做法不能符合你的预期，那么何必不换一种活法。。。不要在一棵树上吊死

风言风语

    1 聊聊HR

    江湖一碗茶，喝完各自爬。。。喝完这碗孟婆汤，再也不见。。。

    最近和外企的HR聊天，面目一新的感觉，优雅的谈吐，在说话的时候中文夹杂着英文，反正我也听不懂，但是给人的感觉就是一种高大上，没有这种文化底蕴，也没有这个耐心去等待，思维之间的转换，还略微显得比较鲁莽。。。看我三板斧。。。

    当然，谈吐是一方面，体现的优雅，而最最关键的是，HR居然负责赋能团队，这个就有意思了，能去找外部资源协助团队的发展，并且想办法去做这件事，这也算是文化的一部分了，能靠自我驱动力去推动这件事，而不是应付，而不是为了形式。。。

    看了那么多形式，看了那么多虚伪的笑容。。。毫无意义，在淤泥里躺久了，都想当淤泥了，何来出污泥而不染。。。

    文化底蕴很重要，到底是挂在嘴上，还是记在心里，有无数种判断方法，其实最简单的方法就是看，在你任职期间，什么时候HR会出现。。。是在你需要帮助的时候？还是在你绩效考核的时候。。。不是在解决你，就是在解决你的路上。。。这大概也是对HR的刻板印象。。。

    心若向阳，无谓悲伤。。。

    2 架构重构

    架构重构是一个充满着风险，但是却收益不是那么大的行为，对于技术来说，这是一种挑战，同样也充满着成就感，如果能成的话。。。

    痛则思变，其实架构设计不好，只有研发比较痛苦，带上运维也比较痛苦，其他人感受的不多，但是呢，如果没有从中吸收经验，那么就会一直痛苦一直爽，要么忍着，要么憋着，毕竟自己写的代码。。。

    重构的价值有多大，这个就要看架构师的能力，要说服高层给予相关的资源，要说服技术团队使用新技术或者新方法，要说服产品经理给予时间暂缓业务功能的开发，要说服测试进行回归测试。。。

    重构的价值，在高层看来，那是看不见的，因为不会影响到终端客户，如果影响了，那么也是运维或者研发背锅。。。毕竟高层关注的一般都是业务价值，而对于后端的可用性，可扩展性，高性能啥的，要么就是不懂，要么就是根本不予理会，why？

    每一届高层自己也有KPI，要作出什么样的价值，要作出什么样的贡献，而且大部分的压力都是业务贡献，而不是代码贡献。。。你说你要重构，重构需要多久？一年？一年没准高层都跑路了。。。看不见的收益，高层都不好去画饼，用什么来衡量产出。。。

    就算业务天天崩溃，可用性太低，高层也感受到了这个压力，但是又会给多少资源去解决这个问题。。。代码你们自己写的，只能自己背锅了。。。

    天天说要重构，凭什么要重构。。。为了规划未来的性能压力？为了规划未来的容量压力？。。。如果连目前的KPI都无法完成，那么还有什么未来。。。未来已死。。。

    对于看不见的价值，是无法衡量的价值？但是换一个角度来说，如果程序需要重构，那么说明发生了很多问题，可能是扩展性不足，每次修改代码需要十天半个月，伤经动骨找一群人来讨论，规避风险。。。再看一个角度，程序需要修改，是BUG还是新功能的研发，如果是新功能，那说明业务还是在持续发展的。。。

    如果业务在持续发展，那么就有重构的机会。。。就看怎么去汇报。。。用数据说话，数据是最有说服力的一个东西。。。例如我们使用敏捷开发，居然一个月才能发布一个新版本，其中讨论花了三周，写代码花了2天，剩余时间测试部署上线。。。例如本周五次故障，都是高可用能力不足，不能灰度上线，修改一个小功能，导致所有业务中断。。。。

    每个人都能感受到这种架构的痛苦，那么就顺其自然的进行重构或者重写。。。梳理现状其实还是最难的一部分，然后总结汇总成数据，一目了然。。

    3 为什么要SRE/devops   

    其实这个问题很简单，有了这个职位，既能做业务开发，又能做运维，那么自己写的狗粮自己吃，正所谓己所不欲勿施于。。。。

    当自己写的代码三更半夜出现故障时，朦朦胧胧的起来处理故障。。。痛苦不？那是相当痛苦。。要是三天两头出问题，痛苦不，那是相当爽快。。。就像龙卷风。。。

    有了痛苦，才会思索这种痛苦如何解决。。。那么下一次，你自己写的代码，你就会有自己的思考了。。。你会考虑高性能，你会考虑高扩展，你会考虑高可用。。。考虑这么多，不是别人收益，而是为了让自己不半夜三更爬起来解决故障。。。

    故障身上背，黑锅头上抗。。。慢慢的长了记性也长了脑子。。。重要的是提高了自己的能力。。。

    痛则思变，这是第一个原则。。。有了痛苦，自然会想办法去解决。。。

    先诊断，后下药。。。一定要先找到本质问题，才能恰当的给出合适的药方，不然可能是碰运气。。。而我们不是靠运气吃饭。。。

    为什么需要痛苦。。。因为很多人对于不存在的问题毫无远见，这就是为什么很多防御性策略不愿意做，没有动力去做，拖沓延迟。。。等到真正出现问题的时候，才想着，卧槽。。。原来要是早点这样就好了。。。但是，没有如果。。。

   4 敏捷

    敏捷团队，真的是相当相当棒。。。一个队伍里面就有各种技能的人，能相互配合，能减少沟通，能为了一个目标而冲向前方，比其他类型的团队好太多。。

    其他的组织架构类型，总是同种技能的在一个团队，那么就必然会带来一个问题，那就是内部竞争，俗称内卷。。。对内重拳出击，对外唯唯诺诺。。。

    其他的组织架构类型，还有很多问题，例如其中之一就是跨部门协调，这个就更加难了，脸要是够厚够大，那么还好点儿，对于那种脸蛋儿比较小的，估计活不下去，事情只能拖延拖延无限延期。。。最后咽气了。。。

    敏捷，快而凶猛。。。这种情况下，如果能自己挑选队友，那么就很少出现猪队友的，君不见，猪队友成群结队。。。

    敏捷，不同技能相互衔接互补，而且不冲突，没有竞争。。。但是风险就是，如果一旦市场不好，就是整个团队扑街。。。所以这样的压力更能让人团结一致。。。

    尬聊其实还是蛮难的，和不熟悉的人，说着不熟悉的话题。。。不停的找，然而依旧会冷场。。。哈哈哈，估计都很尴尬，但是只要你不说，我也不说，那就都不尴尬。。。

    让生活中充满爱，不要做自己讨厌的人。。。技术只是一种手段，而不是目的。。。梦回从前，时光冉冉，感恩有你。