Quantcast
Channel: iThome
Viewing all 31479 articles
Browse latest View live

臉書開放1PB的使用者互動URL資料,供學者研究社群媒體對選舉與民主的影響

$
0
0

臉書(Facebook)於本周三(7/11)宣布,獨立研究委員會Social Science One正式成立,提供學者可以向Social Science One申請第一個臉書使用者互動URL資料集的存取,來研究社群媒體在選舉與民主中所扮演的角色。

臉書在4月時就推出了一個計畫,並與一群學者合作成立獨立研究委員會,提供研究者可以使用經臉書隱私保護的資料集,來研究社群媒體對選舉和民主的影響。現在,臉書正式宣布此委員會的名稱為Social Science One,並與7個非營利基金會合作,目前聚焦於臉書資料的分析。

同時,臉書也發布第一個1PB臉書使用者互動URL資料集,包含了全球臉書用戶點擊過的公開URL連結,以及包含何時點擊、何種類型用戶,還有經第三方事實審核員判定為假新聞的連結等資料,提供學者們來進行社會科學研究,以了解企業社群媒體平臺對民主程序的影響。

Social Science One共同創辦人Gary King表示,透過私有企業蒐集的資料能夠幫助社會科學家理解並解決社會上的重大議題,但是這些資料至今仍難以用於學術研究,而Social Science One建立了一個道德架構,用於整合隱私保護產業資料,以獲取更大的社會利益,同時確保學術出版的自由。

另外,根據Social Science One官網,這些資料僅會使用於特定的研究提案,且只會在通過匿名同行預審(Peer Pre-Review)後才能使用,且臉書也承諾,在研究結果出版前,不會審查或批准結果。

 


暗網販售RDP非法存取IT系統名單,只要10美元就能駭入國際機場

$
0
0

要當駭客門檻已經降低!安全廠商發現網路罪犯們在暗網兜售可透過遠端桌面協定(remote desktop protocol, RDP)存取的可能受害IT系統相當多樣化,其中不乏物聯網裝置及政府、醫院、國際機場的系統。

McAfee進階威脅研究小組近日研究暗網上數個販售RDP門戶大開的裝置名單的市集,並對這些市集銷售的「商品」做了分析。這些市集銷售的RDP受害裝置名單小至15個,大到俄羅斯主要暗網市集UAS的40,000台,可讓駭客輕易進入受害電腦行不法之事。

研究人員指出,RDP是微軟讓用戶得以存取其他電腦的遠端存取協定,本身是強大的系統管理工具,但落入歹人之手就可能變成攻擊管道。

根據研究,RDP非法存取最主要用途是借道用戶伺服器/PC進行攻擊,藉此隱匿自己的來源IP,省去社交工程、使用攻擊套件及程式隱匿手法的麻煩。其次用途是大量發送垃圾郵件、竊取用戶信用卡或帳密等資訊、以及現今最熱門的挖礦、賺門羅幣(Monero)等。另外,雖然大部份駭客以網釣郵件及攻擊程式發送勒索軟體,也有像SamSam等駭客組織直接利用RDP後門程式偷潛入用戶系統。

研究發現,從RDP非法存取的受害名單來看,依作業系統類別,從久遠的Windows XP到最新的Windows 10都有。但Windows Server 2008和2012是最大宗,分別有11,000到6,500個研究樣本。而價格從3美元到19元不等,後者為具有管理員權限的高頻寬系統。

執行微軟Windows IoT的物聯網系統也是一大目標;研究人員發現,數百個以是Windows IoT(舊名Windows Embedded Standard),並使用1-GHz VIA Eden處理器的系統。研究人員相信這類系統可能位於荷蘭城市、住家和醫療系統。此外,還發現多個國家的公家系統,包括美國政府持有的系統。另有數十家為醫院、護理及醫療設備商。

研究人員特別指出,他們在數家市集上發現屬於一家主要國際機場的IP位址,他們在一台Windows Server 2008伺服器上發現兩個機場重要設施相關的帳號,一是安全及建築自動化系統,二是攝影監控及影像分析系統。而這個機場另一台電腦上,則可看到機場聯外自動運輸系統的登入帳號。駭客不用撰寫零時差攻擊、或發動網釣郵件或水坑式攻擊,只要10美元就可以買到這些系統名單。

為免被遭到非授權RDP存取,研究人員建議企業,應用複雜密碼及雙因素驗證工具避免被暴力破解RDP密碼,在開放網際網路上也絕對不可允許RDP連線。留心異常存取的行為,對於多次存取失敗的用戶應採取封鎖或使其失效。此外也可考慮使用不會曝露組織資訊的帳號命名法,並清查網路上所有系統的外部存取協定。

硬是不讓AT&T與時代華納合併,美國司法部提出上訴

$
0
0

美國司法部本周四(7/12)針對美國聯邦法官Richard Leon在上個月同意AT&T與時代華納(Time Warner)合併一案提出上訴,再度出手企圖阻止這兩家業者的合併案。

AT&T在2016年10月宣布將以854億美元收購時代華納,美國司法部則是在2017年11月提出反壟斷訴訟,認為雙方的合併將會減少創新、危及市場競爭,還會抬高市場售價。

AT&T為全美第二大電信業者,時代華納則是全球第三大娛樂公司。司法部的論點為,AT&T龐大的影片遞送基礎架構再加上時代華納的熱門內容,非但是美國史上最大的併購案,也將讓AT&T取得時代華納的內容網路控制權,可迫使其它遞送網路支付更多的授權金而妨礙競爭。

不過,聯邦法官Leon在今年6月12日認為司法部未能充份證實該併購案違反反壟斷法,因而決定無條件放行該交易,AT&T很快地在6月14日宣布已完成時代華納收購案。

本周司法部則針對Leon的判決向美國聯邦巡迴上訴法院提出上訴,但並未提供額外的說明,反倒是AT&T對此發表了聲明,表示官司中輸的一方總是有上訴的權利,但聯邦法院的判決是基於事實與充份的理由,很訝異司法部在這樣的情況下選擇了上訴,AT&T將會捍衛聯邦法院的判決。

IBM:10款惡意程式暗藏木馬,成功潛入Google Play

$
0
0

IBM資安團隊X-Force從6月起,在Google Play商店接連發現了至少10款惡意應用程式,這些惡意軟體都以阿奴比斯銀行木馬(BankBot Anubis)感染使用者的裝置,藉由偷取使用者的銀行帳密,進行金融詐欺犯罪。研究團隊提到,雖然10隻惡意程式數量不多,但在每隻惡意軟體的C&C伺服器(Command-and-Control)都可以採集到超過一千個樣本,影響總範圍並不小。

隨著Google Play這類應用程式商店,開始採取了安全層級的機制,進一步阻礙了惡意軟體的散布,不過,這些駭客也並非是省油的燈,研究團隊提到,惡意行為趨向分工化與專業化,為規避不斷發展的應用程式商店防禦機制,駭客現在的策略傾向於不一開始就將惡意軟體本體上傳到商店中,以避免輕易的被偵測以及抽驗發現。

取而代之,駭客們會先上傳一個看似無害的軟體,其中夾帶下載器,下載器相對於惡意軟體本身,更有機率閃過安全檢查和遞迴掃描,而且一旦成功登陸被害者的裝置,便可以大開後門,將惡意軟體本體迎入系統內。這些在應用程式商店中的惡意下載器,以感染阿奴比斯銀行木馬為主要目的。

當受害者成功安裝惡意下載器後,該應用程式便會從C&C伺服器下載阿奴比斯銀行木馬本體,而該木馬會以Google Protect為名(下圖,來源:IBM X-Force),偽裝成正常應用,並要求使用者授予存取權限。而要求存取權限的目的,是要側錄使用者的鍵盤行為,這與大多數的銀行木馬不同,過去通常會在目標畫面上,蓋上一層假的畫面,誘騙受害者信以為真,在上面輸入帳號密碼。但阿奴比斯銀行木馬透過側錄鍵盤,就可以在任何的應用程式中竊取帳密。

這些含有惡意下載器的應用程式被設計來針對土耳其語言用戶,但透過不同的殭屍網路以及設計,阿奴比斯銀行木馬也影響30多個國家包含臺灣。研究團隊透過下載次數以及找到的惡意軟體,來估算Google Play商店中,這些惡意行為的活躍程度。在其中一個案例中,研究團隊找到了一千多個阿奴比斯銀行木馬的樣本,每個樣本都有不同的MD5簽章。

IBM X-Force研究團隊提到,這類的網路犯罪服務在黑市很常見,在商店中散布這些下載器的人,向各方惡意組織提供著專業服務,以進一步使用行動木馬進行金融詐騙。這些人有能力不停地更新惡意下載器,並維持C&C伺服器的運作,以感染更多的受害者,這都一再證明了此為一個有組織、有技術且深思熟慮的犯罪集團。

另外,把惡意軟體偷渡到官方商店中,對於駭客們來說效率很高,因為上面有最多的活躍使用者,而且使用者會傾向相信官方商店上的內容,因而降低了警覺性。X-Force研究團隊也認為,這些有組織的散布惡意木馬的行為已經商業化,並且存在專業的服務供應商,使用者應該意識到行動惡意程式所帶來的風險。

鎖定中小企業資料上雲需求,微軟Azure推出Data Box Disk

$
0
0

企業想要搬上雲端,除了搞定應用程式相依性、提高系統自動化程度,如何把數TB的資料搬遷到公有雲,也是經常碰上的難題。在2017年微軟Ignite大會上,微軟就有推出Azure資料箱(Data Box)預覽版服務,企業將資料匯入後,數據會採用256位元AES資料加密,當資料完全上傳至Azure雲端環境後,資料箱內的數據會完全清除。而在近日,微軟又推出新的資料實體搬遷Azure Data Box Disk,鎖定更小規模資料的搬遷。

微軟表示,相比Azure Data Box提供的大容量資料搬遷服務,許多企業反映,希望能提供更小容量的使用選項。例如,當分支辦公室、遠端辦公室儲存的數據要上雲時,其資料規模不如總部,也不需要使用Azure Data Box的大容量。因此,微軟才推出了新產品線Azure Data Box Disk。

以硬體規格而言,Data Box Disk最多一次能預定5顆8TB的硬碟,搬運40TB的數據。而微軟所提供的傳輸介面是常用的USB、SATA II及SATA III,使用簡單拖拉操作,或者搭配複製指令Robocopy,企業就能將資料匯入到該儲存設備。在資料加密處理上,Azure Data Box Disk採用了128位元AES資料加密。目前LG為在南韓的自動駕駛測試中心,就使用了Data Box Disk。

利用實體設備搬移大量資料的做法,AWS是其中的領頭羊。在2015年re:Invent大會就釋出了資料運送箱服務SnowBall,透過快遞公司再將企業資料送上AWS雲端。在AWS推出此服務後,其他雲端大廠Azure、Google及IBM,也紛紛開始釋出相仿的資料運送服務。

有較大資料搬遷需求的企業,可以選擇Data Box服務。目前它可以支援Azure Blob、Files儲存。該裝置提供2個1Gbps及2個10Gbps傳輸介面,搭配SMB、CIFS等通訊協定傳輸資料。此外,儲存在Azure Data Box的資料,皆會採用256位元AES資料加密。圖片來源:微軟

相比Data Box,Azure Data Box Disk的定位是鎖定比較小規模的資料搬遷,使用方法也相對簡單。該裝置所提供的介面,是一般使用者常用的USB、SATA II及SATA III介面,利用最簡單的拖拉複製,或者複製指令robocopy就可以搬移數據。圖片來源:微軟

 

Python之父心很累,宣布永久卸下「仁慈的獨裁者」重任

$
0
0

被稱為仁慈的獨裁者(Benevolent Dictator For Life,BDFL)的Python之父Guido van Rossum,7月12日在郵件列表對社群宣布,經過了PEP 572之亂後,有鑑於他花費許多心力卻換來不少人批評他的決定,因此他宣布給自己在BDFL這個職務上放一個永久長假,而且不會指定後繼人選,社群可以依照自由意志制定新的決策方法。

Guido van Rossum在這封以Transfer of Power為標題的信中表示,PEP 572已經完成,他從來不想要為了一個PEP打得這麼用力,更何況許多人對於他的決定不以為然。因此他想把自己移出決策過程,單純的當一個核心開發者,他表示,仍然會繼續在社群中耕耘,也可以指導其他開發者,而這樣或許對於Python更有幫助。

但可以確定的是,他已經決定永久離開BDFL的位置,社群現在可以依照自由意志來控制語言發展。Guido van Rossum提到,反正那天終究會到來,他也不再年輕,健康狀況更是每況愈下。由於他不會指定BDFL的繼任者,因此詢問社群對於他不再干涉決策後,要以什麼方式進行決策。

BDFL最重要的事務有兩項,第一是PEP的決定,第二項則是徵招核心開發者的方法。其他諸如問題追蹤器或是GitHub上的日常決策,社群通常不會要求Guido van Rossum介入。他提到,這件事情必須要由社群自己決定,他提議或許可以把這些程序寫成PEP,讓這個PEP成為社群的章程。

他在信中最後強調,他會一直都在,並試著讓大家自己解決現在這個狀況,他現在很累,需要一段長時間的休息。

引起這個社群爭戰的是PEP 572指派表示式(Assignment Expressions)提案,Guido van Rossum主張要在Python中新增一個:=符號,允許在表示式中進行指派。也由於BDFL這個位子,在有必要時可以直接做出決定,因此Guido van Rossum在爭論還未到一個段落時,逕行決定接受PEP 572。

雖然這個功能在不少語言中都有支援,但是PEP 572被提出時,仍然引來正反兩方論戰,Guido van Rossum認為,在表示式中允許變數指派,可以加速程式開發,讓開發者少寫很多程式碼。而即便到現在PEP 572被接受已成定局,仍有強烈反對者發誓不會在程式碼中使用這個新語法,並批評Guido van Rossum就仁慈的獨裁者位子,獨裁遠多於仁慈。

在Guido van Rossum發布這個公開信後,論壇上引發了熱烈討論,絕大多數的人很感謝Guido van Rossum的貢獻,也肯定他所達到的成就,認為BDFL的存在,讓Python比起其他程式語言在發展過程,能更有效率解決許多意見分歧。也有網友提到,Guido van Rossum服務Python社群超過20年,在某種意義上離開自己的孩子是一個了不起的舉動,但應該要把職務交給一個稱職的繼任者。

微軟分析工具Azure Application Insights正式上線,助企業透視使用者行為

$
0
0

在2017年的Build開發者大會上,微軟宣布,推出Azure Application Insights使用者行為分析,當時該服務還是預覽版。而在近日,該功能已經正式上線。

起初Azure Application Insights內建的三大分析功能,分別是用戶人數、時段(Session)以及事件。利用瀏覽器Cookie儲存的匿名ID,計算企業應用程式的瀏覽人數。再者是時段分析工具,可以紀錄應用程式中特定頁面、功能中的使用者活動。最後為事件分析功能,計算企業服務中,特定頁面或者功能被存取的頻繁程度。

而現在使用者分行為分析功能正式上線後,微軟除了原先這三大資料分析外,微軟這次一口氣新推出6個新工具,包含使用者流程(User Flows)、同類群組分析(Cohort)、漏斗分析(Funnel),以及與Visual Studio App Center整合等服務。

第一個新功能是使用者流程分析功能,該功能會記錄使用者在網頁、應用程式上的瀏覽軌跡,從一開始點選進頁面,中間操作哪些功能,到最後離開該服務頁面。該服務可將該使用者一連串操作行為,透過視覺化方式呈現。如此一來,企業用戶就可以剖析,該服務中哪些流程設計不佳,導致使用者反覆操作。藉這些資料,產品團隊可以更了解,整體服務中,哪些流程還可以持續改善。

而第二個漏斗分析服務。團隊可以分析使用者從進入網頁應用後,經過多個操作流程後,最後留下的用戶人數,追蹤每一步驟的轉換率。在該操作頁面上,可以觀察在特定時間範圍內,從一開始登入首頁,中間各個關卡的使用者人數及轉換百分比率。除了報表數字,漏斗分析服務也會利用橫條圖、折線圖,讓使用者可以快速解讀。此外,這些資料,也可以匯入至微軟的商業智慧工具Power BI整合。

再者是影響力分析(Impact),除了歸屬應用程式的服務設計體驗、流程規畫的內部因素,企業也會想了解,還有哪些潛在因子,會影響應用程式、網頁的轉換率。微軟舉例,影響瀏覽量常見的原因,包含網頁讀取速度、使用者選擇瀏覽器版本等。而將此些因子列為過濾條件後,影響力分析功能就可以列出企業服務的使用者轉換率。

第四個新功能是使用者及時間軸分析(User and session timelines )。介面中可以以國家別、使用作業系統、瀏覽器等維度,將使用者初步進行劃分。經過去識別化處理後,每個使用者會被分配至一個獨立ID,企業可以進一步追蹤,單一使用者的精確操作行為,例如顯示某日瀏覽時數、操作流程等資訊。

其次,同類群組分析也是分析工具必備利器之一,將母體中不同性質的使用者分群,個別進行分析。微軟表示,雖然Azure Application Insights的同類群組分析類似其他過濾條件,不過它的差異點在於,開發者可以自行定義Analytics queries,享有更大的彈性。當開發者定義一組新的分群條件後,也可以儲存該樣板,讓團隊其他成員重複使用。

最後一個重要新功能,則是Azure Application Insights與Visual Studio App Center進行整合,開發者可以將App Center設定好的遙測功能,與Azure環境整合,現在行動應用也可以使用Azure Application Insights這些分析服務了。該功能可以支援的應用程式環境,包含iOS、Android、Xamarin、 Universal Windows,或者React Native應用。

在2017年的Build開發者大會上,微軟宣布,推出Azure Application Insights使用者行為分析,當時該服務還是預覽版。一開始,Azure Application Insights內建的三大分析功能,分別是用戶人數、時段(Session)以及事件。圖片來源:微軟

利用使用者流程分析功能,可以記錄使用者在網頁、應用程式上的瀏覽軌跡。企業用戶可以剖析,該服務中哪些流程設計不佳,導致使用者反覆操作。藉這些資料,產品團隊可以更了解,整體服務中,哪些流程還可以持續改善。 圖片來源:微軟

使用漏洞分析服務,可以分析歷經多個操作流程,每一步驟的使用者轉換率,除了報表數字,漏斗分析服務也會利用橫條圖、折線圖,讓使用者可以快速解讀。此外,這些資料,也可以匯入至微軟的商業智慧工具Power BI整合。 圖片來源:微軟

 

企業也會想了解,還有哪些潛在外部因子,會影響應用程式、網頁的轉換率。影響瀏覽量常見的原因,包含網頁讀取速度、使用者選擇瀏覽器版本等。使用影響力分析功能,將這些因子列為過濾條件後,就可以列出服務的使用者轉換率。圖片來源:微軟

在使用者及時間軸分析(User and session timelines )功能的介面,可以利用國家別、使用作業系統、瀏覽器等維度,將使用者初步進行劃分。經過去識別化處理後,每個使用者會被分配至一個獨立ID,企業可以進一步追蹤,單一使用者的精確操作行為。圖片來源:微軟

Azure Application Insights的同類群組分析類似其他過濾條件,不過開發者可以自行定義Analytics queries,而新的分群條件後也可以儲存為樣板,讓團隊其他成員重複使用。圖片來源:微軟

 在Azure Portal中,使用者可以選擇整合Application Insights及Visual Studio App Center,現在行動應用也可以使用Azure Application Insights這些分析服務,可以支援iOS、Android或者Xamarin其他環境。圖片來源:微軟

駭客入侵JavaScript套件ESLint Scope以竊取npm存取令牌

$
0
0

JavaScript工具套件出版商ESLint周四(7/12)透露,駭客盜用了該套件維護人員的npm帳號,並上傳了含有惡意程式的版本,以竊取其它用戶的npm憑證,在短短的幾小時內,即有4,500個帳號的存取令牌(access token)遭竊,為了避免災情擴大,npm撤銷了所有在昨天以前建立的存取令牌。

npm的全名為Node Package Manager,是Node.js預設的軟體套件管理系統,而ESLint則是JavaScript套件供應商,主要出版JavaScript程式分析工具。

意外的發生來自於ESLint的一名套件維護人員重複使用了已外洩的電子郵件及密碼作為npm帳號的憑證,而且未啟用雙因素驗證,使得駭客輕易地就登入了該名工程師的npm帳號,建立新的npm存取令牌,並於npm上出版含有惡意程式的eslint-scope@3.7.2與eslint-config-eslint@5.0.2。

一旦安裝了上述任一個版本,惡意程式即會自pastebin.com下載與執行一個可將用戶的.npmrc檔案傳送給駭客的功能,該檔案通常含有npm的存取令牌。

儘管這兩個偽造檔案從上傳到被下架的時間不到3個小時,但根據npm的估計,已有約4,500個帳號的存取令牌遭竊。

為了防範災情蔓延或造成連鎖效應,npm撤銷了在昨天以前所建立的所有存取令牌,也呼籲npm的註冊用戶必須重新取得npmjs.com的驗證與產生新的存取令牌。

ESLint則奉勸所有的npm套件維護人員都應避免使用重複的憑證,最好啟用npm的雙因素驗證機制,以及限制有權在npm出版套件的人數,另也建議應用程式開發人員應該利用工具來拑制新套件的自動安裝能力。


蘋果更新MacBook Pro產品線,效能提升、鍵盤更安靜了

$
0
0

蘋果在本周更新了含有觸控列(Touch Bar)的13吋與15吋MacBook Pro,標榜15吋的效能提升了70%,13吋則提升100%,然而,蘋果對外透露並沒有修正MacBook鍵盤容易卡住的問題,而只是讓鍵盤的聲音變小了。

蘋果在2015年以蝶式鍵盤取代傳統剪刀式鍵盤,卻被用戶批評新的蝶式鍵盤含有設計瑕疵,容易因灰塵或碎片跑進鍵盤而故障,MacBook與MacBook Pro用戶在今年5月對蘋果提出集體訴訟,6月蘋果即宣布將免費維修相關鍵盤

在此次發表中,蘋果提到有關鍵盤改善的部份只說它在輸入時更安靜了,另向CNET坦承並未針對鍵盤容易卡住的問題進行修正。

這次蘋果只升級了含有觸控列的兩款高階MacBook Pro,並沒有更新基本款的13吋MacBook Pro,也未更新MacBook與MacBook Air。

新款的13吋MacBook Pro採用了第八代的Intel Core四核心處理器,可選擇時脈為2.3GHz的Intel Core i5或2.7GHz 的Intel Core i7,記憶體容量則有8GB與16GB兩種選擇,亦有多種儲存空間選項,最低階售價為1,799美元(台灣售價為57,900元新台幣)。

15吋MacBook Pro則是採用第八代的Intel Core 7及i9六核心處理器,較低階的i7機種售價為2,399美元(77,900元新台幣),高階i9機種則是2,799美元(89,900元新台幣)。

硬體的升級還包括具備原彩(True Tone )顯示技術的Retina螢幕,以及原本應用在iMac Pro中,用來強化安全並支援Siri聲控功能的Apple T2晶片。新一代MacBook Pro可望於本周上市。

企業IT飆速關鍵大公開

$
0
0

數位轉型浪潮吹進臺灣,越來越多企業也想要效法網路公司,擁抱新一代IT架構和開發方法,來改造自家IT的開發力,但要從傳統大型應用和瀑布式開發流程,轉而擁抱雲端原生架構、微服務架構、DevOps、敏捷開發,甚至是最夯的容器技術和Kubernetes,企業該如何上手?iThome深入專訪一手設計出Netflix雲端架構的雲端教父Adrian Cockcroft,揭露企業實現高速IT的關鍵

當年,雲端教父如何成功讓Netflix成為第一間完全上雲的大型企業

$
0
0

關於這趟旅程,起點是2008年8月的一次SAN儲存設備故障事件,足足讓Netflix的關鍵資料庫系統當機2天,當時因為無法查詢訂單資料,一連3天,沒有寄出任何一片顧客租借的DVD影片。大家都在問Netflix怎麼了!Netflix是全美最大的DVD租片服務公司,顧客透過網站租片,過兩天就會在自家郵箱收到,看完再用回郵信封寄回。

這次事件讓Netflix開始反省,就算砸大錢,買來業界最高階的Oracle資料庫系統,搭配最頂級的硬體設備設備,為何還是會出錯?當時Adrian Cockcroft是網站工程團隊的總監,他開始意識到:「服務可用性的主角應該是應用程式,而不是硬體。」而順著這個思路進一步發現,其實,Netflix不見得需要昂貴的硬體,而是可以考慮租用便宜的雲端環境,也許就夠了。

這並不是Netflix獨到的經驗,很多企業資訊主管遇到當機事件時,都會有同樣的反省。但是,「得等到出現外在危機的壓力,企業才會真的願意採取行動,我們也是。」Adrian Cockcroft事後回憶。

Netflxi在2010年4月公開上雲計畫,所有人都不看好,直到年底公開了這張AWS架構圖後,才讓大家意識到,大型企業真的也可以上雲。

 

全球布局的外部壓力浮現,才下定決心上雲端

這個來自外部的壓力,出現在2009年。Netflix除了租片服務,從2007年也開始在美國提供線上影片串流服務,當年2月,Netflix宣布累計出借了10次億份DVD,但他們的串流服務人數,遲遲沒有突破1千萬用戶。

之後,Netflix在2010年進軍國際市場,而為了解決DVD全球寄送的問題,Netflix決定改變,開始主推線上串流服務。這也讓Adrian Cockcroft開始思考,新業務帶來的挑戰有多大。

原有的DVD出租生意,顧客大約每周使用一次Netflix網站來租片,須等到DVD寄到顧客手上看完後,顧客才會再次上站來租片,寄送的時間,往往決定了顧客下次何時再上線挑片的頻率,而這個頻率大約是每人每周一次。

但是,線上串流服務的挑戰完全不同,Netflix串流服務顧客每天大約可以可以觀賞5到6段影片,租片量是DVD租片的10倍以上,而影片還提供個人化瀏覽服務,顧客會花更多時間上站選片,甚至顧客看到一半停下來,網站還要記住他當時所看到的進度,下次再繼續播放。根據Adrian Cockcroft估計,串流顧客與Netflix官網的互動(瀏覽)頻率,大約是租片顧客的100倍。

換言之,租片量10倍成長,顧客互動次數增加100倍,兩者相乘,租片顧客改用串流服務後,每周帶來Netflix資料中心的流量成長,是過去的1千倍。只要有0.1%的用戶改用串流服務,Netflix資料中心承受的流量規模,就要翻倍。

轉移前端系統時,Netflix的策略是,先從最簡單的網頁開始轉移,一次只將網站上的一頁服務搬上雲端。這是Netflix第一個搬上AWS的網頁。(資料來源:Adrian Cockcroft)

 

IT未來要考慮全球顧客的參與度

從IT營運模式的改變來看,Adrian Cockcroft指出,過去IT只需考慮到,以員工人數來決定系統的擴充規模,但未來IT要考慮全球顧客的參與度,以此決定擴充規模。這個數位轉型壓力是根本性的變革,從服務數百、數千人,到服務全球顧客,而且要提供24小時服務。

2009年時,Netflix有兩個選擇,第一是雇用一個世界級資料中心維運團隊,未來需要多少用量,就預先建置多少資料中心。第二個選擇是使用Netflix競爭對手AWS提供的雲。當時的Amazon Prime影片串流服務,是Netflix最大的競爭者。「選擇自己蓋資料中心,還是租用競爭對手的服務,改把錢花在內容和開發者身上。」Adrian Cockcroft表示,這是當年經營高層最頭痛的抉擇。

還有一個難題,促使Netflix最後決定上雲端。那就是進軍全球市場後,Netflix串流服務也會整合到多種播放裝置上,不只是電腦,還增加了iPhone、Wii、PS3和Xbox的版本,未來的成長規模幾乎難以預測。如何滿足至少是1千倍的擴充需求?Netflix決定開始認真評估,了解搬上雲端的風險。

首先,考慮AWS業務和Amazon Prime服務的關連,後來Netflix高層也直接聯繫Amazon創辦人,確定兩者各自獨立運作。其次是要測試AWS的能耐,評估AWS的擴充能力,能否勝過自行建置資料中心的速度。後來,Netflix簽署AWS 第一個企業授權契約,直接上網用信用卡刷卡就完成這件事。

直到2010年4月,Netflix開始公開即將上雲的消息,Adrian Cockcroft表示,大家都覺得他們瘋了,因為他們是第一家這麼做的大企業。不過,早在2009年,Adrian Cockcroft率領的網站工程團隊,就展開上雲轉移的作業。而這個過程的第一步,是先檢視那些不會直接面對顧客的系統,決定先將影片編碼(Movie Encoding)伺服器放上AWS的EC2。因為,這類影片編碼服務需要大量機器來運算,但現有資料中心的空間並不足以擴充。

選定搬遷的目標後,下一步就是要測試EC2的擴充能力,Adrian Cockcroft表示,那次一口氣向AWS提出要求,想在一小時內要取得3千臺EC2虛擬機器,後來,真的拿到了,也才讓Netflix相信,雲端真的可行;接著,就真的把影片編碼的實體主機關了,全部搬上EC2。影片編碼的處理,租用了數千臺EC2實例來組成運算農場,當時還用了不少Windows環境的影片轉碼軟體,處理了上萬部影片,而為此而儲存在S3的資料量,已經高達PB級。

除了影片編碼,第二步則是改將大量的網站存取日誌放上雲端,尤其是所有串流服務的日誌。Netflix有太多想紀錄追蹤的資訊,都改用S3來儲存,這些日誌資料每天的成長量也是TB級。最後,利用Hadoop來分析,還和AWS合作整合Hive SQL來設計資料超市,再整合到Netflix內部資料中心的BI系統上。

2010年初,Netflix就決定不再蓋資料中心了,並且在年初開始也把串流服務的後端系統搬上雲,例如像是DRM金鑰管理、用戶重播書籤服務、高可用設計的「播放」按鈕服務等。

Netflix還決定要在2010年底前,要把前端系統和用戶端設備的API服務,也都搬上雲端。當時,多數後端系統仍部署在資料中心內,不過,前端上雲後,機房就可用於擴充後端系統。

過去IT只考慮服務員工數,來決定系統規模,但未來IT要考慮全球顧客的參與度,來決定擴充力道,這個數位轉型壓力,是根本性的變革。──雲端教父 Adrian Cockcroft

 

2010年底官網前端系統全面上雲

「我們沒有備案!一定要在年底前將網站前端搬上AWS。」那時,Netflix每次經營會議時,都會秀出一張圖,上面有一臺準備起飛的飛機,代表著Netflix,軌道盡頭就是樹林,「到了年底,沒有飛上雲端,就會撞上樹林。」Adrian Cockcroft強調。在2010年12月初,完成官網最後幾頁的轉移,過程沒有發生任何一次當機,Netflix順利飛上了雲端。

原本,Adrian Cockcroft一開始設計了一個漸進式轉移的作法,但他的老闆直接指示:「全部砍掉重練!頂多留下你覺得有用的10~20%,你不要的程式碼,一行都不要留。」他希望趁著重新設計的機會,要求Adrian Cockcroft設計可符合未來5年需求、兼顧效率和生產力的新架構。「因為,我們不想成為一味節省成本的公司,而要追求業務速度。」Adrian Cockcroft表示。

除了重新打造新架構,在轉移前端系統時,Adrian Cockcroft的策略是,先從最簡單的網頁開始轉移,逐次將網站上的一頁服務搬上雲端,並且先從最簡單的API服務開始轉移,其次是轉移對應的頁面,然後再進行下一個API和下一個頁面。同樣的作法,先套用到其他服務頁面,再來,才是轉移其他不同資料來源的頁面。

因為是一頁一頁地轉移上雲端,因此,他們也採取雙軌系統並行。用戶先登入位於資料中心的舊版官網網頁、後端系統和登入服務,再挑選合適網頁,切換成由雲端提供服務的版本給顧客。一旦出現問題,可以馬上切換回來,因為採取標準HTTP轉址來切換,因此,顧客不會察覺。

在資料轉移的策略上,原有系統資料都儲存在Oracle資料庫中,先利用Oracle遠端副本功能,在雲端建立一份副本資料庫,多數用戶只是需要查詢資料,就先由雲端資料庫來提供,只有用戶需要更新記錄時,才連回資料中心的Oracle資料庫來修改。

2011年決定全面上雲端後,新的挑戰是如何備份。過去,Netflix採用磁帶進行離線備份,來保存系統記錄。上了雲端後,Adrian Cockcroft不想把資料再運回本地端資料中心來備份,因此,改而不同的服務區域,建立不同的AWS帳號,利用不同帳號的S3服務,來提供另一個備份。

此外,所有系統記錄資料不會刪除,而是採取每90天自動執行清除程式,將資料壓縮備份到歸檔區的S3帳號,因為可預期這些資料存取頻率不高,壓縮資料的時候,也以縮小容量為主,而不用考慮解壓縮速度來節省空間。後來AWS推出了超便宜的歸檔服務Glacier,就有更彈性的備份策略可用。

後來,Netflix發現,上雲的決定是正確的作法。因為拓展到全球市場後,光是2009年第三季到2010年第三季,一年內串流服務就成長了145%,從原有的1千萬名用戶,增加到1,600萬人。更大的挑戰是,到了冬天,大家都待在家裡看電視,從感恩節到聖誕節期間的串流影片需求,將會大爆發。2011年時,Netflix就決定,全面上雲,連後端和全部資料都要搬上去,不過,仍有少數資料轉移不易,例如,當時有些支付法規遵循的要求,規定資料必須落地。結果,他們花了7年時間,直到2016年1月,Netflix才完成所有雲端轉移工作,並且關閉了資料中心的最後一臺機器。

 

數位轉型三階段:速度、規模,以及策略

從Netflix上雲的經驗,Adrian Cockcroft歸納,企業數位轉型的途徑可分成三階段。第一,是先追求速度,採用新架構,例如將所有JAR元件都微服務化,就不用每隔兩周得關機10分鐘來更新,或是統一服務設計模式,而不是共用一套標準程式碼,同時,還將複雜糾纏的服務API,改為功能分明的分層式架構。這些設計,後來讓Netflix的雲端架構,成為微服務架構的經典參考範本。

「有了速度,下一步才追求規模。」他解釋,例如,透過水平式擴充架構,滿足越來越多服務上雲後的運算需求,還要提高利用率。數位轉型的最後一個階段,就是策略性轉型,目標是徹底取代資料中心,將關鍵應用搬上雲端。

Netflix租用了超過10萬個EC2虛擬機器,來服務遍布全球130多國市場的上億名用戶。根據Netflix統計,從2007年12月到2015年12月為止,每月串流服務播放總時數,成長了1千倍以上。正是因為當年上雲端的決定,才能支撐起這樣的千倍的發展速度。

 

 Profile 

雲端教父 Adrian Cockcroft

1982年:進入劍橋顧問公司擔任軟體工程師,一待就是6年,專責開發即時嵌入式訊號處理和控制系統,後來還兼職擔任Unix系統首席管理員。

1988年:進入昇陽電腦,任職長達16年,直到2004年才離開昇陽,他不只熟諳雲端技術和軟體技術,更是高效能電腦技術的專家,最後成為昇陽高效能工業計算(HPTC)部門的首席架構師。在昇陽期間,也有多本高效能電腦的相關著作,例如他是《Sun Performance and Tuning:Java and Internet》第二版一書的第一作者,這是暢銷的HPC調校參考書之一。

2004年:離開昇陽後,9月轉而進入eBay工作,主要參與多項創新計畫,也是eBay Research Lab創始團隊成員之一。早在iPhone和Android問世之前,Adrian Cockcroft就開始研發自製手機和先進行動應用。

2007年:進入Netflix,擔任網站工程團隊總監,負責Netflix首頁開發,以及打造個人化選片服務,尤其是研發背後的演算法,也參與了Netflix Java系統重構計畫,也就是SOA架構的導入。

2008年8月:一場SAN儲存設備大當機,Netflix開始考慮採用雲端。Adrian Cockcroft是關鍵評估者之一。

2009年:Netflix開始展開雲端轉型之旅,先將內部系統搬上雲端AWS,例如影片編碼。

2010年:進一步將網站前端系統全部放上AWS。

2010年4月:Netflix開始宣布上雲端計畫。

2010年12月:正式完成官網上雲端轉移。

2011年:開始將後端系統搬上雲端。

2013年:Netflix也大方公開了這套轉型上雲端的經驗,甚至打包自己開發的工具和架構設計範本,開源推出了NetflixOSS平臺,這也成了設計雲端原生架構的最佳實務參考之一。

2014年:Adrian Cockcroft離開Netflix,轉而進入Battery Ventures創投擔任技術院士,從更宏觀的角度,來觀察科技產業、網路新創、創新技術的發展。

2016年1月:Netflix最後一批資料搬上雲端,完成了為期7年的雲端之路。

2016年10月:Adrian Cockcroft進入AWS擔任雲端架構策略副總裁,不只帶領AWS的開源推動工作,也開始到各國分享自己一路參與雲端架構發展的經驗。

2018年6月:Adrian Cockcroft首次來臺分享數位轉型經驗和雲端發展策略。

【深度專訪AWS雲端架構策略副總裁】衝刺數位轉型,企業需要什麼IT新架構?

$
0
0

他是打造Netflix全球服務架構的關鍵人物。早在2009年,當時擔任Netflix網站工程總監的Adrian Cockcroft,就開始率領團隊藉助AWS雲端基礎架構,來改造Netflix的IT架構。這個關鍵基礎建設,更助Netflix奠定了全球影片串流服務的龍頭地位。Netflix還大方公開了這套轉型上雲端的經驗,甚至打包自己開發的工具和架構設計範本,開源釋出了NetflixOSS平臺,這也成了設計雲端原生架構的最佳實務參考之一。

當時,Adrian Cockcroft被譽為比AWS更懂得善用AWS的架構師,更有雲端第一架構師的美稱,科技圈也將他選入雲端運算年度十大關鍵人物之一。

Adrian Cockcroft不只熟諳雲端技術和軟體技術,他更是高效能電腦技術的專家,曾在昇陽電腦任職長達16年,最後成為昇陽高效能工業計算(HPTC)部門的首席架構師。2004年離開昇陽,轉而進入eBay,成為eBay Research Lab創始團隊一員。早在iPhone和Android手機問世之前,Adrian Cockcroft就開始研發自製手機和先進行動應用。

他在2007年進入Netflix,負責Netflix首頁和個人化選片服務,也參與了SOA架構的導入。2010年成為Netflix雲端架構長,率領12人團隊重新設計資訊架構,打造出Netflix雲端新架構,後來成為微服務架構的經典。

2014年,Adrian Cockcroft轉而進入Battery Ventures創投擔任技術院士,從更宏觀的角度,來觀察科技產業、網路新創、創新技術的發展。2年前進入AWS擔任雲端架構策略副總裁,不只帶領AWS的開源推動工作,也開始到各國分享自己一路參與雲端架構發展的經驗。趁Adrian Cockcroft近日來臺之際,iThome特別專訪他對雲端架構趨勢與企業數位轉型關鍵的觀察。

Q:為何當年Netflix敢決定把關鍵網站搬上雲端?

A:大膽是Netflix根本的文化。一部份來自公司領導高層,特別是創辦人Reed Hastings,他是很願意投入創新嘗試的人。Netflix喜歡做「不易複製」(Hard copy)的事,就是別人看到會想複製,但又很難複製的事,Netflix也很享受這樣的作風。

Q:當時你如何說服管理階層,接受全上雲端的策略呢?

A:不是我說服他們,反而是管理團隊來說服工程團隊,要採取「全上雲端」的策略。Netflix當時有兩項主要業務,一是DVD出租服務,其次是影片串流服務。串流服務的發展非常快速,對於運算有很大的需求。管理團隊當時最大的煩惱是,運算能力的擴充速度,能不能支持業務的成長需求。

從DVD租片到串流服務,是一種數位轉型帶來的需求改變。就好比,一家零售業者,過去透過零售店面來銷售產品,就算店面擴張到上百家,IT的運算力,只需要擴充到足以滿足這一百家店面就夠了。但是,經營型態數位化後,IT不只要支援生產或銷售所需的系統,還需要直接滿足第一線的終端顧客。

過去租片業務,IT只需考慮幾百家店的連線存取需求,但串流服務不一樣,得直接服務顧客,這是數百萬名顧客以及數百萬個播放裝置的挑戰規模。從支援數百個用戶端,到有能力支持百萬等級規模的連線需求,而且是隨時上線的需求。IT得面臨,不只是幾倍成長的挑戰,而是上千倍成長的衝擊。這是所有面臨數位轉型企業共通的挑戰。

Q:但為何是管理階層發動轉型,而不是IT?

A:Netflix管理階層也頗有技術能力,這是部分原因。但關鍵原因是,這是Netflix當時最大的風險,IT若無法支持擴充需求,公司就會失敗。

Q:臺灣不少企業也想擁抱數位轉型,管理階層要有技術能力,才能順利啟動嗎?

A:不一定必要。如何解決商業上的問題,是企業永遠的課題。不能只看到有新科技,就想用,雖然這可能很有趣,但企業不應該如此。企業要去解決商業的問題。企業可分成三種,多數企業儘管追求效率,但只是一種不想落後對手的態度,這是安全牌的企業。但有些企業則是有種什麼都要搶第一,這是領導型企業,Netflix就是這類企業,想要搶占市場大宗,各種類型的顧客都要滿足,雖然只是少數,但AWS會找出這群顧客,花時間了解他們的需求,因為安全牌顧客後來都會想要具備領導型企業的能力。

Netflix就是那種率先衝進叢林打頭陣開路的領導型企業,多數人則是想走在這條開拓出來的道路,安全地前進。第三種則是落後型企業,忽然才發現,大家都往前進了,自己才開始擔心如何跟上隊伍。

Q:除了業務面的轉型,IT架構如何改變,來滿足轉型所需?

A:Netflix在自家資料中心部署的內部系統(on-premise),都是大部頭式(monolithic)的大型系統,我們把它打破成一塊塊小型服務,再部署到雲端成為各種微服務。Netflix上雲端就是從大部頭系統到微服務的轉型之路。

Q:上雲端轉移,花了多久時間?

A:至少花了2年,光是前端系統上雲端,就花了1年,包括從學習如何拆解,後來腳步比較快,但也花了一年才將後端系統和資料庫搬上雲。前端系統和後端系統分成兩階段來進行。在資料中心的運作,其實很慢,資源調度和分配得花很長的時間,技術改變的腳步也很慢,打造各種內部流程,希望穩妥完成工作,但你就是在打造一套緩慢的大系統。大部頭系統就是這樣的系統,所有的改變都相互綁定在一起,因為你不得不如此。

當你希望緩慢穩定前進時,大部頭系統是對的架構。但是,在雲端,幾分鐘就可以增加一臺機器,你應該藉由做「小事」來提高效率,所以,要打破成微服務型態,因為每一小塊服務,都可以獨立且快速地改變。對速度的需求,系統自然發展成最理想的架構。(編按:Neflix仍有少數資料在本地端,直到2016年)

Q:你自己設計出整套新架構嗎?

A:不,我率領了一個12人團隊,我們一起打造出所有的新架構。

Q:第一步從哪裡開始?你當時幾乎沒有前例可參考?

A:改變要從最簡單的地方開始。因為你必須藉此學習新技術、新平臺和新模式,來了解如何上雲端部署任何事情。第一步要從最簡單的工作開始,然後才逐漸嘗試更複雜的工作,逐漸就會學會新技術,也會熟悉新平臺。Netflix服務是網站,我們從最簡單的那一個網頁開始,一次一頁。最後才是最複雜的那一頁。同時有兩套系統並行,一開始用戶瀏覽Netflix網站時,有些網頁在資料中心內執行,另一些則是在雲端。幾乎花了一年才全部搬上雲,但透過轉址切換,顧客其實不會發現。

Q:這個作法現在還適用嗎?如果臺灣企業想把自家系統搬上雲端?

A:是的,我認為還適用。就算你的網站再複雜,還是一次搬一頁最好。但現在可能比較容易,因為企業的行動應用,多半會不只用到資料中心提供的後端API,也會用到不少雲端服務的API,這會讓轉移工作變得更容易一些。但基本原則是要採取漸進式作法,一次轉移一個功能。

Q:你從Netflix學到什麼經驗?至今仍適用嗎?

A:我從Netflix上雲學到的第一個經驗就是,Netflix先為了追求速度而展開優化轉型,也因此而贏得市場,因為可以比市場上任何人都跑得更快。速度致勝,至今不論那個產業都還是如此,跑得快的人可以贏得市場。Uber、Lyft、Airbnb、Expedia都是因為雲而速度很快的公司。世界現在變得更快,技術也是,更要善用這些技術來加速自己。

很多公司是自己綁住自己,自己設置了很多內部門檻,其實可以簡單一點,不要花了6個月才做出決定,但只用1個禮拜就完成工作。利用科技只需1周時間的工作,卻耗上數個月,這就是問題。所以,第二項經驗是,產品開發過程要盡可能減少摩擦。快速決策是數位轉型的其中一項關鍵,要讓各種決策的發生,更加自主和自動化,

Amazon有個披薩團隊的比喻,團隊要小又獨立,10個人左右剛剛好,產品經理、維運、開發人員都組隊在一起,共同讓產品更好。保持獨立運作,但要和產品相關的團隊保持聯繫。這也是我在Netflix看到的工作模式,去除磨擦,就可以加速決策,這正是讓企業組織變快的方法。

第三項經驗是「最高信任,最少流程,避免工作在團隊間輪流接棒。」寫完一段程式碼,何時才能上線執行?傳統企業得花上好幾個月,但在現代化企業,可能只要幾分鐘,不用開會,只需一張工作單發動任務,透過持續整合、持續派送自動化完成。

要衡量一個組織的績效,要用創造價值的時間(Time to Value)來評估,對開發團隊而言,就是看一段程式碼從提交(Commit)到上線執行,花了多久時間。這是最好的績效指標,任何影響,最後都會反應到這個指標上。

例如越少開會,這個時間就能越短。有些企業得花上幾個月,甚至程式碼寫完永遠無法抵達顧客,因為專案最終還沒上線就取消了。今天寫完,明天上線,這是對開發者最好的獎勵,也能讓你的產品持續改善,每一天都變得更好,這是一個新世界。

Q:非科技公司,尤其是傳統企業也能適用這樣的快速開發模式嗎?

A:所有企業,現在都是科技公司。Netflix其實是內容產業,不只用前所未有的方式來拍攝電視劇,還用更有效率的方法來製作,也比任何人更能瞄準受眾。過去只能用猜測,但Netflix現在可以清楚知道每一部電影,有多少人看,誰在看,都能知道。Netflix再用這些資料來優化業務所打造的內容,科技只是負責派送和記錄,看電視才是Netflix真正的生意,科技只是工具。

任何非科技公司,都能複製這樣的模式。就算是食品業,儘管仍舊需要在實體世界生產、製作和運送食物,但你對顧客的了解越多,甚至透過直接銷售的方式,來掌握顧客的特性,你就越能優化你的生產過程,甚至改變商業模式。數位轉型就是回到基礎,思考企業商業模式的改變。

尤其現在許多產品連上網路,不只可以與顧客有更多聯繫,也可以讓產品來告訴你要如何改善,許多智慧家電就是如此。這是一個商業模式的大改變,也需要開發應用程式來輔助這件事。

Q:開發新應用最好直接採用微服務架構嗎?

A:不,現在開發新應用,最好優先採用Serverless架構。可以快速完成你的App,再持續根據顧客需求來優化。例如服務網路流量很大,可以改租用PaaS來分攤部分Serverless上的服務。或你需要快速回應的App,就專注於優化網路延遲。但使用Serverless服務,設計出你的應用系統的第一個版本,只需要幾天。Serverless架構就是要排除中間的障礙,讓你盡快嘗試技術。

Q:採用Serverless架構的代價是什麼?

A:應用程式的設計得有一定的妥協,來適應Serverless服務可以提供的功能。

就像要打造一款玩具太空梭,傳統作法是你得先設計太空梭玩具的原型,再用黏土來複製每一個零件模型,接著用黏土模型來鑄造出每個零件的模具,就可以大批鑄造生產零件,再來組出一臺臺太空梭玩具,這就是傳統的瀑布式開發流程,得花上幾個月才能開發一套系統,再部署到不同環境或各地據點中。

但新的快速開發模式(Rapid Development)截然不同,而是改用樂高積木來組合太空梭,幾個小時就能組裝出一個太空梭玩具。這臺樂高太空梭仍舊可以玩,顏色搭配也可以長得像是當初設計的原型,但精細程度比不上鑄造組裝的版本。你得和樂高積木提供的那幾種積木型態妥協。這就是用Serverless的代價,得適應Serverless提供的功能選擇,但帶來的好處是,可用(依舊可玩)、可靠(堅固)、容易局部調整,而且快速完成。這是我最喜歡的比喻。

你要了解各種功能型服務的能耐和限制,如AWS提供的SQS、Kinesis、S3、DynamoDB,以及AWS Lambda等,這些都是AWS上實現Serverless架構的積木,研究如何組合這些服務,來解決你的需求。

 相關報導  企業IT飆速關鍵大公開

AWS雲端架構策略副總裁:飆速開發又有新方向,Serverless是容器和微服務的下一步

$
0
0

早在2015年冬天AWS年度大會一場演講中,AWS雲端架構策略副總裁Adrian Cockcroft就預言,Serverless將是下一階段的雲端架構方向。當時,Docker崛起才2年,正是紅遍半邊天的IT明日技術。但Adrian Cockcroft從IT飆速的角度來看,他當時就指出,可以提供毫秒級部署能力,也只需存活數秒鐘的AWS Lambda(這是AWS率先推出的Serverless服務),將比容器化部署更有速度力。當時他還沒進入AWS,而是在技術創投擔任技術評估者和推廣者。

Serverless的發展也如Adrian Cockcroft所預言的,越來越興盛,甚至不只AWS,其他雲端巨頭也相繼推出Serverless服務,近年更結合了邊緣運算架構和AI認知服務,擴大了Serverless服務的運用型態。

Adrian Cockcroft後來更進一步從商業邏輯的發展變化,將近10年來企業IT架構演進分為三個階段,分別是Monolith分裂(大部頭架構分裂)、Microservice(微服務架構)和Functions(功能架構)。

Monolith架構是早期大型主機時代的架構,將所有功能和服務都集中到一個龐大、複雜的系統中,但在十年前,因為單一系統過於複雜、緩慢,這個主流架構開始分裂。不過,他解釋,當時CPU速度和網路效能還不夠快,只能仰賴XML和SOAP協定來傳輸訊息,因此只能將大部頭系統切割成規模較小的服務,一個服務仍舊包含了大量不同類型功能,依舊是大部頭式的複合式服務。

5年前,微服務架構開始崛起,開始分門別類地更進一步來切割服務的用途,而不同類型服務之間也更容易進行雙向溝通,也容易透過服務架構來存取各類儲存服務或快取機制,應用系統和儲存硬體間容易透過服務串接。

2014、2015年,企業開始擁抱雲端,願意把自家應用搬上雲端,這更促成微服務架構的普及,因為Restful API開始成為微服務架構的訊息傳遞方式後,不只可以串接內部各種微服務,也很容易串接到雲端上的專用型服務。而「容器技術的出現,讓微服務架構變得更容易也更快導入。」他解釋,因為容器技術帶來新的應用程式部署模式。

Adrian Cockcroft用筆電軟體升級過程來比喻。過去,得不斷更新筆電中的軟體,才能享受到新功能。但是,若筆電價格非常便宜時,甚至是只要幾百美元就可以擁有一部低價Chromebook,一旦發生問題,直接換一臺新的筆電更省事。容器技術降低了應用程式部署和封裝的時間成本,也帶來了新的部署作法,就是「直接換新免升級」,這就是Docker所能提供的Immutable打包更新作法。一旦將微服務容器化之後,一來更容易跨平臺、跨雲、跨不同環境來部署相同的微服務,要更新時,也不用關閉正在執行的微服務,修改完再重上線,而是直接部署新版微服務,再關閉舊版微服務,就像是直接換一臺新筆電,就可以獲得新功能,而舊筆電就直接作廢,不用來進行軟體更新。

不過,經過這幾年,許多常用服務都已經標準化,也成為雲端服務平臺提供的基礎服務元件,彼此再透過API來溝通,這也是許多企業開始用雲端平臺提供的服務來組合出自己的微服務架構,而不會全部自建。而實現應用程式商業邏輯的程式,其實會反映在串接這些常用服務之間的程式上,而且這些串接常用服務的機制,往往不用永久存在,只有需要的時候才執行,執行完成了,就可以下線。因此而出現了像AWS Lambda這類的Serverless服務。

而Serverless服務就是一種Functions架構的服務,是將微服務打破成更小的單位,也就是按照功能來打包成最基本的程式單位或程式積木。「Functions很簡單,一次只做一件事,但微服務還是要提供一個介面。Functions等於是更小型也更專注的微服務。」Adrian Cockcroft指出,你可以將一個Functions轉變成一項服務,這就是一個只提供單一功能的微服務,但有些微服務更加複雜。

AWS雲端架構策略副總裁Adrian Cockcroft喜歡用太空梭玩具生產方式來比喻新舊開發模式的差別。傳統(瀑布式)開發,從黏土模型、鑄模、大量生產零件到組裝完成一個精緻的玩具,需要好幾個月,但飆速開發(Rapid)則透過標準化、可組合的樂高積木(如自製容器化服務或Serverless服務),只需要幾個小時就可以先打造出一個可用又容易修改的太空梭玩具。

 

微服務和Serverless可組合運用

微服務和Serverless其實不衝突,而是可以組合運用的架構。舉例來說,容器化的微服務,可以負責那些低延遲而需長久存在的功能,例如即時控制、硬體驅動等,但透過API介面,不同應用程式的商業邏輯則可透過Serverless的功能來實現,再透過API串接兩者。「這正是打造現代應用程式該有的方式。」Adrian Cockcroft表示。

他建議,現在若要開發新應用,最好優先採用Serverless架構,快速完成需要的App,再持續根據顧客需求來優化。例如服務網路流量很大,可以改租用PaaS來分攤部分Serverless上的服務。或先需要有能快速回應的Ap,再來專注於優化網路延遲。「使用Serverless服務,設計出你的應用系統的第一個版本,只需要幾天。」

透過Serverless標準功能服務,更容易實現飆速開發

不過,想要利用標準化的微服務或功能性的Serverless來打造應用程式,「得先適應Serverless服務可提供的功能。」他說,但可以更容易實現新的飆速開發模式(Rapid Development)。

Adrian Cockcroft以打造玩具太空梭來比喻新舊開發模式的差異。傳統作法是,你得先設計太空梭玩具的原型,再用黏土來複製每一個零件模型,接著用黏土模型來鑄造出每個零件的模具,就可以大批鑄造生產零件,再來組出一個個太空梭玩具,這就是傳統的瀑布式開發流程,得花上幾個月才能開發一套系統,在部署到不同環境或各地據點中。

而新的飆速開發模式截然不同,是改用樂高積木來組合太空梭,幾個小時就能組裝出一個太空梭玩具。這臺樂高太空梭仍舊可以玩,顏色搭配也可以長得像是當初設計的原型,但精細程度比不上鑄造組裝的版本。這類積木可以自己開發,或用容器技術來打包出容易再利用的常用程式積木,也可以使用Serverless提供的功能。「使用Serverless好處是,最後組裝出來的太空梭玩具,可用(依舊可玩)、可靠(堅固)、容易局部調整,但最重要的是能夠快速完成。」他說。

不少企業擔心,系統架構改用微服務架構和容器技術後,長期維護工作將會越來越困難?不過,Adrian Cockcroft認為,服務種類和數量變多了,就像樂高積木越出越多款,組合工作不會變得太難,「只有一開始找對積木得費一番功夫」他更進一步指出,拆碎後的微服務,每一個都獨立運作,可以掌握且限制其權限和用途,因此「微服務架構反而Monolithic架構更簡單,因為微服務的複雜度可以被看見。」他說。

 相關報導 企業IT飆速關鍵大公開

未來IT應用場景

$
0
0

今年3月底在臺上檔的好萊塢電影《一級玩家(Ready Player One)》,上映至今已拿下5.8億美元的票房,7月陸續開始發行到各大影音通路,像是Apple iTunes,以至MOD、DVD、藍光光碟等,

之所以注意到這部作品,是因為當中的劇情、所設定的世界觀,可能揭露了當前IT應用潮流發展的前景,而且,它串連了幾個近期受到熱烈關注的幾項技術議題,像是人工智慧、虛擬實境、社群網路,而且主軸更偏重在虛擬實境願景的徹底呈現,而其他兩種技術更是不可或缺,是支撐這個理想環境得以順利運作,以及所有互動機制能夠流暢進行的重大關鍵。

這部電影的片長兩小時20分鐘,令人意猶未盡,於是,後續我也去找來中文版小說閱讀,期望能夠更了解當中的世界觀與科技設定。最近,我也開始讀英文版小說,想知道中英名詞之間的對照。

這些辭彙或許隱含了某些弦外之音,例如,創造虛擬實境的廠商,小說中文版譯為群聚擬仿公司,原文是Gregarious Simulation Systems(GSS) ;這個虛擬實境稱為「綠洲」,英文簡稱OASIS,全名是Ontologically Anthropocentric Sensory Immersive Simulation,中文譯為「以人類為宇宙中心之實體論的感官浸淫模擬體系」;至於企圖奪取OASIS經營權的網路服務業者,譯為創新線上企業(創線企),原稱為Innovative Online Industries(IOI)。

除了名詞的用法,小說裡面,還有更多關於虛擬實境環境與各種應用的介紹,在「第一關(Level One)」的章節,都有更為具體的描述。像是,這個超巨大虛擬實境的發展歷程、存取的介面設備與後臺系統軟體、服務平臺的收費與虛擬物品交易機制,使用者可以隨心所欲地為自己建立虛擬分身/角色。當然,在擬真的環境中,提供了數以千計的3D世界,供玩家們探索,同時,裡面也需要一些反應靈敏的非玩家角色、甚至是由人工智慧創造的人物,與玩家們互動,因此,強大的人工智慧,對於提升虛擬實境的體驗,不可或缺!而這些場景背後的自動化機制,若是基於容器應用、微服務、Serverless等創新技術,來實現變化萬千的場景與人物互動,其實,也相當合理。

而人們之所以熱中投入綠洲的虛擬實境,則是跟全球能源枯竭、生態浩劫、戰爭頻仍等危機有關。這讓我想到2017年上映的另一部電影《縮小人生(Downsizing)》,裡面提到,有人發明出縮小人體的技術,希望以此來減低能源消耗,雖然對於人類為何得以縮小的技術原理,似乎沒有著墨太多,然而,單是這樣,其實也和一級玩家相同,仍然憂慮未來環境趨於惡化的狀態。

人類希望文明可以持續發展,勢必是要耗費更多資源,然而,身處的生態環境卻危在旦夕,如何永續已成為全世界無可迴避的難題,或許積極發展虛擬世界的應用,真的是一種可考慮的選項吧!舉例來說,若能大量以虛擬商品來取代實體商品的需求,至少就可以省去許多塑膠與紙類包裝,或許就能挽救生態,避免動物因此誤食或嚴重受困,在數位世界裡面,許多虛擬資源的使用,大多已考量到回收、再利用的機制。

但是,如果許多事物都是基於電力而成,難道真的那麼理想、對於環境沒有實質耗損和破壞嗎?這讓人很困惑,因為有效率或許代表著不浪費,但並不一定會降低整體耗用,當所有業者都在盡可能發展最有效率的資源使用方式,對於許多事物的需求,可能也跟著水漲船高,因此,關鍵仍然在於可用的資源能否增加,否則,就算再有效率,若無法改變入不敷出的局面,我們終究還是難以卸除對於匱乏即將來臨的不安感。

群暉科技IT大量導入自家產品,使用經驗變身產品隱形推手

$
0
0

人生總會面臨不同的考驗,「沒有想到,擔任公司員工福利委員會主委的經驗,竟然會大幅度改變我在群暉科技的職涯發展。」該公司資訊管理部經理高志鵬回憶說道。

這個無給職的角色其實並沒有任何實權,但個性喜歡助人的高志鵬,想要讓更多同事了解福委會可以幫忙大家做些什麼,提供什麼福利措施等等,這也開啟他將人際網絡拓展出研發部門,延伸到公司其他各個部門的經歷,包括資訊、財會、品管、行銷、業務、產品和後勤支援等部門。

當年全公司總共一百多人還不到二百人,相較於現在全公司八百多人,算是人少的,但高志鵬坦言,如果不是這個福委會主委的經驗,他可能就只是一位認真堅守崗位、盡力把自己研發部門的分內工作做好的阿宅工程師而已;他就沒有機會知道,原來負責出貨部門的同仁,有時候為了配合歐洲時差,晚上11點還沒有下班是常態;也不會知道,原來行銷業務部門要參展時,清晨五、六點就要到公司載送貨品到展場,也是另外一種常態。

擔任群暉科技資訊管理部經理高志鵬剛開始,也是從應徵研發工程師才加入這個軟體開發團隊,但慢慢的,當觸角開始延伸到其他部門時,樂於助人的人格特質,加上看好資訊部門未來也將成為支撐公司營運發展的重要部門,決定接下資訊管理部首位專職主管一職。

高志鵬表示,過去幾年,資訊部門工作滿一年而離職的人數只有2人,低離職率的原因,是因為這是一個能力強、自主性高、具有戰鬥力的團隊,當涉獵服務的角色從內部客戶延伸到外部客戶時,開始接手研發部門以往最頭痛的程式更新的部署、排程與派送;而同樣具有開發與測試、應用能力的資訊部門,在大規模導入自家產品,成為第一線的使用者後,各種經驗分享與使用者建議,更讓資訊部門成為公司產品研發部門背後另類的隱形產品推手。

群暉科技的資訊部門為了協助公司營運,在2009年將資訊部門變成一個獨立運作的部門,但當時,仍然由後勤支援(Support)部門主管兼任資訊部主管。

高志鵬在2013年由研發部門轉任資訊部門,當時,因為有了先前的機遇,能多了解其他部門的工作內容與角色,有這種和其他部門同事打交道的「人和」基礎,讓他在資訊部門工作時,對於要協助公司打造跨部門的共用平臺,了解各部門作業流程上遇到的各種難題時,不僅可以更有「同理心」,因為過往有一些良好互動的經驗,彼此溝通的質量也更好。

看好資訊部門的重要性,擔任第一位專任主管

「萬事起頭難,」高志鵬剛開始任職資訊部門的時候,公司大約2百人,資訊部門只有6個人,所以當時主管指派的任務,就是建置公司所需要的服務系統,例如,早期的官方網站並沒有做RWD(響應式網頁設計),用手機瀏覽官網資訊相對不友善,調整官網可以在手機便利閱讀就很重要;其他的,就像是針對內部同仁需求,打造一個方便進行產品規格更新的後臺系統;或者是客戶如何根據自己需要選擇適合NAS設備的NAS Selector(NAS推薦系統);還有協助使用者熟悉操作的Online help(NAS操作說明系統);以及蒐集使用者資訊分析的UDC系統,和由資訊部門自行開發的資產管理系統等。

因應業務蓬勃發展,一年不到,群暉員工人數增加為3百人,其中資訊人員也提高到11人。一直到2014年,當時的執行長希望讓資訊部門發揮更大的功能,徵詢高志鵬擔任資訊部門主管的意願,他不加思索便一口答應,扛起這個重擔。

第一年剛到資訊部時,資訊部門全都忙著開發系統,希望儘快完善一些針對外部和內部客戶所需服務的配套系統,高志鵬指出,當開發完有當務之急的系統後,則開始看到資訊部門發展時的盲點,資訊部門必須重新打造一套基本的制度與架構,才能讓資訊部發展真正扎根。

他認為,這時候資訊部門最重要的任務就是「建立IT制度」,不論是系統開發制度等各種所需的各種硬體電腦標準、軟體授權記錄、伺服器分級分類並列清單、虛擬機器叢集甚至是把公司最基本的網路拓樸畫出來等等。

他也說,剛開始資訊部門還是會面對到,公司同事電腦壞了,不知道找誰維修;各個部門所需要的軟體授權是否足夠且合法;甚至是,公司網路的DMZ(非軍事區)都得要根據公司的網路政策架構和需求,重新設定才行。不過,高志鵬表示,資訊部門的人數雖然不多,但每一位都是可以獨立作業的

大規模導入自家產品,資訊部門化身產品隱形推手

對所有軟硬體製造商都一樣,「自家的產品自己用」是不變的鐵律,高志鵬在搞定第一波的制度流程後,接下來,就是導入所有自家的解決方案,包括用電子郵件產品MailPlus取代以前的FreeBSD,也導入相關的LDAP和SSO(單一登入)等等。他笑說:「這個經驗讓自己深刻體會到,系統轉移是極其痛苦的事,而做好系統轉移的事前評估和規畫,更是至關重要。」而這樣的經驗,也是高志鵬以前在研發部門不會體會到的感受。

當公司發展到5百人的規模時,資訊部門更要面對管理的挑戰,高志鵬認為,系統穩定和可用性已經成為最重要的議題,也必須做到落實「風險管理」,維持公司系統和營運穩定。

他進一步解釋,當公司導入自家產品和解決方案的過程,有些時候,必須達到一定的使用人數和應用規模後,才會發現某一些特殊的問題,例如,某樣產品就是必須使用人數超過5百人時,才會發生某一樣功能設定不彰的情況,這時,同樣具有程式開發與資訊應用能力的資訊部門,不僅是公司產品第一線最忠實的使用者,所提供的改善建議和使用經驗,就可以直接回饋給研發部門,作為未來產品改善調整的建議,也讓資訊部門成為另類公司產品的品質控管部門,甚至是背後隱形的產品推手。

此外,早期NAS產品要進行版本升級與程式更新時,都是由研發部門做完品質控管( QC)後,再到各國去布建更新程式的下載點。但高志鵬表示,資訊部門在2015年完成程式更新系統(Release System)平臺之後,資訊部門便陸續接手原先由研發部門負責的,各種產品系統更新的部署和排程。

也就是說,後來,研發部門就可以全心全意專注在產品的研發和功能新增,但若是牽涉到產品售後服務,包括各種版本升級與更新程式的下載,則改由資訊部門負責下載點的布建與更新。

因為公司人數和規模持續擴增,對於產品的各種可用性要求以及對於系統復原時間(RTO)也不一樣,資訊部門便會和研發部門以及其他使用者部門討論,包括郵件伺服器、官網、SAP ERP系統甚至是檔案伺服器等,哪些系統是最優先的系統,而這些系統一旦遭駭,又可以在多久的時間內,順利恢復原先的系統運作方式等;其他像是規畫系統的備援,找出單一故障點等。他也說,這個過程中,他們也用了很多亞馬遜EC2雲端服務,也從中學到很多系統穩定和落實相互備援的經驗。

另外,當公司決定導入自行開發的企業即時通訊軟體「Chat」(聊天)時,研發部門希望資訊部門把即時通訊軟體的功能和電子郵件系統整合在一起。但當時資訊部門考量後卻沒有這麼做,而是將它做為內部通訊服務故障時的另一個訊息接收傳遞的管道,他舉例,在2016年一場突發事故,導致公司電子郵件無法對外傳送時,當時,這個即時通訊軟體就幫了很大的忙。這也證明,當初資訊部門未雨稠繆的判斷,是正確的。

群暉科技資訊管理部經理高志鵬表示,資訊部門懂研發部門的語言,使用經驗和改善建議更可以切中核心,成另類產品隱形推手。 (攝影/洪政偉)

IT服務對象延伸外部客戶,和產品部門攜手因應GDPR

高志鵬指出,持續增進IT管理效率是資訊部門的責任,在2017年,資訊部門人數有大幅度的增加,要從公司的產品和各種資訊設備掌握什麼時候會有損壞的跡象,如何提前預警、做好準備,就必須要事先在設備裡面埋入代理程式,並和研發部門蒐集研究各種產品設備的使用效率瓶頸,持續落實各種資料監控的作為等等。

因為資訊部門人數大幅增加,高志鵬也正式依據需求進行功能拆分,區隔IT與開發團隊,除了原本負責伺服器和網路管理功能傳統IT部門功能外,開發團隊也針對服務對象的不同,再另外切割出針對內部客戶的請假系統、資產管理系統的IST(Internal Service Team)服務部門,以及面對外部客戶和產品的EST(External Service Team)服務部門。

「資訊部門2018年最重要的目標,就是做到以客戶為中心,從客戶的角度思考發現,最重要的是系統和服務的穩定而不是功能的新增。」他表示,例如,該公司DSM 6.2版,從去年10月開放測試以來,到後來推出正式版,不僅推出家用版和企業版,更打破該公司以往有大功能新增就會更版的習慣,「提供一個穩定安全好用的版本,比頻繁更新新版更重要。」他說。

高志鵬表示,資訊部門現在不再只是單純服務內部客戶的部門,也將服務觸角延伸到外部客戶後,因為要面對歐盟最嚴格個資法GDPR(歐盟通用資料保護規則)的法規遵循議題,也和產品部門一同攜手因應。

他也指出,未來希望可以強化更多系統自動化系統,讓資訊部門同仁更提升自我能力,成為更有價值的資料分析者,可以進一步針對各種使用者資訊,提供相關的資料分析,進而協助公司達到營運目標。

 

 CIO小檔案 

高志鵬

群暉科技資訊管理部經理

學經歷:臺灣科技大學資工所畢業,2010年畢業後第一份工作就是擔任研發工程師,2013年轉任資訊部門。資訊部門2009年成為獨立部門,過程中,由後勤支援(Support)部門兼任最高主管,後來在2014年才設立獨立的資訊部門主管,並由他擔任資訊管理部經理一職迄今

 

 公司檔案 

群暉科技

● 地址:臺北市長安西路106號3樓之3

● 成立時間:2000年

● 主要業務:提供網路儲存伺服器(NAS) 服務、影像監控方案及網通設備,並跨足混合雲服務

● 總部:臺灣

● 員工數:882人

● 資本額:2億元

● 年營收:近百億元

● 創辦人兼董事長:翁英暉

● 執行長:呂青鴻

 

 資訊部門檔案 

● 資訊部門主管職稱:資訊管理部經理

● 資訊部門主管姓名:高志鵬

● 直屬主管:執行長呂青鴻

● 資訊部門人數:24人

 

 IT大事記 

● 2009年:資訊部門成為獨立部門,並由後勤支援部門主管兼管

● 2013年:建置服務系統,重新打造RWD官網;打造產品規格更新後臺系統;NAS推薦系統;線上協助Online help系統;使用者資料蒐集UDC系統;資產盤點系統

● 2014年:正式派任專職資訊管理部經理;建立各種IT制度,包括各種電腦規格和軟體授權數量,完成網路拓樸,以及進行伺服器分級分類清單與虛擬機器叢集

● 2015年:導入自家解決方案,包括以MailPlus取代FreeBSD,並導入LDAP與SSO、完成產品程式更新的Release更版平臺

● 2016年:落實風險管理,並大量導入自家產品解決方案,包括:即時通訊軟體Chat、以及其他OA系統包含備份以及行事曆功能等

● 2017年:以增進IT管理效率為主,導入Log Center,並作更有效率的資料監控與分析

● 2018年:打造以客戶為中心的IT服務,強調服務品質與穩定性,更在意客戶隱私


【次世代防火牆:StormShield SN510】提供端點設備弱點管理功能,同時可呈現防護政策運作績效

$
0
0

雖然市面上的次世代防火牆品牌眾多,選擇性相當多元,但今年初,我們仍看到有新的品牌加入,像是來自法國的StormShield,他們的次世代防火牆產品,延伸提供了端點的弱點控管(Vulnerability Manager)、惡意網頁內容反制(Clean & Pass)等功能,能夠選擇的機種也相當豐富。

論及StormShield這間公司,它是由空中巴士(Airbus)在2013年成立,旗下的產品線跨足網路防護、端點防護,以及資料安全等領域。其中,網路防護的部分,主要產品便是次世代防火牆,從部署型式區分,包含實體設備SN系列、虛擬版V系列,及雲端服務VS系列。

在實體次世代防火牆設備的產品線中,StormShield總共推出了12款機種之多,從擁有1Gbps吞吐量、適用於小型辦公室環境的SN160,到具備130Gbps吞吐量、可建置在資料中心的旗艦機種SN6000,幾乎可說是涵蓋了大多數的應用範圍。

我們這次測試的機種,是中階定位的SN510。在效能的部分,它擁有5Gbps防火牆吞吐量,對於防毒和IPS的承載能力,分別是850Mbps與3Gbps,這樣的流量處理能力,與我們之前介紹過的眾至NU-850C相近,算是符合一般水準。

在網路介面的部分而言,SN510也與所有的SN系列相同,內建12個RJ-45介面的GbE埠。不過,這款設備沒有提供額外的擴充插槽,若想要採用光纖介面,企業就要選購較高階的SN710,才能加裝SFP或是SFP+埠介面擴充卡。

此外,這個系列的中高階機種,也主打支援高可用性(HA)架構,設定的流程算是相當容易,只要依照精靈引導,輸入主備援線路的IP位址,就能完成。

對於惡意軟體的檢測上,SN系列設備搭配了防毒引擎,算是次世代防火牆產品常見的做法。而針對進階威脅的防禦,這系列次世代防火牆則是結合了雲端沙箱服務,藉此提供進一步的檔案分析能力。

同時提供設備運作情形與警示事件的儀表板

在StormShield SN510的儀表板上,大部分的圖表與清單內容,與這臺設備的維護有關,包含了網路介面使用情形、各模組軟體更新狀態等資訊,不過,這裡也提供了警示事件清單,因此管理者可藉此著手調查攻擊事件。

 

延伸流量過濾,納入端點弱點管理

從這款設備的防護能力來看,大致上可區分為2種面向,包含了偏重流量過濾的安全性政策,以及應用程式保護措施等。其中,對於應用程式的防護機制上,SN系列次世代防火牆設備特別提供了弱點管理的功能,在同類型產品裡算是相當少見。

這裡的弱點控管機制,主要針對的範圍,包含了工作站與伺服器電腦,可偵測它們本身執行的作業系統,以及需要連上網路的應用程式,在流量通過SN510時,檢查進行連線的軟體中,是否含有已知的弱點,並非所有安裝的應用程式都會納入檢查範圍。

具體而言,對於個人電腦,SN510能針對網頁瀏覽器、電子郵件軟體、防毒軟體,加以偵測。

而在伺服器的偵測範圍,則是包含連網服務應用,可對於網頁伺服器、FTP檔案伺服器、郵件伺服器、資料庫,以及管理工具等,檢查其中所包含的弱點。不過,在主控臺上,管理者只能針對某些型態的應用程式,設定從指定的流量來源中執行檢查,而無法針對個別的應用程式或是軟體,啟用這種弱點檢查的機制。

從我們測試環境裡,SN510便檢測到內部網路中,執行Windows 7的VM上,尚有SMB v1等多個漏洞尚待修補,並列出了CVE編號,以及修正檔、危險程度等資訊,管理者也可檢視線上說明,進一步了解漏洞的詳細資料。

而在SN510的報表裡,也提供了有關漏洞發現數量的排行圖表,管理者也能藉此得知需要優先處理的端點電腦。

除了弱點的控管,SN510也採用了信譽評等的概念,藉此歸納出高風險的端點電腦,讓管理者能優先掌握。這款設備中,同時納入防毒引擎與沙箱偵測的結果,加以統計端點電腦的風險分數。

能從流量中管理端點設備作業系統與應用程式弱點

在防護的範圍上,SN510也將流量的內容過濾,加以延伸應用。透過針對指定網路流量的檢測,分析連線的端點工作站與伺服器,檢查其作業系統、瀏覽器,以及各種連網的應用程式之中,是否存在需要修補之處,並能設定定期寄送完整分析報告或是摘要,通知管理者進一步追蹤、處理。

 

強化上網安全的網頁元件封鎖機制

在SN510的功能中,不只包含了網頁伺服器的防護能力,對於使用者上網,也加入前述Clean & Pass的功能,可移除頁面上遭到感染元件。在正常網站受到入侵時,SN510能只針對網頁有害的部分攔截,使用者還是可以正常瀏覽。

不過,這項功能預設沒有啟用。想要開啟這種偵測機制,管理者要在HTTP連接埠的設定頁面中,勾選執行HTML與JavaScript指令檢測項目,這裡也提供了自動刪除頁面中有害內容的功能,若是開啟之後,一旦偵測到網頁上惡意指令時,便能直接進行封鎖。

透過帶有惡意內容的測試網頁,我們先後在關閉及啟用SN510網頁檢查功能的情況下,從內部網路的VM,執行瀏覽器載入這個測試網站。在開啟這項檢測功能後,使用者瀏覽這個網頁時,其中惡意的指令內容,確實沒有載入,而我們也可以在主控臺的警示通知中,看到攔截的記錄。

可彙整端點電腦即時連線狀態

針對透過SN510上網的設備,主控臺也提供了即時監控的功能,並且在連線內容之外,統合了在裝置中執行的應用程式、服務,以及其中所發現的弱點等,再搭配信譽記錄的方式,讓管理者能快速了解端點的運作情形。

 

能檢視政策執行的成效

論及這款防火牆的政策規畫,管理者還是要從SN510的功能選單裡,前述的安全性政策,與應用程式防護等2個類別,著手進行設定。

在安全性政策的子選項中,最重要的便是網路設定項目(Filter - NAT),管理者可針對指定流量的來源、目的地,以及連接埠等,並且開啟SN510的各種防護模組──防毒引擎、防垃圾信、入侵防禦偵測(IPS),以及沙箱檢查機制等。而對於流量的控管,這裡也可以一併指定想要套用的網址、電子郵件,以及SSL加密流量的設定檔,因此,最主要的政策規畫和檢查,管理者都要透過這個網路設定頁面來操作。

對於已經制訂並實施的政策,這裡也對於其中包含的規則,顯示執行的頻繁程度,並且提醒管理者是否出現可能與其他項目衝突的情況。

再者,管理者若是將滑鼠游標移到規則所屬的溫度計項目,主控臺便會以彈出對話框顯示已經執行的總次數,有了這樣的輔助功能,防火牆政策執行的情況是否符合預期,管理者便更能加以判斷,進而調整規則的內容。

值得一提的是,SN510儀表板裡的圖表,提供了向下探索機制,因此管理者能藉此修改政策的設定。但有別於其他防火牆設備,這裡仍以政策的規則調整為主,相較之下,一般同類型設備中,大多提供事件向下調查的能力,因此,SN510的用戶若想從儀表板找尋特定事件,這裡的資訊相當有限。

 產品資訊 

StormShield SN510

●建議售價:含1年軟體授權與硬體保固為42萬元(未稅)

●代理商:柏策科技(02)2557-5687

●防火牆吞吐量:5Gps

●IPS吞吐量:3Gbps

●防毒吞吐量:850Mbps

●IPsec VPN吞吐量:1Gbps

●防毒引擎:Kaspersky

●最大同時連線數:50萬個

●網路介面:12個GbE埠

●儲存空間:320GB

【註:規格與價格由廠商提供,因時有異動,正確資訊請洽廠商】

一周大事

$
0
0

功能再升級,Teams整合Visio和更多第三方應用

圖片來源_ Microsoft

在2017年微軟正式推出企業協作平臺Microsoft Teams後,也給其他競爭平臺帶來許多壓力,挾自家豐富產品、夥伴生態系的優勢,微軟也陸續整合Microsoft Teams與其他企業服務。像是在今年3月時,Microsoft Teams就開始支援訪客存取,不管對方所使用的是企業郵件帳號或是Outlook.com與Gmail.com等消費者郵件帳號,都可加入線上工作團隊。此外,Microsoft Teams的雲端會議紀錄功能,更可支援逐字會議紀錄,使用者可搜尋或播放會議內容。(詳全文)

 

科技產業取得初步勝利,歐洲議會否決《著作權指令》

也許是科技產業的抗議收到了成效,歐洲議會在7月5日投票表決新版的《著作權指令》(Copyright Directive),以318張反對票凌駕了278張的贊成票,讓該法令重新回到修訂與討論的狀態。(詳全文)

 

谷歌重申不會讀取Gmail用戶信件,也嚴格控制外部存取行為

近期媒體報導Google讓上百家App開發商存取用戶Gmail郵件內容,引起軒然大波。雖然Google第一時間已經澄清,不過7月4日Google還是重申,並不會隨便讓App業者這麼做,而Google自己也沒有偷看用戶信件。

Google在官方部落格說明,之所以讓外部App,如郵件用戶端軟體、客戶關係管理(CRM)及行程安排軟體整合Gmail,是為了讓用戶更方便收發郵件。但是有一套嚴格、多階段的審查流程來確保企業及消費者隱私。(詳全文)

 

紅帽OpenStack邁入第13版,大力擁抱容器化,強化與OpenShift整合

從2010年開源釋出後,OpenStack這款開源IaaS,一度是各大IT廠商的新寵兒,但隨著Kubernetes掀起的熱潮,現在此專案的注目程度較不如以往。而從2013年開始推出自家版本OpenStack的紅帽,也正式邁入第13版了。這次釋出的新版OpenStack,紅帽提供了標準3年支援,企業可以選購延長2年支援。(詳全文)

 

Linux基金會釋出免費區塊鏈線上課程

圖片來源_edx

在開放課程平臺edX上,Linux基金會推出了免費的區塊鏈線上課程,想要進一步了解新興技術區塊鏈的人,可要趕緊搭上車,8月1日準時開課。這套為期5星期的課程,會從基礎教導學習者什麼是區塊鏈,區塊鏈對於全球變化的影響力以及其發展潛力,並進一步分析技術、商業、企業產品和組織的使用案例。課程免費提供給大眾,但也可以選擇付費取得證書。(詳全文)

 

ASP.NET Core 2.0版正式支援開放式資料通訊協定OData

近日微軟宣布,現在ASP.NET Core 2.0版正式支援開放式資料通訊協定OData(Open Data Protocol),開發者可以透過打包管理工具NuGet,取得該應用的打包檔。微軟表示,這一次新發布後,現在開發者可以透過OData query syntax,布建更多OData端點,除了Windows平臺,它也支援在各種平臺上執行。OData是由微軟在2007年發起的開放式資料通訊協定,而IBM、SAP以及CA等公司也都支援該開放標準。目前OData 4.0版本已通過OASIS認證,可支援JSON,及以XML為基礎的CSDL等。(詳全文)

 

無預警關閉用戶服務引發嘩然,GCP公開道歉承諾改善

近日有GCP用戶抱怨建構在Google雲端平臺的服務被無預警中止,即便經過搶救,仍然有約一個小時的資料無法救回。這個事件引起GCP用戶一陣譁然。而Google團隊在獲知消息後,便主動聯絡事主止血,並公開承諾會改善審查機制,防止同樣事件再度發生。(詳全文)

 

Google推出端點裝置驗證服務,加強企業內部裝置管理

近日,Google推出了端點裝置驗證(Endpoint Verification)服務,讓系統管理員可以統一管理公司內部辦公用的筆電、桌電。目前該解決方案,已經可以登上了自家公有雲GCP、Cloud Identity,還有G Suite Business、G Suite Enterprise等平臺。而此服務除了在Chorme瀏覽器中推出延伸套件外,其他作業系統平臺如Windows、macOS、ChromeOS也都有釋出原生應用程式。(詳全文)

 

百度發布AI晶片,通吃雲端及邊緣運算

圖片來源_globenewswire

近期百度於2018百度AI開發者大會上發布AI晶片「昆侖」(Kunlun),包含了訓練晶片(Training Chip)「818-300」和推論晶片(Inference Chip)「818-100」。百度宣稱,昆侖晶片是首款支援雲端運算和邊緣運算(Edge)的晶片,可用在資料中心、公共雲和自動車輛上。(詳全文)

 

瑞士SIX證券交易所2019年將提供數位資產交易服務

日前瑞士證交所SIX Swiss Exchange宣布,正在打造一個針對數位資產的完整交易、結算與託管架構,可望帶來一個供數位資產發行與交易的安全環境,預計於2019年中上線。(詳全文)

 

Canalys:今年全球智慧喇叭出貨估將破億

圖片來源_ Amazon

在Amazon、Google、阿里巴巴等大廠的衝刺下,研究機構 Canalys公布的市場研究顯示,智慧喇叭市場從2018到2022年成長態勢大好,今年將突破1億臺大關,到2020年可能超過2.25億臺。智慧喇叭市場仍然是Amazon、Google爭霸局面,蘋果則被甩在後方。(詳全文)

 

英特爾聯手百度,利用視覺處理器Myriad 2 VPU強化AI零售攝影機

英特爾在2018年百度AI開發者大會上宣布,百度人工智慧(AI)零售攝影機Xeye採用英特爾旗下Movidius的視覺處理器Myriad 2 VPU,來加強消費者在零售賣場的購物體驗。(詳全文)

 

民進黨中央官網遭駭,網站內容遭置換

7月3日上午,民進黨中央黨部的網站疑遭駭客攻擊,網頁上出現簡體中文的嘲諷語句。據瞭解,民進黨是在3日早上9點發現網站被置換的問題後,當時已經緊急關閉官網,並請資安廠商協助調查。後續,我們也聯繫到民進黨中央黨部媒體創意中心主任楊緬因,他表示,網站已在7月4日晚間10點恢復正常運作,但遭侵入後臺的詳細調查資訊,尚未對外公布。(詳全文)

 

Klook旅遊訂票平臺洩用戶個資

從香港發跡的旅遊科技新創公司Klook客路,是臺灣民眾規畫國際旅遊行程時,也可能會使用的的訂票服務網站之一,不過,近期傳出個資外流事件。Klook是在事發約兩周時間後,正式對外公告。Klook官方聲明表示,部分用戶資料可能在未經授權的情況下被讀取,有個資外洩疑慮,估計有8%使用者將受影響。Klook也列出常見問答事項,方便用戶能夠了解此事件的影響範圍、被洩漏的資訊,以及用戶可採取的行動等,並強烈建議受影響的用戶應立即更換密碼。(詳全文)

 

社交網站時光機App Timehop驚爆遭駭,2,100萬用戶個資外洩

小心!社交網站風險高!提供臉書及推特過去貼文回顧的App Timehop7月8日公告4日遭駭傳出重大資安事件,2,100萬名用戶個資外洩,而且駭客也曾取得用戶存取臉書、推特、IG等社交網站內容的憑證。(詳全文)

 

瀏覽器擴充程式Stylish化身間諜程式遭下架

一名軟體工程師Robert Heaton在近日警告,知名的瀏覽器擴充程式Stylish擅自紀錄使用者的網頁瀏覽歷史紀錄,並將它們傳送至遠端伺服器,而Google與Mozilla也在最近相繼於Chrome Web Store與Firefox外掛程式頁面上將Stylish下架。(詳全文)

 

睽違5年,美國重返全球超級電腦龍頭寶座

每半年一次的全球五百大(TOP500)超級電腦排行榜近日出爐了,美國能源部的橡樹嶺國家實驗室與IBM聯手打造的超級電腦Summit以122.3 petaflops的運算效能擠下了原本排名第一、來自中國的神威・太湖之光(93 petaflops),這是美國自2012年11月之後,睽違5年再度奪回全球超級電腦的龍頭寶座。(詳全文)

 

烏干達正式對社交媒體課稅,禍延VPN業者

在今年7月1日烏干達正式實施新版消費稅,針對造訪OTT服務的民眾每日徵收200先令(約0.01美元)的稅金,許多民眾為了避開此一「社交媒體稅」,改用VPN(虛擬私人網路)連網,不過,烏干達政府很快就宣布,該政府具備了封鎖VPN服務的技術,沒人能夠安然逃稅。(詳全文)

無拘的物件導向

$
0
0

儘管時有非議,物件導向進入主流程式語言是既定的事實。就本質而言,物件導向是種典範,然而許多開發者,都是從支援物件導向的程式語言認識這個典範,也就不自覺地被特定語法給限制。

然而,沒有語法支援,就不能物件導向嗎?語言的實作層面上,又是如何實現物件導向的呢?

資料複合體

如果要談論物件導向,那麼,我們就必須先談論「物件(Object)」!

多數的文件都會提到,物件是物件導向程式中的基本單元,封裝了程式與資料,然而,就實作層面來看,並不是這樣的。

就如同數學上的複數,是由實數與虛數組合而成,而就物件而言,單純就是整體地看待一組資料,也就是個資料複合體。

因此,像[5, 10]就算是個物件了,也許這代表了一個複數,或者是一個平面直角座標,端看開發者怎麼去接受、運算這類資料。當然,使用可以令這個物件的意圖更明確,或者進一步地,使用個鍵值結構來儲存,例如{'x' : 5, 'y' : 10}會更加方便。這也是許多語言會用來呈現物件的基本語法形式,然而,不代表一定必須是這種形式,才是物件。

像[5, 10]、或{'x' : 5, 'y' : 10},就是所謂被封裝的資料。基本上,資料的封裝並非不可見,而是整體地看待這組資料,私有性(private)這類強封裝則是為了工程、團隊合作才出現的要求,一些比較彈性的語言,如Python,就不強調私有性。那麼,程式上的封裝呢?只要能夠處理這組資料的任何函式(Function)都可以!

真正封裝程式的是函式,如果有一組函式,可以接受物件(資料複合體)進行運算,就可以說這組函式是物件的方法(Method),也就是說,函式與物件是可以分別看待的,只不過概念上會稱這類函式為「物件可用的方法」。例如,有個獨立的函式add(v1, v2),若v1為,要將add視為v1的方法,可以接受v2為,這種方式並非不行。

也就是說,就實作面上來看,物件可以與方法分離,那麼,許多語言在語法層面上,會有obj.someMethod()的寫法,又是怎麼回事?

其中的「.」可以看成是運算子,像1 + obj.someMethod(),底層實作上可視為 (1 + (obj . someMethod())),也就是,obj與someMethod()被視為兩個運算元進行運算,而且,「.」運算子具有最高優先權,沒有交換律,obj會是函式中運算時this、self之類變數參考的對象。

查找方法的依據與約束

物件導向上,會有類別(Class),然而,物件與類別間的對應,也不是絕對必要——在還沒有類別之前,物件也可以獨自擁有方法,例如,add(v1, v2)時,add在概念上可視為v1的方法,這時並沒有類別的存在。

只不過,若有一組物件,經常地會使用某組函式,在程式碼中個別查看哪些函式時,雖然可以被這組物件使用,但這種方式並不方便,於是,希望有個查找函式的專區,願意的話,使用個鍵值結構也就足夠了,例如,CoodClz = {'add' : add, 'minus' : minus},接著,每個物件可以賦予class查找對象,例如[['x', 5], ['y', 10], 'class' : CoodClz],在需要操作add或minus時,就會到CoodClz上查找。

而本質上是資料複合體的物件,一旦擁有了類似的資料結構,也就有了一組函式位於專門供查找的位置。

為了便於表示物件擁有的結構與行為(函式),我們可以稱該物件為CoodClz的實例,而這麼一來,在管理物件上,就方便許多了,因為只要定義、查看CoordClz,就可以得知或規範物件的結構與行為。

類別的本質就是便於管理與約束物件,然而,管理的另一面,就是失去某種程度的彈性,類別約束性越強(例如Java),語言就越不靈活。

有些語言在語法上,允許定義類別之後,繼續增、刪類別上的方法,就工程而言,不應該這麼做。但問題在於,語言不會是完美的,也應該是能演化的,就修補語言而言,這又很重要,所以,任何語言勢必都要權衡類別的約束與彈性。

例如,JavaScript某些程度上,在語言半成品時就推出了,因此可以觸及許多底層實作細節,原型(prototype)是查找方法的依據。然而,又如同一般物件,如果可以隨意調整,既得其利的同時,也蕙深受其害,無怪乎許多程式庫拼了命模擬出各種風格的類別,希望增加約束性,而在ES6,也有了標準的類別定義方式。

重用其他類別方法

既然現在已經定義了類別,作為方法查找的依據與約束,緊接著會面臨的是另一個問題:在不同類別上,我們會發現有些方法在實作上,出現了相同的交集,當重複流程就出現在不同的類別中,就維護的角度而言,並非好事。

熟悉某個物件導向語言的開發者,第一個想到的是「繼承」,然而一如軟體界中許多名詞,通常沒有嚴謹的定義,繼承也是!

而許多開發者談到繼承,直覺的想法是有個父類別,不過,這只是其中一種方式,也就是目前類別查找不到方法時,繼續往父類別尋找,尋找的方式不一而足——也許是基於類別的,也許是基於原型的,或者像Python是基於MRO(Method Resolution Order)等。

繼承的本質是重用其他類別的方法,因此,如果從這方面出發,「組合模式」也算是繼承的實現之一(而不只是模擬繼承),當被組合的物件執行方法時,查找本身所屬類別有無該方法,實質上,也是在重用類別上定義的方法。

只要能重用類別上定義的方法,都可以算是繼承,Go語言就大膽捨棄了類別、繼承等語法,然而如果想要,還是有各種方式可以實現類別的概念,也能實現出共用結構方法,就算語法沒有直接支援物件導向,實際上,只要有心,實現起來也可以是物件導向。

語言的物件本身若支援個體化,直接將某個(類別上的)函式指定為物件之特性,也是重用其他類別方法的方式之一,或者是在類別上開放增、刪方法,甚至是可透過單一的方法,像是Circle.mixin(Ordered)等,將其他類別上的方法,一次性地指定給另一個方法。這些都可說是實現繼承,重用其他類別方法的可行方式。

設計演化的方向

如果語言在語法上直接支援物件導向,那當然是很方便。然而,就算不支援物件導向語法,在必要時,並非無法實現物件導向。

就像〈你所不知道的 C 語言:物件導向程式設計篇〉(https://goo.gl/ELsTRC)中所提到的,「物件導向是一種態度」、「只要有心,Brainf*ck語言也能作OOP」。

更確切地說,物件導向是設計上一種演化的方向,有心或沒有心,指的是開發者有沒有持續地檢討設計,以及當時的需求下是否適合朝該方向演化,而不是一味地套用封裝、繼承的語法或術語。有心的話,就算不想著物件導向,演化的方向後來自然地朝向物件導向,也只是剛好而已!

敏捷開發如何應用在企業轉型

$
0
0
博碩文化

企業生存於一個「霧卡」的世界中。「霧卡」(VUCA)的含義是:不穩定(Volatility),不確定(Uncertain),複雜(Complex)和模糊(Ambiguous)。霧卡是由種種不同因素所造成的,比如人才爭奪戰、千禧世代(與之後的世代)的需求轉移、數位化、快速進入市場的需要、全球化、在混亂中生存或發展等等。霧卡迫使企業以更敏捷(agile)的方式運行(小寫的「a」意味著有彈性、快速和高適應性),並使企業考慮是否能應用敏捷宣言中的敏捷(Agile),或者特定的敏捷方法來面對這些挑戰,比如Scrum。

複雜性意味著,雖然我們傾向於在事後用故事來解釋事件中的因果關係。但如果是複雜的情況,我們其實完全無法真正瞭解哪些因素起到了哪些作用。現實是模糊的,並且非常可能導致各種誤判,非常難加以預測。雖然並非所有不確定或模糊的情況都可被歸類為複雜,但複雜的情況總是不確定且模糊的,這就是為什麼我們不特地區分這三者的原因。在過去,公司會制定長期計畫,並通過里程碑(Milestone)監控一切是否如期進行。

而在當今企業中,由於市場、競爭對手和其他影響因素快速地變化,長期計畫往往在計畫完成時(甚至尚未完成時)就過時了。計畫中的假設也很少會預測到技術的躍進,比如競爭對手的突破、經濟變化(如最近出現的經濟大衰退),以及社會價值觀的改變。因此企業無法像過去一般預測和計畫未來,至少長期計畫是無效的,這驅使企業以更敏捷的方式來計畫。

而產品解決方案也變得比以前複雜得多。許多企業需要與其他企業、顧客、或社群協同合作,因為再也沒有一家企業能夠自行解決這些複雜的問題。在接下來的內容中,我們將針對構成霧卡挑戰的幾個因素進行更深入的探討。到目前為止,如何解決這些問題並沒有一個明確的答案。

規模

大的團體似乎通常比小的團體更難敏捷。大象能夠敏捷地跳舞嗎?大型企業通常被迫購買比他們創新速度更快的小公司,但這種策略也仍無法解決問題。

在精實創業(Lean Startup)中提到,每個公司無論大小都應該像一家新創公司一樣講求速度。一些大型企業通過在公司內為外部的新創公司提供空間,從而解決這一訴求。他們也可能建立內部智庫(相當於公司內部的新創公司),或試圖購買與併入新創公司而不改變其新創組織的「DNA」。透過這些策略,如大象般的企業可讓某部分變得更敏捷,但這不是將企業整體敏捷化,因此挑戰依然存在。

人才

隨著世代的變化,企業需要克服新的挑戰。一方面,企業越來越難找到有能力應變數位革命的人才,這表示公司需要在世界各地招募人才,不能侷限於當地的就業市場。

另一方面,從千禧世代開始的新世代都是在「網路」的環境中長大,而不是在階層的環境中。在千禧世代之前,大部分的人在童軍或教會團體中長大。而千禧時代後,年輕的工作者則在較非結構化的組織中成長,因此對他們來說,平等的話語權與追隨自己的熱情更為重要。由於社交媒體的廣泛使用,開放的交流和發言也越來越普遍,人們也把這些習慣帶到工作中,而這些並不是傳統企業常見的行為模式。

這些因素導致當今人們對工作有不同的期待,企業必須進行調整以適應這些新的期待。比如邀請人們追尋他們的熱情、提供平等的管道來取得所需的資訊、尊重每個人的發言、讓階層制度變成濫權專制等等。如果企業沒有做好這些準備,他們不僅無法招募到優質人才、也無法留住人才,進而陷在缺乏人才的困境中。

企業文化對創新有深遠的影響,也會影響到企業支持改變還是抗拒改變。如人類學家Karen Stephenson指出:「所有的文化,不論是公司企業還是社群,都是建築在信任的人際網絡上,階層組織只是勉強靠在其上的鷹架。這個信任網絡是改變最大的阻力,但如果能讓信任網絡活躍起來,這些阻力將成為持續改變的動力。」

通常人力資源部門已有了完整的流程來分類工作、創建工作說明書、和招募人員填補這些職務。工作說明書列出了人員所需扮演的角色和相應的責任,而當今的企業是應該先確定職務再尋找人才?還是應該先找人才,然後看看他們能做些什麼?後者可能會激發更多的創新。當一個人的生活是有意義的、有平等的話語權、與良好的社交能力,創新的想法更有可能發生,創新不太可能來自一個蘿蔔一個坑的螺絲釘。

數位革命

正如創業家、投資人兼軟體工程師馬克‧安德森(Marc Andreessen)提到的那樣:「軟體正在吃掉世界。」。

● 換句話說,越來越少產業跟軟體無關。舉一個簡單的例子,許多汽車製造商不再將自己視為汽車製造商,而是把自己視為軟體公司,因為當今一輛汽車與另一輛的關鍵區別在於軟體的不同。銀行和保險公司也是如此。這導致越來越多的企業需要適應認知上的差異,找出自己的核心產品或服務到底為何。

● 人工智慧已經佔領了過去被認為機器無法勝出的領域,如圍棋和撲克牌。未來掌控汽車方向盤的也許將不是人類而是自動化駕駛。將企業中的大部分功能自動化會導致以下情況的發生:

◆ 工作所需要的技能改變,員工需要不同的技能(如寫程式)來控制自動化的流程。

◆ 機器將會取代大部分的工作,留給人類的只剩與創新有關的工作。

● 企業無法像過去一樣控制外界對它們的看法。各類社交媒體有能力塑造企業形象,而企業很難施加影響。因此必須和員工、客戶、與潛在市場建立不同的關係。

價值觀的衝突

傳統上企業的責任是把股東的價值最大化,衡量高階管理層的終極標準是當前的股價,這種測量標準也制約了管理層的行為。而這一衡量標準的潛在理念是,企業最終的控制權來自所有權,投資者、顧客和其他利害相關者對企業沒有控制權。在這種傳統觀點中,企業必須由某人擁有,企業不能擁有它自己。

為了使企業蓬勃發展,企業需要能夠快速反應市場需求,並且滿足每一位顧客的需要。然而正如Steven Denning在2016年敏捷年會上所指出的那樣,專注于股東價值最大化,往往與關注顧客需求,兩者互相矛盾:

「如果你在團隊的層級中工作,你就很難理解公司的目標是股東價值最大化,績效並反映在當前股價中,當然你也無法理解高層的獎金與其是息息相關的。這導致要為股東盡可能榨取利潤,而這與為客戶創造價值(以產品或服務的形式)的敏捷概念恰恰相反。所以當你的組織裡,高層正努力榨取利潤,而基層的團隊卻往相反的方向行進,你將會陷在無止境的黑洞中。股東價值最大化和股票價格的重要性,其實是非常新的想法,它在20世紀80年代中期才開始風行。傑克‧威爾許(Jack Welch)都稱其為最愚蠢的想法,即便他是這個想法的實踐者之一。」

——Steven Denning

史蒂夫向我們描述了價值和架構的衝突,現在的挑戰在於如何將「無止境的黑洞」變成雙贏。一位執行長或許會公開表示「我們的目標是服務客戶」。但實際上董事會真正關注的只有股東的短期價值。因此,黑洞還是黑洞,這也意味著難以解決這個問題。艾德里安‧卡百利爵士(Sir Adrian Cadbury)最近引用前通用電氣公司執行長傑克‧威爾許的話,對這種黑洞進行評論:

「(略)你的主要支持者是你的員工、你的客戶和你的產品。很多批評最大化股東價值的人士指出,管理層需把股東價值最大化是基於兩個錯誤的前提假設上:第一,董事有法定義務要把股東價值最大化。第二,『公司』和『股東』兩者是一樣的。現實中並不缺少潛在的替代方案可解決這個衝突,但這兩個錯誤的前提,仍然有許多堅定的擁護者,特別是在財務和會計領域。」

這種價值觀的衝突導致企業內耗,傷害了企業應對快速變化世界的能力。

總結企業所面臨的挑戰

霧卡給公司帶來了很多挑戰。這些挑戰迫使公司變得更敏捷、更靈活和更具適應性。這迫使許多公司應用敏捷方法,來提高其靈活性和適應性。正如我們將在接下來所看到的敏捷只是第一步,但當它要跨越到企業其他範圍實施時卻遇到了重重阻礙。

四大流派名單揭曉

深入研究後,我們決定使用敏捷來作為解決挑戰的基礎流派,因為敏捷在短短十多年內已經取得了驚人的企業接受度。此外敏捷宣言所定義的價值,似乎也可以對應前面提到的企業目前面臨的挑戰。

然而因敏捷宣言是針對軟體開發而生的,我們知道需要重新闡述價值,讓這些價值可以對應到企業的整體挑戰。為幫助新的價值更明確,我們決定結合其他三種流派來改善組織的設計,這三種流派分別是:

● 超越預算模型(Beyond Budgeting)

● 開放空間技術(Open Space)

● 全員參與制(Sociocracy)

我們也少量的使用其他的流派來闡述價值,例如精實創業(Lean Startup)和設計思考(Design Thinking)。

在所有提到的流派中,我們並不自認為在每個領域都是資深專家。但在準備這本書的時候,我們對全球產業做了廣泛的搜尋和研究,確保我們選擇的解決方案是合理的。我們的結論是融合敏捷、全員參與制、超越預算模型和開放空間技術後,將成為一個最具整合性和務實的解決方案。這四大流派提供了必要的綜合戰略,來幫助創建使企業營運敏捷化的「通用理論」,甚至可以提供社會上的所有類型的團體使用。

四大流派都為前面所討論的挑戰提供了寶貴的解決方法,雖然有相似的價值觀和原則,但也從不同角度互補,共同支持企業提升敏捷性。

現在讓我們從宏觀的角度看一下這四大流派。

超越預算模型

超越預算模型(Beyond Budgeting),簡稱超越預算,並非由世界各地的財務長們聚在一起開會討論所產生的,而是由財務長們從財務和人力資源的角度觀察企業是如何取得成功,進而歸納而出的原則和價值觀。

超越預算最早的實踐是瑞典商業銀行於1970年代後期實施,大約是全員參與制開始發展的同一時期。一個叫做超越預算圓桌會議的早期工作群組,產生了關於超越預算的交流網絡。讀者可以找到有許多關於「超越預算模型」(Beyond Budgeting)的書籍。

超越預算這名詞不單單指編列預算本身,編列預算是傳統命令和控制管理所使用的常用工具,而「超越」意味著超越了傳統的管理模式。最主要的區別是超越預算在價值觀上認為「賦權和適應」比「命令和控制」更重要。超越預算中的六個領導原則,可以支持從「命令和控制」到「賦權與適應」的轉變。超越預算主要聚焦在瞭解固定目標和相對目標之間的差異,而沒有既定的配方或套路。就如同全員參與制和敏捷這兩個流派一樣,在實際應用時參考原則,在具體做法上有許多不同的可能性。而在超越預算裡的原則,就是賦權和適應(Empowerment and Adaptation)。

例如在命令和控制管理中,固定目標指的是有限制預算的專案,和用固定目標管理員工績效。在這兩種情況下,固定目標都沒有意義,因為假如我們有固定預算,當我們發現市場已經在改變,且需要更多的資金才能獲得成功,卻會因固定預算而無法得到更多資金。即使市場現在不需要那麼多資金的投入,拿到預算的人還是會盡可能的花掉每分錢,因為怕下個專案沒辦法獲得所需的預算。

以設定員工固定的目標舉例,假設銷售人員的固定目標為100個產品。如果此銷售員賣了80個,而競爭對手賣了120個,那說明這個銷售人員並沒有把工作做好。但是如果這個銷售員賣了80個,競爭對手卻只銷售50個,這個銷售人員可能做得很好。或者已經到了十一月,但我眼見無法達成100個的銷售目標,我會把我的產品的銷售延到明年,來提高明年的銷售情況。反之亦然,如果我已經達成了100個的銷售目標,我也會把產品銷售延到明年,以幫助我明年達到目標。

發明超越預算模型的財務長們發現,針對專案或個人的固定目標設定對企業是不利的,因為它無法即時適應現狀,也未能關注最新的組織發展需求。十二個超越預算原則都是來自於這一觀察,並確保可以即時適應當下情況。例如:

● 顧客:「把每個人的工作和顧客的需求連結起來。」這明確要求建立以顧客為中心的企業文化。

● 透明化:這個原則要求我們「讓資訊公開以實現自我調節、創新、學習和控制;不要限制它。」它要求透明化。

● 自主:這類似於敏捷的概念,即微觀管理不會帶來好的結果:「信任並賦予行動的自由。」

● 節奏:要求「圍繞著商業的節奏和事件,來動態組織管理和流程;而不是跟著年曆走。」學習企業內部和周遭環境所發生的一切,納入考量並且做出適當的調整。

超越預算模型從傳統財務和人資的角度切入,幫助企業整體更敏捷,並向這些部門示範如何透過政策與規定支持敏捷,它改變了公司傳統的支援部門所扮演的角色。

來自挪威國家石油公司,Bjarte Bogsnes的體悟

超越預算模型是一個強大的管理模式,但名字略帶誤導。超越預算並不是只談論要取消預算——這只是從「指揮和控制」轉移到「賦權和適應」,從根本上改變傳統管理,自然會發生的其中一個結果。事實上,超越預算乃是關於:認真面對現實,包括我們的商業環境和公司人員,也為了使組織的理念和實踐是完全一致的。試想當公司正在實踐理論X的時候(傳統的預算規劃就是一個典型的例子),管理階層卻懷抱著理論Y的願景,這將無助於企業的行動,也使說與做之間產生了會跌死人的坑。探討領導或管理流程的理論滿坑滿谷,但只有極少數能像超越預算模式那樣,以全局的眼光同時關照兩者。

許多敏捷協會的成員都明白超越預算模型和企業敏捷化息息相關,並有助於將敏捷方法擴展到更大的規模。然而敏捷方法雖然已經徹底改變了軟體開發的領域,但因為認知及用字的差異,使大部分的管理階層仍處在難以理解,甚至是無法理解其價值的狀態中。而又因管理階層大部分不會玩英式橄欖球,如果聽到他們認為Scrum是某種皮膚病時請不要驚訝!而超越預算模式則使用了管層階層熟悉的共同語言,使其容易理解,即便他們或許不贊同這個概念。

這也是為什麼企業導入超越預算的速度往往比敏捷或精實管理緩慢的原因。畢竟該模型不僅帶來了許多解決領導和管理流程的方法,還直接衝擊了管理階層的信念和特權,這是敏捷和精實管理在軟體開發和製造生產方面沒有碰觸的。在敏捷和精實管理中,最高管理層(C-suite)只看到了更快完成的計劃和更低的成本,既不恐怖也沒有啥威脅性,不像超越預算從一開始就打算處理高階管理階層這個核心問題。

我在二十多年前開始運用超越預算模型。當時的我非常幸運,和兩位既有智慧又勇敢的財務長和執行長共事。當我們提出了一個新的、具有高度自主性(沒有預算)的管理模式的時候,他們的反應是充滿好奇並給予鼓勵,而不是感到恐懼和抗拒,這真的是鼓舞了我們的信心。

我在2005年決定改變職涯,開始全職進行超越預算的執行面工作,直到今日。人們經常問我實施超越預算需要多長時間才可以「完成」。我並不認為我們完成了,也許我們永遠都不會完成,因為這並不是一個專案,這是一段伴隨著勇氣的旅程。

我們不斷發展和擴大挪威國家石油公司(Statoil)的模型,我們稱之為「從野心到行動」。這包括了緊密且全面的連結人力資源流程,在適當時機和情況下不使用年曆來做計畫,實施動態式預測(而不是滾動式預測)以及整合風險管理。時下最熱門的討論話題是和目標有關的。我們可以直接地擺脫這一切嗎?為什麼我們需要設定目標只是為了評量呢?一定有其他更好的方法來決定發展的方向以及評估表現!(摘錄整理自《原來你才是絆腳石》)

 

 書籍簡介 

原來你才是絆腳石:企業敏捷轉型失敗都是因為領導者,你做對了嗎?

Jutta Eckstein, John Buck/著;林裕丞/譯

博碩文化出版

售價:450元

 

 作者簡介 

Jutta Eckstein

Jutta Eckstein是專職的敏捷軟體開發教練、顧問及培訓師。在其超過20年的專案及產品開發經驗中,她獲得了許多敏捷如何運行的知識。

 

John Buck

John Buck是全員參與制社(The Sociocracy Group)的部門領導。全員參與制社社群是一家總部位於荷蘭的國際培訓和咨詢組織。

【複本資料管理伺服器:Rubrik CDM】結合動態與靜態複本應用,同時滿足備份、開發測試、資料分析等需求

$
0
0

在許多場合下,Rubrik都被分類為備份產品,實際上Rubrik已經跨越了備份應用這個目的,而是複本資料管理(Copy Data Management,CDM)這個新興應用領域的一員。

Rubrik的產品本體是稱作「Brick」的應用伺服器,採用2U/4節點規格,可透過連結多臺Brick機箱的節點,以Scale-Out型式擴展系統規模,並含有SSD I/O加速、壓縮、重複資料刪除等提高效能與儲存空間效益的功能,也能提供多租戶(Multu-Tenancy)、全程加密等管理功能。

就這樣的產品形式與特性來看,Rubrik的應用伺服器和一般軟體定義儲存產品十分相似,不同的是,Rubrik可透過內含的專屬Cloud Data Management軟體平臺,來提供複本資料管理(CDM)應用,所以是一種針對CDM應用的軟體定義儲存產品。

 

Rubrik推出的CDM應用伺服器,可透過專屬的Cloud Data Management軟體平臺,為用戶的虛擬平臺或實體主機,提供基於快照技術的資料複本服務,包括備份、開發測試與等分析等應用。

 

統合企業的複本應用需求

CDM是一種結合快照與複製的新興應用架構,先在來源端系統透過快照取得不同時間點下的資料複本,然後利用遠端複製將複本傳送到CDM伺服器保存,接著CDM伺服器再以這些複本為基礎,利用虛擬化技術複製出多個複本,用於備份還原、開發測試、分析等應用。

因此CDM可像備份軟體一樣,於線上生產平臺之外,獨立地長期保存與管理資料複本,以備意外時的還原之需,藉此滿足用途;又能像快照一樣,即時製作資料複本,並透過掛載立即使用資料複本,快速回應臨時性的複本需求。

也就是說,只需要CDM這一個平臺,便能滿足備份/還原這種「靜態」形式的複本需求,以及開發測試這類「動態」形式的複本用途,將企業兩大類複本應用需求合而為一。

推動CDM應用的新興勢力

在複本資料管理這個新興領域,成立於2014年、2015年發表首款產品的Rubrik,也算是後起的新廠商,雖然歷史很短,但發展相當迅速,短短時間內,系統軟體平臺便發展到第4代版本(目前最新版是4.1版,4.2版也即將發布),伺服器硬體也更新了2個世代。

目前Rubrik旗下有r300、r6000兩個主要的應用伺服器系列,另外還有內含更高階資安功能r528 (符合FIPS-140-2標準,並採用加密硬碟),其中r300與r6000都採用2U/4節點機箱,r528則是2U/雙節點機箱,也有VM型式的軟體版本。預計到年底時,r300系列會由較新的r6000系列完全接替。

Rubrik能支援主流的虛擬環境、作業系統,以及Oracle、SQL等應用程式,既可透過應用程式API(VMware VADP、微軟VSS或Oracle RMAN等),提供無代理程式架構的服務啟動與還原作業,也能搭配專屬的代理程式來啟動服務。

先透過vCenter或代理程式,讓來源端系統連結Rubrik伺服器後,然後便可利用控制臺的SLA Domain項目,設定資料保護政策,再將政策套用給個別來源端系統。接下來系統便會依照政策設定,藉由API或代理程式,在來源端系統啟動快照截取複本,並傳送到Rubrik伺服器的儲存區。

除了第一次擷取來源端複本時,須傳輸完整資料外,後續的複本擷取與傳輸都是以增量模式進行,Rubrik伺服器會自動將增量複本合成為完整複本,藉此可減少來員端的複本傳輸資料量。

由於Rubrik的資料複本是透過快照取得,與來源端系統的原始資料形式相同,所以只需掛載便能立即啟動,無須耗時的還原程序。用戶能視不同的應用需要,選擇不同模式來使用複本,例如將複本掛載到指定主機上啟用,用於提供資料還原、開發測試等不同需求。用戶還可在兩個站點之間,利用Rubrik伺服器的遠端複製功能建立異地備援。

提供靈活的Scale-Out部署架構

與其他CDM產品相比,Rubrik的一大特色是支援Scale-Out擴展架構。透過採用分散式NoSQL資料庫架構,提供了基於叢集的Scale-Out擴展架構,可藉由增加Rubrik伺服器節點,彈性擴展系統處理能力與儲存空間。Rubrik叢集的最小規模是3節點,最大規模則無限制,擴充叢集時,可一次以一個節點、或一整臺Brik機箱為單位,並能混搭不同款式節點來組成叢集,例如將r300系列節點,加入到r6000系列的叢集中。

不過,Rubrik的Scale-Out叢集架構,與一般Scale-Out叢集儲存系統仍有不同。一般叢集儲存系統是以stripe方式,把每ㄧ筆寫入I/O以區塊為單位,分散寫入到叢集中所有節點上,從而分散負載、充份利用所有節點的I/O效能與容量;而Rubrik的分散存取,則不是以區塊為單位,而是視不同型態的資料,採取不同的資料切割與分散方式。

若來源端資料是VM,那麼Rubrik會以VMDK為單位,分散給叢集中不同節點來處理;若來源端資料是檔案,Rubrik則會以100GB為單位切割資料,分散給不同節點;針對資料庫,Rubrik則是以資料庫內含的物件為單位,來分散給叢集中各節點處理。

所以Rubrik叢集的分散存取處理架構,並不是基於區塊層級的粒度,而是基於更大的資料單位,但仍能享有叢集架構的優點,包括負載的分散與平衡、充份發揮叢集中所有節點硬體資源等。

Rubrik Appliance儲存組態

Rubrik擁有複本資料管理(CDM)產品少見的硬碟+SSD混合儲存架構,其採用的4節點2U/12Bay機箱,可分配給每組節點3臺3.5吋硬碟,至於每組節點本身,也各自安裝了1臺SSD。

其中硬碟是做為資料儲存空間,SSD則用於讀取與寫入I/O的快取緩衝,可以加速壓縮與重複資料刪除運算處理,備份管理資料庫的寫入與搜尋處理,以及立即啟動複本等作業。

就歸格來看,Rubrik的伺服器每臺節點,都提供了4TB到10TB的硬碟儲存空間,一臺Rubrik伺服器可提供36TB到120TB的儲存容量,加上壓縮與重複資料刪除功能,還可提供比帳面容量規格更高的有效儲存空間,不過Rubrik把自身伺服器的儲存空間,定位為相對短期的儲存用途,至於長期儲存需求,則可透過Rubrik伺服器將資料轉存到雲端儲存環境,或是大容量物件儲存設備上保存。

 

SSD提供I/O加速

每臺Rubrik CDM伺服器節點,都各自搭載了1臺SSD,作為讀寫I/O的快取,依產品款式不同,有4TB、8TB與10TB等3種容量。r300與r6000系列都是採用400GB容量SSD,r528則是使用800GB容量SSD。

 

3種硬碟容量選擇

Rubrik CDM伺服器採用2U/12Bay的4節點機箱,每組節點可分配到3臺3.5吋硬碟,作為複本資料儲存空間。依產品款式不同,r300與r6000系列伺服器有4TB、8TB與10TB等3種硬碟容量。較特別的是r528,搭載了內含加密功能的8TB硬碟。

 

Rubrik Appliance硬體解剖

在複本資料管理(CDM)這個新興產品領域,結合了軟、硬體、訴求便利部署的一體機,是目前最常見的產品型式。除了我們這裡介紹的Rubrik以外,Cohesity與Veritas Velocity也都提供了一體機型式的CDM伺服器產品,不過雖然同樣是CDMㄧ體機,Rubrik的硬體規格仍有幾個與眾不同之處。

首先,Rubrik採用了類似超融合伺服器的2U/4節點機箱,搭配Rubrik Cloud Data Management軟體平臺的分散式叢集架構,可以提供類似超融合系統的高運算密度Scale-Out擴展能力,因此只要串連更多機箱與節點,就能很容易地擴展系統規模。

其次,Rubrik是CDM領域少數採用SSD+硬碟混合儲存架構的產品,每臺節點都含有加速I/O用的SSD。

第三,在新一代的r6000系列伺服器上,Rubrik率先引進了25GbE規格的網路埠(透過兼用於10GbE與25GbE的雙埠網路卡),是CDM領域最早採用這種新規格網路介面的產品,有助於提高資料傳輸頻寬。

目前Rubrik旗下有r300與r6000兩個伺服器系列,兩個系列的規格十分相似,差別只在r6000的處理器與網路介面規格比較新,處理器是Broadwell平臺,資料傳輸與管理介面分別是10/25GbE與10GbE,而r300系列的處理器則是Haswell平臺,資料傳輸與管理介面分別是10GbE與GbE。r528則與r300系列ㄧ樣是搭載Haswell處理器。預計到年底時,規格較舊的r300系列將會為r6000系列完全取代。

 

I/O介面規格

每臺Rubrik的機箱可以安裝最多4臺節點,每臺節點含有2組資料傳輸埠、2組系統管理埠,以及1組IPMI管理埠,我們照片中這臺是r300系列中的r334,便含有2組10GBase-T型式的10GbE資料傳輸埠(1)(也有SFP+埠的選項),2組系統管理用GbE埠(2),與1組IPMI埠(3)

 

電源供應器

2組1620瓦電源供應器提供熱備援的電力供應。

 

RAID卡與加速卡

Rubrik的節點都是單處理器組態,搭配64或96GB記憶體,另外還安裝了1張資料傳輸網路卡,以及1臺I/O加速用SSD。以照片中這臺r334為例,便安裝了1顆8核心2.4GHz處理器,64GB DDR4記憶體,1張雙埠10GBase-T網路卡,以及1臺400GB SATA SSD。

 

Rubrik軟體平臺的管理功能

藉由一體機的產品型式,Rubrik提供了簡便的系統部署與管理方式,管理者只需透過瀏覽器,就能登入Rubrik的CDM伺服器,執行系統環境設定與複本管理工作。

Rubrik的Cloud Data Management軟體平臺目前已發展到4.1版,可以支援類型非常廣泛的應用環境,對於虛擬平臺、資料庫等提供了備份API的應用環境(如VADP、VSS或RMAN等),Rubrik可透過API支援無代理程式架構的備份;對於一般實體主機或沒有API的應用環境,Rubrik也可透過安裝代理程式來提供備份服務。安裝代理程式雖然比較麻煩,不過對於資料庫來說,若透過代理程式備份,Rubrik將能提供更精細的還原時間點選擇。

有了來源端的資料複本後,接著管理者便能在Rubrik伺服器上,視需要以不同還原模式來使用快照複本,以VM複本來說,從複本中搜尋個別檔案、立即掛載複本、將複本匯出、在雲端啟動等5種模式可選。對於SQL資料庫,若搭配代理程式,便可利用拖拉時間軸選擇還原時間點,並選擇立即掛載、還原或匯出等3種還原模式。

由於Rubrik伺服器的儲存空間有限,每節點只有12TB到30TB容量,雖然可透過壓縮與重複資料刪除功能,提供比帳面容量更大的儲存效率,但容量終屬有限,所以Rubrik把自身伺服器定位於複本資料暫存服務,至於長期的歸檔儲存需求,則可透過Rubrik控制臺的歸檔選項,將資料轉存到雲端或物件儲存環境來解決,包括AWS的S3與Glacier、Azure,或指定的NFS儲存區等。

 

Rubrik 的網頁管理控制臺

管理者只需透過瀏覽器,就能登入Rubrik儲存伺服器的HTML 5網頁控制臺,執行系統設定與管理工作。透過控制臺的儀表板介面,管理者能迅速地掌握整體狀況。

 

簡易的備份政策設定

利用SLA Domain選項,管理者可以設定Rubrik伺服器的資料保護策略,包括啟動快照的頻率,保存複本的時間週期等,然後把這些策略套用到個別來源端系統即可。

 

提供多種複本還原應用模式

以來源端的快照複本為基礎,Rubrik可提供多種還原模式來使用複本。以VM複本的應用為例,便可選擇搜尋、瀏覽原單一檔案、將VM複本還原到原始位置、立即掛載VM複本、將複本傳送到雲端並啟動。

 

 產品資訊 

Rubrik CDM

●原廠:Rubrik

●經銷代理:力麗(02)21002458,敦新(02) 87978260

●建議售價:廠商未提供

●處理器:每節點Intel Xeon×1

●記憶體:每節點64GB或96GB

●儲存容量:每節點4TB/8TB/10TB硬碟×3

●叢集擴充能力:3~無限制

●資料傳輸介面:10/25GbE(r6000系列)/10GbE (r300系列)

●支援平臺:VMware Sphere與微軟Hyper-V虛擬平臺,實體主機環境

【註:規格與價格由廠商提供,因時有異動,正確資訊請洽廠商】

Viewing all 31479 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>