在过去几年中，我多次帮助多家企业实现云服务的完善，安全且可靠。虽然这些公司的问题都不一样，但问题类型本质上还是可以归类的。这也是本文将会介绍的十诫。
我将这些多年实践总结出来的十诫分为两种类型：一种是针对商业决策者（高管），另一种针对技术决策者（技术团队中的工程师和管理者）
类型一 面向商业决策者
1.不要把云仅当着一个技术问题
敏捷或DevOps转型被广泛认为是涉及某种程度的自上而下的组织变革。这包括新的职责、新的工作方式以及团队之间新的沟通方式。您不能仅仅是指望通过买一个“DevOps Box”就能达到成功。
你的云计算采用与此无异。不要认为云计算仅仅是通过另一种方式交付同样的旧技术和工作方式。“迁移与转移”的思维方式最终会导致昂贵且臃肿的云计算采用失败。
在成功采用云计算作为优先选择的企业中，开发、运维、安全甚至财务等各个方面都会采取新的架构。请花时间理解并包容必需的深层次变化。
图片
2.从一开始就进行培训
你不能只是下达一个自上而下的组织强制采用云计算的命令，然后就离开，并期望会发生好的事情。
云计算是一场大规模的技术技能和团队职责的转变。拥有对云计算技术的深刻理解的人才并不常见，在市场上也并不易于获得。合作伙伴可以提供帮助，但最终你还是需要有一个计划，从内部培养这种专业知识。
在较大的企业中，建立云计算卓越中心是一个不错的开始，但我也看到过这些努力最终被划分为又一个信息孤岛。你不能只是创建一个“云团队”；你必须更广泛地推动一种文化，这意味着要在几个月甚至几年的时间里，细心设计云计算技能在整个组织中的普及。
是的，培训确实花费是很多，但云计算的本质是让你能够用相同数量的人工实现更高的价值。因此，将招聘预算的一部分转移到培训团队：当你的团队掌握使用由云服务提供商维护的服务时，你会对他们的成就感到惊讶。
设定正确的重点，提供适当的激励措施，你的员工将会逐渐实现转变。
图片
3.将云计算视为价值中心
我们仍然看到一些企业主要是出于节约成本的考虑选择云计算，尽管这样的企业比以往减少了——并且出于不错的理由。你选择云计算不是为了花更少的钱，而是为了创造更大的价值。
这就是为什么我喜欢把云计算描述为“IT的杀手级应用”的想法：就像电子表格让早期的个人电脑成为可取之处，云计算独自就能超越您IT投资的成本。
如果你的组织能够充分利用，云计算能够提升上市时间、创新速度和敏捷度。
一些公司会在云计费单上陷入困境，因为它是他们能看到和理解的与云计算采用相关的唯一指标——尽管它是一个令人痛苦的指标。成功指标，如价值产生的速度，并不是不可能衡量，但是需要有意识地努力建立和评估。
优先考虑实验，知道成功的标准，您就会发现云计算所产生的价值远远超过了成本。
4.从小开始，但不要无准备
很容易陷入几个月或甚至几年的云计算等待期。在Andy Jassy最近的re:Invent主题演讲中，他指出了一家组织，尽管该组织自吹自擂地宣称他们采用了云计算，但实际上他们只是部署了一些小的实验项目。虽然这种方法可能有利于您技术团队的简历打造，但对于业务而言却没有价值。
你在刚开始采用云计算时不会一下子就搞对，但不要让这种担忧阻止你开始行动。选择一个适中的工作负载，认真尝试将其运行在云上，找出短板，进行改进，重复，并不断扩大对云计算的了解。
认真对待云计算，就会得到认真的结果。
图片
5.信任你的合作伙伴
企业在云计算的门槛处陷入数月甚至数年的困境的一个原因是什么？他们意识到变革可能是复杂的，他们不想出错。
出于这个原因，在云计算的过程中介绍可信的合作伙伴是有道理的——那些在这条道路上走过，既知道陷阱，也知道捷径的人。
（顺便说一句，这也是支持公共云的一个很好论点。你真的认为你能比AWS更好地管理数据中心，或者比微软更好地构建开发者工具吗？对锁定的担忧在历史上是合理的，并且有其存在的价值，但最终你必须与能够适当利用风险的供应商合作。）
寻找你可以信任的云计算和咨询合作伙伴，然后给予他们足够的自由度，让他们帮助你实现持久的积极变化。
图片
类型二 面向技术决策者
6.不要因个人喜好选择技术栈
在技术决策中，存在这样一条普遍的建议：对于大多数问题，都应该采用经得起时间考验的长期使用的解决方案。没人因为写了另一个Rails应用程序或者任何类似的东西而被解雇。
这条建议在不发生重大破坏性前进跃进的世界中是合理的。然而，云计算改变了情况，因为一些新技术很大程度上减少了你需要管理的内容，同时增加了你提供的基础规模和功能。
例如，AWS的Amplify服务在移动端和后端开发的实时性方面进步很大。基于低代码、专注于模式的API开发方法绝对是优秀的；与云本地数据存储的紧密集成是更好的。并且因为AppSync后端是一个云服务，它会随着时间的推移不断改进，而你不必做任何事情。可能需要你花几周时间才能完全熟悉。但是，在这种情况下，投入一些时间学习的回报是持久的。
关键是，你的感觉可能会出卖你。你需要冷静地评估哪些工具和服务能为你提供最大的收益。
图片
7.时间是最珍贵的资源；全力优化
你每天都接触到的最昂贵的资源不是你的生产数据库集群、应用服务器群或日志框架。而是你的日程安排。
你和你的团队拥有有限的周期来构建和维护技术。不要浪费时间重复造轮子。
举个不幸的个人例子，我之前的工作中花费了大量时间从零开始构建一个全栈式的部署框架和管道工具。虽然最终这个部署管道确实为业务提供了一定的价值，但代价是数千小时的工程时间。
如果我和团队更多地依赖现有的云服务，我们可以在更短的时间内完成同样的功能，用来从事更有价值的项目，而不用总是解释给管理层我们在干什么。
鉴于云原生开发高度重视使用现成的服务，它使你在日程表上有更多宝贵的时间可用。
图片
8.更早地开始在云上构建。不，比那还早一点。
我已经一直在鼓励“本地测试代码，云上测试服务”的理念。随着无服务器开发在技术栈中的位置越来越高，维护独立于云之外的本地开发环境的价值也越来越小。
如果必须这么做，可以在本地迭代代码；在远程栈（显然不是生产栈）部署的角色和资源上进行测试。你在开发生命周期中越早这么做，发现权限和配置问题的速度就越快，在生产环境中出现意外情况的可能性也就越小。
我认为对此有最好理解的供应商是Stackery。我非常喜欢他们的“cloudlocal”开发概念，尽管我觉得这个名字不太可能流行。他们的命令行工具是我知道的唯一一个目前支持在本地执行AWS Lambda函数，并使用与云部署版本相关联的角色的工具。（当你调用本地函数时，他们会将信任关系注入到该角色中。）我预测，其他主要的无服务器部署框架，如AWS SAM和Serverless Framework，也将很快为此提供更好的支持。这是未来的发展趋势。
图片
9.忽略虚假的问题
你可能认为工作中本来就有足够多的真实问题，无需捏造虚假问题。不幸的是，软件工程师非常擅长找到那些真正不重要的问题的解决方案。
例如，你的应用程序真的需要跨区域吗？如果整个AWS us-east区域都宕机了，你的应用程序需要保持可用性吗？你会花多长时间维护多区域的事务一致性，你会花多少钱来复制数据，而不是每隔特别长一段时间就优雅地短暂停机？
移植性是一个巨大的虚假问题。就像有人说过，如果你正在使用Kubernetes，你必须是很聪明：这是必须的，而不是一种恭维。协调服务网络、服务代理、入口路由等是一项非常复杂的任务。
我甚至看到人们在无服务器应用中设计复杂的抽象层，以便他们在需要选择不同的云服务商时可以随时更换技术。
一个真正明智的技术决策者明白，你可以擅长的事情范围是很小的。利用云服务，从箱子里获得经过生产硬化的体系结构，然后在其上构建你独特的功能。
如果你必须使用Kubernetes，可以考虑使用一些像EKS on Fargate或SpotInst Ocean这样的管理服务，它们可以隐藏许多冗长的细节（并且可以在超低价的点实例上调度容器）。
更不用说，你可以通过与云服务提供商更紧密地集成获得很多优势。直到云服务提供商表明他们将锁定掠夺性的价格（这迄今没有发生），你的时间可能更值得用来交付功能。
我的决策流程很简单：不要只注重代码，忽视云服务。
图片
10.通过展示价值来创造动力
作为一名技术决策者，一个可以直接参与代码开发的人，你特别适合找出在你的领域中可以产生最大影响力的技术。
如果你无法获得关于一个设计决策的赞同，而你觉得该决策有明显的好处，你可以试着在云端为它制作一个原型——这通常可以迅速而且廉价。
作为技术决策者，你可以给企业提供一个强有力的理由：你已经构建了业务所需要的东西。它运行得快，并且易于维护。
图片
不管你是商务决策者还是技术决策者，云迁移的成功最终取决于你是否愿意接受不舒服感：去挑战自己能够构建产品的界限，摒弃舒适圈，并信任那些为你指明前进道路的供应商和合作伙伴。
如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。
原文地址：https://www.trek10.com/blog/ten-commandments-for-cloud-decision-makers
