Basics / Enhance
Daily Build
- 모든 project의 건강도/안정성 -> daliy build로 check
- github action 으로 구성
배포일정/관리/리뷰
- TL이 명확히 리뷰해야 한다
- 직책자들이 서비스 domain및 team overview에 대한 care 의지를 증명 해야 한다
장애리뷰
- 관련 모든 조직원은 참여의 의무가 있다.
- TL이 적극적으로 파악하고 학습되어야 한다.
- 보고 역할자
- 발생원인보고과 후속조치에 대한 전반적 권한과 책임을 확실히 한다
- 상위 조직장에 대한 보고와 장애공유를 구분 할 순 없는가?
- 지금은 장애보고를 전제가 참석하는 느낌
- 보고를 통해서 상위 조직장이 공유 할 만한 사항을 조직장이 리뷰 해주는 것을 보고 싶다
- 중요한 부분에 대한 조직장의 의견을 정확히 하고 싶다
Team System Review
- 현재와 반대로 특이 발생 이슈를 개별 담당자들이 서술하고 공유
- AS-IS
- 각 담당자가 라운드로빈으로 리포팅
- 해당 주 온콜 담당자가 이 내용을 듣고 System 리포팅 작성
- 리뷰가 끝나고 온콜 담당자가 정리한 내용을 다시 리뷰.
- TO-Bea
- 각 담당자가 System 리포팅에 주요이슈 서술
- System 리포팅에 대해서 전체 공유
- TODO
- vitoria metric에 자연복구 되는 knwon issue alert은 제외
- 현재 확인 된 50x에러 alert는 datadog으로 신규 alert 필요한지 체크 <- 기존 datadog alert으로 대체 가능 한지
- 그 동안 alert가 오지 않았던 vitoria metric은 그대로 유지
Pull Request Process
- PR point
- 구성. 설계. 원칙. 스펙.
- 개발 check point 확인
- PR Merge Type
- 기본 merge 방식으로 PR merge 중
- sqush and merge 이용
- 개별 기록들이 master에 모두 기록 된다.
- 최근 트렌드는 s/m 를 이용
- PR Merge Role
- approve 필수 + approve 2 필수
- approve 선택 + approve 1 권고
개발 check point
- 구성 / 설계
- spec / flow
- code
- infra
Git unification of username
- git log에 제각기,,,
- 적용
- local global git username 설정
- github 계정 이름/email 설정
Deploy Release Note
Error tracking
- Sentry도 이용하면 어떨까? go client는 이용 중
- 비용측면에서 불가 from SRE 담당자
- 별도 RPS용 Cluster에 설치해서 이용 중으로 파악
- 그러면 같이 이용하면 되는 것 아닌가????
- 현재는 go client에서만 이용 중
- datadog 사용성 보다는 ES 기반의 Kibana를 적극 활용
Batch job
- web server/pod과 분리
- bulk job
- spring scheule job
- CI 기반으로 job 관리
DB monitor
- RDB / NoSQL
- 정확히 지표를 어디서 같이 볼수 있는지 rewind
project configuration unification
Spring/Server 설정 정보들
- 보안 정보가 아닌데, 왜 helm 환경변수에서 가져오는가???? <- DH 구현 방식
- infra를 통애서 phase 별 설정을 분리 했음 -> 설정을 이원화 하는 것은 큰 pain point
- springboot 같은 경우, application.yml 에 기본 설정을 정의
- spring이 제공하는 profile 방식을 대부분 기본적으로 이용 <- ex) java config vs xml
- 현재 m/s 환경이라면, spring cloud config 를 구성하는 것이 best
- 사내 vault 있음
dev phase at stage k8s??
local 개발시, Spring구동 + test build 가 동시에 안됨
- docker 구동을 해야 하기 떄문에 충돌?
- 별도의 개발팀에 자유도가 있는 k8s 개발 환경 구성이 절대 필요
Test
언어메세지 관련 Test
Sql query check
- slow query 모니터
- 배포 전, performace check 필수
- datadog 에 별도 서비스 추가 하면 모니터 가능
network timeout rule
- connection
- read
- 외부 API/MSA에 대한
- Circuit Break
- retry
- total run time?
- 외부 API/MSA의 guarantee work time은?
Circuit Breaker
- 가장 priority blocker
- m/s 환경에서 한 곳에서 controll 가능한 구성을 가져가야 안정 : ex) Gateway, external in/out m/s
Release Step
- release tag build slow
- exclude test
- prepared release build
- release image 사전 준비 가능?
- deploy 전에 미리 생성
- deploy일에는 바로 image 배포 가능
deploy opinion
- git 전략 개선 필요
- Transmission Component는 CI/CD에 적합한 서비스인가?
- 안정적 gitflow가 적합하다고 생각
- 예외적인 상황 > 많은 service Component가 있고, 담당자가 한정적이라 안정적 git정책이 필요 없었음
- docker image trigger 방식
- ci통합 -> 이건 argo cd?
- canary 필수적?
- master tag image 빌드 : iamge명을 release같은 걸로 고정. rollback 시, 특정 image를 알지 않아도 된다
- 배포 관련 mater 가 필요?
- 배포 일정 스케쥴링
- 각 배포로 인한 영향도 체크
- 외부 요인 체크
Frequent Deployment
legacy
LANG 환경 변수 설정,, OS 언어설정 변경
- test 실패 발생
- 영어 언어 설정이 필요한 이유가 영어명 test 때문 이라면, test를 조정해야 할 부분이라고 생각.
