관찰 가능성 및 모니터링 - 패턴 | 패턴 |

관찰 가능성 및 모니터링 - 패턴

잘 설계된 운영 우수성 → 관찰성 및 모니터링에 대해 자세히 알아보기

패턴

찾을 위치	유사성
플랫폼 \| 이벤트 모니터링	✅ 이벤트 모니터링은 비동기 처리 체인 및 외부 통합을 통해 요청을 추적하는 상관 관계 ID를 수집하는 초기 아키텍처로 설계되었습니다.
플랫폼 \| 이벤트 모니터링	✅ 관찰 가능성 인프라는 프로덕션 사고를 진단할 수 없게 되면 보완되지 않고 초기 스프린트에서 포함됩니다.
플랫폼 \| 통합	✅ 통합 검사점이 의도적으로 배치되어 시스템 경계 전반에서 요청 추적 가능
플랫폼 \| 플랫폼 이벤트	✅ 플랫폼 이벤트 페이로드는 트랜잭션 마커 및 컨텍스트를 사용하여 운영 가시성을 위해 구조화되어 있습니다.
플랫폼 \| 사용자 정의 로깅	✅ 사용자 정의 로깅 프레임워크는 사용자 ID, 타임스탬프, 기간, 결과를 포함한 전체 컨텍스트 정보가 포함된 개별 이벤트를 캡처합니다.
플랫폼 \| 메트릭	✅ 메트릭은 API 소비율, Apex CPU 시간 분포, 배치 작업 성공률 등 시간 경과에 따른 숫자 측정을 집계합니다.
플랫폼 \| 배포된 추적	✅ 추적은 동기식 API 호출을 비동기식 처리 체인, 플랫폼 이벤트를 구독자 실행, 외부 시스템 응답에 통합 요청을 연결합니다.
플랫폼 \| 관찰 가능	✅ 관찰 기능을 사용하면 연산자가 각 조사에 대해 새 지표를 배포하지 않고도 시스템 동작에 대한 임의의의 질문에 답변할 수 있습니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 이벤트 모니터링	⚡️ 솔루션이 사용자 정의 로깅 없이 실행되며, 플랫폼 로그만으로 프로덕션 사고를 진단할 수 없게 되면 6개월 후 주요 리팩터링이 필요합니다.
플랫폼 \| 이벤트 모니터링	⚡️ 관찰성은 대부분의 구성 요소에 영향을 미치고 운영 개선 작업 중 버그가 발생할 수 있는 장비 변경이 필요한 기존 솔루션으로 세분화되었습니다.
플랫폼 \| 통합	⚡️ 통합 실패가 발생하지만 포괄적인 텔레메트리 없이 시스템 경계 전체에서 요청 경로를 추적할 수 없습니다.
플랫폼 \| 플랫폼 이벤트	⚡️ 플랫폼 이벤트 페이로드의 운영 컨텍스트가 부족하여 사고 조사가 다중 시스템 검색에 따라 달라집니다.
플랫폼 \| 사용자 정의 로깅	⚡️ 로그는 충분하지 않은 컨텍스트를 수집합니다. 추가 정보를 수집하기 위해 조사 시 문제를 재현해야 합니다.
플랫폼 \| 관찰 가능	⚡️ 사전 정의된 대시보드는 프로덕션에서 발생하는 시스템 동작에 대한 예기치 않은 질문에 답변할 수 없습니다.

패턴

찾을 위치	유사성
플랫폼 \| 이벤트 모니터링	✅ 이벤트 모니터링은 API 사용, 로그인 활동, Apex 실행, SOQL 쿼리, Visualforce 페이지, Lightning 페이지 및 보고서 실행을 캡처하는 프로덕션 환경에 대해 활성화됩니다.
플랫폼 \| 이벤트 모니터링	✅ 이벤트 로그 파일은 매시간 중앙 집중형 로그 플랫폼으로 내역 분석을 수행하여 네이티브 플랫폼 보존을 넘어 내역 분석을 수행할 수 있습니다.
플랫폼 \| 이벤트 모니터링	✅ 외부 로그 집계를 사용하여 종단간 트랜잭션 추적을 위해 다른 시스템의 엔터프라이즈 Telemetry와 상관 관계 유지
플랫폼 \| 이벤트 모니터링	✅ 규정 준수 보고 및 장기 추세 분석을 위한 규정 요구 사항과 일치하는 이벤트 로그 파일 보존
플랫폼 \| Proactive Monitoring	✅ Proactive Monitoring 임계값은 기본값을 수락하는 대신 조직별 정상 작업 범위를 기반으로 의도적으로 조정됩니다.
플랫폼 \| Proactive Monitoring	✅ Proactive Monitoring 경고는 사용자가 볼 수 있는 사고 이전에 API 제한 스파이크, 동시 Apex 실패, SOQL 행 제한 접근 방식 및 행 잠금 충돌을 감지합니다.
플랫폼 \| Proactive Monitoring	✅ 조정된 임계값은 팀이 Trust 실행 가능한 신호를 생성하고 지속적인 개선의 유용한 주기를 만들기 위해 조치를 취합니다.
플랫폼 \| 스케일 센터	✅ 솔루션 안정화 시 확장 센터 기준선이 설정되고 각 주 릴리스 후 다시 검토됩니다.
플랫폼 \| 스케일 센터	✅ 스케일 센터는 가장 많은 자원을 소비하는 작업, 시간 초과 임계값에 도달한 트랜잭션, 최적화 투자에 가장 큰 영향을 미치는 위치를 보여줍니다.
플랫폼 \| 스케일 센터	✅ 최신 배포에 도입된 의도하지 않은 N+1 쿼리 패턴을 드러내는 기준 프롬프트 조사의 트랜잭션 시간 증가
플랫폼 \| 설정 감사 내역	✅ 설정 감사 내역은 권한 수정, 메타데이터 배포, 보안 설정 업데이트를 비롯한 구성 변경 사항을 최대 180일 동안 추적합니다.
플랫폼 \| 설정 감사 내역	✅ 규정 준수 또는 계약 요구 사항에 따라 내역 기간이 더 긴 경우 설정 감사 내역 항목이 보존되도록 내보내어 180일 이상 유지됩니다.
플랫폼 \| Shield	✅ 필드 감사 내역은 중요한 데이터, 변경 내역이 필요한 규제된 데이터 또는 중요 비즈니스 데이터가 포함된 필드에 대해 선택적으로 활성화됩니다.
플랫폼 \| Shield	✅ 필드 감사 내역은 내역 값을 이해하여 운영 및 규정 준수 보고에 도움이 되는 필드에 대해 최대 10년 동안 보존할 수 있습니다.
플랫폼 \| 상태 확인	✅ 상태 확인 검토는 분기별로 예약되며, 결과는 환경에 대한 위험 우선 순위 지정을 기반으로 수정됩니다.
플랫폼 \| 상태 확인	✅ 상태 확인 결과는 패시브 수락 대신 의도적으로 검토되며, 보상 제어 또는 다른 위험 허용이 문서화됩니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 이벤트 모니터링	⚡️ 이벤트 모니터링이 활성화되어 있지만 로그는 내보내지 않으므로 설문 조사가 네이티브 보존 기간으로 제한되고 내역 추세 분석이 방지됩니다.
플랫폼 \| 이벤트 모니터링	⚡️ 이벤트 로그 파일은 플랫폼 저장소에 유지되며, 외부 집계가 구현되지 않아 장기 수용력 계획이 차단됩니다.
플랫폼 \| Proactive Monitoring	⚡️ Proactive Monitoring 지나치게 민감하거나 너무 느슨한 기본 임계값을 사용하여 팀이 무시하는 것을 배우는 시끄러운 경고를 생성합니다.
플랫폼 \| Proactive Monitoring	⚡️ 경고 소음으로 인해 모니터링 시스템의 Trust 손상되고 팀이 유효한 신호에 응답하지 않습니다.
플랫폼 \| 스케일 센터	⚡️ 스케일 센터가 활성화되었지만 사전에 검토되지 않았습니다. 수개월 동안 증분 저하가 발생한 후 사용자가 불만을 제기할 때까지 성능이 느리게 저하됩니다.
플랫폼 \| 스케일 센터	⚡️ 성과 메트릭에 기준선 컨텍스트가 없으며 3초 트랜잭션 시간이 일반적인지, 개선되는지 또는 저하되는지 여부는 명확하지 않습니다.
플랫폼 \| 설정 감사 내역	⚡️ 설정 감사 내역은 내보내지 않습니다. 보존 제한으로 인해 보안 조사 또는 180일 이상의 규정 준수 확인이 차단됩니다.
플랫폼 \| Shield	⚡️ 필드 감사 내역이 모든 필드에 대해 선택적으로 활성화되어 있으며 해당하는 규정 준수 값 없이 저장소 비용이 발생합니다.
플랫폼 \| 상태 확인	⚡️ 상태 확인 결과는 검토되지 않으며, 보안 구성은 의도한 수락 없이 기준선 권장 사항에서 드리프트됩니다.

