全面自動化

背景：這是我的系列文章中的第 9 篇，內容源自為公開發佈而編輯過的 Lightcone Infrastructure 內部備忘錄。

---

首先，聲明一點。在自動化某件事之前，先看看是否可以乾脆不做這件事。質疑需求* 是在你興高采烈地將任務系統化之前，永遠應該進行的一步。*

Lightcone 比其他地方更注重自動化的原因之一是，我們是一個極力嘗試保持精簡且彼此同步的組織。這涉及到了努力的報酬遞增這一普遍觀點。如果你能自動化一個在大型組織中需要半個全職人力（FTE）的任務，其價值遠低於自動化一個佔用 Lightcone 團隊成員一半時間的任務。

現在，自動化是很棒的。機器很便宜。我們的大部分工作都是那種可以用軟體自動化的內容。然而，自動化任務既存在一些常見的陷阱，也有一些特別有助於指導自動化工作的準則。

1. 只自動化一部分也是可以的。

這是一篇偶爾會在 Hacker News 上瘋傳的部落格文章：https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/

摘錄最相關的部分（並將 Python 腳本轉換為 TS）：

每個維運團隊都有一些還沒來得及自動化的手動流程。瑣事（Toil）永遠無法完全消除。

對於一家成長中公司的團隊來說，最大的瑣事來源通常是修改基礎設施的流程或開設用戶帳號的流程。後者的部分指令可能如下所示：

• 為用戶建立 SSH 金鑰對。
• 將公鑰提交到 Git 並推送到 master 分支。
• 等待構建任務完成。
• 在員工通訊錄中查找用戶的電子郵件地址。
• 通過 1Password 將私鑰發送給用戶。
• [...]

這種徒勞感是我們為了逃離這些手動苦差事而真正需要解決的問題。我發現了一種相當可靠的方法：「不做事腳本」（do-nothing scripting）。

不做事腳本

幾乎任何苦差事都可以轉化為「不做事腳本」。不做事腳本是一個編碼了苦差事指令的腳本，將每個步驟封裝在一個函數中。對於上述範例流程，我們可以編寫以下不做事腳本：

#!/usr/bin/env ts-node
import { ask } from "readline";

const username = process.argv[2];
if (!username) {
  console.error("用法: ts-node script.ts <用戶名>");
  process.exit(1);
}

console.log(`執行：\n ssh-keygen -t rsa -f ~/${username}`);
await ask("按 Enter 鍵繼續：");

console.log(`將 ~/new_key.pub 複製到 user_keys 倉庫，然後執行：\n git commit ${username}\n git push`);
await ask("按 Enter 鍵繼續：");

console.log("等待 http://example.com/builds/user_keys 的構建任務完成");
await ask("按 Enter 鍵繼續：");

console.log(`前往 http://example.com/directory\n查找用戶 ${username} 的電子郵件`);
const email = await ask("貼上電子郵件地址並按 Enter：");

console.log(`前往 1Password\n將 ~/new_key 內容貼到新文件中\n分享給 ${email}`);
await ask("按 Enter 鍵繼續：");

console.log("完成。");
rl.close();

這個腳本實際上沒有執行流程中的任何步驟。這就是為什麼它被稱為「不做事腳本」。它一步步引導用戶，並等待用戶手動完成每一步。

乍看之下，這個腳本的價值可能並不明顯。看起來我們只是讓指令變得更難讀了。但不做事腳本的價值是巨大的：

• 現在你不太可能弄錯進度或跳過某個步驟。這讓你更容易保持專注並完成苦差事。
• 流程的每個步驟現在都被封裝在一個函數中，這使得將任何給定步驟中的文本替換為自動執行該動作的代碼成為可能。
• 隨著時間推移，你會開發出一個有用的步驟庫，這將使未來的自動化任務更有效率。

不做事腳本並不能節省團隊的手動勞動。它降低了自動化任務的啟動能（activation energy），從而讓團隊能夠隨著時間推移消除瑣事。

這篇部落格文章是在一家擁有大量標準作業程序（SOP）的公司背景下寫成的。我們沒有那些東西，這是有充分理由的（也許未來的原則應該是「反對流程」）。儘管如此，這種基本方法仍具價值。

