Home | 簡體中文 | 繁體中文 | 雜文 | Search | ITEYE 博客 | OSChina 博客 | Facebook | Linkedin | 作品與服務 | Email

DEVOPS

Technical department with DevOps

Mr. Neo Chen (陳景峯), netkiller, BG7NYT


中國廣東省深圳市龍華新區民治街道溪山美地
518131
+86 13113668890


版權聲明

轉載請與作者聯繫,轉載時請務必標明文章原始出處和作者信息及本聲明。

文檔出處:
http://netkiller.github.io
http://netkiller.sourceforge.net

微信掃瞄二維碼進入 Netkiller 微信訂閲號

QQ群:128659835 請註明“讀者”

2016-06-01

摘要


目錄

1. 軟件項目管理篇

這裡講述項目管理的基本知識與方法,軟件項目管理與傳統行業項目管理最大的區別可能是知識型人才的管理。所謂管理大可分為兩類,一類是着重考察項目過程本身,一類是主要考察項目的參與者,前者着重於時間管理,後者傾向于績效考核。

學習管理你千萬不能陷入到管理學領域,很多管理者陷入一個誤區,試圖尋找一種管理工具(非軟件,這裡指的是管理方法),通過工具解決項目管理問題。

管理軟件開發團隊,你只需要20%的管理學知識,更多的是對技術的掌握。

1.1. 範圍管理

為了實現項目的目標,對項目的工作內容進行控制的管理過程。它包括範圍的界定,範圍的規劃,範圍的調整等。

我們將技術部劃分為三個子部門,這是為了實現DEVOPS而制定。

  1. 軟件開發部

  2. 軟件測試部

  3. 運維部

1.2. 時間管理

為了確保項目最終的按時完成的一系列管理過程。它包括具體活動的界定,如:活動排序、時間估計、進度安排及時間控制等項工作。

時間管理站項目管理40%的內容,很多人對項目管理的理解就是時間管理,其次就是質量管理。

1.2.1. 項目管理中工時計算的問題

1.2.1.1. 背景
  1. 為什麼項目總是不能按時結項?

  2. 為什麼工期一再延誤?

  3. 員工不夠努力嗎?

  4. 時間去了哪裡?

1.2.1.2. 面臨的問題

普遍問題是,我們至今對知識型工作者的做事效率,仍採用工業時代的評價模式。若工作者每小時的效率產出基本一致,那關注他們的工作時長便行之有理。 對於重複性勞動,這種評價模式可能確實管用,但對知識型工作者就不太適用。

1.2.1.3. 工時去了哪裡?

據統計一個典型的美國辦公室工作者,每個工作日只能完成90分鐘真正有意義的工作。

當天剩餘的大部分時間,都被浪費在各種分心事務上,比如閲讀新聞、網上衝浪、同事社交、吃零食、喝咖啡、翻看報紙、處理無關郵件、不必要的拖延行為、玩遊戲、做白日夢等。 多說一句,美國辦公室工作者在世界範圍內還算最高效的人群。在其他很多國家,人們每天完成的實質工作甚至更少。

1.2.1.3.1. 洗手間,茶水間,吸煙
  • 洗手間,先不分男女性別差異以及大小號,平均下來10~15分鐘一次沒有意見吧?那麼一天至少兩次吧?

  • 茶水間,洗杯子,泡茶,清理茶葉殘渣,遇到同時還需要寒暄幾句。需要10分鐘吧? 一天至少2~4次吧?

  • 吸煙,我不吸煙不太清楚,但是看到公司的煙友抽的爽,了得歡。20 分鐘要吧?

1.2.1.3.2. 看郵件,寫郵件

我最討厭郵件群發,或將不相關的郵件也CC給我。閲讀這些不相關的郵件是非常浪費時間的,你不清楚那封郵件中會與你有關,只能逐一閲讀。 寫郵件更浪費時間,給領導寫郵件浪費時間乘以二,既要要注意措辭,還要注意語氣。 閲讀郵件至少需要30分鐘時間,寫郵件需要1個小時

1.2.1.3.3. 溝通

很多企業組織架構層級導致溝通不順暢,增加溝通成本,工時內耗。企業應該為員工提供開放的溝通,而不是層層轉達。

1.2.1.3.4. 查資料

查資料並沒有浪費工時,磨刀不誤砍柴工。但資料查了,問題沒有解決工時就被消耗了。

1.2.1.3.5. 無關的會議

中國是開會就是你一句我一句出主意,大都無法落實。很多無關會議把你拉去旁聽。一般會議時間都在2個小時左右。

