검사 목록 - 추가 참조

이 페이지에서는 다음 내용에 포함된 문서 및 원칙을 자세히 설명하고 보강할 수 있는 자세한 내용을 제공합니다. 프로젝트 관리 - 우수 사례 검사 목록.

AEM - 무엇을 사용하시겠습니까?

AEM의 기능

AEM을 구현할 때(특히 처음으로) AEM의 기능 및 워크플로 원하는 영역과 필요한 영역을 확인해야 합니다.

사용 중인 AEM의 기능과 디자인에 미치는 영향을 고려하십시오. 예를 들면 다음과 같습니다.

• 상거래
• Screens
• Assets
• 태그
• 다중 사이트 관리 및 번역
• Forms
• 커뮤니티

또한 다음을 확인하십시오. 릴리스 정보를 사용하여 다양한 AEM 버전에서 새 기능이 추가된 시기를 확인할 수 있습니다.

통합

AEM은 다른 Adobe 제품이나 서드파티 서비스 또는 둘 다와 통합할 수 있습니다. 이러한 워크플로우는 원하는 대로 성능과 기능을 향상시킬 수 있습니다.

다음을 참조하십시오 솔루션 통합 전체 정보.

마이그레이션 또는 업그레이드

주요 고려 사항은 다음 중 하나를 원하는지 여부입니다.

• 기존 설치를 업그레이드합니다.
• 현재 시스템에서 새로운 새 설치로 콘텐츠를 마이그레이션합니다.

이전 버전에서 현재 버전으로 이동할 때 두 가지 옵션이 있습니다.

• 사용 패키지 관리자 이전 시스템의 모든 컨텐츠 및 응용 프로그램 코드를 새 시스템으로 내보냅니다.
• 업그레이드 기존 시스템. 일반적으로 이 방법을 사용하는 것이 좋습니다.

기본 기본 기본 기본 규칙

다른 프로젝트와 마찬가지로, 가능한 한 빨리 기본 규칙을 설정하는 것이 중요합니다. 이러한 규칙에는 다음이 포함됩니다.

• 역할

  역할을 명확히 정의하고 프로젝트에 관련된 모든 사람에게 알려야 합니다. 또한 다음을 강조 표시하는 것이 좋습니다.

  • 의사 결정자
  • 연락처

• 책임

  • 각 역할에 대해 프로젝트와 관련된 책임을 명확하게 정의하면 혼동을 방지할 수 있습니다.

• 관여

  이해 관계자들을 가능한 한 빨리 참여시킴으로써, 당신은 그들이 될 수 있도록 격려할 수 있습니다 이해 당사자 을 클릭합니다. 그렇게 하면 성공에 대한 그들의 헌신이 높아집니다.

  • 고객 측면에서는 이 역할에 매일 시스템을 사용하는 작성자가 포함됩니다
  • 자체 프로젝트 팀 내에서 이 참여에는 품질 보증을 담당하는 사람도 포함됩니다. 고객의 요구 사항을 더 잘 이해할수록 테스트를 더 잘 계획할 수 있습니다.

• 통신 경로

  • 커뮤니케이션 경로가 지나치게 형식화되어서는 안 되지만, 구체적인 정의를 통해 주요 사용자에게 항상 정보가 제공되므로 최신 정보를 유지해야 합니다. 외부 당사자와의 의사소통에 특히 주의를 기울여야 한다.

• 프로세스

  정의된 프로세스는 개별 프로젝트에 따라 다릅니다. 다시 한 번, 다음 사항을 고려하여 이러한 프로세스를 단순하게 유지하십시오.

  • 설계 에이전시 및 타사 소프트웨어 공급업체 등 서드파티와 상호 작용하기 위한 프로세스(및 커뮤니케이션 경로)를 정의합니다.
  • 고객은 프로젝트 관리 및 보고 절차 및 도구를 보유한 경우가 많습니다.

• 추적 도구

  버그, 작업 및 프로젝트의 다른 측면에 대한 정보를 추적하는 데 사용할 수 있는 다양한 도구가 있습니다. 다음을 참조하십시오. 잠재적 도구 개요 을 참조하십시오.

  • 여기서 주목할 점은 정보의 사본을 하나만 보관하고 정보를 공유(따라서 사용 중인 도구에 대한 액세스)하는 것입니다. 이 워크플로우에서는 유지 관리가 쉬워지며 불일치를 방지할 수 있습니다.

• 범위

  다양한 수준에서 프로젝트에서 다루는 사항을 명확히 정의합니다.

  • 개별 릴리스(반복 릴리스 프로세스를 사용하는 경우 및 고객에게 전달되었는지 내부 테스트 팀에 전달되었는지 여부에 상관없이).
  • AEM 프로젝트.
  • 타사 소프트웨어, 테스트에 미치는 영향, 조직 문제 등 전체 프로젝트.
  • 특정 측면들에 대해, 무엇이 무엇인지를 서술하는 것도 유용할 수 있다 아님 프로젝트의 범위 내에서. 이 아이디어는 필수적인 문제로 제한되어야 하지만 혼란과 잘못된 가정을 방지하는 데 도움이 될 수 있습니다.

• 보고

  보고하려는 정보, 보고 형식, 빈도 및 대상을 명확히 정의합니다.

• 용어

  • 사용할 약어 및/또는 고객별 용어를 정의합니다.

• 가정

  • 수행되는 모든 가정을 정의합니다.

이 정보는 프로젝트 핸드북 내에서 정의할 수 있습니다. Wiki를 사용하면 진행 중인 변경 사항을 효율적으로 처리할 수 있습니다. 이러한 가정이 정의되는 곳마다, 주요 요인은 다음과 같습니다.

• 정보 정의 및 유지 관리
• 정보는 관련된 모든 사람에게 명확하게 전달됩니다. 표준 프로젝트 관리 방식이지만 명확한 역할 정의와 원활한 커뮤니케이션으로 프로젝트를 만들거나 중단할 수 있을 만큼 자주 반복될 수는 없습니다.
• 한 버전만 추적 중인 정보(예: 버그 추적 및 문제 추적)에 보관됩니다.

주요 성능 지표 및 Target 지표

조직은 주요 성과 지표(KPI)를 사용하여 목표 달성 성공을 평가합니다. 이러한 지표는 구체적 목표가 얼마나 효과적으로 충족되고 있는지를 입증하는 데 사용될 수 있는 측정 가능한 값이다.

이러한 지표는 다음과 같을 수 있습니다.

• 상업:

  • 주요 비즈니스 목표를 측정하는 데 사용됩니다.
  • 비즈니스/시나리오에 적합한 KPI를 선택하는 것이 중요합니다. KPI의 정의, 측정 방법, 사용 방법 및 사용자를 명확히 정의하십시오.

• 공연:

  • 시스템 성능을 측정하는 방법을 정의합니다.
  • 일부 예에는 페이지 로드 시간, 서버 응답 시간 및 데이터베이스 쿼리 성능이 포함됩니다.

전부는 아니지만 일부 지표는 식별 및 정의하는 타겟 지표를 기반으로 할 수 있습니다.

Target 지표

지표는 웹 사이트의 품질에 대한 정량적 측정을 정의하는 데 사용됩니다. 기본적으로 달성하고자 하는 성능 목표에 대한 정의이며, 다음을 정의하는 데 사용할 수 있습니다. KPI(주요 성과 지표).

많은 지표를 정의할 수 있지만, 정의하는 지표가 성과 및 동시성 목표를 다루는 경우가 많습니다. 특히, 정량화가 어려울 수 있고 종종 다음과 같은 요인들이 있습니다. 감정 평가:

• "웹 사이트는 너무 느림 today" - 언제 느림 선별?

• "모두" 서서히 멈추다 내 동료가 로그인할 때" - 시스템이 지원할 수 있는 동시 사용자 수

• "검색하면 시스템이 서서히 멈추다 " - 어떤 검색 요청이 시스템에 영향을 줍니까?

• "시간이 걸린다 세 파일을 다운로드하려면" - 정상적인 네트워크 조건에서 허용되는 다운로드 시간은 얼마입니까?

Target 지표는 프로젝트 시작 시 다음과 같이 정의됩니다.

• 제공할 수 있는 웹 사이트의 예상 차원을 나타냅니다.
• 달성하고자 하는 최소 품질을 나타냅니다.
• 이러한 요인의 측정 방법 정의
• 의 기반으로 사용 주요 성과 지표

대상 지표를 정의할 때 항상 주의해야 하는 것처럼:

• 너무 높게 설정하면 도달할 수 없습니다.
• 너무 낮게 설정하면 강조 표시되지 않을 수 있습니다
• 반복적이고 일관되게 측정할 수 있도록
• 측정 중인 여러 요인에 균형을 맞추기 위해
• 특정 지표는 테스트 환경과 관련이 있지만, 일부는 프로덕션 웹 사이트에서 측정 가능하고 재현 가능해야 하므로 실제 시나리오를 반영해야 합니다
• 웹 사이트에 대한 중요도에 따라 지표 우선 순위 지정
• 모니터링할 수 있는 세트로 지표 제한

프로젝트를 개발하는 동안 적절하게 업데이트하고 조정할 수 있습니다. 프로젝트가 성공적으로 구현되면 설치를 제어하고 지속적인 운영에 필요한 서비스 수준을 모니터링/유지 관리하는 데 도움이 될 수 있습니다.

이러한 지표를 올바르게 사용하면 유용한 도구가 제공될 수 있습니다. 무책임하게 사용하면 시간을 낭비하는 방해가 될 수 있습니다. 항상 그렇듯이 무엇을 측정하고, 어떻게 측정하는지, 왜 측정하는지 이해해야 합니다.

모든 것이 프로젝트 디자인에 달려 있습니다.

측정된 모든 지표는 프로젝트 설계의 영향을 받습니다. 반대로 많은 문제는 설계 변경을 통해 가장 잘 해결됩니다.

따라서 타겟 지표를 정의합니다 다음 이전 디자인 결정. 이렇게 하면 이러한 요소를 기반으로 디자인을 최적화할 수 있습니다. 프로젝트가 개발되면 기본 디자인 원칙은 매우 어렵습니다.

웹 사이트에 대한 구조를 만들 때는 AEM 웹 사이트에 대해 권장되는 구조를 따르십시오. 다음 문제 및/또는 원칙을 이해했는지 확인하십시오.

• 웹 사이트 콘텐츠를 구성하는 방법입니다.
• 템플릿 및 구성 요소 작동 방식
• 캐싱은 어떻게 작동합니까?
• 개인화된 콘텐츠의 영향.
• 검색 기능 작동 방식.
• CSS 및 관련 기술을 사용하여 중복되지 않은 컴팩트한 HTML 코드를 만드는 방법.

디자인이 가이드라인을 따르지 않는다고 생각되거나 몇 가지 영향에 대해 잘 모르는 경우 이러한 문제를 명확히 하십시오. 프로그래밍 단계나 콘텐츠 작성을 시작하기 전에 그렇게 하십시오.

인프라

인프라를 정의하거나 평가하기 위해 다음과 같은 대상 값을 정의하는 데 도움이 됩니다.

• 방문자/일, 평균 및 피크 모두
• 히트/일, 평균 및 피크 모두
• 사용 가능한 웹 페이지 수
• 웹 컨텐츠 볼륨

사용자 상황과 웹 사이트의 전략적 중요성에 따라 인프라를 정의하면 인프라를 평가하고 선택하는 데 도움이 될 수 있습니다.

• 서버 수
• AEM 인스턴스 수(작성자 및 게시)

공연

평가할 수 있는 몇 가지 성능 요소는 다음과 같습니다.

• 다음 사항을 설명하는 개별 페이지의 응답 시간:

  • 작성자 환경의 응답 시간
  • 게시 환경의 응답 시간

• 검색 요청에 대한 응답 시간

이 섹션은 다음으로 읽을 수 있습니다. 성능 최적화 이렇게 하면 실제로 성능을 측정하는 기술적인 세부 사항이 확장됩니다.

개별 페이지의 응답 시간

핵심 문제는 웹 사이트가 방문자 요청에 응답하는 데 걸리는 시간입니다.

이 값은 요청마다 다르지만 평균 대상 값을 정의할 수 있습니다. 이 값이 달성 가능하고 유지 가능한 것으로 입증되면 웹 사이트의 성능을 모니터링하고 잠재적인 문제의 발생을 나타내는 데 사용할 수 있습니다

작성자 및 게시 환경에 대한 다른 타겟

목표로 하는 응답 시간은 타겟 대상자를 반영하는 작성자 및 게시 환경에서 다릅니다.

• 작성 환경

  이 환경은 컨텐츠를 입력하고 업데이트하는 작성자에 의해 사용되므로 다음 작업을 수행해야 합니다.

  • 콘텐츠 페이지 및 해당 페이지의 개별 요소를 업데이트할 때 많은 요청을 생성하는 일부 사용자를 위한 기능입니다
  • 가능한 한 빨리 콘텐츠를 웹 사이트로 가져올 수 있도록 생산성을 극대화하십시오.

• 게시 환경

  이 환경에는 사용자가 사용할 수 있는 콘텐츠가 포함되어 있습니다.

  • 속도는 여전히 중요하지만 작성자 환경보다 느린 경우가 많습니다

  • 추가적인 성능 향상 메커니즘이 적용되는 경우가 많습니다.

    • 콘텐츠가 캐시됨
    • 로드 밸런싱이 적용됨

타겟 응답 시간 설정

달성 가능한(평균) 응답 시간을 어떻게 결정할 수 있습니까? 질문과 대답은 종종 경험의 문제입니다.

• 웹 사이트의 경험
• AEM을 사용한 경험
• 평균 응답 시간을 초과하는 복잡한 페이지 인식(가능한 경우 해당 페이지를 개별적으로 최적화해야 함)

그러나 통제된 상황에서 다음 지침을 적용할 수 있습니다.

• 페이지 요청의 70%가 100ms 이내에 응답해야 합니다.
• 페이지 요청의 25%가 100ms-300ms 이내에 응답해야 합니다.
• 페이지 요청의 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

검색 요청

검색 요청은 다음 두 가지 측면에서 웹 사이트에 상당한 영향을 미칠 수 있습니다.

• 실제 검색의 응답 시간

  • 빠른 검색 기능은 웹 사이트의 품질 목표입니다.

• 일반 성능에 미치는 영향

  • 검색 기능은 콘텐츠의 (잠재적으로 큰) 섹션 또는 특별히 추출된 인덱스를 스캔해야 하므로 최적화되지 않은 경우 전체 시스템의 성능에 영향을 줄 수 있습니다

검색 요청에 대한 대상을 설정하는 것은 다음에 따라 경험의 문제입니다.

• AEM 경험
• 다른 목표와 비교하여 검색이 사용되는 빈도에 대한 평가
• 지속성 관리자
• 검색 색인
• 하나의 검색어를 입력할 수 있는 기본 검색 기능인 검색 기능의 복잡성은 사용자가 AND/OR/NOT을 사용하여 복잡한 검색 문을 작성할 수 있는 고급 검색보다 빠릅니다.

이러한 검색 요청은 프로젝트의 시작 부분부터 계획하고 통합해야 합니다. 모니터링에 사용할 수 있는 메커니즘은 다음과 같습니다.

• AEM request.log를 사용하여 검색 응답 시간 모니터링

  다시 request.log를 사용하여 검색 요청에 대한 응답 시간을 모니터링할 수 있습니다. 다음을 참조하십시오. 성능 최적화 을 참조하십시오.

• 검색 응답 시간을 측정하기 위한 프로그래밍 메커니즘

  검색 요청과 그 성능에 대해 수집하는 정보를 사용자 정의하려면 프로젝트 소스 코드에 정보 수집을 포함하는 것이 좋습니다. 를 참조하십시오. 성능 최적화 을 참조하십시오.

동시성

작성자와 게시 환경 모두에서 일부 사용자와 방문자가 웹 사이트를 사용할 수 있도록 합니다. 이 수치는 종종 테스트 할 때 사용하는 것보다 더 많지만 변동이 심하고 예측하기 어렵습니다. 부정적인 성능에 대한 영향을 알지 못하고 평균 동시 사용자 및 방문자 수에 맞게 웹 사이트를 디자인할 수 있습니다. 다시 한 번 request.log 동시성 테스트를 만듭니다. 다음을 참조하십시오 성능 최적화 을 참조하십시오.

동시 사용자 수에 대한 Target은 환경 유형에 따라 다릅니다.

• 작성 환경

  • 일반적으로 동시 사용자의 수를 정확하게 예측할 수 있습니다. 총 몇 명의 작성자가 있는지 알 수 있지만 모두 동시에 활성화되지는 않을 수 있습니다.

• 게시 환경

  • 게시 환경은 예측하기 더 어렵기 때문에 타겟 값을 선택해야 합니다. 다시 말하지만, 이는 새 웹 사이트에 대한 현실적인 기대와 함께 현재 웹 사이트의 경험을 기반으로 해야 합니다.
  • 특별 이벤트(예: 새로운 인기 콘텐츠를 게시하는 경우)는 기대치를 초과할 수 있습니다. 또는 기능(특정 이벤트 티켓이 판매될 때 언론에 보도되는 것과 같이)도 초과할 수 있습니다.

용량 및 볼륨

관련 지표에 대해 논의하기 전에 용어에 대한 빠른 정의:

• 볼륨

  • 시스템에서 처리 및 제공되는 출력의 양입니다.

• 용량

  • 볼륨을 전달하는 시스템의 기능입니다.
  • 각 단계별로 아래 표와 같이 용량과 부피가 다르게 측정된다. 최상의 성능을 얻으려면 각 단계에서 용량이 볼륨과 일치하는지, 모든 단계에서 용량과 볼륨을 모두 공유해야 합니다. 예를 들어, 모든 요청에 대해 서버에서 탐색을 계산하는 대신 클라이언트 컴퓨터에서 탐색을 계산하거나 캐시에 저장할 수 있습니다.

• 용량 및 볼륨

  내용 / 위치	용량	볼륨
  클라이언트	사용자 컴퓨터의 계산 능력.	페이지 레이아웃의 복잡성입니다.
  네트워크	네트워크 대역폭.	페이지 크기(코드, 이미지 등)입니다.
  Dispatcher 캐시	웹 서버의 서버 메모리(주 메모리 및 하드 드라이브).	웹 서버(주 메모리 및 하드 드라이브). 캐시된 페이지의 수와 크기.
  출력 캐시	AEM 서버의 서버 메모리(주 메모리 및 하드 드라이브).	출력 캐시의 페이지 수 및 크기, 페이지당 종속성 수. Dispatcher 캐시는 이 볼륨을 낮춥니다.
  웹 서버	웹 서버의 계산 능력.	요청 수. 캐싱은 이 볼륨을 낮춥니다.
  템플릿	웹 서버의 계산 능력.	템플릿의 복잡성입니다.
  저장소	저장소의 성능.	저장소에서 로드한 페이지 수입니다.

기타 지표

앞의 섹션에서는 정의할 기본 지표에 대해 자세히 설명합니다.

특정 요구 사항에 따라 위의 분류를 계산하거나 별도로 추가 지표를 정의하는 것이 유용할 수 있습니다.

그러나 웹 사이트의 모든 측면을 측정하고 정의하는 것보다 간단하고 안정적으로 작동하는 작은 정확하고 핵심 지표 세트를 사용하는 것이 좋습니다. 순전히 고유한 특성으로 인해 웹 사이트가 사용자에게 전달되면 변경되고 발전하기 시작합니다.

보안

보안은 중요하고 계속 증가하는 도전입니다. It 필수 프로젝트의 초기 단계부터 고려 및 계획됩니다.

다음 보안 검사 목록 배포 시 AEM 설치가 안전한지 확인하기 위해 수행해야 하는 세부 단계입니다. 다른 보안 측면은에서 다룹니다. 보안(개발 시) 및 사용자 관리 및 보안.

병렬 및 반복 작업

표준 AEM 프로젝트의 새 구현의 경우 다음과 같은 작업을 고려하십시오.

• 영업 프로세스의 인계.
• 고객 애플리케이션 구현(개발).
• 고객 사이트에서 인프라(및 관련 프로세스) 설치 및 구성(인프라).
• 콘텐츠 만들기(또는 마이그레이션)(콘텐츠).
• 작업으로의 핸드오버(유지 관리/지원).
• 후속 릴리스.

모든 측면에서 반복적인 접근 방식을 사용하는 것이 좋습니다.

각 범주에 대해 몇 가지 주의할 사항은 다음과 같습니다.

• 개발

  • 먼저 기본 아키텍처를 정의합니다.

  • 개발에 여러 번 반복(sprints)을 사용합니다.

    • 첫 번째 스프린트는 첫 번째 전체 개발 주기와 동일합니다.
    • 첫 번째 스프린트는 테스트 환경에 첫 번째 배포를 생성합니다.
    • 모든 스프린트는 달릴 수 있는 결과를 가지고 있다.
    • 각 스프린트는 고객 사인오프(피드백이 있는 구조화된 테스트 최소)를 받습니다.

  • 프로젝트 진행 중 사용 가능한 AEM 버전 업데이트의 최종 결과를 계획합니다.

  • 단거리 훈련 중 테스트 및 최적화를 계획합니다.

  • 안정화 및 최적화 단계에 대한 계획.

  • 추가 릴리스를 위해 계획될 항목의 로그를 만듭니다.

  • 파트너 참여 및 인계 계획.

• 인프라

  • 먼저 기본 아키텍처를 정의합니다.

    • 성능 요구 사항을 정의합니다.
    • 성과 목표를 정의합니다(즉, 기대치를 명확히 정의함).
    • 하드웨어 및 인프라 아키텍처 정의(크기 조정 포함)
    • 배포를 정의합니다.

  • 첫 번째 스프린트 및 초기 구성 준비에 대해 여러 번 반복을 사용합니다.

    • 개발 환경.
    • 개발 프로세스.
    • 테스트 환경.
    • 배포 프로세스(구성 관리 포함).

  • 여러 부하 테스트를 계획합니다.

  • 단거리 훈련 중 테스트 및 최적화를 계획합니다.

  • 안정화 및 최적화 단계를 계획합니다.

  • 가능한 한 빨리 프로덕션 환경에 배포합니다(운영 팀이 환경을 구축하도록 시스템 설정).

  • 명명된 사용자 및 정의된 역할을 가능한 한 빨리 사용하십시오.

  • 교육 계획(예: 관리자 교육).

  • 작전으로의 이관 계획.

• 콘텐츠

  • 기본 아키텍처:
    • 콘텐츠 계층 구조를 구동합니다.
    • 콘텐츠 개념을 정의하는 데 도움이 됩니다.
    • MSM 사용 및 레이아웃을 정의합니다.
    • 역할, 그룹, 워크플로우 및 권한을 정의합니다.
  • 오프라인 페이지 생성이 유용한지 여부를 고려합니다.
  • 첫 번째 페이지 및 콘텐츠의 조기 생성을 계획합니다(테스트 및 피드백에 사용).
  • 기존 콘텐츠의 마이그레이션을 계획합니다.
  • 리팩터링 후 "스프린트 내 마이그레이션"을 계획합니다.
  • "콘텐츠 번다운" 계획(Go-Live 콘텐츠의 사이트 맵).

시간 및 노력 추정

그런 다음 결과 작업 목록에 따라 (높은 수준의) 작업 정의에 대한 초기 시간 및 노력을 예상할 수 있습니다. 이러한 예상 값에는 누가 (고객 또는 파트너)가 무엇을 언제 수행하는지 나타내는 정보가 포함되어야 합니다.

다음 목록은 표준 근사 및 관련된 노력의 상호 관계를 보여 주며, 따라서 원가를 보여 줍니다.

그런 다음 세부 계획을 통해 가용 자원 또는 필수 자원을 기한 및 비용과 연결할 수 있습니다.

참조 아키텍처

참조 아키텍처는 AEM 아키텍처에 대한 템플릿 솔루션을 제공하기 위해 제공됩니다. 참조 아키텍처는 확장, 안정성, 보안 등 엔터프라이즈 시스템에서 일반적으로 발생하는 문제를 해결합니다.

다음 사이트 지표를 정의해야 합니다.

잠재적 도구 개요

다음 목록은 사용할 수 있는 도구를 알려줍니다. 이는 광범위한 권장 사항 목록이 아니라 소개를 위한 것이며 다른 도구를 사용하지 못하도록 해서는 안 됩니다.

추가 참조

또한 다음 섹션이 특히 중요합니다.

• 시작하기
• 기술 요구 사항
• 인스턴스 모니터링 및 유지 관리

모범 사례

Adobe은 모든 단계 및 대상에 대해 추가 모범 사례를 제공합니다.

• 배포
• 작성
• 관리
• 개발
• 프로젝트 관리

Business.Adobe.com 리소스

Multichannel Communication Automated Onboarding Version History Dynamic Forms Content Management Digital Rights Management