[정치적으로] 어떻게 소프트웨어 벤더에게 그들이 무엇을 말하는지 모른다고 알리는 방법

그럼에도 불구하고 기술적 인 질문은 아니지만 유효한 질문입니다. 대본:

2 개의 8 코어 Xeon E5-2667 CPU 및 ESXi 5.5를 실행하는 256GB RAM이 장착 된 HP ProLiant DL380 Gen 8. 특정 공급 업체 시스템에 대해 8 개의 VM. 테스트 용 VM 4 개, 프로덕션 용 VM 4 개 각 환경에있는 4 개의 서버는 웹 서버, 기본 앱 서버, OLAP DB 서버 및 SQL DB 서버와 같은 다른 기능을 수행합니다.

테스트 환경이 프로덕션에 영향을 미치지 않도록 구성된 CPU 공유 SAN의 모든 스토리지

성능에 관한 몇 가지 질문이 있었으며 공급 업체는 프로덕션 시스템에 더 많은 메모리와 vCPU를 제공해야한다고 주장합니다. 그러나 vCenter에서 기존 할당에 영향을 미치지 않는 것을 알 수 있습니다. 예를 들어, 주 애플리케이션 서버의 월별 CPU 사용량은 약 8 %이며 홀수 급증은 최대 30 %입니다. 스파이크는 시작되는 백업 소프트웨어와 일치하는 경향이 있습니다.

RAM에 대한 비슷한 이야기-서버에서 가장 높은 활용률은 ~ 35 %입니다.

따라서 프로세스 모니터 (Microsoft SysInternals) 및 Wireshark를 사용하여 일부 파기를 수행했으며 공급 업체에 대한 권장 사항은 첫 번째 인스턴스에서 TNS 조정을 수행하는 것입니다. 그러나 이것은 요점 이외의 것입니다.

내 질문은 : 우리가 보낸 VMware 통계가 더 많은 RAM / vCPU가 도움이되지 않을 것이라는 증거임을 어떻게 알 수 있습니까?

--- 업데이트 12/07/2014 ---

재미있는 주. IT 관리자는 VM 할당을 변경해야한다고 말했으며 이제 비즈니스 사용자의 다운 타임을 기다리고 있습니다. 이상하게도 비즈니스 사용자는 앱의 특정 측면이 느리게 실행되고 있지만 (알지 못하는 것과 비교하여) 시스템을 다운시킬 수있을 때 "알려줄 것"입니다. 으 gr!).

그 외에도 시스템의 "느린"측면은 HTTP (S) 요소가 아닙니다. 즉, 대부분 의 사용자가 사용하는 "씬 앱" 입니다. 주요 금융 기관이 사용하는 "팻 클라이언트"설치 인 것 같습니다. "느린"것 같습니다. 이는 현재 조사에서 클라이언트와 클라이언트-서버 상호 작용을 고려하고 있음을 의미합니다.

이 질문의 초기 목적은 "poke it"경로를 내려갈 것인지 아니면 변경을 할 것인지에 대한 도움을 구하는 것이 었으므로 이제 변경 작업을 수행하므로 longneck 의 답변을 사용하여 닫을 것 입니다.

입력 해 주셔서 감사합니다. 평소와 같이 serverfault는 단순한 포럼 그 이상이었습니다. 심리학자의 소파와도 같습니다. :-)

요청한 내용을 조정하시기 바랍니다. 그런 다음 성능을 벤치마킹하여 아무런 차이가 없음을 보여줍니다. 지금까지 LESS 메모리와 vCPU를 사용하여 벤치마킹하여 요점을 파악할 수도 있습니다.

또한 "우리는 추측이 아니라 실제 솔루션으로 소프트웨어를 지원하기 위해 비용을 지불하고 있습니다."

자신이 문서화 한 지정된 시스템 사양 내에 있다고 확신 할 수 있습니다.

그런 다음 백업 할 수있는 RAM 또는 CPU가 더 필요하다는 주장이 있습니다. 나는 그들의 시스템 전문가로서 이것을 설명 할 사람들을 보유하고 있습니다.

그들에게 구체적으로 물어보십시오.

• 더 많은 RAM이 필요하다는 것을 시스템에 제공된 정보는 무엇이며 어떻게 해석 했습니까?

• 시스템에 제공된 정보는 더 많은 CPU가 필요하다는 것을 나타내며 어떻게 해석 했습니까?

