평범하게 운영 중인 당신의 시스템에 운영자가 손을 대야 한다면 그 시스템에 버그가 있다는 뜻이다. - 칼라 가이저, 구글 SRE
이 장에서는 운영 업무라는 단어의 의미가 사람에 따라 다르게 해석될 수 있으므로 삽질이라고 표현하기로 하겠다.
삽질의 정의
단순히 '하고 싶지 않은 일'을 의미하지만은 않는다. 그렇다고 관리를 위한 허드렛일이나 지저분한 일을 의미하는 것도 아니다.
반드시 수행해야 하며 삽질로 분류해서는 안 되는 업무들도 있다. 이런 업무들이 바로 부하를 일으킨다. 팀 회의나, 둘러앉아 목표를 결정하는 일, 업무 보고, 그리고 구인을 위한 서류 작업 같은 업무들을 포함한다.
지저분한 일은 간혹 장기적으로는 가치가 있을 수도 있다. 그런 경우에는 삽질로 분류해서는 안 된다.
시스템에서 경고와 관련된 전체 설정을 정리한다거나 어지럽게 작성된 코드를 정리하는 것은 지저분한 일이 될 수는 있지만 삽질은 아니다.
그렇다면 삽질이란?
수작업을 동반하고, 반복적이며, 자동화가 가능하고, 사후 대처가 필요하며, 지속적인 가치가 결여되어 있으면서도 서비스의 성장에 따라 지속적으로 늘어나는 업무들을 말한다.
- 수작업을 필요로 한다
- 반복적이다
- 자동화가 가능하다
- 인간의 판단에 의해 실행되어야 한다면 삽질로 분류되지 않을 수도 있다.
- 사후 대처가 필요하다
- 무선으로 날아오는 알림을 처리하는 것은 삽질이다.
- 가치가 지속되지 않는다
- 어떤 작업을 끝냈는데도 서비스가 계속 같은 상태로 남아있다면 삽질로 분류할 수 있다. 서비스가 영구적으로 개선되었다면, 그 작업은 삽질이라고 볼 수 없다.
- 서비스의 성장에 따라 O(n)으로 증가한다
- 이상적으로 디자인되어 관리되는 서비스는 그 크기가 10배로 커지더라도 리소스를 추가하기 위한 단발성 업무 외에 추가로 필요한 작업이 없다.
삽질이 줄어들면 좋은 이유
SRE 조직은 각 전체 작업 시간 중 삽질을 50% 이내로 유지한다는 목표를 공공연하게 가지고 있다. 즉, 각각의 SRE들은 최소 50%의 시간을 엔지니어링 프로젝트 업무에 투입해서 향후에 발생 가능한 삽질을 줄이거나 혹은 서비스에 새로운 기능을 추가해야 한다.
삽질의 가능성이 있는 부분을 제때 점검하지 않으면 나중에 모두가 아무 일도 못하고 삽질에만 매달리게 될 수 있다. 새로운 SRE를 고용할 때, SRE는 일반적인 운영 조직이 아니며, 앞서 설명한 50% 규칙을 보장해줄 것임을 고지한다. 이를 보장하기 위한 방편으로, SRE 조직이나 소속 팀이 운영팀의 업무를 겸하는 것을 허용하지 않는다.
삽질을 줄이고, 나머지 시간을 삽질을 줄이거나 새로운 기능에 투자한다
엔지니어링에 해당하는 업무는?
엔지니어링 업무는 새로우면서도 본질적으로 사람의 판단을 필요로 하는 업무다. 전략에 따라 서비스의 지속적인 개선을 이루어낼 뿐 아니라, 창의적이고 혁신적이며, 디자인 주도 접근법으로 문제를 해결한다.
보통 SRE의 활동은 다음과 같이 분류할 수 있다.
- 소프트웨어 엔지니어링
- 코드를 작성하거나 수정하고, 관련된 디자인이나 문서화 작업을 수행한다. 자동화 스크립트를 작성하는 일, 도구나 프레임워크를 개발하는 일, 확장성과 신뢰성을 위해 서비스 기능을 추가하거나 서비스를 더 안정적으로 운영하기 위해 인프라스트럭처 코드를 수정하는 일 등이 해당된다.
- 시스템 엔지니어링
- 한 번의 노력으로 지속적인 개선을 이루어내기 위해 프로덕션 시스템의 설정을 조정하거나, 문서화를 수행
- 로드밸런서나 서버의 설정 변경, OS 매개변수 튜닝 및 로드밸런서 설치 등의 업무가 이에 해당
- 삽질
- 서비스 운영과 직접 관련된, 반복적으로 발생하는 수작업들
- 부하
- 운영과 직접 관련되지 않은 관리 업무. 채용, HR 서류 작업, 팀/회사 회의, 버그 큐 치우기, 업무 보고, 동료 및 자기 자신에 대한 평가 및 훈련 등의 업무
결론적으로 최소 50%의 시간을 엔지니어링 업무에 할당해야 한다. 현실적으로 어려울 수도 있다. 하지만 프로젝트에 투입한 평균 시간이 50%를 한참 밑돈다면 그 팀은 자신들의 업무에서 한 걸음 물러나 무엇이 문제인지를 찾아야 한다.
삽질은 무조건 나쁜 것일까?
삽질이 항상 사람들을 피곤하게 하는 것은 아니다. 양이 얼마 되지 않는다면 그렇게 문제가 되지는 않을 것이다. 성취감도 있으며, 빠른 시간 내에 처리할 수 있다. 위험하지도 않고 스트레스도 적은 편이다.
삽질이 항상 나쁜 것은 아니다. SRE와 거의 모든 엔지니어링 업무에 있어 어느 정도의 삽질은 피할 수 없다는 것을 분명하게 인식해야 한다. 양이 많지 않다면 나쁘지 않다. 불만이 없다면 삽질은 문제가 되지 않는다.
하지만, 업무량이 엄청나다면 삽질은 독이 되기 시작한다. 삽질에 해당하는 업무가 너무 많이 늘어나면 문제가 되는 이유는 여러 가지가 있지만 대략 다음과 같이 정리해볼 수 있다.
- 경력 개발이 침체된다
- 프로젝트에 너무 적은 시간을 투입하다 보면 개인의 경력 개발이 늦어지거나 서서히 멈추게 된다.
- 의욕이 저하된다
- 삽질을 참고 용인하는 수준은 달라도 누구든 한계를 느끼게 마련이다. 할애하는 시간이 너무 많다면 지치고 지루하고 불만을 갖게 될 것이다.
- 혼란이 가중된다
- SRE는 엔지니어링 조직이라는 점을 분명히 인식시키기 위해 노력한다. SRE가 삽질에 너무 많은 시간을 할애하면 의사소통의 명확성이 저하되며 사람들이 SRE의 역할에 대한 의구심을 품게 된다.
- 성장이 저하된다
- 삽질이 늘어날수록 생산성이 저하되고, SRE가 늘 수작업에 치여 있고, 새로운 기능을 출시하자마자 그 뒷감당을 하느라 너무 바쁘다면 제품의 기능을 개발하는 속도가 떨어질 것이다.
- 좋지 않은 선례를 남기게 된다
- 만일 삽질을 너무 많이 하려고 하면, 함께 일하는 개발팀은 더 많은 삽질을 떠넘기려 할 것이다. 이는 상황을 점점 더 좋지 않는 방향으로 흘러가게 만든다.
- 인력 유출이 발생한다
- 팀에 너무 많은 삽질을 떠안아 온다면, 팀 최고의 엔지니어가 더 보람 있는 일을 찾아 다른 곳으로 떠날 수 있다.
- 신뢰에 문제가 생긴다
- 새로 고용했거나 다른 팀에서 옮겨온 이들이 속았다고 느끼면 그들의 사기에 좋지 않은 영향을 미치게 된다.
결론
만일 모두가 매주 조금씩 삽질을 걷어낼 수 있다면 서비스를 지속적으로 깔끔하게 유지할 수 있고, 서비스 확장을 위한 엔지니어링이나 차세대 서비스의 아키텍팅, 도구 개발 등에 시간을 투입할 수 있다. 삽질은 줄이고 창의적인 일에 더 집중하자.
'개발 > SRE - 사이트 신뢰성 엔지니어링' 카테고리의 다른 글
SRE 18장 - SRE 조직의 소프트웨어 엔지니어링 (0) | 2021.08.13 |
---|---|
SRE 11장 - 비상대기 (0) | 2021.07.30 |
SRE 7장 - 구글의 발전된 자동화 (0) | 2021.07.26 |
SRE 4장 - 서비스 수준 목표 (0) | 2021.07.19 |
SRE 1장 - 소개 (0) | 2021.07.14 |