檢查清單 — 進一步參考 the-checklist-further-reference
本頁提供進一步詳細資訊，以詳細說明及/或擴充 管理專案 — 最佳實務檢查清單.
AEM — 您要使用什麼？ aem-what-will-you-be-using
AEM的功能 features-within-aem
實作AEM （尤其是第一次）時，請檢閱 AEM的功能和工作流程 以確定您想要或需要的區域。
請考量您使用的AEM功能及其對設計的影響；例如：
此外，請檢視 發行說明，以瞭解各種AEM版本何時新增了任何新功能。
整合 integrations
AEM可與其他Adobe產品、協力廠商服務或兩者整合。 這些工作流程可增加您掌握的能力和功能。
另請參閱 解決方案整合 以取得完整資訊。
要移轉或升級嗎？ migrate-or-upgrade
主要考量事項為您是否想要：
- 升級現有安裝。
- 將內容從目前系統移轉到全新的安裝。
從舊版移至目前版本時，有兩個選項：
基本基本規則 basic-ground-rules
和任何專案一樣，必須儘快建立基本規則。 這些規則包括：
-
角色
角色應清楚定義，並告知專案中涉及的每個人。 此外，建議強調下列事項：
- 決策者
- 聯絡點
-
責任
- 針對每個角色，清楚定義與專案相關的責任，有助於避免混淆。
-
參與
透過儘快讓利害關係人參與，您可以鼓勵他們成為 利害關係人 在專案中。 這麼做可提升他們對公司成功的承諾。
- 在客戶方面，此角色包括處理系統日常工作的作者
- 在您自己的專案團隊中，參與的人員還包括負責品質保證的人員。 他們越瞭解客戶的需求，就越能規劃測試。
-
通訊路徑
- 雖然溝通路徑不應過度正規化，但特定定義應確保關鍵人物始終得到通知並因而保持最新。 應特別注意與外部各方的溝通。
-
程式
定義的流程取決於您的個別專案。 再次強調，請儘量讓這些程式保持簡單，並考量以下事項：
- 定義與任何第三方互動的流程（和通訊路徑）；例如，設計機構和第三方軟體供應商等。
- 客戶通常有自己的專案管理和報告程式與工具。
-
追蹤工具
有許多工具可用來追蹤有關錯誤、任務和專案其他方面的資訊 — 請參閱 潛在工具概觀 以取得更多詳細資料。
- 這裡要注意的關鍵點在於僅保留一份資訊並共用資訊（因此存取所使用的工具）。 此工作流程可簡化維護作業，並有助於防止不一致情形。
-
範圍
清楚定義專案在不同層級的涵蓋範圍：
- 個別發行（若使用反複發行程式，無論是否提供給客戶或內部測試團隊）。
- AEM專案。
- 整個專案；包括任何協力廠商軟體、它們對測試的影響、組織問題和其他許多問題。
- 對於某些方面，陳述以下內容可能也會很有用 非 在專案範圍內。 此想法有助於防止混淆和錯誤的假設，但應僅限於基本問題。
-
報告
清楚定義您要以何種形式、頻率及向誰報告的資訊。
-
術語
- 定義要使用的任何縮寫和/或客戶特定術語。
-
假設
- 定義所做的任何假設。
此資訊可在專案手冊中定義；使用Wiki也可協助確保持續變更得到有效處理。 無論這些假設在何處定義，關鍵因素包括：
- 資訊已定義並維護
- 資訊會清楚傳達給所有相關人員。 雖然標準的專案管理作法，但清楚的角色定義和良好的溝通可達成或中斷專案，這樣的反複頻率是無法接受的。
- 對於任何受到追蹤的資訊，只會保留一個版本；例如，錯誤追蹤和問題追蹤。
關鍵績效指標與目標量度 key-performance-indicators-and-target-metrics
組織可使用關鍵績效指標(KPI)來評估達成目標的成功程度。 這些指標是可測量的值，可用來顯示達成特定目標的效率。
這些指標可以是：
-
企業：
- 用於測量關鍵業務目標。
- 請務必選擇適合您業務/情境的KPI，並清楚定義其內容、測量方式、使用方式及使用對象。
-
效能：
- 定義如何測量系統效能。
- 某些範例包括頁面載入時間、伺服器回應時間和資料庫查詢效能。
部分（但不是全部）指標可以您所識別和定義的目標量度為基礎。
目標量度 target-metrics
量度可用來定義網站品質的量化度量。 基本上，這些是您要達成之效能目標的定義，並可用來定義您的 KPI （關鍵績效指標）.
您可以定義許多量度，但您定義的量度通常會涵蓋效能和並行度的目標。 尤其是難以量化且容易出現下列問題的因素 情緒化 評估：
-
「網站是 太慢 今天」 — 何時會 慢 符合資格？
-
「全部 磨得嘎嘎作響 我的同事登入時」 — 系統可同時支援多少位使用者？
-
「當我搜尋時，系統 磨得嘎嘎作響 「 — 哪些搜尋要求會影響系統？
-
「需要 年齡 下載檔案」 — 可接受的下載時間是多少（在一般網路條件下）？
目標量度是在專案開始時定義的，用於：
- 表示您可以提供之網站的預期維度
- 指定您要達到的最低品質
- 定義這些因子的測量方式
- 用作 關鍵績效指標
定義目標量度時，務必謹慎：
- 如果設定得太高，則可能無法實現
- 如果設定得太低，可能不會反白波動
- 確保可重複且一致地測量這些值
- 提供不同測量因素間的平衡
- 某些量度與測試環境有關，但某些量度應反映真實情境，因為它們必須在您的生產網站上可測量且可重現
- 根據量度對網站的重要性來排列量度的優先順序
- 將測量結果限制在可以監視的集合
在專案開發期間，可視需要更新和調整。 成功實作專案後，它們可用於協助您控制安裝，並監控/維護進行中作業所需的服務等級。
正確使用量度可提供有用的工具；若不負責任地使用，可能會浪費時間。 一如既往，瞭解您測量的內容、測量方式及原因。
一切取決於您的專案設計 everything-rests-on-your-project-design
所有測量的量度都會受到專案設計的影響。 相反地，許多問題最好透過設計變更來解決。
因此，請定義您的目標量度 早於 決定您的設計。 如此可讓您根據這些因素最佳化設計。 專案開發後，基本設計原則就變得富有挑戰性。
當您建立網站的結構時，請遵循AEM網站的建議結構。 請務必瞭解下列問題和/或原則：
- 如何建構網站內容。
- 範本和元件的運作方式。
- 快取如何運作？
- 個人化內容的影響。
- 搜尋功能的運作方式。
- 如何使用CSS和相關技術來建立緊湊、非備援的HTML程式碼。
如果您認為您的設計未遵循准則，或您不確定其中某些影響，請澄清這些問題。 在開始程式設計階段或填寫內容之前，請先執行此作業。
基礎架構 infrastructure
若要定義或評估基礎結構，有助於定義目標值，例如：
- 訪客數/天；平均值和尖峰
- 點選/天；平均和尖峰
- 可供使用的網頁數目
- 網頁內容量
根據您的情況和網站的策略重要性，定義基礎結構可以協助您評估和選擇您的基礎結構：
- 伺服器數目
- AEM例項數目（製作和發佈）
效能 performance
有幾個效能因素可供評估：
-
個別頁面的回應時間，包括：
- 作者環境的回應時間
- 發佈環境的回應時間
-
搜尋要求的回應時間
本節內容可透過以下方式閱讀： 效能最佳化 這進一步擴展了實際測量效能的技術細節。
個別頁面的回應時間 response-times-for-individual-pages
關鍵問題是您的網站回應訪客要求所需的時間。
雖然此值會因每個請求而有所不同，但您可以定義平均目標值。 一旦這個值被證實既可達到又可維持，就可用來監視網站的效能並指示潛在問題的發展
製作和發佈環境的不同目標
您針對的回應時間在製作和發佈環境中不同，反映了目標對象：
-
作者環境
作者會使用此環境來輸入和更新內容，因此它必須：
- 適合在更新內容頁面和這些頁面上的個別元素時產生大量請求的少數使用者
- 儘快將您的內容帶入網站，以發揮最大生產力
-
發佈環境
此環境包含您提供給使用者使用的內容：
-
速度仍然很重要，但通常比製作環境慢
-
通常會套用其他效能增強機制：
- 內容已快取
- 已套用負載平衡
-
設定目標回應時間 setting-target-response-times
如何決定可達成的（平均）回應時間？ 問題和答案通常取決於經驗：
- 在您網站上的體驗
- AEM使用體驗
- 識別具有超過平均回應時間的複雜頁面（如果可能，應個別最佳化這些頁面）
但在受控情況下，可套用下列准則：
- 70%的頁面要求應在100毫秒內回應。
- 25%的頁面要求應在100毫秒至300毫秒內回應。
- 4%的頁面要求應在300ms-500ms以內回應。
- 1%的頁面要求應在500ms-1000ms內回應。
- 沒有任何頁面的回應速度應小於1秒。
上述數字假設以下條件：
- 在發佈時測量（沒有製作環境和/或CFC額外負荷）
- 在伺服器上測量（沒有網路負荷）
- 未快取(無AEM輸出快取，無Dispatcher快取)
- 僅適用於具有許多相依性的複雜專案(HTML、JS、PDF…)
- 系統上沒有其他載入
您有數個機制可用來監控回應時間：
-
使用AEM request.log監控回應時間
要求記錄檔是效能分析的良好起點。 除了其他資訊，您可以檢視個別請求的回應時間。 另請參閱 效能最佳化 以取得更多詳細資料。
-
使用HTML註解監控回應時間
HTML註解可用來在每個頁面的來源中包含回應時間資訊：
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
搜尋請求 search-requests
搜尋請求可能會對您的網站造成重大影響，因為兩者皆有：
-
實際搜尋的回應時間
- 快速搜尋功能是您網站的品質目標
-
對一般效能的影響
- 由於搜尋功能必須掃描（潛在大量）內容區段或特別擷取的索引，若未最佳化，此功能可能會影響整個系統的效能
設定搜尋要求的目標同樣是體驗的問題，具體取決於：
- AEM的體驗
- 與其他目標比較下使用搜尋的頻率評估
- 您的持續性管理員
- 您的搜尋索引
- 您搜尋功能的複雜性；允許輸入一個搜尋字詞的基本搜尋功能，比允許使用者使用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伺服器的伺服器記憶體（主記憶體和硬碟）。 網頁伺服器（主記憶體和硬碟）。 快取頁面的數目和大小。 輸出快取 AEM伺服器的伺服器記憶體（主記憶體和硬碟）。 輸出快取中的頁數與大小，每頁的相依性數目。 Dispatcher快取會降低此磁碟區。 網頁伺服器 Web伺服器的運算能力。 要求數目。 快取會降低這個數量。 範本 Web伺服器的運算能力。 範本的複雜性。 存放庫 存放庫效能。 從存放庫載入的頁數。
其他量度 other-metrics
前幾節詳細說明要定義的主要量度。
根據您的特定需求，單獨定義其他量度或說明上述分類可能會對您有所助益。
不過，與其嘗試測量和定義網站的各個層面，不如擁有一組功能輕鬆可靠的精確核心量度。 您的網站從本質上講在移交給使用者後會開始改變和演化。
安全性 security
安全性至關重要，也是一項日益嚴峻的挑戰。 It 必須 會從專案的最初階段開始考量及規劃。
此 安全性檢查清單 詳細說明在部署時，您應採取的步驟以確保您的AEM安裝安全。 其他安全性方面則包含在 安全性（開發時） 和 使用者管理與安全性.
平行和反複任務 parallel-and-iterative-tasks
對於標準AEM專案的新實作，請考慮以下任務：
- 從銷售處理移轉。
- 客戶應用程式的實作(開發)。
- 在客戶場所安裝及設定基礎建設（及相關程式） (基礎架構)。
- 建立（或移轉）內容(內容)。
- 切換至作業(維護/支援)。
- 後續發行。
在所有方面，建議使用反複的方法：
每個類別需要注意以下幾點：
-
開發
-
先定義基礎架構。
-
使用數個反複專案（衝刺）進行開發：
- 第一個衝刺相當於第一個完整開發週期。
- 第一個快速衝刺會產生第一個部署到您的測試環境的結果。
- 每個衝刺都有可執行的結果。
- 每個短衝刺都會獲得客戶認可（具有意見回饋的結構化測試下限）。
-
針對專案期間可用AEM版本更新的可能性進行規劃。
-
在衝刺期間規劃測試和最佳化。
-
規劃穩定與最佳化階段。
-
建立未來發行計畫專案的記錄。
-
規劃合作夥伴參與和移交。
-
-
基礎架構
-
先定義基本架構：
- 定義效能需求。
- 定義效能目標（亦即明確定義期望）。
- 定義硬體與基礎架構架構，包括規模調整。
- 定義部署。
-
使用數個反複專案；對於第一個衝刺和初始組態準備：
- 開發環境。
- 開發流程。
- 測試環境。
- 部署程式（包括設定管理）。
-
規劃數個負載測試。
-
在衝刺期間規劃測試和最佳化。
-
規劃穩定與最佳化階段。
-
儘早部署到生產環境（讓營運團隊設定系統以獲得體驗）。
-
儘早使用指名的使用者和定義的角色。
-
規劃培訓（例如管理員培訓）。
-
計畫切換至作業。
-
-
內容
-
基礎架構：
- 驅動內容階層。
- 協助定義內容概念。
- 定義MSM使用和配置。
- 定義角色、群組、工作流程和許可權。
-
考慮建立離線頁面是否有用。
-
規劃儘早建立第一頁和內容（用於測試和意見回饋）。
-
規劃現有內容的移轉。
-
重構後的「sprint-migration」計畫。
-
計畫「內容待執行工作」（上線內容的網站地圖）。
-
預估時間和精力 estimating-time-and-effort
根據您產生的任務清單，您可以針對（高階）任務定義進行時間與投入的初步預估。 這些估計應包括指示誰（客戶或合作夥伴）做什麼和何時做。
下列清單顯示相關工作的標準近似和相互關係，因此也顯示成本：
然後詳細計畫就可以將可用或所需資源與截止日期和成本相關聯。
參考架構 reference-architecture
提供的參考架構可提供AEM架構的範本解決方案。 參考架構可解決企業系統經常遇到的問題，包括擴充性、可靠性和安全性。
應定義下列網站量度：
潛在工具概觀 overview-of-potential-tools
下列清單會告知您可用的工具。 其目的是作為介紹，而不是廣泛的建議清單，並且不應阻止您使用任何其他工具。
延伸閱讀 further-reading
此外，以下章節也是特別值得關注的：
最佳做法 best-practices
Adobe為所有階段和受眾提供進一步的最佳實務：