雲端計算環境春季大清理最佳實踐

1013301358發表於2015-05-04
技術債務來自許多軟體實踐/做法,而其中大多數實踐/做法相當明顯,是故意選擇的結果。不過在雲端計算領域,有一些隱伏的、幾乎看不見的新來源導致了軟體無序。


連雲端計算也需要春季大清理。而這種大清理不是指你已經有所瞭解的重構和資料質量工作。那些“重大專案”不容易漏掉,現在我們需要注意只有在變得特別突出時才會注意到的那些細小問題。


由於雲系統易於配置,這些新的小債務很快就會顯露出來。新增新的欄位,編輯公式,修改報表,更改引數選用表值,這每一項操作都只需要短短几秒鐘。而這些小更改會帶來重大的後果或影響。拋開沒有全面的方法可以清點所有更改這一點不說,新添或更改的條目引起的連鎖反應很難評估。


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


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


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


Salesforce.com使用者們的好訊息


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


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


採取行動以減少技術債務


但是工具在這裡解決不了問題,而最佳實踐解決得了問題,比如下面這些:


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


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


3.每季度(或者按雲系統的日誌跨度)備份一次系統管理員的更改日誌。這個小檔案要永久儲存。


4.使用標準的沙盒,每月更新一次。想真正看到潛在更改的影響,唯一的辦法就是在裝滿資料的沙盒裡面;即便如此,還是會有一些問題只在生產環境中才會體現出來。


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


6.對生產系統使用系統快照工具,每天更新一次。使用該快照分析哪裡在使用,以支援設計提擬的更改。


7.在生產環境中進行更改之前,先在其中一個沙盒裡面進行測試。要是更改區域是配置在過去30天沒有發生太大變化的區域,就在整個沙盒裡面進行測試。要是出現了許多配置更改,就在開發沙盒裡面進行測試。


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


9.合計系統中的所有檢視、報表和儀表板,每月合計一次。這些東西往往會迅速增多(如果大多數使用者被允許可以建立自己的報表,更是如此),會給系統可靠性帶來致命影響。大膽精簡報表(透過隱藏報表,而不是刪除報表)――12個月裡面沒有執行過的任何報表都不太可能有保留價值。


10.分析什麼條目引起系統管理項急劇增多,嚴密分析增添複雜性的新來源,每月分析一次。在Salesforce中,主要條目有配置檔案、自定義物件和記錄型別。有100000多個布林表示式定義安全系統,這種情況並不罕見,所以你應該密切關注會導致這個數呈幾何增長的任何方面。


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


廢棄物件應該包括條目標籤開頭的特殊ASCII字元(比如▼或?),明確表明在使用該欄位的任何報表或頁面佈局中“這裡出現了異常問題”。
廢棄還應該包括給欄位的“開發人員姓名”前面加上“zzz”,,迫使已廢棄的欄位進入按首字母排序列表的底部。
必須將廢棄和刪除操作當作變更來處理,這些變更已記入日誌,並在沙盒裡面進行了全面測試,之後才可以進入到生產環境。
結束語


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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29874604/viewspace-1621820/,如需轉載,請註明出處,否則將追究法律責任。

相關文章