Sunucu değişiklikleri nasıl kaydedilir?

Böylece hepimiz muhtemelen bu duruma ulaştık: bazı sorunlarda hata ayıkladınız, bunun yalnızca altı ay önce yaptığınız bir yapılandırma değişikliğinden kaynaklandığını anlamak için ve bunu neden yaptığınızı hatırlayamıyorsunuz. Yani geri al ve sorunu çöz, ve şimdi başka bir problem geri dönüyor. Oh evet, şimdi hatırladım! Sonra doğru düzelttin.

Çünkü düzgün notlar almadın, aptal! Ama bunu yapmanın iyi bir yolu nedir?

Mühendislikte değişiklikleri tespit etmemize ve izlememize yardımcı olacak bir sürü yazılımımız var. Kaynak kontrolü, kod incelemeleri vb. Her değişiklik izlenir, her değişiklik ne olduğuna dair bir yorum gerektirir. Ve tipik mühendislik departmanları iyi yorumlar gerektirir, böylece altı ay içinde neden bu şekilde kırıldığına karar verdiğinizde, sorunu tespit etmek için tarihsel bir 'suçlama' özelliğini veya ikili arama yapmayı kullanabilirsiniz. Bu araçlar çok etkili iletişim araçları ve tarihi kayıtlardır.

Ancak serverland'da, farklı konfigürasyon yöntemleriyle, 500 farklı servisimiz var. Ayrıca, metinsel bir sunumu olsa da, her zaman bir metin biçimine sahip değildir (bir klasörde izinleri ayarlamayı veya sayfa dosyası konumunu değiştirmeyi düşünün).

Çevremizde, hangi config dosyalarında Performance yapabileceğimizi kontrol ediyoruz, ancak bunlardan çok az var. Active Directory DB'sinde tam olarak kontrol edemiyorum .. belki de farklı olabilecek bir dökümü ...

Geçmişte wiki'de manuel bir değişiklik kaydı tutmaya çalıştım, ancak bunu yapmak için disiplini sürdürmek çok zor (biliyorum, iyi bir bahane değil, ama gerçekten zor).

SORU: Sunucularınızdaki yapılandırma değişikliklerini izleme sorunuyla başa çıkmak için hangi stratejileri ve araçları kullanıyorsunuz?

-- Güncelleme --

Not: Özellikle sunucu değişikliklerini izlemeye yardımcı olacak otomatik araçlar olduğu kadar, paylaşılan not alma araçlarını (OneNote'a vb. Alıyorum) aramıyorum. Sunucu yapılandırma değişikliklerini izlemek için kapsamlı bir araç yoktur, ancak GPO'lar gibi belirli uygulamalar için bazıları da olabilir.

Ayrıca yararlı bulduğun belirli stratejilerle de çok ilgileniyorum . "Sharepoint'te notları paylaşıyoruz" oldukça belirsiz. Disiplini nasıl sürdürüyorsunuz? Değişikliklerinizi izlemek için hangi formatı kullanıyorsunuz? Değişiklik verilerinizi nasıl düzenlersiniz? Fikirleri ve örnekleri gerçekten çok istiyorum.

Linux ülkesinde insanlar birkaç farklı strateji izliyor:

• Cfengine veya kukla veya şef gibi yapılandırma kısıtlama sistemleri . Bunlar Windows GPO'larına benzer. Tüm sunucu yapılandırmasının kasıtlı olarak tek bir yerde belgelendiğini ve politikanın hangi ayrıntı derecesinde (sunucu odası, grup, belirli sunucu) uygulandığını bildiğinize dikkat edin. Bu sizi "altı ay önce farklı olan neydi?" Den sizi kurtarmayacak. ancak bir sunucu yapılandırmasına izin vermez ve sıfırdan yeniden oluşturmanıza izin vermez. Soruyu cevaplamak için cfengine ve kukla politikalarını revizyon kontrolü altına alabilirsiniz.
• Revizyon kontrol / vb . Genel olarak, Linux programları konfigürasyonlarını tek bir yerde, vb. Cesaret, / etc'yi revizyon kontrolüne koymak için senaryolar yazmaya başlıyor. Bildiğim böyle bir program etckeeper :

Açıklaması: git / mağaza, vb mercurial, bzr veya darcs
 Etckeeper programı git, mercurial, git git
 bzr veya darcs deposu. Otomatik olarak değişiklik yapmak için APT'ye bağlanır
 Paket güncellemeleri sırasında / etc dizinine yapılır. Bu sürümdeki meta verileri izler
 kontrol sistemleri normalde desteklemez, ancak / etc için önemlidir.
 / etc / shadow'ın izinleri gibi. Oldukça modüler ve yapılandırılabilir
 Ayrıca sürümle çalışmanın temellerini anlıyorsanız kullanımı basit olmak
 kontrol.

Bu durumdaki sorunlardan biri, aslında bir kombinasyon iş süreci / teknolojik sorun olmasıdır. Ve kesinlikle bir yöneticinin neyi değiştirdiğini takip etmekten kesinlikle daha büyük. Ayrıca beklenmedik değişikliklere dikkat etmeniz ve yöneticiler veya birimler arasında iyi bir eşgüdüm sağlamanız gerekir; böylece bir AD denetleyicisindeki bir değişiklik bazı departman sunucularında bir veritabanı izinleri ayarını bozmaz. Yani, sorunuz çok büyük bir kurtçuk kutusudur :)

