일반적인 클라우드 운영 모델 검토 및 비교

운영 모델은 현재 요구 사항 및 제약 조건을 기반으로 지원하는 비즈니스에 고유합니다. 그러나 운영 모델은 눈송이가 아닙니다. 고객 운영 모델에는 몇 가지 일반적인 패턴이 있습니다. 이 문서에서는 가장 일반적인 네 가지 패턴에 대해 설명합니다.

운영 모델 비교

다음 이미지는 복잡성 범위를 기준으로 가장 덜 복잡한(탈중앙형)부터 가장 복잡한(전역적 작업)까지의 일반적인 운영 모델을 매핑합니다. 다음 표는 몇 가지 다른 특성의 상대적인 값을 기준으로 동일한 운영 모델을 비교합니다.

우선 순위 또는 범위

클라우드 운영 모델은 주로 다음 두 가지 요소에 의해 주도됩니다.

• 전략적 우선 순위 또는 동기
• 관리할 포트폴리오의 범위

	탈중앙화된 운영(ops)	중앙 집중식 운영(ops)	엔터프라이즈 운영(ops)	분산 작업(ops)
전략적 우선 순위 또는 동기	혁신	컨트롤	민주화	통합
포트폴리오 범위	작업	랜딩 존	클라우드 플랫폼	전체 포트폴리오
워크로드 환경	높은 복잡성	낮은 복잡성	중간 복잡성	중간 또는 가변 복잡성
랜딩 존	해당 없음	높은 복잡성	중간 ~ 낮은 복잡성	낮은 복잡성
기초 유틸리티	해당 없음	N/A 또는 낮은 지원	중앙 집중식 및 더 많은 지원	대부분의 지원
Cloud Foundation	해당 없음	해당 없음	하이브리드, 공급자별 또는 지역 기반	분산 및 동기화

• 전략적 우선 순위 또는 동기: 각 운영 모델은 클라우드 채택을 위한 일반적인 전략적 동기를 제공합니다. 그러나 일부 운영 모델은 특정 동기를 간소화합니다.

• 포트폴리오 scope: 포트폴리오 scope 특정 운영 모델 디자인에서 지원하는 가장 큰 scope 식별합니다. 예를 들어, 중앙 집중식 운영은 몇몇 랜딩 존을 위해 설계되었습니다. 그러나 운영 모델 결정으로 organization 운영 위험이 발생할 수 있습니다. 운영 위험은 대규모 복잡한 포트폴리오를 관리하려고 할 때 발생합니다. 이러한 포트폴리오에는 랜딩 존 설계에 많은 랜딩 존 또는 가변 복잡성이 필요할 수 있습니다.

중요

클라우드를 채택하면 현재 운영 모델에 대한 리플렉션이 트리거되는 경우가 많으며 공통 운영 모델에서 다른 운영 모델로 전환될 수 있습니다. 그러나 클라우드 채택만이 트리거는 아닙니다. 비즈니스 우선 순위와 클라우드 채택 범위는 포트폴리오 지원 방식을 변경할 수 있습니다. 또한 가장 적절하게 조정된 운영 모델에 다른 변화가 있을 수 있습니다. 이사회나 기타 경영진이 5년에서 10년 사이의 사업 계획을 수립할 때 이러한 계획에는 운영 모델을 조정하기 위한 요구 사항(명시적 또는 묵시적)이 포함되는 경우가 많습니다. 운영 모델은 결정을 내리는 데 도움이 되는 좋은 참고 자료입니다. 이러한 모델은 요구 사항 및 제약 조건을 충족하도록 변경되거나 사용자 지정해야 할 수 있습니다.

책임 조정

많은 팀과 개인이 다양한 기능을 지원해야 합니다. 그러나 각 일반적인 운영 모델은 의사 결정 결과에 대한 최종 책임을 한 팀 또는 개인에게 할당합니다. 이 방법은 운영 모델의 자금 조달 방식과 각 기능에 제공되는 지원 수준에 영향을 미칩니다.

	탈중앙화된 운영	중앙 집중식 운영	기업 운영	분산 운영
비즈니스 조정	워크로드 팀	중앙 클라우드 전략	CCoE	가변 - 광범위한 클라우드 전략 팀을 구성하려고 하나요?
클라우드 작업	워크로드 팀	중앙 IT	CCoE	포트폴리오 분석 기반 - 비즈니스 조정 및 비즈니스 약속 참조
클라우드 거버넌스	워크로드 팀	중앙 IT	CCoE	거버넌스의 여러 계층
클라우드 보안	워크로드 팀	SOC(보안 운영 센터)	CCoE + SOC	혼합 - 보안 전략 정의 참조
클라우드 자동화 및 DevOps	워크로드 팀	중앙 IT 또는 해당 사항 없음	CCoE	포트폴리오 분석 기반 - 비즈니스 조정 및 비즈니스 약속 참조

Azure에서 운영 모델 구현 가속화

운영 모델 정의에서 설명한 것처럼 클라우드 채택 프레임워크의 각 방법론은 운영 모델을 개발하기 위한 구조화된 경로를 제공합니다. 이러한 방법론은 클라우드 운영 모델 채택의 격차로 인해 발생하는 장애물을 극복하는 데 도움이 될 수 있습니다.

다음 표에는 운영 모델 구현을 가속화하는 방법이 요약되어 있습니다.

	탈중앙화된 운영	중앙 집중식 운영	기업 운영	분산 운영
시작 지점	Azure WAF(Well-Architected 프레임워크)	Azure 랜딩 존: 소규모로 시작하는 옵션	Azure 랜딩 존: CAF 엔터프라이즈 규모	비즈니스 조정
반복 횟수	워크로드에 중점을 두면 팀이 WAF 내에서 반복할 수 있습니다.	소규모로 시작하는 옵션은 각 방법론에 대해 더 많은 반복이 필요하지만 클라우드 채택 노력이 성숙함에 따라 수행할 수 있습니다.	참조 구현에서 알 수 있듯이 향후 반복에서는 일반적으로 사소한 구성 추가에 중점을 둡니다.	Azure 랜딩 존 구현 옵션을 검토하여 작업 기준에 가장 적합한 옵션부터 시작합니다. 해당 옵션의 설계 원칙에 정의된 반복 경로를 따릅니다.

분산 운영

운영은 항상 복잡합니다. 작업의 scope 하나의 워크로드 또는 작은 워크로드 컬렉션으로 제한하는 경우 복잡성을 제어합니다. 분산 운영은 일반적인 운영 모델 중 가장 덜 복잡합니다. 이러한 형태의 작업에서는 모든 워크로드가 전용 워크로드 팀에서 독립적으로 작동합니다.

• 우선 순위: 팀은 여러 워크로드에서 중앙 집중식 제어 또는 표준화보다 혁신을 측정합니다.
• 명백한 장점: 워크로드와 비즈니스 팀이 설계, 빌드 및 운영을 완전히 제어할 수 있도록 하여 혁신 속도를 최대화합니다.
• 명백한 단점: 워크로드 간 표준화 감소, 공유 서비스를 통한 규모의 경제, 일관된 거버넌스 중앙 집중식 규정 준수 노력.
• 위험: 이 방법은 워크로드 포트폴리오를 관리할 때 위험을 초래합니다. 워크로드 팀에는 중앙 IT 기능을 전담하는 전문 팀이 있을 수 있습니다. 이 운영 모델은 일부 조직, 특히 타사 규정 준수 요구 사항을 따라야 하는 회사에서 고위험 옵션으로 간주됩니다.
• 지침: 탈중앙화 작업은 워크로드 수준 의사 결정으로 제한됩니다. Microsoft Azure Well-Architected Framework는 해당 scope 내에서 내린 결정을 지원합니다. 클라우드 채택 프레임워크 내의 프로세스 및 지침은 분산 운영에 필요하지 않은 오버헤드를 추가할 수 있습니다.

분산 운영의 장점

• 비용 관리: 운영 비용은 단일 사업부에 쉽게 매핑됩니다. 워크로드별 작업은 더 큰 워크로드 최적화를 지원합니다.
• 책임: 일반적으로 이러한 형태의 작업은 오버헤드를 최소화하기 위해 자동화에 크게 의존합니다. 책임은 릴리스 관리를 위한 DevOps 및 파이프라인에 초점을 맞추는 경향이 있습니다. 이 유형의 작업은 개발 중에 더 빠른 배포 및 짧은 피드백 주기를 지원합니다.
• 표준화: 소스 코드 및 배포 파이프라인을 사용하여 릴리스에서 릴리스까지 환경을 표준화합니다.
• 운영 지원: 운영에 영향을 미치는 결정은 해당 워크로드의 요구 사항과 운영 결정을 단순화하는 것에만 관련됩니다. DevOps 커뮤니티의 멤버는 운영 지원이 더 좁은 운영 범위 때문에 가장 순수한 운영 형태라고 말합니다.
• 전문성: DevOps 및 개발 팀은 이 방법으로 가장 큰 힘을 얻고 시장 변화를 주도하는 데 가장 적은 저항을 야기하는 환경을 누립니다.
• 랜딩 존 설계: 특정한 운영상의 이점이 없습니다.
• 기본 유틸리티: 특정한 운영상의 이점이 없습니다.
• 업무 분리: 특정한 운영상의 이점이 없습니다.

