2014 STATE OF DEVOPS REPORT

Owned by Taejoon Moon
Jun 20, 2019


리포트를 보기 전에 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에 대한 조사 및 분석 결과입니다.

2014 STATE OF DEVOPS REPORT

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

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

목차

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

생략