技術文件的失敗方式非常具體，也非常好預測。有人在兩週清閒的時間裡寫下一大堆，接著系統變了，沒有人回頭更新，一年之內那份文件就開始信心十足地講著錯誤的內容。到了那個時候，它比什麼都沒有還要糟，因為相信它的讀者會依據早已不成立的資訊去動手。 常見的反應是號召大家多寫一些，而這只會讓同樣的失敗來得更快。有用的反應是少寫，並且認真挑選寫什麼，因為真正的瓶頸不是寫作的工夫，而是維護的工夫。文件從寫完那一刻起，就開始被現實甩在後面。 判斷一份文件該不該存在，唯一經得起時間的檢驗是： 當它變錯的時候，會不會有人察覺？部署指南天天有人用，錯誤立刻就會浮出來。一份二十頁的子系統說明只會被讀一次，它的錯誤要等到十八個月後，有人照著它動手時才浮出來。沒有...
文章
在同一頁面瀏覽所有文章。找到關於人工智慧、程式設計、資安、基礎設施與網站開發的教學、深度解析、指南與更新。
開發者到職通常是用新人訓練花了幾天來衡量的，而那是問題的另一頭。真正重要的數字是另一個：一位新來的工程師要過多久，才能改動某個東西，而且有把握自己沒有弄壞別的地方。在大多數團隊裡，這個數字是以月計算的，而不是以天計算的。 延遲很少出在人身上。它出在系統裡有多少部分只存在於別人的腦袋裡，以及前兩週裡有多大一部分時間，是靠一次次打斷別人，一點一點把這些東西挖出來的。 唯一值得追蹤的指標：從到職到他們的第一次改動進入正式環境，需要多久。 不是第一次提交，提交可以只是改一個錯字，而是一次有意義而且真正上線的改動。如果這個時間超過一週，障礙幾乎從來都不是能力。而是一份最近沒有人從零走過一遍的環境建置流程，或者一份沒有人帶路就找不到入口的程式碼...
可用性 SLA 看起來像一句承諾，實際運作起來卻更像一份退款政策。供應商很清楚這一點。客戶往往並不清楚，於是在簽下服務等級協議時以為自己買到了可用性，而真正買到的，只是萬一沒拿到時的一點折扣。 這不一定是筆糟糕的交易。它只是與大多數人以為自己在簽的那筆交易不同，而這個差別恰恰在系統停擺、有人追問合約究竟怎麼寫的那一刻顯現出來。 三個九聽起來接近完美，卻允許每月 43 分鐘的停機。 四個九允許四分鐘。如果你的業務吸收得了平日下午 43 分鐘的中斷，99.9% 就足夠了，不必為更高的數字付費。如果吸收不了，再多的九也幫不上忙，因為協議給你的是一筆抵用金，而不是阻止這次中斷。 可用性 SLA 用分鐘兌現的承諾百分比把一個非常大的區間壓縮成...
軟體原始碼託管，也就是把原始碼交給中立的第三方保管（英文稱為 software escrow），回應的是一種完全合理的擔憂：替你打造並維運關鍵系統的供應商收攤了，而你手上留下的，是一個自己離不開、卻又維護不了的東西。託管合約把原始碼寄存在第三方那裡，一旦真的發生這種情況，第三方就把它交付給你。 這種擔憂站得住腳。問題在於這項工具經常被誤解，而兩者之間的落差催生出一種合約：每年都在花錢，真到需要它的那一天卻幫不上忙。 簽約之前該先問的那個不舒服的問題： 如果明天就把程式碼交到你手上，你這邊真的有人跑得起來嗎？一份沒有建置說明、沒有基礎架構定義、沒有它所呼叫的第三方服務憑證、也沒有資料的原始碼託管，不是營運持續計畫。那只是一個資料夾。從...
在固定價格合約與按工時計費之間做取捨，通常會被說成是一次關於風險的選擇。這個說法本身沒錯，可是緊接著就被處理歪了，因為雙方都預設風險會消失，而不是只在兩邊之間換手。 風險並不會消失。在固定價格的安排裡，估算失準的風險由廠商承擔，而廠商會把這份風險先算進報出的金額裡。在按工時計費的安排裡，承擔的人換成業主。真正的問題從來不是哪一種做法能消除不確定性，而是哪一方比較有條件去管理它，以及把風險轉移出去的代價值不值得付。 能事先看出哪一種做法會成功的檢驗： 你能不能把「完成」寫下來，寫到兩個人對於是否已經達到這個狀態能夠得出一致判斷的程度？如果可以，固定價格就是你能用的選項，而且多半是合理的。如果寫不出來，固定價格合約並不會把模糊消掉，它只...
在小團隊裡，災難復原通常只剩下一份從來沒人打開過的文件裡的一行字：備份已經開啟。這句話本身沒有錯，卻算不上任何問題的答案，因為它既沒有說明真正出事時救回來的資料會有多舊，也沒有說明還原一次要花多久，更沒有說明到今天為止究竟有沒有人完整地做過一次還原。 擁有備份和真的能復原之間存在一段明顯的距離，多數的服務中斷正是在這段距離裡升級成事故。一份存在、內容也夠新、卻從來沒有被還原過的備份，本質上仍然只是一個假設；而你第一次驗證這個假設的時刻，剛好是發現它其實是錯的最糟糕的時刻。 兩個數字能把意見變成計畫。 你承受得起丟多少資料，又承受得起停多久？這就是你的復原點目標與復原時間目標。只要營運那一側沒有人把這兩個數字說出口，關於備份頻率的一切...
內容修剪是搜尋最佳化裡最違反直覺的一件事，因為所有本能都在說，頁面越多流量就該越多。發布內容讓人覺得是在累積資產。刪除內容讓人覺得是把別人花錢買來的成果丟掉。於是刪除一再被往後延，最後只剩下一堆越疊越高的頁面。 讓刪除真正發揮作用的機制，是你自己的頁面彼此在競爭。當你有兩個頁面瞄準同一個搜尋意圖，本來會集中在一個頁面上的訊號就被劈成兩半，而必須在兩者之間做取捨的檢索系統，最後甚至可能一個都不選。解法不是把兩個都做得更好，而是別再同時擁有兩個。 在刪掉任何東西之前，先看清每個頁面各自在做什麼。 一個沒有點擊的頁面，可能仍然承接著一條傳遞權重的反向連結，也可能每月只有一位訪客，卻把這位訪客變成比網站其餘部分加起來還值錢的詢價。流量單獨拿...
關於 API 版本管理的爭論，幾乎總是從錯誤的一端開始：版本號到底要放在哪裡。事實上，那是整個主題裡後果最輕微的一個決定。真正要緊的是究竟哪些變更才需要一個新版本，而多數團隊恰好在這裡判斷失準，而且是往掉以輕心的方向失準。他們發布了自認為純屬新增的東西，然後某個用戶端就壞了。 好用的思考模型是這樣：你的 API 是一份承諾，界定了呼叫端可以倚賴什麼。如果一次變更讓一個講理的呼叫端原本倚賴的東西失效，那它就是破壞性的。而呼叫端倚賴的東西，遠遠多過你的文件明確允許他們倚賴的範圍。 讓所有人都踩到的那種變更： 在回應裡多加一個欄位。它只是新增，照理說弄不壞一個寫得規矩的用戶端，可它偏偏經常弄壞真實世界的用戶端，因為其中有些會嚴格驗證回應，...
軟體 RFP，也就是需求建議書，本來的用途是讓不同廠商變得可以互相比較。可是現實中大多數文件剛好起了反效果：它們把解決方案寫得夠細，細到把回答的空間綁死，卻偏偏漏掉了任何人報價時都會需要的那些資訊。結果就是五份報價，彼此差了一個數量級，形式上每一份都回應了需求，但沒有任何兩份在衡量同一件事。 常見的說法是廠商在打太極。偶爾確實如此。但更常見的情況是，文件要了一個從它本身內容根本推不出來的數字，於是每家廠商都用各自不同的假設去填補空白。假設不同，價格自然不同，這裡並沒有誠不誠實的問題。 判斷你的 RFP 是否有效的檢驗方式： 兩家不同的廠商讀完之後，能不能得出實質上相同的範圍？如果文件裡只寫了「使用者管理」，沒有說明有幾種角色、權限是...
軟體維護成本，就是那個讓一個成功專案在十八個月後變成一場尷尬談話的數字。開發階段有預算、有簽核，也如期交付了。可是上線之後會發生什麼事，被一句「技術支援」草草帶過，再配上一個有人憑感覺喊出來的金額，而那個金額幾乎每次都太小。 原因出在結構，不是誰不用心。開發有一個可以報價的範圍。維護沒有範圍，因為決定它的是還沒發生的事：某個相依套件爆出漏洞、某家供應商改掉自己的介接規格、某位使用者碰上當初誰都沒想到的狀況。 人人都在引用的經驗法則是每年抓開發成本的 15 到 20 個百分點，而它之所以危險，正是因為它離正確答案不遠。 它對的次數多到讓人安心，錯的時候又總是往同一個方向錯：它低估了缺陷集中浮現的第一年，而在有法遵義務或外部介接很多的系...