운영 우수성 디자인 원칙

운영 우수성 핵심 핵심은 표준화된 워크플로 및 팀 응집력을 통해 워크로드 품질을 보장하는 DevOps 사례입니다. 이 핵심 요소는 개발 사례, 가시성 및 릴리스 관리를 위한 운영 절차를 정의합니다. 목표는 프로세스 차이, 인적 오류 가능성 및 고객 중단을 최소화하는 것입니다. 운영 상태를 평가하려면 다음 질문으로 시작합니다.

  • 분야를 사용하여 작업을 실행합니까?
  • 고객이 최대 예측 가능성으로 워크로드를 사용하고 있나요?
  • 지속적인 개선을 추진하기 위해 경험과 수집된 데이터를 통해 어떻게 학습하나요?

명확한 소유권이나 리더십이 없는 경우 워크로드 작업은 혼란스러운 관행으로 전환될 수 있습니다. 이러한 유형의 환경에서 팀은 종종 높은 노력으로 실행되는 메서드에 의존하며 낮은 결과를 생성하여 사용자 환경이 저하되는 경우가 많습니다. 이러한 접근 방식은 단기 목표만 충족합니다. 장기적인 이점은 지속적인 평가 및 전략적 투자를 통해 실현됩니다.

디자인 원칙은 증상뿐만 아니라 근본 원인을 해결하기 위해 고려해야 하는 운영 전략에 대한 지침을 제공합니다. 권장 접근 방식부터 시작한 다음, 무엇이 작동하고 개선 영역을 식별하지 않는지 관찰합니다. 전략을 설정한 후 운영 우수성 검사 목록을 사용하여 작업을 계속 진행합니다.

워크로드의 운영 요구 사항은 비즈니스 요구 사항만큼이나 중요합니다. 효율적인 프로세스는 규정 준수가 조직인지 외부인지 여부에 관계없이 워크로드가 규정 준수 제약 조건 내에서 비즈니스 결과를 달성할 수 있도록 합니다. 핵심은 일관성을 사용하여 반복성을 찾는 것입니다.

운영 우수성 핵심 요소의 목표는 옳은 일을 하고, 올바른 방법을 수행하고, 팀으로서 올바른 문제를 해결하는 것입니다.

이러한 목표를 충족하는 경우 워크로드는 변경 시에도 안정적으로 예측 가능하게 실행됩니다. 운영 요구 사항을 충족하지 못하면 배포 실패, 일관되지 않은 사용자 환경 및 적절한 계획 및 간소화된 실행을 통해 피할 수 있는 추가 비용이 발생할 수 있습니다.

DevOps 문화 포용

목표 아이콘 공동 작업, 공동 책임 및 소유권의 사고방식과 함께 작업하여 개발 및 운영 팀이 시스템 디자인 및 프로세스를 지속적으로 개선할 수 있도록 지원합니다.

DevOps는 관점과 기술의 다양성이 하나의 임무를 향해 나아가는 연습 커뮤니티입니다. 팀은 사일로 학습 대신 공유 지식의 공동 작업 환경을 조성 해야 합니다. 공유 함수를 사용하여 리소스 제약 조건을 극복하기 위해 노력합니다.

좋은 DevOps 문화는 공동의 책임으로 번성합니다. 개발 및 운영 팀은 목표와 우선 순위를 고객의 기대에 맞게 조정하고 비즈니스에 중점을 두어야 합니다. 개발 팀은 개선 사항이 업스트림 주도되고 다른 팀이 동등하게 혜택을 받을 수 있도록 피드백 루프에 운영 팀을 참여시켜야 합니다. 반대로 운영 팀은 워크로드와 관련된 리소스와 피드백을 공유하여 개발 팀이 비즈니스 결과에 성공하도록 할 책임이 있습니다.

동시에 DevOps 사례는 각 팀에 명확한 소유권 및 책임 라인을 적용합니다. 애플리케이션이 실행되는 위치에 관계없이 워크로드 팀은 해당 애플리케이션을 담당합니다.

