서버 변경 사항을 기록하는 방법?

따라서 우리 모두는 아마도 이런 상황을 겪었을 것입니다. 6 개월 전에 구성 변경으로 인해 문제가 발생했다는 것을 인식하기 위해 일부 문제를 디버깅했으며 그 이유를 기억할 수 없습니다. 따라서 실행 취소하고 문제를 해결하면 다른 문제가 다시 발생합니다. 네, 지금 기억합니다! 그런 다음 올바르게 수정하십시오.

당신이 적절한 메모를하지 않았기 때문에, 당신은 바보입니다! 그러나 이것을 수행하는 좋은 방법은 무엇입니까?

엔지니어링에는 변경 사항을 감지하고 추적하는 데 도움이되는 많은 소프트웨어가 있습니다. 소스 제어, 코드 검토 등 모든 변경 사항을 추적하고 모든 변경 사항에 대한 설명이 필요합니다. 또한 일반적인 엔지니어링 부서에서는 6 개월 만에 왜 그런 방식으로 문제가 발생했는지 파악할 때 역사적인 '비난'기능이나 이진 검색 빌드를 사용하여 문제를 정확하게 파악할 수 있도록 적절한 의견이 필요합니다. 이러한 도구는 매우 효과적인 의사 소통 도구 및 기록입니다.

그러나 서버 랜드에는 500 개의 서로 다른 서비스가 있으며 모두 서로 다른 구성 방법이 있습니다. 텍스트 형식을 가질 수 있지만 항상 텍스트 형식 (폴더에 대한 사용 권한 설정 또는 페이지 파일 위치 변경 고려)이있는 것은 아닙니다.

우리 환경에서는 Perforce에 어떤 구성 파일을 넣을 수 있는지 확인하지만 그 중 몇 가지는 거의 없습니다. Active Directory DB에서 정확하게 체크인 할 수 없습니다.

과거에는 위키에서 수동 변경 로그를 유지하려고 시도했지만이를 수행하는 원칙을 유지하는 것은 매우 어렵습니다 (잘 알고 있지만, 변명은 아니지만 실제로는 어렵습니다).

내 질문 : 서버 구성 변경을 추적하는이 문제를 해결하기 위해 어떤 전략과 도구를 사용합니까?

-업데이트-

참고 : 서버 변경 사항을 추적하는 데 도움이되는 자동화 된 도구만큼 공유 메모 작성 도구 (OneNote에 익숙 함)를 찾고 있지 않습니다. 서버 구성 변경을 추적하기위한 포괄적 인 도구는 없지만 GPO와 같은 특정 응용 프로그램을위한 도구가있을 수 있습니다.

또한 여러분이 유용하다고 생각한 구체적인 전략에 관심 이 있습니다. "Sharepoint에서 메모를 공유합니다"는 매우 모호합니다. 훈련을 어떻게 유지합니까? 변경 사항을 추적하기 위해 어떤 형식을 사용합니까? 변경 데이터를 어떻게 구성합니까? 아이디어뿐만 아니라 사례도 정말로 좋아합니다.

리눅스 땅에서 사람들은 두 가지 다른 전략을 추구하고 있습니다.

• cfengine 또는 puppet 또는 chef 와 같은 구성 제한 시스템 . 이들은 Windows GPO와 유사합니다. 모든 서버 구성이 의도적으로 한곳에 문서화되어 있고 정책이 시행되는 세분성 (서버 실, 그룹, 특정 서버)을 알 수 있습니다. "6 개월 전에 도대체 무슨 차이가 있었습니까?" 그러나 서버 설정을 취소하고 처음부터 다시 만들 수 있습니다. 질문에 답하기 위해 cfengine 및 꼭두각시 정책을 개정 관리하에 둘 수 있습니다.
• / etc 제어 수정 . 일반적으로 Linux 프로그램은 구성을 한 곳에 / etc에 저장합니다. 대담한 / etc를 개정 제어에 넣는 스크립트를 작성하기 시작했습니다. 내가 아는 그런 프로그램 중 하나는 etckeeper입니다 .

설명 : git, mercurial, bzr 또는 darcs에 / etc 저장
 etckeeper 프로그램은 / etc를 git, mercurial,
 bzr 또는 darcs 저장소. 자동으로 변경 사항을 커밋하기 위해 APT에 연결됩니다.
 패키지 업그레이드 중에 / etc에 작성되었습니다. 해당 버전의 파일 메타 데이터를 추적합니다.
 제어 시스템은 일반적으로 지원하지 않지만 / etc에 중요합니다.
 / etc / shadow의 권한으로. 모듈 식이고 구성 가능하며
 버전 작업의 기본 사항을 이해하면 사용하기 간단합니다.
 제어.

