울프맨
접속 : 4344   Lv. 155

Category

Profile

Counter

  • 오늘 : 818 명
  • 전체 : 2732428 명
  • Mypi Ver. 0.3.1 β
[일기? 일상?] 결국 핵지뢰가 터졌다. (12) 2013/04/19 AM 09:50

내가 짜놓은 핵심로직의 불완전성이 언제나 불안한 나머지 나는 매일 하루3번씩 프로그램의 전체 재고 파악 및 정상여부를 돌린다.

그리고 그런 군데군데 위험성이 있는 로직들을 '핵지뢰'라고 명명하고 작게 터지면 바로 로직을 수정하고 복구하는 등 팀장과 동료들에게 알리지 않은 작업을 은밀하게 해오고 있었다.
대부분의 오류나 데이터 문제는 내 손안에서 처리가 가능한 상황이기 때문에 그렇게 잘 버텨오고 있었는데....

어제 대 비상상황이 발생하고야 말았다.

문제의 발생은 오후 3시경.
그날도 평소처럼 각 창고별 데이터가 이상이 없음을 확인하고 다음 창고의 데이터로 넘어가는 찰나, 재고에 대량의 마이너스 품목이 발생한 것을 파악했다.

사실 그 발생한 창고는 평소에 잘 안보던 창고였고, 지난 마이너스 총 집계 및 추적때도 빠뜨린 것 같아서 난 속으로 웃으면서 '아 이런 빠뜨린게 있었네? ㅋ' 하고 일하는 틈틈히 그 데이터를 복원했다.

그리고 다음 창고에도 그런게 있길래 복원했다. 그렇게 한게 대략 5시.

이제 마이너스도 잡았겠다. 전체가 깨끗한지 보려고 다시 처음 보던 창고로 돌아갔다.
동시에 난 기겁을 할 수 밖에 없었다.

분명히 3시경에 봤을땐 모두 정상이던 재고가 대량으로 마이너스가 발생했던 것!!!
'내가 헛것을보나? 이게 뭐지? 대체 이게 뭐야?!?!?!'

결코 프로그램이 거짓말을 하는 경우는 없으니 이성으로는 '이건 현실이다' 라고 파악하면서도 마음은 그렇지 못해서 몇번이고 다시 조회버튼을 눌러보고 DB로 찾아본 끝에 파악을 끝마쳤다.

[드디어 핵지뢰가 터졌다............]

이미 전 창고에 마이너스가 나타나고 있었고, 그 분량은 내가 은밀히 혹은 개인적으로 처리할 수 있는 범위를 벗어난 양이었다.
결국 신입사원을 불러 정중히 부탁. 내가 사용하는 복구 로직을 알려주며 함께 처리해나가도록 지시를 했는데, 이걸 팀장님이 보고마셨다............

팀장님
-울프씨. 지금 뭐하는거야?


-.........(정황설명)

팀장님
-울프씨. 마이너스 났다고 고치는게 중요한게 아니야
-원인을 파악해야지.


-원인을 파악해도 파악할 수가 없어서..... 일단 복구를 시키고 몇가지 샘플을 채취해서 DB복원한다음에 테스트 해보려고 했습니다;;;

팀장님
-혼자 생각해선 안될때가있어.
-P대리,신입씨

P대리
-넴

신입
-네. 네?

팀장님
-개발자 전원 비상회의야 모두 들어오세요.

그래서 4명이서 각각 DB를 뜯어보고 히스토리 내역과 트리거를 분석하며 가능성 체크를 했다.

그런데 이 체크들이 다 핵지뢰가 터졌다고 판단한 이후에 즉시 내가 체크한 것과 다를게 없어서, 결국 결론은 '원인불명'
마이너스를 야기하는 테이블의 데이터가 삭제되려면 트리거 로직상 특정 테이블 수량이 변경되거나 기타 조건을 만족해야하는데, 그 조건 테이블의 변동내역이 전혀없었던 것이었다.

게다가 내가 만든 복구 로직으로 전부 고쳐질 만큼, 지워진 패턴이 동일해서 '정말 한가한 누군가가 의도적으로 날리려고 마음을 먹고' 하지 않는 이상 대량으로 동시다발적으로 지워질리는 없는 것인 상황이었다.

그래서 그간 작업한 내역들을 각자가 보고하고 데이터에 영향을 미칠 상황도 조사했지만 역시나 없고.......

결국 해당 테이블에 지워지지 못하도록 안전장치를 거는 것으로 회의를 마감했다.

그리고 팀장님 왈 '봤지 울프씨. 수정하는게 능사가 아니야. 대책을 마련해야지'

그래서 어제 회의때문에 2시간을 소모해서 신입사원과 내가 데이터를 복구하는데 밤 12시까지 일했다.



아.................. 내잘못이 아니면 누군가의 테러인가........................
뭘까 정말...............

신고

 

㈜스톤콜드    친구신청

그런경우에는 생각하지 못한곳에서 문제가 튀어나오더라구요

netknight    친구신청

마지막 글 : 회의 때문에 2시간을 소모해서 복구하는데 밤 12시까지 일했다. 안전장치는 복구후에 해도 될 상황이었던거 같네요.
그나저나 누가 손댔는지 의도적이었던건지 아니면 미스테리 자연발생적인 일이었는지 미궁인거군요.

울프맨    친구신청

netknight//프로그램 데이터가 자연발생하는건 있을 수 없는 일이니 분명히 어딘가의 버그나 누군가의 데이터 날림인데, 짐작가는 쪽이 없다는거죠 ㅋ;;;;

hinamania    친구신청

가끔 윗쪽에계신분이 맘에안들어서 장난 치실때가 있던데요
제가 있는쪽에서일이지만요.
그런경우 대체적으로 자기가 알아채지않고 누군가가 알아챈걸 자연스럽게 안거 처럼 접근한후 대대적으로 까대기를 하더군요.

gunpowder06    친구신청

범인은 팀장...

   친구신청

변수 설정, 오타, 주석처리 에서 나느경우가 좀 많더군요

가카인    친구신청

지뢰 터질 것에 대비하여 우리는 항상 로그를 남겨야 합니다.

쿠타라기켄    친구신청

데이터 베이스의 연산 체계가 IEEE연산과 다르지 않나요? 예를 들어 윈도우의 계산기는 IEEE 연산으로는 감당이 안되서 분수라이브러리를 쓴다고 하더군요. 데이터베이스도 일반 IEEE연산과는 다를 거라고 봅니다. 대표적으로 VB도 IEEE연산과는 다르더군요. 전산으로 전달되는 숫자는 모두 같은 체계를 사용해야 오류가 없는 걸로 알고 있습니다. 잘 못 만들면 일부만 통일되고 일부는 통일이 안되는 경우가 발생하여 특정한 숫자가 DB에 잘 못 쌓일 수도 있다고 알고 있습니다.

따마    친구신청

DB 로그를 추적하면 앙대나..

가카인    친구신청

그래도 모르면 더욱 상세한 로그를 남겨야지요 '';

설영시    친구신청

.. 답은 로그를 남기는게 최고.. 그래서 상황 재현 해봐서 100% 나오는 케이스를 찾아보는 수밖에 없지요..
쓰레드나 이런게 오작동할 수도 있는 거라서..
캐스팅 오류라던가.. 등등등...
대량의 I/O가 있는 상황이 아니면 I/O에 대한 로그를 남겨놔도..

hapines    친구신청

회사에 있는 우렁각시가 직원들 모두 퇴근하고나면 튀어나와서 데이터를 지웁니다.
X