From 20122a1e72daa21f30b47ca051cd726c637db3ac Mon Sep 17 00:00:00 2001
From: hhhyunwoo <qgusdngusdn@gmail.com>
Date: Wed, 30 Aug 2023 15:50:06 +0900
Subject: [PATCH] Add new post

---
 _posts/2023-08-27-sre-ch17.md | 80 +++++++++++++++++++++++++++++++++++
 _posts/2023-08-30-sre-ch18.md | 70 ++++++++++++++++++++++++++++++
 2 files changed, 150 insertions(+)
 create mode 100644 _posts/2023-08-27-sre-ch17.md
 create mode 100644 _posts/2023-08-30-sre-ch18.md

diff --git a/_posts/2023-08-27-sre-ch17.md b/_posts/2023-08-27-sre-ch17.md
new file mode 100644
index 00000000..51062628
--- /dev/null
+++ b/_posts/2023-08-27-sre-ch17.md
@@ -0,0 +1,80 @@
+---
+layout: post
+title: "[SRE] Ch17. Testing for Reliability"
+date: 2023-08-27
+categories:
+  - Study
+  - Book
+  - SRE
+tags: [
+    sre,
+    google,
+    devops,
+    study,
+    book,
+    reliable,
+  ]
+---
+
+**결론 : 테스트는 엔지니어들이 자신의 제품의 신뢰성을 향상시킬 수 있는 가장 적절한 투자 수단이다.**
+
+- 테스트의 종류는 굉장히 여러가지가 있는데, 신뢰성을 올리기 위해서 대략적으로 테스트의 종류와 중요도에 대해서 설명하고 있다.
+- 테스트는 어떤 변경 사항이 일어났을 때 특정 부분에서 동일한 결과를 기대할 수 있다는 것을 보여주기 위한 메커니즘이다.
+
+# 소프트웨어 테스트의 종류
+
+## 전통적인 테스트
+
+- 소프트웨어를 개발하는 동안 소프트웨어가 올바른 동작을 수행하는지 여부를 평가하는 `테스트`
+
+### Unit Test
+
+- 클래스나 함수 등을 테스트하여 각 동작을 독립적으로 테스트하는 방법
+- 주로 `TDD` 방법론과 함께 사용됨
+- **dependency 가 있을 때는 어떻게?**
+    - *→ Dependency Injection 사용. Dagger 와 같은 툴을 사용해서 Mock 객체를 생성하여 수행*
+
+### Integration Test
+
+- 단위 테스트를 통과한 소프트웨어 컴포넌트는 그보다 더 큰 규모의 컴포넌트에 편입되는데, 이떄 수행하는 테스트가 `통합 테스트`임
+
+### System Test
+
+- 아직 배포가 완료되지 않은 시스템에 대해 엔지니어가 수행할 수 있는 가장 큰 규모의 테스트.
+- **Smoke Test**
+    - *전자 회로 기판에 전원을 넣었을 때 기판에서 연기가 나는지 확인하는 테스트에서 유래됨.* 즉, 안정성을 유지하기 위해서 주요 기능들이 제대로 작동하는지 확인
+    - 안정성 검사 (Sanity Test) 로 알려져 있으며, 약간의 장애 상황을 가정한 테스트를 포함해서 더 많은 부분을 테스트 함
+- **Performance Test**
+    - 성능 테스트
+- **Regression Test**
+    - 이미 알려진 버그들을 통해 시스템의 실패나 잘못된 결과가 나타나는 것을 유추하는 테스트.
+
+## 프로덕션 테스트
+
+- 실제 동작하는 웹 서비스에 대해 배포된 소프트웨어 시스템이 올바르게 동작 중인지를 판단하는 테스트
+- **Black Box 테스트**라고도 부름
+
+### 설정 테스트
+
+- 실제 프로덕션 환경에서 동작하는 특정 바이너리가 실제로 어떻게 설정되어 있는지를 확인하고 해당 설정 파일과 일치하지 않는 부분을 찾아 보고 함
+
+### 스트레스 테스트
+
+- 시스템을 구성하는 컴포넌트들의 한계를 이해하기 위함.
+- 예시
+    - DB 용량이 어느 정도에 다다르면 쓰기 작업에 실패하는가?
+    - 서버는 초당 몇 개의 쿼리까지 응답할 수 있는가?
+
+### 카나리 테스트
+
+- 서버의 일부만을 새로운 버전의 바이너리나 설정 파일로 업그레이드한 후, 일정 기간 동안 살펴보는 형태로 진행
+
+# 테스트 및 빌드 환경 구성하기
+
+- **일반적으로 초기 설계 부터 테스트 커버리지 100프로를 달성하면서 프로젝트를 수행하는 경우 (TDD) 는 잘 없음.**
+- 뿐만 아니라 SRE 엔지니어들은 대부분 프로젝트가 한창 진행 중일 때 합류하기 때문에, 어느 부분부터 테스트를 시작해야하는지 판단하는 부분이 중요함
+- **고려해야할 점들**
+    - 어떤 형태로든 중요도를 측정해서 컴포넌트들의 우선순위를 결정해야함
+    - 사활이 걸려있거나, 비지니스 관점에서 중요한 기능이나 클래스를 특정할 수 있는지?
+    - 다른 팀들이 통합해서 사용하는 API들이 있는지?
+- → **가장 강력한 테스트 문화 수립 방법은 지금까지 보고된 모든 버그를 테스트 케이스의 형태로 문서화하고,** `regression Test` **에 포함시켜야함**
\ No newline at end of file
diff --git a/_posts/2023-08-30-sre-ch18.md b/_posts/2023-08-30-sre-ch18.md
new file mode 100644
index 00000000..2c76b5e0
--- /dev/null
+++ b/_posts/2023-08-30-sre-ch18.md
@@ -0,0 +1,70 @@
+---
+layout: post
+title: "[SRE] Ch18. Software Engineering in SRE"
+date: 2023-08-30
+categories:
+  - Study
+  - Book
+  - SRE
+tags: [
+    sre,
+    google,
+    devops,
+    study,
+    book,
+    reliable,
+  ]
+---
+
+**결론 : SRE 는 단순 Operation 을 하는 포지션이 아니라 Software Engineering 에 많은 부분 기여를 하고 있으며, 이러한 역량과 작업은 매우 중요하다. 구글에서는 어떤식으로 SRE 의 Software Engineering 이 이루어지고 있는지 엿볼 수 있는 장**
+
+# SRE 조직의 소프트웨어 엔지니어링 역량이 중요한 이유
+
+- **다른 회사들과 비교하여도 구글처럼 크고 복잡한 프로덕션 환경을 가지고 있는 회사는 없을 것이다. 이 때문에 구글에서는 다양한 형태의 소프트웨어 개발이 내부적으로 이루어질 수 밖에 없음.**
+- 구글이 필요로 하는 규모를 감당하는 서드파티 도구가 거의 없기 때문
+- 그렇다면 구글의 SRE 조직이 내부 소프트웨어를 개발할 수 있는 조직이 된 이유는 무엇일까?
+    - **구글만의 프로덕션 환경에 대한 SRE 조직의 폭넓고 깊은 지식을 활용하여 소프트웨어를 디자인하고 개발 가능**
+    - **SRE 들은 중요한 사안에는 모두 참여하므로 전체적인 큰 그림과 요구사항들을 쉽게 이해**
+    - **개발하는 도구를 직접 사용할 사용자들과의 관계가 직접적이기 때문에 빠른 피드백 적용 가능**
+
+# Auxon 사례 연구 : 프로젝트 배경 및 문제가 발생한 부분
+
+- Auxon 은 프로덕션 환경에서 실행되는 서비스의 `Capacity` 계획을 자동화하기 위해 만든 툴이다.
+- **전통적인 수용량 계획이 존재하긴 하지만,** 예측이 변경되고 배포가 지연되고 예산이 줄어드는 등 아주 다양한 변수가 발생하고 정확한 정답이 없는 문제임.
+- **이는 노동집약적이고 모호하며, 본질적으로 불안정함.**
+
+## 구글의 해결책 : 의도 기반 수용량 계획
+
+- 구현이 아닌 요구사항을 명확히 하자.
+- 의도(intent)란 서비스 담당자가 자신들의 서비스를 운영하고자 하는 의도를 의미함.
+- 실제 수용량 계획 의도를 이끌어내기 위해서는 현실적인 자원 수요를 바탕으로 한 타당한 이유를 만들어내기 위해서는 여러 단계의 추상화가 필요함.
+    1. Foo 서비스를 위해 X, Y 그리고 Z 클러스터에 50개의 코어가 필요합니다.
+        1. → 왜?
+    2. Foo 서비스를 위해 YYY 지역의 클러스터 중 세 개에서 50개의 코어가 필요합니다
+        1. → 덜 구체적이긴 하지만 왜?
+    3. Foo 서비스에 대한 각 지역별 수요를 충당하기를 원하며 N+2 의 다중화를 원합니다.
+        1. → 자유도가 훨씬 높아짐. 인간이 이해하기 쉬워짐. 하지만 왜 ?
+    4. Foo 서비스에 99.999% 가용성을 지원하고 싶습니다
+        1. → 매우 추상화된 요구사항. 훨씬 유연함.
+- **→ 3단계의 추상화를 제공할 떄 가장 좋은 성과를 내고, 아주 정교한 서비스는 4단계가 더 어울릴 수 있다.**
+
+## 의도를 파악하기 위한 선행 작업
+
+- 의존성
+- 성능지표
+- 우선순위 결정
+
+## Auxon 소개
+
+<img width="742" alt="image" src="https://github.com/hhhyunwoo/leetcode/assets/37402136/b81c0605-a22f-458f-a6e6-15831defb1b0">
+
+
+- Auxon 은 사용자의 설정 언어 혹은 프로그래밍 API 를 통해 수집한 후, 사람의 의도를 기계가 이해할 수 있는 제약으로 변환함
+- **성능 데이터** : 서비스의 규모를 의미
+- **서비스별 수요 예측 데이터** : 예측된 수요 신호의 사용 궤적을 의미
+- **자원 공급** : 기본적인 자원에 대한 기초 수준의 가용성에 대한 데이터
+- **자원 가격** : 기본적인 자원을 기초적인 수준으로 확보하기 위한 비용에 대한 데이터
+- **의도 설정** : 의도 기반 정보를 Auxon 에 전달하기 위한 핵심
+- **Auxon 설정 언어 엔진** : 의도 설정으로부터 전달받은 정보를 바탕으로 동작
+- **Auxon 해법 엔진** : 이 도구의 뇌에 해당하며 설정 언어 엔진에게서 수신한 최적화된 요청을 바탕으로 거대한 혼합 정수 혹은 선형 프로그램을 공식화함
+- **할당 계획** : Auxon 해법 엔진의 출력 결과
\ No newline at end of file