Bagaimana cara merekam perubahan server?

Jadi kita semua mungkin mengalami situasi ini: Anda men-debug beberapa masalah, hanya untuk menyadari bahwa itu disebabkan oleh perubahan konfigurasi yang Anda buat enam bulan lalu, dan Anda tidak dapat mengingat mengapa Anda melakukannya. Jadi Anda membatalkannya dan memperbaiki masalahnya, dan sekarang beberapa masalah lain kembali. Oh ya, SEKARANG aku ingat! Maka Anda memperbaikinya dengan benar.

Itu karena kamu tidak mencatat dengan benar, bodoh! Tapi apa cara yang baik untuk melakukan ini?

Dalam rekayasa, kami memiliki banyak perangkat lunak yang dimaksudkan untuk membantu kami mendeteksi dan melacak perubahan. Kontrol sumber, ulasan kode, dan sebagainya. Setiap perubahan dilacak, setiap perubahan membutuhkan komentar tentang apa itu. Dan departemen teknik tipikal memerlukan komentar yang baik sehingga dalam enam bulan ketika Anda mencari tahu mengapa Anda melanggarnya seperti itu, Anda dapat menggunakan fitur 'menyalahkan' historis atau membangun pencarian biner untuk menunjukkan masalah. Alat-alat ini adalah alat komunikasi yang sangat efektif dan catatan sejarah.

Namun di serverland, kami memiliki 500 layanan berbeda, semuanya dengan berbagai cara untuk mengonfigurasinya. Dan mereka tidak selalu memiliki format teks (pertimbangkan pengaturan izin pada folder atau mengubah lokasi pagefile) meskipun mereka mungkin memiliki representasi tekstual.

Di lingkungan kami, kami memeriksa file konfigurasi apa yang kami bisa masuk ke Perforce, tetapi jumlahnya sangat sedikit. Tidak dapat secara tepat memeriksa di Active Directory DB .. walaupun mungkin dump yang dapat berbeda ...

Di masa lalu saya telah mencoba menyimpan log perubahan manual di wiki kami, tetapi sangat sulit untuk mempertahankan disiplin untuk melakukan ini (saya tahu, bukan alasan yang bagus, tapi itu benar-benar sulit).

PERTANYAAN SAYA: Strategi dan alat apa yang Anda gunakan untuk mengatasi masalah pelacakan perubahan konfigurasi ke server Anda?

- Perbarui -

Catatan: Saya tidak mencari alat pengambilan catatan bersama (saya kenal dengan OneNote, dll) sebanyak alat otomatis yang khusus dimaksudkan untuk membantu melacak perubahan server. Tidak ada alat komprehensif untuk melacak perubahan konfigurasi server, tetapi mungkin ada beberapa aplikasi spesifik seperti GPO.

Saya juga sangat tertarik dengan strategi spesifik yang menurut Anda berguna. "Kami berbagi catatan di Sharepoint" cukup kabur. Bagaimana Anda menjaga disiplin? Format apa yang Anda gunakan untuk melacak perubahan Anda? Bagaimana Anda mengatur data perubahan Anda? Saya sangat suka contoh dan ide.

Di tanah Linux, orang mengejar beberapa strategi yang berbeda:

• Sistem kendala konfigurasi , seperti cfengine atau boneka atau koki . Ini mirip dengan windows GPO. Intinya adalah bahwa semua konfigurasi server sengaja didokumentasikan di satu tempat dan Anda tahu pada granularity apa (ruang server, grup, server spesifik) kebijakan yang diberlakukan. Ini tidak akan menyelamatkan Anda dari "apa yang berbeda enam bulan yang lalu?" tetapi tidak membiarkan Anda hanya nuke konfigurasi server dan membangun kembali dari awal. Anda mungkin menempatkan kebijakan cfengine dan boneka di bawah kendali revisi untuk menjawab pertanyaan.
• Pengendalian revisi / dll . Umumnya, program Linux menyimpan konfigurasinya di satu tempat, / dll. Keberanian mulai menulis skrip untuk menempatkan / etc ke dalam kontrol revisi. Salah satu program yang saya tahu adalah penjaga dll :

Keterangan: store / etc in git, mercurial, bzr atau darcs
 Program etckeeper adalah alat untuk membiarkan / etc disimpan dalam git, lincah,
 repositori bzr atau darcs. Ini terhubung ke APT untuk secara otomatis melakukan perubahan
 dibuat ke / etc saat upgrade paket. Ini melacak metadata file versi itu
 sistem kontrol biasanya tidak mendukung, tetapi itu penting untuk / etc, semacamnya
 sebagai izin dari / etc / shadow. Ini cukup modular dan dapat dikonfigurasi, sementara
 juga mudah digunakan jika Anda memahami dasar-dasar bekerja dengan versi
 kontrol.

Salah satu masalah dalam situasi ini adalah, sungguh, itu adalah kombinasi proses bisnis / masalah teknologi. Dan jelas lebih besar dari sekedar melacak perubahan yang dilakukan admin. Anda juga perlu mengawasi perubahan tak terduga, dan koordinasi yang baik antara admin atau unit sehingga perubahan pada pengontrol AD ​​tidak merusak pengaturan izin basis data pada beberapa server departemen. Yaitu, pertanyaan Anda adalah kaleng raksasa cacing :)

Dalam organisasi saya, kami sekitar satu tahun dalam meluncurkan proses dan sistem untuk mengatasi ini. Untuk sisi proses bisnis kami membentuk tim Manajemen Perubahan. Menurut SOP semua perubahan pada lingkungan produksi dikoordinasikan melalui mereka. Mereka mengkompilasi semua perubahan, bersama dengan ruang lingkup, sistem yang terpengaruh, layanan yang terpengaruh, dll. Menerapkan dokumentasi yang baik tentang perubahan, serta rencana roll-out dan roll-back. Host rapat mingguan (terbuka) untuk membahas perubahan lingkungan yang akan datang, kemudian kirim email keluar merinci semua perubahan ini. Tujuan akhir dengan proses ini adalah agar, secara efektif, semua orang di TI mengetahui segala sesuatu yang terjadi. Ini membantu menghentikan masalah, misalnya, SysAdmin menginstal patch kernel dan me-reboot sistem yang akan menghapus database timeclock.

Sedangkan untuk sisi teknologi saya hanya bisa berbicara tentang orang-orang Unix / Linux karena saya tidak berurusan dengan Windows. Mereka telah meluncurkan Puppet, oleh Reductive Labs, untuk manajemen konfigurasi semua sistem tersebut. Sederhananya, adalah sistem klien / server di mana seseorang mendefinisikan konfigurasi mesin di server, dan klien sering menarik peluang itu (seringnya adalah 30 menit). Selain itu, jika ada peluang dibuat untuk file yang dikelola secara lokal maka mereka dikembalikan kembali pada waktu itu juga. Kami menggunakannya untuk mengelola layanan yang sedang berjalan, konfigurasi firewall, otorisasi pengguna, dll.

Saya juga akan merekomendasikan melihat sesuatu seperti TippingPoint. Ini adalah layanan klien yang mengawasi konfigurasi sistem, dan mengirimkan peringatan tentang perubahan. Itu membuat kami orang keamanan paling bahagia. Ini sebagian besar digunakan untuk melacak perubahan berbahaya atau tidak dipublikasikan.

Saya telah di 4 atau 5 perusahaan sekarang saya tidak begitu ingat.

Kita semua memiliki masalah ini. Tidak ada di antara kita yang menyelesaikannya 100 persen, tetapi di perusahaan saya sekarang kita memiliki apa yang saya pikir merupakan strategi terbaik hingga saat ini.

Sharepoint / Wiki / Evernote / PIN

• Sharepoint
  • mengerang semua yang Anda inginkan ... ia memiliki beberapa fitur daftar yang sangat bagus.
  • Daftar alamat IP
  • inventaris
  • akun layanan dan penggunaan
  • ubah log pemberitahuan
• Wiki
  • Bagaimana caranya
  • daftar tugas jangka panjang
• Evernote
  • saya dan mitra saya menggunakan ini untuk meletakkan semua yang tidak kita inginkan di Wiki
  • lebih banyak how-to yang bersifat teknis
  • catatan awal yang harus kita lihat
  • akuntansi tugas untuk minggu ini
  • daftar tugas kontraktor
  • clipper evernote memudahkan untuk menyaring pengaturan AD / hak pengambilan gambar
  • tersedia di mana-mana
• PIN
  • Repositori kata sandi

Mungkin ada alat yang lebih baik untuk beberapa di antaranya, tetapi inilah yang kami gunakan:

• Lacak perubahan konfigurasi dan pemutakhiran / tambalan berdasarkan per-server di wiki pribadi
• Juga simpan howtos dan catatan masalah / solusi di wiki
• Gunakan Sharepoint atau Google Documents untuk menyimpan salinan hal-hal yang otoritatif seperti daftar IP statis
• gunakan Subversion untuk melacak perubahan pada file konfigurasi

