운영 우수성

우수한 Salesforce 솔루션은 한 번만 구축할 수 없으며 지속적으로 개선됩니다. 솔루션의 성능을 모니터링하고 작동 방식을 세분화하여 비즈니스 가치를 예측 가능하게 제공하고 중단 시 신속하게 복구할 수 있도록 시스템에 운영 우수성을 포함합니다.

운영 우수성을 무시하면 예측 가능한 결과가 솔루션에 미칠 수 있습니다. 수동 배포 프로세스는 기능 전달이 느려지고 오류 위험이 증가하는 지체 지점이 됩니다. 모니터링이 부적절하면 사용자가 문제를 보고할 때까지 사고 감지가 지연되어 영향 기간이 연장되고 Trust 저하됩니다. 자동화가 누락되면 운영 팀이 솔루션 복잡성에 비례하여 성장하여 지속 가능하지 않은 비용 경로를 생성해야 합니다. 잘못 모니터링된 배치 작업이 실패하면 데이터 또는 다운스트림 프로세스가 손상될 수 있습니다.

운영 우수성을 위해 설계된 솔루션을 사용하면 팀이 포괄적인 모니터링을 통해 시스템 동작을 관찰하고, 자동화된 파이프라인을 사용하여 안전하게 변경 사항을 배포하고, 사전 정의된 절차를 사용하여 사고에 효과적으로 대처하고, 책임 없는 검토를 통해 운영 경험에서 학습할 수 있습니다. 이러한 기능은 시간에 따라 복합됩니다. 운영 기반에 조기에 투자하는 팀은 운영 문제로 인해 반응형 투자를 강요할 때까지 운영 문제를 지연하는 팀보다 빠르고 신뢰할 수 있는 기능을 제공합니다.

운영 우수성은 다른 아키텍처 기초에 직접 연결됩니다. 신뢰성은 장애를 감지하는 모니터링과 신속한 복구를 가능하게 하는 자동화에 달려 있습니다. Trust은 운영 변경을 위해 안전한 개발 수명 주기 관행과 감사 추적을 요구합니다. 자원 최적화는 운영 텔레메트리를 통해 정보를 제공하는 지속적인 개선으로부터 혜택을 얻습니다. 비용을 최적화하려면 배포 효율성과 운영 비용 증가를 방지하는 자동화가 필요합니다. 이러한 기초는 함께 지속적인 운영 투자로 지속적인 비즈니스 가치를 제공하는 솔루션을 만듭니다.

Salesforce는 서버, 데이터베이스, 런타임, 네트워크와 같은 인프라를 운영합니다. 작업 중인 항목은 솔루션을 정의하는 메타데이터, 동작을 관리하는 구성, 플로를 통해 흐르는 데이터, 연결하는 통합, 작업을 수행하는 에이전트와 같은 상위 항목입니다.

이 책임 분할은 수행하는 모든 운영 결정을 결정합니다. Salesforce는 플랫폼을 사용 가능, 성능 및 보안 상태로 유지하면서 관찰 가능, 배포 가능, 자동화 가능, 복구 가능 솔루션을 설계해야 합니다. 플랫폼의 다중 테넌트 아키텍처는 솔루션의 운영 문제로 인해 개별 트랜잭션에 실패하는 총괄자 제한을 트리거하고 조직 전체에서 계단식으로 발생하는 행 잠금 또는 자원 충돌을 의미합니다. 추가 작업이나 재작업 없이 관찰 가능성, 배포 안전 또는 사고 준비 상태를 확인할 수 없습니다.

이 가이드에서는 Salesforce 솔루션을 신뢰할 수 있고 지속 가능한 시스템으로 전환하는 모니터링, 배포 자동화, 사고 대응, 지속적인 개선과 같은 운영 관행을 설계 및 구현하는 방법을 알아봅니다.

이러한 원칙을 사용하여 플랫폼에서 운영 우수성을 위한 아키텍처 결정을 안내합니다.

• 관찰성으로 진화합니다. 문제가 발생한 후 대응적으로 장비를 보완하지 않고 초기 버전에서 포괄적인 관찰성을 설계합니다. 관찰 가능한 시스템은 실제 조건에서 실제 동작하는 방식을 보여주며, 데이터 중심 아키텍처 개선 및 신속한 문제 진단을 지원합니다. 관찰 가능성은 처음부터 솔루션 설계를 형성하는 아키텍처 문제이며, 계측, 모니터링, 텔레메트리 수집 결정이 데이터 모델, 통합 패턴, 구성 요소 경계에 영향을 미칩니다.

• 운영 절차 표준화. 응용 프로그램 코드와 함께 소스 제어의 버전 구성 및 운영 절차 코딩된 작업을 통해 Salesforce DX 배포 자동화, Sandbox 새로 고침 자동화 및 여러 환경에서 일관되게 실행되는 메타데이터 배포가 가능합니다. 팀 구성원이 실행할 수 있는 실행 가능한 스크립트로 조직 구성 변환에 대한 Knowledge. 버전 관리에서 진행 중인 절차는 응용 프로그램 기능과 동일한 검토 및 개선 주기를 거쳐 발전하여 재현 가능한 운영 패턴을 만들어 구성 드리프트를 크게 줄입니다. 탁월성 센터를 구현합니다.

• DevOps 문화를 채택합니다. 개발, 운영, 비즈니스 팀 간의 조직적 혼란을 해소합니다. 솔루션 결과에 대한 공유 책임은 벽에 던져지는 작업을 대체합니다. DevOps 문화는 마찰을 줄이고 사용자 의견 루프를 가속화하며 운영 영향에 대한 책임을 조성합니다. 설계자는 공동 작업을 지원하는 기술 선택 항목과 공유 책임에 대한 구조적 배리어를 제거하는 조직적 지원을 통해 DevOps를 활성화합니다.

• 효율성을 위한 자동화. 반복적인 운영 작업을 자동화하여 수동 작업을 없애고, 인적 오류를 줄이고, 비용 및 자원 사용을 최적화하면서 작업을 확장할 수 있습니다. 자주 반복되는 수동 작업은 자동화에 적합한 후보입니다. 저장된 시간, 오류 감소, 생성된 운영 용량을 통해 자동화 값을 측정합니다.

• 모든 운영 이벤트에서 배웁니다. 사고, 성능 변칙, 실패 근무, 성공적인 작업에서 조직 학습을 추출합니다. 순수한 사후 작업은 개별 오류가 아닌 시스템 개선에 집중하여 정직한 평가를 위해 심리적 안전을 조성합니다. 운영 텔레매터리는 사고에 대한 패턴을 표시하여 사전 예방을 지원합니다. 학습 문화는 운영 환경을 시간에 따라 구성되는 조직 기능으로 전환합니다.

Salesforce가 운영하는 항목을 이해하면 운영 설계 노력을 사용자가 제어하는 항목에 집중할 수 있습니다. 플랫폼은 기존의 IT 환경에서 전담 팀이 필요한 인프라 문제를 처리합니다.

• 인프라 신뢰성 및 성능: Salesforce는 모든 인스턴스 전반에서 서버 용량, 데이터베이스 성능, 네트워크 가용성, 스토리지 시스템을 모니터링하고 유지합니다. 플랫폼 상태는 실시간 사고 업데이트 및 계획된 서비스 점검 창과 함께 status.salesforce.com에 표시됩니다.
• 플랫폼 업데이트 및 패치: 연간 3개의 주요 릴리스(Spring, Summer, Winter)는 새로운 기능, 보안 패치, 성능 개선 사항을 제공합니다. Salesforce는 릴리스 타이밍, API 버전 지원 및 사용 중지, 플랫폼 수준 변경 사항에 대한 변경 관리를 관리합니다. 프로덕션 배포 전에 Sandbox 환경에서 릴리스와 비교하여 솔루션을 테스트합니다.
• 다중 테넌트 자원 관리: 공유 인프라를 공정하게 유지하기 위해 총괄자 제한이 있습니다. 다른 고객과 동일한 리소스에서 실행되므로 Salesforce는 CPU 시간, 힙 크기, Salesforce 개체 쿼리 언어(SOQL) 쿼리, 데이터 조작 언어(DML) 문, API 호출과 같은 항목에 제한을 적용하므로 단일 테넌트가 용량을 과도하게 사용하지 못할 수 있습니다. Salesforce는 전체 사용량을 추적하고 라이센스 계층을 통해 일부 제한(예: API 호출)에 대해 더 높은 할당을 요청할 수 있지만, 거래당 Apex 총괄자 제한 자체는 모두에게 동일한 방식으로 고정되고 적용됩니다.
• 핵심 플랫폼 보안 작업: Salesforce 보안 팀은 위협을 모니터링하고, 취약성 공개 및 패치를 관리하고, 보안 인증을 유지하며, 플랫폼 수준 보안 사고에 대처합니다. 이 기본 보안은 솔루션별 보안 제어를 구축하는 기준선을 만듭니다.
• 재해 복구 및 무중단 업무 운영: Salesforce는 지리적으로 분산된 데이터 센터를 유지하고 재해 복구 절차를 테스트하며 고객 작업 없이 페일오버를 지원하는 중복 시스템을 유지합니다. 인프라 장애 발생 시 플랫폼 수준 복구가 투명하게 수행됩니다.

이러한 플랫폼 작업을 통해 구축할 기초가 생성됩니다. 서버, 패치 데이터베이스를 프로비저닝하거나 인프라에 대한 재해 복구를 설계하지 않습니다. 그러나 이 파운데이션 위에 구축하고 구성하는 모든 사항에 대해 책임이 있습니다.

공유 책임 모델은 Salesforce 내에서 생성하는 모든 작업에 대한 운영 우수성을 소유함을 의미합니다. 플랫폼 작업은 작업을 활성화하지만 교체할 수는 없습니다. 운영 책임은 다섯 가지 상호 연결된 영역에 걸쳐 있습니다.

관찰 가능성은 외부 출력에서 내부 시스템 상태를 이해하는 기능입니다. 관찰 가능한 Salesforce 솔루션을 사용하면 연산자가 각 조사에 대해 새 계측을 배포하지 않고도 시스템 동작에 대한 질문에 답변하고 오류를 진단하고 가설을 확인할 수 있습니다. 모니터링(사전 정의된 대시보드를 사용하여 알려진 질문에 답변)과 관찰 가능(전체적인 텔레메트리를 사용하여 임의의 질문에 답변) 간의 차이점은 프로덕션 시스템이 설계 도중 예상보다 많은 예기치 않은 동작을 생성하므로 중요합니다.

