<게으른 프리랜서> 블로그 술이

요즘 스트레스도 있고 살찌는 문제도 있고해서 2주넘게 점심을 먹고 있지 않다.  오늘은 아침도 부랴부랴 오다가 김밥 한줄도 못사고 오고해서 햄버거나 먹어볼까 고민하고 있었는데...
우리층에 제일 귀염고 상큼한 이모씨가 사진의 내용을 주는것이 아닌가~~~! 물까지 데워서 넣어준...(이정도 되면 오해해도 되는거 맞죠~!)
내용물중 쵸코파이 정말 많이 거시기 합니다. 이것만 먹어도 배가 부르긴 했는데... 감정에 많이 치우치는 술이가 왠지 많은 생각을 하게되는 하루가 되지 않을까 하는 생각을 해본다.
촌놈들한테는 반갑다고 손도 흔들어줘선 안되는데... ㅋㅋㅋ

캬~! 봉감독~~!
옆모습 멋있어~~~!
앞에 막은사람은 누규~~~~~? 이민영K
어두운데서 플래쉬 없이 찍을려니 다 흔들려서 겨우 하나 제대로 나온것중 하나다. 한편으로는 배가 아프다. 다들 결혼하는데... ㅠ,ㅠ
부럽다. 부러우면 지는건데...
이날 봉감독이랑 한잔하면서 봉감독네 집에서 잠을잤다. 그리고 다음날 작업이 있어서 부랴랴 회사로 오고...

지금 이시간도 새벽까지 작업을 해야한다. 콜센터는 은근히 빡세던데...

돼지저금통 작은거 더이상 들어갈 공간이 없기에 털었더니 이정도...
무식이 죄라고 은행에서 돈세어주는 기계도 있는데 그것도 모르고 일일이 다 세어봤다. 만6천 얼마였는데...

내옆자리 권모씨 커피 한잔 사주고 나머지 돈은...
로또샀다. 로또로 인생역전 해보잣 ㅋㅋㅋ

admin을 위한 Pro 관련 원서이다. 원서? 그래도 볼만하다. 모르는 단어는 단어 찾아보면서 보긴 하는데 먼저 IIS7을 연습해보고 공부해보는 중이라 내용이 그다지 어렵지는 않다. IIS6에서 IIS7으로 넘어가는 단계라고 한다면 개발자가 설정해야될 관리부문을 Pro쪽으로 전담을 했다고 해도 과언이 아니다.
IIS7을 공부하면서 개발자한테 많이 물어보구 있다. 솔직히 직접 운영해보구 닷넷이나 소스에대한 메모리나 풀관련 설정들은 뭔가 붙여보구 운영해보지 않으면 이해하기 쉽지 않다.
FastCGI PHP 성능 좋다고 한번 내블로그를 아파치에서 IIS7으로 이전하여 운영해보구 있다. 성능... 글쎄(?) 안되는 플러그인이 있는가 하면 더 많은 보완이 필요하지 않나라는 생각을 해보게끔 한다. 혼자 좋다고 해서 삽질을 경험해 봤기에 좋고 나쁘고 한것이 미리 깨달은 것이다.
제일 마음에 들었던건 응용어플리케이션 풀 설정이다. 이건 IIS6에서도 분리되고 격리 사용했던거기 때문에 특별하다고 하기엔 그렇지만 세부적인 GUI 설정들이 Pro의 역할이 더 많아 진건 아닌가 하는 생각도 있다.

4만원이 조금 넘는 이책. 다른 외서들은 8만원 넘는것도 있으니 IIS7에 관심이 많은 엔지니어라면 구입해서 봐도 나쁘지 않다고 말하고 싶다.
참고로 개발자는 IIS7 닷넷쪽이 있으니 그쪽분야를 찾기 바란다. 뭐 설정에 관심이 있다면 이거 봐도 되고...

IT조직에게 ‘장애’는 두려운 존재다. 장애가 발생하는 경우 IT조직의 무능함을 질타하는 사용자 측의 비난을 만나게 된다. 들 불처럼 일어나는 장애에 대한 관심도 IT조직의 입장에서 부담스럽다. 그런데 이렇게 두려운 장애임에도 불구하고, 장애에 대응하는 일부 IT조직의 접근법은 나이브(naïve)하기 그지없다.

이들 IT조직들은 장애의 직접적인 발생원인을 찾아내는 데에만 집중할 뿐, 장애가 발생하게 된 다양한 원인들을 찾아내는 활동은 게을리하고 있다. 장애에 대한 단순한 대응은, 유사한 원인으로 인한 장애의 재발을 막을 수가 없다. 단순한 장애 대응으로 IT장애를 반복하고 있는 IT조직에 대해서 이야기 해보겠다.

■ 장애 대응의 사례

A회사 IT조직의 장애 기록을 검토하면서 발견한 장애 대응 사례를 하나 소개하겠다.

업무시간 중에 회사 내에서 여러 개의 어플리케이션을 동시에 사용하지 못하는 장애가 발생했다. 사용자로부터 많은 신고 전화가 들어왔고, IT조직에서는 장애를 유발한 곳이 어딘지 찾기 시작했다.

우여곡절 끝에 이 IT조직은 신규로 들여온 네트워크 장비가 장애를 유발한 것이라는 것을 알아냈다. 네트워크 장비의 설정 파일 값이 잘못 입력되어 있었던 것이다.

이 IT조직이 장애의 원인을 찾아내는 동안, 장애로 인한 사용자들의 불만이 쏟아졌으나, 장애의 원인이 된 네트워크 장비의 설정 파일 값을 수정한 이후로는, 사용자들의 불만이 잦아들었고, 정상 상황이라고 판단한 IT조직은 이 장애를 종결 처리하였다.

이 IT조직이 작성한 장애의 기록은 여기까지다.

장애 기록에는 장애의 근본원인을 분석하는 공간이 있었으나 비어있었고, 장애의 원인을 찾았으니 장애의 종료는 당연한 것이 아니냐 하는 담당자의 반문 섞인 설명이 뒤따랐다.

■ 데자뷰(déjà vu)?

이 IT조직의 장애 대응 방식은 우리 사회 어디에서 본듯한 모습이 아닌가?  남대문화재, 대구지하철사고, 물류창고 화재사고 등 우리 나라의 재해를 다루는 모습과 겹쳐진다고 생각하지 않는가?

재해가 발생하면 재해의 발생 원인을 찾느라 호들갑을 떨다가 어느 정도 소명이 되는 발생 원인을 찾게 되고, (웃긴 건지 슬픈 건지 모르겠지만, 우리나라는 주로 처벌을 목적으로 발생 원인을 찾는다.) 희생자 처리와 담당자 처벌이 완료되면 해당 재해는 자연스럽게 종료되어 버린다. 유사한 재해가 또다시 반복되고 있고, 앞으로도 반복될 수 밖에 없는 운명이다.

위에서 언급한 장애대응 사례는 대한민국 사회의 ‘후진국형 재해 대응 방식’과 너무나 닮아있다.

■ 무엇이 문제인가?

장애의 원인은 장애를 유발하게 만든 ‘직접적인 원인’과 그 직접적인 원인을 유발하게 하는 ‘환경적인 원인’으로 나뉜다.

장애의 ‘직접적인 원인’은 IT조직뿐만 아니라, 사용자 측에서 워낙 관심이 많기 때문에 IT조직입장에서는 반드시 찾아내서 소명해야만 한다.

반면에 ‘환경적인 원인’은 IT조직 ‘내부’의 프로세스나 업무 방식에 관련된 것이기 때문에 IT조직의 외부, 즉 사용자 측에서는 별 관심이 없는 경우가 대부분이다. 따라서 사용자 측에 대한 ‘대응’에만 유독 집중하는 IT조직의 경우, 굳이 환경적인 원인까지 찾아낼 필요성을 크게 느끼지 못하게 된다.

