Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps는 원격근무를 추구하면 안되는 걸까?

3,654 views

Published on

HBsmith 의 DevOps 팀에서 어떻게 3년째 원격근무를 하고 있는지 소개합니다. (본 자료는 AWSKRUG #architecture 모임에서 10월 31일에 발표한 자료입니다.)
- 프로세스
- 시스템
- 문화

Published in: Software
  • @Taesu Hyeon 지라 플러그인은 안써봐서 잘 모르겠습니다.. confluence로 템플릿을 만들어서 매달 직접 작성하고 있습니다. 그리고 내용확인은 매주 월요일 또는 스프린트 회의 전에 주기적으로 하고 있습니다.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 안녕하세요. 슬라이드 잘 봤습니다! did list가 인상적이었는데 지라 플러그인 사용하신건가요? did list 어떻게 세팅하고 관리하시는지 알려주실 수 있나요?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

DevOps는 원격근무를 추구하면 안되는 걸까?

  1. 1. DevOps 팀은 원격근무를 추구하면 안되는 것일까? 2019. 10. 31 jesang.yoon@hbsmith.io
  2. 2. 저희 회사는요
  3. 3. • 2018년 부터 AWS 공식 Technology Partner • 웹/앱 서비스의 QA 테스트를 자동화 해주는 SaaS 솔루션을 개발 & 운영하고 있습니다. • 매 2주마다 패치를 3년째 하고 있습니다. • 전원 원격 근무를 하고, 모든 회의를 원격으로 하고 있습니다.
  4. 4. https://github.com/milooy/remote-or-flexible-work-company-in-korea
  5. 5. 원격근무에 대한 질문
  6. 6. • 장애가 발생하면 제때 대응이 가능한가요? • 개발자들이 일 잘 하고 있는지 확인이 가능한가요? • 일정을 맞추기 어렵지 않나요?
  7. 7. DevOps 팀은 원격근무 를 추구하면 안되는 걸까 요? 출처: Auction
  8. 8. 오늘의 주제
  9. 9. • HBsmith의 DevOps 팀은 어떤 프로세스로 일하고 있는가? • HBsmith의 DevOps 시스템은 어떻게 되어 있는가? • HBsmith의 DevOps 문화는 어떤가?
  10. 10. 프로세스
  11. 11. 옛날엔 …
  12. 12. • 킥오프 부터 납기일 까지 수개월 동안 기획 - 개발 - 테스트 - 배포를 1 바퀴만 돕니다. • 주간, 월간 회의를 하며 보고서를 준비해야 합니다. • 실무 및 관리자들이 수시로 회의를 잡습니다. • 1개월 6개월 혹은 1년 이후의 계획까지 세웁니다. • 최종까지 합의된 건은 바꾸기 매우 어렵습니다.
  13. 13. • 회의 하느라 개발할 시간이 없습니다. • 보고서가 수십개 버전이 존재해서 어느게 최종인지 알기 어렵습니다. • 보고서 만드느라 관리할 시간이 없습니다. • 협의에 지쳐서 기존 안을 수정할 생각을 하지 못합니 다. • 일정에 업무를 맞춰야만 할뿐, 일정을 업무에 맞게 조정하기 힘듭니다.
  14. 14. HBsmith에선 이렇게 합니다
  15. 15. • 매 2주 단위로 기획 - 개발 - 테스트 - 배포의 Cycle을 반복합니다. • 시작하기 전에 모든 안건을 같이 리뷰하고 계획을 세우며, Issue 생성 및 공수 산정을 합니다. • 전체 회의는 2주에 1번만 합니다. • 매일 자신의 업무 상황을 간략히 기록/공유합니다.
  16. 16. Sprint 회의
  17. 17. • 스프린트는 업무의 주기(Cycle)을 말합니다. • 1 Sprint = 2 Weeks = 10 Working Days • 이전 2주간 한 일들을 모두 리뷰 합니다. • 회사/개발/운영/마케팅 모든 안건을 논의합니다. • 이번 2주간 할 일을 모두 Issue로 정의합니다. • 이번 2주간 할 일의 Story Point를 추정합니다. • 2주에 1번만 하루종일 합니다. (격주 화요일) • 자신과 관련된게 아니면 회의중 딴짓을 해도 좋습니다.
  18. 18. Story Point 그리고 추정
  19. 19. • Story Point는 공수를 추정하기 위한 단위입니다. • 1 Point = 8시간 = 1 working day • 인간은 하루종일 업무에만 집중할수 없습니다. 그래서 가중치를 줍니다. • 2주 = 10 working day * 가중치 0.8 = 8 point • 1인당 각 Issue에 할당된 총합이 8 포인트를 넘기지 않으면 됩니다. • 1인당 각 Issue의 총 개수가 20개를 넘지 않도록 주의합 니다.
  20. 20. • 8포인트를 2주 동안 잘 쪼개는게 중요합니다. • 1시간내로 끝나는잡무 = 0 point • 1시간 이상 걸리는 업무 = 0.1, 0.2, 0.3 point • 1시간 이상 걸리는데 잘 모르겠음 = 0.5 point • 8시간(하루) 소요 = 1 point • 여러번 해보고 피드백을 받으면서 점점 정확한? 추정이 가능해 집니다.
  21. 21. 추정의 효과 그리고 Burn down chart
  22. 22. • Story Point를 세우고 추정을 하는건 일을 많이 하고 이를 독촉하기 위함이 아닙니다. • 작업자가 자신의 역량보다 너무적게 또는 무리하게 일을 해서 생기는 부작용을 막기 위함 입니 다. • 또한 추정을 통해 현재 팀의 업무 역량을 알수 있습 니다. • 전체의 업무 상황과 역량을 빨리 파악하는덴 Burn Down Chart 가 효과적 입니다.
  23. 23. Daily Did List
  24. 24. • Scrum 회의를 Did List 작성으로 간소화 하였습니다. (scrum 회의는 매일아침 10분간 같이 오늘 할일을 이야기 하는 자리입 니다) • 누가 언제 무엇을 하고 있는지 Did List에 남깁니다. • 모두가 서로 무엇을 하고 있는지 알수 있습니다. • 따로 보고서를 제출하거나 보고회의를 잡지 않습니 다. • Did List 작성은 반드시 의무화 하고 있습니다. (회사 - 근로자간 신뢰의 근간 및 원격근무의 필수요소)
  25. 25. 시스템
  26. 26. 옛날엔 …
  27. 27. • 모두가 개발 서버를 공유합니다. • 운영 환경과 개발 환경이 혼재 되어 있습니다. • 패치는 수동으로 하거나 반자동 입니다. • 시스템은 손으로 Setup 및 Upgrade 합니다. • CI/CD (Continuous Integration) 는 주니어의 업무입니다 . • 아무나 OP(운영)의 설정을 건드릴수 있습니다. • 한번 배포되면 웬만해선 건들지 않습니다.
  28. 28. • 개발하다가 실수로 운영서버를 건드려서 장애가 납니 다. • 남이 개발서버를 수정하는 바람에 내가 개발을 못합니 다. • 누가 왜 만들었는지 알수없는 리소스가 존재합니다. • Full DR 또는 일부만 DR 하는데 얼마나 걸릴지 모릅니 다. • 패치날은 하루종일 일한 후 밤새서 일하는 날입니다. • 퇴사자가 작정하고 OP를 날리면 복구할 방법이 없습 니다. • 오래된 서버가 자주 문제를 일으킵니다.
  29. 29. HBsmith에선 이렇게 합니다
  30. 30. • 나만의 local 개발 환경(vagrant)과 AWS 환경이 모두 제공됩니다. • 모든 인프라와 어플리케이션은 수동세팅 없이 IaC로만 관리됩니 다. • Daily CD: IaC를 이용하여 모든 어플리케이션 리소스를 매일 새것으로 교체 합니다. • GitHub 커밋 기록이 곧 인프라/어플리케이션의 수정 기록입니다. • 장애 발생시 서버 교체에 얼마나 걸릴지 CD 기록으로 알수 있습 니다. • CD/CI 는 시니어 개발자 및 패치 담당자의 역할입니다. • Full Test 및 Patch에 길어도 반나절이면 충분합니다.
  31. 31. AWS Organization 그리고 보안
  32. 32. • 모든 개발자는 각자의 AWS 계정을 발급 받습니다. • QA, OP 역시 각자의 AWS 계정으로 독립되어 있습니다 . • Root 계정의 AWS Organization으로 모든 AWS 계정을 묶어서 관리합니다. • Last Pass 를 이용하여 임원, 시니어, 주니어 순으로 계정 및 설정 정보 노출을 제한합니다. • QA/OP 는 임원외엔 IAM 으로만 계정에 접근 가능합니 다. • DV/QA/OP 모두 VPN 으로만 EC2에 접근 가능합니다.
  33. 33. 로컬 개발환경 그리고 IaC
  34. 34. • 모든 개발자는 각자의 로컬 Vagrant 환경에서 개발을 시작합니다. • Vagrant는 각 MSA 서버들을 VM으로 로컬에서 띄울수 있도록 해줍니다. • Vagrant는 마음대로 수정하고 언제든 버리고 다시 띄울수 있는 sandbox 입니다. • Vagrant 환경도 IaC화 되어 있어 띄우기만 하면 모든 스택이 자동으로 세팅되어 제공됩니다. • AWS 상에서 개발하는데 드는 불편함과 비용에 대한 걱정을 줄일수 있습니다.
  35. 35. • AWS 부터는 HBsmith 전용 IaC인 Johanna를 이용합니다. • run_create.py 만 하면 모든 리소스가 내 AWS 계정에 프로비저닝 됩니다. • run_terminate.py 만 하면 띄운 모든 리소스를 깨끗히 삭제할수 있습니다. • run_create_*.py / run_terminate_*.py 로 원하는 리소스를 찍어서 띄우고 삭제할수 있습니다. • DV/QA/OP 모두 설정값의 내용만 다를뿐 같은 소스코드, 같은 스키마의 설정을 이용합니다. (DV에서 가능한 것들은 QA, OP에서도 모두 가능합니다.) • Johanna의 git commit 기록이 곧 인프라 수정의 기록입니다.
  36. 36. Johanna에 대한 더 자세한 이야기는 마이크로소프트웨어 398호에 있습니다 ! 구매 부탁드립니다 :)
  37. 37. Daily CD
  38. 38. • Johanna의 최고 장점은 쉬운 Daily CD 입니다. • 매일 자동으로 Web, EC2, ELB 등의 리소스를 새것으로 교체 합니다. • 매일 자동으로 교체하기 때문에 서버를 장시간 운영해서 발생하는 이슈가 없습니다. • 매일 자동으로 교체하기 때문에 언제든지 문제없이 패치가 가능하다는 것을 알수 있습니다. • 패치에 걸린 기록이 남기 때문에 DR 상황에서 서버 교체에 얼마나 시간이 걸릴지 알수 있습니다.
  39. 39. https://www.slideshare.net/addnull/20181108-hbsmith-aws-iac
  40. 40. 문화
  41. 41. 옛날엔 …
  42. 42. • 결정은 임원이 책임은 직원이 집니다. • 실수하면 시말서를 제출해야 합니다. • 중요한 정보는 소수 (주로 흡연자) 만이 알고 있습니다. • 운영중에 문제가 안생기길 기도합니다. • 정보는 입으로 전달되며 문서는 오래된 것이 대부분입니다. • 소스코드, 문서는 여기저기 흩어져 있습니다. • 이메일을 뒤져서 업무 히스토리를 추적합니다. • 갈등이나 문제는 술로 풉니다. • 휴가/퇴근을 쓸때 눈치가 많이 보입니다. • 코드 리뷰를 KPI로 설정합니다.
  43. 43. • 정보는 독점되고 공유되지 않습니다. • 직원들은 관리자와 임원들을 두려워 합니다. • 한번 터진 문제는 같은 이유로 또 다시 터집니다. • 임직원들 사이에 사적인 그룹이 형성됩니다. • 계획이나 약속만 있고 실천은 없습니다. • 임원들에 대한 직원들의 신뢰가 없습니다. • 직원들에 대한 임원들의 신뢰가 없습니다. • 모두가 야근과 주말 출근을 자주 합니다. • 이직률이 높습니다. • 코드 리뷰를 싫어합니다.
  44. 44. HBsmith에선 이렇게 합니다
  45. 45. • 기록으로 남지 않는 것은 관리되지 않습니다. • 인사/재무/기획/운영/코드 자료가 모든 구성원이 볼수 있도록 공개되어 있 습니다. (심지어 임원들이 주기적으로 리마인드 까지 해줍니다) • JIRA, Confluence, GitHub 같은 협업툴을 적극 사용합니다. • 사람이 쓰는 Slack 채널은 #general 만 운영 합니다. • 문제가 생겼을때 최선의 미덕은 정직(사실대로 빠른 전파)입니다. • 공유된 문제는 특정인이 아닌 모두의 책임입니다. • 의사결정의 실행은 직원이 책임은 임원이 집니다. • 코드 리뷰는 문화지 업무가 아닙니다. • 술을 마시지 않아도 갈등을 풀수 있습니다.
  46. 46. Code Review
  47. 47. • Code Review은 문화입니다: No Respect, No Review • 코드 작성전 논의는 JIRA/Confluence 에서 • 코드 작업후 논의는 GitHub 에서 • No Merge, Not Done • Fast Merge • Code Freeze • QA/OP 패치 전 PR 은 반드시 정리 • 리뷰가 덜된 PR은 2 Sprint내 Merge
  48. 48. QA 테스트 OP 배포 Issue 생성/지 정 스프린트 회의 Issue 세부논의 JIRA/Confluence PR 생성 GitHub Code Review GitHub Issue 및 PR 정리 OP 테스트 Merge 되지 못한 PR은 논의 후 Close 1 Sprint = 2 Weeks = 10 Working Days Merge 되지 못한 PR은 논의 후 Reopen Code Freeze
  49. 49. Workshop
  50. 50. • 가끔 점심 회식을 합니다. • 대신 분기에 1번 또는 상하반기에 1번씩 전체 워크샵을 갑니 다. • 공기 좋은 곳에서 질 좋은 음식을 먹습니다. • 회사의 과거, 현재, 미래에 대해 같이 이야기 합니다. • 간단한 액티비티/해커톤/페어 프로그래밍도 합니다. • 커피는 마시지만 술은 거의 안마십니다.
  51. 51. One-to-One
  52. 52. • 외부 고객도 중요하지만 내부 고객(임직원)은 더 중요합 니다. • 임원들이 돌아다니며 팀의 모든 임직원과 1:1 로 밥을 먹 고 커피를 마십니다. • 최소 2시간 부터 4~5시간 까지 이야기를 나누기도 합니 다. • 가벼운 근황공유 부터 속 깊은 이야기 까지 대화를 나눕 니다. • One-to-One 때 나온 피드백이 좋은 개선을 불러온적이 많습니다.
  53. 53. 복지
  54. 54. • 최신 MacBook Pro를 지급합니다. (32G Ram) • 2년 근속시 개인소유, 2년에 한번 업그레이드 합니다. • 업무용 SW는 회사에서 사줍니다. • 외부 컨퍼런스, 미팅 비용은 회사에서 대줍니다. • 경조사 지원, 병원비 지원, 명절선물 지원 있습니다. • 코스트코 회원 카드 (비즈니스)를 줍니다. - 한정
  55. 55. 정리
  56. 56. • 장애가 발생하면 제때 대응이 가능한가요? => 시스템 알람 뿐만 아니라 임직원들이 서로 전파합니다. • 개발자들이 일 잘 하고 있는지 확인이 가능한가요? => 업무 상황이 시스템에 모두 기록되어 누가 뭐 하는지 실시간으로 서로 알수 있습니다. • 일정을 맞추기 어렵지 않나요? => 업무를 추정하여 완급을 조절합니다.
  57. 57. • DevOps 팀이 원활한 원격근무가 가능하려면: • 추적가능하고 재현가능한 자동화 달성 • 명확하고 투명한 정보 공유 • 시스템을 바탕으로 업무 • 원칙과 프로세스를 꾸준히 지키고 유지 • 실행은 직원이 책임은 임원이 • 이 모든게 며칠이 아닌 수개월 수년동안의 지속적인 실험/개선의 결과입 니다.
  58. 58. 여러분의 조직은 어떠신가요?
  59. 59. 저희와 같이 성장할 개발자를 찾고 있습니다. 연락주세요 :) hello@hbsmith.io

×