Apakah ada anti-pola yang terkenal di bidang administrasi sistem? [Tutup]

Saya tahu beberapa pola umum yang tampaknya mengganggu hampir setiap proyek di beberapa titik dalam siklus hidupnya:

1. Ketidakmampuan untuk mengambil pemadaman
2. Komponen pihak ketiga mengunci pembaruan
3. Lingkungan yang tidak seragam
4. Kurangnya pemantauan dan peringatan
5. Redundansi tidak ada
6. Kurangnya Kapasitas
7. Manajemen Perubahan yang Buruk
8. Kebijakan akses terlalu liberal atau ketat
9. Perubahan organisasi secara negatif mengaburkan kepemilikan infrastruktur

Saya berharap ada beberapa perpustakaan anti-pola yang diartikulasikan dengan baik yang dirangkum dalam sebuah buku atau situs web. Saya hampir yakin bahwa banyak organisasi belajar melalui percobaan dengan metode api. Jika tidak, mari kita mulai.

Meninggalkan tugas yang dapat diautomatiskan menjadi otomatis hingga melakukannya secara manual membutuhkan waktu yang cukup lama sehingga tidak dapat diotomatisasi, karena melakukan tugas secara manual memakan sepanjang waktu.

Sebaliknya, otomatisasi dini. Sama sekali tidak perlu menghabiskan 3N jam mengotomatiskan tugas satu-shot yang membutuhkan N jam untuk dilakukan secara manual (bahkan jika itu lebih menyenangkan mengotomatisasi daripada slogging melalui sesuatu dengan tangan).

A. tidak menguji pemulihan - cadangan dapat diverifikasi dan ok, tapi bagaimana mengembalikan?

Berapa lama, apa yang dibutuhkan? Anda harus tahu untuk melakukan itu dalam situasi tertekan ...

B. tidak ada manajemen konfigurasi, tidak ada keseragaman - hanya perubahan di sana-sini dan saya pikir saya telah menyetel beberapa di sini ...

Siapa yang tahu bagaimana mereplikasi server yang dilakukan dengan baik jika semua kebiasaan tidak ditulis dan tidak ada konfigurasi yang identik di toko? Bagaimana jika Anda berhasil memulihkan data, tetapi bukan konfigurasi, aplikasi?

C. tidak ada pemantauan - tidak tahu bagaimana dan kotak apa yang dilakukan

Ini ada dua: a) Anda harus memantau alarm untuk bereaksi dalam waktu sebelum Anda kehabisan sumber daya atau perilaku aneh dan b) Anda harus memantau tren jangka panjang untuk mengelola kapasitas (disk, CPU, RAM, jaringan,. ..)

D. tidak ada redundansi di cfg Anda - apa yang terjadi ketika XX mati

Ini berarti merencanakan ke depan apa yang Anda inginkan dari sysadmin Anda.

Bagi saya ini yang paling penting.

Pola yang paling mematikan adalah ketika departemen administrasi sistem (atau seluruh TI) menjadi peserta pasif di perusahaan. Artinya, mereka dipandang sebagai layanan mandiri di mana setiap orang datang dengan ide-ide yang sudah terbentuk bagaimana hal-hal harus dilakukan, yang secara eksklusif mempertimbangkan kebutuhan pengguna dan bukan kebutuhan ekosistem TI lengkap secara keseluruhan.

Pola pembunuhan terbanyak kedua adalah ketika departemen administrasi sistem berubah menjadi sekelompok tombol push, yaitu semua perangkat lunak / alat dibeli atau dikembangkan oleh pihak ketiga dan administrasi sistem mendapatkan pelatihan dan manual resmi dan kemudian hanya mengikuti operasi manual dan eskalasi ke vendor segala sesuatu yang tidak secara eksplisit dalam manual. Situasi ini mungkin sangat nyaman bagi (beberapa jika tidak sebagian besar) administrator sistem, tetapi ini adalah bencana yang menunggu untuk terjadi ketika fakta bahwa tidak ada yang benar-benar tahu bagaimana keseluruhan sistem bekerja akan membawanya ke tanah (pikirkan interaksi halus antara komponen dan permainan menyalahkan antara vendor).

1) kelebihan-janji dan kurang-pengiriman (yaitu menjaga harapan pengguna tetap realistis)

2) Tidak memverifikasi cadangan sampai dibutuhkan.

sunting: Saya bermaksud nomor 2 untuk memasukkan pemulihan file / data

Tidak memantau pola penggunaan akun AD seperti waktu login terakhir> 30 hari

