넥스트라인 서버호스팅, 속상한 고객응대 > 자유게시판

자유게시판

넥스트라인 서버호스팅, 속상한 고객응대 정보

넥스트라인 서버호스팅, 속상한 고객응대

본문


잘 이용하고 계신 분들도 있으실 걸로 알고, 약간의 특수한 상황이니, 아무래도
저처럼 서버에 대해선 초심자이거나, 처음 서버 구입하시는 분들에게 참고되시라고
글 남깁니다.ㅡㅜ

작년 10월 쯤.. 한참 넥스트라인에서 중고서버 무료 이벤트를 할 때 여기 회원 분들도
여러분 신청하신 얘길 듣고 저희도 구입 후 지금까지 사용하여 왔다가 더는 고객응대 때문에
이용을 안하고 싶은데, 약정기간은 남아있고, 제가 다른 업체도 소개해서 서버 이전까지 해 주었고..
참 이런 경우에는 어찌해야 할지 싶은 내용이라 긴 글이 되었습니다.. ㅜ;;

(특수한 상황을 설명하자니, 내용이 많이 길어졌네요.. 대화 내용 중 중간중간 존데는 생략 표현하였습니다.)
(도움이 많이 된 분들도 구입했다는 글 때문에 참고가 많이 됐었기에 속상한 맘은 많이 들지만 남기지 말까,, 하다, 고객응대를 생각하니, 속이 불끈해서 남기게 되네요.)

제가 일하고 있는 회사에선 웹사이트를 제작/관리 해 주고 있는 곳은 많지만, 서버 관련 인력은 없어
구입을 미루다 저렴한 곳에서 한번 테스트를 해 봐야겠다는 생각에 회사에 밀어붙여(ㅜㅜ;;)
시험삼아 넥스트라인에서 작년10월 서비스를 신청하게 되었답니다.

초기에는 vi 에디터 사용만 아는 서버 초심자이다 보니, cname 변경이나, 넥스트라인에서
제공하는 nmanager 프로그램을 넥스트라인에서 잘못 셋팅한 오류와 프로그램 상
ftp 쿼터 설정 오류 등을 주로 처리요청하거나, 문의한 내용이고 그때 그때 처리는 잘 됐습니다.
*(nmanager 용량 제한 오류가 파일이 많아 최대 파일 갯수가 2만개로 설정되어 있어
2만개가 넘으면 에러가 나며, 2만개의 파일이 넘는 사이트는 거의 못 봤다고 하며, 수정했다고 하더군요. 저희가 관리하는 사이트는 파일이 10만개가 넘는 곳도 여러 곳인데...--;; )

어쨌든 간단한 서비스 확인에 대해서 깐깐한 업체들 보다는 낫다고 생각했었죠.
(직접 구입은 안했지만, 고객 요청으로 '오ㄴ과내일, 호스ㅌ웨이' 등에 입고된 고객서버의 사이트
를 관리를 해 와서 서버 장애에 대해 무료기술지원의 한계는 알고 있었거든요..)

때문에 저희 클라이언트 중 "오ㄴ과 내일"에서 9년째 서버들을 운영중인 업체의 대표 분에게도
제안을 해서 넥스트라인으로 서버들을 옮겨오게 하였고, 이전 작업을 하면서 담당 엔지니어가
많이 신경을 써 줬다고 생각했었답니다.

그러나, 이전부터 저희 회사 서버가 자주 밤 시간대에 다운이 되는게 확인되었답니다.
가끔 철야를 할 때 다운되면 넥스트라인에 문의를 했었고 그때마다 "지금 사이트 열어보니 잘 열린다"
는 답변과 저도 확인해 보면 잘 열리고 있어, 그냥 잠깐 회선에 오류가 이었겠거니 했드랬죠..

