自动化是科技行业前进的方向，但它也是一把双刃剑。做对了，能够削减费用开销，减少维护工作；做错了，会让流程更加复杂，并增加预算。就像任何技术或流程一样，自动化在某些时候、某些地方是有效的，而在其他一些领域，要么不是很有效果，要么无效。

如今， 自动化系统和人类之间的差距正在逐渐缩小，人类和机器各自最擅长领域的差异也越来越模糊。以前自动化系统受限于计算机的功能和效率，但是现在，主要的限制是解决方案自动化所带来的效费比。

适合自动化的场景

把枯燥的问题自动化

曾经多少次，你不得不查看一堆日志和表单文件，一遍又一遍做着同样的基础工作？曾经多少次，你被要求将数据从一种格式转换成另一种稍微不一样的格式？当任务具有高度重复性和公式化的时候，这就是最适合自动化的场景了。

我开始采用自动化是因为我被要求打开数以百计的日志文件，在某一行上找点信息，并把它和另一行上的信息做比较。我的经理估计我需要用大约一周的时间完成。我确实也花了将近一周的时间，但不是因为我全是用人工做的。我开始学习 Bash 的基础知识来完成这个任务，因为 Bash 是当时所有可用的机器上都安装了的工具。第一次我花了一周时间，后面几次运行我只花了几个小时，而大部分时间也都是花在传送文件和保存数据上。

把反复出现的问题自动化

自动化的开发是需要成本的，还有着 技术债务 需要维护。开发成本依赖以下一些因素：对问题的熟悉程度、对自动化解决方案的熟悉程度（编程语言，代码库，算法等）、输入或者原始数据的一致性程度等。技术债务则依赖于数据更改的频率，需要多少维护量才能保持解决方案的适用性。

在整个工作流程中，常见的问题往往需要更多时间完成或者处理。即使不能自动化整个问题，可能也有一大部分问题是足够常见的，能够成为自动化目标。如果一个操作占用了 75% 的流程，你可以通过投资自动化开发，把这个流程的 75% 给自动化。即使自动化不能换来更多时间，也能提供比人类更高的准确性，使整个流程更加高效。

把简单的问题自动化

有些操作可能只是流程的沧海一粟，但这些操作也很容易自动化。如果这些操作很常见，你就可能想要自动化它们，因为完成这些自动化系统的代价很小，只要开发自动化方案的时间不超过完成任务本身的时间就好啦。对于我这个任务（找到文件里的某些行），就适合做成自动化的方案，即使这个任务不会那么频繁地出现，或者只会在小数据集上使用，因为这个任务要自动化简直太容易了。而且当你手动做这个任务时，很容易看漏什么东西，比如忽略了某个文件（当手动做的时候，肯定发生过这个情况）。这是我学到的关于自动化的第一堂课，我几乎没花多少时间就从零开始学会了它。

自动化最大阻碍之一是对未知的恐惧，以及对相关主题缺乏了解。针对简单的问题，我们能够简单地测试自动化方法的有效性，也更容易检查错误。简单的问题只需要投入很少量的时间，对技术要求也不高，这就使这样的问题更容易开始着手自动化。简单的问题如果极其单调乏味，人工完成就很可能出现准确性的问题。

自动化的短板

自动化依赖两种能力之一：自动化系统要么能够控制输入格式，要么能够处理错误的输入。给自动化系统完全正确的输入意味着需要有额外的步骤来处理输入数据。错误处理通常暗示着额外的处理代码，这些代码的编写工作是有代价的，其运行是耗时的，可能会影响系统性能。如果想知道一串电话号码，可能会得到如下信息：

• 1235551234
• 123–555–1234
• (123) 555–1234
• 123.555.1234
• 123 5551234

这些对人类来说都是正常的电话号码格式，但是怎样把这些不同格式的数据传给计算机？解决方法对某些编程语言来说异常简单，但是对其他编程语言可能就难得多了。我们需要构建错误处理程序来解决输入格式，这不仅需要了解相关工具集方面的知识，而且需要知道有哪些输入是可行的。如果程序只能接收 1235551234 这样的格式，却被输入了其他某种格式，这时程序应当怎样处理？

输入控制

不同的组织、公司以及地区都有着不同的数据保存标准。美国使用的日期格式就和欧洲使用的格式不同。当自动化时，需要有一种方法能够评估数据是否正确，需要找出合适的解决方案。

11/12/2019可以表示两种日期，这取决于你问的是谁。 11/30/2019 在美国是正确的日期，但在欧盟就没有实际意义。如果你把日期格式标准化了，就能完全避免这些问题带来的影响，另外，还需要确保这个标准能够强制实行。

