운영 적합성 검토 설정Establish an operational fitness review

기업은 Azure에서 워크 로드를 운영 하기 시작 하므로 다음 단계는 운영 적합성을 검토 하기 위한 프로세스를 설정 하는 것입니다.As your enterprise begins to operate workloads in Azure, the next step is to establish a process for operational fitness review. 이 프로세스는 이러한 워크 로드에 대 한 작동 하지 않는 요구 사항을 열거, 구현 및 반복적으로 검토 합니다.This process enumerates, implements, and iteratively reviews the nonfunctional requirements for these workloads. 작동 하지 않는 요구 사항은 서비스의 예상 작업 동작과 관련이 있습니다.Nonfunctional requirements are related to the expected operational behavior of the service.

아키텍처와 관련 된 요구 사항에 대 한 5 가지 필수 범주가 있습니다 ( 아키텍처 핵심 요소).There are five essential categories of nonfunctional requirements, known as the pillars of architecture excellence:

  • 비용 최적화Cost optimization
  • 운영 우수성Operational excellence
  • 성능 효율성Performance efficiency
  • 안정성Reliability
  • 보안Security

운영 적합성을 검토 하기 위한 프로세스는 업무상 중요 한 작업이 핵심 요소 관련 된 비즈니스의 기대를 충족 하는지 확인 합니다.A process for operational fitness review ensures that your mission-critical workloads meet the expectations of your business with respect to the pillars.

프로덕션 환경에서 작업을 실행 하 여 발생 하는 문제를 완전히 이해 하 고 이러한 문제를 해결 하는 방법에 대 한 프로세스를 만듭니다.Create a process for operational fitness review to fully understand the problems that result from running workloads in a production environment, and how to remediate and resolve those problems. 이 문서에서는 기업에서이 목표를 달성 하는 데 사용할 수 있는 운영 적합성 검토에 대 한 개략적인 프로세스를 간략히 설명 합니다.This article outlines a high-level process for operational fitness review that your enterprise can use to achieve this goal.

Microsoft의 운영 적합성Operational fitness at Microsoft

처음부터 Microsoft에서 많은 팀은 Azure 플랫폼 개발에 참여 했습니다.From the outset, many teams across Microsoft have been involved in the development of the Azure platform. 이러한 크기와 복잡성을 비롯 한 프로젝트의 품질 및 일관성을 보장 하기 어렵습니다.It's difficult to ensure quality and consistency for a project of such size and complexity. 기본 작동 하지 않는 요구 사항을 정기적으로 열거 하 고 구현 하려면 강력한 프로세스가 필요 합니다.You need a robust process to enumerate and implement fundamental nonfunctional requirements on a regular basis.

Microsoft에서 수행 하는 프로세스는이 문서에 설명 된 프로세스의 기본을 형성 합니다.The processes that Microsoft follows form the basis for the processes outlined in this article.

문제 이해Understand the problem

시작: 마이그레이션 가속화에서 설명한 대로 엔터프라이즈의 디지털 변환 첫 번째 단계는 Azure를 채택 하 여 해결할 비즈니스 문제를 식별 하는 것입니다.As discussed in Get started: Accelerate migration, the first step in an enterprise's digital transformation is to identify the business problems to be solved by adopting Azure. 다음 단계는 클라우드 기능을 포함 하도록 작업을 클라우드로 마이그레이션하거나 기존 온-프레미스 서비스를 적용 하는 등 문제에 대 한 개략적인 해결책을 결정 하는 것입니다.The next step is to determine a high-level solution to the problem, such as migrating a workload to the cloud or adapting an existing, on-premises service to include cloud functionality. 마지막으로 솔루션을 디자인 하 고 구현 합니다.Finally, you design and implement the solution.

이 프로세스가 진행 되는 동안 서비스의 기능 (서비스에서 수행할 기능 요구 사항 집합)에 집중 하는 경우가 많습니다.During this process, the focus is often on the features of the service: the set of functional requirements that you want the service to perform. 예를 들어 제품 배달 서비스에는 제품의 원본 및 대상 위치를 확인 하 고, 배달 중에 제품을 추적 하 고, 고객에 게 알림을 보내는 기능이 필요 합니다.For example, a product-delivery service requires features for determining the source and destination locations of the product, tracking the product during delivery, and sending notifications to the customer.

