여기에 업데이트 일정에 대해 알아보십시오.

복원성 있는 솔루션은 오류가 발생한 경우에도 서비스 품질을 유지합니다. 성능이 저하되거나 서비스가 중단되면 솔루션이 빠르고 효과적으로 복구됩니다.

솔루션의 복원성은 다음의 두 가지 핵심 특성에 기반합니다.

• 경도: 문제가 발생하면 솔루션이 이를 견뎌내고 유지합니다.
• 연성: 문제를 해결하면 솔루션이 이상적인 상태 또는 모양으로 돌아갑니다.

복원성을 위한 솔루션을 설계하려면 견고함과 탄력을 모두 고려하여 계획된 변경 사항과 계획되지 않은 변경 사항에 맞춰 내구성과 신속한 복구를 보장해야 합니다.

기술 컨텍스트에서 시스템 또는 솔루션을 공유 목표를 수행하기 위해 조율하는 상호 종속적인 구성 요소의 모음으로 간주합니다. 모든 구성 요소는 실패할 수 있습니다. 코드 및 구성 결함에서 네트워크 및 하드웨어 문제에 이르기까지 해당 구성 요소 내의 문제로 인해 예기치 않은 원치 않는 동작이 발생할 수 있습니다. 하나 이상의 구성 요소가 실패할 경우 시스템이 복원적 동작을 보여주지만 전체 시스템이 계속 작동하거나 빠르게 안정된 상태로 돌아갑니다.

Salesforce 솔루션의 복원 능력을 향상하려면 세 가지 핵심 습관에 집중하는 것이 좋습니다.

• 어플리케이션 수명 주기 관리(ALM) - 팀이 소프트웨어 수명 주기 전반에 걸쳐 소프트웨어를 관리하는 방식
• 사고 대응—팀이 시스템의 가용성 또는 보안에 영향을 미치는 문제를 식별, 해결 및 방지하는 방법
• 계속 계획—계획되지 않은 이벤트로 인해 문제가 발생할 경우 팀이 직원과 시스템을 계속 작동하도록 계획하는 방법

응용 프로그램 수명 주기 관리(ALM)는 생성에서 사용 중지까지 수명 주기 전반에 걸쳐 소프트웨어를 종합적으로 관리하는 방법입니다. ALM은 시스템 복원의 핵심이며 응용 프로그램 수명 주기와 관련된 사람, 프로세스, 도구, 분야를 포괄합니다. 해당 분야에는 DevOps 및 전달 방법론, 관찰 가능성, 테스트 전략, 거버넌스, CI/CD가 포함됩니다.

비즈니스에서 효과적인 ALM을 사용하면 팀이 변경 사항에 신속하게 대응하고 응용 프로그램이 안정성이나 품질을 저하하지 않고 변화하는 비즈니스 요구 사항을 준수합니다.

반면, 정상적인 ALM이 없으면 팀은 응용 프로그램 수명 주기의 모든 단계에서 어려움을 겪습니다.

낮은 ALM의 증상은 다음과 같습니다.

• 느리고 오류가 발생하기 쉬운 개발 주기
• 집약적이고 어려운 배포
• 프로덕션 및 QA 후 환경에서 발견된 심각도가 높은 문제 또는 버그
• 환영하거나 일관되지 않게 동작하는 AI 에이전트
• 릴리스 안정화에 필요한 자주 롤백 또는 핫픽스 배포

ALM은 솔루션의 거의 모든 측면을 다루므로 솔루션에 대한 명확하고 효과적인 ALM 관행을 수립하는 것은 아키텍처 작업의 핵심 부분입니다.

세 가지 핵심 영역에 집중하여 더 나은 ALM 관행을 구축합니다.

• 릴리스 관리—변경을 다른 환경으로 계획, 순서, 제어 및 마이그레이션
• 환경 전략 — 개발 및 테스트 시 목표 환경에서 애플리케이션을 사용하고 관리하는 방법에 대한 전략
• 신호화 전략 — 저하가 발생하기 전에 시스템 내 장애를 감지하고 해결하는 데 사용되는 중요 신호 및 응용 기기 정의
• 테스트 전략 - ALM 프로세스 중 애플리케이션의 성공을 측정하기 위해 테스트를 계획하고 실행하는 방법을 안내하는 원칙과 기준

릴리스 관리에는 변경 사항을 계획, 순서, 제어, 하나 이상의 환경으로 마이그레이션하는 작업이 수반됩니다. 단일 릴리스는 팀이 동시에 대상 환경으로 이동하는 계획된 변경 사항의 그룹입니다.

시스템에 대한 변경 사항을 릴리스하면 위험이 발생합니다. 변경 전에 시스템이 안정적인 상태인 경우 새 상태로 전환되며, 이후 변경으로 인한 위험에 더욱 취약해집니다. 향후 변경 사항이 시스템에서 비제어적이고 불안정한 상태를 트리거할 경우 심각한 사고가 발생할 수 있습니다. 솔루션 아키텍처에서 탄력적인 릴리스를 위해 설계하는 것은 단순히 개별 변경 사항을 효과적으로 테스트하는 것 이상입니다. 또한 시스템 및 사용자에게 안전하게 변경 사항을 도입하는 방법을 계획해야 합니다.

팀이 수행하는 작업은 예측 가능하고 정확한 릴리스 정보에 따라 다릅니다. 변경 관리 및 활성화 프로세스에서 시스템으로 이동할 수 있는 변경 사항을 명확하게 확인하십시오. 릴리스 관리 및 활성화 프로세스에서 변경 사항이 시스템에 릴리스되는 방법 및 빈도를 지정합니다.

비즈니스 이해당사자는 특히 릴리스 정보가 요청한 기능 또는 버그 수정과 관련이 있는 경우 릴리스 정보를 신경쓰기도 합니다. 솔루션에 대한 Trust 구축하고 이해당사자에게 가치를 표시하려면 일관되고 명확한 릴리스 일정을 설정하고 안정적인 릴리스 아티팩트를 배포합니다.

Salesforce에 대한 효과적인 릴리스 관리 설정:

• 건축 및 개발 거버넌스와 긴밀하게 일치합니다. 모든 관련 거버넌스 포럼 및 제어에 부합하도록 미리 릴리스를 계획해야 합니다. 개발을 시작하기 전에 우선 순위가 지정된 Agentforce 사용 사례를 모두 검토하고 AI 위원회에 승인하십시오. 법적 및 윤리적 사용 팀에서 높은 위험이 있는 Agentforce 사용 사례를 검토합니다.배포 체크리스트 및 문서를 사용하여 Agentforce 에이전트 API 이름과 같은 배포 아티팩트를 관리 활동에 대해 추적합니다.
• 조직 기반 개발 또는 릴리스 프로세스를 사용하지 마십시오. 이 패러다임은 개발 및 릴리스를 위한 오래된 제한된 기술을 반영합니다. 이제 팀은 Salesforce CLI 사용하여 소스 중심 개발 및 릴리스 기능을 채택할 수 있습니다.
• 가능한 가장 안정적인 릴리스 메커니즘을 선택하십시오. 이 접근 방식은 다음 두 가지를 수행합니다. 먼저, 릴리스 기간 및 서비스 중단 기간을 최소화합니다. 두 번째로, 매우 제어적이고 예측 가능한 릴리스 동작을 허용합니다. 릴리스 메커니즘이 안정적일수록 릴리스에서 핫픽스 또는 롤백이 필요한 변경 사항을 도입할 가능성이 줄어듭니다. 예상치 못한 문제가 발생할 경우 안정적인 릴리스 메커니즘은 지원 담당자 또는 시스템 관리자가 롤백을 수행할 수 있는 간단한 방법도 제공합니다.

팀에 가장 적합한 릴리스 메커니즘은 팀에 필요한 기술이 있는 가장 안정적인 옵션입니다. 다음은 안정성 순서대로 나열된 권장 릴리스 메커니즘입니다. 모든 항목이 서로 호환되므로 회사에 가장 적합한 경우 여러 항목을 동시에 사용하십시오.