이 상황에서 문제 중 하나는 실제로 비즈니스 프로세스 / 기술 문제의 조합이라는 것입니다. 또한 관리자가 변경 한 사항을 추적하는 것보다 훨씬 큽니다. 또한 AD 컨트롤러를 변경해도 일부 부서 서버의 데이터베이스 권한 설정이 손상되지 않도록 예기치 않은 변경 사항과 관리자 또는 장치 간의 적절한 조정을 주시해야합니다. 즉, 귀하의 질문은 거대한 벌레 캔입니다 :)

우리 조직에서는이 문제를 해결하기 위해 프로세스와 시스템을 배포하는 데 약 1 년이 걸립니다. 비즈니스 프로세스 측면에서 변경 관리 팀을 구성했습니다. SOP에 따르면 프로덕션 환경에 대한 모든 변경 사항은이를 통해 조정됩니다. 범위, 영향을받는 시스템, 영향을받는 서비스 등과 함께 모든 변경 사항을 컴파일합니다. 변경 사항과 롤아웃 계획 및 롤백 계획 모두에 대한 적절한 문서화를 시행합니다. 주간 (공개) 회의를 주최하여 예정된 환경 변경 사항을 검토 한 다음 이러한 변경 사항을 모두 자세히 설명하는 전자 메일을 보내십시오. 이 프로세스의 최종 목표는 IT의 모든 직원이 진행중인 다른 모든 것을 효과적으로 알 수 있도록하는 것입니다. 예를 들어 SysAdmin이 커널 패치를 설치하고 타임 클럭 데이터베이스를 다운시키는 시스템을 재부팅하는 등의 문제를 막을 수 있습니다.

기술적 인 측면에 관해서는 Windows를 다루지 않기 때문에 유닉스 / 리눅스 사람들에 대해서만 말할 수 있습니다. 그들은 Reductive Labs에 의해 모든 시스템의 구성 관리를 위해 Puppet을 출시했습니다. 간단히 말해서, 클라이언트 / 서버 시스템은 서버에서 시스템 구성을 정의하며 클라이언트는 이러한 기회를 자주 (기본적으로 30 분) 가져옵니다. 또한 로컬에서 관리되는 파일이있을 경우 해당 시점으로 되돌아갑니다. 실행 서비스, 방화벽 구성, 사용자 인증 등을 관리하는 데 사용합니다.

또한 TippingPoint와 같은 것을 살펴 보는 것이 좋습니다. 시스템 구성을 감시하고 변경 사항에 대한 경고를 보내는 클라이언트 서비스입니다. 보안 담당자를 가장 행복하게 만듭니다. 악의적이거나 게시되지 않은 변경 사항을 추적하는 데 주로 사용됩니다.

나는 4 ~ 5 개 회사에 있었는데 지금은 기억이 나지 않습니다.

우리 모두이 문제가있었습니다. 우리 중 누구도 100 % 해결하지 못했지만 지금은 회사에서 지금까지 최고의 전략이라고 생각합니다.

쉐어 포인트 / 위키 / 에버 노트 / PIN

• 공유 지점
  • 당신이 원하는 모든 신음 ... 그것은 아주 멋진 목록 기능이 있습니다.
  • IP 주소 목록
  • 목록
  • 서비스 계정 및 사용
  • 알림 로그 변경
• 위키
  • 사용법
  • 장거리 작업 목록
• 에버 노트
  • 내 파트너와 나는 이것을 사용하여 우리가 원하지 않는 모든 것을 Wiki에 넣습니다.
  • 사실상 기술적 인 더 많은 방법
  • 스크래치 메모 우리 둘 다 볼 필요가
  • 금주의 작업 회계
  • 계약자 작업 목록
  • Evernote Clipper를 사용하면 AD / 권한 설정을 쉽게 스크린 샷 할 수 있습니다
  • 어디서나 사용 가능
• 다리
  • 비밀번호 저장소

아마도 이들 중 일부에는 더 나은 도구가 있지만 이것이 우리가 사용하는 것입니다.

