DevOps 검사 목록

  • 아티클

DevOps는 개발, 품질 보증 및 IT 운영을 통합된 문화권으로 통합하고 소프트웨어를 제공하는 일련의 프로세스입니다. 이 검사 목록을 시작점으로 사용하여 DevOps 문화권 및 프로세스를 평가합니다.

문화권

조직 및 팀에서 비즈니스 연계를 확인합니다. 조직 내에서 리소스, 용도, 목표 및 우선 순위의 충돌은 성공적인 작업에 위험 요소가 될 수 있습니다. 비즈니스, 개발 및 운영 팀이 정렬되었는지 확인합니다.

팀에서 소프트웨어 수명 주기를 이해해야 합니다. 팀은 애플리케이션의 전체 수명 주기와 각 애플리케이션이 해당 수명 주기 내에 있는 위치를 이해해야 합니다. 이 정보를 사용하면 모든 팀 구성원이 지금 무엇을 해야 하는지, 그리고 미래에 무엇을 계획하고 준비해야 하는지 알 수 있습니다.

주기 시간을 줄입니다. 아이디어에서 사용 가능한 개발 소프트웨어로 이동하는 데 걸리는 시간을 최소화하는 것을 목표로 합니다. 테스트 부담을 낮추기 위해 개별 릴리스의 크기 및 범위를 제한합니다. 가능한 한 빌드, 테스트, 구성 및 배포 프로세스를 자동화합니다. 개발자 간 및 개발자와 운영 팀 간의 통신에 방해가 없도록 합니다.

프로세스를 검토하고 개선합니다. 자동 및 수동 프로세스 및 프로시저는 최종본이 아닙니다. 지속적으로 향상하려는 목표를 가지고 현재 워크플로, 프로시저 및 설명서를 정기적으로 검토합니다.

사전 계획을 수행합니다. 오류에 대해 미리 계획합니다. 문제가 발생할 때 신속하게 문제를 식별하고, 문제를 해결하도록 올바른 팀 구성원에게 에스컬레이션하고, 해결 방법을 확인하는 프로세스를 마련합니다.

오류에서 알아봅니다. 오류는 피할 수 없지만 오류가 반복되지 않도록 이를 통해 배워야 합니다. 작동 오류가 발생하는 경우 문제를 심사하고, 원인과 해결 방법을 문서화하고, 학습한 모든 교훈을 공유합니다. 가능하면 빌드 프로세스를 업데이트하여 향후 이러한 오류를 자동으로 검색합니다.

속도를 최적화하고 데이터를 수집합니다. 계획된 모든 개선 사항은 가설입니다. 가능한 가장 작은 증분 단위로 작업합니다. 새로운 아이디어를 실험으로 처리합니다. 실험 효과를 평가하기 위해 프로덕션 데이터를 수집할 수 있도록 실험을 계측합니다. 가설이 잘못된 경우 빠르게 실패할 준비를 합니다.

학습할 시간을 허용합니다. 실패와 성공은 학습 기회를 제공합니다. 새 프로젝트로 이동하기 전에 중요한 교훈을 수집할 시간을 허용하고 팀이 이러한 교훈을 흡수하는지 확인합니다. 또한 팀이 기술을 빌드하고, 실험하고, 새로운 도구와 기술에 대해 알아볼 수 있는 시간을 제공합니다.

작업을 문서화합니다. 제품 코드와 품질 수준이 같은 모든 도구, 프로세스 및 자동화된 작업을 문서화합니다. 복구 프로세스 및 기타 기본 테넌트 프로시저와 함께 지원하는 모든 시스템의 현재 디자인 및 아키텍처를 문서화합니다. 이론적으로 최적의 프로세스가 아니라 실제로 수행하는 단계에 집중합니다. 정기적으로 설명서를 검토하고 업데이트합니다. 코드의 경우 특히 공용 API에 의미 있는 주석을 포함해야 합니다. 도구를 사용하여 가능할 때마다 자동으로 코드 설명서를 생성합니다.

지식을 공유합니다. 사용자가 설명서를 찾을 수 있어야 유용합니다. 설명서를 체계적으로 정리하고 쉽게 검색할 수 있도록 합니다. 창의적으로 브라운 백(비공식 프레젠테이션) 비디오 또는 뉴스레터를 사용하여 지식을 공유합니다.

