검토됨 · Hosmio 리소스
시작하기 전에
애플리케이션 인벤토리, 클라이언트 연락처, 현재 운영자 및 가능한 대체자를 모으십시오. VPS를 사용할 수 없을 때도 접근 가능한 개요서 저장 장소를 마련하십시오. 보호된 비밀 저장소를 참조하십시오. 자격 증명을 문서에 붙여넣지 마십시오.
01
먼저 서비스 경계를 정의하십시오.
애플리케이션을 유용하게 유지하는 데 필요한 작업을 나열하십시오: 접근 검토, 운영 체제 업데이트, 런타임 변경, 데이터베이스 유지 관리, 백업, 모니터링 및 도메인 갱신. 이를 인프라 공급업체가 실제로 수행하기로 합의한 작업과 분리하십시오. 재설정 버튼, 선택적 백업 선택 또는 지원 연락처만으로는 관리형 서비스 계약이 성립하지 않습니다.
소유자가 아직 알려지지 않은 모든 항목을 기록하십시오. Hosmio의 경우, 최종 공급업체 개입 및 지원 범위는 확인이 필요합니다. 지금 자신의 책임을 계획하면 애플리케이션 사고가 호스트에 의해 자동으로 진단될 것이라고 가정하는 것을 피할 수 있습니다.
02
행동과 결정 권한을 할당하십시오.
| 활동 | 담당 역할 | 트리거 및 점검 |
|---|---|---|
| 애플리케이션 릴리스 | 애플리케이션 운영자; 지정된 백업 담당자 | 승인된 변경; 테스트 로그인 및 대표 작업 |
| 중단성 유지보수 | 고객 변경 승인자 | 영향 범위가 알려진 시간대; 명시적 진행/중단 결정 |
| 복구 훈련 | 복구 운영자 | 예정된 리허설; 복원된 레코드 및 첨부 파일 확인 |
| 인시던트 커뮤니케이션 | 현재 인시던트 책임자 | 중대한 영향 변경; 타임스탬프가 있는 인수인계 |
| 결제 예외 | 구매 담당자 | 불일치 또는 불확실한 결과; 사실적 결제 세부 정보 유지 |
역할은 팀이 연락 가능한 사람을 해당 역할에 배정했을 때만 유용합니다. 현재 배정을 개인 운영 노트에 기록하세요. 한 사람이 여러 역할을 맡을 수 있지만, 이 구분은 기술자가 실수로 고객을 대신하여 비즈니스 위험을 승인하는 것을 방지합니다.
03
변경과 그 중단 지점에 합의하십시오.
계획된 업데이트의 경우, 왜 필요한지, 무엇이 변경되는지, 영향을 받는 서비스와 알려진 상태로 되돌리는 방법을 기록하세요. 누가 중단을 승인할 수 있고, 점검이 실패하면 누가 작업을 중지할 수 있는지 명시하세요. 명시적 시간대가 있는 합의된 시간대를 사용하세요. 국제 팀에게 “업무 시간 외”는 모호합니다.
작업을 시작하기 전에 접근 권한, 복구 사본, 변경되는 정확한 버전 또는 구성을 확인하세요. 팀이 인수 점검을 통과하거나 복구 계획을 실행해야 하는 시점을 정하세요. 실제 리허설이 그 기대를 뒷받침하지 않는 한 롤백을 즉각적이라고 설명하지 마세요.
04
행동으로 이어지는 신호를 선택하십시오.
사용자 작업부터 시작하세요. 대표 계정이 로그인하여 예상 레코드를 읽고 안전한 작업을 완료할 수 있습니까? 실패를 설명하는 데 도움이 되는 리소스 및 종속성 점검을 추가하세요. 백그라운드 큐가 더 이상 진행되지 않는 동안에도 애플리케이션은 기본 상태 점검 요청에 응답할 수 있습니다.
프로젝트의 필요와 관찰을 바탕으로 에스컬레이션 임계값을 선택하세요. 예시 포털은 두 번의 예정된 작업 점검 실패를 보편적 장애 정의가 아니라 조사 촉구로 취급할 수 있습니다. 점검이 어떻게 실행되는지와 운영자가 다음에 무엇을 점검해야 하는지 기록하세요. 책임 수신자가 없는 경고는 대응 체계를 만들지 않습니다.
05
사고 전에 대체를 준비하십시오.
교체 운영자가 코칭 없이 인벤토리, 보호된 접근 절차, 최신 변경 기록 및 복구 노트를 찾을 수 있어야 합니다. 그들은 알려진 사실과 검증되지 않은 가설을 구분할 수 있어야 합니다. 단지 접근을 편하게 하기 위해 개인 계정을 공유하기보다 역할에 적합한 권한을 부여하세요.
인시던트 타임스탬프를 명확하게 유지하세요. RFC 3339는 UTC 또는 명시적 오프셋을 사용한 타임스탬프 표현을 정의합니다. 2026-09-12T14:00:00Z 와 같은 기록은 설명 없는 로컬 시계 값을 피합니다. RFC 3339: 인터넷 타임스탬프 ↗ 시간대 인수인계 가이드를 참조하여 현재 소유권을 더 완전하게 이전하세요.
06
개요서를 리허설하고 격차를 기록하십시오.
문서에 의존하기 전에 탁상 훈련을 실시하세요. 주 운영자를 이용할 수 없는 동안 가상의 실패한 백그라운드 작업을 제시하세요. 교체 담당자에게 영향, 허용된 조치, 승인 경로 및 다음 업데이트를 식별하도록 요청하세요. 개요가 존재함을 입증하기 위해 실제 서비스 변경을 수행하지 마세요.
누락된 권한, 불분명한 소유권 및 접근할 수 없는 문서를 담당자가 있는 조치로 기록하세요. 직원, 통합, 복구 목표 또는 공급업체가 변경되면 개요를 다시 검토하세요. 완료란 다른 권한 있는 사람이 프로세스를 따르고 그 한계를 설명할 수 있음을 의미하며, 지속적인 지원 팀이 구축되었음을 의미하지는 않습니다.
계속 진행: 공급업체 이탈 리허설 그리고 인시던트 개요 템플릿. 문제 발생 시 사용할 수 있을 만큼 운영 개요를 간결하게 유지하고 필요 시 더 자세한 절차로 연결하세요.