장애의 ‘재발’은 이러한 장애의 ‘환경적인 원인’을 등에 업고 발생하게 된다. 환경적인 원인을 찾아내서 제거하지 못하면 유사한 장애의 재발을 막는 것은 불가능하다.

위에서 언급한 장애 대응 사례의 경우, 직접적인 원인은 ‘네트워크 장비의 설정 값 오류’라고 할 수 있다. 하지만 네트워크 장비의 설정 값 오류를 일으킨 ‘환경적인 원인’은 밝혀내려고 시도 조차하지 않은 것이 문제이다.

■ ‘부실한 변경 프로세스’가 환경적인 원인

그러면 이 장애의 경우 ‘환경적인 원인’은 무엇일까? 이를 확인하기 위해서는 장비를 설치할 당시로 거슬러 올라가야 한다.

이 IT조직은 장비설치를 할 때는 반드시 ‘변경 프로세스’를 거치도록 규정하고 있다. 그래서 해당 네트워크 장비의 변경 기록을 검토해 보았다.

변경 기록에는 장비의 ‘설치 계획’과 ‘설치 결과’가 포함이 되어 있었다. 그러나 설치 계획과 설치 결과의 내용이 너무 빈약했고, 설치 결과에는 ‘정상’이라고만 기술되어 있었다. 단순하게 생각해보자. 설치 결과가 ‘정상’인데, 왜 네트워크 설정 파일 값이 잘못 설정되어 장애가 발생했을까?
 
이미 짐작한 사람이 있겠지만, 이 IT조직의 ‘변경 프로세스’ ‘수준’으로는 네트워크 설정 파일 값의 오류를 사전에 ‘검증’할 수가 없다는 것이 그 이유이다.

설치계획에는 언제 어떤 순서로 누가 설치하겠다는 정도로만 기술이 되어 있고, 설치 이후에는 네트워크 장비가 잘 ‘작동’된다는 점만을 확인하여 설치 결과를 기록하고 있기 때문에, 이 IT조직에서는 ‘정상적인 네트워크 설정 파일 값’이 무엇이며, 설치과정에서 제대로 설정했는지를 확인할 수 있는 방법이 없다.

변경 프로세스의 ‘디테일’을 강화하지 않는 한 위와 같은 유사한 장애의 재발을 방지할 수가 없다는 얘기다.
이 장애대응사례의 경우, 결국 IT조직 내부의 부실한 변경 프로세스가 장애의 ‘환경적인 원인’인 것이다.
반복되는 장애의 배경에는 이처럼 IT조직 내부의 ‘부실한 프로세스들’이 또아리를 틀고 있다.

■ 장애의 선진 사례- 장애 사후 검토(Post incident review)

단순한 장애대응에서 벗어나 적극적으로 장애를 대응하기 위해, 선진국이나 선진 기업에서 도입하고 있는 방법 중에 하나가 ‘장애 사후 검토’ 활동이다.

‘장애 사후 검토’ 활동은 ISO 20000 표준과 ITIL에서 다루고 있는 문제 관리 프로세스(Problem management process)를 좀더 확장한 것이라고 보면 된다.

문제 관리 프로세스는 ‘밝혀지지 않은’ 장애의 ‘근본 원인’을 조사하는 것이 목적인 반면에, 장애 사후 검토 활동은 밝혀지지 않은 장애의 근본 원인뿐만 아니라, 위에서 언급한 ‘환경적인 원인’과 장애 발생 이후 IT조직의 대응 과정이 예상대로 또는 성공적으로 진행이 되었는지 여부도 검토하는 것이다.