1.2.1.3.6. 不必要的拖延行為

員工拖延時間有很多原因,不一定都是員工的問題,多是企業的問題造成的,所以企業自身要找原因,不要歸罪為員工問題。

1.2.1.3.7. 私人時間
  • 看手機短信,接聽亂七八糟的電話(買保險的,貸款的,賣房的,頭自理財的,詐騙的)

  • 微信,朋友圈

  • 看新聞,玩遊戲

以上僅僅粗略列出幾項影響工時的因素,但實際過程中遠不止這些,會有更多因素會占用工時。

1.2.1.4. 怎樣改善面臨的問題

死扣工時的時代已經過去了,我們應該更多關注員工產出成果。

歐美企業儘可能的為員工提供最好的工作,彈性工作時間甚至可以SOHO辦公,不是讓員工享受,而是讓員工最大化產出。

目標管理,價值管理都勝過時間管理。

我認為項目管理應該改叫項目服務,項目服務能更描述項目人員的角色。

員工每天真正投入工作的時間越長,產出就越多,做有真正有意義的工作才是王道。

1.2.1.5. 怎樣計算項目工時?

項目管理中通常是採用8小時/每天,一周40小時來計算工時。

項目延期主要問題就是工時計算不合理,項目工時不能與8小時工作制掛鉤。

8小時工作制,僅僅是規定員工在8小時之內要工作崗位上。

員工不是機器人,不可能8小時內,一刻不停的工作。

所以減去上洗手間,茶水間,吸煙,處理工作郵件,回覆工作即時消息,開無用的會議等等時間,員工剩下多少真正有意義的工作時間?

所以我認為保守計算,項目工時應該按6小時計算甚至4小時。

1.2.2. 任務分配


怎樣管理好項目

怎樣輕鬆地管理好項目,其實非常簡單,做好下面幾點即可。

- 規劃目錄
- 配置管理
-

你要關注那些事情要做,安排好先後順序,每個版本中完成那些任務,完成多少任務達到一個里程碑,該在何時測試,何時部署。你每天要關注的是版本庫的變化,代碼的修改與審查,控制好分支等等。下面我會逐條詳述。

首先立項後,你首先要規劃好項目的目錄結構與版本庫佈局,然後是配置項,包括開發,測試,生產三套,分別用戶各種場景。同時需要配置三個項目環境。

接下來是分解任務,確認在那個版本發佈那些完成的任務,規劃里程碑。這些工作是增量,逐漸增加了,但確認第一個版本是必須的。

中國式開發,過于隨意很難按照西方 ALPHA-1,2,3... -> BETA-1,2,3... -> RC1,2,3.... ->
Release 1,2,3...
這樣的進度進行,每個環節都需要半個月之久,發佈一個版本通常需要一年。中國更多的是上面拍板隨時發佈。所以我喜歡採用功能點對應版本的方式,即某某功能就是一個小版本,完成一個功能升級一個版本,里程碑就是一個大的Release
版本。這樣可以滿足中國式發佈。每個版本一個分支,每個Release一個tag。

關注Timeline,代碼每處修改都要仔細讀一遍,很多bug都可以在review(代碼審查)過程中過濾掉一部分,同時防止不符責任的提交(代碼不能運行)

嚴格管控分支,把握項目進度與節奏,什麼時候代碼要從開發分支進入測試分支,什麼時候代碼要從測試分支進入Release分支,什麼時間發佈等等

你需要一個部署工具,能夠實現全量發佈,增量升級,本版切換,備份,失敗回撤等等。例如http://netkiller.github.io/home/deployment.html

1.3. 質量管理

是為了確保項目達到客戶所規定的質量要求所實施的一系列管理過程。它包括質量規劃,質量控制和質量保證等。

1.4. 溝通管理(Communication Management)

為了確保項目的信息的合理收集和傳輸所需要實施的一系列措施,它包括溝通規劃,信息傳輸和進度報告等。

我的要求就是單向精準,消息漏斗化。單向是有別于廣播的。

很多企業喜歡使用廣播試溝通,典型的例子是將電子郵件CC抄送給所有人,有關無關均抄送。這帶來一個問題,員工每日面對一屏幕的電子郵件,找出與自己有關的郵件,既浪費時間也容易出錯。所以電郵需要精準投遞,不要發給無關的人。

消息漏斗化是指消息到達最終接收者,中間經過的環節不斷過濾,消息量越來越少。舉例,10個需求,5個評審通過,3個實現不了,1個開發實現不了, 最終只有1個需求安排給開發者。

