사이트 신뢰성 엔지니어링

사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)은 FDAI의 세 초기 버티컬을 연결하는 운영 discipline입니다. 변경 안전성은 변경 리스크를 낮추고, 비용 거버넌스는 효율성을 관리하며, 복원력은 복구 가능성을 증명합니다. SRE는 이 기능들을 관찰, 대응, 학습, 대비로 이어지는 하나의 증거 기반 라이프사이클로 묶습니다.

이 섹션은 운영자를 위한 지도입니다. FDAI가 구현한 기능, 사람 승인이 필요한 지점, 배포 환경이나 다운스트림 포크가 제공해야 하는 통합을 설명합니다.

무엇을 할 수 있나요?

신호 폭풍을 하나의 인시던트로 정리

관련 리소스 이벤트, 관측 데이터에서 나온 탐지 결과, 변경을 안정적인 구성원 목록과 명확한 시간 순서를 가진 하나의 인시던트로 묶습니다.

예시: 다섯 개의 알림이 동일한 배포 및 리소스 키를 공유 -> 이벤트 상관관계가 인시던트 하나를 생성 -> 운영자는 다섯 페이지가 아니라 하나의 타임라인을 분류합니다.

변경을 제안하기 전에 조사

범위가 제한된 증거를 수집하고, 근거가 있는 근본 원인 가설을 생성하며, 모든 완화 제안을 trust-router, 안전성 검토, 승인 정책 뒤에 둡니다.

예시: 오류율 알림 -> 조사가 최근 배포를 연결 -> 근본 원인 분석이 변경과 관측 데이터를 인용 -> 대응 계획이 롤백을 제안 -> 사람 승인이 이 제안을 작업 파이프라인에 다시 넣을지 결정.

실패를 숨기지 않고 학습

추가 전용 감사 이력, 포스트모템 초안, 관찰 모드 결과, 롤백 근거를 사용해 룰과 런북을 개선합니다. 학습 구성 요소가 정책을 직접 바꾸도록 두지는 않습니다.

예시: 해결된 인시던트 -> 포스트모템이 타임라인과 액션 결과를 추출 -> 출처 이력이 있는 카탈로그 후보 제안 -> 일반 검토 및 승격 게이트를 그대로 통과.

연동 대상

Azure 신호: Activity Log 이벤트, 리소스 인벤토리, 배포 이력, 서비스 메트릭이 프로바이더 어댑터를 통해 들어옵니다.
관측 시스템: 메트릭, 로그, 트레이스 프로바이더는 근거를 공급할 뿐 두 번째 실행 경로가 되지 않습니다.
Git과 ChatOps: 수정 pull 요청이 변경을 전달하고, Teams나 Slack이 승인과 운영 알림을 전달합니다.
감사와 보고: 모든 최종 결과는 추가 전용 감사 기록과 상관관계 참조로 다시 재구성할 수 있습니다.

작동 방식

관찰하고 묶습니다. 이벤트와 발견된 문제를 정규화하고 중복을 제거한 뒤, 관련된 것들을 하나의 인시던트로 묶습니다.
조사하고 대응합니다. 범위가 제한된 근거 묶음을 만들고 그 근거에 기반한 근본 원인 분석을 도출한 다음, 모든 완화 제안을 관리되는 작업 파이프라인으로 보냅니다.
복구하고 학습합니다. 복구를 확인하고 최종 감사 기록을 남기며 포스트모템을 작성한 뒤 근거에 기반한 개선 후보를 제안합니다.

signals -> finding -> incident -> investigation -> RCA
        -> response plan -> risk gate -> action or approval
        -> recovery evidence -> postmortem -> improvement candidate

모든 대응을 제어하는 두 가지 판단

신뢰 라우팅과 실행 정책은 서로 다른 질문에 답합니다. 트러스트 라우터는 판단 후보를 만들 수준으로 T0(결정론 룰), T1(검증된 재사용), T2(근거 기반 추론) 중 하나를 고릅니다. 안전성 검토는 정책, 작업 유형, 영향 범위, 환경, 근거 최신성, 자격 증명, 승격 상태를 모두 보고 가장 엄격한 허용 결과를 계산합니다.

판단	질문	가능한 결과
신뢰 라우팅	어떤 티어가 설명하거나 제안할 수 있는가?	T0, T1, T2 또는 검토 보류
위험 검토	이 제안이 지금 무엇을 할 수 있는가?	`auto`, `hil`, `deny` 또는 관찰 전용
실행	실행 시점 안전 검사가 여전히 유효한가?	한 번 적용, 미실행, 중지 또는 롤백

