The False Economy of not Changing Anything
较大的组织通常必须支持在几个不同平台上生活的无数应用程序。有些是本土的，有些是第三方套餐，有些是外部主持的服务。有些还很年轻，有些是可以追溯到几十年的。即使是用相同编程语言编写的那些也可能需要不同的系统配置或库的不同版本。这是一个具有挑战性的混合袋平台和应用程序。
处理这种复杂性的一种常见策略是避免进行任何更改（最近影响了许多金融机构的一个例子：在较旧的第三方应用程序中缺乏TLS 2支持）。
Usually, three key reasons are given for adopting a no-change strategy.
First, many of these systems are hard to update. In the worst cases, the source code was lost years ago and the original vendor went out of business before the customer’s technical staff was born. In more typical cases, the code was not originally designed to accommodate updates. Vendors concocted a wide variety of schemes to enable customers to update the code. These usually involve matching source code line numbers between the installed version of a product and a set of updates, or some “clever” method even more fragile than that. Complicating the matter further, most customers have made local custom changes to the code over the years, so the line numbers don’t match and the customized routines may not work with the updates installed. Once the technical staff manages to get a stable version of the application working, people leave it alone until it breaks. They may forego年更新是因为应用更改的麻烦实在太大了。
其次，大型企业中的系统通常以多种方式互连。多年来，开发人员在系统之间增加了连接，并且数据以组织中没有人理解的方式流向了许多系统。通常，通过所有系统的数据流都没有记录在任何地方，也不在交叉应用依赖项中记录下来，如果某人上游添加字段或扩展了现有字段的可能值，则不会破坏的接口。没有文件，没有数据库列，没有程序，没有删除程序中的例程，因为没人知道会有什么影响。因此，环境中有很多资源实际上没有使用，亚傅体育app但是没有人有信心他们对依赖关系有足够的了解来删除任何内容。对任何系统的任何变化都有造成下游影响的风险。“上游”和“下游”是乐观的词。流动的各种方式。
第三,任何历史悠久的大型企业upwards of 2,500 applications in production at any given time. It also has quite a few different platforms in the environment, and different versions of each platform to support different applications that vary from convention in unique ways or that have dependencies on obsolete versions of libraries. Even a company that has 100,000 employees doesn’t have enough technical staff to keep up with all that. If they tried to keep all their systems up to date, the technical staff would have no time to do any other work.
但是……听起来不像虚假经济。听起来像是朴素的经济。所以有什么问题？
问题
冒着过度简化的风险，我们可以通过这种方式说明问题：我们推迟更新系统的时间越长，当不可避免的情况最终发生时，更新或替换它们就越困难和昂贵。
It might surprise you to learn how many well-established and trustworthy institutions are running their systems justthis closeto disaster, every day. A single hardware fault could affect customers to the tune of tens of millions of dollars. The delay involved in updating key legacy applications to support a new regulatory requirement could cost tens of thousands per month in fines.
Most of the larger, older companies are running at least one mission-critical application on a hardware platform or operating system version that is no longer supported. Every year they leave that system in place they increase the financial impact that will hit them when it finally fails.
大公司有明确灾难重建very (DR) plans. They routinely test their DR procedures at least once annually; sometimes more often than that. The problem is that they typically don’t keep their DR procedures up to date with respect to new applications and technical resources. Their DR testing processes don’t properly exercise the DR plan; they don’t go to the extent of bringing up the full data center at the hot site. They just hit a few high points.
结果是可以预见的。与客户合作时，我已经看到了不止一次。他们丢失了数据中心或其子集，并激活DR程序以将操作移至热门站点，并为此支付高度的每月费用。不可避免地，至少一个关键系统无法在第二个站点出现。有时，他们了解其数据库备份损坏的困难方式；他们的DR测试过程没有验证所有数据库是否可以恢复。
If it’s hard, do it often
人性（我想；我不是心理学家）导致我们avoid困难或痛苦的事情。公司给出的避免更换系统的原因都归结为这一点：这是艰难而痛苦的。
One mantra of the Agile community is that if something is hard, do it often. Do it so often that it becomes routine. Do it so often that you完全了解压力升高时该怎么做。经常这样做，如果存在缺陷，例如不可读的数据库备份，您会发现它前there’s a crisis.
敏捷主义者通常指的是诸如持续整合之类的事情。从角度来看，小土豆。但是，相同的理念可以应用于数据中心管理和系统更新。
The approach works well for application updates, too. I’ve worked with client personnel when they had to update a third-party package by matching up line numbers. When their management insisted they not apply updates until it was absolutely unavoidable, they had to apply updates for version 25.32 of a system, released in 2017, to their current production version 3.01, released in 1986. The vendor provides help for customers running old releases as far back as 23.0, just in case everyone isn’t quite up to date. Quite nice of them. It’s precisely as much fun as it sounds. (I made up those numbers, by the way. But you get the point.)
这就是虚假经济becomes obvious. The amount of time technical staff must spend to sort out that kind of an update is very costly. Had they simply applied each update as it was released down through the years, it would be a painless no-brainer, completed in minutes or hours. And if the DR plan had been properly exercised, they could make the changes without fear, confident in their recovery process. Instead, the company pays direct cost of labor for an extraordinary number of work hours, plus opportunity cost of all the work the staff isnot在他们浏览更新时，请按行行。
Conclusion
最终，将所有内容保持最新状态并修复任何立即出现的不一致之处要比推迟更新和更改要便宜得多。头上的头和手指交叉并不是一个可行的策略。
What about the third reason to keep things the same…insufficient number of technical people to keep up with all the changes? It turns out that the more frequently they apply updates to the systems, the easier and quicker it becomes. The reason they don’t have time to update everything today is that they’ve allowed things to deteriorate for so long. Once they get to the point that updates are routine, they’ll be able to handle the workload.
那博士程序？继续前进，在辅助站点中提出完整的数据中心，并从中运行实时生产。定期来回切换。这样，你absolutely知道每个站点都可以站在另一个站点。您越多地这样做，您就越会熨烫扭结并自动化困难的部分。