작업, 프로세스 및 환경을 어떻게 문서화하고 있습니까?

위키 형식을 사용하고 있습니까? 그렇다면 어떤 제품입니까? (미디어 위키, 합류점, 쉐어 포인트 등)

지식 기반을 만들었습니까? (문제 / 솔루션 중심의 짧은 문서.)

효과적인 문서를 만들면 어떤 어려움을 겪고 있습니까? 휴일에 외출 할 때 전화를받지 않습니까?

저에게는 문서를 완성하는 것과 관련된 조직적인 "관성"이 종종 있다는 것을 알게되었습니다. 작업을 수행 할 수있는 다른 종류의 사람인 것 같습니다. 그런 다음 작업을 수행 한 방법 에 대해 생각하고 다른 사람이 작업을 수행 할 수 있도록 설명합니다.

최신 정보

지금까지 답변은 다음과 같습니다.

• 합류
• 플렉스 위키
• 포그 버그
• 미디어 위키 (fckeditor와 같은 플러그인 포함)
• 공유 지점
• 트 위키
• 워드 / 엑셀 / Visio Docs
• 문서화 된 스크립트

편집 : 모니터링 시스템으로 네트워크를 암시 적으로 문서화하지 않습니까? Nagios는 항상 네트워크 구조를 반영하기 위해 부모 지시문을 사용하도록 권장했으며 notes_url 지시문은 위키 또는 기타 브라우저 기반 문서에 링크 할 수 있도록 설계되었습니다. 여기에서 "문서"는 모니터링 시스템의 "살아있는 문서"와 위키의 더 자세한 오프라인 문서로 나뉩니다. 내가 Nagios를 응시하는 데 많은 시간을 소비하기 때문에 가능한 한 유익한 정보를 얻기 위해 노력하는 것이 합리적입니다.

툴링에 대한 주석.

우리는 온라인 위키를 시험해 보았지만 개인적인 취향이지만 문서 구조와 문서 서버에 가장 중요하게 연결되어야하는 많은 제한 사항을 발견했습니다.

오프라인이거나 현장에있는 경우 연결되는 것은 심각한 문제입니다 (확실히 SSL 연결 등으로 현장을 완화 할 수 있음).

현재 문서화 프로세스는 다음과 같습니다.

• 정적 HTML 생성기
• 마크 다운 구문
• 분산 버전 관리 시스템

우리는 문서를위한 '형식적인'레이아웃을 가지고 있으며 메뉴의 구조 (및 비주얼 스타일링을위한 관련 CSS)를 제공합니다.

정적 HTML 생성기

우리는 기반으로 집에 정적 HTML 생성기 사용 cubictemp : 및 기타 도구의 숫자 pygments , docutils을 .

우리 / 우리의 시스템 관리자 / 프로그래머 대부분은 미적으로 아름답지만 그러한 건축에 대한 조정이 전혀 없기 때문에 생성 된 페이지는 분명하지 않습니다.

그러나 HTML 파일 형식을 망칠 걱정이나 다운로드를 위해 '서버'에서 찾을 위치에 대해 걱정할 필요없이 구성 파일, 샘플 스크립트, pdf 등을 포함시킬 수 있습니다.

HTML이 아닌 경우 폴더에 드롭하고 URL 링크를 추가하십시오.

HTML은 레이아웃을위한 '잠재적'구조를 제공하고, 지식 / 컨텐츠 항목 (메뉴, 컨텐츠 테이블 등을 만들 수있는 것과 같은 기본 구조 메커니즘) 사이의 '링크'를 비판적으로 제공합니다. HTML을 사용하면 각 사용자는 이제 lighttpd이든 작든 아파치 나 IIS로 가득 찬 작은 웹 서버를 컴퓨터에서 실행하십시오.

우리의 모든 기계에는 기본 HTML 서빙에 대한 불만이 있으며 우리에게 충분히 잘 작동합니다.

MARKDOWN 구문.