Benim organizasyonumda, bunu ele almak için süreçleri ve sistemleri hayata geçirmek üzere bir yıl geçirdik. İş süreci tarafı için bir Değişim Yönetimi ekibi kurduk. SOP'a göre üretim ortamlarındaki tüm değişiklikler onlarla koordine edilir. Kapsam, etkilenen sistemler, etkilenen hizmetler vb. İle birlikte tüm değişiklikleri derler. Değişiklikler hakkında iyi bir dokümantasyonun yanı sıra hem geri alma hem de geri alma planları uygular. Yaklaşan çevre değişikliklerini gözden geçirmek için haftalık (açık) toplantılara ev sahipliği yapın, ardından tüm bu değişikliklerin ayrıntılarını içeren e-postalar gönderin. Bu sürecin son amacı, etkin bir şekilde, BT alanındaki herkesin olup biten her şeyi bilmesidir. Bu, örneğin bir çekirdek düzeltme eki yükleyen ve zaman çizelgesi veritabanını çökertecek bir sistemi yeniden başlatan bir SysAdmin sorununu durdurmaya yardımcı olur.

Teknolojik açıdan ise, Windows ile ilgilenmediğim için sadece Unix / Linux adamlarından bahsedebiliyorum. Tüm bu sistemlerin konfigürasyon yönetimi için Redüktif Laboratuarlar tarafından Kukla’yı piyasaya sürdüler. Basitçe, sunucudaki bir makine konfigürasyonunu tanımlayan bir istemci / sunucu sistemidir ve istemci bu fırsatları her sık ​​sık çeker (varsayılan olarak 30 dakika). Ek olarak, yerel olarak yönetilen dosyalara herhangi bir şans verilirse, o zaman da geri döndürülürler. Çalışan hizmetleri, güvenlik duvarı yapılandırmalarını, kullanıcı yetkilendirmesini vb. Yönetmek için kullanıyoruz.

Ayrıca TippingPoint gibi bir şeye bakmanızı da tavsiye ederim. Sistem yapılandırmasını izleyen ve değişikliklerle ilgili uyarılar gönderen bir istemci hizmetidir. Bizi güvenlik görevlilerinden çok mutlu ediyor. Kötü amaçlı veya yayınlanmamış değişiklikleri izlemek için kullanılır.

4 ya da 5 şirkette bulundum, şimdi hatırlamıyorum.

Hepimizin bu sorunu vardı. Hiçbirimiz bunu yüzde 100 çözemedik, ama şu anda olduğum şirkette şu ana kadarki en iyi stratejinin ne olduğunu düşünüyorum.

SharePoint / Wiki / Evernote / PIN

• Paylaşım Noktası
  • İstediğin kadar inilti ... bazı çok güzel liste özelliklerine sahip.
  • IP adresi listeleri
  • envanter
  • servis hesapları ve kullanımı
  • bildirim günlüklerini değiştir
• wiki
  • Nasıl yapılır?
  • uzun menzilli görev listeleri
• Evernote
  • ortağım ve ben bunu Wiki'de istemediğimiz her şeyi koymak için kullanıyoruz.
  • doğada teknik olan daha nasıl yapılır
  • hem de görmemiz gereken notları
  • haftanın görev muhasebesi
  • yüklenici görev listeleri
  • evernote clipper ekran görüntülemesini kolaylaştırır AD / hak ayarları
  • her yerde mevcut
• PIN
  • Şifre deposu

Bunlardan bazıları için muhtemelen daha iyi araçlar vardır, ancak kullandığımız şey bu:

