作者介紹

黃博文

ThoughtWorks 首席諮詢顧問

個人簡介：ThoughtWorks 首席諮詢師，擔任過開發、測試、運維、技術經理等角色，在國內外多家大型企業做過技術教練以及技術諮詢，熟悉敏捷流程。目前專注於DevOps技術及雲端架構，在搭建持續整合及部署平臺、自動化構建基礎設施、虛擬化環境、雲端運維等方面擁有豐富的經驗。譯作包括《C#多執行緒程式設計實戰》、《基礎設施即程式碼》等。

前言

本文根據DevOpsDays北京站演講記錄整理而成，著重介紹 DevOps 在傳統金融組織中的落地實踐經驗。

今天我給大家帶來的演講話題是傳統金融組織DevOps落地實踐。

我平常喜歡寫程式碼，喜歡把中間的思考過程寫成文章，我也喜歡研讀國內外的優秀書籍，再翻譯成中文，前後翻譯五六本書。

業餘時間我也是一個馬拉松愛好者，以前跑42公里我都覺得了不起，但是去年開始嘗試更長的距離，比如五十公里一百公里等。剛才看到還有一個愛好者，也是倍感欣慰。

背景介紹

我們先對這家金融組織進行一個簡單的背景介紹，這家金融組織它是本土最大的金融資產集團，總資產1000億美元，房地產行業市場份額做到全國前三，他們國家每一百個人中至少就有一個人買過他們的保險產品，這家集團旗下擁有銀行、一般保險壽險等不限，市場上二十多個品牌。

因為隨著近幾年業務的發展，他不斷的收購同業的公司累計起來的，由於它是一個金融組織，所以這就說明它本身不具備網際網路基因。所以他們的組織體系可以分為兩個部門，一個是業務部門，對接前面的消費者。第二個就是ID務部門，在背後為業務進行支撐。

我今天分享的DevOps落地實踐主要是分享IT部門如何使顯得。今天早上我相信很多人已經聽了我們的其他演講，在講DevOpsleave也就是DevOps可以把業務領域涵蓋進去的，當然這個業務不在我這次分享之內。

那年，它的困境

09年這家巨無霸的企業面臨各種各樣的問題，內憂外患，外部來說它是處於開放性的金融市場，他們的法律比較完備，市場競爭非常白熱化，不僅要面臨他們國內的保險行業銀行行業的競爭，還要隨時面臨國外資本的入侵。

另外他們的產品創新法缺乏新的業務增長點，比如09年他們的線上銷售保險系統其他的都不支援，任何的端點都沒有他們的產品。從內部來說，由於他們在過去十多年間收購了很多家公司，就導致了他們的組織機構非常的效率低下。

舉個例子，做賣保險大家可能很多人都聽說過life400，像這樣類似的系統在他們公司內部多達十幾個，也就是所有的保單都分佈在這十幾個當中。內部還存在問題就是人員增長遇到瓶頸，人才流失嚴重，人才流失以後去到他們的競爭公司裡了。

轉型之路

所以從06年開始，他們其實已經啟動了敏捷轉型，整個軟性的時間也是非常長的，從06到13年只是完成一個階段，這裡並不是說2013年以後說明敏捷轉型成功，其實敏捷倡導持續改進，所以他們一直在改進當中。

那麼在這麼多年中，他們的敏捷轉型主要是進行了三大部分的改進。

• 第一部分就是組織結構調整
  從這裡我們就可以看到敏捷改進其實是需要自上而下的，因為我們通常說屁股決定腦袋。組織結構調整包括企業統一化、組織統一化、運營合一化，以前我有十幾個業務線，我們就要進行一些裁減合併。
• 第二部分就是遺留系統優化
  我們根據抗非定律來說肯定會對IT系統進行調整，方式就是簡化我們後臺系統，比如說我們後臺有個客戶管理關係系統，當時他們客戶關係管理系統就有七八個，隨著遺留系統優化以後最後只縮減成了一個。還有他們的理賠系統也是，也由七八個縮減至一個。

  另外一個很重要的IT改進就是它的統一數字渠道，也就是保險的售賣一般分為兩個途徑，一個途徑就是通過各種各樣的代理，通過他們的IT系統以及電話系統進行售賣。

  還有另一種方式就是線上售賣，他們面臨很多很多的品牌，很多的品牌再加上很多的資料系統組合起來對於IT部門的壓力是非常大的，系統簡化以後他們實現了一套規則，把他們所有的系統全部外部化。

  通過外部的方式就可以使用，把他們的樣式也給歸一。這樣既可以增加消費人員對於他們品牌的認同感，另一方面也簡化了IT部門的開發工作量。

