Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

The Practice of System and Network Administration (2/E)

30장 Organizational Structures 조직 구조 요약자료

정리 : 문태준

30 Organizational Structures 조직 구조
30.1 The Basics 기본
30.1.1 Sizing 규모
30.1.2 Funding Models 재원 설계
30.1.3 Management Chain's Influence 관리체인(관리방식)의 영향력
30.1.4 Skill Selection 기술 선택
30.1.5 Infrastructure Teams 인프라스트럭쳐 팀
30.1.6 Customer Support 고객 지원
30.1.7 Helpdesk 헬프데스트
30.1.8 Outsourcing 아웃소싱
30.2 The Icing
30.2.1 Consultants and Contractors 컨설턴트와 도급
30.3 Sample Organizational Structures 조직 구조 예제
30.3.1 Small Company 소규모 회사(20-200명)
30.3.2 Medium-Size Company 중간규모 회사 (200-1000명)
30.3.3 Large Company 대규모 회사 (1천명 이상)
30.3.4 E-Commerce Site 전자상거래 사이트
30.3.5 Universities and Nonprofit Organizations 대학교와 비영리 기구
30.4 Conclusion 결론


30 Organizational Structures 조직 구조

30장에서는 SA 팀을 조직화하는 방식에 대하여 다룸.
조직규모에 따라 소통이 영향을 받음. 조직구조, SA간, SA와 고객간
* SA와 관리자간의 소통은 33장, 34장에서 다루고 있음

30.1 The Basics 기본

많은 SA를 두는 것보다 적절한 SA팀에 적절한 사람을 배치하는게 중요함
적절한 기술와 소통기술이 필요
회사규모에 따라 , 중앙화와 분산화에 따라 다르게 구성을 함

30.1.1 Sizing 규모

일반적으로 SA팀은 필요이상으로 인원이 많은 것보다는 적은 경우가 많음
인원이 많은 경우는 조직에 적절한 기술세트를 가지지 않은 경우와 관련이 됨
고객 지원, 필요한 서비스와 신뢰성을 제공하지 못하는 경우 사람을 더 늘인다고해서 해결할 수 없음.
새로운 사람을 늘리는 것보다는 부족한 기술에 대하여 교육을 하거나 컨설턴트를 늘리는것을 고려해야 함

규모를 판단할 때 인원과 기계의 숫자와 다양성, 작업 형태, 서비스 레벨, 얼마나 미션 크리티컬한 서비스등인지를 고려해야 함.
각종 지원에 들어가는 시간을 분석하는 것이 좋음
트러블 티켓 시스템 분석 등

고객과 SA비율은 다양함. 그러나 최소한 두명의 SA는 필요함. 병이 날 수도 있고 휴가는 가야하지 않습니까!

기계와 서버의 유지보수 시간, 인프라스트럭쳐 유지보수 시간 고려 필요

SA가 사용하는 시간을 분석하고 자동화를 할 부분, 프로세스 개선할 부분을 찾아야 하며 더이상 지원하지 않아도 될 시스템을 찾음.
고객과의 SLA를 정의하고 이 SLA를 가지고 SA 팀의 규모를 판단하는데 사용함


30.1.2 Funding Models 재원 설계

SA 관련된 작업은 일반적으로 수익을 만드는 것보다는 비용을 쓰는 곳으로 보이기 때문에 인원이 모자란 경우가 많음

비용절약은 확인이 힘들지만 문제가 생겨 이익을 만드는 부서에 지장이 생겼을 때 손해를 손실비용은 확인이 쉬움

재원설계는 조직구조에 영향을 줌

모델변경시 SA와 모임을 가지는 것이 중요함. SA에게 관심사를 말하고 질문을 하며 해결책을 제시할 수 있는 기회를 주어야 함

분산모델의 동기는 좀 더 커스터마이징된 서비스를 제공하는 것이며 중앙화는 비용 관리임

중앙화를 할 경우에는 각 부서의 제어권 상실 문제가 있음.

다른 모델로 변경시에는 처음에 잘 하거나 점진적인 개선을 해야 함

sa의 업무와 미리 정의된 SLA에 대한 시간을 분석해야 함

년간보다는 월별 재정 레포트


30.1.3 Management Chain's Influence 관리체인(관리방식)의 영향력

CTO 에 속하면 IT를 투자비용으로 보는 것이며 COO(chief operating officer) 또는 CFO(chief financial officer)에 속하는 경우에는 IT를 절감해야 할 비용으로 봄

SA 관리자는 보고체계가 SA 팀에 어떤 영향을 미치는지를 알고 있어야 하고 보고체계의 단점을 줄이고 장점을 극대화할 수 있는 방법을 찾아야 함

30.1.4 Skill Selection 기술 선택

1) provide maintenance and customer support : 헬프데스크, 서버 유지보수, 2선 헬프데스크 지원 등
2) deployment of new services. implementers. 고객요청에 영향받지 않고 특정 프로젝트에 전담해야 함.
3) the design of new service architectures. architects
4) senior generalists., integrators