• 내가 가진 데이터는 언뜻보기에 당신이 말한 것과 모순됩니다. 내가 왜 이것을 잘못 해석하는지 설명해 줄 수 있습니까?

• 이 [명백한 데이터]를 [명백한 해석]으로 해석하고 있습니다. 내 문제와 관련하여 올바르게 해석하고 있음을 확인할 수 있습니까?

과거에 지원을 처리 한 후에도 같은 질문을했습니다. 때때로 나는 옳았 고 그들은 내 문제에 제대로 초점을 맞추지 않았습니다. 그러나 다른 경우에는 잘못되어 데이터를 잘못 해석했거나 분석에 중요한 다른 데이터를 포함시키지 못했습니다.

어쨌든,이 두 가지 상황은 나에게 순이익 이었습니다. 내가 전에 알지 못했던 새로운 것을 배웠거나 지원 팀이 내 근본 원인을 얻기 위해 내 문제에 대해 더 열심히 생각하도록했습니다.

지원 팀이 당신이 만족할 수있는 근거로 논증의 논리적 확장을 제공 할 수없는 경우 (자신을 타협하려면 열린 마음이 있어야하며 데이터에 대한 해석을 받아 들일 수 있어야합니다) 잘못된 것입니다 그들의 응답에 매우 나타나야합니다. 최악의 경우에도 문제를 확대하기위한 기초로 사용할 수 있습니다.

가장 중요한 것은 시스템 할당에 대한 모범 사례, 특히 SQL 서버에 대한 RAM 및 CPU 예약을 사용하고 있음을 증명할 수 있다는 것입니다.

이 모든 것이 가장 쉬운 것은 적어도 일시적으로 조정을 요청하는 것입니다. 다른 것이 없다면 벤더를 끌어들이는 경향이 있습니다. 나는 실제로 소프트웨어가 동작하지 않는 다른 쪽 끝의 기술을 만족시키기 위해 이와 같은 미친 짓을 해야하는 횟수를 셀 수 없습니다.

이 특정 상황 (VMware 및 애플리케이션 개발자 또는 리소스 할당을 이해하지 못하는 타사가 있는 경우 )의 경우 vCenter Operations Manager (vCops- 필요한 경우 데모 다운로드) 에서 얻은 1 주일 분량의 메트릭을 사용 하여 실제 제약 조건을 찾아냅니다. 응용 프로그램 VM의 병목 현상 및 크기 조정 요구 사항

때로는 경합 시나리오를 처리하기 위해 VM 예약을 수정하거나 우선 순위를 변경하여 완고한 소비자를 만족시킬 수있었습니다. " RAM 경우 | CPU가 꽉, 당신의 VM이 우선합니다! ". 소프트웨어 공급 업체가 실제 분석없이 내 vSphere 클러스터에서 요구 사항을 지시 할 수있게함으로써 나쁜 일이 발생 했습니다 .

그러나 일반적으로 숫자와 데이터가 승리합니다.

Tomcat 응용 프로그램 개발자에게 VM 크기 조정을 정당화하는 데 사용한 예 :

Dev : VM에 MOAR CPU가 필요합니다!

나 : 글쎄, 메모리는 가장 큰 제약이며, 여기에 성능 대 시간의 히트 맵이 있습니다 ... 오후 6시에 수요일이 가장 스트레스가 많은 기간이므로 피크 기간을 지정할 수 있습니다. 아, 여기 지난 6 주 동안의 생산 지표를 기반으로 한 규모 권장 사항이 있습니다.

내가 지원에서 작동하는 데 사용 - 당신이 요구하는지의 일부가 소리를 매우 합리적인 (그리고 아마도 일) : 그러나 그들은 요청하는 자신이 이전에 단지 "성능 향상"을 수행하도록 요청하는 몇 가지 질문이 있습니다

• 당신은 실행중인 적어도 이미 공급 업체가 제시 한 최소 시스템 요구 사항에?
• 최소한 최소 sysreq 인 경우 이미 "권장"시스템 설정에 있습니까?

공급 업체는 100 명 중 99 번 (지원 경험과 고객 / 현장 측면 모두)에서 시스템이 문서 요구 사항과 일치하지 않는 한 성능 관련 문제를 다루지 않습니다. 아마도 1 CPU 및 512M RAM에서 99.5 %의 시간을 잘 운영하는 시스템 일 수 있습니다. 그러나 시스템 요구 사항에 4 개의 CPU 및 4G RAM이 있고 2 개의 CPU 및 1G RAM 만 있으면 더 많은 자원이 할당되도록 요구하십시오 ^* .