• 第三部分就是打造持續交付。
  前面我把基礎的差不多了，可以放開手腳幹了，比如以前沒有收益銀行現在就可以做一個。比如我們要擁抱最新技術，12年的時候我們就有一個網站做了一個系統，不斷的往裡面存錢，看到的畫面是不一樣的。

  到了13年我們就逐步想打造這樣的持續交付流水線，13年很多功能都已經實現了。這個圖我們可以看到我們核心的輸入點是我們的白馬控制庫，我們會把我們所有的程式碼不放在裡面，包括我們的應用程式碼還有測試程式碼包括構建指令碼以及相應的部署指令碼和環境準備指令碼，全部放在我們的版本控制力。

產品團隊交付流水線

我們再建立我們的持續整合服務，通過持續整合服務調動我們的構建指令碼對我們的程式碼建立准入機制，把它全放在我的產出管理裡。

我們通過一些工具實現我們的部署流水線，並在我們的JCK上面展示出來，通過一鍵式按紐就可以把你的構建產出部署到不同的環境，比如我們的int之類的測試環境。也分為A環境和B環境。

當我們把我們的構建產出部署到環境以後並不是說流水線就完成了，我們的區域交付流水線是一個閉環，我們會在我們所有的環境加入相應的監控與告警機制還有一些使用者的度量分析，通過視覺化的儀表盤把這些資料展現出來。

比如我們在每一abb內建了短路應用，通過視覺化的儀表盤可以輕鬆的看到我們微服務每一應用的呼叫頻率是什麼，失敗率是什麼，時間是什麼，就可以把系統的可用性輕鬆的可視化出來。

大規模持續交付仍需要解決的問題

• 第一個問題，如下兼顧穩定和吞吐量
  ，傳統的運維流程比如釋出深比實踐支援等和方法手動操作和夜間部署已經越來越難以適應當今產品不斷縮短的變更週期，同時又要保障系統執行穩定性的要求。
• 第二個問題，如何建立關注業務和使用者價值的文化
  其實我們開發產品目的是什麼？目的是為了賺錢，那怎麼才能賺錢呢？

  肯定是要討使用者的歡心，但是其實大部分團隊裡面我們開發人員和運維人員是不知道使用者開不開心的，他可能知道使用者不開心，比如我伺服器宕機，使用者操作不良肯定不開心，但是使用者是不是滿意他是不知道的。

  特性發布後用戶的反饋抱怨和給業務實際帶來的收益反饋到業務和開發這個過程有大量的資訊丟失，速度太慢，難以真正對特性所帶來的價值進行驗證。

• 第三個問題，就是如何控制IT系統不斷增長的複雜性
  業務開發運維分段式交付模式前端不會充分地考慮堆砌的功能和設計決策給整個IT系統，導致IT運維成本越來越高，反過來導致長期的交付變得越來越困難。

一個典型的例子

這裡就舉一個非常典型的例子，也就是我一個開發團隊開發一個微服務的時候想申請一系列的機器，這些機器一部分用來做我的構建環境，一部分測試環境，一部分產品環境。

這上面可以看出在這個幾大步驟中，通過打造持續流水線已經實現了自動化，拿到我的機器以後就可以通過自動化佈置指令碼，輕鬆的把部署到中介軟體。

運維人員有能力以後再進行相應的伺服器的配置，不僅要配的東西非常多，要安裝作業系統配製IP、防火牆，配置好這些機器以後還要裝上執行所必要的中介軟體，比如shall。

什麼是DevOps？

在2013年的時候，這家組織的CEO和CTO參加了很多大會，和很多DevOps專家都有深刻的討論，他們討論以後覺得DevOps可能解決他們的問題，就是什麼是DevOps？左邊的這個圖今天早上演講中已經展現了，而右邊對DevOps的介紹是我從百科上摘抄出來的。

DevOps落地實踐

那麼在說DevOps的過程究竟這家金融組織怎麼做的？我大概總結了一下，分為四大部分，從13年開始直到現在。

• 第一部分是引入動態基礎設施。
• 第二步是調整IT部門的組織結構。
• 第三部分是採納基礎設施即程式碼的實踐。
• 最後一步是平臺化戰略。

第一步：引入動態基礎設施

那麼第一步我要引入動態基礎設施，是什麼意思？舉例子，你在建立資源的時候這個資源是指我們的執行所需要的資源，包括執行的機器、計算節點，所需要的附帶均衡器，它所需要的網路，所需要的IP，這些資源是可以通過多種方式建立的，你也可以使用HTP遠端呼叫的方式建立，也可以寫程式碼，通過引入一些SDK建立，這些資源你是隨時可以建立使用銷燬的。

其實它就是我們所說的雲端計算。大家有個疑問說我是金融組織，對資料的寶貴性要求比較嚴，你用公有云我們不放心，他們當時的CEO也有這樣的擔心，他們親自飛到美國和共有云的CEO進行了深度交流，交流以後他們發現其實這些都不是問題，我們可以把公有云當成我們的資料執行，我剛開始公有云作為一個數據中心，把一些不是很重要的系統放上去，來進行運作，不就可以了。其實我們發現數據放在公有云其實更加安全。

公有云徹底解放生產力

經過公有云的遷移以後，對Ops團隊來說我們減少了成本，可以減少85%的災備成本，其實這家金融組織有一些自己的收益衷心地但是大部分的都是租的，那些運維人員很多都是winer提供的，但是有了公有云以後你會使用它提供的服務替代。

另外一方面也可以減少自建收費中心的壓力，比如說每一個數據中心要各自維護各自的伺服器升級，以及我的資料庫備份的問題，其實公有云已經對最基本的運維問題提出了一系列的非常簡單的解決方案，也就是我運維再也不用考慮這些問題，我只要使用他們提供的就可以了。

對於開發人員的好處，第一個就是自服務機制，以前我記得有一段時間我剛加入一個團隊的時候，我說我要有一臺機器作為我的桌面，結果這個流程其實走了三週的時間，但是使用了公有云以後有一次我想建立一個虛擬桌面來進行驗證一些問題，我只用了短短的十分鐘就實現了。

這是因為我建立計算資源的時候我可以直接呼叫一些介面直接實現，中間不需要任何人的介入。帶來的另一個好處就是直接帶來了高可用的彈性伸縮，我們在設計產品的時候可以充分利用各種的資源。比如說我們之前一般的保險金融組織有一個計價模組，計價的時候我們需要把計價所有的日誌全部記錄下來，而這個日誌每天產生的資料量大概是100G左右。

我們為了解決這個問題，當時傷透了腦筋，使用各種各樣的磁碟陣列，不斷的擴容我們的磁碟儲存，想了很多方案，但是始終滿足不了需求，最後使用公有云以後問題非常簡單了。

我們直接使用他們提供的高可用的儲存技術輕鬆的把我們這些日誌全部儲存上去了。其實公有云的整個過程不是一蹴而就的，我們前後花了三年多的時間才把大部分的服務遷移到公有云上，只剩下無法在雲上執行的，還有一些核心的資料，比如客戶的資料，還是存在自己的資料中心。

公有云遷移策略

那麼在整個遷移的過程我們遵循一個原則是什麼？首先我們要設計我們的公有云架構，我們如果把公有云當做我們的資料中心我們公有云應該具備什麼樣的設定？

我們根據workspace建立業務線資源隔離，裡面又分為Non-prod和prod兩套環境，設計這樣的公有云架構以後我們就把現有的基礎設施個公有云進行對接，比如我們現有的這十幾個資料中心要和公有云對接，對接過程我們要考慮很多問題。

公有云裡的私有云

• 第一點，公有云本身的認證方式和企業現有SSO的整合
  我們企業都有自己的認證系統，我們不可能再在公有云設定一個認證系統，企業員工使用的時候在這兩條系統之間進行切換，這樣對企業使用者來說是不友好的，對於企業的運維來說也是比較麻煩的。

  那麼我們實現的方式就是根據公有云提供的介面實現了和企業現有SSO的整合，也就是你想要訪問某些資源你要申請一下就可以了，跟其他的資料中心資源一模一樣。

• 第二點，實現公有云與現有設施的直連
  比如我們的後端的某些資料庫是我們本地的資料中心的，我們前端的一些服務還是在我們的雲上的，那麼為了不影響效率，我們就建立這種直連機制。

  另外就是要實現公有云與基礎設施的VPN連線，實現以後公有云建立所有的資源IP地址都是我們內網地址，我在使用它的時候和我使用其他資料中心的這些資源方式都是一模一樣的，根本就不用進行任何切換。當然還有內部DNS服務的互通。

• 第三點，準備這些基礎設施以後我們就可以進行應用程式的遷移
  我們要遵循優先順序，我們就要先遷移技術風險低業務價值高的，我們買保險的時候有保險介紹的頁面，你是通過這些靜態頁面連結到購買系統和自服務系統的，對這樣的應用來說遷移的難度最小，但是帶來的價值最大。

  遷移時儘量不涉及對應用程式架構的變更，所有服務仍然屬於原有架構。我們談遷移很多人就非常激動，他說我終於可以把以前老舊的換掉了，我可以使用一些收費便宜的甚至免費的資料庫，但是如果你抱著這樣的想法那你在遷移中無疑增加了難度，所以我們把應用程式的變動放在最後一步的，再進行應用程式的互換。

  比如說我們把本地資料庫替換成資料庫服務，DES，然後我們本地的一些訊息佇列也替換成雲上的訊息佇列，甚至是我們把非生產環境的作業系統全部換成一些免費的發行版，進一步減少花銷。

我們是如何在公有云裡面保證我們對資料的安全性呢？

其實我們採用了安全機制，比如公有云裡面建立PC和私有云，所有的資源是不能直接暴露給外界的，在私有云我們又劃分了若干子網，每個子網可以是一個公開訪問的也可以是一個禁止公開的，在VPC和子網之間建立一個網際網路閘道器，所有的網際網路的都走的是我這個，在子網裡面我們又可以劃分不同的一些角色叢集，比如我是應用程式叢集，我資料庫叢集，我中間鍵叢集，這些中間鍵開啟相應的訪問許可權，把他們並不暴露給網際網路。

共有云遷移Matrix

這裡就是我們公有云遷移確定應用程式優先順序的Matrix，分為兩個維度，第一個橫向的維度是技術風險，縱向的就是業務價值，通過這樣的維度以後我們把每個應用程式放置在這樣的象限裡就可以選擇對應用程式進行遷移。

第二步：調整部門組織結構-建立自服務機制

第二步進行公有云的遷移我們也進行部門組織機構的調整，建立自服務機制，大家看到右邊這個圖大家都笑了，今天早上喬幫主他們都同時說過一個問題不應該有Dev團隊，就是你們自己要有而不是DevOps，我們為什麼要在這裡建立一個DevOpsteam，其實他講了一個轉型，而我們在做對這個金融組織進行DevOps轉型的時候我們覺得建立DevOps是一個轉型期，我們應該具備這樣的團隊，所以我們就組建了這樣的團隊。

事實證明它是收到非常好的效果。過去我們是中央運維團隊處理各方來的請求，這樣的特點就是我開發團隊要部署了，比如雙11之前我們要集中部署一大片服務，給運維團隊發，他們都忙不過來。

審批是運維團隊掌握生殺大全，我覺得你這個是不是通得過，我是等著你來。經過部門組織調整以後，我們就建立起了服務化的策略，也就是我基礎設施平臺和DevOps團隊提供自服務的機制，就跟你去ATM機取錢，你想取多少都可以。

對應在我們運維的時候，比如我開發人員想在生產環境某臺機器新增一個防火牆規則，以前是我發一個等待運維人員處理，那麼現在是我們有一個介面你可以在介面上直接操作，我們也提供了相應的直接通過程式碼發的方式完成這個變更，整個過程都是全自動的。

有人就問萬一我把惡意的IP地址加進去怎麼辦？是因為我們團隊變成了一個審查制，你做了變更以後我們會審查你的變更是不是合理，如果不合理我們就會進行後續的處理，如果合理的話那麼就被通過了。其實這樣就建立了信用機制，開發團隊要明白自己在幹什麼，運維團隊把責任移交給了開發團隊。

另一方面主動優化，今天下午聽了一些講師的分享，有個來自百度的運維專家說他們的團隊50%的時間是處理日常性事物，50%的時間是在做一些優化和改進，他們覺得是不夠的，因為谷歌團隊只有30%的時間來進行日常的運維70%時間用來創新，建立這種服務化審查式的機制以後，其實運維團隊很大程度解放了，就有時間來進行主動的優化。

DevOps團隊承上啟下

為什麼要建立DevOps團隊？因為我們想讓DevOps起到一個承上啟下的作用，就是既瞭解運維的難點又清楚產品團隊的痛點，人們服務都提供API或命令列介面，向產品團隊賦能，我們在談論DevOps文化的時候經常會提到一點，就是同理心，我開發人員覺得你把這個包部署到那個機器上執行起來是非常簡單的事情，你給我說要兩分鐘的時間。

