Show Menu
主题×

清单——进一步参考

本页提供了进一步的详细信息,以详细说明和/或补充管理项目——最佳实 践清单所涵盖的文档和原则

AEM —— 您将使用什么?

本分节中的列表并非详尽无遗,而是作为介绍。

AEM中的功能

实施AEM时(尤其是第一次),您需要检查AEM 的功能和工作流 ,以确定您需要/需要哪些区域。
考虑您将使用的AEM功能以及对您的设计的影响;例如:
此外,请查 看发行说明 (针对不同版本的AEM),了解何时添加了任何新功能。

集成

AEM可以与其他Adobe产品和/或第三方服务集成。 这些功能可以增加您可以使用的功能。
有关完 整信息,请参阅 “解决方案集成”。

迁移还是升级?

一个主要考虑因素是您是否希望:
  • 升级现有安装。
  • 将内容从当前系统迁移到全新安装。
从先前版本移动到当前版本时,有两个选项:
  • 使用包 管理器 ,将旧系统中的所有内容和应用程序代码导出到新系统中。
  • 就地升级 ,旧系统即可升级。 在大多数情况下,建议选择此选项。

基本基本准则

与任何项目一样,尽快建立基本规则至关重要。 这些 Cookie 包括:
这些要点是通用的,最佳实践 清单涉及与AEM相关的具体细节
  • 角色
    这些内容应该得到明确界定,并应该向参与该项目的所有人公布。 此外,最好突出显示:
    • 决策者
    • 联系人
  • 职责
    • 对于每个角色,明确定义与项目相关的责任有助于防止混淆。
  • 参与
    通过尽快让感兴趣的方参与进来,您可以鼓励他们成为项目的 利益相关者 ,从而增加他们对项目成功的承诺。
    • 在客户方面,这包括作者——他们必须每天与系统一起工作。
    • 在您自己的项目团队中,这也将包括负责质量保证的人员。 他们越了解客户的要求,就越能规划测试。
  • 通信路径
    • 虽然这些问题不应过于正式化,但具体定义应确保关键人员始终得到通知,因此保持最新。 应特别注意与外部方的沟通。
  • 进程
    要定义的流程取决于您的单个项目。 再次尝试保持这些简单,同时考虑:
    • 定义与任何第三方交互的流程(和通信路径);例如,设计机构和第三方软件供应商等。
    • 客户通常会拥有自己的项目管理和报告过程和工具。
  • 跟踪工具
    有许多工具可用于跟踪有关项目缺陷、任务和其他方面的信息——有关更多详细信息,请 参阅潜在工具概述
    • 此处需要注意的要点是仅保留信息的一个副本并共享信息(因此,可访问所使用的工具)。 这将简化维护并帮助防止出现差异。
  • 范围
    明确了项目各级应涵盖的内容:
    • 单个版本(如果使用迭代版本流程,则无论是交付给客户还是您的内部测试团队)。
    • AEM项目。
    • 整个项目;包括任何第三方软件、它们对测试的影响、组织问题和许多其他问题。
    • 在某些方面,声明不在项目范 围内 ,也很有用。 这有助于防止混淆和错误假设,尽管这应该局限于基本问题。
  • 报告
    明确定义您将以何种形式报告哪些信息、报告频率和报告对象。
  • 术语
    • 定义要使用的任何缩写和/或客户特定术语。
  • 假设
    • 定义所作的任何假设。
这些信息可在项目手册中定义;使用Wiki还有助于确保有效处理正在进行的更改。 无论这些定义在哪里,关键因素都是:
  • 信息已定义和维护
  • 向所有相关人员清楚传达信息。 尽管标准的项目管理实践,但明确的角色定义和良好的沟通可能使项目成为或中断的项目,这已经不能经常重复。
  • 只保留一个版本的任何被跟踪信息;例如,错误跟踪、问题跟踪等。

关键绩效指标和目标指标

组织使用关键绩效指标(KPI)来评估其在达到目标方面的成功程度。 这些指标是可衡量的价值,可用于证明具体目标的实现效率。
这些指标可以是:
  • 企业:
    • 用于衡量关键业务目标。
    • 选择适合您的业务/方案的KPI非常重要,它们的定义清楚,包括它们是什么、如何衡量、如何使用以及由谁使用。
  • 演出:
    • 定义如何衡量系统的性能。
    • 一些示例包括页面加载时间、服务器响应时间和数据库查询性能。
某些(但并非全部)指标可以基于您识别和定义的目标指标。

目标指标