문제관리 프로세스를 잘 운영하고 있는 IT조직은 별도로 장애사후검토 활동을 가질 필요가 없이, 기존 문제관리 프로세스의 검토항목을 추가한다면 장애 사후 검토 활동의 이득을 모두 누릴 수가 있다.

■ 장애를 대하는 태도가 바뀌어야 한다

장애를 뿌리뽑겠다고 선언하는 IT조직을 종종 만나게 된다. 그러나 ‘의욕’은 장애의 환경적인 원인이라는 강력한 암초를 만나면서 꺾이는 경우를 보게 된다.

환경적인 원인을 찾아야 한다는 필요성을 이해하고, 환경적인 원인을 찾아내는 데까지는 성공했으나, 그 원인을 제거하기 위해서는 결국 부실한 내부 IT 프로세스에 ‘메스’를 데야 한다는 사실을 알게 되는 순간, 들고 있는 ‘메스’를 주머니에 다시 집어넣어버리는 IT조직을 경험한 적이 있다.

발생한 장애는 어쩔 수 없다. 그러나 유사한 장애가 재발하지 않도록 하는 것은 IT조직이 사용자들에게 지켜야 하는 의무이자 약속이다.

이 약속을 지키기 위해서는, 어떤 희생을 치르더라도 IT조직 내부의 프로세스를 과감하게 뜯어고치겠다는 결심이 뒤따라야 한다는 ‘냉정한’ 현실을 IT조직은 분명히 알아야 한다. 이 정도의 노력과 용기도 없이 ‘무 장애’ 선언과 같은 ‘공수표’를 날리지 말라는 말이다.

원본출처(ZDnet)

여기에 몇마디 적고 싶지만 우리 회사사람이 볼까봐 그냥 비공식적으로 보고서 분석을 하고 난후 나도 칼럼이나 작성해 봐야겠다는 생각이다.
한마디 더 적는다면 가장 큰문제는 IT조직원들은 자신들이 공무원이라고 착각하는데 있다는것이다.
울회사에 관리파트 이모 과장님이 이 글을 보고 참고 하면 업무에 도움을 주지 않을까 생각도 해본다. 그래도 이모과장은 스트레스 받더라도 화를 안내면서도 열심히 하는게 보인다.

Image Gallery Directory Listing Module for IIS7

http://www.iis.net/downloads/default.as ··· i%3D1325

예제 페이지는 http://wallpaper.iis7.org/gallery/ 처럼, /gallery/ 웹디렉토리를 브라우징 하면 보이는 것처럼 이미지 갤러리 형식으로 변환해 줍니다.

모 서버정보 사이트에서 간간히 IIS7에 대한 모듈 정보가 나오길레 한번씩 따라해본 결과물이다. 아주 쉬운 설정방법이여도 새로이 달라진 기능들 앞에서는 삽질은 피해갈수 없었다.

http://image.sooli.com/    <---- 요기에 snsd라는 폴더가 있는데 요즘 남자들이 환장을 하더만. 글쎄 난 별로...

 

이거 설정해보면서 회사 닷넷 개발자분(최모 과장님)한테 많이 물어보기도 하고 이것저것 정보도 많이 얻었다. IT Pro가 개발파트를 조금씩 알때마다 신비스럽기도 하지만 손대기는 싫다는거...(Pro 파트도 할게 너무 많아 ㅠ,ㅠ)

위기능의 장점은 DB가 필요없고 그냥 무작위로 올리고 나면 쉽게 볼수있고 원하는것만 확대해서 볼수 있는 장점이라고 할수 있다. 게시판처럼 DB에 등록되다보면 서버자원에 많은 영향을 준다는 생각을 해봤는데 문제는 닷넷 응용어플리케이션 풀 메모리와 시간설정을 안하면 이 갤러리 모듈 혼자 메모리를 다쓰게 된다. 메모리 여유가 없는 2008 서버라면 반드시 응용풀 설정값을 변경해야함.

 IIS6은 커널기반에 들어오면서 혁명이였는데 IIS7은 혁명에 이어 문명을 이루고 있다고 생각이 드는건 나혼자만의 생각인가?
