在開始對此系統進行再次分析之前，再回顧下可用性。首先，可用性是與系統故障有關的乙個質量屬性，是指系統正常執行的時間的比例，一般通過兩次故障之間的時間長度或在系統崩潰情況下能恢復正常執行的速度來衡量，同時此概念涉及乙個公式的計算。其次，可用性關注以下幾個方面：如何檢測故障、發生故障的頻度、出現故障時的現象、系統故障排除的時限、如何防止故障的發生、發生故障時的處理。最後，可以總結的是，可用性可以從客觀和主觀兩個方面來進行評價，客觀的就是講這個系統講這些個功能是否達標，主觀的講就是使用者是否滿意。另外，提公升可用性，一般從這四個方面來考慮：錯誤檢測、捕獲異常、錯誤恢復、和錯誤預防。
在《大型**技術架構》一書中，第五章首先提到基本分層架構模型，即應用層、資料層和服務層的分離。在原先自己的xx系統中，這三個方面幾乎融為一體，將三個方面都寫在了一起，可以說是乙個相當混亂的系統，這三個方面幾乎沒有什麼獨立的概念。這個學期重做這個系統，首先要做的就是採用合適的框架，盡自己能力的將這三個方面實現獨立，使之相關聯、錯誤卻不相迅速產生連鎖反應，實現整個系統整體結構上的清晰明了與可用。
緊接著，書中提出利用瀏覽器支援的cookie來記錄session，對於這一點，我所想到的其實是使用者在登入一次後，以後是否能進行自動登入這個問題。正如老師曾在安卓的課上所說到的，總不能讓使用者每次都看見歡迎介面，每次自己手動輸入賬號密碼。如果每次的登入都帶來這個問題，那麼使用者必然不願意再繼續使用這款軟體，我這裡也盡可能的在xx系統上做優化。
針對接下來提出的分級管理，我想到上次把我做的系統給學弟評分的時候出現的乙個問題。雖然，我的功能都有了，但是，系統卻能在沒有填寫相關資訊的情況下去填寫徵集表的內容。我將填寫個人資訊的模組和填寫徵集表的模組相獨立卻沒有進行層次上先後的限制，而重做系統，這個限制條件這次是應該加入進去了。
上課的時候，老師一再提到了對於資訊的刪除不能那麼任性！這一點又是值得好好考慮的，首先考慮人性化考慮，其次考慮，真的誤操作，怎麼恢復的問題。這裡，首先是提示，做好人機互動，以防誤操作的問題，其次是資料的備份與恢復，最後是日誌的記錄和回滾，後面兩點均是為真正誤操作而考慮的。其中資料進行同步和非同步的備份；日誌部分為三個：使用者的行為日誌、伺服器端日誌、瀏覽器的日誌。（儘管此處，個人還不知道具體如何實現，但是，先考慮上，努力完成）
在書第六章第七章中，我了解了一些其他方面關於可用性的知識，但是思索過後，並不知道如何與所做的系統具體的結合在一起，因此不在此處進行聯絡說明了。
其實，現在來回顧上個學習整個系統的實現，儘管耗時很久，但是真正實現的時間也就花了兩三個晚上。所以缺點和漏洞還是有很多的。接下來，在重寫系統的過程中，如若發現其他的關於可用性的改動，再來進行補充說明。
（未完）
10條可用性方面的啟發
譯序 這篇文章是可用性大師 jakob nielsen 在10年前總結的，到今天仍然受用。通過這個時間跨度，可以得出，可用性話題不是某個時代的產物，一些研究經驗時至今日也依然值得借鑑。看似短小的10條啟示中，融入了大量專案經驗，這些內容也將繼續指導設計者，在新的網際網路技術推動下，創造出更加高質量的...
關於某某系統增加相應功能，提高系統的可用性和易用性
的可用性描述 的可有效訪問的特性 不同於另乙個 運營指標 usability,通常也被譯為可用性，但後者強調的是 的可用性，即對終端使用者的使用價值 相對於 的其他非功能特性，的可用性更牽動人們的神經，大型 不可用事故直接影響公司形象和利益，許多網際網路公司都將 可用性例如工程師的績效考核，與獎金省...
高可用性系統的集群解決方案整理
關於如何設計乙個高可用性 部分節點宕機仍然保證可用 的系統，整理下大致思路。系統前端的設計中，採用比較通用的解決方案，web伺服器 如apache 應用伺服器集群 tomcat或者weblogic 客戶端 client 連線web伺服器時需要考慮session的分布式管理，可以用memcached與...