ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
DOCS/workflow/51123_nas_remote_operations_workflow.md
happybell80 240465158e chore(workflow): 런북을 워크플로우로 통일 
- 51123_nas_sync_verification_workflow.md 신규
- 51123_github_org_repo_bootstrap_workflow.md 신규
- 기존 런북 deprecated 표시 및 SSOT 링크
- workflow README 문서 목록 테이블화

Made-with: Cursor
2026-03-17 22:08:03 +09:00

6.2 KiB
Raw Blame History

tags
tags
infra
workflow
nas
51123
remote-operations

51123 NAS Remote Operations Workflow

상위 원칙

관련 문서

목적

  • 51123 서버에서 내부 NAS 192.168.0.101를 원격 점검·수정·검증할 때 같은 순서로 작업합니다.
  • 사람과 에이전트가 같은 문서를 읽고 같은 기준으로 NAS 원격 작업을 수행합니다.

적용 범위

  • NAS 점검
  • NAS SSH 접속
  • NAS 라우팅 확인
  • NAS 동기화 로그 확인
  • NAS cron 수정
  • NAS 실행 스크립트 확인

기본 원칙

  • 먼저 51123 기준값과 로그를 확인한 뒤 NAS에 들어갑니다.
  • NAS 원격 변경 전에는 현재 상태와 백업 경로를 먼저 확보합니다.
  • 점검과 수정은 분리해서 기록합니다.
  • 정상으로 보인다가 아니라 로그, state, summary, 실제 스케줄 값을 같이 확인합니다.
  • downloaded = 0만으로 실패 판단을 하지 않습니다.
  • cron, lock, run log, summary를 같은 시각대로 교차 확인합니다.

표준 흐름

1. 51123 기준 확인

먼저 아래를 확인합니다.

grep -n '^NAS_' /home/admin/workspace-config/runtime.env /home/admin/workspace-config/secrets.env
crontab -l
ls -la /mnt/nas/workspace/.sync-logs /mnt/nas/workspace/.sync-logs-hierarchical

판단 기준:

  • NAS_HOST=192.168.0.101
  • /mnt/nas 마운트 정상
  • 최근 summary 파일 존재

2. NAS 접속 가능 여부 확인

nc -vz -w 3 192.168.0.101 22
ssh-keygen -F 192.168.0.101

판단 기준:

  • 22/tcp 접속 성공
  • known_hosts 엔트리 존재 또는 신규 확인 가능

3. NAS 기본 상태 확인

ssh -o StrictHostKeyChecking=no admin@192.168.0.101
date
hostname
whoami
ip route

판단 기준:

  • hostname은 companyx
  • default via 192.168.0.1 dev eth1
  • 외부 NAS 호스트 라우트가 있으면 112.218.113.4 via 192.168.0.1 dev eth1

4. 작업 유형별 분기

A. 점검만 할 때

B. NAS cron을 수정할 때

  1. 현재 값 확인
cat /etc/crontab
  1. 백업 생성
sudo cp /etc/crontab /etc/crontab.bak_YYYYMMDD_HHMMSS

  1. 필요한 한 줄만 수정

  2. 수정 직후 다시 확인

grep 'COMPANYX_NAS_SYNC_' /etc/crontab
  1. 수정 이유와 기대 동작을 같이 기록

C. NAS 동기화 실패를 볼 때

아래 순서로 같이 봅니다.

cat ~/workspace/.sync-logs/companyx_sync_state.json
ls -1t ~/workspace/.sync-logs/companyx_sync_summary_*.json | head -n 3
tail -n 100 ~/workspace/.run-logs/companyx/companyx_sync_fullscan.log

cat ~/workspace/.sync-logs-hierarchical/companyx_sync_state.json
ls -1t ~/workspace/.sync-logs-hierarchical/companyx_sync_summary_*.json | head -n 3
tail -n 100 ~/workspace/.run-logs/companyx/companyx_sync_hierarchical.log

판단 기준:

  • summary.finished_at 존재 여부
  • state.failed 값
  • 같은 시각대에 lock 충돌, skip, hangup 같은 메시지 존재 여부

D. lock 충돌을 볼 때

먼저 두 스크립트의 lock 경로를 확인합니다.

sed -n '1,220p' ~/workspace/infra/infra/scripts/bin/companyx_sync_nas_hierarchical.sh
sed -n '1,220p' ~/workspace/infra/infra/scripts/bin/companyx_sync_nas_fullscan.sh

판단 기준:

  • 같은 lock 파일이면 스케줄 충돌 가능성을 먼저 의심합니다.
  • 같은 분에 배치된 작업이면 cron 시각 충돌을 먼저 봅니다.

자주 쓰는 작업 패턴

패턴 1. NAS가 오늘 새벽 1시에 무엇을 했는지 확인

grep 'COMPANYX_NAS_SYNC_' /etc/crontab
ls -1t ~/workspace/.sync-logs/companyx_sync_summary_*.json | head -n 3
ls -1t ~/workspace/.sync-logs-hierarchical/companyx_sync_summary_*.json | head -n 6
tail -n 50 ~/workspace/.run-logs/companyx/companyx_sync_fullscan.log
tail -n 50 ~/workspace/.run-logs/companyx/companyx_sync_hierarchical.log

패턴 2. cron 시간만 빠르게 조정

sudo cp /etc/crontab /etc/crontab.bak_YYYYMMDD_HHMMSS
sudo vi /etc/crontab
grep 'COMPANYX_NAS_SYNC_' /etc/crontab

검증:

  • 변경된 시각이 실제 줄에 반영됐는지 확인
  • 다음 실행 시각 이후 summary 생성 여부 확인

변경 후 검증

  • 수정한 파일 내용이 기대값과 일치하는지 확인합니다.
  • 다음 실행 시각 이후 summary와 run log가 실제로 생기는지 확인합니다.
  • lock 충돌 수정이면 skip: previous sync still running 메시지가 사라졌는지 확인합니다.

금지선

  • 점검 없이 바로 cron부터 바꾸지 않습니다.
  • 백업 없이 /etc/crontab를 직접 덮어쓰지 않습니다.
  • state 하나만 보고 성공/실패를 단정하지 않습니다.
  • 51123 기준과 NAS 기준 경로를 섞어 쓰지 않습니다.

기록 원칙

  • 문제 없이 끝난 반복 점검은 journey/worklog/
  • 이상 징후, 스케줄 충돌, 실패 원인 분석은 journey/troubleshooting/

한 줄 결론

  • 51123에서 NAS를 원격 조정할 때는 51123 기준 확인 -> NAS 접속 -> 작업 유형별 절차 -> 변경 후 검증 순서로 같은 절차를 반복합니다.