개발

프로덕션과 유사한 환경을 개발자에게 제공합니다. 개발 및 테스트 환경이 프로덕션 환경과 일치하지 않는 경우 문제를 테스트하고 진단하기가 어렵습니다. 개발 및 테스트 환경을 프로덕션 환경에 최대한 가깝게 유지합니다. 테스트 데이터가 실제 프로덕션 데이터가 아닌 샘플 데이터(개인 정보 보호 또는 규정 준수 이유)인 경우에도 프로덕션에서 사용하는 데이터와 일치하는지 확인합니다. 샘플 테스트 데이터를 생성하고 익명화하도록 계획합니다.

권한 있는 모든 팀 구성원이 인프라를 프로비전하고 애플리케이션을 배포할 수 있는지 확인합니다. 프로덕션과 유사한 리소스를 설정하고 애플리케이션을 배포하는 데 복잡한 수동 작업이나 시스템에 대한 자세한 기술 지식이 필요하지 않습니다. 올바른 권한이 있는 사용자는 운영 팀에 가지 않고도 프로덕션과 유사한 리소스를 만들거나 배포할 수 있어야 합니다.

이 권장 사항은 누구나 프로덕션 배포에 라이브 업데이트를 푸시할 수 있음을 의미하지는 않습니다. 개발 및 QA 팀이 프로덕션과 유사한 환경을 만들기 위한 마찰을 줄이는 것입니다.

인사이트를 위해 각 애플리케이션을 계측합니다. 애플리케이션의 상태를 이해하려면 애플리케이션의 성능 및 오류 또는 문제가 발생하는지 여부를 알아야 합니다. 항상 디자인 요구 사항으로 계측을 포함하고 처음부터 각 애플리케이션에 계측을 빌드합니다. 계측에는 근본 원인 분석을 위한 이벤트 로깅뿐만 아니라 각 애플리케이션의 상태 및 사용을 모니터링하기 위한 원격 분석 및 메트릭도 포함되어야 합니다.

기술적인 문제를 추적합니다. 많은 프로젝트에서는 코드 품질보다 릴리스 일정의 우선 순위를 한 수준 또는 다른 수준으로 지정합니다. 항상 바로 가기가 수행되거나 기타 최적이 아닌 구현을 문서화하고 이러한 문제를 다시 검토하는 시간을 예약합니다.

프로덕션에 직접 업데이트를 푸시하는 것이 좋습니다. 전체 릴리스 주기 시간을 줄이려면 제대로 테스트된 코드 커밋을 프로덕션에 직접 푸시하는 것이 좋습니다. 기능 토글을 사용하여 사용하도록 설정할 기능을 제어합니다. 그런 다음 토글을 사용하여 기능을 사용하거나 사용하지 않도록 설정하여 개발에서 릴리스로 빠르게 이동할 수 있습니다. 토글은 프로덕션 환경의 하위 집합에 특정 기능을 배포하는 카나리아 릴리스와 같은 테스트를 수행할 때도 유용합니다.

테스트

테스트 자동화 수동으로 소프트웨어를 테스트하는 작업은 복잡하고 오류에 취약합니다. 일반적인 테스트 작업을 자동화하고 테스트를 빌드 프로세스에 통합합니다. 자동화된 테스트를 사용하면 일관된 테스트 검사 및 재현성이 가능합니다. 통합 UI 테스트를 실행하는 경우 자동화된 도구도 사용합니다. Azure는 테스트를 구성하고 실행할 수 있도록 하는 개발 및 테스트 리소스를 제공합니다. 자세한 내용은 Azure에서 개발 및 테스트를 참조 하세요.

오류에 대한 테스트입니다. 시스템에서 서비스에 연결할 수 없는 경우 시스템은 정상적으로 응답해야 합니다. 그리고 서비스를 다시 사용할 수 있게 되면 시스템이 복구되어야 합니다. 오류 삽입으로 테스트 및 스테이징 환경에서 검토의 표준 파트를 테스트합니다. 테스트 프로세스 및 사례의 완성도가 높은 경우 프로덕션에서 이러한 테스트를 실행하는 것이 좋습니다.

