응용SW·HW·NW·DB 통합 운영

1. 모든 장비 지표가 초록색인데 서비스가 느릴 수 있을까

애플리케이션 CPU, DB CPU, 네트워크 손실, 서버 온도가 각각 정상범위여도 서비스 전체 지연은 커질 수 있다. 구성요소별 대시보드는 자기 경계만 보여 주기 때문에 호출대기·잠금·큐·DNS·스토리지 같은 연결지점의 지연을 놓칠 수 있다.

이번 절은 응용SW·HW·NW·DB 운영을 하나의 서비스 흐름으로 묶어 계층별 책임과 교차계층 진단을 다룬다.

먼저 큐의 작업 수·코어별 사용률·호출시간을 직접 계산한 뒤, 지역 A의 주문 결과조회 장애를 같은 요청 기록으로 진단한다. APP-1·HW-1·NW-1·DB-1은 서로 독립적인 작은 예이고 XOP-1은 이 원리를 종합하는 별도 사례다. 수치·식별자·시험 결과는 모두 교육용 가정이며 실제 서비스 장애기록이나 운영 승인 결과가 아니다.

앞 절의 서비스 관점을 그대로 가져온다

IT 운영기획·서비스수준·ITSM에서는 서비스 수준과 위험을 기준으로 애플리케이션·HW·NW·DB 책임을 연결했다. 이번 절은 그 계획을 실제 계층별 운영과 장애진단에 적용한다.

이 절에서 다루는 통합 운영의 범위

통합 운영은 응용SW·HW·NW·DB의 상태와 변경을 사용자 요청·서비스 결과·같은 시간축으로 연결하여 계층 사이의 의존성과 실패기여를 함께 판단하는 운영 방식이다.

앞 절의 IT 운영관리를 네 기술영역의 실제 진단·복구에 적용한다. 어떤 팀의 장비가 정상인지보다 같은 요청의 지연과 결과가 어디서 달라졌는지 확인한다.

사용자 요청의 통합 운영 경로

화살표의 방향과 조건을 따라 연결을 읽습니다.

선은 실행·접근의 의존 관계를 요약한다. 응용SW→런타임/OS→HW를 모든 요청의 시간순 네트워크 경로로 읽지 않는다. NW/스토리지는 원래 도식의 묶음이며 네 영역의 상태·로그·지표·변경 이력은 서비스 영향과 원인 가설의 증거로 연결한다.

문제 위치를 계층 하나에 고정하기 전에 요청의 실제 경로와 최근 변화를 함께 본다.

2. 응용SW 운영은 배포판본·의존성·상태·오류경로를 관리한다

응용SW 운영에서는 실행판본, 설정, 외부 API, 작업큐, 캐시, 세션, 배치와 오류율을 서비스 요청과 연결한다. 같은 소스라도 설정·의존성·트래픽 패턴이 다르면 운영행위가 달라질 수 있으므로 배포증거와 런타임 상태를 함께 본다.

APP-1: 오류율은 0%인데 주문이 쌓이는 경우

가상의 5분 동안 주문 접수 요청 1,000건이 모두 HTTP 200을 받았다고 하자. 이 API가 약속한 응답은 접수 성공이지 주문의 모든 후속 작업 완료가 아니다. 요청 한 건마다 서로 구별되는 후속 작업 10개를 등록하며, 등록 실패·다른 생산자·중복 등록은 없다고 가정한다. 이 예의 큐 잔량은 대기 중과 실행 중을 합한 전체 미완료 작업 수다.

잔량의 수지는 10 + 1000 × 10 − 2010 − 0 = 8000작업이다. 수지는 같은 대상을 같은 구간에서 더하고 빼는 계산이라는 뜻이다. 실행을 시작했지만 끝내지 못한 작업은 완료 수에 넣지 않으며, 재시도로 새 작업을 등록했다면 실제 등록 수에도 포함한다. 큐를 다른 정의로 측정하면 그 정의에 맞는 이동 항목을 먼저 정한다.

따라서 접수 오류율 0%와 미완료 작업 7,990개 증가는 양립한다. 완료 2,010작업이 곧 완료 주문 2,010건이라는 뜻도 아니다. 주문 식별자별 후속 작업과 최종 상태를 연결해야 한다. 미완료 작업 중 가장 오래 기다린 시간 20초가 별도로 관측됐다고 해도, 그 시간은 위 잔량식에서 나온 값이 아니다.

응답코드뿐 아니라 큐 길이·처리시간·최종 상태를 본다. 완료 수가 3,010작업으로 바뀌고 나머지 조건이 같다면 잔량은 7,000작업이다. 반대로 요청당 작업이 하나뿐이고 다른 유입도 없다면, 시작 10·등록 1,000에서 종료 8,000이라는 기록은 그대로 성립하지 않으므로 등록 누락·구간·측정 대상을 대조해야 한다.

3. HW 운영은 자원·장애영역·펌웨어·물리상태를 서비스와 연결한다

CPU·메모리·디스크·전원·온도·장치오류를 단순 임계값으로만 보지 않고 어떤 서비스와 장애영역에 영향을 주는지 연결한다. 이중화 장치가 모두 같은 전원·랙·펌웨어 결함에 묶여 있다면 숫자상 두 대여도 독립 중복이 아닐 수 있다.

HW-1: CPU 평균 40%가 여유를 보장하지 않는다

같은 성능의 8개 코어를 같은 1분 동안 측정한 사용률이 아래와 같다고 하자. 이 예는 각 코어의 사용률을 같은 비중으로 평균한다.

전체 평균은 (100 + 40 + 40 + 40 + 30 + 30 + 20 + 20) / 8 = 40%다. 첫 코어의 100%가 이 평균에 기여하는 양은 100/8 = 12.5%포인트이며 전체 사용률이 12.5%라는 뜻이 아니다. 나머지 코어의 기여 27.5%포인트를 더해야 한다.

병목이 직렬 구간이라면 전체 평균보다 해당 실행경로의 포화와 대기시간을 봐야 한다. 해당 요청이 첫 코어의 단일 스레드 작업을 기다리는지는 요청별 대기·실행 기록으로 확인한다. 첫 코어의 포화와 요청 지연이 함께 보인다는 이유만으로 원인을 확정하지 않는다. 병렬로 나눌 수 없는 작업이라면 다른 코어를 더 붙여도 그 작업이 자동으로 빨라지지 않는다.

나머지 7개가 모두 0%인 별도 조건에서는 평균이 12.5%가 되지만 첫 코어는 여전히 100%다. 평균이 낮아졌다는 사실과 그 요청의 대기가 해결됐다는 사실을 구별한다.

4. NW 운영은 경로·이름해석·지연·손실·재전송·용량을 함께 본다

네트워크가 연결되었다는 사실과 필요한 품질을 제공한다는 사실은 다르다. DNS, 라우팅, 방화벽, 로드밸런서, MTU, 혼잡, 재전송과 지역별 경로를 요청 단위의 지연·실패와 연결한다.

NW-1: 평균 지연 20 ms가 꼬리 지연을 숨긴다

같은 경계에서 측정한 요청 100개 중 95개가 10 ms이고 5개가 210 ms라면 평균은 (95 × 10 + 5 × 210) / 100 = 20ms다. 그러나 요청의 5%는 200 ms를 넘었다. 요청 수와 고유 사용자 수가 같다는 조건이 없으므로 이를 사용자 5%의 경험으로 바꾸지 않는다. 서비스 요구에 맞는 분포와 구간을 본다.

이 표는 요청별 지연 예이지 원인이 네트워크에 있다는 확정 자료가 아니다. 측정 시작·끝, 경로·재전송·수신 측 대기 등을 대조한다. 시간이 짧은 오류 응답을 정상 서비스의 빠른 응답으로 세지 않는다.

5. DB 운영은 데이터 정확성·동시성·성능·용량·복구를 함께 관리한다

DB가 접속 가능해도 잠금대기, 느린 쿼리, 복제지연, 스토리지 증가, 통계정보 부정확, 백업 실패가 서비스 장애로 이어질 수 있다. 쿼리와 트랜잭션을 애플리케이션 요청·데이터 변경·복구목표에 연결한다.

