내 글을 쓸 때 나는 항상 두 세 세트 를 쓰는 데 집중했습니다 . 시스템 구조에 대한 자세한 정보가 포함 된 완제품 점검표, 시스템 작동 방식, 온라인으로 연결될 때 발생할 수있는 고정 지점 및 추상적 인 설계 가정 등이 포함됩니다. 그 뒤에 가능한 문제와 해결 방법 목록, 시스템 작동 방식, 시스템 작동 방식에 대한 정보 및 고유 한 상황이 발생했을 때 올바른 방향으로 사람들을 지시하는 데 유용한 기타 정보가 포함 된 더 긴 섹션이 이어집니다.

마지막 직장에서 우리는 1 급 헬프 데스크 사람들이 일을 다시 시작할 수 있도록 문서를 작성해야했습니다. 이 필수 점검표는 일반적으로 서면 3 개월 이내에 만료되었습니다. 우리는 가능할 때마다 문제 해결 가이드를 작성해야했지만, 우발성 트리가 3 개 이상의 분기를 가지면 초록없이 문서를 작성할 수 없습니다.

마지막 직장을 떠날 때 떠나기 전에 100 페이지의 ‘내 일을하는 방법’매뉴얼을 보았습니다. 여기에는 추상적 인 점, 디자인 철학 및 통합 지점이 있습니다. 아마도 나를 대신 할 다른 시스템 관리자를 위해 글을 쓰고 있었기 때문에 추상적 인 개념을 취하여 구체적인 행동으로 바꿀 수있는 사람을 목표로 삼았습니다.

5 년이 지났는데 이것에 대한 나의 의견은 다소 바뀌었다. 모두 수동으로 문서 및 체크리스트 등의 문서는 문서의 계층 구조와 생산되는 양을 필요로하는 매우 가치있는 장소가있다. 그러나 그들은 매우 다른 청중을 목표로합니다.

점검 목록으로 문서

이런 종류의 문서화를위한 목표 시장은 어떻게 일을 하는지를 원하는 동료들입니다. 그들은 두 가지 유형으로 제공됩니다.

• 일을하는 방법을 알고 싶어하고 15 페이지의 매뉴얼을 살펴볼 시간이없는 동료들.
• 절차는 단계적으로 복잡하지만 한 번에 한 번만 실행하면됩니다.

조바심은 첫 번째 종류의 동인입니다. 동료가 실제로 출력을 90 문자 펄 정규식을 통해 파이프 해야하는 이유 를 알고 싶지 않을 수도 있습니다 . 단지 티켓을 닫으려면해야합니다. 이유를 알고 싶은 사람들을위한 체크리스트에 “이 워크 플로가 왜 이런 모습인지에 대한 자세한 설명을 보려면이 링크를 따라 가십시오”와 같은 문구를 포함하십시오.

두 번째 요점은 자주 실행되지 않지만 함정이 포함 된 절차입니다. 체크리스트는 특정 운명이 그냥 날아 다니는 것을 피하기위한 맵 역할을합니다. 점검 목록이 문서 저장소에 보관되어 있으면 이전 관리자가 HOWTO를 보낸 시간 동안 전자 메일을 검색하지 않아도됩니다.

제 생각에는 좋은 점검표 문서에는 가능한 실패 지점에 대한 섹션과 이러한 실패에 대한 응답도 포함됩니다. 이렇게하면 문서가 다소 커지고 동료의 TL; DR 응답이 트리거 될 수 있으므로 실패 모드와 해당 응답을 페이지 자체가 아닌 체크리스트의 링크로 만드는 것이 무의미한 체크리스트를 만듭니다. 하이퍼 텍스트를 받아들입니다.

수동 문서

이러한 종류의 문서를위한 목표 시장은 시스템 작동 방식에 대해 더 많이 배우려는 사람들입니다. 작업 방법 스타일 문서는이 문서에서 파생 될 수 있지만, 워크 플로우에서 내린 결정을 뒷받침하는 체크리스트 스타일 문서의 보충 자료로 더 일반적입니다.

이것은 다음과 같은 질긴 조각을 포함하는 문서입니다.

• 왜 이런 식으로 구성되어 있는지 설명하십시오.
  • 이 섹션에는 전체 구매 및 설치 방식을 둘러싼 정치와 같은 비 기술적 문제가 포함될 수 있습니다.
• 일반적인 실패 모드와 그에 대한 설명.
• 서면 및 사실상의 서비스 수준 계약에 대해 설명합니다.
  • 사실상 : “결승 주간에 실패하면 모든 문제가 발생합니다. 여름 방학 동안 다시 잠을 자고 아침에 처리하십시오.”
• 업그레이드 및 리팩토링 목표 설정
  • 나중에 정치가 다를 수 있습니다. 왜 처음에 소개 한 나쁜 생각들을 고쳐 보지 않겠습니까?

이는 전체 시스템에 대한 포괄적 인 이해를 얻는 데 매우 유용합니다. 간단한 인간-자동화 작업을 실행하기 위해 포괄적 인 이해가 필요하지 않습니다. 왜 어떤 일이 왜 그랬는지 알아 내고 다시는 그렇게하지 않아야 할 아이디어가 있어야합니다.

점검 목록이어야하는 재해 복구 설명서도 언급했습니다.

이해합니다, 당신은 내 동정심을 가지고 있습니다.

예, DR 문서는 가능한 체크리스트와 유사해야합니다.
예, DR 문서는 여러 가지 방법으로 인해 점검 목록에 가장 저항력이 있습니다.

DR 점검 목록이 다음과 같은 경우 :

1. 더스틴이나 카렌에게 전화하십시오.
2. 문제를 설명하십시오.
3. 다시 서.

당신은 문제가있다. 이것은 체크리스트가 아닙니다. 즉,이 시스템의 복구가 너무 복잡하여 건축가가 알아내는 것이 허용됩니다. 때때로 그것은 당신이 할 수있는 전부이지만, 가능하다면 그것을 피하려고 노력하십시오.

DR 문서에는 몇 가지 다른 것들에 대한 절차 점검표가 포함됩니다.

• 무엇이 잘못되었는지 파악하기위한 심사 절차를 통해 식별하는 데 도움이됩니다.
• 특정 장애 사례에 대한 복구 절차. 어느 지원 …
• 복구 중 인적 오류를 최소화하기 위해 미리 작성된 복구 스크립트
• 실패 사례, 발생 원인 및 의미에 대한 수동 스타일 문서

심사 절차는 때때로 일부 시스템에 대해 만들 수있는 모든 DR 설명서입니다. 그러나 오전 4시 콜 아웃은 이해하기 쉽고 복구를 담당하는 수석 엔지니어는 실제 문제를 더 빨리 해결할 수 있습니다.

일부 실패 사례에는 간단한 복구 절차가 있습니다. 문서화하십시오. 그것들을 문서화하는 동안 명령 목록이 특정 순서로 입력되는 경우를 발견 할 수 있는데, 이는 스크립팅의 훌륭한 사용 사례입니다. 96 포인트 복구 절차를 20 포인트로 전환 할 수 있습니다. 복구 절차 작업을 작업별로 매핑 할 때까지 무언가를 스크립팅 할 수 있는지 알 수 없습니다.

고장 사례에 대한 수동 스타일 문서는 복구 절차가 없거나 복구 절차가 실패한 경우에 사용되는 마지막 도랑 백스톱입니다. 그것은 그 문제를 겪고있는 다른 사람과 그 문제를 해결하기 위해 무엇을했는지 알아내는 데 필요한 구글 힌트를 제공합니다.

답변