1. 程式人生 > >如何將精益方法應用於企業IT?

如何將精益方法應用於企業IT?

精益工程

將精益方法應用於企業IT

LEAN ENGINEERING
LEAN METHODOLOGY APPLIED TO ENTERPRISE IT

一、前言

精益工程定義了一套高速率且低風險地建立和部署軟體產品的指導原則。使用精益工程,可以降低驗證新技術、在流程中實現增量變更、向市場推出新產品的風險,並且能夠以一個更快的速率達到一個高質量的結果。

每個學科都建立在一套原則和主張之上。作為軟體工程實踐的門徒,我們有必要定義出一套清晰且永恆的原則,用來指導我們創造產品的流程、方法和架構。

二、起源

精益不是新概念,精益的 DNA 可以追溯到上世紀五六十年代,豐田公司優化其著名的精益製造流程時。精益製造的許多指導原則都是歸功於豐田汽車公司副社長大野耐一和新鄉重夫,他們一起創造了豐田生產系統(Toyota Production system,TPS)。

大野耐一著手在他所負責的生產過程中根除效率低下和消滅浪費,他引入了幾個概念,比如:小批量,準時制,持續改進。

三、小批量

作為工程師,當我們面臨大量的工作時,我們的第一想法就是設計出最系統化的方法,以便我們可以通過圍繞重複任務來組織工作,實現批量處理。

想象一下要準備1000封信。

作為工程師,我們的第一想法很可能是要儘可能的以最高效的方式處理這項工作。使用大批量處理方法流水線化生產。

  1. Tri-Fold all the letters(將所有信紙摺疊三次)
  2. Place the Stamp, Delivery and Return address stickers on the envelopes(在信封上貼郵票、收信地址和退信地址)
  3. Place the letters in the envelopes(將信紙裝進信封)
  4. Seal the envelopes(密封信封)

這樣看起來很簡單且高效,因為重複,我們非常高速率地處理單個任務。但是我們錯了。

如果信封和信紙的尺寸不合適呢?如果貼紙沒有膠水了嗎?如果信封有問題不能密封呢?

為了瞭解製造過程中是有缺陷的,小批量的做會更好。在這個案例中,一個完整的迴圈流程是:

(1)摺疊

(2)塞信紙

(3)貼郵票和地址

(4)密封

由此我們可以在大規模處理之前,識別出流程中可能失敗位置。

Small Batches = Fail Fast!

小批量=快速失敗!

四、持續改進

無論何時,流水線上的任何工人在豐田製造流程中發現了問題,都可以停止流程,所有人都會幫助修復問題,直到問題修復才能繼續進行流程。

我們鼓勵工人找到問題的根本原因並立即修復。流水線上的工人也都被鼓勵在自己的崗位上進行改進,而無須徵得管理者的同意。這個流程就是持續改進。持續改進的一些好處:

  • 改進是基於許多小的變化,而不是完全顛覆
  • 由於改進點子都來自工人,所以不會有特別大的變化,因此也更容易落實
  • 小的改進不會像主要流程改變那樣需要大筆的資本投資
  • 持續改進鼓勵工人們對自己的工作負責,有助於加強團隊合作,從而提高員工的積極性

這個領域的先驅者愛德華茲·戴明將持續改進視為根據組織目標對來自過程和來自客戶的反饋進行評估的系統的一部分。

最廣泛使用的持續改進工具是一個四步質量模型 PDCA 迴圈——plan(計劃)-do(執行)-check(檢查)-act(糾正) ,也被稱為戴明環:

  • Plan: 識別改變的機會和計劃
  • Do: 小規模的實現改變
  • Check: 使用資料分析改變的結果以確定行動是否帶來不同的效果
  • Act: 如果改變成功,則在更大規模範圍內落地並持續評估結果,如果改變無效,繼續迴圈

Continuous Improvement = High Quality!
持續改進 = 高質量!

五、精益創業(LEAN STARTUP)

