20 個恐怖傳說:在技術上犯過的最糟糕錯誤
一些系統管理員、網頁設計師、工程師和程序員分享了他們在命令行上經歷的最可怕的經歷。
每個開發人員內心最害怕的事情是什麼?在你的代碼開始運行前的寧靜時刻,什麼最讓你感到恐怖?你見過或寫過最可怕的代碼是什麼?
錯誤的許可權
我負責一台伺服器,然後我通過 FTP 上傳了一些東西。顯示了一些奇怪的東西,所以我想許可權可能需要改變一下。
不用說,我愚蠢地關閉了讀取許可權並使網站癱瘓了。(當沒有人能訪問時,網站就沒啥用了。)
我花了幾個小時才修復好。這是很多年前我在一個機構擔任唯一的網頁開發人員時的事情。
混亂的 HTML
我曾經因 WordPress 的默認主題有可用的更新而使一個客戶的網站癱瘓,這個客戶當時是《華爾街日報》暢銷書榜上的一位作者。
他的開發人員在主題中硬編碼了 HTML,而不是創建一個子主題。而我運行了更新操作。
那個年代,人們不容易實現每晚備份,所以我花了幾個小時打電話給託管提供商。像分階段發布、子主題、每晚備份或手動備份這樣的東西現在都很常見,還有自動更新和手動回滾的能力。但在那個時代並不常見。
密鑰不再秘密
我想我們中的許多人在公共代碼中看到過密鑰。或者另一個經典案例:我的一個朋友從開發伺服器向 10 萬個用戶發送電子郵件。
Unix 混亂
這是一個 Unix 的故事。今天在 Linux 中已經修復了這個問題。
在我要向管理層進行一個重要的新組件演示的前一天,我需要更新我的代碼(這是在 Git 存在之前的年代)。我進入我的主目錄,找到項目目錄,然後刪掉了一切。不幸的是,在那個版本的 Unix 中,該命令會跟隨符號鏈接進行刪除,並且我有一個鏈接指向代碼的最新版本(並不是所有代碼都在源代碼系統中,因為它還處於測試階段)。
好在一天後,大樓里出現了網路問題,因此演示推遲了一天,我們設法恢復了代碼。那是三十多年前的事情。即使現在我也不知道網路問題是巧合,還是我們的系統管理員試圖幫助我們(如果是這樣,那確實奏效了!)
命令式編程
看到 CSS 文件中到處都是 !important;
而不是正確使用特異性。
我曾經不得不覆蓋和定製一個 WordPress 主題幾乎所有的 CSS,因為該網站的所有者堅持不換一個更接近他想要的設計的新主題。
那個主題開發者最後一次更新是在 2018 年,但網站至今仍在使用。
錯誤引用
在我以前的職位上,我的前任在代碼注釋中引用了 Journey 的《Any Way You Want It》歌詞錯誤。
Algol68 的幽靈
在上世紀 60 年代末到 70 年代初,Algol68 的複雜性使許多有影響力的人望而卻步,包括 Niklaus Wirth 在內。我記得當時最常見的抱怨之一是:「誰能為這樣一個複雜的怪物寫一個編譯器呢?」 但是事實上,許多人都開發過。此外,許多在 Algol68 中發展出來的或至少以形式化的概念出現在後來的其他語言中,尤其是在 C 語言和 Bourne shell 中(感謝 Steve Bourne)。
Algol68 的一些概念並沒有經過很好的演化。例如,處理「書」和「章節」等的 I/O 概念在今天有些奇怪。像將字符集等問題留給實現本身處理似乎相當過時。
但是其中一些概念在今天仍然極為重要,例如產生值的表達式、強類型化(Algol68 中稱為「模式」的類型)、堆內存和垃圾回收、運算符的定義和重載等等。
有好的地方,也有不好的地方。
Algol68 是一門值得學習的語言,即使只是為了了解現代計算中的許多想法的來源以及在路上丟失了多少。
密碼暴露
我為一個新的支持客戶進行技術審計時,發現之前的開發人員將密碼以明文形式存儲在整個主題中,並使用了糟糕的方式連接到遠程資料庫。他們的 composer 文件也異常龐大。每次我嘗試在本地運行網站時,需要花費五分鐘的時間。過時的依賴項、我無法訪問的倉庫,問題還有很多。
迷宮般的代碼
我見過的最可怕的代碼是一段 PDP-11 彙編語言,位於一個名為 RSTS 的操作系統的內核中,今天已經沒有人記得它了。當時源代碼記錄在膠片上,我跟隨這段代碼路徑經過幾個轉折,試圖弄清楚正在發生的事情。然後,我遇到了這條指令:
MOV R5,PC
我舉起雙手尖叫了起來。真的,我尖叫了。辦公室里的人以為我撞到頭了,或者心臟病發作了。
那個年代,內存是寶貴的,MOV
指令使用的內存比 BR
(即「分支」)指令稍微少一點。將寄存器 5 的內容複製到程序計數器實際上是一個廉價的無條件跳轉,跳轉到寄存器 5 中存儲的地址。但是,我不知道寄存器 5 中存儲了什麼,也不知道如何找到它。
時至今日,將近 40 年過去了,我仍然想知道是誰寫出這樣的代碼,以及如何調試它。
差一個
我在自動化行業工作,其中的可編程邏輯控制器(PLC)使用一些相當奇怪的語言進行編程。
讓我印象深刻的一個例子是,在 ST 語言中,你可以定義數組從索引 1 開始。這意味著第一個元素在位置 1 而不是 0。每當我看到這個時,我都會抓狂。
分歧
有一次在一個從測試環境到生產環境的發布期間,我讓 MongoDB 實例停機了 40 分鐘。我們的測試環境與生產環境有所分歧。只是一個資料庫配置的差異,沒什麼太激動人心的東西。但這是一個很好的教訓,要確保你的測試和生產環境保持同步!
神秘的低語
這是一個仍在運行且正常的項目,但我已經修改了代碼以隱藏源代碼。
for(int c =0; y < yyy && c < ccc; y++, c++){// some code here}
乍看起來,它似乎是一個無害的循環。但也許你會問為什麼有兩個變數、兩個停止條件以及兩個增量。然後你會意識到只有一個初始化器,第二個變數(y
)在這個循環之前在不同的代碼塊中被初始化。
當我意識到這一點時,我花了大約一個小時的時間來理解為什麼代碼是這樣編寫的,以及它應該如何工作。顯然,代碼中沒有 c
的注釋,並且變數名是無意義的(代碼中被稱為 c
,y
有一個稍微具有意義的名稱,但不足以解釋它的意義,即使是今天我也不知道它的作用)。
關鍵數據
大約在 1980 年,我在大學畢業後得到了我的第一份工作。我是印第安那州一所工程學院的計算中心副主管。這是一個兩人 IT 部門的輔助職位。我在 PDP-11/40 上處理行政計算,使用 RK05 可移動的「披薩碟」磁碟驅動器(每個驅動器容量為 2.5 MB)。每個行政辦公室都有一個驅動器,而我工作的一部分就是每周進行磁碟對磁碟的備份。但是那個夏天我很忙,連續四周沒有備份過註冊辦公室的數據。然後我意識到了風險,所以我確保開始進行每月的磁碟到磁帶備份。
我從 11/40 上卸載了註冊辦公室的磁碟驅動器,然後裝在了帶有一台 9 磁軌磁帶驅動器的 11/70 上,並開始進行備份。幾分鐘後,我聽到磁碟驅動器里傳來一陣刮擦的聲音。是的,磁頭撞上了磁碟。在短短几分鐘內,我摧毀了所有註冊辦公室的數據,以及最新的備份 —— 一個四周前的 9 磁軌磁帶。
當我不得不面對註冊辦公室主任,並告訴他我已經摧毀了他所有的數據時,那一刻真的很尷尬。
如今,我告訴新的 IT 人員,只有在你摧毀了某人的關鍵數據,而且無法恢復時,你才算是專業人士。永遠記住你胃裡的那種感覺。
憤怒的暴民
一個客戶篡改了 WordPress 核心代碼以添加後續在常規更新中發布的功能,但他們卻不明白為什麼在每次嘗試更新 LearnDash 時網站都會崩潰。(他們也不喜歡我們的報告指出了他們糟糕的開發實踐。)於是他們趕我們走,稱我們是騙子和無能之輩。但直到今天,我仍然具有他們域名的委派訪問許可權,以及兩個域名的生產和開發環境的 wp-admin 訪問許可權。
此外,儘管我們給了一個加密位置的鏈接用於共享訪問憑據,他們卻通過電子郵件發送了我們的登錄信息。
不要忘記備份
我在企業網路上的工作經驗不多,所以我沒有使任何伺服器崩潰過。然而,作為一個年輕人,我曾經試圖幫助一個人解決 IT 問題,不知何故導致 Windows 95 崩潰,並不得不免費重新安裝。
作為一個非常年輕的 Amiga 用戶,我最悲傷的時刻之一是我的保存磁碟壞掉了,裡面裝滿了所有我的文件,原因是某種機械故障。如今,我已經學會更好地備份我的重要個人文件。
萬惡之源
當時我剛開始接觸 Linux,之前我用的是 DOS,藉助 Norton Commander 進行操作。後來,Midnight Commander 發布了,我非常喜歡它。當時我使用的 Linux 發行版(Jurix)沒有打包 Midnight Commander,所以我自己從源代碼編譯了它,就像我那個時候使用的其他軟體一樣。它完美地運行了,突然間我在 Linux 上感到更親切了。
這不是一個恐怖的故事。
我的同事告訴我不要以 root 身份運行 Midnight Commander,無論它有多麼讓人舒適。但是 root 許可權很方便,感覺更像 DOS,所以我無視了他們的建議。結果就是:我意外地刪除了整個 /etc
目錄的內容。在那之前,我從來沒有用過備份功能,但是那一天我意識到備份實際上是有用的。
27 年過去了,我仍然記得這個故事,並定期進行備份。
幻覺
最糟糕的項目是一家代理機構讓我做的一個一屏的頁面,一開始看起來很簡單。我說我可以用一些 HTML、CSS,也許加點 JavaScript,將其組合起來。但他們特別要求我不要這樣做。他們希望我將設計圖剪切下來,然後使用 CSS 在頁面中定位這些元素。他們還要求我將所有的 CSS 內嵌到 HTML 文件中,因為他們真的只想要一個頁面。
其中的文本都不是真實的文本。
除了定位這些圖片所需的元素之外,其他都不是真正的 HTML 元素。
我告訴他們,設計足夠簡單,我可以用實際的代碼將其組合起來,但他們不想要那樣。他們只想讓我花時間將這些碎片拼湊在一起,然後轉而做其他項目。他們讓我做了兩個類似的一屏網站。
這實在傷害了我的前端靈魂。為我來說,這個項目在身體上是痛苦的。這是一個試用合同職位,當他們給我提供全職工作時,我禮貌地拒絕了。
內存破壞
對我來說,最可怕的事情就是 ANSI C99 中可能發生的內存破壞。在一個屏幕錄像中,我捕捉到了這個(不完全是)超自然現象,可以在這個 YouTube 視頻片段 中觀看到。
標有 file
的 GtkEntry 顯示了一些隨機的符號。我檢查了一下 代碼,但沒有發現任何問題。
ags_export_soundcard_open_response_callback()
函數是一個回調函數,用於處理 GtkFileChooserDialog
的 response
事件。(順便說一句,用於解決這個問題的工具是 valgrind。)
Python 的恐怖之處
我見過的最可怕的編程特性是 Python 中對 dict
的訪問許可權。在運行時改變對象的類型違背了我的編程行為準則。
縫合怪網路
在 2006 年,我用 Fedora 和一些腳本構建了一台防火牆,並說服了一家託管在合作數據中心的大型網站的客戶,將其專有的防火牆替換為我的防火牆。我建立了系統並在一個清晨的 4 點到達現場進行安裝。那時我才發現(飽受痛苦地)他在防火牆後面有一個帶有公共 IP 地址的負載均衡器。客戶經歷了一個 5 分鐘的停機時間,但我重新連接了一切恢復到原來的狀態。
我發現了一種通過使用代理 ARP 來處理他複雜的網路配置的方法。這個想法是,當外部世界的任何人發出負載均衡器的 ARP 請求時,我會進行回應。幾天後,我再次在凌晨 4 點出現並安裝了我的系統。這次,我把整個數據中心的所有設備都給搞宕了。我設置了我的代理 ARP 來回應所有請求,因此區域網上的所有流量最終都找到了我並消失在黑洞中。
當我意識到我做了什麼時,我把一切都恢復到原來的狀態。但是損害已經造成。如果有人在 2006 年的一個清晨美國中部時間大約 4 點鐘嘗試瀏覽你最喜歡的網站,它沒有響應,那可能是我的錯。我通過在機架上安裝並啟動一個系統,讓整個數據中心的網站都宕機了。
網站運營商憤怒地抗議,而我則黯然離開。他們再也沒有邀請我回去再試。真是遺憾,我覺得再試試橋接可能會起作用。
你的恐怖故事
你最喜歡的與技術相關的恐怖故事是什麼?在評論中告訴我們(但要友善,並更改項目名稱以保護無辜者!)
via: https://opensource.com/article/22/10/technology-horror-stories
作者:AmyJune Hineline 選題:lkxed 譯者:ChatGPT 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive