人们常说：情商高的人会说话。实际上他们的意思是对人说人话，对鬼说鬼话，这样的人才有前途。
很长时间里，我一直以为我无法理解他们为什么要推崇心口不一。后来，我知道了。我不是不理解。我只是不服气。
这样的”不服气“，让我这样的人，在这样的环境下，永远不会坐到更高的位置。
一个同事在2022年中用这样的话评价我：你看，你们是同一个时间进来公司的，别人做部长了，你还在这。
说实在，有一那么一瞬间，我有一丝不舒服。但是，我立马意识到我这是不对的。这样的评价，不值得我花一秒钟去理会。每个人有每个人的活法。在大公司，想往上爬，不就那些方法吗？
所以，2022年我还是坚持着一心搞技术，不会花半点心思在”向上管理“上。
说到技术，这一年有了长足的发展。终于有机会把Everything as Code落地了。说不上成功，但是，已经证明这个方法论是可行的。Everything as Code的核心就是：
尽量将软件工程所有的问题转移到代码构建阶段解决；
版本化及自动化软件工程中所有的依赖，以尽可能减少软件工程中的复杂性的不确定性。
这个核心就像一个数字公式，它在数学家内行中，看起来是完美的，但是在外行看起来就是天书。而且，外行也不会花一秒钟去思考这个公式是否正确。
Everything as Code在实施初期阶段，是没有”界面“的。而软件管理人员里的大多数是不写代码的，在他们看来，没有“界面”，就拿不出手，他们就无法给他们的上级汇报。
所以，即使实施Everything as Code，你还是需要做一些界面的。的确，虽然理论是正确的，但是你总要有一些证明你是正确的数据展示出来。
这一年，还有另一个感触：软件团队效率低的很大原因也许是开发方式，并不是什么技术框架。
一行行代码打断点的开发方式的普遍程度，让我无言以对。这也就不难理解了，这些开发人员经常要看着数据库里的数据才能写代码了：执行一行代码，然后看看数据库的某个表里有没有数据。
这一年的后半年，我已经心累了，不再花心思告诉他们这个世界还有另一种开发方式了。他们效率低下，多加班就好了，和我有什么关系呢？
反过来，开发人员可能觉得，我才是效率低下的原因：
提交一行配置，都要拉分支，然后提Merge Request。Merge Request还提一堆问题；
每个分支还不能停留超过两天时间；
不提供开发环境；
各种权限控制得非常死，申请一个DB的权限，还只能申请三个月；
要执行个SQL，还要将SQL提交到代码仓库里进行Code Review。
这让我想起运维领域的一个普遍现象：只要出几个事故，人们才会知道你的存在，”救火“的才是英雄。
这在我刚来公司时经历的那次三天两夜地事故后，我就知道了这个道理。
但是，出于我的责任心，2022年我还是坚持以上原则。因为我知道这些原则是软件团队的底线。
当然，也因为我知道，当出现事故后，他们可能也无法总结出这些原则。
这种SRE的痛苦，让我在2022年很辛苦。
可是，以上那些，是一个SRE应该做的吗？在国内这个大环境里，SRE不就是那种出了事故，然后进行”擦屁股“的吗？你还管他们提交代码的方式？
是的，SRE在国内的大环境的里，就是给别人擦屁股的。可是，不巧的是，我刚好是那种讨厌给别人擦屁股的SRE。
我已经想好了如何应对这种痛苦。那就是将所有的告警通知分摊到每一个开发人员。让他们去处理他们自己的屁股。当然，我也自己擦自己的屁股。
如果我真这样做了，恐怕，我在团队里又多了一项不受欢迎的决定：将告警通知分摊到每一个开发人员。
我前段时间特意总结了这三年专职做运维后，做过的不受欢迎的决定是什么：
2020年上K8s：开发人员需要花时间学习K8s概念知识，大多数人觉得开发成本高了；
2020年推行Code Review：开发人员的代码只有经过Code Review才能合到master；
2020年提出Feature toggle代替特性分支开发：开发人员一开始无法理解后来理解了。但是一些大厂来的开发人员，还是无法理解；
2020年推行日志结构化：开发人员被强制写日志结构化的代码；
2020年开始实施多仓库的Everything as Code ：开发人员无法理解以提交代码方式来部署应用的运维方式；
2022年实施单仓库的Everything as Code：开发人员无法理解这种操作，觉得浪费他们时间；
2022年将所有的配置都转换成Jsonnet：开发人员觉得学习Jsonnet拖慢了他们的开发速度（然后Jsonnet的语法只有一张A4纸大小）。
看到这些，我也佩服我自己起来了。放在2023，我同样会觉得这些决定是明智的。
2022年的小结就写到这吧。希望读者朋友2023年顺利。
往期推荐：
我们不是研发，不会天天去关注代码
SRE认知升级之可用性的本质
个人开发习惯与团队效率之间的关系
