交付铁三角的故事之兵戎相见

简介：大家好，交付铁三角带着全新的故事来啦！一直被应用交付难题所困扰的他们这次又遇到了新的难题，售前大佬的一句客户资源规划缘何让开发铁子暴怒，交付小锤的劝架为何致使自己的交付团队陷入这场漩涡之中，在客户现场惨遭客户对交付质量的质疑。在这场风波背后，又隐藏着怎样的破解之法，帮助他们重归于好？快来点击下方文章了解吧！

作者：新钰

大家好，我是专注交付的王小锤，与开发老哥铁子还有售前大佬强哥组成的“交付铁三角”团队，我们又来啦！

我们 “交付铁三角” 服务于一家提供大数据分析服务的 ISV 企业。通过对客户提供的大数据，进行多维度智能化分析，提供用户画像、潜客分析、销量预测等信息，将数据价值最大化后给到客户，助力客户通过分析结论达到最大的市场收益。近年来，出于对数据安全性以及安全合规等方面的考虑，选择私有化交付的客户越来越多，而他们的要求也变得复杂多变，无形中我们被迫面临各类复杂的交付环境，同时产品交付压力与日俱增。

这不，一直被软件应用私有化交付问题困扰的我们，近期又碰到了新的交付难题，为此还闹的不欢而散。

兵马未动之粮草准备多少？

起因

故事是从那天强哥的抱怨开始持续发酵的，那天强哥一脸的沮丧回到公司，拉着铁子就问能不能给他一份清单，让他带给客户。好让客户知道要是用咱们的 SaaS 产品，需要买多少设备，准备多大的硬盘？咱们的产品会占用多少内存空间？他抱怨道：“因为客户需要处理的数据量很大，所以最近对资源的使用情况变得格外敏感。客户希望将每一寸资源都用在刀刃上，像是客户自身有 MySQL、Redis，或者已经在使用一些云上资源，那么就希望能将这些资源做到合理的利用与规划，或者客户自身有几台服务器，那么他们最不希望，有些服务器配置的很满，有些却只使用了一小部分资源的情况发生。”

今天他去到客户现场，客户直接问他要准备多少资源刚好够用，能不能给个清单。当时强哥一下子被问住了，忙说下次去的时候准备好给到客户，让客户也好有个心理预期。

这时铁子一听就不乐意，没好气的对强哥说：“你怎么能乱答应客户呢？和你说过很多次了，我们怎么可能准备的出来这样的清单，这种很难预估的，我只能说去试试！就算准备出来了，也不会有多准的！”强哥一听也来了脾气：“客户要了好几次了，我不给的话，这单还要不要谈了？”

升级

听到这里我忙劝架，让铁子别激动，这个事情试试，先拿一个出来，然后强哥叮嘱客户先按照这个预估的资源情况的基础上往大些准备就好了嘛。没想到，就是这句话，将我们交付团队带到了一个个坑之中。

而为了打动客户，让客户感觉不需要花太多钱就可以部署好这个数据产品，铁子给到强哥的资源规划清单相对保守些。直到那天，我们遇到一个客户，真的按照强哥带去的清单做的准备，竟没有多一丝资源冗余给到我们。当我们去部署的时候，发现根本不够部署我们的产品包。因为资源不足导致无法完整运行，最终被迫在现场裁剪产品资源开销后重新部署，这个过程消耗了大量的时间

于是在客户现场，就看到我们在反复部署，将环境部署到一半，铲掉，再去部署。当时客户就和我们在一起，看到屏幕上反复出现的 delete ，不住的摇头。那时的我们感觉太挫败了，后来客户看不下去了，直言：“你们这个交付包是不是质量有问题啊？这么反反复复的到底还能不能跑起来？” 我们连忙安抚客户，说放心，不是交付包有问题，是咱们的环境有点复杂需要稍微费点时间调试。而我们心里知道这些话是说给客户听的，就是客户那边资源没准备足，我们需要对现在的产品现场调试修改，而我们却不能怪到客户头上。

激化

而不巧的是，我们才交付好后回来没两天，客户一个电话过来，和我们抱怨说这才用了多久，就宕机了。我们出发前，就在猜是不是又是因为资源的问题，他们需要处理的数据量还是很大的，当初部署完留给业务运行处理的空间本就不是很多了。果然，当我们飞过去排查后发现，确实资源不足需要扩容，但是扩容的话，需要将客户目前的业务中断。终于，这个举动导致客户的怒气值爆棚，直言我们的交付质量太差。

爆发

当然我们也很委屈，回去后一名交付同学在复盘会，直接将这些话透传给到开发团队，进一步导致了矛盾激化。

铁子立马反击说：“话不能这么说，本来就说了这个清单只是参考，我们哪儿想到客户那么实诚，原原本本按照这个来准备，一点冗余空间都没准备。而且我们人为一点点去进行的核算，已经都占用我们很多研发时间了，你们还不领情。你们可知道，运行时资源情况会动态改变的，这让我们怎么来评估，很难得好不好！你们倒是不写代码，体谅体谅我们开发同学好不好，不要上来就甩锅。”

强哥听到我们屋内吵起来，走了进来，我原以为他是来劝架的，没想到他进来后又进行了补刀。他说刚才接到另一个客户电话，说按照他的清单准备的资源，结果有些机器资源都没怎么用上，空置在那里了，直接浪费他们的钱，体验很差，感觉我们很不靠谱。

铁子听完我们的集体吐槽，留下一句，说了不好规划你们不听，我有什么办法后推门而出，再也不理我们了。

这已经是我们交付铁三角不知道第几次争吵了，每次都是因为交付时出现的这些问题而吵架，最终闹的不欢而散。

大战前夕不来场战略演练？

尽管吵归吵，我们的项目还是需要铁子出包，这天我们还是按照平时那样，拿着交付包去到客户现场。到达客户现场后，我们懵了，交付地点在大山深处的厂房不说，客户准备的机器还十分老旧。我们去安装的时候，一直在心里犯嘀咕。好在，尽管客户的网络情况比较复杂，机器老旧，我们的部署困难重重，但我们还是顺利完成了部署。就在我们准备离开的时候，厂房突然停电了。客户解释道：“我们这边比较偏远，有时候会动不动跳下闸，没事，一会儿就来电了。”

当电力恢复时，如你所猜测的那样，我们的产品跑不起来了，需要重新启动几个组件。当时交付同学就说回去复盘的时候要提一下，你看，就停了下电，断电重启都实现不了。

复盘会上，铁子这样解释道：“每次出包前，我们已经进行了反复的验证，虽然这部分工作耗时耗力，但相对来说我们已经尽力了。尽管这样我们其实还是无法保证交付包一定能够容忍很多特定场景的，这个实现起来是很困难的。

另外，线下交付场景中问题的处理大多与环境、配置有关，当由不同的交付人员处理时，每个人处理的环境、产品故障偏向点状解决。而当遇到新的问题时，需要重新开始排查，摸石头过河效率较低，那便是你们交付同学的问题了。由于你们并没有相关知识的沉淀，并未提供给到我们这些信息，为下次演练提供素材和参考，这样我们只能凭我们的经验对一些场景进行演练，有遗漏的场景太正常了，这才是问题的关键所在。

另外，故障排查数据量大，一个组件出问题排查起来确实很困难，这个也是不争的事实。但是交付前我们确实进行了充分的模拟演练，已经最大限度的来降低问题出错的概率了。”

听完铁子各打两大板的发言，这次冲突虽然没有激化。但是我们对于铁子给出的说法并不满意，会议结束后交付的其他同学拿起电脑头也不回的走了。而我坐在会议室，看着铁子在不住的摇头叹气。那一刻，我竟感受到了技术同学一瞬间的绝望和难过。他在强忍着，只见铁子一手捂紧拳头一手不停的挠头，好似下了很大的决心。

兵马未动之粮草先行

时间不知不觉的过去，直到有一天，铁子找到我和强哥，喊我们一起吃个饭。吃饭的时候，我们才知道，事后铁子那个气啊，于是为了争口气，赌上公司研发一把手的尊严。拉着开发团队彻夜分析，发现核心矛盾点如下图所示，最终导致客户质疑我们的交付质量。而这一切都源于资源评估这一步，如果把这个技术难点突破了，我们的矛盾便可以解决。一边生气一边研究的过程中，他想到了云原生应用交付平台 ADP（以下简称 ADP），上次拜访阿莫了解应对软件应用交付难题的招式的时候，他好像提到过一下，于是他进入 ADP 平台，看到里面真的有资源规划能力，经过分析研究，发现可以很好的解决当前这个矛盾。

资源规划能力

ADP 的资源规划功能可帮助我们，通过模拟部署能力快速且高效的评估出合适的集群资源配置，如：CPU、内存、存储分别需要多少，还可以在部署失败后查看未成功调度的 pod 数以及原因，进行调整，有效降低由人力评估效率低下、动态场景难以统计准确等原因所导致的一系列问题。

三步实现快速资源规划

1、自动统计产品的实际部署开销。

2、对拟定的节点资源规格进行仿真调度实验，得出实际的部署效果。

3、查看调度失败的 Pod 情况，调整节点资源规格，秒级重试验证。

铁子说完这些后，看向强哥道：“你看，以后我们产品适配改造好后，跑一份更靠谱些的资源容量清单给你，你拿给客户，就让客户按照这个准备，还是有问题的话，你来找我，随便你怎么凶我我都认，好不好？”

强哥听完边点头边说道：“行，这可是你说的！一会儿你把明天我要去聊的客户，他的资源规划清单给到我，我明天带过去。”

“好的” ，铁子边答应边扭头看向我，对我说道：“小锤，强哥前置把客户那边搞定，客户按照清单中的资源情况进行准备。那以后你们交付团队再也不会出现，在客户现场反复部署安装，部署了，铲掉，再部署，再铲掉，这样尴尬的情况了！在信老哥一次好不好？” 我拍拍他的肩膀道：“ 好的老哥，再信你一回！”

不打无准备之仗

关于交付同学提怀疑铁子他们出包前验证不充足的事情。虽说铁子他们心里不服气，但是想了想，本身交付的场景就是各种各样的，确实很难做到面面俱到，怀疑开发同学演练不充分也确实是有道理的。于是开发团队的小伙伴集中起来，梳理了许多的演练场景，然后铁子又将这些场景在 ADP 平台中一一查看，发现 ADP 平台可以自动实现这些场景的线上集成一键演练，而且涵盖的演练场景比他们想到的还要多。