Artikel ini adalah yang pertama dari serangkaian artikel yang berjudul “Bagaimana Mengambil Infrastruktur Jaringan Di Bawah Kontrol Anda”. Isi semua artikel dalam seri dan tautan dapat ditemukan di sini .
Saya sepenuhnya mengakui bahwa ada cukup banyak perusahaan di mana jaringan sederhana satu jam atau bahkan satu hari tidak kritis. Sayangnya atau untungnya, saya tidak memiliki kesempatan untuk bekerja di tempat seperti itu. Tetapi, tentu saja, jaringannya berbeda, persyaratannya berbeda, pendekatannya berbeda, namun, dalam satu atau lain bentuk, daftar di bawah ini dalam banyak kasus sebenarnya adalah "tiang kapal".
Jadi, syarat awalnya.
Anda berada di tempat kerja yang baru atau memiliki promosi, atau Anda memutuskan untuk melihat dengan segar tanggung jawab Anda. Jaringan perusahaan adalah bidang tanggung jawab Anda. Bagi Anda, ini sebagian besar merupakan tantangan dan yang baru, yang agak membenarkan nada pendampingan artikel ini :). Tapi, saya berharap artikel itu juga dapat bermanfaat bagi insinyur jaringan mana pun.
Tujuan strategis pertama Anda adalah belajar untuk menolak entropi dan mempertahankan tingkat layanan yang diberikan.
Banyak tugas yang dijelaskan di bawah ini dapat diselesaikan dengan berbagai cara. Saya sengaja tidak mengangkat topik implementasi teknis, karena pada prinsipnya, seringkali tidak begitu penting bagaimana Anda memecahkan masalah tertentu, tetapi bagaimana Anda menggunakannya dan apakah Anda menggunakannya sama sekali adalah penting. Ini tidak banyak berguna, misalnya, dari sistem pemantauan yang dibangun secara profesional, jika Anda tidak melihat di sana dan tidak menanggapi peringatan.
Peralatan
Pertama, Anda perlu memahami di mana risiko terbesar berada.
Sekali lagi, ini bisa berbeda. Saya akui bahwa di suatu tempat, misalnya, ini akan menjadi masalah keamanan, dan di suatu tempat masalah yang berkaitan dengan kelangsungan layanan, dan di suatu tempat, mungkin, sesuatu yang lain. Kenapa tidak
Anggaplah dengan pasti bahwa ini adalah kesinambungan layanan (ini adalah kasus di semua perusahaan tempat saya bekerja).
Maka Anda harus mulai dengan peralatan. Berikut adalah daftar topik yang harus diperhatikan:
- klasifikasi kekritisan peralatan
- redundansi peralatan penting
- dukungan, lisensi
Anda harus mempertimbangkan kemungkinan kerusakan, terutama dengan peralatan di bagian atas klasifikasi kekritisan Anda. Biasanya, probabilitas masalah ganda diabaikan, jika tidak solusi dan dukungan Anda bisa menjadi terlalu mahal, tetapi dalam kasus elemen jaringan yang sangat kritis, kegagalan yang dapat secara signifikan mempengaruhi bisnis, Anda harus memikirkan hal ini.
Contoh
Misalkan kita berbicara tentang switch root di pusat data.
Karena kami sepakat bahwa kesinambungan layanan adalah kriteria paling penting, masuk akal untuk memberikan "redundansi" peralatan ini. Tapi itu belum semuanya. Anda juga harus memutuskan berapa lama, jika terjadi kerusakan pada sakelar pertama, Anda dapat hidup dengan hanya satu sakelar yang tersisa, karena ada risiko sakelar itu akan rusak.
Penting! Anda tidak harus menyelesaikan masalah ini sendiri. Anda harus menggambarkan risiko, kemungkinan solusi, dan nilai bagi manajemen Anda atau manajemen perusahaan. Mereka harus membuat keputusan.
Jadi, jika diputuskan bahwa, mengingat kecilnya kemungkinan kerusakan ganda, bekerja selama 4 jam pada satu saklar, pada prinsipnya, dapat diterima, maka Anda dapat mengambil dukungan yang sesuai (untuk mana peralatan akan diganti dalam waktu 4 jam).
Tetapi ada risiko bahwa mereka tidak akan dikirimkan. Sayangnya, begitu kita menemukan diri kita dalam situasi seperti itu. Alih-alih empat jam, peralatan berjalan selama seminggu !!!
Karena itu, risiko ini juga perlu dibahas, dan mungkin akan lebih tepat bagi Anda untuk membeli sakelar lain (ketiga) dan menyimpannya di suku cadang (cadangan dingin) atau menggunakannya untuk keperluan laboratorium.
Penting! Buatlah tabel dari semua dukungan yang Anda miliki dengan tanggal akhir dan tambahkan mereka ke kalender sehingga setidaknya sebulan kemudian Anda menerima surat bahwa Anda harus mulai khawatir tentang memperluas dukungan.Anda tidak akan dimaafkan jika Anda lupa memperpanjang dukungan dan sehari setelah itu berakhir, peralatan Anda akan mogok.
Pekerjaan darurat
Apa pun yang terjadi pada jaringan Anda, idealnya, Anda harus menjaga akses ke peralatan jaringan Anda.
Penting! Anda harus memiliki akses konsol ke semua peralatan dan akses ini tidak boleh bergantung pada operabilitas jaringan transmisi data pengguna (data).Anda juga harus melihat kemungkinan skenario negatif dan mendokumentasikan tindakan yang diperlukan. Ketersediaan dokumen ini sangat penting, oleh karena itu tidak hanya harus dibagikan pada sumber daya yang dibagikan oleh departemen, tetapi juga disimpan secara lokal di komputer insinyur.
Pasti ada
- informasi yang diperlukan untuk membuka aplikasi yang mendukung vendor atau integrator
- informasi tentang cara mendapatkan peralatan apa pun (konsol, manajemen)
Tentu saja, informasi bermanfaat lainnya dapat dimuat, misalnya, deskripsi prosedur peningkatan untuk berbagai peralatan dan perintah diagnostik yang berguna.
Mitra
Sekarang Anda perlu menilai risiko yang terkait dengan mitra. Biasanya itu
- Penyedia layanan internet dan titik pertukaran lalu lintas (IX)
- penyedia saluran komunikasi
Pertanyaan apa yang perlu Anda tanyakan pada diri sendiri? Seperti halnya peralatan, perlu mempertimbangkan berbagai opsi untuk situasi darurat. Misalnya, untuk penyedia layanan Internet, bisa jadi seperti:
- Apa yang akan terjadi jika ISP X berhenti memberikan Anda layanan karena suatu alasan?
- Apakah Anda memiliki bandwidth yang cukup untuk penyedia lainnya?
- seberapa baik koherensi akan tetap?
- Seberapa independen ISP Anda dan apakah kecelakaan serius di salah satunya akan menimbulkan masalah dengan yang lain?
- berapa banyak input optik ke pusat data Anda?
- Apa yang terjadi jika salah satu input benar-benar hancur?
Adapun input, dalam praktik saya di dua perusahaan yang berbeda, di dua pusat data yang berbeda, excavator menghancurkan sumur dan hanya dengan keajaiban optik kami tidak terpengaruh. Ini bukan kasus yang jarang terjadi.
Yah, tentu saja, Anda tidak hanya perlu mengajukan pertanyaan-pertanyaan ini, tetapi, sekali lagi, dengan dukungan dari kepemimpinan, untuk memberikan solusi yang dapat diterima dalam situasi apa pun.
Cadangkan
Prioritas berikutnya mungkin cadangan konfigurasi perangkat keras. Bagaimanapun, ini adalah poin yang sangat penting. Saya tidak akan mencantumkan kasus-kasus di mana Anda dapat kehilangan konfigurasi, lebih baik untuk membuat cadangan reguler dan tidak memikirkannya. Selain itu, cadangan reguler dapat sangat berguna dalam mengendalikan perubahan.
Penting! Buat cadangan setiap hari. Ini bukan data dalam jumlah besar untuk disimpan. Di pagi hari, insinyur yang bertugas (atau Anda) harus menerima laporan dari sistem yang dengan jelas menunjukkan apakah cadangan berhasil atau tidak, dan jika cadangan tidak berhasil, masalahnya harus diselesaikan atau tiket harus dibuat (lihat proses departemen jaringan).Versi perangkat lunak
Pertanyaan apakah akan meningkatkan atau tidak perangkat lunak perangkat keras tidak begitu jelas. Di satu sisi, versi lama dikenal sebagai bug dan kerentanan, tetapi di sisi lain, perangkat lunak baru, pertama, tidak selalu merupakan prosedur peningkatan tanpa rasa sakit, dan kedua, bug dan kerentanan baru.
Di sini Anda perlu menemukan opsi terbaik. Beberapa rekomendasi yang jelas
- hanya versi stabil
- Namun, Anda tidak boleh hidup dengan versi perangkat lunak yang sangat lama
- membuat tanda dengan informasi di mana ada perangkat lunak
- membaca laporan tentang kerentanan dan bug dalam versi perangkat lunak secara berkala, dan jika ada masalah kritis, sebaiknya pikirkan tentang peningkatan
Pada tahap ini, dengan memiliki akses konsol ke peralatan, informasi pendukung, dan deskripsi prosedur peningkatan, Anda, pada prinsipnya, siap untuk langkah ini. Pilihan yang ideal adalah ketika Anda memiliki peralatan laboratorium di mana Anda dapat memeriksa seluruh prosedur, tetapi, sayangnya, ini tidak sering terjadi.
Dalam hal peralatan kritis, Anda dapat menghubungi dukungan vendor dengan permintaan untuk membantu Anda dengan peningkatan.
Sistem tiket
Sekarang Anda bisa melihat-lihat. Anda perlu membangun proses interaksi dengan departemen lain dan di dalam departemen tersebut.
Mungkin ini tidak wajib (misalnya, jika perusahaan Anda kecil), tetapi saya sangat merekomendasikan untuk mengatur pekerjaan sedemikian rupa sehingga semua tugas eksternal dan internal melewati sistem tiket.
Sistem tiket pada dasarnya adalah antarmuka Anda untuk komunikasi internal dan eksternal, dan Anda harus menggambarkan antarmuka ini dengan tingkat detail yang memadai.
Mari kita ambil contoh tugas penting dan sering dihadapi untuk membuka akses. Saya akan menjelaskan algoritma yang bekerja sangat baik di salah satu perusahaan.
Contoh
Sebagai permulaan, seringkali akses pelanggan mengartikulasikan keinginan mereka dalam bahasa yang tidak dapat dipahami oleh insinyur jaringan, yaitu, dalam bahasa aplikasi, misalnya, "beri saya akses ke 1C".
Karenanya, kami tidak pernah menerima permintaan langsung dari pengguna tersebut.
Dan itu adalah persyaratan pertama
- permintaan untuk akses harus berasal dari departemen teknis (dalam kasus kami, ini adalah unix, windows, helpdesk engineer)
Persyaratan kedua adalah itu
- akses ini harus dicatat (oleh departemen teknis dari mana kami menerima permintaan ini) dan sebagai permintaan kami mendapatkan tautan ke akses yang dicatat ini
Bentuk permintaan ini harus jelas bagi kami, yaitu
- permintaan tersebut harus berisi informasi yang dan di mana akses subnet harus terbuka, juga pada protokol dan (dalam kasus tcp / udp) port
Juga harus ditunjukkan
- deskripsi mengapa akses ini dibuka
- sementara atau permanen (jika sementara, sampai tanggal berapa)
Dan poin yang sangat penting adalah
- dari kepala departemen yang memprakarsai akses (mis., akuntansi)
- dari kepala departemen teknis, dari mana permintaan ini datang ke departemen jaringan (misalnya, helpdesk)
Pada saat yang sama, "pemilik" akses ini dianggap sebagai kepala departemen yang memprakarsai akses (pembukuan dalam contoh kami), dan ia bertanggung jawab untuk menjaga halaman dengan akses log untuk departemen ini tetap mutakhir.
Penebangan
Ini adalah sesuatu untuk ditenggelamkan. Tetapi jika Anda ingin menerapkan pendekatan proaktif, maka Anda perlu belajar cara menangani aliran data ini.
Berikut ini beberapa saran praktis:
- lihat log yang Anda butuhkan setiap hari
- dalam hal tampilan terjadwal (dan bukan keadaan darurat), Anda dapat membatasi diri hingga tingkat keparahan 0, 1, 2 dan menambahkan pola favorit Anda dari level lain jika Anda menganggap perlu
- tulis skrip yang mem-parsing log dan abaikan saja log yang polanya telah Anda tambahkan ke daftar abaikan
Pendekatan ini akan memungkinkan dari waktu ke waktu mengkompilasi daftar log yang tidak Anda sukai dan hanya menyisakan yang menurut Anda penting.
Ini bekerja sangat baik untuk kita.
Pemantauan
Bukan hal yang aneh ketika perusahaan tidak memiliki sistem pemantauan. Anda dapat, misalnya, bergantung pada log, tetapi peralatan tersebut dapat "mati" tanpa harus "mengatakan" apa pun, atau paket protokol syslog udp mungkin hilang dan tidak terjangkau. Secara umum, tentu saja, pemantauan aktif adalah penting dan perlu.
Dua contoh yang paling dituntut dalam praktik saya:
- memantau pemuatan saluran komunikasi, tautan kritis (misalnya, menghubungkan ke penyedia). Mereka memungkinkan Anda untuk secara proaktif melihat potensi masalah degradasi layanan karena kehilangan lalu lintas dan, karenanya, menghindarinya.
- Grafik berbasis NetFlow. Mereka membuatnya mudah untuk menemukan anomali lalu lintas dan sangat berguna untuk mendeteksi beberapa jenis serangan hacker yang sederhana namun signifikan.
Penting! Atur notifikasi sms untuk acara paling kritis. Ini berlaku untuk pemantauan dan penebangan. Jika Anda tidak memiliki giliran tugas, maka sms juga harus masuk setelah jam.Pikirkan proses sedemikian rupa agar tidak membangunkan semua insinyur. Kami memiliki seorang insinyur yang bertugas untuk ini.
Ubah kontrol
Menurut pendapat saya, tidak perlu mengontrol semua perubahan. Tetapi, bagaimanapun juga, Anda harus, jika perlu, dapat dengan mudah menemukan siapa dan mengapa melakukan perubahan itu atau lainnya dalam jaringan.
Beberapa tips:
- menggunakan sistem tiket untuk deskripsi terperinci tentang apa yang telah dilakukan sebagai bagian dari tiket ini, misalnya, menyalin konfigurasi yang diterapkan ke tiket
- Gunakan kemampuan komentar pada perangkat keras jaringan (mis. Komit komentar pada Juniper). Anda dapat mencatat nomor tiket
- gunakan diff cadangan konfigurasi Anda
Anda dapat memasukkan ini sebagai proses dengan melihat semua tiket setiap hari untuk perubahan.
Prosesnya
Anda harus memformalkan dan menjelaskan proses dalam tim Anda. Jika Anda telah mencapai titik ini, maka setidaknya proses berikut ini seharusnya sudah bekerja di tim Anda:
Proses harian:
- bekerja dengan tiket
- bekerja dengan log
- ubah kontrol
- lembar cek harian
Proses tahunan:
- perpanjangan jaminan, lisensi
Proses asinkron:
- Menanggapi berbagai keadaan darurat
Kesimpulan bagian pertama
Anda perhatikan bahwa semua ini bukan tentang konfigurasi jaringan, desain, protokol jaringan, perutean, atau keamanan ... Ini adalah sesuatu di sekitar. Tapi ini, meskipun mungkin membosankan, tetapi, tentu saja, elemen yang sangat penting dari unit jaringan.
Sejauh ini, seperti yang Anda lihat, Anda belum meningkatkan apa pun di jaringan Anda. Jika ada kerentanan keamanan, maka mereka tetap, jika ada desain yang buruk, maka itu tetap ada. Sampai Anda menerapkan keterampilan dan pengetahuan Anda tentang insinyur jaringan, yang kemungkinan besar menghabiskan banyak waktu, tenaga, dan kadang-kadang uang. Tetapi pertama-tama Anda perlu membuat (atau memperkuat) fondasi, dan kemudian lakukan konstruksi.
Bagian berikut ini tentang cara mencari dan memperbaiki kesalahan, dan kemudian meningkatkan infrastruktur Anda.
Tentu saja, tidak perlu melakukan semuanya secara berurutan. Waktu bisa kritis. Lakukan secara paralel jika sumber daya memungkinkan.
Dan tambahan penting. Berkomunikasi, bertanya, berkonsultasi dengan tim Anda. Pada akhirnya, terserah mereka untuk mendukung dan melakukan semua ini.