Làm thế nào để [lịch sự?] Nói với nhà cung cấp phần mềm họ không biết họ đang nói về cái gì


62

Không phải là một câu hỏi kỹ thuật, nhưng một câu hỏi hợp lệ dù sao. Kịch bản:

HP ProLiant DL380 Gen 8 với CPU 2 x 8 nhân Xeon E5-2667 và RAM 256 GB chạy ESXi 5.5. Tám máy ảo cho một hệ thống của nhà cung cấp nhất định. Bốn máy ảo để thử nghiệm, bốn máy ảo để sản xuất. Bốn máy chủ trong mỗi môi trường thực hiện các chức năng khác nhau, ví dụ: máy chủ web, máy chủ ứng dụng chính, máy chủ OLAP DB và máy chủ SQL DB.

Cổ phiếu CPU được cấu hình để ngăn chặn môi trường thử nghiệm ảnh hưởng đến sản xuất. Tất cả lưu trữ trên SAN.

Chúng tôi đã có một số truy vấn liên quan đến hiệu suất và nhà cung cấp khẳng định rằng chúng tôi cần cung cấp cho hệ thống sản xuất nhiều bộ nhớ và vCPU hơn. Tuy nhiên, chúng ta có thể thấy rõ từ vCenter rằng các phân bổ hiện tại không bị chạm vào, ví dụ: chế độ xem hàng tháng về việc sử dụng CPU trên máy chủ ứng dụng chính dao động khoảng 8%, với mức tăng đột biến lên tới 30%. Các gai có xu hướng trùng với phần mềm sao lưu khởi động.

Câu chuyện tương tự về RAM - con số sử dụng cao nhất trên các máy chủ là ~ 35%.

Vì vậy, chúng tôi đã thực hiện một số hoạt động đào, sử dụng Trình giám sát quy trình (Microsoft SysIternals) và Wireshark, và khuyến nghị của chúng tôi với nhà cung cấp là họ thực hiện một số điều chỉnh TNS trong trường hợp đầu tiên. Tuy nhiên, đây là bên cạnh điểm.

Câu hỏi của tôi là: làm thế nào để chúng tôi thừa nhận rằng số liệu thống kê về VMware mà chúng tôi đã gửi cho họ là bằng chứng đủ để RAM / vCPU không giúp được nhiều hơn?

--- CẬP NHẬT 12/07/2014 ---

Tuần thú vị. Quản lý CNTT của chúng tôi đã nói rằng chúng tôi nên thực hiện thay đổi đối với phân bổ VM và hiện chúng tôi đang chờ một số thời gian chết từ người dùng doanh nghiệp. Thật kỳ lạ, người dùng doanh nghiệp là những người nói rằng các khía cạnh nhất định của ứng dụng đang chạy chậm (so với những gì tôi không biết), nhưng họ sẽ "cho chúng tôi biết" khi chúng tôi có thể gỡ bỏ hệ thống (càu nhàu , càu nhàu!).

Bên cạnh đó, khía cạnh "chậm" của hệ thống rõ ràng không phải là yếu tố HTTP (S), tức là: "ứng dụng mỏng" được sử dụng bởi hầu hết người dùng. Có vẻ như đó là cài đặt "máy khách béo", được sử dụng bởi các tổ chức tài chính chính, rõ ràng là "chậm". Điều này có nghĩa là chúng tôi hiện đang xem xét tương tác giữa máy khách và máy khách-máy chủ trong các cuộc điều tra của chúng tôi.

Vì mục đích ban đầu của câu hỏi là tìm kiếm sự trợ giúp về việc có nên đi theo con đường "chọc nó" hay chỉ thực hiện thay đổi, và giờ chúng tôi đang thực hiện thay đổi, tôi sẽ đóng nó bằng câu trả lời của longneck .

Cảm ơn tất cả các đầu vào của bạn; như thường lệ, serverfault không chỉ là một diễn đàn - nó giống như một chiếc ghế bành của nhà tâm lý học :-)



5
Đây vẫn LART ưa thích của tôi: laughingsquid.com/cat-5-o-nine-tails-ethernet-cable-whip Nó cho chẩn đoán mạng. Thật thà.
Sobrique

17
Không quan tâm bạn đã kiểm tra hiệu suất lưu trữ? Yêu cầu nhiều CPU / RAM hơn có thể chỉ là phản ứng của cư sĩ đối với hiệu năng kém, điều này có thể dễ dàng gây ra bởi độ sâu hàng đợi đĩa cao. Có vẻ như rất nhiều người quên mất các thực tiễn tốt nhất về lưu trữ SQL khi ảo hóa xuất hiện.
Ashigore

