사이트 신뢰성 엔지니어링(Site Reliability Engineering, SRE)은 소프트웨어 엔지니어링을 사용하여 시스템 관리자가 수작업으로 수행했던 IT 운영 작업(예: 프로덕션 시스템 관리, 변경 관리, 인시던트 대응, 심지어 긴급상황 대응도 포함)을 자동화합니다. 

SRE의 원칙은 대규모 소프트웨어 시스템에 대한 감독을 자동화하기 위해 소프트웨어 코드를 사용하는 것이 수동 개입보다 더 확장 가능하고 지속 가능한 전략이라는 것입니다. 특히 이러한 시스템이 클라우드로 확장되거나 마이그레이션되는 경우 그러합니다.

또한 SRE는 계속적으로 새 소프트웨어 또는 업데이트된 소프트웨어를 프로덕션으로 릴리스하고자 하는 개발 팀과 운영 중단 또는 기타 운영 문제를 유발하지 않는다는 것이 확실하지 않으면 어떤 유형의 업데이트나 새 소프트웨어도 릴리스하려고 하지 않는 운영 팀 사이에서 자연적으로 발생하는 마찰의 많은 부분을 완화하거나 없앨 수 있습니다. 따라서 엄격히 말해 SRE는 DevOps에 필수적이지는 않지만, DevOps 원칙과 긴밀하게 관련되고 DevOps의 성공에 중요한 역할을 수행할 수 있습니다.

SRE의 개념은 "SRE는 소프트웨어 엔지니어에게 운영 팀 설계를 요청할 때 발생하는 것"이라는 유명한 글을 쓴 Google의 엔지니어링 부사장인 Ben Treynor Sloss가 만든 것입니다.

사이트 신뢰성 엔지니어는 IT 운영 경험이 있는 소프트웨어 개발자로, 코딩 방법을 알고 대규모 IT 환경에서 '운영을 유지'하는 방법도 이해합니다. 

사이트 신뢰성 엔지니어는 수동 IT 운영 및 시스템 관리 작업(로그 분석, 성능 조정, 패치 적용, 프로덕션 환경 테스트, 사고 대응, 사후 분석 수행)을 수행하는 데 절반 이상의 시간을 사용하지 않고 나머지 시간은 이 작업을 자동화하는 코드를 개발하는 데 사용합니다. 목표는 시간이 흐름에 따라 전자에 사용하는 시간을 훨씬 더 줄이고 후자에 사용하는 시간을 훨씬 더 늘리는 것입니다.

개괄적으로 SRE 팀은 개발 팀과 운영 팀 사이의 다리 역할을 수행합니다. 즉, 개발 팀이 최대한 빨리 새 소프트웨어 또는 새 기능을 프로덕션 단계로 진행하고, 조직이 고객과 체결한 서비스 수준 계약(SLA)에 따라 IT 운영 성과와 오류 리스크가 합의된 적절한 수준에 이르도록 지원합니다. SRE 팀은 경험과 풍부한 운영 데이터를 기반으로 개발 팀과 운영 팀이 다음 사항을 고려할 수 있도록 돕습니다.

• 서비스 수준 지표(Service Level Indicator, SLI): 가용성(가동 시간) 또는 대기 시간과 같은 메트릭을 통해 시스템에서 제공하는 서비스 수준 측정
  
  
• 서비스 수준 목표(Service Level Objective, SLO): 서비스 수준 지표를 측정하기 위해 합의된 수단
  
  
• 오류 예산: SLA의 계약 조건을 위반하지 않고 시스템이 실패하거나 성능이 저하될 수 있는 최대 시간. 오류 예산은 단순한 지표가 아닌 사이트 신뢰성 엔지니어링 팀이 회사의 혁신 속도와 서비스 신뢰성을 자동으로 조정하기 위해 사용하는 도구의 기능을 수행 

오류 예산은 SRE 팀이 회사의 서비스 신뢰성과 소프트웨어 개발 및 혁신 속도를 자동으로 조정하기 위해 사용하는 도구입니다. 

회사의 SLA가 연간 99.99%의 가동 시간(일반적인 가용성 목표치)을 약속한다고 가정합니다. 이는 월간 오류 예산(특정 월에 계약을 위반하지 않은 상태로 허용되는 총 다운타임)이 약 4분 23초임을 의미합니다.

이제 개발팀이 시스템에 몇 가지 새로운 기능이나 개선 사항을 출시하려고 한다고 가정해 보겠습니다. 시스템이 오류 예산 아래에서 실행 중인 경우 팀은 새 기능을 제공할 수 있습니다. 그렇지 않을 경우 개발 팀은 운영 팀과 협력하여 이러한 오류 또는 운영 중단을 허용되는 수준으로 낮출 때까지 새 기능을 제공할 수 없습니다.

이러한 방식으로 오류 예산은 개발 팀과 운영 팀이 다음 사항을 수행할 수 있도록 돕습니다.

• 서비스의 안정성 및 성능 향상
  
  
• 새 기능 또는 애플리케이션 배포 여부에 대해 데이터를 기반으로 의사 결정
  
  
• 허용 한계 이내로 리스크를 줄여 혁신을 극대화

DevOps는 소프트웨어 제공 라이프사이클을 자동화하고, 개발 팀과 운영 팀이 책임을 더 많이 공유하고 서로의 업무에 대한 의견을 제시하도록 하여 고품질 애플리케이션을 더 빨리 제공하는 최신 방법입니다. 

SRE와 마찬가지로 DevOps도 프로덕션 환경을 '중단'시키지 않아야 하는 필요성과 더 많은 애플리케이션과 변경 사항을 더 빨리 제공해야 하는 필요성 사이의 균형을 유지하여 비즈니스 민첩성을 향상합니다. SRE와 마찬가지로 DevOps는 허용되는 수준의 오류 리스크를 설정하여 이러한 균형을 유지하고자 합니다. 사실, SRE와 DevOps는 너무 비슷해 보이기 때문에 일부 전문가는 이 두 가지가 같은 것이라고 말합니다. 그러나, 대부분의 사람들은 SRE 관행이 DevOps 원칙을 구현하기 위한 탁월한 방법이라고 봅니다. 예를 들면 다음과 같습니다.

DevOps 원칙: 조직의 사일로를 줄이고, 툴링(tooling) 및 자동화 활용

SRE 관행: 개발자가 소프트웨어를 개발하고 향상하기 위해 사용하는 것과 같은 툴링을 사용하여 운영을 자동화 및 개선

DevOps 원칙: 실패를 당연한 것으로 받아들이고 점진적인 변화 실현

SRE 관행: 허용되는 수준 안에서 오류 예산에 따라 지속적으로 새 기능을 배포

DevOps 원칙: 모든 것을 측정

SRE 관행: SLA 지표에 따라 새로운 소프트웨어 릴리스 여부를 결정함

DevOps에 대한 자세한 내용은 아래 비디오에서 확인하세요(5:58).

사이트 신뢰성 엔지니어링은 DevOps의 성공을 지원할 뿐만 아니라 회사에 다음과 같은 장점을 제공할 수 있습니다.

• 조직 내 모든 서비스에 대한 지표, 로그 및 트레이스를 추적하고 인시던트 발생 시 근본 원인을 파악하기 위한 컨텍스트를 제공하여 서비스 상태에 대한 향상된 가시성을 확보합니다.
  
  
• 개발 팀과 운영 팀이 SLA 위반 시 발생하는 비용을 이해하고, 경영진이 시스템 신뢰성이 생산, 영업, 마케팅, 고객 서비스 및 기타 비즈니스 부문에 미치는 영향을 정량화하도록 도움으로써 다운타임으로 인한 비용을 정량화합니다.
  
  
• 효율적인 긴급 프로세스를 구축하고 경보 워크플로우를 효율화하여 인시던트 대응을 최적화합니다.
  
  
• IT 운영에 대한 심층적 이해를 머신 러닝 및 자동화와 결합하여 문제 해결을 담당하는 사람에게 직접 알림을 보냄으로써 최신 네트워크 운영 센터를 구축합니다 .

기존 IT 및 온프레미스 데이터 센터에서 하이브리드 클라우드로의 마이그레이션은 매년 평균적인 엔터프라이즈가 생성하는 운영 데이터가 2~3배 증가하게 만든 주된 이유 중 하나입니다. 시스템 관리, 운영 및 인시던트 대응을 자동화하고, IT 환경이 더욱 복잡해지는 가운데 엔터프라이즈 신뢰성을 향상하기 위해 이러한 데이터를 활용하려면 SRE가 필수적이라고 보는 사람들이 더 많아지고 있습니다.

클라우드 네이티브 개발 접근법(특히, 애플리케이션을 마이크로서비스로 구축하고 이를 컨테이너에 배포하는 것)은 애플리케이션 개발, 배포, 확장을 간소화할 수 있습니다. 그러나 클라우드 네이티브 개발로 인해 관리와 운영을 복잡하게 하는 더욱 분산된 환경이 조성되기도 합니다. SRE 팀은 DevOps 팀에게 운영 압박을 가중시키지 않고 클라우드 네이티브 접근법으로 가능해지는 빠른 혁신 속도를 지원하고 시스템 신뢰성을 유지하거나 향상할 수 있습니다.