Salesforce 솔루션의 경우 관찰성이 플랫폼의 다중 테넌트 모델에 적합한 세 가지 보완 신호 유형에 걸쳐 있습니다.

• 로그 - 전체 컨텍스트 정보로 개별 이벤트를 캡처합니다. 이벤트 모니터링은 API 호출, 로그인 이벤트, Apex 실행, SOQL 쿼리, Visualforce 페이지, Lightning 페이지, 사용자 ID, 타임스탬프, 기간 및 결과를 포함한 요청 컨텍스트와 함께 보고서 실행을 캡처하는 이벤트 로그 파일을 제공합니다. "이 오류를 경험한 사용자는 누구입니까?" 및 "실행 성공과 실패 사이의 변경 사항은 무엇입니까?"와 같은 질문에 답변을 기록합니다.
• Metrics - 시간에 따라 추세와 패턴을 드러내는 집계된 숫자 측정값. 메트릭에는 API 소비율, Apex CPU 시간 분포, 배치 작업 성공률, 통합 지연 백분율 및 사용자 플로 완료율이 포함됩니다. 메트릭은 "시간에 따라 성능이 저하되고 있습니까?" 및 "총괄자 제한에 근접하고 있습니까?"와 같은 질문에 답변합니다.
• 트레이스 - 분산된 시스템을 통한 요청 경로를 표시하여 지연 소스 및 실패 지점을 표시합니다. Salesforce 솔루션의 경우 추적은 동기식 API 호출을 비동기식 처리 체인, 플랫폼 이벤트를 구독자 실행, 통합 요청을 외부 시스템 응답에 연결할 수 있습니다. "이 플로에서 대기 시간이 누적되는 위치는 어디입니까?" 및 "이 다단계 프로세스에서 실패한 구성 요소는 무엇입니까?"와 같은 질문에 대한 답변을 추적합니다.

초기 아키텍처에서 관찰 가능성을 위해 설계합니다. 활성화할 이벤트 모니터링 이벤트 유형, 운영 가시성을 위해 플랫폼 이벤트 페이로드를 구성하는 방법, 통합 검사점을 배치할 위치, 구현할 사용자 정의 로깅에 대한 결정은 모두 솔루션의 장기 운영성을 결정합니다. 관찰 가능성을 기존 솔루션에 다시 맞추려면 대부분의 구성 요소에 영향을 미치고 운영 개선 작업 중에 버그가 발생할 위험이 있는 장비 변경이 필요합니다.

Salesforce는 설계자가 처음부터 설계해야 하는 용도에 맞게 구축된 모니터링 기능을 제공합니다.

이벤트 모니터링은 조직 전체에서 상세한 운영 데이터를 수집합니다. 이벤트 유형에는 API 사용, 로그인 활동, 로그아웃 이벤트, Apex 실행, SOQL 쿼리, Visualforce 페이지 로드, Lightning 페이지 보기, 보고서 실행, 문서 첨부 파일, 콘텐츠 전송, 사용자 정의 이벤트가 포함됩니다. 이벤트 모니터링은 보안 분석, 성능 최적화, 수용력 계획, 규정 준수 보고에 대한 기반을 제공합니다.

프로덕션 환경에 대한 이벤트 모니터링을 활성화하고 외부 집계 플랫폼에 이벤트 로그 파일의 자동 내보내기를 설정합니다. 대부분의 이벤트 유형에 대해 기본 보존이 제한되어 추세 분석, 수용력 계획, 규정 준수 요구 사항에 충분하지 않습니다. 외부 집계는 내역 분석, 다른 시스템의 엔터프라이즈 Telemetry와의 상관 관계, 고급 분석, 규제 요구 사항과 일치하는 유지 기간을 지원합니다.

Proactive Monitoring은 조직의 성능 및 확장성 위험을 지속적으로 평가하여 사전 정의된 신호가 사용자에게 표시되는 사고가 되기 전에 경고합니다. Proactive Monitoring 일일 할당에 근접하는 API 요청 제한 급증, 공유 자원 충돌을 나타내는 동시 Apex 실행 실패, 총괄자 임계값에 근접한 SOQL 행 제한, 디자인 개선을 제안하는 행 잠금 충돌 등 패턴을 감지합니다.

Proactive Monitoring Salesforce에서 관리하는 사전 정의된 경고 및 경고 임계값 집합을 사용합니다. 성능 가시성을 높이고 기준선 및 추세를 조사하려는 조직을 위해 Scale Center는 CPU 시간 초과, 동시성 및 행 잠금, 총괄자 제한 오류, 데이터베이스 성능을 다루는 자세한 런타임 분석을 제공합니다.

데이터 감지(Salesforce Shield 필요)는 표준 및 사용자 정의 개체 필드를 스캔하여 텍스트, 서식 있는 텍스트 및 암호화된 필드에서 민감한 데이터(예: 개인 식별 정보(PII))를 식별, 분류 및 수정합니다. 패턴 일치 및 사용자 정의 regex가 포함된 네이티브 플랫폼 처리를 사용하여 거짓 양성을 최소화합니다. 이미 분류되거나 사용되지 않는 필드를 제외하고 새 레코드 또는 수정된 레코드를 대상으로 반복 검색(매주 또는 매월)을 실행합니다.

결과를 사용하여 다운스트림 관리를 촉진하고 규정 준수 분류를 업데이트하거나 Shield Platform Encryption 적용하거나 이벤트 모니터링 보안 정책을 트리거하거나 Sandbox 데이터 마스킹을 적용합니다.

Scaling Center는 장기 실행 작업, 처리량 패턴, 예외 핫스팟, 총괄자 제한 소비량에 대한 트랜잭션 수준의 가시성을 제공합니다. 스케일 센터는 가장 많은 자원을 소비하는 작업, 시간 초과 임계값에 도달한 트랜잭션, 최적화 투자가 운영에 가장 큰 영향을 미치는 위치를 보여줍니다.

솔루션 안정화 시 Scale Center 기준선을 설정하고 각 주 릴리스 후 기준선을 다시 확인합니다. 컨텍스트가 없는 성능은 해석하기 어렵습니다. 기준선 비교는 변경 사항이 성능을 향상했는지 또는 저하했는지 여부를 표시하여 추가 최적화 결정을 안내합니다.

• 설정 감사 내역: 권한 수정, 메타데이터 배포, 관리 작업 및 보안 설정 업데이트를 비롯한 구성 변경 사항을 추적하며 기본적으로 최대 180일 동안 보존됩니다. 설정 감사 내역은 어떤 구성을 변경한 사람과 시기를 표시하여 보안 조사, 규정 준수 확인, 사고 사후 상태를 지원합니다. 규정 준수 또는 계약 요구 사항에 따라 내역 기간이 더 긴 경우 180일 이상 유지되도록 설정 감사 내역 항목을 내보냅니다.
• 필드 감사 내역:(Salesforce Shield 필요) 내역 필드 값 변경 사항을 추적합니다. 내역 값을 이해하는 것이 운영 및 규정 준수 보고에 도움이 되는 중요한 비즈니스 데이터 또는 변경 내역이 필요한 규제된 데이터, 중요한 데이터가 포함된 필드에 대해 선택적으로 필드 감사 내역을 활성화합니다.
• 건전 검사: Salesforce 보안 기준 권장 사항과 현재 설정을 비교하는 자동 보안 구성 평가를 제공합니다. 분기별 상태 확인 검토를 예약하고 환경의 위험 우선 순위를 기반으로 결과를 수정합니다. 보상 제어 또는 기본 권장 사항과 다른 위험 허용치가 있는 경우 일부 결과에 수정이 필요하지는 않지만 모든 결과를 의도적으로 검토해야 합니다.

플랫폼 모니터링은 조직 수준의 상태를 표시하지만 응용 프로그램별 문제는 누락합니다. 중요 비즈니스 여정을 계측하여 사용자 관점에서 응용 프로그램 상태를 모니터링합니다.

비즈니스 영향을 기반으로 중요 사용자 프로세스를 정의하고 전체 성공률, 완료 시간, 중단 시점, 오류 비율을 모니터링합니다. 일반적으로 중요한 플로는 수익 창출 활동(주문 제출, 계약 실행, 기회 마감), 대용량 활동(사용자 로그인, 검색 작업, 레코드 생성), 규정 준수 요구 활동(동의 수집, 데이터 주체 권한 이행, 감사에 민감한 워크플로)이 포함됩니다.

각 중요 단계에서 시작, 완료, 중단, 실패를 나타내는 중대 사건 마커가 있는 계측 프로세스입니다. 플로 성공률이 허용되는 임계값 미만이거나 기간이 대기 시간 대상을 초과하는 경우 경고합니다. 프로세스 수준 모니터링은 여러 Apex 클래스, 여러 플로, 3개의 플랫폼 이벤트 및 2개의 외부 통합을 접하는 사용자 여정이 모든 전환 지점에서 실패할 수 있기 때문에 구성 요소 수준 모니터링에서 보이지 않는 문제를 드러냅니다.

통합 상태를 양방향으로 모니터링합니다. 성공률, 대기 시간, 재시도 패턴, 오류 유형에 대한 외부 시스템에 대한 아웃바운드 호출을 추적합니다. 외부 시스템에서 볼륨 패턴, 인증 실패, 데이터 확인 오류, 처리 기간에 대한 인바운드 호출을 추적합니다. 통합 모니터링은 작업자가 감지하기 전에 외부 시스템 문제를 드러내므로 사전 예방적 에스컬레이션이 활성화됩니다.

외부 파트너와 통합 SLA를 수립하고 확정된 목표 대비 실제 성과를 모니터링합니다. 서비스 수준 계약(SLA) 위반이 발생하면 Telemetry는 Salesforce, 통합 계층, 네트워크 경로 또는 외부 시스템에서 발생하는 문제 여부를 구별합니다. 이 구분은 사고 에스컬레이션 및 계약 협상 중에 중요합니다.

서비스 수준 지표(SLI)는 사용자가 인식하는 품질을 나타내는 신중하게 선택된 메트릭입니다. 서비스 수준 목표(SLO)는 사용자 기대와 운영 투자의 균형을 맞추는 SLI의 대상 값입니다. Salesforce 솔루션의 경우 유효 SLI에는 다음이 포함됩니다.