T0 일치가 변경 권한을 자동으로 주지 않고, T2 제안이 스스로 권한을 만들 수도 없습니다. 실행 가능한 모든 작업에는 여전히 사전 검증, 중단 조건, 롤백 경로, 영향 범위 제한, 최신 인벤토리, 리소스별 잠금, 멱등성 키, 권한 있는 자격 증명, 감사 기록이 필요합니다.

성능 저하도 명시적인 상태입니다

FDAI는 근거가 없다고 해서 정상이라고 보지 않습니다. 프로바이더 장애는 그에 의존하는 근거를 사용 불가로 표시합니다. 오래된 인벤토리, 감사 기록 실패, 잠금 획득 실패, 검증되지 않은 롤백 경로는 영향을 받는 작업을 관찰 모드나 거부로 낮춥니다. 알림 실패는 지속적으로 재시도하거나 에스컬레이션합니다. 알림 실패가 승인이 되는 일은 없고, 이미 유효했던 인시던트 상태 전환을 되돌리지도 않습니다.

SRE 기능 지도

영역	문서	상위 프로젝트 상태
관측성, 상관관계, 이상 감지, 예측	관측성, 감지, 예측	지원됩니다. 실제 관측 어댑터는 배포 환경에서 연결합니다.
워크로드 목표와 예산 소진 속도	SLO와 오류 예산	실제 지표 프로바이더와 예약 실행이 연결될 때까지는 부분 지원입니다.
용량과 성능	용량과 성능	지원됩니다. 자율 작업은 여전히 승격 기준을 따릅니다.
인시던트 생애주기	인시던트 관리	지원됩니다.
범위를 정한 근거 수집	분류와 조사	지원됩니다. 근거의 깊이는 프로바이더에 따라 달라집니다.
근본 원인 가설	근본 원인 분석	지원됩니다. T2는 설정된 모델과 지식 연결에 좌우됩니다.
대응 계획과 완화	대응 계획과 완화	지원됩니다. 계획은 제안하고 전달할 뿐 승인을 우회하지 않습니다.
온콜과 에스컬레이션	온콜과 에스컬레이션	페이징 어댑터와 개인 메시지 지정이 연결될 때까지는 부분 지원입니다.
인시던트 이후 학습	포스트모템과 학습	지원됩니다.
성과 측정	SRE 성과 측정	기준선과 적용군 측정 기간이 있으면 지원됩니다.
시나리오 근거	시나리오 검증 인벤토리	데모 18개, 실제 적용 모드 10개, 고정 재생 9개, 카탈로그 시나리오 132개
재해 복구	재해 복구와 훈련	제공되는 훈련과 어댑터 범위에서 지원됩니다.
카오스 엔지니어링	카오스 엔지니어링	지원됩니다. 모든 시나리오는 관찰 모드에서 시작합니다.

상태 페이지 공지와 DORA 배포 지표는 아직 미구현입니다. 프로바이더와 데이터 계약을 구현하기 전까지는 사용 가능한 SRE 기능으로 소개하지 않습니다.

환경과 함께 확장

Day 1: 관찰 모드로 신호를 수집하고 인시던트 묶음을 확인하며 변경 없이 근거를 검토합니다.
주 1: 워크로드 메트릭을 연결하고 초기 SLO를 정의하며 온콜 라우팅을 연결하고, 대응 계획을 합성 또는 과거 사례에 대해 사전 테스트합니다.
월 1: 측정된 저위험 액션을 개별 승격하고 복구 훈련을 예약하며, 포스트모템 증거를 사용해 규칙과 런북을 개선합니다.

시작하기

관측성, 감지, 예측부터 시작하세요.
인시던트 관리에서 이벤트의 흐름을 따라가세요.
근본 원인 분석이 근거에 기반한 상태를 유지하는 방법을 확인하세요.
모든 시나리오 검증 집합을 검토하세요.
SRE 런북 세트로 운영자 절차를 준비하세요.

다음 단계

학습 대상	문서
FDAI가 T0, T1, T2를 선택하는 방법	신뢰 티어
에이전트가 액션 안전성 계약을 적용하는 방법	에이전트 기반 자동화
복구가 제품 기능이 되는 방법	회복탄력성
증거 추적을 검사하는 방법	감사 로그 읽기
승인 요청에 응답이 없을 때의 동작	에스컬레이션과 상시 권한