시작하기 전에
- 위키를 읽고, 편집하고, 관리할 사람들의 목록입니다.
- 선택한 위키와 해당 버전에 대한 문서입니다.
- 운영 노트를 위한 장소와 복구 자격 증명을 위한 별도의 통제된 위치입니다.
1. 위키가 수행할 작업을 설명하세요.
한 문장으로 시작하세요: “회원들은 이 위키를 사용하여 공유 워크숍 운영을 위한 최신 지침을 찾습니다.” 이 가상의 목적은 “모든 것을 온라인에 올린다”보다 좁습니다. 이는 관리 가능한 첫 번째 컬렉션을 제안합니다: 개회 절차, 장비 노트, 회의 결정 사항. 개인 연락처 정보와 접근 자격 증명은 별도의 결정이 필요합니다. 편리한 검색 상자가 그것들을 수집할 이유가 되지 않습니다.
독자가 달성해야 할 목표를 나열하세요. 예: 최신 절차 찾기, 참조된 다이어그램 열기, 오래된 페이지의 소유자가 누구인지 알기. 나중에 애플리케이션을 평가하기 위해 실제 콘텐츠의 작은 샘플을 선택하세요. 회원 수만으로 메모리 요구 사항을 추론하지 마세요. 업로드, 색인 생성, 확장 기능, 동시 작업이 워크로드를 변경할 수 있습니다.
2. 의존성에 대한 페이지를 하나 만드세요.
이 예를 시작 지도로 사용한 다음, 선택한 애플리케이션의 레이아웃으로 모든 가정을 대체하세요. “소유자”는 해당 구성 요소를 설명하고 복구할 수 있는 사람을 의미하며, 반드시 설치한 사람일 필요는 없습니다.
| 부분 | 노트북에 포함할 내용 | 복구 질문 |
|---|---|---|
| 웹 애플리케이션 | 버전, 구성 위치 및 서비스 소유자 | 다른 유지관리자가 동일한 버전을 재구축할 수 있나요? |
| 데이터베이스 | 엔진, 버전 및 백업 방법 | 어떤 스냅샷이 파일과 함께 있어야 하나요? |
| 이미지 및 첨부 파일 | 저장 경로 및 증가 추정 | 복원된 페이지가 다이어그램을 여나요? |
| DNS 및 HTTPS | 도메인 계정 소유자 및 인증서 방법 | 위키 없이 누가 접근을 복구할 수 있나요? |
| 이메일 및 예약 작업 | 발신자, 일정 및 실패 소유자 | 전달이 실패할 때 여전히 작동하는 것은 무엇인가요? |
검색도 기록하세요: 애플리케이션의 일부인지, 재구축 가능한 색인인지, 아니면 다른 서비스인지? 애플리케이션 문서에서 재구축 방법을 확인할 때까지 색인을 버릴 수 있다고 가정하지 마세요.
3. 읽기, 편집, 관리를 분리하세요.
워크숍 예에서 회원들은 절차를 읽고, 작은 편집 그룹이 절차를 변경하며, 두 명의 권한 있는 유지관리자가 계정을 관리합니다. 호스트 관리는 별도의 책임입니다. 누가 페이지를 게시하고, 파일을 업로드하고, 콘텐츠를 내보내고, 권한을 변경할 수 있는지 기록하세요. 떠나는 회원이 어떻게 접근 권한을 잃는지, 그리고 그들이 유지 관리했던 페이지를 누가 검토하는지 결정하세요.
애플리케이션 권한 규칙은 예상치 못한 방식으로 결합될 수 있습니다. 예를 들어 BookStack은 사용자 역할 간 능력을 결합하고 콘텐츠 수준 재정의를 지원합니다. 선반 권한은 책에 자동으로 계단식으로 적용되지 않습니다. 관리자 계정뿐만 아니라 일반 회원 계정을 사용하여 실제 결과를 확인하세요. BookStack 역할 및 권한.
4. 복구 세트를 함께 보관하세요.
각 백업 세트에 날짜, 애플리케이션 버전, 어떤 데이터베이스와 파일 복사본이 함께 속하는지에 대한 메모를 제공하세요. 위키가 실패해도 접근할 수 있는 곳에 지침을 보관하세요. 비밀은 적절한 비밀 저장소에 보관하세요. 노트북에는 값 자체를 재현하지 않고 누가, 어디서 검색할 수 있는지 식별해야 합니다.
구체적인 애플리케이션 예로, BookStack의 백업 지침은 데이터베이스 레코드와 구성, 업로드된 이미지, 첨부 파일, 테마를 다룹니다. 구성에는 암호화된 애플리케이션 데이터와 관련된 키가 포함되므로, 보이는 페이지만 복사하면 중요한 복구 자료를 놓치게 됩니다. 해당 버전의 애플리케이션 자체 절차를 따르세요. BookStack 백업 및 복원.
독립적인 복사 대상을 선택하고 접근 가능한 상태로 유지되는지 확인할 책임자를 지정하세요.
5. 그룹이 지속할 수 있는 일상을 합의하세요.
유지관리자가 실제로 지킬 수 있는 검토 주기를 선택하세요. 각 검토 시 실패한 백업, 대기 중인 애플리케이션 업데이트, 첨부 파일 증가, 더 이상 접근이 필요 없는 계정을 살펴보세요. 긴급 보안 업데이트는 더 이른 주의가 필요할 때 해당 일상 외에 유지하세요. 막연한 우려 목록을 계속 늘리기보다 다음 조치와 담당자를 기록하세요.
예에서 편집 그룹은 짧은 “검토 필요” 목록도 확인합니다. 소유자가 없는 장비 절차는 조용히 권위 있어 보이게 두는 대신 검토가 필요하다고 눈에 띄게 표시해야 합니다. 중요한 업데이트 전에 작업 버전, 애플리케이션의 마이그레이션 지침, 검증 실패 시 사용할 복구 지점을 기록하세요.
6. 유용한 경로를 입증한 후, 부족한 부분을 기록하세요.
별도의 테스트 복사본에서 두 번째 유지관리자에게 샘플 페이지를 찾고, 첨부 파일을 열고, 권한 있는 편집을 수행하고, 해당 계정이 허용하지 않아야 하는 작업을 시도하도록 요청하세요. 콘텐츠 변경 후 검색 결과를 확인하세요. 예상 및 관찰 결과를 기록하세요. 성공적인 로그인만으로는 위키가 사용 가능하거나 올바르게 제한되었음을 증명하지 않습니다.
첨부 파일이 없으면 데이터베이스 레코드를 편집하기 전에 저장 위치와 백업 세트를 비교하세요. 권한이 다르면 접근을 넓히기 전에 계정 역할과 콘텐츠 재정의를 검사하세요. 애플리케이션이 시작되지 않으면 연습을 중단하고 버전 또는 구성 불일치를 기록하세요. 이는 수행할 승인 단계이며, Hoszen 인프라의 보고된 테스트가 아닙니다.
7. 나가는 경로를 남겨두세요.
내보낼 대표적인 챕터 하나를 선택하고 누군가 원래 위키 없이 읽을 수 있는지 물어보세요. 읽을 수 있는 복사본은 복구 세트와 별개의 산출물로 취급하세요. 계정, 권한 또는 애플리케이션 설정을 보존하지 않을 수 있습니다. 콘텐츠가 변경될 때 이 종료 복사본을 누가 유지 관리할지 합의하세요.
완성된 계획은 옆에 있어야 합니다 서비스 인벤토리, 대체하는 것이 아닙니다. 계속하세요 휴대용 내보내기 폴더 및 복원 훈련. 목표는 다른 권한 있는 사람이 이해하고 복구할 수 있는 위키입니다. 이 가이드로는 어떤 애플리케이션도 설치되지 않습니다.
이 노트 뒤의 문서
실제로 실행하는 버전에 대한 설명서를 사용하십시오. 이 예시는 계획 자료이며, Hoszen VPS에서의 테스트 기록이 아닙니다.