如何避免 IT 运营 5 大成本陷阱？

本文要点

• 新的解决方案在最初的开发阶段或集成阶段的决策都会显著影响未来运维的成本。
• 对于功能开发中期预算的错误假设可能会导致采购领域的错误决策。由于实施 DevOps 和#noprojects 的组织认为人员配备比旧的“项目与运营”方法更稳定，因此风险特别突出。
• 许多成本陷阱与供应商和客户等利益相关方之间关于中间件选择的矛盾有关，或与敏捷团队与高级管理层关于集中运营和支持任务的矛盾有关。
• 一旦应用程序上线，把资金转移到不同组织的计划会增加意外的高昂运维成本风险。
• IT 应用环境的持续成本优化，要求成本模型把架构决策和未来的维护及运营成本联系起来。

很多公司喜欢把预算从 IT 维护及运营转移到创新 IT 项目上。但是，他们很难找到新的省钱方案，这是因为最近大多数组织经历了很多成本削减、外包和离岸计划。我们为这样的组织提供了一个崭新的视角——项目的 5 个决策领域，这些领域对后续运营有显著的影响（“陷阱”）。避免这些陷阱是腾出资金以用于真正创新的一种简单方法。

软件开发人员喜欢使用敏捷和 DevOps 方法以每天、每周或每月的节奏交付新功能。尽管创新公司中致力于关键应用的团队可能多年来都在这个模式下工作，但是，对于大多数工程师和应用程序来说，实际情况是有所不同的。很多较小的软件项目由一个紧张的初始阶段开始，该阶段会持续几个月或一两年时间。然后，该应用程序有望交付预期的业务价值。而开发工作继续进行，但是，在几个月（或几年）后，该项目就会达到一个转折点。公司会意识到为新功能投入更多资金并不能增加多少商业价值。他们就会削减资金，对工程师来说意味着工作量的减少。他们中的大多数会转到其他产品或项目的工作上。

DevOps 变成“无需开发工作的 DevOps，”，也即老式的维护和运营。偶尔，剩下的工程师实现一些更改或小型升级，如图 1 所示。其他时候，他们会处理这些工作：确定错误、解决用户问题及维护。

图 1：随着时间的推移，当新功能的添加不再增加多少业务价值时，DevOps 就变成只需进行少量升级的维护工作了。

从员工密集的初始阶段到具有成本效益的维护及运营阶段的过渡面临一个重大挑战：所有的任务和“专门知识”都需要转移给剩下的少量工程师或转给组织中的其他团队。

#noprojects 运动等更新的方法可以缓解一些挑战，但是，商业现实还是一样的：更少的开发任务意味着对具有实践经验，可以介入解决问题或实现更改的工程师的需求也更少了。

这种过渡不仅对新软件的很多业务案例很关键，对创新能力也很关键。在软件的运营和维护阶段花更少的钱意味着有更多的资金可用于启动下一个创新项目。聪明的组织因为了解这个因果关系，所以提前进行计划，避免了我们下面要讨论的 5 种成本。

陷阱 1：集中化不适合时代精神

一个典型的节省成本方法是整合和集中化的中间件及数据库生态系统。这种方法有三个维度：

• 集中专家意见——一个中央数据库管理团队为组织提供支持。
• 共享的安装和实例——一个共享的数据库而不是每个应用程序都安装一个数据库。
• 减少技术“动物园”（the technology zoo）的大小—— 有一个（或两个……）且必须使用的技术作为公司标准。其他类似的解决方案被淘汰，并不再用于新项目。比如，IT 可以选择 MariaDB 和 Oracle 为标准，而不再继续使用 DB2、Microsoft SQL Server 及 MySQL。

乍一看，集中化与 DevOps 和敏捷的精神背道而驰。敏捷团队希望自给自足。他们希望自己的团队具有所有所需的技能，这样，他们就不用依靠外部的、集中化帮助来交付他们的冲刺。尽管这种自给自足是一个指导原则，但 DevOps 团队总是要依靠一些集中化的团队。没有 DevOps 团队会愿意考虑构建其自己的数据中心或自己管理 OS 层级的病毒扫描和补丁管理等所有事务。因此，真正的问题是，出于成本、合规或其他原因，哪些工作必须外包给一个集中化团队？项目或产品团队在哪些领域可以选择自行完成工作（即使相关领域有负责的集中化团队）？图 2 说明了标准服务的生态系统。

图 2：这张图显示了 IT 组织如何定义团队必须在哪些地方遵循公司标准以及在哪些地方可以自行选择。红线下方的服务是集中化的：硬件层、操作系统层和某些中间件服务（数据库、应用程序服务器）。关于应用程序和集成层的任务以及消息和开发工具等专用服务可以由团队负责。无论如何，他们可以自由使用可用的集中服务。

