我們還記得《快樂(lè)大本營(yíng)》中經(jīng)典游戲----快樂(lè)傳真嗎？游戲規(guī)則是：很多人站一排，只有第一個(gè)人才看到最準(zhǔn)確的信息，用東西隔著，戴耳機(jī)，一一將從前一個(gè)人獲得的信息傳遞下去，最后一個(gè)人說(shuō)出推測(cè)的信息。但是往往最后一個(gè)人說(shuō)出的答案五花八門(mén)，基本上和第一個(gè)人說(shuō)的內(nèi)容完全不搭邊！

論反饋信息如何推動(dòng) IT 運(yùn)維團(tuán)隊(duì)進(jìn)步？

回憶這個(gè)游戲主要是為了告訴大家，信息在一連串的傳遞過(guò)程中是很容易受損的。在與消息源的間接交流過(guò)程中，與信息有關(guān)的細(xì)節(jié)和事實(shí)容易被稀釋?zhuān)瑥亩鴮?dǎo)致信息的內(nèi)容自然而然地（有時(shí)則是有意）產(chǎn)生或多或少的改變。

最開(kāi)始傳遞的消息在傳回消息源頭時(shí)往往變得面目全非。很明顯，消息傳遞經(jīng)過(guò)的人越多，循環(huán)時(shí)間越長(zhǎng)，產(chǎn)生的錯(cuò)誤必然就越多。

通過(guò)對(duì)這一活動(dòng)的觀察，我們還可以得到一個(gè)非常明顯但也非常重要的結(jié)論：消息重新傳回源頭的用時(shí)有極大差異，且隨著信息傳遞的必經(jīng)之路上加入的新節(jié)點(diǎn)越多，所用的時(shí)間也就越長(zhǎng)。

總之，數(shù)據(jù)錯(cuò)誤的出現(xiàn)數(shù)量和頻率與數(shù)據(jù)傳遞的路徑長(zhǎng)度和傳遞時(shí)長(zhǎng)成正比。

要如何才能更好的運(yùn)用反饋環(huán)路推動(dòng) IT 運(yùn)維團(tuán)隊(duì)進(jìn)步？以下為四點(diǎn)建議。

不斷提高

Agile 和 DevOps 原則，即旨在采用敏捷軟件開(kāi)發(fā)的方法，促進(jìn)軟件交付和基礎(chǔ)設(shè)施變更軟件開(kāi)發(fā)人員和 IT 運(yùn)維技術(shù)人員之間的合作和溝通的原則，讓我們明白，在交流和執(zhí)行進(jìn)程中消除中間節(jié)點(diǎn)是在現(xiàn)代軟件交付業(yè)務(wù)取得成功的關(guān)鍵元素。縮短反饋環(huán)路不僅可以提高應(yīng)對(duì)速度，還可以降低數(shù)據(jù)出錯(cuò)概率。

要想了解我們做的任何抉擇是否可以達(dá)到預(yù)期的效果，縮短反饋時(shí)間和減少中間步驟便是最高效、最徹底的方法。有競(jìng)爭(zhēng)優(yōu)勢(shì)的公司都深知縮短反饋回路的秘訣。他們不僅在 IT 團(tuán)隊(duì)里采用 Agile 原則并推行有效的 DevOps 實(shí)踐，還將其貫徹到整個(gè)公司。這也是為了不斷提高而持續(xù)付出的努力。

隨著新流程和新工具的涌現(xiàn)與完善，目前的最佳實(shí)踐也很快會(huì)過(guò)時(shí)。隨著科技和創(chuàng)意的不斷進(jìn)步，推動(dòng)其進(jìn)步的因素也逐漸浮出水面，這些因素有正面的也有負(fù)面的。其中有很多都是試運(yùn)行和錯(cuò)誤導(dǎo)致的結(jié)果。正視反饋環(huán)路可以讓我們從這些因素中吸取經(jīng)驗(yàn)，正確應(yīng)對(duì)問(wèn)題，不斷學(xué)習(xí)和進(jìn)步，而這反過(guò)來(lái)又促進(jìn)我們不斷創(chuàng)新我們的產(chǎn)品和服務(wù)。

棄用瀑布流式開(kāi)發(fā)方式

瀑布流式規(guī)劃和交付方法極大地拉長(zhǎng)了軟件發(fā)布周期，因此我們不再使用。競(jìng)爭(zhēng)和創(chuàng)新需求日益增加，每個(gè)開(kāi)發(fā)階段都需要縮短周期。瀑布流式方法的目標(biāo)是布置好一切，使計(jì)劃、范圍和資源都可以在前期決定。

可惜的是，這種方法意味著公司不能迅速響應(yīng)需求。當(dāng)客戶的需求或市場(chǎng)形勢(shì)發(fā)生改變時(shí)，IT 團(tuán)隊(duì)無(wú)法收到反饋并立即把它運(yùn)用到新的抉擇中。只能舍棄大量的計(jì)劃，從頭開(kāi)始做起，不然無(wú)法進(jìn)行自我矯正。