• 잠금 해제 패키지—잠금 해제 패키지는 가장 안정적인 릴리즈 아티팩트입니다. 패키지를 설치하여 변경 사항을 배포하는 것이 가장 빠르고 예측 가능한 방법입니다. 패키지는 버전 관리를 사용하므로 강력한 변경 관리와 시스템 관리자에게 친숙한 세분화된 롤백을 수행할 수 있습니다. 패키지에는 강력한 메타데이터 관리가 필요하므로 조기에 잘못 관리되는 종속성을 식별할 수 있습니다. 또한 감사 가능한 개발 파이프라인 및 아티팩트를 만듭니다. 패키지 가능성을 참조하십시오.
• DevOps Center—DevOps Center를 사용하면 소스 제어를 사용하고, 변경 사항에 대한 공동 작업을 수행하고, 공통 릴리스 경로를 정의할 수 있는 낮은 코드 또는 프로 코드 기술을 갖춘 전달 팀이 가능합니다. DevOps Center 소스 제어와 통합되며 변경 사항 및 배포를 포인트 앤 클릭으로 제어할 수 있습니다.
• 소스 중심 개발 및 메타데이터 배포(Salesforce CLI 사용) - 패키지를 사용할 수 없는 경우 Salesforce CLI를 사용하여 소스 중심 개발 및 메타데이터 배포를 수행합니다. 권장되는 소스 형식과 다른 구조를 따르는 오래된 package.xml 형식을 사용하여 메타데이터를 배포하지 마십시오. 소스 형식은 Sandbox에서 패키지 개발, 스크래치 조직 워크플로, 보다 세분화된 변경 추적을 지원하기 위해 진화되었습니다. 형식은 더욱 쉽게 읽을 수 있으며 복잡한 메타데이터 유형 및 종속성을 더 잘 분리할 수 있으며 배포 매니페스트를 훨씬 더 세밀하게 제어할 수 있습니다.
• 릴리즈 이름을 지정하십시오. 릴리스에 명확한 식별자를 제공하여 팀과 이해당사자가 조율을 유지할 수 있도록 지원합니다. Salesforce에서는 각 주요 릴리스의 이름이 "Spring", "Summer" 또는 "Winter"로 시작하고 그 뒤에 릴리스 연도(예: "Summer '25")가 표시됩니다. 아직 회사에서 릴리스를 정의하고 구성하기 위한 명명 규칙이 없는 경우 명명 규칙을 설정하고 사용합니다. 명확한 릴리스 이름을 사용하면 팀 시스템 전반에서 계획, 개발, 배달의 모든 단계에서 체계적으로 정리할 수 있습니다. 로드맵에서 릴리스 이름을 사용하여 이해당사자에게 예정된 변경 사항 및 시기를 명확하게 전달합니다. 개발 아티팩트를 쉽게 추적하고 감사할 수 있도록 문서, 변경 로그, 작업 설명, 코드 댓글 및 소스 제어 분기에서 릴리스 이름을 사용합니다.
• 릴리스 매니페스트 내에서 종속성을 제대로 관리하십시오. Salesforce 메타데이터에는 내장 종속성이 있습니다. Salesforce 배포가 실패하는 일반적인 이유는 종속성이 제대로 관리되지 않기 때문입니다. 앞서 설명한 것처럼 안정적인 릴리스 메커니즘을 선택하면 개발 주기 초기에 잘못 관리되는 종속성을 노출하는 데 도움이 됩니다. 잠금 해제 패키지가 가장 안정적인 릴리스 차량인 이유 중 하나는 패키지 개발 및 생성에 필요한 강력한 메타데이터 관리입니다. 사용자 또는 릴리스 관리 팀에서 Salesforce 메타데이터 유형 간의 내장 종속성을 이해하지 못할 경우 배포 및 릴리스 매니페스트에서 문제 조합을 사전에 파악할 수 없습니다. 부양 관리를 참조하십시오.

ALM의 패턴과 안티 패턴은 Salesforce 조직의 올바른 릴리스 관리와 나쁜 릴리스 관리를 보여줍니다. 패턴을 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다.

릴리스 관리용 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

Salesforce는 애플리케이션 개발 및 테스트 주기 동안 사용할 수 있는 다양한 환경을 제공합니다. Salesforce의 효과적인 환경 전략을 수행하려면 환경을 사용하는 방법과 효과적인 관리 방식을 이해해야 합니다. ALM에서 개발 또는 테스트 환경의 유용성은 충성도와 프로덕션과의 분리에 따라 다릅니다.

좋은 환경 전략은 몇 가지 이점을 제공합니다.

• 프로덕션에 대한 충성도 향상
• 더 빠른 환경 설정 및 테어다운
• 개발 및 테스트에 대한 민첩성 향상
• 파이프라인 전반의 보안 향상
• 배달 단계 전반에서 소음 및 충돌 감소
• 행복한 개발 팀

팀은 이러한 혜택을 실현하기 위해 어려움을 겪는 경우가 많습니다. 개발 환경 및 전략을 최대한 활용하기 위한 문제는 여러 소스에서 발생할 수 있습니다. 한 가지 가능한 소스는 팀이 따르는 개발 모델 유형입니다.

오래된 조직 기반 개발 접근 방식에서는 각 환경이 여러 기능을 제공해야 했습니다. 팀이 다양한 작업을 수행하는 곳 외에도 릴리스 아티팩트(릴리스에서 배포하려는 메타데이터)의 소스여야 했습니다. 환경을 쉽게 설정하거나 해제할 수 없었기 때문에 팀 간의 메타데이터 충돌이 지나치게 많았으며 전체적으로 ALM에 의미 있는 속도 또는 유연성을 제공하지 않습니다.

소스 기반 개발 모델을 사용하면 릴리스 및 릴리스 아티팩트에 대한 환경 관계가 근본적으로 변경됩니다. 이 모델에서 소스 제어는 릴리스할 메타데이터의 소스입니다. 환경은 팀이 작업을 수행하는 장소입니다.

그러나 소스 기반 개발 모델을 따르는 것은 좋은 환경 전략을 보장하는 것뿐만이 아닙니다. 소스 제어를 사용하더라도 팀은 외부 시스템과의 통합을 테스트하기 위해 조건을 설정하는 데 어려움을 겪을 수 있습니다. 관리 패키지 또는 데이터에 의존하는 사용자 정의 등 소스 제어에 속하지 않는 메타데이터에 의존하는 구성. 특정 상황에서 소스 기반 모델의 챌린지는 조직 기반 모델의 일반적인 챌린지와 유사합니다.

효과적인 환경 전략 개발:

• 소스 중심 개발 및 릴리즈 모델 채택 조직 기반 개발 모델 사용 중지 릴리스 관리를 참조하십시오.) 건강한 환경 전략 및 더 건강한 릴리스를 만들려면 배포하는 환경의 문제를 해제해야 합니다.
• 각 환경이 지원하는 작업 유형을 ** 이해합니다**. Salesforce에서 지원하는 환경 유형에는 기능 및 제한이 다릅니다. 환경 전략을 설계할 때 환경에서 수행할 수 있는 작업과 수행할 수 없는 작업을 고려하십시오. 팀이 필요한 기능이 있는 환경에서 작업을 수행해야 합니다. 지침은 Salesforce 개발 환경 및 해당 기능에 대한 이 개요를 참조하십시오.

이 표를 참조하여 몇 가지 일반적인 개발 과업에 사용할 기능 및 환경을 알아보십시오.

또한 Einstein 데이터 라이브러리, Knowledge 기사 및 비정형 데이터와 같은 기능을 사용하는 Agentforce 에이전트의 경우 Data 360 Sandbox가 없으면 포괄적인 테스트가 제한됩니다. 정확한 테스트 조건을 보장하려면 Data 360 Sandbox도 필요합니다.

• 릴리즈 아티팩트로부터 환경 분리. 조직 기반 개발을 사용하지 마십시오. 환경을 고정된 시간 동안 작업이 수행되는 장소로 취급합니다. 환경의 메타데이터 상태는 릴리스 아티팩트와 구분된 상태로 간주합니다. 환경에서 코드 또는 구성의 일부가 "해결"될 경우 소스 제어에 적용되어 릴리스 아티팩트가 되어야 합니다.

  • 환경은 간단합니다. 가능한 한 빨리 프로세스를 만들고 폐기할 수 있도록 프로세스를 구축합니다.
  • 아티팩트는 지속됩니다. 소스 제어에 속합니다.

• 실패 경로에서 환경 분리 특정 환경에 변경 사항을 배포해야 하는 필수 릴리스 경로가 일반적으로 표시됩니다. 이 접근 방식은 응용 프로그램 성숙도 또는 릴리스 안정성을 확인하기 위한 프록시를 설정하기 위해 구현되는 경우가 많습니다. 팀은 이를 사용하여 복잡한 테스트 인프라를 구성해야 하는 환경의 수를 최소화할 수도 있습니다. 소스 기반 패러다임에서 변경 사항을 확인하고 테스트할 수 있는 방법과 위치에 대한 유연성을 높일 수 있습니다.

  • 릴리스 단계는 환경이 아닌 릴리스 아티팩트에 적용됩니다. 특정 릴리스 스테이지에서 모든 변경 사항을 "모음"하기 위해서만 환경을 만들지 마십시오. 이는 소스 제어(특히 분기)의 목적입니다. 소스 제어에서 분기 전략을 사용하여 어떤 환경에 배포할 변경 사항을 구성합니다. 수행해야 하는 작업에 따라 릴리스의 모든 메타데이터를 환경에 배포해야 할 수 있습니다. 분기를 사용하면 이를 수행할 수 있습니다. 몇 가지 예외를 제외하고 모든 개발 환경은 관련 작업이 완료되면 즉시 새로 고치거나 폐기해야 합니다. 특정 환경 내에서 발생하고 유지할 메타데이터에 대한 변경 사항을 소스 제어에 동기화해야 합니다.
  • 환경은 프로덕션에 대한 충성도만큼 유용합니다. 환경을 최대한 빨리 끊거나 새로 고칠 수 있도록 환경 설정 워크플로 또는 자동화를 최적화합니다. 더 빠르고 빈번한 환경 새로 고침을 수행하지 못하도록 차단하는 구성을 ALM 프로세스의 전반적인 복원에 대한 심각한 위험으로 간주하십시오. 관련 수정 작업이 있는 경우 계획에 추가하고 우선 순위를 지정합니다. 시스템에 더 느슨하게 연결된 모듈형 유닛을 도입하는 방법을 알아보십시오. 이를 통해 팀이 스크래치 조직에서 더 많은 유형의 개발을 수행할 수 있으며, 다른 작업을 위해 Sandbox 할당을 확보할 수 있습니다. 라이센스를 구매하지 않았거나 활성화하지 않았으므로 스크래치 조직에서 프로덕션에 없는 기능을 테스트하기 위해 제공하는 기능을 잊지 마십시오.
  • 비즈니스 사용자 또는 최종 사용자가 액세스할 수 있는 환경에서는 해당 사용자가 자신에게 중요한 사항에 집중할 수 있도록 합니다. 다양한 최종 사용자 그룹 또는 비즈니스 이해당사자가 ALM 관련 작업을 수행하도록 시도하는 차별화되지 않은 일반 환경이 없습니다. 특정 작업을 수행할 특정 이해당사자를 특정 환경에 초대하고 활성화합니다. 부분 복사 Sandbox에서 지원하는 것보다 더 많은 데이터가 포함된 환경에 최종 사용자 또는 비즈니스 이해당사자를 배치하는 프로세스를 주의 깊게 평가합니다. 수행할 작업에 데이터 용량이 필요한지 확인합니다. 사용자 수용 테스트 및 조기 단계 개발 주기를 계획하여 가능한 한 긴밀하게 함께 수행합니다. 모든 테스트 단계를 최적화하여 개발 팀 및 최종 사용자에 대해 빠르고 빠른 사용자 의견 및 반복 주기를 활성화합니다. 테스트 전략을 참조하십시오.