이와 달리 작동 하지 않는 요구 사항은 서비스의 가용성, 복원 력, 확장성등의 속성과 관련이 있습니다.The nonfunctional requirements, in contrast, relate to properties such as the service's availability, resiliency, and scalability. 이러한 속성은 서비스의 특정 기능에 대 한 최종 기능에 직접적인 영향을 주지 않으므로 기능 요구 사항과 다릅니다.These properties differ from the functional requirements because they don't directly affect the final function of any particular feature in the service. 그러나 작동 하지 않는 요구 사항은 서비스의 성능 및 연속성과 관련이 있습니다.However, nonfunctional requirements do relate to the performance and continuity of the service.

SLA (서비스 수준 계약) 측면에서 일부 작동 하지 않는 요구 사항을 지정할 수 있습니다.You can specify some nonfunctional requirements in terms of a service-level agreement (SLA). 예를 들어 가용성의 백분율로 서비스 연속성을 표현할 수 있습니다. "사용 가능한 99.99% 시간"입니다.For example, you can express service continuity as a percentage of availability: "available 99.99 percent of the time". 기타 작동 하지 않는 요구 사항은 정의 하기가 더 어렵고 프로덕션 요구가 변경 됨에 따라 변경 될 수 있습니다.Other nonfunctional requirements might be more difficult to define and might change as production needs change. 예를 들어, 소비자 지향 서비스는 인기의 서 면에서 예기치 않은 처리량 요구 사항을 직면 하 게 될 수 있습니다.For example, a consumer-oriented service might face unanticipated throughput requirements after a surge of popularity.

참고

복원 력 요구 사항에 대 한 자세한 내용은 신뢰할 수 있는 Azure 응용 프로그램 디자인을 참조 하세요.For more information about resiliency requirements, see Designing reliable Azure applications. 이 문서에는 RPO (복구 지점 목표), RTO (복구 시간 목표) 및 SLA와 같은 개념에 대 한 설명이 포함 되어 있습니다.That article includes explanations of concepts like recovery-point objective (RPO), recovery-time objective (RTO), and SLA.

운영 적합성을 검토 하기 위한 프로세스Process for operational fitness review

엔터프라이즈 서비스의 성능과 연속성을 유지 하기 위한 핵심은 운영 적합성을 검토 하기 위한 프로세스를 구현 하는 것입니다.The key to maintaining the performance and continuity of an enterprise's services is to implement a process for operational fitness review.

운영 적합성 검토 프로세스 개요

높은 수준의 프로세스에는 두 단계가 있습니다.At a high level, the process has two phases. 전제 조건 단계 에서 요구 사항이 설정 되어 지원 서비스에 매핑됩니다.In the prerequisites phase, the requirements are established and mapped to supporting services. 이 단계는 자주 발생 하거나 새 작업이 도입 될 때 발생 합니다.This phase occurs infrequently: perhaps annually or when new operations are introduced. 필수 구성 요소 단계의 출력은 flow 단계 에서 사용 됩니다.The output of the prerequisites phase is used in the flow phase. 흐름 단계가 매월 처럼 더 자주 발생 합니다.The flow phase occurs more frequently, such as monthly.

필수 구성 요소 단계Prerequisites phase