DevOps는 효과적이지만 부담스럽지 않도록 운영 작업을 최적화합니다. DevOps의 모든 이점을 누리려면 문화권이 기술을 통해 프로세스를 최적화하고 organization 사람들이 투명한 통신을 촉진할 수 있는 프로세스를 가져야 합니다.

접근 방식 이점
통신 및 추적 진행 상황을 위한 공동 작업 환경을 촉진하는 일반적인 시스템 및 도구를 사용합니다. 일반적인 도구와 프로세스는 투명한 통신을 가능하게 합니다. 개발 및 운영 팀 모두 다양한 환경, 일반적인 지원 문제, 전반적인 과제 및 승리에 대한 상황 인식의 이점을 누릴 수 있습니다.

인시던트가 있는 경우 팀은 이미 기존 에스컬레이션 경로에 익숙할 것입니다.

공유 백로그는 새 기능 작업 또는 버그 수정과 같은 우선 순위를 명확히 합니다.
개발 주기 전반에 걸쳐 지속적인 학습 및 실험 사고방식을 구축합니다.

팀 간 지식 공유를 지원하고 재사용을 위한 설명서를 유지 관리합니다.

흠 없는 분석을 수행하고 릴리스 후 및/또는 인시던트 후 검토를 디브리핑합니다.
A/B 테스트 및 개념 증명 개발과 같은 실험 메커니즘을 통해 비용을 낮게 유지하면서 혁신을 장려할 수 있습니다.

팀이 디자인 접근 방식, 도구 및 프로세스에 능숙하게 만드는 공동 작업을 통해 지식을 공유합니다.

프로젝트 후 회고를 수행하면 개선 영역을 식별하고 성공을 축하하는 데 도움이 됩니다.
작업 최적화에 중점을 둔 검증된 업계 민첩한 사례를 채택합니다.

수동 및 자동화 프로세스, 배포 및 품질 보증 사례 및 가시성을 위해 운영에서 "왼쪽으로 이동"할 기회를 찾습니다.
민첩한 개발 사례로 인해 릴리스 수명 주기가 짧아지며 이는 비즈니스 가치를 나타내는 지표입니다.

이전 문제를 감지, 해결 및 방지하면 프로세스에 덜 방해가 되는 경우가 많습니다.
모든 개발 및 운영 절차에 대한 표준을 설정하고 정기적으로 검토하고 유효성을 검사합니다.

이러한 절차에는 일상적인 작업, 대역 외 프로세스, 비상 훈련 및 상황, 도구 선택, 모니터링 절차, 기술 계획, 이해 관계자 및 고객 공개와의 통신이 포함됩니다.

의사 결정에 대해 의도적이고 명시적이어야 합니다.
표준은 운영에 예측 가능성을 추가하고 프로세스 및 사례를 확장성 있게 만듭니다. 표준의 유효성을 검사하는 것은 개선 사항을 도출하는 좋은 방법입니다.

정기적인 훈련을 수행하여 응급 및 복구 상황에 대비합니다.

정밀도로 실행하고 거버넌스를 사용하도록 설정하여 위험으로 이어지는 변칙을 방지 합니다.
전문 기술과 다양한 경험을 갖춘 중앙 집중식 운영 팀을 활용합니다. 운영 및 리소스 모두에 공유 리소스를 사용하는 경우 비용 이점이 있습니다.

워크로드를 소유하고 있지만 중앙 집중식 팀은 인시던트 관리, 모니터링에 대한 사전 예방적 관점 및 신뢰할 수 있는 아웃소싱 전문 지식과 같은 교차 기능 기술을 제공합니다.

개발 표준 설정

목표 아이콘 개발 사례를 표준화하고, 품질 게이트를 적용하고, 체계적인 변경 관리를 통해 진행 상황과 성공을 추적하여 생산성을 최적화합니다.

