清单 — 进一步参考
本页提供了进一步的详细信息，以详细阐述和/或扩大管理项目 — 最佳实践核对清单所涵盖的文档和原则。
AEM — 您将使用什么？
CAUTION此外，对于各种AEM版本，请查看发行说明以了解何时添加了任何新功能。
集成
AEM可以与其他Adobe产品、第三方服务或两者集成。 这些工作流可以增加您能够使用的功能和能力。
有关完整信息，请参阅解决方案集成。
是否迁移或升级？
主要考虑事项是您想要：
- 就地升级现有安装。
- 将内容从当前系统迁移到全新安装。
从以前的版本移动到当前的版本时，有两个选项：
基本基本基本规则
与任何项目一样，尽快制定基本规则至关重要。 这些规则包括：
NOTE-
角色
应明确定义角色，并使参与项目的每个人都知道这些角色。 此外，建议重点强调：
- 决策者
- 联系点
-
责任
- 对于每个角色，清晰定义与项目相关的责任有助于防止混淆。
-
参与
通过尽快吸引相关方参与，您可以鼓励他们成为项目中的 利益相关者。 这样做增加了他们对其成功的承诺。
- 在客户方面，此角色包括日常使用系统的作者
- 在您自己的项目团队中，这种参与还包括负责质量保证的人员。 他们越了解客户的需求，就越能更好地规划测试。
-
通信路径
- 虽然沟通途径不应过度正规化，但具体的定义应确保关键人物始终了解情况，从而了解最新情况。 应特别注意与外部各方的沟通。
-
个进程
定义的流程取决于您的单个项目。 同样，请尽量简化这些流程，同时考虑：
- 定义用于与任何第三方进行交互的流程（和通信路径）；例如，设计机构和第三方软件供应商等。
- 客户通常有自己的项目管理和报告过程和工具。
-
跟踪工具
有许多工具可用于跟踪有关错误、任务以及项目其他方面的信息 — 有关更多详细信息，请参阅潜在工具概述。
- 这里要注意的关键点是，只保留信息的一个副本，并共享信息（因此可以访问正在使用的工具）。 此工作流可简化维护并有助于防止出现差异。
-
范围
在各级明确界定项目涵盖的内容：
- 单个版本（如果使用迭代发布流程，且无论它们是交付给客户还是内部测试团队）。
- AEM项目。
- 整个项目；包括任何第三方软件、它们对测试的影响、组织问题以及许多其他问题。
- 对于某些方面，在项目范围内声明 而非 也很有用。 这种想法有助于防止混淆和错误假设，尽管应限于基本问题。
-
报表
清楚地定义您要报告的信息、信息的形式、频率以及向谁报告。
-
术语
- 定义要使用的任何缩写和/或特定于客户的术语。
-
假设
- 定义所做的任何假设。
此信息可在项目手册中定义；使用Wiki还有助于确保有效处理正在进行的更改。 定义该等假设时，主要因素为：
- 定义和维护信息
- 信息将明确地传达给所有相关人员。 虽然项目管理是标准的实践，但清晰的角色定义和良好的沟通是无法重复的，不能制造或破坏一个项目。
- 对于任何要跟踪的信息，只保留一个版本；例如，错误跟踪和问题跟踪。
关键绩效指标和目标量度
组织使用关键绩效指标(KPI)来评估他们在实现目标方面的成功情况。 这些指标是可衡量的价值，可用于说明实现具体目标的实效。
这些指标可以是：
-
商业：
- 用于衡量关键业务目标。
- 选择适合您的业务/方案的KPI，并清楚地定义它们是什么、如何衡量、如何使用以及由谁使用它们，这一点很重要。
-
性能：
- 定义如何衡量系统性能。
- 一些示例包括页面加载时间、服务器响应时间和数据库查询性能。
部分（但不是全部）指标可以基于您识别和定义的目标指标。
目标量度
量度用于定义网站质量的量化度量。 它们基本上是您要实现的绩效目标的定义，可用于定义您的KPI（关键绩效指标）。
可以定义许多量度，但您定义的量度通常涵盖性能和并发性的目标。 特别是难以量化，且往往易于 情绪化 评估的因素：
-
“网站 太慢 今天” — 慢于 何时符合条件？
-
“当我的同事登录时，所有 都会暂停” — 系统可支持多少并发用户？
-
“当我搜索时，系统 陷入停止 ” — 哪些搜索请求正在影响系统？
-
“下载文件需要 时间” — 可接受的下载时间是多少（在正常网络条件下）？
目标量度是在项目开始时定义的，用于：
- 指示您可以提供的网站的预期维度
- 指明要达到的最低质量
- 定义如何衡量这些因素
- 用作关键绩效指标的基础
与往常一样，在定义目标量度时必须谨慎：
- 如果设置得过高，则可能无法实现
- 如果设置过低，可能不会突出显示波动
- 确保可反复且一致地衡量指标
- 在衡量的不同因素之间提供平衡
- 某些量度与测试环境相关，但某些量度应反映真实情景，因为它们必须在生产网站上测量并可重现
- 根据量度对网站的重要性排列量度的优先级
- 将度量限制为可以监视的集
在项目开发过程中，可以相应地更新和调整这些指标。 成功实施项目后，它们可用于帮助您控制安装并监控/维护日常操作所需的服务级别。
正确使用这些量度可以提供一个有用的工具；不负责任地使用这些量度可能会浪费时间。 与往常一样，了解您正在衡量的内容、如何衡量的内容及其原因。
NOTE一切都取决于您的项目设计
所有测量的量度都受项目设计的影响。 相反，许多问题最好通过设计更改来解决。
因此，在决定您的设计之前 定义您的目标指标。 这样做使您能够根据这些因素优化设计。 在项目开发后，对基本设计原则充满挑战。
在为网站创建结构时，请遵循为AEM网站推荐的结构。 确保您了解以下问题和/或原则：
- 如何构建网站内容。
- 模板和组件的工作方式。
- 缓存的工作原理是什么？
- 个性化内容的影响。
- 搜索功能的工作原理。
- 如何使用CSS和相关技术创建紧凑的非冗余HTML代码。
如果您觉得您的设计不遵循这些准则，或者您不确定某些影响，请澄清这些问题。 请在开始编程阶段或填写内容之前执行此操作。
基础架构
要定义或评估基础架构，它有助于定义目标值，例如：
- 访客数/天；平均值和峰值
- 点击量/日；平均值和峰值
- 可用的网页数量
- web内容量
根据您的情况以及网站的战略意义，定义基础架构可以帮助您评估和选择基础架构：
- 服务器数
- AEM实例数（创作和发布）
性能
有几个性能因素可供评估：
-
单个页面的响应时间，包括：
- 创作环境的响应时间
- 发布环境的响应时间
-
搜索请求的响应时间
可以通过性能优化读取此部分，该部分扩展了实际测量性能的技术详细信息。
单个页面的响应时间
关键问题是网站响应访客请求所用的时间。
尽管该值因每个请求而异，但可以定义平均目标值。 一旦证实该值既可实现，又可维护，就可使用它来监控网站的性能，并指示潜在问题的发展
创作环境和发布环境中的不同目标
您针对的响应时间在创作环境和发布环境中有所不同，反映了目标受众的情况：
-
创作环境
此环境由输入和更新内容的作者使用，因此它必须：
- 适合在更新内容页面和这些页面上的单个元素时生成大量请求的少数用户
- 尽可能快地最大限度地提高将您的内容放到网站上的工作效率
-
Publish环境
此环境包含可供用户使用的内容：
-
速度仍然至关重要，但通常比创作环境慢
-
通常采用其他性能增强机制：
- 内容已缓存
- 应用负载平衡
-
设置目标响应时间
如何确定可实现的（平均）响应时间？ 问题的答案往往与经验有关：
- 网站体验
- AEM使用体验
- 识别具有高于平均响应时间的复杂页面（如果可能，应单独优化这些页面）
但是，在受控情况下，可以应用以下准则：
- 70%的页面请求应在100毫秒内响应。
- 25%的页面请求应在100毫秒至300毫秒内响应。
- 4%的页面请求应在300ms-500ms内响应。
- 1%的页面请求应在500ms-1000ms内响应。
- 任何页面的响应速度都不应小于1秒。
上述数字假定满足以下条件：
- 在发布时测量（无创作环境和/或CFC开销）
- 在服务器上测量（无网络开销）
- 未缓存(无AEM-output缓存，无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
