https://github.com/tedilabs/fastcampus-devops
https://github.com/UplusTeam1/uplus.com/wiki/Infra
https://github.com/2022UplusITgroup1/OrderService
- DevOps란 무엇일까? DevOps 엔지이니어란 무엇을 하는 직무일까?
- 해야 할 일을 명확하게 이해
- 왜 하는지 이해
- 무엇을 하고있는지 이해
- 소프트웨어의 개발과 운영의 합성어
- 단순하게 운영과 개발의 통합을 의미하는 것 만은 아님
- 데브옵스 탄생비화
- 개발팀과 운영팀의 간극을 줄이기 위한 노력
소프트웨어 개발과 일에 대한 포괄적인 철학과 방법론
데브옵스
는 어떤 요구사항을 효율적으로 만족시키기 위하여, 일을자동화
하며 변경사항 지표들을측정
하고,공유
하고, 이 모든 성공와 실패의 결과물들을 지속적으로축적
해 나아가는문화
를 만들어가는 철학 방법론, 기술
-
문화
: DevOps를 통해 하나의 문화를 만들어 나갑니다사람
: 팀, 인원, 가치, 의사소통일
: 프로세스, 방법론서비스
: 서비스의 가치, 성격자원
: H/W, S/W, 기술, 도구 ( H/W, S/W -> 기술의 성숙도 )시간
: 일정, 변경 가능성, 회복탄력성, 예측
-
자동화
: 자동화를 통해 효율성과 빠른 속도와 안정성을 지향합니다인프라 및 보안
: 클라우드, 네트워크, 접근제어, 암호화 ->IaC
언어 및 도구
: 프로그래밍 및 도구지속적 통합 / 배포
: CI/CD 파이프라인 구성 고려 ->변경에 유연한 서비스
모니터링
: 모니터링 시스템 및 장애대응
-
측정
: 지표를 측정하여 지속적으로 개선해 나갑니다 ->추측이 아닌 예측과 확신으로
- 변경사항 발생 시
항상 측정
어플리케이션 성능
, 개발속도 모니터링- 지속적으로
나가이고 있는지, 아닌지
측정 - 의사결정 시
추측 배제
- 변경사항 발생 시
-
공유
: 투명한 공유를 통해 함께 발전해 나갑니다언제든 접근 가능한 투명한
데이터- 지식의
공유
Open Mind
- 문제 발생시
함께
해결 - 일의
가속도
-
축적
: 기록을 축적하여 자산을 만들어 나갑니다효율적으로
1만 시간의 법칙 이루는 것- 루이비통 : 가장 이상적인 기술 축적
- Logos : 이야기가 논리적이고, 구조적이어야 한다
- Pathos : 감정에 호소하고, 스토리가 있어야 한다
- Ethos : 퍼스널 브랜딩, 화자
- 모르는 사람의 결정에 따라가는 경향이 있다
- 편견을 없애야 한다
- 서비스 개발과 배포를 신속하고 정확하게 만드는 것
- 서비스와 팀의 문제를 빠르고 정확하게 감지하는 것
- 장애를 최대한 빠른 시간 안에 해결하는 것
- 유연하고 신뢰할만한 아키텍처를 만드는 것
- 데이터 기반, 원활한 의사소통이 가능하게 하는 것
퍼포먼스 극대화
-> 소프트웨어 개발의 모든 과정을 코드로 자동화 하는 것
- 소스 레포지토리
- 라이브러리 관리
- CI Tool : Github Action, Travis, Circle CI
- AMI, Docker Image : packer
- Synthetic 자동화
- Testing
- 측정
- Immuatable Infrastructure
- 모니터링
- 알림
- 카오스 엔지니어링
- 로그 관리
- 데이터 분석을 위한 지표 수집
가져야만 하는 권한과 가지면 안되는 권한을 명확하게 분리하여 관리해야 함
- AWS-ID
- 계정 관리
- 모든 유저
- AWS-releng
- 릴리즈 엔지니어링
- 도구 관리
- AWS-preprod
- 프로덕션 준비
- 개발자
- 스테이징
- 부하테스트
- AWS-prod
- 프로덕션
- AWS-sec
- 보안
Access Key, Security Key를 쉽지만 강력한 보안 속에서 받을 수 있도록 CLI 도구 제공 -> 해당 요청을 깃허브에 올려서 Approve 하는 형태로 관리 ( 생성 시간, 주체, ... )
-
Bastion ?
-
젠킨스의 구성 또한 자동화 -> Immutable Infra
-
우리는 단 한개의 Request 도 놓치지 않는다.
- 계층 구조의 도커 이미지
- OS
- 커널 튜닝
- 레이어 쌓기
- 오토스케일링
- 변경 사항을 쉽게 예측
- 스케줄 인스턴스
- 스팟 인스턴스
- 세이빙 플랜
- 온콜
- DATADOG -> alert -> terraform ( 코드화 )
- slack
- okta -> 인증 관리 -> async 하게 일하자
- 접근 제어 -> slack command 자동화
- 암호화
- Hiding -> 정보에 관한 접근을 경로화
- Auditing -> 파일(정보) 접근 기록
- 코드는 배포되어도 아무 상관 없어야 한다
- locurst
- 완전히 도움되는 일
- 나중에 도움되는 일
- 천천히 도움되는 일
- 시간 버리는 것
- 의미가 없는 일
- 점점 망가져 가는 것
- 현재는 +로 보이지만 종국엔 - -> 기술 부채 -> WHY?
- 방해하는 것, 가만히 있는 것
좋은 아이디어를 얼마만큼 빠르게 구현하고, 적용할 수 있는가?
구성요소를 그린 그림은 아키텍처가 아니다!
- 고정관념을 벗기자
- 나는 생각한다, 고로 존재한다
-
포동 서비스, 애자일
-
데일리 스크럼, DSM, 스프린트 플래닝 -> 규칙과 프로세스 ( 가장 중요 x )
- 올바른 개발 문화를 갖는 것이 가장 중요함
-
포동
- 우리 동네로 오는 강아지 훈련사
- 강아지 훈련사와 견주를 매칭
-
MVP 릴리즈 후, 2주 단위로 계속 배포
- 메인 페이지가 계속 바뀜
- 허접하더라도 빠르게 프로덕드를 만들자
-
MAU 8배 성장,
재방문 3배 성장
올바른 개발 문화를 만들어가자
-
우리가 이걸 왜 개발하는지
-
이걸 누가 쓰는지
-
절차는 달콤하고 강력한 단기적 성과를 낸다
- 높은 성과에 초점을 맞춘
절차 중심형 문화
- 실수가 매우 적게 발생한다
- 효율성은 유연성을 떨어뜨린다
- 호기심 많고 개성 있는 혁신가는 거의 남아 있지 않게 된다
- 과거의 단순 반복하는 일에는 혁신가가 없어도 아무 문제 없다
- 높은 성과에 초점을 맞춘
-
그런데 과거와 달리 시장이 움직인다
- 새로운 기술과 경쟁자, 사업모델에 의해 시장이 빠르게 변화한다
- 절차 중심 문화는 이런 시장에 빠르게 발맞추기가 매우 어렵다
직원들이 이미 존재하는 절차를 따라 수행
하는 것만 매우 잘하고, 이러한 시스템에서의 가치는 절차를 잘 지키는 것이기 때문이다
-
실행 가능한 문장 ( 추상적인 워딩 x )
-
이전의 규칙과 통제 절차는 따르지 않는다
-
프로세스만 따라가는 기계적인 일은 하지 않는다
-
내가 무슨 일을 하는지 분명하게 알고 하자
-> 누가 이걸 쓰는지 고객을 알고 하자 -
아닌건 아니라고 이야기 하자. 침묵하지 말자 -> 내가 이해하지 못하는 개발 feature 라면 이야기 하자
-
맥락이 전혀 없는 문서는 핑퐁과 기싸움이 된다
- 만드는데 시간이 오래 걸리면 고객의 니즈가 변화한다
- 고객 여정 정의
- 4 ~ 5 가지의 시나리오 ( [가입] - 탐색 - 결제 - 리뷰 )
- 무엇이 중요하고, 무엇을 빠르게 개발할 수 있는지는 개발자가 정의한다
- 유저 스토리
- 고객의 입장에서 어떤 benefit이 있는지 문장으로 정의
- Low Fidelity
- 모든 의사결정자들이 모여서 Product의 아웃라인을 정의
- 바뀌는데 비용이 거의 들지 않는 수단을 사용
- High Fidelity
- 디테일 수정 ( 표현 )
- 누가 이걸 쓰는지 분명하게 알고 개발 할 수 있다
- 내가 이걸 왜 개발해야 하는지 알고 일한다
- 기획자, 디자이너, 개발자가 같은 목표를 바라본다
- 일을 하는 의미를 내가 분명하게 알 수 있다
- 꼭 필요한 일이 아니라면
메일을 사용하지 않는다
( 너무 느리다 ) - 서로의 응답을 기다리느라
해야할 일이 지체되는 일이 없도록 하자
- 보는 즉시 응답을 하자
- 모든 자료는 모두가 언제나 볼 수 있도록
컨플런스에 공유
한다- 공개를 기본으로 한다
- 살이있는 문서로 만든다
주인의식을 갖을 수 있는 유일한 필요충분조건은 스스로 결정하게 하는 것
- 개발자의 디자인(아키텍처) 결정은 팀장이나 담당이
오버라이드 할 수 없다
- 돌이킬 수 없는 결정만 리더가 한다. 그 외에는 개발자가 스스로 결정한다
- 제품 릴리즈 플랜은
개발자가 최종 수립
한다 - 실행한 사람이 책임지지 않는다.
결정한 사람이 책임진다
- 실수하고 실패해도 괜찮다. 그러나
성장이 없는 것은 안된다
- 반대의견을 주장할 때는
대안을 가지고 이야기하자
- 상황이 조금 불편해 질 것 같아도
솔직하게 이야기하자
- 능동적으로 묻고
맥락을 충분히 전달
하는 설명을 하자 - 동료에 대해 이야기 할 때 동료 앞에서 이야기 할 수 있는 것만 이야기 하자
- 앞과 뒤가 다른 사람이 되지 말자
- 말과 행동이 다른 사람이 되지 말자
- 내 옆에 좋은 동료가 있길 원한다면 내가 먼저 좋은 동료가 되자
- 우리의 가치와 부합하지 않는 행동에 대해
이의를 제기하자
배를 만들고 싶다면, 사람을 시켜 나무를 모으고 역할을 나누고 명령을 내리면서 북을 칠것이 아니라 거대하고 끝없는 바다를 갈망하게 만들어라
- 통제보다는 맥락과 동기
- 실행 가능한 명확한 규칙
- 프로그래밍적 사고를 갖고 무언가를 하는 것은 중요
- Python, Go
- Process
- Thread
- Socket
- TCP/IP
- OSI 7 Layer
- 디스크 사용량 모니터링
- shell
- initd
- systemd
- http
- https, ssl
- ftp, sftp
- ubuntu
- cent os
- 보안
- Reverse proxy
- Caching server
- Load balancer
- Nginx
- Tomcat
- Istio
- envoy
- consul
- Terraform
- Public cloud
- 컨테이너에 대한 이해
- 왜 컨테이너를 사용하는지
- 왜 컨테이너가 Hot 해졌는지
- Immuatable Infrastructur
- K8s
- Ansible
- 도구는 상관 없음
- 뭘 써도 능숙하게 쓸 줄 알아야 한다
- 각 솔루션의 사상에 대해 이해하는 것이 중요
- ELK
- Graylog
- Splunk
- Papertrail
- prometheus
- grafana
- datadog
- pinpoint
- AWS
- GCP
- Azur
- 가용성 유지 전략
- 디자인
- 구현
- 얼마만큼 빠르게
- 데이터 매니지먼트