Bagaimana [dengan sopan?] Memberi tahu vendor perangkat lunak bahwa mereka tidak tahu apa yang mereka bicarakan

Bukan pertanyaan teknis, tetapi yang valid tetap. Skenario:

HP ProLiant DL380 Gen 8 dengan CPU 2 x 8-core Xeon E5-2667 dan RAM 256GB yang menjalankan ESXi 5.5. Delapan VM untuk sistem vendor yang diberikan. Empat VM untuk pengujian, empat VM untuk produksi. Keempat server di setiap lingkungan melakukan fungsi yang berbeda, misalnya: server web, server aplikasi utama, server OLAP DB dan server SQL DB.

CPU share dikonfigurasikan untuk menghentikan lingkungan pengujian agar tidak memengaruhi produksi. Semua penyimpanan di SAN.

Kami telah memiliki beberapa pertanyaan tentang kinerja, dan vendor bersikeras bahwa kami perlu memberikan lebih banyak memori dan vCPU sistem produksi. Namun, kita dapat dengan jelas melihat dari vCenter bahwa alokasi yang ada tidak disentuh, misalnya: tampilan bulanan pemanfaatan CPU pada server aplikasi utama berkisar sekitar 8%, dengan lonjakan ganjil hingga 30%. Paku-paku tersebut cenderung bertepatan dengan perangkat lunak cadangan yang mulai berdatangan.

Kisah serupa tentang RAM - angka pemanfaatan tertinggi di seluruh server adalah ~ 35%.

Jadi, kami telah melakukan penggalian, menggunakan Process Monitor (Microsoft SysInternals) dan Wireshark, dan rekomendasi kami kepada vendor adalah bahwa mereka melakukan beberapa penyetelan TNS pada contoh pertama. Namun, ini tidak penting.

Pertanyaan saya adalah: bagaimana kita membuat mereka mengakui bahwa statistik VMware yang telah kita kirim cukup bukti sehingga lebih banyak RAM / vCPU tidak akan membantu?

--- PEMBARUAN 12/07/2014 ---

Minggu yang menarik. Manajemen TI kami telah mengatakan bahwa kami harus melakukan perubahan pada alokasi VM, dan kami sekarang sedang menunggu waktu henti dari para pengguna bisnis. Anehnya, para pengguna bisnis adalah orang-orang yang mengatakan bahwa aspek-aspek tertentu dari aplikasi berjalan lambat (dibandingkan dengan apa, saya tidak tahu), tetapi mereka akan "beri tahu kami" ketika kami dapat menurunkan sistem (menggerutu) , menggerutu!).

Sebagai tambahan, aspek "lambat" dari sistem tampaknya bukan elemen HTTP (S), yaitu: "aplikasi tipis" yang digunakan oleh sebagian besar pengguna. Kedengarannya seperti instalasi "klien besar", yang digunakan oleh badan keuangan utama, yang tampaknya "lambat". Ini berarti bahwa kami sekarang mempertimbangkan interaksi klien dan server-klien dalam penyelidikan kami.

Karena tujuan awal dari pertanyaan ini adalah untuk mencari bantuan apakah akan turun rute "menyodok", atau hanya membuat perubahan, dan kami sekarang membuat perubahan, saya akan menutupnya menggunakan jawaban longneck .

Terima kasih atas masukan Anda; seperti biasa, serverfault lebih dari sekedar forum - itu seperti sofa psikolog juga :-)

Saya sarankan Anda melakukan penyesuaian yang mereka minta. Kemudian membandingkan kinerja untuk menunjukkan kepada mereka bahwa itu tidak ada bedanya. Anda bahkan bisa melangkah lebih jauh dengan membandingkannya dengan memori KURANG dan vCPU untuk menegaskan maksud Anda.

Juga, "Kami membayar Anda untuk mendukung perangkat lunak dengan solusi aktual, bukan menebak."

Memberikan Anda yakin Anda berada dalam spesifikasi sistem yang diberikan mereka mendokumentasikan.

Maka setiap klaim yang mereka buat sehubungan dengan membutuhkan lebih banyak RAM atau CPU mereka harus dapat membuat cadangan. Sebagai ahli dalam sistem mereka, saya meminta orang untuk bertanggung jawab atas hal ini.

Tanya mereka secara spesifik.

• Informasi apa yang diberikan pada sistem menunjukkan lebih banyak RAM diperlukan dan bagaimana Anda menafsirkan ini?

• Informasi apa yang diberikan pada sistem menunjukkan lebih banyak CPU diperlukan dan bagaimana Anda menafsirkan ini?

