软件开发者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
注册/登录 InfoQ 发表评论