Prinsip Dasar SysAdmin : Pahami, Hormati & Hargai SysAdmin Lain

Beberapa bulan yang lalu, antara bulan Maret s/d Mei 2011 saya diminta oleh seseorang yang punya nama besar dibidang teknologi informasi di Indonesia untuk membantu team konsultannya memberikan training for trainee sekaligus pendampingan teknis untuk project migrasi sistem di sebuah perusahaan besar di Indonesia. Kasarnya saya menjadi konsultan cabutan 😀 .

Proses training for trainee berjalan cukup lancar, bahkan saya bisa belajar banyak dari feedback para peserta yang memang memiliki kemampuan diatas rata-rata. Maklum, peserta training for trainee merupakan pilihan dan mereka nantinya diharapkan menjadi trainer bagi rekan-rekan yang lain.

Yang menjadi masalah adalah saat melakukan pendampingan migrasi sistem dari Microsoft Outlook menjadi Mozilla Thunderbird. Mail server yang digunakan adalah Microsoft Exchange dan tidak ada issue berarti pada koneksi antara Outlook dengan Exchange. Outlook bahkan tidak perlu menggunakan protokol POP3 untuk mengambil email karena bisa langsung menggunakan protokol MAPI untuk koneksi langsung dengan Exchange.

2 masalah utama yang terjadi yaitu masalah lookup address. Konfigurasi auto complete address book gagal dilakukan karena konfigurasi yang dilakukan tidak berhasil, padahal secara teori konfigurasinya sudah benar. Yang kedua adalah Mozilla Thunderbird tidak stabil saat berhubungan dengan Microsoft Exchange 2010 menggunakan protokol POP3 via SSL (POPS).

Untuk mengatasi hal ini, saya bicara dengan bahasa SysAdmin. Karena saya juga pernah menggunakan Microsoft Exchange, saya bicara dengan para Admin mail server mengenai keperluan yang saya inginkan. Awalnya mereka defensif, cenderung tidak mau disalahkan dan bilang, “Selama ini pakai Outlook tidak ada masalah kok, berarti tidak ada yang salah disetting server kami”.

Sebagai antisipasi kasus ini, saya secara persuasif berusaha bicara dalam posisi mereka, meyakinkan mereka bahwa saya tidak bermaksud mengatakan bahwa setting mereka yang salah. Apa yang saya perlukan adalah informasi konfigurasi server dan topologi yang mereka gunakan. Dengan cara ini akhirnya masalah auto complete address book bisa dilakukan dengan cara mengambilnya melalui account Active Directory yang ternyata diletakkan dalam server terpisah.

Masalah kedua lebih berat karena masalahnya tidak permanen. Mozilla Thunderbird yang digunakan untuk mengakses Microsoft Exchange bersifat aneh. Kadang selama beberapa hari tidak mengalami kendala, namun satu waktu terjadi masalah tidak bisa koneksi. Padahal tidak ada perubahan setting apa-apa. Saya bahkan melakukan screenshot dan membandingkannya satu persatu tanpa menemukan perbedaan konfigurasi antara Mozilla Thunderbird yang bisa mengakses dengan yang tidak. Ajaibnya, dengan konfigurasi yang sama, Mozilla Thunderbird yang tidak bisa akses akan kembali normal jika komputernya direstart.

Meski bisa dilakukan, restart komputer tentu bukan sebuah opsi yang menyenangkan. Kami dari team konsultan sempat kebingungan sampai-sampai ada ucapan dari klien, “Jangan-jangan Mozilla Thunderbird memang tidak bisa akrab dengan Microsoft Exchange” 🙂

Yang lebih mengherankan, masalah yang terjadi bersifat sporadis, intermittent. Tidak selalu terjadi dan berselang-seling. Kadang desktop si A, lain kali desktop si B. Ada desktop yang tidak pernah bermasalah, ada juga desktop yang sejak semula tidak bermasalah, padahal setting dan konfigurasinya sama persis.

Terus terang saya tidak percaya kalau untuk hal mendasar berupa koneksi ke mail server saja Mozilla Thunderbird tidak mampu. Berdasarkan hal itu, saya berdiskusi ulang dengan team Admin mail server pihak klien. Sikap kami tetap sama, yaitu menghormati mereka dan tidak berasumsi menyalahkan konfigurasi yang mereka lakukan. Kami hanya butuh informasi tambahan mengenai topologi yang mereka lakukan.

Titik terang mulai muncul saat Admin klien menyampaikan bahwa mereka menggunakan Load Balancing pada sistem Microsoft Exchange Server. Jadi ada 1 buah front-end dengan nama mail.domain.com dan 5 buah back-end. Semua klien akan melakukan koneksi ke mail.domain.com, nanti si front-end mail.domain.com yang akan melakukan load balancing ke salah satu server back-end.

Atas bantuan salah satu team pendamping, kami dapat memiliki IP-IP dan nama server yang menjadi back-end. Berdasarkan alamat IP tersebur, saya melakukan test koneksi satu persatu menggunakan perintah telnet. 4 dari 5 server memberikan respon yang identik, sama persis sedangkan satu server memberikan respon yang berbeda. Letak perbedaan ada pada respon TLS/SSL. 4 Server menyatakan dalam responnya kemampuan menerima akses SSL/TLS sedangkan satu server tidak menyatakannya.

Untuk lebih meyakinkan, kami melakukan konfigurasi testing di salah satu server yang digunakan untuk POC (Proof of Concept), dengan akses langsung melalui IP mail server backend, tidak menggunakan akses front-end mail.domain.com. Dari hasil testing diketahui bahwa memang masalah ada pada server backend yang dimaksud, yang tidak mampu menerima koneksi SSL/TLS.

Asumsi saya, kemungkinan besar masalah ini karena load balancing. Desktop yang mengalami masalah kemungkinan besar sedang diarahkan oleh front-end untuk menggunakan back-end yang bermasalah. Mengapa bersifat sporadis dan intermitten, karena merupakan hasil load balancing. Jika hasil load balancing mengarah pada 4 server yang OK, hasilnya akan bagus sedangkan sial akan menimpa jika kebetulan hasil load balancing mengarah pada server back-end yang bermasalah.

Berbekal hasil test dan screenshot, kami kembali diskusi dengan team Admin mail server pihak klien. Setelah kami berikan contoh-contoh hasil testing kami, barulah bisa ketahuan bahwa ternyata salah satu server back-end belum mengaktifkan koneksi SSL/TLS. Begitu koneksi TLS/SSL diaktifkan, Mozilla Thunderbird sukses melakukan koneksi dan stabil dipergunakan.

Pertanyaan susulannya, mengapa hal yang sama tidak terjadi pada klien berbasis Outlook padahal Outlook juga menggunakan front-end yang sama? Hal ini juga bisa dijelaskan karena Outlook tidak menggunakan protokol POP3 maupun IMAP melainkan terkoneksi langsung ke Exchange sehingga tidak terkena imbas masalah yang sama yang menimpa Mozilla Thunderbird.

Keberhasilan mengatasi masalah diatas tentu tidak terlepas dari bantuan Admin mail server pihak klien dan kesediaan mereka memberikan informasi. Hal ini sangat saya hargai karena saya bisa memahami dan menghargai keberadaan mereka. Fokus saya adalah menyelesaikan masalah, bukan mempermasalahkan mereka.

Jika kita menjadi admin server, apalagi yang berhubungan dengan pihak lain seperti mail server, kemungkinan timbulnya masalah antar admin sangat besar. Misalnya ada email yang semestinya sudah terkirim atau sudah diterima namun belum ada di server yang dimaksud. Masing-masing mempertahankan argumentasinya bahwa si mail server lain yang bermasalah. Apalagi jika boss sudah turun tangan, salah-salah antar admin timbul perselisihan mengenai siapa yang benar siapa yang salah.

Cara terbaik untuk menghindari itu semua adalah dengan cara memahami, menghormati dan menghargai SysAdmin lain. Meski kita yakin kita benar, sebaiknya cari cara agar bisa meyakinkan pihak lawan bahwa apa yang kita sampaikan sudah sesuai fakta.

Meski kita merasa sudah memiliki sekian banyak pengalaman dan sertifikasi professional, akan sangat bijaksana jika kita menempatkan diri kita satu level dengan admin yang lain. Lebih baik kita dianggap kurang paham daripada kita sok paham. Jika kita tidak ingin dipersalahkan, tentu admin lain juga tidak mau disalahkan oleh pihak lain.

Mengapa saya perlu menuliskan hal ini sampai sedemikian panjang, karena kerap kali saya menjumpai admin yang terkesan protektif dan defensif, apalagi jika sistem yang ia tangani ditengarai mengalami masalah. Biar bagaimana, SysAdmin juga manusia biasa, punya rasa dan punya hati, hehehe…