Pertanyaan Ada gagasan tentang cara menjalankan pemeliharaan di situs yang selalu digunakan?


Saya membantu dengan situs game besar di Australia. Kami menjalankan kompetisi dari jam 7 pagi waktu setempat hingga jam 1 pagi hari berikutnya, setiap hari dalam seminggu. Kami belum melewati hari sejak situs itu dirilis. Tentu, ini membuat pemeliharaan sangat sulit dijalankan, dan kami menemukan bahwa server pementasan kami hingga 50 komit di depan cabang produksi kami. Biasanya, dev utama harus bangun sangat awal untuk menggabungkan cabang dan memastikan semuanya berfungsi dengan baik.

Kami telah mencoba membuat situs pementasan kami seakurat mungkin ke situs produksi, tetapi kami hanya dapat membuatnya sangat mirip.

Situs kami didasarkan pada Laravel dengan server Node.JS untuk realtime. Kami menggunakan Laravel Forge.

Adakah yang punya saran tentang cara mendorong pembaruan lebih sering? Kami terbuka untuk apa pun.


18
2017-11-28 06:39




Mengapa penyebaran memakan waktu lama? - Michael Hampton♦
@MichaelHampton Pendistribusian kami tidak butuh waktu lama, hanya saja kami tidak dapat membayar downtime jika ada yang salah. - cheese5505
Saya kira pertanyaannya, kemudian, adalah: Mengapa rollback memakan waktu begitu lama? - Michael Hampton♦
@MichaelHampton kami belum melihat rollback dengan benar, namun pada saat kami melakukan pembaruan besar yang akan membuat situs terputus terlalu lama. - cheese5505
Apa pun yang mengambil blok besar waktu, itulah yang perlu Anda perhatikan. - Michael Hampton♦


Jawaban:


Ada banyak hal yang dapat Anda lakukan untuk meningkatkan proses penerapan Anda. Beberapa diantaranya adalah:

  • Pastikan kode Anda teruji dengan baik.

    Idealnya Anda harus memiliki cakupan uji unit 100%, serta pengujian integrasi untuk setiap skenario yang mungkin.

    Jika Anda belum mendapatkan ini, Anda mungkin harus menghentikan semuanya dan mendapatkan perawatan ini.

    Lihatlah perkembangan yang didorong oleh perilaku.

    Memiliki rangkaian uji lengkap akan memungkinkan Anda untuk ...

  • Jalankan integrasi berkelanjutan.

    Kapanpun seseorang melakukan perubahan, CI bisa secara otomatis jalankan test suite di atasnya. Jika rangkaian uji lolos, maka dapat segera diterapkan (atau menjadwalkan penempatan). Untuk perubahan yang tidak memerlukan perubahan signifikan pada basis data Anda, ini saja akan menghemat banyak waktu dan sakit kepala.

    Jika ada masalah, CI juga dapat memberi Anda rollback satu klik.

    CI banyak kurang bermanfaat jika rangkaian uji Anda tidak lengkap dan benar, karena seluruh premis bertumpu pada kemampuan memvalidasi kode Anda dengan cara otomatis.

  • Buat pembaruan atom.

    Idealnya Anda tidak boleh hanya menyalin file baru di atas yang lama di server produksi. Sebagai gantinya, gunakan alat seperti capistrano, yang menyalin setiap file ke lokasi baru, dan kemudian menggunakan tautan simbolis untuk menunjuk ke penerapan yang diinginkan. Mengembalikannya seketika karena melibatkan hanya mengubah symlink untuk menunjuk ke penyebaran sebelumnya. (Meskipun ini tidak selalu mencakup migrasi basis data Anda.)

    Lihat juga apakah kontainer seperti Docker dapat membantu Anda.

  • Buat perubahan yang lebih kecil dan lebih sering.

    Apakah Anda memiliki tes, CI, atau tidak sama sekali, ini saja dapat membantu Anda secara signifikan. Setiap perubahan harus memiliki cabang gitnya sendiri, dan penempatan harus memiliki sedikit perubahan. Karena perubahan lebih kecil, ada lebih sedikit yang berpotensi salah selama penempatan.

    Pada catatan itu, buat perubahan lebih terisolasi bila memungkinkan. Jika Anda telah membuat perubahan ke permainan Omaha, dan itu tidak mempengaruhi Texas Hold'em, 5 kartu stud atau apa pun, maka itu adalah satu-satunya game yang perlu ditangguhkan untuk pemeliharaan.

  • Analisis apa saja yang sudah lama berjalan.

    Anda menyebutkan beberapa bagian dari penerapan Anda membutuhkan waktu lama. Ini adalah mungkin perubahan skema database. Sebaiknya lihat DBA di database Anda, bersama dengan setiap perubahan skema, untuk melihat apa yang dapat berkinerja lebih baik.

    Mintalah seorang ahli mata pelajaran untuk melihat bagian lain dari penyebaran yang menghabiskan banyak waktu.

  • Bekerja dengan jam kerja yang aneh.

    Anda mungkin sudah melakukan ini, tetapi hal itu disebutkan. Pengembang (dan sysadmins!) Seharusnya tidak diharapkan untuk bekerja "9 hingga 5" lagi, terutama untuk operasi 24x7. Jika seseorang diharapkan menghabiskan berjam-jam semalam menjaga penempatan, memperbaiki masalah, dan kemudian membuat jadwal siang hari, harapan Anda tidak realistis, dan Anda menetapkan orang itu untuk kelelahan.


