100% waktu aktif untuk aplikasi web


312

Kami menerima "persyaratan" yang menarik dari klien hari ini.

Mereka ingin 100% uptime dengan failover di luar situs pada aplikasi web. Dari sudut pandang aplikasi web kami, ini bukan masalah. Itu dirancang untuk dapat memperluas berbagai server database, dll.

Namun, dari masalah jaringan saya sepertinya tidak tahu bagaimana membuatnya bekerja.

Singkatnya, aplikasi akan hidup di server dalam jaringan klien. Ini diakses oleh orang internal dan eksternal. Mereka ingin kita menyimpan salinan sistem di luar lokasi yang jika terjadi kegagalan serius di tempat mereka akan segera mengambil dan mengambil alih.

Sekarang kita tahu sama sekali tidak ada cara untuk menyelesaikannya untuk orang-orang internal (merpati pos?), Tetapi mereka ingin pengguna eksternal bahkan tidak menyadarinya.

Sejujurnya, saya tidak punya ide foggiest tentang bagaimana ini mungkin. Tampaknya jika mereka kehilangan konektivitas Internet maka kita harus melakukan perubahan DNS untuk meneruskan lalu lintas ke mesin eksternal ... Yang, tentu saja, membutuhkan waktu.

Ide ide?

MEMPERBARUI

Saya berdiskusi dengan klien hari ini dan mereka mengklarifikasi masalah ini.

Mereka terjebak oleh angka 100%, mengatakan aplikasi harus tetap aktif bahkan jika terjadi banjir. Namun, persyaratan itu hanya berlaku jika kami menyediakannya untuk mereka. Mereka mengatakan akan menangani persyaratan waktu aktif jika aplikasi sepenuhnya hidup di server mereka. Anda dapat menebak respons saya.


49
Jangan meremehkan downtime besar yang disebabkan oleh peretasan, lihat Sony dan jaringan PlayStation. Anda dapat menjamin mereka memiliki ide waktu aktif% 100 yang sama dan uang / perangkat keras untuk mendukungnya. jelaskan kepada klien bahwa waktu aktif 100% adalah harapan yang tidak mungkin, bahkan teknisi Google akan ragu untuk menggumamkan "Waktu aktif 100%". petunjuknya adalah untuk melihat ke dalam menggunakan DNS dinamis, mereka hanya cache selama 60 detik, ini harus mencakup OS dan server DNS lokal.
Silverfire

182
Saya pribadi akan MENJALANKAN dari klien ini secepat mungkin. Saya menduga ini bukan ide gila terakhir yang mungkin mereka miliki (dari sudut pandang teknologi).
GregD

137
Saya berharap saya bisa menurunkan klien Anda.
joeqwerty

81
Jika Anda mengetahui uptime 100% beri tahu saya. Saya akan membuat bisnis dengannya dan menjualnya ke google. Tidak mungkin untuk menjamin 100%. Bahkan perusahaan seperti microsoft, amazon atau google tidak akan mencapai setinggi itu karena mereka tahu itu tidak mungkin. Yang terbaik yang pernah saya lihat adalah 99,999% dan bahkan itu adalah peregangan (5 menit dalam setahun). Yang terbaik yang mungkin bisa Anda lakukan adalah 99,99% andal.
Matt

39
Buat saja label harga yang sangat mahal untuk permintaan gila mereka. Itu mungkin akan membuat mereka sadar kembali. Entah daripada, atau itu akan mengirim mereka pergi mencari seseorang yang mau berbohong kepada mereka.
Nate CK

Jawaban:


368

Berikut ini adalah bagan Wikipedia tentang pengejaran sembilan:

masukkan deskripsi gambar di sini

Yang menarik, hanya 3 dari 20 situs web teratas yang mampu mencapai mitos 5 nines atau 99,999% uptime pada 2007. Mereka adalah Yahoo, AOL, dan Comcast. Dalam 4 bulan pertama 2008, beberapa jejaring sosial paling populer , bahkan tidak mendekati itu.

Dari grafik, harus jelas betapa konyol mengejar pengejaran 100% adalah ...


62
Pingdom juga tidak memeriksa setiap detik. Selain itu, yang memenuhi lima sembilan mungkin masih memiliki gangguan lokal yang Pingdom mungkin tidak terdeteksi, atau gangguan yang membuat beberapa layanan tidak tersedia saat masih menanggapi ping.
ceejayoz

8
Yang dengan sendirinya membuat lima sembilan kali diragukan ...
GregD

5
Tepat. Dan mereka punya $ miliaran untuk bekerja dengan!
ceejayoz

43
Maaf mengganggu obrolan yang terjadi, tetapi pertanyaan OP adalah bagaimana cara berjuang menuju tujuan 100% waktu aktif pada tingkat teknis tidak secara konseptual, saya yakin dia tahu itu tidak selalu mungkin karena kejadian alami yang terjadi pada perangkat keras dan lingkungan. Bisakah kita membantunya?
David d C e Freitas

5
Untuk OP: Saya telah melihat SLA yang menjamin uptime dalam konteks "di luar pemeliharaan normal". Pemeliharaan normal tentu saja dijadwalkan downtime per bulan untuk pembaruan, tambalan, dll., Yang biasanya terjadi pada hari paling sibuk dalam sebulan selama waktu paling sibuk dalam sebulan (biasanya di tengah malam). Mereka harus memiliki beberapa jenis metrik untuk bisnis mereka terkait dengan bisnis. Anda dapat menawarkan waktu kerja yang lebih baik (4 sembilan) untuk mereka hanya selama waktu tersebut.
GregD

186

Minta mereka untuk mendefinisikan 100% dan bagaimana hal itu akan diukur Selama periode apa. Mereka mungkin berarti hampir 100% yang mereka mampu. Beri mereka biaya.

Untuk menguraikan. Saya telah berdiskusi dengan klien selama bertahun-tahun dengan persyaratan yang dianggap konyol. Dalam semua kasus mereka sebenarnya hanya menggunakan bahasa yang tidak tepat.

Cukup sering mereka membingkai hal-hal dengan cara yang tampak absolut - seperti 100% tetapi pada kenyataannya pada investigasi yang lebih dalam mereka cukup masuk akal untuk melakukan analisis biaya / manfaat yang diperlukan ketika disajikan dengan penetapan biaya untuk risiko data mitigasi. Menanyakan kepada mereka bagaimana mereka akan mengukur ketersediaan adalah pertanyaan penting. Jika mereka tidak mengetahui hal ini maka Anda berada dalam posisi yang harus menyarankan kepada mereka bahwa ini perlu didefinisikan terlebih dahulu.

Saya akan meminta klien untuk menentukan apa yang akan terjadi dalam hal dampak / biaya bisnis jika situs turun dalam keadaan berikut:

  • Pada jam tersibuk mereka selama x jam
  • Setidaknya jam sibuk mereka selama x jam

Dan juga bagaimana mereka akan mengukur ini.

Dengan cara ini Anda dapat bekerja dengan mereka untuk menentukan level '100%' yang tepat. Saya menduga dengan mengajukan pertanyaan-pertanyaan semacam ini mereka akan dapat lebih menentukan prioritas persyaratan mereka yang lain. Misalnya mereka mungkin ingin membayar tingkat SLA tertentu dan kompromi fungsi lainnya untuk mencapai ini.


21
Sepakat. Mereka mungkin berarti uptime "sangat tinggi" (90-an?) Dengan strategi failover yang cukup solid. Jika tidak, maka penjelasan tentang skala biaya yang terlibat semoga akan meyakinkan mereka ...
Martin Dow

32
Memberi +1 untuk tidak melompat ke kesimpulan, dan alih-alih hanya meminta klien untuk menjelaskan apa yang ada dalam pikiran mereka.
sleske

4
Saya menggemakan pernyataan "tidak langsung ke kesimpulan" ... jika pelanggan berarti 100% uptime (dikurangi pemeliharaan terjadwal) maka mungkin lebih dari persyaratan yang wajar.
Tim Reddy

1
Mengenai dampak bisnis, kami benar-benar mengetahui dan memahami bisnis mereka sepenuhnya dan biaya yang dikeluarkan untuk situs tersebut tidak bersifat finansial. Lebih banyak di sepanjang garis penduduk asli muncul dengan garpu rumput, gantungan potensial, dll;) Bayangkan saja 40.000 orang muncul di pintu depan Anda berteriak. Itulah yang ingin mereka hindari dengan penuh gairah.
NotMe

7
@ ChrisLively Semua alasan lebih untuk memiliki pemahaman yang matang tentang risiko itu. Paradigma dominan untuk teknik keselamatan adalah penilaian risiko probabilistik . Ada sistem yang dapat membunuh (tidak hanya mengganggu) ribuan orang dan mereka masih memiliki probabilitas kegagalan yang rendah, semoga dipahami dengan baik, tetapi tidak nol.
poolie

140

Klien Anda gila. Uptime 100% tidak mungkin tidak peduli berapa banyak uang yang Anda habiskan untuk itu. Polos dan sederhana - tidak mungkin. Lihatlah Google, Amazon, dll. Mereka memiliki jumlah uang yang hampir tak ada habisnya untuk dilemparkan ke infrastruktur mereka, namun mereka masih bisa mengalami downtime. Anda perlu menyampaikan pesan itu kepada mereka, dan jika mereka terus bersikeras bahwa mereka menawarkan tuntutan yang masuk akal. Jika mereka tidak menyadari bahwa beberapa jumlah downtime tidak bisa dihindari, maka parit 'em.

Yang mengatakan, Anda tampaknya memiliki mekanisme penskalaan / distribusi aplikasi itu sendiri. Bagian jaringan akan perlu melibatkan uplink yang berlebihan ke ISP yang berbeda, mendapatkan alokasi ASN dan IP, dan mendapatkan leher yang dalam di BGP dan gear routing nyata sehingga ruang alamat IP dapat bergerak di antara ISP jika perlu.

Ini, tentu saja, jawaban yang sangat singkat. Anda belum memiliki pengalaman dengan aplikasi yang memerlukan tingkat uptime ini, jadi Anda benar-benar perlu melibatkan seorang profesional jika Anda ingin mendapatkan mendekati mitos 100% uptime.


7
Sepakat. Sama sekali. Gila.
jdw

2
mereka dulu ??
Sirex

2
@ Sirex Mengacu pada eksperimen baru-baru ini @ CERN di mana neutrino ditemukan bergerak lebih cepat daripada cahaya. Hasil belum dikonfirmasi oleh ilmuwan independen.
TC1

9
@ TC1 Saya akan bertaruh Anda $ 200 yang tidak berjalan dengan baik.
dpatchery

4
@ErikA Permintaan waktu aktif 100% merupakan indikasi ketidaktahuan karakteristik teknis sistem. Tidak apa-apa, karena pekerjaan pelanggan adalah melakukan apa pun yang mereka lakukan. Tugas Anda adalah merekayasa sistem TI. Pelanggan yang sulit seperti ini bisa menjadi mimpi buruk, tetapi mereka juga bisa menjadi pelanggan terbaik Anda.
duffbeer703

54

Yah, itu pasti yang menarik. Saya tidak yakin saya ingin mendapatkan kontrak uptime 100%, tetapi jika saya harus, saya pikir itu akan terlihat seperti ini:

Mulailah dengan IP publik pada penyeimbang beban yang sepenuhnya keluar dari jaringan dan buat setidaknya dua di antaranya sehingga yang satu bisa gagal ke yang lain. Sebuah program seperti Heatbeart dapat membantu dengan kegagalan otomatis dari mereka.

Varnish terutama dikenal sebagai solusi caching tetapi melakukan beberapa load balancing yang sangat baik juga. Mungkin itu akan menjadi pilihan yang baik untuk menangani keseimbangan beban. Hal ini dapat diatur agar memiliki 1 hingga n backend secara opsional dikelompokkan dalam direksi yang akan memuat keseimbangan baik secara acak atau round-robin. Pernis dapat dibuat cukup pintar untuk memeriksa kesehatan setiap ujung belakang dan menjatuhkan ujung yang tidak sehat keluar dari loop sampai kembali online. Backend tidak harus berada di jaringan yang sama.

Saya agak jatuh cinta dengan IP Elastis di Amazon EC2 hari ini, jadi saya mungkin akan membangun penyeimbang beban di EC2 di berbagai wilayah atau setidaknya di zona ketersediaan berbeda di kawasan yang sama. Itu akan memberi Anda pilihan untuk memutar secara manual (Tuhan melarang) memutar load balancer baru jika Anda harus dan memindahkan IP record A yang ada ke kotak baru.

Varnish tidak dapat mengakhiri SSL, jadi jika itu yang Anda khawatirkan, Anda mungkin ingin melihat sesuatu seperti Nginx.

Anda dapat memiliki sebagian besar backend Anda di jaringan klien Anda dan satu atau lebih di luar jaringan mereka. Saya percaya, tetapi saya tidak 100% yakin, bahwa Anda dapat memprioritaskan backend sehingga mesin klien Anda akan menerima prioritas sampai semuanya menjadi tidak sehat.

Di situlah saya akan mulai jika saya memiliki tugas ini dan tidak diragukan lagi memperbaikinya saat saya melanjutkan.

Namun, seperti yang dinyatakan oleh @ErikA, Internet dan selalu ada bagian jaringan yang berada di luar kendali Anda. Anda akan ingin memastikan bahwa hukum Anda hanya mengikat Anda dengan hal-hal yang berada di bawah kendali Anda.


2
Untuk sementara saya memikirkan Amazon dan MS untuk penyebaran cloud, tetapi keduanya mengalami pemadaman besar selama beberapa bulan terakhir. SSL sangat penting.
NotMe

3
Jika Anda akan menggunakan Amazon, Anda pasti ingin menyebarkan mesin Anda di sekitar 5 zona ketersediaan. Sangat tidak mungkin bahwa semua zona mereka akan keluar pada saat yang sama.
jdw

11
+1 untuk benar-benar menjawab pertanyaan utama OP.
Phil

Anda akan selalu memiliki titik kegagalan, jdw, selama ada hal yang tidak terdistribusi dalam rantai (dalam detak jantung kasus Anda, kecuali tentu saja Anda memiliki beberapa contoh yang berjalan pada mesin jarak jauh semua memonitor satu sama lain serta Anda server, yang salah satu dari mereka mungkin atau mungkin tidak melihat karena masalah jaringan sepanjang perutean). Yang membawa kita ke "downtime". Server mungkin aktif dan berjalan dan masih tidak tersedia untuk klien tanpa detak jantung yang pernah mendeteksinya jika kegagalannya tidak ada di jalur perutean.
jwenting

Sepakat. Seperti yang ditunjukkan SEMUA ORANG lainnya, tidak ada yang namanya 100% uptime. Yang dapat Anda lakukan adalah mencoba dan apa yang saya jelaskan adalah bagaimana saya akan mulai mencoba.
jdw

30

Tidak masalah - kata-kata kontrak yang sedikit direvisi:

... menjamin waktu kerja 100% (dibulatkan ke nol tempat desimal).


2
+1 untuk mencatat, bahwa 100% bukan 100,0% atau 100.000% dll. Angka desimal penting, mereka menunjukkan presisi;)
Danubian Sailor

4
Dengan beberapa konvensi, "100%" hanya memiliki satu angka penting, sehingga semua angka antara setengah dan satu akan membulatkan ke "100%"; 50% akan dibulatkan menjadi 100%.
Thomas Levine

1
Tergantung pada standar untuk menghitung beberapa akan mengatakan bahwa 50% memiliki dua angka meeningfull di mana 100% memiliki tiga angka meeningfull. 50,5 dan 100 kedepan sama persis. Yang lain akan menghitung angka setelah titik desimal. Maka 50,5 dan 100,4 akan sama akuratnya. Jika tidak ada yang menyatakan saya akan menganggap bahwa 100% adalah 99,5% dan lebih tinggi. 100,0% adalah 99,95% dan lebih tinggi dll.
Tillebeck

26

Jika Facebook dan Amazon tidak bisa melakukannya, maka Anda tidak bisa. Sesederhana itu.


17
dia bisa lebih pintar daripada gabungan semua orang mereka, siapa tahu: p
Matt

3
100% uptime tidak harus menjadi orang yang benar-benar literal - itu berarti: 100% tersedia selama waktu yang dibutuhkan. Sebagai contoh, sistem bank harus selalu tersedia, dan mereka melakukannya dengan cukup baik. Hanya karena mereka turun untuk pemeliharaan selama 1 detik setahun sekali tidak berarti mereka gagal pada target waktu operasional 100% mereka.
David d C e Freitas

13
@ Davidvidreitas - Saya pikir dalam kontrak biasanya cukup harfiah ...
UpTheCreek

2
@Matt hanya karena Facebook / Amazon tidak dapat melakukannya bukan berarti situs yang lebih kecil tidak dapat melakukannya. Banyak situs web besar menghadapi masalah yang jauh lebih sulit untuk diatasi daripada situs yang lebih kecil.
Xorlev

1
jadi apa yang Anda katakan adalah Anda tidak memiliki uptime 100% karena Anda memiliki beberapa klien yang memiliki kesalahan .. ditambah dns bukan saklar instan karena Anda memiliki ISP yang mengabaikan TTL pendek
Mike

25

Untuk menambahkan jawaban oconnore dari Hacker News