為什麼？運維團隊說你的這個包有這個那個問題，為什麼不早點改？因為他們沒有建立同理心，沒有通知我運維團隊要進行一系列的操作才能真正的把這個運用程式執行起來。

運維團隊也不知道產品團隊很忙，要處理各種各樣的事情，對於運維合規性一方面自身理解的不到位，另一方面也是沒有時間，其實這些都是由於缺乏同理心的行為造成的。但是DevOps團隊這些人一部分來自運維團隊，一部分來自開發團隊，所以兩邊的痛點和難點他們都是清楚的。

團隊結構圖

條業務線，DevOps團隊我們有一個DevOps的部落，我們會有定期的活動，比如每個月進行一次活動，大家會分享一些知識和自己學到的東西，對遇到的問題也可以在這部落裡找到答案，並且推廣一些最佳實踐。這樣整個團隊就會以一個不斷前進的方式進行發展。

DevOps團隊工作職責

DevOps團隊職責分為四大塊。

• 第一塊是建立和維護持續交付生態圈
  也就是我展示持續交付的一個流水線情況，其實那個圖看起來簡單。但是實現過程就是非常難的，因為對一個大型的組織來說他們的應用場景應用程式產品形態是非常不同的，你要為每一種不同型別的應用程式建立起這樣的交付的生態環境還是需要很大量的工作量的。
• 第二塊就是實驗和實踐在災備方案和部署方案
  我想到了前段時間有一個運維工程師在凌晨很晚的時候在執行運維工作敲錯了一項命令，把資料庫刪了，結果DevOps號稱有五重災備機制，災難恢復的時候他發現五重全部失效，最後他們再一個非常老舊伺服器終於找到了資料庫很久之前的備份，恢復以後至少有幾千個資訊是永遠被丟掉了。

  那麼其實DevOps團隊來設計這樣的災備方案並且驗證這些方案，尤其是部署方案，比如說我們一直遵循我們想推廣的部署，如下實現0級部署，我們的團隊是需要進行學習的，需要進行研究的。

• 第三塊是提升生產力
  這裡有一案例，我使用了24小時可以付24小時的費用，在很多公司來說當我們員工下班以後我們的開發環境其實是沒有人在用的，我們就可以把它關閉。

  第二天上班之前再把這些激起來，他們就做了一個公寓，你在建立任何一臺結算節點的時候就會自動的打一標籤，這個標籤可以填上你希望它執行的時間，我們用另外一款工具會定時的觀察這些叢集的態勢地級市的關閉或開啟這些節點。

• 最後一塊，就是向開發人員賦能
  在這樣的團隊我們有各種各樣的角色，有業務分析師、運維人員等等，在這樣一個一個團隊我們如何保證團隊不同的角色技能達到要求，那麼我們可以通過DevOps團隊，由他們向這些產品團隊進行一系列的培訓，促使產品團隊的技能達到快速的提升。

  第三步：建立基礎設施即程式碼的實踐

基礎設施即程式碼是一種釋永信的技術來管理動態基礎設施的方式，把基礎設施、工具和服務以及對基礎設施的管理本身作為軟體系統，採納軟體工程實踐以結構化的安全的方式管理對系統的變更。

基礎設施即程式碼-使用DSL描述環境

我們如何採納基礎設施及程式碼？最觀點的一點就是用領域特定語言描述環境，在這裡在座的各位有沒有人喜歡函數語言程式設計？為什麼很多人喜歡？也就是我想要什麼直接寫出來，DSL也是要達到這個目的，也就是我想要一個機器，即席裡面要具備這樣的東西，你寫出來就可以了。

DevOps團隊可以提供這樣的DSL模板，傳統團隊使用這模板一演示的建立CI、SYS、UAT等環境，比如我的磁碟容量需要多少，需要預裝哪些軟體，你只需要寫一個檔案就可以了。環境自動與CD的流水線整合起來，生成持續交付流水線。

我點一個按紐就可以跟剛才那位老師講的程式碼受限一樣，我在建立正環境過程不需要任何人介入，只不過它已經進入Docker來建立環境和測試環境階段，我們目前做到的可以通過程式碼了建立真正的一些例項。

基礎設施即程式碼-一切都納入版本管理