우리는 MARKDOWN, Textish 및 reStructuredTEXT 의 나쁜 버전을 사용하여 '크리에이티브'주스가 HTML에 대해 걱정할 필요없이 문서를 작성할 수 있도록합니다.

또한 모든 사람들이 자신이 좋아하는 편집기 (Windows 및 * Nix에서는 Scintilla를 사용함)를 사용하고 다른 사람들은 vi / vim을 사용합니다.

분산 버전 관리 시스템.

우리는 Git 을 사용 하여 사용자간에 문서를 '배포'합니다. 아, 우리는 그것도 버전 관리 용량을 사용합니다.

우리에게 가장 큰 장점은 서버에 연결하지 않고도 '완료된'저작물을 게시하지 않고도 문서를 업데이트 할 수 있다는 것입니다. 우리는 모두 문서의 동일한 부분이나 다른 부분에서 작업하거나 정보를 사용할 수 있습니다.

개인적으로, 나는 Wiki는 물론 블로그를 업데이트하기 위해 서버에 묶인 것을 싫어합니다. 힘내는 우리를 위해 잘 작동합니다.

워크 플로우에 대한 주석

Wiki는 지식 보급 / 목록 화를위한 "패션"으로 보이지만 다른 곳에서는 모든 프로세스를 유지하기가 어려워지고 팀의 요구를 가장 잘 지원하고 지속 가능한 도구 조합을 찾는 데 시간이 걸립니다.

더 나은 솔루션은 발견되고 의무화되지 않습니다.

우리는 내가 일하는 곳에서 DokuWiki 를 사용하기 시작했습니다 .

Dokuwiki 웹 사이트에서 :

DokuWiki는 표준을 준수하고 사용하기 쉬운 위키로 주로 모든 종류의 문서 작성을 목표로합니다. 개발자 팀, 작업 그룹 및 소규모 회사를 대상으로합니다. 간단하지만 강력한 구문을 사용하여 Wiki 외부에서 데이터 파일을 읽을 수있게하고 구조화 된 텍스트를 쉽게 만들 수 있습니다. 모든 데이터는 일반 텍스트 파일로 저장되며 데이터베이스가 필요하지 않습니다.

Dokuwiki는 데이터베이스가 필요하지 않기 때문에 구현하기가 가장 쉽고 설치가 쉽다는 것을 알았습니다. 또한 기존 Active Directory 계정 로그온을 사용 하는 대신 모든 사람에 대한 계정을 만들어야 하는 추가 기능 모듈도있었습니다 . 또한 일반적인 버전 관리 기능을 통해 누가 어디에 어디에 게시했는지 알 수 있으며 필요한 경우 이전 버전으로 쉽게 롤백 할 수 있습니다. 또한 사용자 정의 가능한 홈페이지가 포함되어있어 환경에 가장 적합한 유형의 컨텐츠를 쉽게 변경할 수 있습니다.

차트에 맞는 다른 것들에 대한 Doku Wiki 또는 Sharepoint.

당신은 위키에 게시하는 데 꽤 빨리 익숙해지며 구문은 실제로 그렇게 복잡하지 않습니다. 정보를 구성하는 것이 매우 쉽고 나중에 다른 사람이 쉽게 찾을 수 있습니다.

visio를 사용하여보다 명확한 설명을 위해 그래프를 만듭니다 (JPEG로 내보내기).

우리는 위키를 사용하고 있습니다. 실제로, 우리는 미디어 위키를 사용하고 있습니다. 미디어 위키 외에 , 시맨틱 미디어 위키 확장이 설치되어 있는데, 이는 실제로 미디어 위키를 카테고리, 제목, 내용 등으로 쿼리 할 수있는 느슨하게 형식화 된 데이터베이스로 변환합니다.

예를 들어 클러스터 F를 통해 라우팅되는 모든 네트워크 cname을보고 싶다고 가정 해 봅시다. Special : Ask 페이지를 사용하여 [[Category : cname]] [[destination :: cluster_f]]을 쿼리하기 만하면됩니다. 대상을 cluster_f로하여 cname으로 분류 된 모든 페이지를 반환합니다.