개발 팀은 릴리스 전에 최소한의 마찰로 워크로드 문제를 해결할 책임이 있습니다. 코딩에서 테스트 결과에 이르기까지 개발자 효율성을 염두에 두고 빠른 처리 주기를 최적화합니다. 기술 활동을 계획하고 표준화하며 팀 및 이해 관계자 내에서 합의를 이끌어내는 효과적이고 올바른 크기의 프로세스를 구현합니다.

접근 방식 이점
워크로드 기능을 문서화 하고 고객 혜택을 캡처합니다.

아키텍처의 scope 및 자세한 기능 및 비기능 요구 사항을 파생합니다.

관련된 작업의 scope 및 비용을 보고할 크기 조정 예측 모델을 만듭니다.
좋은 사양은 더 생산적이고 간소화된 개발 주기를 지원하여 운영 비용과 실패 가능성을 줄 입니다.

개발자는 코딩 주기를 시작하기 전에 기술 설계, 목표 및 완료 조건을 이해합니다.

좋은 설명서는 새 팀 구성원의 반복 가능한 통신온보딩을 용이하게 합니다.
워크로드 및 팀 크기의 요구 사항에 맞게 적절하게 조정된 업계 표준 소프트웨어 개발 방법론 을 사용합니다.

모든 역할 간에 공유되는 백로그를 유지 관리합니다.
잘 알려진 방법론을 채택 하면 프로젝트의 리듬이 설정됩니다. 팀 구성원에게 명확한 기대와 책임을 부여하여 프로세스 모호성을 제거합니다.

일반적인 목록을 추적하면 표준 사례를 사용하여 작업을 구체화하고 우선 순위를 지정할 수 있습니다. 이 프로젝트는 정시에 전달될 가능성이 높아질 것입니다.

표준 방법론은 위험 관리에 도움이 될 수 있습니다. 개발자는 세분화된 마일스톤 검토를 통해 쇼스토퍼가 되기 전에 잠재적인 문제를 해결할 수 있습니다.
모든 코드, 스크립트, 배포 템플릿, 파이프라인 정의 및 관련 설명서에 통합 소스 제어를 사용합니다.

분기 전략은 독립적이고 상호 종속된 기능, 버그 수정 및 핫픽스의 마찰 없는 릴리스를 지원해야 합니다.

organization 공유 지식을 사용하여 분기 전략 및 배포 프로세스를 빌드합니다.
소스 제어의 적절한 사용은 동시 변경 및 버전 관리를 지원하는 데 중요합니다.

다양한 크기와 위험의 변경 내용을 해제하고, 프로세스의 일부로 피어 검토를 수행하고, 감사 내역을 유지하기 위해 반복 가능한 워크플로를 유지 관리합니다.
개발 수명 주기 초기에 테스트를 강조하는 품질 보증 프로세스를 갖습니다.

기능 릴리스 또는 업데이트의 일부인 애플리케이션 구성 요소, 인프라 및 데이터 평면 작업을 포함하여 계획된 테스트 프로시저에 대한 모든 아티팩트를 포함합니다.

아티팩트는 환경을 통해 승격될 때 변경할 수 없는 것으로 간주하여 품질 게이트를 통과할 때마다 자신감을 얻습니다.

실용적이면 일상적인 검사를 자동화합니다.
품질 보증은 기능 및 비기능 요구 사항을 자신 있게 충족하여 고객에게 긍정적인 영향을 줍니다.

테스트 계획을 보유하면 품질과 완전성이 보장되고 가능한 실패 사례를 고려합니다.

품질 게이트를 사용하면 위험을 줄이기 위해 모범 사례를 적용할 수 있습니다.

불변성은 테스트하는 시스템이 릴리스된 것과 정확히 일치하는지 확인하기 때문에 확신을 줍니다.

품질 기준을 충족하지 않는 한 테스트 주기는 진행률을 효율적으로 차단합니다.
규칙을 적용 하는 스타일 가이드 및 도구를 사용하여 일관성 높이고 이해 관계자와의 개발, 테스트 및 통신을 위한 공통 도구 체인 을 채택합니다.