最终，每家公司和 IT 组织必须确保团队无论敏捷与否，在行动和决策上必须与公司的整体目标和 CIO 的 IT 策略保持一致。他们定义了所有敏捷或非敏捷和 DevOps 或老式的开发及运营团队行动的边界。

一种更细粒度的方法可以区分谁来做这个工作（集中专家意见），是否需要使用集中安装（共享安装）和组织是否有适用于所有项目和产品团队的强制性准则和标准（减少技术“动物园”的大小）。在后两种情况下，项目或产品团队可以自行工作，只要他们使用共享的实例和 / 遵循公司的标准即可。

但是，这种独立性可能是个成本陷阱。在当前阶段，数据库管理员或数据科学家可能有足够的工作，但是，半年之后，情况可能有变。一旦项目或产品切换到运维阶段，那么，团队的规模将急剧缩减。专门的任务必须移交给专门的集中团队，以不会损害质量及稳定性需求为前提的情况下降低成本。如果这种任务的转移不可行，并且成本仍然很高，那么可能导致管理人员不必要的关注和行动。

陷阱 2：避免过度规范

盲目地遵循供应商的要求和安装准则成本很高。在我的一个项目中，软件供应商希望银行使用其产品随附的开源数据库。与此同时，该银行已经在使用由数据库管理员支持的一个大型 Oracle 工作数据库。

只需考虑一下成本和质量的差异：

• 在现有共享数据库中放入一个小模式的工作量最小。
• 在新数据库产品中训练有 2 到 3 名员工的应用程序团队的工作量是很大的，而且与全职数据库管理员相比，他们只有很少的实践经验。

这种过度规范的原因很简单：软件供应商追求规模经济。于是，他们限制了支持中间件选项 （供应商和版本）的数量，因而减少了需要测试的配置数量。例如，他们申明带 Java 13.0.1 和 SQL Servers 16 SP2 的 RedHat7.6 是经过认证的，而其他组合则没有经过认证，从而过度规范了配置。显然，该应用程序或多或少可以和所有的 Linux 发行版本和 SQL 数据库一起使用。他们只是不希望花时间和资金来测试所有这一切。这种方法与 IT 部门的需求有冲突。他们希望标准化其应用程序和集中化任务（参见陷阱 1）。所有应用程序应该运行在相同的版本上。他们不希望自己数以百计的应用程序要使用不同的数据库或 Linux 安装。图 3 说明了这种冲突。

图 3：在选择中间件和要使用的确切发行版本时，通过考虑现有的中央实例和支持团队以降低运营成本。在本例中，蓝色的行表明各软件可以使用的中间件，并区分具有认证的选项和软件供应商不支持但可用的选项。绿色的行表明对于某个软件版本，是否已有中央实例和支持团队。

通过明确决定他们满足哪个供应商的系统需要，IT 部门可以避免过度规范的陷阱。新中间件每年的成本一般都会超过 10 万美元，至少接下来的 4 到 5 年时间是这样的。培训、增加工程师和 / 或具有更深资历、监控、补丁管理等等的工程师都会增加成本。

如果软件供应商或项目坚持使用特定的中间件而导致意外的后续成本，那么我们该怎么做？答案很简单：重做业务案例。然后，项目发起人需要决定是继续、修改还是取消该项目。

陷阱 3：开发成本和运营成本之间不存在线性关系

Elasticsearch 是个非常出色的开源组件，用于给软件解决方案添加搜索功能 。就我个人而言，Elasticsearch 让人大开眼界：开发成本和维护成本之间通常不存在线性关系。

实际的情况是，工程团队说服公司，Elasticsearch 是给软件添加搜索功能经济高效且快速的方法。该软件开发项目经理对他的团队感到非常自豪，并且公司也喜欢这个提议。把便宜的或免费的软件作为构建模块，用最小的工作量添加复杂的新功能是极其伟大的工程工作。然而我们要注意一件事。如果给一个有 10 万行代码的应用程序添加 100 行代码，那么这对维护和运营成本来说影响很小。如果为了集成一两个“免费”组件而添加 100 行“胶水”代码，那么，维护和运营成本的（主要）驱动因素是添加的组件和组件之间额外接口的复杂性，而非代码的行数。

我们来解释一下这个问题：每个人都很清楚 Linux 或 Hadoop 是免费的，但是需要专门的团队来运行它们。这对 TYPO3 和 MariaDB 等解决方案及 Elasticsearch 集成或用于谷歌地图的接口来说也同样适用，尽管通常不是很明显的。我们可能不用支付许可证的费用，但是仍然需要一个团队来维护和操作这类解决方案及与它们的接口。