埃裡克·萊斯將精益製造中的概念應用到了他所參與的許多在網際網路泡沫時期和之後的創業專案。他發展出軟體產品開發流程的兩個指導原則:快速失敗和持續改進

埃裡克·萊斯的整體主張是如果創業是投資自己的時間去迭代式地構建產品或服務以滿足早起採用者的需求。他們可以降低市場風險並避免需要大量的初始專案資金和昂貴的產品釋出和失敗。

埃裡克·萊斯定義了一個將新產品成功推向市場的科學方法。你可以在構建-度量-學習的生命週期中持續地進行小的調整以保持高速進步,而不是制定需要建立在非常多假設基礎上的複雜計劃 。

構建 – 度量 – 學習 是一個反饋環,它的目標是在迴圈中儘快驗證你的想法。

你首先定義出最小可行產品(MVP),這個版本的產品允許團隊以最小的付出進行最大程度的驗證性學習。

構建 MVP 併發布到生產環境(持續交付)並度量執行時健康狀態和產品的可用性(持續分析)

然後你可以使用對比測試和調查的方法讓你的客戶參與產品反饋中來。這為下一個迴圈提供了學習(持續反饋)的輸入。

六、最小可行產品(MINIMAL VIABLE PRODUCT)

最小可行產品(MVP)的定義是這個版本的產品允許團隊以最小的付出進行最大程度的驗證性學習。

在整個週期中的每個迭代中,準確定義出MVP是團隊想要成功實踐這個方法必須要掌握的重要技能。範圍太廣會拖慢速率,範圍太小又不足以在驗證此次釋出的週期中充分學習。

至少有一件事是肯定的,我們想要避免以激進的方式從上到下設計和實現一個大系統的方法。這種方法會導致巨石架構、延期、缺少對終端使用者真實需求和期望的充分溝通以及因為大量的任務和向遺落戰境不可避免的死亡行軍喪失了開發生產力。

通過掌握定義最小可行產品的技能,我們可以實現有用且簡單的產品,以便我們儘快讓使用者參與進來,獲取反饋、驗證我們的想法並且在撞到南牆之後快速失敗。

比如,比想要驗證微服務架構是未來專案的正確方向。不是每個人都相信並正在學習一個傳統的巨石架構,但他們有興趣看看這種方法是否有效。最小可行產品就可能是以一個或幾個 API 定義一個微服務並基於如下的公共能力實現它

  • Logging and Error Handling(日誌記錄和錯誤處理)
  • Run-time Analytics(執行時分析)
  • In-memory Caching(記憶體快取)
  • Data Persistence(資料持久化)
  • API Design(API設計)
  • API Management(API管理)

一旦你構建成功之後就部署到生產環境,讓團隊(客戶)去玩一玩 API,如果使用了 API 管理,可以獲得實時的分析。

第一眼看起來好像有很多事,但是通過分切關注點和不考慮太多服務業務邏輯方面的因素,你可以進行微服務良好的 API 設計和常見的錯誤處理,日誌記錄和報告能力等等將是整個專案的可行方向,而不僅僅是這一個服務的驗證學習。

七、精益工程(LEAN ENGINEERING)

精益工程利用精益創業中的持續創新的構建-度量-學習迴圈並應用在企業級產品開發中。注意術語“產品”的使用,這是一個重要的差別。作為工程師,我們習慣於根據專案進行思考,專案擁有起始日期,任務,里程碑,而且往往不是永久持續下去的。

簡單改變一下我的思維,“我們在創造產品“,我們可以超越我們的條件並且成為快速地為市場帶來高質量產品的專家級企業家。

我的市場是我們支援的企業的員工和夥伴。我們的基礎設施和應用產品提供了運轉一個公司的基石 。我們是企業級的企業家。

1. 持續交付(CONTINUOUS DELIVERY)

為了實現高效率高質量的目標,我們有必要頻繁地自動化釋出。在構建階段,我們定義了最小可行產品,這個版本的產品允許團隊以最小的努力收集大量的經證實的認知(Validated Learning)。我們通過定義部署流水線自動化我們的軟體開發生命週期(SDLC)。

