업무 프로세스 — 누가 언제 무엇을
플랫폼을 조직에서 어떻게 굴리는가를 정리한 문서입니다. 화면 사용법이 아니라 역할과 순서를 다룹니다.
튜토리얼과 다릅니다
튜토리얼이 「혼자 처음 한 번 해 보기」라면, 이 문서는 「여러 사람이 계속 굴리기」입니다. 담당이 나뉘고 인계가 생기는 지점을 표시했습니다.
역할은 셋뿐입니다
| 역할 | 화면 표기 | 하는 일 |
|---|---|---|
| ADMIN | 시스템 관리자 | 계정·보안·설비 마스터·시스템 설정 전부 |
| API | API 개발자 | 외부 시스템 연동. 토큰으로 API 호출 |
| USER | 일반 사용자 | 조회 중심. 변경 권한 없음 |
MANAGER 는 «부여할 수 없는» 역할입니다
역할별로 보이는 메뉴가 다릅니다 → 로그인과 화면 구성.
생애주기 — 세 국면
전체를 역할별 레인으로 보면 이렇습니다. 화살표가 레인을 넘는 곳이 인계 지점입니다.
1. 도입·커미셔닝 — 한 번만, 그러나 제대로
| 순서 | 하는 일 | 담당 | 산출물 |
|---|---|---|---|
| 1 | 설치 | 구축 | 기동된 플랫폼 → 설치 |
| 2 | 기본 비밀번호 전량 교체 | 구축 | 인계 문서 → 초기 비밀번호 변경 |
| 3 | ID 규칙 확정 | 구축 + 현장 | 명명 규칙서 → 도메인 ID 규칙 |
| 4 | 사이트 → 설비 → 태그 등록 | 구축 | 설비 마스터 |
| 5 | Edge 연결·수집 검증 | 구축 | 화면에 값이 들어옴 |
| 6 | 알람 임계값 설정 | 현장 | 알람 정의 → 알람 관리 |
| 7 | 계정 발급·역할 부여 | ADMIN | 사용자 목록 → 사용자 관리 |
| 8 | 인수 점검 | 현장 | 인수 확인서 |
3번을 건너뛰면 되돌리기 어렵습니다
ID 는 화면·API·리포트 전반에 그대로 박힙니다. 급하게 지은 ID 는 오래 갑니다. 등록을 시작하기 전에 규칙을 문서로 만드세요.
2. 정상 운영 — 주기가 있는 일
| 주기 | 하는 일 | 담당 |
|---|---|---|
| 매일 | 알람 확인·조치, 수집 끊김 확인 | 현장 |
| 주 1회 | 디스크·자원 추이 확인 → 모니터링 | ADMIN |
| 월 1회 | 백업 복구 리허설, 계정 정리 | ADMIN |
| 분기 | 비밀번호 회전 → 크리덴셜 회전 | ADMIN |
백업은 「받는 것」이 아니라 「되살리는 것」입니다
받아만 두고 복구를 해 본 적이 없는 상태가 가장 흔한 실패입니다. 저장소가 셋이라 더 그렇습니다 → 데이터베이스 모델.
3. 변경·확장 — 설비가 늘거나 바뀔 때
| 하는 일 | 순서 |
|---|---|
| 설비 추가 | 마스터 등록 → 태그 → 수집 확인 → 알람 |
| 태그 의미 변경 | 기존 데이터와 단위가 섞이지 않는지 먼저 확인 |
| 연동 추가 | API 계정 발급 → 토큰 → IP 제한 → API 매뉴얼 |
태그를 재사용하지 마세요
쓰던 태그의 의미를 바꾸면 과거 데이터와 새 데이터가 같은 이름으로 섞입니다. 리포트는 그것을 구분하지 못합니다. 새 태그를 만드세요.
인계 지점 — 여기서 자주 끊깁니다
| 인계 | 넘겨야 할 것 |
|---|---|
| 구축 → 현장 | 계정 목록, 바꾼 비밀번호의 보관 위치, ID 규칙서, 인수 확인서 |
| 현장 → 시스템 관리자 | 장애 시 연락 경로, 진단 tarball 생성법(./doctor.sh) |
| 담당자 교체 | 위 전부 + 최근 변경 이력 |
비밀번호 값 자체를 인계 문서에 적지 마세요
어디에 보관되어 있는지를 적습니다. 값은 별도 비밀 관리 수단으로 넘깁니다.
자주 어긋나는 지점
| 증상 | 대개의 원인 |
|---|---|
| 「누가 이걸 바꿨는지 모르겠다」 | 계정을 공유해서 씀 — 사람마다 계정을 만드세요 |
| 「알람이 너무 많아 아무도 안 본다」 | 임계값을 도입 때 정하고 손대지 않음. 분기마다 재조정 |
| 「데이터가 언제부터 없다」 | 수집 끊김을 매일 보지 않음. 일일 점검에 넣으세요 |
| 「인계받았는데 비밀번호를 모른다」 | 인계 문서에 보관 위치가 없음 |