Q&A to prepare interview of HSBC

 

1.How do you keep updating lastest IT knowledge?

1).keep an eye on current project technology evethod I didn't apply it directly such as the CDN product Achmai, the caching framework terrorcoctoer, witch is not the same as the KV mechanism caching system for content caching, but has huge capability in object caching and JVM optimization.

2).I learn a lot from some social medium e.g I learn the lasest and trends of technology from wecchat offical account in terms of cloud, architeture, and argile methodologies.

3).I apply some new technology which looks cool but impact less into my new project.

 

2.why HSBC hire you, tell me some special of you.

1).first I have been working as a programer for 6 years including the experience in the finiancy system for around 2 years, I worked as a engineer at that time and design and developed finance settle system which was used to stasticte telephone and messge charges for china mobile company,  we progressed huge data which came from different source and the challenge is we must ensure all kindly of data should be converted to correct reports and we always have to to do mathematical anlysis to figure out the root cause of those abnormal reports.

2).I have experience in consultant industry of foreign company of IBM .  in fully threre years here,  I worked as system support, trouble shooting, application development and team leader to deliver our IT service to clients. I was praised by our client since I was a system support and developer due to efficient delivery and also got satisfaction when I working as a team leader because my team always compelet project ahenad of deadline. most important, I gain similar working style as HSBC working environment I think I'm suiteable for HSBC.

3).

a。本职工做作得好，在当时30多个同批进来的人中，每次都能排前3名绩效

i join cpa project with 30 members at the same time and i can finished all assisment on time and win the top 3 performance every month,

 

b. 会考虑更多团队目标，不只作好本身的份内事情，并且也帮助其余组员完成工做。

response not only my own task but also my team mate and any other assigment that my boss didn't assign to me,

that can really help enhance the team work quilay and got sastifaction from our client 

c. 有能去解决更复杂的问题因此获得promo机会。

 resolve the most amunt of the system issues and no one was missed and delay, we got the best performance during that month in for business unit.

my boss consider I can handle complex and challenge case so I achieve the change to promot.

 keep enhancing my daily work, i develp a log collection tool with shell script and SQLLITE db for distrubition system, you know it is not easy to collect various of logs from a group of application servers, escpecilaay we would hanldle urget case at mid night,,we search logs with low linux command and it may take us haft hour but after useing my tool, just 5 minutes can get the all set of logs for anlysis, my boss is  pretty excited to see suah a huge enhancement

weakness.

云计算等最新技术方面还缺少丰富的实战经验

 

 

 

 

 

 

3. 介绍一下你的项目

 

3.1 中国BOSS计费系统-短彩信结算系统

职责：新需求评审，概要设计和详细设计文档编写，编码，单元测试，协助上线，协助运维团队紧急故障排查。

 

3.1.1 BOSS系统简介（选择性介绍）

--means Business & Operation support system

BOSS系统基本功能包括客户资料管理、产品管理、用户订购管理、计费、出账、结算等，大体分为计费及结算系统，营业与帐务系统，客户服务系统以及决策支持系统四大块分属不一样业务部门，从系统上使用企业总线将四大块有机结合，从业务上看BOSS就是一个框架，来承载业务系统，CRM系统，计费系统。

四个子系统功能简介以下：

营业帐务系统，营业系统受理和处理用户请求， 帐务系统用来汇总用户帐单（可提供给计费系统）

客户服务系统：如中国移动10086， 中国联通10010

决策系统：信息采集，分析，预测，报告。

计费和结算：计费系统主要作计费数据的采集和批价。 计费采集数据源包括来自网关，交换机的原始基础数据，进行差错校验，格式转换等处理，生成原始话单（并不包含费用）。而批价则是依据原始话单及收费标准对用户费用进行实施计算。

3.1.2 短彩信结算系统简介（选择性介绍）

短彩信结算系统属于BOSS大系统下的 计费及结算子系统下的子模块系统，与短彩信结算系统平级的子系统还有 语音结算系统， 数据业务结算系统等等。

系统业务介绍

中国移动的结算系统从业务分类上大体分为语音，数据和短信三大块。

• 按业务种类 分为自有业务和SP（增值业务）业务

自有业务即平时使用的短信收发功能，是中国移动的传统业务。而SP业务，则是中国移动的大量增值业务（不少都是经过短信交互来进行业务开展的），为中国移动带来大量收入。

对于自有业务，如WAP，手机动画等话单将由全国中心（集团中心）从用户归属省份采集，以后再下发结算单到用户归属省份，出具自有业务结算报表。

对于SP业务如校讯通，手机交友，天气预报，手机小说等等是由第三方服务提供商提供的基于中国移动短信平台交互的业务。SP业务须要SP本身上传原始业务文件到省公司，由中国移动计算总收入，再按不一样业务的不一样分红比例与SP进行分红。收入分红的规则各有不一样，有的是按固定百分比来分，有的按收入等级来分，有的须要扣除各类平台服务费用，有的须要进行多方分红等等。

• 按照结算方式分：分红结算，多方分红结算，固定费用结算，一口价包月，包年。
• 按业务开展省份：分为本省业务，外省业务（省际业务），集团业务

这类一般属于自有业务，将按照固定费率在各省进行结算，例如若是自己用户使用了外省业务，则须要结算给外省（支出），外省用户使用了自己业务，则须要与外省结算（收入）。

• 按电信运营商：分网内业务，网间业务。
• 对于网间业务，须要与各通讯运营商之间进行结算。

 

谈谈挑战，经验，教训等（重点介绍）

业务上，对电信业务架构有了总体认识，对短彩信结算业务有了比较深入认识。

技术上，对OLAP类型系统的设计，性能优化方面有了如下认识：

数据库索引，单独索引，复合索引，

数据表设计：字段类型不合理，对不定长字符数据采用了char类型致使每次都调用TRIM函数，不只增长系统开销，并且会致使相关索引不起做用。又好比原本是日期类型的字段却采用了字符串类型，致使底层调用了转换函数

数据表链接：OLAP类型的表链接，HASH并行处理。

数据表拆分：垂直，水平

挑战（重点介绍）

1.业务复杂性：多SP，多种结算方式，分省，分通讯运营商，各类状况的组合就多，每次新增业务，须要对现有业务进行梳理才能评估影响，从而作出正确的设计。

从软件系统生产的产品（即中国移动的各类结算报表）来看，报表样式复杂，多层嵌套。表格中不少数据都是各类SQL通过各类遍历，排序，回溯后的结果，单元格计算公式复杂（即不能经过简单的方式计算获得结果），同一类业务常常还要分各类粒度来展示给不一样的业务部门。

复杂的数据来源和业务规则直接致使的结果就是复杂的校验过程，增长了异常问题核查的复杂度，须要有较强的数学分析能力。

2.数据库表维护困难，由于数据规模大，数据统计的粒度须要灵活多变，须要对不少字段作统计，所以数据表没有主键，也就没有约束，区分一条业务全靠约定俗成的多个字段做为逻辑上的联合主键。

3.数据库表的设计困难，包括索引的设计，表字段设计，表冗余设计，表关联设计，数据量大，在作相关业务查询的时候，一个SQL语句可能要查十几个子表或者视图，若是索引的设置或者SQL语句不太科学，可能致使查询须要半天才能完成。

 

OLAP类型系统最大特征就是数据量巨大，对于OLTP系统来讲，数据量相对小，能够随意加载到应用程序中进行逻辑处理，可是OLAP却不能轻易这么作，一是光从数据库统计这批数据都得半天，再加载进应用程序，应用程序性能势必成为瓶颈。

所以不少业务基本都是经过存储过程直接在数据库中处理好结果，或者获得中间结果，再返回给应用程序进行处理，那么数据库表的设计就成为了关键。

具体来讲， 若是数据库设计方面作得很差，极可能成为程序的瓶颈，致使须要很长时间才能完成。尤为在月初出帐的时候，众多程序须要并行或者串行执行，对于并行执行的程序，执行时间太长意味着长期占用资源，影响其余程序。对于串行程序，执行时机太长意味着其余程序根本没机会执行，尤为当其余程序属于定时调度任务的时候，将会引起大量程序延迟执行的连锁反应，若是其余业务部门（例如营业部）须要依赖这个执行结果才能开展业务，那将致使业务被迫中止。

记一次故障

在一个新需求中使用了这样的语句， select effect_date from table1, table 2 where to_date("yy-mm-dd", effect_date) > table2.effect_date ...

这里的table1和table2数据量都挺大，因此各个字段都创建了索引，可是上面SQL语句中在一个索引字段eect_date上使用了库函数，致使索引根本用不着，从而致使了全表扫描，不只让一个简单程序跑了几个小时，运维团队还发出警报说数据库CPU占用过高。

故障经验教训：谨慎操做创建了索引的字段，不要将创建了索引的字段放入库函数或者表达式中使用。

此次工做经历得感触，遗憾：

在OLAP类型数据库的查询方面有必定积累，惋惜的是一只没有机会进入真正的数据仓库（数据抽取，转换，加载）领域深刻学习。

没有进入帐务部门去深刻学习他们更先进得报表系统。 计费部的结算报表是在程序中计算出结果，导入第三方报表软件（brio）生成的。 而帐务部的报表则是本身开发的报表系统，由各类组件组成，支持热拔插（相似Java中的Spring框架？），本身定义规则，大部分新需求均可以经过配置文件搞定，提高效率和稳定性。

 

Keywords

短彩信结算系统－mobile sms and mms settlement system

帐务部门清单－mobile sms bills from billing centre

服务提供商－service provider

集团公司-centre company

the mobile sms and mms settement system is a sub system under china mobile BOSS system. it uses mobile sms bills from billing centre or service provider to do settlement with centre company or service provider.

role and responsebility: invoke into requiment reviewing,  finish tenichcal design documentnation, coding, unit test, deploy with maintaining team, handle urgert system issues

challenge:

1. complicated business logic

the mobile sms source data is collected from different SP with various of product and package, different product and package mapping different settlement methods, moreover,

mobile user may comes from different telecom operations company, it becomes more complex one all cases to be handle in one system.

2. challenge in huge amount of data

the biggest challenge should be the huge volumn of data, in general we can load data into application to progress for OLTP system however, we can't do it in OLAP system

due to the huge data,  so we have to process them with database stored procedure and the db table design become the key point for system performance.

for db designing, consider efficient db index to speed up query a result, db table scale out to decreate the data volumn of single table,

for  db maintaining, as no business primary key and union key and no constraint due to the consideration of flexbility in displaying of settlement report, it is not easy to ensure the intergrity and consistency.

 

 

3.2. 国泰航空项目（CPA)-IBE

在CPA三年期间，转换了三次工做岗位，作过运维，开发及teleader职位。

系统业务介绍（选择性介绍）

国泰航空业务支撑系统

系统名称是我本身想出来的，目前国泰航空大大小小IT系统上百个，或独立存在或由系统总线有机结合，尚未一个固定名字。

若是按业务层面分，大体能够分为市场部，财务部，系统调度部，物流部，系统基础服务部。 其中我所在的部门市场部是整个国泰航空业务支撑的核心。

其中最核心的业务支撑部门市场部的大体功能以下：

市场部：主要包含客户关系管理（CRM）系统，订票引擎（IBE)系统，增值业务运营（AM, MPO等）系统，顾客机票管理及在线值机系统等等，每一个子系统分属不一样业务部门。本人曾涉及前三个业务系统任职。

CLS/CRM系统：是一个处于业务最底层，进行客户资料管理，会员等级管理，会员特权管理等一系列客户关系管理的系统，自己由C开发，提供Java接口供上游系统IBE,MPO等以SOA方式调用，终端用户（乘客或会员）通常不会直接调用

IBE：提供票务查询，航班查询，订票，退票，进行促销活动，以及充当支付中心等角色。 对内（CPA内部）提供航班相关Java API， 对外（支付平台，1A等）提供会员资料，会员特权（都是内部先调用CLS API）等接口。

AM/MPO：主要是进行会员信息管理，包括资料的管理，特权的管理，同时AM/MPO兼具电商属性，能够进行礼品兑换，酒店预约等等业务。在会员信息管理层面，AM/MPO至关于一个CLS系统的前端，所以对外提供会员信息查询接口。

系统层面介绍（重点介绍IBE系统架构）

CLS：相似中国移动短彩信结算系统，属于后台程序。

MPO：与IBE在系统架构上基本一致。

IBE: IBE名义上叫作订票引擎，可是核心业务都是经过调度其余API完成，IBE则是充当了一个中转前端请求的角色。

所以在IBE中设计了两个重要的入口，一个叫IBEFacade，专门处理外部请求，包括Http，soap等等

一个叫SCAFacade，专门处理内部请求。

IBE整个系统分三层，前端由adobe开发的商业框架充当表现层，控制层使用Spring MVC接收http请求，将请求转发到服务层，在服务层进行业务校验，数据转换等步骤，若是有须要，会经过CPA的统一服务中心调用其余系统API协同完成业务处理（例如须要调用CLS计算积分，调用1A计算价格，调用Alipay完成支付等等），最后将执行结果返回控制层和表现层或者其余系统。

 

挑战（重点介绍）

业务复杂：

1.航班和票务，分日期，时段在价格上会有所差别。

2.购买方式差别，有经过agent购买的，有直接购买，有经过积分兑换的。其中积分兑换和直接购买分属两个子系统。

3.购票的访客会分为三大类：非会员，AM会员，MPO会员，其中MPO会员又要细分五个等级。 因为会员机制的存在，在礼品兑换，购票时会有不一样优惠。

系统交互复杂

在订票的整个过程当中，从用户登陆，查询航班，查询优惠，到支付，到出票，到发送通知，每个环节都须要与其余系统屡次进行各类格式的数据交换，其中须要进行各类数据完整性校验，安全校验，格式转换，业务校验等等，涉及的外部系统多，数据来源多，数据格式不一样，数据频繁在各系统交换。再加上web应用多线程的自然属性，以及系统集群带来的复杂性，致使一旦遇到问题的时候比较难以追踪。

记一个作得不错的项目/系统

本身开发脚本改善了工做效率

在IBE运维期间，常常须要查询应用程序的日志。 因为这些日志文件种类繁多，数据量大，仍是分布在不一样的集群服务器上的，对于使用linux命令进行手动查询的方式来讲很是麻烦，效率很低。在分析突发故障的时候更是力不从心。

记一次故障处理过程

在IBE开发期间，一个由于写日志而引起的故障

故障描述：service频繁time out， 没法search flight，没法订票

问题分析：disk io high utilization, terracotta and JVM reject rejoin,  was server high CPU, MQ and service error log

分析过程：

怀疑WAS 上的IBE和 WMB 上的MQ通讯出故障

MQ connection error and time out， 可能有阻塞，重启WMB，无效， 2）重启WAS JVM， 无效，

root cause：在遍历一个资料表时进行了写日志操做，期间还建立新对象。 最近由于业务扩展，BU新加入了大量资料，致使遍历次数从100飙升到2000，消耗了大量IO去打印了大量日志且消耗了大量CPU去建立对象。

solution

1.限制层数

2.限制表查询条件

3.缓存结果

经验教训：

慎重打日志，慎重建立新对象

感触

从开发到运维

运维不像开发，开发能够相对慢节奏进行，运维则常常须要救火，状况紧急，容不得怠慢也容不得差错，救火事后常常打补丁，打补丁走的是跟开发一样的流程，须要通过分析系统影响，编码，测试，上线等流程。

运维更须要的是一种忽然事件的应变能力，对全局的把控能力，对问题的发散思惟分析能力。所以从开发到运维，最主要是一种思惟上的转变。

在IBE的三个业务单元（CLS, IBE, MPO）均有涉及运维工做，经过几年的运维经历，在如下方面有所收获。

团队做战

在香港出差期间，与客户以及各个合做商专家一块儿参与过紧急系统故障的现场做战

知识面广了

为何会有CLS系统，有了CLS为何还须要MPO系统，在业务层面各自的功能侧重点是什么，各个系统间如何同步登陆状态，如何进行事务控制，如何进行统一的安全管理等等

经过对不一样业务单元（CRM,IBE,MPO）系统的开发和运维，对整个系统框架的设计有了更深入的认识。

风险意识和流程意识

运维直接接触生产数据，有比开发更高的控制权限，数据丢失，系统环境破环等事故时有发生（身边就有所以被炒鱿鱼的例子），经历各类生产事故以后，对生产系统会有一种敬畏之情，每作任何一个微小的操做都会三思对生产系统将会有什么用的影响。对于任何操做以前，能备份的必定要先备份，而且尽量保证回滚的简单和可行性。任何本身开发的脚本，都须要进行测试环境的测试。

同时对于公司或者项目作出的流程规章制度，经历了从一种漠视到敬畏的心理转变，之前以为很鄙视的流程制度，慢慢悟出其设置的合理性，并不断向新人强调流程意识。

发散思惟和严谨思惟

面对不少生产系统的突发情况，善于观察每个细节，CPU utilization 飙升了， 内存占用飙升了， 系统IO飙升了，均可能是不一样问题的表现，要从多方面多角度去分析问题。

同时在救火的时候，每作一个决定都不能太草率，须要反复推敲，是否有负面影响，是否有遗漏事项，是否真能起做用，运维工做无时不刻不在进行思惟训练。

从运维到开发

 

从运维到开发

高度关注程序性能瓶颈

就像前面那个写日志的生产故障同样，没有重复考虑数据源增长间接对程序带来的影响，从而致使了此次故障。这实际上是一个设计不稳定的模块，单独模块的性能瓶颈也可能成为其余模块的性能瓶颈。

也是团队做战

你写的程序并非只有你一我的看，若是程序中没有必要的注释，运维和测试人员都很难理解业务。若是核心业务缺乏必要日志，运维人员也很难进行问题追踪。

重视测试环境和生产环境的一致性

有的时候偷懒，或者难以模拟生产环境，一些功能在测试环境并无获得充分测试就上了生产环境，从而引起一系列因测试不充分产生的问题。

重视测试，才可以保证系统上线的稳定性；
重视测试环境，才可以保障测试的有效性；

 

从开发到team leader

客户沟通是重中之重

上级和客户都不想听到理由，只想知道结果

可是并不意味着不须要时刻汇报最新进展，让客户有充分心理准备和应对措施。 一次bug修复能够被推迟，可是不能等到推迟已成定局的时候才通知客户，这不只显得团队不专业，还会引发客户不满。

安抚客户的情绪比交付完美的项目还重要

带团队不是发号施令

让团队成长

 

 

team leader,

1.more ealy to understand the expanctale

2.why I can promote? keep learning.