• 다른 유형의 변경 사항에 대해 다른 릴리스 경로를 구축합니다. 모든 변경 사항이 동일한 순서로 동일한 유형의 ALM 작업을 완료해야 하는 것은 아닙니다. 최종 사용자가 시스템의 백엔드 구성 요소에 대한 사소한 변경 사항에 대한 승인 테스트를 수행하도록 할 경우 시간이 적절하지 않을 수 있습니다. 사용자 수용 및 규모 테스트는 모바일 응용 프로그램 개발 초기 단계에서 매우 유용합니다. 높은 위험, 보통 위험, 낮은 위험 등 다양한 범주의 변경 사항에 대한 릴리스 경로를 식별합니다.

  • 고위험: 변경 사항은 고객, 파트너 또는 모든 내부 사용자에게 영향을 미칩니다. 변경 사항은 보안 또는 통합에 영향을 미칩니다. 변경 사항이 복잡한 새 기능을 추가합니다.
  • 중간 위험: 변경 사항은 내부 사용자의 정의된 임계값 이상에 영향을 미칩니다. 변경 사항은 데이터 모델, 데이터 작업을 수행하는 자동화 또는 통합에 영향을 미칩니다.
  • 저위험: 내부 사용자의 정의된 임계값보다 적은 직접적인 영향을 미칩니다. 보안, 데이터 모델 또는 데이터 작업 또는 통합과 관련된 자동화에 대한 변경 사항은 포함되지 않습니다.

• 과중한 환경이 존재하도록 허용하지 마십시오. 작업의 우선 순위 지정, 범위 지정, 순서 지정에 대한 규칙이 부족하면 불가피하게 과부하된 개발 환경으로 인해 작업량이 지나치게 많고 지나치게 많거나 지나치게 다양합니다. 과부족한 환경은 개발 팀 간에 높은 수준의 스트레스, 모호성, 충돌을 유발합니다. 또한 개발 파이프라인 내에서 소음을 유발하고 품질 관리 노력을 방해합니다. 부정적인 영향 외에도 밀집된 개발 환경은 환경 유지 관리 및 보안에 심각한 위협입니다. ALM 프로세스에서 잠재적인 문제의 증상으로 과부하를 고려하십시오. 근본 원인 문제를 조사하고 해결합니다. 아직도 과도한 인구가 많으면 추가 샌드박스를 구입할 수 있습니다.

ALM의 패턴 및 비패턴 목록은 Salesforce 조직에서 적절한 환경 관리와 부적절한 환경 관리를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다.

환경 관리를 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

신호 전략은 시스템 전체 저하로 계단화되기 전에 오류를 감지, 진단, 수정하는 데 필요한 중요 신호 및 응용 프로그램 도구를 정의합니다. 효과적인 계측은 실패의 수동적인 피해자에서 문제를 감지하고, 행동을 조정하고, 필요한 경우 유익한 저하를 조율할 수 있는 활성 참가자로 응용 프로그램을 변환합니다.

응용 프로그램이 포괄적인 계측을 구현하면 스트레스를 겪고 자가 조절하고 운영자에게 건강 상태를 알리고 조율된 복구 작업에 참여할 수 있습니다. 이러한 기능을 사용하면 개별 구성 요소가 어려움을 겪어도 시스템에서 서비스 품질을 유지할 수 있습니다. 반면 적절한 도구가 없으면 응용 프로그램이 재해적인 증상이 나타날 때까지 자동으로 실패하는 블랙박스가 됩니다. 팀은 사용자가 보고한 후에만 문제에 대응하며 문제 해결은 관찰이 아닌 고고학의 연습이 됩니다.

• 응용 프로그램 내 장애 감지 응용 프로그램이 직접 도구를 사용하여 부하가 많은 상태에서 발생하는 일반적인 실패 패턴을 감지하고 대응해야 합니다. 대기열 채도를 고려하십시오. 메시지 대기열이 처리할 수 있는 것보다 더 빠르게 채워지면 계단식 메모리 소모 또는 시간 초과가 발생할 때까지 비관리 응용 프로그램이 작업을 계속 수락합니다. 적절하게 계측된 응용 프로그램은 대기열 깊이, 거부율, 처리 대기 시간을 모니터링하여 임계값을 초과할 경우 방어적 응답을 트리거합니다.

• 어플리케이션 외부의 신호를 효과적으로 처리: 운영 체제의 신호 처리는 또 다른 중요한 계측 지점을 나타냅니다. 응용 프로그램은 종료 신호(SIGTERM, SIGINT)에 대한 처리기를 등록하여 완벽한 종료를 활성화해야 합니다. 종료 시 적절하게 계측된 응용 프로그램은 새 작업을 수락하지 않으며, 비행 요청이 완료되도록 허용하고, 버퍼를 플러시하고, 연결을 정리하며, 서비스 검색에서 등록을 취소합니다. 이 오케스트레이션된 종료는 데이터 손실을 방지하고 로드 밸런서가 중단 없이 트래픽을 리디렉션할 수 있도록 합니다.

• 복잡한 장애 시나리오에 대한 도구: 이러한 기본 패턴 외에도 응용 프로그램이 더욱 세분화된 오류 모드를 도구화해야 합니다. 일부 관찰자에게는 구성 요소가 정상적으로 표시되고 다른 관찰자에게는 실패하는 회색 오류를 식별하려면 내부 및 외부 신호를 모두 연관시켜야 합니다. 응용 프로그램이 데이터베이스 연결 풀을 통해 성공적인 상태 확인을 보고하는 동시에 저하가 발생하는 트랜잭션 완료율을 추적할 수 있습니다. 효과적인 계측 전략은 여러 관찰 지점을 계층화합니다.

  • 비즈니스 메트릭은 주문 완료율 또는 검색 결과 품질과 같은 응용 프로그램별 성공 지표를 추적합니다.
  • 시스템 메트릭은 자원 활용도, 지연 분포, 오류 비율을 모니터링합니다.
  • 합성 탐지기는 사용자가 발생하기 전에 중요한 경로를 지속적으로 실행하여 저하를 감지합니다.
  • 분산 추적은 서비스 범위를 넘어 요청 수준의 가시성을 제공합니다.

해당 신호는 자동화된 시스템과 사용자가 모두 응용 프로그램 상태를 평가할 수 있는 표준화된 인터페이스를 통해 노출됩니다. 이 장비 자체는 응용 프로그램의 복원 전략의 일부가 되며, 오류 비율을 기준으로 회로 차단기, 대기열 깊이에 대응하는 자동 스케일러, 사고 시 운영자가 정보에 근거한 결정을 내릴 수 있게 해줍니다.

ALM의 패턴과 안티 패턴은 Salesforce 조직에서 올바르고 나쁜 신호 전략을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다.

신호 전략을 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

테스트 전략은 ALM 프로세스 중 응용 프로그램의 성공 및 실패를 측정하는 테스트를 계획하고 실행하는 방법에 대한 안내 원칙 및 표준 집합입니다. 테스트 전략은 테스트에 관여하는 모든 이해당사자에게 주어진 테스트의 우선 순위, 목적 및 범위에 대한 정보를 제공하고 조율합니다. 프로젝트 팀이 효과적이고 신중한 테스트 계획을 수립할 수도 있습니다.

일반적으로 개발자 또는 품질 보증 및 테스트 전문가가 특정 테스트 만들기 및 실행에 참여합니다. 테스트 전략을 사용하면 해당 개인이 해당 프로젝트에 대해 수행해야 하는 테스트 유형 및 실행 순서를 파악할 수 있습니다. 테스트 전략을 사용하면 팀이 올바르게 구성된 테스트, 테스트 계획, 아티팩트(예: 테스트 데이터 집합, 장치, 트래픽 또는 네트워크 시뮬레이터)를 구축하는 데 필요한 내용을 확보할 수 있습니다.

효과적인 테스트 전략은 다양한 조합과 조건에서 단위 테스트, UI 테스트, 회귀 테스트를 비롯한 다양한 테스트 유형을 실행하는 방법, 시기, 위치, 이유에 대해 명확하게 파악하여 시스템의 동작과 비행 중 변경 사항을 파악합니다. 효과적인 테스트 전략은 단일 유형의 테스트를 통해 측정하기 어려울 수 있는 확장성, 신뢰성 및 유용성과 같은 기능이 아닌 요구 사항을 얼마나 잘 준수하는지 보여주는 테스트를 생성합니다.

Salesforce에 대한 효과적인 테스트 전략 만들기:

• 회복적으로, 자주, 최대한 자동화된 방법을 통해 테스트합니다. 팀이 다양한 작업 부하에 대해 다양한 테스트 유형을 실행할 수 있는 테스트 자동화를 설계 및 구현합니다. 소스 제어에 변경 사항이 적용되면 다양한 테스트 실행을 오케스트레이션하여 자동으로 수행합니다. 이 접근 방식을 사용하면 팀이 조기에 회귀를 사전에 식별하고 해결할 수 있습니다. 가능한 경우 이 작업에 연속 통합/연속 전달(CI/CD)을 사용하십시오. 그렇지 않은 경우 팀이 셀프 서비스 방식으로 테스트 순서를 조기에 자주 실행할 수 있도록 명확한 테스트 계획을 수립합니다. Agentforce 에이전트 테스트의 경우 다양한 입력과 함께 AI 에이전트의 엄격한 배치 테스트를 테스트 센터에 의존하여 다양한 시나리오에서 올바르게 작동하는지 확인하십시오.
• 모든 변화가 모든 종류의 테스트를 필요로 하는 것은 아닙니다. 효과적인 릴리스 파이프라인이 고위험, 중간, 낮은 위험 응용 프로그램에 대한 경로를 수용하는 것처럼 효과적인 테스트 전략도 수용합니다. 다양한 유형의 위험, 사용 사례 또는 복잡성이 있는 응용 프로그램에 적절한 테스트 규칙을 선택하고 따르는 방법을 팀에 명확하게 설명합니다. 환경 전략을 참조하십시오.
• 다양한 환경 유형에서 수행할 수 있는 테스트를 정의합니다. 프로덕션 충성도는 정확한 테스트의 핵심 구성 요소이지만, 다양한 유형의 테스트에 대해 서로 다른 의미를 가집니다. 예를 들어 회귀 테스트를 수행하려면 메타데이터 및 일부 데이터 측면에서 프로덕션에 대한 충성도가 필요합니다. 특정 테스트 집합에 필요한 프로덕션 충성도 유형을 정의하고 다양한 테스트에 적합한 조건을 지원할 수 있는 환경 유형을 명확하게 분류해야 합니다. 각 환경 유형에 맞는 작업 유형의 개요는 환경 전략을 참조하십시오.
• 내구성, 스트레스, 성능 및 규모 테스트를 사용하여 애플리케이션 성숙도를 지속적으로 측정합니다. 해당 테스트는 응용 프로그램의 릴리스 준비 상태를 프로덕션 수준 요구 사항에 비례하여 보여줍니다. 주요 새로운 기능의 경우 응용 프로그램 개발 주기에서 여러 간격으로 해당 테스트를 실행합니다. 이러한 테스트를 진행 중인 과업의 일부가 아닌 단일 개발 단계 또는 스테이지의 일부로만 고려하는 것은 비 패턴입니다. 팀이 빠르고 자주 앱 성능에 대한 사용자 의견을 얻는 것이 가장 유용합니다. 그러면 프로덕션 수준의 준비 상태에서 앱이 얼마나 근접했는지 더 잘 이해할 수 있습니다. 변경 사항이 프로덕션으로 전달되기 전에 문제를 더 잘 식별하고 해결할 수 있는 능력은 더 정교한 테스트를 자주 실행하는 것의 복잡성에 가치가 있습니다.
  • 어떤 테스트가 중요한지 알아요 규모 또는 성능 테스트를 수행할 수 있는 시간은 고정되어 있으므로 시스템의 모든 패싯을 테스트하는 것이 비실용적일 수 있습니다. 모든 기능이 동일하게 사용되지는 않으며 모든 규모 지체 지점이 비즈니스에 동일하게 영향을 미치는 것은 아닙니다. 규모 테스트가 시스템에서 가장 많이 사용되고 가치가 높은 부분에 초점을 맞춥니다. 조직의 규모와 성능을 확인하고 개선하기 위해 가장 중요한 기회를 정의하고 이해합니다.
  • "좋아"가 어떻게 보이는지 알아요. 규모 및 성능 테스트에 대한 성공 기준을 정의하는 것이 중요합니다. 사용자 및 개발 팀에서 성공 기준을 테스트 벤치마크로 사용해야 합니다. 또한 개발 팀이 구축하는 기능 요구 사항을 알려야 합니다. 이러한 기준에는 일반적으로 동시 응답 시간이 합의된 값보다 적은 특정 수의 동시 사용자 지원 및 서비스 수준 목표(SLO)가 포함됩니다. 주요 목표 기준을 정의한 다음, 기준이 충족되는지 확인하는 규모 및 성능 테스트를 설계합니다.
  • 적절한 환경이 있는지 확인하십시오. 규모 및 성능 테스트를 수행하려면 프로덕션에 대한 특별한 충성도가 필요합니다. 비프로덕션 환경의 데이터 집합, 요청 인구 통계, 요청 비율 및 작업 부하 특성은 프로덕션에서 볼 수 있는 내용과 최대한 일치해야 합니다. 규모 테스트의 경우 전체 Sandbox 사용해야 합니다. 조직에 규모 테스트를 위한 전체 Sandbox 없는 경우 적절한 규모 테스트를 실행할 수 없습니다.
• 테스트 워크로드가 기능이 아닌 요구 사항을 측정하는 데 도움이 되는지 확인하십시오. 다음 사항을 고려하십시오.
  • 테스트 데이터 - 모든 종류의 테스트는 생산에서 격리된 데이터에 대해 수행해야 합니다. Apex 단위 테스트에서 코드가 환경 데이터와 분리된 자체 테스트 데이터를 생성하도록 데이터 공장 패턴을 구현합니다. 또한 다양한 형식으로 테스트 데이터 집합을 만들고 유지하여 데이터 로드 동작을 테스트하고 UI 기반 테스트를 위한 데이터를 개발 환경에 채우거나 통합 테스트를 지원할 수 있습니다. 외부화된 데이터 집합으로 유지되거나 데이터 공장 코드로 요청에 따라 생성되는 모든 테스트 데이터는 민감한 식별 데이터를 제거해야 합니다. 음수 및 경계 단위 테스트 동작을 지원하기 위해 손상, 불완전, 잘못된 데이터를 포함해야 합니다.
  • 모형 서비스 - 통합 테스트를 위해 모형 서비스와 모형 서비스를 사용하여 API 응답을 시뮬레이션할 수 있습니다. Apex는 Apex 테스트에 사용할 수 있는 모의 프레임워크를 만들 수 있는 Stub API를 지원합니다. Apex 테스트에서 사용할 수 있는 모의 프레임워크를 만드는 모의 Mocks 및 stubs는 복잡한 데이터 공장 또는 외부 테스트 데이터 집합에 대한 의존도가 줄어들면서 시스템의 데이터 처리 동작을 확인하는 데 도움이 됩니다. 프로덕션과 유사한 트래픽 또는 데이터 용량이 관련이 없는 테스트에서 사용하는 것이 더 적합한 경우가 있습니다.
  • 장치 및 보조 기술 - 관련하고 접근 가능한 애플리케이션을 구축하는 데 중요한 부분은 다양한 장치와 다양한 유형의 보조 기술을 통해 사용자의 기대치를 충족하는 것입니다. 유용한 유용성 테스트를 효과적으로 수행하려면 더 많은 투자와 다양한 종류의 전문 지식이 필요할 수 있지만, 릴리스 시 사용자 대면 응용 프로그램이 얼마나 잘 설계되었는지 파악하는 데 필수적인 부분입니다.
  • 시뮬레이터 - 사용자 요청, API 트래픽 또는 네트워크 속도 변동을 프로덕션 방식으로 복제해야 하는 경우 이러한 조건을 시뮬레이션하는 도구가 필요할 수 있습니다. 모든 테스트에서 이 수준의 투자가 필요하지는 않습니다. 이러한 도구는 확장성 및 성능 테스트에 가장 유용합니다.
  • AI 및 에이전트 테스트 - 테스트의 주된 목표는 인공지능 환각을 줄이는 것입니다. 이는 설득력 있고 잘못된 반응입니다. AI 사용 사례가 테스트되어 고객의 불완전한 이해, 누락된 데이터, 불완전한 메타데이터가 있는 필드, 오래된 데이터로 인해 발생하는 일반적인 문제를 강조합니다. 테스트 센터를 사용하여 해당 테스트에 필요한 테스트 데이터를 만들 수 있습니다.

