(정리) 인프라 조직 셋업 하기-2022
IT기업 되기
회사의 규모가 커지고, 디지털화가 가속화됨에 따라 인프라도 빠른 대응이 필요하다.
사람이 아닌 시스템으로 돌아가는 회사로 만들어야 한다.
지금도 많은 IT기업이 커가며 체계를 잡아야 하는 경우가 있을 것이다.
회사가 분사와 합병을 거듭하고 있다.
이럴 때 이 글이 도움이 될 거 같아 적어 본다.
인프라 경력 20년 이상
아래는 개발, 인프라가 없는 대기업이 IT기업으로 변화하는 과정에서 얻은 노하우를 정리한 내용이다.
나는 인프라 조직 셋업 전문가이다.
네이버 인프라 조직 셋업을 같이 함.
대기업으로 이직해 네이버 인프라 환경을 동일하게 셋업함.
조직 셋업은 달리는 자동차의 바퀴를 바꾸는 일과 유사하다.
<1> 업무를 나누어 함께 하라
<2> 새로운 일을 하라.
<3> 새로 자동차 바퀴 갈아 끼우기와 오래된 자동차 바퀴 교체 하기
<4> 결과
<5> 정리
<10> 대규모 인프라를 운영하기 위한 15가지 정보
<1> 업무를 나누어 함께 하라
휘익~
어디선가 사람이 날라 왔다.
나다.
네이버에서 대기업으로 이직했다.
운영 총괄이라는 직책?이다.
대형 서비스 여러 개와 여러 개의 IDC 운영 총괄이다.
현재 운영은 되고 있다.
개발자가 늘어난다.
100명, 1000명, 3000명까지~
손님 10명 왔을 때 라면을 잘 끓이지만, 손님이 100명이 오면 라면 끓이는 방법이 달라져야 한다.
IT도 마찬가지이다.
10명의 문의를 메일로 처리했지만, 100명의 문의는 메일로 처리하지 못한다.
시스템이 있어야 한다.
네이버 업무요청 시스템을 JIRA로 그대로 복붙해 구축했다.
자동차에서는 바퀴가 추가로 있어야 한다는 것이다.
2대의 바퀴로 달릴 수 있지만, 사람들을 더 태우려면 4바퀴가 안정적일 것이다.
네이버 1만 명의 직원이 사용하는 인프라 시스템을 구축했던 경험이 있다.
이곳에 적용하자~
자동차는 달리고 있었고, 운행하는 엔지니어도 있었다.
혼란스러워한다.
이 사람은 왜 와서 뭘 하려는 것인지?
같이 정리했다.
당신은 지금 하던 일은 하고
나는 위에서 실행이 필요한 일을 확인하고 같이 상의하는 일을 하겠다.
업무를 나누었고, 일은 함께 했다.
<2> 새로운 일을 하라.
차로 말하면 두 바퀴로 달리고 있는데 바퀴를 빨리 만들어 4바퀴로 달리게 하는 일을 했다.
기존에 두 바퀴로 달리고 있던 차다.
내가 와서 달리고 있던 두 바퀴가 잘못되었다고 갈아야 한다면, 충돌이다.
차가 멈춘다.
나는 기존에 없는 다른 두 바퀴를 만들고, 교체하는 일을 했다.
다행히 기존 대형 포털에서 얻은 많은 바퀴를 가지고 있었고, 교체 기술도 있었다.
바퀴 교체를 전문으로 하는 인원 3명도 같이 데리고 왔다.
바퀴는 잘 교체되었고, 차는 지금까지 잘 굴러간다.
지금은 내가 할 일이 별로 없다.
<3> 새로 자동차 바퀴 갈아 끼우기와 오래된 자동차 바퀴 교체 하기
1
메일로 업무 처리?
출근하니 수십 통의 업무 요청이 메일로 와 있다.
다들 회신한다.
이렇게 이렇게 해보세요.
다시 메일이 온다.
안돼요. 다시 알려주세요.
다시 회신..
메일 하나에 회신 회신으로 벌써 10통이 되었다.
개발자가 100명에서 1000명으로 늘었다.
이제 메일이 폭탄 수준이다~
요청 온 내용이 완료되었는지 미완료인지 확인도 안 된다.
JIRA로 업무 요청 시스템을 만들었다.
요청 시스템으로 요청한 것을 우선으로 처리하라고 했다.
완료 여부도 남는다.
메일로 문의가 온건 나중에 처리한다.
작업 이력관리를 위해 메일로 문의가 온건 업무 요청 시스템으로 요청하라고 가이드한다.
그래도 몇 달은 메일로 요청이 온다.
1년이 지나니 대부분의 업무 요청은 시스템으로 처리가 되었다.
2
사업부서에서 장애를 모른다?
어제 장애가 났는데 사업부서에서 장애를 모른다고 한다.
왜냐하면 개발이나 인프라만 알고 담당자에게 전파 잘 안되어서 이다.
사업부에서는 장애 난 걸 알아야 고객 대응을 한다는 것이다.
서비스 장애 관리 센터를 만들었다.
장애는 인프라 폴트와 서비스 장애가 있다.
인프라 폴트는 서버 2 대중 1대가 폴트가 났지만, 서비스는 잘 되는 것이다.
서비스 장애는 사용자가 접속이 안되어 서비스가 안 되는 상태이다.
회사의 규모가 커지면 , 이런 서비스 장애만 전담으로 하는 조직이 필요하다.
장애 처리 담당 전문가 2명을 데려 왔다.
변경 관리시스템과 장애 관리 시스템을 만들었다.
장애 관리 시스템은 ISMS 장애 증적 자료로도 이용되었다.
서비스만 모니터링하는 시스템도 필요하다.
조직과 기존 모니터링 시스템중 서비스로 이용할 만한 툴로 URL 모니터링을 시작했다.
서비스 별 담당자도 지정하여 , 서비스 장애 시 해당 사업, 개발, 인프라 담당자에게 모두 전파되었다.
이제 서비스 장애를 사업부가 몰라 대응 못하는 경우는 없어졌다.
3
자산관리가 안된다. ISMS 심사 시 지적 사항이다.
자산을 구매하면 어디 IDC 어느 랙 몇 번째 칸에 장비가 있는지 확인이 되어야 한다.
그러나 바로 찾을 수 없다.
담당자가 없었다.
포털에서 사람을 데려 왔다.
해결되었다.
자산 여러 개 구매하면 그 구매 번호를 기준으로 같이 구매한 서버, 스토리지, 네트워크 장비를 세분화하고, 물리적 위치를 기입하는 프로세스를 만들었다.
자산 관리시스템으로부터 기본 정보를 받고, 운영 정보를 입력하는 운영 디비 시스템을 만들었다.
CMDB를 만들었다.
이제 바로 자산을 구매하면 어디 IDC 어느 랙 몇 번째 칸에 장비가 있는지 확인이 된다.
4
DNS 신규와 추가 요청은 하루?
개발자가 DNS 변경 요청을 한다.
협력업체가 요청을 정리해 저녁에 작업한다고 한다.
왜?
장애 등 날지 몰라서..
그리고, DNS 시스템은 분사 전 본사에 있었다.
우리 것이 없었다.
새로 직접 DNS 시스템을 구축했다.
DNS 요청이 오면 10분 내로 처리를 해주었다~
개발 생산성이 엄청 빨라졌다 ^^
5
표준화 하기
여러 회사를 합병했다.
서버 OS부터 같지 않았다.
표준화해서 같은 OS와 룰로 운영되도록 했다.
보안 점검까지 받은 OS를 표준으로 해서 바로 서버 생성함
OS 설치하고 다시 보안 점검받지 않도록 개선함.
이런 거 다 포털 다닐 때 배운 거로 써먹음~
6
SPOF 제거 프로젝트
네트워크 SPOF 제거
서버 SPOF제거
스토리지 SPOF
회사에서 뭐 내놓으라고 할 때 SPOF제거 써먹기 좋습니다.
10년이 지난 지금도 SPOF제거 한다.
<4> 결과
1
회사의 개발 생산성은 향상되었다.
DNS신청부터 빠르게 처리되었다.
업무에 대한 요청과 처리가 명확해졌다.
장애에 대한 인지와 처리, 후속 조치까지 진행되었다.
자산 관리가 명확해졌다. 법적 지적사항 해소되었다.
2
나는 2년간 평가가 좋았고, 연봉도 1,000만 원 이상 인상이 되었다.
조직장이 특별 보너스도 주었다.
불만이 없어서 따로 찾아뵙진 않았다.
전화 오셔서 특별히 성과를 주었는데 연락이 없어 전화하셨다고 한다.
난 사회생활을 못하나 보다~
다 네이버 다닐 때 알았던 시스템을 가져다 쓴 거다~
<5> 정리
# 잘 한 점과 필요한 것
1
개선을 하기 위해서는 조직장의 절대적인 지원이 필요하다.
직책은 아니지만 인프라 운영 총괄이라는 이름을 달고 진행되었다.
2
기존 인원과 업무 분장을 잘 하자.
기존 인원이 실무 영역을 하고 있고, 실무를 관리하고 싶다면 기존대로 위임해주자.
나는 윗선과 커뮤니케이션하는 역할로 업무 분장했다.
3
없는 신규 시스템을 구축하라.
있더라도 아주 불편해 누가 보더라도 잘 바꿨다고 생각하는 것을 바꿔라.
기존에 있는 시스템을 건드리는 건 기존 업무 담당자가 잘못했다고 받아들여 충돌이 난다.
없던 자산관리와 운영을 위한 CDMB 만들기
없던 서비스 코드와 CDMB를 만들어 사업 부서에 인프라 비용 배부
없던 서비스 장애를 모니터링하고 전파, 개선하기 위한 인원, 조직 구성
너무나 오래 걸리던 DNS처리
메일 폭탄을 업무 요청 시스템으로 전환
없었던 장애 예방을 위한 SPOF제거 프로젝트
# 주의점
너무 빠른 조직 셋업을 하느라 인원 충원도 전에 장애 관제 센터 맡았다가 혼자서 몇 달간 24시간 전화를 받게 되었다.
입이 화근이다.
필요하다고 이야기하면 위에선 빨리 했으면 하기 때문에 주의 바란다.
<10> 대규모 인프라를 운영하기 위한 15가지 정보
https://brunch.co.kr/@topasvga/1510
