소프트웨어 신뢰성 선언문

회사에서 Service Trust 라는 이름의 프로젝트를 진행한다.

거기에 나도 같이 참여하여 서비스의 신뢰성을 높이게 되었다.

---

기준을 어떻게 가져갈까 하다가 딜리버리 히어로의 신뢰성 선언문을 보았다.

 

인상적인 내용 몇 개만 정리해본다.

내용 중 핵심에 진하게 표시하여 나타냈다.

아키텍처 및 기술 부채

A-1 아키텍처를 문서화합니다. 모든 서비스와 해당 종속성은 아키텍처 가이드라인에 설명된 규칙에 따라 아키텍처 차트에 문서화되어야 합니다.

A-2 우리는 이름 지정에 신경을 씁니다. 모든 서비스에는 명확하고 이해하기 쉬운 이름이 있어야 합니다. 

A-3 모놀리스로 시작합니다. 모놀리스 첫 번째 패턴을 따르면 빠르게 움직일 수 있으며 나중에 요구 사항에 대한 더 나은 지식을 갖게 되면 하위 서비스로 나눌 수 있습니다. 

A-4 우리는 마이크로서비스 원칙을 수용합니다 . 새로운 서비스는 다음을 충족해야 합니다.

• API나 메시지를 통해서만 통신하세요.
• 다른 서비스와 데이터 저장 공간을 공유하지 마세요.
• 기술적 구성 요소가 아닌 제품 도메인(제한된 컨텍스트)의 일부가 되어야 합니다. 
• 단일 책임 원칙을 따르고 한 가지 일을 잘 수행하십시오.
• 단 하나의 분대만이 소유할 수 있습니다. 
• 2개 서비스보다 깊은 동기식 호출 체인을 피하세요. 
• 데이터와 도구를 사용하여 서비스의 상태와 동작을 관찰하여 사고로부터 복원하는 데 걸리는 시간을 최소화합니다.
• 오버헤드를 정당화할 수 있을 만큼 충분한 크기를 갖습니다(나노 서비스 없음).
• 데이터 일관성 보장(예: 최소 1회 메시지 전달)을 전달합니다.

A-5 우리는 Data mess를 수용합니다. 데이터 생산자는 자신의 도메인 데이터를 공통 데이터 플랫폼(Datahub)에 제품으로 게시할 책임이 있으며 다음 사항을 보장합니다.

1. 검색 가능.
2. 주소 지정 가능.
3. 신뢰할 수 있고 진실합니다.
4. 자기 설명적 의미와 구문.
5. 상호 운용 가능하며 글로벌 표준에 따라 관리됩니다.
6. 글로벌 액세스 제어로 안전하고 관리됩니다.

A-6 아키텍처 검토: 새로운 서비스는 부족 및 수직 기술 리더와의 기술 설계 검토 회의를 통과해야 합니다. 부족의 기술 리더는 2년에 한 번씩 전체 아키텍처를 동료에게 발표합니다. 두 회의 모두 관심 있는 누구에게나 열려 있습니다. 

A-7 우리는 부채를 알고 있습니다 . 분기별로 기술 부채에 동의하고 추적합니다.

A-9 우리는 중요한 사항을 최소화합니다. 우리는 서비스가 주문 이행을 위한 중요한 경로의 일부가 되는 것을 피합니다. 중요하지 않은 범위를 다른 곳으로 이동하여 중요한 서비스를 간결하게 유지합니다.

A-10 우리는 결정을 문서화합니다. 우리는 RFC 및 아키텍처 결정 기록을 사용하여 중요한 아키텍처 결정을 그 맥락 및 결과와 함께 조정하고 문서화합니다.

A-11 우리는 잘 정의된 API를 좋아합니다. 우리는 다른 팀에 공개된 모든 API를 문서화하고 API 라이브러리에 문서를 게시합니다.

배달

D-1 매일 배포합니다 . 우리의 목표는 근무일 기준으로 엔지니어당 최소 한 번의 프로덕션 배포를 수행하는 것입니다.

D-2 배포 추적 : 모든 배포는 배포 이벤트를 통해 추적되어야 합니다.

D-3 연중무휴 24시간 운영: 모든 서비스는 가동 중지 시간 없는 배포를 지원해야 합니다. 피크 시간대와 금요일 에는 배포가 안전합니다.

D-4 안전망을 사용하여 배포 : 모든 Tier 1 서비스는 자동화된 카나리아 배포를 지원해야 합니다.

D-5 우리의 인프라는 코드입니다 . 모든 인프라는 코드와 저장소에 구성되어야 합니다. 모든 인프라 변경 사항은 CI/CD 파이프라인을 통해 실행됩니다.

D-6 우리는 테스트를 자동화합니다 . 우리는 프로덕션 코드가 단위 테스트를 통해 60-80%의 코드 적용 범위를 가질 것으로 기대합니다. 또한 주요 애플리케이션 흐름은 통합 테스트를 통해 다루어져야 합니다.

D-7 우리는 절대 혼자 코딩하지 않습니다 . 새롭고 복잡한 코드의 경우 쌍 프로그래밍을 사용합니다. 모든 프로덕션 코드 변경 사항은 코드 검토를 거칩니다.

우리는 실패를 고려합니다.

실패 처리 전략

- Timeout: Beyond a certain wait interval, a successful result is unlikely or simply too late.
- Retry: Many faults are transient and may self-correct after a short delay – use exponential backoff and jitter to avoid cascading failures.
- Circuit Breaker: When a system is seriously struggling, failing fast is better than making clients wait to avoid running out of critical resources.
- Fallback: Things will still fail – plan what you will do when that happens.
- Throttling: Prevent misbehaving clients bringing your service down.
We prepare for rapid growth with ongoing load-tests:ts bringing your service down.
- Idempotence: Multiple identical requests made to a service apply only once.
- Recoverable: Your service has a process to replay messages to recover from an outage of a downstream service.
- Dead-letter queues: Erroneous messages do not stop a service processing valid messages and are published to a dead-letter queue for later analysis.

https://tech.deliveryhero.com/our-reliability-manifesto/

https://tech.deliveryhero.com/our-reliability-manifesto/