"Alfa-bank bisa diandalkan seperti tank,
dan Gamma-bank sama andalnya dengan bank!"
Victor Pelevin, "Numbers"
Ketika frase "sistem perbankan" muncul dalam percakapan, imajinasi menarik sistem yang sangat andal yang dibangun di atas peralatan paling mahal, dikelompokkan di semua tingkat yang memungkinkan dan dipagari dari dunia luar dengan sarana perlindungan yang dapat diakses dan tidak dapat diakses. Memang, sistem seperti itu ada. Tapi ...
Jika Anda melihat lowongan pengembang di bank, maka sangat mungkin untuk melihat di sana di antara persyaratan pengetahuan Cassandra, MongoDB dan platform lain, yang sama sekali tidak menginspirasi pemikiran tentang ketersediaan 100%. Dan DBMS seperti Oracle atau Microsoft SQL Server dipasang di suatu tempat di sekelompok server mahal yang terhubung ke array paling andal dan berkinerja tinggi, dan di suatu tempat di mesin virtual biasa di sebuah peternakan dari komoditas itu sendiri.
Alasannya jelas - solusi yang berlebihan itu mahal. Tetapi bagaimana menemukan kompromi antara biaya platform dan keandalannya?
Dahulu kala, ketika hanya ada sedikit sistem informasi di perusahaan, infrastruktur untuk setiap sistem adalah sebuah karya seni. Seiring waktu, ada lebih banyak sistem, menjadi mahal untuk mendukung beberapa ratus konfigurasi perangkat keras dan perangkat lunak yang berbeda, dan departemen infrastruktur sampai pada standardisasi. Misalnya, sekumpulan solusi infrastruktur RDBMS yang dapat digunakan aplikasi mungkin terlihat seperti ini:
- server kelas hi-end dengan array disk kelas hi-end ditambah replikasi sinkronis;
- server kelas menengah dengan array disk kelas menengah ditambah replikasi sinkronis;
- server kelas midrange dengan array disk midrange ditambah replikasi asynchronous;
- server komoditas dengan array disk midrange tanpa replikasi.
Sekarang bagaimana Anda memilih konfigurasi untuk database tertentu milik aplikasi tertentu?
Anda dapat membuat daftar "aplikasi terpenting yang harus berfungsi dengan segala cara". Hal ini menimbulkan dua masalah:
Konfigurasi perangkat keras untuk aplikasi lainnya bergantung pada "bobot" pemilik sistem. Akibatnya, beberapa layanan cuti sakit elektronik bekerja pada peralatan yang paling mahal, karena itu adalah gagasan favorit dari kepala akuntan, yang tidak ada yang mau bertengkar dengannya. Ini adalah pemborosan uang yang tidak masuk akal.
Beberapa aplikasi mungkin tidak termasuk dalam daftar "terpenting" karena belum dipikirkan. Misalnya, semua orang ingat tentang pemrosesan kartu bank, tetapi tidak ada yang ingat tentang memeriksa klien pada "daftar hitam", yang seharusnya berfungsi dengan setiap operasi. Akibatnya, kegagalan sistem semacam itu menjadi kejutan yang tidak menyenangkan dan berujung pada masalah yang serius.
Ada metodologi formal yang memungkinkan Anda membuat pilihan yang tepat dan melindungi apa yang membutuhkan perlindungan tanpa membayar lebih untuk apa yang tidak dapat Anda bayar lebih.
Untuk memulainya, klasifikasi aplikasi menurut tingkat kekritisan diperkenalkan. Biasanya, ada empat level ini. Mereka bisa dipanggil, misalnya seperti ini:
- Platinum;
- Emas;
- Perak;
- Perunggu.
Atau seperti ini:
- Misi penting;
- Bisnis penting;
- Operasional bisnis;
- Produktivitas kantor.
Keempat tingkatan ini sangat cocok dengan 4 konfigurasi infrastruktur yang berbeda. Satu-satunya hal yang harus dilakukan adalah mengklasifikasikan setiap aplikasi sesuai kebutuhan.
Saat mengevaluasi, penting untuk memperhatikan dua aturan:
Sistem dievaluasi oleh bisnis, dan bukan oleh departemen TI yang melayaninya. Kekritisan tidak boleh ditentukan oleh berapa lama atau padat karya sistem tersebut untuk dipertahankan. Satu-satunya kriteria adalah kerugian yang akan ditanggung bisnis dari waktu henti sistem.
Kata-kata dari pertanyaan yang membentuk penilaian harus memberikan kemungkinan untuk memverifikasi jawaban. Tentu saja, kriteria tersebut masih berdasarkan expert judgement, namun setidaknya expert tersebut dapat menjelaskan mengapa dia memberikan penilaian tersebut.
Apa yang menentukan tingkat kekritisan?
- . , , , .
- SLA (service level agreement). , – , .
- . , , .
Dalam praktik dunia, terdapat sesuatu seperti distribusi ini:
Ini tidak berarti bahwa di perusahaan Anda distribusi sistem menurut kelas harus persis sama. Tetapi bagaimanapun juga, jika lebih dari 15% dari sistem operasi masuk ke kelas kritis Misi, ini adalah alasan untuk berpikir serius.
Untuk pertanyaan "seberapa besar sistem ini atau itu dibutuhkan", pemilik mana pun akan menjawab "sangat". Oleh karena itu, pertanyaan lain perlu ditanyakan: apa yang terjadi jika sistem berhenti? Kelas kekritisan sistem bergantung pada tingkat keparahan konsekuensi dari penghentian sistem dan kecepatan kemunculannya.
Mari kita lihat beberapa sistem perbankan.
Sistem penyelesaian menyediakan (kejutan!) Penyelesaian antara klien - badan hukum. Jika tiba-tiba klien perusahaan besar tidak dapat melakukan pembayaran kepada rekanan, maka bank akan kehilangan jumlah yang sangat besar, sehingga sistem penyelesaian pasti akan termasuk dalam kelas kritis tertinggi.
Mari kita lakukan pemrosesan kartu. Jika seratus atau dua nasabah tidak dapat membayar dengan kartu, kerugian bank akan kecil, tetapi penolakan layanan besar-besaran tidak dapat diterima dengan sendirinya.
Sekarang mari kita ambil sistem yang mengelola simpanan. Jika sistem ini berhenti, kerugian bank akan kembali kecil, dan penolakan layanan tidak akan sebesar dalam kasus pemrosesan. Tapi apakah kita memerlukan editorial surat kabar dengan tajuk "Bank Menolak Menerbitkan Deposit"? Pertanyaannya retoris.
Terakhir, mari kita lihat buku besar. Jika tiba-tiba sesuatu terjadi padanya, maka pelanggan tidak akan melihat apa-apa, karena sistem ini sama sekali tidak berpartisipasi dalam layanan pelanggan. Tapi ada baiknya menunda pengiriman neraca, karena sanksi dari Bank Sentral tidak akan lama lagi.
Jadi, konsekuensi negatif dari waktu henti sistem dapat dibagi menjadi 4 kelas:
- Ekonomi (kerugian langsung);
- Klien (penolakan layanan);
- Reputasi (reaksi negatif di media);
- Hukum (dari peringatan dan denda hingga tuntutan hukum dan pencabutan izin).
Untuk setiap kelas konsekuensi, kriteria tingkat keparahan harus dirumuskan dan diberi skor dari 0 hingga 4. Misalnya, tabel mungkin terlihat seperti ini:
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| Ekonomis | tidak | <0,1% dari laba yang direncanakan | 0,1% .. 0,5% dari laba yang direncanakan | 0,5% .. 1% dari keuntungan yang direncanakan | > 1% dari laba yang direncanakan |
| Klien | tidak | 1 klien | >1% | >5% | >10% |
Tentu saja, semua angka itu sewenang-wenang, semua metode penghitungan hanya didasarkan pada penilaian ahli, dan ruang lingkup perdebatan tentang apa yang dianggap sebagai "media regional" dan bagaimana memperlakukan artikel negatif di blog populer benar-benar tidak terbatas. Tetapi di perusahaan besar pasti akan ada departemen hukum dan layanan PR yang akan dengan mudah mengungkapkan pendapat yang kompeten.
Langkah selanjutnya adalah memilih interval waktu di mana kami akan memperkirakan kerugian. Misalnya jam, 4 jam, 8 jam, 24 jam. Interval ini sewenang-wenang dan tidak ada hubungannya dengan SLA untuk sistem yang dievaluasi. Meskipun di masa mendatang akan tepat untuk mengikat SLA standar ke interval ini.
Sekarang pemilik setiap sistem mengisi matriks 16 sel. Angka-angka pada tabel di bawah ini diberikan sebagai contoh. Satu-satunya hal yang secara fundamental penting adalah bahwa perkiraan konsekuensi untuk interval yang lebih lama tidak boleh kurang dari perkiraan untuk interval yang lebih pendek.
| hingga 1 jam | 1..4 jam | 4..8 jam | 8..24 jam | |
|---|---|---|---|---|
| Ekonomis | 1 | 1 | 3 | 3 |
| Klien | 1 | 2 | 2 | 3 |
| Reputasi | 0 | 0 | 1 | 2 |
| Hukum | 1 | 2 | 3 | 4 |
Ada tiga langkah tersisa untuk mendapatkan nilai akhir dari matriks ini.
Langkah satu - untuk setiap interval waktu, pilih perkiraan maksimum:
| hingga 1 jam | 1..4 jam | 4..8 jam | 8..24 jam | |
|---|---|---|---|---|
| MAKSIMUM | 1 | 2 | 3 | 4 |
Langkah kedua: kami menerjemahkan perkiraan yang diperoleh ke dalam kelas kekritisan menggunakan matriks:
| Poin | hingga 1 jam | 1..4 jam | 4..8 jam | 8..24 jam |
|---|---|---|---|---|
| 4 | MC | MC | SM | SM |
| 3 | MC | SM | SM | BO |
| 2 | BO | BO | BO | OP |
| 1 | BO | BO | OP | OP |
Untuk sistem ini, kami memperoleh perkiraan berikut:
| hingga 1 jam | 1..4 jam | 4..8 jam | 8..24 jam | |
|---|---|---|---|---|
| KELAS | BO | BO | SM | SM |
Dan, terakhir, dari semua estimasi yang diperoleh, kami memilih yang maksimal - dalam hal ini, sistem yang dinilai harus diklasifikasikan sebagai Business critical.
Setelah menerima perkiraan ini, kami dapat memilih satu atau beberapa solusi infrastruktur untuk setiap sistem.
Ada beberapa nuansa yang tersisa, yang tanpanya metodologi yang dijelaskan tidak akan lengkap.
Jika sistem memastikan pengoperasian sistem lain, maka kelas kekritisannya tidak boleh lebih rendah dari kelas sistem dependen. Misalnya, Active Directory sama sekali tidak ada hubungannya dengan bisnis. Tetapi jika tiba-tiba naik, maka konsekuensi untuk banyak aplikasi bisnis akan menjadi yang paling mengerikan, dan oleh karena itu AD pasti termasuk dalam kelas kritis Misi.
Kerugian yang timbul sebagai akibat dari downtime sistem tidak boleh lebih rendah dari kerugian yang timbul karena mengganggu proses bisnis yang disediakan sistem ini. Mengingat aturan ini, sangat menarik untuk mengevaluasi sistem email perusahaan, karena tiba-tiba ternyata pertukaran informasi penting terkait dengannya.
Jika sebuah perusahaan menggunakan beberapa blok pada sistem yang sama, dan estimasi blok-blok tersebut untuk sistem berbeda, maka estimasi maksimum harus digunakan. Selain itu, bahkan kriteria penilaiannya mungkin berbeda. Misalnya, penilaian ketidakmungkinan untuk melayani satu klien bisa sangat berbeda tergantung pada jenis klien itu - "fisikawan" biasa, VIP atau klien korporat besar.
Beri label pada sistem Anda - dan semoga infrastruktur Anda dapat diandalkan sebagaimana mestinya, tetapi tidak lebih mahal dari yang seharusnya!