분산 운영의 단점

• 비용 관리: 기업 비용은 계산하기가 더 어렵습니다. 중앙 집중식 거버넌스 팀이 없으면 균일한 비용 제어 또는 최적화를 구현하기가 더 어렵습니다. 각 워크로드에는 배포된 자산 및 인력 할당이 중복될 수 있으므로 이 모델은 대규모일 경우 비용이 많이 들 수 있습니다.
• 책임: 중앙 집중식 지원이 부족하면 워크로드 팀이 거버넌스, 보안, 운영 및 변경 관리를 전적으로 책임집니다. 이러한 작업이 코드 검토 및 릴리스 파이프라인에서 자동화되지 않은 경우 지원 부족이 문제가 됩니다.
• 표준화: 워크로드 포트폴리오의 표준화는 가변적이며 일관성이 없습니다.
• 운영 지원: 여러 워크로드에서 모범 사례를 만드는 동안 확장 효율성을 놓치는 경우가 많습니다.
• 전문성: 팀 구성원은 애플리케이션 설계 및 구성 내에서 거버넌스, 보안, 운영 및 변경 관리에 대해 현명하고 윤리적인 결정을 내릴 더 큰 책임이 있습니다. 필요한 전문 지식을 향상하려면 Microsoft Azure Well-Architected 검토 및 Azure Well-Architected Framework를 자주 참조하세요.
• 랜딩 존 설계: 랜딩 존은 워크로드와 관련이 없으며 이 방법에서 고려되지 않습니다.
• 기본 유틸리티: 워크로드 간에 공유되는 기본 서비스가 거의 없어(있는 경우) 확장 효율성이 떨어집니다.
• 업무 분리: DevOps 및 개발 팀에 대한 요구 사항이 높아짐에 따라 해당 팀의 높은 권한 사용량이 증가합니다. 업무 분리가 필요한 경우 이 방법을 사용하기 위해 DevOps 성숙도에 많은 투자를 해야 할 수 있습니다.

중앙 집중식 운영

안정적인 상태 환경에서는 아키텍처 또는 개별 워크로드의 고유한 운영 요구 사항에 중점을 둘 필요가 없습니다. 중앙 작업은 주로 안정적인 상태의 워크로드로 구성된 기술 환경에서 표준이 되는 경향이 있습니다. 안정적인 상태 작업의 예에는 COTS(상용 기성품) 애플리케이션 또는 릴리스 주기가 느린 잘 정립된 사용자 지정 애플리케이션과 같은 것들이 포함됩니다. 변동률이 정기적인 업데이트 및 패치에 의해 주도되는 경우 운영을 중앙 집중화하는 것이 포트폴리오를 관리하는 효과적인 방법일 수 있습니다.

• 우선 순위: 우선 순위는 혁신에 대한 중앙 제어이며 최신적인 클라우드 운영으로의 문화적 변화에 대한 기존 운영 프로세스를 측정합니다.
• 명백한 장점: 중앙 집중화는 규모의 경제, 동급 최고의 제어 및 표준화된 운영을 도입하고 클라우드 환경에서 가장 잘 작동합니다. 이러한 환경에는 클라우드 운영을 기존 운영 및 프로세스에 통합하기 위한 특정 구성이 필요합니다. 중앙 집중화는 적절한 아키텍처 복잡성과 규정 준수 요구 사항이 있는 수백 개의 워크로드 포트폴리오에서 가장 유리합니다.
• 명백한 단점: 대규모 워크로드 포트폴리오의 요구 사항을 충족하도록 크기 조정하면 프로덕션 워크로드에 대한 운영 결정을 내리는 중앙 집중식 팀에 상당한 부담이 될 수 있습니다. 기술 자산이 1,000개 이상의 VM, 애플리케이션 또는 데이터 원본을 확장할 것으로 예상되는 경우 18~24개월 내에 엔터프라이즈 모델을 고려할 수 있습니다.
• 위험: 이 방법은 중앙 집중화를 더 적은 수의 구독(종종 하나의 프로덕션 구독)으로 제한합니다. 클라우드 여정의 후반부에 리팩터링할 때 상당한 위험이 수반되며 이는 채택 계획을 방해할 수 있습니다. 재작업을 피하려면 세분화, 환경 경계, ID 도구 및 기타 기본 요소에 중점을 두세요.
• 지침: "소규모로 시작하여 확장" 개발 속도에 맞춰진 Azure 랜딩 존 구현 옵션은 건전한 출발점을 만듭니다. 이러한 옵션을 사용하여 채택 활동을 가속화할 수 있습니다. 그러나 성공하려면 허용 가능한 위험 허용 범위 내에서 조기 채택 노력을 안내하는 명확한 정책을 수립합니다. 방법론을 통제하고 관리하면 병렬로 작업을 성숙시키는 프로세스를 만드는 데 도움이 됩니다. 이러한 단계를 따르는 것은 작업이 성숙함에 따라 증가된 위험을 허용하기 전에 완료해야 하는 단계 관문 역할을 합니다.