7
càu nhàu . Đúng vậy, đổ lỗi cho việc lưu trữ! Nhưng nghiêm túc hơn - đó là một điểm tốt. Nếu có vấn đề và RAM / CPU không giúp được thì đó có thể là IO. Đặc biệt là nếu chúng ta đang nói về VMWare, bởi vì nó không có gì lạ đối với ... tốt, phần hiệu năng lưu trữ của một hệ thống gần như bị bỏ qua hoàn toàn - trong khi quên rằng về bản chất bạn sẽ gặp phải một tắc nghẽn lớn nếu bạn cung cấp nhiều VM trên một số lượng hạn chế số lượng HBA.
Sobrique

6
HP có phải là nhà cung cấp của bạn trong trường hợp này? Vì tôi làm việc ở đó. Tôi có thể xác nhận chúng tôi không quan tâm.
Christopher Wirt

Câu trả lời:


94

Tôi đề nghị bạn thực hiện các điều chỉnh mà họ đã yêu cầu. Sau đó, điểm chuẩn hiệu suất để cho họ thấy rằng nó không có sự khác biệt. Bạn thậm chí có thể đi xa để đánh giá nó với bộ nhớ LESS và vCPU để đưa ra quan điểm của mình.

Ngoài ra, "Chúng tôi sẽ trả tiền cho bạn để hỗ trợ phần mềm bằng các giải pháp thực tế chứ không phải phỏng đoán."


10
... những lời khôn ngoan. Tôi cho rằng đây có thể là con đường phía trước, cũng như nó làm chúng ta đau đớn khi phải thay đổi. Điều tốt (?) Là các thay đổi sẽ yêu cầu khởi động lại và chúng tôi có thể rõ ràng với người dùng doanh nghiệp của mình rằng điều này là do yêu cầu của nhà cung cấp ... gần như chắc chắn sẽ chứng minh là vô nghĩa. Nghe có vẻ như tôi đang trở nên nhỏ mọn, nhưng chúng tôi đang mệt mỏi vì sự thiếu sót rõ ràng của nhà cung cấp.
Simon Catlin

6
Không có gì lạ khi các nhà cung cấp chơi loại đóng thế này. Tôi nghĩ rằng một phần là do các số liệu cấp độ dịch vụ - bỏ qua, hỏi thêm thông tin và đề xuất cách giải quyết (vô nghĩa), bởi vì ít nhất một số thời gian, vấn đề sẽ biến mất / được khắc phục trong thời gian đó. Nếu bạn 'kéo' với nhà cung cấp, trò chuyện với người quản lý tài khoản có thể sẽ tạo nên mánh khóe. Nhưng đừng nín thở.
Sobrique

1
Đã có một tình huống tương tự một lần với máy chủ SQL cho SCCM (hệ thống trung tâm cấu hình mgr) 4 CPU 30% sử dụng avg. Bảng điều khiển chậm khủng khiếp. Bumped đến 8 CPU vẫn sử dụng 30%, console cuối cùng cũng phản hồi theo cách thông thường.
Clayton

2
Đề nghị tuyệt vời. Không có gì giống như dữ liệu để khiến mọi người im lặng. "Chúng tôi sẽ thực hiện thay đổi mà bạn đề xuất. Nếu nó không mang lại sự cải thiện dự kiến, bạn sẽ ăn chi phí." Không chắc có bao nhiêu hệ thống bị ảnh hưởng ở đây nhưng thời gian của bạn chứng minh chúng sai NHANH CHÓNG trở nên đắt hơn so với việc cắm thêm một số RAM.
Floris

67

Cung cấp cho bạn sự tự tin rằng bạn đang ở trong các thông số kỹ thuật hệ thống nhất định mà họ tài liệu.

Sau đó, bất kỳ khiếu nại nào họ đưa ra liên quan đến việc yêu cầu thêm RAM hoặc CPU, họ sẽ có thể sao lưu. Là các chuyên gia trong hệ thống của họ, tôi giữ mọi người để giải thích về điều này.

Hỏi họ cụ thể.

  • Thông tin nào được cung cấp trên hệ thống cho biết cần thêm RAM và bạn đã giải thích điều này như thế nào?

  • Thông tin nào được cung cấp trên hệ thống cho biết cần nhiều CPU hơn và làm thế nào bạn diễn giải điều này?

  • Dữ liệu tôi có - thoạt nhìn - mâu thuẫn với những gì bạn đang nói với tôi. Bạn có thể giải thích cho tôi tại sao tôi có thể giải thích điều này không chính xác?

  • Tôi đang giải thích [chuỗi dữ liệu rõ ràng] này có nghĩa là [giải thích rõ ràng]. Bạn có thể xác nhận tôi đang giải thích nó một cách chính xác liên quan đến vấn đề của tôi?

Đã xử lý hỗ trợ trong quá khứ tôi đã hỏi những câu hỏi tương tự. Đôi khi tôi đã đúng và họ không tập trung chú ý vào vấn đề của tôi. Tuy nhiên, lần khác, tôi đã sai và tôi đã diễn giải dữ liệu không chính xác hoặc không bao gồm các dữ liệu khác quan trọng trong phân tích của tôi.

Trong mọi trường hợp, cả hai tình huống này đều mang lại lợi ích ròng cho tôi, hoặc tôi đã học được điều gì đó mới mà tôi chưa biết trước đây - hoặc tôi đã khiến các nhóm hỗ trợ của họ suy nghĩ kỹ hơn về vấn đề của tôi để có được nguyên nhân sâu xa.

Nếu nhóm hỗ trợ không thể cung cấp cho bạn sự mở rộng hợp lý đối số của họ thành cơ sở mà bạn có thể hài lòng (bạn cần có một suy nghĩ cởi mở để thỏa hiệp với chính mình, hãy hợp lý để chấp nhận cách giải thích dữ liệu của bạn là sai) nên trở nên rất hiện diện trong phản ứng của họ. Ngay cả trong trường hợp xấu nhất, bạn có thể sử dụng điều này làm cơ sở để leo thang vấn đề.


10
+1 để nhận ra rằng lỗi của con người có thể đi theo hai cách (và khiến cho sự hỗ trợ vặn vẹo một chút khi họ thực sự đã cố gắng "bỏ đi").
Vũ trụ Ossifrage

17

Điều quan trọng là có thể chứng minh rằng bạn đang sử dụng các thực tiễn tốt nhất để phân bổ hệ thống của mình, đáng chú ý là việc đặt trước RAM và CPU cho máy chủ SQL của bạn.

Tất cả điều này được nói là điều dễ nhất là thực hiện các điều chỉnh được yêu cầu, ít nhất là tạm thời. Nếu không có gì khác, nó có xu hướng khiến các nhà cung cấp kéo chân. Tôi không thể đếm số lần tôi cần phải làm điều gì đó điên rồ như thế này để thỏa mãn công nghệ ở đầu dây bên kia rằng đó thực sự là phần mềm của họ không hoạt động.


17

Đối với tình huống cụ thể này (nơi bạn có VMware và nhà phát triển ứng dụng hoặc bên thứ ba không hiểu về phân bổ tài nguyên), tôi sử dụng số liệu có giá trị trong một tuần từ vCenter Operations Manager (vCops - tải xuống bản demo nếu cần ) để xác định các ràng buộc thực sự. , tắc nghẽn và yêu cầu kích thước của VM (các) ứng dụng.

Đôi khi, tôi đã có thể làm hài lòng những người tiêu dùng cứng đầu hơn bằng cách sửa đổi các đặt chỗ VM hoặc thay đổi các ưu tiên để xử lý các tình huống tranh chấp; " Nếu RAM | CPU là chặt chẽ, BẠN VM sẽ được ưu tiên! ". Những điều tồi tệ đã xảy ra khi tôi cho phép các nhà cung cấp phần mềm đưa ra yêu cầu của họ trên các cụm vSphere của tôi mà không cần phân tích thực sự .

Nhưng nói chung, số lượng và dữ liệu nên thắng.


Một ví dụ về một cái gì đó tôi đã sử dụng để chứng minh kích thước VM cho nhà phát triển ứng dụng Tomcat:

Dev : VM cần cpu MOAR!

Tôi : Chà, bộ nhớ là hạn chế lớn nhất của bạn và đây là bản đồ nhiệt về hiệu suất của bạn so với thời gian ... Thứ Tư lúc 6 giờ tối là khoảng thời gian căng thẳng nhất, vì vậy chúng tôi có thể chỉ ra khoảng thời gian cao điểm đó. Ồ, và đây là một đề xuất kích thước dựa trên 6 tuần qua của số liệu sản xuất ...

nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây


9
Tôi nên thêm phân tích dựa trên mức trung bình có thể dẫn đến kết quả sai. Có những điều kiện trong đó hiệu suất cao nhất là quan trọng nhưng bạn không thấy các đỉnh trong thống kê tải khi chúng ngắn hơn đáng kể so với khoảng thời gian thu thập / trung bình của bạn. Vì vậy, bạn có thể có một biểu đồ thống kê "mức sử dụng tổng thể của bạn là <60%" đầy màu sắc nhưng nhìn thấy sự suy giảm hiệu suất nghiêm trọng trong các đỉnh cao 1 phút xảy ra 8 lần một giờ cùng một lúc.
the-wợi

Có lẽ tôi đã hoàn toàn đọc sai câu hỏi, nhưng đây không phải là điều ngược lại với những gì OP đã hỏi? Tôi nghĩ rằng họ là nhà phát triển, họ biết rằng họ không cần thêm cpu, mà nhà cung cấp đang cố bán chúng - có vẻ như bạn đang mô tả nghịch đảo, nơi một nhà phát triển đang yêu cầu thêm cpu mà họ không cần.
Benubird

1
Tôi đang sử dụng một ví dụ thuận tiện. Tôi áp dụng cách tiếp cận tương tự với các nhà cung cấp có yêu cầu cứng nhắc (4 vCPU và 16GB RAM), cũng như để xác định các hệ thống chưa được khai thác cần tài nguyên. Về mặt giám sát mức độ chi tiết, bạn có thể quay lại thống kê cấp máy chủ để đối phó với các đỉnh ...
ewwhite

Cảm ơn vì điều đó. Chúng tôi không có vCops, nhưng tôi cho rằng vSphere "động sản" của chúng tôi đã đủ trưởng thành để yêu cầu mức độ chi tiết này. Tôi sẽ thêm nó vào danh sách mong muốn của Capex cho năm tới.
Simon Catlin

2
@SimonCatlin bạn không cần phải mua nó. Bạn có thể tải xuống bản demo miễn phí và sử dụng nó trong 60 ngày. Nó hoàn hảo cho loại tình huống này.
ewwhite

10

Tôi đã từng làm việc trong bộ phận hỗ trợ - và một phần trong những gì bạn hỏi nghevẻ hợp lý (và có lẽ là vậy): nhưng có một vài câu hỏi để tự hỏi mình trước khi thực hiện "tăng cường hiệu suất" mà họ yêu cầu

  • bạn đang chạy ít nhất theo yêu cầu hệ thống tối thiểu đã nêu của nhà cung cấp chưa?
  • nếu bạn ít nhất là ở mức tối thiểu, bạn đã ở cài đặt hệ thống "được đề xuất" của họ chưa?

Các nhà cung cấp sẽ 99 lần trong số 100 (theo kinh nghiệm của tôi - cả về phía hỗ trợ và khách hàng / lĩnh vực) thậm chí không giải quyết các vấn đề liên quan đến hiệu suất cho đến khi / trừ khi hệ thống khớp với những gì tài liệu của họ yêu cầu. Có thể đó là một hệ thống chạy tốt 99,5% thời gian với 1 CPU và RAM 512M - nhưng nếu yêu cầu hệ thống cho biết 4 CPU và RAM 4G và bạn chỉ có 2 CPU và RAM 1G, thì chúng cũng có quyền đòi hỏi nhiều tài nguyên hơn được chỉ định * .

Có thể họ yêu cầu bạn tăng tài nguyên hệ thống vì có thứ gì đó họ tìm thấy trong phòng thí nghiệm / phát triển trong đó một vấn đề sẽ biến mất một cách kỳ diệu nếu bạn vượt qua một ngưỡng cụ thể; nếu đây là trường hợp, vâng, đó là một ví dụ về khả năng sửa lỗi kém, nhưng hãy nhớ rằng họ không có thời gian để loại bỏ mọi lỗi / vấn đề có thể xảy ra - một số chỉ cần xử lý và nếu đó là trường hợp ở đây, chỉ cần đi với nó.

Cũng có một cơ hội không đáng kể rằng các vấn đề bạn gặp phải thậm chí không phải là một phần của phần mềm "của họ", mà là một thành phần mà họ dựa vào từ một số nguồn khác (nhà cung cấp, thư viện OSS, v.v.). Tôi đã gặp tình huống chính xác này liên quan đến kích thước hoán đổi, BEA WebLogic và Sun JRE tại một khách hàng vài năm trước.

tl; dr:

Nói tóm lại, hãy làm việc với nhóm hỗ trợ của họ, leo thang khi cần thiết, cho đến khi bạn tìm thấy giải pháp - nhưng đừng ngạc nhiên khi một số đề xuất / bước gỡ lỗi / sửa lỗi nghe có vẻ khó hiểu hoặc vô nghĩa.


