我們還記得《快樂大本營》中經典遊戲----快樂傳真嗎？遊戲規則是：很多人站一排，只有第乙個人才看到最準確的資訊，用東西隔著，戴耳機，一一將從前乙個人獲得的資訊傳遞下去，最後乙個人說出推測的資訊。但是往往最後乙個人說出的答案五花八門，基本上和第乙個人說的內容完全不搭邊！
回憶這個遊戲主要是為了告訴大家，資訊在一連串的傳遞過程中是很容易受損的。在與訊息源的間接交流過程中，與資訊有關的細節和事實容易被稀釋，從而導致資訊的內容自然而然地（有時則是有意）產生或多或少的改變。
最開始傳遞的訊息在傳回訊息源頭時往往變得面目全非。很明顯，訊息傳遞經過的人越多，迴圈時間越長，產生的錯誤必然就越多。
通過對這一活動的觀察，我們還可以得到乙個非常明顯但也非常重要的結論：訊息重新傳回源頭的用時有極大差異，且隨著資訊傳遞的必經之路上加入的新節點越多，所用的時間也就越長。
總之，資料錯誤的出現數量和頻率與資料傳遞的路徑長度和傳遞時長成正比。
要如何才能更好的運用反饋環路推動 it 運維團隊進步？以下為四點建議。
不斷提高
agile 和 devops 原則，即旨在採用敏捷軟體開發的方法，促進軟體交付和基礎設施變更軟體開發人員和 it 運維技術人員之間的合作和溝通的原則，讓我們明白，在交流和執行程序中消除中間節點是在現代軟體交付業務取得成功的關鍵元素。縮短反饋環路不僅可以提高應對速度，還可以降低資料出錯概率。
隨著新流程和新工具的湧現與完善，目前的最佳實踐也很快會過時。隨著科技和創意的不斷進步，推動其進步的因素也逐漸浮出水面，這些因素有正面的也有負面的。其中有很多都是試執行和錯誤導致的結果。正視反饋環路可以讓我們從這些因素中吸取經驗，正確應對問題，不斷學習和進步，而這反過來又促進我們不斷創新我們的產品和服務。
棄用瀑布流式開發方式
瀑布流式規劃和交付方法極大地拉長了軟體發布週期，因此我們不再使用。競爭和創新需求日益增加，每個開發階段都需要縮短週期。瀑布流式方法的目標是布置好一切，使計畫、範圍和資源都可以在前期決定。
可惜的是，這種方法意味著公司不能迅速響應需求。當客戶的需求或市場形勢發生改變時，it 團隊無法收到反饋並立即把它運用到新的抉擇中。只能捨棄大量的計畫，從頭開始做起，不然無法進行自我矯正。
通過系統思考視角考慮人工反饋
反饋並不單單在系統中產生。同事、合作方和客戶之間的語言及肢體交流也是反饋的另一些形式。通過系統視角檢視這些反饋是一種更為精確的評估方式。後退一步檢查收到的反饋和資料，我們會理解得更加透徹。這一方法的獨有特點是幫我們過濾掉了一些不必要的判斷，同時也提高了可靠性。
為達到這一目的，需要回答三大問題：
給予者和接受者之間的差異是否會給反饋帶來摩擦？
當反饋與常用系統聯絡到一起時，反饋會與給予者和接受者之間的不同角色有聯絡麼？
程序、政策、實體環境或系統裡的其他因素會增加反饋的問題麼？
以這種方式檢查反饋可以深入了解人員輸入輸出的資訊流。通過系統思考（systems thinking）模式審視反饋，可以尋求更多方法、更精確地了解反饋環路，確認導致失敗或成功的相關因素。不帶任何感**彩，以最真實的形式去檢閱資料，從而進一步提高我們求知能力和理解能力，最終積累經驗。
正是因為這些想法，才會有那麼多高效的 it 團隊進行事後免責剖析。以系統思考的模式了解故障期間發生的事件可以帶來更高的回報，更別說可能由此實現的巨大發展。
學習與創新
故障的不可避免性有著獨有魅力，它讓我們無需在系統中再次設定故障。正因如此，現在我們設計時會考慮故障現象，優化減少修復的時間，建立反饋迴路，以免漫無目的地尋找系統崩潰的根源。從這方面說，我們可以用不同的思維方式引導我們對後續措施的決定和選擇，來提高系統的可靠性和彈性。伴隨所有這些嘗試而來的，是乙個由高效的 it 團隊構建、維護和不斷改善的高可用系統。
修復已成為我們的目標，而非干預或解除問題。使我們搖擺不定的反饋環路正是我們軌跡的引導者。我們利用失敗的機會去尋找盡可能多的創新發展領域，而不是研究**錯了。完全擯棄**，取而代之的是「為失敗而建」的新理念，反過來讓我們在自己的程序、工具甚至是自己提供的服務中得到提高和進步。
通過對反饋（包括故障在內）的不斷處理和響應，我們可以利用與先前結果相關的資訊來指導以後的工作。我們可以充分利用各種機會，像交通工具一樣，學著進入新軌道並沿途修正路線，而非推測以後的條件。
例項例證
以國內首個 saas 雲告警平台 onealert 的例項為例，本人對他們在利用反饋環路來推動 it 運維團隊進步所做的努力概括了一部分：
自動化團隊事件工作流，根據分派策略的不同，自動指派給適當的團隊；
自動化運營團隊事件分析功能，先是通過事件聚合將事件分析功能半自動化，現在通過機器學習，基本實現事件關聯演算法；
增加 top 分析、應用、團隊和成員分析，讓反饋更直白簡單。
前兩點為主要是為縮短反饋環路的路徑長度和傳遞時長，減少人為造成的時間和真實性的損耗；第三點主要是從系統的角度考慮人工反饋，從而繼續學習和創新，用來指導以後的工作。補充一句：以上例項概括為本人基於使用了 onealert 後的一些體驗，有更多詳細功能，可以訪問官網，歡迎一起交流。
參考文章：loops on loops: how feedback enables improvement
本文** oneapm 官方部落格
Win CE如何去掉串列埠自動反饋資訊。
比如說，把開發板和pc連在一起，開啟pc上的串列埠軟體，再開啟開發板上 wince5.0系統 的串列埠軟體就會在pc上串列埠軟體上收到一些資訊，每當板子接收到資料時，pc上的串列埠軟體就會收到類似 sl getstatus 這樣的資訊。方法 開啟wince500 platform dk2440 ke...
程式崩潰後如何更好的反饋資訊
我們使用windows都知道，整個windows和微軟提供的應用軟體的穩定性和崩潰後的體驗是逐步提公升的。在大牛的作品 軟體除錯 中有描述。在windows下，軟體出錯，常見的報告手段 1 事件日誌 這裡記錄了很多關鍵的錯誤資訊 2 崩潰報告 可以自動提交錯誤的資訊，或者手動提交，以不斷的改進軟體和...
XML 如何推動下一代資訊共享應用程式
xml 在對等資訊共享方案 包括網格計算 grid puting 即時訊息傳遞和 web 服務 中是乙個關鍵要素。本文 了在適應現有 xml 技術的基礎上為建立統一的 p2p 構造而進行的最前沿的工作。將一台聯網裝置中的資訊直接共享給另一台裝置根本不是乙個新想法。畢竟，象 laplink 這樣的遠端...