중앙 집중식 운영의 장점

• 비용 관리: 여러 워크로드에 걸쳐 공유 서비스를 중앙 집중화하면 규모의 경제를 실현하고 중복 작업을 제거할 수 있습니다. 중앙 팀은 전사적 크기 조정 및 확장 최적화를 통해 비용 절감을 신속하게 구현할 수 있습니다.
• 책임: 중앙 집중식 전문화 및 표준화는 더 높은 안정성, 더 나은 운영 성능 및 최소한의 변경 관련 중단으로 이어질 수 있습니다. 이 접근 방식은 워크로드 중심 팀에 대한 광범위한 기술 압박을 줄입니다.
• 표준화: 일반적으로 중앙 집중식 모델이 중복 시스템 또는 작업이 적기 때문에 표준화 및 운영 비용이 가장 낮습니다.
• 운영 지원: 복잡성을 줄이고 작업을 중앙 집중화하면 소규모 IT 팀이 작업을 더 쉽게 지원할 수 있습니다.
• 전문성: 지원 팀을 중앙 집중화하면 보안, 위험, 거버넌스 및 운영 전문가가 비즈니스에 중요한 결정을 내릴 수 있습니다.
• 랜딩 존 설계: 중앙 IT는 랜딩 존 및 구독 수를 최소화하여 복잡성을 줄입니다. 랜딩 존 디자인은 이전 데이터 센터 디자인을 모방하는 경향이 있어 전환 시간이 단축됩니다. 채택이 진행됨에 따라 공유 리소스가 별도의 구독 또는 플랫폼 기반으로 이동할 수 있습니다.
• 기본 유틸리티: 기존 데이터 센터 디자인을 클라우드로 전달하면 온-프레미스 도구 및 작업을 모방하는 기본 공유 서비스가 생성됩니다. 온-프레미스 작업이 기본 운영 모델인 경우 장점도 있지만 몇 가지 단점이 있습니다. 온-프레미스 운영은 전환 시간을 줄이고, 규모의 경제를 활용하며, 온-프레미스와 클라우드 호스팅 워크로드 간의 일관된 운영 프로세스를 지원합니다. 이 접근 방식을 사용하면 단기적인 복잡성과 노력을 줄이고 소규모 팀이 학습 곡선을 줄여 클라우드 운영을 지원할 수 있습니다.
• 업무 분리: 중앙 작업에서 업무 분리가 명확합니다. 중앙 IT는 프로덕션 환경을 제어하고 다른 팀의 상승된 권한에 대한 필요성을 줄입니다. 이 방법은 상승된 권한이 있는 계정 수를 제한하여 위반을 줄입니다.

중앙 집중식 운영의 단점

