Mengapa situs web (bahkan yang ini) terkadang “Down for Maintenance”?

36

Saya pribadi tidak pernah melakukan ini. Saya tidak mengerti mengapa begitu banyak situs melakukannya, jika Anda melakukan pengembangan di server pengembangan, mengapa Anda harus mematikan situs produksi Anda?

Saya selalu bertanya-tanya tentang ini.

Apa yang mereka lakukan selama ini, apa yang harus dilakukan?

web-development maintenance

— JD Isaacks
sumber

56

Mereka mengganti tabung vakum di server.

— mipadi

11

Saya pikir mereka menumpuk kartu punch.

— Christopher Mahan

5

Perlu diingat bahwa situs tersebut mungkin tidak mengikuti sebagian besar pembaruan. Jelas, Anda hanya melihat yang benar-benar perlu offline untuk sementara waktu.

— Dean Harding

4

Tidak ada yang membahas alasan keamanan; mungkin ada exploit yang diketahui (alias seseorang menerbitkan cara mengeksploitasi situs web tertentu) dan admin mengambilnya secara offline untuk mengurangi penyalahgunaan dari pihak lain sambil memperbaikinya.

— Francisco Presencia

1

Terjadi pada saya untuk bertanya 'Strategi apa yang dapat saya gunakan untuk mencapai nol downtime (direncanakan) dalam aplikasi web yang didukung database?' Khususnya peningkatan yang memerlukan perubahan skema db: softwareengineering.stackexchange.com/questions/336945/…

— Stephen

59

Tendangan besar untuk apa pun dengan skala besar adalah bahwa jika seseorang mengubah skema basis data dengan cara tertentu, seseorang biasanya memiliki beberapa skrip pemeliharaan besar dan tidak menyenangkan untuk dijalankan.

Sekarang, ini mungkin memerlukan waktu satu atau dua detik untuk berjalan dengan set data pengembangan Anda. Tetapi ketika Anda mulai mengukur data dalam terabyte dan petabytes, bahkan menambahkan satu kolom ke tabel bisa memakan waktu berjam-jam.

Jadi, tidak peduli seberapa cepat dan otomatis penyebarannya, Anda masih memiliki masalah pemeliharaan data untuk dilalui. Jika Anda merencanakan dengan sangat baik, Anda dapat memasang mirror read-only dari situs saat Anda sedang menjalani proses, tetapi untuk banyak situs read-only tidak ada gunanya dan dengan demikian tidak sepadan dengan usaha.

— Wyatt Barnett
sumber

3

+1 - stack overflow read-only tidak akan terlalu bagus. Tidak akan banyak yang tidak dapat Anda temukan di google :)

— corsiKa

10

@ glowcoder: Ketika Anda mencari di Google, Anda menemukan jawaban SO.

— Donal Fellows

@ Donal itu persis maksud saya.

— corsiKa

1

Google besar dan pasti memiliki basis data besar; kenapa saya tidak pernah melihat "down for maintenance" untuk google? (Beranda Google.com)

— alexyorke

7

@ alexy13 - google berada dalam kategori skala khusus di mana mereka tidak dapat memiliki database tunggal atau bahkan pusat data, bagian-bagian dari sistem selalu turun dan mereka telah menulis ujung depan untuk menanganinya. Saya juga akan jika Anda memberi saya waktu dan anggaran R&D seperti itu.

— Wyatt Barnett

7

Ada sejumlah alasan mengapa Anda mungkin ingin mengambil situs untuk pemeliharaan. Untuk beberapa nama:

Perubahan basis data
Perubahan DAL
Memperbarui layanan

Pada dasarnya, jika situs Anda tidak statis, ketika melakukan pembaruan logika Anda ingin menghapusnya jika tidak, orang yang memukul situs Anda mungkin menerima kesalahan atau perilaku yang tidak terduga.

Juga, jika Anda akan menyentuh web.config (dalam ASP.NET) untuk situs Anda, Anda harus menghapusnya untuk pemeliharaan terlebih dahulu karena akan meledakkan sesi untuk pengguna. Jadi, jika mereka berada di tengah-tengah sesuatu, itu akan hilang.

— Tyanna
sumber

2

sesi akan hilang jika menggunakan status sesi "Dalam Proses". Jika Anda menggunakan status sesi proses, sesi tidak akan hilang jika web.config diubah.

— Anthony

2

Poin terakhir hanya benar jika Anda melakukan sesi dalam proses, yang saya harap Anda tidak berada di lokasi produksi! Ada lebih dari sekadar menyentuh web.config yang akan menghapus proses pekerja.

— Dean Harding

7

Yah ini entah bagaimana pertanyaan abstrak - saya bahkan melihat situs yang menggunakan "Down for Maintenance" bukan HTTP 500.

Untuk situs web, Anda terkadang perlu melakukan peningkatan. Sebagai contoh jika Anda mengubah database Anda tidak ingin pengguna lain menyentuh database selama waktu itu. Jika database offline, situs harus dimatikan dengan anggun juga karena menunjukkan SqlException tidak terlalu bagus. Alasan lain adalah beberapa kegagalan HW atau kegagalan sistem (seperti sumber daya bocor) yang memerlukan aplikasi atau bahkan reboot sistem.

Suatu kali saya berpartisipasi dalam peningkatan sistem perbankan internet di salah satu bank terbesar di negara saya. Seluruh proses pemutakhiran situs web, tingkat menengah, dan basis data memakan waktu tiga hari di mana sistem offline untuk pelanggan. Ini juga termasuk cadangan penuh dari semuanya sehingga jika terjadi kegagalan sistem dapat dikembalikan ke versi lama.

— Ladislav Mrnka
sumber

2

Bukankah HTTP 503 (bukan 500) kode status yang benar untuk "down for maintenance"?

— Nubok

4

Server perlu patch untuk dijalankan, dan pada banyak sistem operasi, patch itu membutuhkan reboot. Jadi itu adalah salah satu kategori waktu henti. Banyak perusahaan menjadwalkan reboot dari patch untuk waktu penggunaan yang rendah, seperti Minggu pagi. Jika tidak ada tambalan, mereka tetap mem-boot ulang server pada waktu pemeliharaan yang dijadwalkan secara rutin (ini adalah hangover dari hari-hari NT4 ketika penghitung tertentu meluap setiap satu setengah minggu, jadi mem-boot ulang setiap minggu mencegah bug lain).

Satu perusahaan tempat saya bekerja memiliki situs e-commerce pada akhir 90-an yang menghasilkan lebih dari $ 1.000.000 dalam penjualan per bulan. Seseorang mempromosikan tabel pajak yang salah ke server database produksi. Obatnya adalah mengembalikan server db dari cadangan, dan menerapkan transaksi sejak cadangan terakhir. Ini memakan waktu beberapa jam, selama itu situs web tidak dapat menerima pesanan. Karena porsi pesanan dan brosur penjualan statis berjalan di situs yang sama dan tidak dapat dipisahkan, keduanya harus turun.

Satu perusahaan tempat saya bekerja memiliki beberapa teks yang salah dimasukkan ke tempat yang salah dan CEO membalik dan membuat situs web dihapus "untuk pemeliharaan" sementara tata letak dan teks "diperbaiki" dan korban yang tepat disalahkan dan dipecat.

— Tangurena
sumber

Bahkan ini dapat dikurangi dengan penyeimbangan muatan yang tepat

— Voycey

4

Meskipun jawaban lain benar, Anda hampir selalu dapat menghindari waktu henti menggunakan arsitektur yang benar. Tetapi ini memiliki biaya, dan biaya ini mungkin tidak sepadan: satu jam downtime biaya amazon atau infrastruktur di belakang banyak NASDAQ. Stackoverflow? Kemungkinan besar tidak begitu banyak.

Cara menghindari downtime:

mematikan halaman penyajian perangkat keras: jika Anda memiliki proxy di depan situs web Anda, Anda dapat menempatkannya offline tanpa dampak apa pun kepada pengguna
mengkonfigurasi ulang server: sama seperti di atas
memperbarui / mengubah data dalam basis data: Anda dapat menempatkan situs web Anda dalam mode hanya baca, dll ...

Secara umum, dalam arsitektur berlapis, semakin dekat ke "atas" Anda, semakin sulit untuk menghindari downtime, sama untuk stateful (webserver vs database).

— David Cournapeau
sumber

4

Bukankah NASDAQ memiliki waktu henti yang dijadwalkan sekitar 14 jam sehari?

— Peter Taylor

3

Suatu situs dapat menjadwalkan waktu henti yang teratur bahkan jika tidak ada yang dilakukan setiap kali waktu henti yang dijadwalkan tiba. Dengan melakukan itu, mereka membuat pengguna terbiasa dengan gagasan bahwa situs tersebut akan turun untuk waktu tertentu setiap kali sehingga ketika pekerjaan memang perlu dilakukan, pengguna tidak akan banyak mengeluh.

— Barry Brown
sumber

ada obat untuk itu: meruntuhkan sistem keluhan selama downtime :) Saya benar-benar melihat perusahaan melakukan itu. Sebuah perusahaan MMO yang menurunkan situs web yang memuat pengumuman penghentian waktu serta forum dukungan bersama dengan permainan yang sedang dimatikan untuk pemeliharaan adalah contoh yang bagus. Siapa pun yang tidak menangkap pengumuman selama beberapa jam itu sebelum pemeliharaan tidak akan pernah tahu apa yang sedang terjadi.

— jwenting

3

Ada juga sisi psikologis dan pemasaran untuk ini. Dalam beberapa kasus (saya berani mengatakan sebagian besar kasus tetapi saya tidak berani * g *) membaca "Down for maintenance" juga bisa berarti "Server macet atau keluar dari layanan karena alasan lain".

Saya sudah sering melihatnya. Biasanya sebagai pengembang Anda akan menginginkan pesan kesalahan "nyata" yang mengatakan sesuatu seperti "Whoops, kami mengalami beban yang tinggi sekarang dan tidak semua permintaan dapat ditangani" tetapi beberapa orang dari pemasaran akan memberi tahu Anda "bung, Anda tidak bisa beri tahu pelanggan bahwa kami mengalami masalah. Beri tahu mereka bahwa kami sedang dalam pemeliharaan terjadwal - ini akan terlihat jauh lebih baik ".

Jadi "Down for maintenance" seringkali hanyalah istilah lain untuk "out of service".

— perdian
sumber

2

Tidak perlu server untuk turun untuk pemeliharaan. Anda dapat menghindari melakukannya untuk apa pun, pada skala apa pun, perubahan DB, pembaruan server, dll.

Masalahnya adalah bahwa sistem 0-downtime, pada skala tertentu, sangat mahal untuk dibuat dan dikelola. Anda perlu redundansi di mana-mana, load balancing di mana-mana, replikasi data, sinkronisasi. Itu adalah masalah yang sulit.

Pada dasarnya Anda harus sampai pada level untuk dapat melepaskan Netflix Chaos Monkey di prod untuk memastikan itu berfungsi bahkan jika bagian dari sistem Anda sibuk dengan pembaruan, atau hanya tidak sinkron. Ini tentu bisa dilakukan. Ini juga sangat mahal, membutuhkan banyak waktu dan banyak ahli untuk mengatasi masalah tersebut.

Menempatkan situs pada mode pemeliharaan bisa menjadi jalan tengah yang Anda pilih, karena Anda tidak ingin berinvestasi sebanyak itu hanya untuk menghindari mencatat situs Anda sesekali.

Ekonomi.

Tentu saja, jika Anda memilih jalan waktu 0down, situs Anda akan memperoleh lebih dari sekadar ketersediaan, itu akan mendapatkan keandalan juga, karena praktik terbaik tersebut melayani kedua tujuan.

— e-satis
sumber

0

Saya tidak mengerti mengapa begitu banyak situs melakukannya, jika Anda melakukan pengembangan di server pengembangan, mengapa Anda harus mematikan situs produksi Anda?

Sial terjadi. Kecuali jika Anda melakukan beberapa bentuk verifikasi matematis dari kiriman Anda ( dan spesifikasi Anda valid ), tidak peduli seberapa hati Anda Anda, sial terjadi.

Juga, ada saat-saat ketika Anda mungkin harus melakukan perubahan pada bagian penting dari infrastruktur Anda (katakanlah, perubahan pada struktur basis data Anda) yang memang membutuhkan waktu henti.

Kecuali jika Anda mengembangkan sistem kritis (katakan sistem lima-sembilan atau enam-sembilan ), yang bertanggung jawab dan hemat biaya yang harus dilakukan adalah membangun sistem dengan penerimaan waktu henti sebagai bagian dari kenyataan.

Selain itu, Anda mengambil prinsip itu lebih jauh dengan membuat waktu yang dapat diatur dapat diatur dengan baik (atau setidaknya dapat dideteksi) dengan pemahaman dan prosedur yang jelas untuk pemulihan yang efektif.

— luis.espinal
sumber

1

Verifikasi matematika juga bukan obat mujarab; terkadang Anda menemukan bahwa apa yang Anda verifikasi bukan apa yang ingin Anda verifikasi.

— Donal Fellows

Benar. Tapi kemudian saya berpendapat bahwa masalahnya bukan pada verifikasi formal spesifikasi, tetapi dengan validasi spesifikasi tersebut. Jika spesifikasi Anda tidak valid, maka jelas semuanya akan berantakan dari sana, tetapi validasi spesifikasi ( "apakah kami benar-benar membangun hal yang benar yang diperlukan oleh pengguna yang dituju untuk tujuan yang dimaksudkan" ), itu bukan fokus verifikasi (* "diberikan spesifikasi ini, apakah kita membangun benda ini dengan benar, atau dapatkah itu dibangun? "), informal atau tidak. Saya kira saya harus meletakkan peringatan itu (wrt untuk validitas dari spesifikasi.)

— luis.espinal

Saya tidak berpendapat Anda salah untuk menyebutkannya. Saya hanya menunjukkan bahwa ada batasan untuk apa yang dapat dilakukannya. Saya dulu bekerja pada verifikasi formal, dan masalah besar pada saat itu adalah bagaimana mengembangkan spesifikasi dengan benar sehingga memperhitungkan perubahan pemahaman tentang persyaratan. Karena itu terutama masalah manusia, masalah teknis kedua, dan hanya masalah matematika, saya tidak membayangkan itu sudah diselesaikan sepenuhnya.

— Donal Fellows

Oh Saya pikir kita seperti berpikir. Mengubah persyaratan (dan validasi req.) Adalah tumit metode formal Achilles. Karena itu adalah tugas kreatif (karena sifat manusianya), saya tidak percaya itu dapat dipecahkan, tidak seperti yang diinginkan oleh formalis / puritan . Saya pikir itu telah menjadi salah satu janji gagal FM; mereka mendapat oversold (maksud saya, misalnya, metode formal untuk pengembangan web ?) Spesifikasi harus sangat diteliti dan tidak menerima perubahan cepat (dan itu tipikal sistem kritis, bukan yang sangat lunak). Yang belakangan adalah norma dan bukan pengecualian.

— luis.espinal

99% antarmuka pengguna tidak ada hubungannya dengan metode formal, melainkan psikologi terapan. Bukti yang tersisa jelas ("jangan deadlock UI") bahkan jika tidak selalu jelas untuk dibuktikan. Tetapi jika Anda telah memisahkan webapp menurut praktik terbaik, maka metode formal akan sangat masuk akal di lapisan metode bisnis (juga di lapisan penyimpanan data, tetapi biasanya di situlah saran standar “jangan menulis sendiri) DB ”tetap berlaku. :-))

— Donal Fellows

-2

Setelah situs web kami diretas (server IIS6 dan Windows 2003 beberapa tahun yang lalu). sementara kami mengerjakan restorasi, kami meletakkan halaman "sedang dalam pemeliharaan" selama beberapa jam ....

— serega
sumber