• 가용성: 솔루션이 사용자 요청에 성공적으로 응답하는 시간 비율입니다. 인프라 관점이 아닌 사용자 관점에서 가용성을 측정합니다. 플랫폼을 사용할 수 있지만 싱글사인온(SSO) 구성 오류로 인해 사용자가 로그인할 수 없는 솔루션은 플랫폼 가동 시간에 관계없이 사용할 수 없습니다.
• 대기 시간: 사용자 작업 시작부터 표시 응답까지의 시간입니다. 평균은 가장 느린 요청으로 인한 끔찍한 경험을 숨기므로 평균 대비 특정 백분위수(p50, p90, p99)에서 대기 시간 대상을 정의합니다. 8초의 p99 대기 시간은 100건 중 1건의 요청이 8초 이상 걸리므로 트래픽이 많은 솔루션에서 매일 수천 건의 불량 환경을 나타낼 수 있습니다.
• 성공률: 사용자에게 표시되는 오류 없이 완료된 작업 비율 사용자로 인한 오류(올바르지 않은 입력, 권한 부족)와 시스템으로 인한 오류(관리자 제한 실패, 통합 시간 초과, 처리되지 않은 예외)를 구분합니다. 시스템으로 인한 오류만 성공률 SLO에 포함됩니다.
• 지출량: 시간 단위당 완료된 작업량입니다. 처리 수용력에 따라 비즈니스 기한을 충족하는 경우 배치 처리, 데이터 가져오기, 예약된 작업, 대량 작업에 대한 처리량이 중요합니다.

기술 기능이 아닌 사용자 요구 사항을 기반으로 SLO를 설정합니다. 질문은 "이 작업을 얼마나 빠르게 수행할 수 있습니까?"가 아니라 "사용자가 목표를 달성하기 위해 얼마나 빠르게 수행해야 합니까?"입니다. 사용자가 2초를 허용할 경우 200ms 페이지 로드 대상은 의미가 없습니다. 반대로 사용자가 500ms 후에 중단하면 2초 대상이 의미가 없습니다. 사용자 연구, 세션 분석, 비즈니스 요구 사항을 통해 실질적인 SLO 목표를 달성할 수 있습니다.

SLI 굽기 비율을 모니터링하여 누적된 SLO 위반이 오류 예산을 추출하는 시점을 감지합니다. 오류 예산은 사용자 환경과 운영 투자의 균형을 맞추는 허용되는 실패 비율을 나타냅니다. 굽기 비율이 지속 가능한 수준을 초과하면 SLO가 복구될 때까지 기능 작업을 중지하고 신뢰도 향상에 집중합니다. 이 규격은 팀이 재해가 발생할 때까지 기능 기한을 따르면서 신뢰도가 저하되는 패턴을 무시하는 일반적인 패턴을 방지합니다.

자동 시스템이 사람의 판단이나 조치가 필요한 문제를 감지하면 경고가 사람에게 알립니다. 효과적인 경고는 범위(실제 문제 감지)와 정밀도(거짓 경고 방지)의 균형을 맞춥니다. 경고가 부족하면 사고(경고 수가 너무 적거나 임계값이 너무 높음)가 누락되거나 작업자가 알림을 무시하는 방법을 학습하는 경고 피로(경고 수가 너무 많거나 임계값이 너무 낮음)가 생성됩니다.

실천 가능성에 대한 알림을 설계합니다. 모든 경고는 다음 세 가지 질문에 답변해야 합니다.

1. 문제는 무엇입니까?
2. 중요한 이유는 무엇입니까?
3. 어떻게 해야 할까요?

명확한 답변이 없는 경고는 운영자가 무시하도록 교육합니다. 예를 들어, 어떤 API, 어떤 통합 또는 수행할 조치에 대한 컨텍스트가 없는 "API 호출이 제한의 80%를 초과함"이라는 경고는 응답에 대한 정보가 부족합니다.

운영 에스컬레이션 절차와 일치하는 경고 심각도 수준을 구현합니다.

• 중요한 경고: 일과 시간에 상관없이 즉각적인 대응이 필요한 사용자 지향 서비스 저하를 나타냅니다. 중요 경고 페이지 온콜 엔지니어 예로 설정된 임계값을 초과하는 로그인 실패, 가용성 SLO 미만의 수익 창출 플로 또는 데이터 손실 감지가 있습니다.
• 경고 경고: 중재 없이 중요해질 수 있지만 아직 사용자에게 영향을 미치지 않는 문제를 나타냅니다. 경고는 업무 시간 조사에 대한 티켓을 생성합니다. 예를 들어 API 소비 추세가 일일 제한을 향한 추세, SLA 대상을 완료하지만 누락된 배치 작업 또는 통합 오류가 증가하지만 계속해서 실패 임계값 미만인 경우가 있습니다.
• 정보 알림: 조치를 취하지 않고 운영 변화에 대한 인식을 제공합니다. 정보 경고는 모니터링 대시보드에 표시되지만 알림은 생성되지 않습니다. 배포 성공, 예약된 서비스 점검 완료 또는 구성 변경을 예로 들 수 있습니다.

경고 검토 케이던스를 설정하여 경고 품질을 평가하고 실제 사고 패턴을 기반으로 임계값을 조정합니다. True 긍정 비율(실제 문제를 나타내는 경고), false 긍정 비율(문제가 없는 경우 경고), 해결 시간(경고가 사고 해결으로 이어지는 속도)을 포함한 경고 메트릭을 추적합니다. 높은 False Positive 비율은 작업자 Trust 복원하기 위해 조정해야 하는 과도하게 민감한 임계값을 나타냅니다.

DevOps 문화는 초기 코드 커밋에서 프로덕션 작업을 통해 솔루션 결과를 소유하는 통합 팀의 개발 및 운영 책임을 결합합니다. DevOps는 개발자가 효율적으로 실행할 수 있는 컨텍스트가 없는 운영 팀에 작업을 할당하는 기존의 사일로 조직과 비교하여 더 빠른 배달, 더 높은 품질, 더 나은 운영 결과를 제공합니다.

소스 중심 개발은 메타데이터, 구성, 코드, 문서와 같은 모든 솔루션 아티팩트를 조직에만 존재하는 포인트 앤 클릭 설정이 아닌 버전 제어 소스 파일로 처리합니다. 소스 제어는 재현 가능한 빌드, 공동 작업 개발, 변경 추적, 자동화된 배포 파이프라인을 활성화합니다.

Salesforce DX 소스 중심 개발을 위한 도구를 제공합니다. 메타데이터 API는 조직 구성을 XML 파일로 노출합니다. 스크래치 조직은 소스 제어에서 생성된 폐기 가능한 개발 환경을 제공합니다. CLI 도구는 스크립트된 배포 및 조직 조작을 활성화합니다. Git 등 버전 관리 시스템은 변경 사항을 추적하고 공동 작업 워크플로를 활성화합니다.

의도적으로 메타데이터를 구조화하여 팀 공동 작업을 활성화합니다. 모듈식 패키지 구조를 사용하면 팀이 병합 충돌 없이 독립적으로 작업할 수 있습니다. 기능별 구성 요소(Apex 클래스, 플로 및 Lightning 구성 요소)와 공유 구성 요소(페이지 레이아웃, 권한 집합 및 사용자 정의 필드)를 분리합니다. 소유권 경계를 명확히 지정하면 모든 사람이 모든 것을 바꾸는 혼란을 방지할 수 있습니다.

코드 검토는 변화가 생산에 도달하기 전에 품질 관리, Knowledge 공유, 학습 기회를 제공합니다. 효과적인 코드 검토는 철저성과 속도의 균형을 이루어 배포 지체가 되지 않고 의미 있는 사용자 의견을 제공합니다.

명확한 검토 기준을 설정합니다. 검토자는 다음을 확인합니다.

• 정확성 - 코드가 주장하는 대로 수행합니까?
• 유지 보수 - 향후 개발자가 이를 이해하고 수정할 수 있습니까?
• 성능 - 이 접근 방식을 적절하게 확장합니까?
• 보안 - 삽입 위험 또는 권한 우회가 있습니까?
• 일관성 - 프로젝트 패턴 및 표준과 일치합니까?

명시적인 기준이 없으면 검토가 주관적이거나 표면적이 됩니다.

프로덕션 바운드 변경 사항에는 승인이 두 개 필요합니다. 단일 검토자 승인은 Knowledge 사일로를 생성하고 대체 관점이 포착할 수 있는 문제를 놓칩니다. 2명의 검토자 요구 사항은 Knowledge 배포하고, 버스 계수를 1개 이상으로 유지하며, 더 많은 결함을 파악합니다. 팀 규모에 대한 승인 요구 사항의 균형을 맞추십시오. 5명 팀에서 3개의 승인을 받아야만 지체 지점을 만들 수 있습니다.

가져오기 요청(PR)을 작게 유지합니다. 검토자가 엄청난 인지 부담에 직면하므로 수백 개의 변경된 행이 있는 PR는 간단한 검토를 받습니다. 200~400줄의 한 기능을 변경하는 PR는 미묘한 문제를 파악하는 철저한 검토를 받습니다. 대규모 기능을 검토 가능한 청크로 나누어 증분적으로 전달합니다.

기계 검사를 자동화합니다. 코드 서식, 명명 규칙 준수, 테스트 적용 범위 요구 사항, 정적 분석 검사는 검토자의 주의를 끌지 않고 자동으로 실행되어야 합니다. 검토자는 인간의 판단이 필요한 논리, 설계, 유지 관리 기능 질문에 집중해야 합니다.

테스트를 수행하면 솔루션이 올바르게 작동하고 변경 사항이 누적될 때 계속 작동하는지 확신할 수 있습니다. 효과적인 테스트는 실행 속도(테스트 도구 모음 완료 속도) 및 서비스 점검 부담(테스트 유지 관리에 필요한 노력이 얼마나 많은지)와 적용 범위(코드 및 기능 테스트 실행량)의 균형을 맞춥니다.

• 장치 테스트: 개별 구성 요소를 분리하여 검증합니다. Apex 단위 테스트는 기존 조직 데이터 및 외부 종속성과 분리된 방식 및 클래스를 검증합니다. Lightning 웹 구성 요소 테스트는 백엔드 API 없이 구성 요소 논리 및 렌더링을 검증합니다. 잘 설계된 단위 테스트는 몇 초 만에 실행되므로 개발 중에 즉각적인 사용자 의견을 제공합니다. 단위 테스트에서만 75% 이상의 최소 요구 사항 코드 적용 범위를 목표로 지정하고 적용 범위를 최하위 수준으로 처리합니다.
• 통합 테스트: 구성 요소 간 상호 작용을 검증합니다. 통합 테스트는 실제 데이터베이스 작업, 모의 외부 시스템에 대한 실제 콜아웃, 인증된 총괄자 제한 동작을 실행합니다. 통합 테스트는 예기치 않은 데이터 상태, 권한 문제, 대량 작업 제한, 트리거 주문 종속성 등 단위 테스트가 놓친 가정을 포착합니다. 통합 테스트는 테스트당 초~분 단위로 실행됩니다.
• 엔드 투엔드(E2E) 테스트: 로그인에서 작업 완료까지 전체 사용자 여정을 검증합니다. E2E 테스트는 전체 Sandbox 환경에서 실행되며 UI 상호 작용, 백엔드 프로세스, 비동기식 작업 및 통합 접점이 적용됩니다. E2E는 경쟁 조건, 예기치 않은 사용자 워크플로, 환경 구성 문제 등 전체 시스템이 실행될 때만 발생하는 문제를 포착합니다. 포괄적인 도구 모음의 경우 E2E 테스트가 분~시간 이내에 실행됩니다.
• 성능 테스트: 로드 상태에서 솔루션의 동작을 검증합니다. 성능 테스트는 실질적인 트래픽 패턴에서 응답 시간, 처리량, 리소스 소비량, 총괄자 제한 근접성을 측정합니다. 성능 테스트를 통해 성능을 저하하는 변경 사항의 릴리스를 방지하고, 프로덕션 전에 N+1 쿼리 패턴을 파악하고, 최대 계절 전에 수용력 머리글을 확인할 수 있습니다. 성능 테스트에는 프로덕션과 유사한 데이터 볼륨이 필요하며 전용 테스트 환경에서 실행됩니다.

테스트 피라미드 전략을 구현합니다. 많은 빠른 단위 테스트, 더 적은 통합 테스트, 선택적 E2E 테스트와 로드 시 별도로 확인되는 성능 테스트. 이 균형을 유지하면 신속한 반복(빠른 단위 테스트에서 즉각적인 피드백을 제공)이 가능하며 통합 지점이 올바르게 작동하는지 확인할 수 있습니다(통합 테스트에서 교차 구성 요소 문제를 파악), 사용자 환경이 허용되는지 확인할 수 있습니다(E2E 테스트에서 전체 여정을 확인합니다).

CI 파이프라인에서 테스트 실행을 자동화합니다. 커밋하기 전에 테스트 도구 모음을 수동으로 실행하지 말고 커밋할 때마다 CI가 테스트 도구 모음을 자동으로 실행하도록 합니다. 자동 테스트는 회귀를 즉시 파악하고, 품질 표준을 일관적으로 적용하며, 마감 기간 동안 수동 테스트가 선택 사항이 될 때 발생하는 점진적인 품질 저하를 방지합니다.

연속 통합(CI) 및 연속 배포(CD) 파이프라인은 코드 커밋에서 프로덕션 배포로의 경로를 자동화합니다. CI/CD는 인적 오류를 줄이고 피드백을 가속화하며 일관된 품질 검사를 제공하며 신속한 릴리스 케이던스를 활성화합니다.

• 연속 통합은 모든 코드 커밋을 자동으로 구축, 테스트 및 검증합니다. 개발자가 버전 관리에 커밋을 푸시하면 CI 시스템이 새 조직을 구축하고, 변경 사항을 배포하고, 자동화된 테스트 도구 모음을 실행하고, 정적 코드 분석을 수행하고, 테스트 적용 범위 요구 사항을 확인하고, 몇 분 이내에 결과를 보고합니다. 빠른 사용자 의견을 사용하면 개발자가 수동 통합 테스트를 수행하는 동안 며칠 후에 문제를 발견하지 않고 컨텍스트가 새롭게 바뀌는 동안 문제를 해결할 수 있습니다.

기본 지점에 병합을 허용하기 전에 CI 성공을 요구합니다. 이 규칙(일반적으로 "기본 보호"라고도 함)은 다른 개발자를 차단하는 공유 지점에서 손상된 코드가 누적되는 것을 방지합니다. CI 게이트가 있는 보호 지점은 언제든지 기본 지점을 배포할 수 있도록 유지하므로 릴리스 - when-main-happens-to-work가 아닌 - on-demand를 활성화합니다.

• 연속 배포는 환경을 통해 검증된 변경 사항을 자동으로 운영에 배포합니다. CI가 분리된 환경에서 변경 사항을 확인한 후 CD 파이프라인이 통합 Sandbox에 배포되고, 추가 테스트를 실행하거나, 스테이징에 배포하고, 최종 유효성 검사를 실행하고, 경우에 따라 자동으로 또는 수동 승인 게이트 후에 프로덕션에 배포됩니다.

프로덕션 배포 동안 폭발 반경을 제한하는 프로그레시브 배포 전략을 구현합니다.

• 파란색 배포: 두 개의 동일한 생산 환경을 유지합니다. 트래픽은 파란색 환경으로 라우팅되고, 녹색 환경은 새 배포를 수신합니다. 확인 후 트래픽이 녹색 환경으로 전환됩니다. 파란색 환경은 계속해서 인스턴트 롤백 대상으로 실행됩니다.
• Canary 배포: 전체 배포 전에 소규모 사용자 하위 집합에 대한 변경 사항을 릴리스합니다. 초기 Canary는 오류 비율, 대기 시간 및 사용자 동작을 모니터링하면서 소규모 트래픽 비율을 수신합니다. 성공한 캐나리아는 점진적으로 확장됩니다(예: 5%에서 25%, 50%, 100%). Canary 배포 동안 감지된 문제는 모든 사용자에게 영향을 미치기 전에 릴리스가 중단됩니다. Canary 배포는 선택적 기능 노출을 활성화하는 외부 라우팅 레이어 또는 기능 플래그가 있는 Salesforce 솔루션에 적합합니다.
• 기능 플래그: 배포 타이밍과 관계없이 기능 가시성의 런타임을 제어할 수 있습니다. 새 기능은 프로덕션에 배포되지만 명시적으로 활성화될 때까지 플래그 뒤에 숨겨져 있습니다. 기능 플래그는 코드를 배포하지 않고 플래그를 전환하여 Canary 배포, A/B 테스트, 점진적 롤아웃, 즉각적인 롤백을 지원합니다.

노트: Canary 및 blue-green 배포 패턴은 리소스 할당 및 트래픽 배포 제어를 통해 CloudHub 2.0에 배포된 Heroku 또는 MuleSoft 응용 프로그램에서 호스팅되는 사용자 정의 응용 프로그램에 적용됩니다. 핵심 Salesforce Platform 메타데이터 배포는 모두 또는 아무것도 트랜잭션입니다.

IaC(Infrastructure as Code)는 환경의 정의(조직 형태, 메타데이터, 종속성, 구성 및 기능을 제공하는 시드 데이터)를 각 조직에서 수동으로 수행한 설정이 아닌 버전 제어 소스로 처리합니다. Salesforce에서는 프로비저닝할 서버가 없으므로 IaC는 하드웨어가 아닌 환경을 어셈블하는 방법을 관리합니다. 코딩된 환경은 재현 가능하고, 비교 가능하며, 폐기 가능하며, 바로 이 환경이 드리프트되지 않도록 방지합니다.

환경은 수동 구성이 아닌 소스에서 정의됩니다. 스크래치 조직 정의 파일은 Edition, 활성화된 기능, 설정을 지정하므로 누구나 또는 파이프라인이 요청 시 동일한 폐기 가능한 조직을 회전할 수 있습니다. Sandbox는 다른 경로를 따릅니다. 복사 유형 및 템플릿의 이름을 지정하는 정의에서 프로비저닝된 다음, 복제한 프로덕션 조직의 구성을 상속하여 통합 및 스테이징을 위한 더 높은 충성도 환경을 제공합니다. 패키지 정의는 솔루션의 구성 요소 및 종속성을 선언하여 구축을 소스에서 재현할 수 있으며, 장기적인 조직의 누적된 상태에 의존하지 않습니다.

모든 환경이 가정하는 기준선도 버전이 지정됩니다. 사용자 정의 메타데이터, 명명된 자격 증명 구성, 사용자 정의 설정 정의가 메타데이터로 배포되고, 값 설정 및 참조 레코드는 버전이 지정된 시드 데이터에서 로드됩니다. 코드와 함께 소스 제어를 유지하면 각 환경이 수동으로 구성된 기준이 아닌 알려진 일관된 기준에서 시작됩니다.

이 방식으로 환경을 코딩하면 소스에서 구성 드리프트를 공격합니다. 환경의 정의가 버전 관리에 적용되면 환경 간의 차이점이 자동 분산이 아닌 가시적인 차이로 표시되며, 정리된 환경을 디버깅하는 것보다 빠르게 정리된 환경을 재구축할 수 있습니다. 소스에서 다시 프로비저닝하면 환경이 손상될 때 복구 시간이 단축되고 수동 설정 없이 파이프라인이 각 변경 사항에 대해 폐기 환경을 지원할 수 있습니다.

Sandbox는 프로덕션 데이터 또는 구성에 위험을 미치지 않고 개발, 테스트, 교육을 위한 분리된 환경을 제공합니다. 효과적인 Sandbox 전략은 환경 충성도(Sandbox가 프로덕션과 얼마나 근접한지)와 비용 및 새로 고침 주기의 균형을 맞춥니다.

• 개발자 샌드박스는 개별 기능 개발을 위한 가볍고 분리된 환경을 제공합니다. 개발자는 공유 종속성과 통합 테스트를 위해 개발자 Sandbox를 사용하여 일상적인 작업을 위해 소스 제어에서 스크래치 조직을 만듭니다. Developer Sandbox 및 스크래치 조직은 자주 새로 고쳐 프로덕션과 구성을 동기화합니다.
• 통합 Sandbox(개발자 프로 또는 부분 복제본)는 여러 기능이 통합되고 상호 작용하는 공유 환경을 제공합니다. 통합 Sandbox에는 전체 데이터 복제의 비용과 복잡성 없이 실질적인 워크플로를 테스트할 수 있는 충분한 프로덕션 데이터가 포함되어 있습니다. 단계화로 승격하기 전에 통합 Sandbox에 대한 통합 테스트가 실행됩니다.
• 스테이징 샌드박스(전체 복제본)는 프로덕션 구성 및 데이터를 반영하여 프로덕션 배포 전에 최종 검증을 제공합니다. Staging Sandbox는 프로덕션 전에 릴리스를 수신하므로 배포 절차, 성능 특성, 데이터 마이그레이션 스크립트를 프로덕션 방식으로 테스트할 수 있습니다. 스테이징 Sandbox는 분기별로 또는 주 릴리스 전에 새로 고쳐집니다.
• 교육 샌드박스는 실제 고객 데이터를 노출하지 않고도 사용자 교육 및 데모를 위한 현실적인 환경을 제공합니다. 교육 Sandbox에는 합성 데이터 또는 익명화된 프로덕션 데이터가 포함될 수 있습니다. 교육 환경은 지속적인 교육 자료 및 인증 프로세스를 지원하기 위해 장기간 안정적으로 유지됩니다.

Sandbox 새로 고침 및 데이터 로드를 자동화합니다. 수동 Sandbox 새로 고침은 프로덕션 유사 데이터로 자주 테스트를 방지하는 지체 상태가 됩니다. 데이터 로딩 스크립트와 결합된 자동 새로 고침 절차는 주문형 환경 재설정을 지원하므로 연속 통합 파이프라인과 수동 테스트 요구를 모두 지원합니다.

참고: "Sandbox"는 에이전트 엔터프라이즈의 두 가지 고유한 의미입니다. 위의 Sandbox는 환경입니다. 변경 사항이 프로덕션에 도달하기 전에 팀이 구축하고 테스트하는 조직의 분리된 복사본입니다. 에이전트의 작업 Sandbox는 다릅니다. 이는 범위가 지정된 권한, 제한된 개체 및 통합 액세스, 제어된 실행을 통해 자동 작업이 실행되는 위치와 방법을 제한하는 런타임 경계이므로 에이전트가 의도한 범위를 넘을 수 없습니다. 두 가지 항목은 보완적입니다. Developer Sandbox 비프로덕션 데이터에 대한 에이전트의 작업을 확인하고 작업 Sandbox는 프로덕션에서 해당 작업을 포함합니다.

자동화된 파이프라인을 사용하는 경우에도 배포에는 위험이 있습니다. 안전한 배포 관행은 확인, 모니터링, 제어 실행을 통해 위험을 완화합니다.

• 배포 검증: 변경 사항을 적용하지 않고 배포를 건전 실행으로 실행합니다. 확인은 실제 배포 전에 누락된 종속성, 구성 요소 충돌, 잘못된 참조와 같은 배포 오류를 포착합니다. Salesforce는 UI 및 CLI를 모두 통해 유효성 검사 배포를 지원하므로 실제 배포가 서비스 점검 기간을 대기하는 경우에도 업무 시간 동안 프로덕션에서 유효성을 검사할 수 있습니다.
• 배포 모니터링: 배포 도중 및 후 주요 메트릭을 모니터링합니다. 오류율, 성능 메트릭, 사용자 플로 성공률, API 소비를 모니터링합니다. 배포 후 갑작스러운 변경 사항은 조사 및 롤백이 필요한 회귀를 나타냅니다. 자동 모니터링은 배포 전 메트릭과 배포 후 메트릭을 비교하여 통계 편차가 임계값을 초과할 경우 경고를 보냅니다.
• 배포 실습 문서: 사전 요구 사항, 실행 단계, 검증 검사, 롤백 절차, 통신 계획을 비롯한 배포 절차를 문서화합니다. 런북은 스트레스가 많은 부족 Knowledge 의식에서 누구나 수행할 수 있는 일상적인 절차로 배포를 변환합니다. 실행북은 학습된 내용을 수집하고 문제 재발을 방지하는 배포 소급을 통해 발전합니다.
• 롤백 기능: 배포에 실패할 경우 이스케이프 경로를 제공합니다. Salesforce 메타데이터 롤백을 수행하려면 기본 롤백 명령 대신 이전 버전을 다시 배포해야 하므로 버전 관리가 중요합니다. 모든 프로덕션 버전에 대한 배포 패키지를 유지하여 신속하게 재배포할 수 있습니다. 데이터 변경의 경우 복원을 활성화하는 배포 전 백업을 유지하십시오. 구성 변경의 경우 설정 감사 내역에서 이전 값을 추적하십시오.

배포 영향이 더 적은 사용자에게 영향을 미치는 트래픽이 적은 기간 동안 배포 일정을 예약합니다. 주말 및 저녁 배포는 비즈니스 위험을 최소화하지만 운영 부담을 늘립니다. 팀 지속 가능성에 대한 사용자 영향의 균형을 맞춥니다. 강력한 배포 관행 및 포괄적인 모니터링이 있는 솔루션은 업무 시간 동안 안전하게 배포할 수 있지만, 입증되지 않은 솔루션은 신뢰를 구축할 때까지 시간 외 배포의 혜택을 누릴 수 있습니다.

구성은 조직 설정, 기능, 권한, 통합, 사용자 정의 등 솔루션 동작을 관리하는 메타데이터입니다. 구성 변경 사항은 코드 배포 없이 즉시 실행되는 솔루션에 영향을 미치므로 구성 관리는 운영 안정성에 매우 중요합니다.

코드와 함께 소스 제어의 버전 구성 프로필 정의, 권한 집합 할당, 사용자 정의 설정, 플랫폼 이벤트 정의, 명명된 자격 증명, 원격 사이트 설정 모두 버전 관리에 속합니다. 버전이 지정된 구성은 배포 자동화, 변경 추적, 환경 일관성, 롤백 기능을 지원합니다.

구성 드리프트를 감지하고 수정합니다. 시간이 지남에 따라 관리자가 직접 변경하고 핫픽스가 일반 배포 프로세스를 우회하고 문서화되지 않은 해결 방법이 누적되므로 프로덕션 조직이 문서화된 구성에서 드리프트됩니다. 프로덕션 구성과 버전 관리를 자동으로 비교하면 드리프트가 표시됩니다. 분기별 드리프트 감지 및 수정 일정을 예약하여 배포가 예측할 수 없는 지점까지 구성 부채가 누적되지 않도록 합니다.

구성 결정 및 근거를 문서화합니다. 향후 관리자는 구성된 사항뿐만 아니라 이유를 이해해야 합니다. 조직 전체 기본값을 계정에 대해 비공개로 설정하고 연락처에 대해 공개로 설정하려면 이 결정을 이끄는 비즈니스 요구 사항을 설명하는 문서가 필요합니다. 문서화된 근거가 없으면 향후 변경 사항이 비즈니스 프로세스에 포함된 가정을 어기고 있을 수 있습니다.

자동화는 반복적인 수동 작업을 피하고, 인적 오류를 줄이며, 인원 수가 비례하여 증가하지 않고 작업을 확장할 수 있도록 합니다. Salesforce 솔루션의 경우 자동화 기회는 선언적 플랫폼 기능, 프로그래밍 자동화, 운영 절차에 적용됩니다.

Salesforce의 선언적 자동화 도구 Flow Builder, 수식 필드, 확인 규칙, 승인 프로세스를 사용하면 비개발자가 코드 없이 복잡한 비즈니스 논리를 구현할 수 있습니다. 선언적 자동화는 거버넌스 장점(관리자가 배포 없이 수정할 수 있음), 투명성(시각적 디자인 문서 자체), 플랫폼 최적화(선언적 작업은 동등한 코드보다 효율적으로 실행되는 경우가 많음)을 제공합니다.

• Flow Builder: 사용자 상호 작용, 데이터 조작, 비즈니스 논리, 통합을 결합하여 복잡한 프로세스를 자동화합니다. 플로는 종속 조회, 조건부 승인 라우팅, 다단계 데이터 가져오기, 예약된 정리 작업, 오류 알림 워크플로 등 일반적인 패턴을 처리합니다. 자동 실행 플로는 레코드 변경, 예약 간격 또는 코드에서 명시적 호출에 대해 실행됩니다. 화면 플로는 사용자 입력에 기반한 분기 논리를 사용하여 사용자에게 다단계 프로세스를 안내합니다.

재사용 가능성 및 유지 관리 기능을 위해 플로를 설계합니다. 하위 플로는 여러 상위 플로에서 재사용하는 일반적인 패턴(오류 처리 또는 레코드 잠금 논리 등)을 캡슐화합니다. 명명된 플로 변수와 명시적 설명은 향후 관리자가 이해할 수 있는 자체 문서화 논리를 만듭니다. 모듈식 플로 설계를 사용하면 통합 전에 개별 구성 요소를 테스트할 수 있습니다.

• 수식 필드: 코드 또는 데이터베이스 업데이트 없이 다른 필드에서 동적으로 값을 계산합니다. 수식은 복잡한 계산, 조건부 논리, 날짜 산술, 텍스트 조작을 지원합니다. 수식 필드는 보고서, 목록 보기, 확인 규칙 및 플로에서 작동하여 다양한 컨텍스트에서 일관된 계산을 제공합니다. 수식은 데이터베이스 저장소를 사용하지 않고 레코드 액세스 시 즉시 계산하므로 효율적으로 실행됩니다.
• 확인 규칙: 데이터 품질을 적시에 적용합니다. 확인 규칙은 데이터 입력 오류를 포착하고 비즈니스 규칙을 적용하거나 잘못된 상태 전환을 방지합니다. 표준 및 사용자 정의 개체에 확인 규칙을 배치하여 데이터 소스(UI, API, Data Loader, 통합)와 관계없이 오류를 포착합니다. 올바르게 작성된 확인 규칙 오류 메시지는 암호화된 기술 메시지로 사용자에게 문제를 방지하는 대신 문제를 해결하도록 안내합니다.
• 승인 프로세스: 상태 승격 전에 필요한 승인을 통해 레코드를 라우팅합니다. 승인 프로세스는 서명 기관 계층, 규정 준수 검토, 법적 승인, 다자간 동의 워크플로를 구현합니다. 승인 프로세스는 사용자 정의 개발 없이 무엇을 승인했는지 및 시기를 기록하는 감사 추적을 자동으로 제공합니다.

선언적 자동화는 여러 시나리오를 처리하지만, 복잡한 요구 사항 또는 성능 제약으로 인해 Apex 프로그래밍 자동화를 수행해야 할 수도 있습니다. 효과적인 Apex 자동화는 유지 보수 및 거버넌스 문제에 대한 강력한 기능과 유연성의 균형을 유지합니다.

• 트리거 프레임워크는 데이터베이스 트리거 논리에 일관된 구조를 제공합니다. 올바르게 설계된 트리거 프레임워크는 우려 사항(논리가 실행되는 시기, 실행되는 논리, 종속성 순서), 코드 변경 없이 개별 처리기를 활성화/비활성화하고 컨텍스트 추적을 통해 반복 문제를 방지합니다. 트리거 프레임워크는 "단일 큰 트리거" 안티패턴을 방지함으로써 Apex 자동화를 유지할 수 있게 해줍니다.
• 배치 Apex은 대용량 데이터를 청크로 비동기식으로 처리하며, 총괄자 제한을 준수하면서 동기식 실행 시 시간이 초과되는 작업을 수행합니다. 배치 작업은 데이터 정리, 개체 경계를 넘는 대량 업데이트, 레코드당 여러 쿼리를 수행해야 하는 복잡한 계산, 데이터 마이그레이션 작업을 처리합니다. 이상성에 대한 배치 작업을 설계 - 동일한 작업을 두 번 실행하면 중복 작업 또는 손상 없이 동일한 결과를 얻을 수 있습니다.
• Queueable Apex는 명시적 작업 시퀀스를 통해 비동기 작업을 체인화합니다. Future 메서드가 fire-and-forget되는 경우 대기 가능 Apex 하나의 작업을 완료하면 다음 작업이 트리거되는 구조화된 시퀀스를 활성화합니다. 대기 가능한 작업은 API 콜아웃 후 데이터 처리, 다단계 데이터 변환, 기하율 백오프를 사용하는 재시도 논리를 비롯한 복잡한 오케스트레이션을 지원합니다.
• 예약된 Apex는 고정 간격으로 작업을 실행합니다. 예약된 작업은 정기 정리, 야간 데이터 동기화, 시간별 통합 설문, 하루의 끝 처리를 처리합니다. 트래픽이 적은 기간 동안 작업을 예약하고 모니터링을 구현하여 누락된 실행을 감지합니다. 예약된 간격이 실제로 비즈니스 요구를 충족하는지 또는 이벤트 중심 트리거가 더 빠르게 응답하는지 고려합니다.

운영 가시성을 위한 프로그램 자동화를 설계합니다. 시작/종료 시간, 처리된 레코드 개수, 발생한 오류, 성능 메트릭을 기록합니다. 배치 작업이 자동으로 실패하면 사용자가 며칠 후에 데이터 문제를 인지할 때까지 주의할 수 없는 경우가 많습니다. 사전 예방적 로깅 및 경고는 자동 실패를 진단 가능한 사고로 전환합니다.

플랫폼 이벤트는 프로듀서가 소비자를 알지 않고 이벤트를 게시하고 소비자가 프로듀서에 의존하지 않고 이벤트를 구독하는 이벤트 중심 아키텍처를 활성화합니다. 이벤트 중심 아키텍처는 구성 요소를 분리하고 비동기 처리를 활성화하며 다중 언어 통합 패턴을 지원합니다.

• 플랫폼 이벤트 게시: 중요한 비즈니스 이벤트에 대해 관심이 있는 가입자에게 알립니다. 주문 배치, 결제 처리, 처리 완료, SLA 위반, 오류 조건은 모두 게시할 수 있는 이벤트를 나타냅니다. 이벤트 페이로드에는 구독자가 추가 쿼리 없이 적절하게 반응할 수 있는 충분한 컨텍스트가 포함되어 있습니다. 트리거, 플로, Apex 또는 API 호출에서 이벤트를 게시하여 이벤트 소싱에 유연성을 제공합니다.
• 플랫폼 이벤트 구독: Apex 트리거, 플로 또는 외부 통합 플랫폼을 통해 게시된 이벤트에 반응합니다. 구독자는 이벤트를 비동기식으로 처리하므로 게시자가 구독자가 완료될 때까지 기다리지 않습니다. 이벤트 중심 처리는 대규모 동기 트랜잭션에서 제한을 사용하지 않고 별도의 실행 컨텍스트에서 작업을 배포하여 총괄자 제한을 준수합니다.
• 이벤트 재생: 구독자가 내역 이벤트를 처리할 수 있습니다. 플랫폼 이벤트 재생 ID를 사용하여 특정 지점에서 이벤트를 재생합니다. 외부 구독자는 자체 재생 ID 상태를 관리해야 합니다. 배달은 한 번 이상이므로 구독자 논리로 처리하는 중복 처리가 가능합니다. 구독자 복구 요구 사항을 기반으로 이벤트 보존을 구성합니다. 대용량 플랫폼 이벤트의 경우 72시간, 레거시 표준 이벤트의 경우 24시간은 빠른 복구에 충분하며, 장기간 보존은 재해 복구 시나리오를 지원합니다.

안정성을 위해 이벤트를 설계합니다. 이벤트 스키마는 프로듀서와 소비자 간의 계약이 됩니다. 스키마 변경 시 여러 팀 및 시스템 간에 조정이 필요합니다. 이벤트 확장 시 기존 필드를 수정하는 대신 새 필드를 추가합니다. 변경을 중단할 수 없게 되면 명시적으로 버전 이벤트가 발생합니다.

사고는 정상적인 작업을 복원하기 위해 응답이 필요한 비계획 중단 또는 서비스 저하입니다. 효과적인 사고 관리는 문제를 빠르게 감지하고 자격을 갖춘 응답자에게 라우팅하거나 효율적으로 해결하고 반복을 방지하기 위해 학습을 추출합니다.

• 검출 속도: 사고 충돌 기간을 결정합니다. 문제를 빠르게 감지할수록 응답이 시작되기 전에 손상이 적습니다. 감지 메커니즘에는 자동 모니터링 경고(관찰 가능성 시스템), 사용자 보고서(지원 티켓 및 직접 에스컬레이션), 외부 모니터링(네트워크 외부에서 합성 트랜잭션 및 가동 시간 서비스 확인)가 포함됩니다.

기술적 심각도 대신 사용자 영향에 따라 사고의 우선 순위를 지정합니다. 예를 들어 내부 배치 작업에 영향을 미치는 API 오류의 긴급성이 모든 사용자의 액세스를 차단하는 로그인 실패와 다릅니다.

사고 심각도는 응답 타이밍 및 에스컬레이션 경로를 안내합니다.

응답하는 사람, 에스컬레이션 방법, 유지할 커뮤니케이션 케이던스, 팀 간 조정 방법 등 명확한 사고 대응 절차를 수립합니다. 긴급한 상황이 발생하는 동안 런보 엔지니어가 따를 수 있는 절차를 실행북에 문서화합니다. 문서화되지 않은 부족 Knowledge 사람들이 전화를 걸고 수행할 단계를 판단하는 동안 응답 지연을 유발합니다.

• 전화 순환: 모든 사고에 대응하는 몇 명의 영웅을 불태우는 대신 팀 구성원 간에 운영 부담을 분배합니다. 온콜 순환은 적용 범위 요구 사항(항상 사용 가능한 사용자), 자산(모두가 부담을 공유함) 및 지속 가능성(강력한 사고 후 복구 시간이 필요함)에 균형을 맞춥니다.

명확한 처리 및 문서화된 책임을 사용하여 온콜 순환을 구조화합니다. 기본 온콜은 초기 응답을 처리하고 보조 온콜은 기본 지원이 필요한 경우 에스컬레이션을 제공하거나 기본 응답을 사용할 수 없는 경우 인계합니다. 온콜 교대 근무의 크기는 적절해야 합니다. 예를 들어, 1주부터 시작하고 2주를 초과하지 마십시오. 더 짧은 교대 근무는 지속적인 컨텍스트 전환을 유발하고, 더 긴 교대 근무는 번거로움 위험을 높입니다. 사전에 개인 의무를 계획할 수 있도록 순환 일정을 예약합니다.

• 에스컬레이션 경로: 추가 리소스를 사용하는 시기와 방법을 정의합니다. 명확한 에스컬레이션 기준을 통해 젊은이들이 처리할 수 있는 문제에 대한 고위 엔지니어의 시간을 낭비하는 조기 에스컬레이션과 늦은 에스컬레이션과 같은 두 가지 실패 모드를 방지합니다. 일반적으로 에스컬레이션 기준은 진행 상태가 없는 30분과 같은 시간 기반 트리거, 현재 호출되지 않은 전문 지식이 필요한 문제와 같은 복잡성 트리거, 항상 경영진에게 에스컬레이션되는 심각도 1 사고와 같은 심각도 트리거와 같은 세 가지 범주에 속합니다.

온콜 엔지니어에게 필요한 액세스 권한, 도구, 정보를 제공합니다. 프로덕션 액세스 권한이 없는 온콜 상태는 불만을 유발하고 사람들이 액세스를 기다리는 동안 사고 기간을 연장합니다. 온콜 툴킷에는 프로덕션 액세스 자격 증명, 런북 액세스, 모니터링 대시보드 링크, 에스컬레이션 연락처, 공급업체 지원 절차, 커뮤니케이션 템플릿이 포함됩니다.

통화상 대기 업무를 공평하게 보상합니다. 온콜 작업은 개인적인 시간을 방해하고 스트레스를 유발합니다. 보상 접근 방식에는 추가 임금, 대기 시간 또는 다른 책임을 줄이는 순환 크레딧이 포함됩니다. 공정한 보상을 받지 않으면 온콜 순환으로 인해 직장 생활의 균형을 존중하는 조직에 대한 품질 엔지니어의 낙관이 발생합니다.

• 죄 없는 사후: 정직한 토론을 방해하는 두려움을 야기하지 않고 사고에서 최대한의 학습을 추출합니다. 죄책감 없는 문화는 사람들이 복잡한 시스템에서 실수를 하는 것을 인정하며 과거 사고로 인해 개인을 처벌하는 대신 향후 사고를 방지하는 시스템 개선에 중점을 둡니다.

모든 심각도 1 및 심각도 2 사고와 새로운 패턴 또는 시스템 문제를 드러내는 사고에 대해 사후 테마를 수행합니다. 사후 시기는 매우 중요합니다. 너무 빨리 검토를 수행하면 정보가 불완전할 수 있으며 너무 늦게 검토를 수행하면 기억이 사라질 수 있습니다. 사고 해결 후 합리적인 기간(24시간~48시간) 이내에 사후 작업을 예약하여 세부 사항이 최신 상태로 유지되는 동안 데이터를 수집할 수 있습니다.

일관된 형식으로 문서 사후 항목 수집:

• 타임라인: 초기 감지에서 해결까지의 이벤트의 시간순 순서입니다. 타임스탬프, 수행된 작업, 관찰된 결과, 수행된 결정이 포함됩니다. 타임라인 재구축은 응답 효과를 표시하고 지연을 식별합니다.
• ** 근본 원인:** 사고가 발생할 수 있는 기본 시스템 약점입니다. 근접 원인(직접 트리거) 이상으로 시스템 원인(트리거의 결과를 만든 설계 또는 프로세스 공백)으로 이동합니다. "엔지니어 배포 나쁜 코드"는 근접적인 원인입니다. "배포 파이프라인에 이 오류 클래스를 포착하는 자동 테스트가 없음"은 시스템 원인입니다.
• ** 영향:** 사용자 영향 기간, 영향받은 사용자 수, 매출 영향, 데이터 무결성 문제, 평판 손상 수량화된 영향은 예방 작업의 우선 순위를 지정하는 방법을 안내합니다. $100K 영향이 있는 사고를 방지하려면 $1K 영향 사고를 방지하는 것보다 더 많은 투자가 필요합니다.
• 예방: 반복을 방지하는 특정 작업 항목입니다. 효과적인 예방 항목은 구체적이며 작업, 할당받은 사람, 예약 완료를 포함합니다. 예를 들어, CI 파이프라인에 통합 연기 테스트를 추가합니다. 소유자: Jane 및 완료 기준: 다음 스프린트. "테스트 개선"과 같은 모호한 예방 항목은 어떤 조치를 취해야 하는지 모르기 때문에 무시됩니다.
• 검출 개선: 유사한 사고를 더 빠르게 감지하는 방법 사용자 보고서를 통해 발견된 사고는 모니터링 공백을 나타냅니다. 개선 사항 항목에는 새로운 경고, 더 나은 계측 또는 중요 경로에 대한 합성 모니터링이 포함될 수 있습니다.

사후 결과를 광범위하게 공유합니다. 조직 학습에는 직속 팀 외부의 공유가 필요합니다. 사후 실패는 시스템 동작, 일반적인 실패 패턴, 효과적인 응답 절차에 대한 회사 전체 Knowledge 공유합니다. 공개 사후 기록(외부에 게시됨)은 투명성을 보여주고 고객이 서비스 품질 서약을 이해하는 데 도움이 됩니다.

운영 우수성은 지속적인 측정, 학습, 개선에 대한 투자가 필요한 연속적인 관행입니다. 일회성 설정으로 작업을 처리하는 팀은 시간이 지남에 따라 시스템이 복잡해지고 운영 Knowledge 분산될수록 저하됩니다. 지속적인 개선을 받아들이는 팀은 복합 운영 능력을 통해 지속적인 노력으로 가치를 높일 수 있습니다.

2025년 AI 지원 소프트웨어 개발 상태 보고서를 기반으로 하는 DevOps Research and Assessment(DORA) 프로그램의 DORA 메트릭은 연구에 의해 확인된 소프트웨어 전달 및 운영 성능 측정값을 제공합니다. 강력한 배달 성과를 보인 팀은 다음 5가지 핵심 메트릭 전반에서 측정적으로 더 나은 결과를 보입니다.

DORA는 해당 5개의 메트릭을 처리량 및 불안정성의 두 가지 요소로 구성합니다. 실패 배포 복구 시간은 변경 전달 시간, 배포 주기 및 실패 배포 복구 시간으로 구성되며, 얼마나 많은 변경 사항이 프로덕션으로 전달되는지 측정합니다. Instability는 나머지 변경 실패율 및 재작업률 메트릭을 가지고 있으며, 이러한 배포가 얼마나 잘 진행되는지 측정합니다.

• 배포 주기: 프로덕션으로 릴리스하는 빈도를 측정합니다. 가장 빠르게 이동하는 팀은 수요에 따라 배포됩니다(일일에 여러 번). 자주 배포하면 빠른 사용자 의견을 얻을 수 있으며, 작은 변경을 통해 배포 위험을 줄이고, 더 빠른 기능 전달과 관련이 있습니다. 배포 빈도가 낮은 것은 팀이 방지하는 배포 고통을 나타내며, 빈번한 배포로 인해 각 배포가 더 위험해집니다.
• 변경 전달 시간: 코드 커밋에서 프로덕션 배포까지의 시간을 측정합니다. 하위 날짜 리드 시간은 고성능 배달의 강력한 신호이며, 하위 시간 리드 시간은 뛰어난 배달 기능을 나타냅니다. 리드 타임이 짧으면 사용자 요구, 경쟁 위협 및 보안 취약성에 빠르게 대처할 수 있습니다. 리드 시간이 길면 과도한 프로세스 오버헤드, 자동화 부족 또는 조직의 기능 장애가 발생합니다.
• 변경 실패율: 해결이 필요한 생산 사고를 야기하는 배포 비율을 측정합니다. 가장 신뢰할 수 있는 팀은 모든 배포의 소수 부분인 이 비율을 지속적으로 낮춰야 합니다. 변경 실패율이 높으면 테스트가 부족하거나 배포 유효성 검사가 부족하거나 적절한 품질 검사가 없으면 변경 사항이 급해집니다.
• 실패 배포 복구 시간(FDRT): 즉시 개입해야 하는 실패 배포에서 얼마나 빨리 복구하는지 측정합니다. 1시간 미만의 복구는 강력한 배달 성숙도 신호입니다. 짧은 복구 시간은 성숙한 사고 대응, 효과적인 롤백 기능, 잘 실행된 실행북을 나타냅니다. 복구 시간이 길면 배포 확인이 부족하거나 자동 롤백이 부족하거나 프로덕션 사고의 소유권이 불확실합니다.
• 배포 재작업률: 생산 사고로 인해 예상치 못한 배포가 발생하는 빈도를 측정합니다. 재작업 비율이 낮으면 다운스트림 수정 작업을 생성하지 않는 안정적이고 테스트를 마친 릴리스가 나타납니다. 재작업 비율이 높으면 프로덕션 사고가 정기적으로 비상 배포를 유도하고, 사전 프로덕션 테스트, 릴리스 확인 또는 변경 관리 관행에서 차이를 신호화합니다.

지속적으로 DORA 메트릭을 측정하고 시간에 따른 추세를 추정합니다. 개선 내역은 절대값보다 중요합니다. 팀이 품질을 유지하면서 월간에서 주간으로 배포를 개선하는 것은 진행률을 보여줍니다. 전체 조직에 표시되는 운영 대시보드에서 메트릭을 추적하여 운영 성과 및 개선 목표 진행 상황에 대한 투명성을 확보합니다.

• 스프린트 이력: 운영 사고, 배포 문제, 프로세스 마찰, 팀 역동성을 비롯한 최근 작업에서 배운 내용을 추출합니다. 소급적 관찰은 정기적으로 수행해야 합니다(스프린트마다 또는 매달). 위기를 기다리는 대신 지속적인 반영을 위한 리듬을 만듭니다.

참여 및 실천 가능한 결과를 장려하는 구조화된 형식을 사용하여 소급적 관점을 실행합니다. 일반 형식은 다음과 같습니다.

• 시작/중지/계속 - 무엇을 시작, 중지, 계속해야 합니까?
• Mad/Sad/Glad - 최근 경험에 대한 감정적 반영
• 타임라인 - 스프린트 이벤트를 재구성하고 패턴을 식별합니다).

소유자 및 완료 일자를 사용하여 소급 인사이트를 구체적인 작업 항목으로 전환합니다. 긴 토론을 일으키지만, 작업을 하지 않는 후각은 시간 낭비를 유발하고 시니즘을 유발합니다. 효과적인 소급은 세션당 실천 가능한 개선 사항 2-3개를 생성합니다. 후속 작업을 담당하는 팀을 유지하는 소급 전반의 작업 항목 완료를 추적합니다. 단일 사람이 토론을 지배하지 않도록 중재자를 순환해야 합니다.

• 운영 검토: 분기별 또는 월별 비즈니스 검토를 통해 총 운영 상태를 평가합니다. 운영 검토는 추세 데이터를 검사하고, 목표와 비교하고, 개선 기회를 식별하고, 개선 투자를 할당합니다. 또한 해당 검토는 경영진을 참여시켜 기능 개발과 경쟁하는 운영 개선 작업을 위한 자원을 확보합니다.

검토에 운영 메트릭 포함:

• 가용성: 실제 및 목표 비교, 사용자 여정 및 전체
• 성능: 대기 시간 추세, 백분율 및 중요 플로별
• 사고: 심각도, 평균 감지 시간, 평균 해결 시간별 계산
• 배포 상태: 빈도, 성공률, 롤백 빈도
• 작동 부하: 온콜 페이지, 수동 중재, 작업 시간

검토는 운영을 위기 상황에서만 주의를 기울이는 보이지 않는 백그라운드 작업으로 취급하는 대신 운영 우수성에 대한 책임성을 창출합니다. 정기적인 운영 검토는 지속 가능한 운영을 위한 조직의 노력에 대한 신호입니다.

소급은 최근 작업의 진행 현황을 살펴보고 운영 검토 보고서에서 경영진에 대한 상태를 집계합니다. 엔지니어링 검토는 팀이 운영 신호를 배달 결정으로 전환하는 반복 케이던스입니다. 여기에서 시스템이 생성하는 대시보드, 사고 추세, 오류 예산을 팀이 서약한 릴리스 계획 및 백로그 우선 순위와 연결합니다. 이 검토를 실행하면 작업을 수행하는 사람이 운영 상태를 유지하므로 사후 고려 사항이 아닌 계획 내장 부분이 됩니다.

• 릴리즈 계획: 기능 범위, 순서 변경을 통해 폭발 반경을 제한하고 오류 예산이 충족되면 릴리스를 대기할 수 있는 최상의 입력으로 운영 준비를 처리합니다. 이렇게 하면 배포 규칙과 비즈니스 우선 순위가 기한의 압박을 받지 않고 의도적으로 조정됩니다.
• 백로그 정렬: 기능 작업과 동일한 백로그에 운영 작업(예: 사고 작업 항목, 예방 과업, 기술 부채, 모니터링 간격)을 배치하여 수용력에 경쟁합니다. 정기적 정렬은 소유자 및 우선 순위를 할당하여 사후 실사에서 확정된 작업으로의 루프를 닫습니다.