이제껏 IIS는 제대로 공부해보질 않아서 지금이라도 하나씩 공부해보구 있다.
백모 지인의 도움이 나를 이렇게 만들어 부렀다.

(0) (0)

윈도우서버 2008서버가 기능들을 너무 세분화 시키다보니 미디어 서버도 IIS7에 일부 기능을 위임했다고 해도 과언이 아닐정도로 좋아졌다.
단순한 미디어 서비스를 운영하기 위하여 미디어 서비스를 올리지 않아도 된다는 의미에서 이렇게 친절하게도 이리 분산시켰나 생각을 해보는데...

미디어서버를 추가 구성하지 않고 IIS7으로 되는건 어디까지인가를 테스트삼아 구동시켜봤는데 눈에띠는 한가지가 avi 스트리밍이다. avi? AVI~~!! 이건 동영상을 플레이해주는 일부 미디어 서비스를 하는 운영자나 개발자들에게는 반가운 소식이 아닐까?라는 생각을 해보는데...
혹시나 해서 avi 화일 링크주소를 곰으로 열어봤다. 60초를 기본 버퍼링 삼아 플레이 해보니 잘나온다. 더 놀라운건 자막까지 보여준다는거다~~~!
잠깐 테스트 삼아 해본건데 이리 놀라울수가... 이렇게 되면 앞으로 미디어 인코더는 죽는건가? asf나 wmv 같은 미디어로 변환할 필요가 없지 않나?라는 생각을 해보는데 더 특화된 기능은 아직 확인안해봤고 그냥 테스트 삼아 해본게 많이 좋아졌구나~ 라는 놀라움을 감추지 못하고 있다.



http://media.sooli.com/bbs/24%20S7%20Preview.avi

위링크주소를 복사해서 곰플레이 곰주소로 열어보길 바란다. 클릭하면 다운로드 되버림.
웹페이지에서 일부 소스코드를 곰플레이에서 플레이해라라는 구문을 넣어주거나 웹상의 플레이 리스트를 만들고 그것만 곰에서 열어주면 모든 리스트를 줄줄이 볼수 있다는 장점을 가지고 있다.

세상 많이 좋아졌다.

VISTA SP1 클라이언트 이상과 Windows2008 Server 이상 버젼에서만 가능한 SSL VPN 기능을 여러 삽질을 통하다가 도저히 어디서 막혔는지 찾아보지 못하고 Q&A를 진행하면서 구성한 사례가 있었다.
지금까지 PPTP와 L2TP 프로토콜을 사용하다가 필자의 경우는 GRE47 라우팅 프로토콜이 차단된 사무실에서 어쩔수없이 443 보안채널을 통한 VPN 기능이 필요하게 되었다.
대부분 SSL VPN을 사용하는 이유는 보안적인 이슈때문에 사용하는 사례가 대부분인데 필자같은 경우는 보안이고 나발이고 GRE47 패킷 라우팅 열어달라고 하면 도대체 뭘 열어달라고 하는건지 모르겠다는 보안팀의 답변에 두손두발을 다 들었다는 전설이...

스텝바이스텝에서 권장하는건 DC에서 인증서를 갖고오고 VPN서버에서 인증서를 뿌려주는 방식인데 필자가 Q&A를 진행하였던건 Stand Alone에서 구성을 할수 없냐?였다는것이다. VPN 기능만 사용하고 DC까지 올릴 자원이 불필요 했었기 때문에 인증서 기반때문에 복잡할 필요는 없지 않을까?라는 판단하에 지인한테 Q&A 카드를 부탁하여 케이스를 진행해 보았다.