Saya tidak mengerti apa masalahnya. Klien ingin Anda merencanakan bencana, dan mereka tidak berorientasi matematika, jadi meminta probabilitas 100% terdengar masuk akal. Insinyur, seperti yang cenderung dilakukan oleh para insinyur, ingat hari pertamanya tentang masalah & stat 101, tanpa mempertimbangkan bahwa klien mungkin tidak. Ketika mereka mengatakan ini, mereka tidak berpikir tentang musim dingin nuklir, mereka berpikir tentang Fred menumpahkan kopinya di server kantor, disk crash, atau ISP turun. Lebih lanjut, Anda dapat mencapai ini. Dengan server pemantauan mandiri yang berbeda secara geografis, Anda pada dasarnya tidak akan memiliki waktu henti. Dengan 3 server yang beroperasi pada keandalan (1) tiga 9 independen, dengan mode failover yang baik, waktu henti yang diharapkan adalah di bawah satu detik per tahun (2). Bahkan jika ini terjadi sekaligus, Anda masih berada dalam SLA yang wajar untuk koneksi web, dan oleh karena itu downtime praktis tidak ada. Klien masih harus berurusan dengan skenario kiamat, tetapi Godzilla dikecualikan, ia akan memiliki layanan yang "selalu" naik.

(1) Sebuah server di LA cukup independen dari server di Boston, tapi ya, saya mengerti bahwa ada beberapa persimpangan yang melibatkan perang nuklir, peretas Cina menabrak jaringan listrik, dll. Saya tidak berpikir klien Anda akan kecewa dengan ini.

(2) Kegagalan DNS dapat menambahkan beberapa detik. Anda masih dalam skenario di mana klien harus mencoba kembali permintaan setahun sekali, yang, sekali lagi, dalam SLA yang wajar, dan biasanya tidak dianggap dalam nada yang sama dengan "downtime". Dengan aplikasi yang secara otomatis mengalihkan ke simpul yang tersedia pada kegagalan, ini bisa menjadi tidak terlihat.


6
Masalahnya adalah mereka mengatakannya dalam kontrak-ese. Yang berarti bahwa jika bencana tidak terjadi dan Anda perlu lebih dari sepuluh detik untuk mengambil situs kembali online melalui backup mereka harus berdiri untuk menuntut.
Shadur

@ Safur: Jika mereka benar - benar menginginkannya, maka Anda harus benar - benar menagihnya. Sebarkan server secara geografis jauh dan luas, semoga tidak akan ada bencana di mana-mana.
Jungle Hunter

3
Saya telah melihat situs yang menawarkan jaminan uptime 100% atau uang Anda kembali. Caranya adalah mereka menagih muatan kapal dan dipartisi menjadi beberapa bulan. Jadi beberapa bulan tidak dibayar dan Anda menjadwalkan segala sesuatu di sekitar itu, dan menutupi kerugian dengan bulan-bulan yang berjalan dengan baik.
jldugger

17

Anda diminta sesuatu yang mustahil.

Tinjau jawaban lain di sini, duduk bersama klien Anda, dan jelaskan MENGAPA tidak mungkin, dan ukur respons mereka.

Jika mereka masih bersikeras 100% uptime, dengan sopan beri tahu mereka bahwa itu tidak dapat dilakukan dan menolak kontrak. Anda tidak akan pernah memenuhi permintaan mereka, dan jika kontraknya tidak sepenuhnya menyedot Anda akan ditusuk dengan hukuman.


2
100% perlu didefinisikan, yaitu 100% tersedia kecuali ketika melakukan pemeliharaan atau peningkatan dan waktu itu akan terbatas pada jam tenang selama beberapa jam sebulan paling banyak. Itu semua tergantung pada apa tujuan dan penggunaan aplikasi web dalam kasus ini ...
David d C e Freitas

1
dan tentukan "downtime". Bahkan secara teori tidak dapat menjamin mereka akan dapat mengakses server di Omaha dari kantor mereka di Fairbanks kecuali Anda mengontrol seluruh jaringan di antaranya (meskipun Anda dapat memberikan jaminan tentang server yang sedang berjalan dan berjalan).
jwenting

Definisinya adalah, IMHO, tidak relevan jika mereka meminta "100% uptime": Bahkan jika Anda menegosiasikan pemeliharaan terjadwal dan membangun redundansi N + N jika satu kesalahan kecil menyebabkan reboot yang tidak terjadwal atau kedipan layanan Anda telah membuat SLA Anda rusak. PASTI relevan jika Anda sedang bernegosiasi SLA 3, 4 atau 5 nines.
voretaq7

Tergantung pada ketentuan SLA, bukan? Jika Anda dibayar $ 100K per bulan dan setiap menit downtime dikenakan penalti $ 1K, itu mungkin sepenuhnya dapat dilakukan (jika Anda memiliki kontrak lain untuk mengamortisasi biaya 24/7 di sysadmin di tempat).
Michael Borgwardt

@MichaelBorgwardt pasti ada cara untuk "membuatnya bekerja" dari sudut pandang angka murni, tapi saya masih akan menolak karena potensi PR buruk ($ _CLIENT digunakan di Twitter dan memberi tahu dunia bahwa kita sedang down karena $ _PROVIDER tidak kompeten dan tidak dapat memenuhi SLA mereka! '). Secara pribadi saya lebih suka memiliki 10 klien yang lebih kecil dan lebih masuk akal membayar saya $ 10ka bulan :-)
voretaq7

13

Harga sesuai, dan kemudian menetapkan dalam kontrak bahwa setiap downtime yang melewati SLA akan dikembalikan pada tingkat yang mereka bayar.

ISP di pekerjaan terakhir saya melakukan itu. Kami memiliki pilihan jalur DSL "biasa" dengan 99,9% waktu kerja untuk $ 40 / bulan, atau trio T1 terikat pada 99,99% waktu kerja untuk $ 1100 / bulan. Sering terjadi pemadaman 10+ jam per bulan, yang membawa waktu uptime mereka jauh di bawah $ 40 / bulan DSL, namun kami hanya dikembalikan sekitar $ 15 atau lebih, karena itulah tarif per jam * jam berakhir pada. Mereka keluar seperti bandit dari kesepakatan itu.

Jika Anda menagih $ 450.000 sebulan untuk uptime 100%, dan Anda hanya mencapai 99,999%, Anda harus mengembalikannya $ 324. Saya berani bertaruh biaya infrastruktur untuk mencapai 99,999% berada di sekitar $ 45.000 per bulan dengan asumsi colo terdistribusi penuh, beberapa uplink 1 tingkat, perangkat keras fancypants, dll.


3
Jika Anda melihat seseorang menjanjikan 100% uptime maka inilah yang mereka lakukan. Ada perbedaan antara menjanjikan waktu aktif 100% dan memberikannya. Akan lebih baik untuk menjelaskan hal ini kepada klien jika mereka mencoba mengutip SLA pesaing kepada Anda.
sjbotha

10

Jika para profesional mempertanyakan apakah ketersediaan 99,999 persen adalah kemungkinan yang praktis atau layak secara finansial , maka ketersediaan 99,9999% bahkan lebih tidak mungkin atau praktis. Apalagi 100%.

Anda tidak akan memenuhi sasaran ketersediaan 100% untuk periode waktu yang lama. Anda mungkin lolos begitu saja selama seminggu atau satu tahun, tetapi kemudian sesuatu akan terjadi dan Anda akan bertanggung jawab. Kejatuhan dapat berkisar dari reputasi yang rusak (Anda berjanji, Anda tidak memberikan) untuk kebangkrutan dari denda kontrak.


10

Ada dua jenis orang yang meminta waktu aktif 100%:

  1. Orang yang sama sekali tidak memiliki pengetahuan tentang komputer, sistem komputer, atau Internet. *
  2. Orang-orang yang dengan sengaja membuat kesalahan diri mereka sendiri, baik untuk menguji kemampuan Anda untuk mengatakan TIDAK (Google "the Orange Juice Test"), atau mencoba untuk mendapatkan semacam leverage kontrak SLA untuk keluar dari membayar Anda nanti.

Saran saya, setelah menderita kedua jenis klien ini pada banyak kesempatan, adalah untuk tidak menerima klien ini. Biarkan mereka membuat orang lain menjadi gila.

* Orang yang sama ini mungkin tidak memiliki rasa malu untuk bertanya tentang perjalanan yang lebih cepat dari Cahaya, Gerakan Abadi, Cold Fusion, dll.


2
+1 untuk tes jus jeruk .. Saya suka dan tidak tahu tentang hal itu :)
Oliver M Grech

8

Saya akan berkomunikasi dengan klien untuk menentukan dengan mereka apa sebenarnya arti uptime 100%. Mungkin mereka tidak benar-benar melihat perbedaan antara 99% uptime dan 100% uptime. Bagi kebanyakan orang (mis. Bukan admin server) kedua angka itu sama.


6

100% uptime?

Inilah yang Anda butuhkan:

Beberapa, (& redundant) server DNS, menunjuk ke beberapa situs di seluruh dunia, dengan SLA yang tepat dengan masing-masing ISP.

Pastikan server DNS diatur dengan benar, dengan TTL dikenali secara efektif.


1
Ya, DNS adalah awal yang baik - misalnya nslookup google.commengembalikan 6 IP berbeda untuk redundansi jika beberapa dari mereka tidak berfungsi. Lihat juga RobTex.com situs yang bagus untuk melihat konfigurasi domain tertentu, misalnya robtex.com/dns/google.com.html#records
David d C e Freitas

6

Ini mudah. Amazon EC2 SLA dengan jelas menyatakan:

"Persentase Uptime Tahunan" dihitung dengan mengurangi dari 100% persentase periode 5 menit selama Tahun Layanan di mana Amazon EC2 berada dalam keadaan "Wilayah Tidak Tersedia."

http://aws.amazon.com/ec2-sla/

Cukup tentukan 'uptime' sebagai relatif terhadap seluruh bundel layanan yang Anda dapat tetap beroperasi 100% dari waktu, dan Anda seharusnya tidak memiliki masalah.

Juga, ada baiknya menunjukkan bahwa seluruh poin dalam SLA adalah untuk menentukan apa kewajiban Anda dan apa yang terjadi jika Anda tidak dapat memenuhinya. Tidak masalah jika klien meminta 3 nines atau 5 nines atau sejuta nines - pertanyaannya adalah apa yang mereka dapatkan ketika / jika Anda tidak dapat mengirimkannya. Jawaban yang jelas adalah memberikan item baris untuk waktu aktif 100% pada harga 5x harga yang ingin Anda bebankan, dan kemudian mereka mendapatkan pengembalian dana 4x jika Anda melewatkan target itu. Anda mungkin mencetak gol!


5

Perubahan DNS hanya memakan waktu jika dikonfigurasi untuk mengambil waktu. Anda dapat mengatur TTL pada catatan menjadi satu detik - satu-satunya masalah Anda adalah memastikan bahwa Anda memberikan respons yang tepat waktu terhadap permintaan DNS, dan bahwa server DNS dapat mengatasi tingkat pertanyaan itu.

Inilah cara GTM bekerja di F5 Big IP - DNS TTL secara default diatur ke 30 detik dan jika salah satu anggota cluster perlu mengambil alih, DNS diperbarui dan IP baru segera diambil. Maksimal pemadaman 30 detik, tetapi itu adalah tepi kasus, rata-rata akan menjadi 15 detik.


10
Sudah pengalaman saya bahwa beberapa server DNS akan mengabaikan TTL yang mereka anggap rendah (terlepas dari RFC). Apa pun yang kurang dari 5 menit menjadi agak tidak dapat diandalkan dalam skala global.
jdw

13
@ Paul mengabaikan kenyataan bukanlah praktik yang dapat diterima, tidak peduli seberapa banyak hal itu membuat semua orang kesal.
MDMarra

5
Saya dengan jdw tentang ini. Saya telah melihat banyak server DNS yang benar-benar mengabaikan TTL, bahkan pengaturan 1 jam dan default kembali ke sekitar 24 jam atau lebih.
NotMe

