大型銀行實現 DevOps 的挑戰和關鍵

tags: DevOpsDays Taipei 2018 9/11 10:30~11:10

銀行業中IT特有文化：

• 銀行業中IT部門非直接創造收入
• IT高層只關心完成項目，非IT本身如何改進
• 安全要求非常高 -> 產生冗長的審核流程 -> 效率低落
• 大家忙著交付業務需求，沒空進行 DevOps
• 穩定優先，新技術再說
• ex: 業務部門很難理解IT部門買了第三方的軟體還要花很多時間整合才能用

老舊 and 第三方系統

• 銀行普遍存在老系統(20/30年以上)
• 規模龐大，用戶多，難改
• 技術老舊，新的 DevOps 技術 or 工具難以支援
• 維護效率低落

固有開發習慣難改變

• 瀑布流
• 開發流程不透明
• 只關注交付，不考慮過程
• 手動設定/配置多 -> 容易出錯,速度慢
• 沒有建立反饋機制
• 不重視程式碼品質

團隊協作的困難

• 不同地區和地域 (例如：方言多)
• 多種語言
• 管理能力偏低
• 團隊協作不夠
• 發開運維水平參差不齊

DevOps 的關鍵領域

• 自動化
• 反饋報表
• 文化 & 意識
• 分享

自動化 CI/CD

• 開發流程自動化是實現DevOps的基礎

  技術是基礎，人是關鍵的地方。但人的的轉變是最困難的

• CI/CD
  • 持續集成
  • 持續交付
  • 持續部署

DevOps 工具棧

想成為一個 DevOps 工程師，工具是基本的

DevOps 自動作流水線

中心化有利有弊

• pros 硬體上有優勢
• cons 失去對細部的掌握

開發流程數據和持續回饋

• 可視化
• 反饋

開發流程數據的中心化收集

中心化以後收集更方便了
不用分別到各部門收集資料
dashboard (可以分析和反饋)
參考(sematext)[https://sematext.com/]

持續代碼質量分析

sonarqube

與業務部門緊密協作

• 在銀行裡，推動 DevOps 不僅在 IT 部門
• 業務部門是關鍵(外匯部門請業務部門去溝通減少審批流程，如果是DevOps自己發起可能沒用)
  

團隊Pod結構化轉變

也來個場外聊天室好了

這是一定要的

有人知道要怎麼把 hackmd 弄成像這樣的共筆畫面嗎? 左邊是議程內容…右邊對應到每個議程的文章

就最上面的這段 %hackmd zjE8rohhTBKEAPwdaLV11Q %

歡迎聯絡駐場工程師
BoHong Li

上面那一頁是怎麼弄出來的…?

選單>Book Mode
https://hackmd.io/book-example

你點一下列表的編輯，應該就知道了（重整旁邊有一隻小筆）

(題外話) 其實不只銀行業，似乎大部分的公司都是如此，開發部門被認為是「成本單位」

樓上那段可以插在筆記裡面啊XD 不然應該不知道前言後語

感覺應該開個IRC讓大家聊天ＸＤ
哈哈.

https://gitter.im 考慮一下XD

不用跳介面也不是壞事啦

不過銀行老實說各種怕死～台灣銀行業一堆東西都是外包的，他們也只負責維運，以前在銀行在開發要導DevOps各種被打槍。都是說有問題就找廠商就好，我們不用管。

年紀大了後，我漸漸可以理解銀行業的想法，對開發者來說，出包就修正就好，但因為銀行業的分母太大，所以就算是萬分之一可能都代表很大的損失，(萬分之一對於出包來說，真的算是小影響)，漸漸的，他們會傾向安全第一，新技術永遠先擺在後面再看。

因為他們的$$很大，所以高層的薪水也會超級高。

難怪獵人頭不推薦新鮮人去銀行業磨練技術

現在跟的敢弄新的講得出來的也就那幾間而已，其他各種老牌。

上面固有流程，真的不是僅限於銀行業。

請問有簡報url嗎？

(暗黑心法) 寫出高品質的程式碼，很快把工作完成，
你會得到. ..

1. promote
2. days off
3. more tasks?

我好像沒得過1&2..
如果沒有正向刺激，不會往好方向努力好像很正常啊~

[問卦] 如果老闆今天叫我做這個 明天又叫我不要做這個 該怎麼辦？

換個老闆…
當老闆的老闆

記得記錄下來
以後他說你沒貢獻就把這些紀錄列出來給他看

照老闆的做, 弄清楚是誰打你考績& 發你薪水~
然後記得開履歷，去找新工作(無誤)

剛剛講者講到一個重點，要推動某些改變時，需要相關的人「理解」或「感受」到改變的必要性，
ex: 不做 就會多虧/少賺多少錢 (對sales很有用)
痛了就知道
所以要讓人知道現在痛在哪XD
真的!

ex: 要接新需求可以啊, 那麼原本的案子要delay喔~

Pod…我以為我在聽 Kubernetes

突然注意到，剛剛講者的麥克風聲音好像就沒有悶悶的了