<사이트 신뢰성 엔지니어링> - 1부 요약

본문 중에서...

서비스 관리를 위해 시스템 관리자를 활용하는 방법

시스템 관리자를 두면 몇 가지 장점을 얻을 수 있다. 서비스를 운영하고 지탱하는 방법을 직접 결정하는 회사라면 시스템 관리자를 통해 쉽게 서비스를 운영할 수 있다. 시스템 관리자 역할을 소화할 수 있는 전문 인력도 풍부하다.

그런데 시스템 관리팀과 개발팀을 별개로 나누어 운영하면 단점도 존재한다.

변경이력관리와 이벤트 처리를 모두 수작업에 의존하는 팀을 통해 서비스를 운영하게 되면 서비스와 트래픽이 증가하면 업무량 역시 늘어나서 팀의 규모가 커져서 결국 큰 비용이 들게 된다.

그리고 이러한 직접비용보다 간접비용이 더 큰 비용을 발생시키기도 한다. 두 팀의 배경 지식, 스킬, 동기 유발 조건 등이 각각 다르기 때문이다. 그래서 서로 다른 용어를 사용하기도 하고, 위험 요소와 해법을 다르게 예측하고, 제품의 안전성에 대한 목표 수준 역시 다르게 예상한다.

두 그룹을 나누면 동기는 물론 의사소통, 목적, 상호간의 신뢰와 존중에 대한 차이가 발생하게 된다. 그 결과는 병리학만큼 어렵고 복잡하다.

운영팀과 제품 개발팀은 충돌이 종종 발생한다. 대부분 소프트웨어를 얼마나 빨리 프로덕션에 릴리즈할 것인가로 인해 충돌이 발생한다. 기본적으로 개발팀은 사용자들의 반응을 빨리 보고싶어하는 반면, 운영팀은 서비스를  안정적으로 운영하기를 선호한다. 대부분의 문제는 어떤 변화에 의해 발생하느로 두 팀의 목표는 본질적으로 팽팽한 긴장 관계에 있다.

각자 사용하는 용어와 위험 예측 수준이 서로 달라서 종종 자신들의 이해를 기반으로 자신들에게 유리한 고지를 점령하려고 한다. 예를 들어 배포에 대해서, "제품 출시"라는 단어 사용을 자제하고, "플래그 변경", "정기 업데이트" 등의 단어를 더 많이 사용한다. 

서비스 관리에 대한 구글의 해법: 사이트 신뢰성 엔지니어링

SRE팀은 기본적으로 운영팀이 수행하던 업무를 수행한다. 다만 소프트웨어 전문성을 지닌 엔지니어들과 이들이 선천적으로 가지고 있는 인간의 노동력을 대체할 자동화된 소프트웨어를  설계하고 구현하려는 성향과 능력을 활용한다는 차이점이 있다.

SRE 채용에 대한 구글의 접근법은 크게 2가지가 있다. 첫번째 부류는 어떤 작업을 직접 손으로 수행하는 것을 금세 싫증 내는 부류며, 두 번째 부류는 그 해결책이 복잡한 경우라 하더라도 이전까지 사람이 손으로 하던 작업을 대신할 수 있는 소프트웨어를 작성하는 데 필요한 기술을 갖춘 부류다.

기본적으로 SRE팀은 엔지니어링에 초점을 맏춘다. 끊임없이 엔지니어링을 추구하지 않으면 업무 부담이 증가하여 그 부담을 나누기 위해 더 많은 인력이 필요하게 되고 결국에는 서비스의 크기에 따라 전통적인 운영 업무를 감당하는 인력이 기하급수적으로 늘어나게 된다. 서비스가 지원되는 제품이 성공하게 되면 운영 업무에 대한 부간른 트래픽과 함께 증가하게 되고, 그러면 같은 양의 업무를 처리하기 위해 더 많은 사람을 계속해서 채용할 수 밖에 없다.

이러한 숙명에서 벗어나려면 서비스를 관리하는 팀은 코드를 작성해야 한다. 그렇지 않으면 늘어나는 일감에 파묻히게 될 뿐이다. 그래서 구글은 SRE 팀에 수작업 등의 운영 업무에 최대 50%의 시간만 투입하도록 정해두고 있다. 이는 SRE팀이 서비스를 안정적으로 운영 가능한 상태로 유지하기 위한 충분한 시간을 벌어주기 위함이다.

SRE들은 모두 구글의 시스템을 운영하기 위해 자신들의 필요에 따라 직접 코드를 수정하므로 SRE는 빠르게 혁신하고 변화를 폭넓게 수용하는 특징을 보인다.

결과적으로 SRE를 도입함으로써 개발과 운영의 분리로 인한 부작용을 피할 수 있을 뿐만 아니라 개발팀 성장에 도움이 되었다.

제품 개발팀과 SRE 간의 손쉬운 업무 전환을 허용해 전체 구성원이 두 분야를 모두 학습할 수 있게 되었고, 이는 개발자들의 성장으로 이어졌다.