域名到期了网站备案还有效吗,如何给自己的网站做优化,内江手机网站建设,杨和网站设计制作1号恐惧症 你有没有这样的做IT的朋友#xff1f;年纪轻轻#xff0c;就头发花白或者秃顶#xff0c;然后每个月周期性的精神不振#xff0c;一到月底#xff0c;就有明显的焦虑。如果有#xff0c;他可能就是运营商行业做计费运营的#xff0c;请对他好点#xff0c;特…1号恐惧症 你有没有这样的做IT的朋友年纪轻轻就头发花白或者秃顶然后每个月周期性的精神不振一到月底就有明显的焦虑。如果有他可能就是运营商行业做计费运营的请对他好点特别是在国庆、元旦这种节日尽量少晒些美食啊、旅游啊这类的照片否则他真的可能拉黑你。 为什么这群人会如此恐惧1号呢因为1号是运营商计费出账的日子。这个日子要持续N个小时的紧张劳动神经绷紧谨防数据库突然宕机焦虑程序任务能啥时候跑完跑的结果对不对。总之直到做完回去睡觉都可能会被噩梦惊醒。 周期性业务场景普遍存在比如会员月度结算、薪酬月度发放以及林林总总的月度报表等周期性是生活中的惯性规律。那么有没有办法给这些周期性业务优化减负呢 原因分析 当然有。 运营商计费系统1号要做的事情就是批价出账。所谓出账其实就是生成用户账单的过程。对于正常使用的用户出完账后可以查看和打印上个月的消费账单余额不足的用户为了防止继续欠费会被停机需要尽快缴费出账生成的数据要供财务、经营分析、结算等多个部门使用。 可以看出出账事关用户感知事关企业运营非常重要。出账也需要极高的准确性不说百分百但是99.999%还是要做到的还需要极高的及时性因为其他部门的同事都等着你的米下锅呢。 可能有同学要问运营商行业信息化建设那么早难道还不成熟怎么出账出的还如此纠结呢 先说答案。究其根本还是日益增长的业务量与落后的业务流程之间的矛盾。计费的基本业务流程、数据模型大概在十几年前就基本确定后面持续在提升也只是修修补补没有太大的变化。当然即使是站在今天的角度这个模型和流程依然是十分的灵活而且优秀以十多年没有大的修改就可以看出但是也存在不适应现在业务的落后的地方。 这个业务流程哪些地方落后呢 可能对于大部分人你的手机费用无非就是套餐费超出套餐的费用月初收你一笔费用然后每天实时根据清单算出超出的费用没啥难算的。但是站在计费人员的角度还有一些人他们的费用是某些账目的费用打个折然后某些加起来保个底再封顶之类个人的算完还要把这些人集合成一个单位再算一次。 这些业务现在看来十分特殊但是在十几二十年前手机还没广泛使用的时候其实是固定电话的主流业务也基于硬件情况甚至连基于套餐的清单优惠都实现不了这部分用户不仅固定的费用是月底才计算固定费用计算流程在月底在完成了所有话单费用的计算之后还要加上个人的账单优惠流程用户级优惠、家庭或单位的账单优惠流程账户级优惠甚至还有些杂在一起的其他的优惠捆绑优惠而且更加过分的是这些都只能串行因为一个费用会影响另一个费用这个流程计算固定费用的部分我们称之为租费计算流程后面的几个优惠我们称之为账单优惠流程。 这种业务作为主流其实持续了近十年左右而新的业务也在不停的增长直到新的业务变成主流。而老的业务也没法去抛弃这就造成了系统中存在不少的这种用户需要去“特殊处理”下文会称这些用户为特殊用户老的业务流程就一直保留了下来。另外一方面这近十年用户量增长了十倍的数量级业务量增长了百倍的数量级。因为业务量的增长这些业务流程处理时间越来越长从10个里面挑5个和从100个里面挑5个的效率肯定不一样。虽然硬件水平在增长程序也一直在优化但是得到的效果不能说毫无作用吧也只能说九牛一毛。 嗯相信原因已经说清楚主要还是业务流程的问题。业务在增长业务的模式也在不停的更新而业务流程既要适应老的业务也要适应新的业务。新的业务因为是后来者所以是在很多都是老的业务流程上打的补丁虽然满足了业务需要但是也不能避免的造成了新的系统负担。 那接下来要做的事情就是业务流程的优化了。 整体业务流程的优化 先说一个“错误”答案。 你可能首先想到的既然老业务流程的用户挑出来慢那是否可以把这部分用户单独存放然后在月底对这些用户单独处理呢不是不行但是得不偿失。这主要是两个方面的原因其一这样涉及的流程改造点太多从受理、到批价、到最后出账都需要大刀阔斧的改造。另外部分资费不仅仅包含这部分特殊用户也包含主流的用户“融合”是个更大的问题【相信知道预后融合本地电信套餐类型这个词的朋友都知道】 其二即使这么改造了其实月底仍然要走完原来的流程虽然会快但是也不见得能快多少。 我们其实做了一个更加大胆的决定那就是在月底的时候彻底抛弃租费计算流程、账单优惠流程。 通过分析在包括前文所说的特殊用户在内其实在月底账单优惠前95%的用户每月费用不变仅存在固定费或者说套餐内费用只有5%的用户费用发生变更也就是说会产生超出套餐包含量的计量费。也就是说因为账单优惠触发的量并不多我们完全可以在月初的时候租费以及相关的账单优惠全部预生成出来然后再计算每天超出的计量费。产生一笔我们计算一次优惠这样到了月底就可以直接不再计算账单优惠了改造完成后计费的整体流程如下图 月底需要做的核心事情就是图的最下面橙色框的内容一般只需要1.5小时就可以完成原来一直要到第二天早上8点才能结束的出账核心流程在2点一般就可以结束了。 看到这里你自然会有点认为这其实还是没抛弃以前的业务模式也只是在原有的流程上打补丁而已或者说重新组合关于这个疑问我们的理解是补丁完全可以打就看打的漂亮不漂亮了。 漂亮还是不漂亮我们认为应该是有三个标准。 ✨ 第一个标准也是最重要的标准是有没有影响最终用户的感知。整体业务流程修改后由于能够更加实时和精准对用户的费用进行判断催缴、停复机等动作更加及时。最终用户的感知不仅没有影响反而是优化了所以是满足的。 ✨ 第二个标准使用系统本身和下游系统的用户的需求是否满足。整体业务流程修改后加快了出账的速度当然是满足的。其实除了出账快以外还抛弃了一个每月25日左右的“预出账”流程原来做这个流程的目的一个是为了防止月底出账有大的波动的时候核查措手不及另外一个方面也是尽可能早给下游系统如经营分析系统一些分析的数据。这样改造后每天都可以核查预期月账的情况也可以每天都提供下游系统基本准确的数据这样就可以抛弃掉这个预出账流程也增加了下游系统分析的准确性。 ✨ 第三个标准是否能尽可能兼容以前的流程。实际上本次的改造可以理解为积木的重新组合对部分组件进行了适配性修改。如果发现问题还是可以重新搭回以前的流程实际上这次改造是否升级都可以用配置开关来实现。实际实施中各地也存在一些不适配新流程的出账流程这部分完全保留也没有问题。 当然虽然业务流程确实没有伤筋动骨但是也不是看上去的那么简单。 核心流程改造租费与优惠 从前文流程可以看到首先要做的是把所有用户的租费和优惠在月初先算出来按天计算后放入中间表那就是增加月初的租费、优惠预生成流程。 先说简单一点的租费。 在优化之前租费的计算周期有三种类型即月初、每日日租、和月底现在其实要做的就是把月底的租费计算提前到月初并考虑用户感知将租费摊分到每日。实际设计时我们认为可以直接把所有用户的租费包括日租都放在月初执行直接生成每天的数据都放入中间表中后面增加一个中间表到账单表的流程实现每日的“账单合并”(合账流程)。 这样的话租费的计算周期其实就变成了一种类型都是月初计算只不过按照原月初、每日和月底的不同的一些业务差别每天计算的逻辑不太一样而已比如月初计算的都在1号收费。 至于优惠就复杂一些。流程上与租费还是一样的都是分散到每天然后再每日抽取合账主要还是在于优惠的摊分计算方式非常复杂以下就举两个例子非计费专业同学可以只感受一下 赠送固定值的计算方法 需要记录优惠配置的赠送固定值X。 若charge1…chargeN-X0则优惠费用为直接对当天费用取负值若charge1…chargeN-X0并且charge1…charge(N-1)-X0则当天的优惠的总费用为charge1…charge(N-1)-X以后每天的优惠费用都为0。 封顶的计算方法 需要记录优惠配置的封顶值X。 若charge1…chargeN-X0则第N天优惠费用为0charge1…chargeN-X0则第N天优惠费用为X-(charge1…chargeN)第N天以后为-charge(N1)…-charge31。 当然对于优惠实际更加需要关心的是如何做实时的优惠。 第一个问题就是何时该触发实时优惠 首先费用变动肯定需要触发实时优惠流程。这部分我们设计之初认为可能会存在效率问题因为所有优惠都需要重算所以触发的账目为优惠参考的账目组中的账目但是后面实际测试实际上每一次实时优惠即使所有优惠都进行重算响应基本为毫秒级且按照批次而非按照清单触发后触发的次数并不多。所以现在通用的做法是所有产生的超出费用都会触发优惠的重新计算可配置也避免因优惠的各种参考科目问题造成出现费用计算错误的情况。 其次用户资料的变动需要触发实时优惠流程。用户资料的变动是指用户订购了新的套餐、退出或者加入了某个需要参与优惠的账户或者其他优惠对象等等变动。这种情况下其实也不是所有的变动都需要触发比如新套餐为次月生效还是要进行一些筛选。不过肯定有聪明的同学会立刻觉察到另外一个问题现在的套餐下很多都不是一个人的套餐有些与家庭有关有些与公司有关那一个用户的变动是否需要触发所有人的优惠重算呢 如果你想到了这个问题请允许我为你鼓掌。 这就是我们要说的第二个问题单个用户的费用变动哪些关联用户要触发实时优惠又怎么样把这个用户关联的其他用户找出来呢 关联用户分组以及配套流程改造 熟悉三户模型的朋友知道运营商用户资料实际是用户、账户、客户的三层关系加上费用计算的套餐销售品关系比较常用的就是这三个关联套餐关联、账户关联、客户关联。其实还有一些比较随意的捆绑关联这这些是极少数可以保留原有流程单独处理。这几个关联关系比较麻烦的是这三个关联关系存在多层的嵌套关联而某些用户因为有些大账户的存在会关联数万级别的用户分组处理会比较慢。 所以这个关联关系肯定要先生成出来而不能是到了相应的触发流程再去寻找。我们在用户资料层面引入了关联用户分组这个模型与之配套的需要修改一些流程。 首先是生成这个关联用户分组的资料接口。 在实施的时候参考目前的现有资料将关联用户分组先生成出来然后进行用户资料接口的配套改造根据用户的受理情况进行一个实时的分组判断和处理对用户所在的关联分组进行维护。 这样的话就做到了当某个用户费用变动时将其关联的其他用户也再触发一次实时优惠。当然这里面存在一些过滤的问题因为业务规则比较复杂篇幅有限这里就不详细描述。 其次是批价流程。 批价流程最好也根据用户关联分组来区分进程这么做的好处其一为了现在引入的分布式计算引入的流框的效率其二是关联分组肯定会包含套餐关联的用户处理累积量时可以尽可能少的遇到累积量并发锁问题批价效率也自然会提高。当然批价流程进行改造的前提前面的预处理流程将“用户关联分组属性”填出来。 还有一点就是优惠对特别大的分组的处理的大账户优惠进程上需要分开避免造成处理慢影响其他用户程序上也需要优化不过这也是“过于先进不便展示”的内容只说一点成果这个优化之后我们的大账户处理做到了秒级响应。 当然各种需要改造的小流程还是挺多比如话单回退、重处理、补退费等等这些就不一一赘述了。 画龙点睛出账流程自动化 虽然是一个保守而传统的计费人但其实我们非常符合电影里面程序员或者黑客的形象噼噼啪啦敲一阵键盘然后得到一个结果然后想半天又噼里啪啦敲了一阵键盘如此往复直到自己的任务完成。但是这个辛苦只有自己才能感觉到除了减少流程、缩短时长谁不想做到自动化呢 既然都做到实时的出账了那为啥不做的更彻底呢 所以这次的改造除了流程的优化以外我们还做了系统自动化调度、实时可视化展示、智能化的支撑等等。完全摆脱过去人工值守人工启停应用的低效率处理模式完全提升了出账效率。 以下是一张成果图是领导千叮咛万嘱咐让我放进去的当然相信你看完这张图就知道我们做了啥了别问问就是过于先进。 总结打破常规、实事求是 运营商计费系统是非常传统的IT系统。系统模型、业务流程的基本面已经运行了20来年。在这20来年中业务模式在不停更新业务本身在不停发展而系统需要满足各个时期的业务这就造成了系统中存在很多甜蜜的历史负担。要解决这些负担即需要有打破常规的勇气也需要有实事求是的态度来正确对待我们面临的问题。根据解决的问题和带来的影响来评估方法是大刀阔斧还是庖丁解牛或是中间态。 大刀阔斧可能迅速且能够解决更多的问题但是可能影响不可承受庖丁解牛可能辛苦但是好在影响面小出现错误还可以回溯。 我们选择了庖丁解牛式的解决将周期性业务切的更细以月末的集中处理分散到每天处理并加上相应的自动化以及监控使处理更加放心。当然这个过程也确实非常辛苦从主流程优化到配套流程改造设计的每个点都要详细评估从设计、开发到实施每一步都做到精细而且精准。
