簡介：大家好，交付鐵三角帶著全新的故事來啦！一直被應用交付難題所困擾的他們這次又遇到了新的難題，售前大佬的一句客戶資源規劃緣何讓開發鐵子暴怒，交付小錘的勸架為何致使自己的交付團隊陷入這場漩渦之中，在客戶現場慘遭客戶對交付質量的質疑。在這場風波背后，又隱藏著怎樣的破解之法，幫助他們重歸于好？快來點擊下方文章了解吧！

作者：新鈺

大家好，我是專注交付的王小錘，與開發老哥鐵子還有售前大佬強哥組成的“交付鐵三角”團隊，我們又來啦！

我們 “交付鐵三角” 服務于一家提供大數據分析服務的 ISV 企業。通過對客戶提供的大數據，進行多維度智能化分析，提供用戶畫像、潛客分析、銷量預測等信息，將數據價值最大化后給到客戶，助力客戶通過分析結論達到最大的市場收益。近年來，出于對數據安全性以及安全合規等方面的考慮，選擇私有化交付的客戶越來越多，而他們的要求也變得復雜多變，無形中我們被迫面臨各類復雜的交付環境，同時產品交付壓力與日俱增。

這不，一直被軟件應用私有化交付問題困擾的我們，近期又碰到了新的交付難題，為此還鬧的不歡而散。

兵馬未動之糧草準備多少？

起因

故事是從那天強哥的抱怨開始持續發酵的，那天強哥一臉的沮喪回到公司，拉著鐵子就問能不能給他一份清單，讓他帶給客戶。好讓客戶知道要是用咱們的 SaaS 產品，需要買多少設備，準備多大的硬盤？咱們的產品會占用多少內存空間？他抱怨道：“因為客戶需要處理的數據量很大，所以最近對資源的使用情況變得格外敏感?？蛻粝Ｍ麑⒚恳淮缳Y源都用在刀刃上，像是客戶自身有 MySQL、Redis，或者已經在使用一些云上資源，那么就希望能將這些資源做到合理的利用與規劃，或者客戶自身有幾臺服務器，那么他們最不希望，有些服務器配置的很滿，有些卻只使用了一小部分資源的情況發生?！?/p>

今天他去到客戶現場，客戶直接問他要準備多少資源剛好夠用，能不能給個清單。當時強哥一下子被問住了，忙說下次去的時候準備好給到客戶，讓客戶也好有個心理預期。

這時鐵子一聽就不樂意，沒好氣的對強哥說：“你怎么能亂答應客戶呢？和你說過很多次了，我們怎么可能準備的出來這樣的清單，這種很難預估的，我只能說去試試！就算準備出來了，也不會有多準的！”強哥一聽也來了脾氣：“客戶要了好幾次了，我不給的話，這單還要不要談了？”

升級

聽到這里我忙勸架，讓鐵子別激動，這個事情試試，先拿一個出來，然后強哥叮囑客戶先按照這個預估的資源情況的基礎上往大些準備就好了嘛。沒想到，就是這句話，將我們交付團隊帶到了一個個坑之中。

而為了打動客戶，讓客戶感覺不需要花太多錢就可以部署好這個數據產品，鐵子給到強哥的資源規劃清單相對保守些。直到那天，我們遇到一個客戶，真的按照強哥帶去的清單做的準備，竟沒有多一絲資源冗余給到我們。當我們去部署的時候，發現根本不夠部署我們的產品包。因為資源不足導致無法完整運行，最終被迫在現場裁剪產品資源開銷后重新部署，這個過程消耗了大量的時間

于是在客戶現場，就看到我們在反復部署，將環境部署到一半，鏟掉，再去部署。當時客戶就和我們在一起，看到屏幕上反復出現的 delete ，不住的搖頭。那時的我們感覺太挫敗了，后來客戶看不下去了，直言：“你們這個交付包是不是質量有問題啊？這么反反復復的到底還能不能跑起來？” 我們連忙安撫客戶，說放心，不是交付包有問題，是咱們的環境有點復雜需要稍微費點時間調試。而我們心里知道這些話是說給客戶聽的，就是客戶那邊資源沒準備足，我們需要對現在的產品現場調試修改，而我們卻不能怪到客戶頭上。

激化

而不巧的是，我們才交付好后回來沒兩天，客戶一個電話過來，和我們抱怨說這才用了多久，就宕機了。我們出發前，就在猜是不是又是因為資源的問題，他們需要處理的數據量還是很大的，當初部署完留給業務運行處理的空間本就不是很多了。果然，當我們飛過去排查后發現，確實資源不足需要擴容，但是擴容的話，需要將客戶目前的業務中斷。終于，這個舉動導致客戶的怒氣值爆棚，直言我們的交付質量太差。

爆發

當然我們也很委屈，回去后一名交付同學在復盤會，直接將這些話透傳給到開發團隊，進一步導致了矛盾激化。

鐵子立馬反擊說：“話不能這么說，本來就說了這個清單只是參考，我們哪兒想到客戶那么實誠，原原本本按照這個來準備，一點冗余空間都沒準備。而且我們人為一點點去進行的核算，已經都占用我們很多研發時間了，你們還不領情。你們可知道，運行時資源情況會動態改變的，這讓我們怎么來評估，很難得好不好！你們倒是不寫代碼，體諒體諒我們開發同學好不好，不要上來就甩鍋?！?/p>

強哥聽到我們屋內吵起來，走了進來，我原以為他是來勸架的，沒想到他進來后又進行了補刀。他說剛才接到另一個客戶電話，說按照他的清單準備的資源，結果有些機器資源都沒怎么用上，空置在那里了，直接浪費他們的錢，體驗很差，感覺我們很不靠譜。

鐵子聽完我們的集體吐槽，留下一句，說了不好規劃你們不聽，我有什么辦法后推門而出，再也不理我們了。

這已經是我們交付鐵三角不知道第幾次爭吵了，每次都是因為交付時出現的這些問題而吵架，最終鬧的不歡而散。

大戰前夕不來場戰略演練？

盡管吵歸吵，我們的項目還是需要鐵子出包，這天我們還是按照平時那樣，拿著交付包去到客戶現場。到達客戶現場后，我們懵了，交付地點在大山深處的廠房不說，客戶準備的機器還十分老舊。我們去安裝的時候，一直在心里犯嘀咕。好在，盡管客戶的網絡情況比較復雜，機器老舊，我們的部署困難重重，但我們還是順利完成了部署。就在我們準備離開的時候，廠房突然停電了。客戶解釋道：“我們這邊比較偏遠，有時候會動不動跳下閘，沒事，一會兒就來電了?！?/p>

當電力恢復時，如你所猜測的那樣，我們的產品跑不起來了，需要重新啟動幾個組件。當時交付同學就說回去復盤的時候要提一下，你看，就停了下電，斷電重啟都實現不了。

復盤會上，鐵子這樣解釋道：“每次出包前，我們已經進行了反復的驗證，雖然這部分工作耗時耗力，但相對來說我們已經盡力了。盡管這樣我們其實還是無法保證交付包一定能夠容忍很多特定場景的，這個實現起來是很困難的。

另外，線下交付場景中問題的處理大多與環境、配置有關，當由不同的交付人員處理時，每個人處理的環境、產品故障偏向點狀解決。而當遇到新的問題時，需要重新開始排查，摸石頭過河效率較低，那便是你們交付同學的問題了。由于你們并沒有相關知識的沉淀，并未提供給到我們這些信息，為下次演練提供素材和參考，這樣我們只能憑我們的經驗對一些場景進行演練，有遺漏的場景太正常了，這才是問題的關鍵所在。

另外，故障排查數據量大，一個組件出問題排查起來確實很困難，這個也是不爭的事實。但是交付前我們確實進行了充分的模擬演練，已經最大限度的來降低問題出錯的概率了?！?/p>

聽完鐵子各打兩大板的發言，這次沖突雖然沒有激化。但是我們對于鐵子給出的說法并不滿意，會議結束后交付的其他同學拿起電腦頭也不回的走了。而我坐在會議室，看著鐵子在不住的搖頭嘆氣。那一刻，我竟感受到了技術同學一瞬間的絕望和難過。他在強忍著，只見鐵子一手捂緊拳頭一手不停的撓頭，好似下了很大的決心。

兵馬未動之糧草先行

時間不知不覺的過去，直到有一天，鐵子找到我和強哥，喊我們一起吃個飯。吃飯的時候，我們才知道，事后鐵子那個氣啊，于是為了爭口氣，賭上公司研發一把手的尊嚴。拉著開發團隊徹夜分析，發現核心矛盾點如下圖所示，最終導致客戶質疑我們的交付質量。而這一切都源于資源評估這一步，如果把這個技術難點突破了，我們的矛盾便可以解決。一邊生氣一邊研究的過程中，他想到了云原生應用交付平臺 ADP（以下簡稱 ADP），上次拜訪阿莫了解應對軟件應用交付難題的招式的時候，他好像提到過一下，于是他進入 ADP 平臺，看到里面真的有資源規劃能力，經過分析研究，發現可以很好的解決當前這個矛盾。

資源規劃能力

ADP 的資源規劃功能可幫助我們，通過模擬部署能力快速且高效的評估出合適的集群資源配置，如：CPU、內存、存儲分別需要多少，還可以在部署失敗后查看未成功調度的 pod 數以及原因，進行調整，有效降低由人力評估效率低下、動態場景難以統計準確等原因所導致的一系列問題。

三步實現快速資源規劃

1、自動統計產品的實際部署開銷。

2、對擬定的節點資源規格進行仿真調度實驗，得出實際的部署效果。

3、查看調度失敗的 Pod 情況，調整節點資源規格，秒級重試驗證。

鐵子說完這些后，看向強哥道：“你看，以后我們產品適配改造好后，跑一份更靠譜些的資源容量清單給你，你拿給客戶，就讓客戶按照這個準備，還是有問題的話，你來找我，隨便你怎么兇我我都認，好不好？”

強哥聽完邊點頭邊說道：“行，這可是你說的！一會兒你把明天我要去聊的客戶，他的資源規劃清單給到我，我明天帶過去?！?/p>

“好的” ，鐵子邊答應邊扭頭看向我，對我說道：“小錘，強哥前置把客戶那邊搞定，客戶按照清單中的資源情況進行準備。那以后你們交付團隊再也不會出現，在客戶現場反復部署安裝，部署了，鏟掉，再部署，再鏟掉，這樣尷尬的情況了！在信老哥一次好不好？” 我拍拍他的肩膀道：“ 好的老哥，再信你一回！”

不打無準備之仗

關于交付同學提懷疑鐵子他們出包前驗證不充足的事情。雖說鐵子他們心里不服氣，但是想了想，本身交付的場景就是各種各樣的，確實很難做到面面俱到，懷疑開發同學演練不充分也確實是有道理的。于是開發團隊的小伙伴集中起來，梳理了許多的演練場景，然后鐵子又將這些場景在 ADP 平臺中一一查看，發現 ADP 平臺可以自動實現這些場景的線上集成一鍵演練，而且涵蓋的演練場景比他們想到的還要多。

故障演練能力

ADP 提供的故障演練能力可以實現，在線上集成環節即可對線下交付中常見的各類故障場景下產品編排的容錯性、可靠性和可恢復性進行演練，保證編排穩定可靠。

基于線下交付經驗設計的故障演練場景，對基礎設施、底座、中間件的常見故障場景進行覆蓋，無論集群級別的大規模故障還是節點、Pod 級別的資源故障，都可以在線上完成演練，可基于產品在常見故障場景下的問題進行針對性優化。

ADP 故障演練與 AHAS 故障演練產品進行深度集成，演練場景豐富，且可一鍵創建線上產品環境并完成 AHAS 探針接入。基于 AHAS 故障演練產品提供的流程編排能力，可實現常見故障場景的一鍵準備、注入和恢復。使產品在常見故障場景下可以預設其可靠性、可恢復性、告警及時性，大大增加交付信心。

可演練場景如下：

說完這些，鐵子略帶得意的看下我們兩個，問道：“怎么樣，聽完有沒有覺得交付包可靠了許多，信心滿滿？我們開發團隊現在已經在按照這些流程來進行交付了。小錘，下一次交付完記得回來和我反饋，要是交付質量有感覺提升了，體驗棒棒的，別忘了請我吃飯哈！”

“好的，沒問題！” ?聽完鐵子的一番解釋和介紹，我們都覺得這次靠譜了很多，對下一次的交付充滿了期待，于是我爽快的答應了他。

鐵子還說他請我們吃飯前還聯系了下 ADP 的阿莫，和他聊起來這兩個能力，他說現在做的還比較初級，后續在資源規劃和故障演練能力上還會加大投入。

在資源規劃方面，現在提供的是你們部署時所需的規劃清單，但是后續我們為了更加精準，還將引入線上的壓力測試，這樣你們的產品在運行一段時間后是否還能扛得住就清晰明了了，你說的小錘他們部署好立馬又回去擴容的情況可以更有效的避免了。

演練場景這部分，我們后續計劃在交付團隊交付部署好之后，可以讓小錘他們在現場再跑一遍故障演練場景，為交付驗收再加一層保障，做到出包前交付后都進行充分驗證。這樣你們用著也會更放心些，還可以將精力回歸業務發展上。

就這樣，一場兄弟反目的風波就此告一段落。

總結

交付質量提升大法

資源評估—— 帶著合理且可靠的資源規劃清單給到客戶，減少資源浪費、避免資源規劃帶來的業務中斷風險、杜絕反復交付部署情況的發生。

故障演練—— 出包前一鍵演練或者自動化故障演練，做到每個包都千錘百煉，每個可能的故障坑，交付人員心里有數，出問題快速排除與解決。

提到 ADP，上次拜訪阿莫已詳細介紹 ADP 作為一款應用交付的利器，提供以下能力：

全棧式在線化服務：穩定可靠的中間件適配、極致簡化的交付流程。

異構環境全覆蓋：通過集群鏡像實現異構 IaaS 交付、通過應用管控實現異構 Kubernetes 交付、以及面向開放生態的規劃。

穩定可運維底座：ACK Distro 底座、運維管控平臺能力。

上述能力可有效應對我們的產品適配成本高、部署環境復雜、運維低效且門檻高的煩心事，如果感興趣可在文末點擊鏈接，了解上次拜訪細節。

而這次竟然是 ADP 提供的能力讓我們重歸于好，看來是時候再約阿莫他們多聊聊，看看還有什么驚喜，加上上次他埋了幾個小問題讓我們甚是好奇。待我們再次拜訪阿莫后來同大家分享，一起看看還有哪兒些你不知道的事情吧！

獨家交付秘籍之招式拆解（第一回）-阿里云開發者社區

（本文純屬虛構，如有雷同純屬巧合）

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的交付铁三角的故事之兵戎相见的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。