怎么把运维能力沉淀下来？

考证，你考的证就能说明你会什么。比如RHCSA、RHCE和CKA，就能说明你对技术的shell、ansible和k8s是懂的。算是差不多职业资格的认证。如果你都是高分，那么说明你的基础是还可以的。接下来就看实践经验了。因为运维接触的东西也挺多的。
写博客。就像现在这样。有时候自己状态低落或者低迷的时候，就可能会挺没自信的。别人问你有啥能力，你一下子也反应不上来。那么如果你写了技术博客。这里面是说的技术和经验和思考，和一些实操的方法。解决实际问题的实操方法，纯实践的东西。那么就能说明你会什么。比如我这个号，乱七八糟的写了100多篇，差不多130篇了吧。几乎都是关于运维的，linux、网络、数据库、k8s、docker、git、jumpserver，包括一些即兴的临时的思考，就随便写到这。那么可以说明两点，一个是你真的实战解决过什么问题，实战解决的方法具体是什么，这个可以自己拿来用。比如我之前记录的，也是看别人总结的，自己再拿过来，或者加上一些自己的总结，比如之前的git，那么就可以再不会的时候，或者忘了的时候，打开博客，看一下，相当于是笔记。这是一方面，同时这个方面其实可能更加有用的，就是这个写作的过程，是尝试教会别人呢？这个可能占小部分原因，因为更大的，可能是其他两点，一个是找工作面试的时候可以跟别人说自己写博客怎么怎么样，这个从技术从业者的角度来说，是比较加分的应该。对于爱学习，热爱技术的人来说，这个应该是顶用的。第二个就是可能出于自己的陌生人社交的需求吧，也就是可能是所谓的虚荣心，看到自己写的东西有多少人浏览，甚至也有人点赞收藏，这个是一个被部分认可的表现，这样可能也是让自己感觉到自身价值的存在。特别是在自己刚开始写博客的时候，人嘛，可能总是需要获得同类的赞赏和认可的。有时候我们不需要，特别是面对傻逼的时候，你根本不在乎他怎么看怎么说，跟傻逼有啥好说的。除了这样，那么你也可以不用在乎任何人怎么看，无所谓。但在这种不在乎的情况下，有人在无利益的情况下，对你的写作或者叫内容输出，或者就是更多的是吐槽，也表示出认可，那么这个东西还是对写作者的心态应该是积极的。可以这么说吧，你不追求被认可，在这种前提下，还是有人主动表示认可你，那么应该也是高兴的事情。
做项目。就是把自己的东西弄成一个教程。如果方便，就直接在这里写，一步步教别人，什么东西怎么弄，比如说，如何在腾讯云TKE上部署一套zk集群。这个是可以教的。虽然有点麻烦，你的所有资料可能不会直接扔到这个平台上。但是具体的每一步操作的方法，可以放上来，给别人看是其次，主要是自己这么做一遍，自己的收获是最大的。而且这个平台上谁都不认识，所以想写啥，想吐槽啥，就无所谓了。只要不做越界的事，就还是比较随性的吧。还有就是把测试环境的话，怎么部署一个standalone的zk，给开发用。这个玩意也可以写教程在这里。还有就是gitops怎么玩，就是CD用argocd，CI如果用gitlab CI的话，怎么弄。把具体步骤弄上来。还是那句话，教别人，别人真学会了会感谢你，没学会不感谢也无所谓，学会了不感谢也无所谓。因为本来就是随性写，也不为具体的每一个步骤的每一个细节负责。所以就是随便写，那么这个过程最重要的可能还是自己的收获。写教程的时候，自己的思路和逻辑得走的通，然后一步步走通之后，那么可能就是可以说是会了。比如gitops这一套玩下来，先在本地电脑做实验，完事如果能成，那么就可以考虑在云上模拟生产环境搞一套。这个可能就有点意思了。因为这些东西，作为运维可能是迟早得会的，而且可能还能换点工资来。所以写这个玩意还是有点意思的。其实更有意思的，在于对于更底层的探究，把这些底层的东西弄明白，很有意思，在哪都能用上，基本上可能是这样的。比如argoCD是用什么语言写的，它具体是怎么个通信的方式，是怎么监听的git仓库，怎么连接的k8s集群，怎么去diff的，怎么去调用k8s的apiserver的，让这个玩意动起来。这些东西是怎么弄的。我们可能就不是只学习这一套工具了，因为底层这些东西，到处都在用。挖一挖，把各种技术和思路和设计思想连接起来，然后掌握底层的思维逻辑，这些玩意可能就一通百通了，不能一通百通，也应该可能要朝着一通好几通的方向去走。这样可能效率才是高的，看着慢，实际快。像傻逼公司一直逼着你加班要结果，根本不在乎你懂不懂底层，打不打算长期干，在不在乎你进步，这些就是傻逼公司。因为这种傻逼公司里面的傻逼管理他自己都不打算长期干，这种傻逼公司要早点离远一点。
官方文档。这个东西很重要。就是不管是啥，是开源的还是云厂商的，他们做好一个项目，一个服务，这玩意官方是得出对应的文档的，不然流行不起来，谁知道你这东西怎么用啊。所以不知道怎么玩，就看官方文档。比如argocd怎么部署，就看官方文档。当然还有一个特殊的情况，真的官方文档写的不知道在哪，找不到也看不懂，比如zk集群的部署，这里面好像有一些乱七八糟扯皮的事情。那么这种情况怎么办，我部署zk k8s集群的时候就是这样，我让AI IDE给我写的部署的yaml和部署脚本，直接弄到kubectl机器上去跑，居然跑成功了。其实我自己对这里面的步骤也没弄清楚，但是就是部署成功了，也可以用。要指定腾讯云官方的sc，就是storageclass，它那个api接口的名称是啥，或者说那个sc的官方名称是啥，直接用就行了。然后要弄什么pv pvc，这些AI都给弄好了。所以直接apply就行，实在不行，就都删掉，重新弄。除了这个zk的官方文档看不懂，其他应该还好，比如argocd的就还不错。k8s的官方文档也很好。我们看官方文档一般遇到的第一个问题就是，纯英文，看得慢看不太懂，不完全懂，不用装，我觉得很多人都是这样的，因为我也是。我们其实还是看中文比较快，但是英文的语义确实更加精准，而且英文的文档看多了，慢慢也是一种积累的进步。所以着急的话，就用微软的edge浏览器翻译页面，因为它那个翻译的服务器好像是在guo内，所以翻译的比较快，翻译效果好像也挺好，所以对我们比较友好。还有一种我觉得好用的方法，就是把官方文档的连接丢给AI，让它看，根据官方文档，给出具体的操作指南。这样感觉AI容器不瞎搞，就是跑网上搜一下不靠谱的方法。
固化。比如把干啥的方法，弄成一个脚本，把这个脚本保存下来。而且要用面向对象的思想，就是这个脚本尽量能适配越多的情况，所以很多场景就可以直接拿来用。还有就是把一些复杂的方法，弄成docker镜像，保存起来，每次用docker去跑任务，这样不容易影响宿主机。比如扫描各个云上的域名，看看443证书啥时候到期，提前换。就是类似这种东西。比如我现在要用的zk集群，云上又不卖，那就得自己部署，所以把怎么部署，对应的yaml和sh固化下来，到时候换了云或者换了环境，就可以直接用。这个就叫有一件部署中间件zk的能力。1小时内搞定。这个对于自己来说是效率，对于企业来说也是价值。

总之吧，你能教会别人一个东西，才能说明你真的学会了。

还有一点就是，离傻逼远一点，跟傻逼在一起，会把自己也变成傻逼

架构图。要多画，虽然跟傻逼在一块，傻逼不画，逼着画也不画，就是要么他自己放在脑子里，只有他自己知道。要么就是他自己也不清晰。这样工作效率太低了。作为运维，我们的优先级第一的工作之一应该就是弄架构图。或者流程图啥的。千言万语不如一张图。