清单 — 进一步参考 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
要定义或评估基础架构，它有助于定义目标值，例如：
- 访客数/天；平均值和峰值
- 点击量/日；平均值和峰值
- 可用的网页数量
- web内容量
根据您的情况以及网站的战略意义，定义基础架构可以帮助您评估和选择基础架构：
- 服务器数
- AEM实例数（创作和发布）
性能 performance
有几个性能因素可供评估：
-
单个页面的响应时间，包括：
- 创作环境的响应时间
- 发布环境的响应时间
-
搜索请求的响应时间
可以通过性能优化读取此部分，该部分扩展了实际测量性能的技术详细信息。
单个页面的响应时间 response-times-for-individual-pages
关键问题是网站响应访客请求所用的时间。
尽管该值因每个请求而异，但可以定义平均目标值。 一旦证实该值既可实现，又可维护，就可使用它来监控网站的性能，并指示潜在问题的发展
创作环境和发布环境中的不同目标
您针对的响应时间在创作环境和发布环境中有所不同，反映了目标受众的情况：
-
创作环境
此环境由输入和更新内容的作者使用，因此它必须：
- 适合在更新内容页面和这些页面上的单个元素时生成大量请求的少数用户
- 尽可能快地最大限度地提高将您的内容放到网站上的工作效率
-
Publish环境
此环境包含可供用户使用的内容：
-
速度仍然至关重要，但通常比创作环境慢
-
通常采用其他性能增强机制：
- 内容已缓存
- 应用负载平衡
-
设置目标响应时间 setting-target-response-times
如何确定可实现的（平均）响应时间？ 问题的答案往往与经验有关：
- 网站体验
- 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
搜索请求 search-requests
搜索请求可能会对您的网站产生重大影响，因为以下两方面均可能：
-
实际搜索的响应时间
- 快速搜索功能是您网站的质量目标
-
对一般性能的影响
- 由于搜索功能必须扫描（潜在较大的）部分内容或专门提取的索引，因此，如果不进行优化，此功能可能会影响整个系统的性能
同样，设置搜索请求的目标也是个经验问题，具体取决于：
- AEM的体验
- 与其他目标相比，使用搜索频率的评估
- 您的持久性管理员
- 您的搜索索引
- 搜索功能的复杂性；基本搜索功能允许输入一个搜索词，比高级搜索更快，高级搜索允许用户使用AND/OR/NOT构建复杂的搜索语句。
这些搜索请求应从项目的一开始就进行规划和集成。 可用于监测的机制包括：
并发 concurrency
在创作环境和发布环境中使您的网站对某些用户和访客可用。 这些数字通常比您在测试时所使用的要多，但也会出现波动且难以预测。 为平均数量的并发用户和访客设计网站，但不考虑对性能产生负面影响。 再次使用request.log进行并发测试。 有关详细信息，请参阅性能优化。
并发用户数量的目标取决于环境类型：
-
创作环境
- 通常可以准确估计并发用户的数量。 您可以了解总共有多少位作者，但（可能）并非所有作者同时处于活动状态。
-
Publish环境
- 预测发布环境更具挑战性，因此您必须选择目标值。 同样，它应该基于您当前网站的经验以及您新网站的现实期望。
- 特殊活动（例如，当您发布新的热门内容时）可能会超出预期，甚至超出功能（当某些活动的门票可供出售时，媒体有时会报道过这种情况）。
容量和卷 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服务器的计算能力。 请求数。 缓存功能会降低此数量。 模板 Web服务器的计算能力。 模板的复杂性。 存储库 存储库的性能。 从存储库加载的页数。
其他量度 other-metrics
前几节详细介绍了要定义的主要量度。
根据特定要求，单独定义其他指标或考虑上述分类可能对您有用。
但是，与其尝试测量和定义网站的每个方面，不如使用一组易于使用且可靠的精确核心量度。 从本质上看，您的网站在移交给用户后会开始发生更改和演变。
安全性 security
安全是至关重要的，也是日益严峻的挑战。 必须 从项目的最初阶段开始考虑和计划。
安全核对清单详细说明了为确保您的AEM安装在部署时安全而应采取的步骤。 其他安全性方面包含在安全性（开发时）和用户管理和安全性中。
并行和迭代任务 parallel-and-iterative-tasks
对于标准AEM项目的新实施，请考虑以下任务：
- 从Sales流程移交。
- 客户应用程序的实现（开发）。
- 在客户站点（基础架构）上安装和配置基础架构（及相关流程）。
- 创建（或迁移）内容（内容）。
- 切换到操作（维护/支持）。
- 跟进发行。
对于所有方面，建议使用迭代方法：
每个类别需要注意以下几点：
-
开发
-
首先定义基本架构。
-
使用多个迭代（冲刺）进行开发：
- 第一个冲刺相当于第一个完整的开发周期。
- 首次冲刺导致首次部署到测试环境。
- 每一次冲刺都有一个可运行的结果。
- 每个冲刺都会获得客户认可（带有反馈的结构化测试的最小值）。
-
规划在项目期间更新可用AEM版本的可能性。
-
规划冲刺期间的测试和优化。
-
规划稳定和优化阶段。
-
创建要计划用于后续版本的物料日志。
-
规划合作伙伴参与和移交事宜。
-
-
基础架构
-
首先定义基本架构：
- 定义性能要求。
- 定义绩效目标（即明确定义预期）。
- 定义硬件和基础架构体系结构，包括规模调整。
- 定义部署。
-
使用多个迭代；对于第一个冲刺和初始配置，准备：
- 开发环境。
- 开发过程。
- 测试环境。
- 部署过程（包括配置管理）。
-
规划多个负载测试。
-
规划冲刺期间的测试和优化。
-
规划稳定和优化阶段。
-
尽早部署到生产环境（让运营团队设置系统以获得体验）。
-
尽早使用指定用户和定义的角色。
-
规划培训（例如，管理员培训）。
-
计划移交给操作。
-
-
内容
-
基本体系结构：
- 驱动内容层次结构。
- 帮助定义内容概念。
- 定义MSM使用和布局。
- 定义角色、组、工作流和权限。
-
考虑离线页面创建是否有用。
-
计划提前创建第一页和内容（用于测试和反馈）。
-
规划现有内容的迁移。
-
在重构后规划“in-sprint-migration”。
-
规划“内容燃尽”（用于上线内容的站点地图）。
-
估计时间和工作 estimating-time-and-effort
根据生成的任务列表，您可以对（高级）任务定义的时间和工作量进行初始估计。 这些估计应包括指示谁（客户或合作伙伴）在何时做什么。
以下列表显示了相关工作的标准近似和相互关系，因此也显示了成本：
然后，详细规划可以将可用或所需资源与截止日期和成本相关联。
参考架构 reference-architecture
该参考体系结构为AEM体系结构提供了一个模板解决方案。 该参考体系结构解决了企业系统经常遇到的问题，包括可扩展性、可靠性和安全性。
应定义以下网站量度：
潜在工具概述 overview-of-potential-tools
以下列表为您提供了可以使用的工具。 它旨在作为介绍，而不是广泛的推荐列表，并且不应阻止您使用任何其他工具。
深入阅读 further-reading
此外，以下部分也特别令人感兴趣：