다음 표는 조직에서 찾거나 구축할 패턴을 선택하고, 방지하거나 수정할 항 패턴을 표시합니다.

✨ Pattern & Anti-Pattern Explorer에서 ALM에 대한 더 많은 패턴을 확인하십시오.

보안 및 사이트 신뢰도 엔지니어링(SRE)에서 사고 대응은 팀이 시스템의 전체 가용성 또는 보안에 영향을 미치는 이벤트를 식별하고 해결하는 방법, 근본 원인을 해결하고 향후 문제를 방지하기 위해 팀이 작업하는 방법에 초점을 맞춥니다. 사고 대응에는 실시간 및 문제 발생 후 문제를 해결하는 데 필요한 프로세스, 도구, 조직적 동작이 포함됩니다.

설계자는 솔루션이 적용되면 일상적으로 솔루션의 작업을 모니터링하지 않을 수 있습니다. 복원에 대한 아키텍처의 일부는 지원 팀이 1차 진단을 수행하고 시스템을 안정화하고 개발 또는 서비스 점검 팀에 효과적으로 조사 및 근본 원인 완화 작업을 전달할 수 있는 복구 기능을 설계하는 것입니다. 일상적으로 사용자를 직접 지원하는 팀은 시스템 아키텍처에 대한 심층적 이해 또는 전문 지식을 갖지 못할 수 있습니다. 이러한 팀은 일상적인 작업을 모니터링하고, 잠재적인 사고를 진단할 때 시스템에서 정보에 액세스하고, 가용성에 영향을 미치는 문제에 대해 효과적인 최초 대응 담당자 역할을 수행하는 데 필요한 도구와 프로세스를 보유해야 합니다.

Salesforce 솔루션에서 사고에 대한 팀의 대응 수준을 향상할 수 있으므로 복구 시간, 분류 능력, 모니터링 및 경고에 집중할 수 있습니다.

사고가 발생하면 첫 번째 우선 순위가 시스템을 안정적인 운영 상태로 복원해야 합니다. 비즈니스는 사고 복구의 유일한 방법은 "문제를 해결하는 것"이라고 생각하는 경우가 많습니다. 정확한 근본 원인 분석 및 해결 방법이 시스템에서 최종적으로 중요한 문제를 해결하는 방법이라는 가정은 공정합니다. 그러나 위기 대응 초기 단계에서 "문제 해결"은 가장 실용적인 접근 방식이 아닙니다. 사고의 심각도에 따라 사고의 모든 초과와 영향으로 인해 비즈니스의 매출 또는 평판이 손실될 수 있습니다.

근본 원인을 진단하고 해결하려고 하면 시스템을 복원하는 작업이 지연되는 경우가 많습니다. 물류적으로 사고 대응 담당자에게 근본 원인을 해결하도록 요청하는 접근 방식을 채택하면 회사의 주제 전문가(SME) 및 지원 직원이 엄청난 부담을 받습니다. 사고 도중 근본 원인을 찾고 해결하려면 중소기업이 모든 사고에 대해 통화해야 하며, 이는 고객 대면 지원 직원이 조치를 취하지 못하도록 차단할 수 있습니다. 또한 팀이 변경 사항을 릴리스하여 더 많은 사고를 야기할 수 있습니다. 최종적으로 이러한 접근 방식은 비용을 늘리고 팀 전체에서 대역폭을 소비하며 위기 상황에서 고객의 Trust 브랜드 평판을 손상시킬 수 있는 동작으로 이어집니다.

적절한 사고 관리 패러다임은 첫 번째 단계로 복구의 우선 순위를 지정하고 복구에 집중하는 것입니다. 시스템이 안정적으로 복원되면 무책임한 사후 요금, 사고 조사, 근본 원인 해결, 유사한 활동에 대한 팔로우업을 수행할 수 있습니다. 이 작업 순서로 사고 대응 직원이 복구 전술을 분류, 진단, 실행할 수 있게 되므로 필요한 경우에만 지원하도록 관련 SME에 알립니다. 또한 중소기업은 틱크 클럭의 압력을 줄여 사고의 근본 원인을 식별하고 해결할 수 있습니다.

사고 대응에 대한 복구 우선 고려 사항 채택:

• 서비스 수준 목표 SLO를 설정하고 달성합니다. SLO는 성능 또는 가동 시간과 같은 시스템의 특정 비기능 요구 사항(NFR)에 대해 이해당사자와 함께 개발하는 표준입니다. 이러한 목표는 기간에 걸친 서비스 수준 지표(SLI)로 측정됩니다. SLO를 사용하지 않으면 사고 대응 및 복잡한 문제 해결과 관련된 많은 작업이 비정형적이고 반응적일 수 있습니다. 예를 들어, "보고한 사용자 몇 명에 대해 이 특정 오류를 중지하도록 신속한 조치를 취하라는 메시지가 표시됩니다." 이러한 주기는 주로 팀이 사고 응답에 근접하게 근본 원인 분석을 푸시하므로 반응형 동작을 중지하는 데 도움이 됩니다. SLO 및 SLI를 설정하면 더욱 효과적으로 시작할 수 있습니다. SLO를 설정하려면 다음 질문을 고려하십시오.
  • 다음 1~3년 동안 시스템의 NFR는 무엇입니까? 예를 들어, NFR에 시스템에서 지원해야 하는 응답 시간, 최대 요청 비율 및 동시 사용자가 포함될 수 있습니다.
  • 고객과 사용자가 무엇을 경험하길 원하십니까? SLO는 "사용자가 Salesforce에서 보고서를 빠르게 실행할 수 있음"이라는 질문에 대한 답변을 기반으로 합니다.
  • 당신은 무엇을 측정할 수 있으며, 얼마 동안 측정해야합니까? SLI는 이 질문의 답변을 기반으로 합니다. 이전 예제와 일치하는 SLI는 "보고서의 평균 x%가 30일 동안 평균 _n_s 이내에 로드됩니다."입니다.
• 복구 전술을 정의하고 표준화합니다. 변경 롤백 및 해결 방법을 구현하면 시스템이 다시 작동하고 사고의 영향을 최소화할 수 있습니다. 지원 또는 운영 팀의 적절한 구성원이 실행할 수 있는 복구 전술 및 프로토콜을 문서화합니다. 복구 전술은 사고 유형에 따라 다릅니다. 다음 표는 사고 유형을 복구 전술에 매핑하는 일반적인 프레임워크를 보여줍니다. 장애 지점 식별 및 완화 전략 정의에 대한 자세한 내용은 가용성을 참조하십시오.

• 확실한 탈퇴 기준 정의 SLO를 사용하여 시스템이 사고 또는 영향 상태가 아닌 시점을 확인합니다.
• 사고 후 검토 및 근본 원인 해결을 위한 프로세스 정의. 서비스가 복원된 후 사고를 검토하십시오. 검토 중에, 죄없는 사후 접근을 취하십시오. 이해당사자와 협력하여 개인에게 오류 또는 책임을 할당하지 않고 발생한 상황 및 발생 방법에 대한 명확한 사실을 파악하는 데 집중합니다. 다양한 검토 형식을 사용하여 장기간 문제를 해결할 수 있는 방법을 살펴봅니다.
  • 후 조치 검토는 사고에 대한 대응에 중점을 둡니다. 적절한 응답 프로세스 및 전술이 있는지 평가하는 데 유용합니다.
  • • 근본 원인 분석*은 사고의 근본 원인에 초점을 맞춥니다. 사고를 유발한 시스템 설계 및 구현의 버그 또는 문제를 식별하는 데 도움이 됩니다.
• 약속된 복구 프로토콜을 정기적으로 연습하십시오. 모든 사람이 사고를 제대로 처리하는 방법을 알고 있도록 복구 프로토콜을 연습합니다. Sandbox 및 테스트 환경을 사용하여 팀에 사고 시뮬레이션 및 복구를 연습할 수 있는 장소를 제공합니다. 사고 후 검토도 연습하십시오. 이러한 모든 작업을 수행하면 복구가 엔지니어링 및 지원 문화의 일부가 됩니다.

사고 응답을 위한 패턴 및 안티패턴은 Salesforce 솔루션에서 복구 우선 순위를 지정하는 아키텍처를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다.

복구 시간에 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

기술 컨텍스트에서 정렬은 문제 및 지원 요청에 범주 및 심각도 수준을 할당하는 작업을 수행합니다. 솔루션이 얼마나 잘 계획되었든 사용자 지원 문제와 요청이 발생합니다. 이러한 문제는 충분한 교육이나 변경 관리 부족, UI/UX의 격차, 예기치 않은 최종 사용자 행동, 모니터링 또는 경고에서 파악되지 않는 긴급한 시스템 문제로 인해 발생할 수 있습니다.

