서버 > 부.. 부끄럽다능 //

담당자를 두명으로 하고 교체..;;

방어적으로 프로그램하다 보면 조금의 인컨시스턴시가 눈덩이 처럼 불어나 결국 원인파악이 불가능할때 뒈지죠. 낄낄

이거야말로 관찰이라는 행위 자체가 실험의 결과에 영향을 끼치는 경우군요!

세부 상황이나 수순에 대한 정확한 예측만으로 대처가 가능했으면, 애당초 법칙으로 불리지도 않았을 겁니다...

멀티 쓰레드 서버라면 로그 박는게 컨텍스트 스위칭 타이밍을 바꾸므로 이전에 나던 버그가 안나는 경우는 비일비재...

그런데 서버 다운 시점에 담당자가 자리를 지키고 있어야 할 필요가 있나요?

어짜피 다운되면 덤프 남기고 서버는 자동 리스타트 될거고,

담당자가 서버가 장렬히 사망하시는 장면을 직접 본다 한들 디버깅엔 하등 도움이 안되므로..

그냥 서버는 터지게 놔두고 덤프나 열심히 서버 플머에게 던져 주면 그만.. [..]

이 건에 대해선 민감한 (+민망한) 부분이라 답글은 생략합니다. ~_~

Testors // 보통 그게 정석인데.. 윗분들은 프로그래머가 보고 있다라는 사실에 만족하시잖아요???

Ged/ 프로그래머가 보고 있는걸로 윗분들은 만족하지 않음. 단지 보고 있는 동안은 잔소리를 안하는 것일 뿐. 그걸 '만족하고 있다' 라고 받아들인다면 오산.

'지금 문제를 해결하려고 노력 중입니다' 라는 시그널을 윗분들에게 주지 않으면 당연히 윗분들은 잔소리를 하게 됨. 그게 그들의 일이고 만약 잔소리를 안한다면 그건 윗분들이 직무유기를 하고 있는것이거나 혹은 실무자를 매우 믿고 있다는것.

'구지 서버가 터지는 장면을 보지 않아도 디버깅엔 문제 없다' 라는건 실무자 레벨의 지식. 윗분들이 그에 대한 지식 부족으로 실무자를 귀찮게 구는것은 당연히 일어날 수 있는 일이고, 그때 실무자는 그럴 필요 없다는걸 이해시킬 의무가 있음.

물론 개발자가 '우리 윗분은 이런걸 몰라.. 개념이 없으니까..' 라고 생각하고 단지 잔소리를 안듣기 위해서 그냥 의미없이 화면을 쳐다보는 선택을 하는건 자유. 그런데 그런 개발자하고는 같이 일하고 싶지 않을듯. :P

Testors / 본문에 썼던 상태처럼 두어시간마다 죽는데다가 이유도 모르는 상태라면 약이 없습니다. -_-

보통 아무리 어려운 문제라도 서버를 죽인 근본적인 원인은 몰라도 직접적인 원인은 알아야 하는데 어떻게 그런 일이...