SRE의 신조
워크플로, 우선 순위 및 일상적인 작업의 뉘앙스가 SRE 팀마다 다르지만 모두 지원하는 서비스에 대한 기본 책임 세트를 공유하고 동일한 핵심 원칙을 준수합니다. 일반적으로 SRE 팀은 서비스의 가용성, 대기 시간, 성능, 효율성, 변경 관리, 모니터링, 비상 대응 및 용량 계획 을 담당합니다. 우리는 SRE 팀이 프로덕션 환경뿐만 아니라 제품 개발 팀, 테스트 팀, 사용자 등 환경과 상호 작용하는 방식에 대한 참여 규칙과 원칙을 체계화했습니다. 이러한 규칙과 작업 방식은 운영 작업이 아닌 엔지니어링 작업에 집중하는 데 도움이 됩니다.
서비스의 SLO를 위반하지 않고 최대 변경 속도 추구
제품 개발 및 SRE 팀은 각자의 목표에서 구조적 갈등을 제거함으로써 생산적인 업무 관계를 즐길 수 있습니다. 구조적 갈등은 혁신의 속도와 제품 안정성 사이에 있으며, 앞서 설명한 바와 같이 이 갈등은 간접적으로 표현되는 경우가 많다. SRE에서는 이 충돌을 전면에 표시한 다음 오류 예산 을 도입하여 해결합니다 .
오류 예산은 100%가 기본적으로 모든 것에 대한 잘못된 신뢰성 목표 라는 관찰에서 비롯됩니다 (심박 조율기 및 잠금 방지 브레이크는 예외임). 일반적으로 모든 소프트웨어 서비스 또는 시스템에 대해 100%는 올바른 안정성 목표가 아닙니다. 사용자는 시스템이 100% 사용 가능한 것과 99.999% 사용 가능한 것의 차이를 구분할 수 없기 때문입니다. 사용자와 서비스 사이의 경로에는 다른 많은 시스템(노트북, 가정용 WiFi, ISP, 전력망… 따라서 99.999%와 100% 사이의 한계 차이는 다른 비가용성의 소음으로 인해 사라지고 사용자는 가용성의 마지막 0.001%를 추가하는 데 필요한 엄청난 노력의 이점을 얻지 못합니다.
100%가 시스템에 대한 잘못된 신뢰성 목표라면 시스템에 대한 올바른 신뢰성 목표는 무엇입니까? 이것은 실제로 기술적인 질문이 아닙니다. 다음 사항을 고려해야 하는 제품 질문입니다.
사용자가 제품을 사용하는 방식을 고려할 때 사용자가 만족할 가용성 수준은 무엇입니까?
제품의 가용성에 만족하지 못하는 사용자가 사용할 수 있는 대안은 무엇입니까?
다양한 가용성 수준에서 사용자가 제품을 사용하면 어떻게 됩니까?
비즈니스 또는 제품은 시스템의 가용성 목표를 설정해야 합니다. 해당 목표가 설정되면 오류 예산은 1에서 가용성 목표를 뺀 값입니다. 99.99% 사용 가능한 서비스는 0.01% 사용 불가능합니다. 0.01%의 비가용성을 허용하는 것은 서비스의 오류 예산 입니다. 예산을 과도하게 지출하지 않는 한 원하는 모든 것에 예산을 사용할 수 있습니다.
그렇다면 오류 예산을 어떻게 사용하고 싶습니까? 개발 팀은 기능을 출시하고 새로운 사용자를 유치하기를 원합니다. 이상적으로는 신속하게 출시하기 위해 출시하는 모든 오류 예산을 위험을 감수하는 데 사용합니다. 이 기본 전제는 오류 예산의 전체 모델을 설명합니다. 이 프레임워크에서 SRE 활동이 개념화되자마자 단계적 출시 및 1% 실험과 같은 전술을 통해 오류 예산을 확보하면 더 빠른 출시를 위해 최적화할 수 있습니다.
오류 예산의 사용은 개발과 SRE 간의 인센티브의 구조적 충돌을 해결합니다. SRE의 목표는 더 이상 "중단 없음"이 아닙니다. 오히려 SRE와 제품 개발자는 최대 기능 속도를 얻기 위해 오류 예산을 사용하는 것을 목표로 합니다. 이 변화가 모든 차이를 만듭니다. 중단은 더 이상 "나쁜" 것이 아닙니다. 이는 혁신 프로세스의 예상되는 일부이며 개발 및 SRE 팀 모두가 두려워하기보다는 관리하는 발생입니다.
모니터링
모니터링은 서비스 소유자가 시스템의 상태와 가용성을 추적하는 주요 수단 중 하나입니다. 따라서 모니터링 전략은 신중하게 구성되어야 합니다. 모니터링에 대한 일반적이고 일반적인 접근 방식은 특정 값이나 조건을 감시한 다음 해당 값을 초과하거나 해당 조건이 발생할 때 이메일 경고를 트리거하는 것입니다. 그러나 이러한 유형의 이메일 경고는 효과적인 솔루션이 아닙니다. 사람이 이메일을 읽고 응답으로 어떤 유형의 조치를 취해야 하는지 여부를 결정해야 하는 시스템은 근본적으로 결함이 있습니다. 모니터링은 경고 도메인의 어떤 부분도 사람이 해석하도록 요구해서는 안 됩니다. 대신 소프트웨어가 해석을 수행해야 하며 인간은 조치를 취해야 할 때만 알림을 받아야 합니다.
유효한 모니터링 출력에는 세 가지 종류가 있습니다.
경고
상황을 개선하기 위해 인간이 일어나고 있거나 곧 일어날 일에 대한 응답으로 즉시 조치를 취할 필요가 있음을 나타냅니다.
티켓
사람이 조치를 취해야 하지만 즉시 조치를 취해야 하는 것은 아님을 나타냅니다. 시스템이 상황을 자동으로 처리할 수는 없지만 사람이 며칠 안에 조치를 취하면 피해가 발생하지 않습니다.
벌채 반출
아무도 이 정보를 볼 필요가 없지만 진단 또는 포렌식 목적으로 기록됩니다. 다른 사람이 요청하지 않는 한 아무도 로그를 읽지 않을 것으로 예상됩니다.
비상 대응
신뢰성은 평균 고장 시간(MTTF)과 평균 수리 시간(MTTR)의 함수입니다 [Sch15] . 비상 대응의 효율성을 평가할 때 가장 관련성이 높은 지표는 대응 팀이 얼마나 빨리 시스템을 정상 상태로 되돌릴 수 있는지, 즉 MTTR입니다.
인간은 대기 시간을 추가합니다. 주어진 시스템이 더 실제 를 경험하더라도장애가 발생하면 사람의 개입이 필요한 비상 사태를 피할 수 있는 시스템이 실제 개입이 필요한 시스템보다 가용성이 더 높습니다. 인간이 필요할 때 미리 생각하고 모범 사례를 "플레이북"에 기록하면 "날리기" 전략에 비해 MTTR이 약 3배 향상된다는 사실을 발견했습니다. 만능의 대기 엔지니어가 효과가 있지만 플레이북으로 무장한 숙련된 대기 엔지니어가 훨씬 더 잘 작동합니다. 플레이북은 아무리 포괄적이더라도 즉석에서 생각할 수 있는 똑똑한 엔지니어를 대신할 수는 없지만 중요하거나 시간에 민감한 페이지에 응답할 때는 명확하고 철저한 문제 해결 단계와 팁이 중요합니다. 따라서 Google SRE는 "7 엔지니어가 대기 중인 이벤트에 대응할 수 있도록 준비합니다.
변경 관리
SRE는 가동 중단의 약 70%가 라이브 시스템의 변경으로 인한 것임을 발견했습니다. 이 도메인의 모범 사례는 자동화를 사용하여 다음을 수행합니다.
점진적 출시 구현
문제를 빠르고 정확하게 감지
문제 발생 시 변경 사항을 안전하게 롤백
이 세 가지 방법은 잘못된 변경에 노출된 사용자 및 작업의 총 수를 효과적으로 최소화합니다. 루프에서 인간을 제거함으로써 이러한 관행은 피로, 친숙함/경멸, 고도로 반복적인 작업에 대한 부주의와 같은 일반적인 문제를 피합니다. 결과적으로 릴리스 속도와 안전성이 모두 증가합니다.
수요 예측 및 용량 계획
수요 예측 및 용량 계획은 필요한 가용성으로 예상되는 미래 수요를 제공하기에 충분한 용량과 중복성이 있는지 확인하는 것으로 볼 수 있습니다. 놀라운 수의 서비스와 팀이 필요한 시간까지 필요한 용량을 확보하는 데 필요한 조치를 취하지 않는다는 점을 제외하고 이러한 개념에 대해 특별히 특별한 것은 없습니다. 용량 계획은 유기적 성장(고객의 천연 제품 채택 및 사용에서 비롯됨)과 무기적 성장(기능 출시, 마케팅 캠페인 또는 기타 비즈니스 주도 변경과 같은 이벤트로 인한 결과)을 모두 고려해야 합니다.
용량 계획에는 몇 가지 단계가 필수입니다.
용량 확보에 필요한 리드 타임 이상으로 정확한 유기적 수요 예측
수요 예측 에 무기 수요 소스의 정확한 통합
원시 용량(서버, 디스크 등)을 서비스 용량과 연관시키기 위한 시스템의 정기적인 부하 테스트
용량은 가용성에 매우 중요하기 때문에 SRE 팀이 용량 계획을 담당해야 하는 것은 당연합니다. 즉, 프로비저닝도 담당해야 합니다.
프로비저닝
프로비저닝은 변경 관리와 용량 계획을 결합합니다. 경험상 프로비저닝은 용량이 비싸기 때문에 필요한 경우에만 신속하게 수행해야 합니다. 이 운동도 올바르게 수행해야 합니다. 그렇지 않으면 필요할 때 용량이 작동하지 않습니다. 새 용량을 추가하려면 종종 새 인스턴스 또는 위치를 가동하고 기존 시스템(구성 파일, 로드 밸런서, 네트워킹)을 크게 수정하고 새 용량이 올바른 결과를 수행하고 제공하는지 검증해야 합니다. 따라서 시간당 여러 번 수행되는 부하 이동보다 더 위험한 작업이며 그에 상응하는 각별한 주의를 기울여 처리해야 합니다.
효율성 및 성능
서비스가 돈에 관심을 가질 때마다 리소스의 효율적인 사용이 중요합니다. SRE는 궁극적으로 프로비저닝을 제어하므로 활용도는 주어진 서비스가 작동하는 방식과 프로비저닝되는 방식에 따라 달라지므로 활용에 대한 모든 작업에도 관여해야 합니다. 따라서 서비스에 대한 프로비저닝 전략과 그에 따른 활용에 세심한 주의를 기울이면 서비스의 총 비용에 매우 큰 영향을 미칩니다.
리소스 사용은 수요(부하), 용량 및 소프트웨어 효율성의 함수입니다. SRE는 수요를 예측하고 용량을 프로비저닝하며 소프트웨어를 수정할 수 있습니다. 이 세 가지 요소는 서비스 효율성의 큰 부분(전체는 아님)입니다.
소프트웨어 시스템은 부하가 추가됨에 따라 느려집니다. 서비스 속도가 느려지면 용량 손실이 발생합니다. 어느 시점에서 속도 저하 시스템이 서비스를 중지하며, 이는 무한 속도에 해당합니다. SRE 는 특정 응답 속도로 용량 목표를 충족하도록 프로비저닝 하므로 서비스의 성능에 많은 관심이 있습니다. SRE와 제품 개발자는 서비스를 모니터링하고 수정하여 성능을 개선하여 용량을 추가하고 효율성을 개선해야 합니다.