1.4.1. 任務分配

一旦時間點確定,接下來就是分配任務倒指定開發人,任務的分配十分講究,分配任務要精確描述,不能使用模糊語言,那樣會造成誤解。我的分配原則是5W1H方法:



- What:做什麼事?
- Why:為什麼做這件事?有什麼意義?目的是什麼?有必要嗎?
- When:什麼時候做,完成的時間是否適當?
- Where:在什麼地方做,在什麼範圍內完成?
- Who:由誰負責做?由誰負責執行?誰更合適?熟練程度低的人能做嗎?
- How:怎樣做

舉例,運維任務



- What:為api伺服器做負載均衡,多增加一個節點,負載均衡算法採用最小連接數。
- Why:目前api伺服器只有一台,如果出現故障將影響倒所有業務運行,顧該伺服器存在單點故障,需要增加節點。
- When:本週內完成,周末上線。(此處可以寫日期)
- Where:在A機櫃,低2機位處,連接倒交換機第三個連接埠。
- Who:XXX負責網絡配置,XXX負責上架,XXX 負責驗收測試
- How:增加/etc/hosts設置如下
  - api.example.com   127.0.0.1
  - api1.example.com  192.168.2.5
  - api2.example.com  192.168.2.6

舉例,開發任務



- What:增加圖片驗證碼。
- Why:目前用戶註冊登陸以及發帖無驗證嗎,某些用戶通過機器人軟件批量開戶/發廣告帖,給我門管理帶來很大困擾。
- When:2014-06-15 開始開發,2014-06-20 12:00 上線。
- Where:用戶註冊,登陸與發帖處增加該功能,。
- Who:張三負責驗證碼生成類的開發,李四負責用戶註冊,登陸UI修改,王五負責發帖UI的修改。
- How:具體怎麼操作的細節,此處省略200字...

舉例,測試任務



- What:測出XXX軟件並發性能。
- Why:目前XXX軟件在綫任務達到200後,用戶反映速度慢,經常掉綫。
- When:故障時間點10:00AM,需要周二完成測試,周五完成優化,月底上線。(此處可以寫日期)
- Where:在AAA分支檢出代碼,編譯後部署到BBB環境。
- Who:XXX負責網絡配置,XXX負責軟件部署,XXX 負責測試
- How:具體怎麼操作的細節,此處省略200字...

1.4.2. 工作例會

開會就要有解決方案,成熟的方案,否則不要開會,開了沒有意義,浪費時間。

通常我們看到的會議就是針對XXXXX問題你們看看怎麼做,你們大家商量一下,然後你一言,我一嘴,各個提建議,到頭什麼都沒有解決,一份會議記錄發給所有人,几乎沒有人看。

提意見都很踴躍,具體到誰負責都開始低頭,會議內容落實5%不到。

會議不能議而不決,會議的目的是針對方案細節依次敲定,然後進入到Ticket對應具體負責人。

1.4.3. 工作報告

不要讓員工為了寫工作報告而寫工作報告。

我從不要求團隊寫工作報告,因為項目管理中Ticket/Issue一幕瞭然,任務出口是由經我這裡確認後發出,對整個項目了如執掌,所以不需要工作報告。

工作報告並不能判斷員工的工作量以及是否工作飽和,所以工作報告是不准確的,可以虛構,不實的,而員工為了寫報告而寫報告,造成時間成本浪費。

1.5. 變更管理(Change Management)

1.6. 整合管理

是指為確保項目各項工作能夠有機地協調和配合所展開的綜合性和全局性的項目管理工作和過程。它包括項目整合計劃的制定,項目整合計劃的實施,項目變動的總體控制等。

我習慣于將配置管理劃為整合管理,我認為配置管理是軟件整合的一個環節,你別較真,管理學本就沒有規範而言,你的模式成功,你就可以著書立說,你就是權威,你就是標準。

1.6.1. 配置管理

是通過技術或行政手段對軟件產品及其開發過程和生命周期進行控制、規範的一系列措施。配置管理的目標是記錄軟件產品的演化過程,確保軟件開發者在軟件生命周期中各個階段都能得到精確的產品配置。

配置管理很多企業將其理解為應用軟件的配置檔案,這是錯誤的。所有影響軟件正常安裝,運行的配置項,都要納入配置管理。

配置管理範圍涵蓋軟硬件,包括:
  1. 硬件:路由器,交換機,防火牆,負載均衡器,伺服器......

  2. 系統軟件:操作系統,應用伺服器,資料庫,緩存,消息隊列......

  3. 應用軟件配置檔案:日誌,介面,資料庫連接池......