개발자를 위한 기술 표준은 패턴, API 디자인, 로깅, 예외 처리 및 기타 프로세스 구현이 필요합니다.
코드의 일관성은 가독성과 유지 관리를 용이하게 합니다. 또한 복잡성을 줄이고 코드를 다시 사용할 수 있습니다.

또한 일반적인 도구 및 규칙은 팀이 일회성 선택을 처리할 필요 없이 프로세스를 최적화하는 데 도움이 됩니다.
일관되고 의도적으로 작성된 코드의 개발자 설명서를 주장합니다. 코드 설명서를 지우면 이전 코드를 다시 검토해야 하거나 개발 팀이 회전할 때 논리와 기능을 쉽게 이해할 수 있습니다.
진행률 및 추세를 보고 하여 효율성을 측정합니다. 버그, 실패한 업데이트, 배포 시간, 피드백 루프 및 기타 메트릭의 추세가 게시되고 개선이 필요합니다.

가시성을 사용하여 작업 발전

목표 아이콘 시스템에 대한 가시성을 확보하고, 인사이트를 도출하고, 데이터 기반 결정을 내세요.

워크로드를 모니터링하고 Azure Well-Architected Framework의 모든 핵심을 고려하여 지속적으로 품질을 향상시키는 문화를 구축합니다. 팀과 이해 관계자가 필요한 데이터, 통계 및 추세를 제공하여 여러 측면에서 단기 및 장기 결정을 내릴 수 있도록 합니다. 데이터에서 학습하고 개선 사항을 추진합니다.

가시성을 위해 빌드된 운영은 애플리케이션의 사전 유지 관리, 품질 및 보안 보증, 용량 계획 및 제품 관리의 핵심입니다.

모니터링의 중요한 측면은 인시던트가 되기 전에 문제를 예측하고 고객 환경에 영향을 주는 데 도움이 되는 상태 모델링을 사용하는 애플리케이션입니다. 효율적인 모니터링은 인시던트 관리에 소요되는 사후 주기를 줄입니다.

접근 방식 이점
자체 스택 및 흐름을 사용하여 모니터링 시스템을 빌드합니다.

모니터링 시스템을 유틸리티에서 분리된 워크로드의 차원으로 처리합니다. 스택은 인프라, 애플리케이션 상태, 빌드 및 릴리스 프로세스를 비롯한 모든 계층을 포함해야 합니다.

비즈니스 데이터 캡처 또는 샘플링은 가시성 구현을 위해 scope 않습니다.
모니터링 및 워크로드 스택을 분리하여 기능 요구 사항 및 가시성 요구 사항을 분리 하고 독립적인 진화를 가능하게 합니다. 코드 변경은 모니터링에 영향을 주지 않아야 하며 그 반대의 경우도 마찬가지입니다.

가시성 요구 사항은 기능 요구 사항과 별개이므로 구성 변경 또는 중단을 모니터링하여 비즈니스 데이터가중단되지 않습니다 .
데이터 원본의 각 형식에 대한 컬렉션 프로세스의 일관성을 구동합니다.

원격 분석, 인프라 메트릭 컬렉션 및 도구에 대한 업계 표준을 사용하여 코드에서 계측을 표준화합니다.
일관성은 감지 및 측정의 차이를 방지합니다. 유사한 리소스에 대한 친숙함이 데이터 상관 관계를 지정하고 분석하는 데 소요되는 시간을 줄이기 때문입니다. 문제를 예상하는 전체적인 관점이 있습니다.

