- 현재 위치
- home > 컴퓨터·ICT·어학 > 컴퓨터·IT 도서 > 컴퓨터공학 > 시스템 다운, 원인 파악이 먼저다[성안당]
;)
[시스템 다운, 원인 파악이 먼저다]는 기업의 정보 시스템을 안전하게 유지하기 위한 해법을 제시한 책이다. 책에서는 누구나 겪을 수 있는 시스템 다운으로부터 원인을 좁혀가는 플로차트를 그려서 실타래처럼 얽힌 시스템 다운의 원인을 규명하는 법을 알려준다. 1장에서 다운이란 무엇인지 설명하고, 다운의 원인을 2~7장에서 분석, 마지막 8장에서 트러블 대처법을 제시하고 있다.
저자: Owada Naotaka
Chapter_01 시스템이 멈췄다_다운이란 무엇인가
story 01 | 정지=다운은 오해
① 단 하나의 실수가 치명타
② 예외 루트에 숨어 있는 함정
③ 100% 막는 것은 무리라는 현실에 관심을 갖자
④ 근본 원인을 찾아내기까지가 승부수
story 02 | 다운의 원인은 네 가지로 나눌 수 있다
① 다운 상황에 원인의 힌트가 숨겨져 있다
② 네 가지 문제가 연쇄적으로 일어나 ATM 11만 대에 영향을 주다
Chapter_02 제대로 테스트했을텐데..._애플리케이션 소프트웨어 문제
story 01 | 갑자기 눈을 뜨는 20세기 버그
① 시점을 바꾼 여덟 가지 테스트를 반복한다
② 아무리 테스트를 반복해도 버그는 남는다
③ 설마 데이터 복구 프로그램이 전체 데이터를 삭제하다니
④ 하나의 버그가 400억엔(약 4,000억원)의 손실로
⑤ 5개의 조건이 가동한 지 6년째에 처음으로 일치하다
⑥ 정지시키지 않은 것이 화근이었다
⑦ ‘데이터 이전’은 범인 찾기가 어려워
⑧ 회귀 데이터를 찾을 수 없어
story 02 | 잊어버릴만 하면 찾아오는 ‘날짜 문제’
① 윤년의 19년 전은 윤년일까?
② 2100년 2월 28일에 큰 트러블이
③ 34년 먼저 발생한 ‘2038년 문제’
④ ‘30%만 이상’이라 찾기 힘들다
⑤ 자리 넘침으로 ‘2001년 9월 9일 문제’ 발생
⑥ 2036년을 주목하자
⑦ 날짜 문제가 아닌 ‘자리 넘침’ 문제도
CLOUMN | 여기는 시스템 다운 상담실___트러블 대책에 쫓기는 개발 기술자
Chapter_03 애플리케이션뿐만이 아니다_OS, 미들웨어의 이상
story 01 | 정지를 감지 못하다
① 블랙박스의 무서움
② 다섯 종류의 이중화의 차이를 알자
③ 다잉 메시지를 캐치 못하고
④ 클러스터 소프트웨어가 작동하지 않아
story 02 | 조합을 바꿨더니 움직이지 않는다
① 동일 업체의 소프트웨어인데도 궁합이 나쁘다니
② 업무 애플리케이션과 OS의 조합 검증이 누락
③ 패치 적용이나 버전업에 리스크 있음
④ 오래된 소프트웨어와 최신판 중 무엇을 고를까?
⑤ 실적으로 고른 메인 프레임 제품에 버그
⑥ 성능이 너무 높아져 15년 전의 문제가 드러남
⑦ 검증 책임은 이용자에게 있다
story 03 | 메모리를 잡은 채로 놓지 않는다
① 오픈 시스템은 원인 구분이 어렵다
② ‘계속 사용중’이 다운으로 이어진다
③ C언어뿐만 아니다
④ 소프트웨어에 이중화는 적용되지 않는다
Chapter_04 접속 쇄도를 견디지 못하고..._성능 및 용량 부족 문제
story 01 | 하드웨어의 성능을 다 살릴 수 없다
① 타임아웃이 만연하는 실상
② 원인은 하드웨어 자원 부족만이 아니다
③ 시스템 성능을 좌우하는 소프트웨어 자원
④ 파라미터 설정은 균형이 중요
⑤ 웹 서버의 소프트웨어 자원 부족으로 처리 지연
⑥ 과부하 상태에서만 발생하는 문제
⑦ 하드웨어 증강 시 재점검을 잊어버리다
⑧ 재시도를 100번 반복했더니 다운
⑨ 발단은 단 하나의 확장 누락
⑩ 테스트 방법이 확립되지 않은 것이 화근
story 02 | 메모리와 CPU가 부족하다
① 성능 설계 실수로 가동 첫 날 응답 저하
② 애플리케이션이 너무 많아서 메모리 부족으로
③ 액세스 증가가 CPU의 성능 부족을 일으킨다
④ 무한 루프가 리소스 부족으로 이어진다
⑤ 4대 중 3대가 고장나도 75% 성능을 유지하는 구성
story 03 | 통신 데이터 증가가 다운을 초래한다
① 통신 대혼란을 야기한 L3 스위치 1대의 고장
② ‘메인’ ‘보조’여야 하는데 2대 모두 ‘메인’으로
③ 펌웨어 문제로 ‘루프’가 발생
④ 무서운 통신 데이터 ‘폭주’
⑤ 라우터의 경로 정보가 갱신되지 않는다
⑥ 데이터 집중으로 서버가 정지
story 04 | 데이터베이스가 가득 차서
① 거래 증가로 로그 파일이 펑크 직전
② 빈 공간이 있는데도 용량 부족이 되는 경우도
③ 배치 처리의 파일 용량이 병목 현상을
④ 배치 처리가 원인으로 온라인을 긴급 정지
story 05 | 날이 새도 끝나지 않는 배치 처리
① ETC와 전자화폐와 배치 처리의 밀접한 관계
② 오픈회로 확장성 확보가 진행된다
③ 너무 빨리 끝나 ‘이상’으로 오인
COLUMN | 여기는 시스템 다운 상담실_운용 담당자는 혼나는 역할?___개인을 추궁해도 다운은 줄지 않는다
Chapter_05 ‘몰랐다’는 허용되지 않는다_환경설정 및 변경 실수
story 01 | 깜박 잊어버린 파라미터 변경
① 8년만의 단말기 추가에 함정이
② 1년전의 설정 오류가 표면화되어 전철이 긴급 정지
③ 국가 시험 합격자가 불합격으로
④ 테스트에서 발견되지 않은 경우가 대부분
story 02 | 시스템 환경의 변경 실수
① 데이터의 저장 위치를 정리했더니 다운
② 메인 서버에서 버그 수정, 모듈 등록에 누락
③ 절차 위반이 라이브러리 관리 실수를 초래
④ 잘못해서 구버전을 사용하다
⑤ 리허설 후에 환경 되돌리기 작업을 잘못함
story 03 | 패치 파일의 적용을 잊어버림
① 다운으로 이어지는 중요한 문제를 방치
② 제조업체의 경고를 무시하다
③ 무시하기 쉬운 보수 지원 체제 확립
story 04 | 달력 설정 실수
① 요일과 날에 따라 다른 운전 시간과 배치 처리
② 일요일과 월말이 겹쳐져 문제 발생
③ 조합 테스트로 막을 수 있다
Chapter_06 ‘깜박 실수’가 치명타_운용 및 조작 실수
story 01 | 운용 명령을 잘못 내리다
① 운용 조작의 완전 자동화는 무리
② 개발 서버라고 착각하여 운영 서버를 오작동
③ 안내 표시가 효과 없이 ATM 4,000여 대가 정지
④ 두 가지 삭제 명령의 사용 구분을 잘못함
⑤ 다중 확인이나 사전 체크에도 한계가
story 02 | 데이터 이전 및 입력 실수
① 버그가 없는데 신구 시스템의 결과가 맞지 않는다
② 누락되기 쉬운 부분 데이터의 병행 갱신
③ 위험한 작업은 잊어버릴만 하면 찾아온다
④ 이용자의 데이터 입력 실수가 원인인 경우도
⑤ 연금 기록 문제는 질 나쁜 실수의 전형적인 예
story 03 | 보조 시스템의 전환이 실패
① 데이터베이스가 메인 시스템과 일치하지 않고
② 자동으로 전환된다고 착각
③ 다운되지 않았는데 전환시키는 ‘반대 발상’
story 04 | 혼란이 ‘2차 재해’를 낳아 피해 확산
① 3대 대형 은행에서 있었던 ‘중복 인출’ 사건
② 데이터 입력의 중복 조작이 발생
③ 혼란 시에 일어나기 쉬운 ‘JCL’ 변경 실수
④ ‘복구용 기능이 없다’고 후회해도 소용없다
Chapter_07 설마 이런 일이_하드웨어 고장 및 불의의 사고
story 01 | 서버가 고장났다
① 대형 서버는 내부 회로까지 완전 이중화
② 있을 수 없는 2대 동시 고장이 현실로
③ 교체하기 10일 전에 고장
④ 디스크 장치의 동시 고장에 대비하는 ‘RAID6’
story 02 | 통신 네트워크가 불통
① L3 스위치가 가동 500일째 고장
② WAN 서비스 정지로 ATM 600대가 정지
③ 케이블 절단이나 포트 접속 불량도
④ 지상 케이블은 지진에 약하다
story 03 | 컴퓨터, 전기가 없으면 그저 상자일뿐
① 전원 장치에서 이중 고장이 발생
② 화재를 막기 위해 전력 공급을 중단
③ 불과 1초의 정전으로 다운
story 04 | 지진으로 데이터센터가 파괴 소실
① 때로는 일부러 복구시키지 않는 판단이 필요
② 화재로 담당자가 밖으로 피난, 운용 조작이 불가능
COLUMN | 여기는 시스템 다운 상담실___다운이 줄어서 곤란하다?
Chapter_08 트러블 대처는 시간과의 싸움_다운에서 배운다
story 01 | 원인 규명보다는 복구를 우선
① 다운은 ‘나쁜 것’인가?
부록 | 본문 용어 Index
story 01 | 정지=다운은 오해
① 단 하나의 실수가 치명타
② 예외 루트에 숨어 있는 함정
③ 100% 막는 것은 무리라는 현실에 관심을 갖자
④ 근본 원인을 찾아내기까지가 승부수
story 02 | 다운의 원인은 네 가지로 나눌 수 있다
① 다운 상황에 원인의 힌트가 숨겨져 있다
② 네 가지 문제가 연쇄적으로 일어나 ATM 11만 대에 영향을 주다
Chapter_02 제대로 테스트했을텐데..._애플리케이션 소프트웨어 문제
story 01 | 갑자기 눈을 뜨는 20세기 버그
① 시점을 바꾼 여덟 가지 테스트를 반복한다
② 아무리 테스트를 반복해도 버그는 남는다
③ 설마 데이터 복구 프로그램이 전체 데이터를 삭제하다니
④ 하나의 버그가 400억엔(약 4,000억원)의 손실로
⑤ 5개의 조건이 가동한 지 6년째에 처음으로 일치하다
⑥ 정지시키지 않은 것이 화근이었다
⑦ ‘데이터 이전’은 범인 찾기가 어려워
⑧ 회귀 데이터를 찾을 수 없어
story 02 | 잊어버릴만 하면 찾아오는 ‘날짜 문제’
① 윤년의 19년 전은 윤년일까?
② 2100년 2월 28일에 큰 트러블이
③ 34년 먼저 발생한 ‘2038년 문제’
④ ‘30%만 이상’이라 찾기 힘들다
⑤ 자리 넘침으로 ‘2001년 9월 9일 문제’ 발생
⑥ 2036년을 주목하자
⑦ 날짜 문제가 아닌 ‘자리 넘침’ 문제도
CLOUMN | 여기는 시스템 다운 상담실___트러블 대책에 쫓기는 개발 기술자
Chapter_03 애플리케이션뿐만이 아니다_OS, 미들웨어의 이상
story 01 | 정지를 감지 못하다
① 블랙박스의 무서움
② 다섯 종류의 이중화의 차이를 알자
③ 다잉 메시지를 캐치 못하고
④ 클러스터 소프트웨어가 작동하지 않아
story 02 | 조합을 바꿨더니 움직이지 않는다
① 동일 업체의 소프트웨어인데도 궁합이 나쁘다니
② 업무 애플리케이션과 OS의 조합 검증이 누락
③ 패치 적용이나 버전업에 리스크 있음
④ 오래된 소프트웨어와 최신판 중 무엇을 고를까?
⑤ 실적으로 고른 메인 프레임 제품에 버그
⑥ 성능이 너무 높아져 15년 전의 문제가 드러남
⑦ 검증 책임은 이용자에게 있다
story 03 | 메모리를 잡은 채로 놓지 않는다
① 오픈 시스템은 원인 구분이 어렵다
② ‘계속 사용중’이 다운으로 이어진다
③ C언어뿐만 아니다
④ 소프트웨어에 이중화는 적용되지 않는다
Chapter_04 접속 쇄도를 견디지 못하고..._성능 및 용량 부족 문제
story 01 | 하드웨어의 성능을 다 살릴 수 없다
① 타임아웃이 만연하는 실상
② 원인은 하드웨어 자원 부족만이 아니다
③ 시스템 성능을 좌우하는 소프트웨어 자원
④ 파라미터 설정은 균형이 중요
⑤ 웹 서버의 소프트웨어 자원 부족으로 처리 지연
⑥ 과부하 상태에서만 발생하는 문제
⑦ 하드웨어 증강 시 재점검을 잊어버리다
⑧ 재시도를 100번 반복했더니 다운
⑨ 발단은 단 하나의 확장 누락
⑩ 테스트 방법이 확립되지 않은 것이 화근
story 02 | 메모리와 CPU가 부족하다
① 성능 설계 실수로 가동 첫 날 응답 저하
② 애플리케이션이 너무 많아서 메모리 부족으로
③ 액세스 증가가 CPU의 성능 부족을 일으킨다
④ 무한 루프가 리소스 부족으로 이어진다
⑤ 4대 중 3대가 고장나도 75% 성능을 유지하는 구성
story 03 | 통신 데이터 증가가 다운을 초래한다
① 통신 대혼란을 야기한 L3 스위치 1대의 고장
② ‘메인’ ‘보조’여야 하는데 2대 모두 ‘메인’으로
③ 펌웨어 문제로 ‘루프’가 발생
④ 무서운 통신 데이터 ‘폭주’
⑤ 라우터의 경로 정보가 갱신되지 않는다
⑥ 데이터 집중으로 서버가 정지
story 04 | 데이터베이스가 가득 차서
① 거래 증가로 로그 파일이 펑크 직전
② 빈 공간이 있는데도 용량 부족이 되는 경우도
③ 배치 처리의 파일 용량이 병목 현상을
④ 배치 처리가 원인으로 온라인을 긴급 정지
story 05 | 날이 새도 끝나지 않는 배치 처리
① ETC와 전자화폐와 배치 처리의 밀접한 관계
② 오픈회로 확장성 확보가 진행된다
③ 너무 빨리 끝나 ‘이상’으로 오인
COLUMN | 여기는 시스템 다운 상담실_운용 담당자는 혼나는 역할?___개인을 추궁해도 다운은 줄지 않는다
Chapter_05 ‘몰랐다’는 허용되지 않는다_환경설정 및 변경 실수
story 01 | 깜박 잊어버린 파라미터 변경
① 8년만의 단말기 추가에 함정이
② 1년전의 설정 오류가 표면화되어 전철이 긴급 정지
③ 국가 시험 합격자가 불합격으로
④ 테스트에서 발견되지 않은 경우가 대부분
story 02 | 시스템 환경의 변경 실수
① 데이터의 저장 위치를 정리했더니 다운
② 메인 서버에서 버그 수정, 모듈 등록에 누락
③ 절차 위반이 라이브러리 관리 실수를 초래
④ 잘못해서 구버전을 사용하다
⑤ 리허설 후에 환경 되돌리기 작업을 잘못함
story 03 | 패치 파일의 적용을 잊어버림
① 다운으로 이어지는 중요한 문제를 방치
② 제조업체의 경고를 무시하다
③ 무시하기 쉬운 보수 지원 체제 확립
story 04 | 달력 설정 실수
① 요일과 날에 따라 다른 운전 시간과 배치 처리
② 일요일과 월말이 겹쳐져 문제 발생
③ 조합 테스트로 막을 수 있다
Chapter_06 ‘깜박 실수’가 치명타_운용 및 조작 실수
story 01 | 운용 명령을 잘못 내리다
① 운용 조작의 완전 자동화는 무리
② 개발 서버라고 착각하여 운영 서버를 오작동
③ 안내 표시가 효과 없이 ATM 4,000여 대가 정지
④ 두 가지 삭제 명령의 사용 구분을 잘못함
⑤ 다중 확인이나 사전 체크에도 한계가
story 02 | 데이터 이전 및 입력 실수
① 버그가 없는데 신구 시스템의 결과가 맞지 않는다
② 누락되기 쉬운 부분 데이터의 병행 갱신
③ 위험한 작업은 잊어버릴만 하면 찾아온다
④ 이용자의 데이터 입력 실수가 원인인 경우도
⑤ 연금 기록 문제는 질 나쁜 실수의 전형적인 예
story 03 | 보조 시스템의 전환이 실패
① 데이터베이스가 메인 시스템과 일치하지 않고
② 자동으로 전환된다고 착각
③ 다운되지 않았는데 전환시키는 ‘반대 발상’
story 04 | 혼란이 ‘2차 재해’를 낳아 피해 확산
① 3대 대형 은행에서 있었던 ‘중복 인출’ 사건
② 데이터 입력의 중복 조작이 발생
③ 혼란 시에 일어나기 쉬운 ‘JCL’ 변경 실수
④ ‘복구용 기능이 없다’고 후회해도 소용없다
Chapter_07 설마 이런 일이_하드웨어 고장 및 불의의 사고
story 01 | 서버가 고장났다
① 대형 서버는 내부 회로까지 완전 이중화
② 있을 수 없는 2대 동시 고장이 현실로
③ 교체하기 10일 전에 고장
④ 디스크 장치의 동시 고장에 대비하는 ‘RAID6’
story 02 | 통신 네트워크가 불통
① L3 스위치가 가동 500일째 고장
② WAN 서비스 정지로 ATM 600대가 정지
③ 케이블 절단이나 포트 접속 불량도
④ 지상 케이블은 지진에 약하다
story 03 | 컴퓨터, 전기가 없으면 그저 상자일뿐
① 전원 장치에서 이중 고장이 발생
② 화재를 막기 위해 전력 공급을 중단
③ 불과 1초의 정전으로 다운
story 04 | 지진으로 데이터센터가 파괴 소실
① 때로는 일부러 복구시키지 않는 판단이 필요
② 화재로 담당자가 밖으로 피난, 운용 조작이 불가능
COLUMN | 여기는 시스템 다운 상담실___다운이 줄어서 곤란하다?
Chapter_08 트러블 대처는 시간과의 싸움_다운에서 배운다
story 01 | 원인 규명보다는 복구를 우선
① 다운은 ‘나쁜 것’인가?
부록 | 본문 용어 Index