• Data yang saya miliki - sekilas - bertentangan dengan apa yang Anda katakan kepada saya. Bisakah Anda menjelaskan kepada saya mengapa saya bisa menafsirkan ini dengan tidak benar?

• Saya menafsirkan ini [seri data yang jelas] berarti [interpretasi yang jelas]. Bisakah Anda mengonfirmasi bahwa saya menafsirkannya dengan benar terkait masalah saya?

Setelah berurusan dengan dukungan di masa lalu saya telah mengajukan pertanyaan yang sama. Kadang-kadang saya benar dan mereka tidak memusatkan perhatian mereka pada masalah saya dengan benar. Namun di lain waktu, saya salah dan saya menafsirkan data secara tidak benar, atau gagal memasukkan data lain yang penting dalam analisis saya.

Bagaimanapun, kedua situasi ini adalah keuntungan bersih bagi saya, baik saya belajar sesuatu yang baru saya tidak tahu sebelumnya - atau saya punya tim pendukung mereka untuk berpikir lebih keras tentang masalah saya untuk mendapatkan akar penyebab yang layak.

Jika tim pendukung tidak dapat memberikan Anda perluasan logis dari argumen mereka ke dasar yang dapat Anda puasi (Anda harus memiliki pikiran terbuka untuk kompromi diri sendiri, masuk akal untuk menerima interpretasi Anda tentang data yang salah) maka itu harus menjadi sangat hadir dalam tanggapan mereka. Bahkan dalam skenario terburuk Anda dapat menggunakan ini sebagai dasar untuk meningkatkan masalah.

Hal besar adalah untuk dapat membuktikan bahwa Anda menggunakan praktik terbaik untuk alokasi sistem Anda, terutama pemesanan RAM dan CPU untuk server SQL Anda.

Semua ini dikatakan yang paling mudah adalah membuat penyesuaian yang diminta, setidaknya untuk sementara. Jika tidak ada yang lain, hal itu cenderung membuat vendor terseret. Saya tidak dapat menghitung berapa kali saya perlu melakukan sesuatu yang gila seperti ini untuk memuaskan teknologi di ujung lain bahwa sebenarnya perangkat lunak mereka tidak berperilaku.

Untuk situasi khusus ini (di mana Anda memiliki VMware dan pengembang aplikasi atau pihak ketiga yang tidak memahami alokasi sumber daya), saya menggunakan metrik senilai satu minggu yang diperoleh dari vCenter Operations Manager (vCops - unduh demo jika diperlukan ) untuk menunjukkan kendala sebenarnya , hambatan dan persyaratan ukuran VM aplikasi.

Kadang-kadang, saya bisa memuaskan konsumen yang lebih keras kepala dengan memodifikasi reservasi VM atau mengubah prioritas untuk menangani skenario pertikaian; " Jika RAM | CPU ketat, VM ANDA akan diutamakan! " Hal-hal buruk telah terjadi ketika saya mengizinkan vendor perangkat lunak mendikte kebutuhan mereka pada kluster vSphere saya tanpa analisis nyata .

Namun secara umum, angka dan data harus menang.

Contoh dari sesuatu yang saya gunakan untuk membenarkan ukuran VM untuk pengembang aplikasi Tomcat:

Dev : VM membutuhkan MOAR cpu!

Saya : Ya, memori adalah kendala terbesar Anda, dan inilah peta panas kinerja Anda versus waktu ... Rabu pukul 18:00 adalah periode yang paling menegangkan, jadi kami dapat menentukan sekitar periode puncak itu. Oh, dan inilah rekomendasi ukuran berdasarkan 6 minggu terakhir metrik produksi ...

Saya dulu bekerja dalam dukungan - dan bagian dari apa yang Anda minta terdengar sangat rasional (dan mungkin memang): tetapi ada beberapa pertanyaan untuk ditanyakan kepada diri Anda sendiri sebelum hanya melakukan "peningkatan kinerja" yang mereka minta

• Apakah Anda menjalankan setidaknya pada persyaratan sistem minimum yang dinyatakan vendor?
• jika Anda setidaknya pada sysreqs minimum, apakah Anda sudah pada pengaturan sistem "direkomendasikan" mereka?

Vendor akan 99 kali dari 100 (dalam pengalaman saya - baik di sisi dukungan dan pelanggan / sisi lapangan) bahkan tidak berurusan dengan masalah terkait kinerja sampai / kecuali sistem cocok dengan apa yang diminta oleh dokumentasi mereka. Mungkin itu adalah sistem yang bekerja dengan baik 99,5% dari waktu dengan 1 CPU dan RAM 512M - tetapi jika persyaratan sistem mengatakan 4 CPU dan RAM 4G dan Anda hanya punya 2 CPU dan 1G RAM, mereka baik dalam hak mereka untuk menuntut lebih banyak sumber daya ditugaskan ^* .

