Skip to main content

Terminology Layanan IT

Copas from http://bambolz.wordpress.com

Terminologi-terminologi yang perlu difahami pada pembahasan ini adalah
  • Availability : Merupakan ketersediaan atau bagian waktu dimana sebuah aplikasi atau layanan tersedia kepada kostumer internal atau eksternal. (Guarddin, 2012)
  • Reliability : seberapa tahan sih?!?! peluang si komponen nggak rusak selama jangka waktu tertentu.
  • Resiliency : is the ability to overcome challenges of all kinds–trauma, tragedy, personal crises, plain ‘ole’ life problems–and bounce back stronger, wiser, and more personally powerful. (Henderson, 2012) #intinyah kemampuan untuk kembali menjadi benar, berfungsi setelah mengalami kerusakan atau kegagalan
  • Serviceability : mirip availability cuman ini khusus or fokus ke service aja
  • Fault-tolerant system : sistem yang mampu tetap bekerja meskipen terdapat parameter-parameter yang rtidak memenuhi kriteria. In essence, they have to be able to keep working to a level of satisfaction in the presence of faults.
  • High-availability (HA) Clusters : are groups of computers that support server applications that can be reliably utilized with a minimum of down-time. They operate by harnessing redundant computers in groups or clusters that provide continued service when system components fail (wikipedia, 2013) #intinyah jadi sistemnya dibikin cluster redundant biar kalo yang satu down atau busy bisa dialihin ke yg lain.
  • High-performance Clusters (HPC) : kalo cluster yang ini pemrosesanya bisa pararel gan jadinya lebih cepet wuuuz wuuuz
  • Disaster Recovery : kalo ini sih proses buat ngebangun kembali data center atau server-server yang down or fasilitas yang rusak dikarenakan bencana.
Sumber-sumber yang bikin downtime (Planned)
  • Backup
  • penggantian atau upgrade hardware
  • maintenance or upgrade application
  • Rekonfigurasi server
  • Update or Upgrade OS
  • Install Patch
Sumber-sumber yang bikin downtime (Unplanned)
  • extended planned downtime (dari yg planned itu ternyata makan waktu lebih lama)
  • Human Error
  • Application Failure
  • OS Failure
  • Hardware Failure
  • Incompability
Availabilty juga punya Level gan
Level 1: Bergantung pada Hardware Reliability
Level 2: Data Protection
Level 3: Fault Tolerant Servers
Level 4: Server Redundancy or Clustering
Level 5: Disaster Recovery gan


Availabilty-SLA
Dihitung per satuan waktu: (bulan, tahun, menit, hari, dll)
Uptime 98%
Downtime 2%

So Downtime Setahun = 2% x 365 = 7.3 Hari
Trus Downtime Perbulan = 2% x (24×30) Jam = 7 Jam 18 Menit