프로덕션에서 테스트합니다. 릴리스 프로세스는 프로덕션에 배포로 끝나지 않습니다. 테스트를 준비하여 배포된 코드가 예상 대로 작동하는지 확인합니다. 자주 업데이트하지 않는 배포의 경우 프로덕션 테스트를 기본 테넌트의 정기적인 부분으로 예약합니다.

성능 테스트를 자동화하여 성능 문제를 조기에 식별합니다. 심각한 성능 문제의 영향은 코드의 버그만큼 심각할 수 있습니다. 자동화된 기능 테스트는 애플리케이션 버그를 방지할 수 있지만 이러한 테스트는 성능 문제를 감지하지 못할 수 있습니다. 대기 시간, 로드 시간 및 리소스 사용량과 같은 메트릭에 허용 가능한 성능 목표를 정의합니다. 애플리케이션이 이러한 목표를 충족하는지 확인하기 위해 릴리스 파이프라인에 자동화된 성능 테스트를 포함합니다.

용량 테스트를 수행합니다. 애플리케이션은 테스트 조건에서 제대로 작동한 다음 규모 또는 리소스 제한으로 인해 프로덕션에 문제가 있을 수 있습니다. 항상 최대 예상 용량 및 사용량 제한을 정의합니다. 애플리케이션에서 이러한 제한을 처리할 수 있는지 테스트하고 해당 제한을 초과할 때 발생하는 작업을 테스트합니다. 정기적으로 용량 테스트를 수행합니다.

초기 릴리스 후에는 프로덕션 코드를 업데이트할 때마다 성능 및 용량 테스트를 실행해야 합니다. 기록 데이터를 사용하여 테스트를 미세 조정하고 수행해야 하는 테스트 유형을 결정합니다.

자동화된 보안 침투 테스트를 수행합니다. 애플리케이션의 보안을 보장하는 것은 다른 기능을 테스트하는 것만큼 중요합니다. 자동화된 침투 테스트를 빌드 및 배포 프로세스의 표준 부분으로 만듭니다. 배포된 애플리케이션에서 열린 포트, 엔드포인트 및 공격을 모니터링하여 기본 보안 테스트 및 취약성 검사를 예약합니다. 자동화된 테스트를 실행하더라도 정기적으로 심층 보안 검토가 필요합니다.

자동화된 비즈니스 연속성 테스트를 수행합니다. 백업 복구 및 장애 조치를 포함하여 대규모 비즈니스 연속성에 대한 테스트를 개발합니다. 이 테스트를 정기적으로 수행하도록 자동화된 프로세스를 설정합니다.

해제

배포를 자동화합니다. 자동화는 다음을 비롯한 많은 이점을 제공합니다.

  • 더 빠르고 안정적인 배포를 사용하도록 설정합니다.
  • 테스트, 스테이징 및 프로덕션을 포함하여 지원되는 모든 환경에 일관된 배포를 보장합니다.
  • 수동 배포에서 발생할 수 있는 사용자 오류의 위험을 제거합니다.
  • 편리한 시간 동안 릴리스를 쉽게 예약할 수 있으므로 잠재적인 가동 중지 시간의 영향을 최소화할 수 있습니다.

테스트, 스테이징 및 프로덕션 환경에 각 애플리케이션을 배포하는 프로세스를 자동화합니다. 롤아웃 중에 문제를 검색할 수 있는 시스템을 갖추고 수정 사항을 롤포워드하거나 변경 내용을 롤백하는 자동화된 방법을 갖습니다.

연속 통합을 사용합니다. CI(연속 통합)는 모든 개발자 코드를 정기적인 일정에 따라 중앙 코드 베이스로 병합한 다음 표준 빌드 및 테스트 프로세스를 자동으로 수행하는 방법입니다. CI는 전체 팀이 충돌 없이 동시에 코드 베이스에서 작업할 수 있도록 합니다. 또한 CI는 가능한 한 빨리 코드 결함을 찾는 데 도움이 됩니다. 코드에서 커밋하거나 검사 때마다 CI 프로세스가 실행되는 것이 좋습니다. 하루에 한 번 이상 실행해야 합니다.

트렁크 기반 배포 모델을 적용하는 것이 좋습니다. 이 모델에서 개발자는 단일 분기(트렁크)에 커밋합니다. 커밋이 빌드를 중단하지 않는 요구 사항이 있습니다. 이 모델은 트렁크에서 모든 기능 작업을 수행하고 각 커밋이 발생할 때 병합 충돌 해결하기 때문에 CI를 용이하게 합니다.

지속적인 업데이트를 사용하는 것이 좋습니다. CD(지속적인 업데이트)는 자동으로 코드를 빌드하고, 테스트하고, 프로덕션과 유사한 환경에 배포하여 항상 코드를 배포할 준비가 되어 있는 사례입니다. CD를 추가하여 전체 CI/CD 파이프라인을 만들면 가능한 한 빨리 코드 결함을 감지할 수 있습니다. 또한 짧은 시간 안에 제대로 테스트된 업데이트를 릴리스할 수 있습니다.

지속적인 배포 는 CI/CD 파이프라인을 통해 전달된 모든 업데이트를 자동으로 가져와 프로덕션에 배포하는 프로세스입니다. 지속적인 배포에는 강력한 자동 테스트와 고급 프로세스 계획이 필요합니다. 모든 팀에 적합하지 않을 수 있습니다.

작게 증분 변경합니다. 큰 코드 변경은 작은 코드보다 버그를 도입할 가능성이 더 큽니다. 가능하면 조금씩 변경합니다. 이렇게 하면 각 변경의 잠재적 영향을 제한하고 문제를 이해하고 디버깅하는 작업을 간소화할 수 있습니다.

변경 내용에 대한 노출을 제어합니다. 업데이트가 최종 사용자에게 표시되는 시기를 제어할 수 있는지 확인합니다. 기능 토글을 사용하여 최종 사용자에 대한 기능을 켤 때 제어하는 것이 좋습니다.

배포 위험을 줄이는 릴리스 관리 전략을 구현합니다. 프로덕션에 애플리케이션 업데이트를 배포하면 항상 일정한 위험이 따릅니다. 이 위험을 최소화하려면 카나리아 릴리스 또는 청록색 배포와 같은 전략을 사용하여 하위 집합의 사용자에게 업데이트를 배포합니다. 각 업데이트가 예상대로 작동하는지 확인한 다음 각 업데이트를 시스템의 나머지 부분에 롤아웃합니다.

모든 변경 내용을 문서화합니다. 사소한 업데이트 및 구성 변경 내용은 혼란과 버전 관리 충돌을 일으킬 수 있습니다. 항상 작은 것이라도 변경 내용을 명확하게 기록해둡니다. 적용한 패치, 정책 변경 및 구성 변경 내용을 포함하여 변경된 모든 내용을 기록합니다. 변경 내용의 레코드는 팀 전체에 표시되어야 합니다. 그러나 이러한 로그에는 중요한 데이터를 포함하지 마세요. 예를 들어 자격 증명이 업데이트되었고 누가 변경했는지 기록하지만 업데이트된 자격 증명은 기록하지 않습니다.

인프라를 변경할 수 없도록 하는 것이 좋습니다. 변경할 수 없는 인프라는 프로덕션 환경에 배포한 후 인프라를 수정해서는 안 된다는 원칙을 기반으로 합니다. 그렇지 않으면 임시 변경 작업이 수행되어 무엇이 변경되었는지 정확하게 알기 어려운 상태에 빠질 수 있습니다. 변경할 수 없는 인프라는 새 배포의 일부로 전체 서버를 대체하여 작동합니다. 이 방법을 사용하면 코드와 호스팅 환경을 블록으로 테스트하고 배포할 수 있습니다. 배포 후에는 다음 빌드 및 배포 주기까지 인프라 구성 요소를 수정하지 않습니다.

모니터링

시스템을 관찰할 수 있게 합니다. 운영 팀은 항상 시스템 또는 서비스의 상태 및 상태 명확하게 파악할 수 있어야 합니다. 상태 모니터링하도록 외부 상태 엔드포인트를 설정하고 애플리케이션을 코딩하여 작업 메트릭을 계측합니다. 시스템에서 이벤트를 상호 연결할 수 있도록 공통적이며 일관된 스키마를 사용합니다. Azure 리소스의 상태 및 상태 추적하는 표준 방법은 Azure Diagnostics 및 Application Insights를 사용하는 것입니다. Azure Monitor는 클라우드 또는 하이브리드 솔루션에 대한 중앙 집중식 모니터링 및 관리도 제공합니다.