그림과 같이 인증서로 시작해서 인증서로 끝나는 VPN 구성이다. 인증서 설치를 완벽하게 끝내고 나면 하나 풀리지 않는 네트워크 오류가 발생하는데 꼬알라 사이트를 참조해보면 손도장 업데이트를 해줘야만 한다. 즉 기존에 손도장이 남아 있어서 네트워크 연결이 안된다는 메세지가 나와서 뭐가 잘못된건지 오랫동안 당황한적이 있어서 아직도 기억에 남는건 손도장 찍어주지 않았다는 이유만으로 2008서버가 약속을 거절할줄은 생각도 못했다는 필자의 판단.

그림과 같이 PPTP와 L2TP 프로토콜이 아닌 443 보안채널로 들어온것을 확인할수 있다. 저 접속자는 이 회사에서 존재감을 상실한 장모대리가 혼자만 신나게 외부로 인터넷을 하고 있다는...
울회사는 80번과 443을 제외한 모든 아웃바운드 포트는 막혔다. K모 통신회사는 443도 열지않고 오로지 80만 열었다는 정보도 들었는데 역시 우리나라 대표 통신회사라 보안에 대한 절차는 확실하구나라는 생각을 가져본다.
SSL VPN 은 고가 장비로 알고 있다. 하지만 클라이언트가 비스타 운영체제를 사용하고 있는 업장이라면 윈도우2008서버의 SSL VPN 기능을 활용한다면 비용절감과 관리에 많은 효과를 누리지 않을까?라는 생각은 혼자만 갖고있다 ㅋㅋㅋ.

MBC 이정민 아나운서가 뉴스 진행 도중 거울을 보는 장면이 그대로 전파를 타는 방송사고가 발생했다. 

4월 9일 오전 6시7분쯤 MBC ‘뉴스투데이’ 1부에서 강원 지역 산불관련 소식을 전하던 중 갑자기 화면조정 장면으로 전환되는 실수가 벌어졌다. 화면은 곧바로 뉴스를 진행하는 스튜디오로 전환됐지만, 이때 이 아나운서가 오른손에 거울을 들고 자신의 얼굴을 보고 있는 장면이 그대로 방송됐다. 

급히 상황을 파악한 이 아나운서는 곧바로 거울을 책상위에 놓고 ‘뉴욕증시 사흘 만에 소폭 반등’ 소식을 전했다.

그냥 보다가 웃겨서 올려본다. 요즘 뉴스 좀 코믹하긴해. 저번엔 생방송 도중 웃어버리면서 진행하다가 결국 하차해버린 어느 여 아나운서가 생각난다. 징계감이기도 한건 맞지만 순간 웃음을 참지 못하여 그자리에서 내려와버린게 아쉽기도 했는데...

대학다닐때 빌보드 Top10 안에 진입했었던 그녀의 음악을 듣고 바로 구입해 버렸었다. 배철수 음악캠프에서도 참여해서 앨범 표지에 대한 말을 여러 주고 받고 했던 기억도 나긴 하는데...
메릴베인브리지라는 아티스트는 그리 우리나라에서 인기가 없었다. 나혼자만 열심히 좋아했던 1996년도 였다. 음악들어보면 나혼자 좋아 듣는 앨범은 아닌데 왜 우리나라는 좋은 음악에대한 홍보를 안하는지 이젠 지겨울정도다. 90년도 팝음악들은 거의 돌풍이였는데 요즘은 내가 거꾸로 찾아서 들어야 한다는것이 조금 안따까울 뿐이다.

두번째 앨범이 나온지도 몰랐다. 지금 어떻게 찾아볼려고 하는데 쉽지 않은데 누가 구해주기라도 했으면...
WMA로 된 음악을 다운받아서 들어봤었는데 좋은데 왜 수입이 안되었을까...
우리나라 사람은 호주 여자가수를 싫어하나?
세비지가든은 절라 좋아하면서 메릴베인브리지는 왜지? 음악이 우울한 타입이라서 그런건가? 우울하기보단 너무 흥겨운 멜로디가 많은데 말이지.