PMDEXIT 프로젝트 용어사전

클라우드 계정 넘기기 - 오픈 전 콘솔 권한과 비용 알람 주인

“콘솔 권한은 오픈 전에 넘긴다”

인도클라우드 계정 인수콘솔 권한비용 알람

오픈 전날 밤, 월 비용 알람 1통이 수행사 담당자 메일로만 가고 발주사 운영 채널에는 도착하지 않는 현장이 있다. 콘솔 로그인, 결제 명의, 알람 수신, 배포 권한이 한 사람에게 모여 있으면 그 사람이 빠지는 주에 운영이 멈춘다. 계정은 시스템에 남는데 주인은 철수 명단에 있다. 권한 12개를 개인 메일로 받은 채 오픈하면, 다음 달 청구서의 상한도 그 메일로만 간다. 권한을 역할 계정으로 나누고, 비용 상한을 발주사 명의로 옮기며, 인수 체크를 오픈 2주 전 산출물로 고정하는 순서를 적는다. 클라우드로 오픈하는데 계정 목록이 없다면 콘솔부터 다시 보면 된다.

역할명의완료로 보는 증적
결제와 상한발주사알람 1통이 운영 채널에 도착한 시각
콘솔 관리운영 역할 계정개인 메일 관리자 권한 회수 목록
배포파이프라인 전용개인 계정으로 배포가 거부된 기록
조회현업 확인용변경 메뉴가 없는 화면
알람 수신당직 채널 2곳수신자 목록에 개인 메일이 없음
오픈 전에 나눌 계정 역할

오픈 전날 비용 알람은 왜 수행사 메일로 갈까?

계정을 연 사람이 수신자로 남아 있기 때문이다. 연 사람과 운영할 주체는 다르다.

구축 초기에는 속도 때문에 수행사 엔지니어 메일로 루트에 가까운 계정을 만든다. 그 선택이 오픈 주까지 남는다.

알람, 청구서, 인증 코드가 그 메일로만 간다. 담당자가 휴가면 인증 코드가 멈추고, 배포도 멈춘다.

멈추는 이유가 장애가 아니라 부재라는 점이 운영 회의에서 늦게 드러난다. 안정화 계획 기간에 사람을 더 붙이는 계획과, 계정 주인이 누구인지는 다른 문제다.

사람이 있어도 콘솔에 못 들어가면 당직은 전화 중계가 된다. 중계로 새는 시간만큼 복구 시각이 밀린다.

밀린 시각은 장애 보고서에 원인 미상으로 적히기 쉽다. 원인은 미상이 아니라 수신처가 개인 메일이었다.

넘길 계정은 몇 종류로 나눌까?

결제 명의, 관리자, 배포, 조회, 알람. 다섯 역할을 사람 이름과 분리한다.

계정 목록을 메일 주소 20줄로만 넘기면 인수자는 누구를 지워야 하는지 모른다. 역할로 나눈다.

결제와 비용 상한은 발주사 재무 또는 운영 관리자. 콘솔 관리자는 운영 당직이 공유하는 역할 계정.

배포는 파이프라인 전용 계정으로 두고 개인에게 주지 않는다. 조회는 현업 확인용으로 변경 권한이 없다.

알람 수신은 개인 메일이 아니라 운영 채널과 당직 메일 두 곳이다. 한 역할에 사람이 2명 미만이면 그 역할은 단일 실패점이다.

단일 실패점은 Risk(위험)에 올린다. 위험 대장에 계정 줄을 안 넣는 현장은 기술 위험만 적고, 사람이 빠지는 위험은 인사 발령 뒤에야 본다.

발령은 일정보다 갑자기 온다.

권한을 사람 이름으로 두면 무슨 일이 날까?

퇴사와 철수 때마다 권한이 남거나 사라진다. 남은 권한은 감사에서, 사라진 권한은 장애에서 나온다.

개인 계정은 만들기 쉽고 지우기는 늦다. 프로젝트 종료 체크에 계정 회수가 없으면, 수행사 메일이 운영 구독에 남는다.

남은 계정은 다음 보안 점검에서 외부인 권한으로 집계된다. 반대로 성급히 지우면 그 계정에 묶인 인증서가 만료 알람을 잃는다.

알람을 잃은 인증서는 만료 주에 서비스 중단으로 돌아온다. 회수 목록과 유지 목록을 같이 적는다.

유지 목록에는 역할 이름만 두고, 개인 이름은 당직 명단 문서로 뺀다. 당직 명단이 바뀌어도 콘솔의 역할은 그대로다.

이 분리를 WBS의 인계 작업에 한 줄로 넣지 않으면, 인계 산출물은 매뉴얼 PDF 한 부로 끝난다. PDF에는 오늘 로그인한 사람이 안 적혀 있다.

비용 상한과 알람은 누구 명의로 둘까?

청구 명의와 상한 알람은 발주사다. 수행사 카드로 오픈하면 다음 달 내역을 그 회사 포털에서 받는다.

시험 기간의 소액 결제를 수행사 카드로 처리하는 일은 흔하다. 오픈 후에도 그 카드가 남으면 비용의 주인이 계약과 달라진다.

발주사는 사용량을 콘솔에서 못 보고, 수행사는 매월 캡처를 보내야 한다. 캡처는 항목이 잘리고, 잘린 항목에서 다음 분쟁이 난다.

오픈 2주 전에 결제 수단을 발주사 명의로 바꾼다. 바꾼 뒤에 상한 알람을 건다.

상한은 월 예산을 넘기 전에 한 번, 넘긴 뒤에 한 번이면 충분하다. 알람 수신처에 수행사 개인 메일이 남아 있으면 변경이 안 끝난 것이다.

변경 완료의 증적은 알람 테스트 1통이 발주사 채널에 도착한 시각이다. 시각이 없는 완료 보고는 설정 화면의 스크린샷과 같다.

스크린샷은 다음 날 되돌려도 티가 안 난다.

인수 체크는 어느 시점에 둘까?

오픈 당일이 아니라 오픈 2주 전이다. 당일은 계정 작업을 하기에 이미 늦다.

오픈 당일 체크리스트에 계정 인수를 넣으면 그 항목은 항상 이월된다. 인증 코드, 결제 수단 변경, 권한 축소는 적용에 수 시간이 걸리고, 걸린 시간 동안 배포가 막힌다.

막힌 배포를 오픈 당일에 만나면 계정 작업을 되돌린다. 되돌리면 다음 달까지 개인 메일이 남는다.

그래서 인수 체크의 마감은 오픈 2주 전 산출물로 둔다. 산출물이 미완이면 오픈 준비 회의의 선결 조건으로 올린다.

선결을 주간 이슈 하단으로 내리면 다시 당일 업무가 된다. 안정화 인력 계획과 계정 계획을 한 페이지에 둔다.

인력만 있고 계정이 없으면 그 페이지의 당직은 연락 체계일 뿐이다. 연락 체계는 콘솔을 대신하지 못한다.

자주 묻는 것

구축사가 안정화 동안 관리자 권한을 유지해도 되나
유지하려면 역할 계정으로 기간을 적는다. 개인 메일에 무기한 관리자를 두면 철수 주에 권한이 남거나 사라진다.
루트 계정은 어디에 두나
발주사가 보관한다. 사용은 막고, 복구용으로만 둔다. 구축사 노트북에 저장된 루트는 인수 전에 회수 대상으로 적는다.
알람 테스트를 오픈 후에 해도 되나
오픈 후에 하면 첫 초과 비용을 테스트로 만나게 된다. 소액 상한으로 오픈 2주 전에 1통을 보낸다.
계정 목록을 매뉴얼 부록으로 넣으면 끝인가
부록의 메일 주소는 다음 주에 바뀐다. 역할 이름과 회수 완료 시각이 있어야 인수 산출물이다.

관련 용어

출처

다른 가이드