어떤 개발팀의 이야기
고객은 카탈로그를 검색하고 카트에 항목을 추가한 다음 구매를 완료한다. 이 온라인 소매업체의 운영 팀은 주요 측정 기준에 대한 리뷰를 매주 회의한다. 최근 리뷰에서 이 팀은 고객이 결제를 클릭하고 상태가 확인된 것으로 돌아올 때까지의 시간이 서서히 증가하고 있음을 발견했다.
이것이 중요한 문제가 아니라는 것을 인식하고 있지만, 해결될 필요가 있었다. 그 팀은 대기 시간 문제를 해결하기 위해 조용히 시간을 보냈다.
시간이 지남에 따라 비즈니스 측면에서 제품 개발 팀은 기능을 계속 강화했다. 개발자들은 새로운 기능을 제공하는 비즈니스 요청을 따라잡기 위해 시간이 지남에 따라 작업을 시작했을 뿐만 아니라 앞서 확인된 작은 지연 시간 버그를 해결하기 위해 노력했다. 제품 팀들은 여전히 개발 속도에 만족하지 않았다. 기본적으로 IT 팀은 비즈니스를 만족시키기 위해 노력을 기울였다.
이들은 비즈니스와 신뢰성 모두의 요구를 충족시키기 위해 어려움을 겪고 있다. 나중에 IT 팀의 노력이 명백해지자 제품 팀은 대기 시간 버그를 알았다면 새로운 기능을 적용하기 전에 이 문제를 해결하는 것이 우선이였을 것이다. 그러나 비즈니스와 IT가 커뮤니케이션 표준을 공유하지 않았기 때문에 이러한 일은 일어나지 않았다.
구글은 우리가 생각하고 측정하는 방식을 바꾸는 것이 좋은 시작이라고 생각했다. 그리고 인센티브 신뢰성. 이를 사이트 신뢰성 엔지니어링(SRE)이라고 하는 원칙과 관행의 모음이라고 한다. 아마도 여러분은 데브옵스 움직임에 대해 들어본 적이 있을 것이다. SRE와 마찬가지로 팀 간에 원칙, 관행 및 인센티브를 조정하기 위해 노력하는 움직임이다. DevOps와 SRE는 많은 공통점을 가지고 있으며 종종 함께 논의된다. 여러분은 그들이 어떻게 다른지 궁금해 할 수도 있다.
DevOps and SRE
그렇다면 데브옵스란 무엇일까? 무엇인지 이해하기 위해서는 먼저 DevOps가 존재하는 이유를 이해해야 한다. 전통적으로 IT 팀은 개발자와 운영자로 구성된다. 개발자는 시스템용 코드를 작성할 책임이 있고 운영자는 해당 시스템이 안정적으로 작동하도록 보장할 책임이 있으므로 고객이 만족할 수 있다. 개발자들은 빠르게 개발할 것으로 예상되며 종종 새로운 코드를 가능한 한 빨리 작성하고 배포해야 한다.
기본적으로 개발자는 더 빠르게 작업하고, 혁신하며, 빠르게 성공하거나 실패하기를 원한다. 이것은 개발자들이 어떻게 운영되는지에 대한 이해 없이 작성된 코드를 처리해야 하는 운영자들에게 그들의 코드를 벽 너머로 던지는 결과를 낳았다. 시스템을 안정적으로 유지해야 하는 운영자는 신뢰성과 일관성에 초점을 맞춰 더 느리게 작업하는 것을 선호한다. 당연하게도 이러한 작업 방식은 이 두 그룹 사이에서 지속 가능하지 않았다. 그들의 우선순위는 두 팀 사이에 긴장감을 유발했고, 그들이 반드시 비즈니스 요구에 부합하는 것은 아니었다. 벽을 허물고 개발자와 운영자 사이의 격차를 줄이는 방법으로, 데브옵스로 알려진 관행 대신 문화가 탄생했다. 구글이 데브옵스를 어떻게 분류하는지 살펴보자. 다섯 가지 핵심 영역이 있다.
첫 번째는 조직의 사일로를 줄이는 것이다. 팀 간 장벽을 허물어 협업을 강화하고 강화할 수 있다. 둘째, 실패가 정상이라는 것을 받아들여야 한다. 컴퓨터는 본질적으로 신뢰할 수 없기 때문에 완벽한 실행을 기대할 수 없으며, 시스템에 인간을 도입하면 훨씬 더 불안정한 상태가 된다. 실패하는 일들은 필연적으로 그 과정의 일부가 될 것이다. 셋째, 점진적인 변화를 구현하기를 원할 것이다. 작은 변경 사항을 검토하는 것이 더 쉬우며, 점진적인 변경 사항으로 인해 운영 환경에 버그가 발생할 경우 복구 시간을 단축하여 롤백하는 것이 간편하다. 넷째, 툴링과 자동화를 활용해야 한다. IT 팀이 효율적으로 작업하고 중요한 작업에 집중할 수 있도록 하려면 자동화할 수 있는 수동 작업을 식별하는 것이 중요합니다. 마지막으로, 모든 것을 측정해야 한다. 측정은 성공의 중요한 척도이다. 측정할 방법이 없다면 당신이 하고 있는 일이 성공적인지 아닌지 알 수 있는 방법이 없다.
DevOps는 철학 대 개발 방법론 또는 기술이라는 것을 이해하는 것이 중요하다. DevOps 철학은 IT 팀이 운영하는 중요한 방법을 강조하지만, 조직이 성공하기 위해 어떻게 연습을 구현해야 하는지에 대한 명확한 지침을 제공하지는 않는다. 그것이 SRE가 필요한 부분이다.
그렇다면 SRE는 무엇일까? SRE는 2000년대 초에 DevOps와는 별도로 Google에서 발전했다. 지난 2003년, 현재 구글의 엔지니어링 부사장인 Benjamin Trynor Sloss는 구글의 웹사이트를 유지하고 운영하는 것을 책임지는 엔지니어 팀을 관리하는 임무를 맡았다.
여러분은 아마 "잠깐만요, 그럼 이제 코드를 작성하는 소프트웨어 엔지니어들도 운영 시스템을 실행하는 책임을 져야 하는 건가요? 하지만 옵스팀은 그렇게 하지 않나요?" 라고 질문할 수도 있다.
전통적으로 답은 그렇다. 그러나 이 팀에는 소프트웨어 엔지니어만 있었기 때문에 Ben은 개발 작업 외에도 운영 작업에 시간을 할애했다. 그래서 그들은 그들의 코드가 어떻게 운영되고 생산되는지 더 잘 이해할 수 있었다. 이러한 작업 방식이 팀을 사이트 신뢰성 엔지니어링으로 이끌었고 관련 직무 역할은 일반적으로 엔지니어인 SRE가 운영을 담당했다. 데브옵스가 소프트웨어 개발과 소프트웨어 운영 사이의 격차를 좁히는 것을 목표로 하는 것처럼, 이 새로운 SRE 접근법은 데브옵스 철학이 해결하는 문제들을 해결하는 구체적인 방법이다.
SRE는 관행이자 역할이다. SRE 원칙을 따르는 모든 조직이 반드시 SRE라는 직함을 가진 엔지니어를 보유해야 하는 것은 아니다. 이 과정은 주로 실습과 원칙 자체에 초점을 맞추고 있으며, 직함과 팀 구조와 같은 것들이 구현 세부 사항이다. 몇몇 SRE 관행은 구글의 DevOps 분류에 부합하며, SRE 기술 관행을 구현하는 것 외에도 문화적 관행을 구현하고자 할 것이다. 그것들을 유지할 수 있는 문화가 없다면, SRE의 실질적인 측면을 유지하는 것은 불가능하다. 우리가 논의한 DevOps의 핵심 영역에서 이러한 기본 사항이 어디에 적합한지 설명하겠다. 조직의 사일로를 줄이는 것과 관련하여, SRE는 개발자와 생산의 소유권을 공유한다.
이들은 함께 서비스 수준 목표 또는 SLO 및 오류 예산을 정의하고 안정성을 결정하고 작업의 우선순위를 정하는 방법에 대한 책임을 공유한다. 문화적으로 이것은 공동의 비전과 지식뿐만 아니라 협력과 의사소통의 개선에 대한 필요성을 촉진한다. 복잡한 시스템은 흥미롭고 복잡한 방식으로 실패한다. 실패를 정상 상태로 받아들이는 것은 SRE 내에서 중요한 관행이다
Key Points
- DevOps는 개발 팀과 운영 팀 간의 격차를 줄이고 사일로를 허무는 데 도움이 되도록 등장.
- DevOps는 철학이지 개발 방법론이나 기술이 아님.
- SRE는 DevOps 철학을 구현하는 실용적인 방법.
- 개발자는 기능 속도와 혁신에 중점을 둡니다. 운영자는 신뢰성과 일관성에 중점.
- SRE는 기술 및 문화 관행으로 구성.
- SRE 사례는 DevOps 원칙에 맞춰 조정.
