Làm thế nào để ghi lại thay đổi máy chủ?

Vì vậy, tất cả chúng ta có thể đã gặp phải tình huống này: bạn gỡ lỗi một số vấn đề, chỉ để nhận ra rằng đó là do thay đổi cấu hình bạn đã thực hiện sáu tháng trước và bạn không thể nhớ tại sao bạn lại làm như vậy. Vì vậy, bạn hoàn tác nó và khắc phục vấn đề, và bây giờ một số vấn đề khác trở lại. Ồ vâng, NGAY BÂY GIỜ tôi nhớ! Sau đó, bạn sửa nó đúng cách.

Đó là bởi vì bạn đã không ghi chép đúng, bạn ngốc! Nhưng một cách tốt để làm điều này là gì?

Trong kỹ thuật, chúng tôi có vô số phần mềm nhằm giúp chúng tôi phát hiện và theo dõi các thay đổi. Kiểm soát nguồn, đánh giá mã, v.v. Mọi thay đổi đều được theo dõi, mọi thay đổi đều cần có nhận xét về nó là gì. Và các bộ phận kỹ thuật điển hình yêu cầu nhận xét tốt để trong sáu tháng khi bạn tìm ra lý do tại sao bạn phá vỡ nó như vậy, bạn có thể sử dụng tính năng 'đổ lỗi' lịch sử hoặc tìm kiếm nhị phân để xác định vấn đề. Những công cụ này là công cụ truyền thông rất hiệu quả và hồ sơ lịch sử.

Nhưng trong serverland, chúng tôi có 500 dịch vụ khác nhau, tất cả đều có cách cấu hình chúng khác nhau. Và chúng không phải luôn có định dạng văn bản (xem xét việc đặt quyền trên thư mục hoặc thay đổi vị trí tệp trang) mặc dù chúng có thể có biểu diễn văn bản.

Trong môi trường của chúng tôi, chúng tôi kiểm tra các tệp cấu hình nào chúng tôi có thể vào Perforce, nhưng có rất ít trong số đó. Không thể kiểm tra chính xác trong Active Directory DB .. mặc dù có lẽ một bãi chứa có thể khác ...

Trước đây tôi đã cố gắng giữ một nhật ký thay đổi thủ công trong wiki của chúng tôi, nhưng thật khó để duy trì kỷ luật để làm điều này (tôi biết, không phải là một lý do tốt, nhưng nó thực sự khó khăn).

CÂU HỎI CỦA TÔI: Bạn sử dụng chiến lược và công cụ nào để đối phó với vấn đề theo dõi thay đổi cấu hình máy chủ này?

- Cập nhật -

Lưu ý: Tôi không tìm kiếm các công cụ ghi chú chia sẻ (tôi quen thuộc với OneNote, v.v.) nhiều như các công cụ tự động đặc biệt có nghĩa là giúp theo dõi các thay đổi của máy chủ. Không có công cụ toàn diện để theo dõi thay đổi cấu hình máy chủ, nhưng có lẽ có một số cho các ứng dụng cụ thể như GPO.

Ngoài ra tôi rất quan tâm đến các chiến lược cụ thể mà bạn thấy hữu ích. "Chúng tôi chia sẻ ghi chú trong Sharepoint" là khá mơ hồ. Làm thế nào để bạn duy trì kỷ luật? Định dạng nào bạn sử dụng để theo dõi các thay đổi của bạn? Làm thế nào để bạn tổ chức dữ liệu thay đổi của bạn? Tôi thực sự thích các ví dụ cũng như ý tưởng.

Ở vùng đất Linux, mọi người đang theo đuổi một vài chiến lược khác nhau:

