毫无疑问，您想知道项目基础结构的成本是多少。 同时，令人惊讶的是：费用的增长相对于负荷不是线性的。 许多企业主，服务站和开发人员暗中了解到他们多付了钱。 但是到底是什么呢？
通常，降低成本可以归结为简单地找到最便宜的解决方案，AWS资费，或者，如果我们谈论的是物理展位，则可以优化设备配置。 不仅如此：事实上，任何人都这样做，就像上帝把它带入灵魂：如果我们谈论的是一家初创公司，那么这可能是领先的开发商，他们拥有足够的彩旗。 在较大的办公室，首席营销官/首席技术官负责处理此事；有时，首席执行官亲自与总会计师进行一对夫妇的干预。 通常，那些拥有足够“个人资料”的人会担心。 事实证明，基础设施账单正在增长，但他们却发现了……那些没有时间处理它的人。
如果您需要在办公室购买卫生纸，供应经理或清洁公司的负责人会这样做。 如果我们在谈论发展-潜在客户和CTO。 销售-一切也很清楚。 但是，即使是从大胡子时代开始，当“服务器”被称为机柜时，其中有一个普通的塔式系统，其中有更多的RAM和几次硬检查，所有（或至少很多）都忽略了应对容量购买这一事实。也是受过专门训练的人。
遗憾的是，历史记忆和经验表明，这项任务已经转移了数十年，以“随机”人员：最亲近的人提出了这个问题。 直到最近，FinOps专业才开始成形，并在市场上呈现出一些特定的轮廓。 这是经过特别培训的人员，其任务是控制容量的购买和使用。 并最终降低了该领域的公司成本。
我们不竭力放弃昂贵而有效的解决方案：每个企业都必须自行决定要满足铁和云关税的舒适生存所需要的东西。 但是，人们不能不注意这样一个事实，即如果不对随后的许多公司进行使用情况的监视和分析，而在清单上进行周密的购买，由于对后端“资产”的管理效率低下，会导致非常非常巨大的损失。
谁是FinOps
假设您有一家稳固的企业，卖家渴望的企业称其为“企业”。 可能是，“在清单上”您购买了十二个或两个服务器，AWS和其他“在小事上”。 这是合乎逻辑的：在一家大公司中，存在某种运动-一些团队成长，另一些团队解散，而另一些则转移到相邻的项目中。 当查看下一个每月基础设施账单时，这些动作与“基于列表的”采购机制的结合最终导致了新的白发。
那么该怎么办-耐心地进一步变灰，涂满油漆或弄清付款中出现这么多可怕的零的原因？
隐藏一个罪过：在公司内部以相同的AWS费用批准，批准和直接支付应用程序并不总是（几乎从来没有）成为现实。 仅仅由于公司的不断运动，其中的一些收购可能会“迷失”在某个地方。 只是闲着。 如果一位细心的管理员注意到他的服务器机房中没有所有者，那么在云收费的情况下，一切都会变得更加艰难。 他们可以开一个月的玩笑-带薪，但同时被其收购所在部门的任何人都不再需要。 同时，下一个办公室的同事们还没有开始白发，不仅是在他们的头上，还在其他地方-他们无法在同一周为他们支付同样的AWS费用，这是迫切需要的。
最明显的解决方案是什么？ 没错，将the绳交给需要帮助的人，每个人都很高兴。 是的，只有水平沟通并不总是很完善。 第二部门可能根本就不知道第一部门的财富，而对于这种财富来说，以某种方式并不是特别必要。
谁该怪？ -一般没人说。 到目前为止，一切都已安排好。
谁受此困扰？ -就是这样，整个公司。
谁可以解决这种情况？ -是的，是FinOps。
FinOps不仅是开发人员与他们所需设备之间的一层，而且是一个人或团队，他们将知道该公司购买的相同云收费标准在哪里，什么地方以及如何“谎言”。 实际上，这些人一方面应该与DevOps在同一团队中，另一方面应该与财务部门在同一团队中工作，充当有效的中介，最重要的是，发挥分析作用。
关于优化的一点
乌云密布。 比较便宜，很方便。 但是，当服务器数量变为两位数或三位数时，此解决方案便不再便宜。 此外，云使使用越来越多以前不可用的服务成为可能：这些是数据库即服务（Amazon AWS，Azure数据库），无服务器应用程序（AWS Lambda，Azure Functions）以及许多其他服务。 它们都很酷，因为它们易于使用-买和开车，没问题。 这只是公司及其项目深入云端的深度，CFO的睡眠就越糟。 而且一般将变成灰色的速度越快。
事实是，各种云服务的账目总是非常混乱：您可以获得一个三页的解密信息，用于说明您的钱，去向，去向和方式。 当然，这很好，但是要理解它几乎是不可能的。 此外，我们对这一问题的看法远非唯一：为了将云帐户转移给人类，需要使用全部服务，例如
www.cloudyn.com或
www.cloudability.com 。 如果有人因创建用于解密帐户的单独服务而感到困惑，那么问题的规模将超过染发的成本。
那么在这种情况下FinOps会做什么：
- 清楚地了解购买云解决方案的时间和数量。
- 知道如何使用这些权力。
- 根据特定单位的需要重新分配它们。
- 不买“那是”。
- 最后，它可以为您节省金钱。
一个很好的例子是数据库冷拷贝的云存储。 例如，您是否存档以减少更新存储时占用的空间和流量？ 是的，这种情况似乎很便宜-在特定情况下，但是这种便宜情况的整体会转化为云服务的高昂成本。
或另一种情况：您在AWS或Azure上购买了备用电源，以免受到峰值负载的影响。 您可以确定这是最好的解决方案吗？ 毕竟，如果这些实例80％处于空闲状态，那么您只需将钱捐给亚马逊。 此外，在这种情况下，相同的AWS和Azure具有易爆实例-如果可以使用该工具解决高峰负载的问题，为什么需要免费吸烟服务器？ 或者，而不是On Premise实例，您应该朝Reserved的方向看-它们要便宜得多，并且可以为其提供折扣。
说到折扣正如我们在一开始所说的，任何人都经常从事采购工作-他们找到了最后一个，然后又以某种方式自己找到了自己。 通常，已经忙碌的人会变得“极端”，最终，我们遇到这样的情况：一个人快速而熟练地但完全独立地决定购买什么数量的数量。
但是，当从云服务方面与卖方进行交互时，就批量购买容量而言，您可以获得更有利的条件。 很明显，从具有静音和单面注册功能的汽车获得这样的折扣是行不通的-但是与真正的销售经理交谈后，它可能会耗尽。 或者这些家伙可以告诉他们现在有什么折扣。 也有用。
同时，您需要记住，在AWS或Azure上，灯光并未汇聚。 当然，没有关于组织自己的服务器机房的讨论-但是巨人提供了这两种经典解决方案的替代方案。
例如，谷歌为公司带来了Firebase平台，可以在该平台上以交钥匙方式放置相同的移动项目，这可能需要快速扩展。 使用该解决方案的示例可以进行存储，实时数据库，托管和云数据同步。
另一方面，如果我们不是在谈论整体项目，而是在谈论它们的组合，那么集中式解决方案并不总是有益的。 如果项目是长期的，具有自己的开发历史和存储所需的相应数据量，则值得考虑更加零散的布局。
在优化云服务成本时，您可能突然意识到对于关键业务应用程序，您可以购买更强大的资费，以确保公司的收益不中断。 同时，将开发，旧档案，数据库等的“传统”存储在昂贵的云中也是您自己的解决方案。 确实，对于此类数据，具有常规HDD和中等功率硬件且没有任何“批处理”的标准数据中心非常适合。
再次，您可能会认为“大惊小怪是不值得的”，但此出版物的整个发行是基于这样一个事实，即负责任的人员在各个阶段都轻而易举，并且尽可能地方便快捷。 最终，几年之内就转化成了同样的恐怖经历。
结果如何？
通常，云很酷，它们可以解决各种规模的企业的许多问题。 但是，这种现象的新颖性导致我们仍然没有消费和管理文化的事实。 FinOps是一种组织杠杆，可帮助您更有效地利用云功能。 最主要的是不要把这个职位变成解雇班子的类似物，后者的任务是用手抓住那些注意力不集中的开发人员并“责骂”他们以备不时之需。
开发人员应该开发，而不是数钱。 因此，FinOps应该使购买流程以及退役或将云功能转移或转让给其他团队的流程对于各方而言都是一件简单而令人愉快的事情。