DB-1: 쿼리 하나가 20 ms인데 전체 주문이 2초 걸리는 이유

한 요청이 쿼리를 80번 직렬 호출한다고 하자. 여기서 20 ms는 앱이 한 호출을 보내기 시작한 때부터 결과 수신을 마칠 때까지의 경과시간으로, DB 처리와 왕복·클라이언트 쪽 시간이 이미 포함된 값이다. 호출이 서로 겹치지 않고 각 20 ms라는 가정에서 DB 호출 구간의 합은 80 × 20 = 1600ms = 1.6초다.

요청 전체가 2,000 ms였고 이 호출 구간 밖의 시간이 400 ms로 확인됐다면 1600 + 400 = 2000ms로 대조한다. 같은 호출 안의 DB 서버 실행시간이 5 ms라고 해서 80 × (20 + 5)로 다시 더하지 않는다. 바깥 구간과 그 안의 구간을 중복 집계한 것이다. 반대로 20 ms가 서버 실행시간만의 값이면 왕복을 포함한 앱 관측값을 따로 확보해야 한다.

쿼리 단건 성능만 최적화하기 전에 호출횟수·트랜잭션 경계·왕복지연을 함께 본다. 결과가 같은 묶음 조회로 10회까지 줄고 각 호출시간과 나머지 400 ms가 그대로라는 계산 가정에서는 10 × 20 + 400 = 600ms다. 실제 묶음 크기가 커지면 처리·전송시간도 달라질 수 있으므로 600 ms는 실측 개선값이 아니다. 결과 정확성·부하·잠금·요청 분포를 다시 확인한다.

계층마다 대표 운영 질문이 다르다

각 팀의 정상판정이 서비스 정상판정을 대신하지 않는다.

모든 대시보드가 초록색이라는 사실을 원인없음으로 해석하지 않는다

임계값이 사용자 결과와 맞지 않거나, 계층 사이 대기시간을 측정하지 않거나, 최근 변경을 대시보드가 포함하지 않을 수 있다. 서비스 증상에서 요청경로를 따라 가설을 좁힌다.

6. 교차계층 진단 순서

1. 사용자 영향·시작시각·범위를 고정한다.
2. 정상/실패 요청을 구분할 식별자를 잡는다.
3. 최근 배포·설정·DB·NW·HW 변경을 시간순으로 놓는다.
4. 요청경로의 앱→DB/NW→HW 지표를 같은 시간축에 맞춘다.
5. 원인 가설마다 반증 가능한 관찰을 정한다.
6. 가장 안전한 복구와 검증을 먼저 수행한다.
7. 원인·영향·재발방지 변경을 별도 기록한다.

계층별 초록을 서비스 빨강과 연결하는 법

화살표의 방향과 조건을 따라 연결을 읽습니다.

출발 질문은 서비스 오류와 사용자 영향이다. 선은 서로 다른 관찰의 대조 관계이며 APP→DB→NW→HW라는 실행 순서가 아니다. 최근 변경과 반대 증거를 함께 남기고 시간상 일치만으로 원인을 확정하지 않는다.

장애 소유팀보다 사용자 영향의 복구책임을 먼저 정한다

원인이 어느 팀인지 확정되기 전에도 우회·롤백·용량확대처럼 서비스 영향을 줄일 행동이 필요할 수 있다. 원인 소유권과 사건 복구 역할을 분리하면 책임공방으로 복구가 늦어지는 위험을 줄일 수 있다.

최근 변경 하나를 찾았다고 즉시 원인으로 확정하지 않는다

장애 직전 배포가 있었다면 강한 가설이지만 시간상 일치만으로 인과가 증명되지는 않는다. 롤백·비교군·판본별 증상·경로차이를 확인한다.

XOP-1: 지역별 분모에서 복구 판정까지 따라간다

