# 엔지니어가 의도한 것 (가상 재구성)
# 빌링 서브시스템의 서버 소수만 제거
remove-servers --subsystem billing --count small

# 실제로 입력한 것 (가상 재구성)
# 입력 값 오류로 인해 예상보다 훨씬 많은 서버가 대상에 포함됨
remove-servers --subsystem billing --count MUCH_LARGER_THAN_INTENDED

복구 프로세스:
1. 서버 제거 확인 → 즉시 인지
2. 재시작 명령 실행 → 시작
3. INDEX 서브시스템 전체 재시작 → 시간 소요 (데이터 무결성 검증)
4. PLACEMENT 서브시스템 재시작 → INDEX에 의존하므로 순차 대기
5. S3 API 정상화 → INDEX + PLACEMENT 모두 정상 후에야 가능

문제: 마지막 전체 재시작을 해본 적이 없어서
      예상 소요 시간 자체를 몰랐음

S3 (죽음)
├── 직접 의존
│   ├── S3에 정적 파일 호스팅하는 모든 웹사이트
│   ├── S3를 스토리지로 쓰는 모든 앱
│   └── S3 기반 CDN을 사용하는 모든 서비스
│
├── 간접 의존 (다른 AWS 서비스 경유)
│   ├── EC2 (새 인스턴스 시작 불가 — AMI가 S3에 저장)
│   ├── Lambda (코드가 S3에 저장)
│   ├── ECS (도커 이미지 레지스트리)
│   ├── CloudFront (오리진이 S3)
│   └── 기타 수십 개의 AWS 서비스
│
└── 2차 영향
    ├── Slack (파일 업로드/다운로드 불가)
    ├── Trello (보드 로딩 실패)
    ├── Quora (사이트 다운)
    ├── IFTTT (자동화 중단)
    ├── Business Insider (뉴스 사이트 다운)
    └── 수천 개의 웹사이트와 앱

장애 시간: 약 4시간
영향 받은 서비스: 148,213개 이상의 웹사이트
금전적 손실 추정: $150M ~ $160M (S&P 500 기업 기준)
영향 받은 리전: US-EAST-1 (미국 동부)
하지만 US-EAST-1에 전 세계 상당수의 서비스가 몰려 있었음

// 당시 상황을 TypeScript로 재구성 (실제 AWS 내부 코드는 공개되지 않음)

// 문제: 제거 대상 서버 수에 대한 검증이 없었음
async function removeServers(subsystem: string, count: number) {
  // 바로 실행 — 위험!
  const servers = await getServers(subsystem);
  const toRemove = servers.slice(0, count);

  for (const server of toRemove) {
    await decommission(server);
  }

  return { removed: toRemove.length };
}

// 개선: 세이프가드 추가
async function removeServersSafe(subsystem: string, count: number) {
  const servers = await getServers(subsystem);
  const totalCount = servers.length;

  // 가드 1: 전체의 일정 비율 이상은 한 번에 제거 불가
  const MAX_REMOVAL_RATIO = 0.05; // 5%
  if (count > totalCount * MAX_REMOVAL_RATIO) {
    throw new Error(
      `제거 대상(${count})이 전체(${totalCount})의 ` +
      `${(MAX_REMOVAL_RATIO * 100)}%를 초과합니다. ` +
      `최대 ${Math.floor(totalCount * MAX_REMOVAL_RATIO)}대까지 가능.`
    );
  }

  // 가드 2: 핵심 서브시스템은 최소 인스턴스 수 보장
  const CRITICAL_SUBSYSTEMS = ['INDEX', 'PLACEMENT', 'AUTH'];
  if (CRITICAL_SUBSYSTEMS.includes(subsystem.toUpperCase())) {
    const remaining = totalCount - count;
    const MIN_REQUIRED = getMinRequired(subsystem);
    if (remaining < MIN_REQUIRED) {
      throw new Error(
        `핵심 서브시스템 ${subsystem}의 최소 요구 서버 수는 ` +
        `${MIN_REQUIRED}대입니다. 현재 ${totalCount}대에서 ` +
        `${count}대를 제거하면 ${remaining}대만 남습니다.`
      );
    }
  }

  // 가드 3: 수동 확인 요구
  const confirmation = await requestManualConfirmation({
    action: 'REMOVE_SERVERS',
    subsystem,
    count,
    totalAvailable: totalCount,
    remainingAfter: totalCount - count,
  });

  if (!confirmation.approved) {
    throw new Error('관리자 승인이 거부되었습니다.');
  }

  // 가드 4: 단계적 제거 (한 번에 다 빼지 않음)
  const BATCH_SIZE = Math.min(count, 5);
  for (let i = 0; i < count; i += BATCH_SIZE) {
    const batch = servers.slice(i, Math.min(i + BATCH_SIZE, count));
    await Promise.all(batch.map(s => decommission(s)));

    // 각 배치 후 헬스 체크
    const health = await checkSubsystemHealth(subsystem);
    if (!health.ok) {
      // 즉시 중단하고 롤백
      await rollback(servers.slice(0, i + BATCH_SIZE));
      throw new Error(`배치 ${i / BATCH_SIZE + 1} 후 헬스 체크 실패. 롤백 완료.`);
    }
  }
}

