DevOps 팀 토폴로지

IT 팀과 애플리케이션 팀 간의 역할, 책임 및 신뢰 분산은 대규모 클라우드 채택과 관련된 운영 변환에 가장 중요합니다.

IT 팀은 제어를 유지하기 위해 노력합니다. 애플리케이션 소유자는 민첩성을 최대화하려고 합니다. 이러한 두 목표 간에 궁극적으로 설정하는 균형은 클라우드 운영 모델의 성공에 큰 영향을 줍니다.

콘웨이의 법에 따르면, 팀은 통신 구조에 따라 아키텍처를 생산합니다. 자율성과 제어 사이의 필요한 균형을 달성하기 위해 노력할 때 이 원칙을 이해하는 것이 중요합니다. 시스템을 디자인하는 모든 조직(광범위하게 정의됨)은 해당 조직의 통신 구조의 복사본인 디자인 구조를 생성합니다.

콘웨이의 법칙을 보여주는

DevOps 관점에서 조직은 고객의 요구에 신속하게 대응하도록 최적화해야 합니다. 애플리케이션 및 시스템을 소유, 디자인 및 구현하는 팀은 다음과 같은 특성을 가진 아키텍처에서 가장 높은 수준의 자율성을 찾습니다.

• 지속적인 변경을 지원하는 진화 아키텍처
• 배포 가능성
• 테스트 용이성

콘웨이의 해결책은 콘웨이의 법칙을 뛰어넘는 것입니다. 조직에서 특정 구조를 따라 서비스 및 제품을 생산하고 최적화하려는 경우 조직 구조를 재고해야 합니다. 원하는 아키텍처를 달성하기 위해 팀과 조직 구조를 개선합니다.

역방향 콘웨이 기동의

이 원칙은 DevOps의 전체 분야를 달성하기 위해 팀이 소유한 모든 애플리케이션, 시스템 또는 플랫폼의 엔드 투 엔드를 담당하는 의도적으로 디자인된 팀 토폴로지로 이어집니다.

다음 표에서는 이러한 팀의 간소화된 분류를 제공합니다.

디자인 고려 사항

• Azure 랜딩 존 수명 주기를 설계하고, 빌드하며, 프로비전하고, 관리하고, 유지 보수할 기능 간 플랫폼 팀을 구축하세요. 이 팀은 중앙 IT 팀, 보안, 규정 준수 및 사업부의 구성원을 포함시켜 광범위한 엔터프라이즈가 표현되도록 할 수 있습니다. 안티패턴 를 피하도록 하세요.

• 기존 DevOps 기능이 없는 애플리케이션 및 플랫폼을 지원하기 위해 DevOps 함수를 제공할 수 있는 지원 팀 또는 개발 기능이 최소인 레거시 애플리케이션과 같은 비즈니스 사례를 설정할 수 있는 지원 팀을 설정하는 것이 좋습니다.

• 애플리케이션 작업팀의 민첩성을 저해할 수 있으므로 이들을 중앙 아티팩트로 제한하지 마세요. 정책 기반 거버넌스 및 Azure 역할 기반 액세스 제어(Azure RBAC)를 사용하여 일관된 기준 구성을 적용하고, 애플리케이션(사업 부서) 팀이 혁신을 추구하면서도 미리 정의된 템플릿을 활용할 수 있도록 유연성을 가질 수 있습니다.

• 애플리케이션 팀이 애플리케이션 리소스 인스턴스화 또는 관리에 중앙 프로세스 또는 프로비전 파이프라인을 사용하도록 강제하지 마세요. 애플리케이션 배달을 위해 이미 DevOps 파이프라인을 사용하는 기존 팀은 여전히 현재 도구를 사용할 수 있습니다. Azure Policy를 사용하여 조직의 표준을 시행하고 대규모로 규정 준수를 평가하며, DevOps 프로세스를 위한 보안 고려 사항을 해결할 수 있습니다.

• DevOps 모델의 일괄적 적용은 유능한 DevOps 팀을 즉시 구축하지 않습니다.

• 엔지니어링 기능 및 리소스에 대한 투자는 매우 중요합니다.

• 일부 레거시 애플리케이션에 대한 애플리케이션 팀에는 DevOps 전략에 부합하는 데 필요한 엔지니어링 리소스가 없을 수 있습니다.

디자인 권장 사항

다음 섹션에는 팀 토폴로지 설계를 안내하는 디자인 권장 사항이 포함되어 있습니다.

클라우드 운영 모델에 맞춰 팀 토폴로지를 조정하십시오.

팀의 토폴로지를 원하는 클라우드 운영 모델에 맞추도록 하십시오.

팀 구조에서 발생할 수 있는 문제를 완전히 이해할 수 있도록 운영 적합성 검토 위한 핵심 프로세스를 설정합니다.

플랫폼 팀에 대한 함수 정의

다음 목록에서는 Azure 랜딩 존을 담당하는 플랫폼 팀에 권장되는 함수 집합을 제공합니다.

• 아키텍처 거버넌스
• 필요한 네트워크, ID 및 액세스 관리 정책의 구독 프로비저닝 및 위임
• 플랫폼 관리 및 모니터링(전체론적)
• 비용 관리(전체론적)
• 플랫폼-애즈-코드(템플릿, 스크립트 및 기타 자산의 관리)
• Microsoft Entra 테넌트 내에서 Microsoft Azure에 대한 전체 작업(서비스 주체 관리, Microsoft Graph API 등록 및 역할 정의)
• Azure RBAC(전체론적)
• 중앙 서비스에 대한 키 관리(간단한 메일 전송 프로토콜 및 도메인 컨트롤러)
• 정책 관리 및 적용(전체론적)
• 보안 모니터링 및 감사(전체론적)
• 네트워크 관리(전체론적)

애플리케이션 워크로드 팀에 대한 함수 정의

다음 목록에서는 애플리케이션 워크로드를 담당하는 애플리케이션 팀에 권장되는 함수 집합을 제공합니다.

• DevOps 모델을 통해 애플리케이션 리소스 만들기 및 관리
• 데이터베이스 관리
• 애플리케이션 마이그레이션 또는 변환
• 애플리케이션 관리 및 모니터링(애플리케이션 리소스)
• Azure RBAC(애플리케이션 리소스)
• 보안 모니터링 및 감사(애플리케이션 리소스)
• 비밀 및 키 관리(애플리케이션 키)
• 비용 관리(애플리케이션 리소스)
• 네트워크 관리(애플리케이션 리소스)

팀을 가능하게 하는 함수 정의

다음 목록에서는 다른 팀을 지원하는 지원 기반 팀에 권장되는 기능 집합을 제공합니다.

• 전체 대상 클라우드 운영 모델(예: DevOps)과 일치하도록 조직 전체에서 올바른 전문 지식을 습득하는 데 도움이 되는 수평(기능 간) 지침 및 기능 정의
• 다른 팀이 필요한 수준의 전문 지식에 도달할 수 있도록 지원, 교육 및 코칭
• 귀하의 애플리케이션 또는 플랫폼 팀을 위한 공통의 재사용 가능한 템플릿 및 라이브러리 집합을 설정하고, Azure 확인된 모듈같은 InnerSourcing을 촉진합니다.

팀 간의 상호 작용 모드 정의

팀 간의 상호 작용 목표는 다음과 같습니다.

• 자율성 달성
• 종속성 차단 해제
• 낭비 시간 최소화
• 병목 현상 방지

팀 토폴로지 세 가지 팀 상호 작용 모드를 간략하게 설명합니다.