檢查清單 — 進一步參考 the-checklist-further-reference
本頁提供進一步詳細資訊，以詳細闡述及/或增強 管理專案 — 最佳實務檢查清單.
AEM — 您將使用什麼？ aem-what-will-you-be-using
AEM內的功能 features-within-aem
實作AEM時（尤其是首次），您需要檢閱 AEM的功能與工作流程 確定您想要/需要的領域。
請考量您將使用的AEM功能，以及對您設計的影響；例如：
此外，請檢查 發行說明，以查看何時新增任何新功能。
整合 integrations
AEM可與其他Adobe產品及/或協力廠商服務整合。 這些功能可增加您可支配的功能。
請參閱 解決方案整合 以取得完整資訊。
遷移還是升級？ migrate-or-upgrade
主要考量是您是否想：
- 升級現有安裝。
- 將內容從當前系統遷移到全新安裝。
從舊版移至目前版本時，有兩個選項：
基本基本准則 basic-ground-rules
與任何項目一樣，盡快建立基本規則至關重要。 這些類別包括：
-
角色
應明確界定，並向參與項目的所有人公佈。 此外，建議強調：
- 決策者
- 接觸點
-
責任
- 對於每個角色，請明確定義與專案相關的責任，有助於避免混淆。
-
參與
通過盡快讓感興趣的方參與進來，您可以鼓勵他們成為 利害關係人 因此，他們對項目成功的承諾越來越大。
- 在客戶端，這包括作者 — 他們必須每天與系統合作。
- 在您自己的專案團隊中，這也包括負責品質保證的人員。 他們越了解客戶的要求，就越能規劃測試。
-
溝通途徑
- 雖然這些規定不應過分正規化，但具體定義應確保隨時向關鍵人員通報情況，從而保持最新。 應特別注意與外部方的溝通。
-
程序
要定義的程式取決於您的個別專案。 再次嘗試保持這些簡單，並考慮：
- 定義與任何第三方互動的流程（和溝通途徑）;例如設計機構和第三方軟體供應商等。
- 客戶通常擁有自己的項目管理和報告過程和工具。
-
追蹤工具
有許多工具可用來追蹤有關錯誤、任務和專案其他方面的資訊 — 請參閱 潛在工具概觀 以取得更多詳細資訊。
- 此處需要注意的要點是僅保留資訊的一個副本並共用資訊（因此可以訪問所使用的工具）。 這樣就能輕鬆維護，並有助於防止差異。
-
範圍
明確各級項目應涵蓋的內容：
- 個別發行（若使用迭代發行程式，且無論是提供給客戶還是您的內部測試團隊）。
- AEM專案。
- 整個項目；包括任何協力廠商軟體、其對測試的影響、組織問題和其他許多問題。
- 對於某些方面，說明內容也會很有用 not 在項目範圍內。 這有助於防止混淆和錯誤的假設，但應限於基本問題。
-
報告
明確定義您要報告的資訊、形式、報告頻率和向誰報告。
-
術語
- 定義要使用的任何縮寫和/或客戶專屬術語。
-
假設
- 定義所做的任何假設。
這些資訊可在《項目手冊》中定義；使用Wiki也有助於確保有效處理持續的更改。 無論這些定義如何，關鍵因素是：
- 資訊已定義並維護
- 向所有有關人員明確傳達資訊。 雖然標準的項目管理實踐，但是不能經常重複，以使清晰的角色定義和良好的溝通能夠建立或破壞一個項目。
- 只保留任何被追蹤資訊的一個版本；例如錯誤追蹤、問題追蹤等。
關鍵績效指標和目標量度 key-performance-indicators-and-target-metrics
組織使用關鍵績效指標(KPI)來評估其達到目標時的成功。 這些指標是可衡量的價值，可用來證明如何有效地實現具體目標。
這些指標可以是：
-
商務:
- 用於測量關鍵業務目標。
- 請務必以清楚的定義選擇適合您的業務/情境的KPI，以判斷KPI是什麼、如何衡量、如何使用以及由誰使用。
-
效能：
- 定義如何測量系統的效能。
- 例如頁面載入時間、伺服器回應時間和資料庫查詢效能。
某些指標（但並非全部）可以根據您所識別和定義的目標量度。
目標量度 target-metrics
量度可用來定義網站品質的量化測量 — 基本上，這些量度是您要達成之效能目標的定義，可用來定義您的 KPI（關鍵績效指標）.
有許多量度可定義，但您定義的量度通常涵蓋效能和並行性目標。 尤其是難以量化，而且往往容易被 情感 評估：
-
「我們的網站 太慢了 今天，什麼時候 慢慢 合格？
-
「一切」 停了下來 當我的同事登入時」 — 系統可支援多少同時使用者？
-
「當我搜索時，系統 停了下來 「 — 哪種搜索請求正在影響系統？
-
「它需要 年齡 要下載檔案，「 — 可接受的下載時間（在正常網路條件下）是多少？
目標量度是在專案開始時定義，以：
- 指出您要提供的網站的預期維度
- 指定要達到的最低質量
- 定義這些因素的實際測量方式
- 作為 關鍵績效指標
定義目標量度時，請務必小心：
- 如果太高，可能完全無法實現
- 如果設定為過低波動，則不能突出顯示
- 以確保可重複及一致地測量
- 以平衡所測量的不同因素
- 某些量度會與測試環境相關，但有些量度應反映實際情況，因為它們必須可測量，且可重複，在您的生產網站上
- 根據量度對網站的重要性排列量度的優先順序
- 將量度限制為可實際監控的集合
在開發專案期間，可視需要更新及調整。 項目成功實施後，它們可用於幫助您控制安裝，並監視/維護持續操作所需的服務級別。
若正確使用，這些量度可提供實用工具；如果不負責任地使用，它們可能會浪費時間分散注意力。 和往常一樣，你需要了解自己在衡量什麼，如何衡量它，以及為什麼。
一切取決於您的專案設計 everything-rests-on-your-project-design
所有要測量的量度，在某種程度上會受到專案設計的影響。 反之，許多問題最好通過設計變更來解決。
因此，您應定義目標量度 befor 決定你的設計。 這可讓您根據這些因素來最佳化設計。 專案一經開發，就很難對基本設計原則進行任何變更。
建立網站結構時，請遵循AEM網站的建議結構。 請務必了解下列問題和/或原則：
- 如何建構網站內容。
- 範本和元件的運作方式。
- 快取的運作方式。
- 個人化內容的影響。
- 搜尋功能的運作方式。
- 如何使用CSS和相關技術來建立緊湊、非重複的HTML程式碼。
如果您覺得您的設計不符合准則，或如果您不確定其中的某些含意，請在開始程式設計階段或填寫內容之前先釐清這些問題。
基礎設施 infrastructure
要定義或評估基礎架構，將有助於定義目標值，例如：
- 訪客/日；平均和峰值
- 點擊/日；平均和峰值
- 可供使用的網頁數
- 網頁內容量
這將幫助您評估和選擇您的基礎架構，具體取決於您的情況和網站的戰略意義：
- 伺服器數
- AEM例項數（製作和發佈）
效能 performance
可評估的效能因素有數個：
-
個別頁面的回應時間，已考慮：
- 製作環境的回應時間
- 發佈環境的回應時間
-
搜尋請求的回應時間
本節可與 效能最佳化 擴展了實際測量效能的技術細節。
個別頁面的回應時間 response-times-for-individual-pages
一個主要問題是您的網站回應訪客請求所花的時間。
雖然此值會因每個請求而異，但可定義平均目標值。 一旦此值經證實可達且可維護，即可用來監控網站的效能並指出潛在問題的發展
製作和發佈環境上的不同目標
您要針對的回應時間在製作和發佈環境中會有所不同，反映目標對象：
-
製作環境
此環境供輸入及更新內容的作者使用，因此必須：
- 適用於更新內容頁面和這些頁面上的個別元素時，產生大量請求的少數使用者
- 盡可能快地提高他們將您的內容發佈到您網站的生產力
-
發佈環境
此環境包含您可供使用者使用的內容：
-
速度仍然重要，但通常比製作環境慢
-
經常採用其他效能增強機制：
- 快取內容
- 已應用負載平衡
-
設定目標回應時間 setting-target-response-times
那麼，如何決定可達（平均）的回應時間？ 這通常是經驗問題：
- 網站的過去體驗
- AEM體驗
- 識別回應時間超過平均的複雜頁面（如有可能，應個別最佳化）
但是，（在受控情況下）可採用以下准則：
- 70%的頁面要求應在100毫秒內回應。
- 25%的頁面要求應在100毫秒至300毫秒內回應。
- 4%的頁面要求應在300毫秒至500毫秒內回應。
- 1%的頁面要求應在500ms-1000ms內回應。
- 任何頁面的回應速度都不應低於1秒。
上述數字假設下列條件：
- 在發佈時測量（無製作環境和/或CFC開銷）
- 在伺服器上測量（無網路開銷）
- 未快取(無AEM輸出快取、無Dispatcher快取)
- 僅適用於具有許多相依性的複雜項目(HTML、JS、PDF、…)
- 系統上沒有其他負載
您可使用數種機制來監控回應時間：
-
使用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
搜尋請求 search-requests
搜尋請求對您的網站可能有重大影響，包括：
-
實際搜索的響應時間
- 快速搜尋功能是您網站的品質目標
-
對一般效能的影響
- 由於搜索功能必須掃描（可能很大）內容的部分，或是特別提取的索引，因此，如果不優化，這可能會影響整個系統的效能
設定搜尋請求的目標，同樣取決於體驗：
- AEM體驗
- 與其他目標相比，評估搜索的使用頻率
- 您的持續性管理器
- 搜索索引
- 搜索函式的複雜性；僅允許輸入1個搜索詞的基本搜索功能比允許用戶使用AND/OR/NOT建立複雜搜索語句的高級搜索更快。
從您的專案開始，就應規劃並整合這些功能。 可用於監測的機制包括：
並行 concurrency
您的網站將可在製作和發佈環境中供許多使用者/訪客使用。 測試時，數字通常比您所用的要多，但也會波動，難以預測。 您的網站需要針對平均同時使用者/訪客人數而設計，而不需注意到負面效能影響。 再次 request.log 可進行併發測試；請參閱 效能最佳化 以取得更多詳細資訊。
同時使用者人數的目標取決於環境類型：
-
製作環境
- 通常可準確估計同時使用的使用者人數。 您會知道總共有多少位作者，但（可能）並非所有作者都會同時作用。
-
發佈環境
- 這較難預測，因此您必須選取目標值。 這應該以您目前網站的體驗，以及您新網站的實際期望為基礎。
- 特殊事件（例如，當您發佈新的、非常受歡迎的內容時）可能超出預期，甚至超出功能（如某些事件的票證可供銷售時，媒體有時會報導）。
容量和容量 capacity-and-volume
討論相關量度前，請先快速定義下列詞語：
-
卷
- 系統處理和傳送的輸出量。
-
容量
- 系統傳送卷的能力。
- 在每個步驟中，容量和容量的測量方式都不同，如下表所示。 為獲得最佳效能，請確保每個步驟的容量與卷匹配，並且所有步驟都共用容量和卷。 例如，您可以在客戶端電腦上計算導航，或將其放入快取中，而不必針對每個請求在伺服器上計算導航。
-
容量和容量
table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 7-row-3 什麼/位置 容量 卷 用戶端 用戶電腦的計算能力。 頁面配置的複雜性。 網路 網路頻寬。 頁面大小（程式碼、影像等）。 Dispatcher快取 Web伺服器的伺服器記憶體（主記憶體和硬碟）。 Web伺服器（主記憶體和硬碟）。 快取頁數和大小。 輸出快取 AEM伺服器的伺服器記憶體（主記憶體和硬碟）。 輸出快取中的頁數和大小、每頁的相依性數。 Dispatcher快取會降低此卷。 網頁伺服器 Web伺服器的計算能力。 請求數量。 快取會降低此卷。 範本 Web伺服器的計算能力。 範本的複雜度。 存放庫 儲存庫的效能。 從儲存庫載入的頁數。
其他量度 other-metrics
前幾節詳細說明要定義的主要量度。
視您的特定需求而定，單獨定義其他量度或將上述分類納入考量，可能會很實用。
不過，建議您提供一組精確且可靠運作的核心量度，而不要嘗試測量和定義網站的每個層面。 您的網站純粹是由於其性質，一旦交給您的使用者，就會開始變更和發展。
安全性 security
安全至關重要，而且是一個日益嚴峻的挑戰。 It 必須 從專案的最初階段開始加以考量和規劃。
此 安全性檢查清單 詳細說明您應採取的步驟，以確保部署時的AEM安裝安全無虞。 其他安全方面在 安全性（開發時） 和 使用者管理與安全性.
並行和迭代任務 parallel-and-iterative-tasks
對於標準AEM專案的新實作，您需要考慮下列工作：
- 從銷售流程切換。
- 客戶應用程式的實作(開發)。
- 在客戶站點(基礎設施)。
- 建立（或移轉）內容(內容)。
- 切換至操作(維護/支援)。
- 後續發行。
建議在所有方面使用迭代方法：
每個類別的注意事項有：
-
開發
-
首先定義基礎架構。
-
使用數個迭代(sprint)進行開發：
- 首次衝刺相當於第一個完整開發週期。
- 首次衝刺將生成對測試環境的首次部署。
- 每次衝刺都有跑步結果。
- 每次衝刺都會獲得客戶簽核（具有反饋的結構化測試的最小值）。
-
針對專案期間可用AEM版本的最終更新進行規劃。
-
在短跑期間規劃測試和最佳化。
-
穩定化和最佳化階段計畫。
-
建立要計畫供進一步發行的項目記錄。
-
合作夥伴參與和移交計畫。
-
-
基礎設施
-
首先定義基本架構：
- 定義效能需求。
- 定義績效目標（即明確定義期望）。
- 定義硬體和基礎架構體系結構；包括大小調整。
- 定義部署。
-
使用數個迭代；對於第一個sprint和初始配置準備：
- 開發環境。
- 開發程式。
- 測試環境。
- 部署過程（包括配置管理）。
-
計畫多個負載測試。
-
在短跑期間規劃測試和最佳化。
-
穩定化和最佳化階段的計畫。
-
盡早部署至生產環境（讓營運團隊設定系統以獲得經驗）。
-
盡早使用指名的使用者和定義的角色。
-
計畫培訓（例如，管理員培訓）。
-
計畫移交給行動。
-
-
內容
-
基本架構：
- 推動內容階層。
- 有助於定義內容概念。
- 定義MSM使用和配置。
- 定義角色、群組、工作流程和權限。
-
請考慮離線頁面建立是否有用。
-
規劃搶先建立第一個頁面和內容（以用於測試和意見回饋）。
-
規劃現有內容的移轉。
-
重構後規劃「in-sprint-migration」。
-
計畫「內容燃起」（上線內容的Sitemap）。
-
預估時間和工作量 estimating-time-and-effort
然後，您可以根據生成的任務清單對（高級）任務定義的時間和工作量進行初始估計。 這些應包括指出將由誰（客戶或合作夥伴）做什麼以及何時做什麼。
下清單顯示了標準近似值和所涉工作的相互關係，因此也包括成本：
然後，詳細規劃可將可用或所需資源與截止日期和成本相關。
參考架構 reference-architecture
參考架構旨在為AEM架構提供範本解決方案。 該參考體系結構解決了企業系統經常遇到的問題，包括擴展、可靠性和安全性。
應定義下列網站量度：
潛在工具概觀 overview-of-potential-tools
提供下列清單，通知您可使用的工具。 這是作為簡介，而非廣泛的建議清單，當然不應阻礙您使用您偏好的任何其他工具。
延伸閱讀 further-reading
此外，以下幾節特別感興趣：