• 개인 위키 에서 서버별로 구성 변경 및 업그레이드 / 패치 추적
• 또한 위키에서 하우투와 문제 / 해결에 대한 기록을 유지하십시오.
• Sharepoint 또는 Google 문서 도구 를 사용 하여 정적 IP 목록과 같은 저작물의 사본을 보관 하십시오.
• Subversion 을 사용 하여 구성 파일의 변경 사항 추적

Windows의 경우 해당 플랫폼의 구성 및 서비스 관리에서 Microsoft의 System Center 시리즈 또는 기타 경쟁 업체를 확인하십시오.

적절한 변경 관리 루틴을 통해 변경을 라우팅해야합니다. 변경 관리 루틴은 실제로 완료되기 전에 승인 및 기록합니다. 이것은 초보자에게 100 % 수 동일 수 있습니다. 더 나은 통합 도구를 사용하면 개별 서버 콘솔로 직접 이동하여 설정을 직접 파고 들지 않고 실제 변경을 수행하고 중앙 구성 데이터베이스에 "자동"로그 아웃하도록 도구에 요청할 수 있습니다. 문제 카우보이 스타일을 시도하고 수정하십시오.

특히 환경에서 시스템 수준을 변경할 수있는 능력 / 액세스 권한을 가진 여러 사람이있는 경우 변경 관리 프로세스가 반드시 있어야합니다. 또한 경영진이 잠재적 인 변경에 대해 사인 오프 할 수있는 방법을 제공하지만, 변경을 즉시 수행 할 수없는 경우 변경 프로세스에서 지연이 발생한다는 단점이 있습니다.

변경 사항을 추적하는 몇 가지 방법에는 SEM (Security Event Manager가 있다고 가정)의 이벤트 유효성 검사 또는 Nessus와 같은 도구 (많은 작업으로 환경을 감사하여 변경 사항을 찾을 수 있음)가 포함될 수 있습니다.

보다 현지화 된 * nix 기반 답변입니다. Windows에서 그것을 에뮬레이트하는 좋은 도구를 찾지 못했습니다.

이것을 구현하고 잊었을 때 잡을 수있는 몇 가지 방법이 있습니다.

Subversion, git, cvs 또는 RCS와 같은 수정 제어 시스템은 구성 파일의 기록을 추적하는 좋은 방법입니다. 프로덕션 서버에 개정 제어 시스템을 설치하지 않으려는 경우 rsnapshot 과 같은 것을 사용하여 로컬 또는 원격으로 구성 파일 디렉토리를 저장 하면 RCS의 이점을 대부분 얻을 수 있지만 감사 또는 커밋을 종료 할 가능성은 없어집니다. 로그 (파일 자체의 주석으로 해결할 수는 있지만).

변경 사항을 기록하는 것을 돕기 위해 매일 밤 cron의 트립 와이어 실행을 통해 구성 변경을 자동으로보고 하는 것이 좋습니다. 파일의 현재 상태에 대한 tripwire의 데이터베이스를 구축 한 후에는 파일을 변경하면 다음 실행시 이메일이 발송됩니다. 데이터베이스가 업데이트 될 때까지이 메일을 계속 수신하여 트립 와이어를 "재설정"합니다.

나는 flyspray와 같은 문제 추적 시스템을 사용할 것입니다 (어쨌든 할 것이지만 프로그래밍이 아닌 것들에 대해서는 flyspray를 좋아합니다). 누군가 구성을 만지기 전에 개선 / 문제를 기록해야합니다. 수정 / 구현하면 변경 사항이 티켓에 적용됩니다.

위키는 현재 설정을 문서화하는 것이 좋지만, 구식이되기 쉽습니다. IMO를 업데이트하려면 더 많은 노력이 필요합니다.

자동으로 무언가를 찾지는 않을 것입니다. 원하는 경우 특정 구성 파일에 대한 변경 사항이 자동으로 이슈 트래커로 이메일로 전송되도록 설정할 수도 있습니다.

나는 그것이 좋은 정책, 장벽이 낮은 도구 및 훈련의 문제 일 뿐이라고 생각합니다.

우리는 환경에서 변경 로그 추적을 수행하기 위해 자체 제작 한 것을 만들었습니다. 그것은 매우 복잡한 것이 아니며 꽤 잘 작동합니다.

• 자체 정책 정책은 추정시 기본 설정에서 벗어나거나 잠재적으로 문제를 일으킬 수있는 모든 변경 사항이 변경 로그 시스템에 문서화되도록 설정됩니다.
  • 이 '코인'의 반대편은 문제를 해결하는 경우 최근 또는 관련 변경 로그 항목을 검색하는 것입니다.