(Kita harus melakukan ini untuk alasan audit, tetapi hasilnya cukup mengejutkan)

• Menyimpan informasi kunci di folder kepala / kotak masuk / dokumen satu orang. Jika penting, seperti detail kontak vendor, kunci lisensi, instruksi pengaturan, itu harus tersedia untuk semua orang di departemen yang memiliki wewenang dan mungkin perlu mengaksesnya, dan di tempat standar.

• Meminta orang yang tahu tentang sesuatu untuk mendokumentasikannya. Ini kedengarannya bagus karena mereka adalah orang yang memiliki pengetahuan, tetapi sebenarnya buruk karena mereka tidak dapat dengan mudah mengatakan apa pengetahuan yang penting itu. Lebih baik untuk memiliki seseorang yang baru berurusan dengannya, meminta orang yang berpengetahuan itu informasi yang mereka butuhkan dan meminta mereka mendokumentasikan saat mereka melakukannya.

• Dokumentasi tidak jelas. Siapa pun dapat memperbaiki masalah prioritas menengah di siang hari dengan seluruh departemen TI tersedia untuk diajak bicara. Ini masalah lain untuk memperbaiki masalah prioritas tinggi pada larut malam ketika Anda hampir sendirian dan tidak tahu mengapa sistem mengaturnya atau mengapa tidak sesuai dengan apa yang dikatakan dokumentasi.

• Tidak melacak kata sandi dengan baik. Jadi Anda dengan cepat memerlukan akun, buat satu dengan kata sandi acak dan kemudian 18 bulan kemudian masih digunakan dan tidak ada yang tahu kata sandi atau layanan mana yang akan rusak jika diubah.

• Tidak membeli dukungan vendor untuk sistem utama karena "terlalu mahal".

• Prioritas yang tidak pantas. Orang-orang TI harus dipandu oleh manajemen - perjanjian tentang proyek mana yang menjadi prioritas, atau dalam keadaan darurat sistem mana yang diperlukan terlebih dahulu harus ada. Jika TI sedang mencoba memperbaiki sistem bisnis, manajemen meminta email dan pengguna menuntut pemrosesan pesanan itu adalah resep untuk kekacauan.

• Solusi yang tidak pantas - sangat mudah bagi IT untuk terjebak dalam pola pikir "untuk memperbaikinya, sistem TI harus bekerja seperti sebelumnya", ketika mungkin lebih tepat untuk memiliki perjanjian manajemen-TI untuk "mencoba untuk 2 berjam-jam, jika tidak diperbaiki maka hentikan bahkan jika itu tampak menjanjikan, dan beralihlah untuk memulihkan dari cadangan. "

• Salinan file uji di mana-mana. Anda tidak ingin membuka folder yang menjalankan sistem bisnis atau situs web dan lihat "situs web baru /, situs web saat ini /, salin situs web /, situs web pengujian /, tes situs web dave /, penggunaan situs web- this-one /, website-from-feb /, dll). Pengembang, produksi dan pengujian harus ada dan harus dipisahkan dengan setiap departemen yang terlibat (IT, pengembang, manajemen proyek, dll) mengetahui apa yang harus di mana dan menyepakati bagaimana perubahan disetujui. Juga untuk file konfigurasi.

• Ubah persetujuan - bahkan jika Anda baru saja berdiskusi secara lisan terlebih dahulu, jangan mengubah cara kerja hal-hal penting tanpa diketahui orang lain. Terserah Anda untuk memutuskan apa yang "penting" mencakup situasi Anda.

• Solusi berbadan ditinggalkan di tempat jangka panjang. Saya tahu Anda menambal server ini ke jaringan itu dengan kabel telepon lama dengan cepat sehingga Anda dapat mengatasi masalah yang mendesak. Saya tahu Anda tidak punya waktu untuk mengulanginya dengan benar. Luangkan waktu.

• Hubungan yang buruk dengan anggota perusahaan yang lain. TI adalah layanan yang membantu seluruh perusahaan melakukan pekerjaannya. Jika mereka membutuhkan file besar dengan cepat, mewujudkannya. Jika Anda memerlukan persetujuan manajerial untuk membeli perangkat keras, dapatkan itu. Jika Anda tidak bisa mendapatkannya, komunikasikan dengan jelas bahwa file besar tidak dapat bergerak cepat karena manajemen telah memprioritaskan beberapa pengeluaran lainnya. Jika Anda perlu pengarsipan karena alasan hukum tetapi tidak memiliki anggaran maka Anda perlu memasukkan pengarsipan ke dalam sistem Anda sebaik mungkin.