9.1 사이트 신뢰성 엔지니어링

개요와 동기

사이트 신뢰성 엔지니어링(SRE)은 소프트웨어 엔지니어링 실천을 프로덕션 시스템 운영에 적용합니다. 운영을 개발과 분리된 수동의 티켓 기반 작업으로 다루는 대신, SRE는 신뢰성을 코드, 측정, 분명한 서비스 목표로 푸는 엔지니어링 문제로 다룹니다. Google이 대중화했지만 이제 널리 퍼진 핵심 생각은 단순합니다. 시스템을 돌아가게 유지하는 사람들은 같은 실패를 손으로 거듭 불 끄는 데가 아니라 자동화를 만들고 시스템을 개선하는 데 대부분의 시간을 써야 한다는 것입니다.

큰 팀에게 이것이 중요한 이유는 규모가 신뢰성의 가치와 그것을 잘못했을 때의 비용을 모두 올리기 때문입니다. 하나의 서비스가 수백만 사용자나 수천 개의 내부 소비자를 지원할 때, 한 시간의 다운타임은 잃은 매출, 놓친 거래, 침식된 신뢰를 뜻합니다. 소수의 서버에는 잘 통하는 수동 운영은 수백 개의 서비스와 지속적 배포 아래서 무너집니다. SRE는 신뢰성에 대한 공유 언어, 기능을 출하하는 것과 안정을 유지하는 것 사이의 트레이드오프를 명시적으로 만드는 방법, 많은 팀에 걸쳐 그 선을 일관되게 지키는 방법을 줍니다.

기업과 정부 맥락은 무게를 더합니다. 은행, 의료, 공공 서비스 같은 규제 산업은 흔히 법적 또는 계약상 가용성 약속, 감사 요건, 시민이나 안전에 영향을 주는 장애에 대한 낮은 허용도를 집니다. 정부 디지털 서비스는 점점 신뢰성 목표와 성능 데이터를 공개적으로 게시합니다. SRE는 “충분히 믿을 만하다”가 무엇을 뜻하는지 정의하고, 정직하게 측정하고, 리더십과 감독 기관에 의견이 아니라 데이터로 엔지니어링 우선순위를 방어하는 엄밀하고 증거 기반인 방법을 줍니다.

함께 보기: 9.2장(관측 가능성과 모니터링), 9.3장(사고 관리), 3.5장(확장성, 성능, 복원력).

핵심 원칙

신뢰성은 가장 중요한 기능입니다. 동작하지 않는 시스템은 기능이 아무리 많아도 가치가 없지만, 완벽한 신뢰성은 달성할 수도 없고 그 비용만큼 값하지도 않습니다.
측정 가능한 목표로 신뢰성을 정의하십시오. 서비스 수준 지표(SLI), 목표(SLO), 협약(SLA)이 모호한 기대를 모두가 합의할 수 있는 숫자로 바꿉니다.
100퍼센트는 잘못된 목표입니다. 사용자는 매우 믿을 만한 시스템과 완벽하게 믿을 만한 시스템의 차이를 알 수 없으므로, “충분히 믿을 만함”을 목표로 하고 나머지 예산을 속도에 쓰십시오.
오류 예산이 유인을 정렬합니다. SLO와 100퍼센트 사이의 간극은 개발자와 운영자가 공유하는 위험의 예산으로, 논쟁을 산수로 대체합니다.
고역이 적입니다. 반복적이고, 수동적이고, 자동화 가능한 운영 작업은 측정되고, 한도가 정해지고, 체계적으로 제거되어야 합니다.
자동화를 의도적으로 하십시오. 자동화는 작은 팀이 큰 시스템을 운영하는 방법입니다. 거기에 투자하는 것은 일급 엔지니어링 활동입니다.
비난 없는 학습. 실패는 개인을 벌하는 기회가 아니라 시스템과 프로세스를 개선하는 기회로 다뤄집니다.

권장 사항

SLI, SLO, SLA를 의도적으로 정의한다

