# 11 - 장애 탐지 및 대응
**SAP 워크로드에 영향을 미치는 장애를 어떻게 탐지하고 대응합니까?** SAP 워크로드의 상태 및 복원력을 보장할 수 있는 소프트웨어 또는 운영 절차를 설계합니다. 가능한 경우 예방에 초점을 맞춰 잠재적 장애 및 실제 장애를 모니터링합니다. 구성 요소가 분산되어 있는지 아니면 단일 장애 지점인지 고려하고 워크로드에 대한 영향을 최소화하는 복원성 솔루션을 설계합니다. 위험 프로필을 이해하기 위해 주기적으로 테스트하는 것 외에 복원력을 향상할 수 있는 자동화를 검토합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-11.html)
자세한 내용은 다음을 참조하세요.
+ AWS 설명서: [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) ( [장애 시나리오](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-failure-scenarios) 및 [아키텍처 패턴 포함)](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-patterns)
# 모범 사례 11.1 - SAP 애플리케이션, AWS 리소스 및 연결 장애를 모니터링
SAP 애플리케이션, AWS 리소스 및 연결의 장애를 모니터링하면 실제 장애 또는 잠재적 장애에 적시에 대응할 수 있습니다.
**제안 사항 11.1.1 – AWS Personal Health Dashboard 및 알림을 사용**
[AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) 는 애플리케이션을 구동하는 AWS 서비스의 상태에 대한 개인화된 보기를 제공하여 SAP 워크로드에 영향을 미치는 문제가 발생할 때 신속하게 확인할 수 있도록 합니다. 예를 들어 [Amazon Elastic Block Store(Amazon EBS)](https://aws.amazon.com/ebs/) 볼륨이 [Amazon EC2](https://aws.amazon.com/ec2/) 인스턴스 중 하나에 연결된 상태에서 손실되는 경우입니다.
이 대시보드는 또한 미래 지향적인 알림을 제공하며 이메일을 비롯한 여러 채널에서 경고를 설정할 수 있으므로 변경 일정을 계획하는 데 도움이 되는 시기적절하고 관련성 있는 정보를 받을 수 있습니다. 예를 들어 AWS 하드웨어 유지 관리 작업이 [Amazon EC2](https://aws.amazon.com/ec2/) 인스턴스 중 하나에 영향을 미치는 경우 변경을 계획하고 예정된 변경과 관련된 문제를 사전에 해결하는 데 도움이 되는 정보가 포함된 알림을 받게 됩니다.
**제안 사항 11.1.2 – SAP 시스템의 상태를 이해하기 위한 AWS 서비스를 평가**
AWS는 다수의 [관리 및 거버넌스](https://aws.amazon.com/products/management-and-governance/) 서비스를 제공하므로 이를 평가해야 합니다. EC2 인스턴스 장애, 높은 CPU 사용률, 파일 시스템 사용률과 같은 실제 장애 또는 잠재적 장애를 나타내는 지표에 초점을 맞춥니다.
자세한 내용은 운영 우수성 원칙을 참조하세요.
+ SAP Lens [운영 우수성]: [모범 사례 1.1 - SAP on AWS 모니터링을 위한 사전 조건 구현](best-practice-1-1.md)
+ SAP Lens [운영 우수성]: [모범 사례 1.4 - 워크로드 구성 모니터링 구현](best-practice-1-4.md)
**제안 사항 11.1.3 – 장애를 모니터링하는 SAP 도구의 기능을 평가**
Solution Manager, Landscape Manager 같은 SAP 도구를 사용하면 애플리케이션 컨텍스트에서 모니터링 데이터를 확인할 수 있습니다. SAP에서 다음과 같은 모니터링 솔루션을 사용할 수 있습니다. 이러한 도구를 평가할 때 추가 라이선싱 비용을 검토합니다.
+ SAP 설명서: [SAP Focused run](https://support.sap.com/en/alm/sap-focused-run.html)
+ SAP 설명서: [SAP Solution Manager](https://support.sap.com/en/alm/solution-manager.html)
+ SAP 설명서: [SAP Landscape Manager(LaMa)](https://help.sap.com/viewer/lama_help)
+ SAP Note: [2574820 - Amazon Web Services(AWS)용 SAP Landscape Management Cloud Manager](https://launchpad.support.sap.com/#/notes/2574820) [SAP 포털 액세스 권한 필요]
**제안 사항 11.1.4 – AWS 및 SAP 모니터링을 위한 서드 파티 도구를 평가**
AWS Marketplace에서 다음과 같은 모니터링 솔루션을 사용할 수 있습니다. 이러한 도구를 포함하여 서드 파티 도구를 평가해야 합니다.
+ AWS 설명서: [AWS Marketplace의 모니터링 솔루션](https://aws.amazon.com/marketplace/b/2649280011?ref_=mp_nav_category_2649280011)
# 모범 사례 11.2 - 가용성 유지를 위한 접근 방식 정의
단일 기술 구성 요소 또는 AWS 서비스의 장애를 견딜 수 있는 복원력 있는 아키텍처를 통해 가용성을 유지합니다. 이러한 메커니즘에는 이중화된 용량, 로드 밸런싱, 소프트웨어 클러스터가 포함될 수 있습니다.
**제안 사항 11.2.1 – 리소스 고갈 또는 서비스 품질 저하로 인한 장애를 방지**
리소스 초과 프로비저닝, 증가에 대한 사전 모니터링 및 한도 설정을 통한 사용량 제한을 조사합니다.
운영 우수성 원칙은 SAP 애플리케이션의 상태를 이해하고 적절한 조치를 취할 수 있도록 하는 다양한 방법을 다룹니다. [운영 우수성] [1 - 상태를 이해하고 대응할 수 있도록 SAP 워크로드를 설계](design-principle-1.md) 를 참조하세요.
성능 원칙은 용량을 적절한 규모로 설정하고 크기 조정하는 데 도움이 될 수 있습니다. [성능]: [16 - 지속적인 성능 및 최적화 옵션 이해](design-principle-16.md) .
**제안 사항 11.2.2 – 유지 관리 일정을 위한 전략을 수립**
비즈니스에 예정된 중단을 최소화해야 하는 요구 사항이 있는 경우 SAP 애플리케이션, 데이터베이스, 운영 체제, AWS 등 모든 수준에서 유지 관리 전략을 개발해야 합니다. 다음 사항을 고려하세요.
+ 프라이머리 노드와 세컨더리 노드를 교대로 사용하는 복제 및 클러스터 솔루션을 사용.
+ 단계적 중단이 용이하게 확장 및 축소할 수 있는 초과 용량 및 메커니즘.
+ 가능한 경우 운영 체제에 대한 라이브 패치 적용 접근 방식을 사용.
+ [SUSE Linux Enterprise Live Patching](https://www.suse.com/products/live-patching/)
+ [Red Hat Reducing downtime for SAP HANA(SAP HANA 가동 중지 시간 감소) 백서](https://www.redhat.com/cms/managed-files/pa-sap-hana-reducing-downtime-overview-f22788pr-202004-en.pdf)
+ AWS 설명서: [AWS Systems Manager 패치 관리자 패치 그룹](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ SAP Note: [1913302 - HANA: 짧은 유지 관리 작업을 위해 DB 연결 일시 중단](https://launchpad.support.sap.com/#/notes/1913302) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2077934 - HA 환경의 Rolling Kernel Switch](https://launchpad.support.sap.com/#/notes/2077934) [SAP 포털 액세스 권한 필요]
+ SAP Note: [953653 - Rolling Kernel Switch](https://launchpad.support.sap.com/#/notes/953653) [SAP 포털 액세스 권한 필요]
+ SAP Note: [2254173 - Linux: Pacemaker 기반 NetWeaver HA 환경의 Rolling Kernel Switch](https://launchpad.support.sap.com/#/notes/2254173) [SAP 포털 액세스 권한 필요]
또한 일시적으로 성능을 향상시켜 예정된 유지 관리의 전체 가동 중지 시간을 단축할 수 있도록 AWS 서비스의 탄력적 기능을 평가해야 합니다. 예를 들어, 데이터베이스가 실행되는 Amazon EC2 인스턴스의 크기를 확장하여 업그레이드 작업에 더 많은 CPU 및 스토리지 처리량을 제공하거나 EBS 볼륨 유형을 gp2에서 io2로 전환하여 데이터베이스 재구성 중에 스토리지 처리량을 개선합니다.
**제안 사항 11.2.3 – 소프트웨어 클러스터 또는 기타 메커니즘으로 SAP 단일 장애 지점을 보호**
가용 영역 간에 SAP 단일 장애 지점(SAP 중앙 서비스 및 데이터베이스) 자동 장애 조치를 위해 고가용성(HA) 클러스터링 솔루션을 사용할 수 있습니다.
여러 SAP 인증 클러스터링 솔루션이 [SAP 웹 사이트](https://wiki.scn.sap.com/wiki/display/SI/Certified+HA-Interface+Partners) 에 나열되어 있습니다. SAP 클러스터링 솔루션은 SAP가 아닌 클러스터 소프트웨어 공급 업체에서 직접 지원합니다. SAP는 솔루션을 인증만 합니다. 맞춤형 솔루션은 인증되지 않으며 솔루션 빌더가 지원해야 합니다.
단일 장애 지점에 클러스터링 솔루션을 사용하지 않기로 한 경우 서비스 복원과 관련된 오류를 최소화하기 위해 스크립팅 또는 런북을 고려합니다.
**제안 사항 11.2.4 – 지원되는 구성 요소에 대한 이중화된 용량 또는 자동 크기 조정**
정적, 동적 또는 예약된 용량 변경이 사용량과 일치하는지 평가합니다. 최소 용량 요구 사항과 장애 및 유지 관리가 해당 요구 사항에 미치는 영향을 검토합니다. 적절한 경우 장애 복구 시간을 확보할 수 있도록 오버 프로비저닝합니다.
AZ 장애 발생 시에도 100% 용량을 유지해야 하는 경우 3개의 AZ에 걸쳐 애플리케이션 계층을 배포하는 것을 고려해야 합니다. 이때 각 AZ는 필요한 총 용량의 50%를 가져야 합니다.
여러 AZ에 SAP 애플리케이션 서버 계층을 배포하는 것 외에도 다음 SAP on AWS 블로그 게시물에 설명된 것과 같이 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling) 의 기능을 활용하는 크기 조정 솔루션을 고려할 수 있습니다.
+ SAP on AWS 블로그: [AWS를 사용하여 SAP Application Auto Scaling 활성화](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
+ AWS 설명서: [SAP용 Amazon EC2 인스턴스 유형](https://aws.amazon.com/sap/instance-types/)
+ SAP Note: [1656099 - AWS의 SAP 애플리케이션: DB/OS 및 Amazon EC2 제품 지원](https://launchpad.support.sap.com/#/notes/1656099) [SAP 포털 액세스 권한 필요]
**제안 사항 11.2.5 – 모든 식별된 장애 시나리오에서 용량 가용성을 보장**
다음은 분석을 안내하는 데 사용할 수 있는 장애 시나리오의 예입니다. 시나리오의 세분 수준 및 적용 범위, 분류, 영향은 요구 사항 및 아키텍처에 따라 달라집니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-11-2.html)
용량 예약에 대한 추가 지침은 다음에서 확인할 수 있습니다. [안정성]: [제안 사항 10.2.5 – 용량을 보장하기 위한 전략을 조사](best-practice-10-2.md) 및 AWS 백서: [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) .
AWS 계정 내에서 사용 가능한 예약 인스턴스는 [AWS Cost Explorer RI 보고서](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-default-reports.html#ce-ri-reports) 를 사용하여 검토할 수 있습니다.
**제안 사항 11.2.6 – 적용 가능한 경우 가용성이 내재된 AWS 서비스를 사용**
여러 AWS 서비스는 설계에 가용성이 포함되며 고가용성을 위해 여러 가용 영역에서 실행됩니다. SAP 컨텍스트에서 사용되는 관련 서비스에는 다음이 포함됩니다.
+ AWS 서비스: [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html)
+ AWS 서비스: [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)
+ AWS 서비스: [Route 53](https://aws.amazon.com/route53/faqs/)
+ AWS 서비스: [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html)
+ AWS 서비스: [Amazon S3](https://aws.amazon.com/s3/)
또한 배스천 호스트 또는 SAPRouter와 같은 무상태 서비스를 사용하는 구성 요소는 Auto Scaling 그룹을 사용하여 고가용성을 달성할 수 있습니다.
**제안 사항 11.2.7 -– 네트워크 연결을 보장하기 위한 AWS 모범 사례를 준수**
사용 중인 AWS 리전에 대한 네트워크 연결의 복원력을 보장하기 위해 다음 AWS 모범 사례 중 하나 이상을 평가합니다.
+ AWS 설명서: [AWS Direct Connect 복원 도구 키트](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ AWS 설명서: [AWS VPN CloudHub](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-vpn-cloudhub.html)
클러스터 솔루션이 오버레이 IP를 사용하는 경우 VPC 외부로부터 액세스를 활성화하려면 다음을 고려합니다.
+ AWS 설명서: [오버레이 IP 주소 라우팅을 사용한 SAP on AWS 고가용성](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html)
# 모범 사례 11.3 - 서비스 가용성 복원을 위한 접근 방식 정의
가용성 복원은 특정 장애 시나리오의 경우 일부 서비스 손실이 발생한다고 가정합니다. 복원 접근 방식에서는 서비스를 복원하는 데 필요한 시간과 가용성 목표를 달성하는 데 필요한 조치를 검토해야 합니다.
**제안 사항 11.3.1 – EC2 인스턴스에 인스턴스 복구를 사용**
Amazon EC2 인스턴스를 모니터링하고, 기반 하드웨어의 장애로 인해 인스턴스가 손상된 경우 인스턴스를 자동으로 복구하는 Amazon CloudWatch 경보를 생성할 수 있습니다. 이 조치는 수동 개입 필요성을 제거할 수 있지만 시작, 애플리케이션 재시작 및 로드 시간을 복구 시간 목표(RTO)에 포함해야 합니다. 하드웨어 장애로부터 보호하기 위해 클러스터링 솔루션을 사용하려는 경우 인스턴스 복구가 클러스터 솔루션과 호환되는지 평가해야 합니다.
+ AWS 설명서: [Amazon EC2 인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
**제안 사항 11.3.2 – AMI 및 코드형 인프라를 사용하여 EC2 인스턴스를 다시 빌드하는 전략을 수립**
코드형 인프라(IaC)의 이점은 전체 환경을 프로그래밍 방식으로 구축하고 폐기할 수 있다는 것입니다. 복원력을 위해 설계된 경우 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 템플릿 또는 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 을 사용하여 몇 분 안에 환경을 구현할 수 있습니다. 자동화는 고가용성과 빠른 복구를 유지하는 데 중요합니다.
전략의 일부로 다음 AWS 서비스를 평가해야 합니다.
+ AWS 서비스: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ AWS 서비스: [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html)
+ AWS 서비스: [AWS Cloud Development Kit](https://aws.amazon.com/cdk/)
+ SAP on AWS 블로그: [SAP용 DevOps](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**제안 사항 11.3.3 – Amazon EBS 장애를 이해**
하나 이상의 EBS 볼륨에 장애가 발생할 경우 SAP 워크로드의 가용성 및 내구성에 영향을 줄 수 있습니다. 따라서 Amazon EBS 장애 비율, 알림 메커니즘 및 복구 옵션을 이해해야 합니다
+ AWS 설명서: [Amazon EBS 내구성](https://aws.amazon.com/ebs/features/#Amazon_EBS_availability_and_durability)
+ AWS 설명서: [볼륨 상태 모니터링](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html)
+ AWS 서비스: [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)
+ AWS 설명서: [Amazon EBS 스냅샷을 사용한 볼륨 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
**제안 사항 11.3.4 – AWS Personal Health Dashboard 알림에 대응하기 위한 전략을 수립**
AWS Personal Health Dashboard의 알림을 수신하고 조치를 취하기 위한 전략이 있어야 합니다. 여기에는 CloudWatch를 사용하여 Amazon SNS를 시작, [AWS Health API](https://docs.aws.amazon.com/health/latest/ug/health-api.html) 를 통한 ITSM 도구 통합 등이 포함될 수 있습니다.
**제안 사항 11.3.5 – 가용성에 영향을 미치는 우발적 또는 악의적 이벤트로부터 보호**
SAP 워크로드의 가용성에 영향을 줄 수 있는 우발적 또는 악의적 이벤트로부터 보호하려면 다음 접근 방식을 고려해야 합니다.
+ 먼저 [최소 권한 원칙](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 을 구현하고 AWS Identity and Access Management 내에서 업무 분장을 적용합니다.
+ AWS 지식 센터 문서: [실수로 인한 EC2 인스턴스 종료로부터 데이터를 보호하려면 어떻게 해야 하나요?의 지침을 따릅니다.](https://aws.amazon.com/premiumsupport/knowledge-center/accidental-termination/)
+ 다음을 따릅니다. [Amazon EC2 모범 사례](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
+ [보안]: [모범 사례 8.3 - 데이터 복구 메커니즘을 위협으로부터 보호의 지침을 따릅니다.](best-practice-8-3.md)
**Suggestion 11.3.6 – AWS에서 SAP 워크로드를 벗어난 종속성을 식별**
공유 서비스 및 지원 구성 요소 또는 시스템을 포함하여 SAP 비즈니스 프로세스의 기본 종속성을 이해합니다. 예를 들면 Active Directory, DNS, 자격 증명 공급자, SaaS 서비스, 온프레미스 시스템이 있습니다. 장애의 영향과 필요한 완화를 평가합니다.
# 모범 사례 11.4 - 주기적으로 복원력 테스트 수행
소프트웨어 및 절차가 예측 가능한 결과를 제공함을 입증하기 위해 중대 장애 시나리오에 대해 주기적으로 복원력을 테스트합니다. 아키텍처, 소프트웨어 또는 지원 담당자에 대한 변경 사항을 평가하여 추가 테스트가 필요한지 여부를 결정합니다.
**제안 사항 11.4.1 – 비즈니스 요구 사항을 기반으로 범위 내 중대 장애 시나리오를 정의**
비즈니스 요구 사항에 맞춰 테스트할 수 있는 중대 장애 시나리오를 정의해야 합니다. 다음은 분석을 안내하는 데 사용할 수 있는 장애 시나리오의 예입니다. 시나리오의 세분 수준 및 적용 범위, 분류, 영향은 요구 사항 및 아키텍처에 따라 달라집니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/best-practice-11-4.html)
**제안 사항 11.4.2 – 중대 장애를 시뮬레이션하기 위한 일련의 테스트 사례를 정의**
SAP 워크로드에 영향을 줄 수 있는 중대 장애 시나리오를 시뮬레이션할 수 있도록 전체 세트의 테스트가 정의되어 있어야 합니다.
일부 장애 시나리오의 경우 시뮬레이션이 발생할 수 있는 실제 장애를 완전히 나타내지 않을 수 있음을 인지해야 합니다. 예를 들어 하드웨어 문제를 시뮬레이션하기 위해 EC2 인스턴스에서 장애를 유발할 수는 없지만 Nitro 기반 인스턴스의 경우 커널 패닉을 생성하여 인스턴스를 재부팅시킬 수 있습니다.
또한 [AWS Fault Injection Simulation](https://aws.amazon.com/fis/) 은 AWS 리소스에서 장애를 시뮬레이션하는 데 도움이 되도록 설계되었습니다.
+ AWS 설명서: [SAP on HANA용 고가용성 구성 가이드](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-ha-configuration.html)
+ AWS 설명서: [진단 인터럽트 전송](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/diagnostic-interrupt.html#diagnostic-interrupt-prereqs)
**제안 사항 11.4.3 – 각 테스트 사례의 예상 동작을 정의**
테스트의 기준으로 사용할 예상 결과 세트를 문서화해야 합니다.
**제안 사항 11.4.4 – 변경의 영향을 평가하기 위한 접근 방식 및 필요한 후속 테스트를 정의**
변경이 환경에 미치는 영향을 평가하기 위한 접근 방식과 변경으로 인해 가용성 및 안정성에 대한 접근 방식이 무효화되지 않는지 확인하기 위해 해당 변경의 일부로 필요한 테스트가 정의되어 있어야 합니다. 이러한 변경 유형의 예로는 소프트웨어 업그레이드, 패치, 파라미터 변경이 있습니다.
**제안 사항 11.4.5 – 테스트 일정을 정의**
초기 구현, 변경 테스트, 주기적 환경 검증을 포함하는 테스트 일정을 수립해야 합니다.
**제안 사항 11.4.6 – 테스트 결과를 검토**
테스트 결과를 기반으로 테스트 사례, 구성 또는 아키텍처가 개선되었는지 식별합니다.
**제안 사항 11.4.7 – 테스트 전 상태로 복귀하는 데 필요한 작업을 정의**
각 테스트의 일부로 테스트 전 상태로 돌아가기 위해 필요한 작업을 정의해야 합니다. 이는 각 테스트 사례가 서로 격리되고 테스트가 프로덕션 시스템의 가용성 및 안정성에 영향을 미치지 않도록 하기 위한 것입니다.
# 모범 사례 11.5 - 장애 대응 자동화
장애 대응을 자동화하여 서비스에 미치는 영향을 최소화할 수 있습니다. 장애, 용량 손상 또는 연결 손실에 대응하도록 자동화를 설계합니다. 오탐을 방지하기 위해 명확한 중재 기준이 정의되어야 합니다.
**제안 사항 11.5.1 – 자동화의 손상 위험을 평가**
데이터 손상의 위험이 있는 구성 요소의 경우 고가용성(HA) 솔루션이 데이터 복제 방법, 스플릿 브레인 방지, 연결 안정성 및 애플리케이션 인식을 고려해야 합니다.
**제안 사항 11.5.2 – 자동화를 시작하는 상태 확인 메커니즘을 평가**
상태 확인은 오탐으로 인해 자동화가 시작되지 않도록 제어하도록 설계해야 합니다.