DevOps를 좋아하십니까? 그렇다면 SRE를 기다렸다가 만나보세요

SRE란 무엇입니까?

Google의 SRE 지휘자인 Ben Treynor는 사이트 안정성에 대해 여전히 한 문장으로 된 정의를 게시하지는 않았지만, "예전에는 운영이라고 불렀던 작업을 소프트웨어 엔지니어가 맡을 때 발생하는 일”이라고 설명합니다.

근본적인 문제는 다음과 같습니다. 개발 팀은 대중에게 멋진 새 기능을 릴리스하고 기능이 크게 성공하는 것을 보고 싶어 합니다. 운영 팀은 이 기능이 무언가를 고장내지 않기를 바랍니다. 운영 팀은 최대한 많은 릴리스에 제동을 걸려고 노력하고, 개발 팀은 이들을 막는 프로세스를 비껴갈 새로운 방법을 찾으면서, 이것으로 인해 둘 간에 권력의 투쟁이 발생해 왔습니다. (익숙한 내용일 것이라고 생각합니다.)

SRE는 언제, 무엇을 제공할 수 있는지에 대한 추측과 논쟁을 없애줍니다. 제공에 초록불 또는 빨간불 중 어떤 것을 줄지에 대한 수학 공식을 도입하고, 운영 기술을 갖춘 관계자로 이루어진 전담 팀(서비스 신뢰성 엔지니어 또는 SRE라고 함)을 마련하여 제품의 신뢰성을 지속적으로 감독하도록 합니다. Google의 SRE인 Andrew Widdowson은 “우리의 일은 세계에서 가장 힘든 피트 크루의 일원이 되는 것과 비슷합니다. 비유하자면, 경주용 자동차가 100mph의 속도로 달리는 동안 타이어를 교체하는 일을 하죠.”

아직 혁명적인 것 같아 보이지는 않습니까? 이 마법의 대부분은 작동 방식에 있습니다. 다음은 몇 가지 핵심 원칙이며, 이것은 기존 IT 운영과의 가장 큰 차이점 중 몇 가지와 같기도 합니다.

첫 번째로, 새로운 제공은 현재의 제품 성과에 따라 초록불을 받습니다.

대부분의 애플리케이션은 100% 가동 시간을 달성하지 못합니다. 따라서 SRE 팀은 각 서비스에 대해 시스템이 최종 사용자에게 얼마나 안정적이어야 하는지 정의하는 서비스 수준 계약(SLA)을 설정합니다. 팀이 99.9% SLA에 동의하면 0.1%의 오류 예산이 주어집니다. 오류 예산은 이름 그대로, 오류 및 서비스 중단에 대해 허용되는 최대 임계값입니다.

전문가 팁: 멋진 가동 시간 치트 시트를 사용하여 SLA를 "단 몇 분의 가동 중지 시간"으로 쉽게 전환할 수 있습니다.

결정적인 사실은 다음과 같습니다. 개발 팀은 이 오류 예산을 원하는 방식으로 “지출”할 수 있습니다. 현재 오류가 거의 또는 전혀 없이 제품이 완벽하게 실행되고 있는 경우, 언제든지 원하는 대로 제공할 수 있습니다. 반대로 오류 예산을 초과했으며 정의된 SLA 이하로 운영되는 경우, 제공을 진행할 수 있는 수준으로 오류의 개수가 줄어들 때까지 모든 제공은 중지됩니다.

천재적인 부분은, SRE와 개발자 모두 오류의 개수를 최소화하기 위해 협력할 강력한 동기를 가지고 있다는 점입니다.

SRE도 코딩을 할 수 있습니다

이전 모델에서는 사용자에게 신뢰성 문제를 해결하도록 밀어넣고 문제가 사라지거나 결국 터질 때까지 계속 압박하고는 했습니다(때로는 1년 이상 걸림).

SRE에서는 그렇지 않습니다. 개발 팀과 SRE 팀 모두 하나의 인력 풀을 공유하므로, SRE가 한 명 고용될 때마다 이용 가능한 개발자 인력이 한 명 줄어들고 그 반대의 경우도 마찬가지가 됩니다. 이로 인해 개발 팀과 운영 팀 간의 끝없는 인원수 전투가 끝나게 되며, 개발자가 더 효율적인 성능의 코드(예: 더 적은 인원의 SRE로부터 지원이 덜 필요한 코드)를 작성하면 더 많은 팀원이라는 보상을 받는 자체 정책 시스템이 탄생합니다.

개발자들도 험한 일에 관여합니다

Google에서 Ben Treynor는 이 조항을 넣기 위해 많은 의견에 맞서야 했고, 보람이 있다고 느낍니다. 실제로 SREcon14에서의 SRE에 대한 키노트에서, 그는 SRE를 시작하기 전에 경영진으로부터 이 약속을 얻는 것이 꼭 필요하다고 강조합니다.

기본적으로 개발 팀은 모든 운영 워크로드(티켓 처리, 대기 중 지원 제공 등)의 5%를 처리합니다. 이렇게 하면 제품과 긴밀하게 연결된 상태를 유지하고, 제품의 성능을 확인하고, 더 나은 코드 및 릴리스 결정을 내릴 수 있습니다.

또한 운영 부하가 SRE 팀의 작업 수용량을 초과할 때마다 오버플로는 항상 개발자에게 할당됩니다. 시스템이 잘 작동하면 개발자는 강력한 코드를 작성하고 향후 문제를 방지하기 위해 신중하게 제공하면서 여기서도 자체적으로 규제하기 시작합니다.

프리 에이전트 SRE(필요한 경우 가져올 수 있음)

팀의 상태 및 만족도를 높은 수준으로 유지하기 위해 Treynor는 SRE가 원하는 대로 다른 프로젝트로 이동하거나 다른 조직으로도 이동할 수 있도록 허용하는 것이 좋다고 말합니다. SRE는 의욕적이고 헌신적이며 효과적인 팀워크를 장려하므로, 어떤 팀원도 자신의 개인적인 목표를 추구하지 못하도록 가로막혀서는 안 됩니다.

SRE 및 개발자로 구성된 팀 전체가 문제를 해결할 수 없고 신뢰할 수 있는 코드보다 문제가 더 많이 발생하는 경우, 마지막으로 과감한 조치를 취할 수 있습니다. 전체 SRE 팀을 프로젝트에서 제외하고 모든 운영 워크로드를 개발 팀에 직접 할당하는 것입니다. Treynor는 일하는 기간 동안 이렇게 한 적은 몇 번 밖에 없으며, 일반적으로 두 팀 모두 더 긍정적인 협력 관계로 이끄는 데는 위협만으로도 충분하다고 말합니다.

프로덕션 인시던트를 방지하는 방법, 대기 중 지원 팀에 직원을 배치하는 방법 및 각 교대 근무 시 따라야 할 규칙 등, SRE에 대한 내용은 하나의 글에서 다루기에는 너무 많습니다.

Atlassian의 견해

IT 업계는 확실히 유행어와 트렌드로 가득합니다. 어떤 순간에는 클라우드가 유행했다가, 그 다음에는 DevOps, 고객 경험 또는 게이미피케이션이 유행합니다. SRE는 단순한 유행어를 뛰어넘는 무언가가 될 수 있는 강력한 위치에 있습니다. 특히 기초가 되는 기술보다는 사용자와 프로세스에 관한 것이기 때문입니다. SRE가 발전하고 더 많은 팀에서 채택하면서 기술은 분명히 이 개념에 적응할 수 있지만(그리고 그렇게 될 가능성이 높음), 사이트 신뢰성 엔지니어링의 원칙을 중심으로 개발 및 운영 조직을 정렬할 새로운 도구가 필요하지는 않습니다.

이후의 글에서는 SRE를 향해 한 걸음을 내딛기 위한 실질적인 단계와 기술이 여기에 어떤 역할을 수행할 수 있는지 살펴보겠습니다.