SRE를 위한 시스템 설계와 구축

Book description

시스템이 근본적으로 안전하지 않다면 신뢰할 수 있을까? 보안과 신뢰성은 제품 품질, 성능 및 가용성에 중요한 역할을 하기 때문에 확장되는 시스템의 설계와 운영에 매우 중요하다. 이 책은 안전하고 확장이 가능하며 신뢰할 수 있는 시스템을 설계하는 데 도움을 주는 구글의 구체적인 모범 사례를 자세히 공유한다. 또한, 보안과 안정성에 특화된 실무자의 시스템 설계, 구현 및 유지 보수에 대한 통찰력도 함께 제공한다. 구글러들의 경험으로 얻은 통찰과 SRE 지침을 익혀, 안전하고 신뢰성이 높은 시스템을 구축하길 바란다.

Table of contents

  1. 헌사
  2. 추천사
  3. 지은이·옮긴이 소개
  4. 옮긴이의 말
  5. 머리말 (로열 핸슨)
  6. 머리말 (마이클 와일드패너)
  7. 이 책에 대하여
  8. 감사의 글 (1/5)
  9. 감사의 글 (2/5)
  10. 감사의 글 (3/5)
  11. 감사의 글 (4/5)
  12. 감사의 글 (5/5)
  13. PART I 들어가며
    1. CHAPTER 1 보안과 신뢰성 사이의 교집합
      1. 1.1 비밀번호와 전기드릴
      2. 1.2 신뢰성과 보안의 비교: 설계 고려사항
      3. 1.3 기밀성, 무결성, 가용성
        1. 1.3.1 기밀성
        2. 1.3.2 무결성
        3. 1.3.3 가용성
      4. 1.4 신뢰성과 보안: 공통점 (1/2)
      5. 1.4 신뢰성과 보안: 공통점 (2/2)
        1. 1.4.1 불가시성
        2. 1.4.2 평가
        3. 1.4.3 간결성
        4. 1.4.4 발전
        5. 1.4.5 회복성
        6. 1.4.6 설계에서 프로덕션까지
        7. 1.4.7 시스템 조사와 로깅
        8. 1.4.8 위기 대응
        9. 1.4.9 복구
      6. 1.5 마치며
    2. CHAPTER 2 적을 알자
      1. 2.1 공격자의 동기
      2. 2.2 공격자 프로필 (1/3)
      3. 2.2 공격자 프로필 (2/3)
      4. 2.2 공격자 프로필 (3/3)
        1. 2.2.1 취미로 즐기는 사람
        2. 2.2.2 취약점 연구원
        3. 2.2.3 정부와 법 집행 기관
        4. 2.2.4 운동가
        5. 2.2.5 범죄자
        6. 2.2.6 자동화와 인공 지능
        7. 2.2.7 내부자
      5. 2.3 공격의 방식
        1. 2.3.1 위협 정보
        2. 2.3.2 사이버 킬 체인
        3. 2.3.3 전술, 기법, 절차
      6. 2.4 위험 평가 시 고려사항
      7. 2.5 마치며
  14. PART II 시스템 설계
    1. CHAPTER 3 사례 연구: 안전한 프록시
      1. 3.1 프로덕션 환경의 안전한 프록시
      2. 3.2 구글 도구 프록시
      3. 3.3 마치며
    2. CHAPTER 4 설계 절충
      1. 4.1 설계 목표와 요구사항
        1. 4.1.1 기능 요구사항
        2. 4.1.2 비기능성 요구사항
        3. 4.1.3 기능과 이머전트 속성의 비교
        4. 4.1.4 예시: 구글 설계 문서
      2. 4.2 요구사항의 균형잡기 (1/2)
      3. 4.2 요구사항의 균형잡기 (2/2)
        1. 4.2.1 예시: 결제 처리
      4. 4.3 갈등의 관리와 목표의 조정
        1. 4.3.1 예시: 마이크로서비스와 구글 웹 애플리케이션 프레임워크
        2. 4.3.2 이머전트 속성의 요구사항 조정하기
      5. 4.4 초기의 속도와 지속적인 속도의 비교
      6. 4.5 마치며
    3. CHAPTER 5 최소 권한 설계
      1. 5.1 개념과 용어
        1. 5.1.1 최소 권한
        2. 5.1.2 제로 트러스트 네트워킹
        3. 5.1.3 제로 터치
      2. 5.2 위험에 따라 접근 분류하기
      3. 5.3 권장 사례 (1/3)
      4. 5.3 권장 사례 (2/3)
      5. 5.3 권장 사례 (3/3)
        1. 5.3.1 작은 크기의 기능적 API
        2. 5.3.2 유리 깨기 메커니즘
        3. 5.3.3 감사
        4. 5.3.4 테스트와 최소 권한
        5. 5.3.5 접근 거부 진단
        6. 5.3.6 우아한 실패와 유리 깨기 메커니즘
      6. 5.4 실제 사례: 설정 분산
        1. 5.4.1 OpenSSH를 통한 POSIX API 사용
        2. 5.4.2 소프트웨어 업데이트 API
        3. 5.4.3 커스텀 OpenSSH ForceCommand
        4. 5.4.4 커스텀 HTTP 리시버 (사이드카)
        5. 5.4.5 커스텀 HTTP 리시버 (인프로세스)
        6. 5.4.6 절충안
      7. 5.5 인증과 승인을 위한 정책 프레임워크
        1. 5.5.1 고급 승인 제어
        2. 5.5.2 승인 프레임워크의 광범위한 사용
        3. 5.5.3 잠재적인 함정 피하기
      8. 5.6 더 알아보기: 고급 제어 (1/2)
      9. 5.6 더 알아보기: 고급 제어 (2/2)
        1. 5.6.1 멀티파티 승인
        2. 5.6.2 쓰리팩터 인증
        3. 5.6.3 비즈니스 사유
        4. 5.6.4 임시적 접근
        5. 5.6.5 프록시
      10. 5.7 절충과 긴장
        1. 5.7.1 보안 복잡도의 증가
        2. 5.7.2 협업과 기업 문화에 미치는 영향
        3. 5.7.3 보안에 영향을 미치는 양질의 데이터와 시스템
        4. 5.7.4 사용자 생산성에 미치는 영향
        5. 5.7.5 개발자 복잡도에 대한 영향
      11. 5.8 마치며
    4. CHAPTER 6 이해 가능성을 위한 설계
      1. 6.1 이해 가능성이 중요한 이유
        1. 6.1.1 시스템 불변성
        2. 6.1.2 불변성 분석하기
        3. 6.1.3 멘털 모델
      2. 6.2 이해가 가능한 시스템의 설계
        1. 6.2.1 복잡도와 이해 가능성의 관계
        2. 6.2.2 복잡성의 구분
        3. 6.2.3 보안과 신뢰성 요구사항의 중앙 집중식 책임
      3. 6.3 시스템 아키텍처 (1/4)
      4. 6.3 시스템 아키텍처 (2/4)
      5. 6.3 시스템 아키텍처 (3/4)
      6. 6.3 시스템 아키텍처 (4/4)
        1. 6.3.1 이해 가능한 인터페이스 명세
        2. 6.3.2 이해할 수 있는 신원, 인증 그리고 접근 제어
        3. 6.3.3 더 알아보기: 보안 경계
      7. 6.4 시스템 설계 (1/2)
      8. 6.4 시스템 설계 (2/2)
        1. 6.4.1 서비스 요구사항에 애플리케이션 프레임워크를 활용하기
        2. 6.4.2 복잡한 데이터 흐름의 이해
        3. 6.4.3 API 사용성에 대한 고려
      9. 6.5 마치며
    5. CHAPTER 7 범위의 변화를 위한 설계
      1. 7.1 보안과 관련된 변화의 종류
      2. 7.2 변화의 설계
      3. 7.3 보다 쉬운 변화를 위한 아키텍처 결정사항
        1. 7.3.1 디펜던시의 최신 버전을 유지하고 자주 재빌드하자
        2. 7.3.2 자동화된 테스트를 이용해 빈번하게 릴리스하자
        3. 7.3.3 컨테이너를 활용하자
        4. 7.3.4 마이크로서비스를 활용하자
      4. 7.4 변화의 종류: 서로 다른 속도, 서로 다른 일정 (1/3)
      5. 7.4 변화의 종류: 서로 다른 속도, 서로 다른 일정 (2/3)
      6. 7.4 변화의 종류: 서로 다른 속도, 서로 다른 일정 (3/3)
        1. 7.4.1 단기적 변화: 제로데이 취약점
        2. 7.4.2 중기적 변화: 보안 상태의 향상
        3. 7.4.3 장기적 변화: 외부의 수요
      7. 7.5 분란: 계획이 변경될 때
      8. 7.6 예시: 범위의 증가 - 하트블리드
      9. 7.7 마치며
    6. CHAPTER 8 회복성을 위한 설계
      1. 8.1 회복성을 위한 설계 원리
      2. 8.2 심층방어 (1/2)
      3. 8.2 심층방어 (2/2)
        1. 8.2.1 트로이 목마
        2. 8.2.2 구글 애플리케이션 엔진 분석
      4. 8.3 성능 저하의 제어 (1/2)
      5. 8.3 성능 저하의 제어 (2/2)
        1. 8.3.1 장애 비용의 구분
        2. 8.3.2 응답 메커니즘의 배포
        3. 8.3.3 자동화에는 책임이 따른다
      6. 8.4 영향 반경의 제어 (1/2)
      7. 8.4 영향 반경의 제어 (2/2)
        1. 8.4.1 역할 분리
        2. 8.4.2 위치 분리
        3. 8.4.3 시간 분리
      8. 8.5 더 알아보기: 장애 도메인과 이중화 (1/2)
      9. 8.5 더 알아보기: 장애 도메인과 이중화 (2/2)
        1. 8.5.1 장애 도메인
        2. 8.5.2 컴포넌트의 종류
        3. 8.5.3 이중화의 제어
      10. 8.6 더 알아보기: 지속적 검증 (1/2)
      11. 8.6 더 알아보기: 지속적 검증 (2/2)
        1. 8.6.1 검증 집중 분야
        2. 8.6.2 검증 사례
      12. 8.7 실용적인 조언: 어떻게 시작할 것인가
      13. 8.8 마치며
    7. CHAPTER 9 복구를 위한 설계
      1. 9.1 어떤 상태로부터 복구하는가?
        1. 9.1.1 랜덤 에러
        2. 9.1.2 실수에 의한 에러
        3. 9.1.3 소프트웨어 에러
        4. 9.1.4 악의적인 행위
      2. 9.2 복구를 위한 설계 원리 (1/6)
      3. 9.2 복구를 위한 설계 원리 (2/6)
      4. 9.2 복구를 위한 설계 원리 (3/6)
      5. 9.2 복구를 위한 설계 원리 (4/6)
      6. 9.2 복구를 위한 설계 원리 (5/6)
      7. 9.2 복구를 위한 설계 원리 (6/6)
        1. 9.2.1 최대한 빠르게 움직이기 위한 설계(정책에 의한 보호)
        2. 9.2.2 외부 시간에 대한 디펜던시의 제거
        3. 9.2.3 더 알아보기: 롤백은 보안과 신뢰성 사이의 절충이다
        4. 9.2.4 더 알아보기: 명시적 폐기 메커니즘 사용
        5. 9.2.5 의도한 시스템의 상태를 바이트 수준까지 이해하자
        6. 9.2.6 테스트와 지속적 검증을 위한 설계
      8. 9.3 긴급 접근
        1. 9.3.1 접근 제어
        2. 9.3.2 의사소통
        3. 9.3.3 대응자의 습관
      9. 9.4 예상치 못한 장점
      10. 9.5 마치며
    8. CHAPTER 10 서비스 거부 공격의 완화
      1. 10.1 공격과 방어를 위한 전략
        1. 10.1.1 공격자의 전략
        2. 10.1.2 대응자의 전략
      2. 10.2 방어를 위한 설계
        1. 10.2.1 방어적 아키텍처
        2. 10.2.2 방어형 서비스
      3. 10.3 공격의 완화
        1. 10.3.1 모니터링과 알람
        2. 10.3.2 우아한 퇴보
        3. 10.3.3 DoS 완화 시스템
        4. 10.3.4 전략적 대응
      4. 10.4 자체 유발 공격에 대응하기
        1. 10.4.1 사용자의 행위
        2. 10.4.2 클라이언트의 재시도 행위
      5. 10.5 마치며
  15. PART III 시스템의 구현
    1. CHAPTER 11 사례 연구: 공개적으로 신뢰할 수 있는 CA의 설계와 구현 그리고 유지 보수
      1. 11.1 공개적으로 신뢰할 수 있는 인증 기관에 대한 배경
      2. 11.2 는공개적으로 신뢰할 수 있는 CA가 필요했던 이유
      3. 11.3 자체 구축과 솔루션 구입 방식의 비교
      4. 11.4 설계, 구현 및 운영에 대한 고려
        1. 11.4.1 프로그래밍 언어 선택
        2. 11.4.2 복잡도와 이해 가능성의 비교
        3. 11.4.3 서드파티와 오픈 소스 컴포넌트의 보안
        4. 11.4.4 테스트
        5. 11.4.5 CA 키 머티리얼
        6. 11.4.6 데이터 검증
      5. 11.5 마치며
    2. CHAPTER 12 코드 작성
      1. 12.1 보안과 신뢰성을 강제하는 프레임워크 (1/2)
      2. 12.1 보안과 신뢰성을 강제하는 프레임워크 (2/2)
        1. 12.1.1 프레임워크를 사용할 때의 장점
        2. 12.1.2 예시: RPC 백엔드 프레임워크
      3. 12.2 보편적인 보안 취약점
        1. 12.2.1 SQL 주입 취약점: TrustedSqlString
        2. 12.2.2 XSS 방지: SafeHtml
      4. 12.3 프레임워크의 평가와 구현
        1. 12.3.1 간단하고 안전하며 신뢰할 수 있는 공통 작업 라이브러리
        2. 12.3.2 롤아웃 전략
      5. 12.4 간결함은 안전하며 신뢰할 수 있는 코드로 이어진다
        1. 12.4.1 다중 중첩의 방지
        2. 12.4.2 YAGNI 스멜의 제거
        3. 12.4.3 기술 부채의 해소
        4. 12.4.4 리팩터링
      6. 12.5 기본적인 보안과 신뢰성 (1/2)
      7. 12.5 기본적인 보안과 신뢰성 (2/2)
        1. 12.5.1 올바른 도구의 선택
        2. 12.5.2 강력한 타입의 사용
        3. 12.5.3 코드 새니타이징
      8. 12.6 마치며
    3. CHAPTER 13 코드 테스트
      1. 13.1 단위 테스트
        1. 13.1.1 효율적인 단위 테스트의 작성
        2. 13.1.2 단위 테스트의 적절한 사용 시점
        3. 13.1.3 단위 테스트가 코드에 미치는 영향
      2. 13.2 통합 테스트
        1. 13.2.1 효율적인 통합 테스트의 작성
      3. 13.3 더 알아보기: 동적 프로그램 분석
      4. 13.4 더 알아보기: 퍼즈 테스트 (1/3)
      5. 13.4 더 알아보기: 퍼즈 테스트 (2/3)
      6. 13.4 더 알아보기: 퍼즈 테스트 (3/3)
        1. 13.4.1 퍼즈 엔진의 동작 원리
        2. 13.4.2 효과적인 퍼즈 드라이버의 작성
        3. 13.4.3 퍼저 구현 예시
        4. 13.4.4 지속적 퍼징
      7. 13.5 더 알아보기: 정적 프로그램 분석 (1/3)
      8. 13.5 더 알아보기: 정적 프로그램 분석 (2/3)
      9. 13.5 더 알아보기: 정적 프로그램 분석 (3/3)
        1. 13.5.1 코드 검사 자동화 도구
        2. 13.5.2 개발자 워크플로에 정적 분석 통합하기
        3. 13.5.3 추상 해석
        4. 13.5.4 공식 메서드
      10. 13.6 마치며
    4. CHAPTER 14 코드 배포
      1. 14.1 개념과 용어
      2. 14.2 위협 모델
      3. 14.3 권장 사례
        1. 14.3.1 코드 검토를 반드시 실행하자
        2. 14.3.2 자동화를 도입하자
        3. 14.3.3 사람이 아닌 결과물을 검증하자
        4. 14.3.4 설정을 코드처럼 관리하자
      4. 14.4 위협 모델에 적용하기
      5. 14.5 더 알아보기: 고급 완화 전략 (1/3)
      6. 14.5 더 알아보기: 고급 완화 전략 (2/3)
      7. 14.5 더 알아보기: 고급 완화 전략 (3/3)
        1. 14.5.1 바이너리 출처
        2. 14.5.2 출처 기반 배포 정책
        3. 14.5.3 검증가능한 빌드
        4. 14.5.4 배포 관문
        5. 14.5.5 배포 사후 검증
      8. 14.6 현실적인 조언
        1. 14.6.1 한 번에 한 단계씩 진행하자
        2. 14.6.2 대처 가능한 에러 메시지를 제공하자
        3. 14.6.3 출처를 명확히 하자
        4. 14.6.4 정책을 명확히 정의하자
        5. 14.6.5 배포 유리 깨기 메커니즘을 포함하자
      9. 14.7 다시 한번 위협 모델에 적용하기
      10. 14.8 마치며
    5. CHAPTER 15 시스템 조사
      1. 15.1 디버깅부터 조사까지 (1/4)
      2. 15.1 디버깅부터 조사까지 (2/4)
      3. 15.1 디버깅부터 조사까지 (3/4)
      4. 15.1 디버깅부터 조사까지 (4/4)
        1. 15.1.1 예시: 임시 파일
        2. 15.1.2 디버깅 기법
        3. 15.1.3 막혔을 때 할 수 있는 것들
        4. 15.1.4 협력적 디버깅: 가르치는 방법
        5. 15.1.5 보안 조사와 디버깅의 차이
      5. 15.2 적절하고 유용한 로그의 수집 (1/2)
      6. 15.2 적절하고 유용한 로그의 수집 (2/2)
        1. 15.2.1 불변 로그를 설계하자
        2. 15.2.2 개인정보 보호에 대한 고려
        3. 15.2.3 기록할 보안 로그 결정하기
        4. 15.2.4 로깅 예산
      7. 15.3 견고하고 안전한 디버깅 접근
        1. 15.3.1 신뢰성
        2. 15.3.2 보안
      8. 15.4 마치며
  16. PART IV 시스템 유지 보수
    1. CHAPTER 16 재해 계획
      1. 16.1 ‘재해’의 정의
      2. 16.2 동적 재해 대응 전략
      3. 16.3 재해 위험 분석
      4. 16.4 사고 대응 팀의 셋업 (1/2)
      5. 16.4 사고 대응 팀의 셋업 (2/2)
        1. 16.4.1 팀원과 역할의 확인
        2. 16.4.2 팀 헌장의 준비
        3. 16.4.3 심각성와 우선순위 모델의 준비
        4. 16.4.4 IR 팀을 위한 운영 매개변수의 정의
        5. 16.4.5 대응 계획의 개발
        6. 16.4.6 상세한 교범의 작성
        7. 16.4.7 접근 및 업데이트 메커니즘의 도입
      6. 16.5 장애가 발생하기 전에 시스템과 사람에 대한 준비사항
        1. 16.5.1 시스템의 설정
        2. 16.5.2 훈련
        3. 16.5.3 과정과 절차
      7. 16.6 더 알아보기: 시스템과 대응 계획의 테스트 (1/2)
      8. 16.6 더 알아보기: 시스템과 대응 계획의 테스트 (2/2)
        1. 16.6.1 감사 자동화 시스템
        2. 16.6.2 비간섭 모의의 수행
        3. 16.6.3 프로덕션 환경에서의 대응 테스트
        4. 16.6.4 레드 팀 테스팅
        5. 16.6.5 대응의 평가
      9. 16.7 구글의 사례
        1. 16.7.1 글로벌에 영향을 미치는 테스트
        2. 16.7.2 DiRT로 긴급 접근 테스트하기
        3. 16.7.3 업계 전반의 취약점
      10. 16.8 마치며
    2. CHAPTER 17 위기 관리
      1. 17.1 위기일까 아닐까?
        1. 17.1.1 사고의 분류
        2. 17.1.2 손상과 버그의 비교
      2. 17.2 사고 조치 지휘하기 (1/2)
      3. 17.2 사고 조치 지휘하기 (2/2)
        1. 17.2.1 당황하지 말것
        2. 17.2.2 대응하기
        3. 17.2.3 사고 팀의 구성
        4. 17.2.4 더 알아보기: 운영 보안
        5. 17.2.5 제대로 된 OpSec으로 더 나은 결과 얻기
        6. 17.2.6 더 알아보기: 조사의 과정
      4. 17.3 사고 대응의 지속적 제어 (1/2)
      5. 17.3 사고 대응의 지속적 제어 (2/2)
        1. 17.3.1 사고의 병렬처리
        2. 17.3.2 교대
        3. 17.3.3 팀의 사기
      6. 17.4 의사소통
        1. 17.4.1 오해
        2. 17.4.2 얼버무리기
        3. 17.4.3 회의
        4. 17.4.4 적절한 사람에게 적정한 수준의 내용 공유하기
      7. 17.5 종합
        1. 17.5.1 분류
        2. 17.5.2 사고의 선언
        3. 17.5.3 의사소통과 운영 보안
        4. 17.5.4 사고 대응의 시작
        5. 17.5.5 업무 교대
        6. 17.5.6 업무 재교대
        7. 17.5.7 의사소통과 복구의 준비
        8. 17.5.8 사고 대응 종료
      8. 17.6 마치며
    3. CHAPTER 18 복구와 사후처리
      1. 18.1 복구 전략
      2. 18.2 복구 타임라인
      3. 18.3 복구 계획
        1. 18.3.1 복구의 범위
        2. 18.3.2 더 알아보기: 복구 시 고려사항
        3. 18.3.3 복구 체크리스트
      4. 18.4 복구 시작 (1/2)
      5. 18.4 복구 시작 (2/2)
        1. 18.4.1 자산의 격리
        2. 18.4.2 시스템 재빌드와 소프트웨어 업그레이드
        3. 18.4.3 데이터 새니타이제이션
        4. 18.4.4 데이터 복구
        5. 18.4.5 자격 증명과 기밀정보의 로테이션
      6. 18.5 복구 이후
        1. 18.5.1 포스트모템
      7. 18.6 예시
        1. 18.6.1 클라우드 인스턴스의 손상
        2. 18.6.2 대규모 피싱 공격
        3. 18.6.3 복잡한 복구가 필요한 대상 지정 공격
      8. 18.7 마치며
  17. PART V 조직과 문화
    1. CHAPTER 19 사례 연구: 크롬 보안 팀
      1. 19.1 배경과 팀의 발전
      2. 19.2 보안은 팀의 책임이다
      3. 19.3 사용자가 안전하게 웹을 탐색하도록 돕는다.
      4. 19.4 속도가 중요하다
      5. 19.5 어심층방어를 위한 설계
      6. 19.6 투명성의 유지와 커뮤니티와의 교류
      7. 19.7 마치며
    2. CHAPTER 20 역할과 책임의 이해
      1. 20.1 보안과 신뢰성에 대한 책임을 지는 사람은 누구인가? (1/2)
      2. 20.1 보안과 신뢰성에 대한 책임을 지는 사람은 누구인가? (2/2)
        1. 20.1.1 전문가의 역할
        2. 20.1.2 보안 전문성에 대한 이해
        3. 20.1.3 자격증과 학계
      3. 20.2 보안을 조직에 통합하기 (1/3)
      4. 20.2 보안을 조직에 통합하기 (2/3)
      5. 20.2 보안을 조직에 통합하기 (3/3)
        1. 20.2.1 보안 전문가와 보안 팀의 내재화
        2. 20.2.2 예시: 구글의 보안 내재화
        3. 20.2.3 스페셜 팀: 블루와 레드 팀
        4. 20.2.4 외부 연구원
      6. 20.3 마치며
    3. CHAPTER 20 보안과 신뢰성 문화 구축
      1. 21.1 건전한 보안과 신뢰성 문화의 정의 (1/3)
      2. 21.1 건전한 보안과 신뢰성 문화의 정의 (2/3)
      3. 21.1 건전한 보안과 신뢰성 문화의 정의 (3/3)
        1. 21.1.1 자연스럽게 품은 보안과 신뢰성 문화
        2. 21.1.2 검토하는 문화
        3. 21.1.3 의식의 문화
        4. 21.1.4 긍정의 문화
        5. 21.1.5 필연성의 문화
        6. 21.1.6 지속가능성의 문화
      4. 21.2 좋은 사례는 문화를 바꾼다 (1/2)
      5. 21.2 좋은 사례는 문화를 바꾼다 (2/2)
        1. 21.2.1 프로젝트의 목표와 참여자의 인센티브를 연계하자
        2. 21.2.2 위험 감소 메커니즘으로 두려움을 줄이자
        3. 21.2.3 안전망을 표준화하자
        4. 21.2.4 생산성과 유용성의 향상
        5. 21.2.5 많은 의사소통과 투명성 갖추기
        6. 21.2.6 공감대를 형성하자
      6. 21.3 경영진 설득하기 (1/2)
      7. 21.3 경영진 설득하기 (2/2)
        1. 21.3.1 의사결정 과정의 이해
        2. 21.3.2 변화를 위한 사례의 구축
        3. 21.3.3 자신의 전장을 선택하자
        4. 21.3.4 확대와 문제 해결
      8. 21.4 마치며
  18. 마치며
  19. 부록
  20. 찾아보기 (1/4)
  21. 찾아보기 (2/4)
  22. 찾아보기 (3/4)
  23. 찾아보기 (4/4)

Product information

  • Title: SRE를 위한 시스템 설계와 구축
  • Author(s): 헤더 애드킨스, 장현희, 벳시 바이어, 폴 블랭킨십, 피오트르 레반도프스키, 애나 오프레아, 애덤 스터블필드
  • Release date: January 2022
  • Publisher(s): Hanbit Media, Inc.
  • ISBN: 9791162245033