Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
2014 STATE OF DEVOPS REPORT

 

리포트를 보기 전에 DevOps에 대해서 먼저 알고 있어야 합니다. 아래 내용 참고.

Devops 란 무엇인가? : 버전관리, continous delivery http://www.slideshare.net/ds5apn/dev-ops-2013041801pdf 문서참고.
DevOps라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합 을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다.
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology(IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services. http://en.wikipedia.org/wiki/Devops
DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산 하는 것에 도움이 되는 것을 목적으로 한다.

개발팀과 운영팀을 지원/선도하는 조직으로써, 서비스 기획 및 개발 시작 단계에서부터 서버설치, 개발, 빌드, 테스트, 배포, 모니터링까지 모든 서비스 라이프 싸이클 프로세스를 자동화 개선해 나가는 조직

2014 STATE OF DEVOPS REPORT

2014 STATE OF DEVOPS REPORT 는 Puppet Labs, IT Revolution Press, ThoughtWorks 라는 곳에서 Devops에 대한 조사 및 분석 결과입니다.

리포트 출처 : http://puppetlabs.com/2014-devops-report?imm_mid=0bff95&cmp=em-velocity-na-na-newsltr_20140718_direct

또는 제 위키 pdf 2014-state-of-devops-report.pdf

주요 내용만 살펴보겠습니다.

목차

Executive Summary .................................................................................. 3
Who Took the Survey ................................................................................ 6
Organizational Performance ..................................................................11
IT Performance .......................................................................................13
The Culture of High Performance ......................................................... 20
Job Satisfaction .......................................................................................24
Recommendations for Improvement ....................................................26
Report Contributors ...............................................................................30

performance는 생산성으로 번역을 했습니다.

결과 요약

devops 레포트에서는 조직 생산성, it 생산성과 DevOPS 경험간의 상관관계를 분석하고 있습니다.
분석결과를 다음과 같이 요약하고 있습니다.

  • Strong IT performance is a competitive advantage.
  • DevOps practices improve IT performance.
  • Organizational culture matters.
  • Job satisfaction is the No. 1 predictor of organizational performance.

강력한 IT 생산성은 경쟁력을 지닌 장점이 있습니다. 강한 IT 조직을 가진 곳에서 더 좋은 수익성, 시장 점유율 등을 가지고 있습니다.
DevOps 경험은 IT 생산성을 개선시킵니다.
조직 문화가 중요합니다. 조직 문화는 IT 생산성과 전반적인 조직 생산성에 대한 가장 뛰어난 지표가 됩니다. 매우 신뢰과 높은 조직에서는 좋은 정보 흐름, 각 팀간 협업, 책임 공유, 실패에서 배우고 새로운 생각을 제시하기 등을 북돋아주고 있습니다. 또한 이것을 더 높은 수준에서 실행을 합니다.
업무 만족도는 조직 생산성에서 가장 첫번째의 지표가 됩니다.

Who Took the Survey

110여개 국가에서 9,200 여명의 사람들이 설문에 참가했습니다.
조직특성, 지역별 분포, 회사규모, 서버의 수 등은 해당 원문을 직접 보시면 됩니다.

재미있는 부분은 속한 팀(Departments)에서 16%는 운영부서나 연구소가 아니라 DevOps 팀이라는 것입니다.
DevOps 롤에서도 시스템 엔지니어나 개발자가 아닌 DevOps Engineer가 31.3%가 된다는 것입니다.

조직 생산성

조직 생산성에 영향을 미치는 주요한 세가지를 다음과 같이 정리하고 있습니다.

  • IT 생산성과 DevOps 경험(continous delivery 등)
  • 조 직 문화와 배우려고하는 풍토 : DevOps라는 것은 단순한 툴이나 프로세스가 아니라 문화라는 것을 강조하고 있습니다. 강한 신뢰를 가진 조직은 good information flow, cross-functional collaboration, shared responsibilities, learning from failures and encouragement of new ideas 등의 특성을 가지고 있다고 이야기를 합니다.
  • 업무 만족도 : 업무 만족도는 조직 생성산의 가장 첫번째 지표입니다. 업무만족도는 또한 DevOps 경험과 문화에 매우 밀접하게 연관이 있습니다.

IT 생산성

이 문서에서는 IT 생산성을 처리량(throughput)과 안정성(stability)로 나누고 그 안에서 세부항목으로 나누고 있습니다.

  • 처리량 Throughput Metrics
    배포 주기(Deployment Frequency) : Continuous Delivery, Version Control
    변경에 걸리는 시간(Lead Time for Changes) : Version Control, Automated Testing
  • 안정성 Stability Metrics
    복구에 걸리는 평균시간 (Mean Time to Recover) : Version Control, Monitoring System and Application Health (proactive 모니터링을 언급하고 있습니다)
    변경실패 비율 (Change Fail Rate) : Not strongly correlated with specific practices.

그러고나서 세부 항목을 상세히 설명합니다.

  • Continuous Integration and Continuous Delivery
    이 부분은 직접 검색을 해서 찾아보시면 됩니다. 소프트웨어 개발, 테스트, 실서비스 배포 등 전체 과정을 자동화하는 것을 의미합니다.
    버전 관리는 필수이고 자동화된 테스팅 도구도 필수입니다.
  • Automated Acceptance Testing
    이 부분은 제가 정확하게 이해가 기지 않는 부분인데요. 아래 영문으로 대체를 합니다. 새로운 기능을 개발했을 때 자동화된 테스팅으로 받아들이면 될 듯 하네요. 어찌되었건 중요한 것은 테스팅을 수동으로 하는 것이 아니라 자동화되어 처리를 해야 한다는 것입니다.
    As part of continuous delivery, automated acceptance tests are written alongside new code to ensure that new features meet business requirements, and existing high-value features are protected against regressions. New versions of the system must pass numerous automated tests before they can undergo exploratory testing and be deployed to production, substantially reducing the reliance on time-consuming and error-prone manual regression
  • Version Control
    버전관리는 소프트웨어 코드만을 의미하지는 않습니다. 지금문서에서도 다음의 내용을 포함하고 있습니다. 간단히 말하면 개발코드든 시스템 설정이든 변경을 하는 것이라면 모든 것이 버전관리가 되어야 한다고 생각을 하시면 됩니다.
    애플리케이션 코드
    A애플리케이션 설정
    시스템 설정
    모 든 테스팅, 배포 스크립트(Tests and deployment scripts that are used to validate software and deploy it to test, staging and production environments Comprehensive version control enables us)

IT생산성을 판단하는 5가지 지표

  • Peer-reviewed change approval process. : 재미있는 내용이 있습니다. 현재 Change Management 를 할 때와 같은 external change approval (e.g., change approval boards) 에 대한 내용이 있는데요. external change approval 는 IT 생산성을 떨어뜨리는 반면에 기술팀에서 peer review 동료 평가를 하는 경우에는 코드의 질도 높아지고 생산성도 늘린다고 말을 하고 있습니다. external change approval processes 는 복구 시간에는 전혀 영향을 미치지 않고 변경 실패 비율을 줄이는데는 약간의 영향만 미칩니다. 다른 말로 하면 external change approval boards 는 생산성에 매우 안 좋은 영향을 미치는 반면에 안정성에는 하찮은 향만 미칠 뿐입니다.

  • Version control for all production artifacts : 버전 관리는 모든 변화에 대해서 단일한 소스가 됩니다. 문제가 생겼을 때 문제의 원인을 찾기도 쉽고 빠르게 복구를 할 수 있습니다. 또한 팀간에 협업도 강화를 시킵니다. 버전 관리의 장점은 애플리케이션 코드에만 국한된 것이 아닙니다. 시스템과 애플리케이션 설정 모두에 버전 관리를 쓰고 있는 조직에서 더 높은 IT 생산성을 보이고 있습니다.
  • Proactive monitoring : Proactive 모니터링은 문제가 생기고 나서 문제를 해결하는 것이 아니라 사전에 알아서 문제를 줄이는 것을 말합니다. proactive 모니터링을 사용하고 있는 곳에서는 문제를 더 빠르게 진단하고 해결할 수 있으며 좀 더 강한 책임을 갖게 됩니다. Proactive 모니터링이 없다면 문제가 생겼을 때 모니터링 조직 또는 고객을 통해 알게 되고 IT 생산성에 악영향을 미치게 됩니다.
  • High-trust organizational culture : DevOps 의 가장 중요한 것중의 하나가 문화입니다. 조직 문화가 IT 생성성과 조직의 생산성을 알려주는 가장 큰 지표가 됩니다.
  • Win-win relationship between dev and ops : dev vs ops 가 아닙니다. dev + ops 입니다. dev 와 ops 의 상호관계가 좋을 수록 IT 생산성이 커집니다.

높은 생산성의 문화

이 부분은 생략하고 넘어갑니다. 조직 문화를 진단하는데 이론적인 내용을 이용하고 있는데요.
Typology of Organizational Culture 제가 이 부분은 잘 모르겠네요.

조직 문화의 주요 지표만 소개합니다.

  • 업무만족도
  • 배우려는 풍토
  • dev와 ops간에 윈윈 관계
  • 버전 관리
  • 자동화된 테스팅

업무 만족도

업무 만족도가 조직 생성산에 많은 영향을 미칠 것이라고 예상은 했지만 조직의 생산성에 가장 첫번째 지표가 되는 것 때문에 놀랐다고 이야기를 하고 있습니다.

While we suspected job satisfaction affects organizational perfo rmance, we were surprised to find that job satisfaction was the No. 1 pr edictor of organizational performance.

 

How Does Job Satisfaction Impact Organizational Performance?
People who feel supported by their employers, who have the tools and resources to do their work, and who feel their judgment is valued, turn out better work.

회사에서 지원을 하고 있다고 생각하고 자신의 작업을 위해서 적당한 도구와 자원(resource)를 가지고 있으며 평가가 공정하다고 느낄 때 더 일을 잘 한다고 합니다.

DevOps 는 문화입니다. 그렇지만 업무 만족도는 해당 업무에 대해서 적절한 도구와 자원을 가지고 있는지에 대해서 크게 의존을 합니다. 도구는 DevOps 경험중에 중요한 부분이고 이러한 도구는 자동화를 제공을 합니다.

업 무 만족도에 크게 영향을 미치는 것으로 다음을 이야기하고 있습니다. proactive 모니터링, 버전관리, 자동화된 테스팅은 앞에서 언급을 했던 부분인데 feedback loop 에 기반한 결정이 필요하다고 이야기를 합니다. feedback loop 에 기반한 결정이란 사회학적인 이야기인 것 같은데요. 아마도 일방적인 지시와 업무 진행이 아니라 끉임없이 주고받으면서 발전을 할 수 있는 것을 말하지 않나 생각이 듭니다.

Proactive monitoring, version control and automated testing all automate menial tasks, and require people to make decisions based on a feedback loop.

업무 영향도의 주요 지표는 다음과 같이 정리하고 있습니다.

  • 서로 강하게 신뢰하는 조직 문화
  • 배우려는 풍토
  • 각 팀간에 윈윈하는 관계
  • Proactive 모니터링 및 autoscaling
  • 모든 소스 및 설정에 대한 버전 관리 사용
  • 자동화된 테스팅

개선을 위한 권장사항

조직을 발전시키는 것은 간단하거나 쉬운 작업은 아니며 절대적인 방법이 없습니다. 지금의 레포트에서는 관리자와 직원으로 나누어서 다음 항목에 대해서 몇가지 추천을 하고 있습니다.

  • Cross-FunctionalCollaboration
  • Climate ofLearning
  • Tools

제가 관심있게 본 부분만 소개를 하겠습니다.

  • Cross-FunctionalCollaboration 의 Managers 에서 서로 다른 팀간에 이동하는 것을 권장하고 있습니다. 관리자나 엔지니어는 자신의 기술 습득을 위해서 다른 팀의 역할에 대해서 관심을 가질 수 있습니다. 이런 경우의 팀이동은 두 팀 모드에 가치가 있다고 봅니다. 새로운 팀의 프로세스와 문제점 또는 도전과제를 통해서 의미있는 정보를 뽑아낼 수도 있고 그 사람이 속했던 이전 팀에서는 해당 팀과 협력할 수 있는 사람이 생기는 의미가 있다고 합니다. 특정한 조직에 오래 있다보면 자기 팀의 이해관계만 보이는데 본인이 관심이 있는 팀으로 옮기는 경우에 팀간의 이해도도 늘릴 수 있고 옮긴 사람을 통해서 해당 팀간에 협력하는 분위기도 만들어 질 수가 있습니다.
  • Climate ofLearning 의 Manager 에서 언급한 내용입니다. "Make it safe to fail." 만약 조직에서 실패하는 것을 허용하지 않는다면 누구도 새로운 것을 시도하지 않으려고 합니다. 실패 자체를 문제삼고 비판만 하는 것이 아니라 배울 수 있는 기회로 생각한다면 또한 그것을 통해서 프로세스와 시스템을 개선하려고 하는 조직이라면 사람들이 용납할만한 위험에 대해서는 충분히 감수하려고 할 것이고 새로운 혁신 문화가 생기는데도 도움이 될 것입니다.
  • Tools 의 Manager 에서 언급한 내용입니다. Make sure your team canchoose their tools. 자신의 도구를 직접 선택할 수 있는지에 대한 질문입니다. 자신이 도구를 직접 선택할 수 있으면 당연히 자신이 직접 하는 일에 대해서는 더 재미있게 할 수 도 있고 시간도 더 쏟을 수 있습니다. 그게 아니고 딱 정해진 도구만 쓰고 자신이 도전해 볼 만 한 것이 없다면 재미가 없겠지요.

Report Contributors

생략

안녕하세요 sysadminstudy 구글 그룹 개통했던 문태준이라고 합니다.
오랜만에 글을 적습니다.
2010년 8월까지 스터디모임을 하고 개인적으로 여러가지 일들이 있어서 손을 놓고 있었습니다.
개인홈피도 서버호스팅받던 회사가 망해서 가상호스팅으로 옮겼다가 관리가 귀찮아 손놓고 있었지요.
조만간 그동안의 여러 작업을 공유하기 위해서 개인홈피를 올릴 예정입니다.

올해초 딸쌍둥이 낳고 두달간 육아휴직도 했었는데 당분간 육아때문에 스터디모임은 직접 참석은 하지 못하겠지만 온라인으로라도 각종 정보 공유하는 작업을 하려고 합니다.

2009년 11월 스터디모임에서 공개세미나를 진행했었는데 그로부터 몇년이 지났지만 얼마나 우리나라 IT운영이 발전하거나 변했을까 궁금하기도 합니다.
http://wiki.kldp.org/wiki.php/SyadminStudyConf/20091124

요즘 한창 클라우드 컴퓨팅 이야기를 하지만 클라우드이건 물리적인 시스템이건 자동화된 인프라, 각종 도구들이 필요한건 마찬가지라는 생각이 듭니다.
해 외에서는 이미 보편화되어 있는 cfengine/puppet/chef 같은 설정관리툴, LDAP을 이용한 중앙인증시스템, kickstart와 pxe를 이용한 OS자동설치 시스템 등등 예전 논의하고 공부했던 것들이 있었는데 몇년이 지난 지금도 국내 IT 운영기술은 여전히 그대로 인 것 같습니다.

저는 현재 대략 다음의 기술들을 사용하고 있습니다. 제가 한것도 다른 사람이 한것도 다른 팀에서 한것도 있습니다.
http://wiki.kldp.org/wiki.php/SyadminStudyConf/20091124 에서 제가 발표했던 기준으로 설명드립니다.
- OS 설치 : kickstart 이용, 각 프로파일별로 파티션 및 후속 작업까지 자동화. 표준화된 하드웨어 사용하며 ipmi 세팅까지 kickstart에서 자동 설정. PXE는 대규모 설치를 할 경우에만 사용. 글로벌환경을 위하여 global cache 이용한 kickstart 서버 이용.
- Server Inventory : 자체 제작 CMDB 이용
- Identity Management : OpenLdap/AD 이용. opendalp replicaton 이용하여 각 지역의 ldap 서버에 접속하여 각 edge 에 접속함. apache, svn 등 각종 애플리케이션 인증, VPN, DRAC, 각종 내부 솔루션은 기본적으로 ldap을 이용함. 각 edge 에 접속하기 위한 gateway 서버의 경우 ldap slave 기능을 하되 각 edge 에서 직접 ldap연동을 하지 않고 gateway 서버에서 호스트 그룹별-사용자 권한별로 edge 에 접속할 수 있도록 구현함.
- Version Control : svn 이용하며 svn hook script를 이용하여 puppet 등의 변경작업을 할때 문법체크를 하고 svn slave 서버로 데이터 동기화를 함. commit 되었을 경우 담당자에게 이메일 발송함
- Configuration Management : 일부 cfengine 이용하고 기본은 puppet 을 이용함. puppet 의 경우 gslb 같은 기능을 이용하여 각 국가에서 가까운 puppet 서버에서 정보를 받아옴. 서비스단말고 시스템단의 모든 설정은 매뉴얼로 하지 않으며 puppet 모듈을 만들어서 처리함. 설정이 잘못 내려갈 것을 대비하여 edge 와 puppet 서버간의 revision 을 비교하여 적용함. 중요한 것은 "코드로 인프라 관리하기"
- Monitoring : 리눅스는 nagios 프로그램을 이용하되 운영자에게 각종 알람은 별도의 프로그램을 만들어 필요한 것만 알람을 받도록 구성
- Trending
- Email
- Applicaiton Deployment : 표준화된 배포프로그램을 자체 개발하여 사용.


기타로 다음의 같은 작업들이 있습니다.
- QA 환경구축 : 실서버 적용전 실서버와 동일한 네트워크로 구성된 곳에서 테스팅하고 확인함. 이건 기술적인 것이라기보다는 정책적인 부분이지요.
- 시스템메일을 위한 중앙이메일시스템구축 : 시스템의 각종 cron 로그는 메일링서버로 보냅니다. 개별서버차원에서 cron 메일관리하기는 힘들고 히스토리 유지가 힘들기 때문에 중앙메일링시스템을 이용합니다. 그러면 cron 에서 나오는 모든 이메일을 체크할 수 있습니다.
- 중앙로그관리시스템구축 : syslog 대신 rsyslog 를 이용하여 중앙의 로그관리서버로 보냅니다. logstach, graylog2, elasticsearch 등을 이용하여 실시간으로 로그를 받고 필터링하여 필요하면 알람을 줄 수도 있고 문제해결을 하기도 합니다. 예를 들어 각 edge 에 접속하는 사용자의 모든 명령도 중앙로그서버로 보내기 때문에 로그서버에서 실시간으로 특정 사용자가 무슨 작업을 하는지 확인 가능합니다. (이 경우 bash 를 패치하여 bash 에서 syslog 로 로그를 남기도록 설정해야 함)
- OS : CentOS 를 커스터마이징하여 사용을 하되 각종 rpm 패키지 설치등은 운영자가 임의로 하지 않고 자체 yum repo만 사용하도록 되어 있습니다. OS 배포본 관리, RPM 관리의 어려움은 있지만 단일하게 RPM을 관리하는 장점은 있습니다. bash, openssh 등은 일부 소스차원에서 패치하여 각종 접속기록을 남기도록 구성하고 있습니다.

장황하게 설명을 하였지만 앞으로 계속 공유하는 작업 진행하겠습니다.

작은 정보라도 공유를 해주시면 더욱 좋겠습니다.