// 문제: 하나의 명령이 전체 리전에 영향
interface ServerRemovalCommand {
  subsystem: string;
  count: number;
  // region? 파티션? 제한 범위? → 없었음
}

// 개선: 블래스트 레이디우스 제한
interface ServerRemovalCommandV2 {
  subsystem: string;
  count: number;
  // 영향 범위를 명시적으로 제한
  scope: {
    region: string;
    availabilityZone: string;
    partition: string;  // 서브시스템 내부 파티션
  };
  // 최대 영향 범위 설정
  maxBlastRadius: {
    maxServersAffected: number;
    maxPercentageAffected: number;
    requiresApproval: boolean;
    approvalLevel: 'team-lead' | 'principal' | 'vp';
  };
}

// 장애 복구에서 발견된 문제를 TypeScript로 표현

interface DisasterRecoveryPlan {
  subsystem: string;
  lastTestedAt: Date;
  estimatedRecoveryTime: number; // minutes
  actualRecoveryTime?: number;   // minutes — 실제로는 테스트 안 해봐서 모름
  dependencies: string[];
}

// 2017년 당시 S3의 DR 플랜 (가상)
const s3RecoveryPlan: DisasterRecoveryPlan = {
  subsystem: 'S3-INDEX',
  lastTestedAt: new Date('2014-??-??'), // 마지막으로 전체 재시작을 테스트한 게 언제인지...
  estimatedRecoveryTime: 30,  // 예상: 30분
  actualRecoveryTime: 257,    // 실제: 4시간 17분
  dependencies: [], // PLACEMENT가 INDEX에 의존한다는 걸 명시 안 함
};

// 교훈: DR 플랜은 정기적으로 테스트해야 함
class DisasterRecoveryTester {
  // 게임 데이(Game Day) — 정기적으로 장애 시나리오를 시뮬레이션
  async runGameDay(plan: DisasterRecoveryPlan): Promise<GameDayResult> {
    const startTime = Date.now();

    // 1. 의존성 그래프 검증
    const deps = await this.buildDependencyGraph(plan.subsystem);
    console.log(`의존성: ${deps.join(' → ')}`);

    // 2. 실제 재시작 시뮬레이션 (카나리 환경에서)
    await this.simulateRestart(plan.subsystem, { environment: 'canary' });

    // 3. 실제 소요 시간 측정
    const actualTime = (Date.now() - startTime) / 1000 / 60;

    // 4. 예상 시간과 비교
    if (actualTime > plan.estimatedRecoveryTime * 1.5) {
      console.warn(
        `경고: 실제 복구 시간(${actualTime}분)이 ` +
        `예상(${plan.estimatedRecoveryTime}분)의 1.5배를 초과!`
      );
    }

    return {
      subsystem: plan.subsystem,
      estimatedTime: plan.estimatedRecoveryTime,
      actualTime,
      passed: actualTime <= plan.estimatedRecoveryTime * 2,
      lastTested: new Date(),
    };
  }
}

사용자: "S3 왜 안 되지? 대시보드 확인해보자"
        ↓
AWS Service Health Dashboard
        ↓
        [S3에서 정적 파일 로딩]
        ↓
        S3 죽음 → 대시보드도 죽음
        ↓
사용자: "???"
        ↓
트위터 가서 확인: "네, S3 장애 맞습니다"

// 모니터링 시스템 독립성 체크리스트

interface MonitoringInfraCheck {
  // 모니터링 시스템이 모니터링 대상과 인프라를 공유하는가?
  sharesInfraWithTarget: boolean;

  // 공유하는 인프라 목록
  sharedComponents: Array<{
    component: string;
    risk: 'critical' | 'high' | 'medium' | 'low';
    mitigation?: string;
  }>;
}

// 나쁜 예: AWS 2017
const badExample: MonitoringInfraCheck = {
  sharesInfraWithTarget: true,
  sharedComponents: [
    {
      component: 'S3 (스토리지)',
      risk: 'critical',
      // mitigation 없음!
    },
    {
      component: 'US-EAST-1 (리전)',
      risk: 'critical',
      // 같은 리전에 모든 게 있었음
    },
  ],
};

// 좋은 예: 독립적인 모니터링
const goodExample: MonitoringInfraCheck = {
  sharesInfraWithTarget: false,
  sharedComponents: [
    {
      component: 'DNS',
      risk: 'medium',
      mitigation: '멀티 DNS 프로바이더 (Route53 + Cloudflare)',
    },
  ],
};

// 이 사건 이후 "의존성 독립성"에 대한 인식이 높아짐

// 패턴: 중요 시스템의 의존성 검증
function auditDependencies(service: string) {
  const deps = getDependencies(service);

  // 순환 의존성 체크
  const circular = findCircularDeps(deps);
  if (circular.length > 0) {
    console.error('순환 의존성 발견:', circular);
  }

  // 단일 장애점 체크
  const spofs = findSinglePointsOfFailure(deps);
  if (spofs.length > 0) {
    console.error('단일 장애점 발견:', spofs);
    // 예: 모든 서비스가 US-EAST-1의 S3에 의존
  }

  // 독립성 체크: 모니터링은 대상과 분리되어 있는가?
  const monitoringDeps = getDependencies('monitoring');
  const overlap = findOverlap(deps, monitoringDeps);
  if (overlap.length > 0) {
    console.error('모니터링과 서비스가 인프라를 공유:', overlap);
  }
}