軟體供應鏈安全聽起來像是設有專職資安部門的大型組織才需要煩惱的事，而正是這種定位讓人判斷失準。一個只維運少數幾項服務的小型團隊，通常同樣相依於數百個套件，而其中沒有任何一個是團隊裡有人真正讀過的。這些套件會在建置時從團隊無法掌控的套件庫抓下來，接著在存放部署認證資訊的機器上執行安裝腳本。 暴露程度並不跟著公司規模等比例放大。它跟著相依套件的數量與建置自動化的程度放大，而小型團隊往往是前者更多、後者更少人盯著，處境比那些公開談論這件事的大型組織還要吃緊一些。 令人不舒服的算術： 你的應用程式大概有十來個直接相依套件，以及數百個間接相依套件。那十來個是你自己挑的。其餘的不是，你一個也沒讀過，而其中任何一個只要執行安裝腳本，拿到的權限就跟...
文章
在同一頁面瀏覽所有文章。找到關於人工智慧、程式設計、資安、基礎設施與網站開發的教學、深度解析、指南與更新。
多語言 SEO 通常被講成一個翻譯問題，外加一點技術標記。但把這個網站用十二種語言營運下來，也就是英語、阿拉伯語、德語、法語、匈牙利語、義大利語、日語、韓語、羅馬尼亞語、越南語，再加上中文的兩種書寫形式，我們很清楚地看到：翻譯才是簡單的那一半。 難的那一半在於，你在英語裡習以為常的每一條規則，都有一個依文字系統而變的版本，而你原本並不知道它存在。長度上限不一樣。結構會跑掉。數字會被一個想幫忙的譯者寫成國字，從那一刻起就不再和原文對得上。這些問題在有東西去檢查之前，一律看不見。 真正讓它跑得起來的是自動化，不是努力。 在任何內容上線之前，有十一項獨立檢查會從頭到尾掃一遍：語言涵蓋率、原文與各譯文之間的結構一致、數字一致性、標題層級順...
在多數已經經營了一段時間的網站上，內容更新是報酬率最高的一項工作，而它之所以不受歡迎，正是因為做完之後沒有任何東西可以拿出來宣布。修改一篇已經有排名的文章，感覺像是在做維護。發布一篇新文章，感覺像是在往前走。數字通常不同意這種感覺。 原因在於，一個已經存在的頁面早就累積了那些昂貴的東西：外部連結、檢索紀錄，以及與一組搜尋字詞之間被驗證過的關係。新頁面從零開始，什麼都沒有，要花上好幾個月才能掙到舊頁面早已擁有的東西。而改進舊頁面，是直接疊加在這份累積之上。 會讓整件事白做的錯誤，是只改日期，別的什麼都不改。 這種做法夠常見，值得把話講明白。一個把新鮮度納入考量的檢索系統，比較的是內容而不是時間戳記，一個日期動了、實質卻原封不動的頁面，...
程式化 SEO 指的是用一套模板加一份資料集大量生成頁面：每個城市一頁、每個產品組合一頁、每一種參數組合一頁。如果用的是真實的資料集，它是這個領域裡效率最高的做法之一。如果用的是同義詞詞典和洗稿工具，它就正是搜尋引擎花了二十年學著辨認的東西。 差別不在技術。兩條路都會大量產出模板頁面。差別在於每一頁是否包含只有這一頁才能回答的東西，而這是關於你手上資料的問題，不是關於你內容流程的問題。換句話說，這個問題的答案在資料庫裡，不在編輯台上。 區分兩者的檢驗方法： 把模板拿掉，看看一頁上還剩下什麼。如果剩下的是真正不同的事實、不同的價格、不同的資料集、不同的計算，這一頁就有存在的理由。如果剩下的是同一段文字換了個地名，...
技術文件的失敗方式非常具體，也非常好預測。有人在兩週清閒的時間裡寫下一大堆，接著系統變了，沒有人回頭更新，一年之內那份文件就開始信心十足地講著錯誤的內容。到了那個時候，它比什麼都沒有還要糟，因為相信它的讀者會依據早已不成立的資訊去動手。 常見的反應是號召大家多寫一些，而這只會讓同樣的失敗來得更快。有用的反應是少寫，並且認真挑選寫什麼，因為真正的瓶頸不是寫作的工夫，而是維護的工夫。文件從寫完那一刻起，就開始被現實甩在後面。 判斷一份文件該不該存在，唯一經得起時間的檢驗是： 當它變錯的時候，會不會有人察覺？部署指南天天有人用，錯誤立刻就會浮出來。一份二十頁的子系統說明只會被讀一次，它的錯誤要等到十八個月後，有人照著它動手時才浮出來。沒有...
開發者到職通常是用新人訓練花了幾天來衡量的，而那是問題的另一頭。真正重要的數字是另一個：一位新來的工程師要過多久，才能改動某個東西，而且有把握自己沒有弄壞別的地方。在大多數團隊裡，這個數字是以月計算的，而不是以天計算的。 延遲很少出在人身上。它出在系統裡有多少部分只存在於別人的腦袋裡，以及前兩週裡有多大一部分時間，是靠一次次打斷別人，一點一點把這些東西挖出來的。 唯一值得追蹤的指標：從到職到他們的第一次改動進入正式環境，需要多久。 不是第一次提交，提交可以只是改一個錯字，而是一次有意義而且真正上線的改動。如果這個時間超過一週，障礙幾乎從來都不是能力。而是一份最近沒有人從零走過一遍的環境建置流程，或者一份沒有人帶路就找不到入口的程式碼...
可用性 SLA 看起來像一句承諾，實際運作起來卻更像一份退款政策。供應商很清楚這一點。客戶往往並不清楚，於是在簽下服務等級協議時以為自己買到了可用性，而真正買到的，只是萬一沒拿到時的一點折扣。 這不一定是筆糟糕的交易。它只是與大多數人以為自己在簽的那筆交易不同，而這個差別恰恰在系統停擺、有人追問合約究竟怎麼寫的那一刻顯現出來。 三個九聽起來接近完美，卻允許每月 43 分鐘的停機。 四個九允許四分鐘。如果你的業務吸收得了平日下午 43 分鐘的中斷，99.9% 就足夠了，不必為更高的數字付費。如果吸收不了，再多的九也幫不上忙，因為協議給你的是一筆抵用金，而不是阻止這次中斷。 可用性 SLA 用分鐘兌現的承諾百分比把一個非常大的區間壓縮成...
軟體原始碼託管，也就是把原始碼交給中立的第三方保管（英文稱為 software escrow），回應的是一種完全合理的擔憂：替你打造並維運關鍵系統的供應商收攤了，而你手上留下的，是一個自己離不開、卻又維護不了的東西。託管合約把原始碼寄存在第三方那裡，一旦真的發生這種情況，第三方就把它交付給你。 這種擔憂站得住腳。問題在於這項工具經常被誤解，而兩者之間的落差催生出一種合約：每年都在花錢，真到需要它的那一天卻幫不上忙。 簽約之前該先問的那個不舒服的問題： 如果明天就把程式碼交到你手上，你這邊真的有人跑得起來嗎？一份沒有建置說明、沒有基礎架構定義、沒有它所呼叫的第三方服務憑證、也沒有資料的原始碼託管，不是營運持續計畫。那只是一個資料夾。從...
在固定價格合約與按工時計費之間做取捨，通常會被說成是一次關於風險的選擇。這個說法本身沒錯，可是緊接著就被處理歪了，因為雙方都預設風險會消失，而不是只在兩邊之間換手。 風險並不會消失。在固定價格的安排裡，估算失準的風險由廠商承擔，而廠商會把這份風險先算進報出的金額裡。在按工時計費的安排裡，承擔的人換成業主。真正的問題從來不是哪一種做法能消除不確定性，而是哪一方比較有條件去管理它，以及把風險轉移出去的代價值不值得付。 能事先看出哪一種做法會成功的檢驗： 你能不能把「完成」寫下來，寫到兩個人對於是否已經達到這個狀態能夠得出一致判斷的程度？如果可以，固定價格就是你能用的選項，而且多半是合理的。如果寫不出來，固定價格合約並不會把模糊消掉，它只...
在小團隊裡，災難復原通常只剩下一份從來沒人打開過的文件裡的一行字：備份已經開啟。這句話本身沒有錯，卻算不上任何問題的答案，因為它既沒有說明真正出事時救回來的資料會有多舊，也沒有說明還原一次要花多久，更沒有說明到今天為止究竟有沒有人完整地做過一次還原。 擁有備份和真的能復原之間存在一段明顯的距離，多數的服務中斷正是在這段距離裡升級成事故。一份存在、內容也夠新、卻從來沒有被還原過的備份，本質上仍然只是一個假設；而你第一次驗證這個假設的時刻，剛好是發現它其實是錯的最糟糕的時刻。 兩個數字能把意見變成計畫。 你承受得起丟多少資料，又承受得起停多久？這就是你的復原點目標與復原時間目標。只要營運那一側沒有人把這兩個數字說出口，關於備份頻率的一切...