Oleh: agung | Mei 17, 2009

Berbayar atau Gretong Dalam System Management

Berbayar atau Gretong alias Gratis adalah pilihan (Khusus di System Management, baik Network, System dan Aplikasi). Setiap Admin mempunyai argumen masing-masing. Saya masih percaya berbayar itu masih perlu, karena ada nilai di dalam harga itu.

 

“THEY PUT VALUE IN IT….”

 

Bukan berarti yang gratis ngga ada ‘Value’-nya, tapi sekali lagi, itu adalah pilihan. Didalam Network dan System Management, apalagi di dalam perusahaan yang mempunyai infrastruktur besar atau sangat besar ( bukan berarti perusahaannya besar juga, lho… ), unsur Kecepatan, Ketepatan dan Produktifitas, karena ada Kemudahan, adalah nomor 1. Harga no.2, hhmm… mungkin no.3 kalo komisi project diperhitungkan🙂

Mungkin rekan-rekan lebih banyak berkutat di sisi Teknis saja, namun bagi Management yang punya uang, mereka ingin mendapatkan Value dari setiap Rupiah yang dikeluarkan. Makanya sekarang sedang bergeser paradigma ke-arah melihat ROI(=Return on Investment) sebagai acuan bersama dimana KPI(=Key Performance Indikator) atau SLA(=Service Level Agreement) menjadi pilihan Bahasa Percakapan IT dan Management.

Beberapa Bank besar kita yang sedang dipersimpangan jalan untuk mengganti atau menyesuaikan Sistem menurut BASEL II Accord, masih sedang dalam kesulitan mencari justifikasi apa yang diperlukan untuk mensukseskan proses transisi ini.

Model transisinya bagaimana? 

Meniru saja Model yang ada, tapi Mahal…., atau, Re-Engineering sendiri prosesnya, murah tapi ber-resiko.. .??

Seperti misalnya..;

Ada yang tau ngga, bila management tanya…;

1.     Lebih menguntungkan pake Cisco atau Juniper?

2.     Lebih produktif pake Windows atau Linux?

3.     Di Data Center lebih bagus 1GB pake Cooper atau Fiber?

4.     Lalu…, tetap pake Mainframe atau Downsizing saja? dan lain-lainnya. …., Atau yang lebih extreem…,

5.     Tetap pake DRC (=Disaster Recovery Center) atau tidak?

 

Sudah banyak teknology yang memungkinkan tidak perlu tempat khusus yang persis sama dengan System yang ada, untuk DRC. Cisco dan beberapa vendor lainnya (IBM, HP, SUN, EMC, dan merk-merk baru lainnya..), sedang gencar-gencar- nya memperkenalkan konsep Virtualisasi ini.

Dengan demikian, membuat DRC ngga perlu mengeluarkan biaya sebanyak Sistem yang pertama ada (yang sudah ada). Bank ngga suka belanja DRC model lama, tapi tetap mau punya…🙂

                Dari pengalaman Saya berbicara dengan beberapa Manajemen IT dan beberapa sumber di Bank-Bank besar kita yang umumnya sangat aktif pada system yang baru dan kompleks, mereka masih lebih banyak mempersoalkan Terjemahan Surat Edaran BI mengenai RISK MANAGEMENT (MANAJEMEN RISIKO), PBI No.5/8/PBI/2003 tanggal 19 Mei 2003.

                Kalau dalam Basel Accord sebelumnya terjemahan yang dipentingkan adalah Compliances (SARBOX, ITIL, ISO-9000-an, ISO-14000, BS-7779, dan Standard-xxxx lainnya… ), didalam Basel II Accord yang juga sudah diterjemahkan oleh Bank Indonesia (BI) dengan surat edaran-nya, lebih mengutamakan RISK MANAGEMENT. Termasuk RISK MANAGEMENT di IT. Jadi bukan Risk dari LOAN (Pinjaman) saja…, tapi sudah masuk ke aras OPERATIONAL RISK.

                Kalau Saya boleh umpamakan, IT ada di barisan SUPPORT dan Management di barisan Business Inti-nya (CORE).

Dalam Hierarki itu, IT ada dibawah struktur, yang men-support Core-nya. Dari hierarki itu, sampai hari ini jarang yang bisa berbicara dengan bahasa yang sama. Orang IT bicara Teknis, Manajemen bicara uang dan produktifitas.

 

Contoh;

                Orang IT bilang, kita harus pake Bandwidth 512KBps menggantikan Bandwidth yang ada sekarang, 128KBps.