별도 가상 사례 XOP-1은 주문서비스 중 결과조회 기능만 대상으로 한다. 14:00~14:05의 5분 동안 요청 기록이 완전하며 실패는 ‘2초 이내 올바른 조회 결과를 받지 못함’으로 정한다. 이 2초 기준은 자체 사례의 조건이며 앞 절 OP-S의 SLA를 바꾼 것이 아니다. 같은 요청이 두 지역에 중복 집계되지 않는다.

A의 비중은 2500/10000 = 25%이므로 전체 실패율은 0.25 × 8% + 0.75 × 0% = 2%다. 두 지역 비율의 단순평균 4%가 아니다. 14:00 이전 정상 구간의 기록도 보존하고, 사건 지휘자는 INC-X1에 기능·지역·영향시각·분모·아직 모르는 범위를 적는다. 앱·DB·네트워크·플랫폼 담당은 같은 사건 기록에 관찰과 변경을 연결한다.

요청 시간은 포함 관계를 먼저 읽는다

A의 지연 요청 A-0412와, 같은 80개 항목의 조회를 재현한 정상 경로 비교 요청 B-0841을 살핀다. 요청 식별자는 한 번의 호출 흐름을 연결하는 표지이고, 고객·주문 식별자와는 구별한다. 아래 값은 하나의 검증된 시간축으로 맞춘 교육용 기록이며 각 행은 서로 겹치지 않는다. 다른 서버의 시계가 맞지 않거나 구간이 빠졌다면 먼저 시간기준·추적 누락을 확인해야 한다.

A의 클라이언트는 2,000 ms에 시간초과했으며 서버 쪽 관문 처리는 2,150 ms까지 추적됐다고 가정한다. 서버 처리 종료를 고객이 성공 응답을 받은 시각으로 바꾸지 않는다. A의 1,600 ms는 80회×20 ms, B의 200 ms는 10회×20 ms이며 앱에서 관측한 왕복 포함 호출시간이다. 각 호출 안의 서버 실행 5 ms는 이미 포함되어 있다. 2150 + 1600처럼 전체와 하위 구간을 다시 합산하지 않는다.

두 요청의 차이는 2150 − 450 = 1700ms이며, 호출 구간 차이 1,400 ms와 앱 대기 차이 300 ms로 나뉜다. 두 요청만으로 전체 200건의 원인이 모두 같다고 확정하지 않는다. 실패 요청들과 성공 요청을 같은 입력 크기·경로·판본으로 나누어 이 설명이 반복해서 맞는지 조사한다.

네 계층의 가설과 반대 증거를 함께 적는다

14:00에 지역 A만 조회 설정 C1에서 C2로 바뀌었다. C1은 최대 8개 항목을 한 번에 묶어 조회하고 C2는 하나씩 조회한다. 앱 실행파일·DB 구조는 같다는 별도 가정 아래, 80개 항목에서 호출 10회와 80회의 차이가 생긴다. 같은 시각 변경이라는 이유만으로 원인 확정을 하지 않고 아래처럼 검증한다.

현재 자료는 앱의 호출 증가 가설을 우선하지만 DB·NW·HW가 영원히 정상이라는 증명은 아니다. C1/C2의 동일 자료 재현과 변경 전후의 비교가 필요하다. 앱 대기 증가도 호출 증가의 결과인지 별도 병목인지 추적한다. 앱·DB 서버를 무조건 증설하는 안은 호출 구조를 확인하지 못하고 부하를 다른 계층으로 옮길 수 있어 먼저 선택하지 않는다.

무엇을 되돌리고, 언제 중단할지 결정한다

읽기 전용 결과조회에 한정해 C1을 복원하는 안을 택한다. 앱 담당자는 실행파일·설정 차이와 기존 C1의 결과 계약을, DB 담당자는 데이터 구조·권한·조회 결과가 같음을 먼저 확인한다. 서비스 책임자가 CHG-X1의 변경 범위·실행자·복원 절차를 승인하고 사건 지휘자가 실행을 조정한다. 주문 생성이나 결제 요청을 새 식별자로 재발행하여 재현하지 않는다.

