一位雲架構師用服務打動客戶的故事之七「騰訊雲·如何在臨場用服務拿下甲方Boss承認?」

距離上一篇文章有好久了,確實一直想保持這種節奏,但一直出現‘脫更’的狀況實屬無奈。除我的工做的調整以外更可能是由於處處出差‘飛’的狀態。web


時間越久,越是發現技術和溝通的兩把武器,技術在技術人員身上是沒有問題的,可是在溝通上問題極大。雖說‘自古套路得人心’,但初心總歸是好的。
在國內,目前有很是的作雲計算服務的公司,今年格外多。尤爲是伴隨華爲雲發力、AWS發力和各種公有云在基礎架構上的‘白菜價’上,對‘遷移、上雲服務、對持續運維服務’上有簡單而又粗暴的需求。
由於信息敏感問題,最終用戶以「用戶」簡稱、本身的公司以「公司」簡稱。若是您是我文章中提到公司的管理者,且認爲文章表達措辭不當,請及時聯繫我進行刪除或者修改數據庫

郵件聯繫方式:allen_junjun@hotmail.com後端


這次交流,側重與業務線的交流和溝通,這裏不會分享技術原理。文章已經過內部團隊脫敏審覈,請你們放心閱讀:)緩存


分享形式將會使用‘對話形式’,最大化的還原我做爲偏業務線(架構師)臨場與客戶溝通時候的心理變化以及應對策略服務器



如何與不懂技術的強勢甲方boss溝通並得到承認?


本次交流重點簡述架構

  • > 一次救場的溝通記錄(這次分享內容)
  • > 顧問式銷售的三把‘武器’
  • > 服務產品的博弈

☆首先描述下背景(分享會首次使用對話的方式還原場景)


講起來也挺有意思,當天我的行程是下午7點的飛機(飛往古城西安),由於須要出差四天,因此我當天的穿着是運動裝(相似健身房裏的那種穿法),遠去一看不認識還覺得是準備去打籃球,因此極其不適合見客戶。
Sales提早安排了客戶在公司的騰訊雲辦公室見面會談,起初是咱們的倆位同事過去接待的,因前期交流時就是正常的流程:聊需求、聊解決方案,很正常的交流過程。併發


Allen心裏旁白:如今回想起來,確實任什麼時候候不能光憑感受去評估,仍是作最全的心理準備和預期才行,不然就像這一次同樣。
在交流半小時後,咱們的sales上樓從會議室把我叫出來了,告知須要我臨時過去‘解答一些技術問題什麼什麼的····’‘什麼?!!我一身怎麼見客戶?’,沒辦法!搞不定了,要救場,必須上了,我快速脫掉帽子,整理了下頭髮,穿上外套就過去了。
負載均衡


☆會議室場景復原
客戶四位面對會議室進口而坐,咱們四人面對面坐着。進來就有種撲面而來的緊張感,彷佛前面有些沒聊好,第一時間能感受到沒關注用戶的表達。
框架


致命提問1—給我一個總的預算,而後每一項標註清楚


Allen心裏旁白:很尖銳的話題,一上來就問了個問題!沒前沒尾的,同事信息有限的讓我略有心慌不知所措,這裏我用對話的方式還原場景給你們覆盤下這個現場狀況運維


進入實際場景:
C-BOSS=對方最大老闆
Colleague=同事
Allen=我
Customer:對方其餘人


Allen:抱歉,抱歉,各位領導。我今天出差,因此穿的很不正式。很是很差意思,失禮失禮,‘這個話題!抱歉,咱們前面沒參與,不少信息沒有交互。能勞駕您再與我細緻的再複述下‘痛點和需求’和‘大體預算’的數字。


Customer:是這樣的,大概是這麼需求‘咱們想作個30-200W併發’的APP,依大家的專業經驗,是否能幫咱們評估下大概多少錢?


Allen:emmm…..您能再詳細說下這個APP的業務類型嗎?好比;社交、企業商戶、電商等等


Customer:咱們是一家作人力專業資源服務的公司,考慮作一我的力資源的服務APP


Allen:是相似Boss直聘、前程無憂、獵聘、拉勾網這類APP應用嗎?


Customer:對的。


Allen:明白了,那您大概能告訴我,這個APP用戶量級的規劃嗎?在哪個階梯中?好比;500W


Customer:你就當差很少50000W-1億的用戶體量吧,咱們在前期差很少至少能達到3000W的註冊量吧,併發能到30W-50W併發量的樣子,你看看好勒。


Allen:好的,瞭解了。提一句體外話,您這邊的軟件開發商是公司自建的團隊,仍是使用的外包服務團隊?


Customer:外包的,這個事情確實有點讓人不開心,這個APP,咱們開發時間花了將近兩年,並且由於不少合同邊界沒有提早商定清楚,致使一直說有些額外的開發內容須要不斷的補充費用,弄的確實不開心。因此咱們這不是咱們老闆親自也過來了嘛,也是能在一會後面的溝通中,咱們能聽一聽大家對服務這個事情上的一些專業指導和經驗。


C-Boss:咱們實際上是衝着騰訊雲來的,但事先實際上是不知道這邊是服務商(代理商)。


Allen:嗯哈哈,騰訊雲總部在漕河涇那邊。咱們是華東區較有表明性的騰訊雲的服務商。存在的價值主要就是像今天同樣‘坐下來跟您(用戶)一塊兒探討交流,幫助用戶理解騰訊、更好的使用騰訊雲,同時咱們能支撐您後端全部的運維管理工做,這必定程度上避免您須要花比較多的學習成本去學習,或者去招人解決騰訊雲的各種技術運維話題、構建問題了’


Allen:其實您也是管理公司’菜米油鹽’的領導,每一次項目上成本的上升和額外支出都是其實很敏感的,咱們這裏也是。每次提交未預見突發計劃產生的成本,就特別敏感,特別是提headcount的事情,恩哈哈~~~


Allen:對了,聊到這裏,在這個APP開發的過程中,您這邊是如何管理外包團隊的,是專業的項目經理參與管理仍是僅限在合同協議上?


Customer:咱們Selina在負責,就是這位。(說罷,揮手示意了下左手邊的美女)


Allen:噢噢噢,是偏管理上的協調,仍是會盯到特別細節,好比:某一個技術細節這類的管理?


Selina:就是協調管理下,我不是技術,因此沒法盯的這麼細緻。
Allen:好的,明白了,那也就是說,若是我如今想了解您這邊的軟件開發構建框架、技術選型等,這會估計沒法聊的,是不?


Selina:對的。


Allen:那您這邊可否幫我演示下您APP如今的樣子,我看一下里面的業務模塊啊什麼的,同時您幫我講講,用戶/管理員如何如何使用這個APP、您的後臺管理端是什麼樣的、APP是如何產生業務收益的?等等


Selina:這樣吧,我打開手機給你看下好了。
(‘我和其餘兩位同時一塊兒觀看了這個APP的演示和一些用戶的使用過程分析,包括後臺管理端存在一些數據分析的功能等等’)


Allen:好的,我大體能瞭解到您這邊APP的業務邏輯和體現構造了。圖片、文字的交互比較多(無非就是刷簡歷,找工做,彼此介紹工做,),因此您這邊能幫我確認一個事情不,好比圖片的訪問是與應用服務器分離的嗎?好比;咱們圖片和訪問登陸流量是分離的。


Selina:這個,我不知道誒,估計要找技術那邊問了。


Customer:這是有什麼講究嗎?


Allen:有的,採用傳統物理基礎架構構造,是經過一些功能的切分區分各類服務器的功能。好比圖片的反饋全是直接經過web應用服務器反饋到用戶端。即:‘web應用程序的帶寬、IO性能是典型的瓶頸潛在對象’,一旦你的圖片沒有通過一些壓縮等優化,對外的web服務器帶寬可能被圖片的大量返回和調用佔滿,從而影響用戶的APP體驗。