우리는 수백 명의 매우 이질적인 고객을 지원하므로 문서를 중앙 위치에 보관하고 (특별한 사례를 문서화하고 전체적으로 묶을 수 있도록 교차 연결) 큰 도움이됩니다. 분명히, 우리의 문서는 유지되어야하지만, 큰 데이터 세트를 최신 상태로 유지하기위한 미디어 위키 툴킷은 이미 상당히 성숙되어 있기 때문에 유지 보수에 대한 '정원사'접근 방식을 더 많이 사용할 수 있습니다.

올바른 플러그인을 사용하면 Trac 은 티켓과 위키 시스템을 결합 할 수 있습니다. 이렇게하면 티켓이 위키 기사에 쉽게 링크되고 그 반대도 마찬가지입니다.

내가 좋아하는 몇 가지 플러그인 :

• 개인 티켓 플러그인 . Trac은 모든 티켓과 응답이 공개되는 버그베이스로 구축되었습니다. IT 티켓 시스템에는 적합하지 않지만이 플러그인은이를 해결합니다.
• Trac에 WYSIWYG 플러그인 . 대부분의 사람들은 당신을 행복하게하기 위해 위키 구문을 배우지 않을 것입니다. 이를 통해 티켓과 위키 페이지 모두에 대해 '당신이 보는 것이 무엇인지'편집기를 제공합니다.

Trac에 대한 몇 가지 추가 사용자 정의가 있습니다. Trac 시스템을 원하는대로 설정하고 사용자 정의하는 것은 어렵지 않습니다!

이전 작업에서 Twiki를 사용했습니다. 꽤 잘 작동했습니다.

그 다음으로, 나는 대부분의 작업을 자동화하고 스크립트를 문서화하는 경향이 있습니다 (항상 열정이 많지는 않지만 여전히 ...). 스크립트를 문서화하는 과정은 스크립트를 디자인하는 과정에서 쉽게 수행되므로 실제 오버 헤드는 없습니다 ...

스크립트와 버전 제어를 함께 사용하면 트릭을 상당히 잘 수행 할 수 있습니다.

JIRA, Confluence 및 Word Documents의 혼합.

지식을 제도화

우리는 문서부터 시작했습니다. 그런 다음 그중 일부를 Sharepoint 라이브러리에 저장했습니다. 그런 다음 최근에 Sharepoint wiki로 옮겼습니다. Sharepoint의 Wiki는 표와 같은 것들에 대한 그래픽 지원 및 서식 지원에서 원하는 것을 남겨 두지 만 Wiki의 저 마찰 방식으로 빠르게 업데이트합니다. 텍스트에 적합하며 내장 편집기는 기본적인 HTML 형식과 순서 / 순서가없는 목록을 허용합니다. Sharepoint에 대한 다른 저렴한 대안이 있습니다.

또한 지원 데스크 소프트웨어 인 Numara 's Track-It에 지원 티켓에 대한 비공식 지식 기반이 있습니다. 완벽하지는 않지만 작동합니다.

직원이 기관 화 된 지식을 사용하도록하기

지식을 제도화하는 것이 전쟁의 한 부분 일 뿐이라는 귀하의 평가에 동의합니다. 당신의 조직과 사람들이 "먼저 연구하고, 두 번째로 물어 보는"방법에 익숙하지 않다면, 옛날 방식이 우세하다는 것을 알게 될 것입니다. 직접 검색하는 것보다 내 옆에있는 사람

이를 처리하기 위해서는 몇 가지 변경 관리가 필요합니다. 소규모 팀 이상에 영향을 미치는 가장 성공적인 변화 이니셔티브와 마찬가지로 관리 승인 및 지원을받는 데 도움이됩니다. 당신은 정말로 두 가지 방향으로 새로운 행동을 만들어 내야합니다. 누군가는 지식을 포착해야하고 사람들은 그것을 사용해야합니다. 더 어려운 것은 사람들이 해당 데이터를 최신 상태로 유지해야한다는 것입니다.