실행 흐름의 핵심 요소를 상호 연결하고 다양한 세분성 수준에서 엔드 투 엔드 보기를 제공하는 애플리케이션 코드에서 원격 분석을 내보낸다. 심각도 수준에 따라 작업의 우선 순위를 지정하고 세부 정보 표시가 지정된 컨텍스트를 이해합니다. 이 정보는 문제 해결을 위해 중요합니다.
여러 팀에서 데이터 싱크를 공유하고 중앙 팀에서 관리하는 경우에도 데이터를 내보내고 수집하는 책임을 집니다. 모니터링 데이터를 워크로드 환경에 지역화하여 팀은 로그 및 메트릭에 액세스하여 워크로드 문제를 해결할 수 있습니다.
충분한 데이터를 수집하고 충분한 시간 동안 보존합니다.

데이터 로깅 및 저장과 관련된 비용 절충을 고려합니다.
의도적인 데이터 수집은 필요한 것보다 많은 데이터를 수집하는 것과 관련된 재무 및 운영 비용을 최적화 하는 데 도움이 됩니다.

노이즈를 최소화하고 분석 중에 집중적인 계산을 피하고 더 이상 필요하지 않은 데이터를 저장하는 비용을 줄입니다.
프로필, 로그, 메트릭 및 추적과 같은 다양한 모니터링 신호를 구분합니다. 올바른 용도로 각 신호를 사용합니다.

메트릭을 사용하여 숫자 측정에 의존하는 작업을 트리거하는 데 우선 순위를 지정합니다.

프로필을 사용하여 메모리 할당과 같은 하위 수준의 가시성을 시스템에 가져옵니다.

흐름 및 종속성에 대한 컨텍스트를 제공하기 위해 로그 및 추적 사용을 예약합니다.
올바른 용도로 신호를 사용하면 모니터링 시스템의 비효율적인 구현을 방지할 수 있습니다.

예를 들어 작업에 로그를 사용하려면 구문 분석이 필요합니다. 메트릭을 사용하여 동일한 목표를 더 빠르게 달성할 수 있습니다.
대시보드에서 데이터를 집계하고 시각화하여 대상 그룹을 수용하고 비즈니스 컨텍스트를 염두에 두고 모니터링 데이터를 표시합니다.

상황별 대시보드를 사용하여 데이터를 표시하여 관련자 간의 인식을 유도합니다.

인시던트 대응과 같은 운영자 활동에 대한 드릴다운 기능이 있는 운영 대시보드 및 통합 문서를 사용합니다. 대시보드를 자주 새로 고치고 세분화된 데이터를 제공합니다.
시각화를 사용하면 추세를 분석하고, 비즈니스 목표를 추적하고, 인시던트를 관리할 수 있습니다.

고객의 관심에 맞게 조정된 대시보드는 해석을 관련성 있게 만들고 검색 및 작업에 걸리는 시간을 가속화합니다.
표준화된 설명 및 심각도 수준으로 책임 있는 역할에 알리면 경고를 실행 가능하게 만듭니다. 다양한 원본에서 수집된 정보를 제공하고 비즈니스 목표의 편차를 추적합니다.

조치가 필요한 인시던트에 대해서만 경고를 트리거합니다.

성능 저하 상태가 실패하기 전에 작업을 시작하는 사전 예방적 및 생각을 자극하는 경고를 위해 노력합니다.
경고는 organization 정의된 중요한 이벤트에 주의를 기울입니다.

좋은 경고 시스템은 작업 및 심각도를 식별하고 명확성과 목적을 추진하기에 충분한 데이터를 제공합니다. 운영자는 지연 없이 수정을 시작할 수 있습니다.

자신 있는 배포

목표 아이콘 예측 가능성을 사용하여 원하는 배포 상태에 도달합니다.

워크로드의 호스팅 플랫폼, 애플리케이션, 데이터 및 구성 리소스 전반에 걸쳐 모든 환경에서 예측 가능성 목표를 일관되게 달성할 수 있는 워크로드 공급망을 빌드합니다. 배포 메커니즘은 자동화, 테스트, 모니터링 및 버전 관리를 수행할 수 있어야 합니다. 모듈화되고 요청 시 실행할 준비가 되어 있어야 합니다. 모놀리식 엔드 투 엔드 프로세스로 표시해서는 안 됩니다. 공급망은 반드시 더 빠른 실행을 위한 것이 아니라 여러 반복에 대한 일관성과 자체 설명서를 달성하기 위한 것입니다.

