옥희 회원님께서 번역해 주신 DevOps관련 글입니다.
모든 개발자들이 개발 방법론 협업 방법에 대해서 항상 고민하고 있습니다.
이와 관련해 한번쯤 꼭 읽어 보시기를 권해드립니다.
출처 원문 : http://java.dzone.com/articles/devops-isnt-killing-developers
DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity
DevOps은 개발자를 힘들게 하지 않는다.-다만, 개발과 개발자의 생산성을 놀랍도록 끌어올린다.
이러한 DevOps Zone 은 PagerDuty와 새로운 C.A.L.M을 지속하고 DevOps 문화를 설립한 것을 수행한 분들에 의해 소개되었다. Devops은 개발자를 힘들게 하지 않는다 (적어도 내가 아는 한 어떤 개발자도 난처한 적 없다.) 그러나 Devops은 개발자를 미치게 만들거나, 소프트웨어를 개발하고 전달하며 우리가 대부분 생각하는 방법을 제시한다. 애자일(Agile)은 총이며, Devops는 방아쇠를 당긴다.
전달보단 흐름으로…..
바다가 변화하듯, 소프트웨어 역시 개발되고 전달된다. 큰 규모의 폭포와 같은 소프트웨어 개발 프로젝트는 단계적인 전달과 나선형(Spiral) 접근법을 제공한다. 그리고 소규모팀들에게 제한된 시간에 일 할 코드를 전달한다.(사용중인 스크럼[Scrum]이나 다른 반복적인 애자일 방법들을 제시한다). 이제 트렌드가 스크럼에서 칸반(Kanban)으로 이동 하고 있다. 직관적인 하나의 계속적인 흐름(One-Piece Continuous Flow) 그리고 Devops에서 생산하는 코드의 계속적인 배치(Continuous Deployment) 도 주목 받고 있다.다양한 규모가 축소되는 방향으로 개발이 자꾸 집중되기 때문에, 일을 빠르게 끝마치기 위해 시간 틀(frame)을 시행한다. 이런 면과 기준 그리고 프로젝트 검토에서 조금씩 확실하게 최선을 다해 검토하고 진행 중인 일의 한계와 과업의 수준을 최적화 하기위해 통제(Control)한다. 이런 소프트웨어 제품의 규모에 따라서, 어떠한 프로젝트 팀은 1년 후에 완성된 결과물(프로젝트)을 전달하거나, 스크럼 팀(Scrum team)이 1달 후나 1주 후에 프로젝트를 완수하고, 어떤 개인적인 개발자는 몇 시간 후나 며칠 후에 개발을 시작한다. “끝냈다”는 것의 뜻과 “작동중인 소프트웨어” 라는 것은 암호 혹은 부호로 처리가 되어 있고 잘 되거나 시험운행(테스트)하는 것이 가능하며 제작한 소프트웨어를 증명할 준비가 된 생산작업에 의해서 바뀔 수 있다는 것이다. -지금(“끝은 공유를 의미한다.(Done Means Released)”에서).
지속적인 전달과 지속적인 배치는 지속적인 통합이라 말할 수 있다.. 작업에서 신속한 배치는 수작업으로 확인하는 담당자나 수작업 테스트 중일 때 있어서, 시간을 낭비하지 않는다. 개발자들은 코드를 제품출시 하기 전에 소프트웨어 제품을 시험운행하며, 소프트웨어에서 발생한 문제를 해결하기 위해, 해당 소프트웨어 제품의 모든 버그를 포착하여 문제를 해결해야 할 책임이 있다.(아카[aka]”시험운행 중으로서의 관찰”에서)
그 이유는 데브옵(Devops)은 개발자들에게 소프트웨어 제품생산을 손쉽게 하며, (소프트웨어 제품)동작시 위험이 프로젝트 위험보다 더 중요하게 되며, (소프트웨어 제품)동작에 대해 측정한 것 역시 프로젝트를 측정한 것보다 중요하다. 소프트웨어 제품을 작업함에 있어서 시스템 가동시간과 순환시간(cycle time)은 획득한 가치나 속도로 대체한다. 다급한 마감시한에 대한 강조는 생산시 다급함에 대한 강조며 관심사 1순위로 대신하게 된다.
데브옵(Devops)은 프로젝트를 전달하거나 심지어 기능을 전달하지 않는다. 이것은 최소화된 리드타임(생산부터 완성까지 걸리는 시간)과 작업에서 생산까지 최적화된 흐름, 화제를 놓치지 않으며, 쓸데없는 일을 하지 않음과 동시에 지연되고 미뤄진것은 신뢰할 수 있는 시스템으로 개선하는 것, 운영비용을 삭감하고 생산에서 개발까지 계속적인 조언으로 반영한다. 추가로, 표준화하고 자동화하는 절차가 가능한 많이 있다. 보통의 공학기술 보다 과정을 제어하고 생산하는 것이다.
데브옵은 개발자 생산성 역시 기여한다.
데브옵은 또한 개발자의 생산성에 기여한다.당신은 LOC에 의해서 개발자 생산성을 판단하거나 기능의 강조점 이나 기능점 이거나 이야기의 강조할 점 이거나 빠르기나 작성된 많은 코드 몇 줄의 다른 측정법 등을 적은 코드로 판단한다. 사회 공공 기반 시설과 제시안 [플랫폼] 등을 이해하는 것에 대한 시간 학습은 확실히 만들고 설정을 올바르게 하는 것이다. 그것은. 또한, 계속적으로 발전시키고(Building) 전달하며, 다양한 경로를 계속적으로 배치하는 것이다. 옵스(ops)를 살피기 위해 돕는 것과 이슈를 해결하는 것은, 긴급한 고객의 다양한 요청에 응답하는 것이고 질문과 성능 문제에 대해 관찰하고 시스템을 감시하는 것은 일을 정확하게 하는 것이며, A/B 실험 운영하는 것을 돕는 것이다. 변화를 장려하고 준비하는 것은 시험운행하고 코딩(소프트웨어를 제작하고)하고 설계하며 필수적인 것에 대해 미리 시도하고 개발하는 것으로 부터 시간을 쓰는 것이다.
다중 작업(Multi-Tasking)과 일의 중단에 대한 영향
데브옵에서의 최우선의 변화와 일의 중단으로부터 독자 여러분은 개발자를 보호할 수 없고, 당신이 칸반과 엄격하게 WIP 제한을 사용할지라도, 심지어는 딱 맞게 경영할지라도-이건 독자여러분이 원치 않을 것이다. 개발자들은 운영을 원활하게 하며 고객에 대응할 필요가 있고, 생산한 것으로부터 조언을 받고 수정할 수도 있으며, 문제를 해결함과 동시에 되도록 이면 빠르게 실수를 발견하고 해결하는 것에 도움을 주는 것 이다. 모두에게 이것이 의미하는 것은, 특히 가장 재능있는 개발자들은, 모든 시간을 할애하지 않더라도 대부분 옵스를 필요하게 될 수 있다.개발자들은 몇 시간뒤에 대기 중이었다가 옵스에 접속한다. 하루의 일과를 마치고 난 뒤(퇴근 후), 다시 말해서 (누군가의 호출에 시달리거나) 의무를 다하고 옵스에 접속한다는 것이다. 그리고 시간을 투자하며 문제해결을 위해서 지원 한다는 뜻은 정말 문제가 되게 하지 않기 위해서, 긴 밤과 주말을 바쳐가며 소프트웨어 제품의 이슈를 찾아내고 문제점을 해결하기 위해 도움을 주며, 다음날 피로에 쩔어도 자잘한 운영과 시험운행 및 시스템 대체 작동과 미리 운행(roll-forward)하고 다시 소스를 원복하고(commit 하기 전 roll-back), 프로젝트가 끝난 뒤에도 참여 하며, 프로그램이 뭔가 잘못 돌아가거고 시스템이 대체 작동되거나 미리 운행 (roll-forward)하거나 소스를 원복(원상복귀)시켜도 동작하지 않을 때 문제의 원인을 분석하는 것을 말하는 것이다.
당신은 중단과 운영상의 문제에 대해서 계획 할 수 없다. 그리고 당신은 그것들과 관련된 것을 또한 계획할 수 없다. 개발자들은 그들이 자주 베푸는 헌신에 대해 잊을 것이다. 그러면 왜 그들이 어째서 헌신하는가? 계획을 수립하거나 평가하는 것에 대해서 왜 신경을 쓰는 것인가? 가장 중요한 것에 집중하는 하기 전에, 제대로 우선순위를 매기는 것은 옵스나 고객이 갑자기 필요로 하는 것, 추가로 당신이 할 수 있는 것을 바로 실행하는 것 - 그렇지 않으면 뭔가 더 중요하거나 이슈화 된 것 그리고 그것을 미연에 방지하는 것이다.
개발자로서 옵스에 더욱 시간을 쓰고 책임감을 가지고 행동하는 것은 다중 작업 그리고 본연의 임무를 수행하는 것과 중단 및 비효율성을 가져오기도 한다(본연의 임무만 집중했을때 얻을 이익을 일컫는다). 개발자가 옵스에 참여해서 투자해야 할 시간이 증가하고, 손해보는 시간과 본인을 위한 일을 하지 못하는 것 등이 중단 및 비효율성을 의미한다. 이러한 것은 생산성이 지연되는 결과를 가져온다. 그리고 반면에, 문제해결에 참여한 사람들의 생각하는 능력에 있어서 매우 큰 영향을 주고 문제해결에 기여한다. 그렇지만 계속적인 개발 조언만으로도 개발자만의 작업흐름을 방해한다.
개발자가 코드를 확인한 뒤에, 계속적인 통합을 위해 단위별 테스트를 하는 것은 더욱 퍼포먼스를 증대시키고, 몇 초 혹은 몇 분이 빨라진 다는 점에서 개발자들이 개발자의 괴업과 함께 행동할 수 있게 된다. 그러나 작업을 위해 즉각적으로 배치하는 것이 의미하는 것은 통합테스트 단위를 더욱 확장하는 것을 통해 운영하는 것을 뜻하고, 시스템 시험운행과 계속적인 전달을 위한 다른 확인도 하는 것을 뜻한다(더 철저하게 시험운행 하는 것과 더욱 시간을 들여서 확인 하는 것).그리고 그 다음, 배치를 통해서 단계적으로 실행하며, 작업을 살피고 모든 일이 제대로 돌아가는지 확인 하면서, 어떤 것이 잘못 되었는지 확인 하는 것이다.
만약 거의 모든 단계들이 자동화되고 최적화 되어 있을지라도, 이것들 전부 추가 시간과 코딩하는 것을 떠나서 개발자의 주의가 필요하다.
작업의 흐름을 최적화 하는 것과 운영을 밖의 의미는 개발자의 에너지를 희생하는 것이다. 또는 개발일 그자체를 늦추는 일을 발생시킨다.
기대와 통계(예측) 및 변화해야 할 우대정책
데브옵에서 방법이란, 개발자들(그리고 옵스) 과업을 변화하는 방법과, 그들이 관리되어 지는 것의 변화하는 방법을 이야기 하는 것이다. 그것은 또한 개발자들을 위해 중요한 기대와 통계, 장려책을 변화하기 위한 것이기도 하다.
데브옵의 성공은 운영중인 정보기술 통계에 의해 측정되고, 어떠한 범주의 프로젝트 전달 목표에 의한 것이 아니며, 일정과 비용, 발표할 목표나 최우선적인 헌신을 충족하는 것도 아니며, 혹은 심지어는 제품 디자인 목표에 만족하는 것도 아니다.
- 어떻게 하면 빠르게 팀이 중요한 변화나 문제에 반응할 수 있는가: 작업시간을 변화하는 것과 코딩하는 방법이나 속도 대신 작업 하는 것에 있어서 시간의 흐름(Cycle Time)
- 얼마나 자주 생산하기 위해 변화를 주장하는가.(이것은 여전히 통계적인 면이 있다. 대부분 사람들은 가장 흥분하게 되는 이유는-하루에 얼마나 많은 시간 혹은 1시간에 분당 소요하는 것이나 넷픽스(Netflix)나 아마존(Amazon) 배치의 변화
- 얼마나 자주 실수를 만드는가 - 변화/실패의 비율
- 시스템 의존도와 가동시간-MTBF and especially MTTD and MTTR
- 변화의 비용 - 그리고 전반적인 운영과 지원 비용 등
데브옵스(Devops)는 데브 보다 더욱 옵스다.
더욱 소프트웨어는 빠르게 배급되고 더욱 생산성이 증하하며, 개발은 유지보수하는 방향으로 가고 있다. 프로젝트 관리는 부수적인 관리와 과업(Task) 관리에 의해 대체되었다. 더욱 많이 짧게 수평적으로 계획하는 것이나 계획하는 것은 제시간에 순차적으로 우선시하는 것과 분류하는 것으로 대체되었다.정보 기반시설로서의 코드와 함께 옵스는 개발자가 되었고, 설계하고 코딩 정보 기반시설과 정보 기반시설의 변화, 재활용과 재사용에 대한 생각과 복제와 리팩토링(단위로 묶는 것), 기술적인 의심과 시험 혹은 분석 가능성과 TDD에서 TDI(Test Driven Infrastructure)를 만드는 것에 대해 생각한다. 그들은 더욱 더 날렵하고, 매우 자주 작게 변화를 만들으며, 짬을 만들어서 프로그래밍 하는 것과 시간을 쓰고, 서류작업을 들한다.
그리고 개발자들은 더욱 옵스같이 일을 하기위해 시작한다. 지원과 동작에 대한 책임을 자발적으로 한다. 동작에대한 위험으 첫번째로 생각하고, 제반시설에 대해 관리하며, 제작하는 것의 도구나, 장기간의 설계목표와 함께 동작지원에 대한 즉각적인 단기간 수요의 조화를 이룰 수 있는 방법을 찾는다.
이것 중 어느 것도 온라인 사업에서 오랫동안 일한 사람에겐 놀라운 일이 아니다. 독자분들이 시스템을 넘겨주고 고객은 그 시스템을 사용하기 시작하며, 최우선적으로 변화하며, 독자 여러분 들도 일하고 계획 역시 변화해야 하는 것이다.
이런 식으로 일하는 것은 개발자를 위해서 좋지 않거나 필수적으로 최악이다. 그러나 오늘날 일하는 것과 많은 개발자들이 어떻게 생각 하는 지에 것은 근본적으로 다르다. 더욱 미친듯이 바쁘고 지속적으로 빈번한 방해요인이 오히려 근무시 해야할 일을 잘되게 한다. 동시에 더욱 원칙적이고 더욱 의지한다. 더욱 투명해진다. 더욱 책임감과 의무를 갖는다. 개발은 덜하는 것과 출시, 배포, 동작과 지원에 더 집중한다.
개발자들과 그들의 관리자들 운영중인 정보기술의 더욱 큰 그림의 부분이 되어가며 사용할 필요가 있고, 앱을 설계하는 것과 작성하고 코드를 넘겨주는 것보다 더욱 중요한다. 이것은 아마도 소프트웨어 개발의 미래일 수 있다. 그러나 모든 개발자가 이것을 좋아하지 않거나 혹은 좋아하기도 한다.
Published at DZone with permission of Jim Bird, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
No comments:
Post a Comment