단지 몇 가지 아이디어 : 아마도 해결 된 티켓과 이슈가 폐쇄 된 것으로 간주되기 전에 지식 기반이나 위키에 문서화되어야한다는 공식 정책의 형태로 격려가 필요할 것입니다. 또한 일반적으로 질문을받는 지식 리더는 항상 요청에 대한 답변 만 제공해서는 안됩니다. 사람들이 위키를 가리 키도록하고 먼저 위키를 확인하는 데 익숙해 져야합니다. 또 다른 문제는 사용자가자가 진단을 위해 데이터를 사용할 수 있도록하여 기술 담당자가 저글링해야 할 또 다른 항목이되기 전에 문제를 해결할 수 있도록하는 것입니다.

유용한 것은 헬프 데스크 시스템에 StackOverflow 및 ServerFault와 유사한 시스템이 있다는 것입니다. 질문을 입력하면 검색 엔진이 유사한 항목을 찾아서 제공하므로 사용자는 질문을 제출하기 전에도 해당 항목을 볼 수 있습니다.

마지막 두 곳에서 Wiki 문서로 쉽게 만들 수없는 특정 문서 (예 : DRP 및 일회성 업그레이드 계획)가 포함 된 문서 라이브러리와 함께 Sharepoint의 Wiki를 사용했습니다. 그 문서들은 위키 내에서 링크를 가지고있었습니다. Wiki는 많은 사람들이 편집 할 수 있고, 버전 관리 기능이 내장되어 있고, 쉽게 검색하고 액세스 할 수있는 등이 영역에서 많은 이점을 가지고 있습니다. 메모 나 아이디어를 빠르게 기록하려면 OneNote 또는 화이트 보드를 사용합니다.

포럼 형식 (Lotus Notes 및 MS Sharepoint 모두)으로 일부 지식 기반을 만들었지 만 특정 문제가 이미 해결되었는지 확인하기 위해 사람들을 통해 정보를 찾는 경우는 거의 없습니다. 이러한 솔루션은 매우 강력하고 효과적인 검색 엔진을 갖춘 첫날부터 이루어져야합니다.

휴일에있을 때 사용할 수있는 문서를 만들려면 부모 중 한 사람에게 지시하는 것처럼 작성하십시오. 이것은 100 % 바보가 아니지만 때때로 도움이됩니다. 누가 읽고 있는지에 따라 다릅니다.

쉐어 포인트가 좋습니다.

검색 기능은 거의 모든 유형의 문서를 색인화 할 수있어 문서 검색이 매우 쉽습니다.

예를 들어 구축하는 각 서버에 대한 표준 정보 시트가있는 경우 더 쉽게 만들 수있는 템플릿을 사용할 수 있습니다.

또한 문서의 버전을 지정할 수 있으므로 문서 변경 내역을 기록 할 수 있습니다.

또한 문서 라이브러리에 포함 된 파일은 웹을 통해, 또는 Outlook을 통해 즉시 사용할 수 있습니다.

우리는 몇 년 동안 MediaWiki (fckeditor와 함께)를 사용해 왔지만, 사진 (예 : 스크린 샷) 처리가 더 쉬울 경우 좋을 것이라고 말해야합니다. 그리고 검색 기능이 필수적이지만 MediaWiki의 검색은 종종 페이지를 빠뜨립니다. 아마도 그것은 더 나은 검색을 배우는 문제 일 것입니다 (다른 사람들이 귀하의 작업을 수행 할 수있는 간단한 방법을 갖는 목적을 상실합니다)

지금은 위키에 반드시 필요한 것은 아니지만 모든 것을 MS Sharepoint로 옮기는 것에 대해 이야기하고 있습니다. Sharepoint는 위키의 장점 중 일부를 무효화하는 방식으로 전체 문서 검색 을 수행 할 수 있다고 생각 합니다.

(현재 문서를 모두 포팅하는 과정을 기대하지는 않습니다 :))