Allen:其次呢,咱們這一次聊的背景自己是採用雲計算的方式部署應用系統,故綜合雲的優點會將構建進行必定的架構優化,這是面向雲計算的正確使用作法。因此在前面的這個問題上,咱們會使用雲上的對象存儲去「剝離」這部分圖片的返回的帶寬流量,加上對象存儲不存在單點故障,接近不存在IO瓶頸,並自然擁有無縫對接CDN的加速特色。這樣用戶將會打開更快的同時又不佔用web應用服務器大量帶寬。由於您大概能知道,雲上帶寬是最貴的。


Allen:講究也不算,這實際上是任何一家作雲管理的服務商最基本的能力。由於您問了不少專業的參數測算值,出於嚴謹和對您負責,咱們大膽的探討假設的同時,須要的是謹慎的求證才行,我這裏須要您比較多的關聯信息來支持個人判斷,因此您看看能不能再幫我詳細一些。


Customer:這可能無法知足你,咱們自身原本就不是專業的,因此過來找大家來聊也是這個目的。想聽取大家專業的意見。因此你不要再問很技術的問題了,咱們無法給到你,根據大家的專業意見,幫助咱們來看下大概多少預算吧。


C-BOSS:大家這樣,就告訴我根據你的實踐,咱們這個APP在騰訊雲咱們須要花多少錢,好吧。咱們也沒帶軟件商過來。幫咱們把每個資源對應的費用都現場拉出來,咱們來一項一項來看。


Allen:emmmmm,明白了,現場咱們就能夠拉價格的,由於價格在官網都是公開的,咱們這就邊回顧最佳實踐以及如今的狀況給到一個基礎架構資源的評估


Colleague:好的,我來拉給您現場看下(這個時候,咱們邊聊邊解釋我爲何要用這個資源,例如:爲何要用負載均衡、爲何要用waf應用防火牆、爲何要買八臺而不買2臺)


C-BOSS:咱們也會須要過等保的,因此大家要結合這些一塊兒來考慮。


Colleague:好的,明白
(隨後我帶着同事一塊兒follow等保的要求產品須要,和一些最佳實踐把雲資源作出來,客戶考慮後,以爲太貴了,暫時不考慮。)


致命提問2—大家告訴我這些產品是幹嗎用的?


• 問題2)爲何使用負載均衡、爲何讀寫分離、爲何須要緩存服務器?


Allen心裏旁白:這個看似很日常的問題,但實際很是要當心,其中陷進不少。咱們都知道越是看似簡單的問題越是能提現出甲方想觀察你對基本的事情理解深度。又或者這位提問者是明白的,只是‘揣着明白裝糊塗’看看你的專業度狀況,這個過程當中除了‘潤物細無聲’體現咱們的專業能力的過程以外。更重要的技巧是你還要用最最最最通俗的語言翻譯給這些領導。
(咱們在邊講邊介紹的過程 中,用戶老闆不時有打斷並質問爲何?好比下面)


C-BOSS:這個負載均衡是幹嗎用的,爲何咱們要用呢?


Allen:這個是必須的,不僅您這邊,任何一家大企業部署生產業務都不能忽略這個產品。舉個例子:這個房間是一個大門對吧。咱們如今一個一個進來是沒有問題的。可是若是有不少人同時一塊兒並排進來怎麼辦呢?是否是就是會產生擁擠的狀況。


Allen:那咱們更進一步比喻,若是把咱們如今的這個騰訊雲會議室比喻成一個應用系統,把這個‘門’比喻成咱們應用程序入口,也就是‘公網’。那是否是就會出現用戶量不少,可是沒有辦法同時一塊兒進來。由於門並排最多同時一塊兒兩我的進來。


Allen:那今天,您把這個問題交給咱們,咱們就用技術構建的維度解決這個問題。


Allen:傳統的作法,是否是會告訴(建議)您,多放幾個這樣的騰訊雲會議室嘛。這樣不就解決了嗎,這有什麼難的?!!,您說承認這個說法嗎?
C-BOSS:emmm,不難,就是這麼弄的


Allen:那麼第一個問題來了,誰來告訴進來的人,這兩個房間均可以進呢?對,指示牌或指示人嘛。因此咱們在提早設置一個指示牌或者人來指引,這兩個房間均可以進去的,請根據本身洗好選擇進去好了。第二個問題也來了,若是其中有一個房間裏有一半凳子壞了,這個時候指示牌沒有辦法主動發現並解決這個問題。可能當人(指示牌)被動發現問題臨時說,大家快去第二個房間吧。


C-BOSS:對,是這麼個邏輯


Allen:emmm,這個指示牌或人用技術的思惟去思考就是‘負載均衡’,這裏凳子壞了就比喻爲‘應用程序故障’,我這麼講您能明白不?
C-BOSS:能明白。


Allen:可是您提早放一個‘智能’的人,提早告訴他這裏有10個騰訊雲會議室能夠用,您根據這個‘智能’的人,提早預設好的規則和策略,按照該規則去分配,同時你會議室想臨時拿走或增長、或者會議室凳子壞了。這個智能的人都能發現和感知,咱們把這個動做比喻爲‘故障自動檢測’的過程


C-BOSS:好的,這個我能明白是作什麼的了,那什麼讀寫分離是什麼?這個技術必需要嗎?


Colleague:是的,這個有利於緩解您的數據庫讀寫壓力。


C-BOSS:……嗯?


Allen:是這樣,我同事解讀的很是正確。我幫您解讀下這個使用場景,不恰當的比喻啊,或許您就能明白這個是幹嗎的了。仍是前面的這個場景,會議室是應用程序,門是公網入口,凳子是實際的‘用戶’進來要坐的(用得),我這個比喻能理解否?


C-BOSS:這個能理解


Allen:好的,咱們更進一步,那請問在公司組織管理上,是否是會各類部門,部門內部是否是有各類工種的分類,這個您是專家,畢竟是作人力資源的企業。因此咱們這個時候引入‘場景’的概念。回到會議室(會議室比喻成應用程序),是否是會有像我這樣的用戶‘反正就是天天(進來會議室)登上來查詢下本身的簡歷被多少獵頭看過、看看新聞’等等。


Customer:啊哈哈哈……


Allen:這種人不少的,我就屬於這種,恩哈哈,,,不過話題說話來。這確實是一種場景。


C-BOSS:哈哈啊,是的


Allen:好,那是否是還存在一種這樣的人,剛註冊或者要頻繁修改本身的簡歷信息的。


C-BOSS:是的


Allen:emm好的。那咱們把這兩種比喻成兩種不一樣的‘場景’,對應到前面我所說‘凳子’,因此我會根據實際用戶的真實使用場景的頻度來提早安排‘凳子’的分配。好比每天查本身簡歷被多少人看過的客戶,在您的用戶羣體中佔比80%,那我是否是就須要爲這些用戶多準備一些資源(多準備一些凳子)讓用戶使用。


C-BOSS:是的,就是這個意思。


Allen:那咱們這個時候,若是咱們這個會議室中放置‘兩種場景’的用戶,是否是對這個地方的管理會增長難度和壓力,即:又要顧着查詢量又要幫着存儲修改後的簡歷數據。若是按照如今這個會議室,我可能只能專心的聽您說,不能同時兼着處理另一位的疑問。因此我這邊描述,您是否明白我想表達的意思?


C-BOSS:好的,彷佛明白了,是否是至關於我將用戶場景提早分類,而後把壓力作一些合理區分。那這裏有個疑問,兩個場景只查詢的數據和作修改的數據,是否能保持一致呢,不然不就有問題呢?


Allen:好問題,這個‘讀寫分離’的技術在誕生的那一刻就要解決這個問題,因此目前各大廠商這類技術(PAAS數據庫產品)幾乎徹底接近沒有延遲,兩邊的數據在同可用區幾乎接近實時保持一致。


Customer:咱們明白了,謝謝了。那再好比緩存呢?這個是解決什麼問題?
C-BOSS:這個是否是就是好比啊;咱們提早把一些可能涉及的查詢數據提早算好,而後用戶登陸進來後,就能夠提早拿到了,不須要進去數據庫裏面查詢了。好比:咱們的後臺程序管理界面,天天一打開都會看到有多少登陸量,相似這樣的數據,就緩解了數據庫的壓力。


Colleague:沒錯的,就是緩解數據庫壓力的設計


Allen:您這描述看起來不像不專業的啊,這個解釋很專業了,啊哈哈哈···我在您的基礎上補充一下,這個緩存產品是在原有數據庫讀寫分離的基礎上,再次下降了數據庫的讀的壓力。


Customer:恩哈哈哈……………..


Allen:您這個補充,着實是真的專業(我豎起大拇指了,比劃了一下)
(隨後還補充了一些WAF和主機防禦的場景介紹,這裏就不詳細贅述了)


致命提問3—APP故障了,大家怎麼賠償?


第三個問題,也很突兀。這都是什麼問題!!!但實際是咱們在平常陌拜或者會議中常常出現的提問,合同關係是跟咱們發生的。若是是錢付給咱們,那騰訊雲是否會拒絕向我賠償,必定要經過大家來申請賠償呢?
• 大家爲咱們APP運行兜底嗎?好比故障,大家要積極解決以外,故障過久要賠償的這種兜底。


不少新手在這種對話場景中,常常會出現一些不專業和不知如何應對的問題?且感覺下我是如何應對的


Allen:您這邊具體指什麼故障?


Customer:全部的故障,既然委託給大家了,那就是全部的故障都包含了。
Allen:是啊,作雲服務必需要積極面對和處理基礎故障並承諾超出故障時間的賠償金,但有些故障確實不是咱們能左右的,好比;公有云自身物理機房斷電故障致使業務瞬斷、又或者剛好您的業務就在這個斷電的機架中,致使宿主機遷移影響了業務5-10秒的時間,再好比運營商對外出口線路光纜被市政施工意外挖斷了,還有颱風啊等等。


C-BOSS:大家不是華東區最大的騰訊雲服務商嗎,咱們跟你籤合同,騰訊雲的故障就應該大家承擔,否則要我找誰賠償?合同跟大家前的,找騰訊應該不認吧?


Allen:(我打開一個公有云責任共擔模型),解釋各個責任歸屬問題的同時,也具體的理清了一些不可抗力的故障:地震等天然災害。另外再次強調了服務商在三個角色中的責任(用戶、服務商、騰訊雲),同時解釋了基礎設備硬件致使的故障騰訊雲是根據公開承諾的協議文件進行賠償的,這一點不會隨着您跟服務商或者代理商籤合同就會發生‘責任轉移’,這一點您放心,另外這個賠償(合同)協議騰訊雲官網都是公開的。若是您仍是擔憂,咱們能夠將這個協議文件以附件的形式依附在合同裏,您看這麼處理,是否定可?


C-BOSS:那這樣說,我直接找騰訊雲不就行了,幹嗎非要跟大家前呢?
Allen:呃。。沒錯的,固然是能夠直籤,這個徹底取決您的意願,但提示您,如今這個雲計算大熱的背景下,爲何咱們這樣的服務商存在並且還活的很好,並且原廠也很是依賴咱們。這側面也印證了它並無辦法關注到全部用戶的交付,每個客戶都有本身獨到的場景需求,廠商不可能樣一萬數量級的客服人員,一萬數量級的交付人員。何況騰訊雲也好,阿里雲也好,AWS也好,他們的客戶量都是解決百萬級的。


Allen:加上原廠的單我的力成本都高,那~您是作人力資源行業的也是大老闆。您確定能明白好資源要用在重要(高回報)的地方。舉個例子;您這邊前面通過一些測算,一年總共的雲資源在20W左右。那假設我做爲騰訊雲sales,評估一對一服務20W的客戶與服務一個200W的客戶,頗有可能成本是同樣的。那請問我有什麼動力來支持您呢?


C-BOSS:那我選阿里,選華爲不就行了,華爲雲如今服務也挺好,就像你說的端到端的這種服務。


Allen:固然能夠選,咱們也作阿里雲、華爲雲,甚至也作亞馬遜和微軟雲。坦率的給您彙報一下吧,今年2019年人力成本的上升就是全部企業都在頭疼的問題。我相信您也頭疼!每家都實際上是同樣的。哪怕他如今確實給您作很一對一的服務,但隨着它的業務量上去,它(廠商)必定會作一些取捨的。對吧,領導~


