저는 IT 팀이 생산 변경 계획에 어떻게 접근하는지 항상 관심이 있습니다. 일반적으로 우리는 런북을 사용하여 변경의 주요 단계와 취소 계획을 계획합니다. 저는 우리가 다른 사람들로부터 배울 수 있는지, 그리고 런북을 가장 잘 문서화하는 방법을 알고 싶습니다.
답변1
나는 주석과 인쇄물이 있는 스크립트를 선호합니다.
문서화와 자동화라는 두 가지 장점이 있습니다.
그러나 보다 전체적인 접근 방식을 취하면 일반적으로 추적할 항목이 많으며
스크립팅은 순서대로 수행해야 하는 작업에만 사용됩니다.
관련된 메모가 많을 때는 로컬에서 호스팅되는 Wiki(개인의또는그룹).
그것은 사용될 수 있습니다
- 링크를 통해 도구를 참조하고 빠른 메모를 작성하세요.
- 연락처 및 에스컬레이션 참조 열거
- 키워드를 기반으로 긴급 조치 문서화
- 백업 위치 및 복구 순서
- 정기적인 요구 사항 및 솔루션에 대한 검색 가능한 기록을 호스팅합니다. 그래서 사람들은 그걸 확인한 후에 당신에게 옵니다
하지만 위치를 안전하게 유지하세요. 긴급 상황에서 데이터에 액세스할 수 없는 상황을 원하지는 않을 것입니다.
여기 오래된 것이 있습니다Microsoft Technet SQL Server 런북일반적인 아이디어를 얻기 위한 페이지입니다.
답변2
내가 하는 일:
설치된 OS 기준에서 변경해야 하는 모든 서버 구성은 Chef에 의해 관리되며, 이는 모듈(쿡북이라고 함)에 저장된 다음 Git을 통해 버전 제어에 저장됩니다.
대부분의 구성은 테스트 시스템(종종 VM 이미지 또는 단순히 EC2 인스턴스)에서 수동으로 수행되었으며, 그런 다음 변경 사항의 다양한 구성 요소를 모두 포함하도록 구성 레시피가 작성되었습니다. 환경 워크플로 업데이트는 다음과 같이 진행됩니다.
- 변경이 필요한 적절한 시스템에서 티켓을 만듭니다.
- 변경 이유와 내용을 모두 문서화하세요.
- 대상 시스템에서 변경을 수행하는 데 필요한 구성 레시피, 템플릿, 파일 등을 편집합니다.
- 변경 사항을 로컬 저장소에 커밋하고 마스터 버전 제어 서버로 푸시합니다.
- 변경 사항에 대한 동료 검토를 위해 티켓을 업데이트합니다.
- 변경 사항이 승인되고 변경 사항이 Chef 서버에 배포되어 업데이트된 비트를 알 수 있습니다.
- 클라이언트에서 Chef를 수동으로 실행하거나 변경 요구 사항에 따라 자동으로 실행되도록 하세요. (6개 이상의 시스템을 직접 실행하지는 않을 것입니다.)
Chef의 작동 모드는 패키지가 존재하지 않거나 템플릿 파일을 찾을 수 없는 경우 또는 기타 여러 문제와 같이 클라이언트를 실행하는 데 문제가 있는 경우 실패하는 것입니다. 문제를 해결하고 티켓에 문서화한 후 클라이언트를 다시 실행하세요.
변경에 대한 비즈니스 요구 사항이 있는 사람은 변경이 성공했음을 확인하고 티켓을 종료합니다.
그것이 내가 사용하는 것이기 때문에 특정 요리사입니다. 환경에 적합한 도구를 대체하고, 구성 관리 도구를 사용하지 않는 경우 전체 프로세스를 훨씬 더 강력하고 안정적으로 만들 수 있는지 살펴봐야 합니다. 확장성은 말할 것도 없습니다.
답변3
매우 중요하고 민감한 변경의 경우 일반적으로 진행 상황을 설명하는 #comments와 함께 사용할 실제 명령이 포함된 텍스트 파일을 사용합니다. 이렇게 하면 터미널에 빠르게 잘라내어 붙여넣을 수 있습니다.
답변4
나는 꼭두각시가 내가 선택한 도구라는 점에서 jtimberman의 게시물 뒤에 있는 기본 아이디어에 두 번째로 동의합니다.