人們常在意識到任務中有些部分對程式來說很難處理時，就放棄自動化該任務。但大多數時候，任務中總有某些部分是可以自動化的！將任務放入一個現在可以逐步自動化的情境中（例如，將其嵌入 Airtable 自動化或上述腳本中），能讓你開始一點一滴地解決它。

然而，自動化的障礙往往更深層，這引出了第二點：

2. 自動化某件事通常需要為底層問題尋找全新的解決方案（而該方案通常會更糟，但這是值得的）。

這點絕對不能做得太過火，但通常為了適應自動化，解決問題的流程或方法需要進行相當深度的重構。我想到的幾個例子：

• 我常對 Lighthaven 房間周轉的成本感到沮喪。Atlantis（Atlas Fellowship 運作時的場地）針對個人訂房採用了青年旅館的規範。也就是說，除了最基本的清潔外，他們不會在客人抵達前準備房間，並建立了領取乾淨床單和歸還髒床單的系統。他們還要求人們在離開前自己打掃房間。這確實讓某些體驗變差了，但也大幅降低了管理訂房的日常開支。
• 我們過去常需要深入且複雜地思考如何封鎖 LessWrong 用戶，或要求他們改變行為。最終我們實施了自動化頻率限制（rate-limits）。頻率限制並不是我們以前常用的工具，但在自動化情境下它更有意義。
• 為了自動化我們的大部分會計工作，我們不得不從頭重建了相當一部分的會計系統。因為根本沒有現實的方法可以自動化 Quickbooks。

你的時間真的非常寶貴。如果降低任務的品質標準能真正釋放你的時間，那幾乎總是值得的。如果產生的系統能為組織實現真正的消除開放迴圈（open loop free），那就更是如此。

3. 自動化特別容易產生「殭屍化」的子結構。因此要讓它們可見。

自動化（以及一般的許多流程形式）的一個大問題是，當一項任務開始作為自動化的一部分執行時，該任務往往會失去很多固有的靈活性。即使沒有失去靈活性，人們也往往會忘記自動化任務的原始目標，這使得他們不太可能注意到該任務是否已變得不必要或不那麼重要（或者變得更重要，以至於在品質上做出了糟糕的權衡）。

這使得自動化系統定期產生關於其運作情況的消息和通知變得尤為重要。Slack 是放置這些內容的首選。每日執行報告、每次處理某事時的消息，以及每週或每月關於自動化運作情況的匯總報告，這些都很重要，能讓大家不會忘記後台正在發生的事情。

4. UI 設計就是自動化

良好的 UI 設計在很大程度上是將任務中不必要的部分自動化。一個好的任務 UI 會消除所有不必要的工作，僅留下需要 UI 使用者做出關鍵決策的部分。令人困惑的 UI 通常表示你正要求用戶做出一個他們不需要做的決定，而這個決定本可以為他們自動化。

如果你未能通過自定義 UI 自動化所有可自動化部分的常見指標：

• 你要求用戶查看某物，卻不告訴他們為什麼你認為他們應該查看。
• 你向用戶展示了過多資訊，而你本可以預先弄清楚他們決策需要哪些資訊（篩選資訊在很多時候是一個非常可自動化的任務！）。
• 常見操作需要多次點擊。

在許多情況下，「為 X 製作 UI」是比「自動化 X」更好的切入點。

5. Airtable 和 Slack 是你的好朋友

在 Lightcone，（與 LessWrong 無關的）數據默認應存放在 Airtable 中，管理自動化的邏輯應首先存在於 Airtable 自動化中；如果變得太複雜，則放在我們內部的基礎設施 Github 倉庫中。

盡可能讓與問題的互動完全發生在 Slack 中。如果做不到，就在 Airtable 中建立界面並從 Slack 鏈接過去。如果這還不夠強大，就製作一個自定義 Web App，並在 Slack 消息中頻繁鏈接它。盡量避免那些不由 Slack 消息觸發，或在完成時不在 Slack 中更新的流程。

Slack 擁有出色的強大工具，我認為我們目前尚未充分利用。Slack 消息可以開啟帶有複雜自定義 UI 的彈窗（modals），並由複雜的自定義數據驅動。消息可以有多個不同的按鈕來觸發外部自動化。你可能會對 Slack 能做的事情感到驚訝。