문서관리번호			비밀구분	비공개
관리구분	관리본문서
본 문서는 임의로 복사되거나 배포될 수 없음.

장애대응 매뉴얼

개정이력 관리

개정번호	개정내용 요약	일 자	비 고

목  차

장애 대응 매뉴얼

Ⅰ. 개요	5

1.1. 목적	5

1.2. 범위	5

1.3. 대상	5

1.4. 절차	5

가. 장애감지 및 공유	5

나. 장애조치 및 장애요인 분석	5

다. 장애상황 해결	5

Ⅱ. 대상시스템	7

2.1. OOO 클라우드 온라인	7

가. KT G-Cloud 자산	7

나. OOO 클라우드 자산	7

Ⅲ. 장애대응 조직 및 역할	8

Ⅳ. 장애대응 프로세스	9

4.1. 장애 유형 및 심각도 정의	9

가. 장애 유형 및 분류	9

나. 장애 심각도 정의	9

4.2. 장애 유형 및 심각도별 보고절차	10

4.3. 장애 유형별 탐지 방법	10

가. KT에서 제공받은 자산(IaaS)	10

나. OOO 자산(SaaS)	10

4.4. 장애 유형별 대응 절차	11

가. KT 자산 관련 장애발생시 대응 절차	11

나. OOO 클라우드 관련 장애발생시 대응 절차	12

4.5. 프로메테우스, Zabbix 알람 내용 및 장애등급 정의	13

4.6. 장애대응 및 복구에 대한 책임과 역할	15

가. 운영자 별 사전 업무분장	15

4.7. 장애 유형별 대응 및 복구 절차	16

가. 장애 영향도	16

Ⅴ. 장애 기록 및 조치 보고서	18

5.1. 장애기록	18

5.2. 장애조치 보고서	18

Ⅵ. 장애에 따른 이용자 신고/통지 절차	19

6.1. 공지 수단 및 형식	19

가. 장애 발생 공지 형식	19

나. 장애 복구 공지 형식	19

6.2. 공지 대상	20

가. 이용 고객 연락처(온라인 서비스)	20

나. 고객사 담당자	20

Ⅶ. 비상 연락망	21

7.1. 비상 연락망	21

7.2. 주요 Alarm에 따른 담당자 연락	21

7.3. 협력업체 연락처(온라인서비스)	21

Ⅰ		개 요

1.1. 목 적

OOO의 OOO 클라우드 장애 발생 시 초기대응체계 확립을 통하여, 신속하고 효율적인 장애 처리를 위한 절차와 조치사항 규정을 목적으로 한다.

1.2. 범위

본 매뉴얼은 운영과 관련된 OOO 클라우드 및 해당업무와 관련된 OOO 내 담당자 및 외부 인력을 포함한다.

1.3. 대상

o OOO 클라우드 서비스가 이용되는 모든 구간(KT G-Cloud 등)

o 기타 OOO 클라우드와 관련된 보안 및 네트워크 장비

1.4. 절차

가. 장애감지 및 공유

㉠ 장애감지는 HW 및 SW 측면으로 나누어 감지한다.

㉡ (HW 측면) IaaS에 대해서는 MSP 사업자로부터 장애발생시 상황전파 받으
며, 운영팀에서 정보보안 담당자에게 연락하여 장애 상황을 공유한다.

㉢ (SW 측면) 응용프로그램에 대한 장애 이벤트는 서비스기술팀 전인원이 구글
챗(SMS)으로 문자를 수신하며, 장애 감지 즉시 해당 SW 장애 관련 담당
자 및 정보보호 담당자에게 연락하여 장애 상황을 공유한다.

나. 장애조치 및 장애요인 분석

㉠ 장애관리책임자(정보보호 최고책임자)

o 장애가 복구제한 시간 내 해결되지 않을 경우 장애등급 상향 조정한다.

o 장애등급별 보고체계에 따라 보고하고 조치한다.

㉡ 장애관리담당자(각 팀별 운영자)

o 서비스 영향도와 긴급도에 따른 장애등급을 파악한다.

o 장애등급별 보고체계에 따라 보고하고 조치한다.

- 보고사항 : 장애발생시간, 내용, 장애영향, 처리내용 등

o 장애가 복구제한 시간 내 해결되지 않을 경우 장애관리책임자에게 장애       등급 상향 조정을 건의한다.

o 장애요소를 파악하며, 장애복구 후 개선대책 마련한다.

o 장애조치 후 장애원인 분석 및 장애보고서를 작성한다.

다. 장애상황 해결

㉠ 장애관리 담당자 : 장애해결 시 정보보호 담당자에게 장애완료를 공유 한다.

㉡ 정보보호 담당자

o 장애조치 후 장애등급별 보고계통에 따라 장애관리 책임자에게 장애 완료       보고를 한다.

o 장애 발생 시 클라우드 장애 사고에 대해 공공기관의 담당자의 요청시

아래 내용이 작성된 장애조치 보고서를 제공하여야 한다.

- 장애 발생일시, 보고자 및 보고일시, 장애내용(원인, 내용, 영향범위),

조치 내용, 복구 내용, 재발방지 대책

※ 5.2 장애조치 보고서 양식 참조

Ⅱ		대상시스템

2.1. OOO 클라우드 온라인            ※ 자산의 범위는 변동될시 추가/삭제

가. IaaS별 자산 목록

순번	목적 및 기능(용도)	Hostname	Platform	OS버전	위치	상세 자산 내역
1		Virture Router	Virture Router	-	KT G-Cloud	KT G-Cloud에서 제공하는 자산임
2		-	-	-
3		master01	Linux	Ubuntu 22.04
4		master02	Linux	Ubuntu 22.04
5		master03	Linux	Ubuntu 22.04
6		worker01	Linux	Ubuntu 22.04
7		worker02	Linux	Ubuntu 22.04
8		registry	Linux	Ubuntu 22.04
9		priv-registry	Linux	Ubuntu 22.04
10		nfs	Linux	Ubuntu 22.04
11		nginx-ingress	Linux	Ubuntu 22.04
12		worker01	Linux	Ubuntu 22.04	NHN 판교IDC	NHN Cloud에서 제공하는 자산
13		worker02	Linux	Ubuntu 22.04
14		registry	Linux	Ubuntu 22.04
15		priv-registry	Linux	Ubuntu 22.04
16		bastion	Linux	Ubuntu 22.04
17		NAS	-	-

※ 각 IaaS공급사에서 제공하는 자산은 공급사에서 관리하며, 장애발생시 IaaS	공급사에서 장애 대응

나. OOO 클라우드 자산

순번	자산그룹	목적 및 기능(용도)	Hostname	Platform	OS 버전	담당 부서	위치
1		dashboard		Node.js	18.17.0	프론트엔드	KT G-Cloud
2		dashboard-proxy		NginX-Ingress	1.7.0	프론트엔드
3		api-server		OpenJDK	8u212	DevOps
4		build-api		golang	1.19	DevOps
5		package		golang	1.19	DevOps
6		batch-server		golang	1.13	DevOps
7		cluster-api		golang	1.13	DevOps
8		모니터링 및 알람 정보 제공		golang	4.8.3	모니터링
9		모니터링 데이터 DB 저장		golang	4.8.3	모니터링
10		알람 데이터 DB 저장		golang	4.8.2	모니터링
11		Public cloud 감사 데이터 수집 및 DB 저장		golang	4.8.0	모니터링
12		감사 데이터 DB 저장		golang	4.8.0	모니터링
13		모니터링, 알람, 감사 DB 저장공간 관리		golang	1.0.2	모니터링
14		OOO에 등록된 클러스터 상태 검사		golang	3.3.1	모니터링
15		클러스터 모니터링 정보 전송		golang	4.8.1	모니터링
16		클러스터 알람 정보 전송		golang	4.8.0	모니터링
17		클러스터 감사 로그 전송		golang	4.8.0	모니터링
1		dashboard		Node.js	18.17.0	프론트엔드	NHN Cloud
2		dashboard-proxy		NginX-Ingress	1.7.0	프론트엔드
3		api-server		OpenJDK	8u212	DevOps
4		build-api		golang	1.19	DevOps
5		package		golang	1.19	DevOps
6		batch-server		golang	1.13	DevOps
7		cluster-api		golang	1.13	DevOps
8		모니터링 및 알람 정보 제공		golang	4.8.3	모니터링
9		모니터링 데이터 DB 저장		golang	4.8.3	모니터링
10		알람 데이터 DB 저장		golang	4.8.2	모니터링
11		Public cloud 감사 데이터 수집 및 DB 저장		golang	4.8.0	모니터링
12		감사 데이터 DB 저장		golang	4.8.0	모니터링
13		모니터링, 알람, 감사 DB 저장공간 관리		golang	1.0.2	모니터링
14		OOO에 등록된 클러스터 상태 검사		golang	3.3.1	모니터링
15		클러스터 모니터링 정보 전송		golang	4.8.1	모니터링
16		클러스터 알람 정보 전송		golang	4.8.0	모니터링
17		클러스터 감사 로그 전송		golang	4.8.0	모니터링

Ⅲ		장애대응 조직 및 역할

							장애관리책임자
							(정보보호 최고책임자)
																	정보보호 담당자
							장애관리담당자
							(각 담당자)
개발실 (프론트엔드)						개발실 (데브옵스)						개발실 (모티터링)						서비스기술팀 (운영)

구 분		책 임 과 역 할
장애관리 책임자 (정보보호 최고책임자)		o 장애 발생 관련 업무 총괄
정보보호 담당자		o 장애관리책임자 보좌 및 장애관련 모든 활동을 조정관리 o 정보시스템의 운영환경을 안정적으로 유지 o 내․외부적으로 필요한 지원조직 간의 협력지원 o 장애 또는 비상상황의 복구 활동에 소요되는 자원 확보 o 장애이력 관리 및 장애복구절차 확립 o 장애등급의 상향 등 장애등급 조정 o 비상연락망 유지관리 및 장애발생 내용 상황전파
장애관리 담당자	개발실 (프론트엔드)	o 장애발생 시 모든 상황파악에 대한 실무 담당 o 장애로 인한 영향력을 최소화 및 신속한 해결 o 장애에 대한 근본원인을 분석․해결 o 장애등급의 상향 건의 등 장애등급 조정 건의 o 접수한 장애이력 관리 및 정보보안 담당자 보고 o 해결된 장애에 대한 문서화
	개발실 (데브옵스)
	개발실 (모니터링)
	서비스기술팀 (운영)	o IaaS 공급사에서 제공된 IaaS 장애에 대하여 장애 근본원인 분석․해결 o 접수한 장애이력 관리 및 정보보안 담당자 보고 o 해결된 장애에 대한 문서화
협력업체		o 장애감지 시 장애관리담당자 또는 정보보호 담당자에게 상황 전파

Ⅳ		장애 대응 프로세스

4.1. 장애 유형 및 심각도 정의

가. 장애 유형 및 분류

㉠ 장애는 크게 시스템 장애, 미들웨어（WEB/WAS) 장애, 데이터베이스 장애　예정된  장애로  정의하여 구분된다.

㉡ 각  장애 유형별 대응 절차는  다음  아래와  같다．

구분	장애원인	장애조치순서	담당자
시스템 장 애	물리적 장애(CNode, CPU/Meory, Disk, Fan, Main B/D, LANCard)	1) 물리Level은 IaaS공급사가 관리하며 해당 장비들에 대해서도 IaaS공급사의 보안관제를 실시한다. 2) IaaS공급사 장애조치 절차에 따라 교체	IaaS 공급사
	프로세스별 리소스 (CPU, Memory, Disk) 점유율 과다(90%이상)	1) 사후분석을 위해 Dump 2) Resource 과다 점유 프로세스 kill 3) 프로세스 재실행 4) 원인분석 및 근본적 조치 5) Disk Full인 경우 필요 없는 File 삭제후 여유공간 확보, 필요시 물리적 디스크 확보	서버 관리자
	운영체제 손상	1) 백업된 운영체계로 복원 * 백업 및 복구 절차서를 참조하여 복구	서버 관리자
미들웨어（WEB/WAS) 장 애	CPU/Memory	1) 쓰레드, 힙메모리 덤프 수행 2) 인스던스 재기동 3) 덤프분석 후 원인파악 및 조치	개발실 (프론트 엔드)
	TCP 접속 세션수	1) TCP 상태 별 증가 추이 분석 - Close, Wait 정상수행여부 확인 2) 지속증가 시 인스던스 재기동 3) 덤프분석 후 원인파악 및 조치
	이상로그 감지	1) 이상로그 발생시 원인 분석하여 적용
데이터 베이스 장 애	프로세스 정지/이상	1) 기동 안될 시 로그 분석 2) 에러 조치 후 기동	각 담당자
	Directory Full	1) 백업 수행 후 파일 삭제
	데이터 손상	1) 최근 백업 데이터 복원
	config. 파일 변경 이상	1) 변경 전 상태로 복원 및 수정 후 재적용
예정된 장 애	S/W 패치	1) 작업 절차서에 따라 수행 (RollBack)	각 담당자
	H/W 패치	1) 작업 절차서에 따라 수행 (RollBack)	각 담당자

나. 장애 심각도 정의

등급	시스템 상황	조 치 목표시간	보고(공유) 체 계
1 등급	- 시스템을 계속 또는 부분적으로 이용할 수 없게 만드는 장애 - 서브시스템(storage, registry 등)이 down되어 서비스 사용자가 서비스를 이용할 수 없는 장애	43.2분 이내에 처리를 목표로 함	장애인지한 후 즉시 개발실 전체
2 등급	- 처리속도의 심각한 지연 - 사용자 서비스에는 문제는 없으나, 시스템이 load 증가, OOO 시스템의 처리속도 지연	7시간 이내	장애인지한 후 즉시 개발실 전체
3 등급	- 서비스 사용자에게 영향을 주지 않는 장애 - 처리속도의 지연, 모니터링 데이터의 유실, 반복적인 프로세스 재시작, 백업 시스템의 비정상 동작	35시간 이내	장애인지한 후 즉시 개발실 전체

※ 조치 목표시간 산출 근거 : 계약서 내 보상 비율에 따른 조치 목표시간을 산정

4.2. 장애 유형 및 심각도별 보고절차

가. 장애보고는 [표 장애등급별 보고계통 단계]의 단계별 담당자가 담당하며,     장애등급별 보고시간은 아래와 같다.

장애등급	장애 보고계통
1등급	장애관리담당자 <-> 정보보호 담당자(협의) -> 장애관리책임자 -> 경영진
2등급	장애관리담당자 <-> 정보보호 담당자(협의) -> 장애관리책임자
3등급	장애관리담당자 <-> 정보보호 담당자(협의) -> 장애관리책임자

[표 장애등급별 보고계통 단계]

나. 장애 보고시간은 등급별 최종보고자까지 보고하는데 걸리는 시간을 말하며,   경과보고는 장애관리책임자와 협의하여 조정하거나 생략할 수 있다.

다. 2내지 3등급의 장애는 [표 장애등급별 보고시간] 과 같이 협력업체를 통해  제한시간 내 해결 가능한 장애는 장애관리책임자까지 보고하며, 제한시간 내 해결이 불가능한 장애는 장애등급을 상향조정 후 경영진까지 보고하고   조치한다. (1등급인 경우에는 재발방지 대책을 수립하고 경영진까지 보고한다.)

장애등급	최초보고	경과보고	최종보고
1등급	장애발생 즉시 또는 30분 이내	매 30분 단위	복구 즉시
2등급	장애발생 1시간 이내	매 1시간 단위	복구 즉시
3등급	장애발생 2시간 이내	매 2시간 단위	복구 즉시

[표 장애등급별 보고시간]

4.3. 장애 유형별 탐지 방법

가. IaaS공급사에서 제공받은 자산

㉠ 각IaaS공급사에서 제공받은 자산에 장애가 발생시 즉시 내용을 통지 받는다.

(통지 내용 : 사고내용, 사고원인(확인시), 피해확산 방지 조치, 담당자 및 연락처)

㉡ OOO 클라우드 시스템에서 CPU, Memory, HDD 등 성능․용량을 주기적으로 체크하며, 실시간 장애 발생시 즉시 각 팀별 담당자 및 정보보호 담당자에게 공유한다. (주요자산 : master01/02/03, worker01/02, registry, nginx, nfs,NAS)

나. OOO 자산(SaaS)

㉠ 응용프로그램에 대한 장애 이벤트는 서비스기술팀 전인원이 구글 챗(SMS)으로 문자를 수신하며, 장애 감지 즉시 해당 SW 장애 관련 담당자 및 정보보호 담당자에게 연락하여 장애 상황을 즉시 공유한다.

4.4. 장애 유형별 대응 절차

가. IaaS공급사에서 제공한 자산 관련 장애발생시 대응 절차

㉠ 자산 장애상황

Hardware 장애로 구분되며 크게 Server 장애, Network 장애, 환경 장애로 나뉠수 있다. OOO 클라우드의 IaaS는 각 IaaS공급사로로부터 제공받아 이용 중이며, IaaS 장애 발생시 KT로부터 장애대응을 제공 받는다.

㉡ 이벤트 탐지

IaaS는 공급사에서 제공하는 자산이며, 해당 자산 장애발생시 각 IaaS공급사 내의 관제업체에서 장애 이벤트를 탐지한다.

㉢ 장애 탐지 및 상황 전파

IaaS 장애 발생시 IaaS공급사의 관제 서비스로부터 장애발생에 따른 메일(OOO)로 수신하며, 다음 아래와 같다. (예시)

주메일 사용자는 서비스기술팀(운영), 정보보호팀이며, 해당 장애발생 메일 수신 후 정보보호 담당자는 장애발생에 대해 정보보호 최고책임자에게 보고한다.

㉣ 초동 조치

장애의 위험도를 판단하여 심각할 경우 초동조치 단계로 정보보호 최고책임자에게 보고하고 IaaS 장애에 따른 OOO 클라우드 서비스의 영향도를 파악하여 피해완화를 위한 조치를 진행한다.

㉤ 이벤트 분석

장애와 관련된 정보를 수집하여 장애발생 원인 및 피해범위 등을 파악하고 별도의 대응조치 필요여부 등 대응방안을 수립한다.

㉥ 복구 및 정상화

IaaS 장애 복구 후 OOO 클라우드의 서비스의 정상화를 확인한다.

나. OOO 클라우드 관련 장애발생시 대응 절차

㉠ OOO 클라우드 장애 상황

크게 Software 장애와 Data 장애로 구분되며, Software 장애는 OOO 장애, 클러스터(k8s) 장애, OS 장애로 세분화되며, Data 장애는 Database 장애, Data 장애, 백업 장애로 세분화 할 수 있다. 각 장애 유형에 따라 Prometheus 알람 또는 운영 중 장애를 인지하게 되며, 인지 직후에 해당 장애를 조치할 팀은 즉시 복구 및 안정화 하도록 조치한다.

