『壹』 銀行壓力測試的不同看法
在相同的兩年內,國際貨幣基金組織為歐洲(不包括英國)給出的銀行貸款損失為8750億美元。高於美國的數字反映了這樣一個事實:經濟下滑在歐洲的出現晚於美國,而歐洲銀行對美國的虧損也持有一定的風險敞口。此外,歐洲銀行的資產負債表一般持有更大比例的貸款,與可交易證券相反,貸款只有在貸款人停止還款時才允許核銷,而大多數交易證券的估值是由注重未來違約預期的市場價格決定的。(國際貨幣基金組織預計英國銀行體系未來兩年將進一步核銷2000億美元)
所有這些並不是說美國的壓力測試毫無瑕疵。分析人士和施泰因布呂克都批評了測試使用的方法,並對監管部門關於衰退嚴重程度的假設提出質疑,事實已經證明,衰退比某些應用情景更為糟糕。很多投資者對銀行只需要750億美元的新資本感到驚訝。國際貨幣基金組織估計,它們需要2750億美元,才僅能回到遭受危機重創之前所達到的資本化水平。國際貨幣基金組織更願意把銀行股本作為其總資產的一部分加以衡量。
也存在這樣的懷疑:測試結果遭到篡改,以確保財政部不必根據問題資產解救計劃向國會要求更多資金。
不過,如果演習的目的是恢復人們對美國銀行體系的信心,早期信號顯示這行之有效。自結果公布以來,幾家銀行已宣布從私募市場募集新股本的計劃。這些銀行還加大了發行債券的力度。「這可能是一個恰好管用的矇混過關策略,」一位銀行高管表示。
而如果與美國同行相比,歐洲銀行不夠透明——由此也不夠可靠,這在金融市場並不是顯然的。最近幾周信心飆升,已經使大西洋兩岸的銀行股股價上升。多數銀行股票相對於它們的有形資產略有溢價,表明投資者相信未來收益將超過它們的資產成本。「總體說來,目前情況有所好轉——我們從危險的邊緣回來了,」匯豐銀行董事長葛霖說。「壓力測試聲明排除了特別悲觀的結果。」
即便如此,許多人仍然不相信危機已經過去。據瑞士信貸的分析師計算,假如歐洲銀行的預留前利潤下降20%——與上世紀90年代初瑞典銀行所經歷的跌幅相似——就必須在2009年和2010年核銷2.5%的賬面貸款,歐洲銀行部門的一級資產率將從7%降到5%,迫使多數銀行募集新股。
即使這個情景證明過於悲觀,人們仍期望許多銀行加強儲備。「如果私營部門再度對銀行股本感興趣,我們預期很多歐洲銀行將在中期募集股份,」野村分析師預測。
由於不同國家銀行所面臨的問題種類繁多,為歐洲銀行設計壓力測試系統也很復雜。西班牙銀行提供的融資助長了房地產泡沫,很有可能比法國銀行面臨更大的抵押貸款損失。在法國,房價還未瘋狂上漲。德國銀行對已提供給處境艱難的生產廠家的貸款感到擔憂。義大利的銀行則面臨較大的東歐風險敞口。
太平洋投資管理公司銀行信貸分析師菲利普·波德羅稱,歐洲銀行的壓力測試或許必須假設較低水平的抵押貸款損失,但對公司和國際市場的風險敞口較大。「如果歐洲銀行平均說來對消費市場泡沫的風險敞口較小,它們對公司杠桿融資和東歐等新興市場的風險敞口就更大」。
另一個兩難的謎題是行業的基礎盈利能力狀況。事實證明,美國銀行的資金需求相對較低,原因之一是人們預期,一旦經濟恢復活力,它們能創造健康的利潤。但在德國這樣的國家,基本的零售銀行業務只是微利業務,這意味著銀行需要較長時間,才能建立能吸收未來虧損的緩沖空間。低利率對有著大量存款基礎的歐洲銀行來說也是痛苦的,因為新生貸款的盈利率受到擠壓。
隨著市場恢復,系統崩盤的危險逐漸淡化成為過去,假設最壞的情況已被拋在身後,這種假設對政策制定者和銀行家們都是種誘惑。只要歐洲銀行相對於它們的美國競爭對手沒有明顯的劣勢,強力推行美國式壓力測試的企圖很可能會面臨阻力。然而,如果疏於防範預計會出現在銀行賬本上的不斷堆積的壞賬,就意味著歐洲經濟恢復的速度較之充分防範所應有的速度來得慢。

『貳』 壓力測試含義是什麼
傳統上所謂壓力測試(stress testing)是指將整個金融機構或資產組合置於某一特定的(主觀想像的)極端市場情況下,如假設利率驟升100個基本點,某一貨幣突然貶值30%,股價暴跌20%等異常的市場變化,然後測試該金融機構或資產組合在這些關鍵市場變數突變的壓力下的表現狀況,看是否能經受得起這種市場的突變。
在軟體測試中:壓力測試(Stress Test),也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬體環境及用戶使用過程的系統負荷,長時間或超大負荷地運行測試軟體,來測試被測系統的性能、可靠性、穩定性等。
『叄』 壓力測試是什麼意思啊
傳統上所謂壓力測試(stress testing)是指將整個金融機構或資產組合置於某一特定的(主觀想像的)極端市場情況下,如假設利率驟升100個基本點,某一貨幣突然貶值30%,股價暴跌20%等異常的市場變化,然後測試該金融機構或資產組合在這些關鍵市場變數突變的壓力下的表現狀況,看是否能經受得起這種市場的突變。
在軟體測試中:壓力測試(Stress Test),也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬體環境及用戶使用過程的系統負荷,長時間或超大負荷地運行測試軟體,來測試被測系統的性能、可靠性、穩定性等。
『肆』 請問什麼是壓力測試
目前對壓力測試的定義有各種各樣的解釋,並沒有統一的定義。 國際證券監管機構組織1995年最早提出壓力測試。該機構對壓力測試的定義為:壓力測試是假設市場在極端不利的情形時(如利率急升或股市重銼),分析對資產組合的影響效果。1999年該機構又指出,壓力測試是將資產組合所面臨之極端但可能發生的風險加以認定並量化。 貨幣基金組織和世界銀行2005年總結出版的《金融部門評估手冊》中對壓力測試的定義:壓力測試是對風險因素(比如資產價格)發生重大變化時資產組合價值變化幅度的大概估算。貨幣基金組織和世界銀行特別指出,之所以使用「大概估算」這個詞,是為了避免人們錯誤地認為壓力測試是一種科學精確性的工具。 國際貨幣基金組織和國際清算銀行對(宏觀)壓力測試的定義為:(宏觀)壓力測試是指用於評定金融系統在「罕見但可能發生的」宏觀經濟沖擊下的薄弱和脆弱點的一系列方法和技術。從定義可以看出,上述國際金融組織把壓力測試著眼點放在兩個地方:一是壓力測試的目的,用於評估金融體系的穩定性;二是壓力因素,主要來源於宏觀經濟沖擊。 中國銀行業監督管理委員會二00七年十二月二十五日制定的《商業銀行壓力測試指引》關於壓力測試的表述有:壓力測試是一種以定量分析為主的風險分析方法,通過測算銀行在遇到假定的小概率事件等極端不利情況下可能發生的損失,分析這些損失對銀行盈利能力和資本金帶來的負面影響,進而對單家銀行、銀行集團和銀行體系的脆弱性做出評估和判斷,並採取必要措施。壓力測試能夠幫助商業銀行充分了解潛在風險因素與銀行財務狀況之間的關系,深入分析銀行抵禦風險的能力,形成供董事會和高級管理層討論並決定實施的應對措施,預防極端事件可能對銀行帶來的沖擊。對於日常管理中廣泛應用各類風險計量模型的銀行,壓力測試應成為模型方法的重要補充。壓力測試也能夠幫助銀監會充分了解單家銀行和銀行業體系的風險狀況和風險抵禦能力。壓力測試包括敏感性測試和情景測試等具體方法。敏感性測試旨在測量單個重要風險因素或少數幾項關系密切的因素由於假設變動對銀行風險暴露和銀行承受風險能力的影響。情景測試是假設分析多個風險因素同時發生變化以及某些極端不利事件發生對銀行風險暴露和銀行承受風險能力的影響。 壓力測試並不僅僅是把許多數據表套入一堆公式,它還包括一系列的判斷和假設,與獲得的結果相比,這些判斷和假設及實際計算過程同等重要,每一個假設、匯總方法或近似分析方法都可能帶來很大誤差,因此需要謹慎地進行估計和解釋。 壓力測試的目的在於分析銀行在宏觀調控、外部市場環境變化和內在經營壓力下,能夠承擔風險沖擊的能力,進而衡量銀行經營的穩健性,為強化銀行風險管理奠定基礎,更好的為維護金融穩定和實施有效監管提供決策依據。
『伍』 如何通過雪球查詢股票之前的變動狀況
一. 雪球公司介紹
雪球 聰明的投資者都在這里。
web 1.0:新聞資訊,股價信息,K線圖
web 2.0:SNS 訂閱,分享,聊天
web 3.0:移動 APP,交易閉環
雪球現在員工數還不到100,其中技術人員佔一半。去年9月C輪融資4kw刀。我們現在的技術棧由下列組件組成:Java,Scala,Akka,Finagle,Nodejs,Docker ,Hadoop。我們當前是租用IDC機房自建私有雲,正在往「公私混合雲」方向發展。
在雪球上,用戶可以獲取滬深港美2w+股票的新聞信息,股價變化情況,也可以獲取債券,期貨,基金,比特幣,信託,理財,私募等等理財產品的各類信息,也可以關注雪球用戶建立的百萬組合,訂閱它們的實時調倉信息,還可以關注雪球大V。雪球當前有百萬日活躍用戶,每天有4億的API調用。App Store 財務免費榜第 18 名。歷史上曾排到財務第二,總免費榜第 19。
二. 雪球當前總體架構
作為一個典型的移動互聯網創業公司,雪球的總體架構也是非常典型的設計:
最上層是三個端:web端,android端和iOS端。流量比例大約為 2:4:4 。web3.0 的交易功能,在 web 端並不提供。
接入層以及下面的幾個層,都在我們的自建機房內部。雪球當前只部署了一個機房,還屬於單機房時代。正在進行「私有雲+公有雲混合部署」方案推進過程中。
我們當前使用 nodejs 作為 web 端模板引擎。nodejs 模塊與android 和 ios 的 app 模塊一起屬於大前端團隊負責。
再往下是位於 nginx 後面的 api 模塊。跟 linkedin 的 leo 和微博的 v4 一樣,雪球也有一個遺留的大一統系統,名字就叫 snowball 。最初,所有的邏輯都在 snowball 中實現的。後來慢慢的拆出去了很多 rpc 服務,再後來慢慢的拆出去了一些 http api 做成了獨立業務,但即便如此,snowball 仍然是雪球系統中最大的一個部署單元。
在需要性能的地方,我們使用 netty 搭建了一些獨立的介面,比如 quoto server,是用來提供開盤期間每秒一次的股價查詢服務,單機 qps 5w+,這個一會再細說;而 IM 服務,起初設計里是用來提供聊天服務,而現在,它最大的用途是提供一個可靠的 push 通道,提供 5w/s 的消息下發容量,這個也一會再細說。
雪球的服務化拆分及治理採用 twitter 開源的 finagle rpc 框架,並在上面進行了一些二次開發和定製。定製的功能主要集中在 access log 增強,和 fail fast,fail over 策略及降級開關等。 finagle 的實現比較復雜,debug 和二次開發的門檻較高,團隊內部對此也進行了一些討論。
雪球的業務比較復雜,在服務層中,大致可以分為幾類:第一類是web1.0,2.0 及基礎服務,我們稱為社區,包括用戶,帖子,新聞,股價,搜索等等,類比對象就是新浪財經門戶+微博;第二類是組合及推薦,主要提供股票投資策略的展示和建議,類比對象是美國的motif;第三類是通道,類似股市中的「支付寶」,接入多家券商,提供瞬間開戶,一鍵下單等等各種方便操作的功能。
雪球的業務實現中,包含很多非同步計算邏輯,比如搜索建索引,比如股票漲跌停發通知,比如組合收益計算等等,為此,我們設計了一個獨立的 Thread/Task 模塊,方便管理所有的後台計算任務。但隨著這些 task 越來越多,邏輯差異越來越大,一個統一的模塊並不是總是最佳的方案,所以,我們又把它拆成了兩大類:流式的,和批量式的。
雪球的推薦體系包括組合推薦「買什麼」和個性化推薦。我們最近正在重新梳理我們的大數據體系,這個感興趣的話可以單聊。
最下面是基礎設施層。雪球基礎設施層包括:redis,mysql,mq,zk,hdfs,以及容器 docker。
線上服務之外,我們的開發及後台設施也很典型:gitlab開發,jenkins打包,zabbix 監控系統向 openfalcon 遷移,redimine向confluence遷移,jira,以及內部開發的 skiing 後台管理系統。
** 三. 雪球架構優化歷程**
首先描述一下標題中的「股市動盪」定語修飾詞吧:
上證指數從年初的3000點半年時間漲到了5000多,6月12號達到最高點5200點,然後就急轉直下,最大單日跌幅 8.48%,一路跌回4000點以下。最近一周都在3900多徘徊。
3月最後一周,A股開戶 166萬戶,超過歷史最高紀錄 2007年5月第二周165萬戶。
4月份,證監會宣布A股支持單用戶開設多賬戶。
6月底,證金公司代表國家隊入場救市。
7月份,證監會宣布嚴打場外配資。
中國好聲音廣告第一晚,帶來超過平時峰值200倍的注冊量
挑戰:小 VS 大:
小:小公司的體量,團隊小,機器規模小
大:堪比大公司的業務線數量,業務復雜度,瞬間峰值沖擊
雪球的業務線 = 1個新浪財經 + 1 個微博 + 1 個 motif + 1 個大智慧/同花順。由於基數小,API調用瞬間峰值大約為平時峰值的 30+ 倍。
挑戰:快速增長,移動互聯網 + 金融,風口,A股大盤劇烈波動。
首先,在app端,在我們核心業務從 web2.0 sns 向 3.0 移動交易閉環進化的過程中,我們開發了一個自己的 hybrid 框架:本地原生框架,加離線 h5 頁面,以此來支撐我們的快速業務迭代。當前,雪球前端可以做到 2 周一個版本,且同時並行推進 3 個版本:一個在 app store 等待審核上線,一個在內測或公測,一個在開發。我們的前端架構師孟祥宇在今年的 wot 上有一個關於這方面的詳細分享,有興趣的可以稍後再深入了解。
雪球App實踐—構建靈活、可靠的Hybrid框架 http://wot.51cto.com/2015mobile/ http://down.51cto.com/data/2080769
另外,為了保障服務的可用性,我們做了一系列的「端到端服務質量監控」。感興趣的可以搜索我今年4月份在環信SM meetup上做的分享《移動時代端到端的穩定性保障》。其中在 app 端,我們採用了一種代價最小的數據傳輸方案:對用戶的網路流量,電池等額外消耗幾乎為0
每個請求里帶上前一個請求的結果
succ or fail : 1 char
失敗原因:0 - 1 char
請求介面編號: 1 char
請求耗時:2 - 3 char
其它:網路制式,etc
炒股的人大多都會盯盤:即在開盤期間,開著一個web頁面或者app,實時的看股價的上下跳動。說到「實時」,美股港股當前都是流式的數據推送,但國內的A股,基本上都是每隔一段時間給出一份系統中所有股票現價的一個快照。這個時間間隔,理論上是3秒,實際上一般都在5秒左右。 交了錢簽了合同,雪球作為合作方就可以從交易所下屬的數據公司那裡拿到數據了,然後提供給自己的用戶使用。
剛才介紹總體架構圖的時候有提到 quote server ,說到這是需要性能的地方。
業務場景是這樣的,雪球上個人主頁,開盤期間,每秒輪詢一次當前用戶關注的股票價格變動情況。在內部,所有的組合收益計算,每隔一段時間需要獲取一下當前所有股票的實時價格。起初同時在線用戶不多,這個介面就是一個部署在 snowball 中的普通介面,股價信息被實時寫入 redis ,讀取的時候就從 redis 中讀。後來,A股大漲,snowball 抗不住了。於是我們就做了一個典型的優化:獨立 server + 本地內存存儲。開盤期間每次數據更新後,數據接收組件主動去更新 quote server 內存中的數據。 後續進一步優化方案是將這個介面以及相關的處理邏輯都遷移到公有雲上去。
對於那些不盯盤的人,最實用的功能就是股價提醒了。在雪球上,你除了可以關注用戶,還可以關注股票。如果你關注的某隻股票漲了或跌了,我們都可以非常及時的通知你。雪球上熱門股票擁有超過 50w 粉絲(招商銀行,蘇寧雲商)粉絲可以設置:當這支股票漲幅或跌幅超過 x%(默認7%)時提醒我。曾經連續3天,每天超過1000股跌停,證監會開了一個會,於是接下來2天超過1000股漲停
原來做法:
股票漲(跌)x%,掃一遍粉絲列表,過濾出所有符合條件的粉絲,推送消息
新做法:
預先建立索引,開盤期間載入內存
1%:uid1,uid2
2%:uid3,uid4,uid5
3%:uid6
問題:有時候嫌太及時了:頻繁跌停,打開跌停,再跌停,再打開。。。的時候
內部線上記錄:
4台機器。
單條消息延時 99% 小於 30秒。
下一步優化目標:99% 小於 10 秒
IM 系統最初的設計目標是為雪球上的用戶提供一個聊天的功能:
送達率第一
雪球IM:Netty + 自定義網路協議
Akka : 每個在線client一個actor
推模式:client 在線情況下使用推模式
多端同步:單賬號多端可登錄,並保持各種狀態同步
移動互聯網時代,除了微信qq以外的所有IM,都轉型成了推送通道,核心指標變成了瞬間峰值性能。原有架構很多地方都不太合適了。
優化:
分配更多資源:推送賬號actor池
精簡業務邏輯:重復消息只存id,實時提醒內容不推歷史設備,不更新非活躍設備的session列表等等
本地緩存:拉黑等無法精簡的業務邏輯遷移到本地緩存
優化代碼:非同步加密存儲,去除不合理的 akka 使用
akka這個解釋一下:akka 有一個自己的 log adapter,內部使用一個 actor 來處理所有的 log event stream 。當瞬間峰值到來的時候,這個 event stream 一下子就堵了上百萬條 log ,導致 gc 顛簸非常嚴重。最後的解決辦法是,繞過 akka 的 log adapter,直接使用 logback 的 appender
線上記錄:5w/s (主動限速)的推送持續 3 分鍾,p99 性能指標無明顯變化
7月10號我們在中國好聲音上做了3期廣告。在廣告播出之前,我們針對廣告可能帶來的對系統的沖擊進行了壓力測試,主要是新用戶注冊模塊,當時預估廣告播出期間2小時新注冊100萬
壓測發現 DB 成為瓶頸:
昵稱檢測 cache miss > 40%
昵稱禁用詞 where like 模糊查詢
手機號是否注冊 cache miss > 80%
注冊新用戶:5 insert
優化:
redis store:昵稱,手機號
本地存儲:昵稱禁用詞
業務流程優化:DB insert 操作同步改非同步
下一步優化計劃:
將 sns 系統中所有的上行操作都改成類似的非同步模式
介面調用時中只更新緩存,而且主動設置5分鍾過期,然後寫一個消息到 mq 隊列,隊列處理程序拿到消息再做其它耗時操作。
為了支持失敗重試,需要將主要的資源操作步驟都做成冪等。
前置模塊HA:
合作方合規要求:業務單元部署到合作方內網,用戶的敏感數據不允許離開進程內存
業務本身要求:業務單元本身為有狀態服務,業務單元高可用
解決方案:
使用 Hazelcast In-Memory Data Grid 的 replication map 在多個 jvm 實例之間做數據同步。
java 啟動參數加上 -XX:+DisableAttachMechanism -XX:-UsePerfData,禁止 jstack,jmap 等等 jdk 工具連接
關於前置模塊,其實還有很多很奇葩的故事,鑒於時間關系,這里就不展開講了。以後有機會可以當笑話給大家講。
組合凈值計算性能優化:
一支股票可能在超過20萬個組合里(南車北車中車,暴風科技)
離線計算,存儲計算後的結果
股價3秒變一次,涉及到這支股票的所有組合理論上也需要每 3 秒重新計算一次
大家可能會問,為什麼不用戶請求時,實時計算呢?這是因為「組合凈值」中還包括分紅送配,分股,送股,拆股,合股,現金,紅利等等,業務太過復雜,開發初期經常需要調整計算邏輯,所以就設計成後台離線計算模式了。當前正在改造,將分紅送配邏輯做成離線計算,股價組成的凈值實時計算。介面請求是,將實時計算部分和離線計算部分合並成最終結果。
實際上,我們的計算邏輯是比較低效的:循環遍歷所有的組合,對每個組合,獲取所有的價值數據,然後計算。完成一遍循環後,立即開始下一輪循環。
優化:
分級:活躍用戶的活躍組合,其它組合。
批量:拉取當前所有股票的現價到 JVM 內存里,這一輪的所有組合計算都用這一份股價快照。
關於這個話題的更詳細內容,感興趣的可以參考雪球組合業務總監張岩楓在今年的 arch summit 深圳大會上的分享:構建高可用的雪球投資組合系統技術實踐 http://sz2015.archsummit.com/speakers/201825
最後,我們還做了一些通用的架構和性能優化,包括jdk升級到8,開發了一個基於 zookeeper 的 config center 和開關降級系統
四. 聊聊關於架構優化的一些總結和感想
在各種場合經常聽說的架構優化,一般都是優化某一個具體的業務模塊,將性能優化到極致。而在雪球,我們做的架構優化更多的是從問題出發,解決實際問題,解決到可以接受的程度即可。可能大家看起來會覺得很凌亂,而且每個事情單獨拎出來好像都不是什麼大事。
我們在對一個大服務做架構優化時,一般是往深入的本質進行挖掘;當我們面對一堆架構各異的小服務時,「架構優化」的含義其實是有一些不一樣的。大部分時候,我們並不需要(也沒有辦法)深入到小服務的最底層進行優化,而是去掉或者優化原來明顯不合理的地方就可以了。
在快速迭代的創業公司,我們可能不會針對某一個服務做很完善的架構設計和代碼實現,當出現各種問題時,也不會去追求極致的優化,而是以解決瓶頸問題為先。
即使我們經歷過一回將 snowball 拆分服務化的過程,但當我們重新上一個新的業務時,我們依然選擇將它做成一個大一統的服務。只是這一次,我們會提前定義好每個模塊的 service 介面,為以後可能的服務化鋪好路。
在創業公司里,重寫是不能接受的;大的重構,從時間和人力投入上看,一般也是無法承擔的。而「裱糊匠」式做法,哪裡有性能問題就加機器,加緩存,加資料庫,有可用性問題就加重試,加log,出故障就加流程,加測試,這也不是雪球團隊工作方式。我們一般都採用最小改動的方式,即,准確定義問題,定位問題根源,找到問題本質,制定最佳方案,以最小的改動代價,將問題解決到可接受的范圍內。
我們現在正在所有的地方強推3個數據指標:qps,p99,error rate。每個技術人員對自己負責的服務,一定要有最基本的數據指標意識。數字,是發現問題,定位根源,找到本質的最重要的依賴條件。沒有之一。
我們的原則:保持技術棧的一致性和簡單性,有節制的嘗試新技術,保持所有線上服務依賴的技術可控,簡單來說,能 hold 住。
能用cache的地方絕不用db,能非同步的地方,絕不同步。俗稱的:吃一塹,長一智。
特事特辦:業務在發展,需求在變化,實現方式也需要跟著變化。簡單的來說:遺留系統的優化,最佳方案就是砍需求,呵呵。
『陸』 美聯儲在今年4月對銀行壓力測試的假設情景是什麼
美國政府將力保銀行不倒閉
通過美聯儲公布的報告,外界可以初步了解政府官員是如何判定大型銀行是否需要額外資金的。美聯儲在其網站上發布聲明稱,按照2月25日出台的「監管資本評價項目」(SCAP)的規定,在過去兩個月的時間里,政府對總資產超過1000億美元的銀行進行了壓力測試,這些銀行囊括了美國銀行系統三分之二的資產和超過一半的貸款。據悉,有超過150位政府監管部門的官員、督察人員及經濟學家參與了壓力測試。考慮到美國經濟和銀行業未來不斷增加的不確定性,監管人員認為大型銀行控股公司還是應該准備額外的資金,以便為高於預期的信貸損失提供緩沖。
推薦閱讀
資深財經記者揭黃光裕入獄真相:弱女子成導火索
發改委:會出措施避下滑
淡水河谷為何退出鐵礦石談判 魏東自殺未讓涌金擺脫監管視線 京新樓盤集體熱銷 開盤當日售罄 基金調研:企業訂單一夜間回來 郎咸平:股市有泡沫 散戶才賺錢 美20歲媽媽生出同母異父雙胞胎 另外,壓力測試要求銀行業對2009和2010年的信貸損失和收入作出預測,還包括到2010年年底時需要為2011年的預期損失計提的准備金。美聯儲表示,監管者對主要銀行進行壓力測試的目的是為了確保其擁有足夠的資本儲備,以在可能出現的更惡劣環境下繼續放貸,而這項測試不能被視為是對銀行當前償債能力的衡量標准。
美聯儲強調,美國大多數銀行組織目前所擁有的資金水平仍遠遠超過需要被供給資本的數額,即使一些銀行壓力測試的結果不盡如人意,美國政府也不能讓它們倒閉,美聯儲也預計截至2010年,上述19家銀行需要應對資產負債表意外的約9000億美元資金缺口。
市場玩起「競猜游戲」
有消息指出,美聯儲上周五已經開始「私下」向19家金融機構通知壓力測試的結果。由於美聯儲都沒有明確指出哪些銀行可能需要在經濟更加惡化的情形下增加資金,引起一片市場猜疑。摩根大通及高盛被市場判斷為相對健康的「低風險」一類,而花旗,美國銀行及富國三家銀行,以及如喬治亞州太陽信託銀行等有較多房地產投資的區域性銀行都被歸為「高危」一類。此外,市場認為,通用汽車金融服務公司(GMAC)也有可能需要集資。
美國金融服務業圓桌會議組織的政府事務高級副總裁塔爾博特表示,對於此次壓力測試,市場的過度反應讓人感到擔心,人們可能會賣空所有銀行類股並從銀行中取回存款。有分析師也表示,監管機構之所以在對外公布測試結果的問題上採取「慢動作」,是為了削弱市場對有關部門銀行業狀況的消息所將作出的反應。
銀行國有化或在所難免
按照相關規定,若某家銀行被認定為增加資本,則可通過轉換政府由於先前注資而持有的優先股至普通股,或在六個月之內吸引私有資本的投資。若仍無法籌集資金,則必須向政府發行可轉換優先股。而在隨後的七年時間里,銀行在徵得監管機構的同意後,可以回購優先股或將其轉為普通股。
有分析人士表示,測試結果可能會迫使銀行籌集額外資金作為緩沖,這些資金可能來自財政部的進一步注資,或可能通過將政府持有的優先股轉為普通股獲得。無論以何種方式,相關銀行都有可能無法避免被「國有化」。
據一份來自最高監管機構的報告草稿,在採取措施穩定金融體系的過程中,美國政府最後或許會獲得大量銀行的普通股股份,將引發大量棘手的問題。
美聯儲公布的報告對金融類股幾乎沒有造成任何影響。24日當天,除花旗集團股價小幅下跌之外,多數銀行股價上漲,道瓊斯工業平均指數上漲了1.50%,報收8076.29點,不過該指數本周累計下跌0.7%,終結了連續6周累計上漲的走勢。
『柒』 什麼是壓力測試
壓力測試
是給軟體不斷加壓,強制其在極限的情況下運行,觀察它可以運行到何種程度,從而發現性能缺陷,是通過搭建與實際環境相似的測試環境,通過測試程序在同一時間內或某一段時間內,向系統發送預期數量的交易請求、測試系統在不同壓力情況下的效率狀況,以及系統可以承受的壓力情況。
然後做針對性的測試與分析,找到影響系統性能的瓶頸,評估系統在實際使用環境下的效率情況,評價系統性能以及判斷是否需要對應用系統進行優化處理或結構調整,並對系統資源進行優化。
『捌』 股票連續三天觸碰半年線後回落什麼情況
已經連續三天觸碰半年線,按常理來說已經可以確認空頭占優,多頭失敗,回落也是正常的,但這也要看情況,比如近3天的成交量是否很大、股價是否處於高位等,如果這樣風險就大了,但如果量不大,不是高位,那麼主力經過壓力測試後心中已經有數,故意虛晃一槍的可能性也存在。
『玖』 壓力測試和性能測試有什麼區別
壓力測試和性能的測試的區別是在於他們不同的測試目的:
壓力測試是為了發現系統能支持的最大負載,他的前提是要求系統性能處在可以接受的范圍內,比如經常規定的葉面3秒鍾內響應 。
所以概括的說就是:在性能可以接受的前提下,測試系統可以支持的最大負載。
性能測試是為了檢查系統的反映,運行速度等性能指標,他的前提是要求在一定負載下,如檢查一個網站在100人同時在線的情況下的性能指標,每個用戶是否都還可以正常的完成操作等。
所以概括的說就是:在不同負載下(負載一定)時,通過一些系統參數(如反應時間等)檢查系統的運行情況。