在2002年我们几个人成立的一家小型初创公司，我们在超过50%的台式机上运行Linux。我的桌面保持着最长正常运行时间的记录：173天。然后，由于计划中的电力系统维护，主电源和UPS都用完了，它也不得不关闭。我向无数的朋友吹嘘我的制度。现在，这是什么固定与一个系统，不关闭。作为个人，我的个人电脑可能在晚上执行了一些不那么关键的任务：从CVS中检查和构建一些工具的最新副本，并在晚上执行构建一大块软件的工作。没什么大不了的。

但是，想象一下，当你早上第一件事登录时脸上的笑容，这已经完成并准备好了吗？偶尔，当我们进行GUI更新时，我不得不按Ctrl+Alt+Backspace来终止X服务器时，情况变得非常糟糕。

系统的许多部分不可用，与我们的自然反应不一致。上周我的公寓停电了，原因是漏水（变成了一个喷泉，落在电源插座上），导致我的电源短路。现在，让企业用户更上一层楼。尤其是那些卡车因无法执行必要的SD处理而无法按计划交货的客户。这是一张可怕的照片。。正确的？这的确是一种损失，效率低下和烦恼。

这个问题的正确答案是什么？是云吗？你们中的许多人可能在不远的过去看到过AWS停机： 所以，真正的答案在于我们思考工程的能力！

运行我们应用程序的每一层：

必须设计为具有弹性，以真正避免我们的最终客户停机。

最近，我们有一位客户报告了从质量到生产的运输过程中出现的问题，他准备了一个实时实例：这个过程需要几个小时，这比他们能够承受的系统停机时间还要多。这让我检查了我们手头要解决的可能性。

我们对TR进行了合并，以尽量减少对象的数量（TR创建、排序和压缩），并使用了注释中的说明：1223360:导入期间的性能优化和1069417–程序的生成和语法检查。这可能适用于您。

同时，我们还可以将其他几种技术尽可能形象化：

它描述了创建克隆生产系统的可能性–启动操作，并在发生这种情况时，收集"旧"系统上可能出现的增量日志迁入新环境

求和

甚至在云中，在地理分布的站点上提供故障保护机制，以避免停机。

除了这里的技术，客户计划采用一种新的解决方案来提供/避免这些类型的惊喜。

纯功能技术供应商可以通过启用热插拔或集群技术来帮助榨取这一等式中的最后几滴果汁。除此之外，它在应用程序开发领域还留有相当大的空间来检查升级期间每个模块/跨模块的"依赖性"。回滚阻力最小的路径是什么？更重要的是，要确保数据的一致性。如果我们有可以进行依赖性分析的小部件，并给出一个对我来说在周日晚上支持的重要事务列表，并检查我计划的升级和软件是否会影响其中任何一个事务，那就太好了。随着过去几年我们在代码透明性和使用分析方面取得的进步，我敢肯定，在不远的将来，我们将有一个非常精细的视图，我们可以运行SAP功能多年，而不会真正出现任何中断。