㉡ 이벤트 탐지

OOO 클라우드와 관련된 이벤트 발생시 Prometheus 알람을 서비스기술팀 전원이 수신하며, 다음 아래와 같다.(예시)

㉢ 장애 탐지 및 상황 전파

Prometheus 알람 중 OOO 클라우드와 관련된 장애 이벤트를 확인한 인원은 장애발생에 대해 정보보호 최고책임자에게 보고 및 전 팀원에게 상황을 전파(구글 Chat)한다.

㉣ 초동 조치

장애의 위험도를 판단하여 심각할 경우 초동조치 단계로 정보보호 최고책임자에게 보고하고 OOO 클라우드 서비스의 영향도를 파악하여 피해완화를 위한 조치를 진행한다.

㉤ 이벤트 분석

장애와 관련된 정보를 수집하여 장애발생 원인 및 피해범위 등을 파악하고 별도의 대응조치 필요여부 등 대응방안을 수립한다. 이때 장애와 연관된 팀은 별도로 장애에 따른 추가 피해상황이 있는지 확인한다.

㉥ 복구 및 정상화

장애 복구 후 OOO 클라우드의 서비스의 정상화를 확인한다.

4.5. 프로메테우스 알람 내용 및 우선순위 정의

알람수신	알람 내용	우선 순위	비고
OOO 클러스터 화면, Slack	하나 이상의 ETCD 멤버가 중지되면 ETCD 클러스터를 사용할 수 없습니다.	1
	인스턴스 {{ $labels.instance }}에 리더가 없습니다.	1
	{{ $labels.job }} 메트릭 수집 대상의 {{ $value }}% 이상이 동작하지 않습니다.	1
	Apiserver가 없어졌거나 Apiserver의 메트릭을 수집할 수 없습니다.	1
	Controller manager가 동작하지 않습니다. Deployment와 Replication Controller가 더이상 동작하지 않습니다.	1
	Scheduler가 동작하지 않습니다. 새로운 Pod가 Node에 할당되지 않습니다.	1
	노드 {{ $labels.node }}의 kubelet이 Apiserver에 check-in 하지 않았거나 1시간 이상 NotReady 상태입니다.	1
	{{ $value }} Kubernetes 노드의 10%이상이 NotReady 상태입니다.	1
	전체에서 {{ $value }}%의 Kubelet 메트릭 수집 실패	1
	Kubelet이 없어졌거나 전체에서 {{ $value }}%의 Kueblet 메트릭 수집 실패	1
	노드 {{ $labels.node }} 의 디스크 공간이 부족합니다.	1
	노드 {{ $labels.node }}의 메모리가 부족합니다.	1
	노드 {{ $labels.node }}의 디스크 공간이 부족합니다.	1
	노드 {{ $labels.node }}의 CPU 사용량이 90%이상입니다. (현재 값: {{ $value }})	1
	노드 {{ $labels.node }}의 Memory 사용량이 90%이상입니다. (현재 값: {{ $value }})	1
	Apiserver 에 대한 {{ $labels.verb }} 요청 중 가장 느린 요청의 대기시간이 1초이상 걸립니다.	2
	Kubelet {{$labels.instance}}에 {{$value}}개의 Pod가 실행중입니다. (제한값: 110개)	2
	Node-exporter가 없어졌거나 Node-exporter의 메트릭을 수집할 수 없습니다.	2
	실패한 gRPC 요청이 많습니다.	2
	Alertmanager가 없어졌거나 Alertmanager의 메트릭을 수집할 수 없습니다.	3
	Alertmanager {{ $labels.namespace }}/{{ $labels.pod }}의 설정을 다시 읽는 도중 에러가 발생하였습니다.	3
	지난 1시간 동안 인스턴스 {{ $labels.instance }}의 리더가 {{ $value }}번 변경되었습니다.	3
	인스턴스 {{ $labels.instance }}의 gRPC {{ $labels.grpc_method }} 요청 실패율: {{ $value }}%	3
	인스턴스 {{ $labels.instance }}의 gRPC {{ $labels.grpc_method }} 요청 실패율: {{ $value }}%	3
	인스턴스 {{ $labels.instance }}의 gRPC {{ $labels.grpc_method }} 요청의 응답속도가 느립니다.	3
	인스턴스 {{ $labels.instance }}의 HTTP {{ $labels.method }} 요청 실패율: {{ $value }}%	3
	인스턴스 {{ $labels.instance }}의 HTTP {{ $labels.method }} 요청 실패율: {{ $value }}%	3
	인스턴스 {{ $labels.instance }}의 HTTP {{ $labels.method }} 요청의 응답속도가 느립니다.	3
	인스턴스 {{ $labels.instance }}와 {{ $labels.To }} 간의 통신속도가 느립니다.	3
	지난 1시간 동안 인스턴스 {{ $labels.instance }}의 raft protocol 요청이 {{ $value }}번 실패했습니다. (리더 선출의 일시적인 실패 또는 멤버 부족으로 인한 ETCD 클러스터 중단 시간이 길어질 경우 발생합니다.)	3
	인스턴스 {{ $labels.instance }}의 wal fync 대기 시간이 깁니다. (디스크에 대한 작업 시간이 길어지면 디스크에 문제가 있음을 타냅니다.)	3
	인스턴스 {{ $labels.instance }}의 backend commit 대기 시간이 깁니다. (디스크에 대한 작업 시간이 길어지면 디스크에 문제가 있음을 나타냅니다.)	3
	DeadMansSwitch는 전체 Alerting 파이프 라인이 동작하는지 알려줍니다. 해당 Alert는 사용자에게 통지되지 않습니다.	3
	인스턴스 {{ $labels.instance }}는 사용 가능한 파일 및 소켓 Descriptor의 {{ $value }}%를 사용하고 있습니다.	3
	인스턴스 {{ $labels.instance }}의 파일 및 소켓 Descriptor가 곧 소진됩니다.	3
	{{$labels.namespace}}/{{$labels.deployment}}의 deployment generation이 관측된 값과 일치하지 않습니다.	3
	{{$labels.namespace}}/{{$labels.deployment}}의 replica가 변경되지 않았습니다.	3
	Daemonset {{$labels.namespace}}/{{$labels.daemonset}}에서 {{$value}}%의 Pod만 실행중입니다.	3
	다수의 Daemonset이 스케줄되지 않았습니다.	3
	다수의 Daemonset이 실행되지 않아야하는 위치에서 실행 중입니다.	3
	Pod {{$labels.namespace}}/{{$labels.pod}}가 지난 1시간 내에 {{$value}}번 다시 시작하였습니다.	3
	Prometheus {{ $labels.namespace }}/{{ $labels.pod}}의 설정을 다시 읽는 도중 에러가 발생하였습니다.	3
	인스턴스 {{$labels.namespace}}/{{$labels.instance}}에 마운트된 PV의 디스크 사용량이 디스크 전체 크기 대비 80%이상입니다. (현재값: {{ $value }})	3
	Pod {{$labels.namespace}}/{{$labels.pod_name}}의 CPU 사용량이 제한량 대비 90%이상입니다. (현재 값: {{ $value }})	3
	Pod {{$labels.namespace}}/{{$labels.pod_name}}의 Memory 사용량이 제한량 대비 90%이상입니다. (현재 값: {{ $value }})	3

4.6. 장애대응 및 복구에 대한 책임과 역할

가. 운영자 별 사전 업무분장

대상	순번	역할	기타
전략기획실 정보보호팀	1	신속한 상황전파 및 보고
	2	피해범위 파악 및 보고
	3	침해사고 및 장애 연관성 검토
	4	내․외부적으로 필요한 지원조직 간의 협력지원
개발실 (모니터링) (프론트엔드) (데브옵스)	1	장애 발생시 고객사에 대한 장애 발생 공지.	응용 프로그램
	2	장애 발생 시각, 현상, 원인, 작업 기록
	3	장애로 인해 고객사에서 발생한 피해 상황 파악
	4	주요 장애 처리 작업에 대한 내용과 시간 기록
	5	장애 처리 매뉴얼에 따른 조치
	6	비상 연락망을 통한 담당자 호출 및 상황 유지
	7	장애 이력 관리 시스템에 장애 처리 내용 등록
	8	장애 복구 완료시 고객사에 대한 장애 복구 완료 공지
	9	예방 방안 수립
서비스기술팀 (운영)	1	장애 발생시 고객사에 대한 장애 발생 공지.	KT로부터 제공받은 IaaS 자산
	2	장애 발생 시각, 현상, 원인, 작업 기록
	3	KT 조치 진행 상황 모니터링
	4	장애 복구 완료시 고객사에 대한 장애 복구 완료 공지
	5	예방 방안 수립 확인

4.7. 장애 유형별 대응 및 복구 절차

가. 장애 영향도

구분	자산그룹	목적 및 기능(용도)	Hostname	Platform	영향도
1			Virture Router	Virture Router	전체 서비스 안됨
2			-	-	전체 서비스 안됨
3			master01	Linux	서비스 영향 없음
4			master02	Linux	서비스 영향 없음
5			master03	Linux	서비스 영향 없음
6			worker01	Linux	일부 서비스 안됨
7			worker02	Linux	일부 서비스 안됨
8			registry	Linux	일부 서비스 안됨
9			priv-registry	Linux	일부 서비스 안됨
10			nfs	Linux	전체 서비스 안됨
11			nginx-ingress	Linux	일부 서비스 안됨
12			-	-	일부 서비스 안됨
12			master01 master02 master03	Node.js	일부 서비스 안됨
13				NginX	전체 서비스 안됨
14				OpenJDK	일부 서비스 안됨
15				golang	일부 서비스 안됨
16				golang	일부 서비스 안됨
17				golang	일부 서비스 안됨
18				golang	일부 서비스 안됨
19			-	golang	서비스 영향 없음
20			-	golang	서비스 영향 없음
21			-	golang	서비스 영향 없음
22			-	golang	전체 서비스 안됨
23			-	golang	서비스 영향 없음
24			-	golang	서비스 영향 없음
25			-	golang	서비스 영향 없음
26			-	golang	일부 서비스 안됨
27			-	golang	일부 서비스 안됨
28			all node	golang	일부 서비스 안됨

나. 장애종류별 처리절차

고객사	대상	체크 항목	체크 방법
Host 시스템	서버	Host cmdb, etcd backup이 정상적으로 동작하는지 확인	1. Master1(192.168.0.221)에 접속 2. ls /nas/BACKUP/db 로 해서 cmdb backup file이 어제날짜 포함해서 30일치가 보관되는지 확인 3. ls /nas/BACKUP/etcd 로 해서 etcd snapshot파일이 어제날짜 포함해서 30일치가 보관되는지 확인.
		POD 정상동작 확인	1. Master1(192.168.0.221)에 접속 2. kubectl get pods --all-namespaces 명령으로 pod 상태가 running이 아닌 것이 있는지 확인 3. pod상태가 running이 아닌것에 대해 아래 명력으로 상태 확인 kubectl describe pod {pod명} -n {namespace명}
		NFS 서버 정상 동작확인	1. Worker2(192.168.0.223)에 접속 2. 아래 명령으로 nfs관련 service가 정상기동 중인지 확인 systemctl status rpcbind systemctl status nfs
		NFS 가용 용량 확인 및 삭제된 항목 정리	1. Worker2(192.168.0.223)에 접속 2. 아래 명령으로 nfs 공유 디렉토리 사용량 확인 df -h | grep "/home$" 3. 삭제된 항목 정리 archived- 된 디렉토리는 삭제된 항목임으로 rm 명령으로 삭제
		Registry서버 정상 동작확인	1. Brower로 regi.acloud.run에 로그인되는지 확인한다. 2. 로그인 후 우측 상단의 disk 사용량을 확인한다.
		서버 resource 사용량 확인	1. Zabbix로 로그인하여 host 서버(5대)의 cpu, memory, disk 사용량을 조사한다. (http://192.168.0.5/index.php?reconnect=1&form=default)
demo(3대) 시스템	서버	POD 정상동작 확인	1. Master(192.168.0.227)에 접속 2. kubectl get pods --all-namespaces 명령으로 pod 상태가 running이 아닌 것이 있는지 확인 3. pod상태가 running이 아닌것에 대해 아래 명령으로 상태 확인 kubectl describe pod {pod명} -n {namespace명}
		NFS 서버 정상 동작확인	1. Master(192.168.0.227)에 접속 2. 아래 명령으로 nfs관련 service가 정상기동 중인지 확인 systemctl status rpcbind systemctl status nfs
		NFS 가용 용량 확인 및 삭제된 항목 정리	1. Worker3(192.168.0.223)에 접속 2. 아래 명령으로 nfs 공유 디렉토리 사용량 확인 df -h | grep "/home$" 3. 삭제된 항목 정리 archived- 된 디렉토리는 삭제된 항목임으로 rm 명령으로 삭제
		서버 resource 사용량 확인	1. Zabbix로 로그인하여 대상장비 cpu, memory, disk 사용량을 조사한다. (http://192.168.0.5/index.php?reconnect=1&form=default)
한국 demo (GKE)	서버		1. 일본 리전 node 및 pod 상태 확인
		NFS 가용 용량 확인 및 삭제된 항목 정리	1. Storage(35.200.28.204)에 접속 2. 아래 명령으로 nfs 공유 디렉토리 사용량 확인 df -h | grep "/storage$" 3. 삭제된 항목 정리 archived- 된 디렉토리는 삭제된 항목임으로 rm 명령으로 삭제

Ⅴ		장애 기록 및 조치 보고서

5.1. 장애 기록

장애관리대장

no	발생일	발생내용	조치내용	조치일	조치자	확인자	장애유형	비고

5.2. 장애조치 보고서

장애조치보고서
장애발생 일시		조치완료 일시		장애 유형 및 심각도
장애내용	(장애원인) (장애내용) (영향범위)
조치내용
복구내용
재발방지대책
2024. 00. 00 작성부서 : . 작성자 : (서명) 확인자 : (서명)

Ⅵ		장애에 따른 이용자 신고/통지 절차

6.1. 공지 수단 및 형식

장애 공지는 이메일 통한 공지를 기본으로 한다. 경우에 따라서는 이메일 공지와 함께 유선, SNS를 통한 안내를 진행한다.

클라우드발전법 시행령 제16조(통지가 필요한 클라우드컴퓨팅서비스의 중단 기간)

1. 클라우드컴퓨팅서비스의 중단 기간이 연속해서 10분 이상인 경우

2. 클라우드컴퓨팅서비스의 중단 사고가 발생한 때부터 24시간 이내에 클라우드컴퓨팅서비스가       2회 이상 중단된 경우로서 그 중단된 기간을 합하여 15분 이상인 경우

가. 장애 발생 공지 형식

발신자: OOO

[장애공지] OOO 클라우드 온라인 OO 서비스 장애 건

OOO 클라우드 온라인 OO 서비스 장애가 발생하여 아래와 같이 공지합니다.

-  아래  -

1. 장애발생 일시 : 2024년 1월 1일 10:00

2. 예상복구 일시 : 2024년 1월 1일 11:00 (예측이 불가능할 경우 +2시간)

3. 장애 내용     : 레지스트리 서버 다운에 의한 접속 불가

4. 장애 원인     : 레지스트리 서버 다운에 의한 접속 불가

5. 영향받는 시스템

1) OOO 시스템

6. 클라우드컴퓨팅서비스 제공자의 피해 확산 방지 조치 현황

7. 클라우드컴퓨팅서비스 이용자의 피해 예방 또는 확산 방지 방법

8. 담당부서 및 연락처

장애로 인하여 업무에 불편을 드린 점에 대해 사과말씀 드리며, 빠른 시간 내에 정상화 될 수 있도록 최선을 다하겠습니다.

나. 장애 복구 공지 형식

[장애공지] OOO 클라우드 온라인 OO 서비스 장애 건

OOO 클라우드 온라인 OO 서비스 장애가 복구되어 아래와 같이 공지합니다.

-  아래  -

1. 복구완료 일시 : 2024년 1월   1일 11:00

2. 장애발생 일시 : 2024년 1월   1일 10:00

3. 장애 내용     : 레지스트리 서버 다운에 의한 접속 불가

4. 조치 내용     : 서버 재기동 후 정상화

5. 담당부서 및 연락처

장애로 인하여 업무에 불편을 드린 점에 대해 사과말씀 드리며, 안정적인 서비스를 위해 최선을 다하겠습니다.

6.2. 공지 대상

OOO 서비스를 이용하는 모든 고객을 대상으로 공지하며, 공지 대상은 항상 최신 정보로 관리한다.

2024년 4월 8일부 현재 서비스 이용 고객은 아래와 같다.

가. 이용 고객 연락처(온라인 서비스)

기관명	담당자	업무 구분	전화번호 및 핸드폰 연락처	이메일주소
이용고객 발생시 추후 작성

나. 고객사 담당자

이름	업무 구분	핸드폰	비고

Ⅶ		비상 연락망

7.1. 비상 연락망

구분		성명	직급	연락처	해당업무
CND	정보 보호팀	김동혁	-	010-3895-5556	정보보안 업무담당
		이홍준	-	010-3861-6203
개발실	프론트 엔드	유병운	-	010-4715-7125	Kubernetes 클러스터 관리솔루션 개발
		김수환	-	010-5669-1379
	데브옵스	장 준	-	010-9377-7854	OOO 클라우드 API 개발
		최호재	-	010-9008-7908
	모니터링	허광훈	-	010-2845-8112	Kubernetes 클러스터 모니터링 담당
		김범기	-	010-6338-0434
서비스 기술팀	운영	나성현	-	010-7330-7859	OOO 클라우드 설치 운영
		이병철	-	010-8485-4354
		이현주	-	010-5018-9472

7.2. 주요 Alarm에 따른 담당자 연락

구분	alarm 내용	담당자	비고
1	특정 application의 cpu, memory 부족, 계속 restart됨	해당 pod 담당자
2	k8s 주요 컴포넌트 (etcd, api-server, controller, scheduler, node, kubelet)	해당 pod 담당자
3	프로메테우스, Zabbix 발생 알람	해당 pod 담당자
4	Application 배포 이상 및 Build 동작 이상	장 준, 최호재	개발실 (데브옵스)
5	모니터링 데이터가 부분 출력되거나 전체 출력 안될 경우	허광훈, 김범기	개발실 (모니터링)

7.3. 협력업체 연락처(온라인 서비스)

회사	이름	업무 구분	핸드폰	이메일주소
KT	김대성 부장	Cloud 사업 담당	010-3010-6813	daesung.kim@kt.com
KT DR	정미진	Cloud 사업팀		mj.jung@kt.com
보안관제	WINS (보안관제1팀)	KT G-Cloud 보안관제	02-2655-1830 02-2655-1831	mss.ktcloud@kt.com
NHN	NHN상주 근무자	NHN Cloud 관제	1588-7967	-