度量用于定义网站质量的定量度量——基本上,度量是您要实现的绩效目标的定义,可用于定义 KPI(关键绩效指标)
可以定义许多指标,但您定义的指标通常涵盖您的性能和并发目标。 特别是,可能难以量化、往往容易进行情绪评估的 因素 :
  • “我们的网站 现在太慢 ”-什么时候 才能 ?
  • “我的同 事登录时 ,一切都停了下来”-系统支持多少并发用户?
  • “当我搜索时,系统停 止了 ” —哪类搜索请求会影响系统?
  • “下载文 件需要 很长时间”-可接受的下载时间(在正常网络条件下)是多少?
目标指标在项目开始时定义为:
  • 指示您将提供的网站的预期维度
  • 指示要达到的最低质量
  • 定义这些因素的实际测量方式
  • 用作关键绩效指标 的基础
定义目标量度时必须始终注意:
  • 如果设置得太高,它们可能完全无法实现
  • 如果设置为过低的波动,则可能不会突出显示
  • 以确保他们能够反复、一致地衡量
  • 在测量的不同因素之间取得平衡
  • 某些指标将与测试环境相关,但某些指标应反映真实场景,因为它们必须在生产网站上可测量且可复制
  • 根据指标对网站的重要性对指标进行排序
  • 将度量限制在可以实际监视的集合中
在项目开发过程中,可以根据需要更新和调整它们。 项目成功实施后,它们可以帮助您控制安装并监控/维护持续操作所需的服务级别。
如果使用得当,这些指标可以提供有用的工具;如果用起来不负责任,它们可能是浪费时间的分散注意力。 和往常一样,您需要了解您所衡量的、如何衡量它以及为什么。
本节将讨论将审议的基本原则和问题。 每个安装都不同,因此要测量的实际值会不同。

一切都取决于您的项目设计

所有要衡量的指标都将在某种程度上受到项目设计的影响。 相反,许多问题最好通过设计更改来解决。
因此,您应在决定设计之前 定义 目标指标。 这使您能够根据这些因素优化您的设计。 项目一旦开发完成,将很难对基本设计原则进行任何更改。
创建网站结构时,请遵循AEM网站的推荐结构。 确保您了解以下问题和/或原则:
  • 如何构建网站内容。
  • 模板和组件的工作方式。
  • 缓存的工作方式。
  • 个性化内容的影响。
  • 搜索功能的工作方式。
  • 如何使用CSS和相关技术创建紧凑的、非冗余的HTML代码。
如果您认为您的设计不遵守准则,或者如果您不确定某些含义,请在开始编程阶段或填写内容之前澄清这些问题。

基础结构

要定义或评估基础架构,它将帮助定义目标值,例如:
  • 访客/日;平均和峰值
  • 点击/天;平均和峰值
  • 提供的网页数
  • Web内容量
这将根据您的情况和网站的战略重要性帮助您评估和选择基础架构:
  • 服务器数
  • AEM实例数(作者和发布)

演出

可以评估以下几个性能因素:
  • 单个页面的响应时间,请考虑:
    • 创作环境中的响应时间
    • 发布环境上的响应时间
  • 搜索请求的响应时间
此部分可与“性能优化”结合阅读, 性能优化 该优化扩展了实际测量性能的技术细节。

单个页面的响应时间

关键问题是网站响应访客请求所花费的时间。
尽管此值会因每个请求而异,但可以定义平均目标值。 一旦这一价值被证明是可实现的和可维护的,它就可以用于监控网站的性能并指示潜在问题的发展
创作和发布环境中的不同目标
在创作和发布环境中,您要针对的响应时间会有所不同,反映目标受众:
  • 创作环境
    此环境供输入和更新内容的作者使用,因此它必须:
    • 满足在更新内容页面和这些页面上的各个元素时生成大量请求的少数用户的需求
    • 尽可能快地最大化将内容发布到网站的工作效率
  • 发布环境
    此环境包含您向用户提供的内容:
    • 速度仍然至关重要,但通常比创作环境慢
    • 通常应用额外的性能增强机制:
      • 内容已缓存
      • 应用负载平衡

设置目标响应时间

那么,您如何决定可实现(平均)的响应时间? 这通常是个经验问题:
  • 您网站的过去体验
  • 体验AEM
  • 识别具有高于平均响应时间的复杂页面(如果可能,应单独优化这些页面)
但是,(在受控情况下)可以应用以下准则:
  • 70%的页面请求应在100毫秒内作出答复。
  • 25%的页面请求应在100ms-300ms内作出响应。
  • 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

搜索请求

