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

高度複雜的系統

在科技領域, 工作在一個或多個超級複雜的系統結合起來的環境中, 可能會出現的極高的災難性的風險相伴而生. 比如2015年的紐約證券交易所曾經暫停交易218分鐘.

全世界最繁忙的交易系統停止的218分鐘，每秒鐘都是巨大的損失，雖然不瞭解紐約證券交易所的系統是如何運作的，但是能夠支援全世界最龐大的證券業務運營的系統怎麼來說也都應該是行業翹楚，其實類似的情況並不罕見，巨型系統的複雜性已經遠遠超出了我們的想象，而且一旦發生問題，則將會是災難性的。

製造業經驗學習

而在製造業領域，很多時候在嚴重問題可能會發生的剛開始的時候，很多現象都會被檢測到，更早發現，更早對應，成本更低，速度更快，代價更低，這是我們從製造業經驗中所學到的。而且我們也將會應用到DevOps的實踐之中，問題的發現和反饋的迴路非常重要，在反饋原則的實踐中，更重要的是我們將會將每次問題發生都視作一次機會，一次從中學習的機會，而不是責備和懲罰。當然這是需要前提的，只有我們確保和確信我們的系統運作是安全的，這些問題的發生不會導致災難性的結果為前提的。

更加安全的複雜系統

複雜系統往往有高度耦合的各功能元件，難以簡單解釋的各種系統行為，以及與無數外接系統的千絲萬縷的關聯，導致很難對其可能的失敗進行精確的原因預測。

為什麼像核反應堆這樣的系統如此複雜，其可能出現的故障難道不能準確預測麼？Charles Perrow博士通過對三裡島危機進行研究發現：準確預測在各種情況下的反應堆的可能的反應以及如何會發生故障幾乎近乎不可能。當某一個部分的問題正在發生的時候，很難將其和其他部分分開，快速的變化使得結果變得無比複雜，而預測也變得近乎不可能。
而Sidney Dekker博士通過研究也發現了複雜系統的另外一個特性，兩次同樣的執行並不能一定通向一致的結果。
在複雜系統中，問題的發生既然是不可避免的， 我們所能做的則是撞見一種安全的機制，就像製造業中所做到的那樣，問題能夠快速的被檢測到，遠遠在其出現災難性後果之前，已經開始著手對應，明察秋毫，防微杜漸，而不是病入膏肓之後下虎狼之藥。而這樣的機制使得我們對問題的出現不再畏懼，同時文化的改變才有可能的土壤。

檢測問題發生

在一個更加安全的系統中，新的想法/功能等都需要經常地測試以確保其正確性。我們的目標就是多快好省地建立和更新系統。我們驗證出越多的問題，就意味著能更快的修復問題/增強擴充套件性/提高速度，同時獲得更快的學習和創新能力。
而這些則可通過建立反饋迴路來幫組達成。Peter Senge博士在他的”The Fifth Discipline”一書中這樣寫道：學習型的組織會把反饋迴路作為學習型組織以及系統思考方式的重要組成部分。
在製造業中，缺少有效的反饋經常會導致質量和安全問題的發生。在製造業中這樣的例子比比皆是。而在高效的製造企業中，在整個價值鏈中，快速高頻度高質量的資訊流動隨處可見，每個工序都被測量和監視，任何故障或者可能引起問題的偏離都會很快的被發現和糾正。而正是這些奠定了建立高質量的安全的系統，從中進行持續學習和改進的基礎要件。
而在軟體開發領域，這種在製造業中習以為常的反饋卻在很長時間內不是那樣隨處可得。比如在傳統的瀑布型軟體開發中，往往是設計和編碼全部完成之後，才能從測試階段的關於質量的反饋，甚至於一部分只有在釋出之後才得到反饋，而這一切都已經太晚，而且往往影響也已經非常的嚴重。而我們所期待的則是在軟體開發領域也能建立和製造領域中一樣的機制為我們保駕護航。
反饋迴路不僅能夠快速檢測問題和輔助故障恢復，通過這種機制進行持續學習還能使得在將來再次出現這種問題的時候如何進行預防。這種持續性的學習最終將推動持續學習和成長的創新型企業文化的落地生根。

