一个DevOps/SRE/运维的2022年碎碎语

人们常说：情商高的人会说话。实际上他们的意思是对人说人话，对鬼说鬼话，这样的人才有前途。

很长时间里，我一直以为我无法理解他们为什么要推崇心口不一。后来，我知道了。我不是不理解。我只是不服气。

这样的”不服气“，让我这样的人，在这样的环境下，永远不会坐到更高的位置。

一个同事在2022年中用这样的话评价我：你看，你们是同一个时间进来公司的，别人做部长了，你还在这。

说实在，有一那么一瞬间，我有一丝不舒服。但是，我立马意识到我这是不对的。这样的评价，不值得我花一秒钟去理会。每个人有每个人的活法。在大公司，想往上爬，不就那些方法吗？

所以，2022年我还是坚持着一心搞技术，不会花半点心思在”向上管理“上。

说到技术，这一年有了长足的发展。终于有机会把Everything as Code落地了。说不上成功，但是，已经证明这个方法论是可行的。Everything as Code的核心就是：

这个核心就像一个数字公式，它在数学家内行中，看起来是完美的，但是在外行看起来就是天书。而且，外行也不会花一秒钟去思考这个公式是否正确。

Everything as Code在实施初期阶段，是没有”界面“的。而软件管理人员里的大多数是不写代码的，在他们看来，没有“界面”，就拿不出手，他们就无法给他们的上级汇报。

所以，即使实施Everything as Code，你还是需要做一些界面的。的确，虽然理论是正确的，但是你总要有一些证明你是正确的数据展示出来。

这一年，还有另一个感触：软件团队效率低的很大原因也许是开发方式，并不是什么技术框架。

一行行代码打断点的开发方式的普遍程度，让我无言以对。这也就不难理解了，这些开发人员经常要看着数据库里的数据才能写代码了：执行一行代码，然后看看数据库的某个表里有没有数据。

这一年的后半年，我已经心累了，不再花心思告诉他们这个世界还有另一种开发方式了。他们效率低下，多加班就好了，和我有什么关系呢？

反过来，开发人员可能觉得，我才是效率低下的原因：

这让我想起运维领域的一个普遍现象：只要出几个事故，人们才会知道你的存在，”救火“的才是英雄。

这在我刚来公司时经历的那次三天两夜地事故后，我就知道了这个道理。

但是，出于我的责任心，2022年我还是坚持以上原则。因为我知道这些原则是软件团队的底线。

当然，也因为我知道，当出现事故后，他们可能也无法总结出这些原则。

这种SRE的痛苦，让我在2022年很辛苦。

可是，以上那些，是一个SRE应该做的吗？在国内这个大环境里，SRE不就是那种出了事故，然后进行”擦屁股“的吗？你还管他们提交代码的方式？

是的，SRE在国内的大环境的里，就是给别人擦屁股的。可是，不巧的是，我刚好是那种讨厌给别人擦屁股的SRE。

我已经想好了如何应对这种痛苦。那就是将所有的告警通知分摊到每一个开发人员。让他们去处理他们自己的屁股。当然，我也自己擦自己的屁股。

如果我真这样做了，恐怕，我在团队里又多了一项不受欢迎的决定：将告警通知分摊到每一个开发人员。

我前段时间特意总结了这三年专职做运维后，做过的不受欢迎的决定是什么：

看到这些，我也佩服我自己起来了。放在2023，我同样会觉得这些决定是明智的。

2022年的小结就写到这吧。希望读者朋友2023年顺利。

往期推荐：

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/70942.html