该陷阱是假设我们只需维护短短几行代码，可是为了监督它们所需的组件和接口给运营人员带来了很多工作。解决方案？不仅要考虑维护自行编写的代码行所需的工作量。还一定要估算出给解决方案添加接口和“免费”组件的运营和维护的工作量。

陷阱 4：高运营成本的发起者不承担责任。

这似乎是完美的设置：创新型的 IT 公司开发该软件。他们与业务部门频繁地联系以详细讨论所需功能。与此同时，IT 部门组织将业务移交给富有经验的 IT 服务供应商。这样的设置相当吸引人。在公司内部，每个组织专注于其最熟悉的方面：业务部门考虑银行客户的需求，IT 组织考虑将应用程序管理和操作外包给 IT 服务供应商。此外，银行选择了最好的软件开发公司和最好的运营公司。但这样的设置是有风险的。实际情况是：项目（和业务）专注于功能，而无视后续成本。由于他们只是从业务的角度来讨论功能，IT 部门并没有参与讨论。显然，一旦 IT 部门的负责人意识到将来的运营和维护有多么昂贵，他们是不会感到高兴的。然而，解决方案已被实施， 已经造成了损害。

当回过头来分析这样的情形（并了解风险）时，三个主要的利益相关方的责任三角是比较有用的：该责任三角由这三个部分组成：首先是参与工程工作的人员，如软件开发人员。其次是决定功能的人员，如产品所有者。再者也是最后一个是支付账单的发起人，如业务部门。

图 4: 主要利益相关方的责任三角

当项目从开发密集阶段向维护及运营密集阶段转移，并且所有这三个利益相关方继续保持不变时，产生糟糕的意外风险就很低。但是，尤其是发起人的变化会导致失衡及运营成本定时炸弹。尽管批评项目经理或外部公司是件简单的事，但这只是个花招罢了。真正的原因出在该项目的文化和 / 或缺少治理上：组织如何测量项目的成功？只是查看那些在预算内准时交付的东西就够了？是否反映了后续的运营成本？谁估计更改对运营成本的影响以及谁批准了这样的更改？

陷阱 5：抵制简单化的成本模型

我们有没有考虑过一个良好的成本 / 价格模型与一个优秀的模型之间的不同？一个良好的模型反应了 IT 组织为内部或外部客户提供服务所形成实际的成本和工作量。这可能是一个后验估计。而一个优秀的成本模型能让消费者模拟（事先）估算其决策如何影响未来的成本，并通过这个来进行成本控制。

当我们希望简化应用程序场景并以一种可持续的方法降低 IT 运营成本时，关键是把架构决策与后续的运营成本直接联系在一起。在决定更改请求或架构变体前，经理必须知道对成本的影响。这需要简单或甚至简化的成本模型。想要添加一个具有三个接口的组件？那么我们每年运维的预算是 30000 瑞士法郎（参见图 5）。如果在实施以后才明白对运营的成本影响，那就太迟了。

图 5：运营成本的简化成本模型

对这类设置最大的阻碍是情感。工程师把应用程序视为“他们的宝贝”，独一无二的艺术作品，相比之下一般的成本模型太简单且不够用。让他们实施自己的建议，然后（直到那时）才有可能有个良好的运维成本估算。另一个典型的说法是，发起人必须为 IT 运营付费。他们总是说：“哦，它只是一个小接口，几乎不需什么额外的工作。你不想宰我吧，对不对？”从我自己的经验来说，这是消费者 / 服务供应商之间关系的一种微妙情形。但是，真正的陷阱是“全包”成本模型。由于每个组件和接口都没有价格， 因此不方便讨论。只有一个固定价格。副作用是：现在没有动力去优化了。在需要重新计算成本时，比如说，一年之后，复杂性的增加将导致了没有人意识到的额外成本。

展望

我们讨论了应用程序的 5 个典型成本陷阱，这些应用程序迟早会从开发阶段移到较少开发的维护和运营阶段。这 5 个成本陷阱围绕着所有权和治理层面。想要解决它们，常常不是技术和工程知识或资金的问题，而更多是该组织或管理层是否有意愿去真正在组织方面努力的问题。我们要获得快速、高性能项目和创新方法的好处，也要为没人关心新功能并且只在乎成本的情况做好准备。我们是否已经准备好应对这个挑战了呢？

作者简介

Klaus haller 是资深 IT 项目经理和解决方案架构师，其在数据管理及分析、信息安全及合规、业务分析、软件工程和测试方面非常有经验。他喜欢应用自己的分析技能和技术创新，为具有高度不确定性的复杂项目找到解决方案。Klaus 毕业于德国 TU Kaiserslautern 及瑞士科技联邦学院（Swiss Federal Institute of Technology，简称 ETH，位于苏黎世）的计算机科学专业，并定期发表反映其在 IT 业界工作经验的文章。

原文链接：

5 IT Operations Cost Traps and How to Avoid Them