현직에서 일하시는 시스템 엔지니어 경력직분들에게 묻습니다.

jocdoc의 이미지

경력은 없으며 신입으로 혼자 일하고 있는 시스템 엔지니어입니다.

본론으로 들어가서 묻고 싶은 사항이

작은 기업이든 큰 기업이든 작업을 하실때의 업무 프로세스가 궁금합니다.

저 같은 경우 어떤 간단한 작업( 데몬에 대한 실행 스크립트, 중지 스크립트 등을 만드는 것)이라도 일일이

작업 보고서를 작성합니다. 이 부분은 당연할수 있는 부분이라 생각하며 불만은 없습니다만.

개인적으로 생각했을때 이렇게 까지 보고서를 작성해야 하나 하는 부분때문에 여러분들의 생각을 듣고 싶습니다.

문제는 어떤 문제나 장애가 발생했을 경우. 그 문제나 장애를 해결하고서 어떻게 해결했는지의 보고서를 작성했습니다.

보고서는 간단하게 "원인", "내용", "해결" 이렇게 구성하고서 엔지니어라면 보고 이해할수있는 수준이었습니다.

허나 상사께서는 해당 작업 내용에 대한 명령어 사용 내역까지 모두 다 게제를 하라고 하십니다. 단순히 파일을 찾고 지운것에

불과한대두요.(실제로 쓰인 명령어는 find, rm 둘 뿐입니다. 그것도 스크립트로 만든겁니다.)

원하시는 것이 이쪽일을 전혀 몰라도 보고서만 보고 따라할수 있도록 작성하라는데

보고서의 의미가 인수인계인지 메뉴얼인지 모호하게 느껴집니다. 보고서는 말 그대로 어떠한 문제나 작업에 대해 이렇게 했다라는
상사에게 보고하는 문서아닌가요. 뭘 할때마다 간단히 작성하는 보고서가 아닌 무슨 메뉴얼을 작성하는 기분이라 부담이 되는데요. 다른 곳도 일반적으로 이렇게 하시는지 궁금합니다.

annabel의 이미지

'이쪽일을 몰라도 따라할 수 있도록' 이라는 단서는 거꾸로 말하면 '아무것도 모르는놈 앉혀놔도 그 일을 할 수 있게 해놔라'와도 같습니다. 보통 협력업체들에게 운영을 맡기는 기업에서 그렇게 하는데 회사가 좀 크신가 봅니다.
아니면 단순히 윗분들이 그런걸 원하는 것일수도 있겠구요 :P

jocdoc의 이미지

대부분이 이렇게 일을 하시는건지 저희 회사가 유독 그런걸 원하는건지 알고 싶어서요.ㅠㅠ

bt의 이미지

제가 있는 곳에서는 장애 보고서에는 저렇게 자세히 적지 않습니다.

혹시 장애 대응 매뉴얼도 같이 만드는 것으로 이해할 수 있는 것일까요? 장애 매뉴얼에는 커맨드 라인 명령어도 모두 기록합니다. 다른 사람이 읽고 같은 장애에 대응할 수 있도록 빠뜨리지 않고 적습니다.

jocdoc의 이미지

그런거라면 당연히 그래야하는게 맞는거라고 생각합니다.

그러나 제가 이해할수 없는것은 장애해결에 복잡성이 좀 있는 것이라면 해결과정을 자세히 적는것이 맞으나

단순히 원인이 되는 파일을 찾아서 지우는 것 정도의 간단한 경우라도 자세히 써야한다는게 이해할수 없다는 것이죠;;

엔지니어라면 아무리 신입이라도 설마 find나 rm 을 모르진 않을꺼란 말이지요. 뭐 이야기를 하자면 너무 많지만 일례로

들어서 말씀드린겁니다. ㅠㅠ

김정균의 이미지

저는 장애 보고서에 장애를 해결한 명령을 적어본 적은 없는 것 같습니다. 재발 방지 대책으로 어떻게 하겠다는 내용은 있지만요.

보통 명령 실수가 많은 경우에는 정규적으로 사용할 수 있도록 script를 만들고, 재발 방지 대책에는 script화 해서 정규화 하도록 한다라고 적습니다. 그리고, 해당 시스템의 매뉴얼에 이 스크립트를 사용하도록 작성을 합니다.

결론적으로 장애 보고서에 사용한 명령까지 들어가는 경우는 전 한번도 없네요.

bt의 이미지

분명 비효율적인 면이 있네요. 마음에 안드시겠습니다.

여기에 대해 상사되시는 분과 대화를 해보셨나요? 그 분이 상황에 관계없이 지시를 그대로 따르길 원하시던가요? 그런 성격인 분이라면 지시를 그대로 따라주는 것이 좋지요. :-|

ymir의 이미지

SE 는 아니지만, 본문과 같이 보고서를 작성하는 경우 어떤 장단점이 있을 지 생각해 봤습니다.

긍정적인 면을 보자면, 문제를 정확히 해결할 수 있는 명령어를 사용했는지, 처리 과정 및 결과 확인 내용이 정확한지 확인이 가능하므로 피드백을 통한 개선이 가능, 추후 문제의 재발생 또는 이 조치로 인해 다른 문제가 발생했을 경우, 원인 규명 및 면피 용이 (일종의 감사 로그). 자료가 누적되면 반복되는 일, 비슷한 일을 묶어서 업무 처리 매뉴얼 및 자동화 스크립트 등 효율적인 교육 및 업무 처리 기대. 추후 신입이 들어오거나 한다면 자연스럽게 세대 교체가 용이해지겠죠.

부정적인 면을 보자면, 하는 일에 비해 몸값이 높아졌을 때 찬밥 될 수도..

음.. 대체적으로 감사 기록으로써의 의미가 더 클 거라고 보여지네요.
조치 후 문제가 생겼을 때 작업 내역을 공개함으로써, 면피가 가능하죠. 일종의 보험처럼..

되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』

junilove의 이미지

보고서에 명령어까지 쓴적은 없는듯 합니다.
다만, 어떤 작업을 하였다라고 상세히 남길경우는 해당화면을 대충 편집(생략할 건 생략하고)하여 첨부하기도 합니다.
제 생각에는 보고서에 "방법 1" 또는 "스크립트 1"을 이용하여 작업함. 하고 명시하고, 해당 내용을 누구나 볼수 이게 온라인/인쇄물로 보관하시는 방향으로 상사님과 이야기해보시는게 좋을듯합니다.

tzr250의 이미지

전 상세하게 써주려고 합니다.

고객들은 전문용어나 대충 쓰면 못알아듣고 두번세번 계속 물어보더라구요

그래서 가능한 쉽게 상세하게 적고 설명해주면

차후에 문제의 소지도 사라지고 신뢰감 형성에 도움을 주는거 같았습니다.

그래도 명령어 까지는 아닌거 같아요

ultrix의 이미지

저 역시 오랫동안 근무는 하고 있으나 작업계획서, 장애보고서 등등에 상세명령어 수준까지는 작성해 본적은 없는거 같네요.
(러프한 수준의 명령어는 기록함)

상사분께서 상세한 기록(rm, find)을 원하시는 것을 봤을때 제 판단으로는 님께서 신뢰를 못 얻고 계시다는 생각밖에 들지
않네요.

예를 들어 회사를 퇴사할지도 모른다는 생각으로 거의 업무매뉴얼(인수인계를 위한)화 시킨다는 생각이 많이 듭니다