먼저 격리된 동일 자료에서 C1/C2의 정확한 결과와 10회/80회 호출을 비교한다. 그 뒤 승인된 제한된 읽기 트래픽에서 확인하고 지역 A로 적용 범위를 넓힌다. 예상과 다른 데이터·권한 결과, 호출 수 미감소, 새로운 오류, 제한 구간의 대기 지속 증가 중 하나라도 보이면 확대를 중단하고 원인·안전한 다음 조치를 재검토한다. 변경 승인서는 실제 검증 결과를 대신하지 않는다.

이 사례의 복구 확인은 A의 연속 10분, 유효 조회 1,000건 이상, 2초 이내 올바른 결과 비율 99.9% 이상, 잘못된 결과·의도하지 않은 데이터 변경 0건, 미완료 대기 비증가를 함께 요구한다. 영향받지 않은 경로도 기존 관측 정의로 악화 여부를 확인한다. 표본 부족이나 기록 결손은 통과가 아니라 미확인이다. 이 수치들은 단기 복구 판단용 자체 조건이며 월간 SLA나 모든 사용자에 대한 무결점 보장이 아니다.

가상 후속 기록 R1이 지역 A에서 연속 10분 동안 관측한 유효 조회 5,000건 중 4,998건을 2초 안에 올바르게 처리하고, 나머지 2건도 뒤늦게 정확한 결과로 대조됐으며, 잘못된 결과·데이터 변경 0건, 대기 80→20, 다른 경로 악화 없음이라면 위 한정된 복구 조건을 충족한다. 4998/5000 × 100 = 99.96%다. 늦은 2건은 원래의 실패 집계에서 지우지 않는다. 같은 속도 결과여도 잘못된 결과가 1건인 별도 기록 R2는 복구 조건에 미달한다.

지휘자는 실제로 위 조건을 확인한 구간과 복구 판단시각을 남긴다. 시간초과 사용자에 대한 상태 안내·미확인 결과의 담당 인계가 끝난 뒤 사건 종료를 판단하고, 원인 확정·설정 검토·항목 수별 성능시험·계층별 대기 감시의 개선은 PRB-X1에서 계속 관리한다. 남기는 산출물은 지역 집계, 요청 시간표, 가설별 관찰·반례, CHG-X1, 복구 판정과 후속 책임이다. 이 자료를 나열하는 데 그치지 않고 같은 요청·설정·시간창으로 연결한다.

용량과 변경은 네 계층을 동시에 움직일 수 있다

트래픽 2배 증가는 앱 스레드, DB 연결, 네트워크 처리량, 스토리지 IOPS를 함께 압박한다. 한 계층만 증설하면 병목이 다음 계층으로 이동할 수 있으므로 서비스 경로의 제한요소를 반복 측정한다.

유지보수 창은 작업시간이 아니라 사용자 위험 창이다

DB 패치 10분이라도 사전 동기화·트래픽 전환·검증·롤백까지 40분이 필요할 수 있다. 변경절차는 실제 사용자 영향, 의존성 순서와 복구시간을 기준으로 잡는다.

공식 범위 연결 — 응용SW 운영관리

배포판본·설정·의존성·큐·캐시·세션·오류·외부 API 상태를 요청 흐름과 연결하고 안전한 배포·복구·검증을 관리한다.

공식 범위 연결 — HW 운영관리

CPU·메모리·스토리지·전원·온도·장애영역과 펌웨어 상태를 서비스 영향·용량·교체·복구계획에 연결한다.

공식 범위 연결 — NW 운영관리

DNS·라우팅·방화벽·로드밸런서·지연·손실·재전송·용량과 경로변경을 서비스 요청의 도달성·성능·복구에 연결한다.

공식 범위 연결 — DB 운영관리

트랜잭션·잠금·쿼리·복제·용량·백업·복구 상태를 애플리케이션 요청과 데이터 정확성·가용성에 연결한다.

출처와 적용 경계

이 절은 응용SW·HW·NW·DB의 서로 다른 관찰 경계를 같은 요청·시간축으로 대조하는 학습 사례다. 구체 제품 명령·도구·임계값은 환경마다 달라 별도 운영문서를 확인한다. 본문의 수치와 장애상황은 교육용 자체 예제다.