규모가 큰 회사에서는 SA가 다른 역할도 할 수 있는 기회를 주고 성장할 수 있도록 자신의 경험을 다른 사람들에게 교육도 할 수 있도록 하는게 필요함

헬프데스트를 통하여 모든 SA를 순환시키는 것이 중요함.

업무순환강조 : 고객과 잘 접하지 않는 SA가 고객지원과 연관된 업무를 할 수 있도록 하는 것이 중요함

상황이 급박하게 돌아갈 때는 전문가를 활용

30.1.5 Infrastructure Teams 인프라스트럭쳐 팀

회사의 규모가 커지면 인프라스트럭쳐를 지원할 전담 인원이 필요함.
인프라스터럭쳐팀은 중앙화된 구조로 구성

30.1.6 Customer Support 고객 지원

고객은 자기를 지원하는 사람이 누군지를 알때 좋아함

분산모델을 쓸 경우에는 SA간의 소통은 약해지고 고객과의 소통은 강해짐
중앙화모델을 쓸 경우에는 SA간의 소통은 강해지지만 고객과의 소통은 약해짐. 고객이 지원을 받을 때마다 지원하는 사람이 달라질 수 있음

고객 그룹당 지원하는 SA를 나누는 방법, 지원을 1선과 2선으로 나누는 방법 등

30.1.7 Helpdesk 헬프데스트

1선의 헬프데스크는 중앙집중화가 좋음
고객은 하나의 전화번호, 이메일 주소, 웹페이지를 원함
규모가 큰 회사는 잘 조정된 지역별 헬프데스크가 필요함. 다중의 헬프데스크에서 상승 절차, 서로간에 이관절차가 중요함

30.1.8 Outsourcing 아웃소싱

시스템 어드민이 회사의 핵심 능력이 아니라고 생각될 때는 시스템 관리에 대한 아웃소싱도 선택할 수 있는 방안임. 작은 규모의 회사, 코로케이션 서비스 등
전자상거래사이트, 보안 등은 아웃소싱에 신중해야 함
아웃소싱을 하는 경우 SLA가 중요함.
아웃소싱에 대해서는 21.2.2 에서 다루고 있음


30.2 The Icing

컨설턴트는 특정 프로젝트에 대하여 새로웁고 깊이 있는 기술이 필요할 때 도움이 되며 Contractors 는 기존 다른 SA가 수행하고 있는 업무를 분담할 때 필요함

30.2.1 Consultants and Contractors 컨설턴트와 도급

컨설턴트와 성공적인 관계를 맺으려면 컨설턴트가 하는 작업에 SA가 관여되어야 함. 특히 chitects 와 implementers
컨설턴트와 SA와의 관계. SA 참여가 중요하고 SA가 신규 프로젝트에 참여할 기회를 주는 것이 중요함.
재미있는 프로젝트에 참여하는 in-house SA를 순환시켜서 모든 SA가 팀을 강화할 수 있는 프로젝트에 참여할 기회를 주는 것이 중요함
계속 쓰지 않는 기술이라면 직접 하는 것보다는 관련업체에 맡기는 것이 나음

30.3 Sample Organizational Structures 조직 구조 예제
30.3.1 Small Company 소규모 회사(20-200명)
전형적인 헬프데스크는 없고 헬프-요청 트래킹 시스템을 사용함
규모가 늘어나면서 고객 지원 역할을 하는 sa를 순환시킴

30.3.2 Medium-Size Company 중간규모 회사 (200-1000명)
전담 헬프데스크 요원이 필요함.
SAs in customer-support roles may still rotate through the helpdesk to augment the dedicated staff.
특정 기술에 특화된 SA가 생김

30.3.3 Large Company 대규모 회사 (1천명 이상)
2선 지원역할을 하는 헬프데스크, 특정 부서를 전담 지원하는 작은 규모의 고객지원팀, 중앙 인프라 스트럭쳐 그룹과 중앙 보안팀
각 기술별 최소 한명의 architect, 각 분야별 implementers 팀
각 지역별 조직 등이 생길 수 있으며 이 경우 소통 경로가 필요함. 가능한 동일한 회사 정책을 가져야 함

30.3.4 E-Commerce Site 전자상거래 사이트

고객지원과 사내지원으로 구분을 함

30.3.5 Universities and Nonprofit Organizations 대학교와 비영리 기구

가능한한 중앙화를 함

30.4 Conclusion 결론

규모와 비용 문제
SA팀 최적화 : 적절하게 기술을 혼합하고 배치함
근거자료 제시하고 펀딩 모델에 제안하고 참여를 함. 비용/이익 분석
중앙화 : 인프라스트럭쳐
분산화 : 고객지원
컨설턴트와 contractors 는 특정 프로젝트에 대하여 단기간에 효과적으로 활용. 그러나 SA도 관심있는 프로젝트에 참여가 보장되어야 함.
대규모 회사는 architects 와 senior generalists 가 필요함.
인터넷을 통해 중요한 서비스를 제공하는 회사는 두개의 팀으로 나누어야 함. 인터넷 서비스를 제공하는 팀은 전형적인 내부 시스템 관리 지원팀보다 더 다양한 기술이 필요함.

Labels
  • No labels