22
2017-11-28 07:55



Solusi paling sederhana di sini adalah menggunakan scripting penyebaran dalam alat seperti Capistrano dan mungkin bahkan melakukan load balancing juga. - JakeGould
Terima kasih atas sarannya. Kami akan melihat ini. Saat ini kami tidak memiliki test suite sama sekali, dan saya benar-benar ingin melihat ke dalamnya, namun situs ini telah dikembangkan selama lebih dari 8 bulan dan sangat besar akan membutuhkan lebih dari satu minggu untuk membuatnya. Kami menjalankan Laravel Forge yang hanya symlink versi baru ke folder yang nginx sudah siapkan. Saya tidak dapat bekerja di jam-jam aneh karena sekolah, dan hal yang sama berlaku untuk dev lainnya. - cheese5505
@ cheese5505 Saya tahu ini membuat frustrasi dan ini tidak menyelesaikan masalah Anda tetapi ketika Anda mengatakan ini, "... sangat besar butuh lebih dari satu minggu untuk membuatnya." yang tampaknya sangat konyol. Setiap pengembangan dan penyebaran proses yang waras akan memungkinkan server untuk dibangun dalam waktu kurang dari satu hari atau mungkin beberapa jam hingga satu jam. Anda harus benar-benar meninjau apa yang Anda lakukan untuk membangun tumpukan barang yang tidak terkendali ini untuk menghindari hal ini. Masalahnya bukan kompleksitas tetapi kejelian dasar dalam perencanaan. - JakeGould
"Saat ini kami tidak memiliki test suite sama sekali" - perbaiki ini sekarang, sebelum mengembangkan fitur baru. Ini adalah titik nyeri terbesar Anda dan akan menjadi risiko ketersediaan. Pengujian otomatis akan sangat membantu mencegah pemadaman dan akan mengurangi nyeri ops secara signifikan. - Josh


Sepertinya dari apa yang Anda katakan bahwa Anda memiliki jendela pemeliharaan dari jam 1 pagi hingga 7 pagi setiap hari masalahnya bukanlah waktu tetapi kenyamanan. Ini normal dan banyak orang hanya menanganinya sebagai bagian dari bisnis.

Anda bisa memiliki sistem 2 (atau lebih backend) dengan front end yang mengarahkan lalu lintas ke mana pun yang saat ini tinggal. Setelah Anda senang bahwa rilis akan bekerja Anda memberi tahu bagian depan untuk beralih ke sistem baru. ini harus mudah untuk skrip yang membutuhkan waktu yang singkat.

Sekarang Anda memiliki pilihan untuk meninggalkan sistem lama sehingga Anda dapat kembali atau memperbaruinya sehingga dapat digunakan sebagai cadangan untuk sistem siaran langsung sampai saatnya untuk membuat / menguji pembaruan berikutnya.


6
2017-11-28 07:24



Ketika Anda membedakan backend dari frontend, maksud Anda arsitektur perangkat lunak modular sepenuhnya? Atau arsitektur server seperti penyeimbang beban? - JakeGould
hanya sesuatu yang menerima koneksi dan mengantarkannya ke backend primer saat ini. - Iain


Mengubah jawaban lain: Anda harus mengikuti model penyebaran biru-hijau. Ketika Anda ingin merilis versi baru, Anda menyebarkannya ke situs web pementasan internal. Kemudian, Anda dapat menjalankan tes otomatis di situs produksi versi berikutnya. Ketika tes melewati Anda, arahkan penyeimbang beban untuk menggunakan situs web baru.

Ini membantu dengan cara berikut:

  1. Masalah yang parah selalu ditemukan tanpa downtime nol.
  2. Beralih ke versi baru benar-benar nol downtime karena versi baru sudah dimulai dan dihangatkan.
  3. Anda dapat kembali ke versi lama kapan saja karena masih berjalan secara fisik.

Semua masalah lain yang Anda dan orang lain telah sebutkan menjadi kurang parah ketika Anda dapat menerapkannya kapan saja dengan cara yang bebas stres. Model penyebaran biru-hijau adalah solusi yang cukup lengkap untuk masalah penyebaran.


5
2017-11-28 13:06



Kami sudah memiliki server pementasan yang kami gunakan untuk menguji, tetapi pada saat ini produksi dan pementasan berada di server penyedia yang berbeda di lokasi yang berbeda. Kami mencoba memindahkan produksi ke tempat pementasan karena memberikan kinerja yang lebih baik bagi kami. - cheese5505
Kuncinya adalah hanya perlu mengganti load balancer ke versi kerja yang terbukti. Dengan model saat ini, Anda tidak memilikinya. - usr
Seberapa baik model ini sangat tergantung pada apa yang dilakukan situs. Jika situs ini tidak memiliki status hukum maka bagus, tetapi jika tidak bernegara Anda harus mengetahui bagaimana Anda akan berpindah keadaan itu pada peralihan. - Peter Green
@PeterGreen sangat sulit untuk situs web menjadi stateful karena itu tidak memungkinkan untuk pengelompokan dan negara dapat hilang kapan saja di redeployment / reboot / crash / bluescreen dll. Oleh karena itu, ini sangat tidak biasa. - usr
@usr sebagian besar situs web memiliki status. Keadaan itu dapat disimpan baik dalam file atau dalam database. Dalam kasus terakhir, basis data dapat berupa lokal atau jarak jauh. Beberapa pemutakhiran cenderung berdampak pada status yang berarti peningkatan dan rollback tidak sesederhana hanya dengan mengalihkan kode. - Peter Green


Apa yang akan Anda lakukan jika pusat data utama Anda mengalami gangguan, yang terjadi di semua pusat data dari waktu ke waktu? Anda mungkin menerima downtime, Anda mungkin gagal ke pusat data lain, Anda mungkin berjalan dalam mode aktif-aktif di beberapa pusat data sepanjang waktu, atau Anda mungkin memiliki beberapa rencana lain. Apapun itu, lakukan ketika Anda melakukan rilis, dan kemudian Anda dapat mengambil pusat data utama Anda selama rilis. Jika Anda siap untuk memiliki downtime ketika pusat data Anda memiliki gangguan, maka Anda siap untuk memiliki waktu henti, jadi seharusnya tidak menjadi masalah selama rilis.


3
2017-11-28 08:24





