Fallacy #6: The admin will know what to do

Hal ini mungkin saja benar dimana network nya cukup kecil untuk ditangani oleh satu orang. Dimana orang tersebut juga orang yang membuat sekaligus melakukan maintenance terhadap system tersebut. Hal ini merupakan kondisi yang sangat ideal sampai orang tersebut pindah pekerjaan atau di promosikan atau tidak bekerja lagi. Jika itu terjadi maka kita akan mencari pengganti dan kemungkinan besar pengganti tersebut tidak akan mengetahui keseluruhan sistem dengan baik. Dimana letak log nya, configuration nya dan bagaimana melakukan tuning terhadap sistem tersebut.

Jadi kita harus bersiap-siap dengan kemungkinan bahwa orang yang akan melakukan monitoring dan maintenance terhadap sistem kita tidak mengetahui apa-apa tentang sistem tersebut. Sehingga kita dapat melakukan tindakan pencegahan yang tepat.

Kebanyakan kita developer juga tidak mengetahui semua konfigurasi yang ada. Karena jika kita memiliki keraguan semua akan kita letakkan di dalam konfigurasi sehingga keputusan tersebut dapat di tunda. Hal ini menyebabkan konfigurasi tersebut semakin lama semakin banyak dan sulit dipahami oleh satu orang. Dan pada satu saat kita akan menemukan sistem tersebut tidak bekerja dan menemukan bahwa kesalahan nya adalah orang salah melakukan konfigurasi.

Ini diperparah jika konfigurasi terdapat di beberapa tempat di database, environment variables dan juga config file. Jika hal ini terjadi maka banyak hal yang harus dengan cepat di trace dan kemungkinan untuk melakukan kesalahan sangat tinggi. Semakin banyak komponen yang ada di sistem semakin besar pula kesempatan untuk melakukan kesalahan. Hal ini juga terjadi di big data ataupun microservices architecture. Dimana kita memiliki config server dan banyak service yang saling loose coupling juga message queue.Developer juga mungkin tidak akan mengetahui bagaimana keseluruhan system bekerja.

Kita harus membuat investasi di awal untuk melakukan dokumentasi dan bagaimana melakukan backup dari state sistem yang baik dan dapat melakukan rollback. Hal ini seharusnya dapat dimengerti oleh administrator. Configuration management merupakan salah satu field yang sangat besar dan anda sebaiknya memahami mengenai hal tersebut. Ada juga standard mengenai hal tersebut ITIL salah satunya.

Banyak hal sudah di dokumentasikan dan banyak best practice mengenai hal ini. Pelajarilah hal tersebut dan jangan membuat standard baru.

High availability adalah salah satu hal yang kita harapkan admin dapat melakukannya. Contohnya jika kita melakukan upgrade dari software. Hal ini biasanya akan menyebabkan downtime pada sistem kita. Kebanyakan orang memiliki persepsi upgrade sama dengan down time. Hal ini membuat business user menjadi takut melakukan upgrade terhadap sistem.

Tetapi ini menyebabkan upgrade yang kecil menjadi terhalang dan hasilnya adalah upgrade yang besar. Hal ini lebih menakutkan lagi. Semakin banyak code yang di pending untuk di deploy, semakin banyak perubahaan dan semakin besar kemungkinan system tersebut berubah besar-besaran jika code yang baru di deploy.

Kita perlu berubah dari sudut padang tersebut ke continuous deployment. Sehingga deployment menjadi non event atau tidak merupakan suatu hal yang besar. Automation merupakan salah satu kunci dari keberhasilan ini. Juga kita harus membuat code yang kita deploy merupakan code yang backward compatible dengan versi sebelumnya. Jika kita ingin membuat system kita tidak memiliki downtime, maka kita akan perlu membuat perubahan di satu server dan membiarkan server lain memiliki versi sebelum. Jadi versi n dan n+1 dapat hidup berdampingan tanpa merubah behaviour dari sistem. Jika kita dapat melakukan ini maka system akan highly available.

Code yang backward compatible sulit untuk ditulis tetapi bukan tidak mungkin. Tetapi diperlukan kedisiplinan dan programming practice yang baik. Hal tersebut adalah hal yang wajib dilakukan jika kita ingin system kita selalu high available. Hal ini adalah merupakan bagian besar dari cerita DevOps dan continuous deployment. Jika anda tidak dapat melakukan backward compatiblity maka continuous deployment akan sama dengan continuous downtime.

Admin harus dapat mematikan bagian dari system tanpa membuat keseluruhan system down. Queue memberikan banyak kemudahan dalam hal ini karena kita dapat membuat system yang decouple satu sama lain. Dan kita tidak kehilangan command yang di push ke system. Salah satu part dari system dapat melakukan queueing message tanpa perlu memperhatikan bagian dari system lain hidup atau mati. Queue akan mempermudah tetapi bukan merupakan satu-satunya solusi.

Salah satu hal yang lain yang perlu dilakukan adalah melakukan logging untuk mengetahui masalah pada system. Tetapi logging yang terlalu banyak dapat membuat masalah juga. Kita akan sangat kesulitan untuk menemukan jarum dalam tumpukan jerami jika terlalu banyak. Tapi buatlah fokus lebih besar ke jarum nya bukan memperbanyak jerami.