前言
为什么写这个系列呢？ 因为考虑到运维这个职业的发展，想要更进一步，你必须熟悉一门开发语言，最少可以做到不用google/baidu等工具，自己完成一些自动化的脚本工具的开发，最好可以完成一个平台的开发。这样无论是你在当前的运维工作还是后面跳槽到新的公司，都会是你的一大助力，让你的对工作更游刃有余！
闲话不多说，上面说到了要熟悉一门开发语言，这里我推荐python或者go, python应该很多人都熟悉了解，包括我之前的文章也都有它的影子，关于这两个也都简单说一下。
对于go呢，这是一个相对来说比较新的语言，很多公司其实已经在用了或者已经在转go的路上，但是那都是业务代码，对我们运维来说，go 有一个核心的点在于，k8s相关的生态都是用go来开发的，所以如果你熟悉go，加上相关的运维经验，完全可以向k8s相关的开源组件二次开发的方向去发展，很多大厂都有这个方向，而且前景也不错。
而相观python呢，虽然没有k8s相关的生态链，但是现在无论上是已有的，还是正在开发的相关的运维开源平台，很多都还是使用的python，另外它的易读性，让新人的学习成本变得很低，投入很少的时间可能就能进行简单的开发。
运维的重构是什么？
回到我们这次的主题上，重构。 为什么要写它呢？你可能会想，重构一般不都是业务代码吗？运维还会重构什么呢？
哈哈哈，重构当然不只能是业务开发相关的流程，我们运维也会有属于自己的重构。当我们的业务发展到一定的规模，这时候我们运维必须要提供一些标准化流程，才能更好的支撑业务的迭代，从运维的角度来保证业务的质量，也能体现我们的价值所在。
举例说明：
举个例子，比如说我们公司现在只有20个服务，所以每次代码发布可能只用一个脚本就简单解决问题了，但是呢，某一天由于公司的一些政策以及一些其他外在的因素，20个服务变成了200个服务，业务量扩增了十几倍。这个时候原来整个的发布流程已经不足以支撑业务的正常迭代，整个发布流程都要重新设计，中间可能依赖分支管理，发布工具，自动化脚本，通知回调，流量灰度等等一系列相关的流程。这几个步骤的PIC基本都是运维。
或许你觉得分支管理这个怎么还要运维来参与呢，我认为多了解了解是挺好的一个过程，这样你就可以整个的宏观角度来看待问题，从问题需求 -> 解决方案 -> 方案实施 -> 成果优化，整个流程闭环。即使下次又遇到了其他的新的问题需求，你可以针对整个系统，快速的找到问题所在去解决它，从而体现运维的价值所在。
上面说的那个场景可能是一个整个性比较宏观的事情，我再举一个具体一点的例子。作为一个运维人员呢，我们手里可有很多服务器，各个厂商的都有，所以我们可能有一个自研的运维平台来管理这些服务器，但是呢每次我们修改服务器信息或者新增了一些机器时，都要我手动去处理这些信息，当然偶尔一次没什么感觉，可是如果跟上面情况类似，公司业务量突增，每天都要新增/修改很多台机器的信息，而且一般这些机器的元数据很多，这时候可能就要抓狂了。 所以我们需要设计一套自动化方案，在现有的工具上进行重构，让它支持信息自动录入的功能，这样既省了我们的精力，又能保证数据的准确性。
其实这些例子在我们身边应该有很多，只要你善于发现，并把发现的问题归纳总结，进行专业化，合理化的设计，毕竟每个公司的流程，现状，需求着重点都不一样，我们作为公司的一员，要根据自己的情况做适合自己的方案。
回头看了看这篇文章，感觉并没有输出什么硬核的"教程"， 更多是我想传达一种看待问题的角度，不能只通过技术来看待技术，还要根据自身所处的情况，来设计实施自己的技术方案！另外可能优化/重构的地方一定不要吝啬自己的想法，可以多跟同事讨论并落地，对自己也是一种提升！
总结:
有问题可以打在评论区，欢迎交流！
