· Interview  · 10 min read

SRE & Observability 면접 질문 20선 — SLO/SLI부터 장애 대응까지

SRE 엔지니어 면접 핵심 질문. SLO/SLI/SLA 설계, Prometheus/Grafana 운영, 로그 수집, 장애 대응 프로세스, On-call 문화까지 실무 답변.

SRE 엔지니어 면접 핵심 질문. SLO/SLI/SLA 설계, Prometheus/Grafana 운영, 로그 수집, 장애 대응 프로세스, On-call 문화까지 실무 답변.

SRE 기초

1. SRE란 무엇이고, 기존 운영(Ops)과 차이는?

SRE(Site Reliability Engineering) 는 소프트웨어 엔지니어링 관점으로 운영 문제를 해결하는 방법론입니다.

구분전통적 OpsSRE
목표안정성 최우선안정성과 속도의 균형
변경 관리변경 최소화에러 버짓 내 적극적 변경
반복 작업수동 처리자동화 (Toil 제거)
장애 문화책임 추궁Blameless Postmortem

2. SLO, SLI, SLA의 차이를 설명해주세요.

  • SLI (Service Level Indicator): 측정 가능한 서비스 품질 지표

    • 예: 요청 성공률, P99 응답시간, 가용시간 비율

  • SLO (Service Level Objective): SLI의 목표값

    • 예: 성공률 99.9%, P99 < 500ms

  • SLA (Service Level Agreement): 고객과의 계약. SLO 미달 시 보상 조건 포함.

    • 예: 가용성 99.9% 미달 시 크레딧 제공

3. Error Budget이란?

SLO가 99.9%라면, 허용되는 오류 비율은 0.1%입니다. 이것이 Error Budget입니다.

  • 월간 43,200분 × 0.1% = 43.2분의 다운타임 허용
  • Error Budget이 남아있으면 → 새 기능 배포 가능
  • Error Budget 소진 → 안정성 작업에 집중, 배포 동결

4. Toil이란 무엇이고, 어떻게 줄이나요?

Toil: 수동적, 반복적, 자동화 가능한, 전술적, 가치 없는 운영 작업

줄이는 방법:

  • 반복 작업 스크립트/자동화
  • Self-healing 시스템 구축
  • Runbook 자동화
  • Platform Engineering (내부 도구 개발)

Google SRE 권장: 엔지니어 시간의 50% 이상은 엔지니어링 작업에 할애

SLO/SLI 설계

5. Critical API 선정 기준은?

  1. 비즈니스 영향도: 매출에 직접 영향을 주는 API
  2. 사용자 경험: 사용자가 직접 체감하는 API
  3. 의존성: 다른 서비스가 의존하는 API
  4. 트래픽 볼륨: 호출 빈도가 높은 API

예시: 로그인, 결제, 상품 조회, 검색 API

6. SLI 계산 방법과 구현 경험은?

SLI = (성공한 요청 수) / (전체 요청 수) × 100

가용성 SLI = 1 - (5xx 응답 수 / 전체 응답 수)
지연시간 SLI = P99 응답시간 < 임계치인 요청 비율

구현:

  • CloudWatch Application Signals에서 자동 계측
  • Lambda로 SLI를 주기적으로 계산하여 대시보드 DB에 저장
  • 전사 대시보드에서 서비스별 SLO 달성률 실시간 모니터링

7. SLO 기반 알람은 어떻게 설계하나요?

Burn Rate Alert 방식:

  • 현재 Error Budget 소진 속도가 목표 대비 빠르면 알람
  • Fast burn (1시간 윈도우): 즉시 대응 필요
  • Slow burn (6시간 윈도우): 주의 관찰
Burn Rate = (에러 발생률) / (허용 에러율)
Burn Rate > 14 → Critical (1시간 내 월간 버짓 2% 소진)
Burn Rate > 6  → Warning  (6시간 내 월간 버짓 5% 소진)

Observability 3요소

8. Metrics, Logs, Traces의 차이와 관계는?

요소형태용도도구
Metrics수치 시계열”무엇이 문제인가?”Prometheus, CloudWatch
Logs텍스트 이벤트”왜 문제인가?”Fluentbit, CloudWatch Logs
Traces요청 경로”어디서 느린가?”X-Ray, Jaeger

관계: Metrics로 이상 감지 → Traces로 병목 구간 확인 → Logs로 근본 원인 분석

9. Prometheus의 데이터 모델과 PromQL을 설명해주세요.

데이터 모델: metric_name{label1="value1", label2="value2"} value timestamp

주요 PromQL:

# 5분간 HTTP 요청 비율
rate(http_requests_total[5m])

# P99 응답시간
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# 에러율
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

10. Grafana 대시보드 설계 Best Practice는?

USE Method (리소스 관점):

  • Utilization: CPU, 메모리, 디스크 사용률
  • Saturation: 큐 길이, 대기 스레드
  • Errors: 에러율, 실패 카운트

RED Method (서비스 관점):

  • Rate: 초당 요청 수
  • Errors: 에러율
  • Duration: 응답시간 (P50, P90, P99)

11. Fluentbit으로 로그를 Metrics로 변환하는 방법은?

Fluentbit의 Lua Script Filter를 사용:

