paulwong

工作心得之二 业务

说到业务是个让人又爱又恨的东西,客户、领导把它看的很重,不少“技术控”却瞧不起它,认为它是“低智商”的代名词。当然了,这些看法都很偏激。技术仅仅是一个工具,因“业务”的需求而诞生至使用,小说里常常写到,当一个人学会了屠龙之术,却发现天地之间没有龙给他“屠”,这个是最悲惨的事情了,这里的“龙”就是业务,“屠龙之术”就是技术,离开了业务的技术是没有意义的。
业务本身是个抽象的集合,真正把它搞懂了其实也能锻炼人的抽象能力。
说来说去“业务”是个什么东西,似乎没有明确的定义,我觉得“业务”就是个“标准”,程序员完成的系统必须满足这个“标准”,不同行业,不同硬件环境都会有自己的合适的标准,某项技术都有其对应的“标准”。
比如一直讨论很久的问题,C++和Java到底谁快,为此也有衍生出了很多讨论,技术控也是乐此不疲,但是或多或少都脱离具体环境。
计算机语言发展了这么多年,都会相互学习优点,不过总有些本质的区别,比如C++的优势是和硬件结合紧密,Java的优势是屏蔽了硬件限制,两者在诞生的时候发展的方向就有不同,比如通信系统的交换机等各类硬件的程序非C/C++莫属,Java在这里难有使用的地方,但是在异构硬件集群中,现在很火的“云”系统,Java的优势就很明显,现在常用的服务器系统大多都是Java。当然也有人说Java免费,所以比C++更容易推广,的确没错,但是这也属于“业务”的范畴。
说完了业务的大范围,下面说说具体行业的业务。我最熟悉的是电信的业务。相比金融、电商系统,从网上的信息来看似乎电信的系统是最没技术含量的,其实电信的数据量远大于金融、电商,只是大量的数据是后台处理,可以异步展现,所以给的要求并不高,总体来说电信系统是入门的技术低,做好了很不容易。

我和不少电信的程序员人聊过,他们纷纷吐槽是,工作就是配置各种业务参数,体力活。但是说到具体的业务模型时,却说不清楚。

我总结的电信系统分2两大部分,业务模型(CRM)和工作流(IOM)。CRM和IOM是比较老的名词了,新的我也不太清楚。
模型如下:

主产品+子产品+产品规则+动作

解释如下:
主产品,和硬件挂钩。现在的电信产品有手机(移动,联通,电信分属不同网段)、固话、ADSL、光纤、2B+D、30B+D等。
子产品,依赖于主产品。比如移动电话的各种优惠包,宽带的互联星空等。
产品规则,这里是最让人抓狂的。产品规则分3类、
1、主产品规则,主产品之间是没有任何关系的,比如一家人可以装两条宽带,用多个手机。
2、子产品规则,基于不同主产品的子产品之间没有任何关系,基于同一主产品的子产品之间有各种规则,比如手机的资费包开通了一个就不能开通另一个,这类为互斥。不同的优惠可以共同作用,这类为叠加。由于各种子产品的数量繁多,所以这些规则的校验和实现是个很庞大的数字。
3、运营商制定的规则,比如,从硬件角度来说,装宽带、装电话、开通手机是互不相干的,但是运营商制定了各种套餐,“强迫”统一办理。这个无论是对程序员还是消费者都是是很讨厌的……
动作,装、拆,(改=装+拆)

分析完了以后可以发现真正麻烦的地方是业务规则这块,一个电信客户系统的质量高低很大程度上就由这个“业务规则引擎”决定,如果只是闷头往这个引擎里加参数的确无聊,但是这正了解这个引擎的工作步骤还是很有趣的,个人认为理解一个系统的运行是很容易提高能力的。

下面说说“工作流”,消费者的任何一个请求在电信系统中都会转变一个流程,某些特殊的业务流程会很长,比如装高清宽带,需要人上门施工,并测试宽带质量等,这些都成功了才会触发其它的步骤。消费者的业务请求在后端实现往往是“事务”型的,比如原来是套餐A,改成套餐B的会有3个步骤,不熟悉电信业务的人可以想下“神州行”改“全球通”。当步骤1和2施工成功后,步骤3发现现有条件不满足时(这里的判断不在当前系统中,或者说当前系统无法判断,必须将数据发送到另一个平台之后由那个平台来判断,这种情况在电信系统里很常见,比如当前系统没有客户资料,所以无法判断),也就意味着不能办理套餐B,这样得回复成套餐A,这样需要对步骤1和2得进行反向施工,也就是“事务回滚”。先后这就是“工作流”的任务。
工作流在电信系统中是很重要的角色,相比于是电商和金融系统,电信系统的工作流最强大。
简单解释下工作流,工作流有两个最基本单元(节点),逻辑节点和工作节点(不同的系统中叫法也不同,但是作用都一样)。
逻辑节点,就是if判断。
工作节点,就是一个具体的施工环节,一般关联一个平台。
一般工作流的具体配置都由这两种节点组成。

工作流定义的关系有,串行和并行(电信里的叫法是同进同退,一般直接定义成事务)。
于一个系统来说,业务层的调优效果优于代码层的调优效果(代码错误引起的宕机问题不属于调优范围)。比如,一个业务的判断规则精简了,比你优化几个计算语句强的多。比如之前说的例子,在步骤1、2、3中,因为3出了问题,导致1、2得反向施工,所以实际有5步操作,1、2、3、2反向、1反向。所以如果3最容易出问题,那么应该调整顺序应该是3、1、2,把最容易出问题的放在最开始,这样可以避免不必要的步骤。其实在系统上线后运行一段时间,就可以统计出那些平台的出错率高,调整顺序几乎是0修改,但是带来的效率提升是明显的,但是没有几个地方有这么做的。

说了这么多,我觉得把整个系统的框架搞明白还是很能提高个人能力,抽象逻辑对于程序员来说必不可少。所以现在每次抱怨工作无聊时,我都会想想,真的就不能挖出点东西么?

posted on 2012-02-13 23:15 paulwong 阅读(225) 评论(0)  编辑  收藏 所属分类: Project Management


只有注册用户登录后才能发表评论。


网站导航: