简单网站html模板下载地址,阿里云买域名后怎么做网站,网页设计师和ui设计师区别,安卓优化大师下载简介#xff1a;大家好#xff0c;交付铁三角带着全新的故事来啦#xff01;一直被应用交付难题所困扰的他们这次又遇到了新的难题#xff0c;售前大佬的一句客户资源规划缘何让开发铁子暴怒#xff0c;交付小锤的劝架为何致使自己的交付团队陷入这场漩涡之中#xff0c;…简介大家好交付铁三角带着全新的故事来啦一直被应用交付难题所困扰的他们这次又遇到了新的难题售前大佬的一句客户资源规划缘何让开发铁子暴怒交付小锤的劝架为何致使自己的交付团队陷入这场漩涡之中在客户现场惨遭客户对交付质量的质疑。在这场风波背后又隐藏着怎样的破解之法帮助他们重归于好快来点击下方文章了解吧
作者新钰
大家好我是专注交付的王小锤与开发老哥铁子还有售前大佬强哥组成的“交付铁三角”团队我们又来啦
我们 “交付铁三角” 服务于一家提供大数据分析服务的 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 提供的能力让我们重归于好看来是时候再约阿莫他们多聊聊看看还有什么惊喜加上上次他埋了几个小问题让我们甚是好奇。待我们再次拜访阿莫后来同大家分享一起看看还有哪儿些你不知道的事情吧
独家交付秘籍之招式拆解第一回-阿里云开发者社区
本文纯属虚构如有雷同纯属巧合
原文链接
本文为阿里云原创内容未经允许不得转载。
