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

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

리소스에 문제가 있어 보일 때는 판단하기 전에 몇 가지 구체적인 사실이 필요합니다. 지금 어떤 상태인지, 마지막으로 누가 바꿨는지, 플랫폼 자체는 정상이었는지 같은 것입니다. FDAI는 Azure를 읽되 절대 바꾸지 않는, 범위가 고정된 조사 카탈로그로 그 질문에 답합니다.

이 가이드에서는 무엇을 물을 수 있는지, 답에 무엇이 담기는지, 깔끔한 답이 아닌 결과를 어떻게 읽어야 하는지 다룹니다.

구조적으로 읽기 전용입니다: 조사는 근거를 수집합니다. Azure 변경을 승인하거나 실행할 수 없고, 조사가 사용하는 신원은 실행기 신원과 분리돼 있습니다. 이 페이지의 어떤 내용도 스스로 변경으로 이어지지 않습니다.

조사할 수 있는 항목

카탈로그는 고정되어 있고 버전이 관리됩니다. 각 항목은 탐지 에이전트인 Heimdall이 소유하며 읽기 작업으로 선언되므로, 새 조사가 조용히 쓰기를 끼워 넣을 수 없습니다.

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

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

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

결과가 알려 주는 것

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

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

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

답이 깔끔하지 않을 때

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

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

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

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

조사를 시작하는 방법

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

POST /read-investigations

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

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

이 조사가 하지 않는 것

연결 가능성을 증명하지 않습니다. 보안 그룹 규칙과 피어링 상태는 무엇이 구성돼 있는지 알려 줍니다. 트래픽이 실제로 흐르는지 확인하려면 유효 규칙과 경로 확인 같은 별도의 근거가 더 필요합니다.
진단하지 않습니다. 조사는 사실을 돌려줍니다. 사실을 원인으로 바꾸는 일은 근본 원인 분석이며, 이 근거를 바탕으로 추론하되 지시가 아니라 인용된 가설로 남습니다.
스스로 범위를 넓히지 않습니다. 더 넓은 리소스 탐색, 프로바이더 프로파일, 생성된 명령 설명은 아직 사용할 수 있는 기능이 아니라 설계 단계의 작업입니다.

다음 단계

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