사용자의 관점에서 시작하십시오. 서비스 수준 지표는 300밀리초 안에 처리된 요청의 비율이나 성공 응답의 비율처럼 서비스 행동의 정량적 척도입니다. 사용자의 만족을 진정으로 반영하는 소수의 SLI를 고르십시오. 가용성, 지연, 정확성, 최신성이 흔한 것입니다. 서비스 수준 목표는 SLI의 목표 값이나 범위로, 예컨대 “28일 이동 기간에 걸쳐 요청의 99.9퍼센트가 성공”입니다. 서비스 수준 협약은 약속된 수준에 결과(환불, 위약금)가 붙은 계약입니다. 약속을 위반하기 전에 경고를 얻도록 SLO를 SLA보다 엄격하게 유지하십시오. SLO를 공표하고, 분기마다 검토하고, 배우면서 조여지거나 느슨해지는 살아 있는 문서로 다루십시오.

오류 예산을 채택하고 시행한다

오류 예산은 100퍼센트 빼기 SLO입니다. SLO가 99.9퍼센트라면 예산은 기간당 0.1퍼센트의 비신뢰성, 대략 한 달에 43분입니다. 계획된 위험에 쓰십시오. 공격적 릴리스, 실험, 통제된 실패 테스트입니다. 예산이 건강하면 팀이 빠르게 출하할 수 있습니다. 소진되면 정책이 자동으로 우선순위를 신뢰성 작업 쪽으로 옮기고 시스템이 회복될 때까지 위험한 변경을 멈춰야 합니다. 오류 예산의 힘은 앞서 합의하므로 장애의 순간에서 감정과 정치를 걷어낸다는 것입니다.

고역을 측정하고 줄인다

고역은 수동적이고, 반복적이고, 자동화 가능하고, 전술적이고, 시스템과 함께 커지는 운영 작업입니다. SRE 시간 중 고역에 쓰이는 비율을 추적하고 한도를 정해, 흔히 50퍼센트 정도로, 엔지니어링 시간의 적어도 절반이 지속적 개선에 가게 하십시오. 고역 감소 프로젝트의 백로그를 유지하고, 빈도 곱하기 비용으로 우선순위를 정하고, 반복되는 작업을 없애는 것을 새 기능을 출하하는 것만큼 축하하십시오. 자동화 의무가 이를 명시적으로 만듭니다. 정해진 횟수 넘게 수행하는 수동 절차는 자동화나 셀프서비스 도구의 후보가 됩니다.

용량을 계획하고 수요를 예측한다

과거 추세, 계획된 출시, 비즈니스 전망으로 예상 부하를 모델링하십시오. 유기적 성장 예측을 마케팅 캠페인, 세금 마감, 정부에서 크게 중요한 급여 등록 기간 같은 일회성 사건과 결합하십시오. 피크 위에 여유를 유지하고, 가정을 확인하도록 부하 테스트를 하고, 가능한 곳에서는 확장을 자동화하되 큰 약속에는 사람이 리뷰하는 용량 계획을 유지하십시오. 부족이 허를 찌르지 못하도록 프로비저닝 리드 타임을 추적하십시오.

신뢰성을 실제 비용이 있는 기능으로 다룬다

가용성의 “9”를 하나 더할 때마다 보통 중복, 테스트, 운영 정교함에서 앞의 것보다 훨씬 많은 비용이 듭니다. 제품 소유자가 눈을 뜨고 목표를 고르도록 9의 비용을 명시적으로 만드십시오. 부분 실패가 전체 장애 대신 줄어든 서비스를 주도록 우아한 성능 저하를 설계하십시오. 중복과 장애 조치에 모든 구성 요소에 고르게가 아니라 SLO에 비례해 투자하십시오.

SRE 조직 모델을 고른다

단일한 올바른 구조는 없습니다. 중앙화된 SRE 팀은 일관성, 깊은 전문성, 공유 도구를 주지만 병목이 되거나 남들의 문제를 쏟아 넣는 곳이 될 수 있습니다. 내장 모델은 SRE를 제품 팀 안에 두어 긴밀한 협업을 하지만 비일관성과 고립의 위험이 있습니다. 많은 큰 조직이 하이브리드를 씁니다. 중앙 플랫폼 및 표준 팀에 내장 신뢰성 엔지니어를 더하고, 서비스가 언제 SRE 지원 자격을 얻는지와 먼저 넘어야 할 프로덕션 준비 기준이 무엇인지 정의하는 분명한 참여 모델을 둡니다.

장단점

결정	장점	단점
엄격한 SLO (더 많은 9)	더 높은 사용자 신뢰. 계약 충족	비용 상승. 더 느린 기능 전달
느슨한 SLO (더 적은 9)	더 빠른 출하. 더 낮은 비용	사용자 이탈과 SLA 위약금의 위험
중앙화된 SRE	일관성. 공유 전문성	병목. 제품과의 거리
내장 SRE	긴밀한 협업. 맥락	비일관성. 인력 확보가 어려움
무거운 자동화 투자	확장됨. 고역 감소	선행 비용. 자동화 자체가 실패할 수 있음

신뢰성 엔지니어링은 실제로 유한한 자원을 현명하게 쓰는 것입니다. 사용자가 인지조차 못하는 9를 하나 더 쫓는 것은 기능에 자금을 대거나 가격을 낮출 수 있는 돈을 낭비합니다. 반대로 가서 실패가 실제 해를 입히는 시스템에 과소 투자하면 태만입니다. 오류 예산 틀은 정확히 이 트레이드오프를 암묵적이고 논쟁적인 것이 아니라 보이고 협상 가능한 것으로 만들기 위해 존재합니다. 조직 모델 트레이드오프도 똑같이 실제입니다. 올바른 답은 회사 규모, 엔지니어링 성숙도, 서비스가 얼마나 균일한지에 달려 있습니다.

팀과 논의할 질문

어떤 정확한 SLI가 사용자가 실제로 느끼는 것을 반영하며, 그것이 허영 지표가 아님을 보일 수 있습니까? 잘못된 지표를 고르면 사용자가 고통받는 동안 모든 대시보드가 초록으로 보이며, 이것이 이 장이 경고하는 허영 SLI의 덫입니다. 논의에 실제 데이터를 가져오십시오. 서버 CPU나 백엔드 상태 검사가 아니라 실제 요청 경로(로그인에서 대시보드, 결제에서 확인)에서 같은 사용자 여정을 측정하십시오. 큰 팀에서 나쁜 SLI 하나는 전파됩니다. 수십 개 서비스가 그것을 물려받고, 알림이 잘못된 것에 발동하고, 오류 예산이 아무 의미도 없게 됩니다. SLA가 환불이나 시민 영향을 지니는 기업과 정부 환경에서 SLI는 감사자에게 방어하는 증거이므로, 사용자에게 보이는 성공까지 직접 추적되어야 합니다. 숫자에서 사용자의 경험까지 선을 그을 수 없다면, 숫자를 교체하십시오.
SRE 팀이 온콜을 맡기 전에 서비스는 무엇을 증명해야 하며, 누가 거절합니까? 프로덕션 준비 기준이 없으면 중앙 SRE 팀은 모든 불안정한 서비스의 쏟아 넣는 곳이 되어 남들의 기술 부채에 가라앉습니다. 진입 기준을 적어 두십시오. 소유된 SLO, 동작하는 런북, 행동 가능한 알림, 용량 여유, 입증된 배포와 롤백 경로입니다. 큰 조직에서 이 참여 모델이 신뢰성 팀이 모두를 늦추는 병목이 되지 않게 지킵니다. 규제 환경에서 준비도 리뷰는 감독 기관에 보일 수 있는 통제 역할도 합니다. 누가 온보딩을 거절할 권한을 쥐는지 정하십시오. 아무도 시행하지 않는 기준은 기준이 아니며, 답이 SRE가 확장되는지 물려받은 고통 아래 무너지는지를 바꿉니다.
가장 큰 예측 가능한 피크에 얼마나 앞서 사전 프로비저닝하며, 프로비저닝 리드 타임을 압니까? 클라우드 탄력성이 즉각적이고 무한하다고 가정하면 가장 중요한 바로 그 피크 동안 부족이 생기며, 그 피크(세금 마감, 등록 기간, 세일 이벤트)는 실패가 가장 눈에 띄고 가장 비싼 순간입니다. 숫자를 가져오십시오. 과거 피크 부하, 예측된 성장, 부하 테스트하는 배수, 큰 예약 용량이나 특수 인스턴스를 확보하는 실제 리드 타임입니다. 정부의 계절성 서비스에서 피크는 정상 부하의 몇 배가 될 수 있고 정치적으로 놓칠 수 없으므로, 자동 확장이 따라오기를 바라는 것보다 몇 주 앞서 사전 프로비저닝하는 것이 낫습니다. 답은 구체적인 달력을 정해야 합니다. 언제 부하 테스트를 하고, 언제 용량을 잠그고, 누가 진행 결정을 소유하는지입니다.
오류 예산이 소진되면 실제로 무슨 일이 일어나며, 누가 시행할 자격이 있습니까? 소진되어도 행동되지 않는 오류 예산은 장식일 뿐이며, 장애의 순간은 정책을 처음부터 협상하기에 최악의 시간입니다. 경쟁하는 끌림은 실제입니다. 약속된 출시, 매출 마감, 공개 발표가 위험한 변경의 동결에 강하게 압박할 것입니다. 소진율 데이터, 사전 합의된 정책 문안, 예산이 위반된 최근 몇 번의 기록을 가져와 동결이 실제로 유지되었는지 보십시오. 큰 팀에서 예산은 모든 그룹이 같은 시행을 물려받을 때만 유인을 정렬하므로, 누가 무시를 승인하고 그 예외가 어떻게 기록되는지 미리 정하십시오. SLA가 위약금이나 시민 영향을 지니는 기업과 정부 환경에서 무시의 추적은 감사 산출물이 되므로, 예산이 이미 사라진 뒤 즉흥적으로 하는 대신 지금 책임 있는 소유자의 이름을 정하십시오.
SRE 팀의 한 주 중 고역은 얼마이며, 그것은 측정된 숫자입니까 느낌입니까? 아무도 세지 않는 고역은 팀이 모든 시간을 불 끄는 데 쓰고 지속적 개선은 전혀 만들지 못할 때까지 조용히 커지며, 이것이 SRE가 벗어나려고 존재하는 바로 그 덫입니다. 긴장은 고역을 측정하는 것 자체가 일이고 마감 압박 아래의 엔지니어는 시간이 어디로 가는지 기록하는 것에 저항한다는 것입니다. 정직한 표본을 가져오십시오. 고역의 공유된 정의(수동적, 반복적, 자동화 가능, 전술적, 시스템과 함께 확장)에 대해 추적한 한두 주의 시간과, 빈도 곱하기 비용으로 순위를 매긴 자동화 프로젝트의 백로그입니다. 큰 조직에서 50퍼센트 한도는 팀별로 보고되고 방어될 때만 의미가 있으므로, 누가 숫자를 리뷰하는지와 팀이 위반하면 무슨 일이 일어나는지 합의하십시오. 규제 및 정부 맥락에서 고역을 제한하면 수동 운영이 밀어내는 통제와 감사 작업에 희소한 전문가를 풀어 주므로, 고역 수치를 리더십이 봐야 할 역량 신호로 다루십시오.
어떤 SRE 조직 모델을 운영하며, 더 이상 맞지 않게 되었음을 알려 줄 증거는 무엇입니까? 중앙화된 팀은 일관성과 공유 도구를 주지만 병목이 될 수 있고, 내장 모델은 맥락을 주지만 비일관성으로 표류하며, 대부분의 큰 조직이 정착하는 하이브리드는 분명한 참여 모델이 없으면 둘의 약점을 물려받습니다. 긴장을 드러내는 신호를 가져오십시오. 서비스가 SRE 지원을 기다리는 시간, 팀 간 신뢰성 실천이 얼마나 다른지, 내장 엔지니어가 전문 공동체에서 단절되었다고 느끼는지입니다. 올바른 답은 회사 규모, 엔지니어링 성숙도, 서비스가 얼마나 균일한지에 달려 있으므로, 첫 선택을 영구적인 것으로 다루지 말고 그것들이 바뀜에 따라 다시 검토하십시오. 많은 팀과 엄격한 균일성 요건이 있는 기업이나 정부 기관에서는 중앙 표준 및 플랫폼 그룹에 내장 신뢰성 엔지니어를 더하는 것이 보통 일관성과 지역 맥락의 균형을 맞추지만, 참여 모델과 프로덕션 준비 기준이 적히고 누군가 소유할 때만 그렇습니다.

분야별 관점

스타트업. 엔지니어가 소수이고 전담 신뢰성 팀에 쓸 여유가 없다면, 가장 중요한 사용자 여정에 단일 SLO 하나를 고르고 팀 전체가 온콜을 공유하십시오. 관측 가능성 인프라를 만드는 대신 클라우드 제공자의 관리형 서비스와 내장 모니터링에 기대고, 수정이 자리 잡도록 공유 문서에 짧은 사후 검토를 쓰십시오. 여기서는 프로세스보다 속도가 중요합니다. 실제로 시행하는 느슨한 SLO가 아무도 지켜보지 않는 정교한 것을 이깁니다.

소기업. 신뢰성을 운영할 전문가가 없으니 플랫폼을 통해 사 들이는 규율로 다루십시오. 맞춤 스택 대신 호스팅 가동 시간 모니터링, 관리형 데이터베이스, 상태 페이지 도구입니다. 사업을 지탱하는 거래에 묶인 한두 개의 SLO를 정하고, 어떤 실패가 고객을 잃게 할지 정직하게 정하십시오. 만드는 것보다 싼 곳에서는 복원력을 사고, 기존 엔지니어가 기능 작업과 함께 감당할 수 있을 만큼 운영 부담을 가볍게 유지하십시오.

대기업. 도전은 많은 팀에 걸친 일관성입니다. 공유 SLO 어휘, 공통 오류 예산 정책, SRE가 온콜을 맡기 전에 모든 서비스가 넘는 프로덕션 준비 기준입니다. 중앙 플랫폼 및 표준 그룹에 내장 신뢰성 엔지니어를 더하면 병목이 되지 않으면서 실천을 균일하게 유지하며, 거버넌스에는 오류 예산이 어디서나 같은 방식으로 보고되고 시행되어야 합니다. 관측 가능성 인프라와 자동화 투자를 명시적으로 예산에 잡고, 신뢰성을 리더십이 볼 수 있는 지표가 있는 포트폴리오로 관리하십시오.

정부. 공공 서비스는 흔히 공표된 가용성 목표, 법정 약속, 감사 의무를 지니므로, SLO와 오류 예산 결정은 감독 기관에 방어하는 기록이 됩니다. 조달 규칙이 쓸 수 있는 모니터링과 호스팅을 제약할 수 있고, 투명성 기대가 공개 상태 대시보드에 신뢰성 데이터를 공표하도록 이끕니다. 세금 마감과 급여 등록 기간 같은 극단적인 계절성 피크를 몇 주 앞서 계획하고, 공개적 실패가 개인 비난이 아니라 시스템 개선을 이끌도록 비난 없는 사후 검토 문화를 유지하십시오.

사례

스타트업. 열 명의 스타트업이 단일 웹 앱을 운영하며 세 엔지니어가 온콜을 공유합니다. 감당할 수 없는 신뢰성 팀을 만드는 대신 의미 있는 SLO 하나를 고릅니다. 실제 사용자 요청에서 측정한 로그인에서 대시보드 흐름의 99.5퍼센트 성공입니다. 불안정한 제3자 API가 그 예산을 먹기 시작하자, 팀은 다음 기능을 출하하는 대신 금요일을 재시도와 캐시를 더하는 데 쓰고, 수정이 자리 잡도록 공유 문서에 두 문단짜리 사후 검토를 씁니다.

기업. 한 글로벌 결제 회사가 거래 API에 99.99퍼센트 가용성 SLO를 정해, 한 달에 약 4분의 오류 예산을 갖습니다. 중앙 SRE 플랫폼 팀이 공유 관측 가능성, 사고 도구, 오류 예산 정책을 소유하고, 내장 신뢰성 엔지니어는 각 제품 그룹 안에서 일합니다. 새 사기 탐지 기능이 일주일 만에 월 예산의 절반을 태우자, 사전 합의된 정책이 신뢰성 작업이 여유를 되찾을 때까지 핵심이 아닌 릴리스를 동결합니다. 경영진이 미리 정책을 승인했기 때문에 논쟁 없이 받아들입니다.

정부. 한 국세청이 연간 마감 둘레에 극단적인 계절성 피크가 있는 온라인 신고 서비스를 운영합니다. SRE 팀은 이전 연도에 인구와 정책 변화를 더해 수요를 예측하고, 정상 피크의 몇 배까지 부하 테스트를 하고, 몇 주 앞서 용량을 사전 프로비저닝합니다. 가용성과 페이지 지연에 대한 공개 SLO가 상태 대시보드에 올라갑니다. 비난 없는 사후 검토 문화(개인 비난을 배정하는 대신 시스템을 개선하려고 실패를 리뷰)와 자동화 의무가 한때 신고 시즌을 지배하던 수동 개입을 꾸준히 줄여, 직원이 마감마다 시스템을 보살피는 대신 개선할 수 있게 풀어 줍니다.

비즈니스 사례: 동기, ROI, TCO

SRE의 수익은 세 원천에서 옵니다. 피한 다운타임, 줄어든 운영 노동, 더 빠르고 안전한 전달입니다. 큰 서비스의 다운타임은 잃은 매출, 위약금, 수습으로 시간당 수천에서 수백만의 비용이 들 수 있으므로, 소박한 신뢰성 이득도 팀 비용을 빨리 갚습니다. 고역 감소는 반복되는 수동 비용을 일회성 자동화 투자로 바꾸므로, 총소유비용은 규모와 함께 오르는 대신 규모가 커질수록 떨어집니다. 오류 예산은 신뢰성이 건강할 때 비즈니스가 더 빨리 출하하게 하여, 지나치게 신중한 운영이 테이블에 남겨 둘 기능 가치를 포착합니다.

도입 비용은 실제입니다. SRE는 숙련된 엔지니어, 관측 가능성 인프라, 기능 마감과 경쟁하는 문화적 변화가 필요합니다. 그러나 도입하지 않는 비용은 규모에서 더 높습니다. 한도 없는 운영 인력, 예측할 수 없는 장애, 직원의 소진과 이직, 정량화하기는 어렵지만 겪기는 쉬운 평판 손상입니다. 리더십을 설득하려면 SRE를 측정 가능한 수익이 있는 위험 관리로 구성하십시오. 사고와 수동 운영의 현재 비용, 비즈니스 약속에 묶인 SLO 목표, 둘 다의 예상 감소를 제시하십시오. 논거를 오류 예산에 닻을 내려 리더십에게 신뢰성 대 속도 트레이드오프에 대한 지렛대를 주는 거버넌스 도구로 삼으십시오.

안티패턴과 함정

재포장된 운영으로서의 SRE. 엔지니어링 시간, 자동화 의무, 반박할 권한 없이 운영 팀의 이름만 바꾸면 아무것도 바뀌지 않습니다.
100퍼센트를 목표로 하기. 완벽한 신뢰성을 쫓는 것은 사용자가 인지할 수 없는 이득을 위해 돈을 낭비하고 전달을 막습니다.
허영 SLI. 사용자에게 보이는 성공 대신 서버 CPU를 측정하면 사용자가 고통받는 동안 좋아 보이는 숫자를 줍니다.
이빨 없는 오류 예산. 소진되어도 시행되지 않는 예산은 그저 장식입니다.
측정 없는 고역. 고역을 추적하지 않으면 개선 작업이 일어나지 않을 때까지 조용히 팀을 소모시킵니다.
쏟아 넣는 곳으로서의 SRE. 준비 기준 없이 모든 불안정한 서비스를 물려받는 중앙화된 팀은 남들의 기술 부채에 가라앉습니다.
용량 리드 타임 무시. 클라우드 탄력성이 즉각적이고 무한하다고 가정하면 가장 중요한 바로 그 피크에 부족이 생깁니다.

성숙도 모델

1단계, 시작. 운영이 수동적이고 반응적입니다. 공식 SLO가 없고, 신뢰성은 의견의 문제이며, 불 끄기가 지배하는 동안 같은 사고가 되풀이됩니다. 자동화가 있다면 부수적이고, 아무도 신뢰성을 엔지니어링 관심사로 소유하지 않습니다.

2단계, 발전. 일부 서비스에 기본적인 SLI와 SLO, 초보적인 모니터링과 알림이 있지만 실천은 팀마다 크게 다릅니다. 고역은 인정되지만 측정되지 않고, 자동화는 즉흥적이며, 사후 검토는 일관되지 않게 이루어집니다. 신뢰성은 조직이 요구해서가 아니라 개인이 밀어붙이는 곳에서만 개선됩니다.

3단계, 표준화. SLI, SLO, 오류 예산 정책이 문서화되어 팀 전반에 일관되게 적용됩니다. 고역이 정의되고 추적되며, 용량 계획이 일상적이고, 프로덕션 준비 리뷰가 있는 SRE 참여 모델이 존재하며, 자동화는 부업 프로젝트가 아니라 자금이 지원되는 작업 흐름입니다. 신뢰성 실천이 적히고 조직 전체에서 시행됩니다.

4단계, 관리. 신뢰성 프로그램이 기준선에 대해 데이터로 측정되고 통제됩니다. 오류 예산 소진율, 고역 비율, SLO 달성, 평균 복구 시간, 프로비저닝 리드 타임이 지표로 추적되고, 고정된 주기로 리뷰되며, 팀을 목표에 묶는 데 쓰입니다. 예산 위반은 합의된 동결을 촉발하고, 용량은 수요 모델에 대해 예측되며, 모든 진행 또는 중단 결정은 의견이 아니라 증거에 근거합니다.

5단계, 오케스트레이션. 신뢰성 엔지니어링이 조직 전체에 통합되고 지속적으로 개선됩니다. 오류 예산 정책은 자동화되어 어디서나 존중되고, 대부분의 운영은 셀프서비스이며, 용량은 사전적으로 프로비저닝되고, 신뢰성 데이터가 속도와 안정성 사이의 적응적 트레이드오프를 이끕니다. 조직은 비즈니스와 위험 상황이 이동함에 따라 SLO의 범위를 일상적으로 다시 정하고, 고역을 퇴역시키고, 신뢰성 투자를 재균형합니다.

논의를 위한 아이디어

조직이 기준이 될 과거 신뢰성 데이터가 없을 때 첫 SLO를 어떻게 정해야 합니까?
오류 예산이 소진되었는데 주요 출시가 약속되어 있다면, 누가 동결을 무시할 권한이 있으며 그 결정은 어떻게 기록됩니까?
중앙화, 내장, 하이브리드 SRE 모델 중 어느 것이 조직에 맞으며, 무엇이 변경을 촉발하겠습니까?
같은 투자가 자금을 댈 수 있는 기능에 견주어 가용성의 9 하나를 어떻게 평가합니까?
여러분의 맥락에서 무엇이 고역이며, 가치 있는 수동 판단과 없앨 수 있는 반복 사이의 선은 어디입니까?
신뢰성 목표는 시민 대면 정부 서비스와 내부 기업 도구 사이에서 어떻게 달라야 합니까?

핵심 요점

SRE는 소프트웨어 엔지니어링을 운영에 적용해 신뢰성을 측정 가능하고 자금을 댈 수 있는 기능으로 다룹니다.
SLI, SLO, SLA는 신뢰성을 의견에서 합의된 숫자로 바꿉니다. SLO를 SLA보다 엄격하게 유지하십시오.
오류 예산은 신뢰성 대 속도 트레이드오프를 명시적이고 사전 협상된 것으로 만들어 개발자와 운영자를 정렬합니다.
고역을 측정하고 한도를 정하고, 운영이 준선형으로 확장되도록 자동화를 일급 엔지니어링으로 다루십시오.
수요 예측으로 용량을 계획하고 특히 계절성 피크의 프로비저닝 리드 타임을 존중하십시오.
SRE 조직 모델을 의도적으로 고르고 분명한 참여 및 프로덕션 준비 기준을 정의하십시오.

참고 문헌과 더 읽을거리

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE
David N. Blank-Edelman (editor), Seeking SRE: Conversations About Running Production Systems at Scale
Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan, The Practice of Cloud System Administration
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps