从这 5 个 DevOps “恐怖故事”，我们能学到什么？

DevOps 是企业转型的关键。但要明确的是，DevOps 是一个过程，而不是目标。从这个意义上说，实践 DevOps 需要不断优化，不断去学习、尝试更好的方法。持续改进 DevOps 实践是推进企业转型的重要途径。

就算是一些很知名的企业，在将 DevOps 应用于其转型战略时，也会犯错误并面临可怕的后果。不过，幸运的是，他们从失败中吸取了宝贵的教训。

SlideShare：限制对生产环境的访问

SlideShare 是全球最大的内容分享社区，很早就推出了 DevOps 模型以加快开发流程。

时间回到 2012 年，当时它还是一家员工不到 20 人的小型初创公司，开发团队分散在旧金山和新德里，基础设施相当复杂。

有一次，一位开发人员试图使用一种新工具分析 MySQL 数据库。当他开始更改数据库中列的顺序时，他不知道的是，这也改变了生产环境中的数据库，最终导致 Slideshare.net 瘫痪，拒绝了试图访问它的六万多个用户。而且事故发生时，负责人并没有意识到是该工具正在执行操作，最后通过集体的努力，花了 15 分钟才找出问题的根源。

时任运营工程师的 Sylvain Kalache 评论说，虽然 DevOps 与授权团队中的每个人都相关，但对生产环境的访问应该仅限于少数能够处理它的人。这就是为团队和个人配置高级的、基于角色的访问 (RBAC) 的重要性。AWS IAM 之类的工具对于确保每个人都可以访问执行他们的日常任务至关重要，但不能完全访问可能会损害用户体验。在这种情况下，为了不会影响用户，开发人员可以访问暂存环境来尝试该操作。

Knight Capital：自动化的黑暗面

Knight Capital 因为 DevOps 失败付出了惨痛的代价。它是一家全球性金融服务公司，曾凭借其高频交易算法，成为美国最大的股票交易商，在纽约证券交易所市场份额为 17.3%，

Knight Capital 使用了一个名为 SMARS 的内部应用程序来处理股票市场的买单。这个应用程序已经运行了很多年，它的代码库中有很多过时的部分。其中一个部分是名为 Power Peg 的功能，该功能处于非活动状态，但未从代码库中删除。

2012 年，在为应用程序编写新代码时，新代码无意中调用了 Knight Capital 忽略的 Power Peg 功能。结果，Knight Capital 的应用程序在短短几分钟内就完成了价值数十亿美元的采购订单。这导致该公司支付了 4.6 亿美元的罚款，并在一夜之间破产。

教训：自动化非常强大，但如果使用不当，可能会导致重大事故。而且，随着时间的推移，流程需要更新，需要在应用程序中引入新功能，以免更改发生冲突。

Workflowy：不要轻易分拆数据库

Workflowy 是一个简单而优雅的生产力工具，并且一直在稳步增长。为应对用户增长，开发者需要对架构进行优化。由于数据库变得庞大，于是他们决定，将一个大型数据库分解为多个较小的数据库。

在这个过程中，他们发现，分解成多个小数据库会减慢查询速度并阻止用户访问数据。一些用户无法从他们的移动设备同步数据，而其他用户则无法登录 Web 应用程序。

经过一番故障排除后，团队发现其使用的 Web 服务器 (Apache) 存在一个从未遇到过的错误，在修复了该错误并试图让所有人重新登录后，该网站又再次关闭了。

最后发现，他们分解数据库的过程是根本原因，并通过避免对数据库的某种 “慢查询” 的方式，保持了网站正常运行。此外，他们还升级了基础设施以加快查询速度。

教训：分解数据库可能会导致性能问题，甚至中断，但是隔离关键问题并首先解决它们，这样就可以更快地恢复服务。

IRS：迁移到云端

美国国税局 (IRS) 并不以其技术实力而闻名。毕竟，它的工作是收税，而不是推动技术创新。

这也许就是处理纳税申报表的 IRS 应用程序在 2016 年失败的原因。一个处理数百万美国人纳税申报的计算机服务器上的电压调节器于 2 月 3 日开始出现故障。当一名技术人员努力解决这个问题时，备用电压调节器也出现了故障。

事实上，40 年来，美国国税局一直在尝试更新其主要计算机系统，但都失败了。之后，还陆续爆出 “拥有 60 年历史的 IT 系统因新硬件而在纳税日崩溃”、“计算机故障导致数千名纳税人收到错误信息” 等新闻。

教训：在管理基础架构时，很多事情都可能出错。解决方案是将基础架构迁移到云端。今天，云是运行应用程序最可靠的方式。将设置和维护物理硬件的工作交给云供应商，这样就可以专注于最重要的事情 —— 运行和改进应用程序。

Instapaper：了解您的云供应商

Instapaper 是一款离线阅读应用。最初，它以 Softlayer 作为其云供应商，但被 betaworks 公司收购后，转移到了 AWS。但是团队并不熟悉 AWS。

2017 年 2 月，Instapaper 出现了长时间的服务中断。开发团队注意到， AWS RDS 上的一个 MySQL 数据库空间不足，深入挖掘之后发现，原来 2014 年 4 月之前创建的所有 RDS 数据库的大小均限制为 2TB，而他们存储用户书签的数据库已经达到了这个 2TB 的限制。

在与 AWS 团队进行多次讨论并获得 Pinterest 开发人员的一些帮助后，Instapaper 使用 Aurora 对现有数据进行索引，并在具有更大大小限制的新实例中创建新数据库。最终，服务恢复了。

教训：需要了解使用的云供应商的限制。如果您使用多个云供应商，或者您从一个提供商迁移到另一个提供商，则尤其如此。

写在最后：

无论是数据库、硬件基础设施、遗留代码还是云供应商限制，在实践 DevOps 时，可能会蹦出无数种你想不到的问题。不过，我们可以从失败案例中习得一些经验教训，尽量避免出现这些问题。比如，IRS 如果能更早地将基础架构迁移到云端，就不需要每年花费数千万美元来解决各种本不应该出现的问题。如果 Knight Capital 能正确地使用自动化工具，也不会至于破产。

事实上，在项目设计阶段就要考虑到，使用什么样的工具或者说平台能够更好地实现产品功能。如果说有什么平台能够屏蔽基础设施的多样性，配置高级的访问权限，能够自动化联动测试、智能预警，那非 SoFlu 软件机器人莫属了。

SoFlu 软件机器人是飞算推出的全自动化软件工程平台，采用了通用的技术功能模块，支持循环、条件判断、函数调用等组件，用户只要根据业务逻辑，通过拖拽方式进行参数配置，就能完成编程。而且，平台统一了代码规范，不依赖人工编码、审码，因此可以从源头上保证代码高质量。总而言之， SoFlu 软件机器人通过可视化编程的方式满足低门槛开发需求，输入流程图即可实现自动开发。