APP-1의 작업 수지, HW-1의 코어 평균, DB-1의 포함 시간, XOP-1의 분모·시간표·가설·복구 기록은 이 절을 위해 작성한 유한 가정과 산술 예다. 과거 출처 관찰일을 이번 편집일로 갱신하거나 새 표준·제품 성능을 검증한 자료로 쓰지 않는다. 기출 원문·공식 모범답안·실제 고객 실험을 수행한 것으로 표시하지 않는다. 서비스수준·사건과 변경의 의미는 앞 절 운영기획과 관리에서 이어받되 여기서는 요청 진단에 적용한다.

7. 한 장으로 정리하기

1. 응용SW·HW·NW·DB는 다른 신호와 실패모드를 가진다.
2. 각 계층의 초록색이 서비스 정상이라는 뜻은 아니다.
3. 요청 식별자·시간축·변경이력으로 교차계층 증거를 맞춘다.
4. 복구책임과 원인소유권을 구분한다.
5. 한 계층 증설·변경이 다른 계층 병목을 옮길 수 있다.

독립 연습 — 한 요청의 시간과 한 지역의 실패율을 분리한다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

XOP-1의 지역 A 2,500 건·실패 200 건, 그 밖의 지역 7,500 건·실패 0 건을 유지한다. A-0412의 총 시간 2,150 ms에는 DB 호출 1,600 ms가 이미 포함된다. 각 20 ms 호출에는 DB 내부 실행 5 ms가 포함된다.

• 지역 A와 전체의 실패율을 각각 계산하라.
• 2,150+1,600 또는 80×(20+5)가 틀린 이유를 설명하라.
• C1으로 복구했는데도 호출 수가 80 회로 유지된다면 어떤 가설과 확대 결정을 다시 판단할지 쓰라.

풀이와 오답 교정 보기

A는 200/2500=8%, 전체는 200/10000=2%다. 지역별 실패율을 단순 평균한 4%가 아니다. 2,150 ms는 1,600 ms를 포함한 전체이고, 20 ms는 5 ms 내부 실행과 왕복 등을 포함한 값이므로 두 식 모두 중복 합산이다. C1의 10 회 호출로 회복한다는 가설과 달리 80 회가 유지되면 단순 판본 원인 가설을 다시 검토한다. 확대를 보류하고 다른 경로·호출·집계 조건을 확인한다.

DB 호출 시간의 포함 관계와 XOP-1의 가설·반대 증거에서 요청 식별자와 비교 조건을 함께 고친다.

8. 자체 10점 문제

응용SW, HW, NW, DB 운영관리의 주요 대상과 실패징후를 비교하고, 네 영역을 서비스 관점에서 통합 운영해야 하는 이유를 설명하시오.

요구어는 비교, 설명이다. 네 계층의 차이와 교차계층 진단을 함께 제시한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 통합 운영의 서비스 관점
2. 응용SW 운영대상
3. HW 운영대상
4. NW 운영대상
5. DB 운영대상
6. 시간축·요청경로 기반 교차진단

10점 답안 도식

실행·접근 의존 그림과 네 계층 증거 대조 그림을 함께 읽는다. 사용자 요청의 APP·DB·HW·NW 관계를 확인하고 같은 시간축의 변경 이력·서비스 영향을 대조한다. 상호 의존을 모든 요청의 정해진 순서로 바꾸지 않는다.

10점 모범답안

응용SW 운영은 배포판본·설정·의존성·큐·캐시·오류경로를, HW 운영은 CPU·메모리·스토리지·전원·장애영역을, NW 운영은 DNS·경로·지연·손실·재전송을, DB 운영은 트랜잭션·잠금·쿼리·복제·백업·복구를 관리한다. 각 영역의 정상판정은 자기 경계만 설명하므로 모두 정상이어도 계층 사이 대기나 호출폭증으로 서비스가 실패할 수 있다. 사용자 영향과 요청 식별자를 기준으로 같은 시간축에 앱·DB·NW·HW 신호와 최근 변경을 놓고 반증 가능한 원인가설을 검증해야 한다. 복구책임과 원인소유권을 구분하고, 변경·증설 뒤에는 병목이 다른 계층으로 이동했는지 서비스 결과를 다시 확인한다.