Untuk menambah jawaban sebelumnya:

  • Gunakan strategi penyebaran yang memungkinkan untuk rollback dan switching instan, Capistrano atau cukup banyak sistem penyebaran lainnya akan membantu dengan ini. Anda bisa menggunakan hal-hal seperti snapshot database dan kode symlink untuk dapat dengan cepat kembali ke keadaan sebelumnya.

  • Gunakan manajemen konfigurasi yang lengkap, jangan tinggalkan apa pun yang dikelola secara manual. Sistem seperti SaltStack, Ansible, dan Wayang adalah contoh. Mereka dapat diterapkan untuk konfigurasi kontainer Docker dan kotak gelandangan juga.

  • Gunakan HA untuk memastikan Anda dapat memberikan permintaan saat meningkatkan node. Jika pemutakhiran gagal, cukup turun node, dan ketika itu dibatalkan, bawa kembali dan solusi HA Anda akan melihat dan mendorong permintaan ke simpul tersebut lagi. HAProxy adalah contoh, tetapi nginx juga berfungsi dengan baik.

  • Pastikan aplikasi dapat menangani instance konkuren, menggunakan repositori data berversi terpusat untuk data non-kode yang perlu disimpan pada disk, seperti cache. Dengan cara ini, Anda tidak akan pernah memiliki aplikasi yang ditingkatkan untuk menjalankan file cache dari versi yang berbeda. Ini akan dilakukan di atas membersihkan cache dan melakukan pemanasan cache tentu saja. (Hal caching hanyalah sebuah contoh)

Saya biasanya mengatur alur kerja di mana manajer tim dapat menyetujui permintaan gabungan ke cabang khusus yang melakukan semua hal CI normal, tetapi sebagai langkah terakhir tambahan juga mulai mendorong ke simpul produksi. Apa yang pada dasarnya Anda lakukan adalah menjalankan CI manual yang disebarkan ke instance produksi. Jika instance tersebut tidak menghasilkan respons yang tidak valid, rusak, atau melakukan hal-hal aneh pada data Anda, Anda kemudian meningkatkan semua node secara massal menggunakan solusi pilihan CI Anda. Dengan cara ini, jika satu penerapan berfungsi, Anda tahu semua penerapan akan berfungsi untuk tag / komitmen tertentu.

Saat ini, sepertinya Anda menjalankan aplikasi produksi pada satu node, dengan satu proses penyebaran, satu sumber dan satu target. Ini secara praktis berarti bahwa setiap langkah dalam alur kerja itu adalah titik kegagalan yang dengan sendirinya dapat merusak situs web. Memastikan bahwa hal semacam itu tidak dapat terjadi adalah dasar dari semua proses CI, HA, dan failover. Jangan hanya menjalankan satu node, jangan jalankan hanya satu proses HA, jangan jalankan hanya pada satu alamat IP, jangan jalankan hanya satu CDN dll. Mungkin terdengar mahal, tetapi menempatkan duplikat dari apa yang sudah Anda miliki di rak di server dengan koneksi sendiri biasanya biaya kurang dari satu jam downtime di situs bisnis.


2
2017-11-29 04:12





Saya secara global setuju dengan Michael pada setiap poinnya (https://serverfault.com/a/739449/309477).

Menurut pendapat saya, peningkatan pertama yang harus Anda lakukan adalah menggunakan alat penyebaran (Capistrano).

Ini akan memungkinkan Anda untuk menyebarkan secara damai, lalu beralih ke versi yang lebih baru secara instan. Jika ada yang salah, Anda dapat kembali ke versi kerja langsung, cukup dengan mengubah symlink saat ini ke versi yang berfungsi.

Dan Capistrano cukup cepat untuk menangani pertama (dibandingkan dengan mulai menggunakan tes dan CI yang akan menjadi investasi waktu yang lebih besar).

Kedua, jika uang bukan milik Anda utama masalah, Anda harus memiliki server pengembangan iso-prod untuk menguji aplikasi Anda sebelum menerapkannya dalam produksi. Gunakan sebuah industri solusi (Ansible, Chef, Wayang) untuk mengelola instance VPS.


0
2017-12-04 10:31