특정 임계 값을 넘으면 문제가 마술처럼 사라지는 랩 / 개발에서 찾은 것으로 인해 시스템 리소스를 늘리라고 요청하는 것이 가능합니다. 이 경우에는 잠재적으로 열악한 디버깅의 예이지만 가능한 모든 버그 / 문제 를 제거 할 시간이 없다는 것을 명심하십시오 -일부는 해결하기 만하면됩니다. 바로 여기에 있습니다.

또한보고있는 문제가 "자신의"소프트웨어의 일부가 아니라 다른 소스 (공급 업체, OSS 라이브러리 등)에서 의존하는 구성 요소도 중요하지 않습니다. 나는 크기, BEA 웹 로직 및 스왑 관련이 정확한 상황에 달렸다 Sun JRE를 에서 고객이 몇 년 전.

tl; dr :

요컨대, 지원 팀과 함께 해결책을 찾을 때까지 필요에 따라 에스컬레이션합니다. 그러나 제안 / 디버깅 단계 중 일부가 벽에서 소리가 나거나 무의미한 소리가 나더라도 놀라지 마십시오.

^{* _{이 경우 정말 당신이 그것을 입증 할 때까지하지만, 그 길을 밀어하지 않습니다하지 않는 것 - 그 여분의 자원을 "필요"하지 않습니다, 당신은 향후 버전에 대한 문서 버그 / RFE를 제기 할 수있는 장소에서 가능성이있어} ^ _문제는
^ _{당신이 쓴 eBook : 소프트웨어 시스템 디버깅 및 지원}}

티켓을 에스컬레이션하거나 다른 담당자를 요청하십시오. 현재 지원 수준이 문제를 적절하게 해결하지 못한다고 생각하는 경우 공급 업체에 따라 에스컬레이션이 도움이 될 수 있습니다. 그들이 확대하지 않으면 다른 담당자를 요청하면 도움이 될 수 있습니다. 왜냐하면 "모든 정당화"가 훨씬 덜 필요하기 때문입니다. 왜냐하면 현재 필요한 것에 만족하지 않기 때문입니다.

대형 벤더 인 경우 티켓을 닫고 동일한 문제로 새로운 티켓을 개설하면 다른 담당자에게 라우팅 될 수 있지만 작동하지 않을 수 있습니다.

당신은 또한 당신의 입장에 서서 더 많은 RAM / vCPU가 어떻게 도움이 될지에 대한 이론적 근거를 요구할 수도 있고, 더 많은 RAM / vCPU를 제공하여 그것이 도움이되지 않을 것이라는 것을 증명할 수도 있습니다.

나는 내 두 센트를 던질 것이다. 우리는이 접근 방식으로 상당히 성공했습니다. 모든 사람이 훨씬 더 나은 결과와 좌절감을 줄입니다. 그것은 비난 게임보다 훨씬 더 많은 노력을 필요로하고 맹목적으로 자원을 추가하지만 근본적인 문제를 찾을 가능성이 더 큽니다.

공급 업체 지원 계약으로 뒷받침되는 온-프레미스 앱에 심각한 문제가 발생하고 공급 업체가 닷지 셔플 링 댄스를 시작하면 (더 많은 CPU 또는 RAM에 대한 비 데이터 중심의 요구가 항상 포함되는 것처럼 보입니다) 이 3 가지를하십시오 :

1. 시스템 다운 동등성에 우선 순위를 확대하십시오. 일반적으로 문제가 발생하지만 기술적으로 "작동"하더라도 효과적으로 사용할 수 없다고 설명하면 일반적으로 취소됩니다. 그것을 해결하기 위해 심각한 문제로 취급하십시오. 여기서는 모든 이해 관계자로부터 상태 업데이트를 받기 위해 매일 만나는 호랑이 팀이라고합니다. 일반적으로 공급 업체는 변경을 요구합니다. 제품 시스템 인 경우 문제가 있지만 도움이 필요하면 문제를 격리하는 데 도움이되는 책임을 받아 들여야하므로 테스트를 실행할 수있는 개발 / 준비 환경이있는 경우 도움이됩니다.