예를 들어 APP-1의 접수 성공은 미완료 8,000작업의 해소가 아니고, HW-1의 평균 40%는 한 코어의 100% 포화를 가릴 수 있다. DB-1에서는 왕복 포함 20 ms를 80번 직렬 호출한 1.6초와 그 밖의 시간을 대조한다. 서로 다른 측정 경계와 분모를 먼저 맞추어야 원인과 복구 근거를 비교할 수 있다.

9. 자체 25점 문제

주문서비스가 특정 지역에서만 느려졌고 앱·DB·NW·HW의 기본 대시보드는 모두 정상이다. 응용SW·HW·NW·DB 통합 운영 관점에서 진단·복구·재발방지 절차를 설계하시오. 요청 식별자, 시간축, 최근 변경, 계층별 가설과 검증을 포함하시오.

요구어는 설계, 포함이다. 증상에서 계층을 찍는 대신 증거를 같은 시간축으로 맞춘다.

답안의 가정·관찰값은 앞의 XOP-1을 사용한다. 2초 기준의 결과조회, 지역별 2,500/7,500건, C1/C2 설정, 80항목의 비교 요청과 복구 판정 조건을 하나의 사례로 연결한다. 다른 조건을 택하는 답안도 가능하지만 측정 경계·권한·선택 이유·중단 조건이 서로 맞아야 한다. 아래 답안은 실제 장애를 처리한 기록이 아니라 교육용 설계 결과다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 사용자 영향·지역·시작시각 고정
2. 정상/실패 요청 식별자
3. 최근 앱·DB·NW·HW 변경 비교
4. 응용SW: 판본·큐·캐시·외부API
5. DB: 잠금·쿼리·복제
6. NW: DNS·경로·손실·지연
7. HW: 자원·장애영역
8. 안전한 우회·롤백과 검증
9. 원인·재발방지·모니터링 개선

25점 도식 대조표

XOP-1에서 연결할 기록	확인할 내용
지역 A 지연·요청 ID·시간축	기능·지역·분모·영향시각
APP·DB·NW·HW와 변경 이력	판본·잠금·경로·자원과 반대 증거
가설 → 검증	같은 80항목의 C1/C2 결과·호출 수
복구 → 재발방지	승인된 읽기 전용 C1 복원·확대 중단·후속 PRB-X1

네 계층 증거 대조 그림의 합류는 실행 순서가 아니라 관찰의 대조다. 위 표의 검증에는 동일 80항목·C1/C2 비교를, 복구에는 읽기 전용 C1 복원과 확대 중단 조건을 채워 그 판단을 설명한다.

25점 완성 답안 예시

1. 영향과 분모. XOP-1의 결과조회 기능에서 14:00~14:05 지역 A는 2,500건 중 200건 실패로 8%, 나머지는 7,500건 중 실패 0건이다. 전체는 200/10,000=2%이며 실패는 2초 이내 올바른 결과를 받지 못한 요청이다. 사건 지휘자는 INC-X1에 기능·지역·영향시각·측정 경계와 미확인을 기록하고 앱·DB·NW·HW 담당을 같은 시간축으로 연결한다.

2. 요청별 증거. 동일 80항목의 A-0412와 B-0841을 비교한다. A는 대기 350+직렬 DB 호출 1600+앱 100+관문 100=2150 ms이고 B는 50+200+100+100=450 ms다. A의 고객 시간초과 2000 ms와 서버 처리 종료를 구분한다. 호출시간은 왕복 포함이므로 그 안의 서버 실행 5 ms를 다시 더하지 않는다. 두 요청의 차이 1700 ms를 호출 1400 ms와 대기 300 ms로 나누되 전체 실패의 원인 확정으로 확대하지 않는다.