로그 및 메트릭을 집계하고 상관 관계를 지정합니다. 적절하게 계측된 원격 분석 시스템은 대량의 원시 성능 데이터와 이벤트 로그를 제공합니다. 운영 직원이 항상 시스템 상태에 대한 최신 그림을 갖도록 시스템이 원격 분석 및 로그 데이터를 신속하게 처리하고 상호 연결해야 합니다. 문제를 응집력 있는 보기로 표시하고 이벤트가 서로 관련된 시기를 볼 수 있도록 데이터를 구성하고 표시합니다.

데이터를 처리하는 방법 및 데이터 저장 기간에 대한 요구 사항은 회사 보존 정책을 참조하세요.

자동화된 경고 및 알림을 구현합니다. 모니터와 같은 모니터링 도구를 설정하여 잠재적 또는 현재 문제를 나타내는 패턴 또는 조건을 검색합니다. 문제를 해결할 수 있는 팀 구성원에게 경고를 보냅니다. 거짓 긍정을 방지하도록 경고를 조정합니다.

만료할 자산 및 리소스를 모니터링합니다. 인증서와 같은 일부 리소스 및 자산은 만료됩니다. 만료될 자산, 만료 시기 및 해당 기능을 사용하는 서비스 또는 기능을 추적해야 합니다. 자동화된 프로세스를 사용하여 이러한 자산을 모니터링합니다. 자산이 만료되기 전에 운영 팀에 알리고 만료로 인해 애플리케이션이 중단될 경우 상황을 에스컬레이션합니다.

관리

운영 작업을 자동화합니다. 반복적인 작업 프로세스를 수동으로 처리하는 작업은 오류가 발생하기 쉽습니다. 이러한 작업을 자동화하면 항상 일관된 실행 및 품질을 보장할 수 있습니다. 소스 제어를 사용하여 자동화를 구현하는 버전 코드를 사용합니다. 다른 코드와 마찬가지로 자동화 도구를 테스트합니다.

프로비전에 대해 infrastructure-as-code 방법을 사용합니다. 리소스를 프로비전하는 데 필요한 수동 구성의 양을 최소화합니다. 대신 스크립트 및 Azure Resource Manager 템플릿을 사용합니다. 기본 다른 코드와 마찬가지로 스크립트와 템플릿을 소스 제어에 유지합니다.

컨테이너를 사용하는 것이 좋습니다. 컨테이너는 애플리케이션을 배포하는 데 표준 패키지 기반 인터페이스를 제공합니다. 컨테이너를 사용하는 경우 애플리케이션을 실행하는 데 필요한 소프트웨어, 종속성 및 파일을 포함하는 자체 포함 패키지를 사용하여 애플리케이션을 배포합니다. 이 방법은 배포 프로세스를 크게 간소화합니다.

또한 컨테이너는 환경 간에 일관성을 제공하는 애플리케이션과 기본 운영 체제 간에 추상화 계층을 만듭니다. 이 추상화는 컨테이너를 호스트에서 실행되는 다른 프로세스 또는 애플리케이션에서 격리할 수도 있습니다.

복원력 및 자동 복구를 구현합니다. 복원력은 오류로부터 복구하는 애플리케이션의 기능입니다. 복원력에 대한 전략에는 일시적 오류를 다시 시도하고 보조 인스턴스 또는 다른 지역으로 장애 조치하는 것이 포함됩니다. 자세한 내용은 신뢰할 수 있는 Azure 애플리케이션 디자인을 참조 하세요. 중단 또는 기타 시스템 오류를 관리할 수 있도록 애플리케이션을 계측하여 문제를 즉시 보고합니다.

작업 설명서가 있습니다. 운영 설명서 또는 Runbook은 운영 직원이 시스템을 기본 데 필요한 절차 및 관리 정보를 문서화합니다. 또한 서비스에 대한 오류 또는 기타 중단 시 수행할 수 있는 모든 작업 시나리오 및 완화 계획을 문서화합니다. 개발 프로세스 중에 이 설명서를 만들고 나중에 최신 상태로 유지합니다. 이러한 리소스를 정기적으로 검토, 테스트 및 개선해야 하는 살아있는 문서로 처리합니다.

