本頁提供進一步詳細資訊,以詳細闡述及/或增強 管理專案 — 最佳實務檢查清單.
本小節中的清單並非詳盡無遺,而是作為簡介。
實作AEM時(尤其是首次),您需要檢閱 AEM的功能與工作流程 確定您想要/需要的領域。
請考量您將使用的AEM功能,以及對您設計的影響;例如:
此外,請檢查 發行說明,以查看何時新增任何新功能。
AEM可與其他Adobe產品及/或協力廠商服務整合。 這些功能可增加您可支配的功能。
請參閱 解決方案整合 以取得完整資訊。
主要考量是您是否想:
從舊版移至目前版本時,有兩個選項:
與任何項目一樣,盡快建立基本規則至關重要。 這些包括:
這些點是通用的, 最佳實務檢查清單 處理AEM的相關細節。
角色
應明確界定,並向參與項目的所有人公佈。 此外,建議強調:
責任
參與
通過盡快讓感興趣的方參與進來,您可以鼓勵他們成為 利害關係人 因此,他們對項目成功的承諾越來越大。
溝通途徑
程序
要定義的程式取決於您的個別專案。 再次嘗試保持這些簡單,並考慮:
追蹤工具
有許多工具可用來追蹤有關錯誤、任務和專案其他方面的資訊 — 請參閱 潛在工具概觀 以取得更多詳細資訊。
範圍
明確各級項目應涵蓋的內容:
報告
明確定義您要報告的資訊、形式、報告頻率和向誰報告。
術語
假設
這些資訊可在《項目手冊》中定義;使用Wiki也有助於確保有效處理持續的更改。 無論這些定義如何,關鍵因素是:
組織使用關鍵績效指標(KPI)來評估其達到目標時的成功。 這些指標是可衡量的價值,可用來證明如何有效地實現具體目標。
這些指標可以是:
商務:
效能:
某些指標(但並非全部)可以根據您所識別和定義的目標量度。
量度可用來定義網站品質的量化測量 — 基本上,這些量度是您要達成之效能目標的定義,可用來定義您的 KPI(關鍵績效指標).
有許多量度可定義,但您定義的量度通常涵蓋效能和並行性目標。 尤其是難以量化,而且往往容易被 情感 評估:
「我們的網站 太慢了 今天,什麼時候 慢慢 合格?
「一切」 停了下來 當我的同事登入時」 — 系統可支援多少同時使用者?
「當我搜索時,系統 停了下來 「 — 哪種搜索請求正在影響系統?
「它需要 年齡 要下載檔案,「 — 可接受的下載時間(在正常網路條件下)是多少?
目標量度是在專案開始時定義,以:
定義目標量度時,請務必小心:
在開發專案期間,可視需要更新及調整。 項目成功實施後,它們可用於幫助您控制安裝,並監視/維護持續操作所需的服務級別。
若正確使用,這些量度可提供實用工具;如果不負責任地使用,它們可能會浪費時間分散注意力。 和往常一樣,你需要了解自己在衡量什麼,如何衡量它,以及為什麼。
本節將討論要審議的基本原則和問題。 每個安裝都不同,因此要測量的實際值會不同。
所有要測量的量度,在某種程度上會受到專案設計的影響。 反之,許多問題最好通過設計變更來解決。
因此,您應定義目標量度 befor 決定你的設計。 這可讓您根據這些因素來最佳化設計。 專案一經開發,就很難對基本設計原則進行任何變更。
建立網站結構時,請遵循AEM網站的建議結構。 請務必了解下列問題和/或原則:
如果您覺得您的設計不符合准則,或如果您不確定其中的某些含意,請在開始程式設計階段或填寫內容之前先釐清這些問題。
要定義或評估基礎架構,將有助於定義目標值,例如:
這將幫助您評估和選擇您的基礎架構,具體取決於您的情況和網站的戰略意義:
可評估的效能因素有數個:
個別頁面的回應時間,已考慮:
搜尋請求的回應時間
本節可與 效能最佳化 擴展了實際測量效能的技術細節。
一個主要問題是您的網站回應訪客請求所花的時間。
雖然此值會因每個請求而異,但可定義平均目標值。 一旦此值經證實可達且可維護,即可用來監控網站的效能並指出潛在問題的發展
製作和發佈環境上的不同目標
您要針對的回應時間在製作和發佈環境中會有所不同,反映目標對象:
製作環境
此環境供輸入及更新內容的作者使用,因此必須:
發佈環境
此環境包含您可供使用者使用的內容:
速度仍然重要,但通常比製作環境慢
經常採用其他效能增強機制:
那麼,如何決定可達(平均)的回應時間? 這通常是經驗問題:
但是,(在受控情況下)可採用以下准則:
上述數字假設下列條件:
您可使用數種機制來監控回應時間:
使用AEM request.log監控回應時間
效能分析的一個好起點是請求記錄。 在其他資訊中,您可以使用此項目來查看個別請求的回應時間。 請參閱 效能最佳化 以取得更多詳細資訊。
監控含有HTML備注的回應時間
*HTML comments* can be used to include response time information within the source of each page:
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
搜尋請求對您的網站可能有重大影響,包括:
實際搜索的響應時間
對一般效能的影響
設定搜尋請求的目標,同樣取決於體驗:
從您的專案開始,就應規劃並整合這些功能。 可用於監測的機制包括:
使用AEM request.log監控搜尋回應時間
可再次使用request.log來監控搜尋要求的回應時間;請參閱 效能最佳化 以取得更多詳細資訊。
用於測量搜索響應時間的寫程式機制
若要自訂您收集的搜尋請求相關資訊及其效能,建議您在專案原始碼中加入資訊收集;請參閱 效能最佳化 以取得更多詳細資訊。
您的網站將可在製作和發佈環境中供許多使用者/訪客使用。 測試時,數字通常比您所用的要多,但也會波動,難以預測。 您的網站需要針對平均同時使用者/訪客人數而設計,而不需注意到負面效能影響。 再次 request.log
可進行併發測試;請參閱 效能最佳化 以取得更多詳細資訊。
同時使用者人數的目標取決於環境類型:
製作環境
發佈環境
討論相關量度前,請先快速定義下列詞語:
卷
容量
容量和容量
什麼/位置 | 容量 | 卷 |
---|---|---|
用戶端 | 用戶電腦的計算能力。 | 頁面配置的複雜性。 |
網路 | 網路頻寬。 | 頁面大小(程式碼、影像等)。 |
Dispatcher快取 | Web伺服器的伺服器記憶體(主記憶體和硬碟)。 | Web伺服器(主記憶體和硬碟)。 快取頁數和大小。 |
輸出快取 | AEM伺服器的伺服器記憶體(主記憶體和硬碟)。 | 輸出快取中的頁數和大小、每頁的相依性數。 Dispatcher快取會降低此卷。 |
網頁伺服器 | Web伺服器的計算能力。 | 請求數量。 快取會降低此卷。 |
範本 | Web伺服器的計算能力。 | 範本的複雜度。 |
存放庫 | 儲存庫的效能。 | 從儲存庫載入的頁數。 |
前幾節詳細說明要定義的主要量度。
視您的特定需求而定,單獨定義其他量度或將上述分類納入考量,可能會很實用。
不過,建議您提供一組精確且可靠運作的核心量度,而不要嘗試測量和定義網站的每個層面。 您的網站純粹是由於其性質,一旦交給您的使用者,就會開始變更和發展。
安全至關重要,而且是一個日益嚴峻的挑戰。 It 必須 從專案的最初階段開始加以考量和規劃。
此 安全性檢查清單 詳細說明您應採取的步驟,以確保部署時的AEM安裝安全無虞。 其他安全方面在 安全性(開發時) 和 使用者管理與安全性.
以下項目:
對於標準AEM專案的新實作,您需要考慮下列工作:
建議在所有方面使用迭代方法:
將專案啟動分割為 軟啟動 (降低可用性、多次迭代和 硬啟動 (完全可用性 — 正式啟用),允許在生產環境的實際條件下進行調校、優化和用戶培訓。
請參閱 專案檢查清單 以了解在項目的生命週期中應執行(或評估)的任務的示例。
每個類別的注意事項有:
開發
首先定義基礎架構。
使用數個迭代(sprint)進行開發:
針對專案期間可用AEM版本的最終更新進行規劃。
在短跑期間規劃測試和最佳化。
穩定化和最佳化階段計畫。
建立要計畫供進一步發行的項目記錄。
合作夥伴參與和移交計畫。
基礎設施
首先定義基本架構:
使用數個迭代;對於第一個sprint和初始配置準備:
計畫多個負載測試。
在短跑期間規劃測試和最佳化。
穩定化和最佳化階段的計畫。
盡早部署至生產環境(讓營運團隊設定系統以獲得經驗)。
盡早使用指名的使用者和定義的角色。
計畫培訓(例如,管理員培訓)。
計畫移交給行動。
內容
然後,您可以根據生成的任務清單對(高級)任務定義的時間和工作量進行初始估計。 這些應包括指出將由誰(客戶或合作夥伴)做什麼以及何時做什麼。
下清單顯示了標準近似值和所涉工作的相互關係,因此也包括成本:
這些數字只能用於初步估計。 經驗豐富的AEM開發人員必須進行詳細分析。
階段 | 工作 |
---|---|
開發 | 每個元件節點粗估2至4小時,可涵蓋所有開發需求。 |
開發人員測試 | 15%的發展 |
後續 | 10%的發展 |
文件 | 15%的發展 |
JavaDoc檔案 | 10%的發展 |
錯誤修正 | 15%的發展 |
專案管理 | 20%的項目成本用於進行中的項目管理和治理 |
然後,詳細規劃可將可用或所需資源與截止日期和成本相關。
參考架構旨在為AEM架構提供範本解決方案。 該參考體系結構解決了企業系統經常遇到的問題,包括擴展、可靠性和安全性。
應定義下列網站量度:
分類 | 定義 |
---|---|
網際網路站點數 | |
內聯網站點數 | |
代碼基數(例如,如果Internet和Intranet不同) | |
個別頁面數 | |
網站造訪次數/日 | |
頁面檢視次數/日 | |
資料傳輸的卷(以GB為單位)/天 | |
同時使用者人數(封閉使用者群組) | |
同時訪客數(發佈) | |
同時作者人數 | |
註冊作者人數 | |
頁面激活次數/工作日 | |
部署期間的頁面啟動數 |
提供下列清單,通知您可使用的工具。 這是作為簡介,而非廣泛的建議清單,當然不應阻礙您使用您偏好的任何其他工具。
產品 | 說明 |
AEM | AEM本身提供多種機制,可協助您監控、測試、調查及除錯應用程式;包括: |
硒 | 硒 是開放原始碼測試工具。 測試會直接在瀏覽器中執行,以模擬使用者的運作方式。 |
Microsoft專案 | 常用的專案管理工具。 |
吉拉 | 吉拉 是開放原始碼工具,用於追蹤及管理軟體錯誤的詳細資訊。 工作流程可視需要強加至錯誤詳細資訊。 |
Git | Git 是修訂控制軟體。 |
Eclipse | Eclipse是開放原始碼IDE,由各種項目組成。 這些重點是構建一個由可擴展的框架、工具和運行時組成的開放式開發平台,以便在整個生命週期中構建、部署和管理軟體。 請參閱 如何使用Eclipse開發AEM專案 以取得更多資訊。 |
IntelliJ | 專業(因此可能需要支付許可費)IDE提供一系列全面的功能。 請參閱 如何使用IntelliJ IDEA開發AEM專案 以取得更多資訊。 |
馬文 | 馬文 是一種軟體項目管理和理解工具,可管理項目的構建過程(軟體和文檔)。 |
此外,以下幾節特別感興趣:
Adobe針對所有階段和對象提供進一步的最佳實務: