검사 목록 - 추가 참조 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를 선택하는 것이 중요합니다. KPI의 정의, 측정 방법, 사용 방법 및 사용자를 명확히 정의하십시오.
-
성능:
- 시스템 성능을 측정하는 방법을 정의합니다.
- 일부 예에는 페이지 로드 시간, 서버 응답 시간 및 데이터베이스 쿼리 성능이 포함됩니다.
전부는 아니지만 일부 지표는 식별 및 정의하는 타겟 지표를 기반으로 할 수 있습니다.
Target 지표 target-metrics
지표는 웹 사이트의 품질에 대한 정량적 측정을 정의하는 데 사용됩니다. 기본적으로 달성하고자 하는 성능 목표에 대한 정의이며, 다음을 정의하는 데 사용할 수 있습니다. KPI(주요 성과 지표).
많은 지표를 정의할 수 있지만, 정의하는 지표가 성과 및 동시성 목표를 다루는 경우가 많습니다. 특히, 정량화가 어려울 수 있고 종종 다음과 같은 요인들이 있습니다. 감정 평가:
-
"웹 사이트는 너무 느림 today" - 언제 느림 선별?
-
"모두" 서서히 멈추다 내 동료가 로그인할 때" - 시스템이 지원할 수 있는 동시 사용자 수
-
"검색하면 시스템이 서서히 멈추다 " - 어떤 검색 요청이 시스템에 영향을 줍니까?
-
"시간이 걸린다 세 파일을 다운로드하려면" - 정상적인 네트워크 조건에서 허용되는 다운로드 시간은 얼마입니까?
타겟 지표는 프로젝트 시작 시 다음과 같이 정의됩니다.
- 제공할 수 있는 웹 사이트의 예상 차원을 나타냅니다.
- 달성하고자 하는 최소 품질을 나타냅니다.
- 이러한 요인의 측정 방법 정의
- 의 기반으로 사용 주요 성과 지표
대상 지표를 정의할 때 항상 주의해야 하는 것처럼:
- 너무 높게 설정하면 도달할 수 없습니다.
- 너무 낮게 설정하면 강조 표시되지 않을 수 있습니다
- 반복적이고 일관되게 측정할 수 있도록
- 측정 중인 여러 요인에 균형을 맞추기 위해
- 특정 지표는 테스트 환경과 관련이 있지만, 일부는 프로덕션 웹 사이트에서 측정 가능하고 재현 가능해야 하므로 실제 시나리오를 반영해야 합니다
- 웹 사이트에 대한 중요도에 따라 지표 우선 순위 지정
- 모니터링할 수 있는 세트로 지표 제한
프로젝트를 개발하는 동안 적절하게 업데이트하고 조정할 수 있습니다. 프로젝트가 성공적으로 구현되면 설치를 제어하고 지속적인 운영에 필요한 서비스 수준을 모니터링/유지 관리하는 데 도움이 될 수 있습니다.
이러한 지표를 올바르게 사용하면 유용한 도구가 제공될 수 있습니다. 무책임하게 사용하면 시간을 낭비하는 방해가 될 수 있습니다. 항상 그렇듯이 무엇을 측정하고, 어떻게 측정하는지, 왜 측정하는지 이해해야 합니다.
모든 것이 프로젝트 디자인에 달려 있습니다. everything-rests-on-your-project-design
측정된 모든 지표는 프로젝트 설계의 영향을 받습니다. 반대로 많은 문제는 설계 변경을 통해 가장 잘 해결됩니다.
따라서 타겟 지표를 정의합니다 다음 이전 디자인 결정. 이렇게 하면 이러한 요소를 기반으로 디자인을 최적화할 수 있습니다. 프로젝트가 개발되면 기본 디자인 원칙은 매우 어렵습니다.
웹 사이트에 대한 구조를 만들 때는 AEM 웹 사이트에 대해 권장되는 구조를 따르십시오. 다음 문제 및/또는 원칙을 이해했는지 확인하십시오.
- 웹 사이트 콘텐츠를 구성하는 방법입니다.
- 템플릿 및 구성 요소 작동 방식
- 캐싱은 어떻게 작동합니까?
- 개인화된 콘텐츠의 영향.
- 검색 기능 작동 방식.
- CSS 및 관련 기술을 사용하여 중복되지 않은 컴팩트한 HTML 코드를 만드는 방법.
디자인이 가이드라인을 따르지 않는다고 생각되거나 몇 가지 영향에 대해 잘 모르는 경우 이러한 문제를 명확히 하십시오. 프로그래밍 단계나 콘텐츠 작성을 시작하기 전에 그렇게 하십시오.
인프라 infrastructure
인프라를 정의하거나 평가하기 위해 다음과 같은 대상 값을 정의하는 데 도움이 됩니다.
- 방문자/일, 평균 및 피크 모두
- 히트/일, 평균 및 피크 모두
- 사용 가능한 웹 페이지 수
- 웹 컨텐츠 볼륨
사용자 상황과 웹 사이트의 전략적 중요성에 따라 인프라를 정의하면 인프라를 평가하고 선택하는 데 도움이 될 수 있습니다.
- 서버 수
- AEM 인스턴스 수(작성자 및 게시)
공연 performance
평가할 수 있는 몇 가지 성능 요소는 다음과 같습니다.
-
다음 사항을 설명하는 개별 페이지의 응답 시간:
- 작성자 환경의 응답 시간
- 게시 환경의 응답 시간
-
검색 요청에 대한 응답 시간
이 섹션은 다음으로 읽을 수 있습니다. 성능 최적화 이렇게 하면 실제로 성능을 측정하는 기술적인 세부 사항이 확장됩니다.
개별 페이지의 응답 시간 response-times-for-individual-pages
핵심 문제는 웹 사이트가 방문자 요청에 응답하는 데 걸리는 시간입니다.
이 값은 요청마다 다르지만 평균 대상 값을 정의할 수 있습니다. 이 값이 달성 가능하고 유지 가능한 것으로 입증되면 웹 사이트의 성능을 모니터링하고 잠재적인 문제의 발생을 나타내는 데 사용할 수 있습니다
작성자 및 게시 환경에 대한 다른 타겟
목표로 하는 응답 시간은 타겟 대상자를 반영하는 작성자 및 게시 환경에서 다릅니다.
-
작성 환경
이 환경은 컨텐츠를 입력하고 업데이트하는 작성자에 의해 사용되므로 다음 작업을 수행해야 합니다.
- 콘텐츠 페이지 및 해당 페이지의 개별 요소를 업데이트할 때 많은 요청을 생성하는 일부 사용자를 위한 기능입니다
- 가능한 한 빨리 콘텐츠를 웹 사이트로 가져올 수 있도록 생산성을 극대화하십시오.
-
게시 환경
이 환경에는 사용자가 사용할 수 있는 콘텐츠가 포함되어 있습니다.
-
속도는 여전히 중요하지만 작성자 환경보다 느린 경우가 많습니다
-
추가적인 성능 향상 메커니즘이 적용되는 경우가 많습니다.
- 콘텐츠가 캐시됨
- 로드 밸런싱이 적용됨
-
타겟 응답 시간 설정 setting-target-response-times
달성 가능한(평균) 응답 시간을 어떻게 결정할 수 있습니까? 질문과 대답은 종종 경험의 문제입니다.
- 웹 사이트의 경험
- 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
검색 요청 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 캐시 웹 서버의 서버 메모리(주 메모리 및 하드 드라이브). 웹 서버(주 메모리 및 하드 드라이브). 캐시된 페이지의 수와 크기. 출력 캐시 AEM 서버의 서버 메모리(주 메모리 및 하드 드라이브). 출력 캐시의 페이지 수 및 크기, 페이지당 종속성 수. Dispatcher 캐시는 이 볼륨을 낮춥니다. 웹 서버 웹 서버의 계산 능력. 요청 수. 캐싱은 이 볼륨을 낮춥니다. 템플릿 웹 서버의 계산 능력. 템플릿의 복잡성입니다. 저장소 저장소의 성능. 저장소에서 로드한 페이지 수입니다.
기타 지표 other-metrics
앞의 섹션에서는 정의할 기본 지표에 대해 자세히 설명합니다.
특정 요구 사항에 따라 위의 분류를 계산하거나 별도로 추가 지표를 정의하는 것이 유용할 수 있습니다.
그러나 웹 사이트의 모든 측면을 측정하고 정의하는 것보다 간단하고 안정적으로 작동하는 작은 정확하고 핵심 지표 세트를 사용하는 것이 좋습니다. 순전히 고유한 특성으로 인해 웹 사이트가 사용자에게 전달되면 변경되고 발전하기 시작합니다.
보안 security
보안은 중요하고 계속 증가하는 도전입니다. It 필수 프로젝트의 초기 단계부터 고려 및 계획됩니다.
다음 보안 검사 목록 배포 시 AEM 설치가 안전한지 확인하기 위해 수행해야 하는 세부 단계입니다. 다른 보안 측면은에서 다룹니다. 보안(개발 시) 및 사용자 관리 및 보안.
병렬 및 반복 작업 parallel-and-iterative-tasks
- 와 관련된 개요를 제공합니다. 첫 번째 AEM 프로젝트 구현.
- 이는 추상적인 개요입니다. 다음을 참조하십시오. 프로젝트 체크리스트 특정 단계/이정표/작업의 경우.
- 모든 시간 척도는 이론적입니다.
표준 AEM 프로젝트의 새 구현의 경우 다음과 같은 작업을 고려하십시오.
- 영업 프로세스의 인계.
- 고객 애플리케이션 구현(개발).
- 고객 사이트에서 인프라(및 관련 프로세스) 설치 및 구성(인프라).
- 콘텐츠 만들기(또는 마이그레이션)(콘텐츠).
- 작업으로의 핸드오버(유지 관리/지원).
- 후속 릴리스.
모든 측면에서 반복적인 접근 방식을 사용하는 것이 좋습니다.
각 범주에 대해 몇 가지 주의할 사항은 다음과 같습니다.
-
개발
-
먼저 기본 아키텍처를 정의합니다.
-
개발에 여러 번 반복(sprints)을 사용합니다.
- 첫 번째 스프린트는 첫 번째 전체 개발 주기와 동일합니다.
- 첫 번째 스프린트는 테스트 환경에 첫 번째 배포를 생성합니다.
- 모든 스프린트는 달릴 수 있는 결과를 가지고 있다.
- 각 스프린트는 고객 사인오프(피드백이 있는 구조화된 테스트 최소)를 받습니다.
-
프로젝트 진행 중 사용 가능한 AEM 버전 업데이트의 최종 결과를 계획합니다.
-
단거리 훈련 중 테스트 및 최적화를 계획합니다.
-
안정화 및 최적화 단계에 대한 계획.
-
추가 릴리스를 위해 계획될 항목의 로그를 만듭니다.
-
파트너 참여 및 인계 계획.
-
-
인프라
-
먼저 기본 아키텍처를 정의합니다.
- 성능 요구 사항을 정의합니다.
- 성과 목표를 정의합니다(즉, 기대치를 명확히 정의함).
- 하드웨어 및 인프라 아키텍처 정의(크기 조정 포함)
- 배포를 정의합니다.
-
첫 번째 스프린트 및 초기 구성 준비에 대해 여러 번 반복을 사용합니다.
- 개발 환경.
- 개발 프로세스.
- 테스트 환경.
- 배포 프로세스(구성 관리 포함).
-
여러 부하 테스트를 계획합니다.
-
단거리 훈련 중 테스트 및 최적화를 계획합니다.
-
안정화 및 최적화 단계를 계획합니다.
-
가능한 한 빨리 프로덕션 환경에 배포합니다(운영 팀이 환경을 구축하도록 시스템 설정).
-
명명된 사용자 및 정의된 역할을 가능한 한 빨리 사용하십시오.
-
교육 계획(예: 관리자 교육).
-
작전으로의 이관 계획.
-
-
콘텐츠
-
기본 아키텍처:
- 콘텐츠 계층 구조를 구동합니다.
- 콘텐츠 개념을 정의하는 데 도움이 됩니다.
- MSM 사용 및 레이아웃을 정의합니다.
- 역할, 그룹, 워크플로우 및 권한을 정의합니다.
-
오프라인 페이지 생성이 유용한지 여부를 고려합니다.
-
첫 번째 페이지 및 콘텐츠의 조기 생성을 계획합니다(테스트 및 피드백에 사용).
-
기존 콘텐츠의 마이그레이션을 계획합니다.
-
리팩터링 후 "스프린트 내 마이그레이션"을 계획합니다.
-
"콘텐츠 번다운" 계획(Go-Live 콘텐츠의 사이트 맵).
-
시간 및 노력 추정 estimating-time-and-effort
그런 다음 결과 작업 목록에 따라 (높은 수준의) 작업 정의에 대한 초기 시간 및 노력을 예상할 수 있습니다. 이러한 예상 값에는 누가 (고객 또는 파트너)가 무엇을 언제 수행하는지 나타내는 정보가 포함되어야 합니다.
다음 목록은 표준 근사 및 관련된 노력의 상호 관계를 보여 주며, 따라서 원가를 보여 줍니다.
그런 다음 세부 계획을 통해 가용 자원 또는 필수 자원을 기한 및 비용과 연결할 수 있습니다.
참조 아키텍처 reference-architecture
참조 아키텍처는 AEM 아키텍처에 대한 템플릿 솔루션을 제공하기 위해 제공됩니다. 참조 아키텍처는 확장, 안정성, 보안 등 엔터프라이즈 시스템에서 일반적으로 발생하는 문제를 해결합니다.
다음 사이트 지표를 정의해야 합니다.
잠재적 도구 개요 overview-of-potential-tools
다음 목록은 사용할 수 있는 도구를 알려줍니다. 이는 광범위한 권장 사항 목록이 아니라 소개를 위한 것이며 다른 도구를 사용하지 못하도록 해서는 안 됩니다.
추가 참조 further-reading
또한 다음 섹션이 특히 중요합니다.
모범 사례 best-practices
Adobe은 모든 단계 및 대상에 대해 추가 모범 사례를 제공합니다.