• Các hệ thống ràng buộc cấu hình , như cengine hoặc con rối hoặc đầu bếp . Đây là tương tự như GPO windows. Điểm đáng chú ý là tất cả các cấu hình máy chủ được ghi lại một cách có chủ ý ở một nơi duy nhất và bạn biết mức độ chi tiết (phòng máy chủ, nhóm, máy chủ cụ thể) chính sách được ban hành. Điều này sẽ không cứu bạn khỏi "cái quái gì đã khác sáu tháng trước?" nhưng nó cho phép bạn chỉ cần cấu hình máy chủ và xây dựng lại từ đầu. Bạn có thể đặt các chính sách của cengine và con rối dưới sự kiểm soát sửa đổi để trả lời câu hỏi.
• Kiểm soát sửa đổi / vv . Nói chung, các chương trình Linux lưu trữ cấu hình của chúng ở một nơi, / v.v. Những kẻ táo bạo đang bắt đầu viết các kịch bản để đưa / etc vào kiểm soát sửa đổi. Một chương trình như vậy tôi biết là etckeeper :

Mô tả: lưu trữ / vv trong git, mercurial, bzr hoặc darcs
 Chương trình etckeeper là một công cụ cho phép / etc được lưu trữ trong một git, đồng bóng,
 kho bzr hoặc darcs. Nó móc vào APT để tự động cam kết thay đổi
 thực hiện để / vv trong quá trình nâng cấp gói. Nó theo dõi siêu dữ liệu tập tin phiên bản đó
 hệ thống điều khiển thường không hỗ trợ, nhưng điều đó rất quan trọng đối với / etc, như vậy
 như quyền của / etc / bóng. Nó khá mô-đun và cấu hình, trong khi
 cũng đơn giản để sử dụng nếu bạn hiểu những điều cơ bản khi làm việc với phiên bản
 điều khiển.

Một trong những vấn đề trong tình huống này là, thực sự, đó là một vấn đề kết hợp giữa quy trình kinh doanh / công nghệ. Và nó chắc chắn lớn hơn việc theo dõi những thay đổi mà quản trị viên đã thực hiện. Bạn cũng cần theo dõi những thay đổi bất ngờ và phối hợp tốt giữa quản trị viên hoặc đơn vị để thay đổi trên bộ điều khiển AD không phá vỡ cài đặt quyền cơ sở dữ liệu trên một số máy chủ của bộ phận. Tức là câu hỏi của bạn là một con giun khổng lồ :)

Trong tổ chức của tôi, chúng tôi có khoảng một năm để đưa ra các quy trình và hệ thống để giải quyết vấn đề này. Đối với phía quy trình kinh doanh, chúng tôi đã thành lập một nhóm Quản lý thay đổi. Theo SOP, tất cả các thay đổi đối với môi trường sản xuất đều được điều phối thông qua chúng. Họ biên dịch tất cả các thay đổi, cùng với phạm vi, các hệ thống bị ảnh hưởng, các dịch vụ bị ảnh hưởng, v.v. Thi hành các tài liệu tốt về các thay đổi, cũng như cả các kế hoạch triển khai và quay lại. Tổ chức các cuộc họp hàng tuần (mở) để xem xét các thay đổi môi trường sắp tới, sau đó gửi email chi tiết tất cả các thay đổi này. Mục tiêu cuối cùng với quy trình này là để mọi người trong CNTT biết mọi thứ đang diễn ra một cách hiệu quả. Điều này giúp ngăn chặn vấn đề, ví dụ, SysAdmin cài đặt bản vá kernel và khởi động lại hệ thống sẽ gỡ bỏ cơ sở dữ liệu khóa thời gian.

Về mặt công nghệ, tôi chỉ có thể nói về những người Unix / Linux vì tôi không giao dịch với Windows. Họ đã triển khai Puppet, bởi Redative Labs, để quản lý cấu hình của tất cả các hệ thống đó. Đơn giản, là một hệ thống máy khách / máy chủ nơi người ta xác định cấu hình máy trên máy chủ và máy khách sẽ kéo những cơ hội đó thường xuyên (30 phút theo mặc định). Ngoài ra, nếu có bất kỳ cơ hội nào được thực hiện cho các tệp được quản lý cục bộ thì chúng cũng được hoàn nguyên trở lại vào thời điểm đó. Chúng tôi sử dụng nó để quản lý các dịch vụ đang chạy, cấu hình tường lửa, ủy quyền người dùng, v.v.