이후, 트래픽 확인을 위해 설치해 놓았던 mod_cband를 어제 낮 시간에 확인해 보니
server uptime이 60분마다 리셋되고 있어서, 이에 넥스트라인에 확인해 보니, 서버 crontab에
매시간 리셋이 스케쥴링 되어있다는 얘길들었고 crontab 부분을 만진 적도 없는데
왜 그렇게 되어 있는지 물어보니, "직접 설정을 안한거라면 모르겠다"는 답변만 들었고,
이때까지만 해도 "뭐 작업하다 보면 실수하셨을 수도 있겠거니.." 했었습니다.

문제는 오늘 새벽 1시 경 또 서버가 죽어서 여러 사이트가 다운된게 확인되었고 바로 넥스트라인
당직자와 통화하여 보니,
당직자 : "crontab에 서버가 매일 밤 1시 1분에 재부팅 되게끔 스케쥴링 되어 있습니다"는 답변
저 : "crontab 부분은 만진 적도 없고 기능에 대해선 얼마 전에 알게 된 것이라 설정할 일이 없습니다"
당직자 : "고객이 직접 설정하거나, 요청한 작업이 아니면 일부러 들어가 만질 일은 없다"

하여 저도 그 부분은 이해를 하기 때문에, "넥스트라인에서 일부러 했다는 얘기가 아니라, 요청한
작업을 해 주거나, 테스트하다가 그렀겠지 않을까 하는 생각이 들고 또 일반적으로 사이트를 운영
하는 업체가 일부러 매일 밤 중단되도록 할 일은 없지 않겠느냐" 고 하니, 당직자도
"개인적으로 생각할 때도 일부러 고객이 해 놓지는 않았을 것 같고, 서버에도 부하나, 하드웨어에
매일 재부팅은 좋지 않기 때문에 왜 이렇게 설정 되어 있는지는 모르겠다"고 하더군요..
그리고 이 재부팅 문제는 3월19일 부터 시작된 로그가 남아있고 작업 요청한 내역에는 3월19일에는
작업을 요청한 적이 없고 관련된 요청을 했었던 기록도 없다고 했답니다.
(전화로 요청한 내역도 제가 퀵메일게시판에 기록을 위해 항상 남겨 놨었거든요..)

그리고 본인은 네트워크 담당이라 낮 시간에 서버엔지니어에게 문의하는게 좋겠다고 하여
저도 어찌됐든 고민하던 문제 (매일 밤 서버가 죽어 몇개 들어와 있던 사이트 고객들도 계속 문의한
상황) 는 해결되었고, 친절히 응대해준 당직자도 고맙고 하여 같은 문제 재발 방지 차원에서
셋팅이 왜 이렇게 됐는지만 물어보자 생각하고 말았답니다.

이후 오늘 오전 전화로 '어제 낮에 발생한 아파치 데몬 60분마다 재시작 설정/오늘 새벽 발생한
매일 새벽1시1분 서버 리부팅 설정' 문제로 얘기를 하니,
서버 담당 : "고객이 직접 했으니 그랬을거다"
저 : "블라블라~ (중략) 하여 문제를 삼자고 얘기하는게 아니라 왜 이렇게 셋팅이 되어 있는지
 이유는 알아야 될 것 같아, 문의하는거다"

는 얘기에 친절하던 당직자와 달리 기분나쁘다는 투로
 "우리가 서버에 들어갈 일이 없는데, 우리가 했다는 것이냐? 고객이 요청한 작업아니면 건들지 않는다"

저 : "~(중략) 그러면 상식적으로 고객사이트도 있는데, 제가 일부러 매일 밤 서버가 죽도록 설정하겠느냐?"

이후 전화기를 막고 제가 '여보세요?' 할 때 까지 한참 있더군요.
그러다 타업체 서버들을 이전해 올 때 작업한 엔지니어가 전화를 갑자기 받더니
"무슨 일 때문에 그러느냐?"

저 : "또 다시 설명해야 하느냐?"

넥스트라인 : 짜증을 내며 "대충 얘기는 들었는데, 우리가 그럴 일이 없다, 고객이 그렇게 설정했으니깐, 그리 된 것이지"

저 : "(중략)~~ 어제 그렇게 당직자와 얘기를 나눠 문의하는 것이다, 거기에 책임을 묻고자 하는게
아니라 확인하기 위해선데, 고객한테 그리 따지는게 말이 되느냐?"

