这是学习笔记的第 1899 篇文章

  最近在整理运维开发方向的一些内容的时候，总是感觉有一些地方不够清晰，而纠结的是我也不知道具体哪里不够清晰，怎么去改进了。

    在整理的过程中碰到这类问题，很容易就会陷入循环，我原本采用的方式是搜集整理相关的一些文章，比如有30篇文章，然后我把这些文章都整理到一起，然后对已有的内容继续进行归类和划分。在这种情况下，我的思路是根据已有的文章进行删改，然后在这个基础上提炼出一些共性和要点来，对于我来说，写的每一篇文章都是用心的，所以本意上是希望每篇文章都能够充分利用到。

    在我最近整理另外一类文档的时候，感觉自己突然悟到了。比如做运维自动化方向，那么你要做的运维自动化它的架构是什么样的，它有什么难点的核心内容，哪些是创新点，然后做这件事情你是怎么规划的。这四个问题可以理解为通用的问题，也是我们在整理的时候需要好好思考的。如果这些能够整理明白，那么后续的细化内容其实就有了一个明确的目标和方向。 

  所以按照这种思路，发现原来整理的内容，不清晰的原因就是难以体现出核心技术和创新点，而这些内容其实对于新手和老鸟来说都是受用的，对于一个需要改进运维开发技能的人来说，可以把一些想到想不到的问题都罗列清楚。所以这部分内容其实可以根据已有的文章做一些取舍，重新整理，整个过程和交付效率也能够大大提高。

今天收到一封邮件，看了邮件之后充分证明了一个运维铁律：不要在周五做一些重要变更，除非你愿意在周末继续努力工作。今天就中招了一次，有一个配置文件的数据有点问题，导致备份任务都失败了。对于这类问题的修复就很纠结了，有接近百套环境要重新开启任务，而这个任务目前是不具备重新执行的功能的，为了保险起见，还需要逐个对执行的任务做下确认。

一台一台的服务器逐个连接，显然是低效的，但是通过中控端自动执行又存在一些风险，所以我采用的就是半自动的方式，提取脚本执行信息，然后确认后执行，这样每个操作需要操作3次，而原来的方式需要至少7次以上。 

问题的改进思路就是我写了简单的脚本，就2行内容，然后通过组装的方式衔接起来。这个时候手底下的速度也能够逐步快起来，而且还可以杜绝犯手工错误的可能。 

执行方式就类似 

sh test.sh xxxx

sh test2.sh 

这种操作这样看起来没有什么复杂度和难度，可以很轻松的把任务衔接起来，保证执行的过程更加顺畅，而在这个之外，我们需要考虑的就是对已有的这种批量操作能够进一步做到规范化和标准化，使得批量执行成为可行的方式。