Mungkin mereka meminta Anda untuk menambah sumber daya sistem karena sesuatu yang mereka temukan di lab / pengembangan di mana masalah secara ajaib menghilang jika Anda melewati ambang tertentu; jika ini masalahnya, ya itu adalah contoh dari debugging yang berpotensi buruk pada akhirnya, tetapi perlu diingat mereka tidak punya waktu untuk menghilangkan setiap kemungkinan bug / masalah yang muncul - beberapa hanya perlu ditangani, dan jika itu yang terjadi di sini, ikuti saja.

Ada juga kemungkinan yang tidak signifikan bahwa masalah yang Anda lihat bahkan bukan bagian dari perangkat lunak "mereka", tetapi komponen yang mereka andalkan dari sumber lain (vendor, pustaka OSS, dll). Saya mengalami situasi yang tepat terkait dengan ukuran swap, BEA WebLogic, dan Sun JRE di pelanggan beberapa tahun yang lalu.

tl; dr:

Singkatnya, bekerja dengan tim dukungan mereka, meningkat sesuai kebutuhan, sampai Anda menemukan resolusi - tetapi jangan kaget ketika beberapa saran / langkah debugging / perbaikan terdengar off-the-wall atau tidak berguna.

^{* _{Jika benar - benar tidak "memerlukan" sumber daya tambahan itu, Anda mungkin berada di tempat untuk dapat mengajukan bug bug / RFE untuk versi masa depan - tetapi jangan memaksakan rute itu sampai Anda menunjukkan bahwa itu bukan masalah yang dihadapi}
^ _{eBuku yang saya tulis mungkin bermanfaat bagi Anda pada topik: Debugging dan Sistem Perangkat Lunak Pendukung}}

Entah meminta untuk meningkatkan tiket atau meminta perwakilan yang berbeda. Bergantung pada vendor mana itu eskalasi dapat membantu jika Anda mengatakan bahwa Anda merasa tingkat dukungan saat ini tidak cukup untuk mengatasi masalah tersebut. Jika mereka tidak akan meningkat maka meminta perwakilan yang berbeda dapat membantu karena memerlukan jauh lebih sedikit "pembenaran" karena semua yang dibutuhkan adalah untuk tidak senang dengan yang sekarang.

Jika itu adalah vendor besar maka cukup menutup tiket dan membuka yang baru pada masalah yang sama mungkin berhasil karena dapat dialihkan ke perwakilan yang berbeda, tetapi saya akan menyarankan untuk tidak melakukannya karena ini bentuk yang buruk.

Anda juga bisa bertahan dan meminta alasan untuk berapa banyak RAM / vCPU akan membantu, atau Anda bisa memberikan lebih banyak RAM / vCPU untuk membuktikan bahwa itu tidak akan membantu.

Saya akan membuang dua sen saya. Kami telah cukup berhasil dengan pendekatan ini - hasil yang jauh lebih baik dan lebih sedikit frustrasi di pihak semua orang. Ini membutuhkan lebih banyak upaya daripada permainan menyalahkan dan menambahkan sumber daya secara membabi buta, tetapi juga memiliki peluang yang lebih baik untuk menemukan masalah yang mendasarinya.

Ketika kami memiliki masalah serius dengan aplikasi di tempat kami yang didukung oleh kontrak dukungan vendor, dan vendor memulai tarian penghindaran menghindar (yang sepertinya selalu mencakup permintaan non-data-driven untuk CPU atau RAM), kami cenderung lakukan 3 hal ini:

1. Tingkatkan prioritas ke sistem yang setara - mereka biasanya menolak, tetapi biasanya mundur ketika Anda menjelaskannya secara efektif tidak dapat digunakan walaupun secara teknis "berfungsi". Perlakukan itu sebagai masalah serius bagi mereka untuk dipecahkan. Di sini kita menyebutnya sebagai tim harimau, yang bertemu setiap hari untuk mendapatkan pembaruan status dari semua pemangku kepentingan. Biasanya vendor akan meminta Anda untuk mengubah barang. Jika itu adalah sistem prod, itu bermasalah, tetapi jika Anda ingin mereka membantu, Anda harus menerima tanggung jawab untuk membantu mereka mengisolasi masalah, jadi itu membantu jika Anda memiliki lingkungan pengembang / pementasan tempat Anda dapat menjalankan tes.