2. 실험실에서 문제를 격리 할 수 ​​있도록 공급 업체에 환경을 복제 할 것을 요청하십시오. 필요한 경우 일부 클라우드 환경에서 호스팅 할 수도 있습니다. 환경과 정확히 일치 할 필요는 없지만 이상적입니다. 요점은 VENDOR가 적극적으로 문제를 복제하려고하므로 사용자 대신 시스템에서 추측을 테스트 할 수 있다는 것입니다. 복제 된 환경의 다이어그램, 사양 등이 제대로 작동하는지 확인하도록 요청하십시오.

3. NDA에서 실제 데이터 세트를 제공하여 추측하는 대신 실제 데이터 세트를 실행 / 재생할 수 있도록하십시오. 우리의 경우 대부분의 공급 업체 제공 앱 문제 (일시적 및 만성적)는 종종 공급 업체 제공 데이터베이스와 관련된 문제인 것으로 판명되었습니다. 나는 우리가 이것을 한 횟수를 세지 못하고 마침내 실제 데이터에서 예기치 않은 무언가로 문제를 정확히 지적했다. 2 년 전에 앱이 완전히 변환되지 않은 앱 업그레이드의 이상한 아티팩트; GC 설정에 문제가있는 오래된 레코드; OUR 데이터 값이 공급 업체 코드 등에서 일부 변형 변형 루틴을 위반하기 때문에 쿼리가 제대로 작동하지 않습니다. 우리 스스로 절대 식별 할 수없는 것들.

우리는 지난 몇 년 동안 몇 개의 벤더와 함께이 작업을 수행했으며, 처음에는 그렇게하는 데 매우 저항 적입니다. 그러나 그것이 작동 한 후에는 벤더와 함께 분기 별 리뷰에서 항상 긍정적 인 하이라이트로 나타납니다. 또한 이러한 공급 업체와 기술 관계를 강화하는 데 도움이됩니다. 그들은 모호한 문제를 원하지 않습니다. 그들은 제품을 개선하기 위해 분석 할 수있는 특정 문제를 원합니다.

제안이 도움이 되길 바랍니다. 나는 그것이 하나의 크기에 맞는 접근법이 아니라는 것을 알고 있지만, 스윙 할 수 있다면 가치가 있다고 생각합니다.

진짜 질문은, 누가 책임지고 있는가입니다. 현실적으로 다른 공급 업체로 전환 할 수 없다면, 그들에게는 힘이 있으며, 실제로 할 수있는 일은 그들이하는 말과 함께 가고 그것이 해결되기를 바랍니다. 행복한 상황이 아닙니다! 그렇지 않으면 다른 담당자가 말한 것처럼 다른 담당자에게 요청하는 것이 좋지만 서비스에 만족하지 않으며 업무를 수행 할 수없는 경우 다른 곳을 살펴볼 것입니다.

작동하지 않을 것이라고 확신하는 경우 "제안 된 조정"을하지 마십시오. 장기적으로 당신을 해칠 수있는 관계에 대한 패턴을 설정하기 때문입니다. 당신은 그들에게 서비스를 제공하기 위해 돈을 지불하고 있으며, 그들은 내 집을 페인트하기 위해 고용 한 사람이 어떤 색이 될지를 지시 할 수있는 것 이상으로 당신의 행동을 지시 할 수 없어야합니다.

이것은 매우 중요한 문제는 아니기 때문에 과감하게 들릴 수 있지만, 사소한 일로 주변을 엉망으로 만들면 큰 일에 대해 똑같이 할 것입니다. 마지막으로 원하는 것은 6 개월 동안 끔찍한 찰리 폭스 트롯을 겪고 나서 공급 업체와 같은 문제를 겪었습니다.

마감일로부터 이틀이 걸리고 모든 것이 깨질 때 지금 문제를 해결하기 위해 취한 조치가 모두 잘 작동하는지 확인하십시오.

공급 업체 측에서 의견을 게시하겠습니다.

우리는이 반복적 인 문제를 겪고있는 고객이 있었는데, 몇 시간마다 소프트웨어의 성능이 약 몇 시간마다 떨어지고 몇 시간 후에 다시 돌아올 수있었습니다.

시스템의 bulitin 프로파일 러는 시스템 CPU (또는 메모리) 속도가 예상 2GHZ가 아닌 100MHZ와 같은 역겨운 속도를 나타냅니다. VM에서 제공하는 CPU를 두 배로 늘려도 증상이 바뀌지 않았고 우리가 낭비하고 있다고 생각했습니다.

더 빠른 CPU를 얻을 수 없었기 때문에 (더 많은 CPU는 도움이되지 않음) TEST와 PROD VM을 교환하려고 시도했습니다. 문제는 다음날 TEST에 나타났습니다. 그런 다음 클라이언트 중 하나를 독립형 (서버리스) 인스턴스로 승격하려고했습니다. 서버가 질식하는 동안 해당 워크 스테이션에 문제가 없습니다.

그들은 VM 호스트에서 성능 문제가 없음을 나타내는 보고서를 작성하고 응용 프로그램 문제라고 주장하기 위해 다시 시도했습니다.

마지막으로 나는 [엔지니어] (전용 지원 역할을 가진 사람들의 지원이 전혀 없었 음)는 물리적 상자를 특별히 요구했습니다. 고객은 피의 살인을 외쳤지 만 다른 잠재적 인 해결책은 없었습니다. 아시다시피, 문제는 마술처럼 사라졌습니다.

우리는 문제가 무엇인지 찾지 못했습니다. 모든 벤치 마크 프로그램은 정상적으로 표시되었지만 애플리케이션 프로파일 러는 컴퓨팅 리소스가 충분하지 않다고 말합니다. 프로파일 러에서 찾을 수있는 특정 서명이 있습니다. 우리가 그것을 볼 때, 우리는 문제가 VM 상호 작용이라는 것을 알기 전에 알고 있지만 당시에는 알려지지 않았습니다.

그들은 확실히 내가 그것으로 가득하다고 생각했습니다. 나는 아니었다. 나는 옵션이 없었다.

몇 년 후 수정, 업데이트 :

점점 더 많은 고객이 VM에서 실행하기를 원하고 경영진이 모든 비용으로 문제 해결을 기꺼이 시도하면서 VM 하드웨어가 양호했습니다. 512MB RAM이있는 두 개의 단일 코어 VM에서 사용자 공간에서 실행되고 권한이 필요없는 특수한 VM 레코딩 프로그램을 구성 할 수 있었으며, 이는 4 개의 단 하나의 다른 단일 코어 VM에서 1/3 메모리 성능을 소모 할 수있었습니다. VM 호스트에서 16 개 중 총 코어가 사용되며 대부분의 램은 여전히 ​​사용 가능합니다. 이 프로그램은 경보를 발생시키지 않았으며 메모리 액세스 속도가 느리다는 점을 제외하고 VM 호스트 나 게스트에서 평소와 다른 것을 보여주지 않았습니다.

이제 고객에게 VM에 문제가 있으며 소프트웨어가 아니라는 것을 알 수 있습니다. 우리는 여전히 VM 호환 소프트웨어에 대한 고객의 요청을받습니다. 경영진이 왜 지원을 통해 동일한 호스트의 다른 모든 VM 속도를 늦추는 소프트웨어를 개발할 수 없었는지 궁금합니다.

무서운 것은 관련된 기술이 잠금없는 동기화를 포함하는 잘 알려진 프로그래밍 기술의 간단한 변형이라는 것입니다. 수백 개의 소프트웨어 공급 업체가이 VM 드레 이너를 소프트웨어에 포함시킬 수 있으며이를 모를 수도 있습니다. 인기가 높은 원자 명령 잠금을 얻는 것은 드물지만 불가능하지는 않습니다. 그중에서도 재미있는 부분은 ACROSS VM과 경쟁 할 수있는 기회를 얻은 것입니다.

지금까지 언급 한 방식과는 매우 다른 접근법을 제안합니다. 공급 업체와 논쟁하기 전에보고 된 문제를 자세히 살펴보고 그 내용을 확인하십시오.

보고되는 실제 문제는 무엇이며 사용자의 기대치는 무엇입니까? 사용자가 "너무 오래 걸린다"고 말하면 정확히 '그것'이 무엇인지 (따라서 재현 할 수 있는지), 얼마나 오래 걸리는지, 왜 그렇게 오래 걸리는지 생각하십시오. 기대치가 합리적 일 경우, 수행하려는 작업의 실제 성능 및 시스템 영향을 측정하십시오. 시스템이 한 달에 30 % 급등했다는 것이 사용자가 쿼리를 시도 할 때> 100 %에서 실행되고 있지 않다는 것을 의미하지는 않습니다. 공급 업체에 CPU 및 메모리에 문제가있는 작업이 발생하지 않았 음을 입증 할 수 있으면 공급 업체에 비용이 많이 드는 권장 사항을 정당화하도록 요청할 수 있습니다.