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.