지원 및 운영 팀은 사용자 지원 쿼리를 효율적으로 조사하고 빠르게 진단할 수 있어야 합니다. 문제를 정렬하여 덜 심각한 우려 사항을 필터링하고 중요한 시스템 사고를 신속하게 파악하는 것이 해당 팀의 핵심 역량입니다. 잘못된 분류는 모든 수준의 사용자 지원을 지연하고, 중요한 사고를 연장하며, 고객 및 비즈니스에 대한 추가 중단 위험을 높입니다.

일상적인 운영 및 지원에 관여하지 않을 수도 있지만, 설계자로서 지원 및 운영 팀이 Salesforce Platform에서 생성하는 모든 솔루션에서 문제를 효과적으로 정렬할 수 있도록 지원할 책임이 있습니다.

팀이 Salesforce 솔루션 내에서 문제를 효율적으로 분류할 수 있도록 지원:

• 지원 팀이 유용한 정보에 액세스할 수 있도록 하십시오.
  • 시스템 문서화 및 디자인 패턴 솔루션의 읽기 및 일관성을 보장하는 것은 지원 담당자가 지원하는 시스템을 이해할 수 있도록 하는 핵심 요소입니다. 문서에서 팀이 시스템의 다양한 부분에서 문제 또는 사고의 우선 순위를 지정하는 방법에 대한 정보를 찾는 방법을 고려합니다. 또한 팀이 영향 영역을 기반으로 복구 전술에 대한 기술 정보를 빠르게 확인할 수 있도록 합니다. 주제 분류 및 작업 선택과 같은 일반적인 Agentforce 문제에 대한 관련 문제 해결 가이드를 제공하여 팀이 권한 또는 구성과 관련된 문제를 신속하게 정렬할 수 있습니다.
  • 디버깅을 염두에 두고 설계하십시오. 지원 팀 및 조직 관리자가 다양한 환경에서 사용자 문제를 올바르게 정렬하려면 디버깅 및 진단을 활성화해야 합니다. 디버그 친화적 패턴의 예는 로깅 및 사용자 정의 오류 메시지를 시스템 전체의 실행 경로에 통합하는 패턴입니다. 이벤트 로그 및 Agent Builder의 추론 보기와 같은 도구를 사용하여 일반적인 Agentforce 디버깅 접근 방식을 지원하는 팀을 지원합니다.
  • 사고 중소기업 및 이해당사자 파악 사고 복구를 지원할 수 있어야 하는 관련 중소기업 또는 이해당사자 목록을 만들고 사고 후 분석 동안 관여해야 하는 이해당사자를 만듭니다.
  • Handoff를 신중하게 처리하십시오. 적용 과정의 일부로 지원 팀 또는 운영 팀에 대한 각 솔루션의 품질을 확인합니다. 지원 담당자가 관련 시스템 아키텍처 및 모의 사고 대응 드릴을 살펴볼 수 있도록 교육을 제공합니다. 팀이 로그 또는 사례 노트에서 수집되지 않는 정보를 문서화해야 하는 방법과 사고 응답자가 근본 원인 조사에 기여하거나 해결 방법에 대한 사용자 수락 테스트를 수행할 수 있는 방법을 포함하여 사고 후 하던프에 대해 생각해 보십시오.
• 상담을 받는 경우 모두가 복구에 집중하도록 하십시오.
  • 빠르게 응답하십시오. 수신한 모든 사용자 지원 요청, 모니터링 알림, 경고에 빠르게 응답합니다.
  • 증상과 문제를 구분하는 데 도움이 됩니다. 해결해야 하는 실제 시스템 사고가 있는지 확인합니다. 실제 문제가 있는 구성 요소를 식별하십시오. 합의된 복구 전술을 따라 시스템을 사고 상태에서 빠르게 제거하도록 지원합니다.
• 중요한 사용 사례를 지원하는 Agentforce 에이전트의 경우 실행 가능한 적절한 해결 방법이 있는지 확인하고 예비 조치로 짧은 경고로 설정할 수 있습니다. 예를 들어 수동으로 전환하거나 수동 검토를 위해 관련 문서로 리디렉션됩니다.

사고 응답을 위한 패턴 및 안티패턴은 Salesforce 솔루션에서 효과적인 분류를 위한 아키텍처를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다.

분류에 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

모니터링 및 경고은 현장 안정성 엔지니어링에서 널리 사용되는 용어입니다. 시스템 복원 능력의 맥락에서 모니터링은 시스템의 현재 상태를 지속적으로 평가하고 경고는 시스템 상태에 대한 잠재적인 우려 사항에 대해 이해당사자에게 자동으로 알립니다. 효과적인 모니터링 및 경고는 시스템의 규모와 성장과 지원 직원의 규모와 성장을 분리하는 데 중요한 부분입니다.

Salesforce는 시스템의 동작을 모니터링할 수 있는 다양한 내장 기능을 제공합니다. Salesforce는 추가 기능 또는 Salesforce Shield의 일부로 실시간 이벤트 모니터링도 제공합니다. Salesforce 솔루션에서 모니터링 및 경고를 위해 설계된 설계는 다음을 제공합니다.

• 자동 사고 응답 기능
• 적시에 적절한 사용자에게 관련 정보 제공
• 내역 보기 및 추세 분석에 대한 명확한 정보

Salesforce 솔루션 내에서 효과적인 모니터링 및 경고를 위한 설계:

• 자동화의 우선 순위 지정 시스템을 안정적이고 운영하기 위해 중요한 상태 변경 사항에 대해 사용자에게 알리는 것이 중요하지만, 이상적인 아키텍처에서 시스템은 가능한 경우 문제를 자체 수정하고 긴급하고 복구할 수 없는 문제에 대해서만 경고를 보냅니다. 자동화는 자체 수정 기능이 없어도 경고 및 보고가 더욱 유용해질 수 있습니다.
  • Salesforce에서 이미 제공하는 것부터 시작하십시오. Salesforce Platform은 총괄자 제한과 관련하여 솔루션의 작업을 모니터링할 수 있는 관련 로그 및 API를 제공합니다. 또한 플랫폼은 총괄자 제한 위반 및 유사한 문제에 대한 경고를 보냅니다. 이러한 로그 및 경고를 기반으로 시스템 자가 복구, 사고 보고, 경고를 보다 완전히 자동화할 수 있는 방법을 살펴볼 수 있습니다. 예를 들어, 로그를 모니터링한 후 특정 유형의 이벤트가 기록될 때 복구 작업을 수행하는 자동화를 구현할 수 있습니다.
  • 예측 가능한 방식으로 시스템 상태의 변경 사항을 분류합니다. 모니터링하고 보고할 주요 상태에 대한 의미 있는 특정 범주를 만듭니다. 이러한 범주를 응용 프로그램 구성 요소에서 상태를 관리하기 위해 정의한 범주에 맞춥니다. 상태 변경 정보를 처리하는 방법에 대해 API 지향적 사고 방식을 채택합니다. 일관된 메시지 형식 및 상태 범주를 사용하면 자동화, 보고, 경고를 간소화할 수 있습니다.
  • 자동화 논리를 시스템의 다른 부분과 일치시킵니다. 올바른 자동화 오류 처리를 구축한 경우 해당 패턴을 상태 변경을 분류하고 자동화로 대응하는 방법으로 확장할 수 있습니다. 복구 가능한 상태로 간주되는 상태 변경의 경우 재시도 동작을 자동화할 수 있습니다. 중요하거나 치명적인 상태로 간주되는 상태 변경의 경우 사용자에게 경고를 자동화합니다.
• 소리를 피하십시오. 특히 조치를 취하지 않아도 되는 경고가 너무 많으면 사용자가 모든 경고를 비활성화하거나 무시하는 경향이 있습니다. 이 시나리오는 유용한 경고를 생성하기 위한 모든 노력을 저하합니다. 알림을 수신하는 사람, 트리거하는 요소 및 트리거 시기를 더 잘 파악하려면 다음 작업을 고려하십시오.
  • 이해당사자 맵 구축 시스템이 적시에 적절한 이해당사자에게 올바른 경고를 전달하도록 하려면 먼저 이해당사자 그룹을 식별하고 분류합니다.
  • 사용자 권한을 기반으로 메시지를 라우팅합니다. 응답할 수 있는 능력 및 권한이 있는 수신자에게만 경고를 보냅니다. 비즈니스 사용자는 액세스 권한이 있는 레코드의 문제를 수정하여 해결할 수 있는 문제에 대한 경고의 혜택을 누릴 수 있습니다. 문제에 대해 더 적극적인 기술적 대응이 필요한 경우 지원 담당자에게 경고를 보냅니다.
  • 예상 응답을 명확히 하십시오. 사람이 개입해야 하는 시나리오에서만 경고를 보냅니다. 수신자에게 예상되는 작업을 명확하게 표시하도록 메시지를 구조화합니다. 이해당사자에게 가시성을 위해 경고를 보내고 이해당사자에게 조치가 필요하지 않은 경우 수신하는 메시지 버전에 명확하게 명시합니다.
  • 일시적이고 적절한 경고를 만듭니다. 발생했지만 수정해야 하는 실패에 대한 응답으로 전달되는 경고는 잠재적인 실패에 대한 경고만큼 유용하지 않습니다. 이상적으로 지원 직원은 시스템에서 문제가 발생하면 즉시 경고를 받으므로 문제가 비즈니스 운영에 부정적인 영향을 미치기 전에 문제를 정렬할 수 있습니다.