通過(guò)系統(tǒng)思考視角考慮人工反饋

反饋并不單單在系統(tǒng)中產(chǎn)生。同事、合作方和客戶之間的語(yǔ)言及肢體交流也是反饋的另一些形式。通過(guò)系統(tǒng)視角查看這些反饋是一種更為精確的評(píng)估方式。后退一步檢查收到的反饋和數(shù)據(jù)，我們會(huì)理解得更加透徹。這一方法的獨(dú)有特點(diǎn)是幫我們過(guò)濾掉了一些不必要的判斷，同時(shí)也提高了可靠性。

為達(dá)到這一目的，需要回答三大問(wèn)題：

1. 給予者和接受者之間的差異是否會(huì)給反饋帶來(lái)摩擦？
2. 當(dāng)反饋與常用系統(tǒng)聯(lián)系到一起時(shí)，反饋會(huì)與給予者和接受者之間的不同角色有聯(lián)系么？
3. 進(jìn)程、政策、實(shí)體環(huán)境或系統(tǒng)里的其他因素會(huì)增加反饋的問(wèn)題么？

以這種方式檢查反饋可以深入了解人員輸入輸出的信息流。通過(guò)系統(tǒng)思考（Systems Thinking）模式審視反饋，可以尋求更多方法、更精確地了解反饋環(huán)路，確認(rèn)導(dǎo)致失敗或成功的相關(guān)因素。不帶任何感情色彩，以最真實(shí)的形式去檢閱數(shù)據(jù)，從而進(jìn)一步提高我們求知能力和理解能力，最終積累經(jīng)驗(yàn)。

正是因?yàn)檫@些想法，才會(huì)有那么多高效的 IT 團(tuán)隊(duì)進(jìn)行事后免責(zé)剖析。以系統(tǒng)思考的模式了解故障期間發(fā)生的事件可以帶來(lái)更高的回報(bào)，更別說(shuō)可能由此實(shí)現(xiàn)的巨大發(fā)展。

學(xué)習(xí)與創(chuàng)新

故障的不可避免性有著獨(dú)有魅力，它讓我們無(wú)需在系統(tǒng)中再次設(shè)置故障。正因如此，現(xiàn)在我們?cè)O(shè)計(jì)時(shí)會(huì)考慮故障現(xiàn)象，優(yōu)化減少修復(fù)的時(shí)間，建立反饋回路，以免漫無(wú)目的地尋找系統(tǒng)崩潰的根源。從這方面說(shuō)，我們可以用不同的思維方式引導(dǎo)我們對(duì)后續(xù)措施的決定和選擇，來(lái)提高系統(tǒng)的可靠性和彈性。伴隨所有這些嘗試而來(lái)的，是一個(gè)由高效的 IT 團(tuán)隊(duì)構(gòu)建、維護(hù)和不斷改善的高可用系統(tǒng)。

修復(fù)已成為我們的目標(biāo)，而非干預(yù)或解除問(wèn)題。使我們搖擺不定的反饋環(huán)路正是我們軌跡的引導(dǎo)者。我們利用失敗的機(jī)會(huì)去尋找盡可能多的創(chuàng)新發(fā)展領(lǐng)域，而不是研究哪里錯(cuò)了。完全擯棄預(yù)測(cè)，取而代之的是「為失敗而建」的新理念，反過(guò)來(lái)讓我們?cè)谧约旱倪M(jìn)程、工具甚至是自己提供的服務(wù)中得到提高和進(jìn)步。

通過(guò)對(duì)反饋（包括故障在內(nèi)）的不斷處理和響應(yīng)，我們可以利用與先前結(jié)果相關(guān)的信息來(lái)指導(dǎo)以后的工作。我們可以充分利用各種機(jī)會(huì)，像交通工具一樣，學(xué)著進(jìn)入新軌道并沿途修正路線，而非推測(cè)以后的條件。

實(shí)例例證

以國(guó)內(nèi)首個(gè) SaaS 云告警平臺(tái) OneAlert 的實(shí)例為例，本人對(duì)他們?cè)诶梅答伃h(huán)路來(lái)推動(dòng) IT 運(yùn)維團(tuán)隊(duì)進(jìn)步所做的努力概括了一部分：

1. 自動(dòng)化團(tuán)隊(duì)事件工作流，根據(jù)分派策略的不同，自動(dòng)指派給適當(dāng)?shù)膱F(tuán)隊(duì)；
2. 自動(dòng)化運(yùn)營(yíng)團(tuán)隊(duì)事件分析功能，先是通過(guò)事件聚合將事件分析功能半自動(dòng)化，現(xiàn)在通過(guò)機(jī)器學(xué)習(xí)，基本實(shí)現(xiàn)事件關(guān)聯(lián)算法；
3. 增加 Top 分析、應(yīng)用、團(tuán)隊(duì)和成員分析，讓反饋更直白簡(jiǎn)單。

參考文章：Loops On Loops: How Feedback Enables Improvement

本文轉(zhuǎn)自 OneAPM 官方博客