• 비용 관리: 중앙 팀이 워크로드 수준에서 효과적인 최적화를 생성하기 위해 워크로드 아키텍처를 항상 이해하는 것은 아닙니다. 이러한 이해 부족으로 인해 잘 조정된 워크로드 작업에서 발생하는 비용 절감의 양이 제한됩니다. 워크로드 아키텍처를 완전히 이해하지 못하면 중앙 집중식 비용 최적화에 영향을 미칠 수 있으며, 이는 잘 설계된 워크로드의 성능, 규모 및 기타 핵심 요소에 영향을 미칩니다. 높은 프로필 워크로드에 엔터프라이즈 차원의 비용 변경을 적용하기 전에 중앙 IT 팀은 Microsoft Azure Well-Architected 검토를 이해하고 완료해야 합니다.
• 책임: 프로덕션 지원 및 액세스를 중앙 집중화하면 소수의 사람에게는 높은 운영 부담이 가해지고 각 개인은 더 큰 압박을 느끼게 됩니다. 이러한 개인에게 가해지는 압력으로 인해 배포된 워크로드에 대한 심층 검토를 수행해야 하며, 이를 통해 세부 보안 거버넌스 및 규정 준수 요구 사항을 준수하는지 유효성을 검사합니다.
• 표준화: 중앙 IT 방법을 사용하면 중앙 IT 담당자의 선형 크기 조정 없이 표준화를 크기 조정하기 어렵습니다.
• 운영 지원: 이 방법의 가장 큰 단점은 혁신을 측정하는 상당한 규모 및 변화와 관련되어 있습니다.
• 전문성: 개발자 및 DevOps 전문가는 이러한 유형의 환경에서 과소 평가되거나 너무 제한될 위험이 있습니다.
• 랜딩 존 설계: 데이터 센터 설계는 클라우드와 항상 관련이 있는 것은 아닌 이전 방법의 제약 조건을 기반으로 합니다. 이 방법을 따르면 환경 세분화를 재고하고 혁신 기회를 강화할 기회가 줄어듭니다. 랜딩 존 세분화가 부족하면 위반의 잠재적 영향, 거버넌스 복잡성 및 규정 준수 준수가 증가하고 클라우드 경험에서 채택에 방해가 될 수 있습니다. 위의 위험 섹션을 참조하세요.
• 기본 유틸리티: 디지털 변환 중에는 클라우드가 기본 운영 모델이 될 수 있습니다. 온-프레미스 운영을 위해 빌드된 중앙 도구는 운영 현대화 기회를 줄이고 운영 효율성을 높입니다. 채택 프로세스 초기에 운영 현대화를 선택하지 않는 것도 옵션입니다. 현대화는 클라우드 채택 과정에서 플랫폼 기반 구독을 만들어 달성할 수 있습니다. 이러한 노력은 고급 계획 없이 복잡하고 비용이 많이 들며 시간이 많이 걸릴 수 있습니다.
• 업무 분리: 중앙 운영은 일반적으로 두 경로 중 하나를 따르며 둘 다 혁신을 방해할 수 있습니다.
  • 옵션 1: 중앙 IT 외부의 팀에는 프로덕션을 모방하는 개발 환경에 대한 제한된 액세스 권한이 부여됩니다. 이 옵션은 실험을 방해합니다.
  • 옵션 2: Teams는 지원되지 않는 환경에서 개발 및 테스트합니다. 이 옵션은 배포 프로세스를 방해하고 배포 후 통합 테스트를 느리게 합니다.

엔터프라이즈 운영

엔터프라이즈 작업은 모든 클라우드 작업에 대해 제안된 대상 상태입니다. 기업 운영은 의사 결정과 책임을 단순화함으로써 제어와 혁신의 필요성 사이에서 균형을 이룹니다. 중앙 IT는 워크로드 팀을 지원하는 보다 용이한 클라우드 센터 또는 CCoE 팀으로 대체됩니다. CCoE 팀은 작업을 제어하거나 제한하는 것이 아니라 결정에 대한 책임을 워크로드 팀에 부여합니다. 워크로드 팀에는 잘 정의된 가드레일 내에서 혁신을 주도할 수 있는 더 많은 권한과 더 많은 책임이 부여됩니다.

• 우선 순위: 우선 순위를 지정하는 것은 기술적 결정을 민주화하는 것입니다. 기술적 결정의 민주화는 이전에 중앙 IT가 담당했던 책임을 워크로드 팀으로 이전시킵니다. 이러한 우선 순위 변화를 제공하기 위해 의사 결정은 사람이 운영하는 검토 프로세스에 덜 의존합니다. 이 방법은 클라우드 네이티브 도구를 사용하여 자동화된 검토, 거버넌스 및 적용을 지원합니다.
• 명백한 장점: 환경의 세분화와 업무의 분리를 통해 제어와 혁신 사이의 균형을 유지할 수 있습니다. 중앙 집중식 운영은 규정 준수를 높이고 안정적인 상태 운영을 필요로 하거나 더 큰 보안 위험을 나타내는 워크로드를 유지합니다. 반대로, 이 방법은 더 큰 혁신이 필요한 워크로드 및 환경의 중앙 집중식 제어를 줄이는 것을 지원합니다. 포트폴리오의 크기가 크면 제어와 혁신 사이의 균형에 어려움을 겪을 수 있습니다. 이러한 유연성 덕분에 운영상의 어려움을 줄이면서 수천 개의 워크로드를 쉽게 확장할 수 있습니다.
• 고유한 단점: 온-프레미스에서 작동하는 작업이 엔터프라이즈 클라우드 운영에서 제대로 작동하지 않을 수 있습니다. 운영에 대한 이러한 접근은 여러 측면에서 변화가 필요합니다. 제어와 책임에 대한 문화적 변화는 종종 가장 큰 도전이 됩니다. 문화적 변화에 따른 운영상의 변화는 구현, 성숙 및 안정화를 위해 시간과 헌신적인 노력이 필요합니다. 안정적인 워크로드에는 아키텍처 전환이 필요할 수 있으며, 문화, 운영 및 아키텍처 전환에 권한을 부여하고 지원하려면 도구 변경이 필요합니다. 이러한 변화에는 기본 클라우드 공급자에 대한 약속이 필요할 수 있습니다. 이러한 변경 전에 수행된 채택 작업에는 일반적인 리팩터링 노력을 넘어서는 상당한 재작업이 필요할 수 있습니다.
• 위험: 이 방법에는 변경 전략에 대한 경영진의 헌신이 필요합니다. 또한 학습 곡선을 극복하고 필요한 변화를 제공하기 위해 기술 팀의 헌신이 필요합니다. 장기적인 이점을 얻으려면 비즈니스, CCoE 및 중앙 IT 및 워크로드 팀 간의 장기적인 협력이 필요합니다.
• 지침: Azure 랜딩 존 옵션은 엔터프라이즈 규모로 정의됩니다. 이러한 옵션은 Azure에서 클라우드 네이티브 도구를 사용하여 기술 변경 내용이 제공하는 방법을 보여 주는 참조 구현을 제공합니다. 엔터프라이즈 규모의 방법은 이러한 구현을 최대한 활용하는 데 필요한 운영 및 문화 변화를 통해 팀을 안내합니다. 동일한 방법으로 참조 아키텍처를 조정하여 채택 전략 및 규정 준수 제약 조건을 충족하도록 환경을 구성할 수 있습니다. 엔터프라이즈 규모 구현 시 거버넌스 및 관리 방법론을 통해 프로세스를 정의할 수 있습니다. 이러한 프로세스는 운영 요구 사항에 맞게 규정 준수 및 운영 기능을 확장할 수 있습니다.