3. 가설과 역할. 앱 담당은 A만 C2로 바뀐 시점과 동일 자료의 C1/C2를 비교해 80회/10회 호출 및 결과 일치를 확인한다. DB 담당은 호출 수뿐 아니라 잠금·실행·복제·결과 판본을 대조한다. NW 담당은 DNS·경로·손실·재전송을 확인하며 앱 관측 20 ms에서 서버 5 ms를 뺀 전부를 망 지연으로 보지 않는다. HW 담당은 평균 대신 코어별 최고 45%와 CPU 대기·스토리지·공통 장애영역을 조사한다. 예상과 다른 관찰은 가설을 다시 여는 근거로 남긴다.

4. 선택한 복구와 중단. 조회 결과·권한·DB 구조가 동일함을 확인한 뒤, 서비스 책임자의 CHG-X1 승인 아래 읽기 전용 결과조회 설정만 C1으로 복원한다. 격리 재현 후 제한 트래픽에서 확인하고 지역 A로 확대한다. 결과·권한 불일치, 호출 수 미감소, 신규 오류 또는 대기 지속 증가가 있으면 확대를 중단한다. 주문·결제를 새 식별자로 재발행하는 재현과 근거 없는 일괄 증설은 선택하지 않는다.

5. 복구 판정. A의 연속 10분·유효 조회 1000건 이상에서 2초 이내 올바른 결과 99.9% 이상, 잘못된 결과·의도하지 않은 데이터 변경 0건, 대기 비증가와 다른 경로의 악화 여부를 함께 확인한다. 같은 연속 10분의 R1에서 4998/5000=99.96%, 늦은 2건의 대조 완료, 대기 80→20과 무결성 조건은 이 한정된 기준을 충족한다. 속도가 같아도 잘못된 결과가 1건인 R2는 미달이며 자료 결손·표본 부족은 미확인으로 둔다. 늦은 결과를 지난 실패 집계에서 지우지 않는다.

6. 종료와 재발방지. 사용자 안내와 미확인 결과의 후속 책임을 인계한 뒤 사건 종료를 판단한다. 지역별 집계·요청 시간표·가설 반례·설정 변경·복구 근거를 연결하고 원인·기여조건과 설정 검토, 항목 수별 회귀시험, 대기·호출 수 감시 개선은 PRB-X1에 남긴다. 단기 복구 관찰을 월간 SLA 달성·모든 원인 제거·실제 운영 승인으로 확대하지 않는다.

10. 답안을 가리고 수치와 결정을 고친다

다음 오답을 먼저 고친 뒤 해설을 대조한다. 숫자만 계산하는 것과 그 숫자로 결정할 수 있는 범위를 설명하는 것은 다르다.

조건 변경 1. 지역 A가 5,000건 중 400건 실패, 나머지가 5,000건 중 실패 0건이라면? 전체는 400/10000=4%다. A 자체의 8%는 같고 비중이 25%에서 50%가 된 것이다. 실패율 변화만으로 각 지역의 품질 악화를 확정하지 않는다.

조건 변경 2. XOP-1에서 복원 뒤 호출은 10회가 됐지만 호출당 앱 관측이 50 ms이고 나머지 시간이 350+100+100 ms라면? 합계는 10×50+350+100+100=1050ms다. 한 요청이 2초 이내라는 관찰일 뿐 전체 분포·정확성·복구 기준 통과는 아니다. DB 실행·왕복·대기 범위를 다시 조사한다.

조건 변경 3. R1과 같은 성공률이 나왔지만 수신 로그가 일부 유실됐다면? 실제 분모를 확인할 수 없으므로 99.96%를 확정하지 않는다. 독립 집계와 요청 식별자를 대조하고, 해소 전에는 측정 불완전으로 남긴다.

25점 답안에서 가설 이름만 적었다면 가설 표로 돌아가 관찰·반대 증거·담당을 한 줄씩 쓴다. 복구를 ‘롤백한다’로 끝냈다면 변경할 설정, 보존할 결과 계약, 중단 조건과 판정 분모를 채운다. 면접에서는 왜 앱 전체나 DB를 되돌리지 않았는지, C1도 느리다면 다음 무엇을 확인할지 설명한다. 가상 사례를 자신의 실무 수행 경력으로 소개하지 않는다.