输入控制是让自动化更具扩展性和实用性的最简单方法之一，但也可能是最难跨越的障碍之一。相关的任何老数据格式都需要数字化来适配到新的数据格式。所有的新东西都需要标准化，而且需要有人来检查标准化结果，特别是在处理流程开始的时候。如果输入数据是有问题的，那输出数据也会是有问题的。

我曾经构建过一个 ERP 系统，但不得不移除其中的一个模块，因为客户公司的工作人员拒绝使用某个输入字段需要的标准术语。客户问我为什么不能让自动化系统“读取”这个格式。我告诉他们如果我能实现这个功能，我早就成了亿万富翁。为何程序可以读取某种数据格式，而不能读取其他数据格式呢？客户无法理解这一点，但是他们相信我。最终，由于缺少标准输入，一个简单的输入字段成为了自动化实现的争论焦点。

错误处理

一个好的自动化解决方案的容错性是很好的，并且能很容易地标记出哪些是错误数据，或者哪些数据和解决方案中的参数不匹配。随着时间的推移，构建这样的错误处理程序会越来越复杂，并且这还会取决于数据本身。如果不控制输入格式，那怎样才能保证输入的正确性？如果需要同时在欧盟和美国处理日期格式，我们会怎样处理 11/12/2019 这样的数据格式呢？

首要的是，我们需要错误处理程序来保证，当自动化程序没有像预期那样运转，我们应当知道这一状况。一个自动化解决方案在外部调用 api 后返回了数据，但如果中间出错，这个自动化解决方案就可能崩溃，但它也可能功能失调，然后继续运行。编写一个搜集数据的脚本很容易，但是如果数据改变了，或者数据中出现非法字符，这将发生什么？我们怎样才能知道程序仍然在运行，知道它究竟做了些什么事情呢？

我曾经看到过某个字段意外地出现了一个非法字符，就让这个自动化解决方案中断了数月之久，但这个中断是静默的且不可预测的。这个自动化过程可能会完成 99% 的工作，或许刚开始出错时就挂掉了。没有错误处理和日志来显示挂掉的时间和原因，但是每回都会表现得像一切都在完美运行着那样。幽灵般的系统不一致错误持续了数月之久，才找到了流水线中挂掉的地方。

这些听起来都像是砸自动化买卖的事情，但是通过正确划定解决方案的范畴，并且在构建工作流之前就完整思考一遍，可以防止这些问题的发生。好的实践习惯是，在完全集成解决方案之前，多规划和测试。如果想要尽快规划自动化解决方案的范畴和用例，并且始终践行这个解决方案，就需要更加完整地测试，才会知道这个解决方案可以被信任。

范畴和用例

自动化解决方案的范畴和用例只有在经过充分开发和理解后才能信赖。了解范畴和用例后，项目需求就不会再扩增。功能蔓延是规划不佳（之前没有想到有诸如此类的功能需求）或者实现不佳（对于项目的发展方向没有足够把控）的表现。

敲定范畴和用例意味着必须了解方案目标，知道哪些内容会影响自动化流程。更改数据搜集方式，与在自动化解决方案中修复数据，哪种方式代价更大？如果不知道，项目的开销注定会比预想中大。

超出预定范畴的应用程序，构建和维护会更加昂贵。没有定义用例的应用程序，往好了说是另一个“me too”产品，往坏了说就是思想和代码搅合在一起的混合体。范畴指明了产品应当做什么，而用例则指明了目标是什么。功能可以有机地向前开发，但是需要尽可能遵守预定的范畴。

测试

你不会允许一辆未经撞击和制造质量测试的车上路，但是很多人都能接受把未经审核的自动化解决方案引入核心业务领域。自动化可以是一个黑盒 ，但必须是具有一致输出的黑盒。有一个错误的自动化系统还不如没有。如果不知道自动化系统内有错误，那一开始就不要大费周章地建立自动化系统。解决方案必须经过正常数据、异常数据、服务崩溃等测试，只有这样才能真正了解这个系统能否可以承担这些负载。测试意味着知道真实世界的限制是什么。

结束语

自动化并不可怕，糟糕的自动化系统却是可怕的。完善的自动化系统可以节省大量时间和精力，但是草率的自动化系统就会变为财务黑洞。自动化并不是解决所有问题的方法。有时候，它就像一把寻找钉子的锤子，但是你却只有一些螺丝钉。有时，只需要这个螺丝钉坚持一小会儿，那把螺丝钉锤进去是奏效的。每件事情都需要权衡，以确保自动化不会变为吸金器或者麻烦，提前规划自动化方案能够节省大量的时间和金钱。

原文链接：https://medium.com/swlh/when-should-you-automate-150d3fdbf97

链接: https://www.fly63.com/article/detial/6495