엔터프라이즈 운영의 장점

• 비용 관리: 중앙 팀은 포트폴리오 간 최적화 작업을 수행하고 개별 워크로드 팀이 더 심층적인 워크로드 최적화에 대한 책임을 지도록 합니다. 워크로드 중심 팀은 의사 결정을 내릴 수 있는 권한을 부여하고 이러한 결정이 부정적인 비용 영향을 미칠 때 명확성을 제공합니다. 중앙 및 워크로드 팀은 적절한 수준에서 비용 결정에 대한 책임을 공유합니다.
• 책임: 중앙 팀은 클라우드 네이티브 도구를 사용하여 가드레일을 정의, 적용 및 자동화합니다. 워크로드 팀의 노력은 CCoE 자동화 및 사례를 통해 가속화됩니다. 워크로드 팀은 이러한 가드레일 내에서 혁신을 주도하고 결정을 내릴 수 있습니다.
• 표준화: 중앙 집중식 가드레일과 기본 서비스는 모든 환경에서 일관성을 만듭니다.
• 운영 지원: 중앙 집중식 운영 지원이 필요한 워크로드는 안정적인 상태 제어가 있는 환경으로 분할됩니다. 업무 분할 및 분리를 통해 워크로드 팀은 전용 환경에서 운영 지원을 책임질 수 있습니다. 자동화된 클라우드 네이티브 도구는 중앙 집중식 운영 지원을 통해 모든 환경에 대한 최소 운영 기준을 보장합니다.
• 전문 지식: 보안, 위험, 거버넌스 및 운영과 같은 핵심 서비스를 중앙 집중화하면 적절한 중앙 전문 지식이 보장됩니다. 명확한 프로세스와 가드레일은 워크로드 팀이 보다 자세한 결정을 내릴 수 있도록 교육하고 권한을 부여합니다. 이러한 결정은 기술 규모에 따라 담당자를 선형적으로 확장할 필요 없이 중앙 집중식 전문가의 효과를 확장합니다.
• 랜딩 존 설계: 랜딩 존 설계는 포트폴리오의 요구 사항을 복제하여 명확한 보안, 거버넌스 및 책임 경계를 만듭니다. 이러한 경계는 클라우드에서 워크로드를 운영하는 데 필요합니다. 세분화 관행은 이전 데이터 센터 설계에서 만들어진 제약 조건과 유사하지 않을 수 있습니다. 엔터프라이즈 운영에서 랜딩 존 디자인은 덜 복잡하여 더 빠르게 확장할 수 있고 셀프 서비스 수요에 대한 장벽을 줄일 수 있습니다.
• 기본 유틸리티: 기본 유틸리티는 플랫폼 기반이라고 하는 별도의 중앙 제어 구독에서 호스팅됩니다. 그런 다음 중앙 도구는 유틸리티 서비스로 각 랜딩 존에 파이프됩니다. 랜딩 존에서 기초 유틸리티를 분리하면 일관성과 규모의 경제가 극대화됩니다. 이러한 유틸리티는 또한 중앙에서 관리되는 책임과 워크로드 수준의 책임을 명확하게 구분합니다.
• 업무 분리: 기본 유틸리티와 랜딩 존 간의 명확한 업무 분리는 운영 방법의 가장 큰 장점 중 하나입니다. 클라우드 네이티브 도구 및 프로세스는 중앙 집중식 팀과 워크로드 팀 간의 액세스 및 적절한 제어 균형을 지원합니다. 이 방법은 개별 랜딩 존의 요구 사항과 랜딩 존 세그먼트에서 호스팅되는 워크로드를 기반으로 합니다.