공유 설명서가 중요합니다. 팀 멤버가 지식을 만들고 공유하도록 도와줍니다. 전체 팀이 문서에 액세스할 수 있어야 합니다. 팀의 누구나 문서를 쉽게 업데이트할 수 있어야 합니다.

대기 중 프로시저를 문서화합니다. 통화 중인 의무, 일정 및 절차를 문서화하고 모든 팀 구성원과 공유해야 합니다. 항상 이 정보를 최신 상태로 유지합니다.

타사 종속성에 대한 에스컬레이션 프로시저를 문서화합니다. 애플리케이션에서 사용자가 직접 제어할 수 없는 외부의 타사 서비스를 사용하는 경우 가동 중단 시 대처할 계획이 있어야 합니다. 계획된 완화 프로세스에 대한 설명서를 만듭니다. 지원 연락처 및 에스컬레이션 경로를 포함합니다.

구성 관리를 사용합니다. 구성 변경 내용을 계획하고, 작업에 표시하고, 기록합니다. 이러한 용도로 구성 관리 데이터베이스 또는 코드로 구성 방법을 사용할 수 있습니다. 구성을 정기적으로 감사하여 예상 설정이 실제로 적용되었는지 확인합니다.

Azure 지원 계획을 수립하고 지원 프로세스를 이해합니다. Azure는 많은 지원 계획을 제공합니다. 요구 사항에 적합한 계획을 결정하고 전체 팀이 계획을 사용하는 방법을 알고 있는지 확인합니다. 팀 멤버는 계획의 세부 정보, 지원 프로세스의 작동 방식 및 Azure에서 지원 티켓을 여는 방법을 이해해야 합니다. 확장성이 높은 이벤트가 예상되는 경우 Azure 지원에서는 서비스 제한을 증가시켜 지원할 수 있습니다. 자세한 내용은 Azure 지원 플랜 FAQ를 참조하세요.

리소스에 대한 액세스 권한을 부여할 때 최소 권한 원칙을 따릅니다. 리소스에 대한 액세스를 주의 깊게 관리합니다. 사용자에게 리소스에 대한 액세스 권한을 명시적으로 부여하지 않는 한 기본적으로 액세스를 거부합니다. 사용자에게 작업을 완료하는 데 필요한 항목에 대한 액세스 권한만 부여합니다. 사용자 사용 권한을 추적하고 기본 보안 감사를 수행합니다.

Azure 역할 기반 액세스 제어 사용 사용자 계정 및 리소스에 대한 액세스 권한을 할당하는 작업은 수동 프로세스가 아니어야 합니다. Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 Microsoft Entra ID ID 및 그룹을 기반으로 하는 액세스 권한을 부여합니다.

버그 추적 시스템을 사용하여 문제를 추적합니다. 문제를 추적할 수 있는 좋은 방법이 없으면 항목을 놓치거나 작업이 중복되거나 새로운 문제가 발생할 수 있습니다. 버그의 상태를 추적하는 데 개인 간 비공식 통신을 사용하지 마십시오. 버그 추적 도구를 사용하여 문제에 대한 세부 정보를 기록하고, 리소스를 할당하여 문제를 해결하고, 프로세스 및 상태의 감사 내역을 제공합니다.

변경 관리 시스템에서 모든 리소스를 관리합니다. 관리 및 버전 관리 시스템에 DevOps 프로세스의 모든 측면을 포함하는 경우 변경 내용을 쉽게 추적하고 감사할 수 있습니다. 코드, 인프라, 구성, 설명서 및 스크립트를 포함합니다. 테스트, 빌드 및 검토 프로세스 전체에서 이러한 모든 유형의 리소스를 코드로 처리합니다.

검사 목록을 사용합니다. 작업 검사 목록은 프로세스를 따르는 데 도움이 될 수 있습니다. 큰 설명서에서 무언가를 놓치기 쉽지만 검사 목록에 따라 달리 간과할 수 있는 세부 사항에 주의를 기울일 수 있습니다. 검사 목록을 유지 관리하고 작업을 자동화하고 프로세스를 간소화하는 방법을 지속적으로 찾습니다.

다음 단계