Azure 리소스 조사하기(Investigate an Azure resource)

리소스에 문제가 있는 것으로 보이면 판단을 내리기 전에 몇 가지 사실을 확인해야 합니다. 리소스의 현재 상태, 마지막 변경자, 플랫폼 자체의 정상 작동 여부 등입니다. FDAI는 범위가 제한된 고정 조사 카탈로그를 사용하여 이러한 질문에 답합니다. 모든 조사는 Azure에서 정보를 읽기만 하며 리소스를 변경하지 않습니다.

이 가이드에서는 조사할 수 있는 항목, 조사 결과에 포함되는 정보, 명확한 답변이 아닌 결과가 반환되었을 때 이를 해석하는 방법을 설명합니다.

설계상 읽기 전용: 조사는 근거를 수집하는 작업입니다. Azure 변경을 승인하거나 실행할 수 없으며, 조사에 사용하는 ID는 변경 실행에 사용하는 ID와 분리되어 있습니다. 이 페이지에서 설명하는 어떤 작업도 자체적으로 변경을 일으킬 수 없습니다.

조사할 수 있는 항목

조사 카탈로그는 고정되어 있으며 버전이 관리됩니다. 각 항목은 탐지 에이전트인 Heimdall이 소유하고 읽기 작업으로 선언됩니다. 따라서 새로운 조사를 추가하더라도 쓰기 작업이 암묵적으로 포함될 수 없습니다.

조사	답하는 질문
리소스 상태	이 리소스는 지금 어떤 상태인가요? 예를 들어 VM이 실행 중인가요?
변경 주체 확인	이 컨트롤 플레인 변경을 누가 또는 무엇이 수행했나요?
리소스 변경 이력	최근 이 리소스에 어떤 작업이 실행됐나요?
플랫폼 상태	이 리소스에 대해 Azure 자체는 정상이었나요, 아니면 플랫폼이 원인이었나요?
게스트 종료	게스트 로그에 운영체제 종료 흔적이 있나요?
네트워크 보안	어떤 보안 그룹 규칙과 연결이 적용되며 무엇이 열려 있나요?
네트워크 피어링	피어링 토폴로지는 어떻게 되고 동기화 상태인가요?

각 항목은 버전이 지정된 하나의 쿼리 계획에 연결됩니다. 그래서 같은 질문을 두 번 하면 모델이 그때그때 만들어 낸 쿼리가 아니라 같은 제한된 쿼리가 실행됩니다.

예시: 02:14에 VM이 응답하지 않습니다. 리소스 상태로 할당 해제 여부를 확인하고, 변경 주체 확인으로 사람이 했는지 자동화가 했는지 보고, 플랫폼 상태로 Azure 쪽 이벤트를 배제합니다.

결과가 알려 주는 것

조사는 결론이 아니라 근거를 돌려줍니다. 모든 결과에는 그 근거를 얼마나 신뢰할지 판단하는 데 필요한 맥락이 함께 담깁니다.

상태. 실제 답인지 확인 불가인지 구분할 수 있습니다.
대상 리소스. 정확한 참조로 해석된 대상입니다.
관측 시각과 최신성 표시.
잘림 여부와 그 이유. 일부 목록이 완전한 목록처럼 읽히지 않게 합니다.
근거 참조. 감사 기록까지 따라갈 수 있습니다.
제약 사항. 원본이 완전히 답하지 못한 경우에 표시됩니다.

내용에 따라 움직이기 전에 관측 시각을 먼저 읽으세요. 5분 전 상황에 대한 정확한 답도 결국 5분 전 상황에 대한 답입니다.

답이 깔끔하지 않을 때

세 가지 결과는 정상 경로보다 더 중요합니다. 각각 여러분이 내릴 수 있는 결론의 범위를 바꾸기 때문입니다.

결과	무슨 일이 있었나	무엇을 해야 하나
모호함	입력한 이름이 여러 리소스와 일치합니다	함께 돌아온 후보 목록에서 고른 뒤 다시 물어보세요
확인 불가	프로바이더 호출이 실패했거나 제한(throttling)됐습니다	그 사실을 알 수 없음으로 두고, 정상으로 읽지 마세요
잘림	결과가 상한에 도달했습니다	결론을 내리기 전에 기간이나 범위를 좁히세요

모호한 경우 일부러 일찍 멈춥니다. 어느 app-db를 말한 것인지 추측해서 엉뚱한 대상에 이력 쿼리를 돌리는 대신, FDAI는 후보를 돌려주고 기다립니다.

확인 불가가 무엇을 뜻하는지 꼭 기억하세요. 실패한 상태 조회는 정상이라는 근거가 아닙니다. FDAI는 원본을 확인 불가로 표시하고 프로바이더 오류 원문 없이 제약 사항만 기록하므로, 관측 도구 장애가 정상 동작 중인 워크로드로 요약되는 일은 생기지 않습니다.

조사를 시작하는 방법

조사는 Operator API로 실행합니다.

POST /read-investigations

이 경로는 배포 환경에서 조사를 구성한 경우에만 등록됩니다. 조사를 시작하려면 기여자 이상의 역할이 필요합니다. 읽기 담당은 결과를 볼 수 있지만 조사를 시작할 수는 없습니다. 실제 구독에 대한 읽기라도 누가 했는지 남길 가치가 있기 때문입니다.

같은 카탈로그를 대화로도 사용할 수 있습니다. 챗으로 물으면 같은 제한된 계획으로 라우팅되고 같은 근거를 돌려주므로, 대화 경로가 API보다 Azure를 더 넓게 볼 일은 없습니다.

이 조사가 하지 않는 것

연결 가능성을 증명하지 않습니다. 보안 그룹 규칙과 피어링 상태는 무엇이 구성돼 있는지 알려 줍니다. 트래픽이 실제로 흐르는지 확인하려면 유효 규칙과 경로 확인 같은 별도의 근거가 더 필요합니다.
진단하지 않습니다. 조사는 사실을 돌려줍니다. 사실에서 원인 가설을 도출하는 일은 근본 원인 분석이 맡습니다. 이 근거를 바탕으로 추론한 결과도 실행 지시가 아니라 출처를 인용한 가설로 남습니다.
스스로 범위를 넓히지 않습니다. 검토된 ResourceContainers 및 Resources 프로바이더 프로파일과 생성된 명령 설명은 사용할 수 있습니다. 그러나 검토되지 않은 테이블, 열, 조인, 더 넓은 프로바이더 범위는 쿼리를 만들어 내지 않고 거부합니다.

다음 단계

학습 대상	문서
조사가 인시던트 작업에 들어맞는 방식	분류와 조사
근거가 인용된 원인이 되는 과정	근본 원인 분석
발견된 문제가 처음 전달되는 방식	관측성, 감지, 예측
조사를 근거 기록에서 추적하는 방법	감사 로그 읽기
조사 계약과 쿼리 계획 전체	Azure 읽기 조사