엔터프라이즈 운영의 단점

• 비용 관리: 중앙 팀은 랜딩 존 내에서 프로덕션 변경을 수행하기 위해 워크로드 팀에 더 많이 의존합니다. 이러한 변화는 잠재적인 예산 초과를 불러일으키며 실제 지출의 적절한 규모 조정이 느려질 위험이 있습니다. 비용 제어 프로세스, 명확한 예산, 자동화된 제어 및 정기적인 검토는 예상치 못한 비용을 피하기 위해 조기에 마련되어야 합니다.
• 책임: 엔터프라이즈 운영에는 더 큰 문화적 및 운영 관련 요구 사항이 필요합니다. 이러한 요구 사항은 중앙 팀과 워크로드 팀 간의 책임을 명확하게 합니다.
• 기존 변경 관리 프로세스 또는 CAB(변경 자문 위원회)는 이 운영 모델에 필요한 속도와 균형을 유지하지 못할 수 있습니다. 이러한 프로세스는 클라우드 채택을 안전하게 확장하는 프로세스 및 절차를 자동화하는 데 반영됩니다.
• 변화에 대한 헌신의 부족은 먼저 협상과 책임 조정에서 구체화됩니다. 책임 이동에 맞춰 조정할 수 없다는 것은 단기 클라우드 채택 노력 중에 중앙 IT 운영 모델이 필요할 수 있음을 나타냅니다.
• 표준화: 중앙 집중식 가드레일 또는 자동화에 대한 투자가 부족하면 수동 검토 프로세스를 통해 극복하기가 더 어려운 표준화 위험이 발생합니다. 랜딩 존의 워크로드와 공유 서비스 간의 운영 종속성은 더 큰 위험을 만듭니다. 이러한 위험은 업그레이드 주기 동안의 표준화 또는 기본 유틸리티의 향후 버전에서 확장됩니다. 플랫폼 기반 수정 중에 지원되는 모든 랜딩 존과 호스팅하는 워크로드에 대해 개선되거나 자동화된 테스트가 필요합니다.
• 운영 지원: 자동화 및 중앙 집중식 작업을 통해 제공되는 작업 기준은 낮은 영향 또는 낮은 중요도 워크로드에 충분할 수 있습니다. 그러나 워크로드 팀 또는 기타 형태의 전용 작업은 복잡하거나 중요도가 높은 워크로드에 필요할 수 있습니다. 그렇다면 사업부가 이러한 형태의 고급 운영에 운영 비용을 제공해야 하는 운영 예산이 변경될 수 있습니다. 운영 비용에 대한 단독 책임을 유지하기 위해 중앙 IT가 필요한 경우 엔터프라이즈 운영은 구현하기 어려울 수 있습니다.
• 전문 지식: 중앙 IT 팀 구성원은 수동 프로세스를 통해 이전에 전달된 중앙 제어를 자동화하는 전문 지식을 개발해야 할 수 있습니다. 또한 이러한 팀은 환경을 정의하고 분기, 병합 및 배포 파이프라인을 이해하기 위한 코드로서의 인프라 방법에 대한 숙련도를 개발할 수 있습니다. 최소한 플랫폼 자동화 팀은 클라우드 우수성 센터 또는 중앙 운영 팀의 결정을 이해하기 위해 의사 결정 기술이 필요할 수 있습니다. 워크로드 팀은 의사 결정을 관리하는 제어 및 프로세스와 관련된 더 많은 지식을 개발해야 할 수 있습니다.
• 랜딩 존 설계: 랜딩 존 설계는 기초 유틸리티에 따라 다릅니다. 워크로드 팀은 디자인의 내용과 포함할 수 없는 사항을 이해해야 합니다. 이러한 이해는 노력, 오류 또는 충돌의 중복을 피하는 데 도움이 될 수 있습니다. 유연성을 만들기 위해 랜딩 존 디자인에 대한 예외 프로세스를 고려할 수 있습니다.
• 기본 유틸리티: 기본 유틸리티를 중앙 집중화하는 데 시간이 걸립니다. 이러한 유틸리티는 결국 옵션을 고려하고 다양한 채택 계획에 맞게 확장할 수 있는 솔루션을 개발합니다. 조기 채택 노력이 지연될 수 있습니다. 지연은 프로세스 후반부의 가속 및 차단 방지로 인해 장기적으로 상쇄될 수 있습니다.
• 업무 분리: 업무를 명확하게 분리하려면 성숙한 ID 관리 프로세스가 필요합니다. 사용자, 그룹 및 온보딩 및 오프보딩 활동의 적절한 정렬과 관련된 유지 관리가 더 있을 수 있습니다. 상승된 권한을 통해 Just-In-Time 액세스를 수용하기 위해 새 프로세스를 채택해야 할 수 있습니다.