Customer:好的,咱們明白了,那大家能夠負責哪些故障呢?能承諾什麼呢?


Allen:咱們一直跟您聊運維管理服務,可是一直沒有不知道您對這個有不少的不明確的地方,抱歉哈,這是咱們的問題。我來給您詳細解讀下,咱們到底作哪些事情,能夠承諾什麼?


Allen:所謂運維管理服務,其實不恰當的比喻爲‘維穩部隊’,那給您開發APP的團隊呢呢,咱們比喻爲‘武器生產部門’,咱們對這個武器的‘運行’負責,不對您的‘武器’生產質量負責。可是咱們做爲武器運行的‘維穩部隊’,咱們在平常行動中會使用這些‘武器’。那咱們必定知道這個‘武器’運行的穩定與否,以及解決問題的實際效果如何,我這麼表達您看是否合理?


C-BOSS:沒問題,我能理解。


Allen:前面說的,我對‘武器’的正常使用負責,開發團隊對武器的功能開發負責。因此這個武器功能也就是眼下咱們談到的APP應用,在運行時候,咱們會幫助您管理他的運行狀態(異常等)、容量等一系列須要關注的指標等問題。若業務量上去了,咱們清晰的知道該如何正確迎接業務峯值壓力。


Allen:對現有資源進行基礎架構調整(或提早預留水平/垂直擴展的架構),優化APP在峯值突發運行時的訪問和基礎架構服務的健康性。但如果由於APP自己代碼開發設計問題致使運行緩慢(異常),咱們會盡量快的協助您的開發團隊找到問題緣由,而後與您的開發商一塊兒面對並克服該問題,但產生該問題的主因是代碼質量的問題,咱們沒法提早干預,因此咱們只能盡力幫助,沒法承諾爲此負責。


Allen:簡而言之,你能夠把咱們比喻爲家政服務中的保姆,咱們沒法承擔房子結構不合理、塌陷、漏水的責任。我不知我這樣描述,你們是否能理解這個。另外這是咱們的服務清單,各位一塊兒過目下。(sales將服務列表打印出來後,咱們隨着客戶一塊兒過了一次)


Customer:好的,咱們看看,挺好挺好。。


C-BOSS:咱們如今這個開發商啊,每一次調整功能就要收錢,特別不能理解,並且弄的特別不開心,咱們雙方。因此咱們也是但願能更細緻點,這樣也好。


Allen:您究竟是領導啊,很強。


Allen:咱們也是同樣,畢竟如今愈來愈多的強調‘專業的人作專業的事情’,肯定成本能獲得較好的控制下,讓用戶不要太擔憂責任邊界不清晰致使的額外付費等等。不過坦率的說,在這點上對您自身公司的對接人綜合能力要求較高,要懂不少。


C-BOSS:是的,小夥子你很專業


Allen:聊了這麼一會,我確實能感受到您以前受了很多傷害,我很是但願能幫助您這邊扮演好這種‘連接器’職能的服務商,由於不少的日企都是這樣找到咱們的,並以這樣的形式所有委託給咱們。因此,感謝您給咱們一次介紹本身的機會,也挺期待近期咱們能依據今天的溝通,將商務、最終價格清單有更好的進展溝通。


Allen:MC(sales名字),你看我遺漏哪些尚未談到的內容。


Sales:都探討了,謝謝你。X總,P總,您看還須要咱們作哪些補充?要是沒了,咱們今天就暫時先到這?


Customer:好的,暫時沒有其餘問題了,咱們先這樣。
(主動過去握手,再次抱歉我今天着裝是這樣子,很是期待下一次與您溝通)


回顧一下,問題提出

思考今天分享的這個案例前半部分中,我提到的三個問題。加入這個救場的人是你,你會如何考慮和應對的?如何提早保證內部團隊的‘唱跳’搭配。


☆貴在堅持,請努力!
謝謝各位的閱讀,又進步了一些,天天進步一點點,下一次


Allen人生格言:越努力,越幸運~~

相關文章
相關標籤/搜索