menjadi parameter pada SLA (Service Level Agreement

Reliability – MTBF:mirip availabilty cuman fokus ke Perhitungan untuk tidak rusak
expressed as MTBF Mean Time Before Failure

jadi bisa digunain selama xxx jam sebelum akhirnya bakalan rusak xD

Resiliency – Fault Tolerant
kemampuan untuk tetap berfungsi meskipun terjadi beberapa kesalahan
ex: RAID 1/4/5/60/50/15, Redundant power supply

Serviceability x MTTR
Probabilitas sebuah layanan u/  berfungsi kembali dalam waktu tertentu
ex: 0,26 dlm 3 jam
Berarti dalam waktu 3 jam kemungkinan layanannya bisa berfungsi kembali adalah 26%

Sering juga disebut mean time to repair
MTTR = 0 berarti serviceabilitynya 1 untuk waktu 0 jam
Okeh Sekarang kite main rumus
Availability = MTBF/(MTBF + MTTR)
Availability = Uptime/(Uptime + Downtime)
Kesimpulanya
Downtime atau MTTR mendekati 0 berarti  Availability ~ 100%
Jika Uptime atau MTBF sangat tinggi, efek dari Downtime atau MTTR menjadi tidak signifikan

Popular posts from this blog

Freenas Snapshots Replication Backup

Mungkin anda sudah mengetahui Freenas sebelumnya. Ya..Freenas adalah salah satu software NAS Storage berbasis FreeBSD. Karena kehandalannya, Freenas banyak digunakan sebagai NAS Storage di dunia IT. Saya pernah berfikir bagaimana jika Freenas yang kita gunakan mengalami masalah, crash misalnya. Mungkin jika hardisknya menggunakan RAID bisa tinggal ganti disknya. Bagaimana jika tidak ada RAID (hari gini Server gak ada Raid hdewww heee) atau hal lain yang membuat data tidak bisa digunakan di Freenas. Tutorial ini saya buat untuk berbagi ilmu kepada rekan2 sekalian. Saya akan coba membuat Replikasi Freenas. Dimana Dataset pada salah satu Freenas (Freenas A) akan di snapshot dan di replikasikan ke Freenas B Hal yang perlu disiapkan : 1.  Freenas A : 192.168.100.1 (Primary) Disk 8GB x 2 2.  Freenas B : 192.168.100.2 (Secondary) Disk 8GB x 2 SETING FREENAS A DAN B Kita akan buat raid mirror untuk 2 disk. Storage - Volume Manager   Volume Name :

Migrasi Nextcloud 19 ke Nextcloud 20.02 (Beda Server)

Server A : 192.168.0.1 (Server lama : Centos 7), port 80 Server B : 192.168.0.2 (Server baru : Centos 8), port 80 Nginx Load Balance : 192.168.0.10, port 443 untuk SSL Tahapan : 1. Upgrade Nextcloud 19.0.3 ke 19.0.5 (server lama) 2. Instalasi server baru (Centos 8) 3. Backup dan restore data nextcloud dan databas ke server baru 4. Konfigurasi Nextcloud di server baru dan Nginx Server 5. Finish A. Upgrade Nextcloud 19.0.3 ke 19.0.5 Untuk Upgrade 19.0.3 ke 20.0.2 tidak dapat dijalankan secara langsung. Harus bertahap upgrade ke versi minor. 19.0.3 -> 19.0.5 secara otomais. Dan upgrade ke 20.0.2 secara manual. 1. Login ke Nextcloud 2. Setting - Administration-Overview 3. Versi yang tersedia 19.0.5 5. Pilih Open updater  4. Start Update 5.  Pilih No (for usage of the web based updater), untuk mode maintenance dan upgrade via console. 6. Masuk ke console dan ke directory /var/www/html/nextcloud 7. Jalankan $ sudo   - u  apache   php occ upgrade 8. Maintenance mode masih dalam keadaan

Zimbra Error Subject : ***UNCHECKED***

Beberapa hari yang lalu Subject email Zimbra selalu di tambahkan tulisan ***UNCHECKED***. Padahal tidak ada perubahan konfigurasi mail server sebelumnya. Cari di google ada beberapa referensi yaitu merubah file /opt/zimbra/. Tahapan : #su root #cd /opt/zimbra/amavisd/bin #cp -pa amavisd amavid.org #vi amavisd Rubah isi file di baris : #su zimbra $undecipherable_subject_tag = '***UNCHECKED*** '; menjadi $undecipherable_subject_tag = '';   $zmamavisdctl restart Di hari berikutnya saya coba cek kembali utilisasi mail dengan 'top'. Terilhat penggunaan clamd sebesar 100%. Coba dicek di log /var/log/zimbra.log |grep clamd hasilnya mail amavis[26778]: (26778-07) ClamAV-clamd: All attempts (1) failed connecting to /opt/zimbra/data/clamav/clamav.sock, retrying (1) Oct 24 10:10:43 mail amavis[26778]: (26778-07) (!)connect to /opt/zimbra/data/clamav/clamav.sock failed, attempt #1: Can't connect to UNIX socket /opt/zimbra/data/clamav/clamav.sock: Co