Tôi cũng sẽ khuyên bạn nên xem xét một cái gì đó như TippingPoint. Đây là một dịch vụ khách theo dõi cấu hình hệ thống và gửi thông báo về các thay đổi. Nó làm cho chúng tôi an ninh folks hạnh phúc nhất. Nó chủ yếu được sử dụng để theo dõi các thay đổi độc hại hoặc chưa được công bố.

Tôi đã ở 4 hoặc 5 công ty bây giờ tôi không thực sự nhớ.

Tất cả chúng ta đều có vấn đề này. Không ai trong chúng tôi đã giải quyết được 100 phần trăm, nhưng tại công ty tôi hiện tại chúng tôi có những gì tôi nghĩ là chiến lược tốt nhất cho đến nay.

Sharepoint / Wiki / Evernote / PIN

• Điểm chia sẻ
  • rên rỉ tất cả những gì bạn muốn ... nó có một số tính năng danh sách rất hay.
  • Danh sách địa chỉ IP
  • hàng tồn kho
  • tài khoản dịch vụ và sử dụng
  • thay đổi nhật ký thông báo
• Wiki
  • Cách làm
  • danh sách nhiệm vụ tầm xa
• Evernote
  • đối tác của tôi và tôi sử dụng điều này để đưa mọi thứ chúng tôi không muốn vào Wiki
  • nhiều hơn về bản chất là kỹ thuật
  • ghi chú đầu chúng ta cần xem
  • nhiệm vụ kế toán trong tuần
  • danh sách nhiệm vụ nhà thầu
  • clipper evernote giúp dễ dàng chụp màn hình cài đặt AD / quyền
  • có sẵn ở mọi nơi
• PIN
  • Kho mật khẩu

Có thể có các công cụ tốt hơn cho một số trong số này, nhưng đây là những gì chúng tôi sử dụng:

• Theo dõi các thay đổi cấu hình và nâng cấp / vá lỗi trên cơ sở từng máy chủ trong wiki riêng
• Đồng thời giữ howtos và hồ sơ các vấn đề / giải pháp trong wiki
• Sử dụng Sharepoint hoặc Google Docs để giữ các bản sao chính thức của những thứ như danh sách IP tĩnh
• sử dụng Subversion để theo dõi các thay đổi đối với các tệp cấu hình

Đối với Windows, hãy xem loạt Trung tâm Hệ thống của microsofts hoặc bất kỳ đối thủ cạnh tranh nào khác về quản lý cấu hình và dịch vụ cho nền tảng đó.

Các thay đổi cần được chuyển qua một thói quen quản lý thay đổi hợp lý, chính nó chấp thuận và ghi lại chúng trước khi chúng thực sự được thực hiện. Điều này có thể được hướng dẫn 100% cho người mới bắt đầu. Với một số công cụ tích hợp tốt hơn, bạn có thể yêu cầu công cụ thực hiện các thay đổi thực tế và đăng xuất "tự động" vào cơ sở dữ liệu cấu hình trung tâm - thay vì chuyển tay vào bảng điều khiển của một máy chủ riêng lẻ, tìm hiểu kỹ các cài đặt thử và sửa một vấn đề kiểu cao bồi.

Bạn hoàn toàn nên có một quy trình quản lý thay đổi tại chỗ, đặc biệt nếu có nhiều người có khả năng / quyền truy cập để thực hiện thay đổi ở cấp hệ thống trong môi trường của bạn. Điều này cũng cung cấp một cách để quản lý ký tắt các thay đổi tiềm năng, tuy nhiên nhược điểm của nó gây ra độ trễ trong quá trình thay đổi nếu bạn không thể thay đổi nhanh chóng.

Một số cách theo dõi các thay đổi có thể bao gồm xác thực các sự kiện trong SEM của bạn (giả sử bạn có Trình quản lý sự kiện bảo mật) hoặc các công cụ như Nessus (với rất nhiều công việc có thể kiểm tra môi trường của bạn để tìm thay đổi).

Đây là một câu trả lời dựa trên địa phương hơn, * nix. Tôi không tìm thấy bất kỳ công cụ tốt nào để mô phỏng nó trong Windows.