解決問題 持續學習

當然，僅僅通過反饋迴路檢測到預期外的問題發生還遠遠不夠，我們需要解決這些問題。讓我們再次將目光投到製造業是如何做的，當問題發生的時候，團隊的Leader將會立即被通知到而其開始立即著手去解決問題，當這個問題在一個一定的時間比如55秒沒有的得到解決，整條生產線會停下來而整個組織去一同幫助，直到問題得到解決。區別於帶病作業或者安排一個“等閒下來了就立即去對應”的日程，立即聚集起來去解決這個問題，有需要的時候甚至會停下來整個生產線。
看起來很簡單，但是往往在最初的階段需要決心和勇氣。在鳳凰專案裡面曾經將部署凍結，其實也是類似於製造業的做法的學習，不讓問題繼續擴散，在問題的初期進行對應是最好的選擇之一。一旦發現反應堆已經開始溶化了，這時候去對應已經為時已晚。所以只有通過在整個流動的過程中儘可能早地發現小的問題之後立即聚集起來進行解決，我們才有可能建立一個安全的機制保證在災難性的後果發生之前能夠有足夠時間去對應和解決。

質量控制 人人有責

大型複雜系統中，問題的發生是不可避免的，隨著問題的不斷髮生，監視和審批的流程可能會增加的越來越多。質量控制中很多效率低下的情況都在發生，比如：

• 要求其他的團隊去完成單調重複/容易出錯的大量手工作業
• 要求不在一線的繁忙的某人去作決定是否應該做某個操作，而此人可能完全不懂相關技術，而且上下文有可能也沒有說清楚。或者是大量的內容，等到看的時候已經可能發生了變化。
• 扔出一些需要首先對應的問題給某些團隊然後開始等待。

而事實上，我們需要在價值鏈中的每個人在日常的工作當中去發現和對應這些問題，質量控制，人人有責。通過這種方式，質量和安全的責任的控制，不再是來自上層的審批，而是變成了現場的每個人在持續學習和成長的同時，發現反饋迴路中的問題，參照精益的經驗進行聚集和立即對應。當然還是有很多最佳實踐可以幫助我們在這個過程中做的更好。比如，通過Peer Review確保結果的正確性， 通過自動化使得原本容易出錯的枯燥重複的大量作業變得安全高效。
總的來說，我們通過強化整體質量是每個人的責任這一意識，區別於傳統方式下的每個人只確認自己的單獨的責任，更好的實現組織的目標。
另外，這種整體化的意識也會需要反饋的及時和迅速。就像Gary Gruver 觀察到的那樣：“當有人抱怨開發人員在六個月之前做錯的事情的時候，開發人員也很難從中學到任何東西–而這個正是為什麼我們需要反饋要儘可能的快，問題發生後的幾分鐘之內，而不是幾個月後”

非功能要素的優化

在整個價值流中，那些非功能性的需求同樣非常重要。在一定程度上，後續的問題很多都是由於這些非功能性的要素的設計重視不夠才引起的。比如：架構/效能/穩定性/可測性/配置/安全要素等等，由於這些要素沒有像功能性要素那樣給與了足夠重視所引起的問題也屢見不鮮。給與非功能性要素足夠重視，不斷進行優化，也是非常重要的。

總結

通過建立快速反饋對於達成穩定/可靠/安全的系統至關重要。通過快速反饋迴路，在問題發生的時候，我們能第一時間看到，自然能夠立即行動起來去解決問題，從中學習到新的知識，每個人都參與到質量的控制中，無論是功能性要素還是非功能性要素都給與足夠重視，不斷優化，從而使得整個系統更加安全和穩定。

Referrence