KT 사고 미스터리…협력업체는 왜 야간작업을 낮에 했나 (msn.com)
제가 보기에는 협력업체 직원이 전산쪽에 일을 많이 안해본 신입이거나
어느정도 경력이 된 직원이라도 네트워크 장비 하나 교체 하는데 네트워크 부하를 그렇게 많이
받겠어? 이런 안일한 생각으로 만들어낸 사고가 아닐까 싶네요
야간에 작업 했으면 네트워크 트래픽이 많이 없기에 가능하겠지만 한 낮에 11시 부터 12시까지는
밥 먹으러 온 손님들도 있는 시간대인데 그때 네트워크 장비 교체 작업을 한 것은
밥 장사 하는 자영업자들 골탕 먹이는 거였죠
19개의 댓글이 있습니다.
희안하네요.... 분명 테스트를 충분히 해봤을텐데....
드래그 복사할때 맨밑에 줄을 빼먹었나....
일반 기업들도 아무리 작은 작업할때도 업무영향 고려해서 스케줄 정하는데
전국적인 서비스를 하는 국내 탑수준 통신업체에서 너무 안이하게 생각하고 작업했던게
이런 참사를 가져온 것 같습니다.
아마도..
야간 작업을 하면 KT 담당자자도 야근을 해야 하니 .. 그래서 주간에 시도하지 않았나 생각이드네요.
정말이지 중요 작업을 점심때 했다는것 자체가 문제였고
협력사도 문제지만 KT 담당자도 문제가 크네요
IT쪽에 종사하고 계신다면 사고 영향이 커든 적든 이와 유사한 사고 경험들은
한두번정도는 있었을겁니다.
일반적으로 명령어 누락과 같은 실수는 흔하죠.
다만, KT처럼 국가기간망 관리 사업자의 경우는 더 철저한 절차와 프로세스 관리가
되지 못한게 아쉬운 부분이네요.
다들 의견이 비슷하시겠지만,
협력 업체의 작업 오류 일어날 수 있는 사고 입니다.
사람이 하는 작업이기에 아무리 꼼꼼하게 검토를 하고 해도 문제는 발생이 되죠...
하지만, 하나의 작업 실수로 전국적인 네트워크 마비가 일어나는 문제,
과연 KT 직원의 승인 없이 협력업체가 무단으로 작업을 했을까 하는 생각은 드네요~~
그러게요 야간 작업 하도록 해야 하는데 저런 작업을 낮에 하게금
방치한 잘못도 있죠
KT가 맘에 안들죠~문제생기면 다들 하청업체 탓하고 진짜
방금 전에 올라온 따끈따끈한 보도 자료 공유합니다.
https://www.msit.go.kr/SYNAP/skin/doc.html?fn=0fcac17d6b390c0ecd4a795b3ebe9577&rs=/SYNAP/sn3hcv/result/
is-is protocol 마무리 부분에 exit 명령을 빼먹어서 이런 사태가 생겼다네요.
예전에 COBOL 프로그래밍하면서 끝에 점하나 안찍어서 생긴 오류 찾느라 몇날 몇일 고생한적이 많았었는데... ㅎㅎㅎ
눈에 잘 보이지도 않는 . 하나 때문에... 고생 많이 했던걸 생각해 보면...
사람이기 때문에 그런일이 생길만도 하다는 생각이 듭니다~ ㅎㅎ
예전에 UNIX CLI 명령으로 SMS 문자 수십만건씩 한번에 보내는 경우가 종종 있었는데...
Enter 키를 입력할때 얼마나 떨리던지...
칠까 말까 몇번씩 손이 내려갔다 멈췄다... 반복하다가 결단을 내리고 눌렀던 기억이... ㅎㅎ
나중에는 조금 번거롭고 시간이 걸리더라도 실제 발송처리전까지 시뮬레이션 한번해보고 발송을 위해 전달하려는 자료들을 대충이라도 쭉~ 살펴보고 보내는 걸로 프로그램 수정 본을 하나 더 만들어서 사용했었는데...
아마도 그 직원이 중요한 라우팅 테이블 값을 제거 해 버렸거나 엉뚱한 경로값을 집어 넣어 버렸을 것 같아 보이네요.
맞습니다. 사실 이번 사고 또한 내부에서 모의 테스트 (dry run)를 진행하는 절차가 있었거나, 작업을 진행하기 전에 제대로 확인했으면 일이 이렇게까지 커지지 않았을 거에요.
네임서버에 DDoS 공격이 있었다고 발표했는데, IP를 활용하는 통신과 LTE 망까지 왜 떨어졌을까요.. 정말 교환기로 연결되는 서킷 망 빼고 다 죽었는데, 그 와중에 IPTV는 잘 됐잖아요? IPTV는 일반적인 라우팅 경로를 따르지 않고 IGMP 스트림으로 받으니깐요. 예전에 미라이 봇넷 공격처럼 코어 망을 떨어뜨릴 수 있는 공격이었다면 IPTV까지 안되어야 하는데..
이번 사고는 너무나 라우팅 오류로 일어난 정황과 근거가 많아 보입니다.
저도 엔지니어 일 하면서 KT 쪽 작업 여러번 해봤는데...해명이 이해 되지 않는게
작업을 진행하기 전에 작업계획서를 제출하고 담당자 자리에서 ssh 나 telnet 을 이용해서 장비에 접속을 하는데
실제적으로는 클라이언트 프로그램에서 명령어를 입력해도 실제 장비에 반영이 바로 안되고
담당자 비밀번호 또는 otp 를 입력해야 장비에 실제적으로 설정이 업로드 됩니다.
KT 쪽 해명이나 협력업체 실수가 아닌 다른게 분명히 있었을겁니다...
저의 부장님도 단순히 명령어 몇줄 잘못 친 걸로 이런 사고가 터진 게 아니라
다른 해킹 공격에 의해서 문제가 생긴 건데 괜히 그런 일들이 이슈가 생기면 복잡해니깐
가장 만만한 협력 업체 탓을 한 게 아니냐 라고 추측 하시더라구요
역시 사람의 손으로 터진 문제라.. 제일 중요한 건 그래서 이게 고쳐질까요?
만약에 계속 이렇게 간다면 문제가 또 터질 게 분명한데, 그동안 있었던 일을 보면 잘 모르겠네요.
게다가 사람의 손이 가는 소프트웨어부터 바꾸는 것도 중요해 보입니다.
장비하나 세팅 오류로 전국이 마비된다는 것이 이해가 잘 안되요..
그냥 욕받이로 협력업체를 팔은 거 같습니다.
협력업체 실수라고 말 할 거라는 건 충분히 예상되었지요..
그냥 제 생각인데 보통 저런 작업들은 하청 업체들이 하기에 협력업체 직원이
실수한 거 맞은 거 같아요 제가 SK 에서 잠깐 일했을때에도 대부분 하청 업체 직원들이
와서 작업을 하죠 정직원들이 직접 안하죠
썰에 의하면 KT 정직원중에는 라우팅 테이블 만질줄 아는 사람이 없다는 얘기도 있습니다.
보통 KT와 미팅을 하면 협력업체와 KT 영업이 오죠 ^^~