论反馈信息如何推动 IT 运维团队进步？

我们还记得《快乐大本营》中经典游戏----快乐传真吗？游戏规则是：很多人站一排，只有第一个人才看到最准确的信息，用东西隔着，戴耳机，一一将从前一个人获得的信息传递下去，最后一个人说出推测的信息。但是往往最后一个人说出的答案五花八门，基本上和第一个人说的内容完全不搭边！

回忆这个游戏主要是为了告诉大家，信息在一连串的传递过程中是很容易受损的。在与消息源的间接交流过程中，与信息有关的细节和事实容易被稀释，从而导致信息的内容自然而然地（有时则是有意）产生或多或少的改变。

最开始传递的消息在传回消息源头时往往变得面目全非。很明显，消息传递经过的人越多，循环时间越长，产生的错误必然就越多。

通过对这一活动的观察，我们还可以得到一个非常明显但也非常重要的结论：消息重新传回源头的用时有极大差异，且随着信息传递的必经之路上加入的新节点越多，所用的时间也就越长。

总之，数据错误的出现数量和频率与数据传递的路径长度和传递时长成正比。

要如何才能更好的运用反馈环路推动 IT 运维团队进步？以下为四点建议。

不断提高

Agile 和 DevOps 原则，即旨在采用敏捷软件开发的方法，促进软件交付和基础设施变更软件开发人员和 IT 运维技术人员之间的合作和沟通的原则，让我们明白，在交流和执行进程中消除中间节点是在现代软件交付业务取得成功的关键元素。缩短反馈环路不仅可以提高应对速度，还可以降低数据出错概率。

要想了解我们做的任何抉择是否可以达到预期的效果，缩短反馈时间和减少中间步骤便是最高效、最彻底的方法。有竞争优势的公司都深知缩短反馈回路的秘诀。他们不仅在 IT 团队里采用 Agile 原则并推行有效的 DevOps 实践，还将其贯彻到整个公司。这也是为了不断提高而持续付出的努力。

随着新流程和新工具的涌现与完善，目前的最佳实践也很快会过时。随着科技和创意的不断进步，推动其进步的因素也逐渐浮出水面，这些因素有正面的也有负面的。其中有很多都是试运行和错误导致的结果。正视反馈环路可以让我们从这些因素中吸取经验，正确应对问题，不断学习和进步，而这反过来又促进我们不断创新我们的产品和服务。

弃用瀑布流式开发方式

瀑布流式规划和交付方法极大地拉长了软件发布周期，因此我们不再使用。竞争和创新需求日益增加，每个开发阶段都需要缩短周期。瀑布流式方法的目标是布置好一切，使计划、范围和资源都可以在前期决定。

可惜的是，这种方法意味着公司不能迅速响应需求。当客户的需求或市场形势发生改变时，IT 团队无法收到反馈并立即把它运用到新的抉择中。只能舍弃大量的计划，从头开始做起，不然无法进行自我矫正。

通过系统思考视角考虑人工反馈

反馈并不单单在系统中产生。同事、合作方和客户之间的语言及肢体交流也是反馈的另一些形式。通过系统视角查看这些反馈是一种更为精确的评估方式。后退一步检查收到的反馈和数据，我们会理解得更加透彻。这一方法的独有特点是帮我们过滤掉了一些不必要的判断，同时也提高了可靠性。

为达到这一目的，需要回答三大问题：

给予者和接受者之间的差异是否会给反馈带来摩擦？
当反馈与常用系统联系到一起时，反馈会与给予者和接受者之间的不同角色有联系么？
进程、政策、实体环境或系统里的其他因素会增加反馈的问题么？

以这种方式检查反馈可以深入了解人员输入输出的信息流。通过系统思考（Systems Thinking）模式审视反馈，可以寻求更多方法、更精确地了解反馈环路，确认导致失败或成功的相关因素。不带任何感情色彩，以最真实的形式去检阅数据，从而进一步提高我们求知能力和理解能力，最终积累经验。

正是因为这些想法，才会有那么多高效的 IT 团队进行事后免责剖析。以系统思考的模式了解故障期间发生的事件可以带来更高的回报，更别说可能由此实现的巨大发展。

学习与创新

故障的不可避免性有着独有魅力，它让我们无需在系统中再次设置故障。正因如此，现在我们设计时会考虑故障现象，优化减少修复的时间，建立反馈回路，以免漫无目的地寻找系统崩溃的根源。从这方面说，我们可以用不同的思维方式引导我们对后续措施的决定和选择，来提高系统的可靠性和弹性。伴随所有这些尝试而来的，是一个由高效的 IT 团队构建、维护和不断改善的高可用系统。

修复已成为我们的目标，而非干预或解除问题。使我们摇摆不定的反馈环路正是我们轨迹的引导者。我们利用失败的机会去寻找尽可能多的创新发展领域，而不是研究哪里错了。完全摈弃预测，取而代之的是「为失败而建」的新理念，反过来让我们在自己的进程、工具甚至是自己提供的服务中得到提高和进步。

通过对反馈（包括故障在内）的不断处理和响应，我们可以利用与先前结果相关的信息来指导以后的工作。我们可以充分利用各种机会，像交通工具一样，学着进入新轨道并沿途修正路线，而非推测以后的条件。

实例例证

以国内首个 SaaS 云告警平台 OneAlert 的实例为例，本人对他们在利用反馈环路来推动 IT 运维团队进步所做的努力概括了一部分：

自动化团队事件工作流，根据分派策略的不同，自动指派给适当的团队；
自动化运营团队事件分析功能，先是通过事件聚合将事件分析功能半自动化，现在通过机器学习，基本实现事件关联算法；
增加 Top 分析、应用、团队和成员分析，让反馈更直白简单。

前两点为主要是为缩短反馈环路的路径长度和传递时长，减少人为造成的时间和真实性的损耗；第三点主要是从系统的角度考虑人工反馈，从而继续学习和创新，用来指导以后的工作。补充一句：以上实例概括为本人基于使用了 OneAlert 后的一些体验，有更多详细功能，可以访问官网，欢迎一起交流。

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

本文转自 OneAPM 官方博客