• 시스템에 로그인하고 변경중인 서버, 서비스 또는 하드웨어 구성 요소를 선택하십시오.
  • 구성 요소는 이전에 기본 '인구 통계'정보 (위치, 공급 업체, 일련 번호, 담당 부서)와 동일한 시스템에 입력되었습니다.
• 기본 카테고리 드롭 다운에서 선택
  • 예기치 않은 다운 타임
  • 패치
  • 하드웨어 유지 보수
  • 소프트웨어 설치
• 당신이 한 일, 관찰 한 일에 대해 자세하게 설명하십시오
• 사본은 담당자에게 전송되어 검색 어플라이언스에서 색인을 생성 한 XML 파일로 저장됩니다.
• 이익

내가 말했듯이, 멋진 것은 없습니다. PERL CGI (10 억년 전에 작성 됨)와 Google 검색 어플라이언스를 사용하여 색인을 생성합니다.

단점 :

• 예를 들어, 서비스 그룹은 25 개의 도메인 컨트롤러 모두에 동일한 패치를 추가했습니다. "도메인 컨트롤러"그룹이 없으므로 모두 수동으로 선택해야합니다
• 하드웨어, 소프트웨어 또는 이벤트 로그 오류보고와 통합되지 않아 문제 해결에 도움이됩니다.
• 관련하여 위에서 언급 한 모든 '인구 통계'데이터에 대한 수동 데이터 입력

어쨌든, 코드에 관심이 있으시면 알려 주시면 공유 할 수 있습니다.

말했듯이, 종종 문화적 문제-결국 일부 개발 상점은 더 이상 주석으로 귀찮게하지 않으며 (자체 문서화 코드는 오늘날 유행의 유행어입니다!) 일부는 버전 관리 시스템을 역사적인 기록의 성배로 사용합니다. 분명히 이것들은 완벽하지 않습니다.

따라서 문제를 해결하는 유일한 방법은 문화 솔루션을 만드는 것입니다. 변경 사유가 모두 버그 추적기 (또는 지식 기반 또는 wiki)에 기록되고 모든 변경 사항이 변경 제어 시스템에 기록되도록하십시오.

우리는 응급 서비스 고객이 있으며 시스템에 발생하는 모든 변경 사항이 기록되며 시스템에 로그인 할 때마다 로그인해야합니다. 그들 중 일부는 먼저 전화를 걸어 허가를 받아야합니다 (그리고 나는 그것들도 기록합니다!). 모든 변경 사항은 기록되며 고객 시스템을 변경하지 않고 변경하는 것은 징계 위반입니다.

귀찮게 들리지만 그렇지 않습니다. 액세스 로그 및 변경 로그에 자신을 추가하는 습관을 빨리들이십시오. 코드 변경을 체크인 할 때 주석을 작성하는 것보다 나쁩니다.

버그 추적기를 변경 제어 이유 로그로 권장합니다. 일반적으로 업데이트하기 쉽기 때문에 Mantis를 사용합니다.

"엔터프라이즈 솔루션"을 찾고 있다면 (즉, 신보다 더 많은 돈이 있고 정말 멋진 도구를 원합니다), 현장 작업을 지원하고 제공하는 데 사용한 도구는이를 다양한 기능 중 하나로 사용합니다.

기본 가격이 얼마인지는 모르지만 HP가 Opsware를 구입하기 전에 ~ 35 만 달러 (지원하지 않고 나를 신뢰했습니다-Opsware를 시작할 때 지원을 원했습니다)입니다.

우리가 일하는 동안 여러 고객이 Tripwire 와 함께 애플리케이션 구성 및 스냅 샷 기능을 사용 했습니다 .

물론, 예산이 없다면 이것은 Bad Choice ™입니다. :)

그리고, 다시로드했을 때이 페이지의 상단에 게재 된 광고는 spiceworks 용 이었습니다 . HPSA와 매우 비슷하게 보입니다. :)

당신이 원하는 모든 경우 추적 (요리사 또는 인형을 통해, 즉) 전체 프로세스를 관리 변경이 아니라, 단지 rsync당신의 etc로컬 자식의 repo에 (즉 수 있습니다 곳) 디렉토리.

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

물론 필요에 따라 다른 소스를 추가 할 수 있습니다.