在以下两方面,搜索请求都可能对您的网站产生显着影响:
  • 实际搜索的响应时间
    • 快速搜索功能是网站的质量目标
  • 对一般性能的影响
    • 由于搜索功能必须扫描(可能较大)内容部分或特别提取的索引,因此如果未进行优化,这可能会影响整个系统的性能
为搜索请求设置目标同样是一个体验问题,具体取决于:
  • AEM的体验
  • 评估与其他目标相比使用搜索的频率
  • 您的持久性管理器
  • 您的搜索索引
  • 搜索功能的复杂性;只允许输入1个搜索词的基本搜索功能比允许用户使用AND/OR/NOT建立复杂搜索语句的高级搜索要快。
这些应从项目开始就进行规划和集成。 可用于监控的机制包括:
  • 使用AEM request.log监视搜索响应时间
    同样,request.log可用于监控搜索请求的响应时间;有关更 多详细信息 ,请参阅性能优化。
  • 用于测量搜索响应时间的编程机构
    要自定义您收集的有关搜索请求的信息及其性能,建议将信息收集纳入您的项目源代码;有关更 多详细信息 ,请参阅性能优化。

并发

您的网站将在创作和发布环境中提供给许多用户/访客。 测试时,数据往往比您使用的要多,但也会波动,难以预测。 您的网站需要针对平均数的并发用户/访客进行设计,而不会注意到对性能造成负面影响。 同样, request.log 还可以用于并发测试;有关更 多详细信息 ,请参阅性能优化。
并发用户数的目标取决于环境类型:
  • 创作环境
    • 通常可以准确估计并发用户数。 您将知道您总共拥有多少个作者,但(可能)并非所有作者都同时处于活动状态。
  • 发布环境
    • 这更难预测,因此您必须选择一个目标值。 同样,这应该基于您当前网站的经验以及对新网站的现实期望。
    • 特殊活动(例如,当您发布新的、非常受欢迎的内容时)可能超出预期,甚至超出功能(某些活动的门票可供销售时,有时会在媒体上报告)。

容量和卷

在讨论相关指标之前,请快速定义这些术语:
    • 由系统处理和传送的输出量。
  • 容量
    • 系统交付卷的能力。
    • 在每个步骤中,容量和卷的测量都不同,如下表所示。 为获得最佳性能,请确保每个步骤的容量与卷相匹配,并确保所有步骤都共享容量和卷。 例如,您可以在客户端计算机上计算导航,或将其放入缓存中,而不是在服务器上计算每个请求的导航。
  • 容量和卷
    什么/位置
    容量
    客户端
    用户计算机的计算能力。
    页面布局的复杂性。
    网络
    网络带宽。
    页面大小(代码、图像等)。
    调度程序缓存
    Web服务器的服务器内存(主内存和硬盘)。
    Web服务器(主内存和硬盘)。 缓存的页数和大小。
    输出缓存
    AEM服务器的服务器内存(主内存和硬盘)。
    输出缓存中的页数和大小,每页的依赖关系数。 调度程序缓存会降低此卷。
    Web 服务器
    Web服务器的计算能力。
    请求数量。 缓存会降低此卷。
    模板
    Web服务器的计算能力。
    模板的复杂性。
    存储库
    存储库的性能。
    从存储库加载的页数。

其他指标

前面几节详细介绍了要定义的主要指标。
根据您的特定要求,您可以单独定义其他指标或将上述分类考虑在内。
但是,最好有一套简单而可靠的精确核心指标,而不是尝试测量和定义网站的各个方面。 从本质上讲,您的网站一旦移交给您的用户,就会开始变化和发展。

安全

安全性至关重要,也是一个日益严峻的挑战。 必 ​** 须从项目的最初阶段考虑并计划它。
全核对清单 (Security Checklist)详细介绍了您应采取的步骤,以确保部署AEM时的安全安装。 安全性(开发时)以及用 户管理和安全性中 , 涵盖其他安全方面

并行和迭代任务

以下是:
  • 提供与AEM项目的第一 次实施 相关的概述。
  • 作为摘要概述;有关特定 阶段 /里程碑/任务,请参阅项目清单。
  • 任何时间尺度都是理论上的。
对于标准AEM项目的新实施,您需要考虑以下任务:
  • 从销售流程移交。
  • 客户应用程序的实施( 开发 )。
  • 在客户站点(基础结构)上安装和配置基础结构(及相关​ 流程 )。
  • 创建(或迁移)内容( 内容 )。
  • 移交到操作( 维护/支持 )。
  • 后续版本。
