我们都喜欢工具，这个是正确的。工具能让我们编程，构建，测试，打包，版本发布，配置，监控我们的系统和服务。随着DevOps兴起，免费，开源，和商业的工具呈现大爆炸式的出现。

这些新工具中的许多功能，特别是在服务周期方面的功能，带来了惊人的效果和效率。我们经常参考DevOps工具链，没有任何一种工具可以满足你的所有要求。您想要的是一系列工具，可以组成工具链来满足您的需求。但是，你想要这些工具集成在一起使用，就相当于在linux上可以输出很多个shell命令一样的效果。请记住，

第一，系统思考，工具仅仅是支持某些系统在一定程度有作用，工具不是万能。在选择工具的时候要考虑周到，确保工具之间相辅相成并且符合你的策略。请记住，你使用的任何一种工具，可能都有成本问题，它可能是收费工具，也可能是开源的免费工具。开源的工具也需要人去熟悉和学习如何使用它。还有工具本身也是需要维护，升级等。绝对有太多能帮你实现一些功能的工具，但是，不要天真地认为工具是高级别的DevOps的策略产物，工具本身是可以驱动DevOps的发展和落地。

有时，新技术改变了我们的文化。 例如，无处不在的智能手机具有在技术创建时尚未完全理解的含义。谁能想到，当时在设计智能手机的时候，考虑到了手机的支付功能。同样的事情适用于DevOps工具。 配置管理早在云计算普及之前就存在了。 尽管如此，它通常只是作为一个很好的事后才被实现。但随着工作负载转向云，这种模式转变为配置管理成为您需要实现的第一件事之一。这些工具可以带来惊人的新功能，但对于那些不改变他们的方法来考虑新工具的人来说，它也可能是一种威胁。

自动化系统可以帮你一次性把全部系统崩溃，而不是一次崩溃。面对这些新工具，你的策略必须改变以避免这种影响，这就是为什么我们首先强调DevOps的价值观，原则和方法，以及最后的工具。我们来谈谈你想要的工具集。 首先，您希望该工具与工具链中的其他工具一起使用，它应该能够以自动方式执行某些工作。你应该能够调用它，从API或命令行调用它。 只有UI界面操作的工具，这个工具就很鸡肋，在DevOps中无法集成进去。所以，我们经常说，一个任务如果能在放在命令行去执行，这个任务就可以考虑放在jenkins job上实现自动化。

第二，你希望该工具带验证功能。Ronald Reagan有一句最喜欢的俄罗斯谚语，他经常引用“信任，但要验证。”。最好的DevOps工具清楚地暴露了它正在做的事情，并提供了一些验证它做了它应该正确做的事情的方式。 你使用的工具中的事件和指标是反馈的重要来源。

第三，就像孩子一样，从开发人员的角度和运营的角度来看，这个工具必须表现得很好用。你应该能够将工具的配置检查到源代码管理中，它应该带有可用于验证其行为的测试，并且您应该能够以自动方式部署它。这些工具不必自己提供此功能。 最理想的是，他们可能只是插入现有的渠道，比如集成到你当前测试代码环境，能输出符合你要求的测试报告。

当然，你会发现，如果你自己写工具，这会更好，目的性更强。前提就是我们代码能力要厉害，自己写也好，根据现有别人基础上修改也罢，代码能力要过关。你应该先看看是否可以使用现有的工具来满足您的需求，但通常情况下，你可能找不到完美的选择。 DevOps中dev的一个要点就是能够在需要时自己动手，自己开发一个工具，不管这个工具有多小，能实现你需求就好。但是，在开发自己的工具时，请牢记上面提到这三个标准，以便你的工具表现良好。 后续文章（如果可能），我们将在DevOps，基础设施自动化，持续交付和可靠性工程的背景下更多地讨论特定工具。