软件开发者 Brian Troutwine 在 DevOps Days 上分享了有关复杂系统和实时系统的话题,内容涉及到人与机器的交互。Brian 举例说明了哪些是正确的自动化,哪些是不正确的自动化。
实时系统并不仅仅是快速运行的系统,而且是有时间期限的系统。实时系统可分为如下几类:
- 软类型(soft),即过期后收益递减
- 固类型(firm),即可容忍偶尔的过期,只是会影响整体系统的服务质量(QoS)
- 硬类型(hard),即任何过期都会导致整个系统不可用
复杂系统则通常带有如下特征:
- 非线性反馈
- 与外部系统耦合
- 难以建模,难以理解
Brian 用两个例子介绍了关于人类跟机器关系的两种解读:阿波罗 13 号事件中的人类与机器协作,以及切尔诺贝利核事故中的人类与机器的对抗。
在宇宙飞船的项目中,NASA 总是不确定要如何把人类安插到系统当中。有些实验构建了完全自动化的飞船,软件的设计思路完全来自于工程师。宇航员则不觉得这是个好主意,因为他们都是经验丰富的飞行员,在他们看来,宇宙飞船也无非就是更高级的飞机而已,应该由人类来操作,计算机作为辅助系统,人和机器之间达到一种平衡的状态。在阿波罗 13 号事件当中,正是经验丰富的宇航员找到了问题的关键,改造系统以适应他们的需求,才最终解救了自己。
工具在上述事件中的作用是:
- 正确的自动化减少了重复性劳动
- 正确的自动化减少了错误
- 正确的自动化解放人类
而在第二个例子当中,切尔诺贝利核电站的系统被设计成了正反馈系统,即一旦有错误发生,错误会叠加反馈给系统自身,最终造成灾难。在一次后备系统的测试过程中,反应堆进入了容易发生错误的临界状态。由于系统设计和管理上的缺陷,警告信息被忽略,而操作员则进行了误操作;另一方面,反应堆的安全系统当时处于关闭状态。在这种人类不受信任的环境当中,反应堆最终出了故障。这是一个系统处于主导地位,最终导致人类死亡、流离失所。
- 错误的自动化把人类机器化了。系统不给人类提供信息。
- 错误的自动化提供错误的指引,提供错误的信息。
- 错误的自动化使人陷入困境。
每个系统都潜藏着毁灭自己的种子。“正常的意外”总是不可避免,因此故障必然会发生。每个系统的设计都要将故障纳入考虑,否则系统故障将会以想象不到的方式发生。
在设计一个复杂系统的时候,需要认识到人类的局限性并以自动化补充这部分局限性。这个工作不能自己闷头做,需要跟人沟通,集思广益:
- 用资源交换你需要的东西。
- 接受故障,从故障中学习。
- 从他人的事故中学习。
- 那些一旦故障就造成大损失的组件,可能不值得去做。
- 理解你构建的东西。
本次分享来自 DevOps Days 第二天的内容。第一天的内容可在InfoQ 英文站上查看。
查看英文原文: Automation with humans in mind: making complex systems predictable, reliable and humane
评论