# 我們需要 DevOps 嗎?
###### tags: `DevOpsDays Taipei 2018` `9/11` `14:20~15:00` `Track B`

{%hackmd zjE8rohhTBKEAPwdaLV11Q %}

主旨：提供你一個參考方向(其實每個人要走的路都不一樣)

## 我們需要DevOps嗎？
瞎子摸象圖again

### 到底什麼是DevOps?
* 開建立高效能團隊?
* 開發速度變快?
* 建立自動化?
* 早下班?
* 老闆說的...
* 潮

### DevOps 三個因子
#### 人
* 最重要，但也最不可控
* 開發維運角色心態不同
* 組織大小，歷史包袱
* 行為思想要改變
*
成功-------------------->失敗
新創 -> 成長型公司 -> 傳統大型企業
做一個人的 DevOps

#### 流程
* 開發流程
* 維運流程
* 交付行為
* 協同合作

難-----------------簡單
專案項目 <- 服務 <- 產品

#### 工具
* 工具目的：在於輔助前兩者個實踐
* 不是最重要的
* 可以自選想要的工具

## Case

快速交付很困難
* 老闆認為要做好全面的測試，需要花很多時間
* 交付時間長 = 最安全的交付 ？

要快速交付、快速迭代，人的思維要改變

花大量時間全面測試，交付大量需求 -> 花更多時間在部署 <--> 確保系統穩定成本

永遠都在測試，無法交付
* Developer 超過三個月就會忘東忘西
* 要出部署文件
* Developer 不喜歡寫文件
* 文件寫很爛...

## DevOps 三個挑戰
#### 政治
* 最困難，要說服開發、維運團隊老闆

#### 成本

#### 技術
* 找不到人，最後還是純手工打包...

> 學會選擇，學會放棄 (DevOps)

> 有時候在想，搞DevOps真累，要搞人、搞流程、搞技術...
> [name=講者]

## DevOps 的本質

#### DevOps 思維
==持續交付價值==給我們的客戶
==縮短發布==產品到客戶的週期
==發現==問題、==持續==改善

#### DevOps 原則
系統==思維==
放大==回饋==循環
接受==失敗==和==持續==學習的文化
* 最困難的也是最重要的，難免會發生，需要公司去接受
* 不可能做到完整測試，難免出問題

## 7種 DevOps 習慣
1. ==自我組織團隊需與企業目標(比較容易說服長官)一致==
2. 嚴格管理技術債
3. ==專注於客戶/用戶價值流==
4. 假設理論、驅動開發
5. 蒐集監控正式系統運作資訊
6. ==實戰文化==
7. 管理環境架構作為靈活資源

## DevOps 循環
* Agile Planning
* Monitor and Learn
* monitor 很重要，才知道怎麼改善系統
* Build and test
* Release
* CD
* Release management

## 符合特性，進行DevOps改革
可以依照團隊或是組織特性選擇：

* 平台工具
* Release 節奏
* 開發和維運團隊的合作組織
* 測試方法或測試框架
* 自動化程度
* 或是其他軟體開發模式

> 標準很重要

## 7 種 DevOps 實踐

## DevOps ...

文化轉變中，相對應的技術會油然而生
有CI/CD不代表做好DevOps
DevOps 循環中，開發維運心態要改變
通往DevOps 道路需要不斷學習
DevOps 不會限制團隊必須什麼方法或理論進行軟體開發
不強制改變現有團隊的開發行為

## DevOps 的實踐

1. 資訊透明度
* 不管用看板、slack 等所有資訊都要可以讓大家看到
2. Backlog
* 使用者需求(80%)：來自商業需要的功能或是用戶需求
* 工程需求(20%)：建構Infrastructure、系統的改善或重構項目，須放在同一個Backlog被追蹤和完成，不可以被排除看板外

3. Version Control(建議用git)
* 有效的建立版本控制的分支策略
* Check in 的程式碼必須要連接工作項目
* 只要是程式碼就要納入版控，包含 database (table view, 等)
* infra 設定(IaS) ，需要納入版控 (Infra as Code, Dockerfile ...)

4. Testing
* 自動化是測試的關鍵
* 單元測試、整合測試、UI測試到負載平衡測試都是屬於持續測試一環
* 使用增量和迭代方法，讓測試的深度不斷前進
* 有錯就加測試，總有一天會寫完
* 別期望一開始就寫好所有的測試案例
* 最好的測試，就是增量測試

5. 持續整合、持續部署
* CI / CD 策略定好，再自動化
* 80%自動化 > 100%自動化
* 不自動化也能 CI/CD 只是比較累
* 工人智慧

6. 監控與學習
* 品質
* 安全
* 可靠性
* 持續提供價值給用戶
* 了解用戶如何使用系統
* 通常 bug 有兩種，user 用錯了或是真的系統壞了

7. 量測指標
* 沒有 Burndown chart, velocity 反正時間都估不準，看這個也沒用
* 看整個團隊的指標
* time to build
* time to release

8. 定義 Story Done
* Story 完成後，到正式上線
* 正式上線後，有第一位使用者開始使用

## 建立 100% ~~DevOps~~ 精實協作團隊

全都是工程人員 都要開發QA維運

## 良好的 DevOps 文化團隊

* 團隊每個人一起致力讓系統能夠平穩且有效率
* 資訊共享、互助合作共同承擔成功與失敗
* 團隊每個人互相扶持、相信人人都可以改變
* 資深人員提攜新進人員
* 每個人努力讓團隊變得更好，不是追求自我成功或是價值
* 團隊中不能有只想提升自我，不幫助團隊的人

## 最後 - DevOps Milestone

* Sprint 縮短為一週
時間縮短人的潛力就出現了 !?(笑)
奉行不加班，能開發的時間只剩四天，因為其他事務約佔一天
* 重新切分 Story 大小
* Dev + Ops = One Team
* 資訊透明化
* CI / CD
* 類微服務
* 發現架構太大了，逐步轉換。
* Time to Release / Time to Build
* Container Docker

## 總結
持續改善完善系統

減少浪費

> DevOps 需迭代演進！

Release vs Deploy
* CD 只有到 Release
* Container Image 準備好

---

> 場外聊天室，歡迎在下方喇賽