部署流水線包括持續整合,開發者使用自動化原始碼控制、構建和單元測試。部署流水線是將程式碼從程式碼庫交付到測試人員手中的自動化過程,包括從測試環境到預釋出環境,再到生產環境。

更廣泛的是自動化從創意到終端使用者手中可使用的服務的全過程,以驅動反饋環。

部署流水線既定義了部署計劃又定義了釋出計劃。這兩者的區別在於:

  • 部署是一個工程決策,關於以何種頻率部署到預釋出環境以驗證構建內容。
  • 釋出是一個業務決策,當團隊準備好期待反饋過程時進行。

自動化的主要優點是它創造一個可重複的、可靠的、可預期的過程。自動化可以防止混亂,如果結合一個完善的反饋機制,可以洞察團隊的績效。

2. 持續分析(CONTINUOUS ANALYTICS)

為了給持續學習試驗提供輸入,無論是通過自動化部署流水線還是生產環境。我們想要利用每一個優勢去收集資料。我們的目標是將分析結合到流程的每個部分,以便生成可以合成為資訊並作為學習過程的一部分的資料。

為了從程式碼庫中獲取實時資料,在程式碼、日誌和異常處理的級別引入度量是非常重要的。我們也會使用已有的運維工具度量負載、服務和程序健康狀態,資料庫指標等等。如果有必要,團隊可以考慮構建一個面板將所有資訊合併到一個檢視中便於展示和閱讀

3. 持續反饋(CONTINUOUS FEEDBACK)

我們經常地釋出並讓我們的客戶參與到反饋中來,這些反饋可以幫助我們定義下一階段的 MVP 開發。

隨著 MVP 產品的功能增長,產品從早期採用階段成長為你可以從之收穫利潤的產品。由於你在最開始就已經將產品釋出到生產環境,你無須擔心產品會在釋出的時候失敗,因為你從第一天開始就已經將產品釋出了。

4. 精益工程和雲端計算(LEAN ENGINEERING AND THE CLOUD)

精益工程在小且機動性高的跨職能團隊中效果最好。精益工程的目標是通過自動化和頻繁地釋出以實現快速且可靠的方式高效率地交付高質量的、有價值的軟體。

使用商業雲平臺可以建立高度自動化的按需提供流程並基於構建-度量-反饋迴圈快速迭代。引入雲平臺的持續整合和部署流水線並使用構建於雲平臺中的分析工具。

商業雲平臺提供一鍵式基礎設施和通用應用和資料服務。通過利用這些服務的優勢,開發者可以專注於為他們的客戶創造真正的價值。

八、總結(SUMMARY)

精益工程是精益方法在低風險地交付高質量軟體方面的應用。它吸收了精益製造、精益創業、持續交付的思想。特別感謝 Jez Humble(http://jezhumble.net/),他在這個領域裡非常有影響力並且一直處在宣傳這些思想的最前沿。

推薦學習(RECOMMENDED LEARNING)

  1. The Lean Startup, Eric Reis( http://www.amazon.com/The-Lean-Startup-Entrepreneurs-Continuous/dp/0307887898 )
  2. Lean Enterprise, Jez Humble, Barry O’Reilly, Joanne Molesky(http://shop.oreilly.com/product/0636920030355.do)
  3. Continuous Delivery, Jez Humble, David Farley(http://www.amazon.com/gp/product/0321601912?tag=contindelive-20)

中英文對照版PDF下載連結:https://pan.baidu.com/s/1hsBOcni 

密碼: a65q

胥峰

盛大遊戲高階研究員

《Linux 運維最佳實踐》作者、《DevOps: A Software Architect’sPerspective》譯者。擁有10年運維經驗,目前關注運維自動化、DevOps以及Docker在遊戲中的應用等相關技術主題。運營公眾號“運維技術實踐”。