者：新钰
大家好，我是专注交付的王小锤，与开发老哥铁子还有售前大佬强哥组成的“交付铁三角”团队，我们又来啦！
我们 “交付铁三角” 服务于一家提供大数据分析服务的 ISV 企业。通过对客户提供的大数据，进行多维度智能化分析，提供用户画像、潜客分析、销量预测等信息，将数据价值最大化后给到客户，助力客户通过分析结论达到最大的市场收益。近年来，出于对数据安全性以及安全合规等方面的考虑，选择私有化交付的客户越来越多，而他们的要求也变得复杂多变，无形中我们被迫面临各类复杂的交付环境，同时产品交付压力与日俱增。
这不，一直被软件应用私有化交付问题困扰的我们，近期又碰到了新的交付难题，为此还闹的不欢而散。
兵马未动之粮草准备多少？
起因
故事是从那天强哥的抱怨开始持续发酵的，那天强哥一脸的沮丧回到公司，拉着铁子就问能不能给他一份清单，让他带给客户。好让客户知道要是用咱们的 SaaS 产品，需要买多少设备，准备多大的硬盘？咱们的产品会占用多少内存空间？他抱怨道：“因为客户需要处理的数据量很大，所以最近对资源的使用情况变得格外敏感。客户希望将每一寸资源都用在刀刃上，像是客户自身有 MySQL、Redis，或者已经在使用一些云上资源，那么就希望能将这些资源做到合理的利用与规划，或者客户自身有几台服务器，那么他们最不希望，有些服务器配置的很满，有些却只使用了一小部分资源的情况发生。”
今天他去到客户现场，客户直接问他要准备多少资源刚好够用，能不能给个清单。当时强哥一下子被问住了，忙说下次去的时候准备好给到客户，让客户也好有个心理预期。
这时铁子一听就不乐意，没好气的对强哥说：“你怎么能乱答应客户呢？和你说过很多次了，我们怎么可能准备的出来这样的清单，这种很难预估的，我只能说去试试！就算准备出来了，也不会有多准的！”强哥一听也来了脾气：“客户要了好几次了，我不给的话，这单还要不要谈了？”
升级
听到这里我忙劝架，让铁子别激动，这个事情试试，先拿一个出来，然后强哥叮嘱客户先按照这个预估的资源情况的基础上往大些准备就好了嘛。没想到，就是这句话，将我们交付团队带到了一个个坑之中。
而为了打动客户，让客户感觉不需要花太多钱就可以部署好这个数据产品，铁子给到强哥的资源规划清单相对保守些。直到那天，我们遇到一个客户，真的按照强哥带去的清单做的准备，竟没有多一丝资源冗余给到我们。当我们去部署的时候，发现根本不够部署我们的产品包。因为资源不足导致无法完整运行，最终被迫在现场裁剪产品资源开销后重新部署，这个过程消耗了大量的时间。
于是在客户现场，就看到我们在反复部署，将环境部署到一半，铲掉，再去部署。当时客户就和我们在一起，看到屏幕上反复出现的 delete ，不住的摇头。那时的我们感觉太挫败了，后来客户看不下去了，直言：“你们这个交付包是不是质量有问题啊？这么反反复复的到底还能不能跑起来？” 我们连忙安抚客户，说放心，不是交付包有问题，是咱们的环境有点复杂需要稍微费点时间调试。而我们心里知道这些话是说给客户听的，就是客户那边资源没准备足，我们需要对现在的产品现场调试修改，而我们却不能怪到客户头上。
激化
而不巧的是，我们才交付好后回来没两天，客户一个电话过来，和我们抱怨说这才用了多久，就宕机了。我们出发前，就在猜是不是又是因为资源的问题，他们需要处理的数据量还是很大的，当初部署完留给业务运行处理的空间本就不是很多了。果然，当我们飞过去排查后发现，确实资源不足需要扩容，但是扩容的话，需要将客户目前的业务中断。终于，这个举动导致客户的怒气值爆棚，直言我们的交付质量太差。
爆发
当然我们也很委屈，回去后一名交付同学在复盘会，直接将这些话透传给到开发团队，进一步导致了矛盾激化。
铁子立马反击说：“话不能这么说，本来就说了这个清单只是参考，我们哪儿想到客户那么实诚，原原本本按照这个来准备，一点冗余空间都没准备。而且我们人为一点点去进行的核算，已经都占用我们很多研发时间了，你们还不领情。你们可知道，运行时资源情况会动态改变的，这让我们怎么来评估，很难得好不好！你们倒是不写代码，体谅体谅我们开发同学好不好，不要上来就甩锅。”
强哥听到我们屋内吵起来，走了进来，我原以为他是来劝架的，没想到他进来后又进行了补刀。他说刚才接到另一个客户电话，说按照他的清单准备的资源，结果有些机器资源都没怎么用上，空置在那里了，直接浪费他们的钱，体验很差，感觉我们很不靠谱。
铁子听完我们的集体吐槽，留下一句，说了不好规划你们不听，我有什么办法后推门而出，再也不理我们了。
这已经是我们交付铁三角不知道第几次争吵了，每次都是因为交付时出现的这些问题而吵架，最终闹的不欢而散。
大战前夕不来场战略演练？
尽管吵归吵，我们的项目还是需要铁子出包，这天我们还是按照平时那样，拿着交付包去到客户现场。到达客户现场后，我们懵了，交付地点在大山深处的厂房不说，客户准备的机器还十分老旧。我们去安装的时候，一直在心里犯嘀咕。好在，尽管客户的网络情况比较复杂，机器老旧，我们的部署困难重重，但我们还是顺利完成了部署。就在我们准备离开的时候，厂房突然停电了。客户解释道：“我们这边比较偏远，有时候会动不动跳下闸，没事，一会儿就来电了。”
当电力恢复时，如你所猜测的那样，我们的产品跑不起来了，需要重新启动几个组件。当时交付同学就说回去复盘的时候要提一下，你看，就停了下电，断电重启都实现不了。
复盘会上，铁子这样解释道：“每次出包前，我们已经进行了反复的验证，虽然这部分工作耗时耗力，但相对来说我们已经尽力了。尽管这样我们其实还是无法保证交付包一定能够容忍很多特定场景的，这个实现起来是很困难的。
另外，线下交付场景中问题的处理大多与环境、配置有关，当由不同的交付人员处理时，每个人处理的环境、产品故障偏向点状解决。而当遇到新的问题时，需要重新开始排查，摸石头过河效率较低，那便是你们交付同学的问题了。由于你们并没有相关知识的沉淀，并未提供给到我们这些信息，为下次演练提供素材和参考，这样我们只能凭我们的经验对一些场景进行演练，有遗漏的场景太正常了，这才是问题的关键所在。
另外，故障排查数据量大，一个组件出问题排查起来确实很困难，这个也是不争的事实。但是交付前我们确实进行了充分的模拟演练，已经最大限度的来降低问题出错的概率了。”
听完铁子各打两大板的发言，这次冲突虽然没有激化。但是我们对于铁子给出的说法并不满意，会议结束后交付的其他同学拿起电脑头也不回的走了。而我坐在会议室，看着铁子在不住的摇头叹气。那一刻，我竟感受到了技术同学一瞬间的绝望和难过。他在强忍着，只见铁子一手捂紧拳头一手不停的挠头，好似下了很大的决心。
兵马未动之粮草先行
时间不知不觉的过去，直到有一天，铁子找到我和强哥，喊我们一起吃个饭。吃饭的时候，我们才知道，事后铁子那个气啊，于是为了争口气，赌上公司研发一把手的尊严。拉着开发团队彻夜分析，发现核心矛盾点如下图所示，最终导致客户质疑我们的交付质量。而这一切都源于资源评估这一步，如果把这个技术难点突破了，我们的矛盾便可以解决。一边生气一边研究的过程中，他想到了云原生应用交付平台 ADP（以下简称 ADP），上次拜访阿莫了解应对软件应用交付难题的招式的时候，他好像提到过一下，于是他进入 ADP 平台，看到里面真的有资源规划能力，经过分析研究，发现可以很好的解决当前这个矛盾。
资源规划能力
ADP 的资源规划功能可帮助我们，通过模拟部署能力快速且高效的评估出合适的集群资源配置，如：CPU、内存、存储分别需要多少，还可以在部署失败后查看未成功调度的 pod 数以及原因，进行调整，有效降低由人力评估效率低下、动态场景难以统计准确等原因所导致的一系列问题。
三步实现快速资源规划
1、自动统计产品的实际部署开销。
2、对拟定的节点资源规格进行仿真调度实验，得出实际的部署效果。
3、查看调度失败的 Pod 情况，调整节点资源规格，秒级重试验证。
铁子说完这些后，看向强哥道：“你看，以后我们产品适配改造好后，跑一份更靠谱些的资源容量清单给你，你拿给客户，就让客户按照这个准备，还是有问题的话，你来找我，随便你怎么凶我我都认，好不好？”
强哥听完边点头边说道：“行，这可是你说的！一会儿你把明天我要去聊的客户，他的资源规划清单给到我，我明天带过去。”
“好的” ，铁子边答应边扭头看向我，对我说道：“小锤，强哥前置把客户那边搞定，客户按照清单中的资源情况进行准备。那以后你们交付团队再也不会出现，在客户现场反复部署安装，部署了，铲掉，再部署，再铲掉，这样尴尬的情况了！在信老哥一次好不好？” 我拍拍他的肩膀道：“ 好的老哥，再信你一回！”
不打无准备之仗
关于交付同学提怀疑铁子他们出包前验证不充足的事情。虽说铁子他们心里不服气，但是想了想，本身交付的场景就是各种各样的，确实很难做到面面俱到，怀疑开发同学演练不充分也确实是有道理的。于是开发团队的小伙伴集中起来，梳理了许多的演练场景，然后铁子又将这些场景在 ADP 平台中一一查看，发现 ADP 平台可以自动实现这些场景的线上集成一键演练，而且涵盖的演练场景比他们想到的还要多。
故障演练能力
ADP 提供的故障演练能力可以实现，在线上集成环节即可对线下交付中常见的各类故障场景下产品编排的容错性、可靠性和可恢复性进行演练，保证编排稳定可靠。
基于线下交付经验设计的故障演练场景，对基础设施、底座、中间件的常见故障场景进行覆盖，无论集群级别的大规模故障还是节点、Pod 级别的资源故障，都可以在线上完成演练，可基于产品在常见故障场景下的问题进行针对性优化。
ADP 故障演练与 AHAS 故障演练产品进行深度集成，演练场景丰富，且可一键创建线上产品环境并完成 AHAS 探针接入。基于 AHAS 故障演练产品提供的流程编排能力，可实现常见故障场景的一键准备、注入和恢复。使产品在常见故障场景下可以预设其可靠性、可恢复性、告警及时性，大大增加交付信心。
可演练场景如下：
说完这些，铁子略带得意的看下我们两个，问道：“怎么样，听完有没有觉得交付包可靠了许多，信心满满？我们开发团队现在已经在按照这些流程来进行交付了。小锤，下一次交付完记得回来和我反馈，要是交付质量有感觉提升了，体验棒棒的，别忘了请我吃饭哈！”
“好的，没问题！” 听完铁子的一番解释和介绍，我们都觉得这次靠谱了很多，对下一次的交付充满了期待，于是我爽快的答应了他。
铁子还说他请我们吃饭前还联系了下 ADP 的阿莫，和他聊起来这两个能力，他说现在做的还比较初级，后续在资源规划和故障演练能力上还会加大投入。
在资源规划方面，现在提供的是你们部署时所需的规划清单，但是后续我们为了更加精准，还将引入线上的压力测试，这样你们的产品在运行一段时间后是否还能扛得住就清晰明了了，你说的小锤他们部署好立马又回去扩容的情况可以更有效的避免了。
演练场景这部分，我们后续计划在交付团队交付部署好之后，可以让小锤他们在现场再跑一遍故障演练场景，为交付验收再加一层保障，做到出包前交付后都进行充分验证。这样你们用着也会更放心些，还可以将精力回归业务发展上。
就这样，一场兄弟反目的风波就此告一段落。
总结
交付质量提升大法
资源评估—— 带着合理且可靠的资源规划清单给到客户，减少资源浪费、避免资源规划带来的业务中断风险、杜绝反复交付部署情况的发生。
故障演练—— 出包前一键演练或者自动化故障演练，做到每个包都千锤百炼，每个可能的故障坑，交付人员心里有数，出问题快速排除与解决。
提到 ADP，上次拜访阿莫已详细介绍 ADP 作为一款应用交付的利器，提供以下能力：
全栈式在线化服务：稳定可靠的中间件适配、极致简化的交付流程。
异构环境全覆盖：通过集群镜像实现异构 IaaS 交付、通过应用管控实现异构 Kubernetes 交付、以及面向开放生态的规划。
稳定可运维底座：ACK Distro 底座、运维管控平台能力。
上述能力可有效应对我们的产品适配成本高、部署环境复杂、运维低效且门槛高的烦心事，如果感兴趣可在文末点击链接，了解上次拜访细节。
而这次竟然是 ADP 提供的能力让我们重归于好，看来是时候再约阿莫他们多聊聊，看看还有什么惊喜，加上上次他埋了几个小问题让我们甚是好奇。待我们再次拜访阿莫后来同大家分享，一起看看还有哪儿些你不知道的事情吧！
https://developer.aliyun.com/article/866129
（本文纯属虚构，如有雷同纯属巧合）
点击此处，了解云原生应用交付平台 ADP 更多资讯！
