我們還記得《快樂大本營》中經(jīng)典游戲----快樂傳真嗎？游戲規(guī)則是：很多人站一排，只有第一個(gè)人才看到最準(zhǔn)確的信息，用東西隔著，戴耳機(jī)，一一將從前一個(gè)人獲得的信息傳遞下去，最后一個(gè)人說出推測的信息。但是往往最后一個(gè)人說出的答案五花八門，基本上和第一個(gè)人說的內(nèi)容完全不搭邊！
回憶這個(gè)游戲主要是為了告訴大家，信息在一連串的傳遞過程中是很容易受損的。在與消息源的間接交流過程中，與信息有關(guān)的細(xì)節(jié)和事實(shí)容易被稀釋，從而導(dǎo)致信息的內(nèi)容自然而然地（有時(shí)則是有意）產(chǎn)生或多或少的改變。
最開始傳遞的消息在傳回消息源頭時(shí)往往變得面目全非。很明顯，消息傳遞經(jīng)過的人越多，循環(huán)時(shí)間越長，產(chǎn)生的錯誤必然就越多。
通過對這一活動的觀察，我們還可以得到一個(gè)非常明顯但也非常重要的結(jié)論：消息重新傳回源頭的用時(shí)有極大差異，且隨著信息傳遞的必經(jīng)之路上加入的新節(jié)點(diǎn)越多，所用的時(shí)間也就越長。
總之，數(shù)據(jù)錯誤的出現(xiàn)數(shù)量和頻率與數(shù)據(jù)傳遞的路徑長度和傳遞時(shí)長成正比。
要如何才能更好的運(yùn)用反饋環(huán)路推動 IT 運(yùn)維團(tuán)隊(duì)進(jìn)步？以下為四點(diǎn)建議。
不斷提高
Agile 和 DevOps 原則，即旨在采用敏捷軟件開發(fā)的方法，促進(jìn)軟件交付和基礎(chǔ)設(shè)施變更軟件開發(fā)人員和 IT 運(yùn)維技術(shù)人員之間的合作和溝通的原則，讓我們明白，在交流和執(zhí)行進(jìn)程中消除中間節(jié)點(diǎn)是在現(xiàn)代軟件交付業(yè)務(wù)取得成功的關(guān)鍵元素?？s短反饋環(huán)路不僅可以提高應(yīng)對速度，還可以降低數(shù)據(jù)出錯概率。
要想了解我們做的任何抉擇是否可以達(dá)到預(yù)期的效果，縮短反饋時(shí)間和減少中間步驟便是最高效、最徹底的方法。有競爭優(yōu)勢的公司都深知縮短反饋回路的秘訣。他們不僅在 IT 團(tuán)隊(duì)里采用 Agile 原則并推行有效的 DevOps 實(shí)踐，還將其貫徹到整個(gè)公司。這也是為了不斷提高而持續(xù)付出的努力。
隨著新流程和新工具的涌現(xiàn)與完善，目前的最佳實(shí)踐也很快會過時(shí)。隨著科技和創(chuàng)意的不斷進(jìn)步，推動其進(jìn)步的因素也逐漸浮出水面，這些因素有正面的也有負(fù)面的。其中有很多都是試運(yùn)行和錯誤導(dǎo)致的結(jié)果。正視反饋環(huán)路可以讓我們從這些因素中吸取經(jīng)驗(yàn)，正確應(yīng)對問題，不斷學(xué)習(xí)和進(jìn)步，而這反過來又促進(jìn)我們不斷創(chuàng)新我們的產(chǎn)品和服務(wù)。
棄用瀑布流式開發(fā)方式
瀑布流式規(guī)劃和交付方法極大地拉長了軟件發(fā)布周期，因此我們不再使用。競爭和創(chuàng)新需求日益增加，每個(gè)開發(fā)階段都需要縮短周期。瀑布流式方法的目標(biāo)是布置好一切，使計(jì)劃、范圍和資源都可以在前期決定。
可惜的是，這種方法意味著公司不能迅速響應(yīng)需求。當(dāng)客戶的需求或市場形勢發(fā)生改變時(shí)，IT 團(tuán)隊(duì)無法收到反饋并立即把它運(yùn)用到新的抉擇中。只能舍棄大量的計(jì)劃，從頭開始做起，不然無法進(jìn)行自我矯正。
通過系統(tǒng)思考視角考慮人工反饋
反饋并不單單在系統(tǒng)中產(chǎn)生。同事、合作方和客戶之間的語言及肢體交流也是反饋的另一些形式。通過系統(tǒng)視角查看這些反饋是一種更為精確的評估方式。后退一步檢查收到的反饋和數(shù)據(jù)，我們會理解得更加透徹。這一方法的獨(dú)有特點(diǎn)是幫我們過濾掉了一些不必要的判斷，同時(shí)也提高了可靠性。
為達(dá)到這一目的，需要回答三大問題：
- 給予者和接受者之間的差異是否會給反饋帶來摩擦？
- 當(dāng)反饋與常用系統(tǒng)聯(lián)系到一起時(shí)，反饋會與給予者和接受者之間的不同角色有聯(lián)系么？
- 進(jìn)程、政策、實(shí)體環(huán)境或系統(tǒng)里的其他因素會增加反饋的問題么？
以這種方式檢查反饋可以深入了解人員輸入輸出的信息流。通過系統(tǒng)思考（Systems Thinking）模式審視反饋，可以尋求更多方法、更精確地了解反饋環(huán)路，確認(rèn)導(dǎo)致失敗或成功的相關(guān)因素。不帶任何感情色彩，以最真實(shí)的形式去檢閱數(shù)據(jù)，從而進(jìn)一步提高我們求知能力和理解能力，最終積累經(jīng)驗(yàn)。
正是因?yàn)檫@些想法，才會有那么多高效的 IT 團(tuán)隊(duì)進(jìn)行事后免責(zé)剖析。以系統(tǒng)思考的模式了解故障期間發(fā)生的事件可以帶來更高的回報(bào)，更別說可能由此實(shí)現(xiàn)的巨大發(fā)展。
學(xué)習(xí)與創(chuàng)新
故障的不可避免性有著獨(dú)有魅力，它讓我們無需在系統(tǒng)中再次設(shè)置故障。正因如此，現(xiàn)在我們設(shè)計(jì)時(shí)會考慮故障現(xiàn)象，優(yōu)化減少修復(fù)的時(shí)間，建立反饋回路，以免漫無目的地尋找系統(tǒng)崩潰的根源。從這方面說，我們可以用不同的思維方式引導(dǎo)我們對后續(xù)措施的決定和選擇，來提高系統(tǒng)的可靠性和彈性。伴隨所有這些嘗試而來的，是一個(gè)由高效的 IT 團(tuán)隊(duì)構(gòu)建、維護(hù)和不斷改善的高可用系統(tǒng)。
修復(fù)已成為我們的目標(biāo)，而非干預(yù)或解除問題。使我們搖擺不定的反饋環(huán)路正是我們軌跡的引導(dǎo)者。我們利用失敗的機(jī)會去尋找盡可能多的創(chuàng)新發(fā)展領(lǐng)域，而不是研究哪里錯了。完全擯棄預(yù)測，取而代之的是「為失敗而建」的新理念，反過來讓我們在自己的進(jìn)程、工具甚至是自己提供的服務(wù)中得到提高和進(jìn)步。
通過對反饋（包括故障在內(nèi)）的不斷處理和響應(yīng)，我們可以利用與先前結(jié)果相關(guān)的信息來指導(dǎo)以后的工作。我們可以充分利用各種機(jī)會，像交通工具一樣，學(xué)著進(jìn)入新軌道并沿途修正路線，而非推測以后的條件。
實(shí)例例證
以國內(nèi)首個(gè) SaaS 云告警平臺 OneAlert 的實(shí)例為例，本人對他們在利用反饋環(huán)路來推動 IT 運(yùn)維團(tuán)隊(duì)進(jìn)步所做的努力概括了一部分：
- 自動化團(tuán)隊(duì)事件工作流，根據(jù)分派策略的不同，自動指派給適當(dāng)?shù)膱F(tuán)隊(duì)；
- 自動化運(yùn)營團(tuán)隊(duì)事件分析功能，先是通過事件聚合將事件分析功能半自動化，現(xiàn)在通過機(jī)器學(xué)習(xí)，基本實(shí)現(xiàn)事件關(guān)聯(lián)算法；
- 增加 Top 分析、應(yīng)用、團(tuán)隊(duì)和成員分析，讓反饋更直白簡單。
前兩點(diǎn)為主要是為縮短反饋環(huán)路的路徑長度和傳遞時(shí)長，減少人為造成的時(shí)間和真實(shí)性的損耗；第三點(diǎn)主要是從系統(tǒng)的角度考慮人工反饋，從而繼續(xù)學(xué)習(xí)和創(chuàng)新，用來指導(dǎo)以后的工作。補(bǔ)充一句：以上實(shí)例概括為本人基于使用了 OneAlert 后的一些體驗(yàn)，有更多詳細(xì)功能，可以訪問官網(wǎng)，歡迎一起交流。
參考文章：Loops On Loops: How Feedback Enables Improvement
本文轉(zhuǎn)自 OneAPM 官方博客
