솔루션 설계자의 검사 목록
설계자의 책임은 설계와 계획을 제공하는 것입니다. 설계자는 워크로드의 구현자가 아닙니다. 설계 자는 기능 및 비기능 요구 사항을 클라우드 디자인 패턴 및 용도에 맞는 구성 요소로 변환합니다. 또한 설계자는 필요할 때 적응할 수 있을 만큼 유연하지만 기능의 계획된 수명을 견딜 수 있을 만큼 내구성이 뛰어난 워크로드를 설계합니다.
또한 디자인에는 가시성 및 지원 가능성을 포함하여 워크로드의 운영 측면과 재해 복구와 같은 바람직하지 않은 상황을 고려합니다. 마지막으로 디자인은 모든 비즈니스, 재무, 규정 준수 및 조직 요구 사항에 의해 제한되어야 합니다.
Azure Well-Architected Framework와 같은 아키텍처 프레임워크는 설계자에게 시스템 디자인에 대한 전체적인 관점을 제공하는 데 도움이 됩니다. Well-Architected Framework 아티팩트에는 디자인 원칙, 검사 목록 및 권장 사항과 같은 요소가 포함됩니다. 워크로드의 요구 사항을 지원하려면 이러한 아티팩트가 의사 결정 트리, 참조 아키텍처 및 평가와 같은 다른 리소스와 결합하여 정보에 입각한 결정을 내려야 합니다.
검사 목록
결과물 작업 | |
---|---|
☐ | 다이어그램과 함께 구조화된 패킷으로 제공되는 아키텍처 디자인 사양을 개발합니다. 사양은 워크로드의 기능 및 비기능 요구 사항을 충족하고 루틴, 임시 및 긴급 작업에 대한 프로비저닝을 포함해야 합니다. |
☐ | 광범위한 개요에서 네트워크 및 ID와 같은 자세한 차원에 이르기까지 시스템 디자인의 모든 측면을 보여 주는 아키텍처 디자인 다이어그램을 만듭니다. |
☐ | 디자인 프로세스 중에 수행되는 아키텍처 결정에 대한 근거를 포함하는 ADR(아키텍처 의사 결정 레코드)을 유지 관리합니다. |
☐ | 구현 중에 워크로드 팀과 협업하여 구현 시퀀스에 대한 명확성과 권장 사항을 제공합니다. 이 협업을 통해 처음부터 학습을 최대화하고 개선할 수 있습니다. 또한 필요한 경우 관련자와 요구 사항을 재협상합니다. |
☐ | 워크로드 문제에 대한 컨텍스트화된 정보를 제공하는 모델링 연습을 지원합니다. 컨텍스트화된 정보는 비용, 애플리케이션 상태 및 기타 영역을 다룰 수 있습니다. |
☐ | 사용 패턴의 관찰과 워크로드 기능 또는 클라우드 공급자 변경 내용의 변경 내용을 기반으로 하는 최적화 권장 사항을 제공합니다. |
☐ | 감사, 규정 준수 및 신뢰도 검토에 참여하여 검토를 수행할 권한이 있는 외부 당사자에게 귀중한 관점을 제공합니다. |
☐ | 변경 검토 중에 컨설턴트가 되어 예상 변경 비용 및 타당성에 대한 인사이트를 제공합니다. |
다음 단계
Well-Architected Framework 핵심 요소에 대해 알아보고 주요 개념을 숙지하세요.
피드백
https://aka.ms/ContentUserFeedback
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요.다음에 대한 사용자 의견 제출 및 보기