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.