패턴 및 안티패턴 목록은 Salesforce 솔루션에서 효과적인 모니터링 및 경고를 위한 아키텍처를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템 영역을 식별합니다.

모니터링 및 경고를 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 사고 응답에 대한 더 많은 패턴을 알아보십시오.

비즈니스 복구의 핵심은 비계획 이벤트로 인해 발생한 문제를 통해 사람과 시스템이 작동하는 방법에 중점을 둔 연속성 계획입니다. 비즈니스 연속성 계획(BCP)은 위기를 통해 프로세스를 계속 진행하는 방법에 대한 사람 중심의 보기를 가져옵니다. 무중단 계획의 기술적 측면은 BCP의 재해 복구 부분에 포함되어 있습니다. 기술 연속성을 참조하십시오.

적절한 연속성 계획이 없으면 이제 조직이 위기 또는 시스템 중단 시 조치를 취하는 방법을 알 수 있으므로 전혀 조치를 취하지 않을 수 있습니다. 비효율적인 연속성 계획은 고객, 이해당사자, 비즈니스에 재앙적인 영향을 미칠 수 있습니다. 부정적인 이벤트 후 중요한 프로세스를 유지하거나 복구하지 않고 지나가는 모든 순간은 재정적 손상, 평판 손상, 직원 안전, 규정 준수까지 위험합니다.

Salesforce의 비즈니스 연속성 정의, 기술 연속성 계획, 백업 및 복원 기능 구축과 같은 세 가지 영역에 노력을 집중하여 시스템에 더 나은 연속성 계획을 수립할 수 있습니다.

회사에 이미 BCP가 있을 수 있습니다. 이 경우 Salesforce가 포함되어 있는지 확인합니다. 회사에 BCP가 없는 경우 이해당사자와 협력하여 Salesforce 조직에 적용되는 BCP를 만듭니다.

Salesforce는 많은 비즈니스 디비전 전반에서 고객 데이터 및 필수 비즈니스 프로세스에 대한 신뢰할 수 있는 소스로 사용되는 경우가 많습니다. 따라서 Salesforce가 BCP에서 수행하는 역할은 다른 시스템에서 수행하는 역할과 다를 수 있습니다. Salesforce가 복구에 우선 순위가 높은 여러 영역에 참여할 가능성이 높습니다.

Salesforce 시스템에 대한 관련 비즈니스 연속성 계획 만들기:

• 복구의 우선 순위를 명확히 하십시오. 사고 대응에 대한 일반적인 접근 방식과 마찬가지로 위기 시점에서 시스템의 최우선 순위가 복구여야 합니다. 많은 비즈니스에 중요한 서비스가 Salesforce에서 실행됩니다. 이해당사자가 다양한 비즈니스 기능 및 성능을 복구하기 위한 올바른 우선 순위를 식별하도록 지원해야 합니다. 일반 프레임워크는 다음과 같습니다.
  • 필수 비즈니스 인프라를 안정화합니다.
  • 고객 서비스를 안정화합니다.
  • 직원 및 파트너 서비스를 안정화합니다.
• BCP에서 생태계 계산 Salesforce는 해당 환경의 유일한 시스템이 아닙니다. Salesforce와 통합되는 시스템, AppExchange 공급업체에서 설치된 솔루션, Salesforce의 데이터 또는 프로세스에 연결되는 기타 시스템과 관련하여 BCP의 간격을 파악해야 합니다. 배달 능력이 공급업체에 따라 달라질 경우 해당 공급업체에 연속성 계획에 대해 문의하십시오. 해당 기능을 평가하고 시스템을 계속 사용할 수 있는 방법을 계획합니다.
• BCP 문제를 테스트 전략에 통합합니다. BCP에 대한 테스트 계획을 만들고 실행합니다. 프로세스 또는 사람과 관련된 BCP 영역을 테스트하는 것이 특히 중요하며, 이를 잊어버리는 경우가 많습니다. BCP의 관련 항목을 전체 ALM 테스트 전략에 통합합니다. 서비스 점검 일정을 만들고 따라 테스트를 검토하고 계획이 최신 상태로 유지되는지 확인합니다.

연속성 계획을 위한 패턴과 안티패턴은 Salesforce 솔루션에서 올바른 연속성 계획과 나쁜 연속성 계획을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다.

비즈니스 연속성을 정의하기 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

기술 연속성의 목표는 시스템의 구성 요소에 대한 문제로 인해 비즈니스가 필수 운영을 유지할 수 없도록 하는 것입니다. Salesforce는 서비스 가용성 수준을 최대로 유지하고 문제에 대한 투명한 정보를 제공하는 것이 중요합니다. Trust.salesforce.com에서 Salesforce 시스템 성능 및 문제에 대한 실시간 정보를 볼 수 있습니다. Salesforce에 구축된 설계자로서, 솔루션은 Salesforce가 전체 플랫폼에서 제공하는 사이트 신뢰성, 보안, 성능 기능을 활용할 수 있습니다.

그러나 Salesforce 솔루션의 전반적인 연속성은 Salesforce에서 제공하는 내장형 서비스 이상으로 확장됩니다. 아키텍처 관점에서 Salesforce 기술 연속성 계획은 대규모 기업 환경에 Salesforce가 어떻게 적합한지에 대한 질문과 답변으로 시작해야 합니다. Salesforce와 통합되는 시스템은 무엇입니까? Salesforce의 프로세스 또는 정보에 외부 시스템이 어떻게 의존합니까? Salesforce 조직에서 AppExchange 솔루션에 의존하는 프로세스 또는 기능은 무엇입니까? 사용자가 타사 ID 서비스 또는 SSO를 통해 Salesforce에 액세스합니까?

Salesforce 시스템에서 더 나은 기술 연속성 구축:

• 인프라를 평가합니다. 기술 중단 또는 문제에 대한 가장 일반적인 해결 전략은 사고 중에 다시 사용할 수 있는 중복 서비스 또는 시스템 구축입니다. Salesforce에는 의도적으로 중복된 아키텍처가 있습니다. 즉, 고객의 시스템 및 서비스 사본을 다른 물리적 위치에 유지합니다. 필요한 경우 하나의 데이터 센터에서 다른 데이터 센터로 사용자 트래픽을 이동시킬 수 있는 사이트 전환 등 몇 가지 재해 복구 기법을 사용합니다. 의도적 중복을 구축해야 할 위치를 식별하려면 다음 질문을 하십시오.
  • [X] 서비스에 대한 서비스가 중단되는 동안 어떤 일이 발생합니까? 해당 서비스에서 다른 서비스로 전환할 수 있습니까?
  • [X]를 복구하는 데 시간이 얼마나 걸립니까? 고객에게 미치는 영향은 무엇입니까? 파트너에게 미치는 영향은 무엇입니까? 내부 팀에 미치는 영향은 무엇입니까?
  • 백업 및 빈도는 어떻습니까? 백업에서 비즈니스를 지원하는 데 필요한 데이터를 제공할 수 있습니까?
  • 공급업체에 종속성이 있습니까? BCP 계획은 무엇입니까?
• 운영 지원 제공. 운영 지원은 가능한 한 빨리 팀을 복구하고 실행하는 것입니다. 시스템이 산업 전체, 지역 전체 또는 글로벌 변화 등 예기치 않은 변화로 인한 수용력 요구 사항 및 수요의 상당한 증가를 처리할 수 있는 방법을 생각해 보십시오. 사이트 신뢰도 엔지니어링(SRE) 또는 지원 팀이 사고에 효과적으로 대응하기 위해 필요한 추가 리소스나 구체적인 절차가 BCP에 포함되어 있는지 확인합니다. 운영 지원에 대한 질문에는 다음이 포함됩니다.
  • 중단 시 기술 팀에 작업을 계속하기 위해 필요한 도구가 있습니까? 계획을 확인하거나 공백을 식별하기 위해 중단을 시뮬레이션했습니까?
  • 특정 지역에 재해가 발생한 경우 해당 지역에 대한 보장 계획이 있습니까?
  • 고객은 전 세계 고객입니까? 연중무휴 운영 여부
  • 장애가 발생할 경우 적절한 개인에게 알릴 수 있는 적절한 모니터링 및 경고가 있습니까?
• 복구 전술을 자동화하고 테스트합니다. 문제를 해결한 후 발생한 위치와 해결 방법을 식별합니다. 가능한 경우 조치를 기반으로 복구 전술을 자동화하고 프로세스 문제를 조정합니다. 많은 회사가 서비스 하위 집합에 대한 사고 시뮬레이션을 예약하여 시스템 복원을 테스트합니다. 예를 들어 시스템 관리자 계정이 잠겨 있거나 손상되었거나 AppExchange 공급자의 중단 또는 문제를 시뮬레이션할 수 있습니다. 사고 대응을 참조하십시오.) 테스트 및 자동화가 서비스를 더 빠르게 복원하는 데 도움이 되는 방법에 대한 질문은 다음과 같습니다.
  • 사고 시뮬레이션을 얼마나 자주 예약하고 실행합니까?
  • 서비스를 안정적인 상태로 복원하는 데 걸리는 시간을 알고 있습니까?
  • 안정적인 배달 프로세스가 있습니까?
  • 페일오버 및 복구를 자동화할 수 있는 위치를 알고 있습니까?

