技術債務來自許多軟件實踐/做法，而其中大多數(shù)實踐/做法相當明顯，是故意選擇的結果。不過在云計算領域，有一些隱伏的、幾乎看不見的新來源導致了軟件無序。

[[132823]]

連云計算也需要春季大清理。而這種大清理不是指你已經(jīng)有所了解的重構和數(shù)據(jù)質量工作。那些“重大項目”不容易漏掉，現(xiàn)在我們需要注意只有在變得特別突出時才會注意到的那些細小問題。

由于云系統(tǒng)易于配置，這些新的小債務很快就會顯露出來。添加新的字段，編輯公式，修改報表，更改參數(shù)選用表值，這每一項操作都只需要短短幾秒鐘。而這些小更改會帶來重大的后果或影響。拋開沒有全面的方法可以清點所有更改這一點不說，新添或更改的條目引起的連鎖反應很難評估。

所以，撤銷更改(為了停用過時功能或糾正新癥狀)涉及的工作量比當初進行更改所需的工作量要大得多。由于日積月累，原先的小債務也開始變得令人討厭。

當然了，傳統(tǒng)派會提到采用配置控制這一方法。對此我深表贊同：云系統(tǒng)比傳統(tǒng)系統(tǒng)更加需要配置控制，就因為它們更容易使用，而且通常以一種完全分散的方式來加以管理。

為此我曾在四年前撰文過，使用云系統(tǒng)支持的新模式將更改記入文檔。但如果將更改記入到配置控制系統(tǒng)所花的時間比實際更改所花的時間還要長，你沒必要是行為經(jīng)濟學家就知道人們不會記入更改。這是人性使然――誰都知道，用牙線清潔牙齒受益無窮，可是由于每天要花2分鐘，于是沒人經(jīng)常用牙齒清潔牙齒。

Salesforce.com用戶們的好消息

這里有幾則好消息，至少對Salesforce.com用戶們來說是這樣。系統(tǒng)會自動保持一份管理更改日志。它并不能代替真正將你的每個操作記入文檔，但這至少開了個好頭。另外，面向Eclipse IDE的Force.com插件讓你可以對幾乎整個系統(tǒng)配置進行快照處理，處理成一組(有時是一組龐大的)XML文件。拿來當月快照后使用你常用的XML差分工具，你就能看到什么地方發(fā)生了更改。當然了，你不會知道為何更改或者由誰更改，但至少有了點頭緒。

另外，還有DreamFactory、Panaya等其他廠商提供的一些快照和差分工具。但如果你并沒有一直在做任何定期的清理任務，可能會發(fā)現(xiàn)這些工具不頂用。在Salesforce.com中，API讓你可以詢問最多10000個對象;而在最近的系統(tǒng)審計中，一個客戶有20000多個對象。真糟糕。

采取行動以減少技術債務

但是工具在這里解決不了問題，而***實踐解決得了問題，比如下面這些：

1.設定更改方面的預期目標。即便你可以在20秒內進行更改，也要明確：更改只能每天進行一次，如果可以的話，每周進行一次。

2.設定系統(tǒng)管理工作負載方面的預期目標。你根本無法一下子還清技術債務，預計15%的管理時間專門用于慢慢清理債務是合理的。

3.每季度(或者按云系統(tǒng)的日志跨度)備份一次系統(tǒng)管理員的更改日志。這個小文件要***保存。

4.使用標準的沙盒，每月更新一次。想真正看到潛在更改的影響，唯一的辦法就是在裝滿數(shù)據(jù)的沙盒里面;即便如此，還是會有一些問題只在生產環(huán)境中才會體現(xiàn)出來。

5.另外使用開發(fā)沙盒(這是免費的)，每天更新一次。

6.對生產系統(tǒng)使用系統(tǒng)快照工具，每天更新一次。使用該快照分析哪里在使用，以支持設計提擬的更改。

7.在生產環(huán)境中進行更改之前，先在其中一個沙盒里面進行測試。要是更改區(qū)域是配置在過去30天沒有發(fā)生太大變化的區(qū)域，就在整個沙盒里面進行測試。要是出現(xiàn)了許多配置更改，就在開發(fā)沙盒里面進行測試。

8.一旦你將更改的內容放入到沙盒，就按一下“運行所有測試”按鈕(或者是你的云系統(tǒng)用來運行單元測試和系統(tǒng)測試的任何機制)，看看有沒有任何新的測試錯誤出現(xiàn)。有時候，僅僅修復參數(shù)選用表中的拼寫錯誤就會引起好多的測試錯誤。

9.合計系統(tǒng)中的所有視圖、報表和儀表板，每月合計一次。這些東西往往會迅速增多(如果大多數(shù)用戶被允許可以創(chuàng)建自己的報表，更是如此)，會給系統(tǒng)可靠性帶來致命影響。大膽精簡報表(通過隱藏報表，而不是刪除報表)――12個月里面沒有運行過的任何報表都不太可能有保留價值。

10.分析什么條目引起系統(tǒng)管理項急劇增多，嚴密分析增添復雜性的新來源，每月分析一次。在Salesforce中，主要條目有配置文件、自定義對象和記錄類型。有100000多個布爾表達式定義安全系統(tǒng)，這種情況并不罕見，所以你應該密切關注會導致這個數(shù)呈幾何增長的任何方面。

11.制定一項政策：每當你給系統(tǒng)添加內容，至少要廢棄一個條目。至少需要刪除之前被廢棄的一個條目(通常每月至少應該進行一次“清除”工作。)

• 廢棄對象應該包括條目標簽開頭的特殊ASCII字符(比如▼或♖)，明確表明在使用該字段的任何報表或頁面布局中“這里出現(xiàn)了異常問題”。
• 廢棄還應該包括給字段的“開發(fā)人員姓名”前面加上“zzz”，迫使已廢棄的字段進入按首字母排序列表的底部。
• 必須將廢棄和刪除操作當作變更來處理，這些變更已記入日志，并在沙盒里面進行了全面測試，之后才可以進入到生產環(huán)境。

結束語

這方面沒有什么簡易的解決辦法，沒人喜歡還債。但是技術債務確確實實存在，而且會日積月累。所以，不妨授權員工來一番春季大清理，免得到時局面失控。

原文標題：Best practices for cloud spring cleaning