function cb_filter(tag, timestamp, record)
    -- 특정 패턴의 로그에서 비즈니스 메트릭 추출
    if record["log"] then
        local amount = string.match(record["log"], "payment_amount=(%d+)")
        if amount then
            record["payment_metric"] = tonumber(amount)
        end
    end
    return 1, timestamp, record
end

CloudWatch EMF(Embedded Metric Format)로 변환하여 커스텀 메트릭으로 발행합니다.

장애 대응

12. 장애 대응 프로세스를 설명해주세요.

  1. 감지 (Detection): 알람 수신 또는 사용자 리포트
  2. 분류 (Triage): 영향 범위 파악, 심각도 판단
  3. 소통 (Communication): 이해관계자 알림, 상태 페이지 업데이트
  4. 진단 (Diagnosis): 대시보드/로그/트레이스 분석
  5. 완화 (Mitigation): 트래픽 전환, 롤백, 스케일업
  6. 복구 (Recovery): 근본 원인 해결, 정상 확인
  7. 사후 분석 (Postmortem): Blameless 회고, 재발 방지 액션

13. Blameless Postmortem이란?

장애 후 개인이 아닌 시스템의 문제를 분석하는 문화입니다.

Postmortem 문서 구조:

  • 타임라인 (언제 무엇이 발생했는가)
  • 영향 범위 (어떤 서비스, 몇 명의 사용자)
  • 근본 원인 (Root Cause)
  • 잘한 점 / 개선할 점
  • 액션 아이템 (담당자, 기한)

14. MTTR과 MTTD를 개선하는 방법은?

  • MTTD (Mean Time To Detect): 장애 감지까지 걸리는 시간

    • SLO 기반 Burn Rate 알람
    • 합성 모니터링 (Synthetic Monitoring)
    • 이상 탐지 (Anomaly Detection)

  • MTTR (Mean Time To Recover): 장애 복구까지 걸리는 시간

    • Runbook 자동화
    • 원클릭 롤백
    • 장애 주입 훈련 (Chaos Engineering)

모니터링 운영

15. Alert Fatigue를 방지하는 방법은?

Alert Fatigue: 너무 많은 알람으로 중요한 알람을 놓치는 현상

방지 전략:

  • Actionable 알람만: 즉시 대응이 필요한 것만 알람
  • Grouping: 관련 알람 묶어서 하나로
  • Inhibition: 상위 장애 발생 시 하위 알람 억제
  • Severity 분리: Critical(즉시), Warning(업무시간), Info(로그만)
  • 정기 리뷰: 트리거되지 않은 알람, 무시된 알람 정리

16. Percentile 기반 모니터링의 장점은?

Average만 보면 문제를 놓칠 수 있습니다:

  • 평균 응답시간 100ms여도, P99가 5초일 수 있음
  • 상위 1% 사용자의 경험이 극도로 나쁨

권장 모니터링 지표:

  • P50: 중앙값, 일반적 경험
  • P90: 대부분의 사용자 경험
  • P99: 최악의 1% 경험 (SLO 기준으로 적합)

17. CloudWatch Application Signals의 장점은?

  • 코드 변경 없이 자동 계측 (Auto-instrumentation)
  • 서비스 맵 자동 생성
  • SLO/SLI 설정 및 모니터링 UI
  • X-Ray 트레이스와 통합
  • 에러율, 지연시간, 호출 빈도 자동 수집

고급 주제

18. Chaos Engineering이란?

프로덕션 환경에서 의도적으로 장애를 주입하여 시스템의 복원력을 검증하는 방법론입니다.

실험 프레임워크:

  1. 정상 상태 정의: 어떤 메트릭이 정상인가
  2. 가설 수립: “X가 실패해도 시스템은 정상 동작할 것”
  3. 변수 주입: 네트워크 지연, Pod Kill, AZ 장애
  4. 관찰: 정상 상태 유지 여부 확인
  5. 학습: 약점 발견 시 개선

도구: Litmus, Chaos Mesh, AWS FIS

19. SRE On-boarding 프로세스를 설명해주세요.

신규 서비스 SRE On-boarding 단계:

  1. 서비스 이해: 아키텍처, 의존성, 사용자 패턴 파악
  2. SLI 선정: Critical API 식별, 측정 방법 결정
  3. SLO 설정: 비즈니스 요구사항에 맞는 목표값 설정
  4. 대시보드 구축: RED Method 기반 모니터링 대시보드
  5. 알람 설정: Burn Rate 기반 멀티 레벨 알람
  6. Runbook 작성: 장애 시나리오별 대응 절차
  7. 전사 대시보드 연동: SLO 달성률 중앙 모니터링

20. On-call 문화와 Escalation 정책은?

On-call 로테이션:

  • Primary + Secondary 2인 체제
  • 1-2주 단위 교대
  • 보상: 수당 또는 대체 휴무

Escalation 정책:

  • L1 (5분): On-call 엔지니어
  • L2 (15분): 팀 리드
  • L3 (30분): 매니저 + 관련 팀

건강한 On-call 문화:

  • 주당 호출 2회 이하 목표
  • 반복되는 호출 → 자동화/근본 해결
  • On-call 부담 메트릭으로 팀 건강도 관리
Share:
Back to Blog

Related Posts

View All Posts »