• 운영 준비 검토(ORR)는 새로운 기능 또는 시스템이 운영 요구 사항을 충족하는지 조정하기 전에 생산을 시작합니다. ORR은 수정이 실행 후 수정보다 저렴한 경우 개발 도중 운영 차이를 파악하여 운영 재해를 방지합니다.

운영에 영향을 미치는 새로운 솔루션, 주요 기능 또는 아키텍처 변경을 프로덕션 출시하기 전에 ORR을 수행합니다. ORR 타이밍은 중요합니다. 너무 빠르고 구현이 아직 완료되지 않으며, 너무 늦고 운영상의 우려는 배포 차단으로 인해 수정을 건너뛰어야 하는 것처럼 느껴집니다.

다음은 ORR을 수행하는 동안 유의해야 할 우려 사항 및 질문입니다.

• 모니터링 및 경고: 메트릭이 충분히 계측되어 있습니까? 실패 시나리오에 대한 경고가 있습니까? 대시보드가 상태를 표시하도록 구성되어 있습니까?
• 문서: 일반 작업에 대한 실행북이 있습니까? 응답자가 시스템을 이해할 수 있도록 아키텍처가 문서화되어 있습니까? 에스컬레이션 절차가 명확합니까?
• 배포 및 롤백: 배포를 신뢰할 수 있습니까? 롤백 절차가 있습니까? 스테이징에서 배포가 확인되었습니까?
• 성능 및 확장성: 실질적인 부하에서 성능 목표를 확인했습니까? 성장할 여유 공간이 있습니까? 총괄자 제한 위험이 있습니까?
• 보안 및 규정 준수: 보안 검토가 완료되었습니까? 감사 요구 사항을 충족합니까? 액세스 제어가 요구 사항과 일치합니까?
• 종속성: 외부 종속성이 식별되었습니까? 통합 파트너에게 SLA가 있습니까? 종속성 실패에 대한 대체 동작이 있습니까?

ORR 완료 시 게이트 프로덕션 시작 팀은 최선의 노력이 아닌 배포 요구 사항이 될 때 운영상의 우려 사항을 심각하게 고려합니다. ORR 게이트를 사용하면 운영 부채가 누적되어 향후 운영 우수성이 점점 더 어려워집니다.

학습 조직은 운영 환경을 체계적으로 수집하고 개선된 관행으로 전환합니다. 학습 문화는 두려움 없이 문제를 보고할 수 있도록 심리적 안전, 데이터가 패턴을 드러낼 수 있도록 측정, 경영진이 개선 시간을 할당할 수 있도록 노력에 따라 다릅니다.

• 심리적 안전: 처벌을 두려워하지 않고 문제, 실수, 거의 실패에 대한 정직한 논의를 가능하게 합니다. 심리적 안전이 부족한 팀은 재해가 발생할 때까지 문제를 숨기고 조기에 중재를 방지합니다. 자신의 실수에 대해 논의하여 죄책감 없는 사후 사건, 문제 발견 축하, 경영진 모델링 취약성을 통해 심리적 안전을 구축합니다.
• 측정: 작동 상태가 표시됩니다. 운영 메트릭, 사고 추세, DORA 지표, 사용자 만족도 점수는 실제 작업 성과와 원하는 성과를 보여줍니다. 측정을 통해 가장 큰 불만 사항이나 가장 최근 사고가 아닌 영향을 기반으로 개선 작업의 우선 순위를 목표적으로 지정할 수 있습니다.
• 개선 시간: 운영 우수성에는 투자가 필요하다는 점을 인정합니다. 기능에 100 %의 용량을 사용하는 팀은 운영을 개선할 시간이 없으므로 최종적으로 위기 대응을 강제해야 하는 기술 및 운영 부채가 발생합니다. 운영 개선, 기술 부채 절감, 툴링, 자동화 투자에 대한 엔지니어링 수용력을 의도적으로 예약합니다. 이 규칙은 장기적인 성능 저하를 방지하면서 지속적인 기능 속도를 제공합니다.

운영 환경을 연결하여 의사 결정을 설계하는 사용자 의견 루프를 만듭니다. 사고로 인해 아키텍처의 약점이 나타나면 유사한 사고를 방지하는 아키텍처 개선 사항의 우선 순위를 지정합니다. 모니터링 시 성능 저하가 표시되면 최적화 작업의 우선 순위를 지정합니다. 배포 실패로 인해 테스트 공백이 나타나면 테스트 적용 범위 개선의 우선 순위를 지정합니다. 사용자 의견 루프는 작업이 점진적으로 저하되는 대신 지속적으로 개선되는 가치 있는 주기를 만듭니다.

운영 우수성은 관찰 가능성을 위한 솔루션을 설계하고, 자동화된 파이프라인을 통해 배포하고, 사고에 효과적으로 대응하고, 운영 경험에서 지속적으로 학습해야 합니다. 이 체크리스트를 검토하여 운영 성숙도를 평가합니다.

관찰 및 모니터링

• 분산 추적을 위한 포괄적인 로깅 수집 상관 관계 ID가 포함된 솔루션
• 이벤트 모니터링 활성화 및 이벤트 로그 파일을 외부 플랫폼으로 내보내 네이티브 제한을 넘어 보존
• 조직 기준값에 맞게 조정된 임계값으로 구성된 Proactive Monitoring
• 각 릴리스 후에 설정 및 검토된 스케일 센터 기준선
• 보존을 위해 설정 감사 내역 내보내기 180일 이상
• 민감하고 규제된 데이터 필드에 대해 활성화된 필드 감사 내역 ]
• 데이터 감지 스캔은 규정 준수 분류 및 조치를 주도하는 결과를 통해 필드에서 중요한 데이터를 식별하고 분류합니다.
• 상태 확인 결과가 위험 우선 순위에 따라 수정된 보안 기준선에 대해 분기별 검토
• 중대 사건 마커 및 성공률 모니터링을 사용한 중요 사용자 프로세스
• 모든 외부 종속성에 대한 양방향 상태 추적 통합 모니터링
• 가용성, 대기 시간, 성공률, 처리량에 대해 정의된 서비스 수준 목표
• 경고 아키텍처에 심각도 수준, 실천 가능한 컨텍스트, 명확한 에스컬레이션 포함

DevOps Practices

• 소스에서 재현 가능한 빌드를 활성화하는 모든 메타데이터 버전 제어
• 스크래치 조직 또는 개발자 Sandbox에서 분리된 개발 지원
• 코드 변경과 같은 검토 프로세스에 따라 구성 변경 사항 수행
• 구성 드리프트 감지는 문서화된 수정 사항과 함께 분기별로 실행됩니다.
• Sandbox 전략에는 개발자, 통합, 스테이징, 교육 환경이 포함됩니다.
• Sandbox 새로 고침 및 데이터 로드 자동화
• CI 파이프라인은 자동 테스트를 통해 모든 커밋을 확인합니다.
• 보호된 기본 지점은 병합하기 전에 CI 성공이 필요합니다.
• 프로그레시브 유효성 검사를 통해 환경을 통해 CD 파이프라인 배포
• 프로덕션 배포 전에 배포 확인 실행
• 배포 모니터링 - 배포 도중 및 후 주요 메트릭 추적
• 배포 실행북 문서 절차, 확인, 롤백
• 테스트 피라미드에는 단위 테스트, 통합 테스트, 종단간 테스트가 포함됩니다.
• CI 파이프라인에서 자동화된 테스트 실행
• 코드 검토에는 명시적 검토 기준이 포함된 승인이 2개 필요합니다.
• 철저한 검토를 위해 소규모로 유지된 가져오기 요청(200~400줄)

자동화 및 효율성

• 해당하는 경우 사용되는 선언적 자동화(플로, 수식, 확인, 승인)
• 재사용 가능한 하위 플로를 사용하여 모듈 방식으로 설계된 플로
• 트리거 프레임워크는 Apex 자동화를 위한 일관된 구조를 제공합니다.
• 일괄 처리 작업은 idempotency 및 포괄적인 로깅을 구현합니다.
• 모니터링을 사용하여 트래픽이 적은 기간에 예약된 작업이 실행됩니다.
• 비동기식 처리를 위한 이벤트 기반 아키텍처를 활성화하는 플랫폼 이벤트
• 버전 관리 전략을 사용하여 안정성을 위해 설계된 이벤트 스키마
• 자동화 운영 가시성에는 로깅, 모니터링, 경고가 포함됩니다.

사고 관리

• 기본 사고 감지를 제공하는 자동 모니터링
• 명확한 응답 시간 요구 사항으로 정의된 사고 심각도 수준
• 런북에 문서화된 사고 대응 절차
• 온콜 순환은 팀 전체에 운영 부담을 공평하게 배포합니다.
• 시간 기반 및 복잡성 기반 트리거를 사용하여 에스컬레이션 경로 지우기
• 온콜 엔지니어에게 필요한 액세스, 도구, 정보가 있습니다.
• 공정하게 보상된 온콜 요금
• 모든 심각도 1 및 2 사고에 대해 실수 없는 사후 실사 수행
• 사후 문서 타임라인, 근본 원인, 영향, 감지 개선 및 특정 예방 작업
• 사후 연구 결과를 조직 학습을 위해 광범위하게 공유

계속적인 개선

• 지속적으로 추적되는 DORA 메트릭(배포 주기, 리드 시간, 변경 실패 비율, 복원 시간, 재작업 비율)
• 구조화된 형식 및 실행 가능한 결과를 사용하여 정기적으로 스프린트 소급이 발생합니다.
• 운영 검토에서 분기별 또는 월별로 집계 건강 평가
• 운영 준비 검토 게이트 프로덕션 새 기능 출시
• 문제 및 실수에 대한 정직한 토론을 지원하는 심리적 안전
• 운영 개선을 위해 의도적으로 예약된 엔지니어링 수용력
• 사용자 의견 루프가 운영 환경을 연결하여 개선 사항 설계
• 운영 팀뿐만 아니라 모든 사람의 책임으로 운영 우수성 확인

좋게 설계된 프레임워크에 대한 사용자 의견을 공유하십시오.