Untuk Windows, lihat seri Microsofts System Center atau pesaing lain dalam konfigurasi dan manajemen layanan untuk platform itu.

Perubahan perlu dialihkan melalui rutin manajemen perubahan yang layak yang dengan sendirinya menyetujui dan mencatatnya sebelum benar-benar dilakukan. Ini bisa menjadi manual 100% untuk pemula. Dengan beberapa alat terintegrasi yang lebih baik, Anda dapat meminta alat untuk melakukan perubahan aktual dan mengeluarkan "otomatis" dari itu ke basis data konfigurasi pusat - daripada langsung ke konsol server individual, menggali pengaturan dengan tangan untuk coba dan perbaiki masalah ala koboi.

Anda benar-benar harus memiliki proses manajemen perubahan, terutama jika ada beberapa orang yang memiliki kemampuan / akses untuk membuat perubahan pada tingkat sistem di lingkungan Anda. Ini juga menyediakan cara bagi manajemen untuk menandatangani perubahan potensial, namun kerugian yang terjadi menyebabkan latensi dalam proses perubahan jika Anda tidak dapat melakukan perubahan dengan cepat.

Beberapa cara melacak perubahan mungkin termasuk validasi acara di SEM Anda (dengan asumsi Anda memiliki Security Event Manager) atau alat seperti Nessus (dengan banyak pekerjaan dapat mengaudit lingkungan Anda untuk menemukan perubahan).

Ini adalah jawaban yang lebih lokal, berdasarkan * nix. Saya belum menemukan alat yang bagus untuk meniru di bawah Windows.

Ada beberapa cara untuk mengimplementasikan ini ... dan menangkapnya ketika Anda lupa.

Sistem kontrol revisi seperti subversi, git, cvs atau RCS adalah cara yang baik untuk melacak sejarah file konfigurasi. Jika Anda tidak ingin menginstal sistem kontrol revisi pada server produksi Anda, menyimpan direktori file konfigurasi baik secara lokal atau jarak jauh menggunakan sesuatu seperti rsnapshot akan memberi Anda sebagian besar manfaat RCS, tetapi Anda kehilangan kemungkinan diaudit atau meninggalkan komit log (meskipun ini bisa diselesaikan dengan komentar di dalam file itu sendiri).

Untuk membantu Anda mengingat untuk mencatat perubahan, pelaporan otomatis perubahan konfigurasi melalui tripwire yang dijalankan setiap malam, merupakan awal yang baik. Setelah membuat basis data tripwire tentang status file saat ini, perubahan apa pun pada file tersebut akan menghasilkan email selama proses berikutnya. Anda akan terus menerima email ini sampai database diperbarui, sehingga "mengatur ulang" tripwire.

Saya akan menggunakan sistem pelacakan masalah seperti flyspray (ada yang akan lakukan, tapi saya suka flyspray untuk hal-hal yang bukan pemrograman). Sebelum ada yang menyentuh konfigurasi, perbaikan / masalah harus dicatat. Saat Anda memperbaiki / mengimplementasikannya, perubahannya ada di tiket.

Sebuah wiki bisa bagus untuk mendokumentasikan pengaturan saat ini, tetapi mudah untuk keluar dari tanggal - dan tampaknya butuh upaya lebih untuk memperbarui IMO.

Anda tidak akan menemukan sesuatu yang otomatis untuk melakukan ini - walaupun Anda mungkin bisa mengaturnya sehingga perubahan pada file konfigurasi tertentu secara otomatis diemailkan ke pelacak masalah jika Anda mau.

Saya pikir itu hanya masalah kebijakan yang baik, alat penghalang rendah dan disiplin.

Kami menciptakan sesuatu yang dibuat sendiri untuk melakukan perubahan pelacakan log di lingkungan kami; itu bukan sesuatu yang sangat rumit, dan itu bekerja dengan baik.

• Kebijakan kebijakan mandiri adalah pengaturan bahwa perubahan apa pun yang menurut perkiraan Anda menyimpang dari pengaturan di luar kotak atau berpotensi menyebabkan masalah, harus didokumentasikan dalam sistem changelog.
  • sisi berlawanan dari 'koin' ini adalah jika Anda memecahkan masalah, cari entri log perubahan terbaru atau yang terkait.