所以我們產品團隊把產品程式碼測試程式碼構建指令碼和資料庫變更指令碼和自動化的部署指令碼都放在版本管理的時候，又可以有環境定義指令碼，我拿到了一個應用程式的程式碼倉以後我想執行它，我只需要調一些命名來呼叫裡面的環境定義指令碼就可以了，再部署指令碼就可以部署進去，所以中間不用問任何人，不需要問應用程式都需要哪些依賴，因為都是在一庫裡面。

第四步：建立平臺化服務

最後一步就是建立平臺化服務，也就是我們要真正的實現持續交付，必須要把生態圈建立起來，其實是非常重要的，比如我在大型公司做技術資訊和DevOps資訊的時候我發現開發人員的痛苦就在於我真想學習新技術，我在公司裡是沒法學的，不是有人阻止你。

我在產品開發過程我要使用一些日誌服務，在我的磁碟上我看這些日誌的時候需要登入一臺機器，這些事情都說明了你的持續交付生態圈沒有建立起來，我要建立起第三方架包的代理和對APM代理，我能不能方便的讓開發人員輕鬆的獲取這些。

另一方面我在開發軟體的過程能不能很方便的使用各種各樣的工具來把我們的一些運維工作提前的整合起來，比如日誌管理平臺等等，能不能方便的和產品整合起來，這是非常關鍵的。

所以說這就需要DevOps團隊來統一提供一些平臺，讓產品團隊自助的使用。金融組織在實現這些平臺的時候我們給他建議不要自己研發，你是金融行業，你不是做工具的，做工具和產品是不一樣的，你最好買一些商用的軟體或者使用一些開源性的軟體使用。

有些人有就說了我的需求不一樣，我覺得這些工具滿足不了我的需求，我就問他你的需求為什麼不一樣你沒有仔細想過，這些好多人都採用了，為什麼到你這玩不轉了，是不是你的需求過於奇葩？是不是你的需求就不是你要解決的問題所在。

經過這樣的反思以後我們就可以發現我們在採納一款工具的時候就會更容易。這裡列出了統一日誌管理平臺，DevOps平臺需要提供相應的日誌管理介面，高可用的日誌查詢引擎與企業內部其他系統整合。

產品團隊需要建立起符合規範的日誌，還有接入日誌管理平臺和定製日誌管理需求，我們團隊要建立中心式排程平臺以及提供構建包排程中心，提供依賴庫管理，他們只需要建立Slave接入排程平臺，配置繼續交付管道。DevOps團隊需要提供統一系統級監控平臺，通用性應用層監控和運營分析提供等。

建立平臺化服務-準則

建立平臺化服務的準則第一個是要提供最專業級出色的服務，也就是DevOps團隊不要提供自己研發的不好的專案，第二個就是要契合開發團隊的痛點，你要抓住關鍵的瓶頸，而不是自己想一些功能對開發團隊帶來幫助，最後就是優化再優化，比如我的日誌搜尋平臺，開發人員覺得很慢，你就得優化。

總結-DevOps落地的核心要素

最後總結我們DevOps落地的核心要素主要三條。

• 第一個，就是建立自服務的審查式的機制；
• 第二個，就是Automation，一切自動化；
• 第三個，就是Sharing，讓每個人都具備相應的技能；

DevOps並不是銀彈

最後DevOps並不是銀彈，在座的各位來到這個會上一定抱著各種各樣的問題來的，但是DevOps真的不能解決你的所有問題，但是考慮DevOps落地的時候我們可以從五個方面著手，這是優先順序，人、準則、時間、產品、流程。

因為一百多年前工業時代，其實他們更注重流程，那個時候產品比較匱乏，使用者對產品的質量要求不高，最後才是人，因為你只要機械的進行操作就可以了。但是在如今我們已經進入了知識經濟的時代，我們需要人來創造知識進行創新，我們創新的過程也要遵循一定的準則，就不能跑偏了。

第三個就是實踐，也就是我要做的事情，我們要不斷的優化改進，第四個是產品，我們IT部門做事情的時候要以對待產品的態度來做事情，而不是以對待專案來做。

這個是什麼意思？如果我是以做產品的態度來做事情的話，那麼我自然會考慮我的運維問題，但是以做專案的方式來做，做完以後扔給運維團隊就可以了地這樣質量怎麼提高？

最後才是流程，就像早上我分享的時候有一個講師說他們在谷歌是沒有流程的，因為流程固化到工具裡面了，所以我們的流程是可以變的，只要我們建立一致的目標。

文章來自微信公眾號：高效運維