任何項目應該有三套以上配置庫,分別是開發,測試,生產

開發配置檔案所涉及資源與權限僅限于開發環境,測試配置檔案所涉及資源與權限也僅限于測試環境,生產環境也一樣,應用程序部署到那個環境,就應該使用那套配置檔案

1.7. 風險管理

涉及項目可能遇到各種不確定因素。它包括風險識別,風險量化,制訂對策和風險控制等。

1.7.1. 開發,測試與運維的關係

開發,測試,運維不是三個獨立部門,他們相互緊密聯繫,但又相互制約:

開發只負責寫程序,將運行無誤的程序提交至版本庫中

開發不能私自將程序交給運維部署,也不能將編譯好的程序給運維測試。

測試部只能從版本庫提取代碼,然後編譯,打包,運行,測試

不允許測試部將代碼交給運維部部署

避免代碼沒有經過版本庫流入生產環境,綫下與線上代碼不一致

運維部負責部署應用程序,配置管理,只接受測試部確認無誤的版本,部署代碼只能從版本庫中提取

1.7.2. 權限管理

Master 是主幹,只有開發部主管/經理級別擁有權限

Tag 是 Release 本版,開發部主管/經理擁有權限

Development 開發組分支,所有程序員有權限提交

Testing 測試分支,測試部擁有權限,此分支不能修改,只能從開發分支合併代碼

1.7.3. 代碼審查

1.8. 成本管理

為了保證完成項目的實際成本、費用不超過預算成本、費用的管理過程。它包括資源的配置,成本、費用的預算以及費用的控制等項工作。

1.9. 人力資源管理

是為了保證所有項目關係人的能力和積極性都得到最有效地發揮和利用所做的一系列管理措施。它包括組織的規劃、團隊的建設、人員的選聘和項目的班子建設等一系列工作。

1.9.1. 管理好管理層

管理好管理層比管理好員工更重要,不要讓管理層成為傳話筒。你是抱著很大期望提供優厚的待遇聘用管理層,對於所有人來說,你需要一個這樣的職位,對於他需要一分工作而已。出色的管理層就像出色的員工一樣非常難尋,需要機遇,需要天時,地利,人和。很多管理層也如果普通員工一樣平平談談,當一天和尚撞一天鐘。

1.10. 採購管理

為了從項目實施組織之外獲得所需資源或服務改採取的一系列管理措施。它包括採購計劃,採購與徵購,資源的選擇以及合同的管理等項目工作。

採購管理這塊運維涉及比較多,機房選型,機櫃,路由器,交換機,防火牆,負載均衡,伺服器,存儲...... 這裡先放棄本章節

2. 流程篇

開發 -> 測試 -> 運維 貫穿始終。

几乎所有的技術企業都會重視技術規範,為此制定各種規範,並要求員工嚴格執行。同時員工會想出各種對策,就這樣形成了潛規則。

流程與規範的制定需要需要滿足幾個條件,簡單,容易掌握,容易執行,可重複執行

2.1. 技術規範的誤區

企業管理層擅長制定烏托邦式的流程與規範,隨便拿出一條都堪稱完美,無懈可擊,但沒有考慮到執行結果,流程規範在執行過程中每個環節都會出現問題。

我16年的職業生涯中在不同的公司任職過,几乎每到一家公司都會遇到各種規範,隨着職業發展最後我也成為了規範的制定者,也曾經主持制定過開發規範,運維規範,測試規範等等。

我做過很多規範,文檔無數,技術人員根本不會去看,通過開會向下傳達,開會的人根本沒有心思理會你的規範,規範執行阻力是很大的,效果也差。

終於有一天我意識問題的存在,開始反思,企業是否需要制定這些規範? 我發現與企業環境/文化有很大關係。

有些強制的規範可以通過一些技術手段,避免出現。不會出現也就無需規範!

只有機器人才能100%執行流程

除了事,制定規範,後續無人跟進,

員工考慮的是儘快完成工作,

但這些規範起到的實質作用就好比“請保持室內衛生,不准亂團垃圾,禁止隨地吐痰”

2.2. 開發流程

2.3. 測試流程

2.4. 運維流程

3. 實施篇

按照章節順序依次實施

3.1. 項目管理工具

實施DEVOPS首先我們要有一個項目管理工具。