• Özel wiki'de konfigürasyon değişikliklerini ve yükseltmeleri / yamaları sunucu bazında izleyin
• Ayrıca wiki'de howtos ve sorunların / çözümlerin kaydını tutun
• Statik IP listeleri gibi nesnelerin yetkili kopyalarını saklamak için Sharepoint veya Google Dokümanlar kullanın.
• yapılandırma dosyalarındaki değişiklikleri izlemek için Subversion'ı kullanın

Windows için, bu platform için yapılandırma ve servis yönetiminde Microsofts System Center serisini veya diğer rakipleri inceleyin.

Değişikliklerin, gerçekten yapılmadan önce kendileri tarafından onaylanan ve günlüğe giren düzgün bir değişiklik yönetimi rutini ile yönlendirilmesi gerekir. Bu yeni başlayanlar için% 100 el kitabı olabilir. Daha iyi tümleşik araçlardan bazılarıyla, araçtan asıl değişiklikleri yapmasını ve merkezi bir yapılandırma veritabanına giriş yapmasını "otomatik" hale getirmesini isteyebilirsiniz; kovboy tarzı bir sorunu çözmeye çalışın.

Özellikle ortamınızdaki sistem düzeyinde değişiklik yapma yeteneği / erişimi olan birden fazla kişi varsa, kesinlikle bir değişim yönetimi sürecine sahip olmalısınız. Bu aynı zamanda yönetimin olası değişikliklere imza atması için bir yol sağlar, ancak olumsuz tarafı, anında değişiklik yapamıyorsanız değişim sürecinde gecikmeye neden olur.

Değişiklikleri izlemenin bazı yolları, SEM'inizde (bir Güvenlik Olay Yöneticisine sahip olduğunuzu varsayarak) olayların doğrulanmasını veya Nessus gibi araçları (çok çalışarak değişiklik bulmak için ortamınızı denetleyebilir) içerebilir.

Bu daha yerel, * nix tabanlı bir cevaptır. Windows altında taklit edecek iyi bir araç bulamadım.

Bunu yapmanın ve unuturken yakalamanın ... birkaç yolu var.

Subversion, git, cvs veya RCS gibi revizyon kontrol sistemleri bir config dosyasının geçmişini takip etmenin iyi bir yoludur. Üretim sunucularınıza bir revizyon kontrol sistemi kurmak istemiyorsanız, yapılandırma dosyası dizinlerini yerel olarak veya uzaktan rsnapshot gibi bir şey kullanarak saklamak , bir RCS'nin avantajlarından en iyi şekilde faydalanmanıza neden olur, ancak denetim veya taahhütten vazgeçme olasılığını kaybedersiniz kütükler (bu, dosyaların kendi içindeki yorumlar ile çözülebilmesine rağmen).

Değişiklikleri günlüğe kaydetmeyi hatırlamanıza yardımcı olmak için, gecelik olarak cron'ed tripwire run üzerinden otomatik olarak yapılandırma değişikliklerinin raporlanması iyi bir başlangıçtır. Tripwire'ın mevcut dosya durumunun veritabanını oluşturduktan sonra, değişiklik yapılması, bir sonraki çalıştırma sırasında bir e-posta ile sonuçlanacaktır. Veritabanı güncellenene kadar bu postayı almaya devam edersiniz, böylece tripwire "sıfırlanır".

Flyspray gibi bir sorun izleme sistemi kullanırdım (herhangi bir şey yapacaktır, ancak programlama dışı şeyler için flyspray'i severim). Herhangi biri bir yapılandırmaya dokunmadan önce, iyileştirme / problem kaydedilmelidir. Düzeltdiğinizde / uyguladığınızda, değişiklikler bilette gerçekleşir.

Bir wiki mevcut kurulumu belgelemek için güzel olabilir, ancak güncelliğini yitirmesi kolaydır - ve IMO'yu güncellemek için daha fazla çaba sarf etmesi gerekiyor.

Bunu yapmak için otomatik bir şey bulamayacaksınız - muhtemelen ayarlayabilmenize rağmen, belirli yapılandırma dosyalarındaki değişiklikler otomatik olarak sorun izleyicisine e-posta ile gönderilirse.

Bence bu sadece iyi bir politika, düşük engelli araç ve disiplin meselesi.

Çevremizdeki log takibini değiştirmek için kendi yetiştirdiğimiz bir şey yarattık; süper karmaşık bir şey değil ve gayet iyi çalışıyor.

• Kendi kendini denetleyen bir politika, tahminde bulunduğunuz herhangi bir değişikliğin ya kullanıma hazır bir kurulumdan sapabileceği ya da potansiyel olarak sorunlara neden olabilecek herhangi bir değişikliğin değişmez sistemde belgelenmesi gerektiğidir.
  • Bu "madalyonun" tam tersi bir sorunu gideriyorsanız, son veya ilgili değişiklik listelerini arayın.
• Sisteme giriş yapın ve değiştirdiğiniz sunucu, servis veya donanım bileşenini seçin.
  • Bileşenler daha önce temel “demografik” bilgilerle (yer, satıcı, seri numarası, sorumlu bölüm) aynı sisteme girilir.
• Temel kategorilerin açılır listesinden seçim yapın
  • Planlanmamış arıza süresi
  • yama
  • Donanım Bakımı
  • Yazılım yüklenmesi
• Yaptıklarını, gördüklerini, gözlemlediklerini ayrıntılı olarak açıkla
• Bir kopya sorumlu tarafa gönderilir ve bir arama cihazı tarafından indekslenen XML dosyaları olarak saklanır.
• kâr

Dediğim gibi, süslü bir şey yok. PERL CGI (bir milyar yıl önce yazılmış) ve indeksleme için bir Google Arama cihazı kullanır.

eksiklikleri:

• Hizmet grupları ile çalışmak zordur, örneğin, etki alanı denetleyicilerinizin tümüne aynı düzeltme ekini eklediniz; bir "Etki Alanı Denetleyicisi" grubumuz olmadığı için hepsini manuel olarak seçmeliyiz
• Sorun gidermeye yardımcı olmak için donanım, yazılım veya olay günlüğü hata raporlaması ile entegre değil
• buna bağlı olarak, yukarıda belirttiğim gibi tüm 'demografik' veriler için manuel veri girişi

Her neyse, kodla ilgilenirseniz, bilmeme izin verin, ben de muhtemelen paylaşmak için onu alabilirim.

Söylediği gibi, genellikle kültürel bir mesele - sonuçta, bazı geliştirme dükkanları artık yorumlarla uğraşmıyor (kendi kendine belgelendirme kodu bugün moda bir terimdir!) Ve bazıları, tarihi kayıtların kutsal bir gazı olarak sürüm kontrol sistemini kullanıyor. Açıkçası, bunlar mükemmel değil.

Dolayısıyla, düzeltmenin tek gerçek yolu onu kültürel bir çözüm haline getirmektir. Tüm değişiklik nedenlerinin bir hata izleyicide (veya bilgi bankası veya wiki) kaydedildiğinden ve tüm değişikliklerin bir değişiklik kontrol sisteminde kaydedildiğinden emin olun.

Acil servis müşterilerimiz var, sistemlerinde meydana gelen her değişiklik günlüğe kaydedilir ve sisteme her giriş yaptığımızda günlüğe kaydetmemiz gerekir. Bazıları için önce izin almak için telefon etmek zorundayız (ve sanırım bunu da günlüğe tutuyorlar!). Her değişiklik kaydedilir ve müşteri sistemini günlüğe kaydetmeden değiştirmek, disiplin cezası alır.

Kulağa zor geliyor, ama değil. Kendinizi erişim günlüğüne ekleme ve günlüğünü değiştirme alışkanlığını hızla alıştırırsınız; kod değişikliğini denetlerken yorum yazmanıza gerek kalmaz.

Değişim kontrolü neden günlüğü olarak bir hata izleme aracı öneririm, bunlar genellikle güncellenmeleri kolaydır (Mantis kullanıyorum).

Eğer “kurumsal çözüm” arıyorsanız (yani, tanrıdan daha fazla paranız var ve gerçekten harika bir araca sahip olmak istiyorsanız), yerinde destek sağlamak ve yerinde çalışma sağlamak için kullandığım araç bunu çok yönlü özelliklerinden biri olarak yapıyor.

Baz fiyatlandırmanın ne olduğu hakkında hiçbir fikrim yok, ancak HP Opsware'i satın almadan önce ~ 350.000 ABD Doları (desteksiz ve güven bana - Opsware ile başladığımda destek istediniz).

Orada çalışırken sahip olduğumuz müşterilerin birçoğu, Tripwire ile birlikte uygulama yapılandırması ve anlık görüntü özelliklerini kullandı .

Tabii ki, bütçeniz yoksa - bu Kötü Bir Seçim ™ :)

Ve fwiw, yeniden yüklediğimde bu sayfanın en üstünde görünen reklam, spiceworks içindi . HPSA'ya benziyor mu :)

Yapmak istediğiniz tüm ise izlemek (şef veya kukla aracılığıyla, yani) tüm süreci yönetmek değişiklikleri değil, sadece rsyncsenin etcyerel git repo içine (yani, her nerede) dizin.

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

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

done

Elbette ihtiyaç duyduğunuz diğer kaynakları ekleyebilirsiniz.