Có một vài cách để thực hiện điều này ... và để nắm bắt nó khi bạn quên.

Các hệ thống kiểm soát sửa đổi như lật đổ, git, cvs hoặc RCS là một cách tốt để theo dõi lịch sử của tệp cấu hình. Nếu bạn không muốn cài đặt hệ thống kiểm soát sửa đổi trên các máy chủ sản xuất của mình, việc lưu trữ các thư mục tệp cấu hình cục bộ hoặc từ xa bằng cách sử dụng thứ gì đó như rsnapshot sẽ mang lại cho bạn hầu hết các lợi ích của RCS, nhưng bạn sẽ mất khả năng kiểm tra hoặc để lại cam kết nhật ký (mặc dù điều này có thể được xử lý xung quanh với các bình luận bên trong các tệp).

Để giúp bạn nhớ ghi nhật ký các thay đổi, báo cáo tự động về thay đổi cấu hình thông qua hoạt động tripwire hàng đêm, là một khởi đầu tốt. Sau khi xây dựng cơ sở dữ liệu của tripwire về trạng thái hiện tại của các tệp, mọi thay đổi đối với chúng sẽ dẫn đến một email trong lần chạy tiếp theo. Bạn sẽ tiếp tục nhận thư này cho đến khi cơ sở dữ liệu được cập nhật, do đó "đặt lại" tripwire.

Tôi sẽ sử dụng một hệ thống theo dõi vấn đề như flyspray (bất kỳ sẽ làm được, nhưng tôi thích flyspray cho những thứ không lập trình). Trước khi bất cứ ai chạm vào một cấu hình, cải thiện / vấn đề nên được ghi lại. Khi bạn sửa chữa / thực hiện nó, những thay đổi sẽ xuất hiện trong vé.

Một wiki có thể tốt để ghi lại thiết lập hiện tại, nhưng nó dễ dàng bị lỗi thời - và dường như phải mất nhiều nỗ lực hơn để cập nhật IMO.

Bạn sẽ không tìm thấy thứ gì đó tự động để làm điều này - mặc dù bạn có thể thiết lập nó để thay đổi các tệp cấu hình nhất định sẽ tự động được gửi qua email cho trình theo dõi vấn đề nếu bạn muốn.

Tôi nghĩ đó chỉ là vấn đề của một chính sách tốt, các công cụ và kỷ luật thấp.

Chúng tôi đã tạo ra một cái gì đó cây nhà để làm thay đổi theo dõi nhật ký trong môi trường của chúng tôi; nó không phải là bất cứ điều gì siêu phức tạp, và nó hoạt động khá tốt.

• Chính sách tự kiểm soát là thiết lập rằng bất kỳ thay đổi nào trong ước tính của bạn đều lệch khỏi thiết lập ngoài luồng hoặc có thể có thể gây ra sự cố, nên được ghi lại trong hệ thống thay đổi.
  • mặt đối lập của 'đồng xu' này là nếu bạn đang khắc phục sự cố, hãy tìm kiếm các mục thay đổi gần đây hoặc có liên quan.
• Đăng nhập vào hệ thống và chọn máy chủ, dịch vụ hoặc thành phần phần cứng mà bạn đang thay đổi
  • các thành phần trước đây được nhập vào cùng một hệ thống với thông tin 'nhân khẩu học' cơ bản (địa điểm, nhà cung cấp, số sê-ri, bộ phận chịu trách nhiệm)
• Chọn từ danh sách cơ bản thả xuống
  • Thời gian chết không theo quy định
  • Vá
  • Bảo trì phần cứng
  • Cài đặt phần mềm
• Đưa vào chi tiết những gì bạn đã làm, đã thấy, đã quan sát
• một bản sao được gửi cho bên chịu trách nhiệm và được lưu trữ dưới dạng tệp XML được công cụ tìm kiếm lập chỉ mục.
• Lợi nhuận

Như tôi đã nói, không có gì lạ mắt. Nó sử dụng PERL CGI (đã được viết cách đây một tỷ năm) và một công cụ Tìm kiếm của Google để lập chỉ mục.

Thiếu sót:

• Các nhóm dịch vụ khó làm việc với, ví dụ, bạn chỉ cần thêm bản vá tương tự cho tất cả 25 bộ điều khiển miền của mình; chúng tôi không có nhóm "Bộ điều khiển miền", vì vậy chúng tôi phải chọn tất cả chúng theo cách thủ công
• Không tích hợp với báo cáo lỗi phần cứng, phần mềm hoặc nhật ký sự kiện để giúp khắc phục sự cố
• liên quan, nhập dữ liệu thủ công cho tất cả dữ liệu 'nhân khẩu học' như tôi đã nói ở trên

Dù sao, nếu sau tất cả những gì bạn quan tâm đến mã, hãy cho tôi biết và tôi có thể lấy nó để chia sẻ.

Như đã nói, đây thường là một vấn đề văn hóa - sau tất cả, một số cửa hàng phát triển không bận tâm đến các bình luận nữa (mã tự ghi là một từ thông dụng thời trang ngày nay!) Và một số sử dụng hệ thống kiểm soát phiên bản như một chén thánh của các ghi chép lịch sử. Rõ ràng, những điều này không hoàn hảo.

Vì vậy, cách duy nhất để khắc phục nó là biến nó thành một giải pháp văn hóa. Đảm bảo tất cả các lý do cho sự thay đổi được ghi lại trong một trình theo dõi lỗi (hoặc kiến ​​thức hoặc wiki) và đảm bảo tất cả các thay đổi được ghi lại trong một hệ thống kiểm soát thay đổi.

Chúng tôi có khách hàng dịch vụ khẩn cấp, mọi thay đổi xảy ra với hệ thống của họ đều được ghi lại và mỗi lần chúng tôi đăng nhập vào hệ thống của họ, chúng tôi phải đăng nhập. Đối với một số người trong số họ, chúng tôi phải gọi điện trước để xin phép (và tôi đoán họ cũng đăng nhập như vậy!). Mọi thay đổi đều được ghi lại và sẽ là vi phạm kỷ luật khi thay đổi hệ thống khách hàng mà không đăng nhập.

Nghe có vẻ khó chịu, nhưng nó không phải. Bạn nhanh chóng có thói quen thêm bản thân vào nhật ký truy cập và thay đổi nhật ký - không tệ hơn là phải viết bình luận khi kiểm tra thay đổi mã.

Tôi khuyên dùng bugtracker là nhật ký lý do kiểm soát thay đổi, vì chúng thường dễ cập nhật (tôi sử dụng Thần chú).

Nếu bạn đang tìm kiếm "giải pháp doanh nghiệp" (nghĩa là bạn có nhiều tiền hơn thượng đế và muốn có một công cụ thực sự tuyệt vời), thì công cụ tôi sử dụng để hỗ trợ và cung cấp công việc tại chỗ để thực hiện điều này như một trong những tính năng đa dạng của nó.

Không biết giá cơ bản là bao nhiêu, nhưng trước khi HP mua Opsware, nó đã ~ 350.000 đô la Mỹ (không có hỗ trợ và hãy tin tôi - bạn muốn được hỗ trợ khi tôi bắt đầu với Opsware).

Một số khách hàng chúng tôi có khi tôi làm việc ở đó đã sử dụng cấu hình ứng dụng và các tính năng chụp nhanh kết hợp với Tripwire .

Tất nhiên, nếu bạn không có ngân sách - đây là một lựa chọn tồi ™ :)

Và, fwiw, quảng cáo xuất hiện ở đầu trang này cho tôi khi tôi tải lại nó là cho gia vị . Trông hùng mạnh tương tự như HPSA :)

Nếu tất cả những gì bạn muốn làm là theo dõi các thay đổi và không quản lý toàn bộ quá trình (tức là thông qua Chef hoặc Puppet), chỉ cần thư mục rsynccủa bạn etc(bất cứ nơi nào có thể) vào một repo git cục bộ.

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

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

done

Tất nhiên, bạn có thể thêm các nguồn khác khi cần thiết.