본문으로 바로가기
Builder Shin.
Engineering
Builder Shin.

더 나은 내일을 만드는, 오늘의 기록.

THE BUILDER’S NOTE

Engineering.

01 / INSIDE THE BUILD

만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.

찾고 있던 이야기

작은 발견부터 깊이 있는 고민까지.

CATEGORIES

전체 글FrontendBackendAI & DataDevOpsEngineering Culture
카테고리DevOps
필터 초기화
DevOps

잠금 파일로 CI 의존성 설치 고정하기, 변경 전후를 비교하는 방법

로컬에서는 통과한 코드가 CI에서 다른 의존성 버전을 받으면 문제 원인이 코드인지 환경인지 구분하기 어렵다. 설치 과정도 검증의 입력으로 취급한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 07. 22.
DevOps

한 번 만든 산출물을 환경 사이에서 이동하기, 변경 전후를 비교하는 방법

같은 커밋이라도 배포할 때마다 의존성을 다시 풀면 다른 결과가 나올 수 있다. 코드 식별자와 실행 산출물 식별자를 연결해야 재현이 쉬워진다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 07. 14.
DevOps

배포 완료를 응답 확인까지 연결하기, 변경 전후를 비교하는 방법

빌드 성공과 프로세스 시작만으로 새 버전이 정상이라고 판단하기 어렵다. 실제 라우팅과 필수 기능 확인까지 이어져야 배포 결과를 설명할 수 있다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 07. 12.
DevOps

재시도에 대기와 한도를 함께 두기, 변경 전후를 비교하는 방법

실패한 요청을 즉시 다시 보내면 잠시 느려진 서비스에 더 많은 부하를 줄 수 있다. 재시도는 실패를 없애는 장치가 아니라 제한된 추가 시도다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 07. 02.
DevOps

평균 뒤에 숨은 느린 요청 보기, 변경 전후를 비교하는 방법

일부 요청이 매우 느려도 평균 응답 시간은 괜찮게 보일 수 있다. 분포의 긴 꼬리를 보려면 관측 창과 집계 방식을 함께 이해해야 한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 06. 18.
DevOps

사용자 증상에서 출발하는 서비스 지표, 변경 전후를 비교하는 방법

CPU 사용률만 보고 있으면 요청이 실패하는데도 상태가 정상처럼 보일 수 있다. 자원 지표와 사용자가 경험하는 결과를 함께 관찰해야 한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 06. 06.
1…131415…29