1. 程式人生 > >DevOps企業實踐指南(5): 第三條原則:文化

DevOps企業實踐指南(5): 第三條原則:文化

第一條原則體現了價值流的從左向右的流動,第二條原則是快速和日常的行為帶來的從優向左的反饋。第三條原則聚焦於創造一個持續學習和持續實踐的企業文化。而這些原則使得組織中的成員能夠不斷地積累知識和經驗,而這些知識和經驗最終成為團隊乃至組織的巨大收穫。

製造業的實踐

讓我們再次把目光轉向製造業,傳統的製造業中工作內容被嚴格地定義並必須遵從,留給作業者們極少的權利,作業者們基本無法從日常工作中進行學習併成長,而至於將學到的內容或好的想法改善和整合到現行系統中更是不可能,對企業來說個人完全就是那個“工業時代舞動的扳手”,個人對企業自然也會漠不關心,冷漠是整個文化的主基調。
在這種環境中,除了冷漠,這種傳統的企業文化中還往往包含另外另個字:”罰”與”怕”。前者是企業行為,後者是員工心理,整體構成這種文化的主基調。企業有這種想法也很正常,出了問題的員工被懲罰天經地義,難道還要把犯錯的員工供起來不成。拋開容易引起爭論的應該怎樣做不做討論,這種情況下,從同理心的角度出發,一般有兩種情形會習以為常:
第一種情形是:因為害怕被懲罰,出了錯的員工會做兩件事情,第一是瞞,瞞到啥時是啥時。第二是推,瞞不住的時候開始找各種理由,各種推脫,各種背鍋俠紛紛湧現。
第二種情形是:那些指出問題或者可以改善的點的員工容易遭到孤立,因為他們被視為麻煩製造者。潛臺詞就是“就你能”,”就你事多”,排除極少數的嫉妒心之外,更多地是因為這種文化下,改善的原因是因為發現了目前做的不好的地方,做的不好的就要罰嘛,不嫉妒你的idea,但是你的idea造成別人的困擾,如果不站在道德制高點上,而從人之常情來說孤立這種有創意的改善推動者也確實是事出有因。
而這些會帶來不好的效果也是每個人都一清二楚。
相較於傳統的製造業企業,在上世紀製造業變革的浪潮中,很多高績效的製造業的做法卻是截然不同的。不再是將工人們視作工具,給予其一定的權責,使得一線的工人能夠在他們的日常工作中進行實驗以便能夠進行不斷的改進。區別於傳統的做法,限定的流程,出現錯誤進行懲罰,這種做法實際是源於企業本身認為不斷地改進才應該是常態,甚至已經將其變成了例行的工作內容,因此有想法的員工自然少了後顧之憂。

罰與瞞

做了某個操作,或者某個外部的影響之下,核反應堆會如何反應,其可能性的結果由於其複雜性導致幾乎無法預測,即使預測之後成千上萬種的可能性也使得我們無法做出對應的措施。而我們現代複雜的系統往往也如同核反應堆一樣複雜,即使我們在工作已經謹小慎微如履薄冰,依然不能精確地判斷變更等是否會對其帶來好處或者災難性的後果。
而一旦問題發生之後,我們立即會去確認原因,而根本的因素似乎經常是員工的失誤,而非常通常的做法也是找出來進行懲罰(Name/Blame/Shame),做錯事的人被懲罰是非常自然的,另外為了防止類似的錯誤繼續發生會增加審批的流程。在專案中還可以增加一種叫做checklist的神奇列表,你改了一行程式碼可能需要你看10000行checklist確保你的這樣程式碼從設計到編碼規範到測試質量到整體效能以及科技人文企業利潤不會造成影響,可惜的是,似乎不是很奏效。
而這種懲罰的方式所帶來的後果正如Sidney Dekker所說的那樣:它會使得那些做容易出錯的工作的人更加恐懼而不是更加仔細,而整個組織也只是會變得更加官僚化,自我保護也會變得更加常見。
複雜的系統中,日常的操作不得不做,而那些容易出錯的操作,除去一小部分就是由於粗心和技能不足的關係,大部分情況下,儘管已經小心翼翼,但是問題還是發生了。但是由於懲罰文化大行其道所帶來的恐懼情緒,當問題出現或者出現徵兆的時候,一直到災難的發生那一刻, 員工的做法是隱瞞或者視而不見。

信任和分享