우리는 위키를 사용하고 있습니다. 구문에 익숙해지기는했지만, 우리가 사용하는 구문 (twiki)은 데이터를 텍스트 파일로 완전히 저장합니다. 이를 통해 재난 발생시 쉽게 읽을 수 있으며 어디에서나 복원 할 수 있고 grep을 통해 명령 줄에서 검색하고 원하는 텍스트 편집기에서 읽을 수 있습니다.

모든 서버에는 변경 관리 정보, 시작 / 종료 및 구성 정보와 dns, 방화벽 및 자산 정보에 대한 표준 하위 페이지 모음이있는 페이지가 있습니다.

우리는 3 개의 서버에 분산되어있는 단어 문서와 몇 개의 폴더를 알고 있는지 혼합하기 위해 일부 버전의 Sharepoint 서비스로 이동할 준비를하고 있습니다. 현재 우리는 여기에 설명 된 문서에 대한 하이퍼 링크를 포함하는 방대한 Excel 스프레드 시트를 가지고 있습니다.

가장 좋은 방법은 아니지만 회사가 시작했을 때 내부 문서를 처리하는 방법을 계획하지 않았고 각 그룹에 맡겨 자신의 문서를 정렬하고 저장하는 방법을 결정했습니다. 이제 우리는 Sharepoint 오퍼링 중 하나 인 통합 시스템으로 통합하려고합니다.

내가 일하는 NGO에서는 중요한 절차를 위해 폴더에 배치 된 텍스트 파일을 사용합니다. 개인적으로 시스템 관리자 / 웹 개발자 하이브리드로서 트리 디렉토리에 흩어져있는 텍스트 파일의 지식 기반을 사용하고 있습니다. 그것이 Memex 이며 거의 모든 것을 (개인, 작업 등) 기록합니다. 이 체계는 텍스트 처리를 위해 실제 스위스 군용 칼인 Jedit 를 사용하여 관리하는 것이 매우 쉽습니다. 개요 플러그인, 코드 접기 및 하이퍼 검색 기능이 필수적이라는 것을 알았습니다. 이 모든 것이 rsync에 의해 ssh 액세스 가능 원격 서버에 안전하게 백업됩니다.

부부와 것을 Makelink 파이어 폭스 확장 하고 완벽한 북마크 관리자가 있습니다.

우리 는 닷넷과 오픈 소스 인 flexwiki를 사용 합니다.

음 ... 포그 버그는 어때요? :)

컨텐츠 및 SharePoint에 ScrewTurn을 사용하여 문서 / 이미지를 저장합니다.

여기에 흥미로운 것들이 있습니다 -나는 금고의 암호에 관한 것을 좋아합니다.

grep으로 빠른 검색을 위해 텍스트 파일 조합을 사용합니다. 보다 체계적인 심층 문서 모음 (Visio 다이어그램 등)을 제공하는 SharePoint.

Google Apps (엔터프라이즈) 고객으로서 Google 사이트 도구 인 위키 "맛"을 사용합니다. 사용하기 쉬우 며 관리자와 개발자들로부터 큰 호응을 얻었습니다.

다른 질문에 대답하기 전에이 질문을 보지 못했지만 여기에갑니다.

우리는 많은 도구와 방법을 사용합니다.

• 인프라 구성 요소 및 소프트웨어의 기능 사양 .
• 두 개의 합류 위키 . 하나는 회사 내부 문서 (정책, 절차, 내부 인프라 및 IT 등)와 오픈 소스 소프트웨어 제품을위한 것입니다.
• RSpec 및 오이 테스트. 우리의 소프트웨어는 대부분 루비로 작성되었으며, BDD / TDD를 연습 하므로 사양 테스트는 실제 코드와 문서를 구동합니다.
• 인라인 코드 문서. 우리 는 코드 주석에 RDoc 마크 업을 사용 합니다.
• 선언적 구성 관리 ( Chef ). 우리의 모든 서버는 Chef로 관리되며, Chef는 레시피와 요리 책에있는 열렬한 리소스를 통해 "자체 문서화"합니다.