넥스트라인 : "따진 적 없다. (중략~)"

저 : "(중략)~ 다시 설명을 하지만, 우리도 사이트 제작의뢰 고객을 응대하지만, 그렇게 불친절하게 하지도 않고 고객 입장에서 당연히 설정 이유를 확인하려고 좋게 문의할 수..." 중간에
통화하던 상담원이 "아, 알았어요!" 라며, 말을 짤라버리더군요.

화도 나고 어이가 없어 목까지 치밀어 오르는 화를 참고 "위에 책임자를 바꿔달라"고 했더니
"누굴 바꿔주냐?" 고 하더군요. "장애 책임자나, 위에 관리자가 있을 것 아니냐"고 했더니
"잠깐 기다려라, 전화 다시 하겠다"고 하더군요.
 40~50분간 연락이 없어 다시 전화를 했더니, "관련 내용 때문에 담당자와 미팅중이다"고
한 뒤 다시 또 한참~ 그리고 나서

넥스트라인 : "000주임이다, 제가 책임자다"
저 : "좀 전에 통화한 사람은 대리이던데, 어찌 밑에 분이 책임자라고 전화를 주시냐?"고
했더니 "저희가 따로 책임자가 없어서.. 잠깐 기다려라"..
다시 또 한참 뒤 통화를 하니, 차장이라는 분이 받더군요.

저 : "직원분들이 어찌 그리 고객응대를 하느냐?"
책임자 : "죄송하다. 이런 일 없도록 하겠다, 나중에 전화받은 직원은 000업체 서버들 이전 시
고생해서 작업해준 엔지니어다"
저 : "그렇다고 이렇게 불친절한 고객응대를 그냥 이해해야 하느냐? 제가 화를 낸것도 아니고
먼저 고객한테 그렇게 따지는 경우가 어디있느냐? 다른데 소개해서 이전해 온 것도 후회스럽다는
생각이 든다."

책임자 분은 죄송하다는 말을 하길래 책임자에게 더 이상 뭐라 하겠나, 싶어 알았다고 말았습니다.
그러나, 그렇게 화가 날 정도로 불친절하게 응대하는 문제와 책임자나 관리자를 바꿔 달랬더니,
점심까지 한참을 있다가 밑에 직원한테 '책임자'라고 전화를 시키는 행위는 도저히 납득이 되질
않는군요.

저희 회사 사장님은 "뭐 그런 업체가 다 있냐? 다른데로 옮길 걸로 생각하고, 더 신경 써 봤자
화만 날테니, 신경쓰지 말라"고 하시는데, 아직 기간이 6개월이나, 남아서 해지하면, 위약금이
있는 것 아닌가 하는 문제랑 아는 업체를 일로 옮겨주고 다른 몇 곳에도 소개를 해 줬는데, 이런
일이 생기니, 저희 거래 업체는 또 어찌해야 할지 답답하네요.

정말 긴 글이 되어 버렸는데, 너무 답답하고 화가나니 어찌해야 할지 참 모르겠네요.. ㅡㅜ


 

추천
0
  • 복사

댓글 24개

네, 옵션님 말씀처럼 저도 첨에 그리 생각하고 그냥 사이트 개발하는 입장에서
원인이나 이유는 알아야겠구나.. 하는 생각이었답니다. ㅜ
이래저래 중간에서 고생 많이 하셨겠어요.
crontab에 reboot을 넣는거와 한시간 간격으로 아파치를 restart 하는 거는
굳이 부탁을 안하면 안하는 일이 맞아요 (대부분 유료로 해주는 작업이죠).

/var/log/secure 파일을 보면 최고 관리자 접속 기록이 있으니
초기에 그걸 보고 누가 접속했는지 확인을 했어야 책임소재의 규명이 가능하겠지만
시간이 오래되어서 지금은 누가 그랬는지 확인도 하기 힘들 겁니다.

이후에는 서버의 /var/log/secure 파일 같은 것은 주기적으로 보셔야 할 겁니다.

이정도면 그나마 나은 겁니다.
저도 다른 곳에서 이번달에 몇번 욱~ 했습니다. ㅠ..ㅠ...
아, 불당님 말씀해주신 것 처럼 그쪽에서도 처음에 당직자 분이 접속기록이 오래되어 확인이 어렵다는 말을 해 주더라구요..
저는 크론탭을 불과 며칠 전 알게 되었고 지금 서버는 제가 거의 확인하거든요. 그래서
제가 손대지 안았으면 넥스트라인 직원 밖에 없으니,,,
하긴 당직자 얘기로는 훨씬 더 이전에 셋팅이 되어 있었을 수도 있다고 하더라구요..ㅠㅠ
1시간 간격으로 아파치가 restart 하는 것은 아파치의 log file을
lotate하기 위한 것 같은데 (저도 그렇게 하고 있습니다)
그런거는 나름 귀챦은 작업이라 돈 안받으면 안해주는 일이고
요청에 의해서 작업을 했다면 당연히 작업일지를 남겨두는 겁니다.

그래서 담당자는 당연히 자기가 한게 아니라고 말을 하는 것인데
자꾸만 나는 안했고 누가 그러냐고 물으니까 욱~한거 같은데
root 패스워드를 아는 서버 관련자를 조금 더 고민해보세요.

넥스트라인의 누가 그랬냐고 물으신거 같은데
관련자가 몇명 없고, 그일을 하는 사람이 자기인데
자기는 그런거 돈 안받으면 절대 안하는데 추궁하니까 욱~ 한거 같네요.

글쿠 /var/log/secure 파일을 보세요.
누가 로그인 하는지 이력이 있어요.
그걸 보구 관련자를 찾아 내시는 것은 웹스타일님의 책임이죠.

회사 또는 고객중 root를 아는 사람일 겁니다.
네, 불당님 말씀 감사합니다. 한번 이력은 확인해 봐야 겠어요.

넥스트라인 퀵메일 글쓰기 특성상 항상 root 패스워드를 기재하고
작성하게끔 되어 있어서 항상 남겼기 때문에, 퀵메일 문의란을 본 사람은
아마 다 root를 알 거 같습니다..-ㅜ

그리고 당직자가 얘기했던 것 처럼 처음 실행 한 날짜는 3월19일이지만
그 이전에 셋팅된 것일 수도 있어서 확인은 어려울 거라 했거든요..
그래서 뭐 이미 지나고 해결된 내용이다 생각하고 원인이나, 이유만 알고
말려고 했었어요..

그냥 당직자 얘기대로 오늘 오전에 문의해 보고 뭐 때문에 그렇게 설정되어
있는건지 확인이 안되면, 어쩔 수 없겠다 싶었죠...

문제는 문의를 하는 것 조차 안되는 것 마냥 얘기를 하고 이해가 안가는
고객응대 태도(역으로 고객에게 짜증이나 화를 내는..)가 황당한 것이었죠.

맨 처음 서버 설치 후 넥스트라인에서 nmanager 셋팅을 잘못해서 처음엔
첫 로그인 화면조차 다 깨져 나올때도, 이후에 nmanager 자체 오류여도
"프로그램 문제여서 그랬다" 또는 "저희가 잘못 셋팅해서 그렇다" 같은
죄송하다는 답변을 한번도 듣지 못했죠..

항상 답변은 nmanager 자체 오류여도 "파일 2만개가 넘어서 문제가 생겼다.
원래 2만개 넘는데는 거의 없다" 거나 "db 셋팅이 안되어서 에러났다. 추가했다" 이런식이었다는 것도 저는 그러려니.. 했던 겁니다..
퀵메일에 root가 있다고 해서, 그걸 가지고 자기 맘대로 작업 안합니다.
저도 서버관리 오래했지만, 서버 만지는거 진짜 짜증나는 일이거든요.