사고 후 검토에서 나온 모든 항목을 다른 개발 항목과 마찬가지로 처리합니다. 우선 순위를 지정하고 작업할 수 있도록 계획 시스템에 추가합니다.

연속성 계획을 위한 모형 및 비모형은 Salesforce 솔루션에서 올바른 기술 연속성 계획과 나쁜 기술 계획을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다.

기술 연속성 계획을 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

백업된 데이터 또는 메타데이터 사본을 복원하면 조직이 마지막으로 알려진 안정 상태로 되돌아갈 수 있습니다. 재해적인 시스템 오류 또는 서비스 중단 시 장애 복구 시스템을 제공할 수도 있습니다. 데이터 및 메타데이터를 정기적으로 백업하고 암호화된 백업 복사본을 보안 위치에 저장하면 아키텍처에 추가적인 복원 수준이 추가됩니다.

백업 및 복원 전략이 없으면 악의적으로 손상되거나 결함이 실수로 프로덕션으로 들어오거나 대용량 데이터 로드 중 실패로 인해 프로덕션 데이터가 손상된 경우 정리된 버전의 프로덕션 데이터 및 메타데이터를 복원할 수 없습니다. 이러한 시나리오 중 하나로 인해 비즈니스에 중요한 프로덕션 데이터가 손상되거나 영구적으로 손실될 수 있습니다. 백업 및 복원 기술을 설정하면 대용량 데이터를 완화하는 전략 및 규정 준수 관련 유지 정책을 준수하는 등 연속성 계획 외에도 다양한 장점을 제공합니다.

Salesforce 솔루션의 백업 및 복원 전략에 대한 연속성 보장:

• 시작해요. 적절한 백업 및 복원 전략을 수립하기 위한 첫 단계는 먼저 전략을 수립하는 것입니다. 조직의 모든 데이터 및 메타데이터를 야간으로 백업하는 것처럼 간단한 작업을 수행해도 비즈니스가 재해 시 중요한 정보 또는 기능을 잃지 않도록 할 수 있습니다.
• 백업에 대한 액세스를 제한합니다. 시스템 관리자만 데이터의 백업 복사본에 액세스해야 하는 사용자입니다. 액세스 제한으로 인해 비즈니스 사용자가 조직에서 볼 권한이 없는 백업 사본의 레코드를 볼 수 없습니다.
• 정기적으로 복원 프로세스를 테스트하십시오. 어떤 백업 및 복원 전략을 구현하든 상관없이 전체 또는 부분 복제 sandbox에서 복원 프로세스를 정기적으로 테스트하십시오.
• 백업 및 복원 전략을 데이터 아카이빙 전략과 일치시킵니다. 레코드가 보관되거나 시스템에서 제거될 때 백업 또는 보관에서 수행할 작업을 결정합니다. 데이터 볼륨 참조).

데이터 용량이 너무 크므로 다음 백업을 실행하기 전에 전체 백업을 완료할 시간이 없을 경우 보다 세부적인 백업 전략이 필요할 수 있습니다. 또한 조직의 데이터가 너무 자주 변경되어 업데이트가 조직에 중요한 임무가 될 경우 보다 세부적인 백업 전략이 필요할 수 있습니다.

보다 세분화된 백업 전략 만들기:

• 백업 범위를 특정 개체로 지정합니다. 이 전략은 다른 시간 간격으로 다른 개체의 레코드를 백업하는 작업을 수행합니다. 하위 개체를 상위 개체와 동일한 간격으로 백업해야만 데이터 일관성을 유지할 수 있습니다.
• 타임박스 부분 백업 이 전략은 전체 백업(모든 데이터 및 메타데이터)과 부분 백업(마지막 백업 이후에 추가되거나 변경된 메타데이터 및 레코드만)을 구분하는 작업을 포함합니다.

* 전체 백업 수행을 중지하지 마십시오. 데이터 용량으로 인해 실행 시간이 길어도 전체 백업을 완전히 제거해서는 안 됩니다. 대용량 데이터의 경우 정기적이지만 자주 사용하지 않는 전체 백업(예: 주간 백업)을 계획하십시오. 또한 부분 또는 개체별 백업(예: X 시간마다 야간 백업 또는 백업)을 더 자주 수행할 수 있습니다. 이 접근 방식을 통해 복원 프로세스에 사용할 가장 완전하고 정확한 데이터 집합을 유연하게 재구성할 수 있습니다.*

연속성 계획을 위한 패턴 및 안티패턴은 Salesforce 솔루션에서 올바른 백업 및 복원 기능과 나쁜 백업 및 복원 기능을 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 재구성해야 하는 시스템의 위치를 식별합니다.

자체 획득에서 자체 복구를 포함하는 통합 Salesforce 솔루션인 Salesforce 백업 및 복구는 중요한 데이터를 손실 또는 손상으로부터 보호합니다. 고안정성과 설정이 간편하며 항상 사용할 수 있는 솔루션은 비즈니스 연속성과 데이터 복원성을 보장하고 규정을 준수하는 과정을 간소화합니다.

Salesforce 백업 및 복구를 사용하여 데이터 손실을 방지하고, 데이터 사고로부터 신속하게 복구하고, 전반적인 데이터 관리 전략을 간소화합니다. 중요한 규제된 데이터에 대한 백업 정책을 만들고 클릭 몇 번으로 해당 데이터를 복원할 수 있습니다.

일일 자동 백업은 메타데이터, Sandbox, 관리 패키지 데이터, 파일 첨부 파일 등을 포함하여 모든 중요한 조직 데이터를 보호합니다. 필요한 만큼 자주 백업을 실행하여 복구 지점 목표(RPO) 목표를 달성하고 배포를 보호합니다. 백업에 항상 액세스할 수 있으며 안전하고 규정을 준수하는 방식으로 저장됩니다. 더욱 민감한 데이터 또는 트랜잭션 데이터에도 연속 데이터 보호를 사용할 수 있으므로 빠르게 변화하는 중요 정보를 빠르게 복구할 수 있습니다.

이메일로 직접 전송되는 사전 경고를 사용하여 일반적이지 않은 데이터 활동, 데이터 손실, 손상을 감지합니다. 실시간 경고를 수신하여 통계 이상값을 식별하거나 일반적이지 않은 데이터 활동을 알리는 규칙을 만들어 사고를 그 어느 때보다 빠르게 감지할 수 있습니다.

Salesforce 백업 및 복구는 변경 사항에 대한 세부적인 가시성을 제공하여 신속하게 영향받는 데이터를 식별하고 복원할 수 있도록 복구 속도를 높입니다. 시각적 그래프와 같은 도구는 원치 않는 변경 사항을 강조 표시하고, 사용하기 쉬운 복구 기능은 영향받는 개체, 필드, 레코드를 정확하게 복원합니다.

도구를 사용하면 분석, 감사, 규정 준수에 백업을 사용할 수 있으며, 검색 가능한 내역 데이터를 제공하고, 과거 데이터의 가시성을 위한 열려 있는 검색 기능을 사용하고, 외부 분석 또는 창고를 위한 내보내기 기능을 사용할 수 있습니다. 이렇게 하면 추가 Salesforce API가 필요하지 않은 백업 용도가 변경됩니다.

백업 및 복구는 모든 백업, 관리, 운영, 규정 준수를 통합하기 위한 단일 콘솔을 제공합니다. 이 콘솔을 사용하면 모든 프로덕션 조직 및 Sandbox에 대한 백업에 액세스, 관리, 사용자 정의, 모니터링할 수 있습니다. 또한 데이터 주체 요청을 실행하여 백업 데이터 규정을 준수하고 백업 일정, 빈도, 보존 정책을 완벽하게 제어할 수 있습니다.

• 데이터 사고의 영향 완화 Salesforce 백업 및 복구를 사용하면 사용자가 영향을 받는 레코드를 사고 전 상태로 되돌릴 수 있으므로 사이버 공격 또는 악의적인 내부 또는 외부 활동과 같은 데이터 사고를 완화할 수 있습니다. 백업 및 복구의 내보내기 기능은 사용자의 중요 데이터에 대한 지속적인 액세스 및 유용성을 보장합니다.
• 지연 데이터 손실을 방지합니다. 인간 오류는 여전히 데이터 손실의 주요 원인입니다. 백업 및 복구는 이러한 오류에 대한 정확하고 빠른 솔루션을 제공합니다.
• 데이터 규정 준수 및 법적 요건을 더욱 쉬워집니다. Salesforce 백업 및 복구는 공유 책임 모델을 지원하므로 백업 데이터의 대량 분실 또는 데이터 정정을 위한 셀프 서비스 기능을 활성화합니다.

백업 및 복원용 Salesforce 도구에 대해 자세히 알아보려면 Salesforce Resiliency 도구를 참조하십시오.

이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 연속성 계획을 위한 더 많은 패턴을 알아보십시오.

Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 설문 조사를 수행하고 다음에 원하는 내용을 알려주십시오.