Confluence는 매우 유연하고 강력하며 기능이 완벽하기 때문에 Jira 와 같은 티켓 관리 소프트웨어와 연계되어 있기 때문에 Confluence를 좋아 합니다.

내가 근무했던 이전 회사에서는 다양한 도구와 방법을 사용했으며 많은 사람들이 모든 것을 위해 하나의 포괄 리소스 (위키와 같은)를 유지하려고 노력했습니다. 문제는 그 주제를 다루는 데 적합하지 않은 단일 도구로 다양한 주제를 문서화하는 것이므로 정보를 마이그레이션하기가 어렵 기 때문에 많은 것들이 전혀 문서화되지 않는다는 것을 의미합니다. 유닉스 / 리눅스 괴짜로서 각 작업에는 특정 도구가 필요하며 그 도구는 그 작업에 매우 적합해야한다고 생각합니다.

이 질문은 아주 잘 중복 이 하나 나는 거기에 내 대답을 옮겼습니다.

회사에 대한 대부분의 문서를 작성했으며 여기에서 작업을 시작할 때 설정 한 형식은 편집 가능한 원본 용 MS Word이며 읽기 전용 일반 릴리스 용 PDF로 내보냈습니다. 한 사람 만 문서를 업데이트하는 프로젝트에는 상당히 효과적이며, 그 사람은 보통 나이므로 관리자는 변경할 필요가 없습니다.

코드 검토를 위해 "Peer Review"확장을 사용하면서 Trac로 버그 및 향후 작업을 문서화하기 시작했습니다 . 협업하기 쉽고 탐색하기 쉽기 때문에 팀의 큰 호응을 얻었습니다. 다른 몇몇 팀원들은 사양, 테스트 절차 및 매뉴얼과 더 많은 협업을 시작하기를 원했기 때문에 매뉴얼과 같은 공개 문서 용 PDF로 내 보내진 DocBook / XML 및 스펙과 같은 내부 문서 용 Trac WIKI 페이지를 찾고 있습니다 시험 절차.

내 생각에 문서 형식을 선택할 때 가장 큰 문제는 다음과 같습니다.

1. 쉽게 만들 수 있습니까?
2. 유지 관리가 용이합니까?
3. 다른 사람이 작성한 경우 유지 관리하기가 쉽습니까?
4. 번거 로움없이 다른 형식으로 내보내거나 변환 할 수 있습니까?

1-3은 내 인생을 더 편하게 만들고, 제 정신을 잃지 않고 문서를 빠르게 제작하는 데 중요합니다. 형식이 계속 바뀌기 때문에 네 번째 형식은 고객 쪽에서 가장 중요하다고 생각합니다. Microsoft Word 2003 형식은 영원히 사용되지 않으며 현재 PDF를 구현하지도 않습니다. OS 나 문서 선택의 종류에 상관없이 모든 고객이 문서를 읽을 수 있도록해야합니다.

우리는 SemanticMediaWiki를 포함한 다양한 플러그인과 함께 MediaWiki를 사용합니다. SMW는 MediaWiki 설치를 자유롭고 자유로운 형태의 관계형 데이터베이스로 전환하여 자유롭게 문의 할 수 있기 때문에 좋습니다. 웹 사이트가 어느 서버에 있는지 알아야합니까? 페이지를 방문하십시오. 어떤 웹 사이트가 서버에서 호스팅되는지 알아야합니까? 쿼리를 실행하면 각 웹 사이트 페이지의 적절한 태그를 기준으로 페이지 이름이 선택됩니다.

나는 내가 사용한 문서 시스템이 아니라 내가 사용한 것으로 보았고 아주 좋은 것으로 대답 할 것이다 : http://stackexchange.com/

stackexchange는 serverfault에서 실행되는 Q & A 플랫폼입니다. 기술적으로 정확히 동일하지는 않지만 여기서는 동일한 것으로 가정 할 수 있습니다.

Fogbugz가 사용합니다 .

