雲端計算環境春季大清理最佳實踐
技術債務來自許多軟體實踐/做法,而其中大多數實踐/做法相當明顯,是故意選擇的結果。不過在雲端計算領域,有一些隱伏的、幾乎看不見的新來源導致了軟體無序。
連雲端計算也需要春季大清理。而這種大清理不是指你已經有所瞭解的重構和資料質量工作。那些“重大專案”不容易漏掉,現在我們需要注意只有在變得特別突出時才會注意到的那些細小問題。
由於雲系統易於配置,這些新的小債務很快就會顯露出來。新增新的欄位,編輯公式,修改報表,更改引數選用表值,這每一項操作都只需要短短几秒鐘。而這些小更改會帶來重大的後果或影響。拋開沒有全面的方法可以清點所有更改這一點不說,新添或更改的條目引起的連鎖反應很難評估。
所以,撤銷更改(為了停用過時功能或糾正新症狀)涉及的工作量比當初進行更改所需的工作量要大得多。由於日積月累,原先的小債務也開始變得令人討厭。
當然了,傳統派會提到採用配置控制這一方法。對此我深表贊同:雲系統比傳統系統更加需要配置控制,就因為它們更容易使用,而且通常以一種完全分散的方式來加以管理。
為此我曾在四年前撰文過,使用雲系統支援的新模式將更改記入文件。但如果將更改記入到配置控制系統所花的時間比實際更改所花的時間還要長,你沒必要是行為經濟學家就知道人們不會記入更改。這是人性使然――誰都知道,用牙線清潔牙齒受益無窮,可是由於每天要花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”,,迫使已廢棄的欄位進入按首字母排序列表的底部。
必須將廢棄和刪除操作當作變更來處理,這些變更已記入日誌,並在沙盒裡面進行了全面測試,之後才可以進入到生產環境。
結束語
這方面沒有什麼簡易的解決辦法,沒人喜歡還債。但是技術債務確確實實存在,而且會日積月累。所以,不妨授權員工來一番春季大清理,免得到時局面失控。
連雲端計算也需要春季大清理。而這種大清理不是指你已經有所瞭解的重構和資料質量工作。那些“重大專案”不容易漏掉,現在我們需要注意只有在變得特別突出時才會注意到的那些細小問題。
由於雲系統易於配置,這些新的小債務很快就會顯露出來。新增新的欄位,編輯公式,修改報表,更改引數選用表值,這每一項操作都只需要短短几秒鐘。而這些小更改會帶來重大的後果或影響。拋開沒有全面的方法可以清點所有更改這一點不說,新添或更改的條目引起的連鎖反應很難評估。
所以,撤銷更改(為了停用過時功能或糾正新症狀)涉及的工作量比當初進行更改所需的工作量要大得多。由於日積月累,原先的小債務也開始變得令人討厭。
當然了,傳統派會提到採用配置控制這一方法。對此我深表贊同:雲系統比傳統系統更加需要配置控制,就因為它們更容易使用,而且通常以一種完全分散的方式來加以管理。
為此我曾在四年前撰文過,使用雲系統支援的新模式將更改記入文件。但如果將更改記入到配置控制系統所花的時間比實際更改所花的時間還要長,你沒必要是行為經濟學家就知道人們不會記入更改。這是人性使然――誰都知道,用牙線清潔牙齒受益無窮,可是由於每天要花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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 最佳實踐丨雲開發CloudBase多環境管理實踐Cloud
- 端到端的實時計算:TiDB + Flink 最佳實踐TiDB
- 雲端計算原生安全模型和實踐模型
- 雲端計算環境下的BGP協議應用協議
- 哪些開源雲端計算環境管理工具好用?
- 邊緣計算的最佳實踐
- Ftj aRTTy因子計算最佳實踐
- 修改雲端計算災難恢復計劃,最佳實踐的7個建議來了!
- Nestjs最佳實踐教程:1編碼環境搭建JS
- 雲端計算技術在家庭辦公環境的應用
- 後端多環境治理的實踐(二)後端
- 後端多環境治理的實踐(一)後端
- 雲端計算大趨勢
- 雲端設計平臺Coohom在生產環境中使用istio的經驗與實踐
- 容器化環境中,JVM最佳引數配置實踐JVM
- 小白怎麼學習雲端計算?雲端計算學習大綱
- 【雲端計算】雲端計算六大優點簡單說明
- 雲端計算管理平臺之OpenStack簡介及基礎環境搭建
- 雲端計算和大資料學哪個好?雲端計算學習大資料
- 雲環境下集合隱私計算-解讀
- 雲端儲存安全標準和最佳實踐
- 雲端計算大資料面試題,雲端計算大資料面試題集錦大資料面試題
- 從零開始實踐大模型 - 配置環境大模型
- 學習雲端計算怎麼樣?大資料比雲端計算更好嗎?大資料
- 雲端計算前景如何?大專學歷學習雲端計算怎麼樣?
- 雲端計算基礎學習,雲端計算的八大運用分析
- 調研:民營企業挑起雲端計算實踐的大梁
- 雲端計算與大資料[4]大資料
- 容器雲多叢集環境下如何實踐 DevOpsdev
- Gartner:新安全環境對虛擬化和雲端計算提出更高要求
- Hybris開發環境的license計算實現開發環境
- 測試環境使用問題及其最佳化對策實踐
- 微服務不同環境到底該如何部署?最佳實踐是什麼?微服務
- 人工智慧+大資料+雲端計算人工智慧大資料
- 雲端計算的五大誤解
- 雲端計算規模大嗎?可靠嗎?
- 雲端計算的三大服務模式模式
- 大資料與雲端計算概論大資料
- 作業幫在多雲環境下的高可用雙活架構最佳化實踐架構