이 단계의 단계는 중요 한 서비스에 대 한 정기적인 검토를 수행 하기 위한 요구 사항을 캡처합니다.The steps in this phase capture the requirements for conducting a regular review of the important services.

  1. 중요 한 비즈니스 작업을 식별 합니다.Identify critical business operations. 회사의 중요 업무 비즈니스 운영을 식별합니다.Identify the enterprise's mission-critical business operations. 비즈니스 운영은 지원되는 모든 서비스 기능과는 독립적입니다.Business operations are independent from any supporting service functionality. 즉, 비즈니스 작업은 비즈니스에서 수행 해야 하는 실제 작업과 IT 서비스 집합에서 지원 되는 작업을 나타냅니다.In other words, business operations represent the actual activities that the business needs to perform and that are supported by a set of IT services.

    업무에 중요 한 (또는 업무상 중요) 라는 용어는 작업이 방해가 경우 비즈니스에 심각한 영향을 미칩니다.The term mission-critical (or business-critical) reflects a severe impact on the business if the operation is impeded. 예를 들어 온라인 대리점에는 "고객이 장바구니에 항목을 추가 하도록 설정" 또는 "신용 카드 지불 처리"와 같은 비즈니스 작업이 있을 수 있습니다.For example, an online retailer might have a business operation, such as "enable a customer to add an item to a shopping cart" or "process a credit card payment." 이러한 작업 중 하나라도 실패 하면 고객이 트랜잭션을 완료할 수 없으며 enterprise에서 판매를 실현 하지 못합니다.If either of these operations fails, a customer can't complete the transaction and the enterprise fails to realize sales.

  2. 작업을 서비스에 매핑합니다.Map operations to services. 중요 한 비즈니스 작업을 지 원하는 서비스에 매핑합니다.Map the critical business operations to the services that support them. 쇼핑 카트 예제에서는 재고 재고 관리 서비스 및 쇼핑 카트 서비스를 비롯 한 여러 서비스가 포함 될 수 있습니다.In the shopping-cart example, several services might be involved, including an inventory stock-management service and a shopping-cart service. 신용 카드 지불을 처리 하기 위해 온-프레미스 지불 서비스는 타사 결제 처리 서비스와 상호 작용할 수 있습니다.To process a credit-card payment, an on-premises payment service might interact with a third-party, payment-processing service.

  3. 서비스 종속성을 분석 합니다.Analyze service dependencies. 대부분의 비즈니스 작업에는 여러 지원 서비스 간의 오케스트레이션이 필요 합니다.Most business operations require orchestration among multiple supporting services. 이러한 서비스를 통해 서비스와 중요 업무용 트랜잭션의 흐름 간의 종속성을 이해 하는 것이 중요 합니다.It's important to understand the dependencies between the services, and the flow of mission-critical transactions through these services.

    또한 온-프레미스 서비스와 Azure 서비스 간의 종속성을 고려 합니다.Also consider the dependencies between on-premises services and Azure services. 쇼핑 카트 예제에서 재고 재고 관리 서비스는 온-프레미스에서 호스트 되 고 실제 웨어하우스에서 직원 들이 입력 한 데이터를 수집 하는 것일 수 있습니다.In the shopping-cart example, the inventory stock-management service might be hosted on-premises and ingest data entered by employees from a physical warehouse. 그러나 Azure Storage와 같은 Azure 서비스 또는 Azure Cosmos DB와 같은 데이터베이스에 데이터를 저장할 수 있습니다.However, it might store data off-premises in an Azure service, such as Azure Storage, or a database, such as Azure Cosmos DB.

이러한 활동의 출력은 서비스 작업에 대한 일단의 성과 기록표 메트릭 입니다.An output from these activities is a set of scorecard metrics for service operations. 성과 기록표는 가용성, 확장성 및 재해 복구와 같은 기준을 측정 합니다.The scorecard measures criteria such as availability, scalability, and disaster recovery. 성과 기록표 메트릭은 서비스에서 충족 해야 하는 운영 조건을 표현 합니다.Scorecard metrics express the operational criteria that you expect the service to meet. 이러한 메트릭은 서비스 작업에 적절 한 세분성 수준으로 표현할 수 있습니다.These metrics can be expressed at any level of granularity that's appropriate for the service operation.

성과 기록표는 비즈니스 소유자와 엔지니어링 소유자 간의 의미 있는 토론을 용이하게 하기 위해 간단한 용어로 표현해야 합니다.The scorecard should be expressed in simple terms to facilitate meaningful discussion between the business owners and engineering. 예를 들어 확장성을 위한 성과 기록표 메트릭은 간단한 방법으로 색으로 구분 될 수 있습니다.For example, a scorecard metric for scalability might be color-coded in a simple way. 녹색은 정의 된 조건을 충족 하는 것을 의미 하 고, 노란색은 정의 된 조건을 충족 하는 데 실패 하 고 계획 된 수정을 적극적으로 구현 하며, 빨간색은 계획 또는 작업 없이 정의 된 조건을 충족 하지 못할 수 있음을 의미Green means meeting the defined criteria, yellow means failing to meet the defined criteria but actively implementing a planned remediation, and red means failing to meet the defined criteria with no plan or action.

이러한 메트릭에 비즈니스 요구 사항을 직접 반영 해야 한다는 점을 강조 하는 것이 중요 합니다.It's important to emphasize that these metrics should directly reflect business needs.

서비스 검토 단계Service-review phase

서비스 검토 단계는 운영 적합성 검토의 핵심입니다.The service-review phase is the core of the operational fitness review. 여기에는 다음 단계가 포함 됩니다.It involves these steps:

  1. 서비스 메트릭을 측정 합니다.Measure service metrics. 서비스를 모니터링 하는 데 성과 기록표 메트릭을 사용 하 여 서비스가 비즈니스 기대치를 충족 하는지 확인 합니다.Use the scorecard metrics to monitor the services, to ensure that the services meet the business expectations. 서비스 모니터링은 필수적입니다.Service monitoring is essential. 작동 하지 않는 요구 사항과 관련 하 여 서비스 집합을 모니터링할 수 없는 경우 해당 하는 성과 기록표 메트릭을 red로 간주 합니다.If you can't monitor a set of services with respect to the nonfunctional requirements, consider the corresponding scorecard metrics to be red. 이 경우 재구성에 대한 첫 번째 단계는 적절한 서비스 모니터링을 구현하는 것입니다.In this case, the first step for remediation is to implement the appropriate service monitoring. 예를 들어 비즈니스에서 서비스가 99.99%의 가용성을 제공 하는 것으로 예상 하지만 가용성을 측정할 수 있는 프로덕션 원격 분석이 없는 경우, 요구 사항을 충족 하 고 있지 않다고 가정 합니다.For example, if the business expects a service to operate with 99.99 percent availability, but there is no production telemetry in place to measure availability, assume that you're not meeting the requirement.

  2. 관리를 계획 합니다.Plan remediation. 메트릭이 허용 되는 임계값 보다 낮은 각 서비스 작업에 대해 서비스를 수정 하 여 작업을 허용 가능한 수준으로 전환 하는 비용을 결정 합니다.For each service operation for which metrics fall below an acceptable threshold, determine the cost of remediating the service to bring operation to an acceptable level. 서비스를 수정 하는 데 필요한 비용이 서비스의 예상 수익 창출 보다 큰 경우에는 고객 환경과 같은 무형의 비용을 고려 하 여 진행 하세요.If the cost of remediating the service is greater than the expected revenue generation of the service, move on to consider the intangible costs, such as customer experience. 예를 들어 고객이 서비스를 사용 하 여 성공적으로 주문 하는 데 어려움이 있는 경우 대신 경쟁 업체를 선택할 수 있습니다.For example, if customers have difficulty placing a successful order by using the service, they might choose a competitor instead.

  3. 재구성을 구현 합니다.Implement remediation. 비즈니스 소유자 및 엔지니어링 팀이 계획에 동의한 후에는 구현 합니다.After the business owners and engineering team agree on a plan, implement it. 성과 기록표 메트릭을 검토할 때마다 구현 상태를 보고 합니다.Report the status of the implementation whenever you review scorecard metrics.

이 프로세스는 반복적 이며 엔터프라이즈에 전용 팀이 있는 것이 가장 좋습니다.This process is iterative, and ideally your enterprise has a team dedicated to it. 이 팀은 정기적으로 기존 수정 프로젝트를 검토 하 고, 새 워크 로드의 기본 검토를 시작 하 고, 기업의 전반적인 성과 기록표를 추적 해야 합니다.This team should meet regularly to review existing remediation projects, kick off the fundamental review of new workloads, and track the enterprise's overall scorecard. 팀은 예정 된 상태 이거나 메트릭을 충족 하지 못하는 경우에도 수정 팀을 보유 하는 권한을 보유 해야 합니다.The team should also have the authority to hold remediation teams accountable if they're behind schedule or fail to meet metrics.

검토 팀의 구조Structure of the review team

운영 적합성 검토를 담당 하는 팀은 다음 역할로 구성 됩니다.The team responsible for operational fitness review is composed of the following roles:

  • 비즈니스 소유자: 비즈니스에 중요 업무용 작업을 식별 하 고 우선 순위를 지정 하는 비즈니스 정보를 제공 합니다.Business owner: Provides knowledge of the business to identify and prioritize each mission-critical business operation. 또한이 역할은 완화 비용과 비즈니스 영향을 비교 하 고 수정에 대 한 최종 결정을 유도 합니다.This role also compares the mitigation cost to the business impact, and drives the final decision on remediation.

  • 비즈니스 대표: 비즈니스 작업을 개별 부분으로 분할 하 고, 온-프레미스 또는 클라우드에서와 관계 없이 이러한 파트를 서비스 및 인프라에 매핑합니다.Business advocate: Breaks down business operations into discreet parts, and maps those parts to services and infrastructure, whether on-premises or in the cloud. 이 역할에는 각 비즈니스 운영과 관련된 기술에 대한 전문 지식이 필요합니다.The role requires deep knowledge of the technology associated with each business operation.

  • 엔지니어링 소유자: 비즈니스 작업과 연결 된 서비스를 구현 합니다.Engineering owner: Implements the services associated with the business operation. 이러한 개인은 검토 팀에서 확인 하지 않은 요구 사항 문제에 대 한 솔루션의 디자인, 구현 및 배포에 참여할 수 있습니다.These individuals might participate in the design, implementation, and deployment of any solutions for nonfunctional requirement problems that are uncovered by the review team.

  • 서비스 소유자: 비즈니스의 응용 프로그램 및 서비스를 운영 합니다.Service owner: Operates the business's applications and services. 이러한 개인은 이러한 애플리케이션과 서비스에 대한 로깅 및 사용량 현황 데이터를 수집합니다.These individuals collect logging and usage data for these applications and services. 이 데이터는 문제를 식별 하 고 배포 후에 수정 사항을 확인 하는 데 사용 됩니다.This data is used both to identify problems and to verify fixes after they're deployed.

검토 회의Review meeting

검토 팀이 정기적으로 충족 하는 것이 좋습니다.We recommend that your review team meet on a regular basis. 예를 들어 팀은 월별을 충족 하 고 분기별으로 선임 리더십에 상태 및 메트릭을 보고할 수 있습니다.For example, the team might meet monthly, and then report status and metrics to senior leadership on a quarterly basis.

특정 요구 사항에 맞게 프로세스 및 모임 세부 정보를 조정 합니다.Adapt the details of the process and meeting to fit your specific needs. 다음 작업을 시작 지점으로 사용하는 것이 좋습니다.We recommend the following tasks as a starting point:

  1. 비즈니스 소유자 및 비즈니스 담당자는 엔지니어링 및 서비스 소유자의 입력으로 각 비즈니스 작업에 대해 작동 하지 않는 요구 사항을 열거 하 고 결정 합니다.The business owner and business advocate enumerate and determine the nonfunctional requirements for each business operation, with input from the engineering and service owners. 이전에 식별 된 비즈니스 작업의 경우 우선 순위를 검토 하 고 확인 합니다.For business operations that have been identified previously, review and verify the priority. 새 비즈니스 작업의 경우 기존 목록에 우선 순위를 할당 합니다.For new business operations, assign a priority in the existing list.

  2. 엔지니어링 소유자와 서비스 소유자는 비즈니스 운영의 현재 상태를 해당 온-프레미스 서비스와 클라우드 서비스에 매핑합니다.The engineering and service owners map the current state of business operations to the corresponding on-premises and cloud services. 매핑은 종속성 트리로 표시 되는 각 서비스의 구성 요소 목록입니다.The mapping is a list of the components in each service, oriented as a dependency tree. 엔지니어링 및 서비스 소유자는 트리를 통해 중요 한 경로를 결정 합니다.The engineering and service owners then determine the critical paths through the tree.

  3. 엔지니어링 소유자와 서비스 소유자는 이전 단계에서 나열된 서비스에 대한 운영 로깅 및 모니터링의 현재 상태를 검토합니다.The engineering and service owners review the current state of operational logging and monitoring for the services listed in the previous step. 강력한 로깅 및 모니터링은 중요 한 요구 사항을 충족 하지 못하는 데 기여 하는 서비스 구성 요소를 식별 합니다.Robust logging and monitoring are critical: they identify service components that contribute to a failure to meet nonfunctional requirements. 충분 한 로깅 및 모니터링이 수행 되지 않는 경우 팀은 계획을 만들고 구현 하 여 적절 하 게 배치 해야 합니다.If sufficient logging and monitoring aren't in place, the team must put them in place by creating and implementing a plan.

  4. 팀은 새로운 비즈니스 운영에 대 한 성과 기록표 메트릭을 만듭니다.The team creates scorecard metrics for new business operations. 성과 기록표는 2 단계에서 식별 된 각 서비스에 대 한 구성 요소 목록으로 구성 됩니다.The scorecard consists of the list of constituent components for each service identified in step 2. 이는 작동 하지 않는 요구 사항에 맞게 조정 되며 각 구성 요소가 요구 사항을 얼마나 잘 충족 하는지 측정 합니다.It's aligned with the nonfunctional requirements, and includes a measure of how well each component meets the requirements.

  5. 구성 요소가 작동 하지 않는 요구 사항을 충족 하지 못하는 경우 팀은 개략적인 솔루션을 디자인 하 고 엔지니어링 소유자를 할당 합니다.For constituent components that fail to meet nonfunctional requirements, the team designs a high-level solution, and assigns an engineering owner. 이 시점에서 비즈니스 소유자 및 비즈니스 담당자는 비즈니스 운영의 예상 수익을 기반으로 하 여 수정 작업의 예산을 수립 합니다.At this point, the business owner and business advocate establish a budget for the remediation work, based on the expected revenue of the business operation.

  6. 마지막으로 팀은 지속적인 수정 작업을 검토 합니다.Finally, the team conducts a review of the ongoing remediation work. 진행 중인 작업의 각 성과 기록표 메트릭은 예상 된 조건에 대해 검토 됩니다.Each of the scorecard metrics for work in progress is reviewed against the expected criteria. 메트릭 기준을 충족 하는 구성 요소의 구성 요소에 대해 서비스 소유자는 조건을 충족 하는지 확인 하기 위해 로깅 및 모니터링 데이터를 제공 합니다.For constituent components that meet metric criteria, the service owner presents logging and monitoring data to confirm that the criteria are met. 메트릭 기준을 충족 하지 않는 구성 요소의 경우 각 엔지니어링 소유자는 조건을 충족 하지 못하게 하는 문제를 설명 하 고 수정에 대 한 새로운 디자인을 제공 합니다.For those constituent components that don't meet metric criteria, each engineering owner explains the problems that are preventing criteria from being met, and presents any new designs for remediation.

  • Microsoft Azure Well-Architected Framework: 워크 로드의 품질을 향상 시키기 위해 개념 안내 하는 방법에 대해 알아봅니다.Microsoft Azure Well-Architected Framework: Learn about guiding tenets for improving the quality of a workload. 이 프레임워크는 다음과 같이 뛰어난 아키텍처의 5가지 핵심 요소로 이루어져 있습니다.The framework consists of five pillars of architecture excellence:
    • 비용 최적화Cost optimization
    • 운영 우수성Operational excellence
    • 성능 효율성Performance efficiency
    • 안정성Reliability
    • 보안Security
  • Azure 응용 프로그램에 대 한 10 가지 디자인 원칙Ten design principles for Azure applications. 애플리케이션의 확장성, 복원력 및 관리성을 높이려면 다음과 같은 디자인 원칙을 따르십시오.Follow these design principles to make your application more scalable, resilient, and manageable.
  • Azure 용 복원 력 있는 응용 프로그램 디자인Designing resilient applications for Azure. 디자인 및 구현에서 배포 및 작업까지 응용 프로그램의 수명 동안 구조화 된 방법을 사용 하 여 신뢰할 수 있는 시스템을 구축 하 고 유지 관리 합니다.Build and maintain reliable systems using a structured approach over the lifetime of an application, from design and implementation to deployment and operations.
  • 클라우드 디자인 패턴.Cloud design patterns. 디자인 패턴을 사용 하 여 아키텍처 핵심 요소 응용 프로그램을 빌드합니다.Use design patterns to build applications on the pillars of architecture excellence.
  • Azure Advisor.Azure Advisor. Azure Advisor는 고가용성, 보안, 성능 및 비용에 대 한 리소스를 최적화 하는 데 도움이 되는 사용 현황 및 구성에 따라 개인 설정 된 권장 사항을 제공 합니다.Azure Advisor provides personalized recommendations based on your usage and configurations to help optimize your resources for high availability, security, performance, and cost.