Hacking Culture

Hacking Culture by Jesse Robins

QCon San Francisco 2012에서 Chef로 유명한 Opscode의 공동창업자인 Jesse Robins가 발표한 내용입니다. Chef나 Opscode에 대한 홍보가 섞여있고, 내용은 어디선가 들어봤을 법한 내용들이었지만, 자신의 이야기를 곁들여서 재미있고 한층 더 마음에 와닿게 설명을 하고 있는 것 같습니다.

Velocity 2009

요즈음 유행하고 있는 DevOps라는 개념이 처음 나온 것은 Velocity 2009에서의 John Allspaw가 발표한 “10 Deploys per Day: Dev and Ops Cooperation at Flicker” (Slides)라는 강연입니다. Jesse Robins의 강연도 이 강연의 일부 내용을 다시 소개하고 있는 것 같군요.

Continuous Delivery

장기간에 걸친 커다란 변경은 위험하기 때문에 작은 양의 코드를 좀 더 자주 배포해야한다는 개념을 Change monster라는 그림을 통해 설명하고 있습니다.

hacking_culture_00

결국 더 빠르게 비즈니스 가치로 이어지고, 버그를 방지할 수 없는 한 버그를 더 빨리 고칠 수 있으며, 개발자들은 자신이 변경한 것을 바로 볼 수 있기 때문에 즐겁게 일할 수 있다는 내용입니다.

DevOps

‘테스트는 통과했으니 이제 운영자의 책임이야’, ‘제가 필요로 하는 권한이 없어’ 같은 전통적인 개발-운영의 문제를 풀기 위해서는 단지 도구가 아니라 서로 신뢰하는 환경이 필요하다고 얘기하고 있습니다.

조직 구조가 제품의 구조를 결정한다는 얘기를 Conway’s law를 빌려 이야기 하고 있습니다.

하나하나 설명하기는 힘들지만, 아래의 그림 한장이 DevOps의 전체 스택을 보여주는 것 같군요.

 

 

hacking_culture_01

Changing Culture

Toyota Production System (이하 TPS)이 한창 유행할 때 모두가 이를 벤치마킹해서 똑같은 시스템을 만들었지만, 가장 핵심적인 요소라고 할 수 있는 누구든지 문제의 해결을 위해서 라인을 정지시킬 수 있는 것은 따라하지 못했다고 얘기하면서 문화의 중요성을 강조합니다.

문화를 바꾸기 위한 다섯가지 조언을 하고 있습니다.

1. Start small, build trust & safety

작은 것은 위협도 되지 않거니와 무시해도 좋다고 생각하기 때문에 거부감을 가지지 않습니다. 사람들에게는 그저 실험이라고 얘기하라고 하고 있습니다.

2. Create champions

자신이 일으키는 변화를 신뢰하고 지원하는 관리자가 있어야 합니다. 그리고, 주변 사람들 모두에게 credit을 주고, 변화와 관련된 사람들에게 특별한 상태 (예를 들어 ‘이달의 직원’)를 주어 그들이 새로운 변화에 대해 더욱 많은 이야기들을 하도록 해야합니다.

3. Use metrics to build confidence

변화를 지지할 수 있는 KPI (예를 들어, MTTR)를 찾아서 그것을 통해 사람들에게 가치를 보여주고, 나중에는 변화하지 않을 경우의 비용을 보여주는 용도로 사용합니다. 사람들에게 변화와 관련한 이야기를 들려줄 때 데이터를 가지고 이야기합니다.

4. Celebrate successes

사람들과 문제를 극복한 사례에 대해 긍정적인 면을 이야기 합니다. 절대로 문제를 만들어낸 사람들에 대해서는 이야기 하지 않습니다.

5. Exploit compelling events

언젠가는 변화를 위한 중요한 기회가 자연스럽게 찾아오게 됩니다. 중요한 것은 이 때 ‘I told you so’가 아니라 ‘What do we do now’라고 이야기할 수 있어야 합니다.

Hacking Permission

어떤 사람들은 스스로의 시간을 털어서 다른 사람들에게 도움이 되는 옳은 일을 하려고 하지만 보통 권한이 없기 때문에 그렇게 하지 못합니다. 그들에게 “site directors”와 같은 권한을 주라고 얘기합니다.

hacking_culture_02

Don’t Fight Stupid, Make More Awesome

이 강연에서도 언급했다시피 변화를 일으키는 것에는 많은 시간과 인내심이 필요한데, 이 문구를 되새기면 언제든지 다시 힘을 낼 수 있을 것 같은 느낌이군요.

hacking_culture_03

The Facebook Release Process

The Facebook Release Process by Chuck Rossi

사용자들이 항상 사용하고 있는 서비스를 하면서 빠르게 변화하는 것은 두마리 토끼를 잡으려는 것과 같이 어려운 일이기 때문에 많은 고민과 노력을 통한 좋은 프랙티스가 필요하다고 생각되지만, 실제로는 그러한 프랙티스는 그다지 널리 알려져 있지는 않는 것 같다.

이 발표는 QCon SF 2012의 발표 중 하나로, Facebook의 Release Engineering을 2008년부터 지금까지 담당해온 Chuck Rossi가 Facebook의 Release Process를 소개하고 있다.

Facebook의 개발자나 코드의 규모는 상당히 큰 편이지만, 릴리즈의 속도는 현재 일하고 있는 서비스의 그것과 거의 유사해서 이 발표를 통해 어떤 면에서는 자신감을 얻을 수 있었고, 반면에 앞으로 개선할 수 있는 많은 영감들을 얻을 수 있었던 것 같다.

이 발표의 주요한 점들을 요약하면 아래와 같다.

Weekly Release & Daily Releases

우선 trunk, lastest, production 3개의 branch로 관리되고 있다. 매주 일요일 오후 6시에 trunk로부터 lastest가 생성되고, 이를 이틀 동안 테스트한 뒤에 production으로 push가 되어 release가 된다. 또한, 매일 300개 가량의 cherrypick을 통해 production으로 릴리즈되고 있다고 한다. 작은 크기의 release를 더욱 자주할 것을 권장하고 있다.

Dogfooding

Facebook의 모든 직원들은 facebook을 사용할 때, www.lastest.facebook.com으로 redirection된다고 한다. 더욱 테스트를 잘하기 위한 이유도 있겠지만, 서비스에 문제를 일으켰을 때, 사용자들이 느낄 고통을 직원들이 느껴보라는 이유도 있다고 한다. 그리고, 이 내부 서비스에 문제가 생기더라도 릴리즈 매니저가 롤백을 하지 않고 고칠 때까지 그대로 둔다고 한다.

Self Service

개발자 개개인이 릴리즈하고자 하는 commit을 추적하기 위해서 릴리즈 매니저에게 메일을 쓴다든가 물어보는 것이 아니고, IRC bot을 통해 자신의 commit이 현재 어떤 상태인지 추적할 수 있다고 한다.

 

Test Automation

Weekly Release는 이틀간의 테스트 기간이 있지만, Daily Release는 그렇지 않은 것 같은데, Daily Release의 테스트는 어떻게 이루어지는가의 의문이 남는데, 자세히 언급하고 있지는 않지만, 일단 자동화된 테스트들이 굉장히 많으며, 이들에 의존하는 것이 아닌가 싶다.

Error Tracking / Perflab

에러의 종류별로 발생 빈도나 API의 응답 속도 등의 트렌드를 그래프로 살펴볼 수 있고, 이를 릴리즈 시기와 비교할 수 있기 때문에, 어떤 릴리즈가 regression을 발생시켰는지를 쉽게 파악할 수 있다. 에러에 직접적으로 관련된 소스 코드를 통해 문제를 일으킨 개발자를 쉽게 찾을 수 있다.

Gatekeeper

어떤 기능을 정해진 조건의 사용자들에게만 릴리즈할 수 있다. 실험적인 기능을 소수의 사용자에게 먼저 릴리즈하고 안정화를 거친 후 전체 사용자에게 릴리즈할 수 있는 bucket test 등의 용도로 사용할 수 있다. Facebook의 다양한 개인 정보들을 가지고 분류할 수 있다.

Push Karma

어떤 commit의 규모 (추가, 변경, 삭제된 라인의 수), 논란이 되는 정도 (review 상의 comment, rejection) 등을 막대 그래프로 시각화 하고 있고, 릴리즈 매니저만 볼 수 있는 개발자에 대한 Like/Dislike 버튼이 있어서 어떤 commit의 위험성을 가늠할 수 있도록 도구를 구성하고 있다.

BitTorrent

수천대에 이르는 서버에 빠른 시간 내에 배포하기 위해서 BitTorrent를 이용하고 있다. 예전에 일했던 팀에서는 비슷한 이유로 Binary Tree 형태로 rsync 구동 플랜을 짜서 배포했던 적이 있었다.

Culture

릴리즈 관리자가 사용할 수 있는 도구는 소프트웨어적인 도구와 문화라고 얘기할만큼 개발 문화의 중요성을 강조하고 있다. 항상 그렇지만, 도구만으로는 성공할 수 없다.

Further Reads