自动化CIO

2020年9月8日周二 · 4分钟阅读

目录

• 发送数据到数据库
  • 申请人
  • RFD
  • GitHub
• 以简单方式利用数据

发送数据到数据库

我之前在《自动化艺术》文章中简要介绍过我们的内部基础设施。本文将深入探讨我们自动化的首席基础设施官（CIO）系统。我经常开玩笑说我已经自动化了我们的CIO，甚至将存放代码的仓库命名为… cio。

我利用这个周末的时间最终清理了部分代码。之前，我们的基础设施由bash、冰棍棒、胶水和一些Rust拼凑而成。现在，它主要是Rust和一个更易于理解的合理架构。我们还可以自由地将所有数据缓存到我们拥有的数据库中，这样即使服务宕机，我们也能访问数据。之前，我们为每个脚本、机器人或其他东西调用每个服务的API，这可能成本高昂、速度缓慢，并且可能充满速率限制，或者更糟的是停机时间。

让我给你展示现在的架构图：

在图表的最底部，你可以看到我们使用webhook和cron作业从各种服务API中提取数据并发送到数据库。

让我们深入了解其中几个，因为在大多数情况下，这并不像从API到数据库的简单管道那样简单。

申请人

每个申请Oxide的候选人都会完成我们的申请材料。这是一系列关于他们工作经历的问题。这些材料与他们的简历和其他详细信息一起提交到Google表单。

一个cron作业解析来自Google表单的电子表格。在这个过程中，它会判断申请是否是新提交的，我们需要向申请人发送确认邮件。它还会向团队发送新申请通知。

cron作业还会将他们提交的材料和简历解析为纯文本。材料可以是HTML、PDF、doc、docx、zip，甚至是带有zip头的PDF格式。简历和材料中的每个问题都保存在单独的数据库列中，这使得当我们想根据材料或简历中的内容查找申请时，搜索和索引更加容易。

RFD

我们在Oxide博客的RFD 1《请求讨论》中写过我们的RFD流程。

每个RFD都是用markdown或asciidoc编写的。我们收集每个RFD的内容，并将其更新到数据库中，同时包括其等效的HTML。

HTML用于在我们与Oxide外部人员分享RFD的小型网站中生成页面。这些人员可能是Oxide的朋友、我们重视其专业知识和反馈的工程师，或潜在客户和合作伙伴。

通过将所有内容存储在数据库中，还可以更轻松地跨所有RFD的内容进行搜索。

这些只是我们在将数据移入数据库时构建和丰富的API的两个示例。

GitHub

当GitHub宕机或我们受到速率限制时，拥有某些GitHub API调用的缓存是很有用的。我们还将一些GitHub端点数据存储在我们的数据库中。

以简单方式利用数据

接下来，我们需要一种方式与其他机器人、脚本、同事和公司内部的应用共享所有这些数据。这就是API服务器发挥作用的地方。

API服务器充当数据库与任何脚本、机器人、用户和应用之间的中间人。由于我们从外部服务和API获取所有数据，因此该API是只读的。

API服务器将数据库数据与Airtable同步，这样我们就可以使用Airtable作为前端，一次性查看特定表中的所有数据。这被证明是Airtable的一个很好的用途，因为你还可以非常轻松地与Airtable中的其他表进行连接。它提供了良好的视觉体验。

例如，我们可以将RFD表中的RFD与路线图相关的不同表中的项目关联起来。当人们对他们的RFD进行更改时，RFD内容也会在Airtable中更新。

总而言之，构建、重构、再构建、再重构这个过程非常有趣。这是我在有空时可以随时接手并工作的项目，并且当我们需要以特定方式使用数据时，可以轻松添加功能。

对于API服务器，我使用了我们的dropshot REST API库！

感谢Dave和Adam编写了这个库！

在这一点上，我无法想象在一个没有内部API的公司工作，这个API可以查询从Google群组到申请人，再到邮件列表订阅者，再到RFD等等的所有内容。以上就是全部内容！我很想听听你对内部基础设施的其他想法！

© Jessie Frazelle 2022 @jessfraz