聊聊伪SRE

序言

   剑就是剑，木剑铁剑并没有什么差别，如果提出的问题本身就有问题，那么答案又有什么意义呢？

    时光荏苒，还没过多久，各种高级词汇就逐渐的淡出视野，现在已经没人说碎片化时间了，因为大家都有在忙的时间，无数的短视频已经充斥了所有的时间。

伪SRE

   曾几可时，SRE的概念开始风靡，每个团队都自称为SRE，扛着一个名号，就感觉自己认为很高档很高级，但是实际上，名称虽然改变了，但是手头上的事还是那些事，人还是那些人，取一个高档的名词，作为座右铭。

    SRE好像是运维的追求，半天开发，半天运维，看看这种模式诞生的主要目的：首先是因为要控制团队的大小，因为团队的大小不能随着服务的指数级增长而增长；其次就是要形成运维的标准，推广和共享运维产生的解决方案或者平台，这样才能最大化提高运维效率；最后就是为什么不用专门的开发呢？因为只有对生产环境运维的人，才有第一手的运维痛感，知道哪些地方需要自动化，知道哪些地方需要重点关注。这些也就是SRE产生的本质原因。

    而现在出现很多的伪SRE，首先，他们叫做SRE团队，然后之间分了各种各样的人，有的人专门做运维，有的人专门做开发，然后两者相爱相杀，运维的不知道开发的苦，开发觉得运维提的需求很傻逼。

    专门做开发的人，希望得到准确的需求描述，而运维产生的大部分的需求都是一句话描述，没做过运维的开发，根本不懂为什么要这么做；并且在运维中产生的无论是项目经理，还是产品经理，对于产品需求的讨论，产品的规划能力，还是属于比较弱的，因为并没有相关的专业能力，表面上看起来也是人模人样，实际上不知道是个啥玩意儿。

    专门做运维的人，希望得到快速功能的开发，各种MVP功能先上，先跑起来，然后再进行优化，谁知道会碰到什么问题呢，而大部分的开发并不理解，迭代？什么是迭代，那是不存在的。

    开发脱离了运维，就不知道哪个功能是重要的，并不知道可靠性在运维的产品中带变了什么含义，一个产品，建立信任是比较难的，而信任的摧毁只要一个故障就可以了。

    一个SRE不能从用户角度去思考需要什么功能，也是挺搞笑的，只是自以为是的开发一些垃圾功能，鸡肋功能，永远不会有人去使用的功能，还能洋洋得意，不知道哪里来的自信，梁静茹给的吗？

    一个SRE做了一款产品，一天更改一次，各种流程各种界面，用户都懵逼了，卧槽，这个功能怎么不见了，卧槽，这个页面消失了，从来没有说有个过度的过程，AB测试都不会弄，说什么SRE

    一个SRE从来不开发，一个SRE从来不运维，一群伪军。。。

    一个好的SRE懂得从用户的角度去思考，他们关心什么，他们的本质需求是什么，而不是说用户提了一个需求，refuse，而不是说扩展这个需求，看看能不能做出更加通用的方案。

    一个好的SRE懂得从风险的角度去思考，我的产品如何降低这种操作风险，是提示用户？还是针对有风险的操作直接拒绝？

    一个好的SRE会将最有风险的操作留给自己，而不是转嫁风险，将风险转移给用户，SRE使用的总是最多的，而不是开发了一个垃圾功能给别人用。

    SRE的诞生需要一个好的土壤，一个不会技术的带头人，肯定带不好一个SRE团队，但是可以成立一个伪SRE团队。对外不能打，对内牛的不行。自嗨还是可以的。

    欲行，试之。

风言风语

   有的人表面人畜无害，但是一旦和你熟了，反手就是一刀，所以不要口嗨，你所说的每一句话，没准就已经转发给了一群人，这种是一种恶心的背刺，好像也怪不得别人。

    有的人很努力的做方案，但是上面却说，干掉他，你觉得他的努力能得到什么样的结果？估计也会遭受到质疑，投入产出比在哪里？看看他们那种无助的眼神，好像也很凄凉，不过大家都是牛马。

    做商务不要做底层，底层什么样的人都有，牛鬼蛇神。。。搞定了高层，也就一句话的事，天天接触底层，做的越多，错的越多，而且结果还不好，所以大家都学了欺上瞒下，一群舔狗。

    又到了半年评绩效的时候，草台班子好像也不能有啥变化，死水一潭。。。运维，绩效还是比较难评定的，其实也简单，因为都是任人唯亲，都是根据自己的喜好来。。。

    抱怨无用，只是心理健康的一种方式，如果是你，你如何来处理这种人这种事？