2. Katakan pada vendor Anda ingin mereka meniru lingkungan Anda, sehingga mereka bisa mengisolasi masalah di lab mereka. Mereka bahkan dapat meng-host hal-hal di beberapa lingkungan cloud jika perlu. Tidak harus sama persis dengan lingkungan Anda, meskipun itu ideal. Intinya adalah Anda ingin VENDOR secara aktif mencoba mereplikasi masalah Anda, sehingga mereka dapat menguji dugaan mereka pada sistem mereka alih-alih masalah Anda. Mintalah mereka untuk diagram, spesifikasi, dll dari lingkungan yang direplikasi untuk memastikan mereka melakukannya.

3. Berikan mereka (di bawah NDA tentu saja) dengan dataset Anda yang sebenarnya sehingga mereka dapat menjalankan / memutar ulangnya secara nyata alih-alih menebak. Dalam kasus kami, sebagian besar masalah aplikasi yang disediakan vendor kami (baik sementara maupun kronis) sering menjadi masalah dengan database yang disediakan vendor yang disertakan. Saya tidak dapat menghitung berapa kali kami melakukan ini dan mereka akhirnya menunjuk masalah ke sesuatu yang tidak terduga dalam data aktual - artefak aneh dari peningkatan aplikasi 2 tahun lalu di mana ada sesuatu yang tidak dikonversi dengan bersih; catatan basi memperlihatkan masalah dengan pengaturan GC; pertanyaan tidak berfungsi dengan benar karena nilai data KAMI melanggar beberapa rutin transmog dalam kode vendor, dll. Hal-hal yang tidak akan dapat kami identifikasi sendiri.

Kami telah melakukan ini dengan beberapa vendor selama beberapa tahun terakhir, dan mereka pada awalnya sangat menolak untuk melakukannya dengan cara kami. Namun, setelah berhasil, selalu muncul sebagai sorotan positif dalam ulasan triwulanan yang kami miliki dengan vendor kami. Dan itu membantu memperkuat hubungan teknis kami dengan vendor tersebut. Mereka tidak ingin masalah yang kabur. Mereka memang menginginkan masalah khusus yang dapat mereka analisis untuk meningkatkan produk mereka.

Semoga saran ini membantu. Saya tahu ini bukan pendekatan satu ukuran untuk semua, tetapi jika Anda bisa mengayunkannya, saya pikir Anda akan menganggapnya berharga.

Pertanyaan sebenarnya adalah, siapa yang bertanggung jawab di sini? Jika Anda tidak dapat secara realistis beralih ke vendor alternatif, maka mereka memiliki kekuatan, dan yang dapat Anda lakukan hanyalah mengikuti apa pun yang mereka katakan dan berharap itu akan berhasil. Bukan situasi yang bahagia! Kalau tidak, saya sarankan Anda meminta perwakilan lain (seperti yang dikatakan orang lain), tetapi jelaskan bahwa Anda tidak puas dengan layanan ini dan akan mencari di tempat lain jika mereka tidak dapat melakukan pekerjaan itu.

Jangan hanya "membuat penyesuaian yang mereka sarankan" jika Anda yakin itu tidak akan berhasil, karena itu akan membentuk pola hubungan Anda yang akan menyakiti Anda dalam jangka panjang. Anda membayar mereka untuk memberikan layanan kepada Anda, dan mereka seharusnya tidak dapat mendikte tindakan Anda seperti halnya seseorang yang saya sewa untuk mengecat rumah saya dapat menentukan warna apa yang akan dibuat.

Ini mungkin terdengar drastis, karena sepertinya ini bukan masalah yang sangat kritis, tetapi faktanya adalah jika mereka mengacaukan Anda pada sesuatu yang kecil, mereka mungkin akan melakukan hal yang sama untuk sesuatu yang besar, dan hal terakhir yang Anda inginkan adalah bertemu dengan semacam foxtrot charlie mengerikan enam bulan di telepon dan memiliki masalah yang sama dengan vendor itu.

Pastikan bahwa langkah apa pun yang Anda ambil untuk menyelesaikan masalah sekarang, akan bekerja dengan baik ketika Anda dua hari dari tenggat waktu dan semuanya rusak ...

Saya akan memposting pandangan dari sisi vendor.

Kami memiliki pelanggan ini yang memiliki masalah berulang ini di mana kinerja perangkat lunak akan turun setiap beberapa jam atau lebih ke tingkat yang benar-benar buruk kemudian kembali beberapa jam kemudian.

Profiler bulitin dalam sistem menunjukkan kecepatan CPU sistem (atau mungkin memori) menjijikkan lambat, sesuatu seperti 100MHZ daripada 2GHZ yang diharapkan. Menggandakan CPU yang disediakan oleh VM tidak mengubah gejala dan mereka pikir kami boros.

