본문으로 건너뛰기

업무 프로세스 — 누가 언제 무엇을

플랫폼을 조직에서 어떻게 굴리는가를 정리한 문서입니다. 화면 사용법이 아니라 역할과 순서를 다룹니다.

튜토리얼과 다릅니다

튜토리얼이 「혼자 처음 한 번 해 보기」라면, 이 문서는 「여러 사람이 계속 굴리기」입니다. 담당이 나뉘고 인계가 생기는 지점을 표시했습니다.

역할은 셋뿐입니다​

역할화면 표기하는 일
ADMIN시스템 관리자계정·보안·설비 마스터·시스템 설정 전부
APIAPI 개발자외부 시스템 연동. 토큰으로 API 호출
USER일반 사용자조회 중심. 변경 권한 없음
MANAGER 역할은 없습니다

소스에 존재하지 않습니다. 「중간 관리자에게 일부 권한만」이 필요하면 역할이 아니라 보안 정책(권한 그룹) 으로 풉니다 → 보안 관리.

역할별로 보이는 메뉴가 다릅니다 → 로그인과 화면 구성.

생애주기 — 세 국면​

전체를 역할별 레인으로 보면 이렇습니다. 화살표가 레인을 넘는 곳이 인계 지점입니다.

1. 도입·커미셔닝 — 한 번만, 그러나 제대로​

순서하는 일담당산출물
1설치구축기동된 플랫폼 → 설치
2기본 비밀번호 전량 교체구축인계 문서 → 초기 비밀번호 변경
3ID 규칙 확정구축 + 현장명명 규칙서 → 도메인 ID 규칙
4사이트 → 설비 → 태그 등록구축설비 마스터
5Edge 연결·수집 검증구축화면에 값이 들어옴
6알람 임계값 설정현장알람 정의 → 알람 관리
7계정 발급·역할 부여ADMIN사용자 목록 → 사용자 관리
8인수 점검현장인수 확인서
3번을 건너뛰면 되돌리기 어렵습니다

ID 는 화면·API·리포트 전반에 그대로 박힙니다. 급하게 지은 ID 는 오래 갑니다. 등록을 시작하기 전에 규칙을 문서로 만드세요.

2. 정상 운영 — 주기가 있는 일​

주기하는 일담당
매일알람 확인·조치, 수집 끊김 확인현장
주 1회디스크·자원 추이 확인 → 모니터링ADMIN
월 1회백업 복구 리허설, 계정 정리ADMIN
분기비밀번호 회전 → 크리덴셜 회전ADMIN
백업은 「받는 것」이 아니라 「되살리는 것」입니다

받아만 두고 복구를 해 본 적이 없는 상태가 가장 흔한 실패입니다. 저장소가 셋이라 더 그렇습니다 → 데이터베이스 모델.

3. 변경·확장 — 설비가 늘거나 바뀔 때​

하는 일순서
설비 추가마스터 등록 → 태그 → 수집 확인 → 알람
태그 의미 변경기존 데이터와 단위가 섞이지 않는지 먼저 확인
연동 추가API 계정 발급 → 토큰 → IP 제한 → API 매뉴얼
태그를 재사용하지 마세요

쓰던 태그의 의미를 바꾸면 과거 데이터와 새 데이터가 같은 이름으로 섞입니다. 리포트는 그것을 구분하지 못합니다. 새 태그를 만드세요.

인계 지점 — 여기서 자주 끊깁니다​

인계넘겨야 할 것
구축 → 현장계정 목록, 바꾼 비밀번호의 보관 위치, ID 규칙서, 인수 확인서
현장 → 시스템 관리자장애 시 연락 경로, 진단 tarball 생성법(./doctor.sh)
담당자 교체위 전부 + 최근 변경 이력
비밀번호 값 자체를 인계 문서에 적지 마세요

어디에 보관되어 있는지를 적습니다. 값은 별도 비밀 관리 수단으로 넘깁니다.

자주 어긋나는 지점​

증상대개의 원인
「누가 이걸 바꿨는지 모르겠다」계정을 공유해서 씀 — 사람마다 계정을 만드세요
「알람이 너무 많아 아무도 안 본다」임계값을 도입 때 정하고 손대지 않음. 분기마다 재조정
「데이터가 언제부터 없다」수집 끊김을 매일 보지 않음. 일일 점검에 넣으세요
「인계받았는데 비밀번호를 모른다」인계 문서에 보관 위치가 없음

관련 문서​