워크로드 팀은 자체 워크로드와 관련된 공급망에 대한 책임이 있습니다.

접근 방식 이점
IaC(Infrastructure as Code)를 사용하여 프로덕션 준비가 된 공급망의 반복 가능한 측면을 정의합니다.

명령적 메서드보다 선언적 접근 방식을 선호합니다.
선언적 IaC 기술은 자동화 및 재사용 가능성을 염두에 두고 설계되었습니다. 인프라 배포를 개인의 도구로 오프로드하고 일관된 품질을 얻을 수 있습니다.

인프라 관점에서 볼 때 기술 선택 항목이 적으면 도구의 분산이 제거되고 구성 드리프트를 쉽게 검색할 수 있습니다. 유지 관리도 더 쉬워질 것입니다. 선택 사항을 팀의 기존 기술 집합에 맞추면 팀에서 쉽게 채택할 수 있습니다.
선택한 IaC 기술을 사용하도록 팀을 준비합니다. 확장성 모델, 기능 및 제한 사항에 대해 알아봅니다.

팀 내의 전문화와 organization 내의 공유 지식을 활용합니다.
업스킬은 생산성을 높이고 공유 학습을 통해 공동 작업 환경을 조성합니다.

채용 대신 교육으로 격차를 메울 수 있습니다.
IaC 개발 및 유지 관리에 대한 소프트웨어 권장 사항을 따릅니다.

조정에서 모듈화합니다. 사용자 지정 또는 낮은 값 추상화는 사용하지 마세요.

계층화된 접근 방식을 따라 다양한 수명 주기를 반영합니다. 하위 계층이 일정하게 유지되고 상층이 필요에 따라 변경되는 기본 계층을 형성합니다.

애플리케이션 이진 파일, IaC 템플릿 및 매개 변수와 같은 배포 아티팩트가 공격 표면의 일부입니다. 보안 핵심 요소의 비밀 관리, 액세스 제어 및 기타 원칙과 같은 보증을 적용합니다.
아티팩트에서는 애플리케이션 코드와 동일한 수준의 엔지니어링 엄격함을 경험합니다. 피어 검토 및 테스트를 통한 품질 제어를 통해 배포에 대한 확신을 얻을 수 있습니다.

계층화된 접근 방식을 사용하면 유지 관리가 더 쉬워지고 명확한 책임 라인을 설정하는 경계가 만들어집니다.

아티팩트에서 보안 컨트롤을 추가하면 배포 프로세스 중에 시스템을 강화하는 데 도움이 됩니다.
모든 환경에서 사용되는 공통 배포 매니페스트를 개발합니다. 해당 매니페스트를 그린필드 프로젝트, 증분 워크로드 업데이트 또는 재해 복구의 기본 메커니즘으로 사용합니다. 여러 자산을 유지 관리하는 오버헤드를 제거합니다.

재해가 발생하면 즉석 환경을 만드는 대신 시도되고 테스트된 매니페스트를 배포할 수 있으므로 복구가 빠르고 안정적입니다.
IaC 자동화를 통해 배포되는 변경할 수 없는 임시 인프라 를 위해 노력합니다. 구성 드리프트를 금지하고 배포 멱등을 만듭니다.

이러한 종류의 인프라는 패치와 같은 상당한 운영 부담을 제거합니다. 또한 파란색-녹색 인프라 배포와 같은 핵심 유효성 검사 시나리오에도 이점을 제공합니다.

참고

포털 사용량의 scope 반복하지 않는 조사 작업으로만 줄입니다.

효율성을 위해 자동화

목표 아이콘반복적인 수동 작업을 더 빠르게 완료하고 일관성과 정확도를 높이고 위험을 줄이는 소프트웨어 자동화로 바꿉니다.

워크로드에는 팀 구성원이 실제로 인간의 지성이 필요하지 않은 평범하고 반복적이며 시간이 많이 걸리는 작업을 수행하는 프로세스가 포함된 워크플로가 있을 수 있습니다. 빈도에 따라 이러한 작업에 상당한 시간을 할애하여 워크로드가 증가함에 따라 더 많은 시간을 투자할 수 있습니다. 또한 이러한 프로세스는 종종 사람의 입력으로 인해 오류가 발생하기 쉽습니다.

자동화를 통해 시간, 노력 및 비용을 절약하고 실수를 방지할 수 있습니다.

접근 방식 이점
복잡성, 노력, 빈도, 정확도, 타임라인 및 수명 수준에서 적절한 수준의 기준에 대해 모든 워크플로를 평가합니다.

해당 평가에 따라 워크플로를 자동화하고 가장 높은 예상 반환으로 워크플로의 우선 순위를 지정합니다.

중복 워크플로를 제거 하거나 값을 추가하여 사람의 노력을 정당화합니다.
더 높은 가치의 작업에 팀 용량을 재투자하고 생산성과 일관성을 높일 수 있습니다.

워크플로 인벤토리를 빌드하면 올바른 작업을 자동화할 수 있습니다. 중복 작업을 제거하면 복잡성과 오류가 줄어듭니다.
사용자 지정 도구를 빌드할지 또는 소프트웨어를 구입할지 여부를 평가할 때 의사 결정에 대해 명시적으로 설명합니다.

고도로 전문화되고 가치 높은 작업을 위해 빌드 자동화를 예약합니다.
기성 소프트웨어를 구입하고 지원 계약을 활용하여 유지 관리 비용을 절감할 수 있습니다.

소프트웨어를 빌드하면 더 많은 제어를 할 수 있으며 팀과 워크로드에 고유한 사용 사례를 충족할 수 있습니다. 그러나 비용 영향이 있습니다.

도구를 선택하면 작업에 표준화 수준이 제공됩니다. 교육을 통해 채택을 위한 일관된 수준의 준비를 달성할 수 있습니다.
자동화 기능을 지원하도록 워크로드 구성 요소를 디자인합니다. 시스템 디자인에서 자동화가 부족하면 반복적인 작업의 안티패턴이 촉진되고 성장 속도가 느려지고 기술적인 부채가 누적되는 상황을 방지할 수 있습니다.
모든 자동화를 워크로드의 중요한 종속성으로 처리합니다. 워크로드의 예상 성장에 맞게 조정합니다.

자동화 도구는 워크로드의 필수적인 부분이며 5가지 Well-Architected 프레임워크 핵심 요소에 따라야 합니다.
보안 위협과 같은 위험을 견딜 수 있도록 자동화 구성 요소를 디자인합니다. 적용된 모범 사례를 사용하면 구현이 확산되는 것을 방지할 수 있습니다.

이 종속성이 기능적이고 안전하게 유지되는 경우 워크로드는 높은 수준의 보장으로 계속 작동합니다.
워크로드 이외의 옵션을 탐색하여 대규모로 자동화합니다.

새 프로젝트를 온보딩하고 기존 디자인 및 구현의 재사용을 촉진하기 위한 템플릿 및 프레임워크를 제공하여 "한 번 디자인, 모든 곳에서 실행" 모델을 선호합니다.
시도되고 테스트된 메서드를 사용하고 실패 가능성을 줄입니다.

안전한 배포 사례 채택

목표 아이콘 배포 프로세스에서 가드 레일을 구현하여 오류 또는 예기치 않은 조건의 영향을 최소화합니다.

개발 주기 동안 워크로드 아티팩트가 구현 및 테스트되고 버그가 수정될 때 많은 변경 내용을 거행합니다.

배포 프로세스는 표준 운영 절차를 따라야 합니다. 모든 변경 내용은 동일한 수준의 엄격한 수준으로 배포해야 합니다. 이 원칙은 코드, 구성 및 모든 관련 아티팩트에도 동일하게 적용됩니다. 핵심은 프로덕션 환경에서 예측 가능성을 갖도록 가능한 한 빨리 안전한 사례를 적용하는 것입니다. 오류가 고객에게 도달하더라도 가능한 한 빨리 복구 변경 내용을 롤아웃할 수 있어야 합니다.

접근 방식 이점
파이프라인과 같은 자동화된 배포 프로세스를 사용하여 변경 내용을 배포하도록 프로세스를 표준화합니다.

모든 환경에서 파이프라인을 사용해야 합니다.

자산 및 버전을 환경별로 분류하여 쉽게 추적 가능하고 식별할 수 있도록 합니다.
일관된 배포 방법을 사용하면 프로세스 오류 및 분산으로 인한 문제를 줄이고 워크로드 문제에 집중할 수 있습니다.

표준화는 배포가 안전하고 안정적이며 반복성 있게 완료되도록 합니다.

분류를 사용하면 이전 배포 및 발생한 문제의 로그를 쉽게 볼 수 있습니다. 해당 정보를 사용하여 롤백 및 롤포워드 작업을 신속하게 수행할 수 있습니다.
일반 주기 로 작은 증분 업데이트를 배포합니다 . 테스트가 잘 된 빈번한 작은 업데이트를 통해 릴리스의 유효성을 더 쉽게 검사할 수 있습니다.

적은 공간으로 인해 고객에게 미치는 영향을 최소화 하여 더 빠르게 문제를 해결합니다.
개발 수명 주기 전반에 걸쳐 다양한 메커니즘을 사용하여 업데이트를 엄격하게 테스트합니다. 개발 초기 단계에서 문제를 파악합니다. 반복적인 수정 및 일관된 배포 사례로 인해 업데이트가 프로덕션에 준비될 때까지 문제가 줄어듭니다.
실사를 통해 업데이트를 점진적으로 롤아웃합니다.

모든 사용자가 업데이트를 안전하게 채택할 때까지 컨트롤을 제공하는 배포 모델을 사용하여 인스턴스 및 고객 수를 점진적으로 늘릴 수 있습니다.
프로덕션 초기에 문제가 해결되도록 각 업데이트를 제어된 방식으로 테스트합니다. 전체 고객 기반에 영향을 주는 잘못된 업데이트를 롤아웃하지 않습니다.

업데이트가 이전 버전과 앞으로 호환되는지 테스트합니다.
배포 오류로부터 신속하게 복구하기 위한 완화 전략을 갖습니다.

이 전략은 문제의 중요도에 따라 롤백 또는 앞으로 롤백 에 대한 의사 결정을 포함해야 합니다.

표준 배포 파이프라인을 사용하여 수정 사항을 신속하게 롤아웃할 수 있는 잘 정의된 프로세스 및 자동화된 시스템이 있습니다.
잠재적 영향 기간을 줄입니다.

시스템을 이전 작업 버전으로 복원하거나 철저히 테스트된 수정 사항이 있는 버전으로 롤오버합니다.
비상 시 시스템을 작동 상태로 다시 설정 하여 예기치 않은 오류로부터 복구하는 대체 계획을 세워야 합니다. 필요한 경우에만 이 전략을 사용하고 승인을 받아야 합니다.

시간이 지남에 따라 계획을 개선하기 위해 노력합니다.
보안 수정과 같은 우선 순위가 높은 수정 사항을 빠르게 추적할 수 있습니다.

가속화된 파이프라인은 표준 운영 프로시저에 대한 모든 검사를 수행하지 못할 수도 있지만, 고객에게 가장 빠른 방법으로 안전한 버전으로 전환할 수 있으며, 이는 영향이 낮은 오류보다 큽니다.

다음 단계

운영 우수성 검사 목록을 검토하여 다른 개념을 살펴보는 것이 좋습니다.