Karena mereka tidak bisa mendapatkan CPU yang lebih cepat (lebih banyak CPU tidak akan membantu), kami kemudian mencoba bertukar TEST dan PROD VM. Masalahnya kemudian muncul di TEST keesokan harinya. Kemudian kami mencoba mempromosikan salah satu klien ke contoh mandiri (serverless). Tidak ada masalah pada workstation itu ketika server sedang tersedak.

Mereka menghasilkan laporan dari host VM yang menunjukkan tidak ada masalah kinerja dan mencoba lagi untuk mengklaim itu adalah masalah aplikasi.

Akhirnya saya [seorang insinyur] (saya tidak mendapat dukungan dari mereka yang memiliki peran pendukung khusus) meminta kotak fisik secara khusus. Pelanggan berteriak-teriak melakukan pembunuhan berdarah, tetapi tanpa ada yang punya solusi potensial lain, mereka melakukannya. Apa yang Anda tahu, masalahnya hilang secara ajaib.

Kami tidak pernah menemukan apa masalahnya. Semua program benchmark menunjukkan normal, tetapi profiler aplikasi memberi tahu kami sumber daya komputasi tidak memadai. Ada semacam tanda tangan khusus yang kami cari di profiler sekarang. Jika kita melihatnya, kita tahu sebelum kita mendapatkan lebih jauh masalahnya adalah interaksi VM, tapi itu baru diketahui pada saat itu.

Mereka yakin mengira saya penuh dengan itu. Bukan saya. Saya kehabisan pilihan.

EDIT, Perbarui dari tahun-tahun kemudian:

Dengan semakin banyak pelanggan yang ingin berjalan di VM dan manajemen bersedia untuk mencoba menyelesaikan masalah dengan segala cara, kami mendapatkan perangkat keras VM yang baik. Saya dapat membangun program pembakaran VM khusus yang berjalan di userspace (dan tidak memerlukan hak istimewa) pada dua VM inti tunggal dengan RAM 512mb, yang mampu menguras 1/3 kinerja memori dari VM inti-tunggal lain hanya dengan 4 total core dari 16 yang digunakan pada host VM dan sebagian besar ramnya masih gratis. Program tidak mengangkat alarm, dan tidak menunjukkan apa pun yang luar biasa pada host VM atau tamu, kecuali untuk akses memori lambat.

Sekarang kami dapat memberi tahu pelanggan bahwa kami tahu ada masalah dengan VM, dan itu bukan perangkat lunak kami. Kami masih mendapatkan permintaan pelanggan dari waktu ke waktu untuk perangkat lunak yang kompatibel dengan VM. Saya bertanya-tanya mengapa manajemen tidak membiarkan dukungan memberi tahu mereka bahwa kami dapat mengembangkan perangkat lunak yang memperlambat setiap VM lain di host yang sama.

Yang menakutkan adalah teknik yang terlibat adalah transformasi sederhana dari teknik pemrograman terkenal yang melibatkan sinkronisasi bebas-kunci. Ratusan vendor perangkat lunak dapat memiliki drainer VM ini dalam perangkat lunak mereka dan tidak mengetahuinya. Mendapatkan kunci instruksi atom yang diperebutkan dengan panas harus jarang tetapi bukan tidak mungkin. Bagian yang lucu dari itu semua adalah saya mendapatkan kunci untuk kontes ACROSS VMs.

Saya akan menyarankan pendekatan yang sangat berbeda dengan yang disebutkan sejauh ini. Sebelum berdebat dengan vendor, mengapa tidak melihat lebih dekat pada masalah yang dilaporkan dan lihat apa yang memberitahu Anda.

Apa masalah aktual yang dilaporkan dan apa harapan pengguna. Jika seorang pengguna mengatakan sesuatu "terlalu lama", tanyakan kepada mereka apa sebenarnya 'itu' (sehingga Anda dapat mereproduksinya), berapa lama mereka pikir itu perlu waktu, dan mengapa mereka berpikir itu harus makan waktu lama. Jika harapan mereka masuk akal, ukur kinerja aktual dan dampak sistem dari apa yang mereka coba lakukan. Fakta bahwa sistem Anda menunjukkan lonjakan 30% lebih dari sebulan tidak berarti itu tidak berjalan di> 100% ketika pengguna mencoba permintaan mereka. Jika Anda dapat menunjukkan kepada vendor Anda bahwa cpu dan memori tidak tegang oleh tugas yang bermasalah, maka Anda dapat meminta vendor untuk membenarkan rekomendasi yang akan dikenakan biaya uang.