Fogbugz 직원 의 흥미로운 블로그 게시물이 있습니다.

제품 사양 이외의 모든 목적을 위해 회사 위키와 토론 양식이 치명적인 타격을 입었다 고 생각합니다.

...

지원 플랫폼으로 FogBugz.StackExchange.com을 사용하기 시작한 이후로 동일한 질문에 두 번 답변 한 적이 없습니다. 비공개 대면 Q & A에 사용하는 내부 SE 서버도 있으며 동일한 원칙이 적용됩니다.

고객 대면 기술 자료 및 내부 기술 자료에 대해 스택 교환을 사용합니다.

이러한 지식 교환 Q & A 플랫폼이 회사 위키를 대체 할 것인지 알고 싶습니다.

이전 고용주에서 폴더에 함께 수집 된 Word, Excel 및 Visio 파일을 사용했습니다. 내 책상의 바인더에 모든 내용의 하드 카피가 보관되었습니다. 나는 유일한 IT 담당자 였으므로 다른 사람이 정보에 액세스 할 필요가 거의 없었습니다.

현재 고용주에서는 Exact Software의 Macola ES를 사용하지만 내장 문서 편집기를 사용하는 것보다 Word로 문서를 작성하여 첨부 파일로 Macola에 업로드하는 것을 선호합니다.

직장에서 ScrewTurn Wiki를 Windows 개발 서버 중 하나에 놓고 SQL Server에 연결했습니다. 실제로 잘 작동하고 빠르게 실행되며 주로 문서화를 방해합니다. 배포 된 지 2 주 만에 이미 약 60 페이지의 정보를 추가했으며 팀 전용 (~ 10 명)입니다.

지금까지는 현재 및 과거 프로젝트에 대한 정보를 유지하고 처음부터 새로 빌드하는 방법, URL 및 팀에 새로운 개발자를위한 기타 중요한 정보와 같은 애플리케이션에 대한 정보를 추가하기 시작했습니다.

위키에서 내가 가장 좋아하는 페이지 중 하나는 도구 및 라이브러리 페이지입니다. 여기에서 자주 사용하는 자주 사용하는 생산성 도구 및 라이브러리에 대한 정보를 추가하기 시작했습니다. 그 예로 Windows에서 텍스트 검색을위한 grepWin이 있습니다.

사용 가능한 전체 위키 범위를 확인하고 원하는 사용법, 기능 및 배포 환경에 적합한 것을 찾으십시오. 사용하기 쉽기 때문에 ScrewTurn을 선택했으며 로컬 WinServer에는 많은 여유 공간이 있지만 YMMV가 있습니다.

경우에 따라 Confluence를 Wiki 및 문서 공유 지점으로 사용하고 있습니다. 온라인 위키 형식은이 정보를 실제로 광범위하게 공유해야 할 때 선호되며 문서를 매우 자주 편집하고 업데이트 할 때 훨씬 더 중요합니다. 그래서 나는 지식 기반 기사를 위키에 넣는 것이 낫다고 생각합니다.

현재 네트워크에 분산 된 다양한 문서에서 두 위치로 정보를 이동하고 있습니다.

1. 인트라넷에서 사용 가능한 위키
2. 해당 서버 / root 디렉토리에있는 특정 서버와 관련된 정보의 사본.

네트워크 다이어그램의 경우 네트워크 메모장 .

또한 무엇을 기록하는 동안 무언가가 어떻게 구성되어 있는지 기록해야합니다. 이렇게하면 좋은 아이디어처럼 보이는 아이디어가 실수로 바뀌는 것을 방지 할 수 있습니다.

우리는 MediaWiki가 느리게 시작했지만, IT 외부의 사람들이 댓글, 변경, 편집 등을 추가하는 것이 얼마나 쉬운 지 알게되자, 그것은 필수 불가결 한 것이되었습니다. 개발자는 내부 문서, 시설 부서에 사용하고 있습니다. 공지 사항 등을 게시하는 데 사용됩니다. IT 문서 도구가 아니라 그 이상입니다.