분산 운영

조직 전체가 새로운 운영 모델로 전환하기에는 기존 운영 모델이 너무 깊이 박혀 있을 수 있습니다. 다른 기업의 경우 글로벌 운영 및 다양한 규정 준수 요구 사항으로 인해 특정 사업부가 변경하지 못할 수 있습니다. 이 경우 분산 작업 접근 방식이 필요할 수 있습니다. 이 방법은 앞에서 언급한 운영 모델 중 하나 이상을 통합해야 하므로 가장 복잡합니다.

매우 권장되지 않지만 일부 조직에서는 이 운영 방법이 필요할 수 있습니다. 이 접근 방식은 주로 서로 다른 사업부의 느슨한 컬렉션, 다양한 고객 세그먼트 기반 또는 지역 운영이 있는 조직과 관련이 있습니다.

• 우선 순위: 여러 기존 운영 모델을 통합합니다.
• 이전에 언급된 운영 모델 중 하나로 전체 조직을 이동하는 데 중점을 둔 과도기 상태입니다.
• 조직이 너무 크거나 너무 복잡하여 단일 운영 모델에 맞출 수 없는 경우의 장기 운영 방법입니다.
• 고유한 이점: 각 사업부의 공통 운영 모델 요소를 통합합니다. 이 접근 방식은 일관된 반복 가능한 프로세스를 사용하여 작업을 완성하는 데 도움이 되는 운영 단위를 계층 구조로 그룹화할 차량을 만듭니다.
• 명백한 단점: 여러 운영 모델 간의 일관성과 표준화는 장기간 유지하기 어렵습니다. 이러한 운영 접근 방식을 사용하려면 포트폴리오에 대한 깊은 인식과 다양한 기술 포트폴리오 세그먼트의 작동 방식에 대한 인식이 필요합니다.
• 위험: 기본 운영 모델에 대한 약속이 뚜렷하지 않으면 팀 간에 혼란이 발생할 수 있습니다. 단일 운영 모델에 맞출 방법이 없는 경우 이 운영 모델을 사용합니다.
• 지침: 먼저 비즈니스 조정 문서에 설명된 방법을 사용하여 포트폴리오를 철저히 검토합니다. 상태 운영 모델(탈중앙형, 중앙 집중형 또는 엔터프라이즈)별로 포트폴리오를 그룹화합니다.
• 운영 모델 그룹화를 반영하는 관리 그룹 계층 구조를 개발합니다. 이 정렬에는 가장 일반적인 버킷에서 가장 일반적인 버킷으로 워크로드 클러스터를 매핑하는 지역, 사업부 또는 기타 기준에 대한 다른 조직 패턴이 포함됩니다.
• 운영 모델에 대한 워크로드의 정렬을 평가하여 시작할 가장 관련성이 높은 운영 모델 클러스터를 찾습니다. 노드 및 관리 그룹 계층 구조 아래의 모든 작업에 대한 운영 모델에 매핑된 지침을 따릅니다.
• 거버넌스 및 관리 방법론을 사용하여 계층의 다양한 지점에서 필요한 운영 관리 사례를 포함하여 일반적인 회사 정책을 찾습니다. 공통 Azure 정책을 적용하여 공유 회사 정책을 자동화합니다.
• 다양한 배포를 사용하여 Azure 정책을 테스트할 때 관리 그룹 계층 구조에서 더 높게 이동하려고 시도합니다. 정책은 공통점과 고유한 작업 요구 사항을 찾을 수 있는 많은 워크로드에 적용될 수 있습니다.
• 시간이 지남에 따라 이 방법은 다양한 운영 모델에 걸쳐 확장되는 모델을 정의하는 데 도움이 될 수 있습니다. 이 방법은 일련의 공통 정책 및 절차를 통해 팀을 통합할 수도 있습니다.

이 방법의 장점과 단점은 의도적으로 비어 있습니다. 포트폴리오의 비즈니스 조정을 완료한 후 장점과 단점에 대한 명확성을 위해 위의 주요 운영 모델 섹션을 참조하세요.

다음 단계

운영 모델과 관련된 용어를 알아봅니다. 이 용어는 운영 모델이 기업 계획의 더 큰 주제에 어떻게 맞는지 이해하는 데 도움이 됩니다.

운영 모델 용어

랜딩 존이 클라우드 채택 환경의 기본 구성 요소를 제공하는 방법에 대해 알아봅니다.

랜딩 존이란?