Google이 DevOps를 보는 방식

and -에서 제시한 video content을 통해 개발자와 운영 간의 잠재적인 마찰에 대해 논의합니다. 변화 대 안정성.

내가 잘못 설명하지 않은 것을 신께 감사드립니다! 🤓 적어도 이 영상만큼은요.

Google은 DevOps에 5가지 특성이 있다고 설명합니다.

조직 사일로 감소

실패를 정상으로 받아들임

점진적 변경 구현

툴링 및 자동화 활용

모든 것을 측정하세요

SRE로 이동

Google은 객체 지향 클래스가 인터페이스를 구현하는 방식과 유사한 방식으로 사이트 안정성 엔지니어링을 생각합니다.

class SRE implements DevOps

특히 SRE의 의지

개발자와 환경 소유권 공유(조직 사일로 감소)

서비스 수준 개체 및 비난 없는 사후 분석(실패를 정상으로 받아들임)

Canary releases 등의 실패 비용 절감 (점진적 변화 구현)

가능한 한 많은 수작업을 제거합니다(툴링 및 자동화)

측정TOIL 및 시스템 신뢰성(모든 것을 측정)

신뢰성에 대해 이야기합시다

내가 좋아하는 이 부분. 실제로 시스템이 얼마나 신뢰할 수 있어야 하는지, 그 반대의 경우에는 어떤 비신뢰성 오류 예산이 필요한지 질문하십시오.

99.9% = 28일 동안 40분

따라서 모니터링 시스템이 문제를 발견하고 누군가와 사람이 조치를 취하도록 경고하는 데 충분합니다. 물론 근본 원인에 따라 다릅니다.

99.99% = 28일 동안 4분

이제 기계 기반 감지 및 자가 치유의 세계에 들어왔습니다. 소프트웨어 업데이트 및 롤아웃은 분리된 영역으로 격리되어야 할 수 있습니다.

99.999% = 28일 동안 28초

행운을 빕니다! 모니터링 시스템이 실제로 이 다운 시간을 놓칠 가능성도 있습니다. 1분마다 가동 시간을 확인하는 경우 가동 중지 시간 문제를 놓치고 '작동 중'이라고 잘못 보고할 수 있다고 상상해 보십시오.

이제 이러한 생각을 Google Cloud와 같은 퍼블릭 클라우드 서비스 사용으로 확장하십시오. 왕복 지원 요청을 도입하고 안정성 오류 예산을 소비했을 가능성이 높습니다.

시스템이 얼마나 "가용성"이 있어야 하고 그것이 어떤 의미를 갖는지에 대한 매우 흥미로운 생각입니다.

더 스테이퍼프트 맨

인정합니다 - 어쩔 수 없었습니다....오늘 모의 테스트 중 하나를 실행했습니다. 당신은 내 격차를 이해하는 것을 알고 있습니다.

저는 13개 중 7개를 맞혔습니다. 약 53%였습니다.

이 단계에서 내 격차는 특히 Stackdriver 내의 특정 Google API와 권장되는 보안 관행에 관한 것이었습니다.

나와 함께 일한 사람에게 - 그것은 아마도 새로운 정보가 아닐 것입니다 #카우보이