3군사에서 망 떨어진걸 우리보고 욕하던 군단장 ^오^

미안행..

ㄹㅇ 인트라넷 나가면 통신반장부터 먼저 불러서 갈굼

그럴때마다 존나 서러움

오전에 30분정도 먹통됐었음

문제가 뭔지 알아도 해결은 못함

ㅇㅇㅋㅋ 알아도 해결은 못하지 구글쪽 인프라니까 그냥 전산팀이면 어지간해선 아는데 제가 그걸 어떻게 알아요!!라고 하는 경우는 보기 힘들어서 ㅋㅋㅋ

인덕원에 계신가요.....

인덕원이 모야?

농협전산센터

농협전산센터가 그쪽에 있군.. 나는 인덕원에 없어...

노놉. 네트워크 장비가 죽었으면 아예 오류화면 자체가 안뜨겠지?

저런건 대부분 데이터베이스랑 WAS랑 연결이 제대로 안되어서 그런경우가 많아. 방화벽 세팅이 조금 꼬였을때가 대부분이지.

방화벽 세팅이 꼬이면 아예 통신이 안됨 왜냐면 방화벽 자체가 포트나 아이피 기반 차단되서 아예 통신이 단절되기 때문이지.

즉 꼬인다 = 오류 화면 자체도 안뜬다.

네트워크 장비가 죽어도 오류화면이 뜨는 이유는 요즘 전산 고도화 후 구성을 WEB이랑 WAS, DB를 존 분리를 해서 놓기 때문에 WEB은 구동되면서 WAS쪽 응답 없으니 오류 화면이 정상적으로 출력 됨 기타 메뉴나 로그인 페이지도 잘 나오고 그럼 WAS냐 DB냐 문제인데 DB쪽 문제였으면 로그인도 안돼 되면 이상하겠지? 한 서비스에 DB서버를 용도 별로 여러개 분리하는 경우는 금융쪽밖에 없으니까

그리고 제일 핵심은 만약 방화벽 세팅 문제였다면 복구에 저렇게 시간이 걸릴 수 없어 작업계획만 살펴보면 답 나오는걸

아니다 생각해보니까 오류 화면이 뜰 수 있겠다. 결국 방화벽 문제나 네트워크 장비 문제나 통신 장애니까 WEB쪽이 살아있고 서비스가 안되면 오류 화면도 충분히 뜰 수 있겠네.

그렇게 만들어 놓는다면 말이지.. 결국 서비스 복구시간으로 밖에 예측할 수 없는 건데 방화벽 세팅 복구 시간, 네트워크 장비 복구 시간 중 가장 예상되는 것을 얘기하면 되겠네. 합리적으로 뭐가 더 오래걸리는지.

데이터센터에서 server support specialist 로 트러블슈팅 담당자로 2년 일했다. 방화벽 장비가 있어도 이게 세션이 즉시 끊어지지 않는 경우도 있음... 저렇게 대규모 서비스는 대부분이 데이터베이스랑 와스랑 커넥션하는데에 문제가 생긴거야. 그거 아니면 데이터베이스 패스워드랑 와스미들웨어에 타이핑된 패스워드가 일치하지 않는 경우도 종종 있고...

방화벽 정책도 확인하는데에 시간 제법 걸려. 우리 회사는 규모가 많이 큰편인데 7종정도 거친다. 방화벽이 한두개여야지....

댓글 이제 봤네.

일단 방화벽 장비의 정책 문제였을 경우, 최대 2~3초 내로 바로 끊어진다고 보면 돼 즉시 끊어지지는 않지만 사람의 입장에서 보기에는 정책이 적용된 시점에서 필터를 시작하니 바로 알 수 있지. 내 생각에 네가 통합로그나 통합관제 통해서 보다보니 syslog 전송되서 보는거 체킹하는거면 그렇게 느낄 수 있다고 봐 관제쪽에서는 약간 시간이 소요된 뒤에 장애 알람이 뜰테니까(만약 이건 아닌데 싶으면 시큐아이나 안랩 파이오링크 같은 곳 고객센터 전화해서 물어보면 즉시 끊긴다고 답변올거야)

그리고 만약 WAS쪽 미들웨어에 패스워드 기간 만료일 경우에는 서비스 장애 발생 시에는 어떤 곳이든 해당 DB 서버랑 WAS먼저 바로 터미널이나 콘솔 접속해서 미들웨어 패스워드랑 라이센스 만료부터 체크하거나 대장에서 관리하기 때문에 어지간한 규모 이상이면 거의 길어야 10분이내에 처리될 수 있는 장애야.

그러니 1시간 이상의 장애는 있을 수 없는 일이지.

그리고 방화벽 정책 확인에 큰 시간이 걸리지 않는 이유는 정책 적용 전에는 무조건 작업관련 이력을 남기거나 남기지 못했을 경우(말도 안되는 이야기지만 실수로 정책 적용 확인을 2~3회 걸쳐 그냥 생각없이 눌렀을 때)통합로그관리시스템이나 통합관제시스템 통해서 스위치 다운 포트쪽 알람이 바로 뜨기 때문에 체킹에 시간이 오래 걸릴 수 없음.... 특히 10~20년이상된 IT기업이나 집적정보통신시설의 경우에는 상주 네트워크 엔지니어나 방화벽 엔지니어가 있기 때문에 체킹 시간이 오래걸릴 수 없지.. 만약 1% 확률로 오래 걸렸다면 인프라 관리 쪽 엔지니어 실력이 전부다 기대 이하로 SLA에 낙제점을 받는 케이스임. 근데 나는 구글이 데이터센터 운영하는데 SLA 관리를 그렇게 형편없이 했을 거라고 생각하지는 않거든.

그리고 WAS랑 DB랑 통신이 끊어졌다고 볼 수 있지만 그 둘 사이가 직접적으로 끊어졌다고 보기는 어려운게..

1. WAS랑 DB는 동일한 서버팜에 구성해 즉 24포트 이상 스위치나 라우터에 한 구간내에 통신장비에 구성해둬서 장애가 터지면 동시에 죽거나 한 포트가 죽으면 금방 파악이 가능하거나 standby쪽으로 서비스가 최소 5분 내로 넘어감.

2. 만약 WAS랑 DB가 구간이 분리되어있다고 해도 그럼 내가 말한 것 처럼 중간에 standalone으로 구성된 L4같은 스위치에서 VIP 설정에 문제가 생겼다거나 로드밸런싱 중에 원인 모를 부하가 생겨 장비가 죽어서 복구 시간이 오래 걸렸다고 볼 수 있지.(아예 죽어버린 경우 이전에 백업한 config를 가져와서 세팅을 다시 해야 하는데 그동안 적용된 정책이 밀려있으면 그걸 일일히 검증하고 타이핑해서 쳐넣느라 오래 걸림)

과장놈이 알기 쉽게 설명해 줄 수가 없으니까

모른다고 일축한거다

글쿤ㅋㅋㅋ 내가 너무 꽉 막힌 군대 같은 곳에서만 일해서 그런가보다 보고할 때 저렇게 해보고 싶다.ㅋㅋㅋ

방화벽이 문제면 짜증나게 하지말고 UDP로 들어와서 투혼맵 잡고 있으란말이야

그거를 알아들을수준이면 전산실에 저딴거 물어보지도 않지 ㅋㅋㅋㅋ

언론사 뉴미디어쪽 부서일수도 있고.. 금융이나 정부기관 홍보 부서나 기획쪽 부서일 수 있징 사유는 생각해보면 많을듯 ㅋㅋㅋ

일 안하고 딴짓하는 관리자들 유튜브 잘 봄

옆에있던 아줌마 : 바람에 와이파이 신호가 날라가서 그래용~ 오홓ㅎ호호

자네가 고쳐보게

문과쉑ㅋㅋㅋㅋ