傳統制造業改革所奏效的,對現代企業來說也是如此。科技作為驅動生產的第一生產力,而技術的提升自然需要不斷地學習不斷地試錯,為了輔助這個過程,文化的作用自然在建立一個高度信任的寬鬆環境,使得員工敢於也甘於執行持續學習的過程促進自身成長,而這個過程在於日常瑣碎的工作之中進行,因為要不斷地實驗,自然會有風險,如果沒有高度信任的文化,是難以做到的。通過實驗,自然會知道哪些流程或者知識能夠在實際的生產環境中有效,哪些沒有效果。有想法的員工將自己的想法付諸實施之後,有些成功和失敗的,自然也會判斷出一些可以哪些可能有用哪些目前還無法起效。而且,經驗的分享和全域性利用也是文化的重要部分,如何將一處較好的實踐經驗推廣到整個組織,也是企業文化需要考慮的事情。
信任和分享構成文化的基石,在具體實踐方面,有很多需要做的細節,比如

  • 在日常的工作中預留出時間用於改善的時間用於持續的學習
  • 自行引入壓力測試或者容錯性測試保證持續的改進
  • 甚至可以考慮在生產環境自行模擬或者進行一些可能導致問題的操作以確保系統一切都在可控之中

依靠持續學習和改進,使得團隊具有了快速自適應不斷變化的環境的能力,而市場正是不斷變化的,唯一沒有變化的就是變化自身,這種適應市場快速變化能力最終會幫助企業贏得一席之地。

三種文化

作為最早研究組織文化對安全和績效所起作用的主要人員之一的Ron Westrum發現在衛生保健領域所起的作用,發現了”拓展型”的文化會起到非常好的一個效果。Westrum 定義了三種類型的文化:

文化型別 擁有此種文化的企業行為特徵
病態型組織 企業中充滿畏懼和威脅感。員工會會因為各種內部政治因素隱藏資訊,故意曲解使得對他們自己有利。失敗經常會被隱瞞而不會被彙報
官僚型組織 規則和流程統治著整個組織,各自都有自己的一畝三分地。失敗會由組織系統地判斷以決定懲罰還是寬大處理
開拓型組織 積極主動地尋找和分享資訊以使得組織能更好地實現目標。在整個價值流中進行責任共享,並能夠進行失敗的反饋和反思。

Dr. Westrum在醫療保健領域所發現的開拓型組織文化以及高度信任的氛圍在科技領域的公司同樣奏效。當問題發生的時候,更加積極地對系統進行重新設計,每一次問題的出現都成為改進的機遇。
正如Etsy的Bethany Macri所說的那樣,免責的文化消除了恐懼,恐懼的消除帶來了對真實狀況的把握,而對真實狀況的把握才使得問題的真正預防和改善成為可能。

總結

好的企業文化對DevOps的實踐有著很好的促進,DevOps提倡免責的文化,提倡高度信任的文化,提倡分享/協作和深度溝通。就像製造業曾經走過的那樣,這種文化的提倡最終會直接帶來日常工作的改善,比如在日常的工作中進行故障性測試以保證業務在各種情況下的連續性,並能將局部發現的各種改善在整個組織中進行擴充套件,而保持這種持續學習的氛圍,則能使得企業創新和適應快速變更的能力不斷增強,最終對實現業務價值的目標起到推動作用。

相關推薦

DevOps企業實踐指南(5): 原則文化

第一條原則體現了價值流的從左向右的流動,第二條原則是快速和日常的行為帶來的從優向左的反饋。第三條原則聚焦於創造一個持續學習和持續實踐的企業文化。而這些原則使得組織中的成員能夠不斷地積累知識和經驗,而這些知識和經驗最終成為團隊乃至組織的巨大收穫。 製造業的實

DevOps企業實踐指南(4): 第二原則反饋

DevOps的第二條原則名為反饋,它存在於價值流的各個階段的逆向過程中,通過反饋而使得工作更加安全和可控。而反饋的重要性在大型複雜系統中顯現的更加重要,在故障出現最初端倪的時候就能檢測到的能力對於一個不能中斷和降低服務標準的關鍵性功能來說是無比重要的。 高

DevOps企業實踐指南(3): 第一原則流動

DevOps的三條基本原則:流動/反饋/文化。第一條原則(流動)需要達成快速平穩地從開發向運維的價值流動,從而更快的進行價值交付。在這個過程中,作為開發或者運維的區域性目標被弱化,而開發和運維等協同所產生的整體的共同目標在這條原則中得到強化。 從業務需求到交付

DevOps企業實踐指南 1 DevOps能為我們帶來什麽

反饋 參考文獻 預測 需求 怎樣 而是 安全相關 告訴 最大 幫助盈利/提升文化/加速效率是DevOps實踐的三大目標,上世紀八十年代在制造業領域展開的那場如火如荼的精益實踐的變革還歷歷在目,而DevOps在軟件領域將要或者已經掀起的風浪也是如出一轍。 Dev+Op

DevOps企業實踐指南(7): 版本管理

在推行DevOps的過程中,持續整合和持續部署都是DevOps落地時需要重視的重要基石。而最終保證DevOps成功實施則需要更多更加細緻的細節落到實處,比如版本管理。在這篇文章中我們將會結合企業實施版本管理中經常會出現的七個場景去理解為什麼版本管理是複雜的,在此

【HTTP權威指南章-HTTP報文

響應 主體 方法 首部 部分 功能 第三章 http 支持 HTTP是因特網的信使,報文就是信使運送的包裹。 這一章包含: 報文如何流動 報文的三個組成部分(起始行,首部,實體的主體部分) 請求報文和響應報文的區別 請求報文支持的各種功能(方法) 響應報文返回的狀態碼

軟工實踐學習(次)

bsp ima 增刪改查 pri 增刪 ext 處理 logs ring 經過這一段時間的ssh框架學習,通過老師帶我們完成一個項目後,我們需要自己從0開始,開始新的項目,重新搭建框架 這次我選擇的是庫存管理系統 首先依然是搭建hibernate,以及spring。

DevOps企業實踐與架構

相關 可靠 端到端 質量 離線 追溯 數字 通過 敏捷 原文地址:http://www.sohu.com/a/112351816_355140 什麽是DevOps及其誤區 DevOps概念從2009年提出已有8個年頭。可是在8年前的那個時候,為什麽DevOps沒有迅速走

博客 你好 Java web!

目的 conn .com 分享 ges 網頁 服務器 今天 mage 今天周五了,明天就是周末!第一個周末就這樣結束了 今天我學習了MyEclipse開發 Javaweb 程序,學的是最基礎的那一部分 首先先創建了自己的

企業訂餐系統(次周總結)

src ges ket cnblogs 頁面設計 log images 實現 技術 第三次周總結   本周大家都基本開始了項目實現的步驟   王潔學姐做了後端有關登錄、註冊部分以及查看和修改信息功能。   項詩茹學姐在構思我們網站的設計圖   王賢國學長在實現文件上傳部分

【NOIP2016提高組A組7.16】跑道

以及 span const queue als TP 分析 namespace 技術分享 題目 數據範圍 分析 時限5000ms。 我們註意到\(a_{i}初始值以及x小於等於600且非零\) 也就是說,\(a_{i}\)的質因數一定小於600,而600以內的質因數只有

大話企業上雲之

ges 當前 可靠性 運營 數據安全 需要 常見 water 企業 前言:不論什麽項目,最終部署實施都有其對應的方法論。按照項目的方法論,可以將上雲過程分為如下四個階段:評估階段~~~設計階段~~~實施階段~~~~運維階段一、評估階段1.1可行×××主要是驗證上雲的可行性,

次作業閱讀《構建之法》1-5章有感

工程師 -- 成功 計算機行業 new 各種功能 量化 解釋 com 這個作業的要求來自於:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178 閱讀《構建之法》1-5章有感 第1章:概論

次作業閱讀《構建之法》1-5

不能 ont 我不 tsp ref 後端 有一個 bsp 產生 這個作業來自於:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178 第一章:概論 這一章主要介紹計算機科學的領域,軟件工程與計算機科學

實踐】演算法章上機實踐報告

1. 實踐題目 7-3 編輯距離問題   2. 問題描述 設A和B是2個字串。要用最少的字元操作將字串A轉換為字串B。這裡所說的字元操作包括 (1)刪除一個字元; (2)插入一個字元; (3)將一個字元改為另一個字元。 將字串A變換為字串B所用的最少字元運算元稱為字串A到 B的編輯距離,記為

python-opecv圖片混合及亮度調節

import cv2 as cv import numpy as np def add_demo(m1,m2): dst=cv.add(m1,m2) #量圖片加在一起 cv.imshow("add_demo",dst) def subtract_demo(m1

小白讀《HTML5權威指南部分 CSS

點選連結:http://note.youdao.com/noteshare?id=02dbcb3ade7cd5a7fe2c327fc6404ee0 下面是直接複製貼上,沒有圖片且亂版 理解CSS 1.CSS標準化 一開始:具有相同名稱的屬性採用不同的方式處理,只能用瀏覽器特定的屬性訪

讀書筆記-PowerShell實戰指南版)

第三版和第二版的不同 在第三版中增加了很多實用的技巧和經驗,比第二版的層次更加的豐富,增加了很多不容易注意到的知識點,這些知識點掌握了之後,可以很好的避免在實際的應用中踩坑。 關於本書的介紹請參考 http://www.pstips.net/learn-powershell-3-in-a

《php與mysql權威指南部分02

第14章 mysql資料庫開發14.1 mysql資料型別   1.數值型別:     五種整型:tinyint,smallint,mediumint,int,bigint分別為1,2,3,4,8位元組數     三種浮點型:float,double,decimal分別4,8,m位元組     # 宣告一個整

Python程式設計從入門到實踐課後答案:

3-1 姓名: 將一些朋友的姓名儲存在一個列表中,並將其命名為names 。依次訪問該列表中的每個元素,從而將每個朋友的姓名都打印出來。 names = ["Tom", "Bob", "Jack"] for i in names: print(i) 3-2 問候語: 繼續使用練習