Skip to content

Instantly share code, notes, and snippets.

@Bogyie
Last active March 7, 2024 05:39
Show Gist options
  • Save Bogyie/df8662e7c19f3a2feb22f068ed359ec1 to your computer and use it in GitHub Desktop.
Save Bogyie/df8662e7c19f3a2feb22f068ed359ec1 to your computer and use it in GitHub Desktop.

https://github.com/tedilabs/fastcampus-devops

https://github.com/UplusTeam1/uplus.com/wiki/Infra

https://github.com/2022UplusITgroup1/OrderService

Public Cloud 에 대한 이해

CI/CD 구축에 대한 관심

새로운 기술에 대한 호기심과 관심

K8s에 대한 관심

  • DevOps란 무엇일까? DevOps 엔지이니어란 무엇을 하는 직무일까?
    • 해야 할 일을 명확하게 이해
    • 왜 하는지 이해
    • 무엇을 하고있는지 이해

DevOps

  • 소프트웨어의 개발과 운영의 합성어
  • 단순하게 운영과 개발의 통합을 의미하는 것 만은 아님
  • 데브옵스 탄생비화
    • 개발팀과 운영팀의 간극을 줄이기 위한 노력
    • 소프트웨어 개발과 일에 대한 포괄적인 철학과 방법론

데브옵스는 어떤 요구사항을 효율적으로 만족시키기 위하여, 일을 자동화하며 변경사항 지표들을 측정하고, 공유하고, 이 모든 성공와 실패의 결과물들을 지속적으로 축적해 나아가는 문화를 만들어가는 철학 방법론, 기술

DevOps의 5가지 철학

  • 문화 : DevOps를 통해 하나의 문화를 만들어 나갑니다

    • 사람 : 팀, 인원, 가치, 의사소통
    • : 프로세스, 방법론
    • 서비스 : 서비스의 가치, 성격
    • 자원 : H/W, S/W, 기술, 도구 ( H/W, S/W -> 기술의 성숙도 )
    • 시간 : 일정, 변경 가능성, 회복탄력성, 예측
  • 자동화 : 자동화를 통해 효율성과 빠른 속도와 안정성을 지향합니다

    • 인프라 및 보안 : 클라우드, 네트워크, 접근제어, 암호화 -> IaC
    • 언어 및 도구 : 프로그래밍 및 도구
    • 지속적 통합 / 배포 : CI/CD 파이프라인 구성 고려 -> 변경에 유연한 서비스
    • 모니터링 : 모니터링 시스템 및 장애대응
  • 측정 : 지표를 측정하여 지속적으로 개선해 나갑니다 -> 추측이 아닌 예측과 확신으로

    • 변경사항 발생 시 항상 측정
    • 어플리케이션 성능, 개발속도 모니터링
    • 지속적으로 나가이고 있는지, 아닌지 측정
    • 의사결정 시 추측 배제
  • 공유 : 투명한 공유를 통해 함께 발전해 나갑니다

    • 언제든 접근 가능한 투명한 데이터
    • 지식의 공유 Open Mind
    • 문제 발생시 함께 해결
    • 일의 가속도
  • 축적 : 기록을 축적하여 자산을 만들어 나갑니다

    • 효율적으로 1만 시간의 법칙 이루는 것
      • 루이비통 : 가장 이상적인 기술 축적

설득의 3요소

  • Logos : 이야기가 논리적이고, 구조적이어야 한다
  • Pathos : 감정에 호소하고, 스토리가 있어야 한다
  • Ethos : 퍼스널 브랜딩, 화자

더닝크루거 효과 (인지편향)

  • 모르는 사람의 결정에 따라가는 경향이 있다
  • 편견을 없애야 한다

DevOps가 하는 일

  • 서비스 개발과 배포를 신속하고 정확하게 만드는 것
  • 서비스와 팀의 문제를 빠르고 정확하게 감지하는 것
  • 장애를 최대한 빠른 시간 안에 해결하는 것
  • 유연하고 신뢰할만한 아키텍처를 만드는 것
  • 데이터 기반, 원활한 의사소통이 가능하게 하는 것

퍼포먼스 극대화

데브옵스가 현실에서 정말 동작하나요?

-> 소프트웨어 개발의 모든 과정을 코드로 자동화 하는 것

  • 소스 레포지토리
  • 라이브러리 관리
  • CI Tool : Github Action, Travis, Circle CI
  • AMI, Docker Image : packer
  • Synthetic 자동화
  • Testing
  • 측정
  • Immuatable Infrastructure
  • 모니터링
  • 알림
  • 카오스 엔지니어링
  • 로그 관리
  • 데이터 분석을 위한 지표 수집

AWS Account 를 어떻게 다룰것인가?

가져야만 하는 권한과 가지면 안되는 권한을 명확하게 분리하여 관리해야 함

  • AWS-ID
    • 계정 관리
    • 모든 유저
  • AWS-releng
    • 릴리즈 엔지니어링
    • 도구 관리
  • AWS-preprod
    • 프로덕션 준비
    • 개발자
    • 스테이징
    • 부하테스트
  • AWS-prod
    • 프로덕션
  • AWS-sec
    • 보안

Access Key, Security Key를 쉽지만 강력한 보안 속에서 받을 수 있도록 CLI 도구 제공 -> 해당 요청을 깃허브에 올려서 Approve 하는 형태로 관리 ( 생성 시간, 주체, ... )

  • Bastion ?

  • 젠킨스의 구성 또한 자동화 -> Immutable Infra

  • 우리는 단 한개의 Request 도 놓치지 않는다.

EKS, K8s

  • 계층 구조의 도커 이미지
    • OS
    • 커널 튜닝
    • 레이어 쌓기

비용 절감

  • 오토스케일링
  • 변경 사항을 쉽게 예측
  • 스케줄 인스턴스
  • 스팟 인스턴스
  • 세이빙 플랜

24 x 7 Operation

  • 온콜
  • DATADOG -> alert -> terraform ( 코드화 )
  • slack
  • okta -> 인증 관리 -> async 하게 일하자

보안

  • 접근 제어 -> slack command 자동화
  • 암호화
  • Hiding -> 정보에 관한 접근을 경로화
  • Auditing -> 파일(정보) 접근 기록

IAM / Secreats Manager / KMS

  • 코드는 배포되어도 아무 상관 없어야 한다

ETC

  • locurst

일의 8가지 구분

  • 완전히 도움되는 일
  • 나중에 도움되는 일
  • 천천히 도움되는 일
  • 시간 버리는 것
  • 의미가 없는 일
  • 점점 망가져 가는 것
  • 현재는 +로 보이지만 종국엔 - -> 기술 부채 -> WHY?
  • 방해하는 것, 가만히 있는 것

아키텍처란?

좋은 아이디어를 얼마만큼 빠르게 구현하고, 적용할 수 있는가?

  • 구성요소를 그린 그림은 아키텍처가 아니다!

문화 -> 엘무원 타도

  • 고정관념을 벗기자
  • 나는 생각한다, 고로 존재한다
  • 포동 서비스, 애자일

  • 데일리 스크럼, DSM, 스프린트 플래닝 -> 규칙과 프로세스 ( 가장 중요 x )

    • 올바른 개발 문화를 갖는 것이 가장 중요함
  • 포동

    • 우리 동네로 오는 강아지 훈련사
    • 강아지 훈련사와 견주를 매칭
  • MVP 릴리즈 후, 2주 단위로 계속 배포

    • 메인 페이지가 계속 바뀜
    • 허접하더라도 빠르게 프로덕드를 만들자
  • MAU 8배 성장, 재방문 3배 성장

규칙과 프로세스 -> 문화

올바른 개발 문화를 만들어가자

통제보다는 맥락 - 1

  • 우리가 이걸 왜 개발하는지

  • 이걸 누가 쓰는지

  • 절차는 달콤하고 강력한 단기적 성과를 낸다

    • 높은 성과에 초점을 맞춘 절차 중심형 문화
    • 실수가 매우 적게 발생한다
    • 효율성은 유연성을 떨어뜨린다
    • 호기심 많고 개성 있는 혁신가는 거의 남아 있지 않게 된다
    • 과거의 단순 반복하는 일에는 혁신가가 없어도 아무 문제 없다
  • 그런데 과거와 달리 시장이 움직인다

    • 새로운 기술과 경쟁자, 사업모델에 의해 시장이 빠르게 변화한다
    • 절차 중심 문화는 이런 시장에 빠르게 발맞추기가 매우 어렵다
      • 직원들이 이미 존재하는 절차를 따라 수행하는 것만 매우 잘하고, 이러한 시스템에서의 가치는 절차를 잘 지키는 것이기 때문이다

우리의 원칙 - 1

  • 실행 가능한 문장 ( 추상적인 워딩 x )

  • 이전의 규칙과 통제 절차는 따르지 않는다

  • 프로세스만 따라가는 기계적인 일은 하지 않는다

  • 내가 무슨 일을 하는지 분명하게 알고 하자 -> 누가 이걸 쓰는지 고객을 알고 하자

  • 아닌건 아니라고 이야기 하자. 침묵하지 말자 -> 내가 이해하지 못하는 개발 feature 라면 이야기 하자

  • 맥락이 전혀 없는 문서는 핑퐁과 기싸움이 된다

    • 만드는데 시간이 오래 걸리면 고객의 니즈가 변화한다

통제 보다는 맥락 - 2

  • 고객 여정 정의
    • 4 ~ 5 가지의 시나리오 ( [가입] - 탐색 - 결제 - 리뷰 )
    • 무엇이 중요하고, 무엇을 빠르게 개발할 수 있는지는 개발자가 정의한다
  • 유저 스토리
    • 고객의 입장에서 어떤 benefit이 있는지 문장으로 정의
  • Low Fidelity
    • 모든 의사결정자들이 모여서 Product의 아웃라인을 정의
    • 바뀌는데 비용이 거의 들지 않는 수단을 사용
  • High Fidelity
    • 디테일 수정 ( 표현 )

이렇게 하면 좋은 점

  • 누가 이걸 쓰는지 분명하게 알고 개발 할 수 있다
  • 내가 이걸 왜 개발해야 하는지 알고 일한다
  • 기획자, 디자이너, 개발자가 같은 목표를 바라본다
  • 일을 하는 의미를 내가 분명하게 알 수 있다

우리의 원칙 - 2

  • 꼭 필요한 일이 아니라면 메일을 사용하지 않는다 ( 너무 느리다 )
  • 서로의 응답을 기다리느라 해야할 일이 지체되는 일이 없도록 하자
    • 보는 즉시 응답을 하자
  • 모든 자료는 모두가 언제나 볼 수 있도록 컨플런스에 공유한다
    • 공개를 기본으로 한다
    • 살이있는 문서로 만든다

우리의 원칙 - 3 (우리의 의사 결정 의식)

주인의식을 갖을 수 있는 유일한 필요충분조건은 스스로 결정하게 하는 것

  • 개발자의 디자인(아키텍처) 결정은 팀장이나 담당이 오버라이드 할 수 없다
  • 돌이킬 수 없는 결정만 리더가 한다. 그 외에는 개발자가 스스로 결정한다
  • 제품 릴리즈 플랜은 개발자가 최종 수립한다
  • 실행한 사람이 책임지지 않는다. 결정한 사람이 책임진다
  • 실수하고 실패해도 괜찮다. 그러나 성장이 없는 것은 안된다

우리의 원칙 - 4 (우리의 커뮤니케이션 원칙)

  • 반대의견을 주장할 때는 대안을 가지고 이야기하자
  • 상황이 조금 불편해 질 것 같아도 솔직하게 이야기하자
  • 능동적으로 묻고 맥락을 충분히 전달하는 설명을 하자
  • 동료에 대해 이야기 할 때 동료 앞에서 이야기 할 수 있는 것만 이야기 하자
    • 앞과 뒤가 다른 사람이 되지 말자
    • 말과 행동이 다른 사람이 되지 말자
    • 내 옆에 좋은 동료가 있길 원한다면 내가 먼저 좋은 동료가 되자
  • 우리의 가치와 부합하지 않는 행동에 대해 이의를 제기하자

배를 만들고 싶다면, 사람을 시켜 나무를 모으고 역할을 나누고 명령을 내리면서 북을 칠것이 아니라 거대하고 끝없는 바다를 갈망하게 만들어라

요약

  • 통제보다는 맥락과 동기
  • 실행 가능한 명확한 규칙

프로그래밍 언어

  • 프로그래밍적 사고를 갖고 무언가를 하는 것은 중요
  • Python, Go

OS의 컨샙

  • Process
  • Thread
  • Socket
  • TCP/IP
  • OSI 7 Layer
  • 디스크 사용량 모니터링
  • shell
  • initd
  • systemd

서버를 관리하는 기술들

  • http
  • https, ssl
  • ftp, sftp

OS

  • ubuntu
  • cent os

Security

  • 보안

Infra Tools

  • Reverse proxy
  • Caching server
  • Load balancer
  • Nginx
  • Tomcat
  • Istio
  • envoy
  • consul

IaC

  • Terraform
  • Public cloud

Container

  • 컨테이너에 대한 이해
  • 왜 컨테이너를 사용하는지
  • 왜 컨테이너가 Hot 해졌는지
  • Immuatable Infrastructur

오케스트레이션

  • K8s

Configuration Management

  • Ansible

CI / CD

  • 도구는 상관 없음
  • 뭘 써도 능숙하게 쓸 줄 알아야 한다
  • 각 솔루션의 사상에 대해 이해하는 것이 중요

모니터링

  • ELK
  • Graylog
  • Splunk
  • Papertrail
  • prometheus
  • grafana
  • datadog

APM

  • pinpoint

Cloud provider

  • AWS
  • GCP
  • Azur

Cloud design pattern

  • 가용성 유지 전략
  • 디자인
  • 구현
  • 얼마만큼 빠르게
  • 데이터 매니지먼트

리눅스 명령어 top 10

SSH

ifconfig, curl, ifconfig.co

curl

nslookup

telnet, ping

ps

top, sar, free, df

systemd

chmod, chown

일반

자기소개

Frontend 나 Backend 같은 대중적인 직군이 아닌 DevOps에 지원한 이유가 무엇인가?

다양한 DevOps 직무 중 현재 관심을 두고 있는 직무가 무엇인가?

평소 사용하는 IDE 는 무엇이 있는가?

프로젝트 관련

프로젝트에서 팀장 역할을 했을 때 뒤처지는 팀원이 있다면 어떻게 해결했는가?

팀 프로젝트를 하면서 겪었던 어려움과 그 문제를 해결한 방법은 무엇인가?

팀 프로젝트를 하면서 문서화를 어떻게 했으며, 의사소통은 어떻게 했는가? 오프라인으로만 진행했는가?

백엔드나 DevOps와 관련이 없는 Vue.Js 프로젝트를 한 이유가 무엇인가?

Vue.Js 프로젝트는 본인이 직접 팀을 꾸려서 한 것인가?

Armeria 라는 오픈소스를 어떻게 알게 되었고, 그 오픈소스에 기여한 이유가 무엇인가?

7일간 인프라를 구축했다고 적혀있는데, 처음부터 기획하고 한 것인가? 아니면 프로젝트 과정에서 자연스럽게 하게 된 것인가?

쿠버네티스를 사용하고 싶었던 이유가 무엇인가?

CS 관련

사용해본 리눅스 명령어를 나열해보라

SSH의 원리와 접속 과정을 설명해보라

RSA의 원리를 설명해보라

HTTP와 HTTPS 프로토콜의 차이를 설명해보라

IaC를 사용해 프로젝트를 구성해 보았는가?

DNS 이후 사용자의 요청이 어떻게 처리되는지 그 과정을 아는대로 설명해보라

Java와 Python의 차이가 무엇이라고 생각하는가?

도커와 VM의 차이에 대해서 설명해보라

c_group 에 대해 설명해보라

인성 관련

2 ~ 30 년 뒤 어떤 개발자가 되고 싶은가?

대학교 자퇴를 하면서까지 커리어 전환을 시도한 이유가 무엇인가?

본인이 입사 후 다른 포지션에서 일해야 한다면 어떻게 할 것인가?

본인은 아침형 인간인가 저녁형 인간인가?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment