DevOps企业实践指南-第二条原则：反馈
本帖最后由 adminlily 于 2018-11-7 17:06 编辑DevOps的第二条原则名为反馈，它存在于价值流的各个阶段的逆向过程中，通过反馈而使得工作更加安全和可控。
而反馈的重要性在大型复杂系统中显现的更加重要，在故障出现最初端倪的时候就能检测到的能力对于一个不能中断和降低服务标准的关键性功能来说是无比重要的。
高度复杂的系统
在科技领域, 工作在一个或多个超级复杂的系统结合起来的环境中, 可能会出现的极高的灾难性的风险相伴而生. 比如2015年的纽约证券交易所曾经暂停交易218分钟。
全世界最繁忙的交易系统停止的218分钟，每秒钟都是巨大的损失，虽然不了解纽约证券交易所的系统是如何运作的，但是能够支持全世界最庞大的证券业务运营的系统怎么来说也都应该是行业翘楚，其实类似的情况并不罕见，巨型系统的复杂性已经远远超出了我们的想象，而且一旦发生问题，则将会是灾难性的。
制造业经验学习
而在制造业领域，很多时候在严重问题可能会发生的刚开始的时候，很多现象都会被检测到，更早发现，更早对应，成本更低，速度更快，代价更低，这是我们从制造业经验中所学到的。
而且我们也将会应用到DevOps的实践之中，问题的发现和反馈的回路非常重要，在反馈原则的实践中，更重要的是我们将会将每次问题发生都视作一次机会，一次从中学习的机会，而不是责备和惩罚。
当然这是需要前提的，只有我们确保和确信我们的系统运作是安全的，这些问题的发生不会导致灾难性的结果为前提的。
更加安全的复杂系统
复杂系统往往有高度耦合的各功能组件，难以简单解释的各种系统行为，以及与无数外接系统的千丝万缕的关联，导致很难对其可能的失败进行精确的原因预测。
为什么像核反应堆这样的系统如此复杂，其可能出现的故障难道不能准确预测么？Charles Perrow博士通过对三里岛危机进行研究发现：准确预测在各种情况下的反应堆的可能的反应以及如何会发生故障近乎不可能。当某一个部分的问题正在发生的时候，很难将其和其他部分分开，快速的变化使得结果变得无比复杂，而预测也变得近乎不可能。
而Sidney Dekker博士通过研究也发现了复杂系统的另外一个特性，两次同样的执行并不能一定通向一致的结果。
在复杂系统中，问题的发生既然是不可避免的， 我们所能做的则是撞见一种安全的机制，就像制造业中所做到的那样，问题能够快速的被检测到，远远在其出现灾难性后果之前，已经开始着手对应，明察秋毫，防微杜渐，而不是病入膏肓之后下虎狼之药。而这样的机制使得我们对问题的出现不再畏惧，同时文化的改变才有可能的土壤。
检测问题发生
在一个更加安全的系统中，新的想法/功能等都需要经常地测试以确保其正确性。我们的目标就是多快好省地创建和更新系统。我们验证出越多的问题，就意味着能更快的修复问题/增强扩展性/提高速度，同时获得更快的学习和创新能力。
而这些则可通过创建反馈回路来帮组达成。Peter Senge博士在他的”The Fifth Discipline”一书中这样写道：学习型的组织会把反馈回路作为学习型组织以及系统思考方式的重要组成部分。
在制造业中，缺少有效的反馈经常会导致质量和安全问题的发生。在制造业中这样的例子比比皆是。而在高效的制造企业中，在整个价值链中，快速高频度高质量的信息流动随处可见，每个工序都被测量和监视，任何故障或者可能引起问题的偏离都会很快地被发现和纠正。而正是这些奠定了创建高质量的安全的系统，从中进行持续学习和改进的基础要件。
而在软件开发领域，这种在制造业中习以为常的反馈却在很长时间内不是那样随处可得。比如在传统的瀑布型软件开发中，往往是设计和编码全部完成之后，才能从测试阶段的关于质量的反馈，甚至于一部分只有在发布之后才得到反馈，而这一切都已经太晚，而且往往影响也已经非常的严重。而我们所期待的则是在软件开发领域也能创建和制造领域中一样的机制为我们保驾护航。
反馈回路不仅能够快速检测问题和辅助故障恢复，通过这种机制进行持续学习还能使得在将来再次出现这种问题的时候如何进行预防。这种持续性的学习最终将推动持续学习和成长的创新型企业文化的落地生根。
解决问题 持续学习
当然，仅仅通过反馈回路检测到预期外的问题发生还远远不够，我们需要解决这些问题。让我们再次将目光投到制造业是如何做的，当问题发生的时候，团队的Leader将会立即被通知到而其开始立即着手去解决问题，当这个问题在一个一定的时间比如55秒没有的得到解决，整条生产线会停下来而整个组织去一同帮助，直到问题得到解决。区别于带病作业或者安排一个“等闲下来了就立即去对应”的日程，立即聚集起来去解决这个问题，有需要的时候甚至会停下来整个生产线。
看起来很简单，但是往往在最初的阶段需要决心和勇气。在凤凰项目里面曾经将部署冻结，其实也是类似于制造业的做法的学习，不让问题继续扩散，在问题的初期进行对应是最好的选择之一。一旦发现反应堆已经开始溶化了，这时候去对应已经为时已晚。所以只有通过在整个流动的过程中经可能早地发现小的问题之后立即聚集起来进行解决，我们才有可能创建一个安全的机制保证在灾难性的后果发生之前能够有足够时间去对应和解决。
质量控制 人人有责
大型复杂系统中，问题的发生是不可避免的，随着问题的不断发生，监视和审批的流程可能会增加的越来越多。质量控制中很多效率低下的情况都在发生，比如：
◇ 要求其他的团队去完成单调重复/容易出错的大量手工作业
◇ 要求不在一线的繁忙的某人去作决定是否应该做某个操作，而此人可能完全不懂相关技术，而且上下文有可能也没有说清楚。
◇ 或者是大量的内容，等到看的时候已经可能发生了变化。
◇ 扔出一些需要首先对应的问题给某些团队然后开始等待。
而事实上，我们需要在价值链中的每个人在日常的工作当中去发现和对应这些问题，质量控制，人人有责。通过这种方式，质量和安全的责任的控制，不再是来自上层的审批，而是变成了现场的每个人在持续学习和成长的同时，发现反馈回路中的问题，参照精益的经验进行聚集和立即对应。当然还是有很多最佳实践可以帮助我们在这个过程中做的更好。比如，通过Peer Review确保结果的正确性， 通过自动化使得原本容易出错的枯燥重复的大量作业变得安全高效。
总的来说，我们通过强化整体质量是每个人的责任这一意识，区别于传统方式下的每个人只确认自己的单独的责任，更好的实现组织的目标。
另外，这种整体化的意识也会需要反馈的及时和迅速。就像Gary Gruver 观察到的那样：“当有人抱怨开发人员在六个月之前做错的事情的时候，开发人员也很难从中学到任何东西–而这个正是为什么我们需要反馈要尽可能的快，问题发生后的几分钟之内，而不是几个月后”。
非功能要素的优化
在整个价值流中，那些非功能性的需求同样非常重要。在一定程度上，后续的问题很多都是由于这些非功能性的要素的设计重视不够才引起的。比如：架构/性能/稳定性/可测性/配置/安全要素等等，由于这些要素没有像功能性要素那样给与了足够重视所引起的问题也屡见不鲜。给与非功能性要素足够重视，不断进行优化，也是非常重要的。
总结
通过创建快速反馈对于达成稳定/可靠/安全的系统至关重要。
通过快速反馈回路，在问题发生的时候，我们能第一时间看到，自然能够立即行动起来去解决问题，从中学习到新的知识，每个人都参与到质量的控制中，无论是功能性要素还是非功能性要素都给与足够重视，不断优化，从而使得整个系统更加安全和稳定。
原创：刘淼
页:
[1]