패턴

찾을 위치	유사성
플랫폼 \| 사용자 플로	✅ 중요 사용자 플로는 비즈니스 영향을 기반으로 정의되며 성공률, 완료 시간, 중단 지점, 오류 비율에 대한 전체 모니터링
플랫폼 \| 사용자 플로	✅ 중요 플로는 수익 창출 활동(주문 제출, 계약 실행, 기회 마감), 대량 활동(로그인, 검색, 레코드 생성), 규정 준수 요구 활동(동의 수집, 데이터 주체 권한 이행)이 포함됩니다.
플랫폼 \| 사용자 플로	✅ 플로에 각 중요 단계에서 시작, 완료, 중단, 실패를 나타내는 트랜잭션 마커가 표시됩니다.
플랫폼 \| 사용자 플로	✅ 각 단계의 플랫폼 이벤트(장바구니 검증, 재고 점검, 지불 처리, 이행 트리거)로 설명된 주문 제출 흐름
플랫폼 \| 사용자 플로	✅ 플로 수준 모니터링은 모든 전환 지점에서 실패가 발생할 수 있으므로 구성 요소 수준 모니터링에서 표시되지 않는 문제를 표시합니다.
플랫폼 \| 사용자 플로	✅ 플로 성공률이 허용되는 임계값 미만이거나 기간이 대기 시간 대상을 초과하면 경고가 실행됩니다.
플랫폼 \| 통합	✅ 통합 상태 모니터링은 사용자 대면 오류로 계단화하기 전에 외부 시스템 오류, 네트워크 문제, 인증 문제, 속도 제한 접근 방식을 감지합니다.
플랫폼 \| 통합	✅ 중요 동기 통합의 성공률 모니터링 경고가 99% 미만일 경우
플랫폼 \| 통합	✅ 기준선에 없는 새 오류 유형이 나타나면 오류 배포 모니터링 경고
플랫폼 \| 통합	✅ 동기식 사용자 연결 통화의 경우 3초를 초과할 경우 대기 시간 백분위수 모니터링(p95) 경고
플랫폼 \| 통합	✅ 알려진 속도 제한 또는 SLA 임계값의 80%를 초과할 경우 처리량 모니터링 경고
플랫폼 \| 통합	✅ 외부 시스템 저하를 나타내는 회로가 열리면 차단기 상태 모니터링 경고
플랫폼 \| 통합	✅ 지속적인 재시도 비율이 신뢰성 문제를 나타내는 5%를 초과할 경우 재시도 비율 모니터링 경고
플랫폼 \| 통합	✅ 통합 Telemetry는 중앙 집중식 모니터링 플랫폼으로 라우팅하여 시스템 경계 전반의 상관 관계를 활성화합니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 사용자 플로	⚡️ 구성 요소가 독립적으로 모니터링되어 정상적인 작동을 표시하며 12%의 사용자가 중요한 플로를 중단하고 그 이유를 파악할 수 없습니다.
플랫폼 \| 사용자 플로	⚡️ 구성 요소 상태 대시보드에 녹색 표시가 표시되고 사용자가 모니터링 아키텍처 실패를 보여주는 중요 워크플로를 완료할 수 없습니다.
플랫폼 \| 사용자 플로	⚡️ 여러 Apex 클래스, 플로, 플랫폼 이벤트 및 외부 통합에 영향을 미치는 사용자 여정
플랫폼 \| 사용자 플로	⚡️ 중요한 비즈니스 여정에는 도구가 부족하며 성공률 및 중단점은 알 수 없음
플랫폼 \| 통합	⚡️ 통합 실패는 사전 예방적이지 않고 사용자 대면 실패로 계단식으로 이동한 후에만 감지됩니다.
플랫폼 \| 통합	⚡️ 통합 Telemetry는 개별 시스템에서 격리된 상태로 유지되어 경계 전반에 걸친 상관 관계 및 근본 원인 분석을 방지합니다.
플랫폼 \| 통합	⚡️ 조기에 근본 원인을 밝히는 대신 손상 후 다운스트림 증상에 대한 경고 모니터링