* Nếu nó thực sự không "cần" những tài nguyên bổ sung đó, thì có khả năng bạn sẽ có thể gửi lỗi doc / RFE cho các phiên bản trong tương lai - nhưng đừng đẩy tuyến đường đó cho đến khi bạn chứng minh rằng đó không phải là vấn đề trong tay
^ Sách điện tử tôi đã viết bạn có thể thấy hữu ích về chủ đề: Gỡ lỗi và hỗ trợ hệ thống phần mềm


2
Bất cứ điều gì liên quan đến hiệu suất đều mất rất nhiều thời gian và nguồn lực để khắc phục sự cố và chẩn đoán. Rốt cuộc, không có gì bị hỏng nên bạn phải tìm kiếm một cách đau đớn.
Sobrique

1
@Sobrique hoàn toàn - và họ thường ở trong các phân khúc khá liên quan (thậm chí không liên quan) của sản phẩm trong tay
warren

Đó là một điểm tốt, rất nhiều bước gỡ lỗi có thể rất phản cảm, mặc dù tôi không nghĩ rằng sẽ không hợp lý khi nhấn mạnh rằng họ cung cấp lý do để thực hiện. Nếu họ không thể nói lợi ích gì khi làm điều gì đó sẽ mang lại (ngay cả khi đó chỉ là "để xem liệu nó có ảnh hưởng đến X" không) thì họ sẽ làm việc thông qua một danh sách kiểm tra mà họ không hiểu, hoặc họ không biết và đang thực hiện phỏng đoán hoang dã, hoặc họ đang che giấu điều gì đó - không ai trong số này là rất đáng khích lệ.
Benubird

@Benubird - thật đáng buồn khi một số trong những điều này xuất phát từ bản năng ruột thịt hoặc "nó đã sửa nó ở một nơi khác ..." :(
warren

2
"nó đã sửa nó ở một nơi khác" là một lý do khủng khiếp để làm một cái gì đó. Đúng, đôi khi không có thời gian để gỡ lỗi một vấn đề, và bạn phải đi theo bản năng ruột thịt, nhưng suy nghĩ về nó vẫn khiến tôi rùng mình. Tôi đã thấy rất nhiều lỗi "dường như" đã được sửa bằng cách thực hiện X, chỉ để sau đó phát hiện ra rằng vấn đề thực sự nằm ở một thứ dường như hoàn toàn không liên quan, đã gây ra nhiều vấn đề ở nơi khác cho đến khi chúng tôi phát hiện ra.
Benubird

8

Hoặc yêu cầu leo ​​thang vé hoặc yêu cầu một đại diện khác. Tùy thuộc vào nhà cung cấp nào, việc leo thang có thể giúp ích nếu bạn nói rằng bạn cảm thấy rằng mức hỗ trợ hiện tại không giải quyết thỏa đáng vấn đề. Nếu họ sẽ không leo thang thì yêu cầu một đại diện khác có thể giúp đỡ vì điều đó đòi hỏi ít "sự biện minh" hơn vì tất cả những gì nó cần là không hài lòng với người hiện tại.

Nếu đó là một nhà cung cấp lớn thì chỉ cần đóng vé và mở một cái mới cho cùng một vấn đề có thể hoạt động vì nó có thể được chuyển đến một đại diện khác, nhưng tôi khuyên bạn nên chống lại nó vì hình thức kém.

Bạn cũng có thể giữ vững lập trường của mình và yêu cầu một lý do hợp lý về việc RAM / vCPU sẽ giúp được bao nhiêu, hoặc bạn có thể cung cấp thêm RAM / vCPU để chứng minh rằng nó sẽ không giúp ích.


4

Tôi sẽ ném vào hai xu của tôi. Chúng tôi đã khá thành công với phương pháp này - kết quả tốt hơn nhiều và ít thất vọng hơn về phía mọi người. Nó đòi hỏi nhiều nỗ lực hơn trò chơi đổ lỗi và bổ sung tài nguyên một cách mù quáng, nhưng nó cũng có cơ hội tốt hơn để tìm ra vấn đề tiềm ẩn.

Khi chúng tôi gặp sự cố nghiêm trọng với các ứng dụng tại cơ sở được hỗ trợ bởi các hợp đồng hỗ trợ của nhà cung cấp và các nhà cung cấp bắt đầu nhảy múa xáo trộn (dường như luôn bao gồm các yêu cầu phi dữ liệu đối với CPU hoặc RAM nhiều hơn), chúng tôi có xu hướng làm 3 việc sau:

  1. Nâng cao mức độ ưu tiên đối với hệ thống tương đương xuống - chúng thường chùn bước, nhưng thường lùi lại khi bạn giải thích nó thực sự không sử dụng được ngay cả khi về mặt kỹ thuật "hoạt động". Hãy coi nó như một vấn đề nghiêm trọng để họ giải quyết. Xung quanh đây, chúng tôi đề cập đến như một đội hổ, gặp gỡ hàng ngày để nhận được cập nhật trạng thái từ tất cả các bên liên quan. Thông thường các nhà cung cấp sẽ yêu cầu bạn thay đổi công cụ. Nếu đó là một hệ thống prod, điều đó có vấn đề, nhưng nếu bạn muốn họ giúp đỡ, bạn sẽ cần chấp nhận trách nhiệm giúp họ cách ly vấn đề, vì vậy nó sẽ giúp ích nếu bạn có môi trường phát triển / thử nghiệm nơi bạn có thể chạy thử nghiệm.

  2. Nói với nhà cung cấp mà bạn muốn họ tái tạo môi trường của bạn, để HỌ có thể cách ly vấn đề trong phòng thí nghiệm của họ. Họ thậm chí có thể lưu trữ công cụ trong một số môi trường đám mây nếu cần. Nó không phải là một kết hợp chính xác của môi trường của bạn, mặc dù đó sẽ là lý tưởng. Vấn đề là bạn muốn VENDOR tích cực cố gắng tái tạo vấn đề của bạn, để họ có thể kiểm tra phỏng đoán của họ trên hệ thống của họ thay vì của bạn. Yêu cầu họ cho các sơ đồ, thông số kỹ thuật, vv của môi trường nhân rộng đó để đảm bảo rằng họ đang làm điều đó.

  3. Cung cấp cho họ (tất nhiên là theo NDA) với bộ dữ liệu thực tế của bạn để họ có thể chạy / phát lại nó thực sự thay vì đoán. Trong trường hợp của chúng tôi, hầu hết các sự cố ứng dụng do nhà cung cấp của chúng tôi cung cấp (cả tạm thời và mãn tính) thường trở thành sự cố với cơ sở dữ liệu do nhà cung cấp đi kèm. Tôi không thể đếm số lần chúng tôi đã thực hiện việc này và cuối cùng họ đã xác định được vấn đề bất ngờ trong dữ liệu thực tế - các tạo tác kỳ lạ từ nâng cấp ứng dụng 2 năm trước, nơi một thứ gì đó không chuyển đổi sạch sẽ; hồ sơ cũ phơi bày một vấn đề với các cài đặt GC; các truy vấn không hoạt động hoàn toàn đúng vì các giá trị dữ liệu của chúng tôi phá vỡ một số thói quen truyền trong mã nhà cung cấp, v.v. Thứ chúng tôi sẽ không bao giờ có thể tự xác định được.

Chúng tôi đã làm điều này với khá nhiều nhà cung cấp trong vài năm qua, và ban đầu họ rất chịu khó thực hiện theo cách của chúng tôi. Tuy nhiên, sau khi nó hoạt động, nó luôn xuất hiện như một điểm nhấn tích cực trong các đánh giá hàng quý mà chúng tôi tổ chức với các nhà cung cấp của chúng tôi. Và nó giúp củng cố mối quan hệ kỹ thuật của chúng tôi với các nhà cung cấp. Họ không muốn những vấn đề mơ hồ. Họ muốn có những vấn đề cụ thể mà họ có thể phân tích để cải thiện sản phẩm của họ.

Hy vọng gợi ý giúp. Tôi biết đó không phải là cách tiếp cận một kích cỡ phù hợp với tất cả, nhưng nếu bạn có thể xoay nó, tôi nghĩ bạn sẽ thấy nó đáng giá.


3

Câu hỏi thực sự là, ai chịu trách nhiệm ở đây? Nếu bạn thực sự không thể chuyển sang một nhà cung cấp thay thế, thì họ có sức mạnh và tất cả những gì bạn thực sự có thể làm là đi cùng với bất cứ điều gì họ nói và hy vọng nó sẽ hoạt động. Không phải là một tình huống hạnh phúc! Mặt khác, tôi khuyên bạn nên yêu cầu một đại diện khác (như những người khác đã nói), nhưng hãy nói rõ rằng bạn không hài lòng với dịch vụ này và sẽ tìm nơi khác nếu họ không thể thực hiện công việc.

Đừng chỉ "thực hiện các điều chỉnh mà họ đề xuất" nếu bạn chắc chắn rằng chúng sẽ không hoạt động, vì đó là thiết lập một mô hình cho mối quan hệ của bạn sẽ làm tổn thương bạn về lâu dài. Bạn đang trả tiền cho họ để cung cấp cho bạn một dịch vụ và họ không thể ra lệnh cho hành động của bạn hơn bất kỳ ai tôi thuê để sơn nhà tôi có thể ra lệnh nó sẽ có màu gì.

Điều này nghe có vẻ quyết liệt, vì nghe có vẻ như đây không phải là một vấn đề cực kỳ nghiêm trọng, nhưng thực tế là nếu họ đang làm phiền bạn về một điều gì đó nhỏ nhặt, họ có thể sẽ làm điều tương tự cho một điều gì đó lớn lao, và điều cuối cùng bạn muốn là chạy vào một số loại charlie foxtrot khủng khiếp sáu tháng xuống dòng và gặp rắc rối tương tự với các nhà cung cấp sau đó.

Hãy chắc chắn rằng bất kỳ bước nào bạn thực hiện để giải quyết vấn đề ngay bây giờ, sẽ hoạt động tốt như nhau khi bạn còn hai ngày kể từ ngày hết hạn và mọi thứ đều bị phá vỡ ...


4
Tôi đã nghĩ rằng nó sẽ cung cấp đạn dược trong một cuộc tranh cãi - bạn đã yêu cầu chúng tôi làm điều vô lý này lần trước; chúng tôi đã làm như một cử chỉ thiện chí. Lần này chúng tôi muốn một số chi tiết hơn về lý do của bạn tại sao điều này sẽ làm cho bất kỳ sự khác biệt.
Sobrique

@Sobrique Điều đó có ý nghĩa, và nó có thể diễn ra theo cách đó - Tôi không biết đủ tâm lý để nói theo cách này hay cách khác. Mặc dù vậy, bản năng của tôi là nếu bây giờ bạn đã làm gì đó chỉ vì họ nói - thực sự thừa nhận họ biết nhiều hơn bạn - họ sẽ mong đợi điều tương tự trong tương lai. Dù bằng cách nào, nếu bạn phải tranh luận với họ (đạn dược hay không), bạn đã lãng phí thời gian có thể được dành để giải quyết vấn đề.
Benubird

"Chúng tôi đã làm theo cách của bạn lần trước. Bạn đã sai. Bạn đã chuẩn bị để chấp nhận rằng bạn có thể sai một lần nữa chưa? Chúng tôi đã có tiền lệ ở đây."
Sobrique

3

Tôi sẽ đăng một cái nhìn từ phía nhà cung cấp.

Chúng tôi đã có khách hàng này có vấn đề tái diễn này trong đó hiệu suất của phần mềm sẽ giảm xuống sau mỗi vài giờ hoặc lâu hơn với tốc độ thực sự đáng kinh ngạc sau đó quay lại vài giờ sau đó.

Trình lược tả bulitin trong hệ thống cho thấy tốc độ CPU của hệ thống (hoặc có thể là bộ nhớ) chậm đến mức kinh khủng, tương đương 100MHZ thay vì 2GHZ dự kiến. Nhân đôi CPU do VM cung cấp đã không thay đổi triệu chứng và họ nghĩ rằng chúng tôi đang lãng phí.

Vì họ không thể có được CPU nhanh hơn (nhiều CPU hơn sẽ không có ích), sau đó chúng tôi đã thử trao đổi máy ảo TEST và PROD. Vấn đề sau đó xuất hiện trên TEST vào ngày hôm sau. Sau đó, chúng tôi đã thử quảng bá một trong các máy khách thành một phiên bản độc lập (không có máy chủ). Không có vấn đề trên máy trạm đó trong khi máy chủ bị nghẹt thở.

Họ đã tạo các báo cáo từ máy chủ VM cho thấy không có vấn đề về hiệu năng và đã thử lại để khẳng định đây là sự cố ứng dụng.

Cuối cùng tôi [một kỹ sư] (tôi không có sự hỗ trợ nào từ những người trong vai trò hỗ trợ chuyên dụng) đã hỏi cụ thể về một hộp vật lý. Khách hàng hét lên giết người đẫm máu nhưng không ai có giải pháp tiềm năng nào khác họ đã làm điều đó. Bạn biết gì, vấn đề kỳ diệu biến mất.

Chúng tôi không bao giờ tìm ra vấn đề là gì. Tất cả các chương trình điểm chuẩn cho thấy bình thường nhưng trình hồ sơ ứng dụng đã cho chúng tôi biết tài nguyên điện toán đơn giản là không đủ. Bây giờ có một loại chữ ký cụ thể mà chúng tôi tìm kiếm trong hồ sơ. Nếu chúng ta thấy nó, chúng ta sẽ biết trước khi chúng ta gặp vấn đề xa hơn là tương tác VM, nhưng nó không được biết đến vào thời điểm đó.

Họ chắc chắn nghĩ rằng tôi có đầy đủ của nó. Tôi đã không. Tôi đã hết lựa chọn.

EDIT, Cập nhật từ những năm sau:

Với ngày càng nhiều khách hàng muốn chạy trên máy ảo và quản lý sẵn sàng cố gắng giải quyết vấn đề bằng mọi giá, chúng tôi đã có được phần cứng VM tốt. Tôi đã có thể xây dựng một chương trình ghi VM chuyên dụng chạy trong không gian người dùng (và không yêu cầu đặc quyền) trên hai máy ảo lõi đơn có RAM 512mb, có thể rút 1/3 hiệu năng bộ nhớ ra khỏi máy ảo đơn lõi khác chỉ với 4 tổng số lõi trong số 16 được sử dụng trên máy chủ VM và hầu hết ram của nó vẫn miễn phí. Chương trình không đưa ra báo động và không cho thấy điều gì khác thường trên máy chủ VM cũng như bất kỳ khách nào, ngoại trừ việc truy cập bộ nhớ bị chậm.

Bây giờ chúng tôi có thể nói với khách hàng rằng chúng tôi biết rằng có vấn đề với máy ảo và đó không phải là phần mềm của chúng tôi. Thỉnh thoảng chúng tôi vẫn nhận được yêu cầu của khách hàng đối với phần mềm tương thích VM. Tôi tự hỏi tại sao quản lý không cho phép hỗ trợ nói với họ rằng chúng tôi có thể phát triển một phần mềm làm chậm mọi VM khác trên cùng một máy chủ.

Điều đáng sợ là kỹ thuật liên quan là một biến đổi đơn giản của kỹ thuật lập trình nổi tiếng liên quan đến đồng bộ hóa không khóa. Hàng trăm nhà cung cấp phần mềm có thể có bộ thoát VM này trong phần mềm của họ và không biết. Có được một khóa hướng dẫn nguyên tử mà tranh cãi nóng bỏng là rất hiếm nhưng không phải là không thể. Phần thú vị của tất cả là tôi đã nhận được khóa để tranh tài với máy ảo ACROSS.


-3

Tôi sẽ đề nghị một cách tiếp cận rất khác với những người được đề cập cho đến nay. Trước khi tranh luận với nhà cung cấp, tại sao không xem xét kỹ hơn vấn đề được báo cáo và xem những gì cho bạn biết.

Các vấn đề thực tế được báo cáo là gì và những gì người dùng mong đợi. Nếu người dùng đang nói điều gì đó "mất quá nhiều thời gian", hãy hỏi họ chính xác "nó" là gì (để bạn có thể tái tạo nó), họ nghĩ nó sẽ mất bao lâu và tại sao họ nghĩ rằng nó sẽ mất nhiều thời gian như vậy. Nếu kỳ vọng của họ là hợp lý, hãy đo lường hiệu suất thực tế và tác động hệ thống của những gì họ đang cố gắng thực hiện. Việc hệ thống của bạn hiển thị mức tăng 30% trong một tháng không có nghĩa là nó không chạy ở mức> 100% khi người dùng đang thử truy vấn của họ. Nếu bạn có thể chứng minh với nhà cung cấp của mình rằng cpu và bộ nhớ không bị căng thẳng bởi nhiệm vụ có vấn đề, thì bạn có thể yêu cầu nhà cung cấp biện minh cho các đề xuất sẽ khiến bạn mất tiền.


1
Toàn bộ nửa đầu đề nghị của bạn dường như đã được thực hiện. Toàn bộ nửa thứ hai chính xác là những gì OP đang yêu cầu.
Chris S

Tôi sẽ không đồng ý. Không có bằng chứng nào được đưa ra về phân tích vấn đề và các số liệu cpu và mem được trích dẫn là các tổng hợp hàng tháng không liên quan rõ ràng đến vấn đề hiện tại.
Paul Smith
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.