• Masuk ke sistem dan pilih komponen server, layanan, atau perangkat keras yang Anda ubah
  • komponen sebelumnya dimasukkan ke dalam sistem yang sama dengan informasi 'demografis' dasar (lokasi, vendor, nomor seri, departemen yang bertanggung jawab)
• Pilih dari drop-down kategori dasar
  • Waktu henti yang tidak dijadwalkan
  • Menambal
  • Perawatan Perangkat Keras
  • Instalasi Perangkat Lunak
• Masukkan detail dari apa yang Anda lakukan, lihat, amati
• salinan dikirim ke pihak yang bertanggung jawab dan disimpan sebagai file XML yang diindeks oleh alat pencarian.
• Keuntungan

Seperti yang saya katakan, tidak ada yang mewah. Ini menggunakan PERL CGI (ditulis satu miliar tahun yang lalu), dan alat Google Search untuk pengindeksan.

Kekurangan:

• Grup layanan sulit untuk dikerjakan, misalnya, Anda baru saja menambahkan tambalan yang sama ke 25 pengontrol domain Anda; kami tidak memiliki grup "Kontroler Domain", jadi kami harus memilih semuanya secara manual
• Tidak berintegrasi dengan perangkat keras, perangkat lunak, atau pelaporan kesalahan log peristiwa untuk membantu mengatasi masalah
• terkait, entri data manual untuk semua data 'demografis' seperti yang saya katakan di atas

Ngomong-ngomong, jika Anda semua tertarik pada kode, beri tahu saya dan saya mungkin dapat mengambilnya untuk dibagikan.

Seperti yang dikatakan, ini sering menjadi masalah budaya - lagipula, beberapa toko pengembangan tidak lagi repot dengan komentar (kode mendokumentasikan diri adalah kata kunci yang modis saat ini!) Dan beberapa menggunakan sistem kontrol versi sebagai cawan suci catatan sejarah. Jelas, ini tidak sempurna.

Jadi, satu-satunya cara yang benar untuk memperbaikinya adalah menjadikannya solusi budaya. Pastikan semua alasan untuk perubahan dicatat dalam pelacak bug (atau basis pengetahuan, atau wiki), dan pastikan semua perubahan dicatat dalam sistem kontrol perubahan.

Kami memiliki pelanggan layanan darurat, setiap perubahan yang terjadi pada sistem mereka dicatat, dan setiap kali kami masuk ke sistem mereka, kami harus mencatatnya. Untuk beberapa dari mereka, kita harus menelepon terlebih dahulu untuk mendapatkan izin (dan saya kira mereka juga mencatatnya!). Setiap perubahan dicatat, dan itu akan menjadi pelanggaran disiplin untuk mengubah sistem pelanggan tanpa mencatatnya.

Kedengarannya berat, tapi tidak. Anda dengan cepat terbiasa menambahkan diri Anda ke log akses dan mengubah log - tidak lebih buruk daripada harus menulis komentar saat memeriksa perubahan kode.

Saya merekomendasikan bugtracker sebagai log alasan perubahan kontrol, karena biasanya mudah diperbarui (saya menggunakan Mantis).

Jika Anda mencari "solusi perusahaan" (yaitu, Anda memiliki lebih banyak uang daripada dewa dan ingin memiliki alat yang benar-benar keren), alat yang saya gunakan untuk mendukung dan menyediakan pekerjaan di tempat untuk melakukan ini sebagai salah satu fitur yang beraneka ragam.

Tidak tahu apa harga dasarnya, tetapi sebelum HP membeli Opsware, harganya $ 350.000 AS (tanpa dukungan, dan percayalah - Anda menginginkan dukungan ketika saya mulai dengan Opsware).

Beberapa pelanggan yang kami miliki ketika saya bekerja di sana menggunakan konfigurasi aplikasi dan fitur snapshot bersama dengan Tripwire .

Tentu saja, jika Anda tidak memiliki anggaran - ini adalah Pilihan Buruk :)

Dan, fwiw, iklan yang muncul di bagian atas halaman ini untuk saya ketika saya memuat ulang itu untuk spiceworks . Tampak perkasa mirip dengan HPSA :)

Jika semua yang ingin Anda lakukan adalah melacak perubahan dan tidak mengelola seluruh proses (yaitu, melalui Chef atau Wayang), cukup direktori rsyncAnda etc(di mana pun itu mungkin) menjadi repo git lokal.

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

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

done

Anda tentu saja dapat menambahkan sumber lain sesuai kebutuhan.