[사이트 신뢰성 엔지니어링]_오탈자

현재까지 발견된 위 책의 오탈자 정보와 오류, 그리고 보다 매끄러운 문장을 위해 수정한 내용을 안내해드립니다. 번역과 편집 시에 미처 확인하지 못하고 불편을 끼쳐드려 죄송하다는 말씀을 드립니다. 아래의 오탈자 사항은 추후 재쇄 시에 반영하도록 하겠습니다. 

 

이외의 오탈자 정보를 발견하시면 옮긴이(aspnetmvp@gmail.com)나 출판사(readers.jpub@gmail.com)로 연락주시면 고맙겠습니다.

 

최종수정일자: 2021년 8월 12일

4쇄본 오탈자

 

(업데이트순)

69쪽 '블랙박스와 화이트박스' 절 첫 번째 문단의 마지막 문장(배O희 님 제보)
그래서 문제가 발생하려는 징후나 재시도에도 불구하고 여전히 실패하는 작업 등을 포착할 수 있다.
==>

그래서 문제가 발생하려는 징후나 재시도에 의해 가려진 실패 등을 포착할 수 있다.

125쪽 ' 개발' 절 두 번째 문단 첫 번째 문장(배O희 님 제보)
제 23장 치명적인 상태 관리하기: 신뢰성을 위한 대한 합의에서는
==> 

제 23장 치명적인 상태 관리하기: 신뢰성을 위한 분산에 대한 합의에서는

136쪽 동물 모양의 제안사항 문단 1행에서(배O희 님 제보)
카운터는 변수를 감소시키는

==>
카운터는 변수를 감소시키지 않는

142쪽 그림에서(배O희 님 제보)
inter-Borgmon Valuesteam

==>
inter-Borgmon Valuestream

 

522 쪽 '조기 참여의 장점' 절의 2~3행에서(배O희 님 제보)
서비스 주기에 늦게 투입되는 모에 대비 훨씬 많은 장점을 얻게 된다.
==>

서비스 주기에 늦게 투입되는 것에 비해 훨씬 많은 장점을 얻게 된다.

518쪽 '참여(engagement)' 절의 마지막 문단에서(배O희 님 제보)
목적은 SRE팀이 개발팀과 그 서비스에 참여하기 위한 절차, 최종 목표, 그리고 대한 공통의 합의를 이끌어내는 것이다.
==>

목적은 SRE팀이 개발팀과 그 서비스에 참여하는 데 필요한 절차, 최종 목표, 그리고 결과물에 대한 공통의 합의를 이끌어내는 것이다.

503족 4행에서(배O희 님 제보)
무지기수이고 ==> 부지기수이고

500쪽 두 번째 문단 1행에서(배O희 님 제보)
또한 주요 의사 결정이자 또한 이 회의에 참석해야 한다.
==>

또한 주요 의사 결정자도 이 회의에 참석해야 한다.

491쪽 하단 4행에서(배O희 님 제보)
SEO의 관점에서 볼 때
=> 

SRE의 관점에서 볼 때

 

396쪽 네 번째 문단 마지막 문장에서(배O희 님 제보)
이 예시에서 보듯이 최상의 데이터 무결성 위반에 대한 조기 발견 및 신속한 수정과 복구다.
==>  
이 예시에서 보듯이 최상의 데이터 무결성의 비밀은 조기 발견 및 신속한 수정과 복구다.

 

262쪽 'DNS를 이용한 로드밸런싱' 절의 두 번째 문단 마지막 문장에서(배O희 님 제보)
SRE 레코드는 HTTP에는 아직 적용되지 않았다.
==>
SRV 레코드는 HTTP에는 아직 적용되지 않았다.

 

37쪽 본문 두 번째 문단 5~8행(배O희 님 제보)

그러나 ISP와 프로토콜(예를 들면 TCP와 UDP, 혹은 IPv4와 IPv6)에 따라 그 차이가 적지 않으므로 우리가 측정한 ISP의 평균 백그라운드 에러율은 0.01%에서 1% 사이 정도다.
==>
물론 ISP와 프로토콜(예를 들면 TCP와 UDP, 혹은 IPv4와 IPv6)에 따라 그 차이가 적지는 않으나, 우리는 ISP의 평균 백그라운드 에러율을 0.01%에서 1% 사이 정도로 보고 있다.

 

최종수정일자: 2019년 11월 13일

3쇄본 오탈자

 

(업데이트순)

334쪽 마지막 문단 1번째 줄 (JuhoLee 님 제보)

개다가 개발자의 입장에서는

=> 

게다가 개발자의 입장에서는

 

 

최종수정일자: 2018년 5월 23일

1-2쇄본 오탈자

 

(업데이트순)

399쪽 6번째 줄 (윤*림 님 제보)

실제로 백업은 데이터 복구에 촛점을 맞춰야 한다.

=> 실제로 백업은 데이터 복구에 초점을 맞춰야 한다.

 

399쪽 7번째 줄 (윤*림 님 제보)

간혹 사람들은 백업을 원하는 게 아니라 데이터를 복구하기를 원하는 경우가 있다.

=> 실제로 사람들이 정말 원하는 것은 데이터의 복구지 백업 자체가 아니다.

 

462쪽 2번째 줄 (윤*림 님 제보)

가장 ㅈ유용한 문서 자료

=> 가장 유용한 문서 자료

 

486쪽 밑에서 2번째 줄 (윤*림 님 제보)

이 방법을 사용할 때는 한 명 이상의 엔지니어를 지원할 필요는 없다. 

=> 이 방법을 사용할 때는 두 명 이상의 엔지니어를 지원할 필요는 없다.

 

494쪽 3번째 줄 (윤*림 님 제보)

이 시작 프로시저는 너무 복잡해 보입니다.

=> 

"이 시작 프로시저는 너무 복잡해 보입니다.

 

132쪽 마지막 줄 (윤*림 님 제보)

이 시계열에 다른 레이블의 치환을 추가하면 행렬은 다차원 행렬이 된다.  

=>

이 시계열에 다른 레이블의 순열을 추가하면 행렬은 다차원 행렬이 된다.  

 

140쪽 '알림' 절 첫째 줄 (윤*림 님 제보)

보그몬은 알림 규칙을 평가해서 그 결과가 참이면 알림을 발송하지만 그 결과가 참이 아닐 수도 있다.  

=> 

보그몬은 알림 규칙을 평가하여 그 결과가 참이면 알림을 발송하고 아니면 발송하지 않는다.

 

145쪽 밑에서 9번째 줄 (윤*림 님 제보)

유지 관리 비용이 서비스 크기와 부차적으로 비례하도록 보장하는 것은  

 

=> 

유지 관리 비용이 서비스 크기와 부선형적으로 비례하도록 보장하는 것은

 

157쪽 '이론' 절 첫째 줄 (윤*림 님 제보)

가설귀납법적인방법

 

=> 

가설 연역 방법

 

166쪽 밑에서 9번째 줄 (윤*림 님 제보)

이런 도구들은 대부분 서비스와 팀 간의 공통성을 확인함으로써 중복된 노력을 제거하기 위해 주어진 시스템에 특화되어 개발되어야 한다.  

 

=> 

이러한 도구들은 대부분 주어진 시스템에 특화되어 있지만, 중복된 노력을 제거하기 위해 서비스와 팀 간의 공통성을 찾아야 한다.

 

192쪽 첫 번째 절제목 (윤*림 님 제보)

책임에 대한 귀납적인 분리

=> 

책임에 대한 재귀적인 분리

 

193쪽 밑에서 3번째 줄 (윤*림 님 제보)

포스트모템

=> 

포스트모텀

 

226쪽 절제목 (윤*림 님 제보)

테스트로 인한 재해

=> 

재해 테스트

 

251쪽 '기대치 설정하기' 절 3번째 줄 괄호 (윤*림 님 제보)

최소 존속 제품

=> 

최소 기능 제품

 

85쪽 밑에서 7번째 줄 (윤*림 님 제보) 

임의의 계좌들을 선별해서 그 속성을 변경하는 등의 코드를 작성하는 경우는 드물다.

=> 

임의의 계정들을 선별해서 그 속성을 변경하는 등의 코드를 작성하는 경우는 드물다.

 

87쪽 위에서 5번째 줄 괄호 안 (윤*림 님 제보)

(통상 계정의 추가나 시스템 시동(tuneup)과 같은 '최초 작업들')

=> 

(통상 계정의 추가나 시스템 시동(turnup)과 같은 '최초 작업들')

 

89쪽 가운데 두 번째 불릿기호에서 (윤*림 님 제보) 

오류 예산을 충족하려면

 

=> 에러 예산을 충족하려면

 

90쪽 위에서 9번째 줄 (윤*림 님 제보) 

장애 대응가 자동화되었으므로

=> 

장애 대응이 자동화되었으므로

 

 

최종수정일자: 2018년 5월 8일

1쇄본 오탈자

 

(업데이트순)

25쪽 위에서 6번째 줄 (윤*림 님 제보) 

그런 다음 서버에게 HTML 요청을 담은 RPC를 전달한다(3).

=> 그런 다음 서버에게 HTTP 요청을 담은 RPC를 전달한다(3).

 

25쪽 위에서 8번째 줄 (윤*림 님 제보) 

셰익스피어 서버는 HTML 요청을 분석하여 탐색할 단어를 포함하는 프로토콜 버퍼를 구성한다.

=> 셰익스피어 서버는 HTTP 요청을 분석하여 탐색할 단어를 포함하는 프로토콜 버퍼를 구성한다.

 

13쪽 첫 번째 문단 2-3행(윤문) 

이 과정에서 사람의 개입을 배제하면 피로도, 숙련도/무시, 반복 작업에 대한 부주의 등의 일반적인 문제들을 해소할 수 있다.

==>

이 과정에서 사람의 개입을 배제하면 피로도와 숙련도 또는 무시와 반복 작업에 대한 부주의 등 일반적인 문제들을 해소할 수 있다.

 

41쪽 '소프트웨어  결함 허용' 2-3행(윤문)

너무 경직되어 있다면 융통성 없고 사용성이 떨어지는 제품이 될 것이고, 너무 유연하다면 (너무나 안정적으로 동작하지만) 아무도 사용하려 하지 않는 제품이 될 것이다.

==>

결함을 너무 허용하지 않으면 융통성이 없고 사용성이 떨어지는 제품이 될 것이고, (너무나 안정적으로 동작하지만) 결함을 너무 많이 허용하면 오히려 아무도 사용하려 하지 않는 제품이 될 것이다.