使用Saltstack也有段时间，期间踩了不少坑，有的解决了，有的解决不了便避开了。本文便是一些排障经验的归纳和使用体验的总结，纯属个人经验，不喜勿喷。

开启Debug模式

最好的排障手段莫过于直接重现故障（salt里一般是可以重现的，其他应用就未必了，可能就只能通过日志和代码来层层拨丝抽茧了），使用salt-master -l debug 或者 salt-minion -l debug的方式来开启debug级别的日志输出，并尝试重现故障，这样便可以找到引发报错或异常的症结所在。

定位到代码级别

引发问题的所在最终肯定是某行代码的逻辑方式不对，或者一些不恰当的使用方式导致的。鄙人个人就曾遇到过这样的情况，在使用Salt gitfs特性时遇到一些不支持的情况，最后定位到Salt源码层面，通过修改源码来满足需求。实际上，在遇到异常情况时完全可以通过上面提到的debug模式来定位报错代码行数和位置，并着手阅读源码，从而寻找问题所在。

辅助的Job归档

Salt本身提供Returner的方式将job执行数据很好的归档到指定目标数据源，不过鄙人更倾向于使用绿肥神提供的 event returner方式，即直接从Zeromq消息总线抓取Job反馈信息，并做相应的归档，这样的一个优势在于“数据是绝对新鲜的”，很明显，它们都是第一时间反馈到消息总线时被抓取归档的。

实际上，这样的归档是完全必要，并十分有意义的。试想一下，如果将Salt Job数据落到比如Mysql数据库里，那么便可以做一些额外的数据分析和数据展示，并且在出现异常时给予一定的助力。

比如Master突然对Minion Timeout，那么便可以直接使用SQL语句获取最后一次下发的Salt job执行内容，以及返回情况，响应时间等。

重装、降级、升级

同很多软件一样，鄙人遇到的很多Salt的报错都是可以通过卸载重装或者删key重启服务，甚至降级、升级等方式去解决。

可不要小瞧这样的模式，鄙人曾听位大神说 “在Windows中，80%的问题都是可以通过重启来解决”，如果重装这样一个简单粗暴的方式能够解决问题，为什么不采用它呢？

尽量遵循标准

在鄙人的使用环境里，也曾遇到自定义的应用service脚本(init.d下的服务脚本)无法被Salt很好的支持的情况，后来通过查看源码得知Salt也是简单的通过ps命令来获取相关信息，并且在执行脚本后判断exitcode是否正常，如果不按照这样的一个标准逻辑走的话，很显然，便会遇到一些莫名其妙的问题。

所以，在这里建议使用Salt部署环境时尽量遵循已有的标准，这样会减少出错几率。

对Salt整体有一定程度了解和规划后再上线

对于一个新的软件，尽量不要大规模的去使用它，除非你真的很了解它。（鄙人暂时还不敢说自己很了解Salt的运行机制，尤其对于认证和消息分发模块尤为模糊，也希望更多的大神去分享这方面的经验。）

关于Salt，个人认为首先要掌握一些必要的排障手段，然后熟悉大部分的state编写及现有modules、Returner\Reactor\Schedule等等特性，最后等到这些都有一定了解的时候再去考虑生产环境的大范围使用。

处理逻辑尽量简洁、优雅

实际上，不单是配置管理，编写代码也应该如此，所有的代码处理逻辑都应该简单明了、优雅可读，这样的程序才便于维护和更新迭代。

在salt的使用过程中，编写sls或许占很大比重。鄙人这里建议sls编写遵循以下几个准则：

  • 内部逻辑尽量简单易读，order和require机制尽量少用;
  • 每个独立的应用都应该做成一个Salt formulas;
  • 复杂的流程处理考虑使用Salt Orchestration系统;
  • 尽可能少的在sls里出现cmd.run;
  • 恰当的使用pillar和grains、mine来规划、分类主机;
  • 足够多、足够广的测试;

升级前做好新版本的测试

个人感觉Salt 2014.1.x 坑非常多，之前也在测试环境做过很多功能性的测试，但是苦于Salt本身的认证关系，不能使用已有的tcpcopy方式去测试大规模使用下的性能。

不过，嘿嘿，鄙人没事喜欢挖挖github上的salt源码，竟然有些意外的收获，那便是MinionSwarm 和 MasterSwarm ( ? 还没有测试，是最近Salt官方开发人员加上去的)，具体参见源码：MinionSwarm

使用方法也比较简单，Python 脚本带上简单的参数就可以直接执行，效果便是终端下动态虚拟出指定数量的minion 实例，以供测试使用，大家用了就知道了 :)

向他人求助

曾经，在完全不懂salt的情况下遇到各种奇怪问题，自己又不太懂内部运行机制，也不会什么排障手段，最终结果便是整个自动化系统的不可用。而在这样的尴尬情况下，最好还是求助于大神吧，也希望力所能及的大神们都能抽出点时间来帮忙看看，毕竟"授人玫瑰，手留余香"嘛。

总结

最后，鄙人想说的是，一个自动化系统的构建和完善都是需要耗费大量的时间和脑力的，Salt只是一个工具，怎么去用好它还是得看自己，也许你要会点Python，也许你要做很多前期的规划，也许你得在大规模故障面前有足够的应对能力，也许你可以做的更好……