DevOps企业实践指南(4): 第二条原则：反馈
DevOps的第二条原则名为反馈，它存在于价值流的各个阶段的逆向过程中，通过反馈而使得工作更加安全和可控。而反馈的重要性在大型复杂系统中显现的更加重要，在故障出现最初端倪的时候就能检测到的能力对于一个不能中断和降低服务标准的关键性功能来说是无比重要的。
高度复杂的系统
在科技领域, 工作在一个或多个超级复杂的系统结合起来的环境中, 可能会出现的极高的灾难性的风险相伴而生. 比如2015年的纽约证券交易所曾经暂停交易218分钟.
| 开始时间 | 终了时间 | 持续时长 |
|---|---|---|
| (美国东部时间)2015/07/08 11:32 | 2015/07/08 15:10 | 218分钟 |
全世界最繁忙的交易系统停止的218分钟，每秒钟都是巨大的损失，虽然不了解纽约证券交易所的系统是如何运作的，但是能够支持全世界最庞大的证券业务运营的系统怎么来说也都应该是行业翘楚，其实类似的情况并不罕见，巨型系统的复杂性已经远远超出了我们的想象，而且一旦发生问题，则将会是灾难性的。
制造业经验学习
而在制造业领域，很多时候在严重问题可能会发生的刚开始的时候，很多现象都会被检测到，更早发现，更早对应，成本更低，速度更快，代价更低，这是我们从制造业经验中所学到的。而且我们也将会应用到DevOps的实践之中，问题的发现和反馈的回路非常重要，在反馈原则的实践中，更重要的是我们将会将每次问题发生都视作一次机会，一次从中学习的机会，而不是责备和惩罚。当然这是需要前提的，只有我们确保和确信我们的系统运作是安全的，这些问题的发生不会导致灾难性的结果为前提的。
更加安全的复杂系统
复杂系统往往有高度耦合的各功能组件，难以简单解释的各种系统行为，以及与无数外接系统的千丝万缕的关联，导致很难对其可能的失败进行精确的原因预测。
| 时间 | 事件 | 影响 |
|---|---|---|
| 1979/03/28 | 由于设备故障，三里岛核电站2号机组反应堆的冷却水外溢 ，导致反应堆部分毁坏。 | 事故现场，3人受到了略高于半年的容许剂量的照射。核电厂附近80千米以内的公众，平均每人受到的剂量不太大的影响。对环境影响极小 |
| 1986/04/25 | 切尔诺贝利核电站4号反应堆预定关闭以作定期维修。由于操作失误，燃料棒开始熔化并引发爆炸，使反应器顶部移位和受破坏，放射性污染物之后进入大气，燃料棒碎片也散落在附近区域。 | 至少32名工人及消防员在数月内死亡.大约4000名儿童和青少年因喝了被放射性物质污染的牛奶而得了甲状腺癌。 |
| 2011/03/12 | 日本3/11大地震导致福岛县两座核电站反应堆发生故障，其中第一核电站中一座反应堆震后发生异常导致核蒸汽泄漏。于3月12日发生小规模爆炸。 | 日本当局划设了长12.5英里的禁区，禁区内16万名居民被迫搬离家园。 |
为什么像核反应堆这样的系统如此复杂，其可能出现的故障难道不能准确预测么？Charles Perrow博士通过对三里岛危机进行研究发现：准确预测在各种情况下的反应堆的可能的反应以及如何会发生故障几乎近乎不可能。当某一个部分的问题正在发生的时候，很难将其和其他部分分开，快速的变化使得结果变得无比复杂，而预测也变得近乎不可能。
而Sidney Dekker博士通过研究也发现了复杂系统的另外一个特性，两次同样的执行并不能一定通向一致的结果。
在复杂系统中，问题的发生既然是不可避免的， 我们所能做的则是撞见一种安全的机制，就像制造业中所做到的那样，问题能够快速的被检测到，远远在其出现灾难性后果之前，已经开始着手对应，明察秋毫，防微杜渐，而不是病入膏肓之后下虎狼之药。而这样的机制使得我们对问题的出现不再畏惧，同时文化的改变才有可能的土壤。
检测问题发生
在一个更加安全的系统中，新的想法/功能等都需要经常地测试以确保其正确性。我们的目标就是多快好省地创建和更新系统。我们验证出越多的问题，就意味着能更快的修复问题/增强扩展性/提高速度，同时获得更快的学习和创新能力。
而这些则可通过创建反馈回路来帮组达成。Peter Senge博士在他的”The Fifth Discipline”一书中这样写道：学习型的组织会把反馈回路作为学习型组织以及系统思考方式的重要组成部分。
在制造业中，缺少有效的反馈经常会导致质量和安全问题的发生。在制造业中这样的例子比比皆是。而在高效的制造企业中，在整个价值链中，快速高频度高质量的信息流动随处可见，每个工序都被测量和监视，任何故障或者可能引起问题的偏离都会很快的被发现和纠正。而正是这些奠定了创建高质量的安全的系统，从中进行持续学习和改进的基础要件。
而在软件开发领域，这种在制造业中习以为常的反馈却在很长时间内不是那样随处可得。比如在传统的瀑布型软件开发中，往往是设计和编码全部完成之后，才能从测试阶段的关于质量的反馈，甚至于一部分只有在发布之后才得到反馈，而这一切都已经太晚，而且往往影响也已经非常的严重。而我们所期待的则是在软件开发领域也能创建和制造领域中一样的机制为我们保驾护航。
反馈回路不仅能够快速检测问题和辅助故障恢复，通过这种机制进行持续学习还能使得在将来再次出现这种问题的时候如何进行预防。这种持续性的学习最终将推动持续学习和成长的创新型企业文化的落地生根。
解决问题 持续学习
当然，仅仅通过反馈回路检测到预期外的问题发生还远远不够，我们需要解决这些问题。让我们再次将目光投到制造业是如何做的，当问题发生的时候，团队的Leader将会立即被通知到而其开始立即着手去解决问题，当这个问题在一个一定的时间比如55秒没有的得到解决，整条生产线会停下来而整个组织去一同帮助，直到问题得到解决。区别于带病作业或者安排一个“等闲下来了就立即去对应”的日程，立即聚集起来去解决这个问题，有需要的时候甚至会停下来整个生产线。
看起来很简单，但是往往在最初的阶段需要决心和勇气。在凤凰项目里面曾经将部署冻结，其实也是类似于制造业的做法的学习，不让问题继续扩散，在问题的初期进行对应是最好的选择之一。一旦发现反应堆已经开始溶化了，这时候去对应已经为时已晚。所以只有通过在整个流动的过程中尽可能早地发现小的问题之后立即聚集起来进行解决，我们才有可能创建一个安全的机制保证在灾难性的后果发生之前能够有足够时间去对应和解决。
质量控制 人人有责
大型复杂系统中，问题的发生是不可避免的，随着问题的不断发生，监视和审批的流程可能会增加的越来越多。质量控制中很多效率低下的情况都在发生，比如：
- 要求其他的团队去完成单调重复/容易出错的大量手工作业
- 要求不在一线的繁忙的某人去作决定是否应该做某个操作，而此人可能完全不懂相关技术，而且上下文有可能也没有说清楚。或者是大量的内容，等到看的时候已经可能发生了变化。
- 扔出一些需要首先对应的问题给某些团队然后开始等待。
而事实上，我们需要在价值链中的每个人在日常的工作当中去发现和对应这些问题，质量控制，人人有责。通过这种方式，质量和安全的责任的控制，不再是来自上层的审批，而是变成了现场的每个人在持续学习和成长的同时，发现反馈回路中的问题，参照精益的经验进行聚集和立即对应。当然还是有很多最佳实践可以帮助我们在这个过程中做的更好。比如，通过Peer Review确保结果的正确性， 通过自动化使得原本容易出错的枯燥重复的大量作业变得安全高效。
总的来说，我们通过强化整体质量是每个人的责任这一意识，区别于传统方式下的每个人只确认自己的单独的责任，更好的实现组织的目标。
另外，这种整体化的意识也会需要反馈的及时和迅速。就像Gary Gruver 观察到的那样：“当有人抱怨开发人员在六个月之前做错的事情的时候，开发人员也很难从中学到任何东西–而这个正是为什么我们需要反馈要尽可能的快，问题发生后的几分钟之内，而不是几个月后”
非功能要素的优化
在整个价值流中，那些非功能性的需求同样非常重要。在一定程度上，后续的问题很多都是由于这些非功能性的要素的设计重视不够才引起的。比如：架构/性能/稳定性/可测性/配置/安全要素等等，由于这些要素没有像功能性要素那样给与了足够重视所引起的问题也屡见不鲜。给与非功能性要素足够重视，不断进行优化，也是非常重要的。
总结
通过创建快速反馈对于达成稳定/可靠/安全的系统至关重要。通过快速反馈回路，在问题发生的时候，我们能第一时间看到，自然能够立即行动起来去解决问题，从中学习到新的知识，每个人都参与到质量的控制中，无论是功能性要素还是非功能性要素都给与足够重视，不断优化，从而使得整个系统更加安全和稳定。
Referrence
| 参考文献 | 作者 |
|---|---|
| The DevOps Handbook | John Willis, Patrick Debois, Jez Humble, Gene Kim |
DevOps企业实践指南(4): 第二条原则：反馈相关推荐
- DevOps企业实践指南(3): 第一条原则：流动
DevOps的三条基本原则:流动/反馈/文化.第一条原则(流动)需要达成快速平稳地从开发向运维的价值流动,从而更快的进行价值交付.在这个过程中,作为开发或者运维的局部目标被弱化,而开发和运维等协同所产 ...
- DevOps企业实践指南(5): 第三条原则：文化
第一条原则体现了价值流的从左向右的流动,第二条原则是快速和日常的行为带来的从优向左的反馈.第三条原则聚焦于创造一个持续学习和持续实践的企业文化.而这些原则使得组织中的成员能够不断地积累知识和经验,而这 ...
- DevOps企业实践指南(8): 安全机制
DevOps落地实践中,安全机制应该如何保证,这篇文章从当前安全状况调查解读开始,同时介绍了DevOps落地实践时应该遵循的原则. 安全问题现状 Kaspersky Lab对26个国家超过5500公司 ...
- DevOps企业实践指南(1):DevOps能为我们带来什么
帮助盈利/提升文化/加速效率是DevOps实践的三大目标,上世纪八十年代在制造业领域展开的那场如火如荼的精益实践的变革还历历在目,而DevOps在软件领域将要或者已经掀起的风浪也是如出一辙. Dev+ ...
- devops实践指南_开发DevOps的实用指南：减少八卦的步骤
devops实践指南 我的一个软件开发的朋友最近问我,如果我可以告诉他,他可以做什么亲自来鼓励更多的合作与理解的工作环境-一个与更一致建议 从未来 的社区的DevOps . 我们之间的对话很长,他的情 ...
- 深入分析游戏设计的8条原则
原文链接:http://gamerboom.com/archives/78680 深入分析游戏设计的8条原则 发布时间:2013-11-11 16:33:03 Tags: 反馈, 奖励, 平衡, 流 ...
- 阿里巴巴DevOps实践指南 | 为什么DevOps的必然趋势是BizDevOps？
简介:从精益思想出发,我们可以看到DevOps的必然发展方向,那就是向业务侧延伸.业务是产品开发和运维的源头,完整的价值流必须从源头开始.这不是预测,而是正在发生的事实 编者按:本文源自阿里云云效团队 ...
- 重磅发布！阿里云云效《阿里巴巴DevOps实践指南》
简介:6月23日,在2021阿里巴巴研发效能峰会上,由阿里云云效团队20位专家共同撰写的<阿里巴巴DevOps实践指南>(以下简称指南)正式对外发布.本指南是阿里云云效团队对过去十年阿里巴 ...
- DevOps Master教练十二条原则
作者:北京老李:EXIN授权EXIN DevOps Master(大师级)讲师(首批全国十名) .EXIN授权EXIN Agile Scrum .Product Owner.Lean IT 认证讲师 ...
最新文章
- linux7 kernel.sem,centos7.4内核调优，tcp单服务器万级并发
- Robotium todolist.test.elements
- 02 小程序入门实战
- ssm框架restful风格实现增删改查
- 分布式缓存服务器设计原理
- bzoj 1863 二分+dp check
- go语言初体验（流程控制、range遍历、函数、结构体、面向对象）
- AnotherRedisDesktopManager下载地址
- go mongodb排序查询_「赵强老师」MongoDB中的索引（下）
- Django框架(20.Django的视图函数的request参数以及QueryDict对象）
- 为Ubuntu安装build-essential软件包
- c语言缩写一个人的名字,用C语言输入一个人的英文名字统计个数输出
- Python机器学习库sklearn自动特征选择（训练集）
- mysql load data 一行_MySQL LOAD DATA LOCAL INFILE仅导入一行
- 无线网络 设置网关和服务器,我家的网络连接的IP是 192.168.1.223 我想问网关是多少 服务器是...
- c语言函数实现数组输入输出
- 比亚迪秦后排座椅拆卸
- 阿尔泰数据采集卡模拟量采集演示
- 上传图片格式一句话木马
- 看了这个逻辑关系图，才更清晰为何不让你随便外出了