글쿠 원인, 이유는 담당자가 다 말했는데 자꾸 물으시니까
담당자는 자기 책임이냐고 묻는걸로 생각할 겁니다.
글쿠 원래 서버 담당자는 승질이 많습니다. 
제가 대리일때, 개발실 부장들도 제 눈치보구 살았어요. ㅎㅎ

서버호스팅 관리. 대표적인 3D 업종입니다.
작은 급여에 야간 당직. 미래도 뚜렷치 않은 상황이라서
어느회사에서 호스팅을 하던 건드리면 펑~하고 터질 겁니다.

최대한 굽신굽신하면서, 문의를 해야 합니다.
그렇다고 해도 고객이 눈치를 봐 가면서 비용을 내고 이용할 수 없는
건데요..
어디든 똑같이 고객응대를 해야 한다면, 기본적으로 먼저 큰소리내거나
짜증내고 성질낼 수는 없는거지요.

불당님 말씀도 이해는 하지만, 담당자가 짜증난다고 돈내는 이용자가
그 사람 마음까지 헤아려가면서 눈치 살펴야 하는 건 아니라고 생각드네요..
그게 참 미묘한 문제고 커뮤니케이션의 방법이겠죠?
...

내가 만들어준 웹사이트에 황당한 버그가 있다고 말하는데
내가 절대로 작업하지 않은 건데
누가 그랬냐구 책임은 묻지 않겠다고 물어와서
그런거 아니라고 하는데 자꾸 같은 것을 물으면 어떻게 하실꺼에요?
...

가끔은 세상을 역지사지하면 편할 때가 있습니다.
얘기드린 부분은 기본적으로 손 댄 사람을 색출하겠다는 얘기가 아니라
당직자와 처음 확인 시 낮 시간에 서버 담당자에게 문의를 다시 하는게
확실하겠다 해서 문의를 한 것이었다는 얘기였고, 또한, 전화받은 상담원에게 이미 그러한 얘기를 했던 거죠.
그런데, 돌아온 답변이 짜증과 승질이라면, 불당님도 이해가 쉽게 안걸거에요..
여기서 터진거에요.

웹스타일님은 내가 한일이 아니니까 이유를 알고 싶다고 하는데,
그 이유는 한가지 뿐입니다.
웹스타일님 생각으로 이유는 root를 아는 넥스트라인 담당자인거죠.
그래서 담당자에게 문제를 삼지는 않을테니까 빨리 말하라는 걸로
들릴 수 있었던거에요.

담당자에게
니가 사실대로 말하면 다 용서해준다...
이렇게 이해될 수 있는 상황이 되었으니 담당자가 펑~한거죠. ㅠㅠ

---
저 : "블라블라~ (중략) 하여 문제를 삼자고 얘기하는게 아니라 왜 이렇게 셋팅이 되어 있는지  이유는 알아야 될 것 같아, 문의하는거다"

는 얘기에 친절하던 당직자와 달리 기분나쁘다는 투로
 "우리가 서버에 들어갈 일이 없는데, 우리가 했다는 것이냐? 고객이 요청한 작업아니면 건들지 않는다"
당연히, 저희가 작업을 한 것이 아니다고 얘기를 하지요.
그래도 이해가 안간다고 고객이 그런다면 확인을 해 본 뒤
역시 마찬가지 답변이 되겠지만, 최소한 고객이 먼저 성질을
내지 않는 한 성질 낼 이유도 없고 짜증을 부릴 이유도 없죠.

좋게 얘기를 하고 상대방도 좋게 받아들이면 좋은 마무리가 될 겁니다.

그렇기 때문에 문의할 때 부터 짜증이나, 말을 막는 그런 태도가 이해가
안간다고 얘기를 한 것이고 또한, 이후에도 문제는 누가 했는지가 문제가 아니라, 왜 고객한테 그런식이로 응대를 하느냐는 것이었습니다.

쉽게 말씀드려 포인트는 '왜 고객한테, 먼저 성질이냐'는 것 때문에 책임자를 바꿔달라는 것이었죠.

