it-swarm-ko.tech

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

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

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

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

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

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

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

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

-업데이트-

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

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

52
scobi

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

  • Configuration constraint systemscfengine 또는 puppet 또는 chef 와 같습니다. 이들은 Windows GPO와 유사합니다. 모든 서버 구성이 의도적으로 한곳에 문서화되어 있고 정책이 시행되는 세분성 (서버 실, 그룹, 특정 서버)을 알 수 있습니다. "6 개월 전에 도대체 무슨 차이가 있었습니까?" 그러나 서버 설정을 취소하고 처음부터 다시 만들 수 있습니다. cfengine 및 꼭두각시 정책을 개정 관리하에 놓아 질문에 대답 할 수 있습니다.
  • 개정 제어/etc. 일반적으로 Linux 프로그램은 구성을 한 곳에/etc에 저장합니다. 대담한/etc를 개정 제어에 넣는 스크립트를 작성하기 시작했습니다. 내가 아는 그러한 프로그램 중 하나는 etckeeper 입니다.
설명 :/etc를 git, Mercurial, bzr 또는 darcs에 저장 
 etckeeper 프로그램은/etc를 git, Mercurial, 
 bzr 또는 darcs 저장소에 저장하는 도구입니다. 패키지 업그레이드 중에/etc에 대한 변경 사항 
을 자동 커밋하기 위해 APT)에 연결됩니다. 버전 
 제어 시스템이 일반적으로 지원하지 않지만 파일 메타 데이터를 추적합니다./etc/shadow의 권한과 같이 
과 같은/etc에 중요합니다. 모듈 식이고 구성 가능하며 
도 버전 작업의 기본 사항을 이해하면 사용하기 간단합니다. .] 제어. 
20
jldugger

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

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

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

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

10
Scott Pack

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

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

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

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

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

  • private wiki에서 서버별로 구성 변경 및 업그레이드/패치를 추적합니다.
  • 또한 위키에서 하우투와 문제/해결에 대한 기록을 유지하십시오.
  • Sharepoint 또는 Google Docs를 사용하여 고정 IP 목록과 같은 것들의 정식 사본을 유지하십시오
  • Subversion을 사용하여 구성 파일의 변경 사항을 추적하십시오.
2
Brent

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

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

2
Oskar Duveborn

특히 사용자 환경의 시스템 수준에서 변경을 수행 할 수있는 여러 사람이있는 경우 변경 관리 프로세스를 갖추어야합니다. 또한 경영진이 잠재적 인 변경에 대해 사인 오프 할 수있는 방법을 제공하지만, 변경을 즉시 수행 할 수없는 경우 변경 프로세스에서 지연을 유발하는 단점이 있습니다.

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

2
David Yu

보다 현지화 된 * nix 기반 답변입니다. Windows에서 에뮬레이션하는 데 유용한 도구를 찾지 못했습니다.

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

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

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

2
Greg Work

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

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

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

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

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

1
warren

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

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

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

단점 :

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

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

1
Guamaniac

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

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

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

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

1
Draemon

track 변경 만하고 전체 프로세스를 관리하지 않는 경우 (예 : Chef 또는 Puppet을 통해) rsync your etc 디렉토리 (가능한 경우) be) 로컬 자식 저장소에.

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

    rsync -avz --exclude-from=exclusions -e ssh [email protected]$Host:/opt/local/etc/ ./$Host

done

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

1
PartialOrder

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

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

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

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

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

1
gbjbaanb