我建議使用 Gitlab,早年我傾向使用Trac,但Trac項目一直處于半死不活狀態,目前來看Trac 對於 Ticket管理強於Gitlab,但Gitlab發展的很快,我們可以看到最近的一次升級中Issue 加入了 Due date 選項。Gitlab已經有風投介入,企業化運作,良性發展,未來會超越Redmine等項目管理軟件,成為主流。所以我在工具篇採用Gitlab,BTW 我沒有使用 Redmine,我認為 Redmine 的發展方向更接近傳統項目管理思維。

軟件項目管管理,我需要那些功能,Ticket/Issue管理、里程碑管理、內容管理Wiki、版本管理、合併分支、代碼審查等等

關於Gitlib的安裝配置請參考 http://www.netkiller.cn/project/project/gitlab/index.html

3.1.1. 創建用戶

過程 1. 企業內部使用的 Gitlab 初始化
  1. 關閉在綫用戶註冊

  2. Step 3.

    1. Substep a.

    2. Substep b.

3.1.2. 創建組與項目

過程 2. Gitlab 初始化 - 創建組
  1. 點擊 New Group 按鈕新建一個組,我習慣每個域一個組,所以我使用 netkiller.cn 作為組名稱

  2. 輸入 netkiller.cn 然後單擊 Create group

  3. 組創建完畢

創建組後接下來創建項目

過程 3. Gitlab 初始化 - 創建項目
  1. 單擊 New Project 創建項目

  2. 輸入 www.netkiller.cn 並點擊 Create project 按鈕創建項目

  3. 項目創建完畢

3.1.3. 分支管理

起初我們應對並行開發在Subversion上創建分支,每個任務一個分支,每個Bug一個分支,完成任務或修復bug後合併到開發分支(development)內部測試,然後再進入測試分支(testing)提交給測試組,測試組完成測試,最後進入主幹(trunk)。對於Subverion來說每一個分支都是一份拷貝,SVN版本庫膨脹的非常快。

Git 解決了Svn 先天不足的分支管理功能,分支在GIT類似快照,同時GIT還提供了 pull request 功能。

我們怎樣使用git 的分支功能呢? 首先我們不再為每個任務創建一個分支,將任務分支放在用戶自己的倉庫下面,通過 pull request 合併,同時合併過程順便code review。

testing: 用戶測試組的測試分支,只能合併,不能提交代碼。

development:開發組的分支,可以合併,可以接受pull request, 可以提交代碼

過程 4. Gitlab 分支應用 - 創建分支
  1. 首先,點擊左側 Commits 按鈕,然後點擊 Branches 按鈕進入分支管理

  2. 點擊 New branch 創建分支

    在 Branch name 中輸入分支名稱,然後點擊 Create branch 創建分支

  3. 分支已經創建

重複上面步驟,完成development分支的創建。

過程 5. 保護分支
  1. 保護分支,鎖定下面分支,只允允許合併,不允許提交

    master

    testing

  2. Step 2.

    1. Substep b.

3.1.4. 分支管理

3.2. 升級流程

下面流程是自動化完成,這裡分部講解

過程 6. 升級操作流程
  1. 數據備份

    通常絶大多數人,備份還採用 cp / tar / 以及稍微有點技術含量的rsync做差異備份 例如

    					
    cp -r /www/example.com/www.example.com /backup/www.example.com-2016-05-23
    tar zcvf www.example.com-2016-05-23.tgz /www/example.com/www.example.com
    
    rsync -auzv /www/example.com/www.example.com /backup/www.example.com-2016-05-23
    					
    					

    這種備份適合比較小的軟件包,對於圖片伺服器什麼的就比較耗時。我很早就開始嘗試使用快照備份當時使用LVM,後來轉為Btrfs檔案系統,到2010的時候btrfs快照已經非常成熟.

    					
    [root@www.netkiller.cn www]# btrfs subvolume snapshot /www /www/backup_2016-05-23
    Create a snapshot of '/www' in '/www/backup_2016-05-23'
    					
    					

    快照瞬間建立,使用下面命令查看快照

    					
    [root@www.netkiller.cn www]# btrfs subvolume list /www
    ID 284 gen 18583 top level 5 path backup_2016-05-23
    					
    					

    掛載快照

    					
    [root@www.netkiller.cn www]# mount -t btrfs -o subvol=backup_2016-05-23 /dev/xvdb1 /mnt
    [root@www.netkiller.cn www]# ll /mnt/
    					
    					

    關於BTRFS詳細使用方法,請參考 《Netkiller Linux 手札》

4. 背景

5. 概述

6. 總結

comments powered by Disqus