패턴

찾을 위치	유사성
플랫폼 \| SLI	✅ 가용성 SLI는 사용자 관점에서 중요 플로가 성공적으로 실행되는 시간 비율을 측정합니다(200 상태 코드뿐만 아니라 예상 결과 수신)
플랫폼 \| SLI	✅ 대기 시간 SLI는 p50(중앙값), p90( 이상값을 제외한 90번째 백분위수), p95(최악 이상값을 제외한 95번째 백분위수), p99(최악 예를 표시하는 99번째 백분위수)에서 작업을 완료하는 시간을 측정합니다.
플랫폼 \| SLI	✅ 대기 시간 목표는 작업 중요도 및 사용자 기대에 따라 다릅니다(500ms 검색은 즉각적이고 입력에 대한 동일한 대기 시간이 느려짐)
플랫폼 \| SLI	✅ 처리량 SLI는 수용력 활용도 및 성장 추세를 보여주는 시간 단위당 성공한 작업량을 측정합니다.
플랫폼 \| SLI	✅ 대기 시간과 결합된 처리량은 로드 증가 시 시스템 성능 유지 여부 또는 볼륨 증가에 따라 성능 저하 여부를 보여줍니다.
플랫폼 \| SLI	✅ 오류율 SLI는 오류 유형을 구분합니다(확인 실패와 같은 사용자 오류와 총괄자 제한 예외와 같은 시스템 오류).
플랫폼 \| SLO	✅ 아키텍처 패턴을 선택하기 전에 비즈니스 요구 사항을 기반으로 허용 가능한 SLI 임계값을 정의하는 서비스 수준 목표 설정
플랫폼 \| SLO	✅ 비즈니스 요구 사항 “세일즈 담당자가 5초 이내에 기회 업데이트를 확인해야 함”은 아키텍처 결정을 유도하는 SLO “P95에서 3초 이내에 기회 세부 사항 페이지 로드 완료”를 구동합니다.
플랫폼 \| SLO	✅ SLO는 현재 시스템에서 달성한 사항을 기반으로 정의되지 않고 비즈니스 요구 사항에서 도출되고 아키텍처 결정을 촉진합니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| SLI	⚡️ 가용성은 기술적 관점(사용자 관점이 아닌 상태 코드 200개)에서 측정됩니다(예상 결과 수신).
플랫폼 \| SLI	⚡️ 대기 시간은 p95 또는 p99 백분율에서 최악의 사용자 환경을 이해하지 않고 중간값에서만 측정됩니다.
플랫폼 \| SLI	⚡️ 오류율 SLI는 사용자 오류와 시스템 오류를 구분하지 않으므로 다른 솔루션이 필요한 다른 문제를 마스킹합니다.
플랫폼 \| SLO	아키텍처가 먼저 구축된 다음, SLO는 시스템 설계에서 사용자 요구 사항을 고려하지 않았으므로 12초 페이지 로드를 수락하는 “현재 달성한 내용”으로 정의됩니다.
플랫폼 \| SLO	⚡️ SLO는 비즈니스 중심이 아닌 아키텍처 중심이며, 사용자가 필요로 하는 항목이 아닌 시스템 성과를 기반으로 목표를 설정합니다.