在所有方面,建议使用迭代方法:
将项目启动拆分为 Soft Launch (降低可用性,多次迭代)和 Hard Launch (完全可用性——实时),以允许在生产环境的实际条件下进行调整、优化和用户培训。
有关在 管理项目——最佳实践清单 项目生命周期中应执行(或评估)的任务的示例,请参阅项目核对清单。
每个类别需要注意的一点是:
  • 开发
    • 首先定义基本架构。
    • 使用多个迭代(Sprint)进行开发:
      • 首次冲刺等于首个完整开发周期。
      • First sprint会导致首次部署到测试环境。
      • 每次冲刺都有一个可以跑的结果。
      • 每个冲刺都会获得客户的批准(带有反馈的结构化测试的最小值)。
    • 计划在项目期间是否会更新可用的AEM版本。
    • 计划在短跑期间进行测试和优化。
    • 规划稳定化和优化阶段。
    • 创建要计划用于进一步发行的项目日志。
    • 计划合作伙伴参与和移交。
  • 基础结构
    • 首先定义基本架构:
      • 定义性能要求。
      • 定义绩效目标(即明确定义预期)。
      • 定义硬件和基础架构架构;包括大小调整。
      • 定义部署。
    • 使用多个迭代;对于第一个sprint和初始配置,请准备:
      • 开发环境。
      • 开发流程。
      • 测试环境。
      • 部署过程(包括配置管理)。
    • 计划多个负载测试。
    • 计划在短跑期间进行测试和优化。
    • 规划稳定和优化阶段。
    • 尽早部署到生产环境(让运营团队设置系统以获得体验)。
    • 尽早使用指定用户和定义的角色。
    • 计划培训(例如,管理员培训)。
    • 向行动移交的计划。
  • 内容
    • 基本架构:
      • 推动内容层次结构。
      • 帮助定义内容概念。
      • 定义MSM的使用和布局。
      • 定义角色、组、工作流和权限。
    • 考虑脱机页面创建是否有用。
    • 计划提前创建首页和内容(用于测试和反馈)。
    • 规划现有内容的迁移。
    • 重构后的“in-sprint-migration”计划。
    • 计划“内容燃耗”(用于上线内容的站点地图)。

估计时间和精力

根据您生成的任务列表,您随后可以对(高级)任务定义的时间和精力进行初步估计。 其中应包括指示将由谁(客户或合作伙伴)执行什么和何时执行什么操作。
下表显示了标准的近似和所涉及的相互关系,因此也包括成本:
这些数字只能用于初步估计。 经验丰富的AEM开发人员必须进行详细分析。
相位
努力
开发
粗略估计每个组件节点2 - 4小时将涵盖所有开发要求。
开发人员测试
15%的开发
跟进
10%的开发
文档
15%的开发
JavaDoc文档
10%的开发
错误修复
15%的开发
项目管理
20%的项目成本用于持续的项目管理和治理
然后,详细的规划可以将可用或必需的资源与截止日期和成本相关联。

参考架构

该参考体系结构用于为AEM体系结构提供模板解决方案。 该参考体系结构解决了企业系统常见的问题,包括扩展、可靠性和安全性。
应定义以下网站指标:
分类
定义
Internet站点数
内部网站点数
代码库的数量(例如,如果Internet和Intranet不同)
单个页数
网站访问次数/天
页面查看次数/天
数据传输量(以GB为单位)/天
并发用户数(已关闭的用户组)
并发访客数(发布)
并发作者数
注册作者数
页面激活次数/工作日
部署期间的页面激活次数

潜在工具概述

下面的列表用于通知您可以使用的工具。 它是作为介绍而非广泛的推荐列表提供的,并且不应阻止您使用您喜欢的任何其他工具。
产品 描述
AEM
AEM本身提供了一系列机制,帮助您监视、测试、调查和调试应用程序;包括:
Selenium 是一个开放源代码测试工具。 测试直接在浏览器中运行——模拟用户的工作方式。
Microsoft Project 常用的项目管理工具。
吉拉 Jira 是一个开放源代码工具,用于跟踪和管理软件错误的详细信息。 可以根据需要将工作流强加到错误详细信息上。
Git Git 是一款修订控制软件。
Eclipse
Eclipse是由各种项目组成的开放源IDE。 这些解决方案侧重于构建一个由可扩展框架、工具和运行时组成的开放式开发平台,用于在整个生命周期中构建、部署和管理软件。
IntelliJ
提供各种功能的专业(因此需要承担许可成本)IDE。
马文 Maven 是一个软件项目管理和理解工具,可以管理项目的构建过程(软件和文档)。

进一步阅读

此外,以下几节特别关注:

最佳实践

Adobe为所有阶段和受众提供了更多最佳实践: