說好的 2015 Cloud & Datacenter EXPO 心得兼筆記文來了，但此文僅只針對下午 DevOps & App 此條議程線。因為文有些長，因此會分成上下兩篇文章來發佈，目前先整理出上篇。
How Trend Micro adopt DevOps model - 趨勢科技 資深工程師 / 陳彥宏 第一場就是一個亮點，趨勢科技的陳彥宏帶來了趨勢科技的 DevOps 經驗，簡報分為兩大部分，首先當然是 DevOps 基本介紹，第二部分則是趨勢科技目前的 DevOps Practices。
開場
首先陳彥宏先用了 Dev 與 Ops 之間常發生的問題作為開場，常見的案例就是 Dev 的 Code 在開發環境中可以運作的很好，可是上到 Production 之後程式卻炸了，於是 Dev 就冷冷的撒手不管說「在我家跑得好好的，但既然是在你們家出了問題，當然就你們自己處理喔～」
但其實 Dev 這邊的 RD 也不是故意不管問題，而是 Ops 這邊的 Datacenter 有一定的管理，當災難發生時，Dev 這端還需要經過一堆申請手續後，才能進去做救災的動作，而經過一大堆的手續後，往往火都不知道燒到哪裡去了。所以每次要上新的程式就變成了一場可怕的夢魘，為了解決這樣的問題，趨勢科技開始導入 DevOps。
DevOps - CAMS
接著陳彥宏先開始說明何謂 DevOps。提到 DevOps 一般都會從 CAMS 四個角度來解釋，CAMS 分別代表 Culture, Automation, Measurement, Sharing。
Culture
前面提到的 Dev 與 Ops 之間的問題，其實是一個文化上的問題，因為 Dev 與 Ops 之間的距離不夠緊密，彼此之間無法了解對方的想法。
既然是文化問題，當然就要從文化著手，打破部門之間的隔閡，首先讓 Dev 也開始做一些 Ops 的工作，反之讓 Ops 也開始做一些 Dev 的工作，如此就能產生一些變化，讓 Dev 知道在開發中遺留下的問題是如何地顯現在 Ops 端，讓 Dev 自己知道面對問題有多痛。例如：DB migration。在開發環境沒有正式資料且資料量有限，因此 DB migration 可以輕易地完成，但在 Production 環境，服務正在運行中且資料量可能是成千上萬筆，DB migration 就不會是一件輕鬆的事。
如此一來 Dev 漸漸知道要多爲 Ops 著想，反之 Ops 也是如此，Ops 因為有了 Dev 的經驗，在問題發生時，將更懂得分辨問題的原因，究竟是因為程式本身造成的問題，還是系統架構、Server 層次的問題，甚至能具備解決程式層面問題的解決能力。
當 Dev 與 Ops 兩邊的溝通順暢後，前述的問題便減少了，解決問題的速度也提升了。甚至小型專案也不用區分 Dev 及 Ops，兩種角色可以由同一個人員來擔任。除了職務上的變化，同時也建立一個共同的溝通平台，讓 Dev 及 Ops 可以跨專案及專業的來分享知識，提升彼此的水準。
當組織改變之後，在流程上也跟著改變。過去的流程是 Dev 先啟動，當程式完成後，Dev 工作便結束，程式則移交給 Ops 做後續處理，接著 Ops 才開始建立 Production 環境、部署程式、建立備援計劃，最後正式上線。
但真實的狀況往往是，開發進度可能會有所延誤，因此時程被壓鎖的很緊繃，等到程式移交給 Ops 時，已經要急忙上線了，這時候也許在上線前有 10 個步驟要完成，可是時間不夠，因此其中的幾個步驟就可能會被暫時忽略或延後處理，像是「備援計劃」，但天知道你會不會在上線沒多久就遭遇需要備援的狀況呢？
而更新過的流程則是 Dev 與 Ops 同時進展，例如當 Dev 開始建構程式架構時， Ops 也同時也配合 Dev 建構系統架構，同時兩方合作針對程式面與系統面的擴展機制、備援機制…等進行溝通，避免發生到開發後期才發現無法擴展，導致程式或系統架構需要大改的狀況。又例如當 Dev 開始在做程式的驗證時，Ops 這端則可以開始做 Monkey Test 或 Security Scan。或者當 Dev 準備 release 時，Ops 這端則可以進行 Performance Test 確保效能及系統乘載量。
在趨勢科技中，經過人員、組織與流程的改變，建立起新的文化，把 RD、QA (Dev) 及 Ops 三方重新融合在一起，在每一個專案中，都有自己的 RD、QA 及 Ops，此種新的文化有助於三方的提升與合作，各人不再僅僅關心自己的事，也開始用不同的角度思考，並懂得為其他人著想。
Automation
在 Ops 的工作當中有許多很繁瑣的事情，每天都一再的重複發生，例如 deployment。假設 A 與 B 各自部署，很可能部署的環境狀態會有些許的不同，然而雖然只是些微的差異，但在 QA 或 Testing 可能就會產生無法預期的結果。因此自動化是非常重要的一件事情，除了可以節省時間，同時也能確保重複的動作能一再的被重複執行，並且每次執行都能獲得相同的結果。
自動化可以應用在許多的地方，像是 Build、Testing、deployment、Monitoring、Self-healing、System Configuration、Scaling、Infrastructure。
唯有當一切都自動化之後，才能提到做到所謂的 Continuous Delivery。如此一來才有可能加快產品的發佈週期。然而有些人會提到一個迷思「加快發佈週期，不會影響產品的品質嗎？」，事實上不會，因為加快發佈週期代表的是快速的每次前進一小步。因此當這一小步有問題時，你可以再次同樣快速的更新而修補，或是快速的 rollback。畢竟在軟體開發時，不管測試的多仔細一定都還會有意想不到的 Bug，因此重點反而在於能多快發現問題、解決問題，而快速的解決問題發佈更新，更代表著一種重視使用者回饋的態度，這在商業拓展上是有正面幫助的。
在趨勢科技的經驗中，從原本三個月一次 release，提升為最短一周一次。當 RD 確認完程式之後，30 分鐘內即可自動進入 Alpha 環境並同時開始自動 Testing，而 Alpha 環境最短一周可進入到 Beta，然後再進入 Production。
Measurement
Measurement 可以幫助你收集資料，並能與過去的資料進行比較，因此透過 Measurement 可以幫助我們了解系統的真實狀況，而不會只是自我感覺良好。
目前趨勢科技在 Measurement 方面做了三大部分，分別是 Monitoring、Metrics、Dashboard。 Monitoring 要做的事，不只是關注 Infrastructure 層面，像是 CPU 或 memory。在 Product 層面也有 Product 的 Monitoring，例如可觀察 Application 的 Error 是否有增加的趨勢，或者透過 API 去監測 Application 的運作是否正常。
嘉言錄：「Monitoring 就像是我們的眼睛，沒有 Monitoring 我們的眼睛就是盲的，你就沒有辦法知道你的系統的狀態」
Monitoring 比較像是一個二維的向度，代表每一個項目在某一個時間點 ok 不 ok，但 Metrics 則像是三維的，代表某個項目在某個時間的狀態如何及數據的數值是如何，所以從基本的 CPU 到所有 Application 的相關數據，當應該要盡可能的收集。
在收集資料時，當下可能會覺得收集這些資料似乎沒有用途，為何要全部收集來占用硬碟空間，但事實上數據收集的越完整，當問題發生時，這些資料就越有幫助，因為也許問題發生時，對於發生原因一點頭緒也沒有，但透過交叉比對各種數據，往往問題的原因立刻就會浮現。
最後，當有非常多的 Metrics 之後，就會需要一個合適的 Dashboard 方便觀察系統的狀況。例如透過 Dashboard 幫助你將數據繪製成圖表，並且將圖表並列方便查看比對。Dashboard 也能用來協助比對現況與過去數據，借此協助判斷目前的數據是忽然異常，還是週期性的狀況。當然還有一種常見的狀況是老闆或業務可能會三不五時來問最近的使用人次有沒有上升，只要提供適當的 Dashboard，就可以方便他們自己去閱讀，不用三天兩頭的一直來問最新數據。
Sharing
前面有提到每一個專案內都有自己的 Ops，並且有建立共通的溝通平台，讓 Dev 及 Ops 可以跨專案及專業的來分享知識。例如最新的 Security Issue，就可以透過溝通平台發佈訊息，讓每一個 team 都能及時注意問題並立即修補。另外就是每一個專案都會有可共用的 tools，這些也都能彼此分享，讓彼此各自站在對方的肩膀上，一步一步的往上提升。
DevOps Practices
接著陳彥宏開始介紹目前趨勢科技目前進行的 DevOps Practices，主要是依據趨勢科技採用的 DevOps Toolchain 逐一介紹。
趨勢科技目前有實現 Infrastructure as Code 的做法，首先 Configuration Management 使用的是 puppet，並且配合 git 做版本控制。如此實行之後，讓即便是新進的同仁也能有所依循，得以知道目前 Infrastructure 的架構。並且透過 puppet 即能做到快速且自動化的部署，當新系統部署之後 Monitoring 也能自動偵測並自動開始記錄它的資訊。
Monitoring 方面趨勢科技使用的是 icinga。icinga 提供了一個平台，讓使用者可以自由加入要 Monitoring 的項目，因此除了監測常見的項目之外，也可以加入比較細節的項目。例如 DB 的 Deadlock、table size 是否過大，甚至是 DB Backup 是否成功之類的數據。盡可能地記錄所有的數據，由小地方開始著眼，才能避免大災難的發生。
另一個 Monitoring 採用的是 smokePing。用 smokePing 來補足一些 icinga 無法看到的地方，利用 smokePing 測試 HTTP 或某些 API 是否有正常運作，以及每次測試的 response time 。透過這些數據來得知服務的健康狀態。
Monitoring 工具可以分別由不同的角度來監測你的系統，所以 Monitoring 工具越齊全，當然你就越能了解你的系統狀態。
Metrics 採用的是 Graphite。Graphite 使用起來滿容易的，並且針對歷史資料會自動 average，雖然這會造成檢閱歷史資料時，無法看到最精確詳盡的數據，但卻能避免歷史資料量太大。
Dashboard 採用的是 Grafana 與 GDash。
另一個 Practices 是 Peer Learning、Peer Coaching，當有一個新進 Ops 時，會由前輩先示範一次，再讓新人自行操作，而前輩在一旁觀看，等到發現新人已經夠熟練之後，才會讓他獨自操作系統。另外在重大的系統部署之前，也會先進行 Peer Operation 以此確保人為疏失可以降到最低。
接著提到了 Security，作為 DevOps 一定要具備 Security 的概念，因為當新機器連上網的那一分鐘開始，就避不了 Security 的問題，所以不論是 Firewall、Honeypot 等，該做的事情一定都要做。
其他陳彥宏還列出了許多的 Practices，但因為本場簡報時間有限，他便沒有逐一說明了。
下圖即是趨勢科技目前的 DevOps Toolchain
第一場講題實在令人驚奇，後來根據會後旁人私下請教陳彥宏時，他表示趨勢科技導入他所提到的這些 DevOps Practices 大概花了 4~5 年的時間，由此可見趨勢科技滿早就有注意到內部流程的問題，並且一直有在尋找改善的方法與工具。這可以說是一個實踐 DevOps 的優良範例！
我們如何以OpenStack打造UniCloud大學雲 - 國立清華大學 教授 / 鍾葉青 請原諒我在第二場時，思緒有稍微登出，所以因此沒有非常詳盡的記錄。但我們可以先看看 iThome 在活動網頁上的議題介紹
「社群雲的概念雖然才在國內萌芽，但在幾所大學的努力下，每一個大學的Cloud已經串聯起來，成立UniCloud(大學雲)。本議程特別邀請到教育雲端服務平台UniCloud的推手－－鍾葉青教授蒞臨分享他的團隊是如何透過 OpenStack 這樣開源技術，打造新一代的大學雲。」
鍾教授在一開場就先說明其實並不全部都是使用 OpenStack 的技術，因此這個題目並不完全正確，而在接下來的簡報中，則是逐一介紹了 UniCloud 的開發歷史過程，以及 UniCloud 裡面包含了哪些服務。
想要更認識 UniCloud 他們目前也已經有官方網站，https://www.unicloud.org.tw/
有興趣者可以前往官網了解更多內容，但要先強調的是 UniCloud 基本上是「大學雲」、「學術雲」，因此當然是學術單位才能申請使用，一般企業則必須要透過建教合作的方式才能使用。
而 UniCloud 中個人最深感興趣的是 SSDB，因為在簡報中提到了幾個重點：
- SQL-to-NoSQL Translator: A 100% ANSI SQL to NoSQL (HBase) translator
- Multi-tenancy: User, database and table management
- Transaction: Supports ACID
- JDBC driver: Replaces with SSDB JDBC driver without modifying user programs
- RESTful APIs: CREATE, INSERT, UPDATE, SELECT, …
- Hybrid architecture: HBase API/MapReduce; SQL/NoSQL databases
- Better performance: Reduce the execution time from hours to seconds
其中第一點號稱能 100% ANSI SQL to NoSQL，讓使用者不用改變 SQL 的使用習慣，就能直接使用 NoSQL。乍聽之下挺有趣的，不知道實際使用的狀況如何，以及效能如何？