Manajemen tanya…, mengapa harus 512KBps? Mengapa tidak 256KBps…?

                Bagi Manajemen, berasumsi, peningkatan Bandwidth 2x saja dari Kapasitas yang ada, harapannya Produktifitas dan Revenue Generation dari Link itu seharusnya, paling tidak 2 kali juga. (Kecuali bersepakat buat nutupin kesalahan Sizing Link Network….)

Ngga salah kan…, Manajemen berpikir begitu..??

Nah…, apa justifikasi orang IT untuk memilih antara 256KBps atau 512KBps…?

Apa kita mau pake gaya… “POKOKNYA… harus gini, POKOKNYA harus segitu…!!”

 

Contoh aktual lagi:

                Bank Sentral kita, Bank Indonesia (BI) si pembuat Edaran, masih terlihat berkutat terlalu teknis dalam operasionalnya.

                Belum terlihat bagaimana mereka meng-aktual- kan Basel II Accord itu dalam IT-nya (Mungkin ngga perlu untuk mereka… justru yang perlu itu di Bank binaannya… )

 

Misalkan saja soal RTGS (=Real Time Gross Settlement) dulu. Pernah RTGS itu tidak seperti janjinya (dulu…), tidak Real Time. Bahkan perlu waktu beberapa jam agar dana aktif di-rekening tujuan.

(Ini khan tidak lucu…!!)

Setelah berjalan beberapa tahun masih sama dan namanya belum diganti-ganti juga, masih “REAL TIME” Gross Settlement.

                Bahkan ada Bank yang nulis pengumuman di Counter Teller berbunyi..,” Dana melalui Fasilitas RTGS akan aktif 2 jam setelah Anda meninggalkan Counter”.

 

Ini kan tidak lucu…. Seolah-olah Nasabah kita tidak mengerti istilah Bahasa Inggris, “Real Time..”

Atau “REAL TIME” itu sebuah NAMA saja.

 

Kasus seperti itu terjadi, biasanya karena tidak punya cara mengontrol baik teknisnya maupun kualitas.

Seperti ungkapan yang saya kutip ini;

You can not IMPROVE what you can not SEE!

You can not CONTROL what you can not MEASURE!

You can not OPTIMIZE what you can not CONTROL!

Kalau kita tidak punya data…, bagaimana mungkin ada justifikasi ??

Karena tidak ada Justifikasi yang jitu…, siap-siap saja pengajuan anggaran ditolak terus…, dipotong terus…

Kalaupun disetujui… , lebih karena terpaksa, supaya rekan-rekan di IT ngga pindah kerja ketempat lain…

BENEEERRRR ITU…!!!! Para Bos-bos banyak ngakunya begitu….!!

Jadi jangan cepat Gee…Errr.. ., kalau ajuan budget-nya disetujui…🙂

Belum tentu karena kita hebat…

 

::Kembali ke soal Berbayar dan Gratis::

                Karena antara IT dan Manajemen perlu ada Bahasa yang sama–KPI dan SLA. Kita harus punya cara agar sama-sama bisa memantau KPI dan SLA itu. Dan akhirnya kita bisa menghitung ROI…, bersama-sama pula. (Jadi…, kita bisa ikut klaim besaran Pembagian Bonus Perusahaan.. ., ngga hanya nunggu gaji saja…. Logis, kan…??🙂

Pembuat Aplikasi yang Berbayar biasanya sudah meng-investasikan cukup banyak waktu, biaya dan pemikiran untuk memberikan solusi kepada Customer-nya agar mampu melakukan integrasi dengan tugas-tugas Manajemen dalam membuat keputusan-keputusan , seperti sekarang yang sedang marak dengan istilah “Business Service Management”.

Seperti juga sudah Saya sebutkan diatas “They Put Value in It”.

Atau lebih spesific, “They Put Value in IT (Information Technology)

                Untuk beberapa aplikasi Gratis yang Saya baru lihat terdapat kelebihan kepada Penanganan Sub-Struktur dan umumnya sangat terlokalisasi dan umumnya juga belum terintegrasi dengan Sistem Pelaporan dan Tracking/Logging yang gencar-gencarnya dipersyaratkan.

                Kalaupun sudah ada biasanya hanya menyediakan Raw Data atau Gateway-nya saja, harus di format ulang untuk penyajian kepada Auditor dan Manajemen, yang otomatis tidak bisa cepat. Wong.. buatnya di MS-EXCEL…

                Apalagi untuk Ad-Hoc Reporting (Tiba-tiba si-Manager lagi heng…, kesal sama atasannya… , mungkin cutinya ditolak, minta kita sedia-in laporan dadakan. HARI INI JUGA…!!!! ). Atau si Pak Direktur Marketing pusing, karena di-complaint terus sama Customer. Padahal dari sisi Kita, System biasa-biasa saja beroperasi.

                Tapi untuk bilangin bahwa “Permasalahan bukan di kita, Paaaakk…..”, susah…, karena kita ngga ada data.

Pusing ngga…!!??

                Nah disini…, pakai yang ‘Gretong” adalah cara yang BAGUS untuk BELAJAR…., tapi TIDAK BAGUS ditempat BEKERJA… Kecuali tempat Anda bekerja, Anda dibayar untuk lebih banyak BELAJAR…., daripada banyak BEKERJA….🙂

(Ssstt…, supaya bisa lulus CCNP atau CCIE Written dan cari tempat kerja yang gajinya lebih besar di Dubai…)

 

Salah satu contoh kasus dengan RRD Tools Cacti atau sejenisnya.. .;

— Cacti atau sejenis dari NOC memantau Server 1,2,3 dan 4 melalui Router A yang terkoneksi ke Core Switch B. Swicth B ke Aggregate Switch C. Switch C terkoneksi ke 4 Application Server.

 

<<NOC>>—<< ROUTER A>>—-<<CORE SWITCH B>>—-<<AGGREGATE SWITCH C>>—-<<SERVER 1, 2, 3 dan 4>>

 

                Kalau ROUTER A mengalami HANG setelah High CPU Utilization dan High Memory Utilization beberapa jam setelah Re-Konfigurasi terakhir oleh salah satu Engineer… sehingga tidak ada traffic dari/ke Core Switch, Aggregate dan Server-Server, alias terputus;

1.        ALARM apa yang Anda harapkan muncul di NOC? Apakah Server(-Server) bermasalah, atau Masalah di Switch-switch ?

2.        Berapa langkah dan Berapa lama untuk masing-masing langkah Anda lakukan, sampai kepada kesimpulan ROUTER A bermasalah?

3.        Berapa lama Anda baru tahu bahwa masalah sebenarnya adalah “Router Configuration CHANGED” ? Bukan “Kurang Memory”..!!

4.        Ketahuan ngga siapa yang merubah Konfigurasi dan atas alasan apa serta persetujuan siapa?

5.        Bagaimana Anda menghitung SLA per-node, SLA per-device, SLA per-Interface, SLA per-Service* *, dan SLA Gabungan dari keseluruhan System?

6.        Bagaimana Trend perilaku dari setiap Element tersebut sepanjang link itu…? Apakah ada polanya terhadap waktu? Karena setiap setelah di Re-Start bbrp jam kejadian lagi…., lagi… dan lagi…

(Emang kerjaan kita buat lihatin Router itu saja…!! Ada 50-an, 200-an, 1000-an Router lagi di cabang, Men..?!)

**SLA per-Service yang merupakan Gabungan dari beberapa infrastruktur yang membentuk Layanan IT di Perusahaan Anda.

 

Misalnya yang dipantau SLA LAYANAN MAIL SYSTEM, merupakan gabungan dari ;

 [AVAILABILITY Inteface]; +

[RESPON TIME DNS Service (bisa dari Server berbeda)]; +

[Max. TOTAL Mail in Queue]; +

[AVAILABILITY dari MTA (Message Transport Agent) Mail Server];+

[CPU Utilization dgn max tresshold 75% ];+

[Memory Utilization] ;+

[SWAP MEMORY Size];+

[DISK SPACE UTILIZATION] ;+ de..el..el..

 

Umumnya yang Gretong perlu KERJA EXTRA KERAS untuk dapat melakukan itu dan BIASA-nya kita langsung VONIS “TIDAK BAGUS” begitu dapat 3x, 4x, 5x sandungan, dan pindah cari Gretong-an yang lain…. Jadi menurut Saya…, relatif lah… mau lihat Gretong alias Gratisan atau Berbayar…. WE SHOULD SEE VALUE IN IT…

::Re-Phrase. ..

INOVASI pada PRODUK hanya memberikan Anda 3 bulan Penyelesaian Masalah…., Tapi,

INOVASI pada PROSES memberikan Anda Setahun lebih Ketenangan Bekerja….. , dan bisa ambil Cuti Liburan.

 

Berbayar atau Gretong alias Gratis adalah pilihan (Khusus di System Management, baik Network, System dan Aplikasi).
Setiap Admin mempunyai argumen masing-masing.
Saya masih percaya berbayar itu masih perlu, karena ada nilai di dalam harga itu.
“THEY PUT VALUE IN IT….”
Bukan berarti yang gratis ngga ada ‘Value’-nya. .., tapi sekali lagi, itu adalah pilihan.
Didalam Network dan System Management, apalagi didalam perusahaan yang mempunyai infrastruktur besar atau sangat besar ( Bukan berarti perusahaannya besar juga, lho… ), unsur Kecepatan, Ketepatan dan Produktifitas- -karena ada Kemudahan, adalah nomor 1. Harga no.2, hhmm… mungkin no.3 kalo komisi project diperhitungkan🙂 :p .
Mungkin rekan-rekan di milis ini lebih banyak berkutat di sisi Teknis saja, namun bagi Management– yang punya uang, mereka ingin mendapatkan Value dari setiap Rupiah yang dikeluarkan. Makanya sekarang sedang bergeser paradigma ke-arah melihat ROI (=Return on Investment) sebagai acuan bersama dimana KPI(=Key Performance Indikator) atau SLA (=Service Level Agreement) menjadi pilihan Bahasa Percakapan IT dan Management.
Beberapa Bank besar kita yang sedang dipersimpangan jalan untuk mengganti atau menyesuaikan Sistem menurut BASEL II Accord, masih sedang dalam kesulitan mencari justifikasi apa yang diperlukan untuk mensukseskan proses transisi ini.
Model transisinya bagaimana?
Meniru saja MOdel yang ada, tapi Mahal…., atau,
Re-Engineering sendiri prosesnya, murah tapi ber-resiko.. .??
Seperti misalnya..;
Ada yang tau ngga, bila management tanya…;
(1) Lebih menguntungkan pake Cisco atau Juniper?
(2) Lebih produktif pake Windows atau Linux?
(3) Di Data Center lebih bagus 1GB pake Cooper atau Fiber?
(4) Lalu…, tetap pake Mainframe atau Downsizing saja?
dan lain-lainnya. ….
Atau yang lebih extreem…,
(5) Tetap pake DRC (=Disaster Recovery Center) atau tidak?
Sudah banyak teknology yang memungkinkan tidak perlu tempat khusus yang persis sama dengan System yang ada, untuk DRC.
Cisco dan beberapa vendor lainnya (IBM, HP, SUN, EMC, dan merk-merk baru lainnya..), sedang gencar-gencar- nya memperkenalkan konsep Virtualisasi ini.
Dengan demikian, membuat DRC ngga perlu mengeluarkan biaya sebanyak Sistem yang pertama ada (yang sudah ada).
Bank ngga suka belanja DRC model lama, tapi tetap mau punya…🙂
Dari pengalaman Saya berbicara dengan beberapa Manajemen IT dan beberapa sumber di Bank-Bank besar kita–yang umumnya sangat aktif pada system yang baru dan kompleks, mereka masih lebih banyak mempersoalkan Terjemahan Surat Edaran BI mengenai RISK MANAGEMENT (MANAJEMEN RISIKO), PBI No.5/8/PBI/2003 tanggal 19 Mei 2003
Kalau dalam Basel Accord sebelumnya Terjemahan yang dipentingkan adalah Compliances (SARBOX, ITIL, ISO-9000-an, ISO-14000, BS-7779, dan Standard-xxxx lainnya… ), didalam Basel II Accord yang juga sudah diterjemahkan oleh Bank Indonesia (BI) dengan Surat Edaran-nya, lebih mengutamakan RISK MANAGEMENT. Termasuk RISK MANAGEMENT di IT. Jadi bukan Risk dari LOAN (Pinjaman) saja…, tapi sudah masuk ke aras OPERATIONAL RISK.
Kalau Saya boleh umpamakan, IT ada di barisan SUPPORT dan Management di barisan Business Inti-nya (CORE).
Dalam Hierarki itu, IT ada dibawah struktur,yang men-support Core-nya.
Dari hierarki itu.., sampai hari ini jarang yang bisa berbicara dengan bahasa yang sama.
Orang IT bicara Teknis, Manajemen bicara uang dan produktifitas.
Contoh;
Orang IT bilang, kita harus pake Bandwidth 512KBps menggantikan Bandwidth yang ada sekarang, 128KBps.
Manajemen tanya…, mengapa harus 512KBps? Mengapa tidak 256KBps…?
Bagi Manajemen, berasumsi, peningkatan Bandwidth 2x saja dari Kapasitas yang ada, harapannya Produktifitas dan Revenue Generation dari Link itu seharusnya, paling tidak 2 kali juga. (Kecuali bersepakat buat nutupin kesalahan Sizing Link Network….)
Ngga salah kan…, Manajemen berpikir begitu..??
Nah…, apa justifikasi orang IT untuk memilih antara 256KBps atau 512KBps…?
Apa kita mau pake gaya… “POKOKNYA… harus gini, POKOKNYA harus segitu…!!”
Contoh aktual lagi:
Bank Sentral kita, Bank Indonesia (BI) si pembuat Edaran, masih terlihat berkutat terlalu teknis dalam operasionalnya.
Belum terlihat bagaimana mereka meng-aktual- kan Basel II Accord itu dalam IT-nya (Mungkin ngga perlu untuk mereka… justru yang perlu itu di Bank binaannya… )
Misalkan saja soal RTGS (=Real Time Gross Settlement) dulu.
Pernah RTGS itu tidak seperti janjinya (dulu…), tidak Real Time.
Bahkan perlu waktu beberapa jam agar dana aktif di-rekening tujuan.
(Ini khan tidak lucu…!!)
Setelah berjalan bbrp tahun masih sama dan namanya belum diganti-ganti juga…, masih “REAL TIME” Gross Settlement.
Bahkan ada Bank yang nulis pengumuman di Counter Teller berbunyi..,” Dana melalui Fasilitas RTGS akan aktif 2 jam setelah Anda meninggalkan Counter”.
Ini kan tidak lucu…. Seolah-olah Nasabah kita tidak mengerti istilah Bahasa Inggris, “Real Time..”
Atau “REAL TIME” itu sebuah NAMA saja.
Kasus seperti itu terjadi, biasanya karena tidak punya cara mengontrol baik teknisnya maupun kualitas.
Seperti ungkapan yang saya kutip ini;
You can not IMPROVE what you can not SEE!
You can not CONTROL what you can not MEASURE!
You can not OPTIMIZE what you can not CONTROL!
Kalau kita tidak punya data…, bagaimana mungkin ada justifikasi ??
Karena tidak ada Justifikasi yang jitu…, siap-siap saja pengajuan anggaran ditolak terus…, dipotong terus…
Kalaupun disetujui… , lebih karena terpaksa, supaya Rekan-rekan di IT ngga pindah kerja ketempat lain…
BENEEERRRR ITU…!!!! Para Bos-bos banyak ngakunya begitu….!!
Jadi jangan cepat Gee…Errr.. ., kalau ajuan budget-nya disetujui…🙂
Belum tentu karena kita hebat…
::Kembali ke soal Berbayar dan Gratis…
Karena antara IT dan Manajemen perlu ada Bahasa yang sama–KPI dan SLA.
Kita harus punya cara agar sama-sama bisa memantau KPI dan SLA itu.
Dan akhirnya kita bisa menghitung ROI…, bersama-sama pula.
(Jadi…, kita bisa ikut klaim besaran Pembagian Bonus Perusahaan.. ., ngga hanya nunggu gaji saja…. Logis, kan…??🙂🙂 )
Pembuat Aplikasi yang Berbayar biasanya sudah meng-investasikan cukup banyak waktu, biaya dan Pemikiran untuk memberikan solusi kepada Customer-nya agar mampu melakukan integrasi dengan tugas-tugas Manajemen dalam membuat keputusan-keputusan , seperti sekarang yang sedang marak dengan istilah “Business Service Management”.
Seperti juga sudah Saya sebutkan diatas “They Put Value in It”.
Atau lebih spesific, “They Put Value in IT (Information Technology)”
Untuk beberapa aplikasi Gratis yang Saya baru lihat terdapat kelebihan kepada Penanganan Sub-Struktur dan umumnya sangat terlokalisasi dan umumnya juga belum terintegrasi dengan Sistem Pelaporan dan Tracking/Logging yang gencar-gencarnya dipersyaratkan.
Kalaupun sudah ada biasanya hanya menyediakan Raw Data atau Gateway-nya saja, harus di format ulang untuk penyajian kepada Auditor dan Manajemen, yang otomatis tidak bisa cepat. Wong.. buatnya di MS-EXCEL…
Apalagi untuk Ad-Hoc Reporting (Tiba-tiba si-Manager lagi heng…, kesal sama atasannya… , mungkin cutinya ditolak, minta kita sedia-in laporan dadakan. HARI INI JUGA…!!!! ).
Atau si Pak Direktur Marketing pusing, karena di-complaint terus sama Customer. Padahal dari sisi Kita, System biasa-biasa saja beroperasi.
Tapi untuk bilangin bahwa “Permasalahan bukan di kita, Paaaakk…..”, susah…, karena kita ngga ada data.
Pusing ngga…!!??
Nah disini…, pakai yang ‘Gretong” adalah cara yang BAGUS untuk BELAJAR…., tapi TIDAK BAGUS ditempat BEKERJA…
Kecuali tempat Anda bekerja, Anda dibayar untuk lebih banyak BELAJAR…., daripada banyak BEKERJA….🙂
(Ssstt…, supaya bisa lulus CCNP atau CCIE Written dan cari tempat kerja yang gajinya lebih besar di Dubai…)
Salah satu contoh kasus dengan RRD Tools Cacti atau sejenisnya.. .;
— Cacti atau sejenis dari NOC memantau Server 1,2,3 dan 4 melalui Router A yang terkoneksi ke Core Switch B. Swicth B ke Aggregate Switch C. Switch C terkoneksi ke 4 Application Server.
<<NOC>>—<< ROUTER A>>—-<<CORE SWITCH B>>—-<<AGGREGATE SWITCH C>>—-<<SERVER 1, 2, 3 dan 4>>
Kalau ROUTER A mengalami HANG setelah High CPU Utilization dan High Memory Utilization beberapa jam setelah Re-Konfigurasi terakhir oleh salah satu Engineer… sehingga tidak ada traffic dari/ke Core Switch, Aggregate dan Server-Server, alias terputus;
(1) ALARM apa yang Anda harapkan muncul di NOC? Apakah Server(-Server) bermasalah, atau Masalah di Switch-switch ?
(2) Berapa langkah dan Berapa lama untuk masing-masing langkah Anda lakukan, sampai kepada kesimpulan ROUTER A bermasalah?
(3) Berapa lama Anda baru tahu bahwa masalah sebenarnya adalah “Router Configuration CHANGED” ? Bukan “Kurang Memory”..!!
(4) Ketahuan ngga siapa yang merubah Konfigurasi dan atas alasan apa serta persetujuan siapa?
(5) Bagaimana Anda menghitung SLA per-node, SLA per-device, SLA per-Interface, SLA per-Service* *, dan SLA Gabungan dari keseluruhan System?
(6) Bagaimana Trend perilaku dari setiap Element tersebut sepanjang link itu…? Apakah ada polanya terhadap waktu? Karena setiap setelah di Re-Start bbrp jam kejadian lagi…., lagi… dan lagi…
(Emang kerjaan kita buat lihatin Router itu saja…!! Ada 50-an, 200-an, 1000-an Router lagi di cabang, Men..?!)
**SLA per-Service yang merupakan Gabungan dari beberapa infrastruktur yang membentuk Layanan IT di Perusahaan Anda.
Misalnya yang dipantau SLA LAYANAN MAIL SYSTEM, merupakan gabungan dari ;
[AVAILABILITY Inteface]; +
[RESPON TIME DNS Service (bisa dari Server berbeda)]; +
[Max. TOTAL Mail in Queue]; +
[AVAILABILITY dari MTA (Message Transport Agent) Mail Server];+
[CPU Utilization dgn max tresshold 75% ];+
[Memory Utilization] ;+
[SWAP MEMORY Size];+
[DISK SPACE UTILIZATION] ;+ de..el..el..
Umumnya yang Gretong perlu KERJA EXTRA KERAS untuk dapat melakukan itu dan BIASA-nya kita langsung VONIS “TIDAK BAGUS” begitu dapat 3x, 4x, 5x sandungan, dan pindah cari Gretong-an yang lain….
Jadi menurut Saya…, relatif lah… mau lihat Gretong alias Gratisan atau Berbayar…. WE SHOULD SEE VALUE IN IT…
::Re-Phrase. ..
INOVASI pada PRODUK hanya memberikan Anda 3 bulan Penyelesaian Masalah…., Tapi,
INOVASI pada PROSES memberikan Anda Setahun lebih Ketenangan Bekerja….. , dan bisa ambil Cuti Liburan.



Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

Kategori

%d blogger menyukai ini: