0. 글을 들어가며...안녕하세요. 에이닷 QA팀입니다.에이닷은 2023년부터 프로젝트 관리 시스템을 개선하기 위해 Jira를 메인 PMS(Project Management System) 툴로 도입했습니다.이 과정에서 조직 전반에 업무 진행 내역을 Jira 이슈 티켓으로 등록하는 문화를 정착시켜 왔습니다.프로젝트와 업무가 다양화되고 복잡해짐에 따라, 구성원들은 자신의 업무를 다각도로 관리하고 시각화 할 수 있는 더 효과적인 방법을 필요로 했습니다.이러한 요구에 부응하기 위해 에이닷은 Jira의 기본 체계를 확장하면서도 계층적 티켓 구조를 명확히 시각화할 수 있는 Advanced Roadmaps 플러그인을 도입하게 되었습니다.Advanced Roadmaps는 직관적인 UI를 통해 복잡한 프로젝트 구조를 쉽게 파악할 수 있게 해주며, 다양한 팀과 프로젝트 간의 연결성을 효과적으로 보여준다는 장점이 있습니다.이 글에서는 에이닷이 로드맵을 어떻게 활용하고 있는지, 그리고 PM과 실무자들이 이 도구를 통해 어떻게 업무 효율성을 높일 수 있는지 상세히 살펴보겠습니다.글을 읽기 전에 로드맵을 아직 생성해 보지 않은 분이시라면, 아래 링크를 참고하셔서 로드맵을 먼저 생성해보시면 좋을 것 같습니다.로드맵은 복잡한 프로젝트와 여러 팀의 업무를 시각적으로 계획하고 관리할 수 있도록 돕는 도구입니다.주로 여러 팀 또는 여러 프로젝트가 동시에 진행되는 환경에서 팀 간 일정과 업무량, 그리고 작업 간 종속성을 명확히 하여 전체 프로젝트 진행 상황을 한눈에 파악할 수 있게 합니다.또한, 업무를 ‘이니셔티브→에픽→스토리/작업→부작업’과 같은 계층 구조로 구성하여 관리할 수 있습니다.1-1. PM의 관점에서 효과적인 사용법PM(Project Manager)은 로드맵에 표현할 데이터를 프로젝트, 보드, 또는 필터에서 가져와 원하는 방식으로 구성할 수 있습니다.로드맵의 타임라인을 통해 프로젝트의 일정과 자원을 시각적으로 배치하고 조정할 수 있으며, 업무 간 종속성을 명확히 설정하여 프로젝트 진행 중 발생 가능한 리스크를 미리 파악하고 관리할 수 있습니다.또한, 프로젝트의 진행 방향에 따라 다양한 계획 시나리오를 생성하고 이를 비교 분석하여 최적의 방안을 선택할 수도 있습니다.1-2. 실무자의 관점에서 효과적인 사용법실무자 관점에서 로드맵은 개인 및 팀의 업무 가시성을 크게 향상 시킵니다.자신의 업무가 전체 프로젝트에서 어떤 위치를 차지하는지, 어떤 업무들과 연결되어 있는지 명확히 파악할 수 있으며, 이를 통해 업무의 우선순위 설정과 일정 관리가 용이해집니다.업무 간 종속성을 시각적으로 확인함으로써 다른 팀이나 동료의 작업 진행 상황이 자신의 업무에 미치는 영향을 즉시 확인할 수 있고, 이는 효율적인 협업 관리를 가능하게 합니다.또한 자신의 작업량(capacity)을 시각화하여 과부하를 방지하고 적절한 업무 배분을 요청할 수 있는 근거를 마련할 수 있습니다.여러 팀과 조직이 협업하는 복잡한 환경의 대규모 프로젝트의 경우, 로드맵은 특히 유용하게 활용됩니다.에이닷에서는 사업

Branch Strategy안녕하세요. 여기어때컴퍼니에서 안드로이드 앱을 개발하고 있는 리처드입니다.현재 저희 팀에서 사용하고 있는 Git Branch 전략에 대해 공유드릴게요. 타겟 독자는 git을 사용한 지 얼마 되지 않은 전공생 및 현재 실무에서 일하고 있는 개발자입니다.실무에서는 대부분 Vincent Driessen의 git flow를 사용하고 있을텐데요. 저희 팀은 운영 상황에 맞게 변경해서 사용하고 있어요. 이해를 돕기 위해 터미널을 사용하지 않고 GUI 프로그램인 깃크라켄을 이용해서 설명하겠습니다.Merge 와 Rebase (사전지식)git을 사용 한 지 얼마 되지 않은 분들도 포함한 글이기에 Merge, Rebase의 차이점부터 짚고 갈 예정이에요.이미 알고 있는 내용은 스크롤 쭉쭉 넘겨주세요!Merge 방식 / Rebase 방식왼쪽 이미지는 Merge 방식으로 운영했을 때의 그래프인데요, 딱 봐도 복잡함을 느낄 수 있어요(두통 주의). 오른쪽 이미지는 Rebase로 운영했을 때 그래프 입니다. Merge 그래프를 보면서 온 두통을 Rebase 그래프가 치유해 주네요 :) 이런 깔끔함에 매료되어 저희 팀은 Rebase를 주로 사용하고 있어요. Rebase 를 하는 방법에 대해 짚고 가보겠습니다.Rebase 하는 법Rebase 하는 방법master, develop 브랜치가 있습니다. develop 브랜치의 작업이 완료되면 master 브랜치에 합치게 됩니다.develop을 master 위로 재배치합니다.Fast-forward merge를 사용하여 develop 작업 내용을 master에 머지합니다.master와 develop는 동일선상에 위치하게 됩니다.Merge 방식을 사용했다면 추가 커밋이 생기면서 그래프가 한 줄기로 나열되지 않지만 Fast-forward merge 방식을 사용하면 추가 커밋 없이 그래프가 한 줄기로 나열됩니다.Fast-forward를 사용할 수 있는 조건에 대해서 알아보겠습니다.before rebase / after rebaseRebase 하기 전 그래프는 Fast-forward를 사용할 수 없습니다. Rebase 후 그래프는 Fast-forward를 사용할 수 있습니다. Fast-forward merge를 사용하기 위해선 master 브랜치의 마지막 커밋을 develop이 갖고 있어야 됩니다. (좀 어렵게 말하자면 master의 Head Commit을 develop의 Base Commit으로 갖고 있어야 됩니다.)Rebase와 Fast-forward에 대한 설명은 여기까지입니다.Git Branch 전략보통 Git Branch 전략 관련 글들을 보면 각 브랜치의 성격을 설명하고 과정을 글로 나열하거나 터미널로 예시를 들면서 설명하는데요. 바로 와닿지 않았던 기억이 있기에 과정을 git 그래프를 예시로 들면서 프로젝트 생성부터 배포까지의 시나리오를 차근차근 진행해 보겠습니다.총 5개의 브랜치로 운영합니다.master : 이력만 관리하며 수정사항이 발생되지 않는 브랜치입니다. Release 머지 후 TAG

안녕하세요. LINE NEXT DevOps 팀에서 쿠버네티스 운영 및 유지 보수, CI/CD 구축, 모니터링, 로그 수집 등 인프라 전반에 걸쳐 업무를 수행하고 있는 이동원입니다. 이번 글에서는 새로운 도구를 활용해 장애/변경 알림 및 관리 시스템을 구축한 과정을 소개하겠습니다.이 글은 먼저 발행했던 ChatOps를 통한 업무 자동화(feat. Slack Hubot) 글과 이어지는 글로, 이번에 새로 소개할 도구는 Playwright라는 E2E(End-to-End) 모니터링 도구입니다. Playwright를 이용해 모니터링 관제를 수행하고, Jira를 이용해 장애 및 변경 티켓을 관리하며, 봇을 이용해 Slack으로 알림을 보내고 Jira를 제어하는 시스템을 구축했습니다. 그 과정을 상세히 소개하겠습니다.LY에서는 타 회사의 TTS(Trouble Ticket System)라는 시스템을 이용해 변경 관리 및 장애 관제를 수행하고 있었습니다. 그러나 타 시스템에 의존적이었고, 시스템을 별도로 운영하다 보니 모니터링과 변경, 장애에 대한 시스템 제어권이 없었습니다.이런 상황에서 장애 발생 후 이를 처리하는 데 소요되는 시간을 분석해 보았는데요. TTS로부터 장애 알림을 받은 후, 장애 대응 및 조치까지 걸리는 시간은 다음과 같았습니다. 2023년 1월부터 2024년 현재까지 발생한 이력을 x축으로, 장애 소요 시간을 y축으로 나타낸 그래프입니다.대체로 장애 처리는 1시간 이내에 완료됐으나, 가장 오래 소요된 상위 5개 사례에서는 1시간을 초과한 것으로 나타났습니다. 결과를 분석해 보니 대체로 장애 급수가 낮을수록 장애 복구에 오래 걸리는 경향이 있다는 것을 알 수 있었는데요. 비즈니스에 끼치는 영향도가 낮은 장애라도 서비스의 이상 유무는 사용자에게 영향을 미칠 수 있기 때문에 모든 장애에 대해 신속하게 알림을 받고 처리하는 것이 필요했습니다.보통 장애 처리는 크게 '장애 지속 시간을 줄이는 작업'과 '사후 처리'로 나눌 수 있습니다. 먼저 장애 지속 시간을 줄이는 작업은 다음과 같은 과정으로 진행됩니다.• 이상 징후 탐지 : 시스템이나 서비스에서 정상적이지 않은 동작이나 성능 저하를 감지하는 과정• 의사 결정 : 탐지된 이상 징후에 대한 대응 방안을 결정하는 과정• 시스템 복구 : 장애를 해결하고 시스템이나 서비스를 정상 상태로 되돌리는 과정다음으로 사후 처리 과정은 다음과 같습니다.• 영향도 파악 : 장애가 시스템, 서비스, 사용자에게 미친 영향을 평가하는 과정• 상세 원인 분석 및 재발 방지 : 장애의 근본 원인을 철저히 분석하고 동일한 문제가 다시 발생하지 않도록 예방 조치를 취하는 과정저희는 그중에서 아래와 같이 장애 지속 시간을 줄이는 데 초점을 맞추고, 이를 위해 기존에 사용하던 TTS을 대체할 시스템 조사해 새로운 시스템을 구축하기로 결정했습니다.기존 시스템을 대체할 새로운 시스템을 구축하기 위해서는 먼저 기존 시스템을 이해하는 것이 필요했습니다. 이에 기존 시스템이 제공하는 기능과 프로세스를 파악한 후 새로운 시스템이 이를 충분

본 글은 SK플래닛에서 OPA(Open Policy Agent)를 이용하여 사내 JIRA의 권한을 구현한 사례를 공유하며, 아래와 같이 크게 세 가지 작업을 정리하고자 합니다.• 첫번째는 개발 중인 ITSM 시스템에서 권한 부분을 OPA를 이용해 구현합니다.• 정책은 Rego로 작성합니다.• 두번째는 작성된 정책을, data API를 이용해 권한 체크를 구현합니다.• 세번째는 애플리케이션과 OPA 서버를 하나의 파드로 묶어 사이드카 형태로 쿠버네티스 개발 환경에 배포합니다.• ITSM 시스템의 백엔드를 Java Spring 및 JPA를 사용하여 개발하였고, 현재 사용 중인 JIRA를 대체할 예정입니다.• JIRA의 데이터를 이전할 계획이라, JIRA의 데이터 구조를 그대로 사용하고자 합니다.• JIRA의 권한 관련 데이터 및 권한 정책을 확인하였습니다.• JIRA의 프로젝트 관리 권한을 가진 사용자라면 아래와 같은 페이지에서 프로젝트의 롤과 퍼미션의 수정이 가능합니다.• Users and Roles 에서 ADMINISTRATORS/DEVELOPERS/USERS 롤에 그룹 및 사용자를 할당할 수 있습니다.• Project Permissions 에서 각 퍼미션에 사용자, 그룹 및 위에서 할당한 롤을 추가할 수 있습니다.• 이렇게 화면에서 설정한 값은 JSON으로 아래와 같이 표현합니다(JIRA API를 통해 확인).• 파일 크기가 꽤 되므로 일부 내용만 캡쳐하며, permissionKey(퍼미션 내용)과 grants(권한부여) 을 포함한 동일한 형태의 퍼미션을 배열로 정의하고 있습니다.• 해당 JSON을 OPA에서 권한 체크 시, 데이터로 사용합니다.• 이러한 구조를 염두해 두고 권한 처리를 생각해 보면, 사용자 및 사용자의 그룹이 속한 롤을 확인하고,• 사용자 아이디, 그룹명, 롤명으로 permissions의 grants를 뒤져서 해당 사용자가 해당 퍼미션에 권한이 있는지 여부를 확인할 수 있습니다.• 복잡해 보이지만 의외로 간단합니다. Rego를 작성해 봅니다.• 작성한 정책(rego)과 데이터을 이용하여 권한을 체크합니다. OPA 플레이그라운드에서 테스트할 수 있습니다.• 백엔드 서버에서 OPA data API를 이용하여 권한 체크를 하는 로직을 개발해 봅니다.• Spring security의 PreAuthorize 태그를 이용합니다.• Spring controller에 권한 체크를 위해 PreAuthorize 태그를 추가합니다.• PreAuhorize에서 opaclient.allow를 호출합니다.• opaClient.allow는 아래와 같이 구현하였습니다.• input으로 사용자 아이디와 그룹, 권한을 체크하고자 하는 프로젝트와 퍼미션를 입력합니다.• 개발한 백엔드 서버와 OPA 서버을 쿠버네티스(이하 k8s) 환경에 개발 서버로 배포해 봅니다.• 아래 k8s deployment yaml를 이용하여, 백단서버(pitsm-backend)와 OPA서버를 한 pod 내에 container로 배포합니다.• OPA 서버를 사이드카 형태로 실행