Memahami masalah ketika hal-hal pecah dalam produksi

24

Skenario:

Anda mendorong produksi
Dorongan itu menghancurkan banyak hal
Bangunan yang sama itu tidak merusak qa atau dev
Sebagai pengembang, Anda tidak memiliki akses prod.
Ada banyak tekanan dari atas untuk membuat semuanya berjalan dengan baik.

Spesifik:

Aplikasi PHP / MVC yang digerakkan oleh API di Zend.
Dikerahkan ke beberapa server.

Pertanyaan saya:

Saat menyelidiki, katakanlah saya punya firasat bahwa ada sesuatu yang salah. Tapi, saya tidak tahu pasti. Dan, tentu saja, saya tidak dapat menguji berbagai hal dalam produksi. Jika saya memiliki saran perbaikan berdasarkan firasat itu, akankah bijaksana untuk mencoba dan menerapkannya dan melihat apakah itu berhasil, sebelum memahami apa masalahnya?

bug production

— bitcycle
sumber

24

Jika tidak merusak DEV atau QA, tetapi merusak produksi, biasanya masalah konfigurasi.

— Mike L.

4

Meskipun Anda mungkin tidak secara pribadi memiliki akses ke produksi, Anda harus memiliki anggota tim operasi yang dapat menjadi mata dan tangan Anda untuk memecahkan masalah.

— shufler

3

Sudahkah Anda mengesampingkan masalah konfigurasi, mis. Akses basis data atau izin jaringan yang dapat digunakan dalam versi baru?

— JB King

7

@MikeL. Atau data korup yang tidak ada di dev atau QA.

— maple_shaft

3

@shufler - Di AS, Sarbanes – Oxley Act (alias SOX) mensyaratkan bahwa pengembang tidak memiliki akses ke produksi di perusahaan publik. Beberapa perusahaan memiliki kebijakan internal mereka sendiri yang membatasi akses. Ini biasanya mulai berlaku setelah pengembang menjatuhkan seluruh sistem berdasarkan firasat.

— jfrankcarr

33

Ambil sebanyak mungkin informasi tentang masalah yang Anda bisa (logfile dll.) Lalu kembalikan server produksi ke kondisi kerja. Tentu saja itu menyusahkan dari sudut pandang pengembang, tetapi kemungkinan besar diberikan.

Selanjutnya, coba dan lihat apakah Anda dapat mereproduksi masalah di lingkungan pengembangan. Jika Anda bisa, perbaiki dan coba lepaskan lagi.

Jika Anda tidak dapat mereproduksinya, lihat apakah Anda dapat menambahkan lebih banyak diagnostik dan lepaskan ke satu server untuk waktu yang singkat untuk mendapatkan informasi lebih lanjut tentang masalah tersebut.

Jika itu tidak mungkin maka lihat lebih dekat perbedaan antara produksi dan lingkungan dev / qa dan cobalah untuk membuat lingkungan dev lebih dekat dengan produksi.

— Chris Card
sumber

4

Seberapa baik Anda memahami masalahnya? Apa risiko bahwa firasat Anda akan memperburuk keadaan? Apakah mungkin untuk kembali dan mereproduksi masalah di wilayah DEV / QA? Apa yang dapat Anda lakukan untuk menyinkronkan wilayah DEV / QA Anda agar lebih dekat dengan PROD? Mungkin Anda harus mengubah beberapa pengaturan lingkungan atau basis data, mungkin Anda harus mengimpor data PROD ke DEV, mungkin Anda harus mengubah beberapa pengaturan debug.

Secara umum, saya tidak akan merekomendasikan mendorong firasat Anda solusi untuk PROD kecuali Anda dapat mengkonfirmasi bahwa itu memang benar di wilayah lain. Saya memahami jenis masalah yang muncul ketika bug terjadi di PROD dan tidak dapat direproduksi di tempat lain. Saat itulah turun untuk melihat apa lagi yang berbeda antara DEV / QA dan PROD dan fokus pada mereka. Dalam pengalaman saya, biasanya pengaturan lingkungan atau konfigurasi yang berbeda, khususnya untuk PROD. Dan saya tahu bahwa mungkin ada banyak tekanan dari atas untuk memperbaikinya, jadi mungkinkah untuk kembali ke kondisi kerja sebelumnya dan kemudian mencoba mereproduksi masalah di DEV, menghasilkan perbaikan di DEV, dan kemudian mencoba lagi di PROD? Itu yang saya sarankan.

— FrustratedWithFormsDesigner
sumber

5

Anda pasti tidak ingin menerapkan perbaikan pada produk rusak yang Anda tidak tahu pasti akan memperbaikinya; yang kemungkinan besar hanya akan merusaknya! Lebih baik kembali ke keadaan stabil dan bekerja di QA di mana ada sedikit tekanan untuk memperbaikinya pertama kali dan satu-satunya.

— Michael K

2

Tergantung pada jenis perbaikannya. Lebih sering daripada tidak, masalah dalam produksi yang tidak muncul di dev terkait dengan bersaing dalam database. Jadi menerapkan bug yang mengubah konten basis data tanpa yakin apa yang sebenarnya "di luar sana" mungkin merupakan langkah pertama dalam bencana besar. Jika Anda dapat dengan mudah mengembalikannya, Anda mungkin dapat mencoba-coba. Tetapi secara umum, jika Anda tidak memiliki akses langsung, setidaknya harus ada salinan dari database atau seluruh server untuk pengujian. Orang dengan hak yang tepat masih harus menjalankan kode baru, tetapi setidaknya tanpa risiko kehilangan data. (Tapi kadang-kadang ukuran database atau kompleksitas infrastruktur melarang pengaturan seperti itu)

Ini sangat sulit, karena ada banyak kemungkinan seperti pengaturan yang berbeda, perpustakaan dan versi perangkat lunak.

Mungkin Anda dapat menulis sepotong kode terlebih dahulu yang mengevaluasi dengan beberapa hasil debug jika tebakan Anda untuk sumber bug benar dan baru kemudian menerapkan perbaikan bug yang sebenarnya.

— thorsten müller
sumber

1

Biasanya itu adalah masalah konfigurasi atau data, dengan asumsi bahwa kode dan DB identik antara Prod, QA, dan dev.

Pertama-tama saya akan melihat yang berikut ini:

Data logging apa pun yang dimiliki kode Anda.
Periksa penampil acara untuk pengecualian yang tidak ditangani.
Periksa data yang mewakili kemajuan aplikasi Anda, bisa dalam DB, file, dll. Apakah masuk akal atau tidak? Apa yang kamu harapkan?

Setelah Anda memahami apa yang sedang terjadi, Anda harus mengembalikan produksi ke kondisi kerja dan memperbaiki masalah di lingkungan yang lebih rendah, hingga diperbaiki dan digunakan kembali untuk produksi.

— Hidup lebih dari ini
sumber

0

Meskipun lingkungan Anda adalah PHP, saya telah melakukan presentasi tentang bagaimana cara memikirkannya untuk Java: http://www.infoq.com/presentations/maintaining-production-java-apps

Masalah intinya sama - untuk memahami kemungkinan titik tersedak untuk memecahkan masalah situasi: jaringan, akses sistem file, file log, deadlock, dll. Juga, untuk mengetahui cara mengajukan pertanyaan yang tepat: "Sistem mati" - "Apa yang Anda lakukan secara khusus?" berarti: Apakah halaman web lambat, apakah ada pesan kesalahan khusus, apakah ada batas waktu ", dll.

Plus ada beberapa alat untuk mempermudah pemecahan masalah: Wireshark untuk pemecahan masalah jaringan adalah yang terbaik dan patut dipelajari. Lainnya bergantung pada O / S yang Anda gunakan. Untuk Windows, apa pun dari SysInternal (sekarang bagian dari Microsoft) sangat brilian. Untuk Unix / Linux, lihat truss / strace.

Pada akses ke produksi, kelompok operasi harus tahu cara menggunakan alat / teknik tersebut atau Anda memiliki kasus bisnis untuk mereka (bersama Anda) untuk belajar cara menggunakannya. Setelah itu, mereka membutuhkan seperangkat protokol pemecahan masalah khusus untuk dijalankan ketika masalah terjadi, sehingga Anda dapat melakukan analisis secara offline.

— Alexandre Rafalovitch
sumber

0

Jawaban singkat: Tidak jika Anda punya pilihan.

Jawaban panjang: Jika Anda tidak memahami masalahnya, ada beberapa risiko yang terlibat dalam tambalan tersebut:

Anda dapat merusak sesuatu yang lain, yang bahkan bisa jadi kurang dapat direproduksi.
Anda bisa menutupi masalah, membuatnya lebih sulit untuk diperhatikan dan diperbanyak (yang membuatnya lebih buruk)
Anda membuang pengalaman domestik yang potensial - pengalaman yang bisa menjadikan Anda seorang programmer yang lebih baik, dan pada saat yang sama lebih berharga bagi perusahaan Anda (yaitu potensi kenaikan di masa depan).

Di sisi lain, saya melihat tidak ada salahnya memeriksa terlebih dahulu apakah perbaikan hipotesis Anda berfungsi, dan jika benar - maka gali lebih dalam dan temukan alasan sebenarnya atau cara lain yang lebih baik untuk menyelesaikan masalah.

— Yam Marcovic
sumber