資訊科技與倫理/軟體開發中的自動化
在軟體行業，甚至在軟體開發等領域，自動化是一個相對增長的領域。現在，對於許多人來說，這個概念似乎很簡單。它是建立指令碼來自動執行某項任務的過程。這可以在物聯網裝置中看到，例如 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]