패턴

찾을 위치	유사성
플랫폼 \| 경고	✅ 심각도 분류는 중요한 사고(프로덕션을 사용할 수 없음, 데이터 손상 위험, 보안 저하)를 호출형 엔지니어에게 즉시 라우팅합니다.
플랫폼 \| 경고	✅ 심각도가 높은 사고(성능 저하, 부분 중단)는 업무 시간 내에 신속한 조사를 위해 알림을 생성합니다.
플랫폼 \| 경고	✅ 경고(임계값 대비, 구성 드리프트)는 사전 예방적 조치를 위해 일일 요약 알림을 생성합니다.
플랫폼 \| 경고	✅ 경고 컨텍스트에는 영향을 받는 사용자 수, 오류 메시지, 스택 추적, 최근 배포, 관련 경고, 관련 대시보드 링크가 포함됩니다.
플랫폼 \| 경고	✅ 서식 있는 컨텍스트로 기본 정보를 수집하지 않고 즉시 심각도 평가 및 조사를 활성화하여 평균 확인 시간을 단축합니다.
플랫폼 \| 경고	✅ 경고 그룹화는 단일 기본 문제에 대해 수백 개의 관련 경고가 실행되는 경고 폭풍을 방지합니다.
플랫폼 \| 경고	✅ 통합 실패는 대기 시간 그래프, 오류 분포, 대시보드 링크가 포함된 지난 5분 동안 156개의 실패한 요청을 표시하는 통합 끝점별로 그룹화된 경고 한 개를 트리거합니다.
플랫폼 \| 경고	✅ 경고 일시 중지 - 예상되는 서비스 점검 기간 또는 자동 수정 기간 동안 알려진 전달 상태가 경고를 생성하지 못하도록 방지
플랫폼 \| 경고	✅ 예약된 서비스 점검 중, 캐시가 뜨거운 상태에서 배포 후 처음 몇 분 동안, 재시도 논리가 성공한 짧은 임시 실패 시 알림이 억제됩니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 경고	⚡️ 모든 경고는 심각도 분류 없이 동일한 채널로 라우팅되며, 중요한 사고는 정기적인 경고와 구분되지 않습니다.
플랫폼 \| 경고	⚡️ 경고는 진단 컨텍스트가 없으며, 온콜 엔지니어는 심각도를 평가하기 전에 별도의 쿼리를 통해 기본 정보를 수집해야 합니다.
플랫폼 \| 경고	⚡️ 통합 실패로 5분 만에 156개의 개별 경고가 생성되어 통화 시 엔지니어의 전화가 압도되고 각 경고는 타임스탬프를 제외하고 동일합니다.
플랫폼 \| 경고	⚡️ 경고 폭풍으로 인해 응답자가 수백 개의 관련 증상과 단일 기본적인 문제를 구별할 수 없습니다.
플랫폼 \| 경고	⚡️ 알려진 서비스 점검 기간 동안 발생하는 경고 및 임시 조건으로 인해 모니터링에 대한 Trust 해소하는 소음 발생
플랫폼 \| 경고	⚡️ 음소거한 거짓 양성으로 인해 경고 피로로 인해 팀이 알림을 무시하여 응답 효과가 저하됩니다.