1.
요즘 관심을 가지는 단어중 하나입니다. 언제부터인지 기억이 가물가물하지만 해외의 IT사이트를 볼 때 DevOps라는 단어를 자주 접합니다. 호기심이 생겼지만 잠시 접어두었다가 낱말뜻을 보니까 구미가 당겼습니다.
DevOps은 개발 부문, 운영 부문, 품질 관리 부서 사이의 통합, 커뮤니케이션, 협업을 위한 일련의 메소드 및 시스템이라고 정의하고, 적기에 소프트웨어 제품이나 서비스를 출시를 목표로 하는 조직에 부합하기 위해서는 개발과 운영은 상호 의존을 해야한다는 의미다.
DevOps와 NoOps에 대하여중에서
개발과 운영이 분리되면서 오는 문제점을 해결하기 위해서, 개발과 운영을 하나의 조직으로 합쳐서 팀을 운영하는 문화이자 방법론이다
개발과 운영의 조화 – Devops #2/2중에서
Dev=Development, Ops=Operations의 합성어라고 짐작을 했지만 의미는 제가 생각한 것과 약간 달랐습니다. 개발과 운영의 통합을 위한 ‘무엇’으로 짐작했지만 흐름 혹은 문화라고 함이 마땅하지 않은가 합니다.
새로운 단어가 나오면 이유가 있습니다. 배경을 알아야 새로운 흐름을 이해할 수 있습니다. 그래서 왜 DevOps라는 개념을 나왔는지 궁금했습니다. DevOps를 이해하기 위한 출발은 두 지점에서 가능합니다. 첫째 2009년부터 시작하여 DevOps를 처음으로 사용하기 시작한 DevOps Days행사입니다. 2009년 행사 자료인 Devopsdays Ghent 2009를 보면 Agile이나 Continuous Integration과 같은 소프트웨어 엔지니어링적인 이야기들이 많습니다. New Relic이 정리한 What is DevOps를 보면 전통적인 폭포수모델에 의한 개발방법론, 운영과 개발을 분리하는 개발문화에 반하는 새로운 운동으로 DevOps를 정의합니다. 이 때 Agile과 같은 방법론적인 변화에 큰 의미를 부여합니다.
Born of the need to improve IT service delivery agility, the DevOps movement emphasizes communication, collaboration and integration between software developers and IT operations. Rather than seeing these two groups as silos who pass things along but don’t really work together, DevOps recognizes the interdependence of software development and IT operations and helps an organization produce software and IT services more rapidly, with frequent iterations.
The Perfect Storm of 2009
A perfect storm of converging adjacent methodology including Agile, Operations Management (Systems Thinking & Dynamics), Theory of Constraints, LEAN and IT Service management came together in 2009 through a smattering of conferences, talks and Twitter (#devops) debates worldwide that eventually became the philosophy behind DevOps.
The Perfect Storm
Agile software development paved the way, steering away from the waterfall method of software development toward a continuous development cycle. But it didn’t include the operations side so while development could be continuous, deployment was still waterfall-oriented.
In a DevOps environment, cross functionality, shared responsibilities and trust are promoted. DevOps essentially extends the continuous development goals of the Agile movement to continuous integration and release. In order to accommodate continuous releases, DevOps encourages automation of the change, configuration and release processes.
3.
이와 달리 어떤 이의 개인적인 경험은 더 깊은 이해를 줍니다. DevOps의 전도사같은 Jessie Robbins가 2012년 devops days에서 한 경험을 살펴보죠.
Amazon at the time, 2002-2003, was doing standard ops. They deployed in large monolithic fashion which is an absolutely painful process prone to error. Managing such a process and also finding yourself emotionally involved with the work to a high degree is not a productive situation to be in.
A turning point for Jesse in terms of moving from an obstacle in the way of change to someone that really knew how to add value with ops practice stemmed from a battle he got into with the “VP of Awesome” at Amazon. This was the nickname of this particular VP because it seemed that pretty much any highly interesting project at Amazon was under this man’s purview. What happened was that Jesse did not want to let out a piece of software because he knew, for sure, that it would bring the site down. The VP overrode him by saying that the site may go down, but the stock price will go up. So, the software went out, and it brought the site down. Two days of firefighting and the site came back up, and so did the stock price, and so did the volume of orders.
The dev team went on and had a party, they were rewarded for job well done, new and profitable functionality released. At the end of the year, Ops got penalized for the outage! Amazon rewarded development for releasing software and providing value and operations was not a part of that. They were in fact penalized for something that was out of their control.
DevOps Culture Hacks중에서
길지만 간단히 정리하면 이렇습니다.
“장애가 발생한 시스템을 개발한 개발자는 휴가를 가면서, 운영자는 개발하지도 않은 – out of control – 서비스의 장애로 책임을 져야 하는가?”
항상 주변에서 접하는 이야기입니다. 개발할 때 충분히 시험을 한다고 하지만 충분한 시험이 이루어질 수 없습니다. 사고를 잉태한 채로 운영에 이관합니다. 개발이 만든 사고가 운영할 때 발생하면 운영의 책임이라고 합니다. 그래서 개발과 운영은 서로 다른 가치를 가집니다.
앞서 Jekkins는 개발과 운영의 갈등이 아니라, 일상적으로 하는 운영에 새로운 가치를 부여하여 개발과 운영이 서로 윈윈(win-win)할 수 있는 방향으로 나아가기 위하여 DevOps를 만들었다고 합니다.
Ops looked at their output as a waste. The best thing they could do was to cost the site $0. Instead we need to be looking at this another way, bringing value through the function of ops. DevOps is about creating a competitive advantage around the things Ops does every day.
Why does the break occur? Historically Ops creates value by reducing change and getting paged when things break. Dev is about value creation and Ops is about protecting that value. This creates a “misalignment of incentives” meaning that different organizations are rewarded for different behaviors. This creates something called local optimization. Knowing these terms will help you talk to MBAs about DevOps!
We have a fundamental misalignment of incentives and in fact a conflict in incentives. Development is exclusively aligned to releasing software and not at all focused on maintaining it. Ops, is the opposite. Each group optimizes locally around this which creates conflict. Operations is focused on minimizing change because that reduces outage where as Dev is entirely focused on maximizing change.
Solving this problem is what DevOps is all about.
The unproductive way of thinking mentioned earlier came about was in an environment with 4000 devs and significantly fewer ops folks. In order to alleviate the problems caused by misaligned incentives and local optimizations were to come up with those punitive changes that are incredibly satisfying to Ops folks but really don’t help solve the problem. Those changes in the form of meetings and review boards that are around to punishing people into releasing the software the way you the Ops person wants. These are the kind of measures that control oriented people gravitate towards, and it feels like progress for them. To be more DevOps don’t try to fight them in this: “Don’t fight stupid, make more awesome”.
이와 같은 문제의식에서 출발한 새로운 변화는 Ops에 중요한 역할을 부여합니다.
One initial thing that changed, that started the real progress, was to align dev and ops in a way that prevented local optimization; putting devs on call for their own software. This started to shift ops from being the people that just dealt with all the problems to people that became experts on all the services that allow the software to run. Ops started to become tier 2, escalation for devs. The way you got there, was to offer devs deployment options and permissions, if they passed some training and were willing to be on call.
3.
두가지 사례를 놓고 섞어보면 Agile이 지향하는 문제의식이 큰 역할을 합니다. 애자일방법론을 티몬에 도입한 CTO의 이야기를 들어보죠.
“기존 프로세스에서는 디자이너들끼리 팀을 만들어서 제품을 기획하고 제작한 뒤에 개발팀이나 기획팀으로 넘기게 됩니다. 하지만 애자일을 도입하게 되면 기획자와 개발자, 디자이너가 한 팀으로 섞이게 됩니다. 이제 세 직군의 사람들이 같이 화면을 보면서 제품을 만들게 되는 것이지요. 개발, 기획, 디자인 직군의 구성비는 각 팀의 상황에 따라 적절하게 맞추고 있습니다.”
“애자일을 도입하게 된 결정적인 이유는 소셜커머스 만의 빠른 시장 변화 때문입니다. 보통의 개발 프로세스에서는 기획 후 4~5개월이 지나서야 결과물이 나옵니다. 그런데 시장 상황이 자꾸 변하기 때문에 특정 서비스가 이러한 프로세스 아래서 나오더라도 쓸모 없는 서비스가 되는 경우도 많습니다. 신 대표도 이러한 소셜커머스의 ‘속도’를 알고 있기 때문에 대가를 치르더라도 빠른 변화에 적응할 수 있는 애자일 도입에 찬성하셨지요.”
“애자일 방법론 도입 실험하는 티몬, 왜?”…신현민 티켓몬스터 CTO를 만나다
애자일이든 DevOps이든 개발프로세스와 문화가 바뀌어야 합니다. 이를 여의도에 적용하여도 큰 차이가 없습니다.
첫째 증권산업의 서비스는 IT를 기반으로 합니다. IT가 곧 증권사의 서비스입니다. 또한 증권산업은 규제산업이라 잣은 제도의 변경을 수반합니다. 서비스의 질이나 규제때문에 IT는 항상 변화를 준비하어야 하고 즉시 변화하여야 합니다.
둘째 빅뱅방식의 프로젝트는 더이상 유효하지 않습니다. 비즈니스적인 변화에 대응하는 것 뿐 아니라 성공률이 높지 않습니다. 위험관리도 어렵고 운영을 하더라도 계속 문제가 발생하여 사실상 운영=개발인 경우가 많습니다. 비용도 문제입니다. 변화가 필요합니다.
셋째 고난의 시기를 지나면서 IT는 개발에서 운영중심으로 변화를 하고 있습니다. 운영이 개발까지를 담당하는 방식이 일상화하였고 이를 통하여 비용을 절감합니다. 앞서 지적한 바와 같이 서로 가치가 다른 개발과 운영을 통합하는 것이 프로세스나 문화가 필요합니다.
현재 맡고 있는 프로젝트를 하면서 DevOps를 더 깊이 고민합니다. 무언가 변화가 필요합니다.
아! 이미 변화를 진행중인 곳도 많으리라 생각합니다. 제가 모를 뿐..
