Flickr의 '하루 10회 이상 배포' 발표, 개발자와 운영 사이의 전쟁을 끝내다

2009년 야후 내부의 사진 공유 사이트인 Flickr는 서비스를 끊임없이 업데이트하고 있었고, 업계의 기본 분업 — 개발자는 기능을 배포하고 운영은 사이트를 안정적으로 유지한다 — 은 모든 변경을 싸움으로 만들었다. 변경은 대부분의 장애의 근본 원인이므로, 사이트를 가장 강하게 '보호'하는 팀이 가장 느리게 배포하는 팀이 된다.

변경을 드물게 만드는 대신 안전하게 만들라: 공유 도구 — 기능 플래그, 한 단계 배포, 공유 지표, 채팅 로봇 — 와 비난 없는 문화가 하루 10회 이상의 배포를 일상으로 만든다.

운영 측 매니저 John Allspaw와 엔지니어링 측 매니저 Paul Hammond는 공동 소유를 중심으로 릴리스를 재구축했다: 자동화된 인프라, 하나의 공유 버전 관리 트렁크, 한 단계 빌드 및 배포, 기능 플래그, 공유 지표 대시보드, IRC 채팅 로봇 — 그리고 명시적인 문화 목록: 존중, 신뢰, 실패에 대한 건강한 태도, 비난 회피.

2009년 6월 Velocity 세션은 컨퍼런스의 다른 어떤 발표보다 많은 주목을 받았고, 도구와 문화라는 틀은 DevOps 플레이북의 핵심이 되었다: 몇 달 후 이 운동은 헨트에서 열린 첫 devopsdays에서 스스로 이름을 붙였고, '하루 배포 횟수'는 업계 벤치마크가 되었다.

2009년까지 야후 내부의 사진 사이트인 Flickr는 끊임없이 배포하고 있었다: 평범한 날에도 웹사이트를 프로덕션에 열 번 이상 완전히 배포했다. 그해 6월 산호세에서 열린 O'Reilly의 Velocity 컨퍼런스에서 Flickr의 운영과 엔지니어링 측을 이끌던 두 매니저 John Allspaw와 Paul Hammond는 '하루 10회 이상 배포: Flickr에서의 개발과 운영 협력'이라는 제목의 발표에서 그 방법을 설명했다. 컨퍼런스 현장에서 나온 Data Center Knowledge의 보도는 이 발표를 행사에서 가장 큰 화제를 불러일으킨 프레젠테이션이라고 불렀다.

그들의 주장은 업계의 기본 조직도를 공격했다. 개발자는 기능을 추가하고 운영은 사이트를 안정적이고 빠르게 유지한다는 고정관념은 변경을 적으로 만드는데, 변경이 대부분의 장애를 일으키기 때문이다. Allspaw와 Hammond는 이를 뒤집었다: 운영의 일은 비즈니스를 가능하게 하는 것이고, 비즈니스는 변경을 필요로 하므로, 실제 작업은 도구와 문화를 통해 변경의 위험을 낮추는 것이다. 도구 모음: 자동화된 인프라, 공유 버전 관리 트렁크, 한 단계 빌드 및 배포, 코드를 숨긴 채 배포하는 기능 플래그, 공유 지표, 누구나 릴리스를 지켜볼 수 있게 하는 IRC 로봇.

나머지 절반은 문화였다: 존중, 신뢰, 실패에 대한 건강한 태도, 비난 회피 — 실제 장애가 발생하기 전에 주니어 엔지니어도 프로덕션 장애를 연습해 볼 수 있도록 하는 소방 훈련을 포함해서, 실패는 일어날 것이기 때문이다. 그해 10월 Patrick Debois는 벨기에 헨트에서 첫 devopsdays를 조직했고, 그 행사에서 이름을 얻은 운동은 Flickr 발표의 틀 — 도구를 공유하고 누구도 비난하지 않는 팀이 만드는 작고 안전하며 빈번한 릴리스 — 을 전 세계 엔지니어링 조직으로 퍼뜨렸다.

그것은 진짜 제약을 짚었다: 웹 비즈니스에서 릴리스 열차가 곧 비즈니스이며, 하루에 열 번 안전하게 배포할 수 있는 팀은 한 달에 한 번 배포하는 팀보다 단순히 더 빨리 배운다.

공유 도구는 공유 운명을 만들어냈다 — 하나의 트렁크, 하나의 대시보드, 하나의 배포 버튼 — 그래서 어느 쪽도 상대를 지게 만들어 이길 수 없었다.

그것은 운영을 안정성의 수호자에서 변경의 조력자로 재정의했고, 자동화와 문화를 단 하나의 질문으로 판단하게 했다: 우리는 얼마나 자주 안전하게 배포할 수 있는가?

그것은 비난을 성격 결함이 아니라 엔지니어링 결함으로 취급했다: 사람들이 실수를 숨기면 위험이 조용히 누적된다; 소방 훈련과 비난 없는 리뷰는 정보가 계속 흐르게 한다.

처리량은 변경을 드물게 만드는 것이 아니라 안전하게 만드는 데서 나온다. 공유 도구는 공유 운명을 만든다; 비난은 엔지니어에게 위험을 숨기도록 가르친다; 운영은 비즈니스를 가능하게 하는 것이지, 비즈니스로부터 가동 시간을 지키는 것이 아니다.

세션 녹화본은 여전히 온라인에 있고 여전히 DevOps의 창립 유물로 소개된다. 그해 10월 Debois의 헨트 첫 devopsdays가 이 운동에 이름을 주었고, '하루에 몇 번 배포하는가?'는 벤치마크이자 도전이 되었다. Allspaw는 이 접근법을 Etsy로 가져갔고, 그곳에서 그 사촌 격인 — 비난 없는 사후 분석과 지속적 배포 — 이 그 자체로 유명해졌다. 15년이 지난 지금, 배포 빈도는 표준 엔지니어링 지표이며, '개발 대 운영'은 대부분 이 발표가 무너뜨린 허수아비로만 남아 있다.