6
@ Paul - OP tidak memiliki kendali atas setiap resolusi DNS ISP di planet ini. Ergo, mereka tidak mendapatkan pilihan untuk mengatakan "jika Anda akan menggunakan situs web kami, jangan gunakan Comcast / Roadrunner / siapa pun sebagai ISP Anda karena mereka akan mengabaikan pengaturan TTL kami". Ini adalah sesuatu yang hanya di luar kendali mereka dan karena itu terlalu rapuh untuk dianggap sebagai solusi untuk masalah IMHO ini. Solusinya harus mencakup beberapa cara untuk dapat memaksa IP secara internal sekitar tanpa mengandalkan bit lain dari jaringan yang mungkin tidak kooperatif.
jdw

3
Itu seperti tidak memiliki UPS karena kekuatan 'seharusnya hanya berfungsi'. Ini bukan cara berpikir maju untuk merancang sistem. Jika Anda tahu bahwa ada bagian yang rapuh dari sistem, untuk alasan apa pun, Anda harus mencoba menjelaskannya.
jdw

5

Anda tahu ini tidak mungkin.

Tidak diragukan bahwa klien fokus melihat "100%", jadi yang terbaik yang dapat Anda lakukan adalah berjanji 100%, kecuali untuk [semua penyebab yang masuk akal yang bukan kesalahan Anda].


Tidak diragukan klien tidak menginginkan solusi apa pun. Mereka menginginkan penurunan. Jadi mereka dapat mengatakan, mereka mencoba setidaknya.
mbx

Ya, mungkin. Anda mengasumsikan tingkat petunjuk yang tinggi.
Marcin

4

Meskipun saya ragu 100% adalah mungkin, Anda mungkin ingin mempertimbangkan Azure (atau sesuatu dengan SLA serupa) sebagai suatu kemungkinan. Apa yang terjadi:

Server Anda adalah mesin virtual. Jika ada masalah perangkat keras pada satu server, mesin virtual Anda dipindahkan ke mesin baru. Penyeimbang beban menangani pengalihan sehingga pelanggan tidak akan melihat waktu henti (meskipun saya tidak yakin bagaimana keadaan sesi Anda akan terpengaruh).

Yang mengatakan, bahkan dengan kegagalan ini, perbedaan antara 99,999 dan 100 berbatasan dengan kegilaan.

Anda harus memiliki kontrol penuh atas faktor-faktor berikut.
- Faktor manusia, baik internal maupun eksternal, baik kedengkian dan impotensi. Contohnya adalah seseorang mendorong sesuatu ke kode produksi yang menjatuhkan server. Lebih buruk lagi, bagaimana dengan sabotase?
- Masalah bisnis. Bagaimana jika penyedia Anda keluar dari bisnis atau lupa membayar tagihan listrik mereka, atau hanya memutuskan untuk berhenti mendukung infrastruktur Anda tanpa peringatan yang memadai?
- Alam. Bagaimana jika tornado yang tidak terkait secara bersamaan mengenai pusat data yang cukup untuk membanjiri kapasitas cadangan?
- Lingkungan yang sepenuhnya bebas bug. Apakah Anda yakin tidak ada kasus tepi dengan kontrol pihak ketiga atau sistem inti yang belum terwujud tetapi masih bisa melakukannya di masa depan?
- Bahkan jika Anda memiliki kontrol penuh atas faktor-faktor di atas, apakah Anda yakin perangkat lunak / orang yang memantau ini tidak akan memberi Anda negatif palsu ketika memeriksa apakah sistem Anda menyala?


2
Azure dan EC2 baru-baru ini mengalami kegagalan total dan hampir lengkap. Saya percaya Azure baru-baru ini diturunkan hanya karena entri konfigurasi yang buruk pada server DNS. Either way, terima kasih atas informasinya.
NotMe

dan jika penyeimbang beban Anda (yang melakukan pergantian) turun tanpa disadari (monitornya juga bisa turun tanpa disadari, ad infinitum) saat simpul turun, Anda masih kacau.
jwenting

1
Saya pikir Anda berarti 'tidak kompeten.' 'Impotensi' seharusnya tidak memiliki dampak besar pada kemampuan staf TI untuk melakukan pekerjaan mereka.
mfinni

4

Jujur 100% benar-benar gila tanpa setidaknya goyah dalam hal serangan peretasan. Taruhan terbaik Anda adalah melakukan apa yang dilakukan Google dan Amazon karena Anda memiliki solusi hosting terdistribusi geografis tempat Anda memiliki situs dan DB yang direplikasi di beberapa server di beberapa lokasi geografis. Ini akan menjamin itu dalam apa pun kecuali bencana besar seperti tulang punggung internet yang dipotong ke suatu wilayah (yang memang terjadi dari waktu ke waktu) atau sesuatu yang hampir apokaliptik.

Saya akan memasukkan klausa untuk kasus-kasus seperti itu (DDOS, pemotongan backbone internet, serangan teroris apokaliptik atau perang besar, dll).

Selain itu melihat ke Amazon S3 atau layanan cloud Rackspace. Pada dasarnya pengaturan cloud tidak hanya menawarkan redundansi di setiap lokasi tetapi juga skalabilitas dan geo-distribusi lalu lintas bersama dengan kemampuan untuk mengarahkan ulang di sekitar area geografis yang gagal. Padahal pengertian saya adalah bahwa geo-distribusi membutuhkan lebih banyak uang.


3

Saya hanya ingin menambahkan suara lain ke pesta " bisa (secara teoritis) dilakukan".

Saya tidak akan mengambil kontrak yang menetapkan ini tidak peduli berapa banyak mereka membayar saya, tetapi sebagai masalah penelitian, ia memiliki beberapa solusi yang agak menarik. Saya tidak cukup akrab dengan jaringan untuk menguraikan langkah-langkahnya, tetapi saya membayangkan kombinasi konfigurasi yang berhubungan dengan jaringan + kelistrikan kabel / perangkat keras, kegagalan perangkat lunak, mungkin, dalam beberapa konfigurasi atau pekerjaan lain untuk benar-benar melakukannya.

Hampir selalu ada satu titik kegagalan di suatu tempat dalam konfigurasi apa pun, tetapi jika Anda bekerja cukup keras, Anda dapat mendorong titik kegagalan itu menjadi sesuatu yang dapat diperbaiki "langsung" (mis. Root dns turun, tetapi nilainya masih di-cache di tempat lain sehingga Anda punya waktu untuk memperbaikinya).

Sekali lagi, tidak mengatakan itu layak .. Saya hanya tidak suka bagaimana tidak satu jawaban menjawab fakta bahwa itu bukan "jalan keluar" - itu bukan sesuatu yang mereka inginkan jika mereka memikirkannya.


3

Pikirkan kembali metodologi Anda mengukur ketersediaan kemudian bekerja dengan pelanggan Anda untuk menetapkan target yang berarti .

Jika Anda menjalankan situs web besar, uptime tidak berguna sama sekali. Jika Anda mengajukan pertanyaan selama 10 menit ketika pelanggan Anda sangat membutuhkannya (lalu lintas puncak), itu bisa lebih merusak bisnis daripada pemadaman selama satu jam pada pukul 3 pagi pada hari Minggu.

Terkadang perusahaan web besar mengukur ketersediaan, atau keandalan, menggunakan metrik berikut:

  1. persentase kueri yang berhasil dijawab, tanpa kesalahan sisi server (HTTP 500s).
  2. persentase kueri yang dijawab di bawah target latensi tertentu .
  3. kueri yang hilang harus dihitung terhadap statistik Anda (lihat di bawah).

Ketersediaan tidak boleh diukur menggunakan probe sampel, yang dapat dilaporkan oleh entitas eksternal seperti pingdom dan pingability. Jangan hanya mengandalkan itu. Jika Anda ingin melakukannya dengan benar, setiap permintaan tunggal harus dihitung . Ukur ketersediaan Anda dengan melihat keberhasilan Anda yang sebenarnya dan dirasakan.

Cara paling efisien adalah mengumpulkan log atau statistik dari load-balancer Anda dan menghitung ketersediaan berdasarkan metrik di atas.

Persentase kueri yang dijatuhkan juga harus dihitung terhadap statistik Anda. Itu bisa dipertanggungjawabkan dalam ember yang sama dengan kesalahan sisi server. Jika ada masalah dengan jaringan atau dengan infrastruktur lain seperti DNS atau load balancers, Anda bisa menggunakan matematika sederhana untuk memperkirakan berapa banyak kueri yang hilang . Jika Anda mengharapkan pertanyaan X untuk hari itu dalam seminggu tetapi Anda mendapat X-1000, Anda mungkin menjatuhkan 1000 pertanyaan. Plot lalu lintas Anda ke grafik kueri per menit (atau detik). Jika kesenjangan muncul, Anda menjatuhkan kueri. Gunakan geometri dasar untuk mengukur area celah itu, yang memberi Anda jumlah total kueri yang dijatuhkan.

Diskusikan metodologi ini dengan pelanggan Anda dan jelaskan manfaatnya. Tetapkan garis dasar dengan mengukur ketersediaan mereka saat ini. Akan menjadi jelas bagi mereka bahwa 100% adalah target yang mustahil.

Kemudian Anda dapat menandatangani kontrak berdasarkan perbaikan pada baseline. Katakanlah, jika mereka saat ini mengalami 95% ketersediaan, Anda bisa berjanji untuk memperbaiki situasi sepuluh kali lipat dengan mencapai 98,5%.

Catatan: ada kelemahan cara mengukur ketersediaan ini. Pertama, mengumpulkan log, memproses dan membuat laporan sendiri mungkin tidak sepele, kecuali jika Anda menggunakan alat yang ada untuk melakukannya. Kedua, bug aplikasi dapat mengganggu ketersediaan Anda. Jika aplikasi berkualitas rendah, itu akan melayani lebih banyak kesalahan. Solusi untuk ini adalah dengan hanya mempertimbangkan 500-an yang dibuat oleh load-balancer daripada yang berasal dari aplikasi.

Hal-hal mungkin menjadi sedikit rumit dengan cara ini, tetapi ini satu langkah lebih dari sekadar mengukur waktu server Anda .


3

Sementara beberapa orang mencatat di sini, bahwa 100% itu gila atau tidak mungkin , mereka entah bagaimana melewatkan poin sebenarnya. Mereka berpendapat, bahwa alasan untuk ini adalah kenyataan bahwa bahkan perusahaan / layanan terbaik tidak dapat mencapainya.

Yah, ini jauh lebih sederhana dari itu. Secara matematis tidak mungkin .

Semuanya memiliki probabilitas. Mungkin ada gempa bumi simultan di semua lokasi di mana Anda menyimpan server Anda, menghancurkan semuanya. Agaknya itu adalah probabilitas yang sangat kecil, tetapi itu bukan 0. Semua penyedia layanan internet Anda dapat menghadapi serangan teroris / cyber secara simultan. Sekali lagi, sangat tidak mungkin, tetapi juga tidak nol. Apa pun yang Anda berikan, Anda bisa mendapatkan skenario probabilitas non-nol yang membawa seluruh layanan turun. Karena ini, waktu aktif Anda juga tidak dapat 100%.


Sebenarnya, saya akan melewati masa gila atau tidak mungkin dan menyebutnya bodoh. Tidak ada yang diketahui manusia adalah 100%.
quadruplebucky

2

Pergi ambil buku tentang kontrol kualitas pembuatan menggunakan sampling statistik. Sebuah diskusi umum dalam buku ini, konsep-konsep yang mana manajer akan terkena dalam kursus statistik umum di perguruan tinggi, menentukan biaya untuk pergi dari 1 pengecualian dalam seribu, ke 1 dalam sepuluh ribu ke 1 dalam satu juta ke 1 dalam satu miliar kenaikan secara eksponensial. Pada dasarnya kemampuan untuk mencapai 100% uptime akan membutuhkan biaya dana yang hampir tidak terbatas, seperti jumlah bahan bakar yang dibutuhkan untuk mendorong objek ke kecepatan cahaya.

Dari perspektif rekayasa kinerja saya akan menolak persyaratan karena tidak dapat diuji dan tidak masuk akal, bahwa ungkapan ini lebih merupakan keinginan daripada persyaratan yang sebenarnya. Dengan dependensi aplikasi yang ada di luar aplikasi apa pun untuk jaringan, resolusi nama, perutean, cacat yang dipropagasi dari komponen arsitektural yang mendasari atau alat pengembangan, menjadi mustahil secara praktis untuk meminta siapa pun menjamin uptime 100%.


1

Saya tidak berpikir pelanggan sebenarnya meminta 100% uptime, atau bahkan 99,999% uptime. Jika Anda melihat apa yang mereka gambarkan, mereka berbicara tentang mengambil di mana mereka tinggalkan jika sebuah meteor mengeluarkan pusat data di tempat mereka.

Jika persyaratannya adalah orang luar yang tidak menyadarinya, seberapa drastis hal itu? Apakah membuat permintaan Ajax coba lagi dan tunjukkan spinner selama 30 detik kepada pengguna akhir bisa diterima?

Itu adalah hal-hal yang dipedulikan pelanggan. Jika pelanggan benar-benar memikirkan SLA yang tepat, maka mereka akan cukup tahu untuk menyatakannya sebagai 99,99 atau 99,999.


Jika pelanggan berpikir mereka ingin "100% uptime" dan saat itulah berakhir di bertele-tele kontrak, Anda mungkin ditahan untuk itu jika berakhir di pengadilan. Terbaik untuk membicarakannya dan membantu pelanggan memahami apa yang sebenarnya mereka inginkan alih-alih berasumsi Anda tahu apa yang mereka pikirkan.
Chris S

Oh, saya setuju ini harus diselesaikan sebelum kontrak. Saya hanya mengatakan ini perlu didekati karena klien tidak mengkomunikasikan apa yang sebenarnya mereka inginkan, sebagai lawan dari klien meminta sesuatu yang konyol.
Kevin Peterson

1

2 sen saya. Saya bertanggung jawab untuk situs web yang sangat populer untuk perusahaan keberuntungan-5 yang akan mengeluarkan iklan untuk mangkuk super. Saya harus berurusan dengan lonjakan besar dalam lalu lintas dan cara saya menyelesaikannya adalah dengan menggunakan layanan seperti Akamai. Saya tidak bekerja untuk Akamai tetapi saya menemukan layanan mereka sangat bagus. Mereka memiliki sistem DNS mereka sendiri yang lebih pintar yang tahu dengan node / host tertentu baik di bawah beban berat atau sedang turun dan dapat merutekan lalu lintas yang sesuai.

Yang rapi tentang layanan mereka adalah bahwa saya tidak benar-benar harus melakukan sesuatu yang sangat rumit untuk mereplikasi konten di server di pusat data saya sendiri ke pusat data mereka. Selain itu, saya tahu dari bekerja dengan mereka, mereka menggunakan banyak server HTTP Apache.

Meskipun tidak 100% aktif, Anda dapat mempertimbangkan opsi seperti itu untuk menyebarkan konten di seluruh dunia. Ketika saya mengerti banyak hal, Akamai juga memiliki kemampuan untuk melokalkan lalu lintas yang berarti jika saya berada di Michigan, saya mendapatkan konten dari server Michigan / Chicago dan jika saya berada di California, saya seharusnya mendapatkan konten dari server yang berbasis di California.


-1 karena ini adalah jawaban praktis tetapi tidak berguna sama sekali. Semua pertanyaan di situs ini dapat dijawab dengan "merekrut orang lain untuk melakukannya", tetapi itu bukan alasan kami ada di sini.
Yves Junqueira

Saya mohon untuk berbeda. "Tidak berguna sama sekali?" Itu tentu saja sangat berguna bagi saya dan bertentangan dengan komentar "pekerjakan orang lain untuk melakukannya", saya kira dengan alasan Anda, orang itu harus membuat parit kabel serat optiknya sendiri dan mendesain sakelar sendiri alih-alih membelinya juga? Apakah kamu serius, Yves? Anda terdengar seperti seseorang yang tidak menghabiskan banyak waktu di bidang IT.
Kilo

0

Alih-alih failover off-site, jalankan aplikasi dari dua lokasi secara bersamaan, internal dan eksternal. Dan menyinkronkan dua basis data ... Kemudian jika internal turun, orang-orang internal masih akan dapat bekerja dan orang-orang eksternal masih dapat menggunakan aplikasi. Ketika internal kembali online, sinkronkan perubahan. Anda dapat memiliki dua entri DNS untuk satu nama domain atau bahkan router jaringan dengan round robin.


0

Untuk situs yang dihosting secara eksternal, waktu uptime terdekat Anda akan 100% menjadi hosting situs Anda di Google App Engine dan menggunakan datastore replikasi tinggi (HRD) , yang secara otomatis mereplikasi data Anda di setidaknya tiga pusat data secara real time. Demikian juga, server ujung-depan App Engine secara otomatis diskalakan / direplikasi untuk Anda.

Namun, bahkan dengan semua sumber daya Google dan platform paling canggih di dunia, jaminan uptime App Engine SLA hanya "99,95% dari waktu dalam bulan kalender apa pun."


0

Sederhana dan langsung: Anycast

http://en.wikipedia.org/wiki/Anycast

Inilah yang cloudflare, google, dan perusahaan besar lainnya gunakan untuk melakukan redundansi, latensi rendah, lintas benua, kegagalan / penyeimbangan.

Tetapi juga perlu diingat bahwa tidak mungkin memiliki uptime 100%, dan bahwa biaya untuk beralih dari 99,999% menjadi 99,9999% jauh lebih besar.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.