그리고 이미 당직자와 통화 때 부터 이후에도 "확인이 안되면 어쩔수없다고 생각 할 것" 이라 얘기를 했는데, 계속 "고객 문제다" 라며 딴 사람이 전화를 받고 또 성질내는 건 어처구니 없는 행동 아닐까요?..

어쨌든 불당님은 그렇게 전적으로 제품을 공급하는 입장을 생각하고 서비스 받는다는 것이니 당연히 견해가 다른 것 같네요.

불당님이 만든 프로그램 소스들이 도움이 많이 되어 좋게 생각하여 왔기에, 불필요한 소모로 번지고 싶지는 않아 서로 생각하는 견해가 다르다 이해하겠습니다.

여하튼 저도 위에 남은 문제 때문에 답답해서 퇴근도 못하고 있군요...

---// 추가

네, 방금 써 주신 내용을 보니, 저도 더 이해가 됩니다..ㅜ
근데, 그전에 그쪽에다 "당직자 분이 얘기한데로 확인이 안된다면
이해하겠다. 당직자 분이 낮에 한번 더 문의해 보라 해서 확인이 될까 싶어 문의한거다"라고 얘기를 먼저 했다는 것이죠...

내용이 너무 길어져 중략된 내용중 일부이지만..

때문에 그냥 좋~게 "안타깝지만 누가 했는지 저희도 확인이 안됩니다. ~" 는 식으로 좋게 말햇으면 그냥 '끝!'날 일이었죠..
저는 남들이 인정하는 슈퍼~ 불량고객입니다. ㅎㅎ

담당자가 좋게 설명하는 것에 욱~해서
hp 사장이랑 전화를 해서 담당자를 좌천시켜버린 적도 있고
증권사에 슈퍼울트라 민원을 제기해서 몇달동안 감사를 받도록
하거나 사장 라인까지 뒤집어버린 적도 여러번 입니다. ㅠ..ㅠ..

그런데, 세월이 지나니까
다 그런게 제 말하는 스킬이 부족한 탓이라고
생각되는 측면이 더 크더라구요.

남이 욱하는 것은 내가 말하는 방법이 부족한거라 생각하고
착하게 살려고 노력하고 있습니다.

나이가 아주 많이 들게 되면 그땐 제말이 이해가 가실꺼에요.
글쿠 욱~할 때는, 이야기를 해서 그걸 푸셔야 해요.
안그러면 멍울이 집니다.
넥스트라인의 최대 장점은 회선 초과하면, 먼저 차단해놓고 전화하는 센스가 돋보입니다.

wget 으로 데이터를 이전했던 적이 있었는데,

회선 끊어놓고 새벽에 전화하는 유일한 곳이에요.
그래서 저는 계속 h에 있죠.
10년 고객이라 회선 조금 더 쓴거는 뭐라 안하거든요.
물론 가끔씩 경고의 날카로운 칼날이 오기는 하지만.

하여간 h나 n이나 밤에 전화 좀 안했으면 한다는. ㅠ..ㅠ...
본인들 밤에 일한다고 고객도 당근 일할꺼라 생각하더라구요.
이번달에 자다가 전화 받아서 엉뚱한 서버를 빼서 난리 났었습니다.

호스팅 선택의 원칙은 네가 가장 껄끄로운 부분이 없는 곳이 된게 현실이죠. ㅎㅎ
넥스트라인 차장입니다. 
웹스타일님 먼저 죄송하단 말씀밖에 드릴 말씀이 없네여. ㅜㅜ

최근 추진하고있는 프로젝트가 있어서 신경쓰지 못한점 죄송하구요
어제도 오전에 일이있어 외부업무를 하고 오후에 사무실에 들어오니 저희 엔지니어가 현 상황에 대해 예기를 하더군요
바로 전화를 몇번 드렸는데 전화를 받지 않으셨었습니다.
손님이 오셔서 업무미팅을 하고 다시 사무실로 들어오니, 전화가 왔었다고 하더군요

뭐 다시 말을 해봐야 변명이라고 생각되니, 위의 이야기는 더이상 하지 않겠습니다.
서비스업종인 저희쪽 고객응대부분에서 그렇게 느끼셨다면 저희쪽 잘못이라고 생각됩니다.
이부분에 대해서는 뭐라 드릴말씀이.. 죄송하다는 말밖에는......

호스팅업체 엔지니어분들 정말 고생 많이 합니다. 다른 업종들도 마찮가지겠지만요..
저도 엔지니어 생활 10년넘게 해왔지만, 수십 수백번 때려치고 싶었습니다.
일은 일대로 해주고 욕은 욕대로 먹고 티는 하나도 안나고.....
잘해야 본전인게 시스템 엔지니어가 아닐까라는....

어떤고객은 전화를 받자마자 육두문자를 날리는 분들도 계시고,
잘해드릴려고 한것이 독이 되는 일도 있고.....
어찌보면 이런일들때문에 지치게되고, 사람 대 사람으로 자기일처럼 말하는게 아니라
기계처럼 말하는 되는 것 같습니다.

다들 시간되시면 호스팅업체 사무실에 반나절정도만 계셔보세여.....
화장실 갈 시간도 없을때가 많습니다.
저는 가끔 자리에 앉아 엔지니어들 일하는 모습 한번 쭉 봅니다
그럼 이건 무슨 콜센터인지 전화끊으면 전화오고 전화오고.....
엔지니어라고 입사를 했는데 하는일은 콜센터이니....

뭐 주절주절 말이 길어졌네여.....
너그러이 이해를... ^^

뭐 이일로 인해서 어제 엔지니어들 한번 박살 내놨으니 최대한 이런일이 없도록 하겠습니다.
한번 쫙 타이트하게 쪼아줬으니 울 엔지니어들 또 눈치 살살 보겠네여.....
한번이 이렇게 쫙쫙 쪼아줘야되는 내자신이 싫다능.... ㅜㅜ
처음 서버관리자라는 것을 했던게 90년이니, 벌써 20년도 넘었네요.

Digital의 VAX 서버는 책이 책장 2개이고, 아무나 쉽게 접근하기가
어려운 구조라서 관리자라는 책무의 role 역활이 아주 높은 것이지만
어린 제가 봐도 이건 아니란 생각이 들더라구요. 남들이 보면 높은
수준의 일이지만, 실제로는 low level의 잡일들만 득실거리구요.

담에는 ibm mainframe의 관리를 하게 되었는데, 이거는 책장으로
4개 분량의 책이 있고, VAX보다 관리가 몇배는 더 힘든데 욱~하게
욕이 나오게 잡일이 더 많았어요. 그래서, IBM 버리고 hp server로
바꿔버렸죠. 그랬더니, 책이 10권 안팎으로 줄어들더라구요. ㅎㅎ

서버 관리라는게 미국에서는 20년은 되야 짬밥 인정이 되는 것인데
한국에서는 서버관리의 책임만 있고 급여나 업무의 보상이 안되죠.

제가 했던 서버관리가 업무의 5% 정도 수준이라서 부담이 없었지만
그걸 업으로 하시는 분들 때로는 많이 존경스럽더군요. ㅎㅎ

리눅스의 경우에도 할 것이 많은편이지만 쉽게 손이 잘 안가져서
이제는 모두 의뢰만 하고 저는 서버에 손을 잘 안대는 편 입니다.

h사부터 c사 여기저기 다 써봤지만, 그나마 관리수준이 nextline이
높은 편이라 여기서 setting 된 설정을 다른 곳에서 퍼서 쓰고 있어요.

세상은 첨단으로 알지만 실제로는 3D 업종중의 3D 업종이라 하루에도
몇십번 때려치고 싶은 상황이쟎아요.

너무 엔지니어들 깨지 마시구, 격려하고 간식이라도 많이 챙겨주세요^^
오웃~ 20년.....
아빠불당님은 정말 전천후 시네여....
나두 하루빨리 전천후가 되어야 하는데... ㅜㅜ

음. 간식... ㅋㅋㅋㅋ
결혼전
-> 간식, 담배 다 사주마~ (엔지니어들 : 어머 천사표야~)
결혼후
-> 간식, 담배 다 안사주는건 물론 직원들에게 담배 엥벌이함 (엔지니어들 : 왜이리 많이 변했니  예전으로 돌아왔음 좋겠다~ 흥흥흥)
이런 실정입니다.. ㅜㅜ
마눌님에게 머니를 다 빨리니.... 흑흑흑
아~~~ 옛날이여~~~~~~

아참. .그리고 PHP 공부순서가 방명록 -> 게시판 -> 페이지나누기 -> 계층형 게시판 -> 자료실
이순서 대로 공부하면 되나여?
맨날 문법만 디다보니 지겹기도하고, 다른 소스를 보니 뭐가뭔지 눈돌아가고.... ㅋㅋ
공돌이로 시작해서 나름 으뜸 공돌이지만, 한번도 공돌이의 길을 가본적이 없습니다. ㅋㅋ

php는 어디서 시작을 하든 의미가 없습니다.
기본적으로 문법의 rule을 다 익히고 있다면, 한가지를 꼼꼼히 파고 들면 됩니다.

그누보드가 php를 익히기에는 가장 좋은 참고자료인데,
독립적인 기능부터 하나씩 읽어 나가면 되요.

common.php, lib/common.lib.pp - 2가지에 프로그램에 필요한 함수들은 다 있고
bbs/search.php나 bbs/new.php 같은 독립적인 기능을 하는 것을 읽으면 되요.
고객은 원인을 찾아서 차후에 이런일이 없어야하는데
몇번의 문의 과정이 지나게 되면 문제발생의 원인보다는
위에 사례 처럼 고객응대의 서운함으로 본질은 변하게 되는경우가 많습니다.

엔지니어들이 당연하다고 생각하는것을
고객들도 이해하고 있다고 생각을 할때가 많죠

"내가 설정을 건들일은 당연히 없는데 이 양반 왜 나한데 이러는건가"
하겠지만 잘 돌아가고 있던 서버가 갑자기 저런데 고객은 엔지니어게게 물어볼수 밖에 없겠죠?

고객이 이 문제를 해결하고자 하는것이 목적임을 안다면
내가 전문가로서 도와줄수 있는 부분을 도와주면 이런 문제는 해결되지 않을까 합니다.

"지금상황에서는 오래 지나서 로그파일들로 원인분석을 해볼수가 없다.
로그 파일을 정기적으로 백업을 한다면 차후에 이런 일이 발생할때 원인분석에 도움이 될수 있다.
고객쪽에서도 서버관리자운영이나 패스워드 관리에 신중해달라"
간단하게 로그파일을 하드나 이메일등으로 백업할수 있는 스크립을 짜주겠다.;;"

고된 업무의 엔지니어들에게 이런 친절한 고객응대까지 바라는것은 무리인가요?
당연히 항상 친절하게 대응을 해야죠 ^^
그런데, 가끔씩 이유없이 욱~할때도 있쟎아요.

저도 어제 누가 서비스에 대해서 자꾸 질문하길래,
환불 해줄테니 계약해지 하라고 했습니다.

그랬더니, 다시는 전화가 안오더군요. ㅠ..ㅠ...

친절해야죠. 친절...친절... 친절...

---
그래서 저는 게시판으로만 질문 합니다.
욱~ 해서 전화기 집어 던질까봐요. ㅎㅎ

---

과장일 때, 부장이랑 손가락질 하면서 싸운 더러븐 승질.
이제는 개과천선 하고 싶어요.
서로의 입장에서 이해해 가려는 노력은 꼭 필요하리라 생각되구요.

입장에 따른 어려움들이 있으실텐데, 그래도 이렇게 열린 공간에서
터놓고들 말씀들 하시니 좋은 관계로 계속 이어질 수 있으리라 생각됩니다.

특히, 넥스트라인 차장님께서 많이 당황스러우셨을 것 같은데..
모쪼록 화이팅하시어 좋은 넥스트라인의 모습과 분위기를 이어가시면 좋겠습니다..^^
© SIRSOFT
현재 페이지 제일 처음으로