기록

지속적으로 신뢰성을 개선하는 것은 기준을 명확히 하고 절차를 추적할 수 있을 때만 가능하다. 이를 위해 구글에서는 '아우터레이터'라고 부르는 서비스 중단 현상 추적 도구를 사용한다. 이번 장에서는 아우터레이터를 통해 시스템 중단 추적에 대해서 알아보도록 하자. 1. 에스컬레이터 구글에서는 SRE를 위한 모든 알림은 사람이 알림의 수신을 확인했는지 여부를 추적하는 중앙 응답 시스템을 공유하고 있다. 설정된 시간이 지나도 아무도 수신을 확인하지 않으면 시스템은 설정된 다음 단계로 알림을 격상한다. '에스컬레이터'라고 부르는 이 시스템은 비상 대기 엔지니어에게 전달된 이메일의 복사본을 수신하는 투명한 도구로 기획된 것이다. 이 기능 덕분에 사용자의 반응이 없어도 에스컬레이터가 손쉽게 기존의 업무 흐름에 통합될..

이번 장에서는 포스트모텀의 수행 시기를 결정하기 위한 조건, 포스트모텀 작성 이유에 대해 알아보도록 하자. 1. 구글의 포스트모텀 철학 포스트모텀을 작성하는 가장 큰 이유는 장애에 대한 내용을 문서화하고, 장애가 발생하게 된 원인에 대해 이해하며, 무엇보다 장애를 해결하기 위해 취한 조치들이 향후 장애의 재발을 막는 데도 유용하게 사용될 수 있도록 하기 위함이다. 포스트모텀은 불이익을 주기 위한 것이 아니다. 회사 전체가 실패로부터 새로운 것을 배울 수 있는 기회인 것이다. 팀마다 조금씩 다르겠지만 보통 포스트모텀은 다음과 같은 상황이 발생했을 때 수행한다. 사용자가 다운타임을 경험했거나 신뢰성이 목표치 이하로 떨어진 경우 종류에 관계 없이 데이터 손실이 발생한 경우 장애의 해결 시간이 목표치보다 오래 ..

이번 장에서는 장애를 어떻게 관리하면 좋을지 알아보도록 하자. 1. 미흡한 장애 관리 책에서는 미흡한 장애 관리 예시를 통해서 문제점이 무엇인지 알려주고 있다. 미흡한 장애 관리의 가장 큰 원인은 소통의 부재이다. 동료들이 무엇을 하고 있는지 모르는 상황이었고, 고객과 비즈니스 리더들에게도 현재 상황을 올바르게 전달하지 못하고 있었다. 2. 책임에 대한 재귀적인 분리 소통의 부재를 해결하기 위해서는 각자 자신의 역할을 명확히 이해하고 다른 이의 영역을 침범하지 않도록 하는 것이 가장 중요하다. 역할은 크게 4가지 존재한다. 장애 제어: 장애 제어자(incident commander)는 장애에 대한 높은 수준의 상태를 확인한다. 그리고 장애 조치를 위한 팀을 구성하고 필요와 우선순위에 따라 책임을 나누어준..

이번 장에서는 긴급 대응이 필요했던 몇 가지 사례를 소개하고 있다. 1. 사례 1 - 사전 테스트 구글은 재난과 긴급 상황에 대한 사전적 테스트 접근법을 취하고 있다. SRE들은 시스템에 장애를 일으킨 후 이로 인해 시스템이 어떻게 실패하는지를 지켜본 다음, 그 현상이 반복해서 발생하지 않도록 신뢰성을 향상시킬 수 있는 변경 사항을 적용한다. 대부분의 경우 장애는 계획에 따라 제어가 가능하며 대상 시스템과 그에 의존하는 시스템들은 대체로 예상했던 대로 동작한다. 하지만 예상과 실제 결과가 어긋날 때가 있다. 사전 테스트에 포함되지 않은 내용으로 인해 테스트 수행 시 장애가 발생한 경우를 생각해보자. 장애가 발생한 이유가 무엇일까? 아마도 실제 환경에 존재하는 다양한 의존 관계에 대해서 고려하지 못했기 때..

이번 장에서는 장애 조치의 일반적인 과정에 대해 알아보도록 하자. 1. 이론 장애 조치 방법은 가설 연역 방법이라고 생각하면 된다. 장애의 잠재적 원인에 대해 가설을 세우고 가설을 시험하는 과정을 반복하기 때문이다. 가설을 검증하는 방법은 크게 두 가지가 존재한다. 관찰한 시스템의 상태를 이론과 비교하여 정황들이 들어맞는지 확인 시스템을 고쳐보고 그 결과를 다시 관찰 둘 중 어떤 방법을 사용하든, 근본 원인이 발견될 때까지 계속해서 테스트를 수행하고 원인이 발견되면 장애 재발을 방지하기 위해 그에 대한 조치를 수행한 후 포스트 모텀 문서를 작성한다. 2. 통상적인 문제 비효율적인 장애 조치 세션은 장애 등급 선정, 분석 및 진단 단계에 영향을 미친다. 이들 중 대부분은 시스템에 대한 깊은 이해가 부족해서..

이번 장에서는 구글의 SRE들이 수년에 걸쳐 개발한 비상 대기(on-call) 업무 수행 방안의 기본적인 원리에 대한 소개와, 이를 바탕으로 서비스의 안정성을 보장하고 업무 부하를 안정적으로 유지하는 방법에 대해 설명하고 있다. 1. 소개 구글은 성능과 신뢰성을 책임지는 전담 SRE팀이 있다. 이러한 SRE 분들이 서비스를 위한 비상 대기 업무를 수행하는데 주요 임무는 자신들이 관리하는 서비스들을 문제 없이 운영하는 것이다. 문제 없이 운영하기 위해서는 하나의 분야에 특화된 사람이 아니라 다양한 사람들이 필요하다. 따라서 구글은 시스템과 소프트웨어 엔지니어링에 있어 각기 다른 배경지식을 가진 사람들을 SRE팀에 충원하고 있다. 또한 SRE가 순수한 운영 업무에 할애할 수 있는 시간을 최대 50%로 제한하..

10장은 대부분 구글에서 시계열 모니터링을 어떻게 수행하고 있는지 알려주고 있다. 물론 도움이 되는 내용도 있었지만 보그몬의 탄생, 예시로 든 애플리케이션의 조작, 내보낸 데이터의 수집 등 대부분의 내용은 현업에 적용하기에는 무리가 있어 보인다. 따라서, 구글에서 어떻게 수행하고 있는지 자세하게 알기 위해서는 책을 읽어보는 것이 좋을 것 같고 블로그에는 현업에 적용이 가능한 개념을 작성하고자 한다. 1. 알림 제품을 구성하는 계층의 가장 밑바닥에 깔려있는 모니터링은 안정적인 서비스를 운영하기 위해서는 반드시 필요한 기본 구성 요소다. 서비스 담당자가 서비스의 변경에 따른 영향을 합리적으로 결정할 수 있고, 장애가 발생했을 때는 과학적인 방법으로 대체할 수 있음은 물론이고 서비스가 비즈니스 목표에 맞게 운..

1. 안정성 vs 신속성 시스템의 안정성과 신속함 중 어떤 것이 중요할까? 주요 프로덕션 소프트웨어 시스템의 경우라면, 안정성과 신속함의 적절한 균형을 원할 것이다. SRE는 절차와 사례, 그리고 도구를 만들어 좀 더 신뢰성 있는 소프트웨어를 구성하기 위해 일한다. 마찬가지로 SRE는 이런 작업들이 개발자들의 신속성에 가능한 영향을 미치지 않도록 일한다. 하지만 신뢰성을 위한 프로세스는 개발자들의 신속성을 오히려 높이는 경향이 있다. 2. 지루함의 미덕 소프트웨어 분야에서 '지루함'은 긍정적인 요소이다. 대부분의 개발자들은 프로그램이 자생적이고 흥미로운 어떤 것이기를 원하지 않는다. 스크립트 내에 가만히 앉아서 자신들의 비즈니스적 역할을 예측 가능한 상태에서 수행하기만을 바랄 뿐이다. 프로덕션 환경에서 ..

1. 릴리즈 엔지니어링? 릴리즈 엔지니어링은 소프트웨어 엔지니어링보다 상대적으로 새로운 개념이며 빠르게 성장하고 있는 원리로, 소프트웨어를 빌드하고 전달하는 과정을 간략하게 기술하는 분야라고 한다. 사실, 이번 책을 통해서 릴리즈 엔지니어링 용어를 처음 알게 되었다. 따라서, 소프트웨어를 빌드하고 전달하는 작업은 당연히 소프트웨어 엔지니어(SWE)가 수행하는 것으로 알고 있었다. 하지만, 구글에서는 릴리즈 엔지니어링이라는 특정 직업군이 있다. 릴리즈 엔지니어는 제품 개발부 소속으로 소프트웨어 엔지니어 및 SRE와 함께 일하며 소프트웨어 릴리즈에 필요한 모든 단계들을 정의한다고 한다. 개인적인 생각으로는 릴리즈 엔지니어는 규모가 큰 프로젝트에 필요할 것 같은데 한국에서는 카카오페이가 해당 직군을 채용 중인..

이번 장에서는 자동화의 가치 및 자동화를 대하는 우자세에 대한 변화에 대해 설명하고자 합니다. 1. 자동화의 가치 자동화의 진정한 가치는 무엇일까요? 일관성 아무리 노력하더라도 사람이 기계처럼 일관성을 가지기란 불가능에 가깝습니다. 이처럼 예상치 못한 일정하지 못한 방식은 실수와 간과로 인해 데이터 품질의 문제를 유발하며, 결국 신뢰성의 문제로 발전하게 됩니다. 정확하게 정의된 업무 범위와 정해진 절차를 수행하는 데 있어 일관성의 가치는 다양한 측면에서 자동화가 최우선적으로 추구하는 가치입니다. 플랫폼 자동화 시스템은 확장이 가능하고 다른 시스템에도 적용이 가능하거나 심지어 이윤을 창출할 수 있는 플랫폼을 제공합니다. 이렇게 구축된 플랫폼은 실수를 중앙집중화하는 데도 도움이 됩니다. 엄청난 인력이 수동..