信息技术与伦理/软件开发中的自动化
在软件行业，甚至在软件开发等领域，自动化是一个相对增长的领域。现在，对于许多人来说，这个概念似乎很简单。它是创建脚本来自动执行某项任务的过程。这可以在物联网设备中看到，例如 Alexa 在设置你的灯每天早上 8 点自动打开时，或者像闹钟一样简单的东西，每天早上 8 点从你的手机中播放声音，用于你的课堂。即使在劳动力队伍中，也有一些团队专门负责自动化脚本编写，这本质上是编写脚本或程序，这些脚本或程序可以自动执行特定任务，并且通常将该任务的状态记录在仪表盘上。例如，让我们看看我在芝加哥商品交易所（CME）网络安全自动化团队实习期间编写的自动化脚本。我总共编写了 4 个自动化脚本，这些脚本每天为公司节省了大约 135 分钟的手动劳动。从这些结果来看，自动化为公司提供了最宝贵的东西之一，那就是时间。这 135 分钟的手动劳动需要支付给员工才能完成，而自从我编写了这些脚本之后，他们就不再需要这样做。现在，该员工可以将注意力投入到对公司更有价值的其他任务中。每天，自动化团队都会不断与其他团队讨论他们正在进行的过程，这些过程有被自动化的可能性。这些脚本可以像每 2 小时 ping 一次服务器的主机 URL 来检查服务器是否处于活动状态一样简单，或者可以跨 5 个不同的控制台在超过 10,000 个节点上运行超过 20 个规则名称的列表。这些是我编写的脚本类型。除了节省时间之外，还节省了向其他员工教授手动流程的时间。例如，当我刚来 CME 时，我花了一个星期才熟悉并学会如何执行一个流程，而我现在已经将其自动化了，不再需要一步一步地教别人如何去做。顺便说一句，我没想到在这个领域会发现文档编写如此繁琐。虽然我刚刚提到在如何进行手动检查方面不需要编写文档，但值得一提的是，我们将时间用于记录自动化流程的工作方式，以及一些关于自动化该软件的技巧或有价值的经验教训，以备将来有人需要为同一个流程编写自动化脚本时参考。
现在，在看待自动化时，时间是极其重要的，但另一个必须考虑的因素是，此过程消除了人为错误的因素。在执行手动任务时，特别是那些重复且需要多个步骤的任务（导致用户需要等待存档日志加载），毫无疑问，错误可能会发生。如果手动检查要检查 30 多个记录器上的最后存档日志，以确保一切已正确存档且没有错误，那么人为错误肯定会发生，相信我，我从经验中说话。另一方面，使用脚本检查这些记录器，脚本不可能错误地解释输入的字符串。如果我告诉脚本检查字符串是否等于“已存档”：它不可能忽略此逻辑，即使变量字符串包含“已存档”的值。这就是自动化的力量，如果编写得当，就不可能出现错误。尽管我让这个过程听起来很简单，但在最初编写自动化脚本时，通常仍然会发生错误，因为归根结底，我们仍然是人，即使在编写自动化脚本时也会出现人为错误。如果我们能自动化自动化编写就好了。
根据我刚才谈论的内容，在自动化脚本中，脚本编写者必须考虑到适当的错误处理和日志记录。脚本编写者必须了解脚本中可能出现的每一个错误，并且他们必须记录什么是重要的，以及什么是不值得花时间探索的。如果你正在自动化一个流程，并且你知道 X 会因为 Y 而崩溃，那么让你的自动化脚本记录这一点。从你的脚本中收到通知的其他人可能不像你那样了解这个流程，现在他们知道直接查看 Y。它节省了调试的时间，因为信息被正确记录。此外，我发现记录脚本在传递过程中遇到的每一个有价值的信息都是值得的。如果你成功地从 API 调用中提取了值，请记录你提取的值，以便在调试过程中正确记录沿途的每一步。将你的脚本想象成乐高积木，每个有价值的信息都是一块积木，构建你的最终目标。也就是说，重要的是要单独查看每种情况。用语言很难描述，但不要过度记录，确保你在传递的信息在调试时真正具有价值。过度记录会让你发疯，让你在干草堆里找一根针。
现在，让我们不要忘记自动化的成本，而这本质上又回到了时间本身。事实上，我编写的其中一个脚本花了将近 4 个月的时间进行故障排除和测试，包括向软件开发人员请求某些 API 调用，以及跨多个不同团队进行沟通。公司需要支付我这些时间，同时还需要支付我进行手动流程本身的时间。此外，在使用自动化时，我发现重要的是要确保你的脚本文档非常详细，以便如果你认为自动化“已经完成”，并且你继续编写其他自动化脚本，你确切地知道乐高积木的每一块的作用，以备将来需要回来解决新问题时参考。虽然这听起来很笼统，但我无法足够强调文档编写的重要性。让来自不同团队的其他人阅读这些文档，并查看他们是否能理解一般的概念。因为，将来有一天，这个自动化脚本在你离开公司多年后执行其任务时崩溃了，自动化团队中的某个人应该能够接手，并且了解它所做的每一项操作。
在查看使用软件来自动评估求职申请、简历或大学申请的过程时，我们可以看到，这个概念既有积极的一面，也有消极的一面。在查看使用人工评估者（没有自动化）时，他们会查看你的简历或申请，并阅读所有信息。之后，他们会决定你有关的信息是否与合格候选人的信息相符。他们会倾听你在面试中的回答，并评估你是否“正确”地回答。理想情况下，如果你给出表明你合格的回答，你将被选中。这个过程要慢得多，但它将比在自动化软件下查看这个过程更公平。
当自动化发挥作用时，我们可能会看到，大学或公司可能会在类似于阈值的理念下自动化这个过程。理想情况下，他们会过滤大量的申请，只收集符合非常具体标准的申请。如果你需要在工程领域工作 5 年，但只显示了 4 年，那么你的申请本质上就被丢弃了。因此，虽然我们能够审核更多的申请，但这些申请将根据申请人可能不知道的阈值进行过滤，这会造成不公平的期望。虽然这个过程的一个优点是，自动化将消除偏见或歧视。如果面试官/申请审核员注意到他们可能对其有偏见的信息，这会导致歧视。例如，如果你去了一所他们不喜欢学校，或者你的性别从申请中显而易见（如果你说你在童子军有过去经验，去了男子学校等等），而他们根据此信息做出了决定，那么这里存在偏见。如果审核者对大学论文中讨论的话题有正面联想，或者对你在面试场景中工作的先前地方有正面联想，而他们根据此信息录取/雇用了你，那么这也是有偏见的。
虽然这是一个非常具体的案例，但它仍然深入探讨了使用自动化的伦理问题。自动化作为一个领域可以非常广泛地应用于各种不同的领域或场景，因此尽管我谈论了很多关于我在自动化方面的经验，但不要将其局限于这种情况。想想看，将自动化应用于自动驾驶汽车的软件，这是一个另一个具有伦理挑战性的主题，人们可能会考虑如果自动驾驶汽车撞到一个行人会是谁的错。或者看看我们在课堂上讨论过的电车难题，自动驾驶汽车将如何做出决定？这种情况将使程序员面临几十年来一直在讨论的伦理困境。这些例子，以及自动化本身，符合摩尔定律，“[随着技术革命的社会影响越来越大，伦理问题也随之增加]”。这段讨论可以成为本书的另一章，但为了节省篇幅，并保持与自动化的相关性，我认为只是提一下就够了。[1]
当考察软件开发中自动化的伦理问题时，几乎不可能避免谈论自动化取代工作岗位的后果。这种想法在劳动力中引起了被称为“自动化焦虑”的真实问题。这是一个从 60 年代开始的概念，它基于这样的想法：拥有软件驱动的机械可能是自动化取代人工劳动的开始。虽然这篇文章以及历史本身主要谈论的是机械自动化，但随着技术的进步，自动化在其他领域的应用也并非不可能。我的意思是，即使看看我编写的自动化脚本，它们就消除了网络防御工程运营团队的人员手动执行这些日常检查的必要性，而我当时还是新手。虽然许多职位存在太多变量而无法考虑自动化，但未来自动化与人工智能相结合可能会对劳动力构成潜在威胁，这并非不可能。为什么工人会愿意付钱给别人，如果他们知道软件可以以最小的错误率以最高效率运行？这是一种现实的失业担忧，在考虑自动化的作用时应该考虑。[2]