Keluhan yang sampai ke tim IT biasanya singkat: servernya lemah. Itu bisa benar. Yang lebih sering terjadi, basis data mengerjakan pekerjaan berulang tanpa indeks yang pas, atau satu laporan menarik seluruh tabel padahal yang dibutuhkan hanya satu periode.
Kami mulai dari pertanyaan yang bisa dijawab tanpa membeli apa pun. Kapan lambatnya muncul, laporan mana yang memicunya, dan apakah aplikasi lain ikut melambat pada jam yang sama.
Kalau hanya satu laporan yang berat, menambah memori server tidak mengubah cara laporan itu membaca data. Yang diubah adalah kuerinya. Filter tanggal dipasang di tempat yang tepat, indeks ditambah pada kolom yang benar-benar dipakai, dan laporan besar dipecah supaya tidak mengunci tabel yang dipakai kasir atau petugas input.
Kalau seluruh aplikasi melambat bersamaan, barulah kapasitas server masuk daftar. Keputusan itu diambil setelah bebannya kelihatan, bukan karena kalimat “sudah waktunya upgrade”.
Tim keuangan tahu laporan mana yang aman dijalankan siang hari dan mana yang dijadwalkan malam. Tim IT punya catatan kueri yang berat, jadi bulan depan tidak mulai dari nol. Aplikasi harian tidak lagi antre di belakang satu laporan tutup buku.
Selama satu siklus tutup buku, catat tiga hal: jam laporan dijalankan, berapa lama selesai, dan apakah pengguna lain mengeluh di jam yang sama. Kalau polanya berulang, masalahnya ada di cara data dibaca.
Kalau yang macet bukan laporannya melainkan mesin yang menampung semuanya, lihat satu server untuk seluruh operasi. Untuk mendiskusikan laporan yang molor di tempat Anda, jadwalkan konsultasi.
]]>Ini bukan cerita soal penyerang yang canggih. Ini soal pintu yang tidak dikunci setelah penghuninya pergi.
Kami susun daftar sistem yang benar-benar dipakai: email, aplikasi internal, VPN (jaringan pribadi untuk masuk dari luar kantor), basis data, dan panel perangkat jaringan. Banyak yang terlewat karena tidak ada di daftar resmi. Sistem itu hanya diingat oleh tim yang memasangnya.
Untuk setiap sistem, kami catat siapa yang berhak meminta pencabutan akses, dan berapa lama setelah hari terakhir karyawan itu harus selesai. Akun bersama — satu login yang dipakai banyak orang — dipisahkan. Akun semacam itu tidak bisa dicabut tanpa mematikan pekerjaan orang lain.
Kata sandi yang menempel di dokumen bersama diganti. Bukan karena dokumennya pasti tersebar, tetapi karena tidak ada cara mengetahui siapa saja yang pernah menyalinnya.
HR dan IT memakai urutan yang sama: hari terakhir, daftar sistem, siapa yang menandai selesai. Akun yang tidak terpakai beberapa bulan ditinjau, bukan dibiarkan karena “nanti mungkin dibutuhkan”.
Pilih satu karyawan yang keluar dalam enam bulan terakhir. Minta tim IT menunjukkan bahwa akun email dan aplikasinya sudah ditutup. Kalau tidak ada yang bisa memastikan dalam satu hari, daftar Anda belum cukup untuk diandalkan.
Skenario yang sering menyusul ada di sistem internal terbuka dari internet. Untuk merapikan akses di perusahaan Anda, jadwalkan diskusi.
]]>Kami pisahkan dulu mana yang harus hidup dalam hitungan jam, dan mana yang boleh menunggu sehari. Tidak semua perlu server baru. Berkas bersama kadang cukup dipindah ke penyimpanan terpisah. Aplikasi yang jarang dipakai tidak perlu ikut dalam rencana yang sama dengan kasir.
Baru setelah itu spesifikasi ditulis: berapa pengguna pada jam sibuk, berapa besar data, dan suku cadang apa yang harus ada di rak, bukan dipesan setelah rusak. Pengadaan mengikuti daftar itu, bukan katalog yang sedang promo.
Satu salinan layanan penting di mesin kedua, atau setidaknya langkah menaikkan cadangan ke perangkat cadangan, ditulis supaya orang yang piket tidak bergantung pada satu teknisi.
Kerusakan disk tidak lagi berarti seluruh kantor berhenti tanpa urutan. Ada daftar apa yang dinaikkan lebih dulu. Anggaran penggantian server punya alasan: beban dan umur perangkat, bukan kalimat yang hanya bilang sudah waktunya ganti.
Berapa mesin yang benar-benar menjalankan pekerjaan, dan apa yang ikut mati kalau mesin itu dicabut? Kalau jawabannya “semua”, prioritasnya jelas: pisahkan yang kritis, baru bicara kapasitas.
Kalau ruangannya juga panas dan tidak ada yang diberi tahu, baca ruang server kantor yang tidak terpantau. Untuk menyusun spesifikasi sebelum membeli, lihat pengadaan perangkat atau kirim kondisi Anda.
]]>Kami gambar dulu apa yang ada. Switch mana terhubung ke switch mana, akses nirkabel mana melayani ruangan mana, dan perangkat mana yang seharusnya memakai kabel. Gambar ini sering tidak ada, jadi setiap gangguan diulang dari awal.
Perangkat yang memang butuh kabel — kasir, printer bersama, PC yang menjalankan aplikasi berat — dipindah dari nirkabel. Akses nirkabel dibagi menurut ruangan, bukan satu nama jaringan untuk seluruh gedung dengan satu titik yang menanggung semuanya.
Switch yang portnya habis dan sudah tidak bisa dikelola diganti sesuai jumlah titik yang terpakai, plus cadangan yang wajar. Bukan diganti dengan model tertinggi di brosur.
Gangguan berikutnya punya tempat: ruangan dan perangkat, bukan satu kalimat “internet lemot”. Tim IT bisa melihat titik mana yang penuh sebelum pengguna pindah ke hotspot. Gambar jaringan disimpan, jadi orang baru tidak mengandalkan ingatan pendahulunya.
Hitung berapa orang di satu ruangan yang memakai nirkabel untuk pekerjaan utama, dan apakah PC kasir atau resepsionis ikut di situ. Kalau ya, jalur kabel untuk mereka biasanya lebih masuk akal daripada menambah bandwidth yang lalu tetap berebut di satu titik nirkabel.
Kalau kantor Anda justru akan pindah, baca menata ulang jaringan saat kantor pindah. Untuk pengadaan perangkat jaringan, lihat layanan pengadaan atau kirim kondisi Anda.
]]>Cadangan yang tidak pernah dibuka hanya membuktikan bahwa penyalinan berjalan. Ia tidak membuktikan bahwa salinannya bisa dipakai.
Kami minta satu salinan dibuka di mesin terpisah, bukan di server produksi. Yang dicek sederhana. Apakah berkasnya utuh, apakah basis datanya mau naik, dan apakah satu transaksi yang diketahui kemarin ada di dalam salinan itu.
Lalu kami tulis tiga hal yang biasanya tidak tertulis. Kapan cadangan terakhir berhasil, berapa lama pemulihan percobaan memakan waktu, dan siapa yang boleh menjalankannya kalau orang yang biasa mengerjakan sedang tidak masuk.
Kalau salinan gagal dibuka, jadwalnya diperbaiki dulu. Menambah salinan kedua tidak berguna bila salinan pertama tidak bisa dibaca.
Ada satu prosedur singkat yang bisa diikuti orang lain, bukan hanya satu teknisi. Percobaan pemulihan dijadwalkan, misalnya setiap kuartal, dengan tanggal dan hasil yang dicatat. Tim tahu data mana yang mungkin tidak ada: yang masuk setelah cadangan terakhir, bukan “semua data sejak awal”.
Kapan terakhir cadangan benar-benar dibuka? Siapa yang mencoba? Kalau jawabannya “belum pernah” atau “yang tahu hanya satu orang”, cadangan Anda belum selesai.
Kalau keluhannya soal laporan yang molor, bukan soal data hilang, baca basis data lambat saat tutup buku. Untuk bantuan menjaga cadangan dan pemulihannya, hubungi kami.
]]>Beberapa bulan kemudian pintu itu tetap terbuka. Niat awalnya bukan untuk membahayakan perusahaan. Risikonya muncul karena internet bisa menemukan pintu yang tidak dijaga.
Kami catat layanan yang menjawab dari luar kantor. Pertanyaannya praktis: pintu jaringan mana yang sengaja dibuka, untuk siapa, dan kapan terakhir dipakai.
Yang masih dibutuhkan dipindahkan ke jalur yang ada penggunanya. VPN atau akses per akun, bukan satu kata sandi yang dibagi di grup chat. Yang tidak dipakai ditutup. Catatan perubahannya disimpan, supaya bulan depan ada yang ingat mengapa pintu itu ditutup.
Pembaruan sistem yang tertunda ikut dilihat. Pintu yang sudah ditutup tidak banyak gunanya bila perangkat di dalamnya masih memakai versi yang sudah lama diketahui bermasalah.
Daftar layanan yang menghadap internet menjadi pendek dan ada pemiliknya. Vendor baru tidak lagi menerima password admin di pesan singkat tanpa akun sendiri. Tim IT bisa menjawab, dalam satu halaman, apa saja yang boleh dijangkau dari luar kantor.
Minta daftar layanan yang bisa dibuka tanpa berada di jaringan kantor. Kalau daftarnya tidak ada, itu sendiri jawabannya. Mulai dari remote desktop, panel basis data, dan aplikasi yang dipasang “sementara” tahun lalu.
Bacaan yang terkait: akun masih aktif setelah karyawan keluar. Kalau yang ingin Anda rapikan adalah batas akses ini, ceritakan kondisinya lewat formulir.
]]>Kami pasang pemantauan yang mengirim kabar saat suhu naik atau listrik pindah ke UPS (cadangan listrik singkat saat aliran utama padam), sebelum mesin mati. Ambangnya ditulis: suhu berapa yang cukup untuk ditindak, bukan peringatan yang berbunyi setiap hari lalu diabaikan.
Lalu kami cek hal fisik yang lebih murah daripada server baru. Apakah pendingin punya jalur listrik yang tidak ikut mati saat stopkontak biasa padam. Apakah UPS masih menahan beban sampai genset menyala atau sampai tim datang. Apakah debu di filter sudah menghambat aliran udara.
Kalau UPS tidak lagi menahan beban sesuai yang tertulis di spesifikasinya, itu masuk daftar pengadaan. Alasannya bisa ditunjukkan ke bagian pembelian, bukan hanya “rasanya sudah lemah”.
Ada orang yang menerima peringatan, dan ada kesepakatan apa yang dikerjakan malam itu: matikan layanan yang tidak kritis, atau datang ke kantor. Kegagalan pendingin tidak lagi diketahui dari pengguna yang tidak bisa masuk.
Lihat UPS. Berapa lama ia menahan beban terakhir kali diuji, dan siapa yang menguji. Lihat pendingin ruang server. Apakah ada tanda di luar ruangan itu kalau mesinnya berhenti. Kalau keduanya tidak punya jawaban, pemantauan suhu lebih berguna daripada membeli server pengganti.
Soal mesin yang menampung semua aplikasi, baca satu server untuk seluruh operasi. Untuk pemantauan ruang server dan perangkat pendukungnya, hubungi kami.
]]>Sebelum membeli perangkat, kami hitung titik yang benar-benar dibutuhkan: meja kerja, printer, akses nirkabel per lantai, dan rak kecil. Titik cadangan ditambah di ruangan yang sering diubah susunannya, bukan di setiap sudut.
Perangkat lama dicek mana yang masih layak dibawa. Switch yang tidak bisa dikelola dan kabel yang sudah tidak cukup panjang untuk jalur baru tidak ikut pindah hanya karena sayang dibuang. Yang dibeli adalah kekurangan dari daftar, dengan suku cadang yang bisa didapat, bukan campuran merek yang tidak ada yang pernah mengelolanya.
Jadwalnya dipisah. Penarikan kabel selesai sebelum meja terisi. Pengujian satu PC per ruangan selesai sebelum hari pindah. Ada daftar alamat yang berubah, supaya aplikasi tidak dicari di tempat lama.
Hari pindah dipakai untuk memindahkan orang, bukan untuk menemukan bahwa lantai dua tidak punya jalur ke rak. Ada satu gambar titik dan satu orang yang memegangnya. Perangkat yang tidak dibawa tidak ikut menjadi teka-teki di gudang gedung baru.
Denah kasar, jumlah orang per lantai, dan daftar apa yang harus hidup pada hari pertama: aplikasi, printer, telepon. Tanpa itu, penawaran perangkat hanya tebakan. Dengan itu, spesifikasi dari vendor bisa dibandingkan dengan dasar yang sama.
Jaringan yang sudah berjalan tetapi tidak stabil ada di jaringan kantor putus di jam sibuk. Untuk mulai dari denah Anda, jadwalkan konsultasi.
]]>